[U-Boot] [PATCH v2 2/2] mtd: nand: atmel: use another functions to set gpio value

2017-03-02 Thread Wenyou Yang
Because there isn't the implementation of gpio_set/get_value()
and gpio_set/get_value() after the at91 gpio driver is converted
to support the driver model, use at91_set_gpio_value() and
at91_get_gpio_value()

Signed-off-by: Wenyou Yang 
Reviewed-by: Simon Glass 
---

Changes in v2:
 - Add Reviewed-by tag.

 drivers/mtd/nand/atmel_nand.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index 8669432deb..21d5d0e70d 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -1222,7 +1222,8 @@ static void at91_nand_hwcontrol(struct mtd_info *mtd,
IO_ADDR_W |= CONFIG_SYS_NAND_MASK_ALE;
 
 #ifdef CONFIG_SYS_NAND_ENABLE_PIN
-   gpio_set_value(CONFIG_SYS_NAND_ENABLE_PIN, !(ctrl & NAND_NCE));
+   at91_set_gpio_value(CONFIG_SYS_NAND_ENABLE_PIN,
+   !(ctrl & NAND_NCE));
 #endif
this->IO_ADDR_W = (void *) IO_ADDR_W;
}
@@ -1234,7 +1235,7 @@ static void at91_nand_hwcontrol(struct mtd_info *mtd,
 #ifdef CONFIG_SYS_NAND_READY_PIN
 static int at91_nand_ready(struct mtd_info *mtd)
 {
-   return gpio_get_value(CONFIG_SYS_NAND_READY_PIN);
+   return at91_get_gpio_value(CONFIG_SYS_NAND_READY_PIN);
 }
 #endif
 
-- 
2.11.0

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


[U-Boot] [PATCH v2 1/2] ARM: at91: gpio: fix at91_set_gpio_value() define

2017-03-02 Thread Wenyou Yang
When the CONFIG_ATMEL_LEGACY is undefined, according to the following
defines, at91_set_gpio_value() references to at91_set_pio_value(x, y)
with two parameters.
 #define at91_set_gpio_value(x, y)  at91_set_pio_value(x, y)
 #define at91_get_gpio_value(x) at91_get_pio_value(x)

But there isn't the implementation of at91_set_pio_value(x, y) with
two parameters in U-Boot. This is an error.

Same as at91_get_gpio_value(x) define.

Signed-off-by: Wenyou Yang 
---

Changes in v2:
 - Improve the commit log.

 arch/arm/mach-at91/include/mach/gpio.h | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-at91/include/mach/gpio.h 
b/arch/arm/mach-at91/include/mach/gpio.h
index 5a32bdba8d..df0f71975a 100644
--- a/arch/arm/mach-at91/include/mach/gpio.h
+++ b/arch/arm/mach-at91/include/mach/gpio.h
@@ -223,15 +223,13 @@ static inline unsigned pin_to_mask(unsigned pin)
at91_set_pio_output((x - PIN_BASE) / 32,(x % 32), y)
 #define at91_set_gpio_input(x, y) \
at91_set_pio_input((x - PIN_BASE) / 32,(x % 32), y)
-#define at91_set_gpio_value(x, y) \
-   at91_set_pio_value((x - PIN_BASE) / 32,(x % 32), y)
-#define at91_get_gpio_value(x) \
-   at91_get_pio_value((x - PIN_BASE) / 32,(x % 32))
-#else
-#define at91_set_gpio_value(x, y)  at91_set_pio_value(x, y)
-#define at91_get_gpio_value(x) at91_get_pio_value(x)
 #endif
 
+#define at91_set_gpio_value(x, y) \
+   at91_set_pio_value((x / 32), (x % 32), y)
+#define at91_get_gpio_value(x) \
+   at91_get_pio_value((x / 32), (x % 32))
+
 #define GPIO_PIOA_BASE  (0)
 #define GPIO_PIOB_BASE  (GPIO_PIOA_BASE + 32)
 #define GPIO_PIOC_BASE  (GPIO_PIOB_BASE + 32)
-- 
2.11.0

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


[U-Boot] [PATCH v2 0/2] mtd: nand: atmel: use another functions to set gpio value

2017-03-02 Thread Wenyou Yang
The purpose of the patch set is to use another functions to set
and get the gpio value for the atmel nand driver to fix the error
to set and get the gpio value after the at91 gpio driver conversion
to support the driver model.

Changes in v2:
 - Improve the commit log.
 - Add Reviewed-by tag.

Wenyou Yang (2):
  ARM: at91: gpio: fix at91_set_gpio_value() define
  mtd: nand: atmel: use another functions to set gpio value

 arch/arm/mach-at91/include/mach/gpio.h | 12 +---
 drivers/mtd/nand/atmel_nand.c  |  5 +++--
 2 files changed, 8 insertions(+), 9 deletions(-)

-- 
2.11.0

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


Re: [U-Boot] [U-boot] Question about bootp structure pack

2017-03-02 Thread Eric BOUXIROT
Hi Lukasz,

>> I’m using u-boot-2015.07 in one of my project based on vpac270 soc
>> module.
>>
>> u-boot is well configured and build is fine without error.
>>
>> Gcc is v3.4.5 and glibc v2.3.6 built by crosstool 0.43 for
>> arm-softfloat-linux-gnu
>
> Could you try to use newer gcc and see if bootp is working as expected?
>
>

ok, i will test this, but i think the "normal" build is to NOT pack
theses structs..
and it would be "normal" to get theses alignment gaps inside frame ...

i haven't found in Makefile any options to pack the structs.

have you an explanation about this?? may i miss something in the build
process of uboot...

will let you know soon about testing with another compiler. (have
gcc4.9-linaro toolchain too)

thank !
Eric BOUXIROT
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [RFC PATCH 3/3] arm: bootm: Add dm_pre_os_remove() call to announce_and_cleanup()

2017-03-02 Thread Stefan Roese

Hi Simon,

On 03.03.2017 05:53, Simon Glass wrote:

On 1 March 2017 at 03:23, Stefan Roese  wrote:

This patch adds a call to dm_pre_os_remove() to announce_and_cleanup()
so that drivers that have the flag DM_FLAG_PRE_OS_REMOVE set may do
some last-stage cleanup before the OS is started.

Signed-off-by: Stefan Roese 
Cc: Simon Glass 
---
 arch/arm/lib/bootm.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index 8125cf023f..84f3415c1e 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -91,6 +91,14 @@ static void announce_and_cleanup(int fake)

board_quiesce_devices();

+   /*
+* Call remove function of all devices with the pre-OS remove flag
+* set (DM_FLAG_PRE_OS_REMOVE). This may be useful for last-stage
+* operations, like cancelling of DMA operation or releasing device
+* internal buffers.
+*/
+   dm_pre_os_remove();


In a full DM world we could perhaps have devices which use the DMA
uclass, so we can tell which ones need to be removed.

How about dm_remove_dma_devices()?


I'm not so sure. As we would perhaps need to add other calls for
further pre-OS removal reasons (e.g. the stop timer example). How
about calling a function with the removal flags as parameter:

dm_remove_devices_conditional(ONLY_REMOVE_ACTIVE_DMA | ...);

or

dm_remove_devices_flags(ONLY_REMOVE_ACTIVE_DMA | ...);

What do you think?


+
cleanup_before_linux();
 }

--
2.12.0



Also (once we have things figured out) this needs some sort of test in test/.


I already feared that. ;)

Sure, I'll try to add some test, once the path is clear.

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


[U-Boot] [PATCH v2 2/2] clk: at91: align clk-master's compatibles with kernel's

2017-03-02 Thread Wenyou Yang
Add the compatible "atmel,at91rm9200-clk-master" to align with
the kernel's.

Signed-off-by: Wenyou Yang 
Reviewed-by: Simon Glass 
---

Changes in v2:
 - Add the Reviewed-by tags.

 drivers/clk/at91/clk-master.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/at91/clk-master.c b/drivers/clk/at91/clk-master.c
index 284b248271..72d0a739f1 100644
--- a/drivers/clk/at91/clk-master.c
+++ b/drivers/clk/at91/clk-master.c
@@ -21,6 +21,7 @@ static struct clk_ops at91_master_clk_ops = {
 };
 
 static const struct udevice_id at91_master_clk_match[] = {
+   { .compatible = "atmel,at91rm9200-clk-master" },
{ .compatible = "atmel,at91sam9x5-clk-master" },
{}
 };
-- 
2.11.0

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


Re: [U-Boot] [RFC PATCH 2/3] dm: core: Add dm_pre_os_remove() and hook it into device_remove()

2017-03-02 Thread Stefan Roese

Hi Simon,

On 03.03.2017 05:53, Simon Glass wrote:

On 1 March 2017 at 03:23, Stefan Roese  wrote:

The new function dm_pre_os_remove() is intented for driver specific
last-stage cleanup operations before the OS is started. This patch adds
this functionality and hooks it into the common device_remove()
function.

To enable usage for custom driver (e.g. ethernet drivers), this patch
also sets the pre-OS remove flag for the root driver and simple-bus
drivers. Otherwise the recursive call starting from the root device
would not reach the drivers in need for this specific remove call.

Signed-off-by: Stefan Roese 
Cc: Simon Glass 
---
 drivers/core/device-remove.c | 7 +++
 drivers/core/root.c  | 8 
 drivers/core/simple-bus.c| 1 +
 include/dm/root.h| 9 +
 4 files changed, 25 insertions(+)

diff --git a/drivers/core/device-remove.c b/drivers/core/device-remove.c
index 4725d4751c..0dfb20cdce 100644
--- a/drivers/core/device-remove.c
+++ b/drivers/core/device-remove.c
@@ -166,6 +166,13 @@ int device_remove(struct udevice *dev, bool pre_os_remove)
drv = dev->driver;
assert(drv);

+   /*
+* If pre-OS remove is requested, only continue for drivers with this
+* flag set
+*/
+   if (pre_os_remove && !(drv->flags & DM_FLAG_PRE_OS_REMOVE))
+   return 0;
+


This doesn't seem good to me. I think it should scan the whole tree,
and process devices with the flag set. That way you don't need the
root node to have the flag.


Yes, thats better, I agree.


If a device has DMA, it will be removed. But its parent may not, in
which case the parent will not be removed. However any children of the
device will need to be removed, even if they don't have DMA, because
we cannot have active children of an inactive device. Does that make
sense?


Yes. I'll change this in the next patchset version accordingly.

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


[U-Boot] [PATCH v2 1/2] clk: at91: enhance the peripheral clock

2017-03-02 Thread Wenyou Yang
Enhance the peripheral clock to support both at9sam9x5's
and at91rm9200's peripheral clock via the different compatibles.

Signed-off-by: Wenyou Yang 
Reviewed-by: Simon Glass 
---

Changes in v2:
 - Use an enum with a descriptive name to denote the clock type.

 drivers/clk/at91/clk-peripheral.c | 29 ++---
 1 file changed, 26 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/at91/clk-peripheral.c 
b/drivers/clk/at91/clk-peripheral.c
index e1ed447133..62fabe304d 100644
--- a/drivers/clk/at91/clk-peripheral.c
+++ b/drivers/clk/at91/clk-peripheral.c
@@ -16,6 +16,10 @@
 #define PERIPHERAL_ID_MAX  31
 #define PERIPHERAL_MASK(id)(1 << ((id) & PERIPHERAL_ID_MAX))
 
