[U-Boot] [PATCH] arm: imx-common: introduce back usec2ticks

2016-04-28 Thread Peng Fan
This commit "2bb014820c49a63902103bac710bc86b5772e843"
do some clean up to use the code in lib/time.c.
But usec2ticks is still being used by security related job ring code.
Bring back the function to avoid build break.

Signed-off-by: Peng Fan 
Cc: Stefano Babic 
---
 arch/arm/imx-common/timer.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/imx-common/timer.c b/arch/arm/imx-common/timer.c
index 92c7218..bde24af 100644
--- a/arch/arm/imx-common/timer.c
+++ b/arch/arm/imx-common/timer.c
@@ -124,3 +124,20 @@ ulong get_tbclk(void)
 {
return gpt_get_clk();
 }
+
+/*
+ * This function is intended for SHORT delays only.
+ * It will overflow at around 10 seconds @ 400MHz,
+ * or 20 seconds @ 200MHz.
+ */
+unsigned long usec2ticks(unsigned long usec)
+{
+   ulong ticks;
+
+   if (usec < 1000)
+   ticks = ((usec * (get_tbclk()/1000)) + 500) / 1000;
+   else
+   ticks = ((usec / 10) * (get_tbclk() / 10));
+
+   return ticks;
+}
-- 
2.6.2

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


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

2016-04-28 Thread Tom Rini
On Thu, Apr 28, 2016 at 05:55:17PM -0500, Adam Ford wrote:

> I am hoping to look at this tomorrow at work. Any suggested toolchain you
> recommend?

gcc-4.9.x fails (too large), gcc-5.3.x succeeds, gcc-6.x is also likely
fine but I haven't started using those SDKs I just made today.

-- 
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] dm: allow setting driver_data before/during bind

2016-04-28 Thread Stephen Warren
From: Stephen Warren 

This will allow a driver's bind function to use the driver data. One
example is the Tegra186 GPIO driver, which instantiates child devices
for each of its GPIO ports, yet supports two different HW instances each
with a different set of ports, and identified by the udevice_id .data
field.

Signed-off-by: Stephen Warren 
---
 drivers/core/device.c| 7 ---
 drivers/core/lists.c | 6 +++---
 drivers/gpio/dwapb_gpio.c| 2 +-
 drivers/gpio/s5p_gpio.c  | 2 +-
 drivers/gpio/sunxi_gpio.c| 2 +-
 drivers/gpio/tegra_gpio.c| 2 +-
 drivers/mtd/spi/sandbox.c| 2 +-
 drivers/net/mvpp2.c  | 3 ++-
 drivers/pci/pci-uclass.c | 5 ++---
 drivers/power/pmic/pmic-uclass.c | 2 +-
 drivers/usb/host/usb-uclass.c| 5 ++---
 include/dm/device-internal.h | 5 +++--
 12 files changed, 22 insertions(+), 21 deletions(-)