+enum periph_clk_type {
+   CLK_PERIPH_AT91RM9200 = 0,
+   CLK_PERIPH_AT91SAM9X5,
+};
 /**
  * sam9x5_periph_clk_bind() - for the periph clock driver
  * Recursively bind its children as clk devices.
@@ -28,7 +32,14 @@ static int sam9x5_periph_clk_bind(struct udevice *dev)
 }
 
 static const struct udevice_id sam9x5_periph_clk_match[] = {
-   { .compatible = "atmel,at91sam9x5-clk-peripheral" },
+   {
+   .compatible = "atmel,at91rm9200-clk-peripheral",
+   .data = CLK_PERIPH_AT91RM9200,
+   },
+   {
+   .compatible = "atmel,at91sam9x5-clk-peripheral",
+   .data = CLK_PERIPH_AT91SAM9X5,
+   },
{}
 };
 
@@ -45,12 +56,24 @@ static int periph_clk_enable(struct clk *clk)
 {
struct pmc_platdata *plat = dev_get_platdata(clk->dev);
struct at91_pmc *pmc = plat->reg_base;
+   enum periph_clk_type clk_type;
+   void *addr;
 
if (clk->id < PERIPHERAL_ID_MIN)
return -1;
 
-   writel(clk->id & AT91_PMC_PCR_PID_MASK, &pmc->pcr);
-   setbits_le32(&pmc->pcr, AT91_PMC_PCR_CMD_WRITE | AT91_PMC_PCR_EN);
+   clk_type = dev_get_driver_data(dev_get_parent(clk->dev));
+   if (clk_type == CLK_PERIPH_AT91RM9200) {
+   addr = &pmc->pcer;
+   if (clk->id > PERIPHERAL_ID_MAX)
+   addr = &pmc->pcer1;
+
+   setbits_le32(addr, PERIPHERAL_MASK(clk->id));
+   } else {
+   writel(clk->id & AT91_PMC_PCR_PID_MASK, &pmc->pcr);
+   setbits_le32(&pmc->pcr,
+AT91_PMC_PCR_CMD_WRITE | AT91_PMC_PCR_EN);
+   }
 
return 0;
 }
-- 
2.11.0

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


[U-Boot] [PATCH v2 0/2] clk: at91: enhance the peripheral clock

2017-03-02 Thread Wenyou Yang
The purpose of the patch set is to enhance the peripheral clock
to support both at9sam9x5's and at91rm9200's peripheral clock,
and align the clk-master's compatibles with kernel's.

Changes in v2:
 - Use an enum with a descriptive name to denote the clock type.
 - Add the Reviewed-by tags.

Wenyou Yang (2):
  clk: at91: enhance the peripheral clock
  clk: at91: align clk-master's compatibles with kernel's

 drivers/clk/at91/clk-master.c |  1 +
 drivers/clk/at91/clk-peripheral.c | 29 ++---
 2 files changed, 27 insertions(+), 3 deletions(-)

-- 
2.11.0

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


Re: [U-Boot] [RFC PATCH 1/3] dm: core: Add pre-OS remove flag to device_remove()

2017-03-02 Thread Stefan Roese
Hi Simon,

On 03.03.2017 05:53, Simon Glass wrote:
> On 1 March 2017 at 03:23, Stefan Roese  wrote:
>> This patch adds the pre_os_remove boolean flag to device_remove() and
>> changes all calls to this function to provide the default value of
>> "false". This is in preparation for the driver specific pre-OS remove
>> support.
>>
>> Signed-off-by: Stefan Roese 
>> Cc: Simon Glass 
>> ---
>>  arch/x86/cpu/queensbay/tnc.c   |  4 ++--
>>  cmd/cros_ec.c  |  2 +-
>>  cmd/sf.c   |  2 +-
>>  drivers/block/blk-uclass.c |  2 +-
>>  drivers/block/sandbox.c|  2 +-
>>  drivers/core/device-remove.c   |  9 +
>>  drivers/core/device.c  |  2 +-
>>  drivers/core/root.c|  2 +-
>>  drivers/core/uclass.c  |  2 +-
>>  drivers/mmc/mmc-uclass.c   |  2 +-
>>  drivers/mtd/spi/sandbox.c  |  2 +-
>>  drivers/mtd/spi/sf-uclass.c|  2 +-
>>  drivers/spi/spi-uclass.c   |  4 ++--
>>  drivers/usb/emul/sandbox_hub.c |  2 +-
>>  drivers/usb/host/usb-uclass.c  |  4 ++--
>>  include/dm/device-internal.h   |  5 +++--
>>  include/dm/device.h|  3 +++
>>  test/dm/bus.c  |  8 
>>  test/dm/core.c | 16 
>>  test/dm/eth.c  |  2 +-
>>  test/dm/spi.c  |  2 +-
>>  21 files changed, 42 insertions(+), 37 deletions(-)
> 
> I think adding a parameter to device_remove() makes sense, but how
> about using flags instead? The true/false meaning is not clear here
> and your comment in device.h doesn't really help.

So you are suggesting something like this:

int device_remove(struct udevice *dev, uin32_t remove_flags);

?
 
> Also I think it is better to name it after the required function
> rather than state related to the caller. IOW instead of 'pre-os' use
> something like 'active_dma_only' or as a flag ONLY_REMOVE_ACTIVE_DMA.
> 
> Do you think the presence of DMA should be a device flag?

The usage of flags instead of this pre-os parameter could make
sense to me, as its much more flexible. But I'm not so sure about
the flag (re-)naming to something specific like DMA. As there
could be multiple reasons other than DMA related for this last-stage
driver cleanup / configuration before the OS is started. E.g.
if a driver needs to stop an internal timer before the OS is started,
it would need to "abuse" this DMA flag to get called at the last
pre-OS stage. Or is your thinking that in such cases (e.g. stopping
of timer) a new flag should get introduced and added to this
"remove_flags" parameter in bootm?

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


Re: [U-Boot] [PATCH v3] serial: Add serial driver for Intel MID

2017-03-02 Thread Simon Glass
On 28 February 2017 at 05:04, Andy Shevchenko
 wrote:
> Add a specific serial driver for Intel MID platforms.
>
> It has special fractional divider which can be programmed via UART_PS,
> UART_MUL, and UART_DIV registers.
>
> The UART clock is calculated as
>
> UART clock = XTAL * UART_MUL / UART_DIV
>
> The baudrate is calculated as
>
> baud rate = UART clock / UART_PS / DLAB
>
> Initialize fractional divider correctly for Intel Edison platform.
>
> For backward compatibility we have to set initial DLAB value to 16
> and speed to 115200 baud, where initial frequency is 29491200Hz, and
> XTAL frequency is 38.4MHz.
>
> Signed-off-by: Andy Shevchenko 
> ---
>  drivers/serial/Kconfig|  9 +
>  drivers/serial/Makefile   |  1 +
>  drivers/serial/serial_intel_mid.c | 69 
> +++
>  3 files changed, 79 insertions(+)
>  create mode 100644 drivers/serial/serial_intel_mid.c

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


Re: [U-Boot] [PATCH 03/17] SPL: FIT: rework U-Boot image loading

2017-03-02 Thread Simon Glass
On 28 February 2017 at 19:25, Andre Przywara  wrote:
> Currently the SPL FIT loader always looks only for the first image in
> the /images node a FIT tree, which it loads and later executes.
>
> Generalize this by looking for a "firmware" property in the matched
> configuration subnode, or, if that does not exist, for the first string
> in the "loadables" property. Then using the string in that property,
> load the image of that name from the /images node.
> This still loads only one image at the moment, but refactors the code to
> allow extending this in a following patch.
> To simplify later re-usage, we also generalize the spl_fit_select_index()
> function to not return the image location, but just the node offset.
>
> Signed-off-by: Andre Przywara 
> ---
>  common/spl/spl_fit.c | 34 --
>  1 file changed, 20 insertions(+), 14 deletions(-)

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


Re: [U-Boot] [RESEND PATCH 8/9] defconfig: k2e_hs_evm: Add k2e_hs_evm_defconfig

2017-03-02 Thread Simon Glass
On 28 February 2017 at 10:58, Tom Rini  wrote:
> On Tue, Feb 28, 2017 at 11:47:01AM -0600, Andrew F. Davis wrote:
>> On 02/27/2017 09:19 AM, Tom Rini wrote:
>> > On Fri, Feb 24, 2017 at 06:59:45AM -0600, Andrew F. Davis wrote:
>> >
>> >> From: Vitaly Andrianov 
>> >>
>> >> TI K2E secure devices have to be built with TI_SECURE_DEVICE, FIT, and
>> >> FIT_IMAGE_POST_PROCESS enabled. Add a dedicated defconfig for this.
>> >>
>> >> Signed-off-by: Vitaly Andrianov 
>> >> Signed-off-by: Madan Srinivas 
>> >> Signed-off-by: Andrew F. Davis 
>> >> ---
>> >>  configs/k2e_hs_evm_defconfig | 51 
>> >> 
>> >>  1 file changed, 51 insertions(+)
>> >>  create mode 100644 configs/k2e_hs_evm_defconfig
>> >>
>> >> diff --git a/configs/k2e_hs_evm_defconfig b/configs/k2e_hs_evm_defconfig
>> >> new file mode 100644
>> >> index 00..d515cedaca
>> >> --- /dev/null
>> >> +++ b/configs/k2e_hs_evm_defconfig
>> >> @@ -0,0 +1,51 @@
>> >> +CONFIG_ARM=y
>> >> +CONFIG_ARCH_KEYSTONE=y
>> >> +CONFIG_SYS_TEXT_BASE=0x0c60
>> >> +CONFIG_TARGET_K2E_EVM=y
>> >> +CONFIG_TI_SECURE_DEVICE=y
>> >> +CONFIG_DEFAULT_DEVICE_TREE="keystone-k2e-evm"
>> >> +CONFIG_FIT=y
>> >> +CONFIG_FIT_IMAGE_POST_PROCESS=y
>> >> +CONFIG_OF_BOARD_SETUP=y
>> >> +CONFIG_SYS_CONSOLE_INFO_QUIET=y
>> >> +CONFIG_VERSION_VARIABLE=y
>> >> +CONFIG_HUSH_PARSER=y
>> >> +CONFIG_SYS_PROMPT="K2E HS EVM # "
>> >> +CONFIG_CMD_BOOTZ=y
>> >> +# CONFIG_CMD_IMLS is not set
>> >> +CONFIG_CMD_ASKENV=y
>> >> +# CONFIG_CMD_FLASH is not set
>> >> +CONFIG_CMD_NAND=y
>> >> +CONFIG_CMD_PART=y
>> >> +CONFIG_CMD_SF=y
>> >> +CONFIG_CMD_SPI=y
>> >> +CONFIG_CMD_I2C=y
>> >> +CONFIG_CMD_USB=y
>> >> +# CONFIG_CMD_SETEXPR is not set
>> >> +CONFIG_CMD_DHCP=y
>> >> +CONFIG_CMD_MII=y
>> >> +CONFIG_CMD_PING=y
>> >> +CONFIG_CMD_EXT2=y
>> >> +CONFIG_CMD_EXT4=y
>> >> +CONFIG_CMD_EXT4_WRITE=y
>> >> +CONFIG_CMD_FAT=y
>> >> +CONFIG_CMD_FS_GENERIC=y
>> >> +CONFIG_CMD_UBI=y
>> >> +CONFIG_ISO_PARTITION=y
>> >> +CONFIG_EFI_PARTITION=y
>> >> +CONFIG_OF_CONTROL=y
>> >> +CONFIG_NET_RANDOM_ETHADDR=y
>> >> +CONFIG_DM=y
>> >> +CONFIG_TI_AEMIF=y
>> >> +# CONFIG_MMC is not set
>> >> +CONFIG_DM_SPI_FLASH=y
>> >> +CONFIG_SPI_FLASH=y
>> >> +CONFIG_SPI_FLASH_STMICRO=y
>> >> +CONFIG_DM_ETH=y
>> >> +CONFIG_DM_SERIAL=y
>> >> +CONFIG_SYS_NS16550=y
>> >> +CONFIG_DM_SPI=y
>> >> +CONFIG_USB=y
>> >> +CONFIG_USB_XHCI_HCD=y
>> >> +CONFIG_USB_XHCI_DWC3=y
>> >> +CONFIG_USB_STORAGE=y
>> >
>> > This shows a number of the will-be-problems like the AM43/AM33 devices
>> > have.  More things need to be select'd and imply'd so that the _hs_
>> > variant defconfigs do not get out of sync easily and often.
>> >
>>
>> I do not think selecting all these options in Kconfig files is safe
>> right now, at least until moving some more symbols to Kconfig is
>> complete. After that we can add proper dependencies to all the symbols
>> and some things like _CMD_ symbols could be added automatically.
>>
>> Defconfigs are easier to cleanup than Kconfig definitions. I do not want
>> to maintain the per-platform Kconfig select'd list before we get symbol
>> dependencies worked out.
>
> Well, at the end of the day, the pain is on you on re-syncing the
> defconfig files, so if you want to wait on adding more logic, OK, I'll
> remove my objection.

OK

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


Re: [U-Boot] [PATCH v3 01/11] armv8: Add global variable resv_ram

2017-03-02 Thread Simon Glass
Hi York,

On 1 March 2017 at 12:32, York Sun  wrote:
> Use gd->arch.resv_ram to track reserved memory allocation.
>
> Signed-off-by: York Sun 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 6 ++
>  arch/arm/include/asm/global_data.h| 3 +++
>  cmd/bdinfo.c  | 4 
>  3 files changed, 13 insertions(+)
>
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig 
> b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> index adccdf1..a40556f 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> @@ -273,6 +273,12 @@ config SYS_FSL_SDHC_CLK_DIV
>   clock, in another word SDHC_clk = Platform_clk / this_divider.
>  endmenu
>
> +config RESV_RAM_TOP
> +   bool
> +   help
> + Reserve memory from the top, tracked by gd->arch.resv_ram. It's up
> + to implementation to allow access to this reserved memory or not.

This is not sufficiently descriptive IMO. What is it used for? What do
you mean by 'from the top'? What is the top?

> +
>  config SYS_FSL_ERRATUM_A008336
> bool
>
> diff --git a/arch/arm/include/asm/global_data.h 
> b/arch/arm/include/asm/global_data.h
> index aee87cd..b1fc410 100644
> --- a/arch/arm/include/asm/global_data.h
> +++ b/arch/arm/include/asm/global_data.h
> @@ -59,6 +59,9 @@ struct arch_global_data {
> phys_addr_t secure_ram;
> unsigned long tlb_allocated;
>  #endif
> +#ifdef CONFIG_RESV_RAM_TOP
> +   phys_addr_t resv_ram;

Please add a comment here explaining what it is for, or referencing something.

> +#endif
>
>  #ifdef CONFIG_ARCH_OMAP2
> u32 omap_boot_device;
> diff --git a/cmd/bdinfo.c b/cmd/bdinfo.c
> index ae3027a..0c5fa56 100644
> --- a/cmd/bdinfo.c
> +++ b/cmd/bdinfo.c
> @@ -392,6 +392,10 @@ static int do_bdinfo(cmd_tbl_t *cmdtp, int flag, int 
> argc,
>   gd->arch.secure_ram & MEM_RESERVE_SECURE_ADDR_MASK);
> }
>  #endif
> +#ifdef CONFIG_RESV_RAM_TOP
> +   if (gd->arch.resv_ram)
> +   print_num("Reserved ram", gd->arch.resv_ram);
> +#endif
>  #if defined(CONFIG_CMD_NET) && !defined(CONFIG_DM_ETH)
> print_eths();
>  #endif
> --
> 2.7.4
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 2/2] mtd: nand: atmel: change another functions to set/get gpio value

2017-03-02 Thread Wenyou.Yang
Hi Simon,

> -Original Message-
> From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
> Sent: 2017年3月3日 12:52
> To: Wenyou Yang - A41535 
> Cc: U-Boot Mailing List ; Andreas Bießmann
> ; Scott Wood ; Wenyou
> Yang - A41535 
> Subject: Re: [PATCH 2/2] mtd: nand: atmel: change another functions to set/get
> gpio value
> 
> On 22 February 2017 at 03:07, Wenyou Yang  wrote:
> > Because there is no implementation of gpio_set/get_value() function
> > after the at91 gpio driver is converted to support DM, use
> > at91_set/get_gpio_value().
> >
> > Signed-off-by: Wenyou Yang 
> > ---
> >
> >  drivers/mtd/nand/atmel_nand.c | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> Reviewed-by: Simon Glass 
> 
> At some point this should change to use driver model, right?

Yes, after the NAND uclass Implementation patches are accepted by main-line,  
Atmel nand driver will be converted to support driver model.


Best Regards,
Wenyou Yang
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [RFC PATCH 1/3] dm: core: Add pre-OS remove flag to device_remove()

2017-03-02 Thread Simon Glass
Hi Stefan,

On 1 March 2017 at 03:23, Stefan Roese  wrote:
> This patch adds the pre_os_remove boolean flag to device_remove() and
> changes all calls to this function to provide the default value of
> "false". This is in preparation for the driver specific pre-OS remove
> support.
>
> Signed-off-by: Stefan Roese 
> Cc: Simon Glass 
> ---
>  arch/x86/cpu/queensbay/tnc.c   |  4 ++--
>  cmd/cros_ec.c  |  2 +-
>  cmd/sf.c   |  2 +-
>  drivers/block/blk-uclass.c |  2 +-
>  drivers/block/sandbox.c|  2 +-
>  drivers/core/device-remove.c   |  9 +
>  drivers/core/device.c  |  2 +-
>  drivers/core/root.c|  2 +-
>  drivers/core/uclass.c  |  2 +-
>  drivers/mmc/mmc-uclass.c   |  2 +-
>  drivers/mtd/spi/sandbox.c  |  2 +-
>  drivers/mtd/spi/sf-uclass.c|  2 +-
>  drivers/spi/spi-uclass.c   |  4 ++--
>  drivers/usb/emul/sandbox_hub.c |  2 +-
>  drivers/usb/host/usb-uclass.c  |  4 ++--
>  include/dm/device-internal.h   |  5 +++--
>  include/dm/device.h|  3 +++
>  test/dm/bus.c  |  8 
>  test/dm/core.c | 16 
>  test/dm/eth.c  |  2 +-
>  test/dm/spi.c  |  2 +-
>  21 files changed, 42 insertions(+), 37 deletions(-)

I think adding a parameter to device_remove() makes sense, but how
about using flags instead? The true/false meaning is not clear here
and your comment in device.h doesn't really help.

Also I think it is better to name it after the required function
rather than state related to the caller. IOW instead of 'pre-os' use
something like 'active_dma_only' or as a flag ONLY_REMOVE_ACTIVE_DMA.

Do you think the presence of DMA should be a device flag?

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


Re: [U-Boot] [PATCH 2/3 v3] arm: mvebu: Add gdsys ControlCenter-Compact board

2017-03-02 Thread Simon Glass
Hi Mario,

On 22 February 2017 at 08:07, Mario Six  wrote:
> From: Dirk Eibach 
>
> The gdsys ControlCenter Digital board is based on a Marvell Armada 38x
> SOC.
>
> It boots from SPI-Flash but can be configured to boot from SD-card for
> factory programming and testing.
>
> On board peripherals include:
> - 2 x GbE
> - Xilinx Kintex-7 FPGA connected via PCIe
> - mSATA
> - USB3 host
> - Atmel TPM
>
> Signed-off-by: Dirk Eibach 
> Signed-off-by: Mario Six 
> ---
> Changes in v3:
>
> * Removed gpio_request_simple function
> * Removed dev_get_by_ofname function
> * Removed "plain" GPIOs from the device tree

You are using uclass_get_device_by_name() on an I2C bus. Can you
instead use aliases and uclass_get_device_by_seq()? There is quite a
bit of getting stuff by name. Perhaps it is fine for now, but it would
be better I think to have a driver associated with a DT node, which
has phandles for the things it needs.

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


Re: [U-Boot] [PATCH v1] tools: Remove CONFIG_SYS_TEXT_BASE in Makefile

2017-03-02 Thread Simon Glass
On 28 February 2017 at 11:29, Patrick Delaunay  wrote:
> This define is not used in tools sources and can be removed
> to avoid unnecessary link between tools and defconfig
>
> Signed-off-by: Patrick Delaunay 
> ---
>
>  tools/Makefile | 1 -
>  1 file changed, 1 deletion(-)

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


Re: [U-Boot] [PATCH 2/2] mtd: nand: atmel: change another functions to set/get gpio value

2017-03-02 Thread Simon Glass
On 22 February 2017 at 03:07, Wenyou Yang  wrote:
> Because there is no implementation of gpio_set/get_value() function
> after the at91 gpio driver is converted to support DM, use
> at91_set/get_gpio_value().
>
> Signed-off-by: Wenyou Yang 
> ---
>
>  drivers/mtd/nand/atmel_nand.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)

Reviewed-by: Simon Glass 

At some point this should change to use driver model, right?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/listinfo/u-boot


Re: [U-Boot] Device cleanup before starting OS (Linux)

2017-03-02 Thread Simon Glass
Hi Stefan,

On 28 February 2017 at 22:52, Stefan Roese  wrote:
> Hi Simon,
>
> On 01.03.2017 06:40, Simon Glass wrote:
>> On 28 February 2017 at 09:32, Stefan Roese  wrote:
>>>
>>> Hi!
>>>
>>> I'm currently trying to add some code to stop (DMA) buffer usage
>>> in the Marvell mvpp2 ethernet driver, that should only be
>>> executed once, before the OS is started - stop() does not work
>>> easily for me here. I've found the weak function
>>> "board_quiesce_devices()", which is already used for
>>> such cases. But since you are not fond of weak functions
>>> (I totally agree here, this is far from perfect) and already
>>> suggested some kind of "finalize" DM API call, I'm wondering
>>> if I should introduce this new API call for such cases and use
>>> it in the ethernet driver.
>>>
>>> So what is your opinion about this? Should I add such a
>>> finalize DM function and call it from the arch/.../bootm
>>> code? Or do you have other suggestions on how to handle
>>> such driver specific last-stage (pre OS) calls?
>>
>> Is it possible to use the device's remove() method?
>
> I also thought about this of course. Using remove has the
> following disadvantages, that I currently can think of:
>
> - The remove functions of all devices are called, adding
>   to the bootup time

This seems fairly convincing to me, although I'd be interested to see
if the actual impact is noticeable (e.g. >1ms).

>
> - Since all devices are removed, serial (and other) output
>   is not available (for debug purposes) any more

This seems a lot more convincing.

>
> It should be possible to add a DM flag to enable this pre-OS
> device remove, which could be enabled on a per-device basis.
> This way we don't need another API function. But still I
> need to hook this pre-OS "remove" into arch/.../bootm.
>
> What do you think?

I'll reply on the patches.

>
> Thanks,
> Stefan

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


Re: [U-Boot] [PATCH 2/3] board: at91sam9g20ek/at91sam9260ek: move config options to defconfig

2017-03-02 Thread Simon Glass
On 22 February 2017 at 03:10, Wenyou Yang  wrote:
> Enable CONFIG_CLK and CONFIG_PINCTRL to support at91 clock
> driver and at91 pinctrl driver.
>
> Move some config options to configs/*_defconfig, and make the drivers,
> emac, gpio and mci to support the driver model.
>
> Signed-off-by: Wenyou Yang 
> ---
>
>  configs/at91sam9260ek_dataflash_cs0_defconfig  | 15 +--
>  configs/at91sam9260ek_dataflash_cs1_defconfig  | 15 +--
>  configs/at91sam9260ek_nandflash_defconfig  | 15 +--
>  configs/at91sam9g20ek_2mmc_defconfig   | 16 +++-
>  configs/at91sam9g20ek_2mmc_nandflash_defconfig | 16 +++-
>  configs/at91sam9g20ek_dataflash_cs0_defconfig  | 15 +--
>  configs/at91sam9g20ek_dataflash_cs1_defconfig  | 15 +--
>  configs/at91sam9g20ek_nandflash_defconfig  | 16 ++--
>  include/configs/at91sam9260ek.h|  9 -
>  9 files changed, 109 insertions(+), 23 deletions(-)

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


Re: [U-Boot] [RFC PATCH] kbuild: turn of dtc unit address warnings by default

2017-03-02 Thread Simon Glass
On 26 February 2017 at 23:24, Masahiro Yamada
 wrote:
> DTC 1.4.2 or later checks DT unit-address without reg property and
> vice-versa, and generates lots of warnings.  Fixing DT files will
> take for a while.  Until then, let's turn off the check unless
> building with W=*.
>
> Introduce a new helper dtc-option to check if the option is supported
> in order to suppress warnings on older versions.
>
> Signed-off-by: Masahiro Yamada 
> ---
>
> This is one possible answer to Tom's:
> https://www.mail-archive.com/u-boot@lists.denx.de/msg240328.html
>
> He fixed the problem on travis-ci by commit a0f3e3d, but it is still
> annoying during the regular development.
> Perhaps we may want to hide the warnings (at least hidden in Linux
> Kernel by default).
> Or, is it better to keep it noisy
> to motivate people to fix their DT files?
> I am not quite sure...
>
> Now I am sending this as RFC patch in case people may want to start 
> discussion.
>
> BTW, this is a counter-part of the patch I sent to the Kbuild sub-system
> (https://patchwork.kernel.org/patch/9592747/)
> because I want the U-Boot build system with Linux as much as possible.
> Let's see if I will get possible opinions in the Kbuild review.
>
>
>  Makefile   | 2 +-
>  scripts/Kbuild.include | 5 +
>  scripts/Makefile.extrawarn | 6 ++
>  3 files changed, 12 insertions(+), 1 deletion(-)

Seems like a good idea to me, at least until more are converted.

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


Re: [U-Boot] [PATCH 2/2] rockchip: configs: Enable networking support on rk3288 boards

2017-03-02 Thread Simon Glass
On 22 February 2017 at 23:20, Jacob Chen  wrote:
> At current, only firefly and rock2 have network enabled.
> Let's enable other boards.
>
> Signed-off-by: Jacob Chen 
> ---
>
>  configs/evb-rk3288_defconfig  | 5 -
>  configs/fennec-rk3288_defconfig   | 5 -
>  configs/miniarm-rk3288_defconfig  | 4 
>  configs/popmetal-rk3288_defconfig | 4 
>  4 files changed, 16 insertions(+), 2 deletions(-)

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


Re: [U-Boot] [PATCH 3/3] rockchip: rk3188: drop CONFIG_SYS_NO_FLASH

2017-03-02 Thread Simon Glass
On 23 February 2017 at 09:30, Heiko Stuebner  wrote:
> Commit e856bdcfb492 ("flash: complete CONFIG_SYS_NO_FLASH move with renaming")
> obsoleted the CONFIG_SYS_NO_FLASH option, which still is in our
> rk3188_common.h header, resulting in warnings like
> The following new ad-hoc CONFIG options were detected:
> CONFIG_SYS_NO_FLASH
>
> So also drop it from the rk3188 header.
>
> Signed-off-by: Heiko Stuebner 
> ---
>  include/configs/rk3188_common.h | 1 -
>  1 file changed, 1 deletion(-)

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


Re: [U-Boot] [PATCH 1/3 v3] dm: Add callback to modify the device tree

2017-03-02 Thread Simon Glass
Hi Mario,

On 22 February 2017 at 08:07, Mario Six  wrote:
> Certain boards come in different variations by way of utilizing daughter
> boards, for example. These boards might contain additional chips, which
> are added to the main board's busses, e.g. I2C.
>
> The device tree support for such boards would either, quite naturally,
> employ the overlay mechanism to add such chips to the tree, or would use
> one large default device tree, and delete the devices that are actually
> not present.
>
> Regardless of approach, even on the U-Boot level, a modification of the
> device tree is a prerequisite to have such modular families of boards
> supported properly.
>
> Therefore, we add an option to make the U-Boot device tree (the actual
> copy later used by the driver model) writeable, and add a callback
> method that allows boards to modify the device tree at an early stage,
> at which, hopefully, also the application of device tree overlays will
> be possible.
>
> Signed-off-by: Mario Six 
> ---
> Changes in v3:
>
> None
>
> Changes in v2:
>
> * Switched from usage of globally writeable global data pointer to a locally
>   writeable pointer passed to board_fix_fdt
> * Added comments for board_fix_fdt in include/common.h
> * Added documentation for pre-relocation device tree manipulation
> ---
>  common/board_f.c   |  10 
>  doc/driver-model/fdt-fixup.txt | 132 
> +
>  dts/Kconfig|  10 
>  include/common.h   |   1 +
>  4 files changed, 153 insertions(+)
>  create mode 100644 doc/driver-model/fdt-fixup.txt

Reviewed-by: Simon Glass 

I think as things stand this is reasonable.

But IMO it would be better (i.e. faster) to manipulate the live DT,
assuming we have one (see my series on that).

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


Re: [U-Boot] [PATCHv2 2/3] FIT: Rename FIT_DISABLE_SHA256 to FIT_ENABLE_SHA256_SUPPORT

2017-03-02 Thread Simon Glass
On 1 March 2017 at 14:51, Tom Rini  wrote:
> We rename CONFIG_FIT_DISABLE_SHA256 to CONFIG_FIT_ENABLE_SHA256_SUPPORT which
> is enabled by default and now a positive option.  Convert the handful of 
> boards
> that were disabling it before to save space.
>
>
> Cc: Dirk Eibach 
> Cc: Lukasz Dalek 
> Signed-off-by: Tom Rini 
> ---
> Changes in v2: New patch
>
>  Kconfig| 13 +
>  README |  9 -
>  configs/dlvision-10g_defconfig |  1 +
>  configs/dlvision_defconfig |  1 +
>  configs/h2200_defconfig|  1 +
>  configs/io_defconfig   |  1 +
>  configs/iocon_defconfig|  1 +
>  configs/neo_defconfig  |  1 +
>  include/configs/dlvision-10g.h |  3 ---
>  include/configs/dlvision.h |  3 ---
>  include/configs/h2200.h|  1 -
>  include/configs/io.h   |  3 ---
>  include/configs/iocon.h|  3 ---
>  include/configs/neo.h  |  3 ---
>  include/image.h| 15 +--
>  scripts/config_whitelist.txt   |  1 -
>  16 files changed, 24 insertions(+), 36 deletions(-)

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


Re: [U-Boot] [PATCH v2 2/6] dm: core: Allow multiple drivers to bind for a single node

2017-03-02 Thread Simon Glass
Hi Philipp,

On 22 February 2017 at 13:47, Philipp Tomsich
 wrote:
> Currently, driver binding stops once it encounters the first
> compatible driver that doesn't refuse to bind. However, there are
> cases where a single node will need to be handled by multiple driver
> classes. For those cases we provide a configurable option to continue
> to bind after the first driver has been found.
>
> The first use cases for this are from the DM conversion of the sunxi
> (Allwinner) architecture:
>  * pinctrl (UCLASS_PINCTRL) and gpio (UCLASS_GPIO) drivers need to
>bind against a single node
>  * clock (UCLASS_CLK) and reset (UCLASS_RESET) drivers also need to
>bind against a single node

Does linux work this way? Another approach would be to have a separate
MISC driver with two children, one pinctrl, one clk.

>
> Signed-off-by: Philipp Tomsich 
> ---
>  drivers/core/Kconfig | 14 ++
>  drivers/core/lists.c | 12 +++-
>  2 files changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/core/Kconfig b/drivers/core/Kconfig
> index 8749561..913101c 100644
> --- a/drivers/core/Kconfig
> +++ b/drivers/core/Kconfig
> @@ -31,6 +31,20 @@ config DM_WARN
>   This will cause dm_warn() to be compiled out - it will do nothing
>   when called.
>
> +config DM_ALLOW_MULTIPLE_DRIVERS
> +bool "Allow multiple drivers to bind for one node"
> +   depends on DM
> +   default n

You should be able to drop this line.

> +   help
> + The driver model in U-Boot originally did not allow multiple
> + drivers to bind for a single device node.
> +
> + If enabled, multiple drivers can now bind for a single node
> + by using the same compatible string for matching: lists_bind_fdt()
> + will assume that binding multiple drivers is desirable, if the
> + caller does not request the pointer to the udevice structure to
> + be returned (i.e. if devp is NULL).

Please update the function documentation in the header file.

> +
>  config DM_DEVICE_REMOVE
> bool "Support device removal"
> depends on DM
> diff --git a/drivers/core/lists.c b/drivers/core/lists.c
> index 23b6ba7..52efe69 100644
> --- a/drivers/core/lists.c
> +++ b/drivers/core/lists.c
> @@ -166,7 +166,11 @@ int lists_bind_fdt(struct udevice *parent, const void 
> *blob, int offset,
> dm_dbg("   - attempt to match compatible string '%s'\n",
>compat);
>
> -   for (entry = driver; entry != driver + n_ents; entry++) {
> +   entry = driver;
> +#if defined(CONFIG_DM_ALLOW_MULTIPLE_DRIVERS)
> +   allow_more_matches:
> +#endif
> +   for (; entry != driver + n_ents; entry++) {
> ret = driver_check_compatible(entry->of_match, &id,
>   compat);
> if (!ret)
> @@ -190,6 +194,12 @@ int lists_bind_fdt(struct udevice *parent, const void 
> *blob, int offset,
> found = true;
> if (devp)
> *devp = dev;
> +#if defined(CONFIG_DM_ALLOW_MULTIPLE_DRIVERS)

Can you make this a variable, e.g. with allow_multiple =
IS_ENABLED(DM_ALLOW_MULTIPLE_DRIVERS)? I'd prefer not to add #ifdefs
in this file.

> +   else {
> +   entry++;
> +   goto allow_more_matches;

Is it possible to loop without using goto?

> +   }
> +#endif
> }
> break;
> }
> --
> 1.9.1
>

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


Re: [U-Boot] [PATCH 02/17] SPL: FIT: refactor FDT loading

2017-03-02 Thread Simon Glass
Hi Andre,

On 28 February 2017 at 19:25, Andre Przywara  wrote:
> Currently the SPL FIT loader uses the spl_fit_select_fdt() function to
> find the offset to the right DTB within the FIT image.
> For this it iterates over all subnodes of the /configuration node in
> the FIT tree and compares all "description" strings therein using a
> board specific matching function.
> If that finds a match, it uses the string in the "fdt" property of that
> subnode to locate the matching subnode in the /images node, which points
> to the DTB data.
> Now this works very well, but is quite specific to cover this particular
> use case. To open up the door for a more generic usage, let's split this
> function into:
> 1) a function that just returns the node offset for the matching
>configuration node (spl_fit_find_config_node())
> 2) a function that returns the image data any given property in a given
>configuration node points to, additionally using a given index into
>a possbile list of strings (spl_fit_select_index())
> This allows us to replace the specific function above by asking for the
> image the _first string of the "fdt" property_ in the matching
> configuration subnode points to.
>
> This patch introduces no functional changes, it just refactors the code
> to allow reusing it later.
>
> (diff is overly clever here and produces a hard-to-read patch, so I
> recommend to throw a look at the result instead).

First I want to commend you on your excellent commit messages. For
example this one explains the current situation, the change your
commit performs and the motivation for that change. With these more
complicated / core pieces, it is very valuable and you are an example
to us all :-)

>
> Signed-off-by: Andre Przywara 
> ---
>  common/spl/spl_fit.c | 83 
> 
>  1 file changed, 52 insertions(+), 31 deletions(-).

Reviewed-by: Simon Glass 

I think we need a pytest for this somewhere in this series. With
sandbox_spl we can run spl/u-boot-spl and it jumps to u-boot. Can we
use this to check that the right thing happens in a few simple cases?

>
> diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
> index aae556f..ba45e65 100644
> --- a/common/spl/spl_fit.c
> +++ b/common/spl/spl_fit.c
> @@ -22,13 +22,11 @@ static ulong fdt_getprop_u32(const void *fdt, int node, 
> const char *prop)
> return fdt32_to_cpu(*cell);
>  }
>
> -static int spl_fit_select_fdt(const void *fdt, int images, int *fdt_offsetp)
> +static int spl_fit_find_config_node(const void *fdt)

Can you comment this function please? I should have done this myself.

>  {
> -   const char *name, *fdt_name;
> -   int conf, node, fdt_node;
> -   int len;
> +   const char *name;
> +   int conf, node, len;
>
> -   *fdt_offsetp = 0;
> conf = fdt_path_offset(fdt, FIT_CONFS_PATH);
> if (conf < 0) {
> debug("%s: Cannot find /configurations node: %d\n", __func__,
> @@ -50,39 +48,61 @@ static int spl_fit_select_fdt(const void *fdt, int 
> images, int *fdt_offsetp)
> continue;
>
> debug("Selecting config '%s'", name);
> -   fdt_name = fdt_getprop(fdt, node, FIT_FDT_PROP, &len);
> -   if (!fdt_name) {
> -   debug("%s: Cannot find fdt name property: %d\n",
> - __func__, len);
> -   return -EINVAL;
> -   }
>
> -   debug(", fdt '%s'\n", fdt_name);
> -   fdt_node = fdt_subnode_offset(fdt, images, fdt_name);
> -   if (fdt_node < 0) {
> -   debug("%s: Cannot find fdt node '%s': %d\n",
> - __func__, fdt_name, fdt_node);
> -   return -EINVAL;
> +   return node;
> +   }
> +
> +   return -1;

How about -ENOENT?

> +}
> +
> +static int spl_fit_select_index(const void *fit, int images, int *offsetp,
> +   const char *type, int index)

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


Re: [U-Boot] [PATCH v1] gpt: Fix uuid string format

2017-03-02 Thread Simon Glass
Hi Andy,

On 27 February 2017 at 07:11, Andy Shevchenko
 wrote:
> From: Vincent Tinelli 
>
> Change GPT UUID string format from UUID to GUID per specification.
>
> Signed-off-by: Vincent Tinelli 
> ---
>  cmd/gpt.c   | 2 +-
>  disk/part_efi.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)

Reviewed-by: Simon Glass 

How about also a patch to add comments to that enum in uuid.h?

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


Re: [U-Boot] [PATCH v1] env_mmc: configure environment offsets via device tree

2017-03-02 Thread Simon Glass
Hi Igor,

On 22 February 2017 at 00:35, Igor Grinberg  wrote:
> Hi Philipp, Simon,
>
> On 02/22/17 05:59, Simon Glass wrote:
>> Hi,
>>
>> On 20 February 2017 at 02:18, Dr. Philipp Tomsich
>>  wrote:
>>>
>>> On 20 Feb 2017, at 08:22, Igor Grinberg  wrote:
>>>
>>> That sounds too odd...
>>> DT's purpose is to describe the h/w... and that does not look so...
>>> We also, have a dt file name in the environment, so this creates will create
>>> a chicken and an egg problem…
>>>
>>>
>>> I don’t really follow… as far as I knew the DT name would have to come
>>> from some other source anyway, as the device containing the env might
>>> only be described through the device tree (e.g. mmc0).
>>>
>>>
>>> Why? U-Boot can live pretty well w/o DT.
>>>
>>>
>>> If U-Boot runs without DT, then nothing will/should change about how the
>>> setting
>>> is retrieved from CONFIG_ENV_OFFSET.
>
> ok.
>
>>>
>>> The platform that motivated this change is ARCH_SUNXI, which does not use
>>> per-board defines but aims to have one generic bootloader per-SoC.
>
> Well, after a ten year experience with boars and different SoC vendors,
> I don't think it is possible...
> Unless all boards are copies of their respective reference design...
>
>>>
>>> I really don't think we should go that direction. DT is not meant to provide
>>> a solution to all your problems...
>>>
>>>
>>> I don’t see how this is different from other entries in chosen and config as
>>> of today:
>>> common/autoboot.c allows an override through /config/bootdelay
>>> common/board_r.c uses /config/load-environment
>>> common/cli.c can pull in /config/bootcmd
>>> drivers/serial/serial-uclass.c uses /chosen/stdout-path
>>>
>>> In fact, it is the absence of this mechanism that is causing problems today:
>>> CONFIG_ENV_OFFSET is not configurable through Kconfig, so we would
>>> need board-specific defines (e.g. CONFIG_SUNXI_BOARD_LYNX) and
>>> matching #ifdef primitives in a shared header (sunxi-common.h in our case).
>>>
>>>
>>> Right. Exactly, I think we should move the CONFIG_ENV_OFFSET to Kconfig.
>>> And that will solve the problem.
>>>
>>>
>>> Doing this would still get into the way of architectures that want to build
>>> a single
>>> ‘universal’ bootloader for their SoC: the ENV_OFFSET may not be the same
>>> across all board and vendor configurations. This can easily be handled with
>>> the
>>> (optional) prop in the DT, but not with the compile-time ENV_OFFSET.
>
> I think Kconfig would be enough for this, but please try your approach.
> The 'universal' thing will probably work if you don't have too many boards and
> they don't differ too much from each other...
>
>>>
>>> If we decide to this, I’d at least like to introduce the function call to
>>> (the weak
>>> function) mmc_get_env_addr(…), so we can override this in the board code.
>
> That is how it works today:
> include/environment.h:185:extern int mmc_get_env_addr(struct mmc *mmc, int 
> copy, u32 *env_addr);
>
>>>
>>> So putting this in the DT is the best (and least intrusive) option
>>> available.
>>>
>>>
>>> Ok. I see your point now. Yet I think we should keep the DT to its purpose -
>>> which
>>> is to describe the h/w (and not the s/w placement layout).
>>
>> Well actually we put things like flash map in there and the
>> environment position seems like a very good thing to have there.
>
> Well, I thought so too... But I had a discussion with kernel people
> some time ago and they discourage this approach and would not like to
> have the flash mapping in the DT.

I'm sorry to hear that, but it doesn't change the fact that it is very
useful for dealing with hardware-specific differences between models.

Building the same software multiple times with different #ifdefs is
often painful. Using a DT to handle these minor differences reduces
the number of build combinations and simplifies testing.

>
>> So I
>> like this patch. There is too compile-time configuration in U-Boot
>> still...
>
> Yeah, I know you like it ;-) but DT is not the place for it,
> unless DT specs. guys decide to change its purpose and place
> s/w configuration straps inside...
>
> Although, U-Boot build process is not a pain at all, you might want
> to design another abstraction layer for s/w configuration straps.
> That way you will be able to keep the U-Boot core binary generic...
> Is it worse the effort? I don't know. Currently, having the board
> infrastructure, provides that layer and works fine.

At present in U-Boot DT is that layer. We don't need to ban useful
additions like this and I really am not keen on adding another config
mechanism.

>
>>
>> In fact I wish we could support this for all environment types.
>> Overall the environment drivers need some work to make them more
>> similar...
>
> Indeed, but not just that... It would be great to add a DM to env. drivers.
> This will make it possible to use more than one environment driver
> in runtime and make many people who struggle with it happy...

Yes.

Regards,
Simon
___

Re: [U-Boot] [RFC PATCH 3/3] arm: bootm: Add dm_pre_os_remove() call to announce_and_cleanup()

2017-03-02 Thread Simon Glass
Hi Stefan,

On 1 March 2017 at 03:23, Stefan Roese  wrote:
> This patch adds a call to dm_pre_os_remove() to announce_and_cleanup()
> so that drivers that have the flag DM_FLAG_PRE_OS_REMOVE set may do
> some last-stage cleanup before the OS is started.
>
> Signed-off-by: Stefan Roese 
> Cc: Simon Glass 
> ---
>  arch/arm/lib/bootm.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
> index 8125cf023f..84f3415c1e 100644
> --- a/arch/arm/lib/bootm.c
> +++ b/arch/arm/lib/bootm.c
> @@ -91,6 +91,14 @@ static void announce_and_cleanup(int fake)
>
> board_quiesce_devices();
>
> +   /*
> +* Call remove function of all devices with the pre-OS remove flag
> +* set (DM_FLAG_PRE_OS_REMOVE). This may be useful for last-stage
> +* operations, like cancelling of DMA operation or releasing device
> +* internal buffers.
> +*/
> +   dm_pre_os_remove();

In a full DM world we could perhaps have devices which use the DMA
uclass, so we can tell which ones need to be removed.

How about dm_remove_dma_devices()?

> +
> cleanup_before_linux();
>  }
>
> --
> 2.12.0
>

Also (once we have things figured out) this needs some sort of test in test/.

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


Re: [U-Boot] [PATCH 1/3] dm: Return actual bools in dm_fdt_pre_reloc

2017-03-02 Thread Simon Glass
On 23 February 2017 at 09:30, Heiko Stuebner  wrote:
> Documentation says that we're returning true/false, not 1/0 so adapt
> the function to return actual booleans.
>
> Signed-off-by: Heiko Stuebner 
> ---
>  drivers/core/util.c | 12 ++--
>  include/dm/util.h   |  2 +-
>  2 files changed, 7 insertions(+), 7 deletions(-)

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


Re: [U-Boot] [PATCH 2/3] rockchip: rk3188: enable TPL_LIBGENERIC for generic memset

2017-03-02 Thread Simon Glass
On 23 February 2017 at 09:30, Heiko Stuebner  wrote:
> Commit c67c8c604b6c ("board_init.c: Always use memset()") dropped the naive
> memset alternative from board_init_f_init_reserve.
> So activate CONFIG_TPL_LIBGENERIC for that common memset implementation.
> We cannot use the ARCH-specific memset, as that would incur 200bytes of
> additional TPL size, space we do not have.
>
> Signed-off-by: Heiko Stuebner 
> ---
>  arch/arm/mach-rockchip/rk3188/Kconfig | 3 +++
>  configs/rock_defconfig| 2 ++
>  2 files changed, 5 insertions(+)

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


Re: [U-Boot] [PATCH 1/9] image: Fixes build warning with CONFIG_FIT_IMAGE_POST_PROCESS

2017-03-02 Thread Simon Glass
On 23 February 2017 at 10:54, Andrew F. Davis  wrote:
> The function 'board_fit_image_post_process' is defined only when the
> config option CONFIG_FIT_IMAGE_POST_PROCESS is enabled. For secure
> systems that do not use SPL but do use FIT kernel images, only
> CONFIG_FIT_IMAGE_POST_PROCESS will be defined, which will result in an
> implicit declaration of function 'board_fit_image_post_process' warning
> while building u-boot. Fix this warning.
>
> Signed-off-by: Madan Srinivas 
> Signed-off-by: Andrew F. Davis 
> Reviewed-by: Tom Rini 
> ---
>  include/image.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

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


Re: [U-Boot] [RFC PATCH 2/3] dm: core: Add dm_pre_os_remove() and hook it into device_remove()

2017-03-02 Thread Simon Glass
Hi Stefan,

On 1 March 2017 at 03:23, Stefan Roese  wrote:
> The new function dm_pre_os_remove() is intented for driver specific
> last-stage cleanup operations before the OS is started. This patch adds
> this functionality and hooks it into the common device_remove()
> function.
>
> To enable usage for custom driver (e.g. ethernet drivers), this patch
> also sets the pre-OS remove flag for the root driver and simple-bus
> drivers. Otherwise the recursive call starting from the root device
> would not reach the drivers in need for this specific remove call.
>
> Signed-off-by: Stefan Roese 
> Cc: Simon Glass 
> ---
>  drivers/core/device-remove.c | 7 +++
>  drivers/core/root.c  | 8 
>  drivers/core/simple-bus.c| 1 +
>  include/dm/root.h| 9 +
>  4 files changed, 25 insertions(+)
>
> diff --git a/drivers/core/device-remove.c b/drivers/core/device-remove.c
> index 4725d4751c..0dfb20cdce 100644
> --- a/drivers/core/device-remove.c
> +++ b/drivers/core/device-remove.c
> @@ -166,6 +166,13 @@ int device_remove(struct udevice *dev, bool 
> pre_os_remove)
> drv = dev->driver;
> assert(drv);
>
> +   /*
> +* If pre-OS remove is requested, only continue for drivers with this
> +* flag set
> +*/
> +   if (pre_os_remove && !(drv->flags & DM_FLAG_PRE_OS_REMOVE))
> +   return 0;
> +

This doesn't seem good to me. I think it should scan the whole tree,
and process devices with the flag set. That way you don't need the
root node to have the flag.

If a device has DMA, it will be removed. But its parent may not, in
which case the parent will not be removed. However any children of the
device will need to be removed, even if they don't have DMA, because
we cannot have active children of an inactive device. Does that make
sense?

> ret = uclass_pre_remove_device(dev);
> if (ret)
> return ret;
> diff --git a/drivers/core/root.c b/drivers/core/root.c
> index 583daa88b0..1468a15db4 100644
> --- a/drivers/core/root.c
> +++ b/drivers/core/root.c
> @@ -182,6 +182,13 @@ int dm_uninit(void)
> return 0;
>  }
>
> +int dm_pre_os_remove(void)
> +{
> +   device_remove(dm_root(), true);
> +
> +   return 0;
> +}
> +
>  int dm_scan_platdata(bool pre_reloc_only)
>  {
> int ret;
> @@ -280,6 +287,7 @@ U_BOOT_DRIVER(root_driver) = {
> .name   = "root_driver",
> .id = UCLASS_ROOT,
> .priv_auto_alloc_size = sizeof(struct root_priv),
> +   .flags  = DM_FLAG_PRE_OS_REMOVE,
>  };
>
>  /* This is the root uclass */
> diff --git a/drivers/core/simple-bus.c b/drivers/core/simple-bus.c
> index a300217d39..4142626ff6 100644
> --- a/drivers/core/simple-bus.c
> +++ b/drivers/core/simple-bus.c
> @@ -64,4 +64,5 @@ U_BOOT_DRIVER(simple_bus_drv) = {
> .name   = "generic_simple_bus",
> .id = UCLASS_SIMPLE_BUS,
> .of_match = generic_simple_bus_ids,
> +   .flags  = DM_FLAG_PRE_OS_REMOVE,
>  };
> diff --git a/include/dm/root.h b/include/dm/root.h
> index 3cf730dcee..8ac7bc3512 100644
> --- a/include/dm/root.h
> +++ b/include/dm/root.h
> @@ -115,4 +115,13 @@ int dm_init(void);
>   */
>  int dm_uninit(void);
>
> +/**
> + * dm_pre_os_remove - Call remove function of all drivers with the pre-OS
> + *   remove flag set
> + *
> + * All devices with the pre-OS remove flag set, will be removed
> + * @return 0 if OK, -ve on error
> + */
> +int dm_pre_os_remove(void);
> +
>  #endif
> --
> 2.12.0
>

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


Re: [U-Boot] [PATCH] binman: Explicitly request python2 instead of python from env

2017-03-02 Thread Simon Glass
Hi,

On 27 February 2017 at 09:26, Tom Rini  wrote:
> On Wed, Feb 22, 2017 at 10:25:38AM -0500, Tom Rini wrote:
>> On Thu, Feb 23, 2017 at 12:25:48AM +1100, Jonathan Gray wrote:
>> > On Mon, Feb 20, 2017 at 07:41:34PM +0100, Paul Kocialkowski wrote:
>> > > We now live in a world where python cannot be assumed to be python2.
>> > > As a matter of fact, it is no longer the default for python on many
>> > > GNU/Linux distributions.
>> > >
>> > > Running binman with python3 fails, so explicitly request python2 from
>> > > env in the shebang for running it.
>> >
>> > On other systems such as OpenBSD the binary is python2.7 not python2
>> > or python.  Though there isn't really a way to handle this with
>> > how u-boot builds as I understand it (besides local patches).
>>
>> I thought, but could be wrong, that "python2" was the canonical way name
>> for the python 2.x binary.
>
> So, I looked harder at this and found
> https://www.python.org/dev/peps/pep-0394/ which in sum, to me says it is
> more reasonable to expect 'python2' to exist than it is to expect that
> 'python2.7' exists (but is also possibly getting out of date as it
> sounds like more than just Arch sets python to python3).
>
> That said, I also found issues that note that OSX (and as you note,
> OpenBSD) do not do python2 but rather python2.7 and that the "best"
> overall solution is to make the code compatible with python 2 and
> python 3 so that 'python' is still the correct thing to look for.
>
> My inclination for this release is to keep the current behavior and hope
> that for the next release someone has the time to make binman python2
> and python3 compatible.  We do this today with 'patman' but that tool is
> more optional than binman is and we certainly have the case today where
> patman will fail if the user doesn't have the "future" package installed
> in python.  I almost wonder if making binman python3-only would be
> easier.

I agree. I will make the time for this in a few weeks ,if someone
doesn't kindly beat me to it. It should be possible to support both
Python 2 and 3.

Regarding the incompatibility of Python 2 and 3, I would like to add
my approbation to the pile also.

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


Re: [U-Boot] [PATCH 3/3] board: at91sam9260ek: clean up code

2017-03-02 Thread Simon Glass
On 22 February 2017 at 03:10, Wenyou Yang  wrote:
> Since the introduction of the pinctrl and clk drivers and the
> device tree files, remove unneeded hard coded related code from
> the board file.
>
> Signed-off-by: Wenyou Yang 
> ---
>
>  board/atmel/at91sam9260ek/at91sam9260ek.c | 73 
> ---
>  1 file changed, 73 deletions(-)

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


Re: [U-Boot] [PATCH 1/2] ARM: dts: rockchip: enable gmac for rk3288 boards

2017-03-02 Thread Simon Glass
On 22 February 2017 at 23:20, Jacob Chen  wrote:
> Enable gmac interface for rk3288 board dts.
> use "okay" not "ok"
>
> Signed-off-by: Jacob Chen 
> ---
>
>  arch/arm/dts/rk3288-evb.dtsi  | 22 ++
>  arch/arm/dts/rk3288-miniarm.dtsi  |  2 +-
>  arch/arm/dts/rk3288-popmetal.dtsi |  2 +-
>  3 files changed, 24 insertions(+), 2 deletions(-)

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


Re: [U-Boot] [PATCH 2/2] clk: at91: align clk-master's compatibles with kernel's

2017-03-02 Thread Simon Glass
On 22 February 2017 at 03:01, Wenyou Yang  wrote:
> Add the compatible "atmel,at91rm9200-clk-master" to align with
> the kernel's.
>
> Signed-off-by: Wenyou Yang 
> ---
>
>  drivers/clk/at91/clk-master.c | 1 +
>  1 file changed, 1 insertion(+)

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


Re: [U-Boot] [PATCH 1/2] ARM: at91: gpio: fix at91_set/get_gpio_value()

2017-03-02 Thread Simon Glass
Hi Wenyou,

On 22 February 2017 at 03:07, Wenyou Yang  wrote:
> There is no implementation on at91_set_pio_value() with two arguments.
> at91_get_pio_value() with one argument.
>
> Signed-off-by: Wenyou Yang 
> ---
>
>  arch/arm/mach-at91/include/mach/gpio.h | 12 +---
>  1 file changed, 5 insertions(+), 7 deletions(-)

I cannot make sense of this commit message. It should explain what the
commit does.

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


Re: [U-Boot] [PATCH 1/2] clk: at91: enhance the peripheral clock

2017-03-02 Thread Simon Glass
On 22 February 2017 at 03:01, Wenyou Yang  wrote:
>
> Enhance the peripheral clock to support both at9sam9x5's
> and at91rm9200's peripheral clock via the different compatibles.
>
> Signed-off-by: Wenyou Yang 
> ---
>
>  drivers/clk/at91/clk-peripheral.c | 19 ---
>  1 file changed, 16 insertions(+), 3 deletions(-)

Reviewed-by: Simon Glass 

But I suggest you using something better than 0 and 1 for the
different types. Eg. an enum with a descriptive name.

>
> diff --git a/drivers/clk/at91/clk-peripheral.c 
> b/drivers/clk/at91/clk-peripheral.c
> index e1ed447133..8a4c88566b 100644
> --- a/drivers/clk/at91/clk-peripheral.c
> +++ b/drivers/clk/at91/clk-peripheral.c
> @@ -28,7 +28,8 @@ static int sam9x5_periph_clk_bind(struct udevice *dev)
>  }
>
>  static const struct udevice_id sam9x5_periph_clk_match[] = {
> -   { .compatible = "atmel,at91sam9x5-clk-peripheral" },
> +   { .compatible = "atmel,at91rm9200-clk-peripheral", .data = 0 },
> +   { .compatible = "atmel,at91sam9x5-clk-peripheral", .data = 1 },
> {}
>  };
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/listinfo/u-boot


Re: [U-Boot] x86: SecureBoot: Bay Trail

2017-03-02 Thread Simon Glass
Hi,

On 22 February 2017 at 02:58, Markus Valentin  wrote:
> Hi Simon,
>
> On Tue, 2017-02-21 at 20:59 -0700, Simon Glass wrote:
>> On 20 February 2017 at 02:10, Markus Valentin  wrote:
>> >
>> > Hi,
>> >
>> > On Fri, 2017-02-17 at 19:58 +0800, Bin Meng wrote:
>> > >
>> > > On Fri, Feb 17, 2017 at 5:26 PM, Markus Valentin  wrote:
>> > > >
>> > > >
>> > > > Hi,
>> > > >
>> > > > i'm implementing Secure Boot with U-Boot on a Intel Atom E3800 Series
>> > > > (Bay
>> > > > Trail) based Plattform.
>> > > >
>> > > > I did manage to get the first boot stage (Initial Boot Block) verified
>> > > > by
>> > > > the
>> > > > Trusted Execution Engine, next i need to verify the "ramstage" as they
>> > > > call
>> > > > it.
>> > >
>> > > How did you implement the first boot stage? Is it U-Boot SPL?
>> > No, i'm not using SPL, but maybe i should?
>> >
>> > Currently i follow the instructions from document #558081 "Enabling Secure
>> > Boot
>> > with Intel FSP and coreboot" for Intel ® Atom TM Processor E3800 Product
>> > Family".
>> > There they state that i should extract a IBB(Initial Boot Block) which is
>> > the
>> > last 127Kib from the u-boot.rom/coreboot.rom file. IBB plus a secure boot
>> > "manifest" is the 1st stage that gets properly authenticated, copied to ram
>> >  and executed(128Kib).
>>
>> Coreboot has the concepts of:
>>
>> boot block - run first, handles boot vector 16-bit to 32-bit
>> transition, sets up cache-as-RAM (CAR) and other early things, then
>> starts romstage
>> romstage - runs using CAR as stack, sets up SDRAM, starts  ramstage
>> ramstage - the rest of coreboot
>>
>> These are actually three separate programs, individually compiled and
>> linked, even through they are actually packaged into the same ROM.
>>
>> In 32-bit U-Boot we build U-Boot as one program. It goes through these
>> stages:
>>
>> start - handles boot vector 16-bit to 32-bit transition, sets up
>> cache-as-RAM (CAR) and other early things
>> pre-relocation - runs using CAR as stack, sets up SDRAM, relocates
>> U-Boot into RAM, jumps there
>> post-relocation - the rest of U-Boot
>>
>> Note: For 64-bit U-Boot we do in fact build two images: roughly
>> speaking, SPL runs in 32-bit mode and does the first two steps above
>> then loads U-Boot proper into RAM, changes to 64-bit mode and jumps to
>> it.
> Thanks a lot for the clarification :)
>>
>> Back to your problem...I don't think you need to use SPL on 32-bit
>> x86. You should be able to set things up to verify the reset vector
>> and the entire U-Boot image. Can you adjust the size of the image that
>> is verified?
> No i'm not able to change the size of the image that gets verified by the TXE.
>>
>> If you find that you cannot adjust this size to cover all of U-Boot,
>> then I see two options:
>>
>> - Add a verification piece which runs immediately after the 'start'
>> stage above, and performs the crypto verification using U-Boot's FIT
>> system. This will involve linking all of the required code into a
>> single block which is covered by the chip's verification
> That is exactly what im targeting at.
>
> Luckily i have 400 bytes of arbitrary usable data (OEM-Data-Region) which is
> already authenticated by the hardware (it is inside the SecureBootManifest).
>
> My current idea is to put a checksum over u-boot+u-boot-dtb+ucode (as 
> assembled
> via binman) inside the oem-block. Then i need to compare the stored 
> checksum(s)
> with the at runtime calculated one(s). This would make sure that my u-boot 
> code
> has not been tampered.
>
> So i need to get my verification piece in the start stage as you said. Am i
> right that start stage is equal to u-boot-x86-16bit.bin aka "x86-start16" for
> binman input?
>
> If i have accomplished that, and compared the checksum(s), u-boot has been
> completely verified. Afterwards i can go on and use the fit-mechanism for the
> rest of the boot process.
>
> Please correct me if i miss something or you think something should be done
> differently i'm looking forward your feedback.

That sounds fine, but of course you need to make sure that the code
that checks the checksum is itself protected against modification.

>>
>>  - Use SPL, a bit like 64-bit U-Boot, except that U-Boot proper is
>> x32-bit. Then you can use the chip's verification to verify SPL, and
>> SPL's verification to load and verify U-Boot proper and anything else
>> you need
> I will save that idea if i get a tough problem with my initial idea.
>>
>> >
>> > >
>> > >
>> > > >
>> > > >
>> > > >
>> > > > Intel provides a manual o1n how to enable Secure Boot with coreboot in
>> > > > this
>> > > > manual they extract the "ramstage" from the coreboot.rom file via cbfs.
>> > > >
>> > >
>> > > Which manual is this?
>> > #558081 "Enabling Secure Boot with Intel FSP and coreboot" for Intel ® Atom
>> > TM
>> > Processor E3800 Product Family"
>> > >
>> > >
>> > > >
>> > > >
>> > > > How can i get the equivalent for the coreboot-ramstage from U-Boot?
>> > > >
>> > >
>> > > My under

[U-Boot] [PATCHv3 2/2] pci: layerscape: Add support ls2088a kernel DT node fixup

2017-03-02 Thread Zhiqiang Hou
From: Hou Zhiqiang 

There isn't LS2088A DT file, actually it reuse LS2080A DT file
under u-boot, while under kernel there are DT files for LS2080A
and LS2088A respectively with different PCIe node compatible
string.

Signed-off-by: Hou Zhiqiang 
---
V3:
 - removed unused variable.

 drivers/pci/pcie_layerscape_fixup.c | 35 ---
 1 file changed, 24 insertions(+), 11 deletions(-)

diff --git a/drivers/pci/pcie_layerscape_fixup.c 
b/drivers/pci/pcie_layerscape_fixup.c
index 19ede2f..64e461e 100644
--- a/drivers/pci/pcie_layerscape_fixup.c
+++ b/drivers/pci/pcie_layerscape_fixup.c
@@ -72,19 +72,26 @@ static void fdt_pcie_set_msi_map_entry(void *blob, struct 
ls_pcie *pcie,
u32 *prop;
u32 phandle;
int nodeoffset;
+   uint svr;
+   char *compat = NULL;
 
/* find pci controller node */
nodeoffset = fdt_node_offset_by_compat_reg(blob, "fsl,ls-pcie",
   pcie->dbi_res.start);
if (nodeoffset < 0) {
 #ifdef CONFIG_FSL_PCIE_COMPAT /* Compatible with older version of dts node */
-   nodeoffset = fdt_node_offset_by_compat_reg(blob,
-   CONFIG_FSL_PCIE_COMPAT, pcie->dbi_res.start);
+   svr = (get_svr() >> SVR_VAR_PER_SHIFT) & 0xFE;
+   if (svr == SVR_LS2088A || svr == SVR_LS2084A ||
+   svr == SVR_LS2048A || svr == SVR_LS2044A)
+   compat = "fsl,ls2088a-pcie";
+   else
+   compat = CONFIG_FSL_PCIE_COMPAT;
+   if (compat)
+   nodeoffset = fdt_node_offset_by_compat_reg(blob,
+   compat, pcie->dbi_res.start);
+#endif
if (nodeoffset < 0)
return;
-#else
-   return;
-#endif
}
 
/* get phandle to MSI controller */
@@ -146,19 +153,25 @@ static void fdt_fixup_pcie(void *blob)
 static void ft_pcie_ls_setup(void *blob, struct ls_pcie *pcie)
 {
int off;
+   uint svr;
+   char *compat = NULL;
 
off = fdt_node_offset_by_compat_reg(blob, "fsl,ls-pcie",
pcie->dbi_res.start);
if (off < 0) {
 #ifdef CONFIG_FSL_PCIE_COMPAT /* Compatible with older version of dts node */
-   off = fdt_node_offset_by_compat_reg(blob,
-   CONFIG_FSL_PCIE_COMPAT,
-   pcie->dbi_res.start);
+   svr = (get_svr() >> SVR_VAR_PER_SHIFT) & 0xFE;
+   if (svr == SVR_LS2088A || svr == SVR_LS2084A ||
+   svr == SVR_LS2048A || svr == SVR_LS2044A)
+   compat = "fsl,ls2088a-pcie";
+   else
+   compat = CONFIG_FSL_PCIE_COMPAT;
+   if (compat)
+   off = fdt_node_offset_by_compat_reg(blob,
+   compat, pcie->dbi_res.start);
+#endif
if (off < 0)
return;
-#else
-   return;
-#endif
}
 
if (pcie->enabled)
-- 
2.1.0.27.g96db324

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


[U-Boot] [PATCHv3 1/2] pci: layerscape: add LS2088A series SoC pcie support

2017-03-02 Thread Zhiqiang Hou
From: Hou Zhiqiang 

The LS2088A series SoCs has different physical memory map address and
CCSR registers address against LS2080A series SoCs.

Signed-off-by: Hou Zhiqiang 
---
V3:
 - no change

 arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 46 +
 drivers/pci/pcie_layerscape.c   | 35 +
 drivers/pci/pcie_layerscape.h   |  8 ++
 3 files changed, 89 insertions(+)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c 
b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
index 335f225..6afb40f 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
@@ -89,6 +89,49 @@ static inline void early_mmu_setup(void)
set_sctlr(get_sctlr() | CR_M);
 }
 
+static void fix_final_mmu_map(void)
+{
+#ifdef CONFIG_LS2080A
+   unsigned int i;
+   u32 svr, ver;
+   struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
+
+   svr = gur_in32(&gur->svr);
+   ver = SVR_SOC_VER(svr);
+
+   /* Fix PCIE base and size for LS2088A */
+   if ((ver == SVR_LS2088A) || (ver == SVR_LS2084A) ||
+   (ver == SVR_LS2048A) || (ver == SVR_LS2044A)) {
+   for (i = 0; i < ARRAY_SIZE(final_map); i++) {
+   switch (final_map[i].phys) {
+   case CONFIG_SYS_PCIE1_PHYS_ADDR:
+   final_map[i].phys = 0x20ULL;
+   final_map[i].virt = 0x20ULL;
+   final_map[i].size = 0x8ULL;
+   break;
+   case CONFIG_SYS_PCIE2_PHYS_ADDR:
+   final_map[i].phys = 0x28ULL;
+   final_map[i].virt = 0x28ULL;
+   final_map[i].size = 0x8ULL;
+   break;
+   case CONFIG_SYS_PCIE3_PHYS_ADDR:
+   final_map[i].phys = 0x30ULL;
+   final_map[i].virt = 0x30ULL;
+   final_map[i].size = 0x8ULL;
+   break;
+   case CONFIG_SYS_PCIE4_PHYS_ADDR:
+   final_map[i].phys = 0x38ULL;
+   final_map[i].virt = 0x38ULL;
+   final_map[i].size = 0x8ULL;
+   break;
+   default:
+   break;
+   }
+   }
+   }
+#endif
+}
+
 /*
  * The final tables look similar to early tables, but different in detail.
  * These tables are in DRAM. Sub tables are added to enable cache for
@@ -105,6 +148,9 @@ static inline void final_mmu_setup(void)
int index;
 #endif
 
+   /* fix the final_map before filling in the block entries */
+   fix_final_mmu_map();
+
mem_map = final_map;
 
 #ifdef CONFIG_SYS_MEM_RESERVE_SECURE
diff --git a/drivers/pci/pcie_layerscape.c b/drivers/pci/pcie_layerscape.c
index 90b9fe2..9a49898 100644
--- a/drivers/pci/pcie_layerscape.c
+++ b/drivers/pci/pcie_layerscape.c
@@ -167,6 +167,27 @@ static void ls_pcie_setup_atu(struct ls_pcie *pcie)
pci_get_regions(pcie->bus, &io, &mem, &pref);
idx = PCIE_ATU_REGION_INDEX1 + 1;
 
+   /* Fix the pcie memory map for LS2088A series SoCs */
+   svr = (svr >> SVR_VAR_PER_SHIFT) & 0xFE;
+   if (svr == SVR_LS2088A || svr == SVR_LS2084A ||
+   svr == SVR_LS2048A || svr == SVR_LS2044A) {
+   if (io)
+   io->phys_start = (io->phys_start &
+(PCIE_PHYS_SIZE - 1)) +
+LS2088A_PCIE1_PHYS_ADDR +
+LS2088A_PCIE_PHYS_SIZE * pcie->idx;
+   if (mem)
+   mem->phys_start = (mem->phys_start &
+(PCIE_PHYS_SIZE - 1)) +
+LS2088A_PCIE1_PHYS_ADDR +
+LS2088A_PCIE_PHYS_SIZE * pcie->idx;
+   if (pref)
+   pref->phys_start = (pref->phys_start &
+(PCIE_PHYS_SIZE - 1)) +
+LS2088A_PCIE1_PHYS_ADDR +
+LS2088A_PCIE_PHYS_SIZE * pcie->idx;
+   }
+
if (io)
/* ATU : OUTBOUND : IO */
ls_pcie_atu_outbound_set(pcie, idx++,
@@ -442,6 +463,7 @@ static int ls_pcie_probe(struct udevice *dev)
u8 header_type;
u16 link_sta;
bool ep_mode;
+   uint svr;
int ret;
 
pcie->bus = dev;
@@ -495,6 +517,19 @@ static int ls_pcie_probe(struct udevice *dev)
return ret;
}
 
+   /*
+* Fix the pcie memory map address and P

Re: [U-Boot] [PATCH] cmd: wdt: Add "wdt disable" command

2017-03-02 Thread Tom Rini
On Fri, Mar 03, 2017 at 01:01:11AM +0100, Lukasz Majewski wrote:

> Add support for "wdt disable" command necessary for disabling the watchdog
> timer.
> 
> Signed-off-by: Lukasz Majewski 
> ---
>  cmd/Kconfig|  6 ++
>  cmd/Makefile   |  2 ++
>  cmd/wdt.c  | 32 
>  include/watchdog.h |  2 ++
>  4 files changed, 42 insertions(+)
>  create mode 100644 cmd/wdt.c
> 
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index e339d86..293e0bb 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -426,6 +426,12 @@ config CMD_REMOTEPROC
>   help
> Support for Remote Processor control
>  
> +config CMD_WDT
> + bool "wdt"
> + default n

No need for default n, that is the default.

> + help
> +   Enables the "wdt" command, which is used to control a watchdog timer.
> +
>  config CMD_GPIO
>   bool "gpio"
>   help
> diff --git a/cmd/Makefile b/cmd/Makefile
> index 9c9a9d1..4934427 100644
> --- a/cmd/Makefile
> +++ b/cmd/Makefile
> @@ -157,6 +157,8 @@ obj-$(CONFIG_CMD_ETHSW) += ethsw.o
>  # Power
>  obj-$(CONFIG_CMD_PMIC) += pmic.o
>  obj-$(CONFIG_CMD_REGULATOR) += regulator.o
> +
> +obj-$(CONFIG_CMD_WDT) += wdt.o
>  endif # !CONFIG_SPL_BUILD
>  
>  obj-$(CONFIG_CMD_BLOB) += blob.o
> diff --git a/cmd/wdt.c b/cmd/wdt.c
> new file mode 100644
> index 000..aeaa9c2
> --- /dev/null
> +++ b/cmd/wdt.c
> @@ -0,0 +1,32 @@
> +/*
> + * wdt.c -- Watchdog support command
> + *
> + * Copyright (C) 2017
> + * Lukasz Majewski, DENX Software Engineering, lu...@denx.de.
> + *
> + * SPDX-License-Identifier:  GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +
> +static int do_wdt(cmd_tbl_t *cmdtp, int flag, int argc,
> +   char * const argv[])
> +{
> + int ret = CMD_RET_SUCCESS;
> +
> + if (argc < 2 || argc > 2)
> + return CMD_RET_USAGE;
> +
> + if (!strcmp(argv[1], "disable")) {
> + WATCHDOG_DISABLE();
> + printf("WDT disabled\n");
> + }
> +
> + return ret;
> +}
> +
> +U_BOOT_CMD(wdt, CONFIG_SYS_MAXARGS, 1, do_wdt,
> + "Watchdog (wdt)",
> + "disable - disable watchdog\n"
> +);
> diff --git a/include/watchdog.h b/include/watchdog.h
> index 174c894..b0716c5 100644
> --- a/include/watchdog.h
> +++ b/include/watchdog.h
> @@ -41,8 +41,10 @@ int init_func_watchdog_reset(void);
>   #define WATCHDOG_RESET bl hw_watchdog_reset
>   #else
>   extern void hw_watchdog_reset(void);
> + void hw_watchdog_disable(void);
>  
>   #define WATCHDOG_RESET hw_watchdog_reset
> + #define WATCHDOG_DISABLE hw_watchdog_disable
>   #endif /* __ASSEMBLY__ */
>  #else
>   /*

Can we add other commands, enable (calling _init() or _reset(),
I'm not sure which off the top of my head) as well?  And we may want to
think how to handle that only "omap" and "xilinx_tb" support the
_disable function today.

-- 
Tom


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


Re: [U-Boot] [PATCH v6 1/3] arm: dts: update Meson GXBB / Odroid-C2 DT with latest Linux version

2017-03-02 Thread Jaehoon Chung
On 02/21/2017 04:25 AM, Heiner Kallweit wrote:
> As a prerequisite for adding a Meson GX MMC driver update the
> Meson GXBB / Odroid-C2 device tree in Uboot with the latest
> version from Linux.
> 
> Signed-off-by: Neil Armstrong 
> Signed-off-by: Carlo Caione 
> Signed-off-by: Andreas Färber 
> Signed-off-by: Heiner Kallweit 

I didn't have the board relevant to these patches, i want to get the tested or 
reviewed tags.

Best Regards,
Jaehoon Chung

> ---
> v4:
> - Added SoB of original authors
> v5:
> - no changes
> v6:
> - changed prefix in subject
> ---
> +#endif
> 

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


Re: [U-Boot] [PATCH] fastboot: avoid printing invalid data

2017-03-02 Thread Steve Rae
Hi John,

On Mon, Sep 19, 2016 at 2:59 AM, John Keeping  wrote:

> There is no guarantee that commands are null-terminated in the USB
> request buffer, so limit the length of data that is printed.
>
> Signed-off-by: John Keeping 
> ---
>
>  drivers/usb/gadget/f_fastboot.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/gadget/f_fastboot.c
> b/drivers/usb/gadget/f_fastboot.c
> index 2160b1c..a020b7d 100644
> --- a/drivers/usb/gadget/f_fastboot.c
> +++ b/drivers/usb/gadget/f_fastboot.c
> @@ -710,7 +710,7 @@ static void rx_handler_command(struct usb_ep *ep,
> struct usb_request *req)
> }
>
> if (!func_cb) {
> -   error("unknown command: %s", cmdbuf);
> +   error("unknown command: %.*s", req->actual, cmdbuf);
> fastboot_tx_write_str("FAILunknown command");
> } else {
> if (req->actual < req->length) {
> --
> 2.9.3.728.g30b24b4.dirty
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>

This change looks OK -- but since it is the first time that "%.*s" is used
with "error()" in U-Boot; I created a test build in order to hit this error
condition and ensured that it works correctly!
Thanks!

Tested-by: Steve Rae 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [linux-sunxi] [PATCH 11/17] sunxi: SPL: add FIT config selector for Pine64 boards

2017-03-02 Thread André Przywara
On 01/03/17 03:03, Icenowy Zheng wrote:
> 
> 
> 01.03.2017, 10:26, "Andre Przywara" :
>> For a board or platform to support FIT loading in the SPL, it has to
>> provide a board_fit_config_name_match() routine, which helps to select
>> one of possibly multiple DTBs contained in a FIT image.
>> Provide a simple function which chooses the DT name U-Boot was
>> configured with.
>> If the DT name is one of the two Pine64 versions, determine the exact
>> model by checking the DRAM size.
>>
> 
> I think we shouldn't have is specially for Pine64 here, but make a framework
> for other boards that can be easily checked.
> 
> Then make Pine64 series the first user of this framework.

Well, actually this whole board_fit_config_name_match() *is* the
framework to differentiate boards at runtime. I don't see a reason why
we should make it more complicated than it already is.
With that last patch in the series we leave it to the SPL header to
select the board.

So it's really just the two different Pine64 models that need extra hand
holding here.

So I would hold off the magic framework until we know that we really
need it (a second user) and *what* we really need.

Cheers,
Andre.

> 
>> Signed-off-by: Andre Przywara 
>> ---
>>  board/sunxi/board.c | 23 +++
>>  1 file changed, 23 insertions(+)
>>
>> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
>> index a510422..2ddff28 100644
>> --- a/board/sunxi/board.c
>> +++ b/board/sunxi/board.c
>> @@ -725,3 +725,26 @@ int ft_board_setup(void *blob, bd_t *bd)
>>  #endif
>>  return 0;
>>  }
>> +
>> +#ifdef CONFIG_SPL_LOAD_FIT
>> +int board_fit_config_name_match(const char *name)
>> +{
>> + const char *cmp_str;
>> +
>> +#ifdef CONFIG_DEFAULT_DEVICE_TREE
>> + cmp_str = CONFIG_DEFAULT_DEVICE_TREE;
>> +#else
>> + return 0;
>> +#endif
>> +
>> +/* Differentiate the two Pine64 board DTs by their DRAM size. */
>> + if (strstr(name, "-pine64") && strstr(cmp_str, "-pine64")) {
>> + if ((gd->ram_size > 512 * 1024 * 1024))
>> + return !strstr(name, "plus");
>> + else
>> + return !!strstr(name, "plus");
>> + } else {
>> + return strcmp(name, cmp_str);
>> + }
>> +}
>> +#endif
>> --
>> 2.8.2
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "linux-sunxi" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to linux-sunxi+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/listinfo/u-boot
> 

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