diff --git a/drivers/core/device.c b/drivers/core/device.c
index 74688dc95075..dc66e2400de6 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -27,8 +27,8 @@
 DECLARE_GLOBAL_DATA_PTR;
 
 int device_bind(struct udevice *parent, const struct driver *drv,
-   const char *name, void *platdata, int of_offset,
-   struct udevice **devp)
+   const char *name, void *platdata, ulong driver_data,
+   int of_offset, struct udevice **devp)
 {
struct udevice *dev, *dev2;
struct uclass *uc;
@@ -56,6 +56,7 @@ int device_bind(struct udevice *parent, const struct driver 
*drv,
INIT_LIST_HEAD(>devres_head);
 #endif
dev->platdata = platdata;
+   dev->driver_data = driver_data;
dev->name = name;
dev->of_offset = of_offset;
dev->parent = parent;
@@ -227,7 +228,7 @@ int device_bind_by_name(struct udevice *parent, bool 
pre_reloc_only,
return -EPERM;
 
return device_bind(parent, drv, info->name, (void *)info->platdata,
-  -1, devp);
+  0, -1, devp);
 }
 
 static void *alloc_priv(int size, uint flags)
diff --git a/drivers/core/lists.c b/drivers/core/lists.c
index a72db13a119a..ac5a788e7e2b 100644
--- a/drivers/core/lists.c
+++ b/drivers/core/lists.c
@@ -89,7 +89,7 @@ int device_bind_driver_to_node(struct udevice *parent, const 
char *drv_name,
debug("Cannot find driver '%s'\n", drv_name);
return -ENOENT;
}
-   ret = device_bind(parent, drv, dev_name, NULL, node, devp);
+   ret = device_bind(parent, drv, dev_name, NULL, 0, node, devp);
if (ret) {
debug("Cannot create device named '%s' (err=%d)\n",
  dev_name, ret);
@@ -170,7 +170,8 @@ int lists_bind_fdt(struct udevice *parent, const void 
*blob, int offset,
}
 
dm_dbg("   - found match at '%s'\n", entry->name);
-   ret = device_bind(parent, entry, name, NULL, offset, );
+   ret = device_bind(parent, entry, name, NULL, id->data,
+ offset, );
if (ret == -ENODEV) {
dm_dbg("Driver '%s' refuses to bind\n", entry->name);
continue;
@@ -180,7 +181,6 @@ int lists_bind_fdt(struct udevice *parent, const void 
*blob, int offset,
ret);
return ret;
} else {
-   dev->driver_data = id->data;
found = true;
if (devp)
*devp = dev;
diff --git a/drivers/gpio/dwapb_gpio.c b/drivers/gpio/dwapb_gpio.c
index 72cec4880095..dcbf4c7b0877 100644
--- a/drivers/gpio/dwapb_gpio.c
+++ b/drivers/gpio/dwapb_gpio.c
@@ -137,7 +137,7 @@ static int gpio_dwapb_bind(struct udevice *dev)
goto err;
 
ret = device_bind(dev, dev->driver, plat->name,
- plat, -1, );
+ plat, 0, -1, );
if (ret)
goto err;
 
diff --git a/drivers/gpio/s5p_gpio.c b/drivers/gpio/s5p_gpio.c
index 0f22b238ba99..d4e1822c3646 100644
--- a/drivers/gpio/s5p_gpio.c
+++ b/drivers/gpio/s5p_gpio.c
@@ -344,7 +344,7 @@ static int gpio_exynos_bind(struct udevice *parent)
 
plat->bank_name = fdt_get_name(blob, node, NULL);
ret = device_bind(parent, parent->driver,
- plat->bank_name, plat, -1, );
+ plat->bank_name, plat, 0, -1, );
if (ret)
return ret;
 
diff --git a/drivers/gpio/sunxi_gpio.c b/drivers/gpio/sunxi_gpio.c
index a7cec18d57fb..715239dae38e 100644
--- a/drivers/gpio/sunxi_gpio.c
+++ b/drivers/gpio/sunxi_gpio.c
@@ -306,7 +306,7 @@ static int gpio_sunxi_bind(struct udevice *parent)
plat->gpio_count = SUNXI_GPIOS_PER_BANK;
 

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

2016-04-28 Thread Adam Ford
I am hoping to look at this tomorrow at work. Any suggested toolchain you
recommend?
On Apr 28, 2016 5:45 PM, "Tom Rini"  wrote:

> On Wed, Apr 27, 2016 at 06:46:36PM -0400, Tom Rini wrote:
>
> > While the OMAP3 has 64KiB of SRAM, per the TRM the download area is only
> > from 0x4020 to 0x4020F000 and exceeding that will cause failure to
> > boot.  Further, we need to make sure that we don't run into
> > SRAM_SCRATCH_SPACE_ADDR as once SPL is running we will write values
> > there and would corrupt our running image.
> >
> > Cc: Adam Ford 
> > Cc: Steve Sakoman 
> > Signed-off-by: Tom Rini 
>
> First, this will break linking SPL on some toolchains.  However, I am
> confident that in those cases the binary would not work or not be
> reliable.  I will be fixing this properly in the next release for all
> toolchains.  Applied to u-boot/master, thanks!
>
> --
> Tom
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


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

2016-04-28 Thread Marek Vasut
On 04/28/2016 03:04 PM, Diego wrote:
> In data mercoledì 27 aprile 2016 18:13:51, Marek Vasut ha scritto:
>>
>> OK, I have to two identical sticks and neither has the same USB ID as
>> yours. Can you do lsusb -vvv -d 0951:1689 ?
> 
> Hi Marek,
> 
> thanks for taking the time to look into this.
> Here you are:
> # lsusb -vvv -d 0951:1689
> 
> Bus 003 Device 020: ID 0951:1689 Kingston Technology DataTraveler SE9
> Device Descriptor:
>   bLength18
>   bDescriptorType 1
>   bcdUSB   2.00
>   bDeviceClass0 
>   bDeviceSubClass 0 
>   bDeviceProtocol 0 
>   bMaxPacketSize064
>   idVendor   0x0951 Kingston Technology
>   idProduct  0x1689 DataTraveler SE9
>   bcdDevice1.00
>   iManufacturer   1 Kingston
>   iProduct2 DataTraveler SE9
>   iSerial 3 0019E06B084BFD10470133E8
>   bNumConfigurations  1
>   Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength   32
> bNumInterfaces  1
> bConfigurationValue 1
> iConfiguration  0 
> bmAttributes 0x80
>   (Bus Powered)
> MaxPower  100mA
> Interface Descriptor:
>   bLength 9
>   bDescriptorType 4
>   bInterfaceNumber0
>   bAlternateSetting   0
>   bNumEndpoints   2
>   bInterfaceClass 8 Mass Storage
>   bInterfaceSubClass  6 SCSI
>   bInterfaceProtocol 80 Bulk-Only
>   iInterface  0 
>   Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x81  EP 1 IN
> bmAttributes2
>   Transfer TypeBulk
>   Synch Type   None
>   Usage Type   Data
> wMaxPacketSize 0x0200  1x 512 bytes
> bInterval 255
>   Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x02  EP 2 OUT
> bmAttributes2
>   Transfer TypeBulk
>   Synch Type   None
>   Usage Type   Data
> wMaxPacketSize 0x0200  1x 512 bytes
> bInterval 255
> Device Qualifier (for other device speed):
>   bLength10
>   bDescriptorType 6
>   bcdUSB   2.00
>   bDeviceClass0 
>   bDeviceSubClass 0 
>   bDeviceProtocol 0 
>   bMaxPacketSize064
>   bNumConfigurations  1
> can't get debug descriptor: Resource temporarily unavailable
> Device Status: 0x
>   (Bus Powered)

Urgh, so you seem to have third revision of this stick. I have two
sticks which are exactly the same and work in U-Boot on MX6 wandboard:

=> usb reset
resetting USB...
USB0:   Port not available.
USB1:   USB EHCI 1.00
scanning bus 1 for devices... 2 USB Device(s) found
   scanning usb for storage devices... 1 Storage Device(s) found
=> usb info
1: Hub,  USB Revision 2.0
 - u-boot EHCI Host Controller
 - Class: Hub
 - PacketSize: 64  Configurations: 1
 - Vendor: 0x  Product 0x Version 1.0
   Configuration: 1
   - Interfaces: 1 Self Powered 0mA
 Interface: 0
 - Alternate Setting 0, Endpoints: 1
 - Class Hub
 - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms

2: Mass Storage,  USB Revision 2.0
 - Kingston DataTraveler 2.0 C86000BDB6FFB0201A35968E
 - Class: (from Interface) Mass Storage
 - PacketSize: 64  Configurations: 1
 - Vendor: 0x0930  Product 0x6545 Version 1.16
   Configuration: 1
   - Interfaces: 1 Bus Powered 300mA
 Interface: 0
 - Alternate Setting 0, Endpoints: 2
 - Class Mass Storage, Transp. SCSI, Bulk only
 - Endpoint 1 In Bulk MaxPacket 512
 - Endpoint 2 Out Bulk MaxPacket 512

=> usb reset
resetting USB...
EHCI failed to shut down host controller.
USB0:   Port not available.
USB1:   USB EHCI 1.00
scanning bus 1 for devices... 2 USB Device(s) found
   scanning usb for storage devices... 1 Storage Device(s) found
=> usb info
1: Hub,  USB Revision 2.0
 - u-boot EHCI Host Controller
 - Class: Hub
 - PacketSize: 64  Configurations: 1
 - Vendor: 0x  Product 0x Version 1.0
   Configuration: 1
   - Interfaces: 1 Self Powered 0mA
 Interface: 0
 - Alternate Setting 0, Endpoints: 1
 - Class Hub
 - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms

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

[U-Boot] [PATCH 3/3] ARM: mx6: Enable MMC and SATA extfs boot support

2016-04-28 Thread Marek Vasut
Enable support for booting U-Boot image from ext filesystem when either
SD/MMC or SATA support is compiled into the SPL. This will allow easy
transition from loading U-Boot image from ad-hoc offset on the card to
loading U-Boot image from the filesystem. VFAT support is intently not
enabled. The boot order is tweaked so that raw is tested first and if
the raw has no signature, FS boot is attempted.

To install just the SPL on i.MX6 board, perform the following operation
 $ dd if=SPL of=/dev/sdX seek=2 bs=512
To install the U-Boot image, copy u-boot.img to the first partition of
the SD/MMC/SATA drive. The partition must be formated to extfs.

Signed-off-by: Marek Vasut 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Stefano Babic 
Cc: Tom Rini 
---
 include/configs/imx6_spl.h | 4 
 include/configs/novena.h   | 1 -
 include/configs/tqma6.h| 1 -
 3 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/include/configs/imx6_spl.h b/include/configs/imx6_spl.h
index 68d3fd7..9bd9f6e 100644
--- a/include/configs/imx6_spl.h
+++ b/include/configs/imx6_spl.h
@@ -48,12 +48,16 @@
 #define CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS 800 /* 400 KB */
 #define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION 1
 #define CONFIG_SYS_MONITOR_LEN  (CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS/2*1024)
+#define CONFIG_SPL_ABORT_ON_RAW_IMAGE
+#define CONFIG_SPL_EXT_SUPPORT
 #endif
 
 /* SATA support */
 #if defined(CONFIG_SPL_SATA_SUPPORT)
 #define CONFIG_SPL_SATA_BOOT_DEVICE0
 #define CONFIG_SYS_SATA_FAT_BOOT_PARTITION 1
+#define CONFIG_SPL_ABORT_ON_RAW_IMAGE
+#define CONFIG_SPL_EXT_SUPPORT
 #endif
 
 /* Define the payload for FAT/EXT support */
diff --git a/include/configs/novena.h b/include/configs/novena.h
index e938fbc..2382951 100644
--- a/include/configs/novena.h
+++ b/include/configs/novena.h
@@ -75,7 +75,6 @@
 
 /* SPL */
 #define CONFIG_SPL_FAT_SUPPORT
-#define CONFIG_SPL_EXT_SUPPORT
 #define CONFIG_SPL_MMC_SUPPORT
 #include "imx6_spl.h"  /* common IMX6 SPL configuration */
 
diff --git a/include/configs/tqma6.h b/include/configs/tqma6.h
index badb955..77ced71 100644
--- a/include/configs/tqma6.h
+++ b/include/configs/tqma6.h
@@ -16,7 +16,6 @@
 #define CONFIG_SPL_MMC_SUPPORT
 #define CONFIG_SPL_SPI_SUPPORT
 #define CONFIG_SPL_FAT_SUPPORT
-#define CONFIG_SPL_EXT_SUPPORT
 
 /* common IMX6 SPL configuration */
 #include "imx6_spl.h"
-- 
2.7.0

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


[U-Boot] [PATCH 2/3] SPL: Add CONFIG_SPL_ABORT_ON_RAW_IMAGE

2016-04-28 Thread Marek Vasut
When defined, SPL will proceed to another boot method
if the image it has loaded does not have a signature.
This is useful if the subsequent boot methods are much
more complex.

Signed-off-by: Marek Vasut 
Cc: Tom Rini 
Cc: Stefano Babic 
Cc: Peng Fan 
Cc: Fabio Estevam 
---
 README   | 4 
 common/spl/spl.c | 3 +++
 2 files changed, 7 insertions(+)

diff --git a/README b/README
index 88ff837..d881da2 100644
--- a/README
+++ b/README
@@ -3487,6 +3487,10 @@ FIT uImage format:
consider that a completely unreadable NAND block is bad,
and thus should be skipped silently.
 
+   CONFIG_SPL_ABORT_ON_RAW_IMAGE
+   When defined, SPL will proceed to another boot method
+   if the image it has loaded does not have a signature.
+
CONFIG_SPL_RELOC_STACK
Adress of the start of the stack SPL will use after
relocation.  If unspecified, this is equal to
diff --git a/common/spl/spl.c b/common/spl/spl.c
index 7259619..93f9bd1 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -111,6 +111,9 @@ int spl_parse_image_header(const struct image_header 
*header)
 * is bad, and thus should be skipped silently.
 */
panic("** no mkimage signature but raw image not supported");
+#elif defined(CONFIG_SPL_ABORT_ON_RAW_IMAGE)
+   /* Signature not found, proceed to other boot methods. */
+   return -EINVAL;
 #else
/* Signature not found - assume u-boot.bin */
debug("mkimage signature not found - ih_magic = %x\n",
-- 
2.7.0

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


Re: [U-Boot] Please pull u-boot-sunxi master

2016-04-28 Thread Tom Rini
On Thu, Apr 28, 2016 at 04:42:15PM +0200, Hans de Goede wrote:

> Hi Tom,
> 
> Here is a bug-fix sunxi pull-req for v2016.05 containing 2 bug-fixes.
> 
> The following changes since commit e25b369c048b51b1feb79587750e7e160fc0bd73:
> 
>   ARM64: zynqmp: Cleanup config file after CMD move (2016-04-26 10:16:10 
> -0400)
> 
> are available in the git repository at:
> 
>   http://git.denx.de/u-boot-sunxi.git master
> 
> for you to fetch changes up to ad14166426ab8ca40424ede741d27fdcfb4fc2c6:
> 
>   sunxi: Enable LDO3 at 3.3V on A13-OLinuXino board (2016-04-27 19:54:26 
> +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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


[U-Boot] [PATCH 1/3] SPL: Let spl_parse_image_header() return value

2016-04-28 Thread Marek Vasut
Allow the spl_parse_image_header() to return value. This is convenient
for controlling the SPL boot flow if the loaded image is corrupted.

Signed-off-by: Marek Vasut 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Stefano Babic 
Cc: Tom Rini 
---
 common/spl/spl.c   |  3 ++-
 common/spl/spl_ext.c   |  6 +-
 common/spl/spl_fat.c   |  4 +++-
 common/spl/spl_mmc.c   |  6 +-
 common/spl/spl_nand.c  |  9 +++--
 common/spl/spl_net.c   |  4 +---
 common/spl/spl_nor.c   |  9 +++--
 common/spl/spl_onenand.c   |  5 -
 common/spl/spl_ymodem.c|  7 +--
 drivers/mtd/spi/spi_spl_load.c | 10 --
 include/spl.h  |  2 +-
 11 files changed, 48 insertions(+), 17 deletions(-)

diff --git a/common/spl/spl.c b/common/spl/spl.c
index 82e7f58..7259619 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -73,7 +73,7 @@ void spl_set_header_raw_uboot(void)
spl_image.name = "U-Boot";
 }
 
-void spl_parse_image_header(const struct image_header *header)
+int spl_parse_image_header(const struct image_header *header)
 {
u32 header_size = sizeof(struct image_header);
 
@@ -118,6 +118,7 @@ void spl_parse_image_header(const struct image_header 
*header)
spl_set_header_raw_uboot();
 #endif
}
+   return 0;
 }
 
 __weak void __noreturn jump_to_image_no_args(struct spl_image_info *spl_image)
diff --git a/common/spl/spl_ext.c b/common/spl/spl_ext.c
index b77dbf4..ade5496 100644
--- a/common/spl/spl_ext.c
+++ b/common/spl/spl_ext.c
@@ -48,7 +48,11 @@ int spl_load_image_ext(struct blk_desc *block_dev,
goto end;
}
 
-   spl_parse_image_header(header);
+   err = spl_parse_image_header(header);
+   if (err < 0) {
+   puts("spl: ext4fs_read failed\n");
+   goto end;
+   }
 
err = ext4fs_read((char *)spl_image.load_addr, filelen, );
 
diff --git a/common/spl/spl_fat.c b/common/spl/spl_fat.c
index d761b26..338ea2f 100644
--- a/common/spl/spl_fat.c
+++ b/common/spl/spl_fat.c
@@ -57,7 +57,9 @@ int spl_load_image_fat(struct blk_desc *block_dev,
if (err <= 0)
goto end;
 
-   spl_parse_image_header(header);
+   err = spl_parse_image_header(header);
+   if (err <= 0)
+   goto end;
 
err = file_fat_read(filename, (u8 *)spl_image.load_addr, 0);
 
diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
index 8d588d1..360c754 100644
--- a/common/spl/spl_mmc.c
+++ b/common/spl/spl_mmc.c
@@ -23,8 +23,12 @@ static int mmc_load_legacy(struct mmc *mmc, ulong sector,
 {
u32 image_size_sectors;
unsigned long count;
+   int ret;
+
+   ret = spl_parse_image_header(header);
+   if (ret)
+   return ret;
 
-   spl_parse_image_header(header);
/* convert size to sectors - round up */
image_size_sectors = (spl_image.size + mmc->read_bl_len - 1) /
 mmc->read_bl_len;
diff --git a/common/spl/spl_nand.c b/common/spl/spl_nand.c
index 79388ff..bbd9546 100644
--- a/common/spl/spl_nand.c
+++ b/common/spl/spl_nand.c
@@ -32,7 +32,10 @@ static int spl_nand_load_element(int offset, struct 
image_header *header)
if (err)
return err;
 
-   spl_parse_image_header(header);
+   err = spl_parse_image_header(header);
+   if (err)
+   return err;
+
return nand_spl_load_image(offset, spl_image.size,
   (void *)(unsigned long)spl_image.load_addr);
 }
@@ -77,7 +80,9 @@ int spl_nand_load_image(void)
/* load linux */
nand_spl_load_image(CONFIG_SYS_NAND_SPL_KERNEL_OFFS,
sizeof(*header), (void *)header);
-   spl_parse_image_header(header);
+   err = spl_parse_image_header(header);
+   if (err)
+   return err;
if (header->ih_os == IH_OS_LINUX) {
/* happy - was a linux */
err = nand_spl_load_image(
diff --git a/common/spl/spl_net.c b/common/spl/spl_net.c
index 63b20d8..ae71d26 100644
--- a/common/spl/spl_net.c
+++ b/common/spl/spl_net.c
@@ -34,7 +34,5 @@ int spl_net_load_image(const char *device)
printf("Problem booting with BOOTP\n");
return rv;
}
-   spl_parse_image_header((struct image_header *)load_addr);
-
-   return 0;
+   return spl_parse_image_header((struct image_header *)load_addr);
 }
diff --git a/common/spl/spl_nor.c b/common/spl/spl_nor.c
index d0bd0b0..da2422f 100644
--- a/common/spl/spl_nor.c
+++ b/common/spl/spl_nor.c
@@ -9,6 +9,7 @@
 
 int spl_nor_load_image(void)
 {
+   int ret;
/*
 * Loading of the payload to SDRAM is done with skipping of
 * the mkimage header in this SPL NOR driver
@@ 

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

2016-04-28 Thread Tom Rini
On Wed, Apr 27, 2016 at 06:46:36PM -0400, Tom Rini wrote:

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

First, this will break linking SPL on some toolchains.  However, I am
confident that in those cases the binary would not work or not be
reliable.  I will be fixing this properly in the next release for all
toolchains.  Applied to u-boot/master, thanks!

-- 
Tom


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


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

2016-04-28 Thread Marek Vasut
On 04/28/2016 09:02 PM, Tom Rini wrote:
> On Thu, Apr 28, 2016 at 08:29:47PM +0200, Marek Vasut wrote:
>> On 04/28/2016 08:06 PM, Tom Rini wrote:
>>> On Thu, Apr 28, 2016 at 03:40:45PM +0200, Marek Vasut wrote:
 On 04/28/2016 03:36 PM, Stefano Babic wrote:
> Hi Marek,
>
> On 28/04/2016 13:03, Marek Vasut wrote:
>> On 04/28/2016 07:59 AM, Stefano Babic wrote:
>>> 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
>>
>> The feeling I get from the discussion you linked above and the
>> discussion here is that because user can be an idiot and delete
>> files at random, we should move back to the 80s 
>
> No U-Boot in the 80s.
>
>> and store files
>> like on the casette tapes, at random offset. User can also delete
>> kernel image and yet, we store it on the filesystem. Maybe we should
>> also store the kernel image at another raw offset ... and hey, maybe
>> we should ditch filesystem altogether, just tar everything up and
>> store it at yet another offset, since user might delete files at
>> random, just imaging he'd delete libc ...
>
> wandboard has a market quite similar to the Raspi and yes, there is a
> lot of inexperienced people using it.

 Shall I prepare a patch which places kernel to yet another ad-hoc
 location on the SD card then and tweak bootargs to use cramfs then?
>>>
>>> Users bricking their devices is a real problem.  I don't object to
>>> adding support for many ways of doing things (we have it on TI boards
>>> today) enabled, but saying there's no use case nor reason to do non-FS
>>> installs is also missing the mark.
>>
>> I am convinced this patch does not remove the "fallback to legacy
>> behavior" though.
> 
> Good.  Then you need to shove this up and over to the right common
> location since all of the offsets are, or better be (or we have a
> problem here..) the same for all imx6 and probably falling back a while
> too.  I know on TI parts the "magic" locations go back farther than
> U-Boot still supports.  And I know that might take a little time which
> is fine, this isn't a patch that needs to be in for v2016.05.
> 
Hm, grumble, the thing is falling apart the more I drill into it. There
will be a few more patches needed to deal with this raw legacy. Sigh ...

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


[U-Boot] [PATCH v6 4/4] arm: meson: implement calls to secure monitor

2016-04-28 Thread Beniamino Galvani
Implement calls to secure monitor to read the MAC address from e-fuse.

Signed-off-by: Beniamino Galvani 
---
 arch/arm/include/asm/arch-meson/sm.h   | 12 +++
 arch/arm/mach-meson/Makefile   |  2 +-
 arch/arm/mach-meson/board.c|  1 +
 arch/arm/mach-meson/sm.c   | 57 ++
 board/hardkernel/odroid-c2/odroid-c2.c | 16 ++
 5 files changed, 87 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/include/asm/arch-meson/sm.h
 create mode 100644 arch/arm/mach-meson/sm.c

diff --git a/arch/arm/include/asm/arch-meson/sm.h 
b/arch/arm/include/asm/arch-meson/sm.h
new file mode 100644
index 000..225438d
--- /dev/null
+++ b/arch/arm/include/asm/arch-meson/sm.h
@@ -0,0 +1,12 @@
+/*
+ * (C) Copyright 2016 - Beniamino Galvani 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __MESON_SM_H__
+#define __MESON_SM_H__
+
+ssize_t meson_sm_read_efuse(uintptr_t offset, void *buffer, size_t size);
+
+#endif /* __MESON_SM_H__ */
diff --git a/arch/arm/mach-meson/Makefile b/arch/arm/mach-meson/Makefile
index 44e3d63..bf49b8b 100644
--- a/arch/arm/mach-meson/Makefile
+++ b/arch/arm/mach-meson/Makefile
@@ -4,4 +4,4 @@
 # SPDX-License-Identifier: GPL-2.0+
 #
 
-obj-y += board.o
+obj-y += board.o sm.o
diff --git a/arch/arm/mach-meson/board.c b/arch/arm/mach-meson/board.c
index 782f86c..64fa3c1 100644
--- a/arch/arm/mach-meson/board.c
+++ b/arch/arm/mach-meson/board.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
diff --git a/arch/arm/mach-meson/sm.c b/arch/arm/mach-meson/sm.c
new file mode 100644
index 000..1b35a22
--- /dev/null
+++ b/arch/arm/mach-meson/sm.c
@@ -0,0 +1,57 @@
+/*
+ * (C) Copyright 2016 Beniamino Galvani 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ *
+ * Secure monitor calls.
+ */
+
+#include 
+#include 
+#include 
+
+#define FN_GET_SHARE_MEM_INPUT_BASE0x8220
+#define FN_GET_SHARE_MEM_OUTPUT_BASE   0x8221
+#define FN_EFUSE_READ  0x8230
+#define FN_EFUSE_WRITE 0x8231
+
+static void *shmem_input;
+static void *shmem_output;
+
+static void meson_init_shmem(void)
+{
+   struct pt_regs regs;
+
+   if (shmem_input && shmem_output)
+   return;
+
+   regs.regs[0] = FN_GET_SHARE_MEM_INPUT_BASE;
+   smc_call();
+   shmem_input = (void *)regs.regs[0];
+
+   regs.regs[0] = FN_GET_SHARE_MEM_OUTPUT_BASE;
+   smc_call();
+   shmem_output = (void *)regs.regs[0];
+
+   debug("Secure Monitor shmem: 0x%p 0x%p\n", shmem_input, shmem_output);
+}
+
+ssize_t meson_sm_read_efuse(uintptr_t offset, void *buffer, size_t size)
+{
+   struct pt_regs regs;
+
+   meson_init_shmem();
+
+   regs.regs[0] = FN_EFUSE_READ;
+   regs.regs[1] = offset;
+   regs.regs[2] = size;
+
+   smc_call();
+
+   if (regs.regs[0] == 0)
+   return -1;
+
+   memcpy(buffer, shmem_output, min(size, regs.regs[0]));
+
+   return regs.regs[0];
+}
diff --git a/board/hardkernel/odroid-c2/odroid-c2.c 
b/board/hardkernel/odroid-c2/odroid-c2.c
index c258d4f..bd72100 100644
--- a/board/hardkernel/odroid-c2/odroid-c2.c
+++ b/board/hardkernel/odroid-c2/odroid-c2.c
@@ -7,9 +7,15 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
+#define EFUSE_SN_OFFSET20
+#define EFUSE_SN_SIZE  16
+#define EFUSE_MAC_OFFSET   52
+#define EFUSE_MAC_SIZE 6
+
 int board_init(void)
 {
return 0;
@@ -27,6 +33,9 @@ U_BOOT_DEVICE(meson_eth) = {
 
 int misc_init_r(void)
 {
+   u8 mac_addr[EFUSE_MAC_SIZE];
+   ssize_t len;
+
/* Select Ethernet function */
setbits_le32(GXBB_PINMUX(6), 0x3fff);
 
@@ -47,5 +56,12 @@ int misc_init_r(void)
mdelay(10);
setbits_le32(GXBB_GPIO_OUT(3), BIT(14));
 
+   if (!eth_getenv_enetaddr("ethaddr", mac_addr)) {
+   len = meson_sm_read_efuse(EFUSE_MAC_OFFSET,
+ mac_addr, EFUSE_MAC_SIZE);
+   if (len == EFUSE_MAC_SIZE && is_valid_ethaddr(mac_addr))
+   eth_setenv_enetaddr("ethaddr", mac_addr);
+   }
+
return 0;
 }
-- 
2.7.3

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


[U-Boot] [PATCH v6 3/4] arm: add initial support for Amlogic Meson and ODROID-C2

2016-04-28 Thread Beniamino Galvani
This adds platform code for the Amlogic Meson GXBaby (S905) SoC and a
board definition for ODROID-C2. This initial submission only supports
UART and Ethernet (through the existing Designware driver). DTS files
are the ones submitted to Linux arm-soc for 4.7 [1].

[1] https://patchwork.ozlabs.org/patch/603583/

Signed-off-by: Beniamino Galvani 
---
 arch/arm/Kconfig   |   5 +
 arch/arm/Makefile  |   1 +
 arch/arm/dts/Makefile  |   2 +
 arch/arm/dts/meson-gxbb-odroidc2.dts   |  69 +
 arch/arm/dts/meson-gxbb.dtsi   | 178 +
 arch/arm/include/asm/arch-meson/gxbb.h |  52 ++
 arch/arm/mach-meson/Kconfig|  31 ++
 arch/arm/mach-meson/Makefile   |   7 ++
 arch/arm/mach-meson/board.c|  66 
 board/hardkernel/odroid-c2/Kconfig |  12 +++
 board/hardkernel/odroid-c2/MAINTAINERS |   6 ++
 board/hardkernel/odroid-c2/Makefile|   7 ++
 board/hardkernel/odroid-c2/README  |  60 +++
 board/hardkernel/odroid-c2/odroid-c2.c |  51 ++
 configs/odroid-c2_defconfig|  23 +
 drivers/serial/Kconfig |  15 +++
 drivers/serial/Makefile|   1 +
 drivers/serial/serial_meson.c  | 162 ++
 include/configs/odroid-c2.h|  51 ++
 19 files changed, 799 insertions(+)
 create mode 100644 arch/arm/dts/meson-gxbb-odroidc2.dts
 create mode 100644 arch/arm/dts/meson-gxbb.dtsi
 create mode 100644 arch/arm/include/asm/arch-meson/gxbb.h
 create mode 100644 arch/arm/mach-meson/Kconfig
 create mode 100644 arch/arm/mach-meson/Makefile
 create mode 100644 arch/arm/mach-meson/board.c
 create mode 100644 board/hardkernel/odroid-c2/Kconfig
 create mode 100644 board/hardkernel/odroid-c2/MAINTAINERS
 create mode 100644 board/hardkernel/odroid-c2/Makefile
 create mode 100644 board/hardkernel/odroid-c2/README
 create mode 100644 board/hardkernel/odroid-c2/odroid-c2.c
 create mode 100644 configs/odroid-c2_defconfig
 create mode 100644 drivers/serial/serial_meson.c
 create mode 100644 include/configs/odroid-c2.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 6b65d8e..6252f5a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -456,6 +456,9 @@ config ARCH_KEYSTONE
select SUPPORT_SPL
select CMD_POWEROFF
 
+config ARCH_MESON
+   bool "Amlogic Meson"
+
 config ARCH_MX7
bool "Freescale MX7"
select CPU_V7
@@ -781,6 +784,8 @@ source "arch/arm/mach-orion5x/Kconfig"
 
 source "arch/arm/cpu/armv7/rmobile/Kconfig"
 
+source "arch/arm/mach-meson/Kconfig"
+
 source "arch/arm/mach-rockchip/Kconfig"
 
 source "arch/arm/mach-s5pc1xx/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index d516345..ecd1887 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -50,6 +50,7 @@ machine-$(CONFIG_ARCH_HIGHBANK)   += highbank
 machine-$(CONFIG_ARCH_KEYSTONE)+= keystone
 # TODO: rename CONFIG_KIRKWOOD -> CONFIG_ARCH_KIRKWOOD
 machine-$(CONFIG_KIRKWOOD) += kirkwood
+machine-$(CONFIG_ARCH_MESON)   += meson
 machine-$(CONFIG_ARCH_MVEBU)   += mvebu
 # TODO: rename CONFIG_TEGRA -> CONFIG_ARCH_TEGRA
 # TODO: rename CONFIG_ORION5X -> CONFIG_ARCH_ORION5X
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index d1f8e22..136a7d8 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -26,6 +26,8 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rk3288-jerry.dtb \
rk3288-rock2-square.dtb \
rk3036-sdk.dtb
+dtb-$(CONFIG_ARCH_MESON) += \
+   meson-gxbb-odroidc2.dtb
 dtb-$(CONFIG_TEGRA) += tegra20-harmony.dtb \
tegra20-medcom-wide.dtb \
tegra20-paz00.dtb \
diff --git a/arch/arm/dts/meson-gxbb-odroidc2.dts 
b/arch/arm/dts/meson-gxbb-odroidc2.dts
new file mode 100644
index 000..653c2fa
--- /dev/null
+++ b/arch/arm/dts/meson-gxbb-odroidc2.dts
@@ -0,0 +1,69 @@
+/*
+ * Copyright (c) 2016 Andreas Färber
+ * Copyright (c) 2016 BayLibre, Inc.
+ * Author: Kevin Hilman 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ 

[U-Boot] [PATCH v6 2/4] net: designware: fix descriptor layout and warnings on 64-bit archs

2016-04-28 Thread Beniamino Galvani
All members of the DMA descriptor must be 32-bit, even on 64-bit
architectures: change the type to u32 to ensure this. Also, fix
other warnings.

Signed-off-by: Beniamino Galvani 
Acked-by: Joe Hershberger 
---
 drivers/net/designware.c | 59 ++--
 drivers/net/designware.h |  4 ++--
 2 files changed, 34 insertions(+), 29 deletions(-)

diff --git a/drivers/net/designware.c b/drivers/net/designware.c
index ca58f34..2eda461 100644
--- a/drivers/net/designware.c
+++ b/drivers/net/designware.c
@@ -98,8 +98,8 @@ static void tx_descs_init(struct dw_eth_dev *priv)
 
for (idx = 0; idx < CONFIG_TX_DESCR_NUM; idx++) {
desc_p = _table_p[idx];
-   desc_p->dmamac_addr = [idx * CONFIG_ETH_BUFSIZE];
-   desc_p->dmamac_next = _table_p[idx + 1];
+   desc_p->dmamac_addr = (ulong)[idx * CONFIG_ETH_BUFSIZE];
+   desc_p->dmamac_next = (ulong)_table_p[idx + 1];
 
 #if defined(CONFIG_DW_ALTDESCRIPTOR)
desc_p->txrx_status &= ~(DESC_TXSTS_TXINT | DESC_TXSTS_TXLAST |
@@ -117,11 +117,11 @@ static void tx_descs_init(struct dw_eth_dev *priv)
}
 
/* Correcting the last pointer of the chain */
-   desc_p->dmamac_next = _table_p[0];
+   desc_p->dmamac_next = (ulong)_table_p[0];
 
/* Flush all Tx buffer descriptors at once */
-   flush_dcache_range((unsigned int)priv->tx_mac_descrtable,
-  (unsigned int)priv->tx_mac_descrtable +
+   flush_dcache_range((ulong)priv->tx_mac_descrtable,
+  (ulong)priv->tx_mac_descrtable +
   sizeof(priv->tx_mac_descrtable));
 
writel((ulong)_table_p[0], _p->txdesclistaddr);
@@ -142,13 +142,12 @@ static void rx_descs_init(struct dw_eth_dev *priv)
 * Otherwise there's a chance to get some of them flushed in RAM when
 * GMAC is already pushing data to RAM via DMA. This way incoming from
 * GMAC data will be corrupted. */
-   flush_dcache_range((unsigned int)rxbuffs, (unsigned int)rxbuffs +
-  RX_TOTAL_BUFSIZE);
+   flush_dcache_range((ulong)rxbuffs, (ulong)rxbuffs + RX_TOTAL_BUFSIZE);
 
for (idx = 0; idx < CONFIG_RX_DESCR_NUM; idx++) {
desc_p = _table_p[idx];
-   desc_p->dmamac_addr = [idx * CONFIG_ETH_BUFSIZE];
-   desc_p->dmamac_next = _table_p[idx + 1];
+   desc_p->dmamac_addr = (ulong)[idx * CONFIG_ETH_BUFSIZE];
+   desc_p->dmamac_next = (ulong)_table_p[idx + 1];
 
desc_p->dmamac_cntl =
(MAC_MAX_FRAME_SZ & DESC_RXCTRL_SIZE1MASK) |
@@ -158,11 +157,11 @@ static void rx_descs_init(struct dw_eth_dev *priv)
}
 
/* Correcting the last pointer of the chain */
-   desc_p->dmamac_next = _table_p[0];
+   desc_p->dmamac_next = (ulong)_table_p[0];
 
/* Flush all Rx buffer descriptors at once */
-   flush_dcache_range((unsigned int)priv->rx_mac_descrtable,
-  (unsigned int)priv->rx_mac_descrtable +
+   flush_dcache_range((ulong)priv->rx_mac_descrtable,
+  (ulong)priv->rx_mac_descrtable +
   sizeof(priv->rx_mac_descrtable));
 
writel((ulong)_table_p[0], _p->rxdesclistaddr);
@@ -290,12 +289,11 @@ static int _dw_eth_send(struct dw_eth_dev *priv, void 
*packet, int length)
struct eth_dma_regs *dma_p = priv->dma_regs_p;
u32 desc_num = priv->tx_currdescnum;
struct dmamacdescr *desc_p = >tx_mac_descrtable[desc_num];
-   uint32_t desc_start = (uint32_t)desc_p;
-   uint32_t desc_end = desc_start +
+   ulong desc_start = (ulong)desc_p;
+   ulong desc_end = desc_start +
roundup(sizeof(*desc_p), ARCH_DMA_MINALIGN);
-   uint32_t data_start = (uint32_t)desc_p->dmamac_addr;
-   uint32_t data_end = data_start +
-   roundup(length, ARCH_DMA_MINALIGN);
+   ulong data_start = desc_p->dmamac_addr;
+   ulong data_end = data_start + roundup(length, ARCH_DMA_MINALIGN);
/*
 * Strictly we only need to invalidate the "txrx_status" field
 * for the following check, but on some platforms we cannot
@@ -312,7 +310,7 @@ static int _dw_eth_send(struct dw_eth_dev *priv, void 
*packet, int length)
return -EPERM;
}
 
-   memcpy(desc_p->dmamac_addr, packet, length);
+   memcpy((void *)data_start, packet, length);
 
/* Flush data to be sent */
flush_dcache_range(data_start, data_end);
@@ -352,11 +350,11 @@ static int _dw_eth_recv(struct dw_eth_dev *priv, uchar 
**packetp)
u32 status, desc_num = priv->rx_currdescnum;
struct dmamacdescr *desc_p = >rx_mac_descrtable[desc_num];
int length = -EAGAIN;
-   uint32_t desc_start = (uint32_t)desc_p;
-   uint32_t desc_end = desc_start +
+   ulong desc_start 

[U-Boot] [PATCH v6 1/4] arm: implement generic PSCI reset call for armv8

2016-04-28 Thread Beniamino Galvani
Add a psci_system_reset() which calls the SYSTEM_RESET function of
PSCI 0.2 and can be used by boards that support it to implement
reset_cpu().

Signed-off-by: Beniamino Galvani 
---
 arch/arm/cpu/armv8/fwcall.c   | 16 
 arch/arm/include/asm/psci.h   | 17 -
 arch/arm/include/asm/system.h |  2 ++
 3 files changed, 34 insertions(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv8/fwcall.c b/arch/arm/cpu/armv8/fwcall.c
index 9efcc5a..079e250 100644
--- a/arch/arm/cpu/armv8/fwcall.c
+++ b/arch/arm/cpu/armv8/fwcall.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /*
@@ -73,3 +74,18 @@ void smc_call(struct pt_regs *args)
  "x8", "x9", "x10", "x11", "x12", "x13", "x14", "x15",
  "x16", "x17");
 }
+
+void __noreturn psci_system_reset(bool conduit_smc)
+{
+   struct pt_regs regs;
+
+   regs.regs[0] = ARM_PSCI_0_2_FN_SYSTEM_RESET;
+
+   if (conduit_smc)
+   smc_call();
+   else
+   hvc_call();
+
+   while (1)
+   ;
+}
diff --git a/arch/arm/include/asm/psci.h b/arch/arm/include/asm/psci.h
index 128a606..3704f07 100644
--- a/arch/arm/include/asm/psci.h
+++ b/arch/arm/include/asm/psci.h
@@ -18,7 +18,7 @@
 #ifndef __ARM_PSCI_H__
 #define __ARM_PSCI_H__
 
-/* PSCI interface */
+/* PSCI 0.1 interface */
 #define ARM_PSCI_FN_BASE   0x95c1ba5e
 #define ARM_PSCI_FN(n) (ARM_PSCI_FN_BASE + (n))
 
@@ -32,6 +32,21 @@
 #define ARM_PSCI_RET_INVAL (-2)
 #define ARM_PSCI_RET_DENIED(-3)
 
+/* PSCI 0.2 interface */
+#define ARM_PSCI_0_2_FN_BASE   0x8400
+#define ARM_PSCI_0_2_FN(n) (ARM_PSCI_0_2_FN_BASE + (n))
+
+#define ARM_PSCI_0_2_FN_PSCI_VERSION   ARM_PSCI_0_2_FN(0)
+#define ARM_PSCI_0_2_FN_CPU_SUSPENDARM_PSCI_0_2_FN(1)
+#define ARM_PSCI_0_2_FN_CPU_OFFARM_PSCI_0_2_FN(2)
+#define ARM_PSCI_0_2_FN_CPU_ON ARM_PSCI_0_2_FN(3)
+#define ARM_PSCI_0_2_FN_AFFINITY_INFO  ARM_PSCI_0_2_FN(4)
+#define ARM_PSCI_0_2_FN_MIGRATEARM_PSCI_0_2_FN(5)
+#define ARM_PSCI_0_2_FN_MIGRATE_INFO_TYPE  ARM_PSCI_0_2_FN(6)
+#define ARM_PSCI_0_2_FN_MIGRATE_INFO_UP_CPUARM_PSCI_0_2_FN(7)
+#define ARM_PSCI_0_2_FN_SYSTEM_OFF ARM_PSCI_0_2_FN(8)
+#define ARM_PSCI_0_2_FN_SYSTEM_RESET   ARM_PSCI_0_2_FN(9)
+
 #ifndef __ASSEMBLY__
 int psci_update_dt(void *fdt);
 void psci_board_init(void);
diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
index 9ae890a..2bdc0be 100644
--- a/arch/arm/include/asm/system.h
+++ b/arch/arm/include/asm/system.h
@@ -128,6 +128,8 @@ void hvc_call(struct pt_regs *args);
  */
 void smc_call(struct pt_regs *args);
 
+void __noreturn psci_system_reset(bool smc);
+
 #endif /* __ASSEMBLY__ */
 
 #else /* CONFIG_ARM64 */
-- 
2.7.3

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


[U-Boot] [PATCH v6 0/4] Amlogic Meson GXBaby and ODROID-C2 support

2016-04-28 Thread Beniamino Galvani
Hi,

this series adds a very basic support for Amlogic S905 SoC (GXBaby)
and for the ODROID-C2 board [1], and is based on u-boot sources
available from the board vendor [2]. At the moment the only supported
devices are the integrated UART and Ethernet adapter.

Changes since v5:
 - used default CONFIG_SYS_BAUDRATE_TABLE
 - removed check for CONFIG_IDENT_STRING already set

Changes since v4:
 - added patch to implement generic PSCI reset
 - used min() macro from linux/kernel.h

Changes since v3:
 - designware eth: added check that buffer addresses are in first 4GiB
   as suggested by Marek (and thus removed the ack tags)
 - consolidated pinmux and gpio macros
 - used get_unaligned_be64() to avoid alignment faults in dram_init()
 - uint32_t -> u32 in serial_meson.c
 - implemented reboot and read from e-fuse through secure monitor

Changes since v2:
 - squashed all platform patches into a single one
 - got rid of additional non-upstream DTS node for ethernet
 - improved board README
 - added macros for SoC registers fields

Changes since v1:
 - updated DTS files from Linux kernel
 - added Ethernet support
 - first 16MiB of RAM are now marked as unavailable; this seems to
   be required to successfully boot Linux
 - fixed typo in config file

[1] http://www.hardkernel.com/main/products/prdt_info.php?g_code=G145457216438
[2] https://github.com/hardkernel/u-boot/tree/odroidc2-v2015.01

Beniamino Galvani (4):
  arm: implement generic PSCI reset call for armv8
  net: designware: fix descriptor layout and warnings on 64-bit archs
  arm: add initial support for Amlogic Meson and ODROID-C2
  arm: meson: implement calls to secure monitor

 arch/arm/Kconfig   |   5 +
 arch/arm/Makefile  |   1 +
 arch/arm/cpu/armv8/fwcall.c|  16 +++
 arch/arm/dts/Makefile  |   2 +
 arch/arm/dts/meson-gxbb-odroidc2.dts   |  69 +
 arch/arm/dts/meson-gxbb.dtsi   | 178 +
 arch/arm/include/asm/arch-meson/gxbb.h |  52 ++
 arch/arm/include/asm/arch-meson/sm.h   |  12 +++
 arch/arm/include/asm/psci.h|  17 +++-
 arch/arm/include/asm/system.h  |   2 +
 arch/arm/mach-meson/Kconfig|  31 ++
 arch/arm/mach-meson/Makefile   |   7 ++
 arch/arm/mach-meson/board.c|  67 +
 arch/arm/mach-meson/sm.c   |  57 +++
 board/hardkernel/odroid-c2/Kconfig |  12 +++
 board/hardkernel/odroid-c2/MAINTAINERS |   6 ++
 board/hardkernel/odroid-c2/Makefile|   7 ++
 board/hardkernel/odroid-c2/README  |  60 +++
 board/hardkernel/odroid-c2/odroid-c2.c |  67 +
 configs/odroid-c2_defconfig|  23 +
 drivers/net/designware.c   |  59 ++-
 drivers/net/designware.h   |   4 +-
 drivers/serial/Kconfig |  15 +++
 drivers/serial/Makefile|   1 +
 drivers/serial/serial_meson.c  | 162 ++
 include/configs/odroid-c2.h|  51 ++
 26 files changed, 953 insertions(+), 30 deletions(-)
 create mode 100644 arch/arm/dts/meson-gxbb-odroidc2.dts
 create mode 100644 arch/arm/dts/meson-gxbb.dtsi
 create mode 100644 arch/arm/include/asm/arch-meson/gxbb.h
 create mode 100644 arch/arm/include/asm/arch-meson/sm.h
 create mode 100644 arch/arm/mach-meson/Kconfig
 create mode 100644 arch/arm/mach-meson/Makefile
 create mode 100644 arch/arm/mach-meson/board.c
 create mode 100644 arch/arm/mach-meson/sm.c
 create mode 100644 board/hardkernel/odroid-c2/Kconfig
 create mode 100644 board/hardkernel/odroid-c2/MAINTAINERS
 create mode 100644 board/hardkernel/odroid-c2/Makefile
 create mode 100644 board/hardkernel/odroid-c2/README
 create mode 100644 board/hardkernel/odroid-c2/odroid-c2.c
 create mode 100644 configs/odroid-c2_defconfig
 create mode 100644 drivers/serial/serial_meson.c
 create mode 100644 include/configs/odroid-c2.h

-- 
2.7.3

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


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

2016-04-28 Thread Stephen Warren
From: Stephen Warren 

Use the device's own DT offset, not the device's parent's.

Fixes: 43c4d44e3330 ("fdt: implement dev_get_addr_name()")
Signed-off-by: Stephen Warren 
---
 drivers/core/device.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/core/device.c b/drivers/core/device.c
index e7d4fa5d3f19..c6198da17b10 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -679,8 +679,8 @@ fdt_addr_t dev_get_addr_name(struct udevice *dev, const 
char *name)
 #if CONFIG_IS_ENABLED(OF_CONTROL)
int index;
 
-   index = fdt_find_string(gd->fdt_blob, dev->parent->of_offset,
-   "reg-names", name);
+   index = fdt_find_string(gd->fdt_blob, dev->of_offset, "reg-names",
+   name);
if (index < 0)
return index;
 
-- 
2.8.1

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


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

2016-04-28 Thread Tom Rini
On Thu, Apr 28, 2016 at 08:41:38PM +0200, Marwa Hamza wrote:
> -- Forwarded message --
> From: Tom Rini 
> Date: 2016-04-28 20:08 GMT+02:00
> Subject: Re: [U-Boot] change the relocate address of u-boot
> To: Marwa Hamza 
> Cc: u-boot@lists.denx.de
> 
> 
> On Thu, Apr 28, 2016 at 02:47:21PM +0100, Marwa Hamza wrote:
> 
> > hey
> > i 'm trying to start a whole system on qemu (kernel ,
> > bootloader,filesystem) and i need to change the relocate address , so i'm
> > wondering if there is a patch to change this address 0x1000
> 
> You need to provide a lot more details as without any changes today
> U-Boot is able to run in qemu for a number of boards that qemu supports
> today.  In fact, I need to get around to converting some kernelci.org
> rootfs tarballs into images to pass along and use...
> 
> --
> Tom
> well qemu doesn't need a bootloader to emulate a linux kernel , it needs
> only zImage and rootfs file system
> qemu-system-arm -M versatilepb -kernel zImage -initrd rootfs.img.gz
> I played with QEMU emulation of an ARM Versatile Platform Board
> ,
> making it run bare metal programs
> ,
> the U-Boot
>  boot-loader
> and a Linux kernel
> 
> complete
> with a Busybox-based file system
> . I
> tried to put everything together to emulate a complete boot procedure, but
> it was not so simple
> as we on execution the code copies itself into another address, which by
> default is 0x100 (16MiB). This feature comes handy in this scenario
> because it frees lower memory space in order to copy the Linux kernel. The
> compressed kernel image size is about 1.5MiB, so the first 1.5MiB from the
> start address must be free and usable when U-Boot copies the kernel
> that works perfectly when the kernel 's size is small but when i use a
> kernel 's size over 4MiB that wouldn't work that 's why changing the
> relocate address will free more space

So what you need to do is something like:
qemu-system-arm -M vexpress-a9 -kernel vexpress_ca9x4/u-boot  -nographic -m 1G
to boot qemu and the Versatile A9.  And then you also need to pass in
some more options to qemu-system-arm to give it a disk image that
contains a kernel and root filesystem image and then boot that like a
normal system would.

-- 
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] register polling from HUSH parser?

2016-04-28 Thread Wolfgang Denk
Dear Masahiro,

In message  
you wrote:
> 
> Yes, it really helped me.
> Thank you!

You are welcome.

> I think itest.l works as expected on 32bit architecture,
> but the problem is that sizeof(unsigned long) is 8
> on 64bit architecture.

Oh, yes, you are right, of course. Well, U-Boot has been too long
written for 32 bit only...

> So, "case 4" in the following gets 8-byte data.
> This is probably not what we expect...
> 
>   switch (w) {
>   case 1:
>  l = (long)(*(unsigned char *)buf);
>  break;
>   case 2:
>  l = (long)(*(unsigned short *)buf);
>  break;
>   case 4:
>  l = (long)(*(unsigned long *)buf);
>  break;
>   }

You are right.  We should replace char/short/long by something more
descriptive like u8/u16/u32 - and for 64 bit systems, we should a
branch for 64 bit entities, too.

Do you think you can prepare such a patch?

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
Machines take me by surprise with great frequency.  - Alan Turing
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


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

2016-04-28 Thread Tom Rini
On Thu, Apr 28, 2016 at 03:12:19PM +0200, Michal Simek wrote:
> On 28.4.2016 15:07, Tom Rini wrote:
> > On Thu, Apr 28, 2016 at 11:44:50AM +0200, Michal Simek wrote:
> >> Hi Simon and Tom,
> >>
> >> On 23.2.2016 06:55, Simon Glass wrote:
> >>> Enable SPL FIT support for the Linksprite pcDuino3 as an example of how 
> >>> this
> >>> feature is used.
> >>>
> >>> This is only for demonstration purposes and is not to be applied.
> >>> Signed-off-by: Simon Glass 
> >>> ---
> >>>
> >>> Changes in v2: None
> >>>
> >>>  arch/arm/cpu/armv7/sunxi/board.c  | 5 +
> >>>  configs/Linksprite_pcDuino3_defconfig | 4 
> >>>  2 files changed, 9 insertions(+)
> >>
> >> I have played with SPL_FIT support and find some things
> >> First of all
> >> "mkimage: Support placing data outside the FIT"
> >> (722ebc8f84d5bccd2e70fad1079a0dd40cceddec)
> >> is missing description in usage function to see what -E options does.
> >>
> >> Then I have found a problem with fit address calculation because it has
> >> to be aligned.
> >> I have sent an RFC for it
> >> "SPL: FIT: Align loading address for header"
> >>
> >> I have also added support for ram load for FIT - please review.
> >> "SPL: FIT: Enable SPL_FIT_LOAD in RAM based boot mode"
> > 
> > I think these are reasonable.
> > 
> >> And also for SD fat based images.
> >> "SPL: FIT: Enable SPL_FIT_LOAD for sd bootmode for fat partions"
> > 
> > Ug, sorry.  You missed the series from Lokesh that added a bunch more
> > features along those lines.  I didn't pull them in since it was past the
> > merge window but will for the next release.
> 
> Ah ok. Will look.
> 
> > 
> >> Is there any plan to support falcon mode?
> >> Also I see kind of interesting to have one fit image with ATF, Secure
> >> OS, bitstreams and U-Boot and Linux kernel + dtbs
> >> Currently spl_load_simple_fit() seems to me expecting to blindly read
> >> the first fit partition and say this is u-boot and then based
> >> configuration description choose dtb.
> >>
> >> Do you have any plan to get even u-boot image from configurations instead?
> >> The we should get a support for loadables.
> > 
> > Well, the first itch I needed scratched was supporting many similar
> > platforms in DM+DT from a single binary, and that's what's there today.
> > So long as we can do things in a clean way, all of these other use cases
> > sound interesting and clearly useful to some people, so I don't object.
> 
> 
> How do you identify platform you are running at?

In these cases we know there is an I2C EEPROM with information in a
given format so we can go from there.

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

2016-04-28 Thread Tom Rini
On Thu, Apr 28, 2016 at 08:29:47PM +0200, Marek Vasut wrote:
> On 04/28/2016 08:06 PM, Tom Rini wrote:
> > On Thu, Apr 28, 2016 at 03:40:45PM +0200, Marek Vasut wrote:
> >> On 04/28/2016 03:36 PM, Stefano Babic wrote:
> >>> Hi Marek,
> >>>
> >>> On 28/04/2016 13:03, Marek Vasut wrote:
>  On 04/28/2016 07:59 AM, Stefano Babic wrote:
> > 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
> 
>  The feeling I get from the discussion you linked above and the
>  discussion here is that because user can be an idiot and delete
>  files at random, we should move back to the 80s 
> >>>
> >>> No U-Boot in the 80s.
> >>>
>  and store files
>  like on the casette tapes, at random offset. User can also delete
>  kernel image and yet, we store it on the filesystem. Maybe we should
>  also store the kernel image at another raw offset ... and hey, maybe
>  we should ditch filesystem altogether, just tar everything up and
>  store it at yet another offset, since user might delete files at
>  random, just imaging he'd delete libc ...
> >>>
> >>> wandboard has a market quite similar to the Raspi and yes, there is a
> >>> lot of inexperienced people using it.
> >>
> >> Shall I prepare a patch which places kernel to yet another ad-hoc
> >> location on the SD card then and tweak bootargs to use cramfs then?
> > 
> > Users bricking their devices is a real problem.  I don't object to
> > adding support for many ways of doing things (we have it on TI boards
> > today) enabled, but saying there's no use case nor reason to do non-FS
> > installs is also missing the mark.
> 
> I am convinced this patch does not remove the "fallback to legacy
> behavior" though.

Good.  Then you need to shove this up and over to the right common
location since all of the offsets are, or better be (or we have a
problem here..) the same for all imx6 and probably falling back a while
too.  I know on TI parts the "magic" locations go back farther than
U-Boot still supports.  And I know that might take a little time which
is fine, this isn't a patch that needs to be in for v2016.05.

-- 
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: fix ifdefs in ARMv8 lowlevel_init()

2016-04-28 Thread Stephen Warren
From: Stephen Warren 

Commit 724219a65f55 "ARM: always perform per-CPU GIC init" removed some
ifdefs to unify the MULTIENTRY-vs-non-MULTIENTRY paths. However, the
wrong endif was removed. This patch adds back that missing endif, and
adds a new ifdef to match the endif the now-correctly-terminated block
used to match against. Use "git show -U25 724219a65f55" to see enough
context to make the original issue clear.

In practical terms, this makes no difference to runtime behaviour. The
code that was incorrectly compiled into the binary when ifndef MULTIENTRY
is a no-op for other cases, since branch_if_master evaluates to a hard-
coded jump. The only issues were:

- A few extra instructions were added to the binary.
- The comment on the endif at the very end of the function, indicating
which ifdef it matched, were wrong.

An alternative might be to simply fix the comment on that trailing ifdef,
but that only addresses the second point above, not the first.

Fixes: 724219a65f55 ("ARM: always perform per-CPU GIC init")
Cc: Masahiro Yamada 
Signed-off-by: Stephen Warren 
---
 arch/arm/cpu/armv8/start.S | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
index deb44a895fda..c3cc8199caf9 100644
--- a/arch/arm/cpu/armv8/start.S
+++ b/arch/arm/cpu/armv8/start.S
@@ -214,7 +214,9 @@ WEAK(lowlevel_init)
ldr x1, =GICC_BASE
bl  gic_init_secure_percpu
 #endif
+#endif
 
+#ifndef CONFIG_ARMV8_MULTIENTRY
branch_if_master x0, x1, 2f
 
/*
-- 
2.8.1

___
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

2016-04-28 Thread Marek Vasut
On 04/28/2016 08:06 PM, Tom Rini wrote:
> On Thu, Apr 28, 2016 at 03:40:45PM +0200, Marek Vasut wrote:
>> On 04/28/2016 03:36 PM, Stefano Babic wrote:
>>> Hi Marek,
>>>
>>> On 28/04/2016 13:03, Marek Vasut wrote:
 On 04/28/2016 07:59 AM, Stefano Babic wrote:
> 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

 The feeling I get from the discussion you linked above and the
 discussion here is that because user can be an idiot and delete
 files at random, we should move back to the 80s 
>>>
>>> No U-Boot in the 80s.
>>>
 and store files
 like on the casette tapes, at random offset. User can also delete
 kernel image and yet, we store it on the filesystem. Maybe we should
 also store the kernel image at another raw offset ... and hey, maybe
 we should ditch filesystem altogether, just tar everything up and
 store it at yet another offset, since user might delete files at
 random, just imaging he'd delete libc ...
>>>
>>> wandboard has a market quite similar to the Raspi and yes, there is a
>>> lot of inexperienced people using it.
>>
>> Shall I prepare a patch which places kernel to yet another ad-hoc
>> location on the SD card then and tweak bootargs to use cramfs then?
> 
> Users bricking their devices is a real problem.  I don't object to
> adding support for many ways of doing things (we have it on TI boards
> today) enabled, but saying there's no use case nor reason to do non-FS
> installs is also missing the mark.
> 
I am convinced this patch does not remove the "fallback to legacy
behavior" though.

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


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

2016-04-28 Thread Tom Rini
On Thu, Apr 28, 2016 at 02:47:21PM +0100, Marwa Hamza wrote:

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

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

-- 
Tom


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

2016-04-28 Thread Tom Rini
On Thu, Apr 28, 2016 at 03:40:45PM +0200, Marek Vasut wrote:
> On 04/28/2016 03:36 PM, Stefano Babic wrote:
> > Hi Marek,
> > 
> > On 28/04/2016 13:03, Marek Vasut wrote:
> >> On 04/28/2016 07:59 AM, Stefano Babic wrote:
> >>> 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
> >>
> >> The feeling I get from the discussion you linked above and the
> >> discussion here is that because user can be an idiot and delete
> >> files at random, we should move back to the 80s 
> > 
> > No U-Boot in the 80s.
> > 
> >> and store files
> >> like on the casette tapes, at random offset. User can also delete
> >> kernel image and yet, we store it on the filesystem. Maybe we should
> >> also store the kernel image at another raw offset ... and hey, maybe
> >> we should ditch filesystem altogether, just tar everything up and
> >> store it at yet another offset, since user might delete files at
> >> random, just imaging he'd delete libc ...
> > 
> > wandboard has a market quite similar to the Raspi and yes, there is a
> > lot of inexperienced people using it.
> 
> Shall I prepare a patch which places kernel to yet another ad-hoc
> location on the SD card then and tweak bootargs to use cramfs then?

Users bricking their devices is a real problem.  I don't object to
adding support for many ways of doing things (we have it on TI boards
today) enabled, but saying there's no use case nor reason to do non-FS
installs is also missing the mark.

-- 
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] [RFC PATCH] zynq: add support for on-board shared reset gpio

2016-04-28 Thread Andrea Merello
I'm adding support [1] for another zynq-based board (MYIR Zturn [2]).

This board has one peculiarity that I have to deal with: it has a shared reset
signal that hits both the USB PHY and the Ethernet PHY, and this is routed to
a GPIO that must be shaken down and up before using those two pheripherals
(especially USB) in order to make things working.

This must be done before the two ethernet and USB drivers probes, so I couldn't
delegate this to any of the twos..

Right now I added a top-level node "board" to my DT containing the GPIO property
and I handle this in the board initialization code.

board {
phys-reset-gpio = < 51 GPIO_ACTIVE_LOW>;
};

RFC: is this a good/clean way to handle this thing? Ideally I would like to
put this mechanism out of the Zynq-specific board file, so that it could be
available for any kind of board..

(once a clean way to handle this thing have been agreed I'll rebase and I'll
post a patch serie for adding support for that board).

[1] https://github.com/andreamerello/u-boot-zynq
[2] http://www.myirtech.com/list.asp?id=502

Signed-off-by: Andrea Merello 

diff --git a/board/xilinx/zynq/board.c b/board/xilinx/zynq/board.c
index 183f642..f72b219 100644
--- a/board/xilinx/zynq/board.c
+++ b/board/xilinx/zynq/board.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -70,8 +71,43 @@ int board_init(void)
return 0;
 }
 
+int phys_reset(void)
+{
+   struct gpio_desc reset_gpio;
+   int nodeoffset;
+   const void *blob = gd->fdt_blob;
+
+   nodeoffset = fdt_path_offset(blob, "/board");
+   if (nodeoffset == -FDT_ERR_NOTFOUND)
+   return 0;
+   if (nodeoffset < 0)
+   return nodeoffset;
+
+   gpio_request_by_name_nodev(blob, nodeoffset, "phys-reset-gpio", 0,
+  _gpio, 0);
+
+   if (dm_gpio_is_valid(_gpio)) {
+   /* reset PHYs (ethernet and USB) before any driver comes up */
+   dm_gpio_set_dir_flags(_gpio, reset_gpio.flags |
+   GPIOD_IS_OUT | GPIOD_IS_OUT_ACTIVE);
+
+   mdelay(100);
+   dm_gpio_set_dir_flags(_gpio, (reset_gpio.flags |
+   GPIOD_IS_OUT) & ~GPIOD_IS_OUT_ACTIVE);
+
+   /* wait for PHYs to come up before going on */
+   mdelay(100);
+
+   printf("PHYs reset OK\n");
+   }
+
+   return 0;
+}
+
 int board_late_init(void)
 {
+   phys_reset();
+
switch ((zynq_slcr_get_boot_mode()) & ZYNQ_BM_MASK) {
case ZYNQ_BM_NOR:
setenv("modeboot", "norboot");
-- 
2.1.4

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


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

2016-04-28 Thread Marwa Hamza
hey
i 'm trying to start a whole system on qemu (kernel ,
bootloader,filesystem) and i need to change the relocate address , so i'm
wondering if there is a patch to change this address 0x1000
regards
marwa
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


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

2016-04-28 Thread Simon Glass
On 28 April 2016 at 01:08, Michal Simek  wrote:
>
> 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.
>
> Signed-off-by: Michal Simek 
> ---
>
> Changes in v2:
> - Refactor based on Masahiro comments
>
>  scripts/Makefile.spl | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)


Reviewed-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] dm: ensure device names are unique

2016-04-28 Thread Stephen Warren

On 04/27/2016 10:42 PM, Joe Hershberger wrote:

On Tue, Apr 26, 2016 at 4:30 PM, Stephen Warren  wrote:

From: Stephen Warren 

It is possible for HW to contain multiple instances of the same device. In
this case, the name passed to device_bind() may not be unique across all
devices within its uclass. One example is a system with multiple identical
PCI Ethernet devices. Another might be a system with multiple identical
I2C GPIO expanders, each connected to a separate I2C bus, yet using the
same I2C address on that bus and hence having the same DT node name.

Enhance the code to detect this situation, and append a sequence number so
the device name to ensure uniqueness.

Signed-off-by: Stephen Warren 
---
Some possible issues with this patch:

1) Doing this in bind() rather than probe() means dev->seq isn't
available, so can't be used to generate the unique name. This process
should be done during bind() rather than probe() though, since devices can
be seen (e.g. by running "dm tree") before they're probed. Perhaps the
uclass_resolve_seq() should be called by bind() not probe().


We (Simon and I) had discussion about this when I first added support
for eth devices. He convinced me the correct time for seq to be
evaluated is at probe time. I can dig through the mail history for
reasons if you're interested.


That might be interesting. Right now, about the only thing I see moving 
the evaluation from probe to bind would do is very marginally increase 
the amount of work done in bind, which potentially might be skipped if a 
particular Ethernet device was never probed. I would not expect this to 
make a noticeable difference, especially since IIRC when the network is 
first used, all the Ethernet devices are probed anyway, so this just 
moves work around?



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


Maybe we could add a parameter to provide the pointer and if it's
NULL, then it gets looked up. Might be a bit noisy change, though. Is
that optimization very valuable?


I don't imagine there are too many uclasses, so it's probably not going 
to save too much time. Still, Simon has in the past objected to code 
that parses DT scanning the DT to find parent offsets, and this feels 
like exactly the same kind of thing. I'm not personally concerned about 
it; simply pointing it out in case anyone wanted that to be addressed.



3) Iterating over the list to find the count of devices in the uclass is a
bit annoying. Should the uclass maintain this count so it doesn't need to
be re-calculated each time?


These lists aren't long, right? It seems like the optimization to
store the value is only helpful if the lists could be expected to be
long, or the size is looked up many times.


Yes, I don't imagine this would be a particular issue in practice.
___
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

2016-04-28 Thread Stephen Warren

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

Hi Stephen,

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

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


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


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

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


[U-Boot] Please pull: u-boot-video/master

2016-04-28 Thread Anatolij Gustschin
Hi Tom,

recent change to the am335x-fb driver caused a bug, these to patches
fix it now. We got Tested-by tags for them, so it should be okay
to merge these fixes for the release. Please pull. Thanks!

Anatolij

The following changes since commit e25b369c048b51b1feb79587750e7e160fc0bd73:

  ARM64: zynqmp: Cleanup config file after CMD move (2016-04-26 10:16:10 -0400)

are available in the git repository at:

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

for you to fetch changes up to 3d47b2d741683023de05f08f9adb4bd25c189c46:

  drivers/video/am335x-fb: Properly point framebuffer behind palette 
(2016-04-28 16:51:17 +0200)


Martin Pietryka (2):
  drivers/video/am335x-fb: Add support for 16bpp format
  drivers/video/am335x-fb: Properly point framebuffer behind palette

 drivers/video/am335x-fb.c |   30 +++---
 1 file changed, 23 insertions(+), 7 deletions(-)
___
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

2016-04-28 Thread Anatolij Gustschin
On Wed, 27 Apr 2016 21:39:15 +0200
Martin Pietryka martin.pietr...@chello.at 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(-)

appied to u-boot-video/master, thanks!

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


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

2016-04-28 Thread Anatolij Gustschin
On Wed, 27 Apr 2016 21:39:16 +0200
Martin Pietryka martin.pietr...@chello.at wrote:

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

appied to u-boot-video/master, thanks!

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


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

2016-04-28 Thread Anatolij Gustschin
Hi Stefano,

On Thu, 28 Apr 2016 16:29:43 +0200
Stefano Babic sba...@denx.de wrote:
...
> Applied to u-boot-imx, thanks !

Thanks!

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


[U-Boot] Please pull u-boot-sunxi master

2016-04-28 Thread Hans de Goede

Hi Tom,

Here is a bug-fix sunxi pull-req for v2016.05 containing 2 bug-fixes.

The following changes since commit e25b369c048b51b1feb79587750e7e160fc0bd73:

  ARM64: zynqmp: Cleanup config file after CMD move (2016-04-26 10:16:10 -0400)

are available in the git repository at:

  http://git.denx.de/u-boot-sunxi.git master

for you to fetch changes up to ad14166426ab8ca40424ede741d27fdcfb4fc2c6:

  sunxi: Enable LDO3 at 3.3V on A13-OLinuXino board (2016-04-27 19:54:26 +0200)


Hans de Goede (2):
  sunxi: mctl_mem_matches: Add missing memory barrier
  sunxi: Enable LDO3 at 3.3V on A13-OLinuXino board

 arch/arm/mach-sunxi/dram_helpers.c | 2 ++
 configs/A13-OLinuXino_defconfig| 1 +
 2 files changed, 3 insertions(+)

Regards,

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


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

2016-04-28 Thread Masahiro Yamada
2016-04-28 16:08 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.
>
> Signed-off-by: Michal Simek 


Reviewed-by: Masahiro Yamada 


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


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

2016-04-28 Thread Stefano Babic
On 28/04/2016 16:20, Peter Robinson wrote:
> On Thu, Apr 28, 2016 at 3:07 AM, Peng Fan  wrote:
>> 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 
> Tested-by: Peter Robinson 
> 
>> ---
>>
>> Hi Peter,
>>
>>  Please help test this patch to see whether this fix your issue or not.
>>  Thanks for pointing out this issue.
> 
> It fixes the build issue, I'll be installing it onto a number of
> devices over the next couple of days.
> 
> Thanks,
> Peter
> 
>> 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
>>

Applied to u-boot-imx, thanks !

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] video: ipu_common: fix build error

2016-04-28 Thread Peter Robinson
On Thu, Apr 28, 2016 at 3:07 AM, Peng Fan  wrote:
> 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 
Tested-by: Peter Robinson 

> ---
>
> Hi Peter,
>
>  Please help test this patch to see whether this fix your issue or not.
>  Thanks for pointing out this issue.

It fixes the build issue, I'll be installing it onto a number of
devices over the next couple of days.

Thanks,
Peter

> 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 v3 1/2] spl: Add an option to load a FIT containing U-Boot from FS