[U-Boot] [PATCH] cmd: wdt: Add "wdt disable" command

2017-03-02 Thread Lukasz Majewski
Add support for "wdt disable" command necessary for disabling the watchdog
timer.

Signed-off-by: Lukasz Majewski 
---
 cmd/Kconfig|  6 ++
 cmd/Makefile   |  2 ++
 cmd/wdt.c  | 32 
 include/watchdog.h |  2 ++
 4 files changed, 42 insertions(+)
 create mode 100644 cmd/wdt.c

diff --git a/cmd/Kconfig b/cmd/Kconfig
index e339d86..293e0bb 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -426,6 +426,12 @@ config CMD_REMOTEPROC
help
  Support for Remote Processor control
 
+config CMD_WDT
+   bool "wdt"
+   default n
+   help
+ Enables the "wdt" command, which is used to control a watchdog timer.
+
 config CMD_GPIO
bool "gpio"
help
diff --git a/cmd/Makefile b/cmd/Makefile
index 9c9a9d1..4934427 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -157,6 +157,8 @@ obj-$(CONFIG_CMD_ETHSW) += ethsw.o
 # Power
 obj-$(CONFIG_CMD_PMIC) += pmic.o
 obj-$(CONFIG_CMD_REGULATOR) += regulator.o
+
+obj-$(CONFIG_CMD_WDT) += wdt.o
 endif # !CONFIG_SPL_BUILD
 
 obj-$(CONFIG_CMD_BLOB) += blob.o
diff --git a/cmd/wdt.c b/cmd/wdt.c
new file mode 100644
index 000..aeaa9c2
--- /dev/null
+++ b/cmd/wdt.c
@@ -0,0 +1,32 @@
+/*
+ * wdt.c -- Watchdog support command
+ *
+ * Copyright (C) 2017
+ * Lukasz Majewski, DENX Software Engineering, lu...@denx.de.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+
+static int do_wdt(cmd_tbl_t *cmdtp, int flag, int argc,
+ char * const argv[])
+{
+   int ret = CMD_RET_SUCCESS;
+
+   if (argc < 2 || argc > 2)
+   return CMD_RET_USAGE;
+
+   if (!strcmp(argv[1], "disable")) {
+   WATCHDOG_DISABLE();
+   printf("WDT disabled\n");
+   }
+
+   return ret;
+}
+
+U_BOOT_CMD(wdt, CONFIG_SYS_MAXARGS, 1, do_wdt,
+   "Watchdog (wdt)",
+   "disable - disable watchdog\n"
+);
diff --git a/include/watchdog.h b/include/watchdog.h
index 174c894..b0716c5 100644
--- a/include/watchdog.h
+++ b/include/watchdog.h
@@ -41,8 +41,10 @@ int init_func_watchdog_reset(void);
#define WATCHDOG_RESET bl hw_watchdog_reset
#else
extern void hw_watchdog_reset(void);
+   void hw_watchdog_disable(void);
 
#define WATCHDOG_RESET hw_watchdog_reset
+   #define WATCHDOG_DISABLE hw_watchdog_disable
#endif /* __ASSEMBLY__ */
 #else
/*
-- 
2.1.4

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


Re: [U-Boot] [PATCH] drivers/usb/ehci: Use platform-specific accessors

2017-03-02 Thread Marek Vasut

On 03/01/2017 01:52 PM, Alexey Brodkin wrote:

Hi Marek,

On Fri, 2017-02-10 at 21:33 +0100, Marek Vasut wrote:

On 02/10/2017 09:23 PM, Alexey Brodkin wrote:


Current implementation doesn't allow utilization of platform-specific
reads and writes.

But some arches or platforms may want to use their accessors that do
some extra work like adding barriers for data serialization etc.

Interesting enough OHCI accessors already do that so just aligning
EHCI to it now.

Signed-off-by: Alexey Brodkin 
Cc: Marek Vasut 
Cc: Simon Glass 
Cc: Mateusz Kulikowski 


IMO looks OK,

Acked-by: Marek Vasut 

I'd like to have a few more reviews of this before applying it for
2017.05 . Also CCing Wills, it'd be great to get a test on atheros
MIPS .


It's been quite some time since your request to try the patch
on other systems and so far nobody answered. May we consider that
one for application then?

Essentially I'm not talking about current Tom's master branch
but would be good if the patch lands somewhere and once 2017.03
gets cut is merged in the main branch?


Yeah, it's not happening for 2017.03, it'll go into the next one.

Can you just rebase and repost the patch please ? I'll get to it next 
week, I'm traveling until the 10th.



-Alexey



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


Re: [U-Boot] [PATCH v2 2/8] Revert "spi: cadence_qspi_apb: Use 32 bit indirect read transaction when possible"

2017-03-02 Thread Marek Vasut

On 03/01/2017 05:36 PM, Rush, Jason A. wrote:

This reverts commit b63b46313ed29e9b0c36b3d6b9407f6eade40c8f.

The Cadence QSPI device does not work with caching (introduced with
the bounce buffer in this commit) on the Altera SoC platform.

Signed-off-by: Jason A. Rush 


Do we really need the reverts or can we just fix the commit(s) up somehow ?


---
Changed in v2: None

 drivers/spi/cadence_qspi_apb.c | 22 ++
 1 file changed, 6 insertions(+), 16 deletions(-)

diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
index a6787c3b47..df6a91fc9f 100644
--- a/drivers/spi/cadence_qspi_apb.c
+++ b/drivers/spi/cadence_qspi_apb.c
@@ -633,8 +633,6 @@ int cadence_qspi_apb_indirect_read_execute(struct 
cadence_spi_platdata *plat,
 {
unsigned int remaining = n_rx;
unsigned int bytes_to_read = 0;
-   struct bounce_buffer bb;
-   u8 *bb_rxbuf;
int ret;

writel(n_rx, plat->regbase + CQSPI_REG_INDIRECTRDBYTES);
@@ -643,11 +641,6 @@ int cadence_qspi_apb_indirect_read_execute(struct 
cadence_spi_platdata *plat,
writel(CQSPI_REG_INDIRECTRD_START,
   plat->regbase + CQSPI_REG_INDIRECTRD);

-   ret = bounce_buffer_start(&bb, (void *)rxbuf, n_rx, GEN_BB_WRITE);
-   if (ret)
-   return ret;
-   bb_rxbuf = bb.bounce_buffer;
-
while (remaining > 0) {
ret = cadence_qspi_wait_for_data(plat);
if (ret < 0) {
@@ -661,13 +654,12 @@ int cadence_qspi_apb_indirect_read_execute(struct 
cadence_spi_platdata *plat,
bytes_to_read *= CQSPI_FIFO_WIDTH;
bytes_to_read = bytes_to_read > remaining ?
remaining : bytes_to_read;
-   readsl(plat->ahbbase, bb_rxbuf, bytes_to_read >> 2);
-   if (bytes_to_read % 4)
-   readsb(plat->ahbbase,
-  bb_rxbuf + rounddown(bytes_to_read, 4),
-  bytes_to_read % 4);
-
-   bb_rxbuf += bytes_to_read;
+   /* Handle non-4-byte aligned access to avoid data 
abort. */
+   if (((uintptr_t)rxbuf % 4) || (bytes_to_read % 4))
+   readsb(plat->ahbbase, rxbuf, bytes_to_read);
+   else
+   readsl(plat->ahbbase, rxbuf, bytes_to_read >> 
2);
+   rxbuf += bytes_to_read;
remaining -= bytes_to_read;
bytes_to_read = cadence_qspi_get_rd_sram_level(plat);
}
@@ -684,7 +676,6 @@ int cadence_qspi_apb_indirect_read_execute(struct 
cadence_spi_platdata *plat,
/* Clear indirect completion status */
writel(CQSPI_REG_INDIRECTRD_DONE,
   plat->regbase + CQSPI_REG_INDIRECTRD);
-   bounce_buffer_stop(&bb);

return 0;

@@ -692,7 +683,6 @@ failrd:
/* Cancel the indirect read */
writel(CQSPI_REG_INDIRECTRD_CANCEL,
   plat->regbase + CQSPI_REG_INDIRECTRD);
-   bounce_buffer_stop(&bb);
return ret;
 }




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


Re: [U-Boot] arm: cache: misaligned operation with fastboot

2017-03-02 Thread Steve Rae
Hi Gary,

On Thu, Mar 2, 2017 at 3:12 AM, Lukasz Majewski  wrote:

> Hi,
>
> > Hi Fabio, Lukasz,
> >
> > On Wed, Feb 15, 2017 at 02:24:40PM -0200, Fabio Estevam wrote:
> > > On Wed, Feb 15, 2017 at 2:04 PM, Gary Bisson
> > >  wrote:
> > > > Hi,
> > > >
> > > > I've been testing fastboot to flash a sparse image on a i.MX6Q
> > > > platform (Nitrogen6x) with U-Boot v2017.01.
> > > >
> > > > This test shows a lot of "misaligned operation" traces:
> > > > => fastboot 0
> > > > Starting download of 415679660 bytes
> > > > ...
> > > > downloading of 415679660 bytes finished
> > > > Flashing sparse image at offset 82124
> > > > Flashing Sparse Image
> > > > CACHE: Misaligned operation at range [1228, 12028028]
> > > > CACHE: Misaligned operation at range [12028044, 1208f044]
> > > > CACHE: Misaligned operation at range [1208f060, 123fd060]
> > > > ...
> > > >
> > > > Has any of you seen that behavior?
> > > >
> > > > Note that this behavior only happens for sparse images, flashing
> > > > a raw image doesn't exhibit the problem.
> > >
> > > Adding DFU maintainer, Lukasz on Cc.
> >
> > Any update on this? Has anyone been able to reproduce?
>
> I don't have setup to test the fastboot.
>
> I can integrate patches (to -dfu) tree if you have one.
>
> >
> > Regards,
> > Gary
>
>
>
>
> Best regards,
>
> Lukasz Majewski
>
> --
>
> 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
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/listinfo/u-boot
>

yes -- I have seen these warning messages when flashing a "sparse" image
- they don't seem to cause any issues,
- I haven't had time to investigate yet
Thanks, Steve
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/listinfo/u-boot


Re: [U-Boot] TODO list for u-boot

2017-03-02 Thread Sebastian Panceac
Oh, I forgot to mention but I think is important in this context: I also
have access to oscilloscope and logic analyzer.

Thank you!

On Thu, Mar 2, 2017 at 9:40 PM, Sebastian Panceac 
wrote:

> I can't really say at what part I could contribute.
> That's why I was hoping for a TODO list so I could chose something
>  according to my skills.
> The hardware I have access to is:  Raspi v1 and some custom boards with
> Freescale IMX6 SoC.
>
> Thank you!
>
> On Wed, Feb 22, 2017 at 10:11 AM, Lukasz Majewski  wrote:
>
>> On Mon, 20 Feb 2017 17:19:31 +0200
>> Sebastian Panceac  wrote:
>>
>> > Hi everyone,
>> >
>> > I was looking through the TO DO list of u-boot, because I want to
>> > contribute to the project.
>>
>> Great :-)
>>
>> >
>> > This list here seems to be outdated
>> > http://www.denx.de/wiki/U-Boot/Tasks. For example I checked the "Set
>> > Environment to Default Values" task from the list, and it's seems to
>> > be implemented now. The "Group Environment Variables" TODO doesn't
>> > seem to be implemented. Is this feature still wanted?
>> >
>> > Is there any updated list of TODOs?
>>
>> If I might ask, what tasks are the most interesting ones for you?
>>
>> To what kind of HW do you have access?
>>
>> >
>> > Thank you!
>> > ___
>> > U-Boot mailing list
>> > U-Boot@lists.denx.de
>> > http://lists.denx.de/mailman/listinfo/u-boot
>>
>>
>>
>>
>> Best regards,
>>
>> Lukasz Majewski
>>
>> --
>>
>> 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
>>
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 01/31] ti: common: board_detect: Allow settings board detection variables manually

2017-03-02 Thread Franklin S Cooper Jr


On 03/02/2017 01:10 PM, Felipe Balbi wrote:
> 
> Hi,
> 
> Franklin S Cooper Jr  writes:
>> From: Nishanth Menon 
>>
>> In some situations the EEPROM used for board detection may not be
>> programmed or simply programmed incorrectly. Therefore, it may be
>> necessary to "simulate" reading the contents of the EEPROM to set
>> appropriate variables used in the board detection code.
>>
>> This may also be helpful in certain boot modes where doing i2c reads
>> may be costly and the config supports running only a specific board.
>>
>> Signed-off-by: Nishanth Menon 
>> Signed-off-by: Tero Kristo 
>> Signed-off-by: Keerthy 
>> Signed-off-by: Franklin S Cooper Jr. 
>> ---
>>  board/ti/common/board_detect.c | 24 
>>  board/ti/common/board_detect.h | 17 +
>>  2 files changed, 41 insertions(+)
>>
>> diff --git a/board/ti/common/board_detect.c b/board/ti/common/board_detect.c
>> index a5dba94..5aaf884 100644
>> --- a/board/ti/common/board_detect.c
>> +++ b/board/ti/common/board_detect.c
>> @@ -116,6 +116,30 @@ static int __maybe_unused ti_i2c_eeprom_get(int 
>> bus_addr, int dev_addr,
>>  return 0;
>>  }
>>  
>> +int __maybe_unused ti_i2c_eeprom_am_set(const char *name, const char *rev)
>> +{
>> +struct ti_common_eeprom *ep;
>> +
>> +if (!name || !rev)
>> +return -1;
>> +
>> +ep = TI_EEPROM_DATA;
>> +if (ep->header == TI_EEPROM_HEADER_MAGIC)
>> +goto already_set;
>> +
>> +/* Set to 0 all fields */
>> +memset(ep, 0, sizeof(*ep));
>> +strncpy(ep->name, name, TI_EEPROM_HDR_NAME_LEN);
>> +strncpy(ep->version, rev, TI_EEPROM_HDR_REV_LEN);
>> +/* Some dummy serial number to identify the platform */
>> +strncpy(ep->serial, "", TI_EEPROM_HDR_SERIAL_LEN);
>> +/* Mark it with a valid header */
>> +ep->header = TI_EEPROM_HEADER_MAGIC;
>> +
>> +already_set:
>> +return 0;
>> +}
>> +
>>  int __maybe_unused ti_i2c_eeprom_am_get(int bus_addr, int dev_addr)
>>  {
>>  int rc;
>> diff --git a/board/ti/common/board_detect.h b/board/ti/common/board_detect.h
>> index 343fcb4..eeeacd3 100644
>> --- a/board/ti/common/board_detect.h
>> +++ b/board/ti/common/board_detect.h
>> @@ -193,4 +193,21 @@ u64 board_ti_get_emif2_size(void);
>>   */
>>  void set_board_info_env(char *name);
>>  
>> +/**
>> + * ti_i2c_eeprom_am_set() - Setup the eeprom data with predefined values
>> + * @name:   Name of the board
>> + * @rev:Revision of the board
>> + *
>> + * In some cases such as in RTC-only mode, we are able to skip reading 
>> eeprom
>> + * and wasting i2c based initialization time by using predefined flags for
>> + * detecting what platform we are booting on. For those platforms, provide
>> + * a handy function to pre-program information.
> 
> there's a micro-optimization for some cases here. You can try to read
> i2c only on first time and save the result to environment. Something
> like:
> 
> if (!getenv("serial#")) {
>   read_serial_from_eeprom(&serial);
> setenv("serial#", serial);
> saveenv();
> }
> 
> Of course, this assumes i2c is available and eeprom is properly
> programmed. For bogus eeprom data, well, can't do much.

Atleast for the purposes I'm using it for I have to deal with non
programmed eeprom. The other usecase I've seen was wanting to avoid
touching the EEPROM at all.
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/listinfo/u-boot


Re: [U-Boot] TODO list for u-boot

2017-03-02 Thread Sebastian Panceac
I can't really say at what part I could contribute.
That's why I was hoping for a TODO list so I could chose something
 according to my skills.
The hardware I have access to is:  Raspi v1 and some custom boards with
Freescale IMX6 SoC.

Thank you!

On Wed, Feb 22, 2017 at 10:11 AM, Lukasz Majewski  wrote:

> On Mon, 20 Feb 2017 17:19:31 +0200
> Sebastian Panceac  wrote:
>
> > Hi everyone,
> >
> > I was looking through the TO DO list of u-boot, because I want to
> > contribute to the project.
>
> Great :-)
>
> >
> > This list here seems to be outdated
> > http://www.denx.de/wiki/U-Boot/Tasks. For example I checked the "Set
> > Environment to Default Values" task from the list, and it's seems to
> > be implemented now. The "Group Environment Variables" TODO doesn't
> > seem to be implemented. Is this feature still wanted?
> >
> > Is there any updated list of TODOs?
>
> If I might ask, what tasks are the most interesting ones for you?
>
> To what kind of HW do you have access?
>
> >
> > Thank you!
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > http://lists.denx.de/mailman/listinfo/u-boot
>
>
>
>
> Best regards,
>
> Lukasz Majewski
>
> --
>
> 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
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 27/31] ARM: k2g: Update board_name u-boot env variable at runtime

2017-03-02 Thread Franklin S Cooper Jr
Enable CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG to allow "board_name" to
be set depending on the board it is being ran on.

Update findfdt to use this new dynamic board_name value to determine
which dtb should be used.

Signed-off-by: Franklin S Cooper Jr 
---
 board/ti/ks2_evm/board_k2g.c | 13 +
 include/configs/k2g_evm.h| 14 --
 2 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/board/ti/ks2_evm/board_k2g.c b/board/ti/ks2_evm/board_k2g.c
index 0fbc64a..70164ee 100644
--- a/board/ti/ks2_evm/board_k2g.c
+++ b/board/ti/ks2_evm/board_k2g.c
@@ -198,6 +198,19 @@ int embedded_dtb_select(void)
 }
 #endif
 
+#ifdef CONFIG_BOARD_LATE_INIT
+int board_late_init(void)
+{
+#ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
+   if (board_is_k2g_gp())
+   setenv("board_name", "66AK2GGP\0");
+   else if (board_is_k2g_ice())
+   setenv("board_name", "66AK2GIC\0");
+#endif
+   return 0;
+}
+#endif
+
 #ifdef CONFIG_BOARD_EARLY_INIT_F
 int board_early_init_f(void)
 {
diff --git a/include/configs/k2g_evm.h b/include/configs/k2g_evm.h
index bd25231..0d11e4e 100644
--- a/include/configs/k2g_evm.h
+++ b/include/configs/k2g_evm.h
@@ -13,6 +13,9 @@
 /* Platform type */
 #define CONFIG_SOC_K2G
 
+#define CONFIG_BOARD_LATE_INIT
+#define CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
+
 /* U-Boot general configuration */
 #define CONFIG_EXTRA_ENV_KS2_BOARD_SETTINGS\
DEFAULT_MMC_TI_ARGS \
@@ -25,7 +28,14 @@
"rd_spec=-\0"   \
"args_ubi=setenv bootargs ${bootargs} rootfstype=ubifs "\
"root=ubi0:rootfs rootflags=sync rw ubi.mtd=ubifs,2048\0"   \
-   "name_fdt=keystone-k2g-evm.dtb\0"   \
+   "findfdt="\
+   "if test $board_name = 66AK2GGP; then " \
+"setenv name_fdt keystone-k2g-evm.dtb; " \
+   "else if test $board_name = 66AK2GIC; then " \
+"setenv name_fdt keystone-k2g-ice.dtb; " \
+   "else if test $name_fdt = undefined; then " \
+   "echo WARNING: Could not determine device tree to use;"\
+   "fi;fi;fi;\0" \
"name_mon=skern-k2g.bin\0"  \
"name_ubi=k2g-evm-ubifs.ubi\0"  \
"name_uboot=u-boot-spi-k2g-evm.gph\0"   \
@@ -43,7 +53,7 @@
"run envboot; " \
"run set_name_pmmc init_${boot} init_fw_rd_${boot} "\
"get_pmmc_${boot} run_pmmc get_mon_${boot} run_mon "\
-   "get_fdt_${boot} get_kern_${boot} run_kern"
+   "findfdt get_fdt_${boot} get_kern_${boot} run_kern"
 
 #include 
 
-- 
2.10.0

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


Re: [U-Boot] [PATCH 01/31] ti: common: board_detect: Allow settings board detection variables manually

2017-03-02 Thread Felipe Balbi

Hi,

Franklin S Cooper Jr  writes:
> From: Nishanth Menon 
>
> In some situations the EEPROM used for board detection may not be
> programmed or simply programmed incorrectly. Therefore, it may be
> necessary to "simulate" reading the contents of the EEPROM to set
> appropriate variables used in the board detection code.
>
> This may also be helpful in certain boot modes where doing i2c reads
> may be costly and the config supports running only a specific board.
>
> Signed-off-by: Nishanth Menon 
> Signed-off-by: Tero Kristo 
> Signed-off-by: Keerthy 
> Signed-off-by: Franklin S Cooper Jr. 
> ---
>  board/ti/common/board_detect.c | 24 
>  board/ti/common/board_detect.h | 17 +
>  2 files changed, 41 insertions(+)
>
> diff --git a/board/ti/common/board_detect.c b/board/ti/common/board_detect.c
> index a5dba94..5aaf884 100644
> --- a/board/ti/common/board_detect.c
> +++ b/board/ti/common/board_detect.c
> @@ -116,6 +116,30 @@ static int __maybe_unused ti_i2c_eeprom_get(int 
> bus_addr, int dev_addr,
>   return 0;
>  }
>  
> +int __maybe_unused ti_i2c_eeprom_am_set(const char *name, const char *rev)
> +{
> + struct ti_common_eeprom *ep;
> +
> + if (!name || !rev)
> + return -1;
> +
> + ep = TI_EEPROM_DATA;
> + if (ep->header == TI_EEPROM_HEADER_MAGIC)
> + goto already_set;
> +
> + /* Set to 0 all fields */
> + memset(ep, 0, sizeof(*ep));
> + strncpy(ep->name, name, TI_EEPROM_HDR_NAME_LEN);
> + strncpy(ep->version, rev, TI_EEPROM_HDR_REV_LEN);
> + /* Some dummy serial number to identify the platform */
> + strncpy(ep->serial, "", TI_EEPROM_HDR_SERIAL_LEN);
> + /* Mark it with a valid header */
> + ep->header = TI_EEPROM_HEADER_MAGIC;
> +
> +already_set:
> + return 0;
> +}
> +
>  int __maybe_unused ti_i2c_eeprom_am_get(int bus_addr, int dev_addr)
>  {
>   int rc;
> diff --git a/board/ti/common/board_detect.h b/board/ti/common/board_detect.h
> index 343fcb4..eeeacd3 100644
> --- a/board/ti/common/board_detect.h
> +++ b/board/ti/common/board_detect.h
> @@ -193,4 +193,21 @@ u64 board_ti_get_emif2_size(void);
>   */
>  void set_board_info_env(char *name);
>  
> +/**
> + * ti_i2c_eeprom_am_set() - Setup the eeprom data with predefined values
> + * @name:Name of the board
> + * @rev: Revision of the board
> + *
> + * In some cases such as in RTC-only mode, we are able to skip reading eeprom
> + * and wasting i2c based initialization time by using predefined flags for
> + * detecting what platform we are booting on. For those platforms, provide
> + * a handy function to pre-program information.

there's a micro-optimization for some cases here. You can try to read
i2c only on first time and save the result to environment. Something
like:

if (!getenv("serial#")) {
read_serial_from_eeprom(&serial);
setenv("serial#", serial);
saveenv();
}

Of course, this assumes i2c is available and eeprom is properly
programmed. For bogus eeprom data, well, can't do much.

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


[U-Boot] [PATCH 14/31] ARM: keystone2: Allow to build with all image formats

2017-03-02 Thread Franklin S Cooper Jr
u-boot.bin is a copy of:
u-boot-fit-dtb.bin if CONFIG_FIT_EMBED is enabled,
u-boot-dtb.bin if CONFIG_OF_SEPARATE is enabled,
u-boot-nodtb.bin if DT is not enabled.
So, use u-boot.bin to to generate keystone images instead of
u-boot-dtb.bin

Signed-off-by: Franklin S Cooper Jr 
---
 arch/arm/mach-keystone/config.mk | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-keystone/config.mk b/arch/arm/mach-keystone/config.mk
index 9ae1e9a..ceacffa 100644
--- a/arch/arm/mach-keystone/config.mk
+++ b/arch/arm/mach-keystone/config.mk
@@ -16,13 +16,13 @@ spl/u-boot-spl.gph: spl/u-boot-spl.bin FORCE
 
 OBJCOPYFLAGS_u-boot-spi.gph = -I binary -O binary 
--pad-to=$(CONFIG_SPL_PAD_TO) \
  --gap-fill=0
-u-boot-spi.gph: spl/u-boot-spl.gph u-boot-dtb.img FORCE
+u-boot-spi.gph: spl/u-boot-spl.gph u-boot.img FORCE
$(call if_changed,pad_cat)
 
 ifndef CONFIG_SPL_BUILD
 MKIMAGEFLAGS_MLO = -A $(ARCH) -T gpimage -C none \
-a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_TEXT_BASE) -n U-Boot
-MLO: u-boot-dtb.bin FORCE
+MLO: u-boot.bin FORCE
$(call if_changed,mkimage)
@dd if=/dev/zero bs=8 count=1 2>/dev/null >> $@
 endif
-- 
2.10.0

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


[U-Boot] [PATCH 09/31] ti_armv7_keystone2: Define scratch space in SRAM

2017-03-02 Thread Franklin S Cooper Jr
Scratch space can be used for features such as board detection. Define
an area within SRAM that can be used for this purpose.

Signed-off-by: Franklin S Cooper Jr 
Signed-off-by: Roger Quadros 
---
 include/configs/ti_armv7_keystone2.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/include/configs/ti_armv7_keystone2.h 
b/include/configs/ti_armv7_keystone2.h
index 5d4ef58..f76e0a5 100644
--- a/include/configs/ti_armv7_keystone2.h
+++ b/include/configs/ti_armv7_keystone2.h
@@ -55,6 +55,13 @@
 #define CONFIG_SPL_SPI_LOAD
 #define CONFIG_SYS_SPI_U_BOOT_OFFS CONFIG_SPL_PAD_TO
 
+/* SRAM scratch space entries  */
+#define SRAM_SCRATCH_SPACE_ADDRCONFIG_SPL_STACK + 0x8
+
+#define TI_SRAM_SCRATCH_BOARD_EEPROM_START (SRAM_SCRATCH_SPACE_ADDR)
+#define TI_SRAM_SCRATCH_BOARD_EEPROM_END   (SRAM_SCRATCH_SPACE_ADDR + 
0x200)
+#define KEYSTONE_SRAM_SCRATCH_SPACE_END
(TI_SRAM_SCRATCH_BOARD_EEPROM_END)
+
 /* UART Configuration */
 #define CONFIG_SYS_NS16550_MEM32
 #if defined(CONFIG_SPL_BUILD) || !defined(CONFIG_DM_SERIAL)
-- 
2.10.0

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


[U-Boot] [PATCH 31/31] defconfig: k2g_evm_defconfig: Add K2G ICE to OF_LIST

2017-03-02 Thread Franklin S Cooper Jr
Include K2G ICE to OF_LIST so it can be used for runtime board
detection.

Signed-off-by: Franklin S Cooper Jr 
---
 configs/k2g_evm_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configs/k2g_evm_defconfig b/configs/k2g_evm_defconfig
index 1352877..ed94f19 100644
--- a/configs/k2g_evm_defconfig
+++ b/configs/k2g_evm_defconfig
@@ -60,4 +60,4 @@ CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_STORAGE=y
 CONFIG_DTB_RESELECT=y
 CONFIG_FIT_EMBED=y
-CONFIG_OF_LIST="keystone-k2g-generic keystone-k2g-evm"
+CONFIG_OF_LIST="keystone-k2g-generic keystone-k2g-evm keystone-k2g-ice"
-- 
2.10.0

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


[U-Boot] [PATCH 16/31] ARM: keystone2: Define board_fit_config_name_match for Keystone 2 boards

2017-03-02 Thread Franklin S Cooper Jr
Now with support for U-boot runtime dtb selection each board needs to
define board_fit_config_name_match so U-boot can determine what the
correct dtb is within the FIT blob.

Signed-off-by: Franklin S Cooper Jr 
---
 board/ti/ks2_evm/board_k2e.c  | 10 ++
 board/ti/ks2_evm/board_k2g.c  | 14 ++
 board/ti/ks2_evm/board_k2hk.c | 10 ++
 board/ti/ks2_evm/board_k2l.c  | 10 ++
 4 files changed, 44 insertions(+)

diff --git a/board/ti/ks2_evm/board_k2e.c b/board/ti/ks2_evm/board_k2e.c
index cbb3077..4bbcf2d 100644
--- a/board/ti/ks2_evm/board_k2e.c
+++ b/board/ti/ks2_evm/board_k2e.c
@@ -148,6 +148,16 @@ int get_num_eth_ports(void)
 }
 #endif
 