2016-04-28 Thread Michal Simek
Hi,

2016-04-20 16:41 GMT+02:00 Simon Glass :

> On 13 April 2016 at 23:15, Lokesh Vutla  wrote:
> > This provides a way to load a FIT containing U-Boot and a selection of
> device
> > tree files from a File system.
> >
> > Signed-off-by: Lokesh Vutla 
> > ---
> > Changes since v2:
> > - Fixed the number of bytes being copied.
> >
> >  common/spl/spl_fit.c | 148
> +++
> >  include/spl.h|  31 +++
> >  2 files changed, 156 insertions(+), 23 deletions(-)
> >
> > diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
> > index 1a5c027..f5d47c5 100644
> > --- a/common/spl/spl_fit.c
> > +++ b/common/spl/spl_fit.c
> > @@ -82,12 +82,42 @@ static int spl_fit_select_fdt(const void *fdt, int
> images, int *fdt_offsetp)
> > return -ENOENT;
> >  }
> >
> > +#define get_fit_size(fit) ALIGN(fdt_totalsize(fit), 4)
> > +
> > +static int spl_parse_fit_header(void *fit)
> > +{
> > +   int node;
> > +
> > +   spl_image.images = fdt_path_offset(fit, FIT_IMAGES_PATH);
> > +   if (spl_image.images < 0) {
> > +   debug("%s: Cannot find /images node: %d\n", __func__,
> > + spl_image.images);
> > +   return -1;
> > +   }
> > +   node = fdt_first_subnode(fit, spl_image.images);
> > +   if (node < 0) {
> > +   debug("%s: Cannot find first image node: %d\n",
> __func__, node);
> > +   return -1;
> > +   }
> > +
> > +   /* Get its information and set up the spl_image structure */
> > +   spl_image.data_offset = fdt_getprop_u32(fit, node,
> "data-offset");
> > +   spl_image.data_size = fdt_getprop_u32(fit, node, "data-size");
> > +   spl_image.load_addr = fdt_getprop_u32(fit, node, "load");
> > +   debug("data_offset=%x, data_size=%x\n", spl_image.data_offset,
> > + spl_image.data_size);
> > +   spl_image.entry_point = spl_image.load_addr;
> > +   spl_image.os = IH_OS_U_BOOT;
> > +
> > +   return 0;
> > +}
> > +
> >  int spl_load_simple_fit(struct spl_load_info *info, ulong sector, void
> *fit)
> >  {
> > int sectors;
> > ulong size, load;
> > unsigned long count;
> > -   int node, images;
> > +   int images, ret;
> > void *load_ptr;
> > int fdt_offset, fdt_len;
> > int data_offset, data_size;
> > @@ -99,9 +129,8 @@ int spl_load_simple_fit(struct spl_load_info *info,
> ulong sector, void *fit)
> >  * Figure out where the external images start. This is the base
> for the
> >  * data-offset properties in each image.
> >  */
> > -   size = fdt_totalsize(fit);
> > -   size = (size + 3) & ~3;
> > -   base_offset = (size + 3) & ~3;
> > +   size = get_fit_size(fit);
> > +   base_offset = size;
> >
> > /*
> >  * So far we only have one block of data from the FIT. Read the
> entire
> > @@ -125,26 +154,13 @@ int spl_load_simple_fit(struct spl_load_info
> *info, ulong sector, void *fit)
> > if (count == 0)
> > return -EIO;
> >
> > -   /* find the firmware image to load */
> > -   images = fdt_path_offset(fit, FIT_IMAGES_PATH);
> > -   if (images < 0) {
> > -   debug("%s: Cannot find /images node: %d\n", __func__,
> images);
> > +   ret = spl_parse_fit_header(fit);
> > +   if (ret < 0)
> > return -1;
> > -   }
> > -   node = fdt_first_subnode(fit, images);
> > -   if (node < 0) {
> > -   debug("%s: Cannot find first image node: %d\n",
> __func__, node);
> > -   return -1;
> > -   }
> > -
> > -   /* Get its information and set up the spl_image structure */
> > -   data_offset = fdt_getprop_u32(fit, node, "data-offset");
> > -   data_size = fdt_getprop_u32(fit, node, "data-size");
> > -   load = fdt_getprop_u32(fit, node, "load");
> > -   debug("data_offset=%x, data_size=%x\n", data_offset, data_size);
> > -   spl_image.load_addr = load;
> > -   spl_image.entry_point = load;
> > -   spl_image.os = IH_OS_U_BOOT;
> > +   data_offset = spl_image.data_offset;
> > +   data_size = spl_image.data_size;
> > +   load = spl_image.load_addr;
> > +   images = spl_image.images;
> >
> > /*
> >  * Work out where to place the image. We read it so that the
> first
> > @@ -192,3 +208,89 @@ int spl_load_simple_fit(struct spl_load_info *info,
> ulong sector, void *fit)
> >
> > return 0;
> >  }
> > +
> > +int spl_fs_load_simple_fit(struct spl_load_info *info, const char
> *filename,
> > +  void *fit)
> > +{
> > +   ulong size, load;
> > +   unsigned long count;
> > +   int images, ret;
> > +   void *load_ptr;
> > +   int fdt_offset, fdt_len;
> > +   int data_offset, data_size, file_offset;
> > +   int base_offset = 0, align_len;
> > +   void *dst;
> > +

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

2016-04-28 Thread Marek Vasut
On 04/28/2016 03:36 PM, Stefano Babic wrote:
> Hi Marek,
> 
> On 28/04/2016 13:03, Marek Vasut wrote:
>> On 04/28/2016 07:59 AM, Stefano Babic wrote:
>>> 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
>>
>> The feeling I get from the discussion you linked above and the
>> discussion here is that because user can be an idiot and delete
>> files at random, we should move back to the 80s 
> 
> No U-Boot in the 80s.
> 
>> and store files
>> like on the casette tapes, at random offset. User can also delete
>> kernel image and yet, we store it on the filesystem. Maybe we should
>> also store the kernel image at another raw offset ... and hey, maybe
>> we should ditch filesystem altogether, just tar everything up and
>> store it at yet another offset, since user might delete files at
>> random, just imaging he'd delete libc ...
> 
> wandboard has a market quite similar to the Raspi and yes, there is a
> lot of inexperienced people using it.

Shall I prepare a patch which places kernel to yet another ad-hoc
location on the SD card then and tweak bootargs to use cramfs then?

-- 
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 v2 03/15] arm: Kconfig: Add support for AM43xx SoC specific Kconfig

2016-04-28 Thread Andreas Dannenberg
Hi Heiko,
let me chime in here and address some of your points...

On Thu, Apr 28, 2016 at 06:29:31AM +0200, Heiko Schocher wrote:
> 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?

AFAIK AM33xx and AM43xx have gotten lumped together in several places
both in U-Boot as well as in the Linux Kernel due to similarities in
architecture allowing for code re-use, almost like a "platform" even
though of course those are two different devices. I suppose because
AM33xx devices were first that's how the folder got its name original
name.

If you look around in that folder and open some files you should see
some code such as in emif4.c where stuff is shared.

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

Generally speaking AM335x HS device support in public U-Boot is
currently not for us (us, meaning anybody including existing customers)
to publicly discuss but you can probably take a guess in which direction
things might go after these initial steps taken with Daniel's patch
series. If you have inputs/suggestions however please feel free to email
me directly and we can take it from there.

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

See initial comment..


Thanks and 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] arm: socfpga: Add samtec VIN|ING board

2016-04-28 Thread Dinh Nguyen


On 04/27/2016 06:49 PM, Marek Vasut wrote:

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

Yes.

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

2016-04-28 Thread Stefano Babic
Hi Marek,

On 28/04/2016 13:03, Marek Vasut wrote:
> On 04/28/2016 07:59 AM, Stefano Babic wrote:
>> 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
> 
> The feeling I get from the discussion you linked above and the
> discussion here is that because user can be an idiot and delete
> files at random, we should move back to the 80s 

No U-Boot in the 80s.

> and store files
> like on the casette tapes, at random offset. User can also delete
> kernel image and yet, we store it on the filesystem. Maybe we should
> also store the kernel image at another raw offset ... and hey, maybe
> we should ditch filesystem altogether, just tar everything up and
> store it at yet another offset, since user might delete files at
> random, just imaging he'd delete libc ...

wandboard has a market quite similar to the Raspi and yes, there is a
lot of inexperienced people using it.

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] Introduce clk framework

2016-04-28 Thread Peng Fan
Hi,

Since we are moving towards to use dtb and driver model,
we still lack of a clk framework.

I just have an idea to introduce linux clk framework to u-boot, then
in driver code, we can do as linux "clk_enable/clk_disable/clk_set_freq".

I'd like to hear more voice on clk framework before I began porting the clk 
framework
from kernel to U-Boot. Or redesign a simple one, if the kernel one is too 
complicated?

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


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

2016-04-28 Thread Michal Simek
On 28.4.2016 15:07, Tom Rini wrote:
> On Thu, Apr 28, 2016 at 11:44:50AM +0200, Michal Simek wrote:
>> Hi Simon and Tom,
>>
>> On 23.2.2016 06:55, Simon Glass wrote:
>>> Enable SPL FIT support for the Linksprite pcDuino3 as an example of how this
>>> feature is used.
>>>
>>> This is only for demonstration purposes and is not to be applied.
>>> Signed-off-by: Simon Glass 
>>> ---
>>>
>>> Changes in v2: None
>>>
>>>  arch/arm/cpu/armv7/sunxi/board.c  | 5 +
>>>  configs/Linksprite_pcDuino3_defconfig | 4 
>>>  2 files changed, 9 insertions(+)
>>
>> I have played with SPL_FIT support and find some things
>> First of all
>> "mkimage: Support placing data outside the FIT"
>> (722ebc8f84d5bccd2e70fad1079a0dd40cceddec)
>> is missing description in usage function to see what -E options does.
>>
>> Then I have found a problem with fit address calculation because it has
>> to be aligned.
>> I have sent an RFC for it
>> "SPL: FIT: Align loading address for header"
>>
>> I have also added support for ram load for FIT - please review.
>> "SPL: FIT: Enable SPL_FIT_LOAD in RAM based boot mode"
> 
> I think these are reasonable.
> 
>> And also for SD fat based images.
>> "SPL: FIT: Enable SPL_FIT_LOAD for sd bootmode for fat partions"
> 
> Ug, sorry.  You missed the series from Lokesh that added a bunch more
> features along those lines.  I didn't pull them in since it was past the
> merge window but will for the next release.

Ah ok. Will look.

> 
>> Is there any plan to support falcon mode?
>> Also I see kind of interesting to have one fit image with ATF, Secure
>> OS, bitstreams and U-Boot and Linux kernel + dtbs
>> Currently spl_load_simple_fit() seems to me expecting to blindly read
>> the first fit partition and say this is u-boot and then based
>> configuration description choose dtb.
>>
>> Do you have any plan to get even u-boot image from configurations instead?
>> The we should get a support for loadables.
> 
> Well, the first itch I needed scratched was supporting many similar
> platforms in DM+DT from a single binary, and that's what's there today.
> So long as we can do things in a clean way, all of these other use cases
> sound interesting and clearly useful to some people, so I don't object.
> 

How do you identify platform you are running at?

Thanks,
Michal

___
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

2016-04-28 Thread Marek Vasut
On 04/28/2016 08:16 AM, Stefan Roese wrote:
> On 26.04.2016 03:08, 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 
> 
> Tested-by: Stefan Roese 
> 
> Thanks,
> Stefan

Applied.

-- 
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 v2 27/27] RFC: sunxi: Enable SPL FIT support

2016-04-28 Thread Tom Rini
On Thu, Apr 28, 2016 at 11:44:50AM +0200, Michal Simek wrote:
> Hi Simon and Tom,
> 
> On 23.2.2016 06:55, Simon Glass wrote:
> > Enable SPL FIT support for the Linksprite pcDuino3 as an example of how this
> > feature is used.
> > 
> > This is only for demonstration purposes and is not to be applied.
> > Signed-off-by: Simon Glass 
> > ---
> > 
> > Changes in v2: None
> > 
> >  arch/arm/cpu/armv7/sunxi/board.c  | 5 +
> >  configs/Linksprite_pcDuino3_defconfig | 4 
> >  2 files changed, 9 insertions(+)
> 
> I have played with SPL_FIT support and find some things
> First of all
> "mkimage: Support placing data outside the FIT"
> (722ebc8f84d5bccd2e70fad1079a0dd40cceddec)
> is missing description in usage function to see what -E options does.
> 
> Then I have found a problem with fit address calculation because it has
> to be aligned.
> I have sent an RFC for it
> "SPL: FIT: Align loading address for header"
> 
> I have also added support for ram load for FIT - please review.
> "SPL: FIT: Enable SPL_FIT_LOAD in RAM based boot mode"

I think these are reasonable.

> And also for SD fat based images.
> "SPL: FIT: Enable SPL_FIT_LOAD for sd bootmode for fat partions"

Ug, sorry.  You missed the series from Lokesh that added a bunch more
features along those lines.  I didn't pull them in since it was past the
merge window but will for the next release.

> Is there any plan to support falcon mode?
> Also I see kind of interesting to have one fit image with ATF, Secure
> OS, bitstreams and U-Boot and Linux kernel + dtbs
> Currently spl_load_simple_fit() seems to me expecting to blindly read
> the first fit partition and say this is u-boot and then based
> configuration description choose dtb.
> 
> Do you have any plan to get even u-boot image from configurations instead?
> The we should get a support for loadables.

Well, the first itch I needed scratched was supporting many similar
platforms in DM+DT from a single binary, and that's what's there today.
So long as we can do things in a clean way, all of these other use cases
sound interesting and clearly useful to some people, so I don't object.

-- 
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] Issue with USB mass storage (thumb drives)

2016-04-28 Thread Diego
In data mercoledì 27 aprile 2016 18:13:51, Marek Vasut ha scritto:
> 
> OK, I have to two identical sticks and neither has the same USB ID as
> yours. Can you do lsusb -vvv -d 0951:1689 ?

Hi Marek,

thanks for taking the time to look into this.
Here you are:
# lsusb -vvv -d 0951:1689

Bus 003 Device 020: ID 0951:1689 Kingston Technology DataTraveler SE9
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  idVendor   0x0951 Kingston Technology
  idProduct  0x1689 DataTraveler SE9
  bcdDevice1.00
  iManufacturer   1 Kingston
  iProduct2 DataTraveler SE9
  iSerial 3 0019E06B084BFD10470133E8
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   32
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0x80
  (Bus Powered)
MaxPower  100mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass 8 Mass Storage
  bInterfaceSubClass  6 SCSI
  bInterfaceProtocol 80 Bulk-Only
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval 255
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval 255
Device Qualifier (for other device speed):
  bLength10
  bDescriptorType 6
  bcdUSB   2.00
  bDeviceClass0 
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  bNumConfigurations  1
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x
  (Bus Powered)





Bests,
Diego

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


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

2016-04-28 Thread Tom Rini
On Thu, Apr 28, 2016 at 10:07:53AM +0800, Peng Fan wrote:

> 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 

Reviewed-by: Tom Rini 

-- 
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 v6 4/7] net: phy: ti: Allow the driver to be more configurable

2016-04-28 Thread Dan Murphy
Michal

On 04/28/2016 01:26 AM, Michal Simek wrote:
> Hi Joe,
>
> On 28.4.2016 06:52, Joe Hershberger wrote:
>> 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

Joe fixing these will break readability of the code.
I will document this in the next patch submission


>>> 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).
> NOTE: A lot of my patches (maybe all of them) were already merged to
> mainline via Xilinx tree.

OK latest pull has the SGMII patches on the ti.c.

> Cheers,
> Michal


-- 
--
Dan Murphy

___
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

2016-04-28 Thread Marek Vasut
On 04/28/2016 07:59 AM, Stefano Babic wrote:
> 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

The feeling I get from the discussion you linked above and the
discussion here is that because user can be an idiot and delete
files at random, we should move back to the 80s and store files
like on the casette tapes, at random offset. User can also delete
kernel image and yet, we store it on the filesystem. Maybe we should
also store the kernel image at another raw offset ... and hey, maybe
we should ditch filesystem altogether, just tar everything up and
store it at yet another offset, since user might delete files at
random, just imaging he'd delete libc ...

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

2016-04-28 Thread Tom Rini
On Wed, Apr 27, 2016 at 08:06:24PM -0500, Robert Nelson wrote:
> 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

eMMC is "different" since you don't partition the boot sections usually,
so offset of 0 is good.  But for the eMMC itself when you do partition
it I'd have sworn 4MiB was what to align on.  I haven't thrown
flashbench on something in a while however...

-- 
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] mkimage needs fitImage

2016-04-28 Thread shr ch
Hi,

For adding public keys to uboot dtb the mkimage step is

mkimage -D "-I dts -O dtb -p 2000" -F -k keys -K u-boot.dtb -r fitImage

It resigns fitImage and adds public key to uboot dtb

but why do we need fitImage for adding public keys to uboot dtb ? can't
this be two different steps ? there is already a step to just build
fitImage.

This creates unnecessary dependency of building fitImage before building
uboot.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v3 12/12] defconfig: dra74_evm: enable eth driver model

2016-04-28 Thread Mugunthan V N
Enable eth driver model for dra74_evm as cpsw supports
driver model.

Signed-off-by: Mugunthan V N 
Reviewed-by: Tom Rini 
Acked-by: Joe Hershberger 
---
 configs/dra74_evm_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/dra74_evm_defconfig b/configs/dra74_evm_defconfig
index a11dcd5..32ffce7 100644
--- a/configs/dra74_evm_defconfig
+++ b/configs/dra74_evm_defconfig
@@ -50,3 +50,4 @@ CONFIG_USB_GADGET_DOWNLOAD=y
 CONFIG_G_DNL_MANUFACTURER="Texas Instruments"
 CONFIG_G_DNL_VENDOR_NUM=0x0451
 CONFIG_G_DNL_PRODUCT_NUM=0xd022
+CONFIG_DM_ETH=y
-- 
2.8.1.339.g3ad15fd

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


[U-Boot] [PATCH v3 11/12] defconfig: am437x_sk_evm: enable eth driver model

2016-04-28 Thread Mugunthan V N
Enable eth driver model for am437x_sk_evm as cpsw supports
driver model.

Signed-off-by: Mugunthan V N 
Reviewed-by: Tom Rini 
Acked-by: Joe Hershberger 
---
 configs/am437x_sk_evm_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/am437x_sk_evm_defconfig b/configs/am437x_sk_evm_defconfig
index 48ec91f..8be0412 100644
--- a/configs/am437x_sk_evm_defconfig
+++ b/configs/am437x_sk_evm_defconfig
@@ -51,3 +51,4 @@ CONFIG_USB_GADGET_DOWNLOAD=y
 CONFIG_G_DNL_MANUFACTURER="Texas Instruments"
 CONFIG_G_DNL_VENDOR_NUM=0x0403
 CONFIG_G_DNL_PRODUCT_NUM=0xbd00
+CONFIG_DM_ETH=y
-- 
2.8.1.339.g3ad15fd

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


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

2016-04-28 Thread Mugunthan V N
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 
---
 configs/am437x_gp_evm_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/am437x_gp_evm_defconfig b/configs/am437x_gp_evm_defconfig
index 03b02ac..f098fd3 100644
--- a/configs/am437x_gp_evm_defconfig
+++ b/configs/am437x_gp_evm_defconfig
@@ -47,3 +47,4 @@ CONFIG_USB_GADGET_DOWNLOAD=y
 CONFIG_G_DNL_MANUFACTURER="Texas Instruments"
 CONFIG_G_DNL_VENDOR_NUM=0x0403
 CONFIG_G_DNL_PRODUCT_NUM=0xbd00
+CONFIG_DM_ETH=y
-- 
2.8.1.339.g3ad15fd

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


[U-Boot] [PATCH v3 07/12] arm: dts: am4372: add syscon node to cpsw to read mac address

2016-04-28 Thread Mugunthan V N
Add syscon node to cpsw device node to read mac address
from efuse.

Signed-off-by: Mugunthan V N 
Reviewed-by: Tom Rini 
Acked-by: Joe Hershberger 
---
 arch/arm/dts/am4372.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/dts/am4372.dtsi b/arch/arm/dts/am4372.dtsi
index c95d1d3..3ffa8e0 100644
--- a/arch/arm/dts/am4372.dtsi
+++ b/arch/arm/dts/am4372.dtsi
@@ -547,6 +547,7 @@
active_slave = <0>;
cpts_clock_mult = <0x8000>;
cpts_clock_shift = <29>;
+   syscon = <_conf>;
ranges;
 
davinci_mdio: mdio@4a101000 {
-- 
2.8.1.339.g3ad15fd

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


[U-Boot] [PATCH v3 09/12] arm: dts: dra7: fix ethernet name with proper device address

2016-04-28 Thread Mugunthan V N
Fix typo error for cpsw device name with proper device address

Signed-off-by: Mugunthan V N 
Reviewed-by: Tom Rini 
Acked-by: Joe Hershberger 
---
 arch/arm/dts/dra7.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/dts/dra7.dtsi b/arch/arm/dts/dra7.dtsi
index 3059273..0f242e6 100644
--- a/arch/arm/dts/dra7.dtsi
+++ b/arch/arm/dts/dra7.dtsi
@@ -1411,7 +1411,7 @@
ti,irqs-safe-map = <0>;
};
 
-   mac: ethernet@4a10 {
+   mac: ethernet@48484000 {
compatible = "ti,cpsw";
ti,hwmods = "gmac";
clocks = <_gmac_ck>, <_gmii_ref_clk_div>;
-- 
2.8.1.339.g3ad15fd

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


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

2016-04-28 Thread Mugunthan V N
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 
Reviewed-by: Tom Rini 
Acked-by: Joe Hershberger 
---
 drivers/net/Makefile  |   2 +-
 drivers/net/cpsw-common.c | 121 ++
 drivers/net/cpsw.c|  24 +++--
 include/cpsw.h|   1 +
 4 files changed, 131 insertions(+), 17 deletions(-)
 create mode 100644 drivers/net/cpsw-common.c

diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index fbedd04..d5e4a97 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -59,7 +59,7 @@ obj-$(CONFIG_SMC9) += smc9.o
 obj-$(CONFIG_SMC911X) += smc911x.o
 obj-$(CONFIG_DRIVER_TI_EMAC) += davinci_emac.o
 obj-$(CONFIG_TSEC_ENET) += tsec.o fsl_mdio.o
-obj-$(CONFIG_DRIVER_TI_CPSW) += cpsw.o
+obj-$(CONFIG_DRIVER_TI_CPSW) += cpsw.o cpsw-common.o
 obj-$(CONFIG_FMAN_ENET) += fsl_mdio.o
 obj-$(CONFIG_TSI108_ETH) += tsi108_eth.o
 obj-$(CONFIG_ULI526X) += uli526x.o
diff --git a/drivers/net/cpsw-common.c b/drivers/net/cpsw-common.c
new file mode 100644
index 000..e828e85
--- /dev/null
+++ b/drivers/net/cpsw-common.c
@@ -0,0 +1,121 @@
+/*
+ * CPSW common - libs used across TI ethernet devices.
+ *
+ * Copyright (C) 2016, Texas Instruments, Incorporated
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define CTRL_MAC_REG(offset, id) ((offset) + 0x8 * (id))
+
+static int davinci_emac_3517_get_macid(struct udevice *dev, u16 offset,
+  int slave, u8 *mac_addr)
+{
+   void *fdt = (void *)gd->fdt_blob;
+   int node = dev->of_offset;
+   u32 macid_lsb;
+   u32 macid_msb;
+   fdt32_t gmii = 0;
+   int syscon;
+   u32 addr;
+
+   syscon = fdtdec_lookup_phandle(fdt, node, "syscon");
+   if (syscon < 0) {
+   error("Syscon offset not found\n");
+   return -ENOENT;
+   }
+
+   addr = (u32)map_physmem(fdt_translate_address(fdt, syscon, ),
+   sizeof(u32), MAP_NOCACHE);
+   if (addr == FDT_ADDR_T_NONE) {
+   error("Not able to get syscon address to get mac efuse 
address\n");
+   return -ENOENT;
+   }
+
+   addr += CTRL_MAC_REG(offset, slave);
+
+   /* try reading mac address from efuse */
+   macid_lsb = readl(addr);
+   macid_msb = readl(addr + 4);
+
+   mac_addr[0] = (macid_msb >> 16) & 0xff;
+   mac_addr[1] = (macid_msb >> 8)  & 0xff;
+   mac_addr[2] = macid_msb & 0xff;
+   mac_addr[3] = (macid_lsb >> 16) & 0xff;
+   mac_addr[4] = (macid_lsb >> 8)  & 0xff;
+   mac_addr[5] = macid_lsb & 0xff;
+
+   return 0;
+}
+
+static int cpsw_am33xx_cm_get_macid(struct udevice *dev, u16 offset, int slave,
+   u8 *mac_addr)
+{
+   void *fdt = (void *)gd->fdt_blob;
+   int node = dev->of_offset;
+   u32 macid_lo;
+   u32 macid_hi;
+   fdt32_t gmii = 0;
+   int syscon;
+   u32 addr;
+
+   syscon = fdtdec_lookup_phandle(fdt, node, "syscon");
+   if (syscon < 0) {
+   error("Syscon offset not found\n");
+   return -ENOENT;
+   }
+
+   addr = (u32)map_physmem(fdt_translate_address(fdt, syscon, ),
+   sizeof(u32), MAP_NOCACHE);
+   if (addr == FDT_ADDR_T_NONE) {
+   error("Not able to get syscon address to get mac efuse 
address\n");
+   return -ENOENT;
+   }
+
+   addr += CTRL_MAC_REG(offset, slave);
+
+   /* try reading mac address from efuse */
+   macid_lo = readl(addr);
+   macid_hi = readl(addr + 4);
+
+   mac_addr[5] = (macid_lo >> 8) & 0xff;
+   mac_addr[4] = macid_lo & 0xff;
+   mac_addr[3] = (macid_hi >> 24) & 0xff;
+   mac_addr[2] = (macid_hi >> 16) & 0xff;
+   mac_addr[1] = (macid_hi >> 8) & 0xff;
+   mac_addr[0] = macid_hi & 0xff;
+
+   return 0;
+}
+
+int ti_cm_get_macid(struct udevice *dev, int slave, u8 *mac_addr)
+{
+   if (of_machine_is_compatible("ti,dm8148"))
+   return cpsw_am33xx_cm_get_macid(dev, 0x630, slave, mac_addr);
+
+   if (of_machine_is_compatible("ti,am33xx"))
+   return cpsw_am33xx_cm_get_macid(dev, 0x630, slave, mac_addr);
+
+   if (of_device_is_compatible(dev, "ti,am3517-emac"))
+   return davinci_emac_3517_get_macid(dev, 0x110, slave, mac_addr);
+
+   if (of_device_is_compatible(dev, "ti,dm816-emac"))
+   return cpsw_am33xx_cm_get_macid(dev, 0x30, slave, mac_addr);
+
+   if (of_machine_is_compatible("ti,am4372"))
+   return cpsw_am33xx_cm_get_macid(dev, 0x630, slave, 

[U-Boot] [PATCH v3 05/12] drivers: net: cpsw: fix get mdio base and gmii_sel reg from DT

2016-04-28 Thread Mugunthan V N
Since dra7x platforms address bus is define as 64 bits to support
LAPE, fdtdec_get_addr() returns a invalid address for mdio based
and gmii_sel register address. Fixing this by using
fdtdec_get_addr_size_auto_noparent() which will derive address
cell and size cell from its parent.

Signed-off-by: Mugunthan V N 
Reviewed-by: Tom Rini 
Acked-by: Joe Hershberger 
---
 drivers/net/cpsw.c | 24 
 1 file changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/net/cpsw.c b/drivers/net/cpsw.c
index 971ebf0..9b1e37b 100644
--- a/drivers/net/cpsw.c
+++ b/drivers/net/cpsw.c
@@ -1137,6 +1137,11 @@ static const struct eth_ops cpsw_eth_ops = {
.stop   = cpsw_eth_stop,
 };
 
+static inline fdt_addr_t cpsw_get_addr_by_node(const void *fdt, int node)
+{
+   return fdtdec_get_addr_size_auto_noparent(fdt, node, "reg", 0, NULL);
+}
+
 static int cpsw_eth_ofdata_to_platdata(struct udevice *dev)
 {
struct eth_pdata *pdata = dev_get_platdata(dev);
@@ -1202,8 +1207,14 @@ static int cpsw_eth_ofdata_to_platdata(struct udevice 
*dev)
 
name = fdt_get_name(fdt, subnode, );
if (!strncmp(name, "mdio", 4)) {
-   priv->data.mdio_base = fdtdec_get_addr(fdt, subnode,
-  "reg");
+   u32 mdio_base;
+
+   mdio_base = cpsw_get_addr_by_node(fdt, subnode);
+   if (mdio_base == FDT_ADDR_T_NONE) {
+   error("Not able to get MDIO address space\n");
+   return -ENOENT;
+   }
+   priv->data.mdio_base = mdio_base;
}
 
if (!strncmp(name, "slave", 5)) {
@@ -1221,8 +1232,13 @@ static int cpsw_eth_ofdata_to_platdata(struct udevice 
*dev)
}
 
if (!strncmp(name, "cpsw-phy-sel", 12)) {
-   priv->data.gmii_sel = fdtdec_get_addr(fdt, subnode,
- "reg");
+   priv->data.gmii_sel = cpsw_get_addr_by_node(fdt,
+   subnode);
+
+   if (priv->data.gmii_sel == FDT_ADDR_T_NONE) {
+   error("Not able to get gmii_sel reg address\n");
+   return -ENOENT;
+   }
}
}
 
-- 
2.8.1.339.g3ad15fd

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


[U-Boot] [PATCH v3 08/12] arm: dts: dra7: add syscon node to cpsw to read mac address

2016-04-28 Thread Mugunthan V N
Add syscon node to cpsw device node to read mac address
from efuse.

Signed-off-by: Mugunthan V N 
Reviewed-by: Tom Rini 
Acked-by: Joe Hershberger 
---
 arch/arm/dts/dra7.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/dts/dra7.dtsi b/arch/arm/dts/dra7.dtsi
index e7fecf7..3059273 100644
--- a/arch/arm/dts/dra7.dtsi
+++ b/arch/arm/dts/dra7.dtsi
@@ -1426,6 +1426,7 @@
active_slave = <0>;
cpts_clock_mult = <0x8000>;
cpts_clock_shift = <29>;
+   syscon = <_conf>;
reg = <0x48484000 0x1000
   0x48485200 0x2E00>;
#address-cells = <1>;
-- 
2.8.1.339.g3ad15fd

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


[U-Boot] [PATCH v3 04/12] ARM: omap5: add platform specific ethernet phy modes configurations

2016-04-28 Thread Mugunthan V N
Add platforms specific phy mode configuration bits to be used
to configure phy mode in control module.

Signed-off-by: Mugunthan V N 
Reviewed-by: Tom Rini 
Acked-by: Joe Hershberger 
---
 arch/arm/include/asm/arch-omap5/cpu.h | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/include/asm/arch-omap5/cpu.h 
b/arch/arm/include/asm/arch-omap5/cpu.h
index b1513e9..683d905 100644
--- a/arch/arm/include/asm/arch-omap5/cpu.h
+++ b/arch/arm/include/asm/arch-omap5/cpu.h
@@ -116,4 +116,16 @@ struct watchdog {
 #define CPSW_BASE  0x48484000
 #define CPSW_MDIO_BASE 0x48485000
 
+/* gmii_sel register defines */
+#define GMII1_SEL_MII  0x0
+#define GMII1_SEL_RMII 0x1
+#define GMII1_SEL_RGMII0x2
+#define GMII2_SEL_MII  (GMII1_SEL_MII << 4)
+#define GMII2_SEL_RMII (GMII1_SEL_RMII << 4)
+#define GMII2_SEL_RGMII(GMII1_SEL_RGMII << 4)
+
+#define MII_MODE_ENABLE(GMII1_SEL_MII | GMII2_SEL_MII)
+#define RMII_MODE_ENABLE(GMII1_SEL_RMII | GMII2_SEL_RMII)
+#define RGMII_MODE_ENABLE  (GMII1_SEL_RGMII | GMII2_SEL_RGMII)
+
 #endif /* _CPU_H */
-- 
2.8.1.339.g3ad15fd

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


[U-Boot] [PATCH v3 03/12] drivers: net: cpsw: fix cpsw dp parse when num slaves as 1

2016-04-28 Thread Mugunthan V N
On some boards number of slaves can be 1 when only one port
ethernet is pinned out. So do not break when slave_index and
num slaves check fails, instead continue to parse the next
child.

Signed-off-by: Mugunthan V N 
Reviewed-by: Tom Rini 
Acked-by: Joe Hershberger 
---
 drivers/net/cpsw.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/net/cpsw.c b/drivers/net/cpsw.c
index 7104754..971ebf0 100644
--- a/drivers/net/cpsw.c
+++ b/drivers/net/cpsw.c
@@ -1209,10 +1209,8 @@ static int cpsw_eth_ofdata_to_platdata(struct udevice 
*dev)
if (!strncmp(name, "slave", 5)) {
u32 phy_id[2];
 
-   if (slave_index >= priv->data.slaves) {
-   printf("error: num slaves and slave nodes did 
not match\n");
-   return -EINVAL;
-   }
+   if (slave_index >= priv->data.slaves)
+   continue;
phy_mode = fdt_getprop(fdt, subnode, "phy-mode", NULL);
if (phy_mode)
priv->data.slave_data[slave_index].phy_if =
-- 
2.8.1.339.g3ad15fd

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


[U-Boot] [PATCH v3 02/12] ti_omap5_common: eth: do not define DM_ETH for spl

2016-04-28 Thread Mugunthan V N
Since omap's spl doesn't support DM currently, do not define
DM_ETH for spl build.

Signed-off-by: Mugunthan V N 
Reviewed-by: Simon Glass 
Reviewed-by: Tom Rini 
Acked-by: Joe Hershberger 
---
 include/configs/ti_omap5_common.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/ti_omap5_common.h 
b/include/configs/ti_omap5_common.h
index b049be4..2135af0 100644
--- a/include/configs/ti_omap5_common.h
+++ b/include/configs/ti_omap5_common.h
@@ -153,6 +153,7 @@
 #ifdef CONFIG_SPL_BUILD
 #undef CONFIG_DM_MMC
 #undef CONFIG_TIMER
+#undef CONFIG_DM_ETH
 #endif
 
 #endif /* __CONFIG_TI_OMAP5_COMMON_H */
-- 
2.8.1.339.g3ad15fd

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


[U-Boot] [PATCH v3 00/12] cpsw: enable DM_ETH on dra74 and am437x evms

2016-04-28 Thread Mugunthan V N
This series adds the following
* Enable DM_ETH on dra74, am437x gp and am437x sk evms.
* Add support to verify of_is_device_conpatible() based on
  linux implementation
* Fix an issue in fdtdec get addr for address and size cell length

Changes from initial version:
* removed 02/11 fix size cell and address cell parse from DT and
  used fdtdec_get_addr_size_auto_noparent() to get mdio base and
  gmii_sel register address. Added as separate patch in this
  series.
* used fdt_node_check_compatible() to check if the device or
  machine is compatible with the given compatible string.
* change first argument from node offset to device pointer so
  that in future it is will be easy to migrate out of indexing
  DT by offsets.

Changes from v2:
* Just rebase on top of u-boot/master and resolve conflicts.

Mugunthan V N (12):
  drivers: core: device: add support to check dt compatible for a
device/machine
  ti_omap5_common: eth: do not define DM_ETH for spl
  drivers: net: cpsw: fix cpsw dp parse when num slaves as 1
  ARM: omap5: add platform specific ethernet phy modes configurations
  drivers: net: cpsw: fix get mdio base and gmii_sel reg from DT
  drivers: net: cpsw: add support for reading mac address from efuse
  arm: dts: am4372: add syscon node to cpsw to read mac address
  arm: dts: dra7: add syscon node to cpsw to read mac address
  arm: dts: dra7: fix ethernet name with proper device address
  defconfig: am437x_gp_evm: enable eth driver model
  defconfig: am437x_sk_evm: enable eth driver model
  defconfig: dra74_evm: enable eth driver model

 arch/arm/dts/am4372.dtsi  |   1 +
 arch/arm/dts/dra7.dtsi|   3 +-
 arch/arm/include/asm/arch-omap5/cpu.h |  12 
 configs/am437x_gp_evm_defconfig   |   1 +
 configs/am437x_sk_evm_defconfig   |   1 +
 configs/dra74_evm_defconfig   |   1 +
 drivers/core/device.c |  14 
 drivers/net/Makefile  |   2 +-
 drivers/net/cpsw-common.c | 121 ++
 drivers/net/cpsw.c|  54 ---
 include/configs/ti_omap5_common.h |   1 +
 include/cpsw.h|   1 +
 include/dm/device.h   |  23 +++
 13 files changed, 209 insertions(+), 26 deletions(-)
 create mode 100644 drivers/net/cpsw-common.c

-- 
2.8.1.339.g3ad15fd

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


[U-Boot] [PATCH v3 01/12] drivers: core: device: add support to check dt compatible for a device/machine

2016-04-28 Thread Mugunthan V N
Provide an api to check whether the given device or machine is
compatible with the given compat string which helps in making
decisions in drivers based on device or machine compatible.

Idea taken from Linux.

Signed-off-by: Mugunthan V N 
Reviewed-by: Joe Hershberger 
---
 drivers/core/device.c | 14 ++
 include/dm/device.h   | 23 +++
 2 files changed, 37 insertions(+)

diff --git a/drivers/core/device.c b/drivers/core/device.c
index 1322991..8fdd193 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -715,3 +715,17 @@ int device_set_name(struct udevice *dev, const char *name)
 
return 0;
 }
+
+bool of_device_is_compatible(struct udevice *dev, const char *compat)
+{
+   const void *fdt = gd->fdt_blob;
+
+   return !fdt_node_check_compatible(fdt, dev->of_offset, compat);
+}
+
+bool of_machine_is_compatible(const char *compat)
+{
+   const void *fdt = gd->fdt_blob;
+
+   return !fdt_node_check_compatible(fdt, 0, compat);
+}
diff --git a/include/dm/device.h b/include/dm/device.h
index 8970fc0..cd18e82 100644
--- a/include/dm/device.h
+++ b/include/dm/device.h
@@ -532,6 +532,29 @@ bool device_is_last_sibling(struct udevice *dev);
 int device_set_name(struct udevice *dev, const char *name);
 
 /**
+ * of_device_is_compatible() - check if the device is compatible with the 
compat
+ *
+ * This allows to check whether the device is comaptible with the compat.
+ *
+ * @dev:   udevice pointer for which compatible needs to be verified.
+ * @compat:Compatible string which needs to verified in the given
+ * device
+ * @return true if OK, false if the compatible is not found
+ */
+bool of_device_is_compatible(struct udevice *dev, const char *compat);
+
+/**
+ * of_machine_is_compatible() - check if the machine is compatible with
+ * the compat
+ *
+ * This allows to check whether the machine is comaptible with the compat.
+ *
+ * @compat:Compatible string which needs to verified
+ * @return true if OK, false if the compatible is not found
+ */
+bool of_machine_is_compatible(const char *compat);
+
+/**
  * device_is_on_pci_bus - Test if a device is on a PCI bus
  *
  * @dev:   device to test
-- 
2.8.1.339.g3ad15fd

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


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

2016-04-28 Thread Michal Simek
Hi Simon and Tom,

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

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

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

I have also added support for ram load for FIT - please review.
"SPL: FIT: Enable SPL_FIT_LOAD in RAM based boot mode"
And also for SD fat based images.
"SPL: FIT: Enable SPL_FIT_LOAD for sd bootmode for fat partions"

Is there any plan to support falcon mode?
Also I see kind of interesting to have one fit image with ATF, Secure
OS, bitstreams and U-Boot and Linux kernel + dtbs
Currently spl_load_simple_fit() seems to me expecting to blindly read
the first fit partition and say this is u-boot and then based
configuration description choose dtb.

Do you have any plan to get even u-boot image from configurations instead?
The we should get a support for loadables.

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


[U-Boot] [RFC PATCH] SPL: FIT: Enable SPL_FIT_LOAD for sd bootmode for fat partions

2016-04-28 Thread Michal Simek
Support U-Boot SPL to load FIT image from fat partition.
Fit image can be setup via CONFIG_SPL_FS_LOAD_KERNEL_NAME.
Falcon mode is not supported.

Signed-off-by: Michal Simek 
---

 common/spl/spl_fat.c | 50 --
 fs/fat/fat.c |  4 ++--
 2 files changed, 46 insertions(+), 8 deletions(-)

diff --git a/common/spl/spl_fat.c b/common/spl/spl_fat.c
index d16cd540e38a..4e319c5fa470 100644
--- a/common/spl/spl_fat.c
+++ b/common/spl/spl_fat.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -39,6 +40,29 @@ static int spl_register_fat_device(struct blk_desc 
*block_dev, int partition)
return err;
 }
 
+#ifdef CONFIG_SPL_LOAD_FIT
+static ulong spl_fat_file_read(struct spl_load_info *load, ulong sector,
+  ulong count, void *buf)
+{
+   int err;
+   loff_t actread;
+   char *filename = (char *)load->priv;
+
+   debug("%s: name %s, sector %lx, count %lx, buf %lx\n",
+ __func__, filename,  sector, count, (ulong)buf);
+
+   err = file_fat_read_at(filename, sector, buf, count, );
+   if (err < 0) {
+   printf("%s: error reading image %s, err - %d\n",
+  __func__, filename, err);
+   return err;
+   }
+
+   debug("actread %lx\n", (ulong)actread);
+   return actread;
+}
+#endif
+
 int spl_load_image_fat(struct blk_desc *block_dev,
int partition,
const char *filename)
@@ -57,16 +81,29 @@ int spl_load_image_fat(struct blk_desc *block_dev,
if (err <= 0)
goto end;
 
-   spl_parse_image_header(header);
+   if (IS_ENABLED(CONFIG_SPL_LOAD_FIT) &&
+   image_get_magic(header) == FDT_MAGIC) {
+   struct spl_load_info load;
+
+   debug("Found FIT\n");
+   load.priv = (char *)filename;
+   load.bl_len = 1;
+   load.read = spl_fat_file_read;
+   spl_load_simple_fit(, 0, header);
+   } else {
+   debug("Legacy image\n");
 
-   err = file_fat_read(filename, (u8 *)(uintptr_t)spl_image.load_addr, 0);
+   spl_parse_image_header(header);
 
+   err = file_fat_read(filename,
+   (u8 *)(uintptr_t)spl_image.load_addr, 0);
 end:
 #ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
-   if (err <= 0)
-   printf("%s: error reading image %s, err - %d\n",
-  __func__, filename, err);
+   if (err <= 0)
+   printf("%s: error reading image %s, err - %d\n",
+  __func__, filename, err);
 #endif
+   }
 
return (err <= 0);
 }
@@ -81,6 +118,7 @@ int spl_load_image_fat_os(struct blk_desc *block_dev, int 
partition)
if (err)
return err;
 
+#if !defined(CONFIG_SPL_LOAD_FIT)
 #if defined(CONFIG_SPL_ENV_SUPPORT) && defined(CONFIG_SPL_OS_BOOT)
file = getenv("falcon_args_file");
if (file) {
@@ -116,7 +154,7 @@ defaults:
 #endif
return -1;
}
-
+#endif
return spl_load_image_fat(block_dev, partition,
CONFIG_SPL_FS_LOAD_KERNEL_NAME);
 }
diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index 600a90e30922..0d987e0465ee 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -281,9 +281,9 @@ get_cluster(fsdata *mydata, __u32 clustnum, __u8 *buffer, 
unsigned long size)
 
if ((unsigned long)buffer & (ARCH_DMA_MINALIGN - 1)) {
ALLOC_CACHE_ALIGN_BUFFER(__u8, tmpbuf, mydata->sect_size);
-
+#if !defined(CONFIG_SPL_LOAD_FIT)
printf("FAT: Misaligned buffer address (%p)\n", buffer);
-
+#endif
while (size >= mydata->sect_size) {
ret = disk_read(startsect++, 1, tmpbuf);
if (ret != 1) {
-- 
1.9.1

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


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

2016-04-28 Thread Mugunthan V N
On Thursday 28 April 2016 10:03 AM, Joe Hershberger wrote:
> 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.
> 

Ok, will send it today.

Regards
Mugunthan V N

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


[U-Boot] [RFC PATCH] SPL: FIT: Enable SPL_FIT_LOAD in RAM based boot mode

2016-04-28 Thread Michal Simek
Support loading FIT in SPL for RAM bootmode.
CONFIG_SPL_LOAD_FIT_ADRESS points to address where FIT image is stored
in memory.

Signed-off-by: Michal Simek 
---

Not sure if solution with CONFIG_SPL_LOAD_FIT_ADDRESS is accepted.
But it should be out of TEXT_BASE.

---
 common/spl/spl.c | 44 +++-
 1 file changed, 35 insertions(+), 9 deletions(-)

diff --git a/common/spl/spl.c b/common/spl/spl.c
index f1e792dd7c61..128ccaa55e3e 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -134,19 +134,45 @@ __weak void __noreturn jump_to_image_no_args(struct 
spl_image_info *spl_image)
 }
 
 #ifdef CONFIG_SPL_RAM_DEVICE
+#ifdef CONFIG_SPL_LOAD_FIT
+static ulong spl_ram_load_read(struct spl_load_info *load, ulong sector,
+  ulong count, void *buf)
+{
+
+   debug("%s: sector %lx, count %lx, buf %lx\n",
+ __func__, sector, count, (ulong)buf);
+   memcpy(buf, (void *)(CONFIG_SPL_LOAD_FIT_ADRESS + sector), count);
+   return count;
+}
+#endif
+
 static int spl_ram_load_image(void)
 {
-   const struct image_header *header;
+   struct image_header *header;
 
-   /*
-* Get the header.  It will point to an address defined by handoff
-* which will tell where the image located inside the flash. For
-* now, it will temporary fixed to address pointed by U-Boot.
-*/
-   header = (struct image_header *)
-   (CONFIG_SYS_TEXT_BASE - sizeof(struct image_header));
+   header = (struct image_header *)CONFIG_SPL_LOAD_FIT_ADRESS;
 
-   spl_parse_image_header(header);
+   if (IS_ENABLED(CONFIG_SPL_LOAD_FIT) &&
+   image_get_magic(header) == FDT_MAGIC) {
+   struct spl_load_info load;
+
+   debug("Found FIT\n");
+   load.bl_len = 1;
+   load.read = spl_ram_load_read;
+   spl_load_simple_fit(, 0, header);
+   } else {
+   debug("Legacy image\n");
+   /*
+* Get the header.  It will point to an address defined by
+* handoff which will tell where the image located inside
+* the flash. For now, it will temporary fixed to address
+* pointed by U-Boot.
+*/
+   header = (struct image_header *)
+   (CONFIG_SYS_TEXT_BASE - sizeof(struct image_header));
+
+   spl_parse_image_header(header);
+   }
 
return 0;
 }
-- 
1.9.1

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


[U-Boot] [RFC PATCH] SPL: FIT: Align loading address for header

2016-04-28 Thread Michal Simek
If bl_len is not aligned it can caused a problem because another code
expects that start is aligned.

Signed-off-by: Michal Simek 
---

Not sure if this is the right way how to ensure it.
But patch is pointing to the problem. For example if bl_len is 1.
---
 common/spl/spl_fit.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index e301927c87ac..08e432a52dbb 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -119,6 +119,7 @@ int spl_load_simple_fit(struct spl_load_info *info, ulong 
sector, void *fit)
 * be before CONFIG_SYS_TEXT_BASE.
 */
fit = (void *)(CONFIG_SYS_TEXT_BASE - size - info->bl_len);
+   fit = (void *)ALIGN((ulong)fit, 8);
sectors = (size + info->bl_len - 1) / info->bl_len;
count = info->read(info, sector, sectors, fit);
debug("fit read sector %lx, sectors=%d, dst=%p, count=%lu\n",
-- 
1.9.1

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


Re: [U-Boot] [PATCH 1/3] i2c: Add entry for Designware I2C driver in Kconfig

2016-04-28 Thread Bin Meng
On Thu, Apr 28, 2016 at 3:47 PM, Stefan Roese  wrote:
> This patch adds an entry for the Designware I2C driver in Kconfig.
>
> Signed-off-by: Stefan Roese 
> Cc: Heiko Schocher 
> ---
>  drivers/i2c/Kconfig | 8 
>  1 file changed, 8 insertions(+)
>

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


[U-Boot] [PATCH 3/3] i2c: Select SYS_I2C_DW_ENABLE_STATUS_UNSUPPORTED for SPEAr

2016-04-28 Thread Stefan Roese
The DW I2C controller in the SPEAr SoCs doesn't support the enable
status register check. This patch selects
SYS_I2C_DW_ENABLE_STATUS_UNSUPPORTED for these boards.

Signed-off-by: Stefan Roese 
Cc: Heiko Schocher 
---
 drivers/i2c/Kconfig | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
index 48ab486..3b9f5f5 100644
--- a/drivers/i2c/Kconfig
+++ b/drivers/i2c/Kconfig
@@ -73,6 +73,16 @@ config SYS_I2C_DW
  controller is used in various SoCs, e.g. the ST SPEAr, Altera
  SoCFPGA, Synopsys ARC700 and some Intel x86 SoCs.
 
+config SYS_I2C_DW_ENABLE_STATUS_UNSUPPORTED
+   bool "DW I2C Enable Status Register not supported"
+   depends on SYS_I2C_DW && (TARGET_SPEAR300 || TARGET_SPEAR310 || \
+   TARGET_SPEAR320 || TARGET_SPEAR600 || TARGET_X600)
+   default y
+   help
+ Some versions of the Designware I2C controller do not support the
+ enable status register. This config option can be enabled in such
+ cases.
+
 config SYS_I2C_INTEL
bool "Intel I2C/SMBUS driver"
depends on DM_I2C
-- 
2.8.1

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


[U-Boot] [PATCH 2/3] i2c: config: Move SYS_I2C_DW to Kconfig

2016-04-28 Thread Stefan Roese
This patch moves all appearances of CONFIG_SYS_I2C_DW from the config
header to the defconfig files.

Signed-off-by: Stefan Roese 
Cc: Heiko Schocher 
Cc: Alexey Brodkin 
---
 configs/axs101_defconfig   | 1 +
 configs/axs103_defconfig   | 1 +
 configs/socfpga_arria5_defconfig   | 1 +
 configs/socfpga_cyclone5_defconfig | 1 +
 configs/socfpga_de0_nano_soc_defconfig | 1 +
 configs/socfpga_mcvevk_defconfig   | 1 +
 configs/socfpga_sockit_defconfig   | 1 +
 configs/socfpga_socrates_defconfig | 1 +
 configs/socfpga_sr1500_defconfig   | 1 +
 configs/spear300_defconfig | 1 +
 configs/spear300_nand_defconfig| 1 +
 configs/spear300_usbtty_defconfig  | 1 +
 configs/spear300_usbtty_nand_defconfig | 1 +
 configs/spear310_defconfig | 1 +
 configs/spear310_nand_defconfig| 1 +
 configs/spear310_pnor_defconfig| 1 +
 configs/spear310_usbtty_defconfig  | 1 +
 configs/spear310_usbtty_nand_defconfig | 1 +
 configs/spear310_usbtty_pnor_defconfig | 1 +
 configs/spear320_defconfig | 1 +
 configs/spear320_nand_defconfig| 1 +
 configs/spear320_pnor_defconfig| 1 +
 configs/spear320_usbtty_defconfig  | 1 +
 configs/spear320_usbtty_nand_defconfig | 1 +
 configs/spear320_usbtty_pnor_defconfig | 1 +
 configs/spear600_defconfig | 1 +
 configs/spear600_nand_defconfig| 1 +
 configs/spear600_usbtty_defconfig  | 1 +
 configs/spear600_usbtty_nand_defconfig | 1 +
 configs/x600_defconfig | 1 +
 include/configs/axs101.h   | 1 -
 include/configs/socfpga_common.h   | 1 -
 include/configs/spear-common.h | 1 -
 include/configs/x600.h | 1 -
 34 files changed, 30 insertions(+), 4 deletions(-)

diff --git a/configs/axs101_defconfig b/configs/axs101_defconfig
index 85af09e..07a6a18 100644
--- a/configs/axs101_defconfig
+++ b/configs/axs101_defconfig
@@ -18,6 +18,7 @@ CONFIG_OF_EMBED=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_DM=y
 CONFIG_CLK=y
+CONFIG_SYS_I2C_DW=y
 CONFIG_DM_ETH=y
 CONFIG_ETH_DESIGNWARE=y
 CONFIG_SYS_NS16550=y
diff --git a/configs/axs103_defconfig b/configs/axs103_defconfig
index aa9bf33..01a5143 100644
--- a/configs/axs103_defconfig
+++ b/configs/axs103_defconfig
@@ -18,6 +18,7 @@ CONFIG_OF_EMBED=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_DM=y
 CONFIG_CLK=y
+CONFIG_SYS_I2C_DW=y
 CONFIG_DM_ETH=y
 CONFIG_ETH_DESIGNWARE=y
 CONFIG_SYS_NS16550=y
diff --git a/configs/socfpga_arria5_defconfig b/configs/socfpga_arria5_defconfig
index 9a7c091..a662e72 100644
--- a/configs/socfpga_arria5_defconfig
+++ b/configs/socfpga_arria5_defconfig
@@ -33,6 +33,7 @@ CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_SPL_DM_SEQ_ALIAS=y
 CONFIG_DWAPB_GPIO=y
+CONFIG_SYS_I2C_DW=y
 CONFIG_DM_MMC=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_BAR=y
diff --git a/configs/socfpga_cyclone5_defconfig 
b/configs/socfpga_cyclone5_defconfig
index ac81854..b2933f7 100644
--- a/configs/socfpga_cyclone5_defconfig
+++ b/configs/socfpga_cyclone5_defconfig
@@ -33,6 +33,7 @@ CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_SPL_DM_SEQ_ALIAS=y
 CONFIG_DWAPB_GPIO=y
+CONFIG_SYS_I2C_DW=y
 CONFIG_DM_MMC=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_BAR=y
diff --git a/configs/socfpga_de0_nano_soc_defconfig 
b/configs/socfpga_de0_nano_soc_defconfig
index 405d9d4..f197b6d 100644
--- a/configs/socfpga_de0_nano_soc_defconfig
+++ b/configs/socfpga_de0_nano_soc_defconfig
@@ -32,6 +32,7 @@ CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_DWAPB_GPIO=y
+CONFIG_SYS_I2C_DW=y
 CONFIG_DM_MMC=y
 CONFIG_DM_ETH=y
 CONFIG_ETH_DESIGNWARE=y
diff --git a/configs/socfpga_mcvevk_defconfig b/configs/socfpga_mcvevk_defconfig
index 3615490..6624f9e 100644
--- a/configs/socfpga_mcvevk_defconfig
+++ b/configs/socfpga_mcvevk_defconfig
@@ -32,6 +32,7 @@ CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_DWAPB_GPIO=y
+CONFIG_SYS_I2C_DW=y
 CONFIG_DM_MMC=y
 CONFIG_DM_ETH=y
 CONFIG_ETH_DESIGNWARE=y
diff --git a/configs/socfpga_sockit_defconfig b/configs/socfpga_sockit_defconfig
index bdc8e6b..c6414f8 100644
--- a/configs/socfpga_sockit_defconfig
+++ b/configs/socfpga_sockit_defconfig
@@ -33,6 +33,7 @@ CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_SPL_DM_SEQ_ALIAS=y
 CONFIG_DWAPB_GPIO=y
+CONFIG_SYS_I2C_DW=y
 CONFIG_DM_MMC=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_BAR=y
diff --git a/configs/socfpga_socrates_defconfig 
b/configs/socfpga_socrates_defconfig
index b64ea15..86102b8 100644
--- a/configs/socfpga_socrates_defconfig
+++ b/configs/socfpga_socrates_defconfig
@@ -33,6 +33,7 @@ CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_SPL_DM_SEQ_ALIAS=y
 CONFIG_DWAPB_GPIO=y
+CONFIG_SYS_I2C_DW=y
 CONFIG_DM_MMC=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_BAR=y
diff --git a/configs/socfpga_sr1500_defconfig b/configs/socfpga_sr1500_defconfig
index c4b215a..aab4498 100644
--- a/configs/socfpga_sr1500_defconfig
+++ 

[U-Boot] [PATCH 1/3] i2c: Add entry for Designware I2C driver in Kconfig

2016-04-28 Thread Stefan Roese
This patch adds an entry for the Designware I2C driver in Kconfig.

Signed-off-by: Stefan Roese 
Cc: Heiko Schocher 
---
 drivers/i2c/Kconfig | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
index 9324c6c..48ab486 100644
--- a/drivers/i2c/Kconfig
+++ b/drivers/i2c/Kconfig
@@ -65,6 +65,14 @@ config SYS_I2C_CADENCE
  Say yes here to select Cadence I2C Host Controller. This controller is
  e.g. used by Xilinx Zynq.
 
+config SYS_I2C_DW
+   bool "Designware I2C Controller"
+   default n
+   help
+ Say yes here to select the Designware I2C Host Controller. This
+ controller is used in various SoCs, e.g. the ST SPEAr, Altera
+ SoCFPGA, Synopsys ARC700 and some Intel x86 SoCs.
+
 config SYS_I2C_INTEL
bool "Intel I2C/SMBUS driver"
depends on DM_I2C
-- 
2.8.1

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


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

2016-04-28 Thread 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.

Signed-off-by: Michal Simek 
---

Changes in v2:
- Refactor based on Masahiro comments

 scripts/Makefile.spl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index 33f1a3f3939c..5df860e7ed11 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -174,7 +174,7 @@ cmd_cat = cat $(filter-out $(PHONY), $^) > $@
 quiet_cmd_copy = COPY$@
   cmd_copy = cp $< $@
 
-ifeq ($(CONFIG_SPL_OF_CONTROL),y)
+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)
-- 
1.9.1

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


[U-Boot] [PATCH 0/4] ARM: uniphier: some fixes for U-Boot v2016.05

2016-04-28 Thread Masahiro Yamada


Masahiro Yamada (4):
  ARM: uniphier: fix boot mode table of PH1-LD20
  ARM: uniphier: enable Peripherl clock to use UART in SPL
  ARM: uniphier: allow to use System Bus for ROM boot mode of PH1-LD20
  ARM: uniphier: move pin-mux code into pin_init function

 arch/arm/mach-uniphier/boot-mode/boot-mode-ld20.c  |  2 +-
 arch/arm/mach-uniphier/early-clk/early-clk-ld20.c  |  4 +++
 arch/arm/mach-uniphier/early-pinctrl/Makefile  |  1 +
 .../early-pinctrl/early-pinctrl-ld20.c | 32 ++
 .../early-pinctrl/early-pinctrl-sld3.c |  2 ++
 arch/arm/mach-uniphier/init.h  |  7 +
 arch/arm/mach-uniphier/init/init-ld20.c|  2 ++
 arch/arm/mach-uniphier/init/init-sld3.c|  3 +-
 arch/arm/mach-uniphier/sbc/Makefile|  4 +--
 arch/arm/mach-uniphier/sbc/sbc-sld3.c  | 17 
 10 files changed, 46 insertions(+), 28 deletions(-)
 create mode 100644 arch/arm/mach-uniphier/early-pinctrl/early-pinctrl-ld20.c
 delete mode 100644 arch/arm/mach-uniphier/sbc/sbc-sld3.c

-- 
1.9.1

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


[U-Boot] [PATCH 1/4] ARM: uniphier: fix boot mode table of PH1-LD20

2016-04-28 Thread Masahiro Yamada
PH1-LD20 does not have the dedicated boot swap select latch.
Instead, it is controlled from the boot mode select.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/mach-uniphier/boot-mode/boot-mode-ld20.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-uniphier/boot-mode/boot-mode-ld20.c 
b/arch/arm/mach-uniphier/boot-mode/boot-mode-ld20.c
index 100275e..b092c1b 100644
--- a/arch/arm/mach-uniphier/boot-mode/boot-mode-ld20.c
+++ b/arch/arm/mach-uniphier/boot-mode/boot-mode-ld20.c
@@ -43,7 +43,7 @@ static struct boot_device_info boot_device_table[] = {
{BOOT_DEVICE_MMC1, "eMMC (High Speed SDR, 8bit, 1.8V, Training Off)"},
{BOOT_DEVICE_MMC1, "eMMC (High Speed SDR, 8bit, 1.8V, Training On)"},
{BOOT_DEVICE_MMC1, "eMMC (Legacy, 4bit, 1.8V, Training Off)"},
-   {BOOT_DEVICE_NONE, "Reserved"},
+   {BOOT_DEVICE_NOR,  "NOR Boot (XECS1)"},
 };
 
 static int get_boot_mode_sel(void)
-- 
1.9.1

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


[U-Boot] [PATCH 2/4] ARM: uniphier: enable Peripherl clock to use UART in SPL

2016-04-28 Thread Masahiro Yamada
This is needed to use UART on SPL.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/mach-uniphier/early-clk/early-clk-ld20.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/mach-uniphier/early-clk/early-clk-ld20.c 
b/arch/arm/mach-uniphier/early-clk/early-clk-ld20.c
index 37adb37..5201a55 100644
--- a/arch/arm/mach-uniphier/early-clk/early-clk-ld20.c
+++ b/arch/arm/mach-uniphier/early-clk/early-clk-ld20.c
@@ -21,6 +21,10 @@ int uniphier_ld20_early_clk_init(const struct 
uniphier_board_data *bd)
writel(tmp, SC_RSTCTRL7);
 
/* provide clocks */
+   tmp = readl(SC_CLKCTRL4);
+   tmp |= SC_CLKCTRL4_PERI;
+   writel(tmp, SC_CLKCTRL4);
+
tmp = readl(SC_CLKCTRL7);
tmp |= SC_CLKCTRL7_UMCSB | SC_CLKCTRL7_UMC32 | SC_CLKCTRL7_UMC31 |
SC_CLKCTRL7_UMC30;
-- 
1.9.1

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


[U-Boot] [PATCH 3/4] ARM: uniphier: allow to use System Bus for ROM boot mode of PH1-LD20

2016-04-28 Thread Masahiro Yamada
The System Bus is not available by default on the ROM boot mode of
PH1-LD20.  To use devices connected to the System Bus, such as the
Micro Support Card, it is necessary to set up pin-muxing and some
System Bus Controller register.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/mach-uniphier/early-pinctrl/Makefile  |  1 +
 .../early-pinctrl/early-pinctrl-ld20.c | 32 ++
 arch/arm/mach-uniphier/init.h  |  1 +
 arch/arm/mach-uniphier/init/init-ld20.c|  2 ++
 arch/arm/mach-uniphier/sbc/Makefile|  2 +-
 5 files changed, 37 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/mach-uniphier/early-pinctrl/early-pinctrl-ld20.c

diff --git a/arch/arm/mach-uniphier/early-pinctrl/Makefile 
b/arch/arm/mach-uniphier/early-pinctrl/Makefile
index dc4064c..a103902 100644
--- a/arch/arm/mach-uniphier/early-pinctrl/Makefile
+++ b/arch/arm/mach-uniphier/early-pinctrl/Makefile
@@ -3,3 +3,4 @@
 #
 
 obj-$(CONFIG_ARCH_UNIPHIER_SLD3)   += early-pinctrl-sld3.o
+obj-$(CONFIG_ARCH_UNIPHIER_LD20)   += early-pinctrl-ld20.o
diff --git a/arch/arm/mach-uniphier/early-pinctrl/early-pinctrl-ld20.c 
b/arch/arm/mach-uniphier/early-pinctrl/early-pinctrl-ld20.c
new file mode 100644
index 000..537deaf
--- /dev/null
+++ b/arch/arm/mach-uniphier/early-pinctrl/early-pinctrl-ld20.c
@@ -0,0 +1,32 @@
+/*
+ * Copyright (C) 2016 Masahiro Yamada 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include "../init.h"
+#include "../sg-regs.h"
+
+int uniphier_ld20_early_pin_init(const struct uniphier_board_data *bd)
+{
+   /* Comment format:PAD Name -> Function Name */
+   sg_set_pinsel(0, 0, 8, 4);  /* XECS1  -> XECS1 */
+   sg_set_pinsel(1, 0, 8, 4);  /* ERXW   -> ERXW  */
+   sg_set_pinsel(2, 0, 8, 4);  /* XERWE1 -> XERWE1 */
+   sg_set_pinsel(6, 2, 8, 4);  /* XNFRE  -> XERWE0 */
+   sg_set_pinsel(7, 2, 8, 4);  /* XNFWE  -> ES0 */
+   sg_set_pinsel(8, 2, 8, 4);  /* NFALE  -> ES1 */
+   sg_set_pinsel(9, 2, 8, 4);  /* NFCLE  -> ES2 */
+   sg_set_pinsel(10, 2, 8, 4); /* NFD0   -> ED0 */
+   sg_set_pinsel(11, 2, 8, 4); /* NFD1   -> ED1 */
+   sg_set_pinsel(12, 2, 8, 4); /* NFD2   -> ED2 */
+   sg_set_pinsel(13, 2, 8, 4); /* NFD3   -> ED3 */
+   sg_set_pinsel(14, 2, 8, 4); /* NFD4   -> ED4 */
+   sg_set_pinsel(15, 2, 8, 4); /* NFD5   -> ED5 */
+   sg_set_pinsel(16, 2, 8, 4); /* NFD6   -> ED6 */
+   sg_set_pinsel(17, 2, 8, 4); /* NFD7   -> ED7 */
+   sg_set_iectrl_range(0, 2);
+   sg_set_iectrl_range(6, 17);
+
+   return 0;
+}
diff --git a/arch/arm/mach-uniphier/init.h b/arch/arm/mach-uniphier/init.h
index f5b3fa8..5a0ebeb 100644
--- a/arch/arm/mach-uniphier/init.h
+++ b/arch/arm/mach-uniphier/init.h
@@ -90,6 +90,7 @@ int uniphier_pxs2_early_clk_init(const struct 
uniphier_board_data *bd);
 int uniphier_ld20_early_clk_init(const struct uniphier_board_data *bd);
 
 int uniphier_sld3_early_pin_init(const struct uniphier_board_data *bd);
+int uniphier_ld20_early_pin_init(const struct uniphier_board_data *bd);
 
 int uniphier_ld4_umc_init(const struct uniphier_board_data *bd);
 int uniphier_pro4_umc_init(const struct uniphier_board_data *bd);
diff --git a/arch/arm/mach-uniphier/init/init-ld20.c 
b/arch/arm/mach-uniphier/init/init-ld20.c
index 0ad264c..660ad45 100644
--- a/arch/arm/mach-uniphier/init/init-ld20.c
+++ b/arch/arm/mach-uniphier/init/init-ld20.c
@@ -13,6 +13,8 @@
 int uniphier_ld20_init(const struct uniphier_board_data *bd)
 {
uniphier_sbc_init_savepin(bd);
+   uniphier_pxs2_sbc_init(bd);
+   uniphier_ld20_early_pin_init(bd);
 
support_card_reset();
 
diff --git a/arch/arm/mach-uniphier/sbc/Makefile 
b/arch/arm/mach-uniphier/sbc/Makefile
index 3c1e92a..236f136 100644
--- a/arch/arm/mach-uniphier/sbc/Makefile
+++ b/arch/arm/mach-uniphier/sbc/Makefile
@@ -9,4 +9,4 @@ obj-$(CONFIG_ARCH_UNIPHIER_SLD8)+= sbc-savepin.o 
sbc-ld4.o
 obj-$(CONFIG_ARCH_UNIPHIER_PRO5)   += sbc-savepin.o
 obj-$(CONFIG_ARCH_UNIPHIER_PXS2)   += sbc-savepin.o sbc-pxs2.o
 obj-$(CONFIG_ARCH_UNIPHIER_LD6B)   += sbc-savepin.o sbc-pxs2.o
-obj-$(CONFIG_ARCH_UNIPHIER_LD20)   += sbc-savepin.o
+obj-$(CONFIG_ARCH_UNIPHIER_LD20)   += sbc-savepin.o sbc-pxs2.o
-- 
1.9.1

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


[U-Boot] [PATCH 4/4] ARM: uniphier: move pin-mux code into pin_init function

2016-04-28 Thread Masahiro Yamada
The code in uniphier_sld3_sbc_init() is pin-muxing, so it would
be a better fit in uniphier_sld3_early_pin_init().

Signed-off-by: Masahiro Yamada 
---

 .../mach-uniphier/early-pinctrl/early-pinctrl-sld3.c|  2 ++
 arch/arm/mach-uniphier/init.h   |  6 --
 arch/arm/mach-uniphier/init/init-sld3.c |  3 +--
 arch/arm/mach-uniphier/sbc/Makefile |  2 +-
 arch/arm/mach-uniphier/sbc/sbc-sld3.c   | 17 -
 5 files changed, 4 insertions(+), 26 deletions(-)
 delete mode 100644 arch/arm/mach-uniphier/sbc/sbc-sld3.c

diff --git a/arch/arm/mach-uniphier/early-pinctrl/early-pinctrl-sld3.c 
b/arch/arm/mach-uniphier/early-pinctrl/early-pinctrl-sld3.c
index 22c07fb..6c5d58f 100644
--- a/arch/arm/mach-uniphier/early-pinctrl/early-pinctrl-sld3.c
+++ b/arch/arm/mach-uniphier/early-pinctrl/early-pinctrl-sld3.c
@@ -22,5 +22,7 @@ int uniphier_sld3_early_pin_init(const struct 
uniphier_board_data *bd)
sg_set_pinsel(102, 2, 4, 4);/* TXD2 */
 #endif
 
+   sg_set_pinsel(99, 1, 4, 4); /* GPIO26 -> EA24 */
+
return 0;
 }
diff --git a/arch/arm/mach-uniphier/init.h b/arch/arm/mach-uniphier/init.h
index 5a0ebeb..ab0a68d 100644
--- a/arch/arm/mach-uniphier/init.h
+++ b/arch/arm/mach-uniphier/init.h
@@ -37,7 +37,6 @@ int uniphier_ld20_init(const struct uniphier_board_data *bd);
 #if defined(CONFIG_MICRO_SUPPORT_CARD)
 int uniphier_sbc_init_admulti(const struct uniphier_board_data *bd);
 int uniphier_sbc_init_savepin(const struct uniphier_board_data *bd);
-int uniphier_sld3_sbc_init(const struct uniphier_board_data *bd);
 int uniphier_ld4_sbc_init(const struct uniphier_board_data *bd);
 int uniphier_pxs2_sbc_init(const struct uniphier_board_data *bd);
 #else
@@ -53,11 +52,6 @@ static inline int uniphier_sbc_init_savepin(
return 0;
 }
 
-static inline int uniphier_sld3_sbc_init(const struct uniphier_board_data *bd)
-{
-   return 0;
-}
-
 static inline int uniphier_ld4_sbc_init(const struct uniphier_board_data *bd)
 {
return 0;
diff --git a/arch/arm/mach-uniphier/init/init-sld3.c 
b/arch/arm/mach-uniphier/init/init-sld3.c
index 473e0c8..6d9eb67 100644
--- a/arch/arm/mach-uniphier/init/init-sld3.c
+++ b/arch/arm/mach-uniphier/init/init-sld3.c
@@ -16,6 +16,7 @@ int uniphier_sld3_init(const struct uniphier_board_data *bd)
 
uniphier_sbc_init_admulti(bd);
uniphier_sld3_sbc_init(bd);
+   uniphier_sld3_early_pin_init(bd);
 
support_card_reset();
 
@@ -34,8 +35,6 @@ int uniphier_sld3_init(const struct uniphier_board_data *bd)
 
led_puts("L2");
 
-   uniphier_sld3_early_pin_init(bd);
-
led_puts("L3");
 
 #ifdef CONFIG_SPL_SERIAL_SUPPORT
diff --git a/arch/arm/mach-uniphier/sbc/Makefile 
b/arch/arm/mach-uniphier/sbc/Makefile
index 236f136..38da253 100644
--- a/arch/arm/mach-uniphier/sbc/Makefile
+++ b/arch/arm/mach-uniphier/sbc/Makefile
@@ -2,7 +2,7 @@
 # SPDX-License-Identifier: GPL-2.0+
 #
 
-obj-$(CONFIG_ARCH_UNIPHIER_SLD3)   += sbc-admulti.o sbc-sld3.o
+obj-$(CONFIG_ARCH_UNIPHIER_SLD3)   += sbc-admulti.o
 obj-$(CONFIG_ARCH_UNIPHIER_LD4)+= sbc-savepin.o sbc-ld4.o
 obj-$(CONFIG_ARCH_UNIPHIER_PRO4)   += sbc-savepin.o
 obj-$(CONFIG_ARCH_UNIPHIER_SLD8)   += sbc-savepin.o sbc-ld4.o
diff --git a/arch/arm/mach-uniphier/sbc/sbc-sld3.c 
b/arch/arm/mach-uniphier/sbc/sbc-sld3.c
deleted file mode 100644
index ac9d030..000
--- a/arch/arm/mach-uniphier/sbc/sbc-sld3.c
+++ /dev/null
@@ -1,17 +0,0 @@
-/*
- * Copyright (C) 2011-2015 Masahiro Yamada 
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#include 
-
-#include "../init.h"
-#include "../sg-regs.h"
-
-int uniphier_sld3_sbc_init(const struct uniphier_board_data *bd)
-{
-   sg_set_pinsel(99, 1, 4, 4); /* GPIO26 -> EA24 */
-
-   return 0;
-}
-- 
1.9.1

___
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

2016-04-28 Thread Michal Simek
Hi Joe,

On 28.4.2016 06:52, Joe Hershberger wrote:
> 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).

NOTE: A lot of my patches (maybe all of them) were already merged to
mainline via Xilinx tree.

Cheers,
Michal
___
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

2016-04-28 Thread Michal Simek
Hi Masahiro,

On 28.4.2016 07:54, Masahiro Yamada wrote:
> 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.)

That's fine and it is reasonable limitation.



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

TBH: I was expecting that there will be better solution for it.

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

Let me retest and send v2.

Thanks,
Michal

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





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


Re: [U-Boot] [PATCH] i2c: designware_i2c: Optionally check enable status register

2016-04-28 Thread Heiko Schocher

Hello Stefan,

Am 28.04.2016 um 08:10 schrieb Stefan Roese:

Hi Heiko,

On 28.04.2016 08:06, Heiko Schocher wrote:

Am 27.04.2016 um 09:02 schrieb Stefan Roese:

Some platforms don't implement the enable status register at offset 0x9c.
The SPEAr600 platform is one of them. The recently added check to this
status register can't be performend on these platforms.

This patch introduces a new config option that can be enabled on such
platforms not supporting this register.

Signed-off-by: Stefan Roese 
Cc: Heiko Schocher 
---
  drivers/i2c/designware_i2c.c | 9 +
  1 file changed, 9 insertions(+)


No objections, but I miss an entry in drivers/i2c/Kconfig or at least an
entry in README. Please add this, thanks!


Yes, I am aware that this is not available via Kconfig. I hesitate
to add it to the README, as this is a bit outdated. And we should
move to Kconfig anyways.


Yes!


I'll work on a patch to move this driver and this config option to
Kconfig instead.


Ok, thanks for the info, so I am fine with this patch:

Reviewed-by: Heiko Schocher 

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [Patch v2] fsl-layerscape: fdt: add IFC fixup if no IFC is avaliable in U-Boot

2016-04-28 Thread Gong Qianyu
IFC is considered as a required component in Layerscape platforms' Linux.
But if IFC is not enabled in U-Boot on some boards, accessing IFC memory
space would cause kernel call trace. So disable IFC node in such cases.

Signed-off-by: Gong Qianyu 
---
V2:
 - Revised the title and message.
 - Used #ifndef CONFIG_FSL_IFC rather than #ifdef CONFIG_FSL_QSPI.

 arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c 
b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
index 1e875c4..96dab56 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
@@ -98,4 +98,9 @@ void ft_cpu_setup(void *blob, bd_t *bd)
 #ifdef CONFIG_SYS_DPAA_FMAN
fdt_fixup_fman_firmware(blob);
 #endif
+
+#ifndef CONFIG_FSL_IFC
+   do_fixup_by_compat(blob, "fsl,ifc",
+  "status", "disabled", 8 + 1, 1);
+#endif
 }
-- 
2.1.0.27.g96db324

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


Re: [U-Boot] [PATCH 4/4] ARM: socfpga: Disable USB OC protection on SoCrates

2016-04-28 Thread Stefan Roese

On 27.04.2016 15:24, Marek Vasut wrote:

This is mandatory, otherwise the USB does not work.

Signed-off-by: Marek Vasut 
Cc: Stefan Roese 
Cc: Dinh Nguyen 


Tested-by: Stefan Roese 

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


Re: [U-Boot] [PATCH 3/4] usb: dwc2: Make OC protection configurable

2016-04-28 Thread Stefan Roese

On 27.04.2016 15:24, Marek Vasut wrote:

Introduce a new flag in the controller private data, which allows selectively
disabling the OC protection. Use the standard 'disable-over-current' OF prop
to set this flag. This OC protection must be disabled on EBV SoCrates rev 1.

Signed-off-by: Marek Vasut 
Cc: Stefan Roese 
Cc: Dinh Nguyen 


Tested-by: Stefan Roese 

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


[U-Boot] [PATCH] test, tools: update tbot documentation

2016-04-28 Thread Heiko Schocher
update tbot documentation in U-Boot, as I just
merged the event system into tbots master
branch.

Signed-off-by: Heiko Schocher 
---
Infos about tbots event system:
https://github.com/hsdenx/tbot/blob/master/doc/README.event