+#if defined(CONFIG_FIT_EMBED)
+int board_fit_config_name_match(const char *name)
+{
+   if (!strcmp(name, "keystone-k2e-evm"))
+   return 0;
+
+   return -1;
+}
+#endif
+
 #if defined(CONFIG_BOARD_EARLY_INIT_F)
 int board_early_init_f(void)
 {
diff --git a/board/ti/ks2_evm/board_k2g.c b/board/ti/ks2_evm/board_k2g.c
index 110d9cf..d47b43d 100644
--- a/board/ti/ks2_evm/board_k2g.c
+++ b/board/ti/ks2_evm/board_k2g.c
@@ -120,6 +120,20 @@ int board_mmc_init(bd_t *bis)
 }
 #endif
 
+#if defined(CONFIG_FIT_EMBED)
+int board_fit_config_name_match(const char *name)
+{
+   bool eeprom_read = board_ti_was_eeprom_read();
+
+   if (!strcmp(name, "keystone-k2g-generic") && !eeprom_read)
+   return 0;
+   else if (!strcmp(name, "keystone-k2g-evm") && board_ti_is("66AK2GGP"))
+   return 0;
+   else
+   return -1;
+}
+#endif
+
 #if defined(CONFIG_DTB_RESELECT)
 static int k2g_alt_board_detect(void)
 {
diff --git a/board/ti/ks2_evm/board_k2hk.c b/board/ti/ks2_evm/board_k2hk.c
index e217bea..6f2246f 100644
--- a/board/ti/ks2_evm/board_k2hk.c
+++ b/board/ti/ks2_evm/board_k2hk.c
@@ -119,6 +119,16 @@ int board_early_init_f(void)
 }
 #endif
 
+#if defined(CONFIG_FIT_EMBED)
+int board_fit_config_name_match(const char *name)
+{
+   if (!strcmp(name, "keystone-k2hk-evm"))
+   return 0;
+
+   return -1;
+}
+#endif
+
 #ifdef CONFIG_SPL_BUILD
 void spl_init_keystone_plls(void)
 {
diff --git a/board/ti/ks2_evm/board_k2l.c b/board/ti/ks2_evm/board_k2l.c
index 2a2e005..dfd8216 100644
--- a/board/ti/ks2_evm/board_k2l.c
+++ b/board/ti/ks2_evm/board_k2l.c
@@ -118,6 +118,16 @@ int board_early_init_f(void)
 }
 #endif
 
+#if defined(CONFIG_FIT_EMBED)
+int board_fit_config_name_match(const char *name)
+{
+   if (!strcmp(name, "keystone-k2l-evm"))
+   return 0;
+
+   return -1;
+}
+#endif
+
 #ifdef CONFIG_SPL_BUILD
 void spl_init_keystone_plls(void)
 {
-- 
2.10.0

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


[U-Boot] [PATCH 17/31] ks2_evm: Add EEPROM based board detection

2017-03-02 Thread Franklin S Cooper Jr
Some K2G evms have their EEPROM programming while most do not. Therefore,
add EEPROM board detection to be used as the default method and fall back
to the alternative board detection when needed.

Also reorder board configuration. Perform bare minimal configuration
initially since board detection hasn't ran. Finish board configuration
once the board has been identified.

Signed-off-by: Franklin S Cooper Jr 
---
 board/ti/ks2_evm/board.h |  1 +
 board/ti/ks2_evm/board_k2g.c | 44 +++-
 2 files changed, 24 insertions(+), 21 deletions(-)

diff --git a/board/ti/ks2_evm/board.h b/board/ti/ks2_evm/board.h
index 2bbd792..0698921 100644
--- a/board/ti/ks2_evm/board.h
+++ b/board/ti/ks2_evm/board.h
@@ -11,6 +11,7 @@
 #define _KS2_BOARD
 
 #include 
+#include "../common/board_detect.h"
 
 extern struct eth_priv_t eth_priv_cfg[];
 
diff --git a/board/ti/ks2_evm/board_k2g.c b/board/ti/ks2_evm/board_k2g.c
index d47b43d..64b1f6b 100644
--- a/board/ti/ks2_evm/board_k2g.c
+++ b/board/ti/ks2_evm/board_k2g.c
@@ -152,24 +152,6 @@ static int k2g_alt_board_detect(void)
return 0;
 }
 
-int embedded_dtb_select(void)
-{
-   int rc;
-
-   rc = k2g_alt_board_detect();
-   if (rc) {
-   printf("Unable to do board detection\n");
-   return -1;
-   }
-
-   fdtdec_setup();
-
-   return 0;
-}
-#endif
-
-#ifdef CONFIG_BOARD_EARLY_INIT_F
-
 static void k2g_reset_mux_config(void)
 {
/* Unlock the reset mux register */
@@ -183,11 +165,20 @@ static void k2g_reset_mux_config(void)
setbits_le32(KS2_RSTMUX8, RSTMUX_LOCK8_MASK);
 }
 
-int board_early_init_f(void)
+int embedded_dtb_select(void)
 {
-   init_plls();
+   int rc;
+   rc = ti_i2c_eeprom_am_get(CONFIG_EEPROM_BUS_ADDRESS,
+   CONFIG_EEPROM_CHIP_ADDRESS);
+   if (rc) {
+   rc = k2g_alt_board_detect();
+   if (rc) {
+   printf("Unable to do board detection\n");
+   return -1;
+   }
+   }
 
-   k2g_mux_config();
+   fdtdec_setup();
 
k2g_reset_mux_config();
 
@@ -201,6 +192,17 @@ int board_early_init_f(void)
 }
 #endif
 
+#ifdef CONFIG_BOARD_EARLY_INIT_F
+int board_early_init_f(void)
+{
+   init_plls();
+
+   k2g_mux_config();
+
+   return 0;
+}
+#endif
+
 #ifdef CONFIG_SPL_BUILD
 void spl_init_keystone_plls(void)
 {
-- 
2.10.0

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


[U-Boot] [PATCH 15/31] ARM: k2g: Define embedded_dtb_select for runtime DTB selection in U-boot

2017-03-02 Thread Franklin S Cooper Jr
For K2G, runtime DTB selection utilitizes the embedded_dtb_select function.
Therefore, define the function which will perform a EEPROM read and then
retries selecting the correct dtb now that it can detect which board its
on. For other Keystone devices use an empty function since they will still
use the embedded FIT functionality but their FIT will only contain a single
dtb.

Most production K2G boards do not have their EEPROM programmed. Therefore,
perform a test to verify a K2G GP is currently being used and if it is then
set the values normally set by a EEPROM read.

Signed-off-by: Franklin S Cooper Jr 
---
 board/ti/ks2_evm/board.c |  7 +++
 board/ti/ks2_evm/board_k2g.c | 38 ++
 2 files changed, 45 insertions(+)

diff --git a/board/ti/ks2_evm/board.c b/board/ti/ks2_evm/board.c
index 03254e1..4792311 100644
--- a/board/ti/ks2_evm/board.c
+++ b/board/ti/ks2_evm/board.c
@@ -277,3 +277,10 @@ void ft_board_setup_ex(void *blob, bd_t *bd)
ddr3_check_ecc_int(KS2_DDR3A_EMIF_CTRL_BASE);
 }
 #endif /* CONFIG_OF_BOARD_SETUP */
+
+#if defined(CONFIG_DTB_RESELECT)
+int __weak embedded_dtb_select(void)
+{
+   return 0;
+}
+#endif
diff --git a/board/ti/ks2_evm/board_k2g.c b/board/ti/ks2_evm/board_k2g.c
index 40edbaa..110d9cf 100644
--- a/board/ti/ks2_evm/board_k2g.c
+++ b/board/ti/ks2_evm/board_k2g.c
@@ -11,9 +11,13 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include "../common/board_detect.h"
 #include "mux-k2g.h"
 
 #define SYS_CLK2400
+#define K2G_GP_AUDIO_CODEC_ADDRESS 0x1B
 
 unsigned int external_clk[ext_clk_count] = {
[sys_clk]   =   SYS_CLK,
@@ -116,6 +120,40 @@ int board_mmc_init(bd_t *bis)
 }
 #endif
 
+#if defined(CONFIG_DTB_RESELECT)
+static int k2g_alt_board_detect(void)
+{
+   int rc;
+
+   rc = i2c_set_bus_num(1);
+   if (rc)
+   return rc;
+
+   rc = i2c_probe(K2G_GP_AUDIO_CODEC_ADDRESS);
+   if (rc)
+   return rc;
+
+   ti_i2c_eeprom_am_set("66AK2GGP", "1.0X");
+
+   return 0;
+}
+
+int embedded_dtb_select(void)
+{
+   int rc;
+
+   rc = k2g_alt_board_detect();
+   if (rc) {
+   printf("Unable to do board detection\n");
+   return -1;
+   }
+
+   fdtdec_setup();
+
+   return 0;
+}
+#endif
+
 #ifdef CONFIG_BOARD_EARLY_INIT_F
 
 static void k2g_reset_mux_config(void)
-- 
2.10.0

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


[U-Boot] [PATCH 10/31] ARM: Use Kconfig for board EEPROM's I2C bus and chip address

2017-03-02 Thread Franklin S Cooper Jr
From: Roger Quadros 

In stead of defining the board EEPROM address in the board headers
let's define them in the board config files and make them
configurable by Kconfig.

Signed-off-by: Roger Quadros 
Reviewed-by: Tom Rini 
---
 board/ti/common/Kconfig  | 20 +---
 board/ti/ks2_evm/Kconfig |  2 ++
 include/configs/am57xx_evm.h |  4 
 include/configs/dra7xx_evm.h |  4 
 4 files changed, 19 insertions(+), 11 deletions(-)

diff --git a/board/ti/common/Kconfig b/board/ti/common/Kconfig
index 4980a04..162248c 100644
--- a/board/ti/common/Kconfig
+++ b/board/ti/common/Kconfig
@@ -1,12 +1,24 @@
-config SPL_ENV_SUPPORT
-   default y
-
 config TI_I2C_BOARD_DETECT
bool "Support for Board detection for TI platforms"
help
   Support for detection board information on Texas Instrument's
   Evaluation Boards which have I2C based EEPROM detection
 
+config EEPROM_BUS_ADDRESS
+   int "Board EEPROM's I2C bus address"
+   range 0 8
+   default 0
+
+config EEPROM_CHIP_ADDRESS
+   hex "Board EEPROM's I2C chip address"
+   range 0 0xff
+   default 0x50
+
+if ARCH_OMAP2
+
+config SPL_ENV_SUPPORT
+   default y
+
 config SPL_EXT_SUPPORT
default y
 
@@ -39,3 +51,5 @@ config SPL_POWER_SUPPORT
 
 config SPL_SERIAL_SUPPORT
default y
+
+endif
diff --git a/board/ti/ks2_evm/Kconfig b/board/ti/ks2_evm/Kconfig
index c0568ec..9477f53 100644
--- a/board/ti/ks2_evm/Kconfig
+++ b/board/ti/ks2_evm/Kconfig
@@ -49,3 +49,5 @@ config SYS_CONFIG_NAME
default "k2g_evm"
 
 endif
+
+source "board/ti/common/Kconfig"
diff --git a/include/configs/am57xx_evm.h b/include/configs/am57xx_evm.h
index 3d8b996..40a3bbd 100644
--- a/include/configs/am57xx_evm.h
+++ b/include/configs/am57xx_evm.h
@@ -103,10 +103,6 @@
 #define CONFIG_SYS_SCSI_MAX_DEVICE (CONFIG_SYS_SCSI_MAX_SCSI_ID * \
CONFIG_SYS_SCSI_MAX_LUN)
 
-/* EEPROM */
-#define CONFIG_EEPROM_CHIP_ADDRESS 0x50
-#define CONFIG_EEPROM_BUS_ADDRESS 0
-
 /*
  * Default to using SPI for environment, etc.
  * 0x00 - 0x04 : QSPI.SPL (256KiB)
diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h
index 549439e..2996807 100644
--- a/include/configs/dra7xx_evm.h
+++ b/include/configs/dra7xx_evm.h
@@ -261,8 +261,4 @@
 #endif
 #endif  /* NOR support */
 
-/* EEPROM */
-#define CONFIG_EEPROM_CHIP_ADDRESS 0x50
-#define CONFIG_EEPROM_BUS_ADDRESS 0
-
 #endif /* __CONFIG_DRA7XX_EVM_H */
-- 
2.10.0

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


[U-Boot] [PATCH 07/31] arm: dts: Add new "generic" 66AK2Gx device tree file.

2017-03-02 Thread Franklin S Cooper Jr
With U-boot runtime board detect for DTB selection a "default" dtb needs
to be created. This will be used temporarily until the "proper" dtb is
selected.

Signed-off-by: Franklin S Cooper Jr 
Reviewed-by: Tom Rini 
---
 arch/arm/dts/Makefile |  3 ++-
 arch/arm/dts/keystone-k2g-generic.dts | 21 +
 2 files changed, 23 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/keystone-k2g-generic.dts

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index eb68c20..06ebbf0 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -323,7 +323,8 @@ dtb-$(CONFIG_MX7) += imx7-colibri.dtb
 dtb-$(CONFIG_SOC_KEYSTONE) += keystone-k2hk-evm.dtb \
keystone-k2l-evm.dtb \
keystone-k2e-evm.dtb \
-   keystone-k2g-evm.dtb
+   keystone-k2g-evm.dtb \
+   keystone-k2g-generic.dtb
 
 dtb-$(CONFIG_TARGET_SAMA5D2_XPLAINED) += \
at91-sama5d2_xplained.dtb
diff --git a/arch/arm/dts/keystone-k2g-generic.dts 
b/arch/arm/dts/keystone-k2g-generic.dts
new file mode 100644
index 000..cff9155
--- /dev/null
+++ b/arch/arm/dts/keystone-k2g-generic.dts
@@ -0,0 +1,21 @@
+/*
+ * Copyright 2017 Texas Instruments, Inc.
+ *
+ * 66AK2G0X Generic File
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+#include "keystone-k2g.dtsi"
+
+/ {
+   compatible =  "ti,k2g-generic", "ti,k2g", "ti,keystone";
+   model = "Texas Instruments 66AK2G02 Generic";
+
+   chosen {
+   stdout-path = &uart0;
+   };
+};
-- 
2.10.0

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


[U-Boot] [PATCH 20/31] ARM: k2g: Program DDR PHY MR2 register with the default value

2017-03-02 Thread Franklin S Cooper Jr
K2G GP doesn't require the MR2 register to be programed since the
default is good enough. However, newer K2G boards do need to change
this register value. Therefore, instead of not writing this register if
ran on a K2G board just program the value to be written to match the
default/reset value.

Signed-off-by: Franklin S Cooper Jr 
---
 arch/arm/mach-keystone/ddr3.c | 3 +--
 board/ti/ks2_evm/ddr3_k2g.c   | 2 +-
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-keystone/ddr3.c b/arch/arm/mach-keystone/ddr3.c
index ee8e12e..25a9637 100644
--- a/arch/arm/mach-keystone/ddr3.c
+++ b/arch/arm/mach-keystone/ddr3.c
@@ -52,8 +52,7 @@ void ddr3_init_ddrphy(u32 base, struct ddr3_phy_config 
*phy_cfg)
__raw_writel(phy_cfg->dtpr2, base + KS2_DDRPHY_DTPR2_OFFSET);
__raw_writel(phy_cfg->mr0,   base + KS2_DDRPHY_MR0_OFFSET);
__raw_writel(phy_cfg->mr1,   base + KS2_DDRPHY_MR1_OFFSET);
-   if (!cpu_is_k2g())
-   __raw_writel(phy_cfg->mr2,   base + KS2_DDRPHY_MR2_OFFSET);
+   __raw_writel(phy_cfg->mr2,   base + KS2_DDRPHY_MR2_OFFSET);
__raw_writel(phy_cfg->dtcr,  base + KS2_DDRPHY_DTCR_OFFSET);
__raw_writel(phy_cfg->pgcr2, base + KS2_DDRPHY_PGCR2_OFFSET);
 
diff --git a/board/ti/ks2_evm/ddr3_k2g.c b/board/ti/ks2_evm/ddr3_k2g.c
index 344961d..aeb7da6 100644
--- a/board/ti/ks2_evm/ddr3_k2g.c
+++ b/board/ti/ks2_evm/ddr3_k2g.c
@@ -27,7 +27,7 @@ struct ddr3_phy_config ddr3phy_800_2g = {
.dtpr2  = 0x50022A00ul,
.mr0= 0x1430ul,
.mr1= 0x0006ul,
-   .mr2= 0x0018ul,
+   .mr2= 0xul,
.dtcr   = 0x710035C7ul,
.pgcr2  = 0x00F03D09ul,
.zq0cr1 = 0x0001005Dul,
-- 
2.10.0

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


[U-Boot] [PATCH 13/31] Makefile: Build additional binaries for dtb FIT blobs appended to U-boot

2017-03-02 Thread Franklin S Cooper Jr
Add additional make targets and options for building embedded FIT U-boot
images.

Signed-off-by: Franklin S Cooper Jr 
---
 .gitignore |  1 +
 Makefile   | 18 --
 2 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/.gitignore b/.gitignore
index 7fac5b3..29757aa 100644
--- a/.gitignore
+++ b/.gitignore
@@ -30,6 +30,7 @@
 #
 # Top-level generic files
 #
+fit-dtb.blob
 /MLO*
 /SPL*
 /System.map
diff --git a/Makefile b/Makefile
index 7cbb610..24254a5 100644
--- a/Makefile
+++ b/Makefile
@@ -862,7 +862,21 @@ dts/dt.dtb: checkdtc u-boot
 quiet_cmd_copy = COPY$@
   cmd_copy = cp $< $@
 
-ifeq ($(CONFIG_OF_SEPARATE),y)
+ifeq ($(CONFIG_FIT_EMBED),y)
+
+fit-dtb.blob: dts/dt.dtb FORCE
+   $(call if_changed,mkimage)
+
+MKIMAGEFLAGS_fit-dtb.blob = -f auto -A $(ARCH) -T firmware -C none -O u-boot \
+   -a 0 -e 0 -E \
+   $(patsubst %,-b arch/$(ARCH)/dts/%.dtb,$(subst ",,$(CONFIG_OF_LIST))) 
-d /dev/null
+
+u-boot-fit-dtb.bin: u-boot-nodtb.bin fit-dtb.blob
+   $(call if_changed,cat)
+
+u-boot.bin: u-boot-fit-dtb.bin FORCE
+   $(call if_changed,copy)
+else ifeq ($(CONFIG_OF_SEPARATE),y)
 u-boot-dtb.bin: u-boot-nodtb.bin dts/dt.dtb FORCE
$(call if_changed,cat)
 
@@ -1429,7 +1443,7 @@ CLEAN_DIRS  += $(MODVERDIR) \
$(filter-out include, $(shell ls -1 $d 2>/dev/null
 
 CLEAN_FILES += include/bmp_logo.h include/bmp_logo_data.h \
-  boot* u-boot* MLO* SPL System.map
+  boot* u-boot* MLO* SPL System.map fit-dtb.blob
 
 # Directories & files removed with 'make mrproper'
 MRPROPER_DIRS  += include/config include/generated spl tpl \
-- 
2.10.0

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


[U-Boot] [PATCH 22/31] ks2_evm: Add EEPROM based board detection helper functions

2017-03-02 Thread Franklin S Cooper Jr
Add a function that can be used to determine if the board being ran on is
a K2G Industrial Communication Engine EVM or K2G General Purpose EVM based
on values programmed on the EEPROM.

Signed-off-by: Franklin S Cooper Jr 
---
 board/ti/ks2_evm/board.h | 20 
 1 file changed, 20 insertions(+)

diff --git a/board/ti/ks2_evm/board.h b/board/ti/ks2_evm/board.h
index 0698921..b3ad188 100644
--- a/board/ti/ks2_evm/board.h
+++ b/board/ti/ks2_evm/board.h
@@ -15,6 +15,26 @@
 
 extern struct eth_priv_t eth_priv_cfg[];
 
+#if defined(CONFIG_TI_I2C_BOARD_DETECT)
+static inline int board_is_k2g_gp(void)
+{
+   return board_ti_is("66AK2GGP");
+}
+static inline int board_is_k2g_ice(void)
+{
+   return board_ti_is("66AK2GIC");
+}
+#else
+static inline int board_is_k2g_gp(void)
+{
+   return false;
+}
+static inline int board_is_k2g_ice(void)
+{
+   return false;
+}
+#endif
+
 int get_num_eth_ports(void);
 void spl_init_keystone_plls(void);
 
-- 
2.10.0

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


[U-Boot] [PATCH 24/31] ARM: k2g: Add DDR3 configuration for K2G ICE evm

2017-03-02 Thread Franklin S Cooper Jr
Add configuration settings used by the K2G ICE evm. Also use board
detection to determine which DDR3 configuration to use.

Signed-off-by: Franklin S Cooper Jr 
---
 board/ti/ks2_evm/ddr3_k2g.c | 62 +++--
 1 file changed, 60 insertions(+), 2 deletions(-)

diff --git a/board/ti/ks2_evm/ddr3_k2g.c b/board/ti/ks2_evm/ddr3_k2g.c
index 3b12943..44db335 100644
--- a/board/ti/ks2_evm/ddr3_k2g.c
+++ b/board/ti/ks2_evm/ddr3_k2g.c
@@ -10,7 +10,9 @@
 #include 
 #include "ddr3_cfg.h"
 #include 
+#include "board.h"
 
+/* K2G GP EVM DDR3 Configuration */
 struct ddr3_phy_config ddr3phy_800_2g = {
.pllcr  = 0x000DC000ul,
.pgcr1_mask = (IODDRM_MASK | ZCKSEL_MASK),
@@ -61,13 +63,69 @@ struct ddr3_emif_config ddr3_800_2g = {
.sdrfc  = 0x0C34ul,
 };
 
+/* K2G ICE evm DDR3 Configuration */
+struct ddr3_phy_config ddr3phy_800_512mb = {
+   .pllcr  = 0x000DC000ul,
+   .pgcr1_mask = (IODDRM_MASK | ZCKSEL_MASK),
+   .pgcr1_val  = ((1 << 2) | (2 << 7) | (1 << 23)),
+   .ptr0   = 0x42C21590ul,
+   .ptr1   = 0xD05612C0ul,
+   .ptr2   = 0,
+   .ptr3   = 0x06C30D40ul,
+   .ptr4   = 0x06413880ul,
+   .dcr_mask   = (PDQ_MASK | MPRDQ_MASK | BYTEMASK_MASK),
+   .dcr_val= ((1 << 10)),
+   .dtpr0  = 0x550E6644ul,
+   .dtpr1  = 0x32834200ul,
+   .dtpr2  = 0x50022A00ul,
+   .mr0= 0x1430ul,
+   .mr1= 0x0006ul,
+   .mr2= 0x0008ul,
+   .dtcr   = 0x710035C7ul,
+   .pgcr2  = 0x00F03D09ul,
+   .zq0cr1 = 0x0001005Dul,
+   .zq1cr1 = 0x0001005Bul,
+   .zq2cr1 = 0x0001005Bul,
+   .pir_v1 = 0x0033ul,
+   .datx8_2_mask   = DXEN_MASK,
+   .datx8_2_val= 0,
+   .datx8_3_mask   = DXEN_MASK,
+   .datx8_3_val= 0,
+   .datx8_4_mask   = DXEN_MASK,
+   .datx8_4_val= 0,
+   .datx8_5_mask   = DXEN_MASK,
+   .datx8_5_val= 0,
+   .datx8_6_mask   = DXEN_MASK,
+   .datx8_6_val= 0,
+   .datx8_7_mask   = DXEN_MASK,
+   .datx8_7_val= 0,
+   .datx8_8_mask   = DXEN_MASK,
+   .datx8_8_val= 0,
+   .pir_v2 = 0x0F81ul,
+};
+
+struct ddr3_emif_config ddr3_800_512mb = {
+   .sdcfg  = 0x62006662ul,
+   .sdtim1 = 0x0A385033ul,
+   .sdtim2 = 0x1CA5ul,
+   .sdtim3 = 0x21ADFF32ul,
+   .sdtim4 = 0x533F067Ful,
+   .zqcfg  = 0x70073200ul,
+   .sdrfc  = 0x0C34ul,
+};
+
 u32 ddr3_init(void)
 {
/* Reset DDR3 PHY after PLL enabled */
ddr3_reset_ddrphy();
 
-   ddr3_init_ddrphy(KS2_DDR3A_DDRPHYC, &ddr3phy_800_2g);
-   ddr3_init_ddremif(KS2_DDR3A_EMIF_CTRL_BASE, &ddr3_800_2g);
+   if (board_is_k2g_gp()) {
+   ddr3_init_ddrphy(KS2_DDR3A_DDRPHYC, &ddr3phy_800_2g);
+   ddr3_init_ddremif(KS2_DDR3A_EMIF_CTRL_BASE, &ddr3_800_2g);
+   } else if (board_is_k2g_ice()) {
+   ddr3_init_ddrphy(KS2_DDR3A_DDRPHYC, &ddr3phy_800_512mb);
+   ddr3_init_ddremif(KS2_DDR3A_EMIF_CTRL_BASE, &ddr3_800_512mb);
+   }
 
return 0;
 }
-- 
2.10.0

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


[U-Boot] [PATCH 26/31] ARM: k2g: Use board detection to wrap K2G GP specific calls

2017-03-02 Thread Franklin S Cooper Jr
Certain peripherals used by K2G GP aren't used on K2G ICE evm. Or
configuration is slightly different. Therefore, use board detection to
deal with these variations.

Signed-off-by: Franklin S Cooper Jr 
---
 board/ti/ks2_evm/board_k2g.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/board/ti/ks2_evm/board_k2g.c b/board/ti/ks2_evm/board_k2g.c
index 8340cde..0fbc64a 100644
--- a/board/ti/ks2_evm/board_k2g.c
+++ b/board/ti/ks2_evm/board_k2g.c
@@ -114,7 +114,9 @@ int board_mmc_init(bd_t *bis)
return -1;
}
 
-   omap_mmc_init(0, 0, 0, -1, -1);
+   if (board_is_k2g_gp())
+   omap_mmc_init(0, 0, 0, -1, -1);
+
omap_mmc_init(1, 0, 0, -1, -1);
return 0;
 }
@@ -184,11 +186,13 @@ int embedded_dtb_select(void)
 
k2g_reset_mux_config();
 