A demo result webpage of playing with the event system can be
found here:
http://xeidos.ddns.net/tests/test_db_auslesen.php

What is done here:
After tbot finished with the testcase, it calls some event
backends. They for example add some infos into a mysql database
(like which defconfig used for compiling U-Boot, the U-Boot
version string from the resulting binary).
Also a backend creates a statistic image with gnuplot, and
another a "dot" graphics from the Events, called testcases
created ... click on the links on above webpage ;-)

The data in the database can then be displayed with php.
The above link is just a simple html table for demo purpose.
It would be nice to enhance this sometime.

 tools/tbot/README |  10 ++
 tools/tbot/README.install | 246 ++
 2 files changed, 103 insertions(+), 153 deletions(-)

diff --git a/tools/tbot/README b/tools/tbot/README
index a637a63..49b9e95 100644
--- a/tools/tbot/README
+++ b/tools/tbot/README
@@ -92,6 +92,16 @@ 
https://github.com/hsdenx/tbot/blob/master/doc/tbot_structure.png )
 
   It is possible to switch in a single TC between board states.
 
+- Events
+  tbot creates while executing testcases so called events.
+  After tbot ended with the testcase it can call event_backends,
+  which convert the events to different formats. more info:
+
+  https://github.com/hsdenx/tbot/blob/master/doc/README.event
+
+  demo for a event backend:
+  http://xeidos.ddns.net/tests/test_db_auslesen.php
+
 - tbot cmdline parameters:
 
 $ python2.7 src/common/tbot.py --help