-   /* deassert FLASH_HOLD */
-   clrbits_le32(K2G_GPIO1_BANK2_BASE + K2G_GPIO_DIR_OFFSET,
-BIT(9));
-   setbits_le32(K2G_GPIO1_BANK2_BASE + K2G_GPIO_SETDATA_OFFSET,
-BIT(9));
+   if (board_is_k2g_gp()) {
+   /* deassert FLASH_HOLD */
+   clrbits_le32(K2G_GPIO1_BANK2_BASE + K2G_GPIO_DIR_OFFSET,
+BIT(9));
+   setbits_le32(K2G_GPIO1_BANK2_BASE + K2G_GPIO_SETDATA_OFFSET,
+BIT(9));
+   }
 
return 0;
 }
-- 
2.10.0

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


[U-Boot] [PATCH 28/31] ARM: dts: k2g: Disable netcp by default

2017-03-02 Thread Franklin S Cooper Jr
Disable netcp by default like all other peripherals in the dtsi file.
Enable the peripheral explicitly in the board specific dts file.

Signed-off-by: Franklin S Cooper Jr 
---
 arch/arm/dts/keystone-k2g-evm.dts| 4 
 arch/arm/dts/keystone-k2g-netcp.dtsi | 1 +
 2 files changed, 5 insertions(+)

diff --git a/arch/arm/dts/keystone-k2g-evm.dts 
b/arch/arm/dts/keystone-k2g-evm.dts
index 696a0d7..594543f 100644
--- a/arch/arm/dts/keystone-k2g-evm.dts
+++ b/arch/arm/dts/keystone-k2g-evm.dts
@@ -32,6 +32,10 @@
phy-handle = <ðphy0>;
 };
 
+&netcp {
+   status = "okay";
+};
+
 &spi1 {
status = "okay";
 
diff --git a/arch/arm/dts/keystone-k2g-netcp.dtsi 
b/arch/arm/dts/keystone-k2g-netcp.dtsi
index a9b26c3..d76f2a1 100644
--- a/arch/arm/dts/keystone-k2g-netcp.dtsi
+++ b/arch/arm/dts/keystone-k2g-netcp.dtsi
@@ -99,6 +99,7 @@ netcp: netcp@400 {
reg = <0x2620110 0x8>;
reg-names = "efuse";
compatible = "ti,netcp-1.0";
+   status = "disabled";
#address-cells = <1>;
#size-cells = <1>;
/* power-domains = <&k2g_pds K2G_DEV_NSS0>; */
-- 
2.10.0

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


[U-Boot] [PATCH 11/31] ARM: k2g: Enable TI board detection code

2017-03-02 Thread Franklin S Cooper Jr
K2G boards have a EEPROM that will be used for board detection. Therefore,
select the board detection config for K2G evms.

Signed-off-by: Franklin S Cooper Jr 
---
 arch/arm/mach-keystone/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-keystone/Kconfig b/arch/arm/mach-keystone/Kconfig
index e1962c7..5c880fa 100644
--- a/arch/arm/mach-keystone/Kconfig
+++ b/arch/arm/mach-keystone/Kconfig
@@ -15,6 +15,7 @@ config TARGET_K2L_EVM
 
 config TARGET_K2G_EVM
bool "TI Keystone 2 Galileo EVM"
+   select TI_I2C_BOARD_DETECT
 
 endchoice
 
-- 
2.10.0

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


[U-Boot] [PATCH 18/31] defconfig: keystone2: Enable U-boot runtime DTB detection

2017-03-02 Thread Franklin S Cooper Jr
Enable various config options to allow U-boot at runtime to select the
proper dtb to use from the list of dtb's within the FIT image.

Signed-off-by: Franklin S Cooper Jr 
---
 configs/k2e_evm_defconfig  | 3 +++
 configs/k2g_evm_defconfig  | 3 +++
 configs/k2hk_evm_defconfig | 3 +++
 configs/k2l_evm_defconfig  | 3 +++
 4 files changed, 12 insertions(+)

diff --git a/configs/k2e_evm_defconfig b/configs/k2e_evm_defconfig
index a42a485..801a4e4 100644
--- a/configs/k2e_evm_defconfig
+++ b/configs/k2e_evm_defconfig
@@ -54,3 +54,6 @@ CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_STORAGE=y
+CONFIG_DTB_RESELECT=y
+CONFIG_FIT_EMBED=y
+CONFIG_OF_LIST="keystone-k2e-evm"
diff --git a/configs/k2g_evm_defconfig b/configs/k2g_evm_defconfig
index f3ee01a..1352877 100644
--- a/configs/k2g_evm_defconfig
+++ b/configs/k2g_evm_defconfig
@@ -58,3 +58,6 @@ CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_STORAGE=y
+CONFIG_DTB_RESELECT=y
+CONFIG_FIT_EMBED=y
+CONFIG_OF_LIST="keystone-k2g-generic keystone-k2g-evm"
diff --git a/configs/k2hk_evm_defconfig b/configs/k2hk_evm_defconfig
index d924796..0fa74b6 100644
--- a/configs/k2hk_evm_defconfig
+++ b/configs/k2hk_evm_defconfig
@@ -54,3 +54,6 @@ CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_STORAGE=y
+CONFIG_DTB_RESELECT=y
+CONFIG_FIT_EMBED=y
+CONFIG_OF_LIST="keystone-k2hk-evm"
diff --git a/configs/k2l_evm_defconfig b/configs/k2l_evm_defconfig
index c817585..caad57c 100644
--- a/configs/k2l_evm_defconfig
+++ b/configs/k2l_evm_defconfig
@@ -54,3 +54,6 @@ CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_STORAGE=y
+CONFIG_DTB_RESELECT=y
+CONFIG_FIT_EMBED=y
+CONFIG_OF_LIST="keystone-k2l-evm"
-- 
2.10.0

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


[U-Boot] [PATCH 30/31] ARM: k2g: Add K2G ICE DTB to the list of possible DTBs

2017-03-02 Thread Franklin S Cooper Jr
K2G ICE evm will have its own dtb. Therefore, add it to the list of dtbs
located in the appended U-boot dtb FIT image. Therefore, when swapping out
dtbs K2G ICE boards can grab the correct one.

Signed-off-by: Franklin S Cooper Jr 
---
 board/ti/ks2_evm/board_k2g.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/board/ti/ks2_evm/board_k2g.c b/board/ti/ks2_evm/board_k2g.c
index 70164ee..e7b9bab 100644
--- a/board/ti/ks2_evm/board_k2g.c
+++ b/board/ti/ks2_evm/board_k2g.c
@@ -131,6 +131,8 @@ int board_fit_config_name_match(const char *name)
return 0;
else if (!strcmp(name, "keystone-k2g-evm") && board_ti_is("66AK2GGP"))
return 0;
+   else if (!strcmp(name, "keystone-k2g-ice") && board_ti_is("66AK2GIC"))
+   return 0;
else
return -1;
 }
-- 
2.10.0

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


[U-Boot] [PATCH 21/31] ARM: k2g: Program DDRPHY_DATX8 registers via mask and value variables

2017-03-02 Thread Franklin S Cooper Jr
Different K2G evms may need to program the various
KS2_DDRPHY_DATX8_X_OFFSET registers in different ways. Therefore, use
the mask and val registers for each KS2_DDRPHY_DATAX_X_OFFSET to
properly program the register.

Signed-off-by: Franklin S Cooper Jr 
---
 arch/arm/mach-keystone/ddr3.c | 32 +++-
 board/ti/ks2_evm/ddr3_k2g.c   | 14 ++
 2 files changed, 41 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-keystone/ddr3.c b/arch/arm/mach-keystone/ddr3.c
index 25a9637..4cad6a2 100644
--- a/arch/arm/mach-keystone/ddr3.c
+++ b/arch/arm/mach-keystone/ddr3.c
@@ -65,11 +65,33 @@ void ddr3_init_ddrphy(u32 base, struct ddr3_phy_config 
*phy_cfg)
;
 
if (cpu_is_k2g()) {
-   setbits_le32(base + KS2_DDRPHY_DATX8_4_OFFSET, 0x1);
-   clrbits_le32(base + KS2_DDRPHY_DATX8_5_OFFSET, 0x1);
-   clrbits_le32(base + KS2_DDRPHY_DATX8_6_OFFSET, 0x1);
-   clrbits_le32(base + KS2_DDRPHY_DATX8_7_OFFSET, 0x1);
-   clrbits_le32(base + KS2_DDRPHY_DATX8_8_OFFSET, 0x1);
+   clrsetbits_le32(base + KS2_DDRPHY_DATX8_2_OFFSET,
+   phy_cfg->datx8_2_mask,
+   phy_cfg->datx8_2_val);
+
+   clrsetbits_le32(base + KS2_DDRPHY_DATX8_3_OFFSET,
+   phy_cfg->datx8_3_mask,
+   phy_cfg->datx8_3_val);
+
+   clrsetbits_le32(base + KS2_DDRPHY_DATX8_4_OFFSET,
+   phy_cfg->datx8_4_mask,
+   phy_cfg->datx8_4_val);
+
+   clrsetbits_le32(base + KS2_DDRPHY_DATX8_5_OFFSET,
+   phy_cfg->datx8_5_mask,
+   phy_cfg->datx8_5_val);
+
+   clrsetbits_le32(base + KS2_DDRPHY_DATX8_6_OFFSET,
+   phy_cfg->datx8_6_mask,
+   phy_cfg->datx8_6_val);
+
+   clrsetbits_le32(base + KS2_DDRPHY_DATX8_7_OFFSET,
+   phy_cfg->datx8_7_mask,
+   phy_cfg->datx8_7_val);
+
+   clrsetbits_le32(base + KS2_DDRPHY_DATX8_8_OFFSET,
+   phy_cfg->datx8_8_mask,
+   phy_cfg->datx8_8_val);
}
 
__raw_writel(phy_cfg->pir_v2, base + KS2_DDRPHY_PIR_OFFSET);
diff --git a/board/ti/ks2_evm/ddr3_k2g.c b/board/ti/ks2_evm/ddr3_k2g.c
index aeb7da6..3b12943 100644
--- a/board/ti/ks2_evm/ddr3_k2g.c
+++ b/board/ti/ks2_evm/ddr3_k2g.c
@@ -34,6 +34,20 @@ struct ddr3_phy_config ddr3phy_800_2g = {
.zq1cr1 = 0x0001005Bul,
.zq2cr1 = 0x0001005Bul,
.pir_v1 = 0x0033ul,
+   .datx8_2_mask   = 0,
+   .datx8_2_val= 0,
+   .datx8_3_mask   = 0,
+   .datx8_3_val= 0,
+   .datx8_4_mask   = 0,
+   .datx8_4_val= ((1 << 0)),
+   .datx8_5_mask   = DXEN_MASK,
+   .datx8_5_val= 0,
+   .datx8_6_mask   = DXEN_MASK,
+   .datx8_6_val= 0,
+   .datx8_7_mask   = DXEN_MASK,
+   .datx8_7_val= 0,
+   .datx8_8_mask   = DXEN_MASK,
+   .datx8_8_val= 0,
.pir_v2 = 0x0F81ul,
 };
 
-- 
2.10.0

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


[U-Boot] [PATCH 25/31] board: ks2: Use board detection to wrap code not specific to K2G ICE evm

2017-03-02 Thread Franklin S Cooper Jr
Some code doesn't apply to K2G ICE evm. Therefore, use board detection to
wrap these calls.

Signed-off-by: Franklin S Cooper Jr 
---
 board/ti/ks2_evm/board.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/board/ti/ks2_evm/board.c b/board/ti/ks2_evm/board.c
index 4792311..c61baee 100644
--- a/board/ti/ks2_evm/board.c
+++ b/board/ti/ks2_evm/board.c
@@ -45,13 +45,17 @@ int dram_init(void)
gd->ram_size = get_ram_size((long *)CONFIG_SYS_SDRAM_BASE,
CONFIG_MAX_RAM_BANK_SIZE);
 #if defined(CONFIG_TI_AEMIF)
-   aemif_init(ARRAY_SIZE(aemif_configs), aemif_configs);
+   if (!board_is_k2g_ice())
+   aemif_init(ARRAY_SIZE(aemif_configs), aemif_configs);
 #endif
 
-   if (ddr3_size)
-   ddr3_init_ecc(KS2_DDR3A_EMIF_CTRL_BASE, ddr3_size);
-   else
-   ddr3_init_ecc(KS2_DDR3A_EMIF_CTRL_BASE, gd->ram_size >> 30);
+   if (!board_is_k2g_ice()) {
+   if (ddr3_size)
+   ddr3_init_ecc(KS2_DDR3A_EMIF_CTRL_BASE, ddr3_size);
+   else
+   ddr3_init_ecc(KS2_DDR3A_EMIF_CTRL_BASE,
+ gd->ram_size >> 30);
+   }
 
return 0;
 }
-- 
2.10.0

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


[U-Boot] [PATCH 12/31] board_f: Add new function to allow runtime DTB selection

2017-03-02 Thread Franklin S Cooper Jr
Runtime U-boot dtb selection is generally a two step process. First step
is to simply use an initial generic dtb. The second step is to select
the dtb and perhaps execute additional code ones U-boot knows what board
it is running on. Embedded_dtb_select handles the second step by allowing
board specific code to run and perform what ever necessary configuration
that is needed.

Signed-off-by: Franklin S Cooper Jr 
---
 common/Kconfig   | 10 ++
 common/board_f.c |  3 +++
 include/common.h |  4 
 3 files changed, 17 insertions(+)

diff --git a/common/Kconfig b/common/Kconfig
index 11495f3..bf4e94b 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -352,6 +352,16 @@ config SYS_STDIO_DEREGISTER
 
 endmenu
 
+config DTB_RESELECT
+   bool "Support swapping dtbs at a later point in boot"
+   depends on FIT_EMBED
+   default n
+   help
+ It is possible during initial boot you may need to use a generic
+ dtb until you can fully determine the board your running on. This
+ config allows boards to implement a function at a later point
+ during boot to switch to the "correct" dtb.
+
 config FIT_EMBED
bool "Support a FIT image embedded in the U-boot image"
default n
diff --git a/common/board_f.c b/common/board_f.c
index ae6cd85..2e69b3a 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -920,6 +920,9 @@ static const init_fnc_t init_sequence_f[] = {
 #if defined(CONFIG_DISPLAY_CPUINFO)
print_cpuinfo,  /* display cpu info (and speed) */
 #endif
+#if defined(CONFIG_DTB_RESELECT)
+   embedded_dtb_select,
+#endif
 #if defined(CONFIG_DISPLAY_BOARDINFO)
show_board_info,
 #endif
diff --git a/include/common.h b/include/common.h
index fbbc2cb..7bc85d8 100644
--- a/include/common.h
+++ b/include/common.h
@@ -451,6 +451,10 @@ void   pci_init_board(void);
 #endif
 #endif
 
+#if defined(CONFIG_DTB_RESELECT)
+intembedded_dtb_select(void);
+#endif
+
 intmisc_init_f   (void);
 intmisc_init_r   (void);
 
-- 
2.10.0

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


[U-Boot] [PATCH 23/31] ARM: k2g: Add pinmux support for K2G ICE evm

2017-03-02 Thread Franklin S Cooper Jr
Add basic pinmux data for new K2G ICE evm. Also add pinmuxing for a
generic K2G evm which includes I2C 0 and 1 used for board detection
purposes.

Since multiple K2G boards are supported that means initially generic
pinmuxing should be used when board detection hasn't ran. Once board
detection runs the proper pinmuxing can be reran to match the board
being ran on.

Signed-off-by: Franklin S Cooper Jr 
---
 board/ti/ks2_evm/board_k2g.c |  2 ++
 board/ti/ks2_evm/mux-k2g.h   | 45 +++-
 2 files changed, 46 insertions(+), 1 deletion(-)

diff --git a/board/ti/ks2_evm/board_k2g.c b/board/ti/ks2_evm/board_k2g.c
index 64b1f6b..8340cde 100644
--- a/board/ti/ks2_evm/board_k2g.c
+++ b/board/ti/ks2_evm/board_k2g.c
@@ -180,6 +180,8 @@ int embedded_dtb_select(void)
 
fdtdec_setup();
 
+   k2g_mux_config();
+
k2g_reset_mux_config();
 
/* deassert FLASH_HOLD */
diff --git a/board/ti/ks2_evm/mux-k2g.h b/board/ti/ks2_evm/mux-k2g.h
index 773f9b7..630103d 100644
--- a/board/ti/ks2_evm/mux-k2g.h
+++ b/board/ti/ks2_evm/mux-k2g.h
@@ -11,6 +11,22 @@
 #include 
 #include 
 #include 
+#include "board.h"
+
+struct pin_cfg k2g_generic_pin_cfg[] = {
+   /* UART0 */
+   { 115,  MODE(0) },  /* SOC_UART0_RXD */
+   { 116,  MODE(0) },  /* SOC_UART0_TXD */
+
+   /* I2C 0 */
+   { 223,  MODE(0) },  /* SOC_I2C0_SCL */
+   { 224,  MODE(0) },  /* SOC_I2C0_SDA */
+
+   /* I2C 1 */
+   { 225,  MODE(0) },  /* SOC_I2C1_SCL */
+   { 226,  MODE(0) },  /* SOC_I2C1_SDA */
+   { MAX_PIN_N, }
+};
 
 struct pin_cfg k2g_evm_pin_cfg[] = {
/* GPMC */
@@ -307,7 +323,34 @@ struct pin_cfg k2g_evm_pin_cfg[] = {
{ MAX_PIN_N, }
 };
 
+struct pin_cfg k2g_ice_evm_pin_cfg[] = {
+   /* MMC 1 */
+   { 63, MODE(0) | PIN_PTD },  /* MMC1_DAT3.MMC1_DAT3 */
+   { 64, MODE(0) | PIN_PTU },  /* MMC1_DAT2.MMC1_DAT2 */
+   { 65, MODE(0) | PIN_PTU },  /* MMC1_DAT1.MMC1_DAT1 */
+   { 66, MODE(0) | PIN_PTD },  /* MMC1_DAT0.MMC1_DAT0 */
+   { 67, MODE(0) | PIN_PTD },  /* MMC1_CLK.MMC1_CLK   */
+   { 68, MODE(0) | PIN_PTD },  /* MMC1_CMD.MMC1_CMD   */
+   { 69, MODE(3) | PIN_PTU },  /* MMC1_SDCD.GPIO0_69  */
+   { 70, MODE(0) | PIN_PTU },  /* MMC1_SDWP.MMC1_SDWP */
+   { 71, MODE(0) | PIN_PTD },  /* MMC1_POW.MMC1_POW   */
+
+   /* I2C 0 */
+   { 223,  MODE(0) },  /* SOC_I2C0_SCL */
+   { 224,  MODE(0) },  /* SOC_I2C0_SDA */
+   { MAX_PIN_N, }
+};
+
 void k2g_mux_config(void)
 {
-   configure_pin_mux(k2g_evm_pin_cfg);
+   if (!board_ti_was_eeprom_read()) {
+   configure_pin_mux(k2g_generic_pin_cfg);
+   } else if (board_is_k2g_gp()) {
+   configure_pin_mux(k2g_evm_pin_cfg);
+   } else if (board_is_k2g_ice()) {
+   configure_pin_mux(k2g_ice_evm_pin_cfg);
+   } else {
+   puts("Unknown board, cannot configure pinmux.");
+   hang();
+   }
 }
-- 
2.10.0

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


[U-Boot] [PATCH 29/31] ARM: dts: k2g: Add DT support for K2G Industrial Communication Engine evm

2017-03-02 Thread Franklin S Cooper Jr
Add basic DT support for K2G ICE evm. Only minimal peripherals are
supported to allow console output and MMC boot.

Signed-off-by: Franklin S Cooper Jr 
---
 arch/arm/dts/Makefile |  3 ++-
 arch/arm/dts/keystone-k2g-ice.dts | 25 +
 2 files changed, 27 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/keystone-k2g-ice.dts

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 06ebbf0..eb92480 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -324,7 +324,8 @@ dtb-$(CONFIG_SOC_KEYSTONE) += keystone-k2hk-evm.dtb \
keystone-k2l-evm.dtb \
keystone-k2e-evm.dtb \
keystone-k2g-evm.dtb \
-   keystone-k2g-generic.dtb
+   keystone-k2g-generic.dtb \
+   keystone-k2g-ice.dtb
 
 dtb-$(CONFIG_TARGET_SAMA5D2_XPLAINED) += \
at91-sama5d2_xplained.dtb
diff --git a/arch/arm/dts/keystone-k2g-ice.dts 
b/arch/arm/dts/keystone-k2g-ice.dts
new file mode 100644
index 000..d06bdc6
--- /dev/null
+++ b/arch/arm/dts/keystone-k2g-ice.dts
@@ -0,0 +1,25 @@
+/*
+ * Copyright 2017 Texas Instruments, Inc.
+ *
+ * K2G Industrial Communication Engine EVM device tree
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+#include "keystone-k2g.dtsi"
+
+/ {
+   compatible = "ti,k2g-ice", "ti,k2g", "ti,keystone";
+   model = "Texas Instruments K2G Industrial Communication EVM";
+
+   chosen {
+   stdout-path = &uart0;
+   };
+};
+
+&mmc1 {
+   status = "okay";
+};
-- 
2.10.0

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


[U-Boot] [PATCH 19/31] ARM: keystone2: Add additional fields used for DDR3 configuration

2017-03-02 Thread Franklin S Cooper Jr
Future boards will need to configure DDR3 registers in a slightly
different manner. Support this by defining additional variables and
defines that will be utilized later.

Signed-off-by: Franklin S Cooper Jr 
---
 arch/arm/mach-keystone/include/mach/ddr3.h | 14 ++
 arch/arm/mach-keystone/include/mach/hardware.h |  3 +++
 2 files changed, 17 insertions(+)

diff --git a/arch/arm/mach-keystone/include/mach/ddr3.h 
b/arch/arm/mach-keystone/include/mach/ddr3.h
index 5feffe8..93789fd 100644
--- a/arch/arm/mach-keystone/include/mach/ddr3.h
+++ b/arch/arm/mach-keystone/include/mach/ddr3.h
@@ -35,6 +35,20 @@ struct ddr3_phy_config {
unsigned int zq1cr1;
unsigned int zq2cr1;
unsigned int pir_v1;
+   unsigned int datx8_2_mask;
+   unsigned int datx8_2_val;
+   unsigned int datx8_3_mask;
+   unsigned int datx8_3_val;
+   unsigned int datx8_4_mask;
+   unsigned int datx8_4_val;
+   unsigned int datx8_5_mask;
+   unsigned int datx8_5_val;
+   unsigned int datx8_6_mask;
+   unsigned int datx8_6_val;
+   unsigned int datx8_7_mask;
+   unsigned int datx8_7_val;
+   unsigned int datx8_8_mask;
+   unsigned int datx8_8_val;
unsigned int pir_v2;
 };
 
diff --git a/arch/arm/mach-keystone/include/mach/hardware.h 
b/arch/arm/mach-keystone/include/mach/hardware.h
index 38d0190..1969a10 100644
--- a/arch/arm/mach-keystone/include/mach/hardware.h
+++ b/arch/arm/mach-keystone/include/mach/hardware.h
@@ -52,6 +52,8 @@ typedef volatile unsigned int   *dv_reg_p;
 #define KS2_DDRPHY_ZQ2CR1_OFFSET0x1A4
 #define KS2_DDRPHY_ZQ3CR1_OFFSET0x1B4
 
+#define KS2_DDRPHY_DATX8_2_OFFSET   0x240
+#define KS2_DDRPHY_DATX8_3_OFFSET   0x280
 #define KS2_DDRPHY_DATX8_4_OFFSET   0x2C0
 #define KS2_DDRPHY_DATX8_5_OFFSET   0x300
 #define KS2_DDRPHY_DATX8_6_OFFSET   0x340
@@ -70,6 +72,7 @@ typedef volatile unsigned int   *dv_reg_p;
 #define PDQ_MASK0x0070
 #define NOSRA_MASK  0x0800
 #define ECC_MASK0x0001
+#define DXEN_MASK   0x0001
 
 /* DDR3 definitions */
 #define KS2_DDR3A_EMIF_CTRL_BASE   0x2101
-- 
2.10.0

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


[U-Boot] [PATCH 08/31] ti: common: board_detect: Rename EEPROM scratch start macro

2017-03-02 Thread Franklin S Cooper Jr
From: Lokesh Vutla 

Non OMAP platforms i.e. Keystone will also need to use the board
EEPROM helpers so let's make the macro platform independent.

Signed-off-by: Roger Quadros 
Signed-off-by: Lokesh Vutla 
Reviewed-by: Tom Rini 
---
 arch/arm/include/asm/omap_common.h | 8 +---
 board/ti/common/board_detect.h | 2 +-
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch/arm/include/asm/omap_common.h 
b/arch/arm/include/asm/omap_common.h
index 2034a5e..c1a70b1 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -767,9 +767,11 @@ static inline u8 is_dra72x(void)
 #define OMAP_SRAM_SCRATCH_VCORES_PTR(SRAM_SCRATCH_SPACE_ADDR + 0x1C)
 #define OMAP_SRAM_SCRATCH_SYS_CTRL (SRAM_SCRATCH_SPACE_ADDR + 0x20)
 #define OMAP_SRAM_SCRATCH_BOOT_PARAMS  (SRAM_SCRATCH_SPACE_ADDR + 0x24)
-#define OMAP_SRAM_SCRATCH_BOARD_EEPROM_START (SRAM_SCRATCH_SPACE_ADDR + 0x28)
-#define OMAP_SRAM_SCRATCH_BOARD_EEPROM_END (SRAM_SCRATCH_SPACE_ADDR + 0x200)
-#define OMAP_SRAM_SCRATCH_SPACE_END(OMAP_SRAM_SCRATCH_BOARD_EEPROM_END)
+#ifndef TI_SRAM_SCRATCH_BOARD_EEPROM_START
+#define TI_SRAM_SCRATCH_BOARD_EEPROM_START (SRAM_SCRATCH_SPACE_ADDR + 0x28)
+#define TI_SRAM_SCRATCH_BOARD_EEPROM_END (SRAM_SCRATCH_SPACE_ADDR + 0x200)
+#endif
+#define OMAP_SRAM_SCRATCH_SPACE_END(TI_SRAM_SCRATCH_BOARD_EEPROM_END)
 
 /* Boot parameters */
 #define DEVICE_DATA_OFFSET 0x18
diff --git a/board/ti/common/board_detect.h b/board/ti/common/board_detect.h
index 97dc4e4..1ea4d68 100644
--- a/board/ti/common/board_detect.h
+++ b/board/ti/common/board_detect.h
@@ -98,7 +98,7 @@ struct ti_common_eeprom {
 };
 
 #define TI_EEPROM_DATA ((struct ti_common_eeprom *)\
-   OMAP_SRAM_SCRATCH_BOARD_EEPROM_START)
+   TI_SRAM_SCRATCH_BOARD_EEPROM_START)
 
 /**
  * ti_i2c_eeprom_am_get() - Consolidated eeprom data collection for AM* TI EVMs
-- 
2.10.0

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


[U-Boot] [PATCH 04/31] fdt: Enable selecting correct DTB from append FIT Image

2017-03-02 Thread Franklin S Cooper Jr
This patch gives U-boot the runtime support to have the board specific
code decide which FDT to use. This is especially useful for devices
that need this type of runtime determination and also doesn't use SPL.

Signed-off-by: Franklin S Cooper Jr 
Reviewed-by: Lokesh Vutla 
---
 lib/fdtdec.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 81f47ef..38db61c 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -4,6 +4,7 @@
  */
 
 #ifndef USE_HOSTCC
+#include 
 #include 
 #include 
 #include 
@@ -1243,6 +1244,15 @@ int fdtdec_setup(void)
gd->fdt_blob = (ulong *)&_image_binary_end;
else
gd->fdt_blob = (ulong *)&__bss_end;
+
+#  elif defined CONFIG_FIT_EMBED
+   gd->fdt_blob = locate_dtb_in_fit(&_end);
+
+   if (gd->fdt_blob == NULL || gd->fdt_blob <= ((void *)&_end)) {
+   puts("Failed to find proper dtb in embedded FIT Image\n");
+   return -1;
+   }
+
 #  else
/* FDT is at end of image */
gd->fdt_blob = (ulong *)&_end;
-- 
2.10.0

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


[U-Boot] [PATCH 03/31] boot_fit: Create helper functions that can be used to select DTB out of FIT

2017-03-02 Thread Franklin S Cooper Jr
Some platforms may append a FIT image to the U-boot image. This function
aids in parsing the FIT image and selecting the correct DTB at runtime.

Signed-off-by: Franklin S Cooper Jr 
Reviewed-by: Tom Rini 
---
 common/Kconfig |  8 
 common/Makefile|  1 +
 common/boot_fit.c  | 58 ++
 include/boot_fit.h |  9 +
 include/image.h|  2 +-
 5 files changed, 77 insertions(+), 1 deletion(-)
 create mode 100644 common/boot_fit.c
 create mode 100644 include/boot_fit.h

diff --git a/common/Kconfig b/common/Kconfig
index 8f73c8f..11495f3 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -352,6 +352,14 @@ config SYS_STDIO_DEREGISTER
 
 endmenu
 
+config FIT_EMBED
+   bool "Support a FIT image embedded in the U-boot image"
+   default n
+   help
+ This option provides hooks to allow U-boot to parse an
+ appended FIT image and enable board specific code to then select
+ the correct DTB to be used.
+
 config DEFAULT_FDT_FILE
string "Default fdt file"
help
diff --git a/common/Makefile b/common/Makefile
index 692ebc4..4dfebfc 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -150,6 +150,7 @@ obj-y += image.o
 obj-$(CONFIG_ANDROID_BOOT_IMAGE) += image-android.o
 obj-$(CONFIG_$(SPL_)OF_LIBFDT) += image-fdt.o
 obj-$(CONFIG_$(SPL_)FIT) += image-fit.o
+obj-$(CONFIG_FIT_EMBED) += boot_fit.o common_fit.o
 obj-$(CONFIG_$(SPL_)FIT_SIGNATURE) += image-sig.o
 obj-$(CONFIG_IO_TRACE) += iotrace.o
 obj-y += memsize.o
diff --git a/common/boot_fit.c b/common/boot_fit.c
new file mode 100644
index 000..ff26cf7
--- /dev/null
+++ b/common/boot_fit.c
@@ -0,0 +1,58 @@
+/*
+ * (C) Copyright 2017
+ * Texas Instruments, 
+ *
+ * Franklin S Cooper Jr. 
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+int fdt_offset(void *fit)
+{
+   int fdt_offset, fdt_len;
+   int images;
+
+   images = fdt_path_offset(fit, FIT_IMAGES_PATH);
+   if (images < 0) {
+   debug("%s: Cannot find /images node: %d\n", __func__, images);
+   return -1;
+   }
+
+   /* Figure out which device tree the board wants to use */
+   fdt_len = fit_select_fdt(fit, images, &fdt_offset);
+
+   if (fdt_len < 0)
+   return fdt_len;
+
+   return fdt_offset;
+}
+
+void *locate_dtb_in_fit(void *fit)
+{
+   struct image_header *header;
+   int size;
+   int ret;
+
+   size = fdt_totalsize(fit);
+   size = (size + 3) & ~3;
+
+   header = (struct image_header *)fit;
+
+   if (image_get_magic(header) != FDT_MAGIC) {
+   debug("No FIT image appended to U-boot\n");
+   return NULL;
+   }
+
+   ret = fdt_offset(fit);
+
+   if (ret <= 0)
+   return NULL;
+   else
+   return (void *)fit+size+ret;
+}
diff --git a/include/boot_fit.h b/include/boot_fit.h
new file mode 100644
index 000..b7d2462
--- /dev/null
+++ b/include/boot_fit.h
@@ -0,0 +1,9 @@
+/*
+ * Copyright (C) 2017 Texas Instruments
+ * Written by Franklin Cooper Jr. 
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+int fdt_offset(void *fit);
+void *locate_dtb_in_fit(void *fit);
diff --git a/include/image.h b/include/image.h
index bb8d699..2674cef 100644
--- a/include/image.h
+++ b/include/image.h
@@ -1275,7 +1275,7 @@ int board_fit_config_name_match(const char *name);
 void board_fit_image_post_process(void **p_image, size_t *p_size);
 #endif /* CONFIG_SPL_FIT_IMAGE_POST_PROCESS */
 
-#if IS_ENABLED(CONFIG_SPL_LOAD_FIT)
+#if IS_ENABLED(CONFIG_SPL_LOAD_FIT) || IS_ENABLED(CONFIG_FIT_EMBED)
 
 ulong fdt_getprop_u32(const void *fdt, int node, const char *prop);
 int fit_select_fdt(const void *fdt, int images, int *fdt_offsetp);
-- 
2.10.0

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


[U-Boot] [PATCH 00/31] ARM: k2g: Add support for new K2G ICE EVM.

2017-03-02 Thread Franklin S Cooper Jr
This patchset adds support for the new Keystone 2 Industrial Communication
Engine board.

This patchset includes the introduction of embedded FIT images in U-boot.
This creates a FIT image of dtb files that enables board specific code to
select which DTB to use at runtime. Initially during boot a generic DTB is
required that enables board detection to occur and once it has can later be
swapped out for the correct dtb.

Franklin S Cooper Jr (28):
  spl: fit: Break out some functions into a common file
  boot_fit: Create helper functions that can be used to select DTB out
of FIT
  fdt: Enable selecting correct DTB from append FIT Image
  ti: common: board_detect: Add function to determine if EEPROM was read
  dts: Allow OF_LIST to depend on FIT_EMBED
  arm: dts: Add new "generic" 66AK2Gx device tree file.
  ti_armv7_keystone2: Define scratch space in SRAM
  ARM: k2g: Enable TI board detection code
  board_f: Add new function to allow runtime DTB selection
  Makefile: Build additional binaries for dtb FIT blobs appended to
U-boot
  ARM: keystone2: Allow to build with all image formats
  ARM: k2g: Define embedded_dtb_select for runtime DTB selection in
U-boot
  ARM: keystone2: Define board_fit_config_name_match for Keystone 2
boards
  ks2_evm: Add EEPROM based board detection
  defconfig: keystone2: Enable U-boot runtime DTB detection
  ARM: keystone2: Add additional fields used for DDR3 configuration
  ARM: k2g: Program DDR PHY MR2 register with the default value
  ARM: k2g: Program DDRPHY_DATX8 registers via mask and value variables
  ks2_evm: Add EEPROM based board detection helper functions
  ARM: k2g: Add pinmux support for K2G ICE evm
  ARM: k2g: Add DDR3 configuration for K2G ICE evm
  board: ks2: Use board detection to wrap code not specific to K2G ICE
evm
  ARM: k2g: Use board detection to wrap K2G GP specific calls
  ARM: k2g: Update board_name u-boot env variable at runtime
  ARM: dts: k2g: Disable netcp by default
  ARM: dts: k2g: Add DT support for K2G Industrial Communication Engine
evm
  ARM: k2g: Add K2G ICE DTB to the list of possible DTBs
  defconfig: k2g_evm_defconfig: Add K2G ICE to OF_LIST

Lokesh Vutla (1):
  ti: common: board_detect: Rename EEPROM scratch start macro

Nishanth Menon (1):
  ti: common: board_detect: Allow settings board detection variables
manually

Roger Quadros (1):
  ARM: Use Kconfig for board EEPROM's I2C bus and chip address

 .gitignore |  1 +
 Makefile   | 18 -
 arch/arm/dts/Makefile  |  4 +-
 arch/arm/dts/keystone-k2g-evm.dts  |  4 ++
 arch/arm/dts/keystone-k2g-generic.dts  | 21 ++
 arch/arm/dts/keystone-k2g-ice.dts  | 25 +++
 arch/arm/dts/keystone-k2g-netcp.dtsi   |  1 +
 arch/arm/include/asm/omap_common.h |  8 ++-
 arch/arm/mach-keystone/Kconfig |  1 +
 arch/arm/mach-keystone/config.mk   |  4 +-
 arch/arm/mach-keystone/ddr3.c  | 35 --
 arch/arm/mach-keystone/include/mach/ddr3.h | 14 
 arch/arm/mach-keystone/include/mach/hardware.h |  3 +
 board/ti/common/Kconfig| 20 +-
 board/ti/common/board_detect.c | 34 ++
 board/ti/common/board_detect.h | 28 +++-
 board/ti/ks2_evm/Kconfig   |  2 +
 board/ti/ks2_evm/board.c   | 21 --
 board/ti/ks2_evm/board.h   | 21 ++
 board/ti/ks2_evm/board_k2e.c   | 10 +++
 board/ti/ks2_evm/board_k2g.c   | 93 +++---
 board/ti/ks2_evm/board_k2hk.c  | 10 +++
 board/ti/ks2_evm/board_k2l.c   | 10 +++
 board/ti/ks2_evm/ddr3_k2g.c| 78 -
 board/ti/ks2_evm/mux-k2g.h | 45 -
 common/Kconfig | 18 +
 common/Makefile|  2 +
 common/board_f.c   |  3 +
 common/boot_fit.c  | 58 
 common/common_fit.c| 86 
 common/spl/spl_fit.c   | 76 +
 configs/k2e_evm_defconfig  |  3 +
 configs/k2g_evm_defconfig  |  3 +
 configs/k2hk_evm_defconfig |  3 +
 configs/k2l_evm_defconfig  |  3 +
 dts/Kconfig| 11 +--
 include/boot_fit.h |  9 +++
 include/common.h   |  4 ++
 include/configs/am57xx_evm.h   |  4 --
 include/configs/dra7xx_evm.h   |  4 --
 include/configs/k2g_evm.h  | 14 +++-
 include/configs/ti_armv7_keystone2.h   |  7 ++
 include/image.h|  8 +

[U-Boot] [PATCH 05/31] ti: common: board_detect: Add function to determine if EEPROM was read

2017-03-02 Thread Franklin S Cooper Jr
When the EEPROM is first read its contents are stored in memory as a
cache to avoid further I2C operations. To determine if the EEPROM was
previously read the easiest way is to check the memory to see if the
EEPROM's magic header value is set. Create a new function that can
determine if the EEPROM was previously read or not without having to
perform a I2C transaction.

Signed-off-by: Franklin S Cooper Jr 
---
 board/ti/common/board_detect.c | 10 ++
 board/ti/common/board_detect.h |  9 +
 2 files changed, 19 insertions(+)

diff --git a/board/ti/common/board_detect.c b/board/ti/common/board_detect.c
index 5aaf884..b29807a 100644
--- a/board/ti/common/board_detect.c
+++ b/board/ti/common/board_detect.c
@@ -338,3 +338,13 @@ void __maybe_unused set_board_info_env(char *name)
else
setenv("board_serial", unknown);
 }