diff --git a/tools/tbot/README.install b/tools/tbot/README.install
index 24c67bc..a68e705 100644
--- a/tools/tbot/README.install
+++ b/tools/tbot/README.install
@@ -93,12 +93,6 @@ $
   cp src/tc/tc_lab_denx_connect_to_board.py 
src/tc/tc_lab_denx_connect_to_board_XXX.py
   and adapt the commands to your needs.
 
-  As this TC powers on the board for all your boards in your VL,
-  you can differ between the boards through the tbot class
-  variable "tb.boardlabname" (which is in the default case the
-  same as "tb.boardname"), but you may need to name the power target
-  with an other name than boardname, so you can configure this case.
-
   If connect fails end this TC with "tb.end_tc(False)"
   else call "tb.end_tc(True)"
 
@@ -150,12 +144,6 @@ $
   if (user == 'root'):
   password = ''
 
-  In the above example passwords for logging into the Lab PC tbot finds
-  through:
-  if (board == 'lab'):
- user = 'name':
- password = 'gnlmpf' # password 'gnlmpf' for login of user 'name'
-
 - prepare board config file
   Each board which is found in the VL needs a tbot configuration file
   pass the config file name with the option '-c' to tbot, tbot searches
@@ -187,13 +175,8 @@ $
  keepalive message.
   line 14: channel_timeout: passed to paramiko
   line 15: loglevel: tbots loglevel for adding entries into the logfile.
-  line 16: lap_api: used lap API (currently only 'ssh_std')
- Should be declared as standard -> this line would be not needed
- longer.
   line 17: wdt_timeout: timeout in seconds for tbots watchdog.
  Watchdog gets triggered if prompt get read.
-  line 20,21: include 'ssh_std' api
- should be removed.
   line 24: tc_lab_denx_connect_to_board_tc: Which TC is used for
  connecting to the boards console the TC, here:
  
https://github.com/hsdenx/tbot/blob/master/src/tc/tc_workfd_connect_with_kermit.py
@@ -215,156 +198,113 @@ TC (and hopefully share them), so continue with:
 u-boot:tools/tbot/README.create_a_new_testcase
 
 Heiko Schocher 
-v1 2016.01.22
+v2 2016.04.26
 
 --
 
 [1] tbot Dokumentation:
 [2] u-boot:/tools/tbot/README
 https://github.com/hsdenx/tbot/blob/master/README.md
+tbot-de...@googlegroups.com
 
 [3] Example for a first U-Boot TC which should always work:
 (with commandline option "-v" for verbose output):
-
-hs@localhost:tbot  [master] $ python2.7 src/common/tbot.py -c tbot_dxr2.cfg -t 
tc_ub_setenv.py -v -l log/tbot.log
+hs@localhost:tbot  [event-devel] $ python2.7 src/common/tbot.py -c 
tbot_dxr2.cfg -t tc_ub_setenv.py -v -l log/tbot.log
  option cfg: tbot_dxr2.cfg log: log/tbot.log tc: tc_ub_setenv.py v 1
 ('CUR WORK PATH: ', '/home/hs/data/Entwicklung/tbot')
 ('CFGFILE ', 'tbot_dxr2.cfg')
 ('LOGFILE ', '/home/hs/data/Entwicklung/tbot/log/tbot.log')