+
+bool __maybe_unused board_ti_was_eeprom_read(void)
+{
+   struct ti_common_eeprom *ep = TI_EEPROM_DATA;
+
+   if (ep->header == TI_EEPROM_HEADER_MAGIC)
+   return true;
+   else
+   return false;
+}
diff --git a/board/ti/common/board_detect.h b/board/ti/common/board_detect.h
index eeeacd3..97dc4e4 100644
--- a/board/ti/common/board_detect.h
+++ b/board/ti/common/board_detect.h
@@ -194,6 +194,15 @@ u64 board_ti_get_emif2_size(void);
 void set_board_info_env(char *name);
 
 /**
+ * board_ti_was_eeprom_read() - Check to see if the eeprom contents have been 
read
+ *
+ * This function is useful to determine if the eeprom has already been read and
+ * its contents have already been loaded into memory. It utiltzes the magic
+ * number that the header value is set to upon successful eeprom read.
+ */
+bool board_ti_was_eeprom_read(void);
+
+/**
  * ti_i2c_eeprom_am_set() - Setup the eeprom data with predefined values
  * @name:  Name of the board
  * @rev:   Revision of the board
-- 
2.10.0

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


[U-Boot] [PATCH 06/31] dts: Allow OF_LIST to depend on FIT_EMBED

2017-03-02 Thread Franklin S Cooper Jr
OF_LIST will be useable by SPL and U-boot. Therefore, update its
dependency to allow it to be enable by either SPL or U-boot specific
config option.

Signed-off-by: Franklin S Cooper Jr 
Reviewed-by: Tom Rini 
Reviewed-by: Lokesh Vutla 
Acked-by: Andrew F. Davis 
---
 dts/Kconfig | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/dts/Kconfig b/dts/Kconfig
index 4b7d8b1..ba019a8 100644
--- a/dts/Kconfig
+++ b/dts/Kconfig
@@ -61,14 +61,15 @@ config DEFAULT_DEVICE_TREE
 
 config OF_LIST
string "List of device tree files to include for DT control"
-   depends on SPL_LOAD_FIT
+   depends on SPL_LOAD_FIT || FIT_EMBED
default DEFAULT_DEVICE_TREE
help
  This option specifies a list of device tree files to use for DT
- control. These will be packaged into a FIT. At run-time, SPL will
- select the correct DT to use by examining the hardware (e.g.
- reading a board ID value). This is a list of device tree files
- (without the directory or .dtb suffix) separated by .
+ control. These will be packaged into a FIT. At run-time, U-boot
+ or SPL will select the correct DT to use by examining the
+ hardware (e.g. reading a board ID value). This is a list of
+ device tree files (without the directory or .dtb suffix)
+ separated by .
 
 config OF_SPL_REMOVE_PROPS
string "List of device tree properties to drop for SPL"
-- 
2.10.0

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


[U-Boot] [PATCH 02/31] spl: fit: Break out some functions into a common file

2017-03-02 Thread Franklin S Cooper Jr
Some of the functions within spl_fit will be used for non spl purposes.
Instead of duplicating functions simply break the functions to be reused
into its own file.

Signed-off-by: Franklin S Cooper Jr 
Reviewed-by: Tom Rini 
---
 common/Makefile  |  1 +
 common/common_fit.c  | 86 
 common/spl/spl_fit.c | 76 +-
 include/image.h  |  8 +
 4 files changed, 96 insertions(+), 75 deletions(-)
 create mode 100644 common/common_fit.c

diff --git a/common/Makefile b/common/Makefile
index 86225f1..692ebc4 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -94,6 +94,7 @@ obj-$(CONFIG_SPL_DFU_SUPPORT) += cli_hush.o
 obj-$(CONFIG_SPL_HASH_SUPPORT) += hash.o
 obj-$(CONFIG_ENV_IS_IN_FLASH) += env_flash.o
 obj-$(CONFIG_SPL_YMODEM_SUPPORT) += xyzModem.o
+obj-$(CONFIG_SPL_LOAD_FIT) += common_fit.o
 obj-$(CONFIG_SPL_NET_SUPPORT) += miiphyutil.o
 obj-$(CONFIG_SPL_OF_TRANSLATE) += fdt_support.o
 ifdef CONFIG_SPL_USB_HOST_SUPPORT
diff --git a/common/common_fit.c b/common/common_fit.c
new file mode 100644
index 000..a08af72
--- /dev/null
+++ b/common/common_fit.c
@@ -0,0 +1,86 @@
+/*
+ * Copyright (C) 2016 Google, Inc
+ * Written by Simon Glass 
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+ulong fdt_getprop_u32(const void *fdt, int node, const char *prop)
+{
+   const u32 *cell;
+   int len;
+
+   cell = fdt_getprop(fdt, node, prop, &len);
+   if (len != sizeof(*cell))
+   return -1U;
+   return fdt32_to_cpu(*cell);
+}
+
+int fit_select_fdt(const void *fdt, int images, int *fdt_offsetp)
+{
+   const char *name, *fdt_name;
+   int conf, node, fdt_node;
+   int len;
+
+   *fdt_offsetp = 0;
+   conf = fdt_path_offset(fdt, FIT_CONFS_PATH);
+   if (conf < 0) {
+   debug("%s: Cannot find /configurations node: %d\n", __func__,
+ conf);
+   return -EINVAL;
+   }
+   for (node = fdt_first_subnode(fdt, conf);
+node >= 0;
+node = fdt_next_subnode(fdt, node)) {
+   name = fdt_getprop(fdt, node, "description", &len);
+   if (!name) {
+#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
+   printf("%s: Missing FDT description in DTB\n",
+  __func__);
+#endif
+   return -EINVAL;
+   }
+   if (board_fit_config_name_match(name))
+   continue;
+
+   debug("Selecting config '%s'", name);
+   fdt_name = fdt_getprop(fdt, node, FIT_FDT_PROP, &len);
+   if (!fdt_name) {
+   debug("%s: Cannot find fdt name property: %d\n",
+ __func__, len);
+   return -EINVAL;
+   }
+
+   debug(", fdt '%s'\n", fdt_name);
+   fdt_node = fdt_subnode_offset(fdt, images, fdt_name);
+   if (fdt_node < 0) {
+   debug("%s: Cannot find fdt node '%s': %d\n",
+ __func__, fdt_name, fdt_node);
+   return -EINVAL;
+   }
+
+   *fdt_offsetp = fdt_getprop_u32(fdt, fdt_node, "data-offset");
+   len = fdt_getprop_u32(fdt, fdt_node, "data-size");
+   debug("FIT: Selected '%s'\n", name);
+
+   return len;
+   }
+
+#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
+   printf("No matching DT out of these options:\n");
+   for (node = fdt_first_subnode(fdt, conf);
+node >= 0;
+node = fdt_next_subnode(fdt, node)) {
+   name = fdt_getprop(fdt, node, "description", &len);
+   printf("   %s\n", name);
+   }
+#endif
+
+   return -ENOENT;
+}
diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index aae556f..3a722d3 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -11,80 +11,6 @@
 #include 
 #include 
 
-static ulong fdt_getprop_u32(const void *fdt, int node, const char *prop)
-{
-   const u32 *cell;
-   int len;
-
-   cell = fdt_getprop(fdt, node, prop, &len);
-   if (len != sizeof(*cell))
-   return -1U;
-   return fdt32_to_cpu(*cell);
-}
-
-static int spl_fit_select_fdt(const void *fdt, int images, int *fdt_offsetp)
-{
-   const char *name, *fdt_name;
-   int conf, node, fdt_node;
-   int len;
-
-   *fdt_offsetp = 0;
-   conf = fdt_path_offset(fdt, FIT_CONFS_PATH);
-   if (conf < 0) {
-   debug("%s: Cannot find /configurations node: %d\n", __func__,
- conf);
-   return -EINVAL;
-   }
-   for (node = fdt_first_subnode(fdt, conf);
-node >= 0;
-node = fdt_next_subnode(fdt, node)) {
-   name = fdt_getprop(fdt, node, "description", &len);
-   if (!name) {
-#ifdef CONFIG_SPL_LI

[U-Boot] [PATCH 01/31] ti: common: board_detect: Allow settings board detection variables manually

2017-03-02 Thread Franklin S Cooper Jr
From: Nishanth Menon 

In some situations the EEPROM used for board detection may not be
programmed or simply programmed incorrectly. Therefore, it may be
necessary to "simulate" reading the contents of the EEPROM to set
appropriate variables used in the board detection code.

This may also be helpful in certain boot modes where doing i2c reads
may be costly and the config supports running only a specific board.

Signed-off-by: Nishanth Menon 
Signed-off-by: Tero Kristo 
Signed-off-by: Keerthy 
Signed-off-by: Franklin S Cooper Jr. 
---
 board/ti/common/board_detect.c | 24 
 board/ti/common/board_detect.h | 17 +
 2 files changed, 41 insertions(+)

diff --git a/board/ti/common/board_detect.c b/board/ti/common/board_detect.c
index a5dba94..5aaf884 100644
--- a/board/ti/common/board_detect.c
+++ b/board/ti/common/board_detect.c
@@ -116,6 +116,30 @@ static int __maybe_unused ti_i2c_eeprom_get(int bus_addr, 
int dev_addr,
return 0;
 }
 
+int __maybe_unused ti_i2c_eeprom_am_set(const char *name, const char *rev)
+{
+   struct ti_common_eeprom *ep;
+
+   if (!name || !rev)
+   return -1;
+
+   ep = TI_EEPROM_DATA;
+   if (ep->header == TI_EEPROM_HEADER_MAGIC)
+   goto already_set;
+
+   /* Set to 0 all fields */
+   memset(ep, 0, sizeof(*ep));
+   strncpy(ep->name, name, TI_EEPROM_HDR_NAME_LEN);
+   strncpy(ep->version, rev, TI_EEPROM_HDR_REV_LEN);
+   /* Some dummy serial number to identify the platform */
+   strncpy(ep->serial, "", TI_EEPROM_HDR_SERIAL_LEN);
+   /* Mark it with a valid header */
+   ep->header = TI_EEPROM_HEADER_MAGIC;
+
+already_set:
+   return 0;
+}
+
 int __maybe_unused ti_i2c_eeprom_am_get(int bus_addr, int dev_addr)
 {
int rc;
diff --git a/board/ti/common/board_detect.h b/board/ti/common/board_detect.h
index 343fcb4..eeeacd3 100644
--- a/board/ti/common/board_detect.h
+++ b/board/ti/common/board_detect.h
@@ -193,4 +193,21 @@ u64 board_ti_get_emif2_size(void);
  */
 void set_board_info_env(char *name);
 
+/**
+ * ti_i2c_eeprom_am_set() - Setup the eeprom data with predefined values
+ * @name:  Name of the board
+ * @rev:   Revision of the board
+ *
+ * In some cases such as in RTC-only mode, we are able to skip reading eeprom
+ * and wasting i2c based initialization time by using predefined flags for
+ * detecting what platform we are booting on. For those platforms, provide
+ * a handy function to pre-program information.
+ *
+ * NOTE: many eeprom information such as serial number, mac address etc is not
+ * available.
+ *
+ * Return: 0 if all went fine, else return error.
+ */
+int ti_i2c_eeprom_am_set(const char *name, const char *rev);
+
 #endif /* __BOARD_DETECT_H */
-- 
2.10.0

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


[U-Boot] [PATCH] do_smhload: fix return code

2017-03-02 Thread Ryan Harkin
do_smhload was using a ulong to store the return value from
smh_load_file. That returns an int, where -1 indicates an error. As a
ulong will never be negative, smh_load_file errors were not detected and
so_smhload always returned zero.

Also, when errors were spotted, do_smhload was returning 1, rather than
the enumeration CMD_RET_FAILURE (which is also 1).

Signed-off-by: Ryan Harkin 
---
 arch/arm/lib/semihosting.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/lib/semihosting.c b/arch/arm/lib/semihosting.c
index e32ad90..415ac89 100644
--- a/arch/arm/lib/semihosting.c
+++ b/arch/arm/lib/semihosting.c
@@ -186,7 +186,7 @@ static int do_smhload(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
if (argc == 3 || argc == 4) {
ulong load_addr;
ulong end_addr = 0;
-   ulong ret;
+   int ret;
char end_str[64];
 
load_addr = simple_strtoul(argv[2], NULL, 16);
@@ -195,7 +195,7 @@ static int do_smhload(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
 
ret = smh_load_file(argv[1], load_addr, &end_addr);
if (ret < 0)
-   return 1;
+   return CMD_RET_FAILURE;
 
/* Optionally save returned end to the environment */
if (argc == 4) {
-- 
2.7.4

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


[U-Boot] [PATCH] arm: Update our 'ret' assembler macro slightly

2017-03-02 Thread Tom Rini
We only support cores that do Thumb-1 or later.  So we add a comment to
explain this and remove the architecture test.

Cc: Albert ARIBAUD 
Cc: Mans Rullgard 
Signed-off-by: Tom Rini 
---
 arch/arm/include/asm/assembler.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
index c56daf2a1f69..d24be2d484fe 100644
--- a/arch/arm/include/asm/assembler.h
+++ b/arch/arm/include/asm/assembler.h
@@ -57,17 +57,17 @@
 #define PLD(code...)
 #endif
 
+/*
+ * We only support cores that support at least Thumb-1 and thus we use
+ * 'bx lr'
+ */
.irpc,,eq,ne,cs,cc,mi,pl,vs,vc,hi,ls,ge,lt,gt,le,hs,lo
.macro  ret\c, reg
-#if defined(__ARM_ARCH_5E__)
-   mov\c   pc, \reg
-#else
.ifeqs  "\reg", "lr"
bx\c\reg
.else
mov\c   pc, \reg
.endif
-#endif
.endm
.endr
 
-- 
1.9.1

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


Re: [U-Boot] [PATCH] armv5te: make 'ret lr' produce iinterworking 'bx lr'

2017-03-02 Thread Måns Rullgård
Tom Rini  writes:

> On Thu, Mar 02, 2017 at 02:27:03PM +, Måns Rullgård wrote:
>> Tom Rini  writes:
>> 
>> > On Mon, Feb 27, 2017 at 08:19:07PM +0100, Albert ARIBAUD wrote:
>> >> Current ARM assembler helper for the 'return to caller' pseudo-instruction
>> >> turns 'ret lr' into 'mov pc, lr' for ARMv5TE. This causes the core to 
>> >> remain
>> >> in its current ARM state even when the routine doing the 'ret' was called
>> >> from Thumb-1 state, triggering an undefined instruction exception.
>> >> 
>> >> This causes early run-time failures in all boards compiled using the 
>> >> Thumb-1
>> >> instruction set (for instance the Open-RD family).
>> >> 
>> >> ARMv5TE supports 'bx lr' which properly implements interworking and thus
>> >> correctly returns to Thumb-1 state from ARM state.
>> >> 
>> >> This change makes 'ret lr' turn into 'bx lr' for ARMv5TE.
>> >> 
>> >> Signed-off-by: Albert ARIBAUD 
>> >> ---
>> >> Note: this patch supersedes patch "openrd: disable private arch memset,
>> >> memcpy and libgcc" dated Sun, 26 Feb 2017 16:29:32 +0100.
>> >> 
>> >>  arch/arm/include/asm/assembler.h | 2 +-
>> >>  1 file changed, 1 insertion(+), 1 deletion(-)
>> >> 
>> >> diff --git a/arch/arm/include/asm/assembler.h 
>> >> b/arch/arm/include/asm/assembler.h
>> >> index ae1e42fc06..c56daf2a1f 100644
>> >> --- a/arch/arm/include/asm/assembler.h
>> >> +++ b/arch/arm/include/asm/assembler.h
>> >> @@ -59,7 +59,7 @@
>> >>  
>> >>   .irpc,,eq,ne,cs,cc,mi,pl,vs,vc,hi,ls,ge,lt,gt,le,hs,lo
>> >>   .macro  ret\c, reg
>> >> -#if defined(__ARM_ARCH_5E__) || defined(__ARM_ARCH_5TE__)
>> >> +#if defined(__ARM_ARCH_5E__)
>> >>   mov\c   pc, \reg
>> >>  #else
>> >>   .ifeqs  "\reg", "lr"
>> >
>> > Emperical wins over theory, so I'll take this patch so we don't break
>> > things.  But looking at the kernel, the above is a test for
>> > __LINUX_ARM_ARCH__ < 6 instead.  But the kernel is hardly ever built and
>> > run in Thumb mode rather than ARM mode, so they wouldn't be tickling
>> > this particular issue.
>> 
>> The kernel needs Thumb-2, so the requirements are a bit different there.
>
> Ah, right.
>
>> > I guess my big question now is, when can / should we not just use 'bx
>> > lr' over 'mov pc, lr' ?
>> 
>> All cores with Thumb support the bx instruction.  The only time you want
>> to use "mov pc" is with non-Thumb v4 and v5 cores.
>
> So, of ARM720T, ARM920T, ARM926EJS and ARM946ES, which fall into that
> category?  Or is it harder to say than that?

All of those support Thumb and thus the bx instruction.

The blx instruction, which simplifies interworking, is only available
from v5T, but that's not relevant here.

-- 
Måns Rullgård
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] armv5te: make 'ret lr' produce iinterworking 'bx lr'

2017-03-02 Thread Tom Rini
On Thu, Mar 02, 2017 at 02:27:03PM +, Måns Rullgård wrote:
> Tom Rini  writes:
> 
> > On Mon, Feb 27, 2017 at 08:19:07PM +0100, Albert ARIBAUD wrote:
> >> Current ARM assembler helper for the 'return to caller' pseudo-instruction
> >> turns 'ret lr' into 'mov pc, lr' for ARMv5TE. This causes the core to 
> >> remain
> >> in its current ARM state even when the routine doing the 'ret' was called
> >> from Thumb-1 state, triggering an undefined instruction exception.
> >> 
> >> This causes early run-time failures in all boards compiled using the 
> >> Thumb-1
> >> instruction set (for instance the Open-RD family).
> >> 
> >> ARMv5TE supports 'bx lr' which properly implements interworking and thus
> >> correctly returns to Thumb-1 state from ARM state.
> >> 
> >> This change makes 'ret lr' turn into 'bx lr' for ARMv5TE.
> >> 
> >> Signed-off-by: Albert ARIBAUD 
> >> ---
> >> Note: this patch supersedes patch "openrd: disable private arch memset,
> >> memcpy and libgcc" dated Sun, 26 Feb 2017 16:29:32 +0100.
> >> 
> >>  arch/arm/include/asm/assembler.h | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >> 
> >> diff --git a/arch/arm/include/asm/assembler.h 
> >> b/arch/arm/include/asm/assembler.h
> >> index ae1e42fc06..c56daf2a1f 100644
> >> --- a/arch/arm/include/asm/assembler.h
> >> +++ b/arch/arm/include/asm/assembler.h
> >> @@ -59,7 +59,7 @@
> >>  
> >>.irpc,,eq,ne,cs,cc,mi,pl,vs,vc,hi,ls,ge,lt,gt,le,hs,lo
> >>.macro  ret\c, reg
> >> -#if defined(__ARM_ARCH_5E__) || defined(__ARM_ARCH_5TE__)
> >> +#if defined(__ARM_ARCH_5E__)
> >>mov\c   pc, \reg
> >>  #else
> >>.ifeqs  "\reg", "lr"
> >
> > Emperical wins over theory, so I'll take this patch so we don't break
> > things.  But looking at the kernel, the above is a test for
> > __LINUX_ARM_ARCH__ < 6 instead.  But the kernel is hardly ever built and
> > run in Thumb mode rather than ARM mode, so they wouldn't be tickling
> > this particular issue.
> 
> The kernel needs Thumb-2, so the requirements are a bit different there.

Ah, right.

> > I guess my big question now is, when can / should we not just use 'bx
> > lr' over 'mov pc, lr' ?
> 
> All cores with Thumb support the bx instruction.  The only time you want
> to use "mov pc" is with non-Thumb v4 and v5 cores.

So, of ARM720T, ARM920T, ARM926EJS and ARM946ES, which fall into that
category?  Or is it harder to say than that?

-- 
Tom


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


Re: [U-Boot] [PATCH] armv5te: make 'ret lr' produce iinterworking 'bx lr'

2017-03-02 Thread Måns Rullgård
Tom Rini  writes:

> On Mon, Feb 27, 2017 at 08:19:07PM +0100, Albert ARIBAUD wrote:
>> Current ARM assembler helper for the 'return to caller' pseudo-instruction
>> turns 'ret lr' into 'mov pc, lr' for ARMv5TE. This causes the core to remain
>> in its current ARM state even when the routine doing the 'ret' was called
>> from Thumb-1 state, triggering an undefined instruction exception.
>> 
>> This causes early run-time failures in all boards compiled using the Thumb-1
>> instruction set (for instance the Open-RD family).
>> 
>> ARMv5TE supports 'bx lr' which properly implements interworking and thus
>> correctly returns to Thumb-1 state from ARM state.
>> 
>> This change makes 'ret lr' turn into 'bx lr' for ARMv5TE.
>> 
>> Signed-off-by: Albert ARIBAUD 
>> ---
>> Note: this patch supersedes patch "openrd: disable private arch memset,
>> memcpy and libgcc" dated Sun, 26 Feb 2017 16:29:32 +0100.
>> 
>>  arch/arm/include/asm/assembler.h | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/arch/arm/include/asm/assembler.h 
>> b/arch/arm/include/asm/assembler.h
>> index ae1e42fc06..c56daf2a1f 100644
>> --- a/arch/arm/include/asm/assembler.h
>> +++ b/arch/arm/include/asm/assembler.h
>> @@ -59,7 +59,7 @@
>>  
>>  .irpc,,eq,ne,cs,cc,mi,pl,vs,vc,hi,ls,ge,lt,gt,le,hs,lo
>>  .macro  ret\c, reg
>> -#if defined(__ARM_ARCH_5E__) || defined(__ARM_ARCH_5TE__)
>> +#if defined(__ARM_ARCH_5E__)
>>  mov\c   pc, \reg
>>  #else
>>  .ifeqs  "\reg", "lr"
>
> Emperical wins over theory, so I'll take this patch so we don't break
> things.  But looking at the kernel, the above is a test for
> __LINUX_ARM_ARCH__ < 6 instead.  But the kernel is hardly ever built and
> run in Thumb mode rather than ARM mode, so they wouldn't be tickling
> this particular issue.

The kernel needs Thumb-2, so the requirements are a bit different there.

> I guess my big question now is, when can / should we not just use 'bx
> lr' over 'mov pc, lr' ?

All cores with Thumb support the bx instruction.  The only time you want
to use "mov pc" is with non-Thumb v4 and v5 cores.

-- 
Måns Rullgård
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH][v2] armv8: ls2080aqds: Add support for SD boot

2017-03-02 Thread Tom Rini
On Thu, Mar 02, 2017 at 04:05:49PM +0530, Santan Kumar wrote:

A little here please.

> Signed-off-by: Santan Kumar 
> Signed-off-by: Priyanka Jain 
> Signed-off-by: Abhimanyu Saini 
[snip]
> diff --git a/include/configs/ls2080a_common.h 
> b/include/configs/ls2080a_common.h
> index ae72939..d63208b 100644
> --- a/include/configs/ls2080a_common.h
> +++ b/include/configs/ls2080a_common.h
> @@ -230,6 +230,8 @@ unsigned long long get_qixis_addr(void);
>  #define CONFIG_SPL_NAND_SUPPORT
>  #define CONFIG_SYS_NAND_U_BOOT_DST   0x8040
>  #define CONFIG_SYS_NAND_U_BOOT_START CONFIG_SYS_NAND_U_BOOT_DST
> +#elif defined(CONFIG_SD_BOOT)
> +#define CONFIG_SPL_MMC_SUPPORT

This is in Kconfig.

> @@ -165,12 +169,14 @@ unsigned long get_board_ddr_clk(void);
>  #define QIXIS_LBMAP_DFLTBANK 0x00
>  #define QIXIS_LBMAP_ALTBANK  0x04
>  #define QIXIS_LBMAP_NAND 0x09
> +#define QIXIS_LBMAP_SD   0x00
>  #define QIXIS_LBMAP_QSPI 0x0f
>  #define QIXIS_RST_CTL_RESET  0x31
>  #define QIXIS_RCFG_CTL_RECONFIG_IDLE 0x20
>  #define QIXIS_RCFG_CTL_RECONFIG_START0x21
>  #define QIXIS_RCFG_CTL_WATCHDOG_ENBLE0x08
>  #define QIXIS_RCW_SRC_NAND   0x107
> +#define QIXIS_RCW_SRC_SD 0x40
>  #define QIXIS_RCW_SRC_QSPI   0x62
>  #define  QIXIS_RST_FORCE_MEM 0x01

All of this needs to get moved out of the config header file.  Please
make a note to add this to your TODO list, thanks.

-- 
Tom


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


Re: [U-Boot] [PATCH][v2] armv8:ls2080a: Reorganise NAND_BOOT code in config flag

2017-03-02 Thread Tom Rini
On Thu, Mar 02, 2017 at 04:05:48PM +0530, Santan Kumar wrote:

> Add CONFIG_NAND_BOOT config flag to organise
> NAND_BOOT specific code in config flag like
> -nand-boot specfic errata errata_rcw_src()
> -CONFIG_SYS_NAND_U_BOOT_DST,etc
> 
> Signed-off-by: Santan Kumar 
> Signed-off-by: Priyanka Jain 
> Signed-off-by: Abhimanyu Saini 
> ---
> Changes for v2:
>  Rebased to latest codebase
>  Incorporated York's comments to defined CONFIG_NAND_BOOT
>  in new line
> 
>  arch/arm/cpu/armv8/fsl-layerscape/soc.c | 2 +-
>  configs/ls2080aqds_nand_defconfig   | 1 +
>  configs/ls2080ardb_nand_defconfig   | 1 +
>  include/configs/ls2080a_common.h| 5 +
>  include/configs/ls2080aqds.h| 4 +++-
>  5 files changed, 11 insertions(+), 2 deletions(-)
[snip]
> --- a/include/configs/ls2080a_common.h
> +++ b/include/configs/ls2080a_common.h
> @@ -216,6 +216,7 @@ unsigned long long get_qixis_addr(void);
>  
>  #define CONFIG_PANIC_HANG/* do not reset board on panic */
>  
> +#ifdef CONFIG_SPL
>  #define CONFIG_SPL_BSS_START_ADDR0x8010
>  #define CONFIG_SPL_BSS_MAX_SIZE  0x0010
>  #define CONFIG_SPL_FRAMEWORK
> @@ -225,11 +226,15 @@ unsigned long long get_qixis_addr(void);
>  #define CONFIG_SPL_TARGET"u-boot-with-spl.bin"
>  #define CONFIG_SPL_TEXT_BASE 0x1800a000
>  
> +#ifdef CONFIG_NAND_BOOT
> +#define CONFIG_SPL_NAND_SUPPORT
>  #define CONFIG_SYS_NAND_U_BOOT_DST   0x8040
>  #define CONFIG_SYS_NAND_U_BOOT_START CONFIG_SYS_NAND_U_BOOT_DST
> +#endif
>  #define CONFIG_SYS_SPL_MALLOC_SIZE   0x0010
>  #define CONFIG_SYS_SPL_MALLOC_START  0x8020
>  #define CONFIG_SYS_MONITOR_LEN   (640 * 1024)
> +#endif
>  
>  #define CONFIG_SYS_BOOTM_LEN   (64 << 20)  /* Increase max gunzip size */

This applies to the other config file as well.  But, why do you need to
hide CONFIG_SPL_xxx behind a check for CONFIG_SPL?  That seems wrong.
Also, CONFIG_SPL_NAND_SUPPORT is in Kconfig so we should be select'ing
that under NAND_BOOT (which is also in Kconfig).  We should not have to
hide those used values as well, either.

-- 
Tom


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


[U-Boot] Someone expert in lvds timings ?

2017-03-02 Thread far5893

I'm trying to generate u-boot timings for 
http://www.notebook-lcd.ru/pdf/QD17EL07_REV_11.pdf page 11.

i try 
(x:640,y:1024,depth:24,pclk_khz:54000,le:45,ri:200,up:22,lo:22,hs:1,vs:1,sync:3,vmode:0)
 LCD panel timing details

does someone have experience in writing such timings ?

The panel is dual channel but i create an Y cable to feed two channels from only one supported by u-boot(but i try one channel 
only cable).


My scope is to validate my setup for try to add dual lvds channel support on 
u-boot on A10(cubieboard1).


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


[U-Boot] [PATCH 2/2][v3] armv8: ls2080aqds: Add support for SD boot

2017-03-02 Thread Santan Kumar
Signed-off-by: Santan Kumar 
Signed-off-by: Priyanka Jain 
Signed-off-by: Abhimanyu Saini 
---
Changes for v3:
 Rebased to latest codebase

Depends on
 York MMU patches: 
http://patchwork.ozlabs.org/bundle/yorksun/Rewrite_MMU/ 
 For correct type of image creation: 
https://patchwork.ozlabs.org/patch/671466/

 arch/arm/cpu/armv8/fsl-layerscape/cpu.c|  6 +--
 .../cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c|  6 +--
 board/freescale/ls2080a/ls2080a.c  |  6 +--
 board/freescale/ls2080aqds/eth.c   |  8 +---
 board/freescale/ls2080aqds/ls2080aqds.c|  4 +-
 configs/ls2080aqds_sdcard_defconfig| 53 ++
 include/configs/ls2080a_common.h   |  9 
 include/configs/ls2080aqds.h   | 33 --
 8 files changed, 105 insertions(+), 20 deletions(-)
 create mode 100644 configs/ls2080aqds_sdcard_defconfig

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c 
b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
index 17258a7..d9e2a90 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
@@ -435,7 +435,7 @@ int cpu_eth_init(bd_t *bis)
 {
int error = 0;
 
-#ifdef CONFIG_FSL_MC_ENET
+#if defined(CONFIG_FSL_MC_ENET) && !defined(CONFIG_SPL_BUILD)
error = fsl_mc_ldpaa_init(bis);
 #endif
 #ifdef CONFIG_FMAN_ENET
@@ -571,7 +571,7 @@ phys_size_t board_reserve_ram_top(phys_size_t ram_size)
 {
phys_size_t ram_top = ram_size;
 
-#ifdef CONFIG_FSL_MC_ENET
+#if defined(CONFIG_FSL_MC_ENET) && !defined(CONFIG_SPL_BUILD)
/* The start address of MC reserved memory needs to be aligned. */
ram_top -= mc_get_dram_block_size();
ram_top &= ~(CONFIG_SYS_MC_RSV_MEM_ALIGN - 1);
@@ -686,7 +686,7 @@ void dram_init_banksize(void)
}
 #endif /* CONFIG_SYS_MEM_RESERVE_SECURE */
 
-#ifdef CONFIG_FSL_MC_ENET
+#if defined(CONFIG_FSL_MC_ENET) && !defined(CONFIG_SPL_BUILD)
/* Assign memory for MC */
 #ifdef CONFIG_SYS_DDR_BLOCK3_BASE
if (gd->bd->bi_dram[2].size >=
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c 
b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c
index 7faa86c..10d7f47 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c
@@ -18,7 +18,7 @@ static u8 serdes1_prtcl_map[SERDES_PRCTL_COUNT];
 static u8 serdes2_prtcl_map[SERDES_PRCTL_COUNT];
 #endif
 
-#ifdef CONFIG_FSL_MC_ENET
+#if defined(CONFIG_FSL_MC_ENET) && !defined(CONFIG_SPL_BUILD)
 int xfi_dpmac[XFI8 + 1];
 int sgmii_dpmac[SGMII16 + 1];
 #endif
@@ -103,7 +103,7 @@ void serdes_init(u32 sd, u32 sd_addr, u32 sd_prctl_mask, 
u32 sd_prctl_shift,
debug("Unknown SerDes lane protocol %d\n", lane_prtcl);
else {
serdes_prtcl_map[lane_prtcl] = 1;
-#ifdef CONFIG_FSL_MC_ENET
+#if defined(CONFIG_FSL_MC_ENET) && !defined(CONFIG_SPL_BUILD)
switch (lane_prtcl) {
case QSGMII_A:
wriop_init_dpmac(sd, 5, (int)lane_prtcl);
@@ -152,7 +152,7 @@ void serdes_init(u32 sd, u32 sd_addr, u32 sd_prctl_mask, 
u32 sd_prctl_shift,
 
 void fsl_serdes_init(void)
 {
-#ifdef CONFIG_FSL_MC_ENET
+#if defined(CONFIG_FSL_MC_ENET) && !defined(CONFIG_SPL_BUILD)
int i , j;
 
for (i = XFI1, j = 1; i <= XFI8; i++, j++)
diff --git a/board/freescale/ls2080a/ls2080a.c 
b/board/freescale/ls2080a/ls2080a.c
index ace5bf6..cff468b 100644
--- a/board/freescale/ls2080a/ls2080a.c
+++ b/board/freescale/ls2080a/ls2080a.c
@@ -64,13 +64,13 @@ int board_eth_init(bd_t *bis)
error = smc9_initialize(0, CONFIG_SMC9_BASE);
 #endif
 
-#ifdef CONFIG_FSL_MC_ENET
+#if defined(CONFIG_FSL_MC_ENET) && !defined(CONFIG_SPL_BUILD)
error = cpu_eth_init(bis);
 #endif
return error;
 }
 
-#ifdef CONFIG_FSL_MC_ENET
+#if defined(CONFIG_FSL_MC_ENET) && !defined(CONFIG_SPL_BUILD)
 void fdt_fixup_board_enet(void *fdt)
 {
int offset;
@@ -128,7 +128,7 @@ int ft_board_setup(void *blob, bd_t *bd)
 
fdt_fixup_memory_banks(blob, base, size, 2);
 
-#ifdef CONFIG_FSL_MC_ENET
+#if defined(CONFIG_FSL_MC_ENET) && !defined(CONFIG_SPL_BUILD)
fdt_fixup_board_enet(blob);
 #endif
 
diff --git a/board/freescale/ls2080aqds/eth.c b/board/freescale/ls2080aqds/eth.c
index 59361e9..302ff76 100644
--- a/board/freescale/ls2080aqds/eth.c
+++ b/board/freescale/ls2080aqds/eth.c
@@ -22,7 +22,7 @@
 
 #define MC_BOOT_ENV_VAR "mcinitcmd"
 
-#ifdef CONFIG_FSL_MC_ENET
+#if defined(CONFIG_FSL_MC_ENET) && !defined(CONFIG_SPL_BUILD)
  /* - In LS2080A there are only 16 SERDES lanes, spread across 2 SERDES banks.
  *   Bank 1 -> Lanes A, B, C, D, E, F, G, H
  *   Bank 2 -> Lanes A,B, C, D, E, F, G, H
@@ -834,8 +834,8 @@ void ls2080a_handle_phy_interface_xsgmii(int i)
 int board_eth_init(bd_t *bis)
 {
int error;
+#if defined(CONFIG_FSL_MC_ENET) &

[U-Boot] [PATCH 1/2][v3] armv8: ls2080a: Reorganise NAND_BOOT code in config flag

2017-03-02 Thread Santan Kumar
Add CONFIG_NAND_BOOT config flag to organise
NAND_BOOT specific code in config flag like
-nand-boot specfic errata errata_rcw_src()
-CONFIG_SYS_NAND_U_BOOT_DST,etc

Signed-off-by: Santan Kumar 
Signed-off-by: Priyanka Jain 
Signed-off-by: Abhimanyu Saini 
---
Changes for v3:
 Rebased to latest codebase
 Incorporated York's comments to defined CONFIG_NAND_BOOT
 in new line

 arch/arm/cpu/armv8/fsl-layerscape/soc.c | 2 +-
 configs/ls2080aqds_nand_defconfig   | 1 +
 configs/ls2080ardb_nand_defconfig   | 1 +
 include/configs/ls2080a_common.h| 5 +
 include/configs/ls2080aqds.h| 4 +++-
 5 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c 
b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
index 9489f85..fa68baf 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
@@ -134,7 +134,7 @@ void erratum_a009635(void)
 
 static void erratum_rcw_src(void)
 {
-#if defined(CONFIG_SPL)
+#if defined(CONFIG_SPL) && defined(CONFIG_NAND_BOOT)
u32 __iomem *dcfg_ccsr = (u32 __iomem *)DCFG_BASE;
u32 __iomem *dcfg_dcsr = (u32 __iomem *)DCFG_DCSR_BASE;
u32 val;
diff --git a/configs/ls2080aqds_nand_defconfig 
b/configs/ls2080aqds_nand_defconfig
index 8910938..bc0b9b1 100644
--- a/configs/ls2080aqds_nand_defconfig
+++ b/configs/ls2080aqds_nand_defconfig
@@ -12,6 +12,7 @@ CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_OF_STDOUT_VIA_ALIAS=y
+CONFIG_NAND_BOOT=y
 CONFIG_SYS_EXTRA_OPTIONS="NAND, LS2080A"
 CONFIG_BOOTDELAY=10
 CONFIG_SPL=y
diff --git a/configs/ls2080ardb_nand_defconfig 
b/configs/ls2080ardb_nand_defconfig
index 8223111..d449190 100644
--- a/configs/ls2080ardb_nand_defconfig
+++ b/configs/ls2080ardb_nand_defconfig
@@ -12,6 +12,7 @@ CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_OF_STDOUT_VIA_ALIAS=y
+CONFIG_NAND_BOOT=y
 CONFIG_SYS_EXTRA_OPTIONS="NAND, LS2080A"
 CONFIG_BOOTDELAY=10
 CONFIG_SPL=y
diff --git a/include/configs/ls2080a_common.h b/include/configs/ls2080a_common.h
index 4173d9a..ae72939 100644
--- a/include/configs/ls2080a_common.h
+++ b/include/configs/ls2080a_common.h
@@ -216,6 +216,7 @@ unsigned long long get_qixis_addr(void);
 
 #define CONFIG_PANIC_HANG  /* do not reset board on panic */
 
+#ifdef CONFIG_SPL
 #define CONFIG_SPL_BSS_START_ADDR  0x8010
 #define CONFIG_SPL_BSS_MAX_SIZE0x0010
 #define CONFIG_SPL_FRAMEWORK
@@ -225,11 +226,15 @@ unsigned long long get_qixis_addr(void);
 #define CONFIG_SPL_TARGET  "u-boot-with-spl.bin"
 #define CONFIG_SPL_TEXT_BASE   0x1800a000
 
+#ifdef CONFIG_NAND_BOOT
+#define CONFIG_SPL_NAND_SUPPORT
 #define CONFIG_SYS_NAND_U_BOOT_DST 0x8040
 #define CONFIG_SYS_NAND_U_BOOT_START   CONFIG_SYS_NAND_U_BOOT_DST
+#endif
 #define CONFIG_SYS_SPL_MALLOC_SIZE 0x0010
 #define CONFIG_SYS_SPL_MALLOC_START0x8020
 #define CONFIG_SYS_MONITOR_LEN (640 * 1024)
+#endif
 
 #define CONFIG_SYS_BOOTM_LEN   (64 << 20)  /* Increase max gunzip size */
 
diff --git a/include/configs/ls2080aqds.h b/include/configs/ls2080aqds.h
index 08d1586..93f6b51 100644
--- a/include/configs/ls2080aqds.h
+++ b/include/configs/ls2080aqds.h
@@ -197,7 +197,8 @@ unsigned long get_board_ddr_clk(void);
FTIM2_GPCM_TWP(0x3E))
 #define CONFIG_SYS_CS3_FTIM3   0x0
 
-#if defined(CONFIG_SPL) && defined(CONFIG_NAND)
+#if defined(CONFIG_SPL)
+#if defined(CONFIG_NAND_BOOT)
 #define CONFIG_SYS_CSPR1_EXT   CONFIG_SYS_NOR0_CSPR_EXT
 #define CONFIG_SYS_CSPR1   CONFIG_SYS_NOR0_CSPR_EARLY
 #define CONFIG_SYS_CSPR1_FINAL CONFIG_SYS_NOR0_CSPR
@@ -233,6 +234,7 @@ unsigned long get_board_ddr_clk(void);
 #define CONFIG_SPL_PAD_TO  0x2
 #define CONFIG_SYS_NAND_U_BOOT_OFFS(256 * 1024)
 #define CONFIG_SYS_NAND_U_BOOT_SIZE(640 * 1024)
+#endif
 #else
 #define CONFIG_SYS_CSPR0_EXT   CONFIG_SYS_NOR0_CSPR_EXT
 #define CONFIG_SYS_CSPR0   CONFIG_SYS_NOR0_CSPR_EARLY
-- 
1.9.1

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


Re: [U-Boot] arm: cache: misaligned operation with fastboot

2017-03-02 Thread Lukasz Majewski
Hi,

> Hi Fabio, Lukasz,
> 
> On Wed, Feb 15, 2017 at 02:24:40PM -0200, Fabio Estevam wrote:
> > On Wed, Feb 15, 2017 at 2:04 PM, Gary Bisson
> >  wrote:
> > > Hi,
> > >
> > > I've been testing fastboot to flash a sparse image on a i.MX6Q
> > > platform (Nitrogen6x) with U-Boot v2017.01.
> > >
> > > This test shows a lot of "misaligned operation" traces:
> > > => fastboot 0
> > > Starting download of 415679660 bytes
> > > ...
> > > downloading of 415679660 bytes finished
> > > Flashing sparse image at offset 82124
> > > Flashing Sparse Image
> > > CACHE: Misaligned operation at range [1228, 12028028]
> > > CACHE: Misaligned operation at range [12028044, 1208f044]
> > > CACHE: Misaligned operation at range [1208f060, 123fd060]
> > > ...
> > >
> > > Has any of you seen that behavior?
> > >
> > > Note that this behavior only happens for sparse images, flashing
> > > a raw image doesn't exhibit the problem.
> > 
> > Adding DFU maintainer, Lukasz on Cc.
> 
> Any update on this? Has anyone been able to reproduce?

I don't have setup to test the fastboot.

I can integrate patches (to -dfu) tree if you have one.

> 
> Regards,
> Gary




Best regards,

Lukasz Majewski

--

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
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH][v2] armv8: ls2080aqds: Add support for SD boot

2017-03-02 Thread Santan Kumar
Signed-off-by: Santan Kumar 
Signed-off-by: Priyanka Jain 
Signed-off-by: Abhimanyu Saini 
---
Changes for v2:
 Rebased to latest codebase

Depends on
 York MMU patches: 
http://patchwork.ozlabs.org/bundle/yorksun/Rewrite_MMU/ 
 For correct type of image creation: 
https://patchwork.ozlabs.org/patch/671466/

 arch/arm/cpu/armv8/fsl-layerscape/cpu.c|  6 +--
 .../cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c|  6 +--
 board/freescale/ls2080a/ls2080a.c  |  6 +--
 board/freescale/ls2080aqds/eth.c   |  8 +---
 board/freescale/ls2080aqds/ls2080aqds.c|  4 +-
 configs/ls2080aqds_sdcard_defconfig| 53 ++
 include/configs/ls2080a_common.h   |  2 +
 include/configs/ls2080aqds.h   | 13 +-
 8 files changed, 80 insertions(+), 18 deletions(-)
 create mode 100644 configs/ls2080aqds_sdcard_defconfig

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c 
b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
index 17258a7..d9e2a90 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
@@ -435,7 +435,7 @@ int cpu_eth_init(bd_t *bis)
 {
int error = 0;
 
-#ifdef CONFIG_FSL_MC_ENET
+#if defined(CONFIG_FSL_MC_ENET) && !defined(CONFIG_SPL_BUILD)
error = fsl_mc_ldpaa_init(bis);
 #endif
 #ifdef CONFIG_FMAN_ENET
@@ -571,7 +571,7 @@ phys_size_t board_reserve_ram_top(phys_size_t ram_size)
 {
phys_size_t ram_top = ram_size;
 
-#ifdef CONFIG_FSL_MC_ENET
+#if defined(CONFIG_FSL_MC_ENET) && !defined(CONFIG_SPL_BUILD)
/* The start address of MC reserved memory needs to be aligned. */
ram_top -= mc_get_dram_block_size();
ram_top &= ~(CONFIG_SYS_MC_RSV_MEM_ALIGN - 1);
@@ -686,7 +686,7 @@ void dram_init_banksize(void)
}
 #endif /* CONFIG_SYS_MEM_RESERVE_SECURE */
 
-#ifdef CONFIG_FSL_MC_ENET
+#if defined(CONFIG_FSL_MC_ENET) && !defined(CONFIG_SPL_BUILD)
/* Assign memory for MC */
 #ifdef CONFIG_SYS_DDR_BLOCK3_BASE
if (gd->bd->bi_dram[2].size >=
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c 
b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c
index 7faa86c..10d7f47 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c
@@ -18,7 +18,7 @@ static u8 serdes1_prtcl_map[SERDES_PRCTL_COUNT];
 static u8 serdes2_prtcl_map[SERDES_PRCTL_COUNT];
 #endif
 
-#ifdef CONFIG_FSL_MC_ENET
+#if defined(CONFIG_FSL_MC_ENET) && !defined(CONFIG_SPL_BUILD)
 int xfi_dpmac[XFI8 + 1];
 int sgmii_dpmac[SGMII16 + 1];
 #endif
@@ -103,7 +103,7 @@ void serdes_init(u32 sd, u32 sd_addr, u32 sd_prctl_mask, 
u32 sd_prctl_shift,
debug("Unknown SerDes lane protocol %d\n", lane_prtcl);
else {
serdes_prtcl_map[lane_prtcl] = 1;
-#ifdef CONFIG_FSL_MC_ENET
+#if defined(CONFIG_FSL_MC_ENET) && !defined(CONFIG_SPL_BUILD)
switch (lane_prtcl) {
case QSGMII_A:
wriop_init_dpmac(sd, 5, (int)lane_prtcl);
@@ -152,7 +152,7 @@ void serdes_init(u32 sd, u32 sd_addr, u32 sd_prctl_mask, 
u32 sd_prctl_shift,
 
 void fsl_serdes_init(void)
 {
-#ifdef CONFIG_FSL_MC_ENET
+#if defined(CONFIG_FSL_MC_ENET) && !defined(CONFIG_SPL_BUILD)
int i , j;
 
for (i = XFI1, j = 1; i <= XFI8; i++, j++)
diff --git a/board/freescale/ls2080a/ls2080a.c 
b/board/freescale/ls2080a/ls2080a.c
index ace5bf6..cff468b 100644
--- a/board/freescale/ls2080a/ls2080a.c
+++ b/board/freescale/ls2080a/ls2080a.c
@@ -64,13 +64,13 @@ int board_eth_init(bd_t *bis)
error = smc9_initialize(0, CONFIG_SMC9_BASE);
 #endif
 
-#ifdef CONFIG_FSL_MC_ENET
+#if defined(CONFIG_FSL_MC_ENET) && !defined(CONFIG_SPL_BUILD)
error = cpu_eth_init(bis);
 #endif
return error;
 }
 
-#ifdef CONFIG_FSL_MC_ENET
+#if defined(CONFIG_FSL_MC_ENET) && !defined(CONFIG_SPL_BUILD)
 void fdt_fixup_board_enet(void *fdt)
 {
int offset;
@@ -128,7 +128,7 @@ int ft_board_setup(void *blob, bd_t *bd)
 
fdt_fixup_memory_banks(blob, base, size, 2);
 
-#ifdef CONFIG_FSL_MC_ENET
+#if defined(CONFIG_FSL_MC_ENET) && !defined(CONFIG_SPL_BUILD)
fdt_fixup_board_enet(blob);
 #endif
 
diff --git a/board/freescale/ls2080aqds/eth.c b/board/freescale/ls2080aqds/eth.c
index 59361e9..302ff76 100644
--- a/board/freescale/ls2080aqds/eth.c
+++ b/board/freescale/ls2080aqds/eth.c
@@ -22,7 +22,7 @@
 
 #define MC_BOOT_ENV_VAR "mcinitcmd"
 
-#ifdef CONFIG_FSL_MC_ENET
+#if defined(CONFIG_FSL_MC_ENET) && !defined(CONFIG_SPL_BUILD)
  /* - In LS2080A there are only 16 SERDES lanes, spread across 2 SERDES banks.
  *   Bank 1 -> Lanes A, B, C, D, E, F, G, H
  *   Bank 2 -> Lanes A,B, C, D, E, F, G, H
@@ -834,8 +834,8 @@ void ls2080a_handle_phy_interface_xsgmii(int i)
 int board_eth_init(bd_t *bis)
 {
int error;
+#if defined(CONFIG_FSL_MC_ENET) && !defined(C

  1   2   >