-(, , True)
-(, , True)
-read 0: Last login: Fri Jan 22 12:20:12 2016 from 87.97.28.177
-read 0:
-read 0: *
-read 0: BDI2000 Assignment:(last updated:  2015-11-20 12:30 MET)
-read 0: bdi1  => techem 

Re: [U-Boot] [PATCH 2/4] usb: dwc2: Pull Ext VBUS macro from dwc_otg_core_init()

2016-04-28 Thread Stefan Roese

On 27.04.2016 15:24, Marek Vasut wrote:

Introduce a boolean flag in the dwc2 controller private data and set
it according to the macro (for now) instead of having this macro
directly in the dwc_otg_core_init(). This will let us configure the
flag from DT or such later on, if needed.

Signed-off-by: Marek Vasut 
Cc: Stefan Roese 
Cc: Dinh Nguyen 


Tested-by: Stefan Roese 

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


Re: [U-Boot] [PATCH 1/4] usb: dwc2: Pass private data into dwc_otg_core_init()

2016-04-28 Thread Stefan Roese

On 27.04.2016 15:24, Marek Vasut wrote:

Pass the whole bulk of private data instead of just the regs,
since the private data will soon contain important configuration
flags.

Signed-off-by: Marek Vasut 
Cc: Stefan Roese 
Cc: Dinh Nguyen 


Tested-by: Stefan Roese 

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

2016-04-28 Thread Stefan Roese

On 26.04.2016 03:08, 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 


Tested-by: Stefan Roese 

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

2016-04-28 Thread Stefan Roese
On 28.04.2016 01:07, Marek Vasut wrote:
> 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 :)

Okay, here my collection of tests with numerous USB keys on SoCFPGA
(SoCrates). All these tests were made with current mainline U-Boot
and the following patches applied:

http://patchwork.ozlabs.org/patch/614747/

http://patchwork.ozlabs.org/patch/615647/
http://patchwork.ozlabs.org/patch/615650/
http://patchwork.ozlabs.org/patch/615649/
http://patchwork.ozlabs.org/patch/615651/

a) With current mainline (USB scanning enhancement patch included)

and

b) USB scanning enhancement patch reverted (usb: Change power-on /
scanning timeout handling

I've used the following command to test the USB sticks:

dcache off;time usb start;usb tree


1. Kingston DataTraveler 2.0 (64GiB):
-
a)
starting USB...
USB0:   Core Release: 2.93a
scanning bus 0 for devices... Device NOT ready
   Request Sense returned 00 00 00
2 USB Device(s) found

time: 2 minutes, 1.880 seconds
USB device tree:
  1  Hub (480 Mb/s, 0mA)
  |   U-Boot Root Hub
  |
  +-2  Mass Storage (480 Mb/s, 200mA)
   Kingston DataTraveler 2.0 50E549C688C4BE7189942766


b)
starting USB...
USB0:   Core Release: 2.93a
scanning bus 0 for devices... Device NOT ready
   Request Sense returned 00 00 00
2 USB Device(s) found

time: 2 minutes, 2.784 seconds
USB device tree:
  1  Hub (480 Mb/s, 0mA)
  |   U-Boot Root Hub
  |
  +-2  Mass Storage (480 Mb/s, 200mA)
   Kingston DataTraveler 2.0 50E549C688C4BE7189942766


2. "Paradise" (USBest Technology USB Mass Storage Device) 4GiB:
---
a)
starting USB...
USB0:   Core Release: 2.93a
scanning bus 0 for devices... 2 USB Device(s) found

time: 0.936 seconds
USB device tree:
  1  Hub (480 Mb/s, 0mA)
  |   U-Boot Root Hub
  |
  +-2  Mass Storage (480 Mb/s, 98mA)
   USBest Technology USB Mass Storage Device 09092207fbf0c4

b)
starting USB...
USB0:   Core Release: 2.93a
scanning bus 0 for devices... 2 USB Device(s) found

time: 1.571 seconds
USB device tree:
  1  Hub (480 Mb/s, 0mA)
  |   U-Boot Root Hub
  |
  +-2  Mass Storage (480 Mb/s, 98mA)
   USBest Technology USB Mass Storage Device 09092207fbf0c4


3. Intenso Alu Line 16GiB:

Re: [U-Boot] [PATCH] i2c: designware_i2c: Optionally check enable status register

2016-04-28 Thread Stefan Roese

Hi Heiko,

On 28.04.2016 08:06, Heiko Schocher wrote:

Am 27.04.2016 um 09:02 schrieb Stefan Roese:

Some platforms don't implement the enable status register at offset 0x9c.
The SPEAr600 platform is one of them. The recently added check to this
status register can't be performend on these platforms.

This patch introduces a new config option that can be enabled on such
platforms not supporting this register.

Signed-off-by: Stefan Roese 
Cc: Heiko Schocher 
---
  drivers/i2c/designware_i2c.c | 9 +
  1 file changed, 9 insertions(+)


No objections, but I miss an entry in drivers/i2c/Kconfig or at least an
entry in README. Please add this, thanks!


Yes, I am aware that this is not available via Kconfig. I hesitate
to add it to the README, as this is a bit outdated. And we should
move to Kconfig anyways.

I'll work on a patch to move this driver and this config option to
Kconfig instead.

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


[U-Boot] [PATCH] mmc: sdhci: increase default timeout and make it configurable

2016-04-28 Thread Masahiro Yamada
I found the current timeout is too short for some devices to execute
erase command.  Nor can we override CONFIG_SDHCI_CMD_DEFAULT_TIMEOUT
from a board config.

Increase the default timeout and surround the define with "ifndef"
to allow to override it in case the default value is not a good fit.

Signed-off-by: Masahiro Yamada 
---

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

diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index ef7e615..7670d73 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -126,7 +126,9 @@ static int sdhci_transfer_data(struct sdhci_host *host, 
struct mmc_data *data,
 #ifndef CONFIG_SDHCI_CMD_MAX_TIMEOUT
 #define CONFIG_SDHCI_CMD_MAX_TIMEOUT   3200
 #endif
-#define CONFIG_SDHCI_CMD_DEFAULT_TIMEOUT   100
+#ifndef CONFIG_SDHCI_CMD_DEFAULT_TIMEOUT
+#define CONFIG_SDHCI_CMD_DEFAULT_TIMEOUT   1000
+#endif
 
 static int sdhci_send_command(struct mmc *mmc, struct mmc_cmd *cmd,
   struct mmc_data *data)
-- 
1.9.1

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


Re: [U-Boot] [PATCH] i2c: designware_i2c: Optionally check enable status register

2016-04-28 Thread Heiko Schocher

Hello Stefan,

Am 27.04.2016 um 09:02 schrieb Stefan Roese:

Some platforms don't implement the enable status register at offset 0x9c.
The SPEAr600 platform is one of them. The recently added check to this
status register can't be performend on these platforms.

This patch introduces a new config option that can be enabled on such
platforms not supporting this register.

Signed-off-by: Stefan Roese 
Cc: Heiko Schocher 
---
  drivers/i2c/designware_i2c.c | 9 +
  1 file changed, 9 insertions(+)


No objections, but I miss an entry in drivers/i2c/Kconfig or at least an
entry in README. Please add this, thanks!

bye,
Heiko


diff --git a/drivers/i2c/designware_i2c.c b/drivers/i2c/designware_i2c.c
index 0c7cd0b..e60fd0a 100644
--- a/drivers/i2c/designware_i2c.c
+++ b/drivers/i2c/designware_i2c.c
@@ -36,6 +36,14 @@ struct dw_i2c {
struct dw_scl_sda_cfg *scl_sda_cfg;
  };

+#ifdef CONFIG_SYS_I2C_DW_ENABLE_STATUS_UNSUPPORTED
+static void dw_i2c_enable(struct i2c_regs *i2c_base, bool enable)
+{
+   u32 ena = enable ? IC_ENABLE_0B : 0;
+
+   writel(ena, _base->ic_enable);
+}
+#else
  static void dw_i2c_enable(struct i2c_regs *i2c_base, bool enable)
  {
u32 ena = enable ? IC_ENABLE_0B : 0;
@@ -56,6 +64,7 @@ static void dw_i2c_enable(struct i2c_regs *i2c_base, bool 
enable)

printf("timeout in %sabling I2C adapter\n", enable ? "en" : "dis");
  }
+#endif

  /*
   * i2c_set_bus_speed - Set the i2c speed



--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] register polling from HUSH parser?

2016-04-28 Thread Masahiro Yamada
Hi Wolfgang,

2016-04-27 18:46 GMT+09:00 Wolfgang Denk :
> Dear Masahiro,
>
> In message 
>  you 
> wrote:
>>
>> Is there any good way to poll a certain register
>> in a HUSH parser script?
>
> Yes, there is :-)
>
>> For example, I want to wait
>> until the register value of 0x5000 becomes 1
>> in a HUSH script.
>
> OK...
>
>> The pseudo code would be like this:
>>
>> while   readl(0x5000) != 1
>> do
>>;
>> done;
>
> And in HUSH:
>
> while itest *5000 != 1
> do
> ...
> done
>
>> I wish there were a command that
>> stores a value of a given address into an environment,
>> but I have no idea about that.
>
> Try "help setexpr".  If you want to store the value as is, just apply
> a null operation, like
>
> => setexp foo *5000 | 0
> => printenv foo
>
>
> Hope this helps...


Yes, it really helped me.
Thank you!


I think itest.l works as expected on 32bit architecture,
but the problem is that sizeof(unsigned long) is 8
on 64bit architecture.

So, "case 4" in the following gets 8-byte data.
This is probably not what we expect...

  switch (w) {
  case 1:
 l = (long)(*(unsigned char *)buf);
 break;
  case 2:
 l = (long)(*(unsigned short *)buf);
 break;
  case 4:
 l = (long)(*(unsigned long *)buf);
 break;
  }




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