Re: [U-Boot] [PATCH v3 2/2] nand: extend nand torture
Hi Max,
On Mon, Jun 13, 2016 at 10:15 AM, Max Krummenacher wrote:
> nand torture currently works on exactly one nand block which is specified
> by giving the byteoffset to the beginning of the block.
>
> Extend this by allowing for a second parameter specifying the byte size
> to be tested.
>
> e.g.
> ==> nand torture 100
>
> NAND torture: device 0 offset 0x100 size 0x2 (block size 0x2)
> Passed: 1, failed: 0
>
> ==> nand torture 100 4
>
> NAND torture: device 0 offset 0x100 size 0x4 (block size 0x2)
> Passed: 2, failed: 0
>
> Signed-off-by: Max Krummenacher
>
>
> ---
>
> Changes in v3:
> - findings from Benoît:
> - aligned offset and endoffset to nand blocks
> - checked nand area tested against nand size
> - print actual used values after aligning
> - clarifications to doc/README.nand
>
> Changes in v2:
> - findings from Benoît:
> - change interface to be offset/size
> - change the output to include both 'size tested' and 'nand block size'
> - updated doc/README.nand accordingly
> - I did not implement the suggestion to move the code into the
> nand_torture() function. Likely one uses the extended functionality
> only during HW bringup interactively. If one would want to test
> multiple blocks from code one would also want to know the testresult
> of each individual block rather than only having a return parameter
> indicating a 'all good' or 'at least one block failed'.
>
> cmd/nand.c | 40 ++--
> doc/README.nand | 6 +-
> 2 files changed, 39 insertions(+), 7 deletions(-)
>
> diff --git a/cmd/nand.c b/cmd/nand.c
> index 583a18f..6d239a3 100644
> --- a/cmd/nand.c
> +++ b/cmd/nand.c
> @@ -647,6 +647,9 @@ static int do_nand(cmd_tbl_t *cmdtp, int flag, int argc,
> char * const argv[])
>
> #ifdef CONFIG_CMD_NAND_TORTURE
> if (strcmp(cmd, "torture") == 0) {
> + loff_t endoff;
> + unsigned int failed = 0, passed = 0;
> +
> if (argc < 3)
> goto usage;
>
> @@ -655,12 +658,36 @@ static int do_nand(cmd_tbl_t *cmdtp, int flag, int
> argc, char * const argv[])
> return 1;
> }
>
> - printf("\nNAND torture: device %d offset 0x%llx size 0x%x\n",
> - dev, off, mtd->erasesize);
> - ret = nand_torture(mtd, off);
> - printf(" %s\n", ret ? "Failed" : "Passed");
> + size = mtd->erasesize;
> + if (argc > 3)
> + if (!str2off(argv[3], &size)) {
> + puts("Size is not a valid number\n");
> + return 1;
> + }
>
> - return ret == 0 ? 0 : 1;
> + endoff = off + size;
> + if (endoff > mtd->size) {
> + puts("Arguments beyond end of NAND\n");
> + return 1;
> + }
> +
> + off = round_down(off, mtd->erasesize);
> + endoff = round_up(endoff, mtd->erasesize);
> + size = endoff - off;
> + printf("\nNAND torture: device %d offset 0x%llx size 0x%llx
> (block size 0x%x)\n",
> + dev, off, size, mtd->erasesize);
> + while (off < endoff) {
> + ret = nand_torture(mtd, off);
> + if (ret) {
> + failed++;
> + printf(" block at 0x%llx failed\n", off);
> + } else {
> + passed++;
> + }
> + off += mtd->erasesize;
> + }
> + printf(" Passed: %u, failed: %u\n", passed, failed);
> + return failed != 0;
> }
> #endif
>
> @@ -775,7 +802,8 @@ static char nand_help_text[] =
> "nand bad - show bad blocks\n"
> "nand dump[.oob] off - dump page\n"
> #ifdef CONFIG_CMD_NAND_TORTURE
> - "nand torture off - torture block at offset\n"
> + "nand torture off - torture one block at offset\n"
> + "nand torture off size - torture blocks from off to off+size\n"
> #endif
> "nand scrub [-y] off size | scrub.part partition | scrub.chip\n"
> "really clean NAND erasing bad blocks (UNSAFE)\n"
> diff --git a/doc/README.nand b/doc/README.nand
> index 96ffc48..4ecf9de 100644
> --- a/doc/README.nand
> +++ b/doc/README.nand
> @@ -307,7 +307,7 @@ Miscellaneous and testing commands:
>DANGEROUS!!! Factory set bad blocks will be lost. Use only
>to remove artificial bad blocks created with the "markbad" command.
>
> - "torture offset"
> + "torture offset [size]"
>Torture block to determine if it is still reliable.
>Enabled by the CONFIG_CMD_NAND_TORTURE configuration option.
>This command returns 0 if the block is still reliable, else 1.
> @@ -324,6 +324,
[U-Boot] [RFC PATCH V3] common: image-fdt: support dts from the second address of android image
We can support dts load from the second address of android image.
This let us to boot board (aka freescale)
Signed-off-by: Michael Trimarchi
---
Changes:
v2 -> v3: Move variable fdt_data and fdt_len in main body
v1 -> v2: reduce code and cleanup
---
common/image-android.c | 21 +
common/image-fdt.c | 13 +++--
include/image.h| 2 ++
3 files changed, 34 insertions(+), 2 deletions(-)
diff --git a/common/image-android.c b/common/image-android.c
index ee03b96..9701acd 100644
--- a/common/image-android.c
+++ b/common/image-android.c
@@ -146,6 +146,27 @@ int android_image_get_ramdisk(const struct andr_img_hdr
*hdr,
return 0;
}
+int android_image_get_dts(const struct andr_img_hdr *hdr,
+ ulong *dts_data, ulong *dts_len)
+{
+ if (!hdr->second_size) {
+ *dts_data = *dts_len = 0;
+ return -1;
+ }
+
+ printf("Dts load addr 0x%08x size %u KiB\n",
+ hdr->second_addr, DIV_ROUND_UP(hdr->second_size, 1024));
+
+ *dts_data = (unsigned long)hdr;
+ *dts_data += hdr->page_size;
+ *dts_data += ALIGN(hdr->kernel_size, hdr->page_size);
+ *dts_data += ALIGN(hdr->ramdisk_size, hdr->page_size);
+
+ *dts_len = hdr->second_size;
+ return 0;
+}
+
+
#if !defined(CONFIG_SPL_BUILD)
/**
* android_print_contents - prints out the contents of the Android format image
diff --git a/common/image-fdt.c b/common/image-fdt.c
index 6cac7db..fb4cceb 100644
--- a/common/image-fdt.c
+++ b/common/image-fdt.c
@@ -237,6 +237,7 @@ int boot_get_fdt(int flag, int argc, char * const argv[],
uint8_t arch,
ulong default_addr;
int fdt_noffset;
#endif
+ ulong fdt_data, fdt_len;
const char *select = NULL;
int ok_no_fdt = 0;
@@ -345,6 +346,12 @@ int boot_get_fdt(int flag, int argc, char * const argv[],
uint8_t arch,
fdt_addr = load;
break;
#endif
+#if defined(CONFIG_ANDROID_BOOT_IMAGE)
+ case IMAGE_FORMAT_ANDROID:
+ android_image_get_dts(buf, &fdt_data, &fdt_len);
+ goto boot_fdt;
+ break;
+#endif
case IMAGE_FORMAT_FIT:
/*
* This case will catch both: new uImage format
@@ -389,8 +396,6 @@ int boot_get_fdt(int flag, int argc, char * const argv[],
uint8_t arch,
} else if (images->legacy_hdr_valid &&
image_check_type(&images->legacy_hdr_os_copy,
IH_TYPE_MULTI)) {
- ulong fdt_data, fdt_len;
-
/*
* Now check if we have a legacy multi-component image,
* get second entry data start address and len.
@@ -400,6 +405,10 @@ int boot_get_fdt(int flag, int argc, char * const argv[],
uint8_t arch,
image_multi_getimg(images->legacy_hdr_os, 2, &fdt_data,
&fdt_len);
+
+#if defined(CONFIG_ANDROID_BOOT_IMAGE)
+boot_fdt:
+#endif
if (fdt_len) {
fdt_blob = (char *)fdt_data;
printf(" Booting using the fdt at 0x%p\n", fdt_blob);
diff --git a/include/image.h b/include/image.h
index 61b5d3b..f475481 100644
--- a/include/image.h
+++ b/include/image.h
@@ -1147,6 +1147,8 @@ struct andr_img_hdr;
int android_image_check_header(const struct andr_img_hdr *hdr);
int android_image_get_kernel(const struct andr_img_hdr *hdr, int verify,
ulong *os_data, ulong *os_len);
+int android_image_get_dts(const struct andr_img_hdr *hdr,
+ ulong *dts_data, ulong *dts_len);
int android_image_get_ramdisk(const struct andr_img_hdr *hdr,
ulong *rd_data, ulong *rd_len);
ulong android_image_get_end(const struct andr_img_hdr *hdr);
--
2.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: smsc95xx: Use correct get_unaligned functions
On Mon, Jun 13, 2016 at 8:01 PM, Chris Packham wrote:
> Hi Mark,
>
> On Mon, Jun 13, 2016 at 5:00 PM, Mark Tomlinson
> wrote:
>> The __get_unaligned_le* functions may not be declared on all platforms.
>> Instead, get_unaligned_le* should be used. On many platforms both of
>> these are the same function.
>>
>> Change-Id: If28222615e85a6f34f3fde42eb21c6f56a2cb988
>
> We shouldn't let these leak out of $work. This doesn't really mean
> anything to anyone without access to our internal review system.
>
>> Reviewed-by: Chris Packham
>
> For what it's worth - this is me I usually post with my gmail account
> because it's better for managing high volume mailing lists.
Also your signed-off line is missing.
>
>> ---
>> drivers/usb/eth/smsc95xx.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/usb/eth/smsc95xx.c b/drivers/usb/eth/smsc95xx.c
>> index 08eaed5..7d9abfd 100644
>> --- a/drivers/usb/eth/smsc95xx.c
>> +++ b/drivers/usb/eth/smsc95xx.c
>> @@ -391,8 +391,8 @@ static int smsc95xx_write_hwaddr_common(struct
>> usb_device *udev,
>> struct smsc95xx_private *priv,
>> unsigned char *enetaddr)
>> {
>> - u32 addr_lo = __get_unaligned_le32(&enetaddr[0]);
>> - u32 addr_hi = __get_unaligned_le16(&enetaddr[4]);
>> + u32 addr_lo = get_unaligned_le32(&enetaddr[0]);
>> + u32 addr_hi = get_unaligned_le16(&enetaddr[4]);
>> int ret;
>>
>> /* set hardware address */
>> --
>> 2.8.4
>>
>> ___
>> U-Boot mailing list
>> U-Boot@lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: Allow setenv to set net global variables
On 06/14/2016 06:34 AM, Joe Hershberger wrote:
> Hi Chris,
>
> On Sun, Jun 12, 2016 at 3:58 PM, Chris Packham
> wrote:
>> Hi Joe,
>>
>> On 06/11/2016 03:56 AM, Joe Hershberger wrote:
>>> On Thu, Jun 9, 2016 at 8:40 PM, Matthew Bright
>>> wrote:
The patch fd3056337e6fcc introduces env callbacks to several of the net
related env variables. These callbacks are responsible for updating the
corresponding global variables internal to the net source code. However
this behavior will be skipped if the source of the callbacks originated
from setenv. This is based on the assumption that all current instances
of setenv are invoked using the same global variables that the callback
will eventually write to; therefore there is no need set them to the
same value.
As setenv is a public interface this assumption may not always hold. In
our usage case we implement a user facing menu system for configuration
of networking parameters. This ultimately lead to calling setenv rather
than through the traditional interactive command line parser do_env_set.
Therefore, in our usage case, setenv can be called for an "interactive"
case. Consequently, the early return for non-interactive invocation are
now removed and any call to setenv will update the corresponding states
internal to the net source code as expected.
Signed-off-by: Matthew Bright
Reviewed-by: Hamish Martin
Reviewed-by: Chris Packham
---
net/net.c | 24
1 file changed, 24 deletions(-)
diff --git a/net/net.c b/net/net.c
index 1e1d23d..726b0f0 100644
--- a/net/net.c
+++ b/net/net.c
@@ -209,9 +209,6 @@ int __maybe_unused net_busy_flag;
static int on_bootfile(const char *name, const char *value, enum env_op
op,
int flags)
{
- if (flags & H_PROGRAMMATIC)
- return 0;
-
>>>
>>> Why can't you just change your menu to call the API that is
>>> interactive instead of setenv?
>>
>> Which API are you referring to? _do_env_set() is static so the only
>> public api would be run_command("setenv ipaddr ...") or have I missed
>> something?
>
> Yes, that's what I was referring to.
>
> Another option would be to add an explicit function that provides this
> directly. Maybe even make a generic version that accepts a flags
> parameter, then implement the existing function as a call to this new
> function which passes in a "programmatic" flag.
>
That's what I was thinking. Because setenv is one of the exported
functions for standalone applications I was wondering if instead of
setenv() passing H_PROGRAMMATIC we add prog_setenv() (naming things is
hard) for the net use-case since that is the only thing that currently
checks H_PROGRAMMATIC.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] dm: gpio: MPC85XX GPIO platform data support
Define a platform data structure for the MPC85XX GPIO driver to allow
use of the driver without device tree. Users should define the GPIO
blocks for their platform like this:
struct mpc85xx_gpio_plat gpio_blocks[] = {
{
.addr = 0x13,
.ngpios = 32,
},
{
.addr = 0x131000,
.ngpios = 32,
},
};
U_BOOT_DEVICES(my_platform_gpios) = {
{ "gpio_mpc85xx", &gpio_blocks[0] },
{ "gpio_mpc85xx", &gpio_blocks[1] },
};
This is intended to build upon the recent submission of the base
MPC85XX driver from Mario Six. We need to use that new driver
without dts support and this patch gives us that flexibility.
This has been tested on a Freescale T2080 CPU, although only the first
GPIO block.
Signed-off-by: Hamish Martin
Reviewed-by: Mario Six
Tested-by: Mario Six
---
Changes for v2:
- Fix compile errors noted by Mario Six
- Added Mario's review and test tags
---
arch/powerpc/include/asm/arch-mpc85xx/gpio.h | 6 +
drivers/gpio/mpc85xx_gpio.c | 37 ++--
2 files changed, 36 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/include/asm/arch-mpc85xx/gpio.h
b/arch/powerpc/include/asm/arch-mpc85xx/gpio.h
index 41b6677bba38..76faa22c8b43 100644
--- a/arch/powerpc/include/asm/arch-mpc85xx/gpio.h
+++ b/arch/powerpc/include/asm/arch-mpc85xx/gpio.h
@@ -18,4 +18,10 @@
#include
#endif
+struct mpc85xx_gpio_plat {
+ ulong addr;
+ unsigned long size;
+ uint ngpios;
+};
+
#endif
diff --git a/drivers/gpio/mpc85xx_gpio.c b/drivers/gpio/mpc85xx_gpio.c
index 04773e2b31c3..3754a8215c36 100644
--- a/drivers/gpio/mpc85xx_gpio.c
+++ b/drivers/gpio/mpc85xx_gpio.c
@@ -163,23 +163,41 @@ static int mpc85xx_gpio_get_function(struct udevice *dev,
unsigned gpio)
return dir ? GPIOF_OUTPUT : GPIOF_INPUT;
}
+#if CONFIG_IS_ENABLED(OF_CONTROL)
static int mpc85xx_gpio_ofdata_to_platdata(struct udevice *dev) {
- struct mpc85xx_gpio_data *data = dev_get_priv(dev);
+ struct mpc85xx_gpio_plat *plat = dev_get_platdata(dev);
fdt_addr_t addr;
fdt_size_t size;
addr = fdtdec_get_addr_size_auto_noparent(gd->fdt_blob, dev->of_offset,
"reg", 0, &size);
- data->addr = addr;
- data->base = map_sysmem(CONFIG_SYS_IMMR + addr, size);
+ plat->addr = addr;
+ plat->size = size;
+ plat->ngpios = fdtdec_get_int(gd->fdt_blob, dev->of_offset,
+ "ngpios", 32);
- if (!data->base)
+ return 0;
+}
+#endif
+
+static int mpc85xx_gpio_platdata_to_priv(struct udevice *dev)
+{
+ struct mpc85xx_gpio_data *priv = dev_get_priv(dev);
+ struct mpc85xx_gpio_plat *plat = dev_get_platdata(dev);
+ unsigned long size = plat->size;
+
+ if (size == 0)
+ size = 0x100;
+
+ priv->addr = plat->addr;
+ priv->base = map_sysmem(CONFIG_SYS_IMMR + plat->addr, size);
+
+ if (!priv->base)
return -ENOMEM;
- data->gpio_count = fdtdec_get_int(gd->fdt_blob, dev->of_offset,
- "ngpios", 32);
- data->dat_shadow = 0;
+ priv->gpio_count = plat->ngpios;
+ priv->dat_shadow = 0;
return 0;
}
@@ -190,6 +208,8 @@ static int mpc85xx_gpio_probe(struct udevice *dev)
struct mpc85xx_gpio_data *data = dev_get_priv(dev);
char name[32], *str;
+ mpc85xx_gpio_platdata_to_priv(dev);
+
snprintf(name, sizeof(name), "MPC@%lx_", data->addr);
str = strdup(name);
@@ -221,8 +241,11 @@ U_BOOT_DRIVER(gpio_mpc85xx) = {
.name = "gpio_mpc85xx",
.id = UCLASS_GPIO,
.ops= &gpio_mpc85xx_ops,
+#if CONFIG_IS_ENABLED(OF_CONTROL)
.ofdata_to_platdata = mpc85xx_gpio_ofdata_to_platdata,
+ .platdata_auto_alloc_size = sizeof(struct mpc85xx_gpio_plat),
.of_match = mpc85xx_gpio_ids,
+#endif
.probe = mpc85xx_gpio_probe,
.priv_auto_alloc_size = sizeof(struct mpc85xx_gpio_data),
};
--
2.8.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: Allow setenv to set net global variables
Hi Chris,
On Mon, Jun 13, 2016 at 4:13 PM, Chris Packham
wrote:
> On 06/14/2016 06:34 AM, Joe Hershberger wrote:
>> Hi Chris,
>>
>> On Sun, Jun 12, 2016 at 3:58 PM, Chris Packham
>> wrote:
>>> Hi Joe,
>>>
>>> On 06/11/2016 03:56 AM, Joe Hershberger wrote:
On Thu, Jun 9, 2016 at 8:40 PM, Matthew Bright
wrote:
> The patch fd3056337e6fcc introduces env callbacks to several of the net
> related env variables. These callbacks are responsible for updating the
> corresponding global variables internal to the net source code. However
> this behavior will be skipped if the source of the callbacks originated
> from setenv. This is based on the assumption that all current instances
> of setenv are invoked using the same global variables that the callback
> will eventually write to; therefore there is no need set them to the
> same value.
>
> As setenv is a public interface this assumption may not always hold. In
> our usage case we implement a user facing menu system for configuration
> of networking parameters. This ultimately lead to calling setenv rather
> than through the traditional interactive command line parser do_env_set.
> Therefore, in our usage case, setenv can be called for an "interactive"
> case. Consequently, the early return for non-interactive invocation are
> now removed and any call to setenv will update the corresponding states
> internal to the net source code as expected.
>
> Signed-off-by: Matthew Bright
> Reviewed-by: Hamish Martin
> Reviewed-by: Chris Packham
> ---
>net/net.c | 24
>1 file changed, 24 deletions(-)
>
> diff --git a/net/net.c b/net/net.c
> index 1e1d23d..726b0f0 100644
> --- a/net/net.c
> +++ b/net/net.c
> @@ -209,9 +209,6 @@ int __maybe_unused net_busy_flag;
>static int on_bootfile(const char *name, const char *value, enum
> env_op op,
> int flags)
>{
> - if (flags & H_PROGRAMMATIC)
> - return 0;
> -
Why can't you just change your menu to call the API that is
interactive instead of setenv?
>>>
>>> Which API are you referring to? _do_env_set() is static so the only
>>> public api would be run_command("setenv ipaddr ...") or have I missed
>>> something?
>>
>> Yes, that's what I was referring to.
>>
>> Another option would be to add an explicit function that provides this
>> directly. Maybe even make a generic version that accepts a flags
>> parameter, then implement the existing function as a call to this new
>> function which passes in a "programmatic" flag.
>>
>
> That's what I was thinking. Because setenv is one of the exported
> functions for standalone applications I was wondering if instead of
> setenv() passing H_PROGRAMMATIC we add prog_setenv() (naming things is
> hard) for the net use-case since that is the only thing that currently
> checks H_PROGRAMMATIC.
That might be OK. The only reservation I have about it is that the
setenv() function is generally a programmatic operation since only C
code can get to it. Only in the case where you are implementing some
more complex interaction (like your menu) is it not actually
programmatic. I just worry about it being misleading in the future.
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: Allow setenv to set net global variables
On 06/14/2016 10:19 AM, Joe Hershberger wrote:
> Hi Chris,
>
> On Mon, Jun 13, 2016 at 4:13 PM, Chris Packham
> wrote:
>> On 06/14/2016 06:34 AM, Joe Hershberger wrote:
>>> Hi Chris,
>>>
>>> On Sun, Jun 12, 2016 at 3:58 PM, Chris Packham
>>> wrote:
Hi Joe,
On 06/11/2016 03:56 AM, Joe Hershberger wrote:
> On Thu, Jun 9, 2016 at 8:40 PM, Matthew Bright
> wrote:
>> The patch fd3056337e6fcc introduces env callbacks to several of the net
>> related env variables. These callbacks are responsible for updating the
>> corresponding global variables internal to the net source code. However
>> this behavior will be skipped if the source of the callbacks originated
>> from setenv. This is based on the assumption that all current instances
>> of setenv are invoked using the same global variables that the callback
>> will eventually write to; therefore there is no need set them to the
>> same value.
>>
>> As setenv is a public interface this assumption may not always hold. In
>> our usage case we implement a user facing menu system for configuration
>> of networking parameters. This ultimately lead to calling setenv rather
>> than through the traditional interactive command line parser do_env_set.
>> Therefore, in our usage case, setenv can be called for an "interactive"
>> case. Consequently, the early return for non-interactive invocation are
>> now removed and any call to setenv will update the corresponding states
>> internal to the net source code as expected.
>>
>> Signed-off-by: Matthew Bright
>> Reviewed-by: Hamish Martin
>> Reviewed-by: Chris Packham
>> ---
>> net/net.c | 24
>> 1 file changed, 24 deletions(-)
>>
>> diff --git a/net/net.c b/net/net.c
>> index 1e1d23d..726b0f0 100644
>> --- a/net/net.c
>> +++ b/net/net.c
>> @@ -209,9 +209,6 @@ int __maybe_unused net_busy_flag;
>> static int on_bootfile(const char *name, const char *value, enum
>> env_op op,
>>int flags)
>> {
>> - if (flags & H_PROGRAMMATIC)
>> - return 0;
>> -
>
> Why can't you just change your menu to call the API that is
> interactive instead of setenv?
Which API are you referring to? _do_env_set() is static so the only
public api would be run_command("setenv ipaddr ...") or have I missed
something?
>>>
>>> Yes, that's what I was referring to.
>>>
>>> Another option would be to add an explicit function that provides this
>>> directly. Maybe even make a generic version that accepts a flags
>>> parameter, then implement the existing function as a call to this new
>>> function which passes in a "programmatic" flag.
>>>
>>
>> That's what I was thinking. Because setenv is one of the exported
>> functions for standalone applications I was wondering if instead of
>> setenv() passing H_PROGRAMMATIC we add prog_setenv() (naming things is
>> hard) for the net use-case since that is the only thing that currently
>> checks H_PROGRAMMATIC.
>
> That might be OK. The only reservation I have about it is that the
> setenv() function is generally a programmatic operation since only C
> code can get to it. Only in the case where you are implementing some
> more complex interaction (like your menu) is it not actually
> programmatic. I just worry about it being misleading in the future.
>
Agreed. My initial reaction was that our menu should be treated like
H_INTERACTIVE but there wasn't an easy way to achieve this.
Do you have any feel for the direction of H_PROGRAMMATIC is going? Are
we going to see more environment variables in other parts of the code
that will get similar treatment.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 1/8] ARMv7: PSCI: add PSCI v1.0 functions skeleton
From: Hongbo Zhang This patch adds all the PSCI v1.0 functions in to the common framework, with all the functions returning "not implemented" by default, as a common framework all the dummy functions are added here, it is up to every platform developer to decide which version of PSCI and which functions to implement. Signed-off-by: Hongbo Zhang Signed-off-by: Wang Dongsheng --- arch/arm/cpu/armv7/psci.S| 78 arch/arm/cpu/armv7/virt-dt.c | 10 +- arch/arm/include/asm/psci.h | 16 + 3 files changed, 103 insertions(+), 1 deletion(-) diff --git a/arch/arm/cpu/armv7/psci.S b/arch/arm/cpu/armv7/psci.S index 87c0c0b..8e25300 100644 --- a/arch/arm/cpu/armv7/psci.S +++ b/arch/arm/cpu/armv7/psci.S @@ -46,20 +46,62 @@ ENTRY(default_psci_vector) ENDPROC(default_psci_vector) .weak default_psci_vector +ENTRY(psci_version) ENTRY(psci_cpu_suspend) ENTRY(psci_cpu_off) ENTRY(psci_cpu_on) +ENTRY(psci_affinity_info) ENTRY(psci_migrate) +ENTRY(psci_migrate_info_type) +ENTRY(psci_migrate_info_up_cpu) +ENTRY(psci_system_off) +ENTRY(psci_system_reset) +ENTRY(psci_features) +ENTRY(psci_cpu_freeze) +ENTRY(psci_cpu_default_suspend) +ENTRY(psci_node_hw_state) +ENTRY(psci_system_suspend) +ENTRY(psci_set_suspend_mode) +ENTRY(psi_stat_residency) +ENTRY(psci_stat_count) mov r0, #ARM_PSCI_RET_NI@ Return -1 (Not Implemented) mov pc, lr +ENDPROC(psci_stat_count) +ENDPROC(psi_stat_residency) +ENDPROC(psci_set_suspend_mode) +ENDPROC(psci_system_suspend) +ENDPROC(psci_node_hw_state) +ENDPROC(psci_cpu_default_suspend) +ENDPROC(psci_cpu_freeze) +ENDPROC(psci_features) +ENDPROC(psci_system_reset) +ENDPROC(psci_system_off) +ENDPROC(psci_migrate_info_up_cpu) +ENDPROC(psci_migrate_info_type) ENDPROC(psci_migrate) +ENDPROC(psci_affinity_info) ENDPROC(psci_cpu_on) ENDPROC(psci_cpu_off) ENDPROC(psci_cpu_suspend) +ENDPROC(psci_version) +.weak psci_version .weak psci_cpu_suspend .weak psci_cpu_off .weak psci_cpu_on +.weak psci_affinity_info .weak psci_migrate +.weak psci_migrate_info_type +.weak psci_migrate_info_up_cpu +.weak psci_system_off +.weak psci_system_reset +.weak psci_features +.weak psci_cpu_freeze +.weak psci_cpu_default_suspend +.weak psci_node_hw_state +.weak psci_system_suspend +.weak psci_set_suspend_mode +.weak psi_stat_residency +.weak psci_stat_count _psci_table: .word ARM_PSCI_FN_CPU_SUSPEND @@ -70,6 +112,42 @@ _psci_table: .word psci_cpu_on .word ARM_PSCI_FN_MIGRATE .word psci_migrate + .word ARM_PSCI_0_2_FN_PSCI_VERSION + .word psci_version + .word ARM_PSCI_0_2_FN_CPU_SUSPEND + .word psci_cpu_suspend + .word ARM_PSCI_0_2_FN_CPU_OFF + .word psci_cpu_off + .word ARM_PSCI_0_2_FN_CPU_ON + .word psci_cpu_on + .word ARM_PSCI_0_2_FN_AFFINITY_INFO + .word psci_affinity_info + .word ARM_PSCI_0_2_FN_MIGRATE + .word psci_migrate + .word ARM_PSCI_0_2_FN_MIGRATE_INFO_TYPE + .word psci_migrate_info_type + .word ARM_PSCI_0_2_FN_MIGRATE_INFO_UP_CPU + .word psci_migrate_info_up_cpu + .word ARM_PSCI_0_2_FN_SYSTEM_OFF + .word psci_system_off + .word ARM_PSCI_0_2_FN_SYSTEM_RESET + .word psci_system_reset + .word ARM_PSCI_1_0_FN_PSCI_FEATURES + .word psci_features + .word ARM_PSCI_1_0_FN_CPU_FREEZE + .word psci_cpu_freeze + .word ARM_PSCI_1_0_FN_CPU_DEFAULT_SUSPEND + .word psci_cpu_default_suspend + .word ARM_PSCI_1_0_FN_NODE_HW_STATE + .word psci_node_hw_state + .word ARM_PSCI_1_0_FN_SYSTEM_SUSPEND + .word psci_system_suspend + .word ARM_PSCI_1_0_FN_SET_SUSPEND_MODE + .word psci_set_suspend_mode + .word ARM_PSCI_1_0_FN_STAT_RESIDENCY + .word psi_stat_residency + .word ARM_PSCI_1_0_FN_STAT_COUNT + .word psci_stat_count .word 0 .word 0 diff --git a/arch/arm/cpu/armv7/virt-dt.c b/arch/arm/cpu/armv7/virt-dt.c index 32c368f..5e31891 100644 --- a/arch/arm/cpu/armv7/virt-dt.c +++ b/arch/arm/cpu/armv7/virt-dt.c @@ -67,7 +67,15 @@ static int fdt_psci(void *fdt) return nodeoff; } - tmp = fdt_setprop_string(fdt, nodeoff, "compatible", "arm,psci"); +#ifdef CONFIG_ARMV7_PSCI_1_0 + tmp = fdt_setprop_string(fdt, nodeoff, "compatible", "arm,psci-1.0"); + if (tmp) + return tmp; + tmp = fdt_appendprop_string(fdt, nodeoff, "compatible", "arm,psci-0.2"); + if (tmp) + return tmp; +#endif + tmp = fdt_appendprop_string(fdt, nodeoff, "compatible", "arm,psci"); if (tmp) return tmp; tmp = fdt_setprop_string(fdt, nodeoff, "method", "smc"); diff --git a/arch/arm/include/asm/psci.h b/arch/arm/include/asm/psci.h index 3704f07..2367ec0 100644 --- a/arch/arm/include/asm/psci.h +++ b/arch/arm/includ
[U-Boot] [PATCH v5 5/8] ARMv7: PSCI: ls102xa: check target CPU ID before further operations
From: Hongbo Zhang
The input parameter CPU ID needs to be validated before furher oprations such
as CPU_ON, this patch introduces the function to do this.
Signed-off-by: Wang Dongsheng
Signed-off-by: Hongbo Zhang
---
arch/arm/cpu/armv7/ls102xa/psci.S | 34 +-
1 file changed, 33 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/ls102xa/psci.S
b/arch/arm/cpu/armv7/ls102xa/psci.S
index 548c507..a4482e4 100644
--- a/arch/arm/cpu/armv7/ls102xa/psci.S
+++ b/arch/arm/cpu/armv7/ls102xa/psci.S
@@ -25,6 +25,34 @@
#defineONE_MS (GENERIC_TIMER_CLK / 1000)
#defineRESET_WAIT (30 * ONE_MS)
+.globl psci_check_target_cpu_id
+psci_check_target_cpu_id:
+ @ Get the real CPU number
+ and r0, r1, #0xff
+
+ @ Verify bit[31:24], bits must be zero.
+ tst r1, #0xff00
+ bne out_psci_invalid_target_cpu_id
+
+ @ Verify Affinity level 2: Cluster, only one cluster in LS1021xa SoC.
+ tst r1, #0xff
+ bne out_psci_invalid_target_cpu_id
+
+ @ Verify Affinity level 1: Processors, should be in 0xf00 format.
+ lsr r1, r1, #8
+ teq r1, #0xf
+ bne out_psci_invalid_target_cpu_id
+
+ @ Verify Affinity level 0: CPU, only 0, 1 are valid values.
+ cmp r0, #2
+ bge out_psci_invalid_target_cpu_id
+
+ bx lr
+
+out_psci_invalid_target_cpu_id:
+ mov r0, #ARM_PSCI_RET_INVAL
+ bx lr
+
@ r1 = target CPU
@ r2 = target PC
.globl psci_cpu_on
@@ -33,7 +61,10 @@ psci_cpu_on:
@ Clear and Get the correct CPU number
@ r1 = 0xf01
- and r1, r1, #0xff
+ bl psci_check_target_cpu_id
+ cmp r0, #ARM_PSCI_RET_INVAL
+ beq out_psci_cpu_on
+ mov r1, r0
bl psci_cpu_on_common
@@ -98,6 +129,7 @@ holdoff_release:
@ Return
mov r0, #ARM_PSCI_RET_SUCCESS
+out_psci_cpu_on:
pop {lr}
bx lr
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 6/8] ARMv7: PSCI: ls102xa: check ALREADY_ON or ON_PENDING for CPU_ON
From: Hongbo Zhang For the robustness of codes, while powering on a CPU, it is better to check if the target CPU is already on or in the process of power on, if yes the power on routine shouldn't be executed further and should return with the corresponding status immediately. Signed-off-by: Hongbo Zhang --- arch/arm/cpu/armv7/ls102xa/psci.S | 29 + arch/arm/include/asm/psci.h | 5 + 2 files changed, 34 insertions(+) diff --git a/arch/arm/cpu/armv7/ls102xa/psci.S b/arch/arm/cpu/armv7/ls102xa/psci.S index a4482e4..0188ade 100644 --- a/arch/arm/cpu/armv7/ls102xa/psci.S +++ b/arch/arm/cpu/armv7/ls102xa/psci.S @@ -66,6 +66,22 @@ psci_cpu_on: beq out_psci_cpu_on mov r1, r0 + bl psci_get_cpu_stack_top + sub r0, r0, #PSCI_CPU_STATUS_OFFSET + ldr r5, [r0] + + cmp r5, #PSCI_CPU_STATUS_ON + moveq r0, #ARM_PSCI_RET_ALREADY_ON + beq out_psci_cpu_on + + cmp r5, #PSCI_CPU_STATUS_ON_PENDING + moveq r0, #ARM_PSCI_RET_ON_PENDING + beq out_psci_cpu_on + + mov r5, #PSCI_CPU_STATUS_ON_PENDING + str r5, [r0] + dsb + bl psci_cpu_on_common @ Get DCFG base address @@ -123,6 +139,12 @@ holdoff_release: rev r6, r6 str r6, [r4, #DCFG_CCSR_SCRATCHRW1] + mov r0, r1 + bl psci_get_cpu_stack_top + sub r0, r0, #PSCI_CPU_STATUS_OFFSET + mov r5, #PSCI_CPU_STATUS_ON + str r5, [r0] + isb dsb @@ -137,6 +159,13 @@ out_psci_cpu_on: psci_cpu_off: bl psci_cpu_off_common + bl psci_get_cpu_id + bl psci_get_cpu_stack_top + sub r0, r0, #PSCI_CPU_STATUS_OFFSET + mov r5, #PSCI_CPU_STATUS_OFF + str r5, [r0] + dsb + 1: wfi b 1b diff --git a/arch/arm/include/asm/psci.h b/arch/arm/include/asm/psci.h index bedcd30..89a1ba5 100644 --- a/arch/arm/include/asm/psci.h +++ b/arch/arm/include/asm/psci.h @@ -67,6 +67,11 @@ #define PSCI_PERCPU_STACK_SIZE 0x400 #define PSCI_TARGET_PC_OFFSET (PSCI_PERCPU_STACK_SIZE - 4) #define PSCI_CONTEXT_ID_OFFSET (PSCI_PERCPU_STACK_SIZE - 8) +#define PSCI_CPU_STATUS_OFFSET (PSCI_PERCPU_STACK_SIZE - 12) + +#define PSCI_CPU_STATUS_OFF0 +#define PSCI_CPU_STATUS_ON 1 +#define PSCI_CPU_STATUS_ON_PENDING 2 #ifndef __ASSEMBLY__ int psci_update_dt(void *fdt); -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 7/8] ARMv7: PSCI: ls102xa: add more PSCI v1.0 functions implemention
From: Hongbo Zhang
This patch implements PSCI functions for ls102xa SoC following PSCI v1.0,
they are as the list:
psci_version,
psci_features,
psci_cpu_suspend,
psci_affinity_info,
psci_system_reset,
psci_system_off.
Tested on LS1021aQDS, LS1021aTWR.
Signed-off-by: Wang Dongsheng
Signed-off-by: Hongbo Zhang
---
arch/arm/cpu/armv7/ls102xa/psci.S | 105 +++--
arch/arm/include/asm/arch-ls102xa/config.h | 1 +
arch/arm/include/asm/psci.h| 5 ++
board/freescale/ls1021aqds/Makefile| 1 +
board/freescale/ls1021aqds/psci.S | 36 ++
board/freescale/ls1021atwr/Makefile| 1 +
board/freescale/ls1021atwr/psci.S | 28
include/configs/ls1021aqds.h | 3 +
include/configs/ls1021atwr.h | 1 +
9 files changed, 177 insertions(+), 4 deletions(-)
create mode 100644 board/freescale/ls1021aqds/psci.S
create mode 100644 board/freescale/ls1021atwr/psci.S
diff --git a/arch/arm/cpu/armv7/ls102xa/psci.S
b/arch/arm/cpu/armv7/ls102xa/psci.S
index 0188ade..084f914 100644
--- a/arch/arm/cpu/armv7/ls102xa/psci.S
+++ b/arch/arm/cpu/armv7/ls102xa/psci.S
@@ -12,19 +12,72 @@
#include
#include
+#define RCPM_TWAITSR 0x04C
+
#define SCFG_CORE0_SFT_RST 0x130
#define SCFG_CORESRENCR 0x204
-#define DCFG_CCSR_BRR 0x0E4
-#define DCFG_CCSR_SCRATCHRW10x200
+#define DCFG_CCSR_RSTCR0x0B0
+#define DCFG_CCSR_RSTCR_RESET_REQ 0x2
+#define DCFG_CCSR_BRR 0x0E4
+#define DCFG_CCSR_SCRATCHRW1 0x200
+
+#define PSCI_FN_PSCI_VERSION_FEATURE_MASK 0x0
+#define PSCI_FN_CPU_SUSPEND_FEATURE_MASK 0x0
+#define PSCI_FN_CPU_OFF_FEATURE_MASK 0x0
+#define PSCI_FN_CPU_ON_FEATURE_MASK0x0
+#define PSCI_FN_AFFINITY_INFO_FEATURE_MASK 0x0
+#define PSCI_FN_SYSTEM_OFF_FEATURE_MASK0x0
+#define PSCI_FN_SYSTEM_RESET_FEATURE_MASK 0x0
.pushsection ._secure.text, "ax"
.arch_extension sec
+ .align 5
+
#defineONE_MS (GENERIC_TIMER_CLK / 1000)
#defineRESET_WAIT (30 * ONE_MS)
+.globl psci_version
+psci_version:
+ movwr0, #0
+ movtr0, #1
+
+ bx lr
+
+_ls102x_psci_supported_table:
+ .word ARM_PSCI_0_2_FN_PSCI_VERSION
+ .word PSCI_FN_PSCI_VERSION_FEATURE_MASK
+ .word ARM_PSCI_0_2_FN_CPU_SUSPEND
+ .word PSCI_FN_CPU_SUSPEND_FEATURE_MASK
+ .word ARM_PSCI_0_2_FN_CPU_OFF
+ .word PSCI_FN_CPU_OFF_FEATURE_MASK
+ .word ARM_PSCI_0_2_FN_CPU_ON
+ .word PSCI_FN_CPU_ON_FEATURE_MASK
+ .word ARM_PSCI_0_2_FN_AFFINITY_INFO
+ .word PSCI_FN_AFFINITY_INFO_FEATURE_MASK
+ .word ARM_PSCI_0_2_FN_SYSTEM_OFF
+ .word PSCI_FN_SYSTEM_OFF_FEATURE_MASK
+ .word ARM_PSCI_0_2_FN_SYSTEM_RESET
+ .word PSCI_FN_SYSTEM_RESET_FEATURE_MASK
+ .word 0
+ .word ARM_PSCI_RET_NI
+
+.globl psci_features
+psci_features:
+ adr r2, _ls102x_psci_supported_table
+1: ldr r3, [r2]
+ cmp r3, #0
+ beq out_psci_features
+ cmp r1, r3
+ addne r2, r2, #8
+ bne 1b
+
+out_psci_features:
+ ldr r0, [r2, #4]
+ bx lr
+
.globl psci_check_target_cpu_id
psci_check_target_cpu_id:
@ Get the real CPU number
@@ -169,6 +222,52 @@ psci_cpu_off:
1: wfi
b 1b
+.globl psci_affinity_info
+psci_affinity_info:
+ push{lr}
+
+ mov r0, #ARM_PSCI_RET_INVAL
+
+ @ Verify Affinity level
+ cmp r2, #0
+ bne out_affinity_info
+
+ bl psci_check_target_cpu_id
+ cmp r0, #ARM_PSCI_RET_INVAL
+ beq out_affinity_info
+ mov r1, r0
+
+ @ Get RCPM base address
+ movwr4, #(CONFIG_SYS_FSL_RCPM_ADDR & 0x)
+ movtr4, #(CONFIG_SYS_FSL_RCPM_ADDR >> 16)
+
+ mov r0, #PSCI_AFFINITY_LEVEL_ON
+
+ @ Detect target CPU state
+ ldr r2, [r4, #RCPM_TWAITSR]
+ rev r2, r2
+ lsr r2, r2, r1
+ andsr2, r2, #1
+ beq out_affinity_info
+
+ mov r0, #PSCI_AFFINITY_LEVEL_OFF
+
+out_affinity_info:
+ pop {pc}
+
+.globl psci_system_reset
+psci_system_reset:
+ @ Get DCFG base address
+ movwr1, #(CONFIG_SYS_FSL_GUTS_ADDR & 0x)
+ movtr1, #(CONFIG_SYS_FSL_GUTS_ADDR >> 16)
+
+ mov r2, #DCFG_CCSR_RSTCR_RESET_REQ
+ rev r2, r2
+ str r2, [r1, #DCFG_CCSR_RSTCR]
+
+1: wfi
+ b 1b
+
.globl psci_arch_init
psci_arch_init:
mov r6, lr
@@ -179,6 +278,4 @@ psci_arch_init:
bx r6
- .globl psci_text_end
-psci_text_end:
.popsection
diff --git a/arch/arm/include/asm/arch-ls102xa/config.h
b/arch/arm/include/asm/arch-ls102xa/config.h
index 04abec4..7a0e4bf 100644
--- a/arch
[U-Boot] [PATCH v5 8/8] ARMv7: PSCI: ls102xa: move secure text section into OCRAM
From: Hongbo Zhang LS1021 offers two secure OCRAM blocks for trustzone. This patch moves all the secure text sections into the OCRAM. Signed-off-by: Wang Dongsheng Signed-off-by: Hongbo Zhang --- arch/arm/include/asm/arch-ls102xa/config.h | 2 +- include/configs/ls1021atwr.h | 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/arm/include/asm/arch-ls102xa/config.h b/arch/arm/include/asm/arch-ls102xa/config.h index 7a0e4bf..4729044 100644 --- a/arch/arm/include/asm/arch-ls102xa/config.h +++ b/arch/arm/include/asm/arch-ls102xa/config.h @@ -10,7 +10,7 @@ #define CONFIG_SYS_CACHELINE_SIZE 64 #define OCRAM_BASE_ADDR0x1000 -#define OCRAM_SIZE 0x0002 +#define OCRAM_SIZE 0x0001 #define OCRAM_BASE_S_ADDR 0x1001 #define OCRAM_S_SIZE 0x0001 diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h index 9d0c4fe..e6fbd77 100644 --- a/include/configs/ls1021atwr.h +++ b/include/configs/ls1021atwr.h @@ -12,6 +12,8 @@ #define CONFIG_ARMV7_PSCI #define CONFIG_ARMV7_PSCI_1_0 +#define CONFIG_ARMV7_SECURE_BASE OCRAM_BASE_S_ADDR + #define CONFIG_SYS_FSL_CLK #define CONFIG_DISPLAY_CPUINFO -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 7/9] libfdt: Add overlay application function
On Fri, Jun 10, 2016 at 05:28:11PM +0300, Pantelis Antoniou wrote:
> Hi Maxime,
>
> > On May 27, 2016, at 12:13 , Maxime Ripard
> > wrote:
> >
> > The device tree overlays are a good way to deal with user-modifyable
> > boards or boards with some kind of an expansion mechanism where we can
> > easily plug new board in (like the BBB, the Raspberry Pi or the CHIP).
> >
> > Add a new function to merge overlays with a base device tree.
> >
> > Signed-off-by: Maxime Ripard
> > ---
> > include/libfdt.h | 30
> > lib/libfdt/Makefile | 2 +-
> > lib/libfdt/fdt_overlay.c | 414
> > +++
> > 3 files changed, 445 insertions(+), 1 deletion(-)
> > create mode 100644 lib/libfdt/fdt_overlay.c
> >
> > diff --git a/include/libfdt.h b/include/libfdt.h
> > index 1e01b2c7ebdf..783067e841a1 100644
> > --- a/include/libfdt.h
> > +++ b/include/libfdt.h
> > @@ -1698,6 +1698,36 @@ int fdt_add_subnode(void *fdt, int parentoffset,
> > const char *name);
> > */
> > int fdt_del_node(void *fdt, int nodeoffset);
> >
> > +/**
> > + * fdt_overlay_apply - Applies a DT overlay on a base DT
> > + * @fdt: pointer to the base device tree blob
> > + * @fdto: pointer to the device tree overlay blob
> > + *
> > + * fdt_overlay_apply() will apply the given device tree overlay on the
> > + * given base device tree.
> > + *
> > + * Expect the base device tree to be modified, even if the function
> > + * returns an error.
> > + *
>
> If the base tree has been modified on an error it is unsafe to use it
> for booting. A valid strategy would be to scribble over the DT magic
> number so that that blob is invalidated.
>
> What are the other people’s opinion on this?
>
> > + * returns:
> > + * 0, on success
> > + * -FDT_ERR_NOSPACE, there's not enough space in the base device tree
> > + * -FDT_ERR_NOTFOUND, the overlay points to some inexistant nodes or
> > + * properties in the base DT
> > + * -FDT_ERR_BADPHANDLE, the phandles in the overlay do not have the right
> > + * magic
> > + * -FDT_ERR_INTERNAL,
> > + * -FDT_ERR_BADLAYOUT,
> > + * -FDT_ERR_BADMAGIC,
> > + * -FDT_ERR_BADOFFSET,
> > + * -FDT_ERR_BADPATH,
> > + * -FDT_ERR_BADVERSION,
> > + * -FDT_ERR_BADSTRUCTURE,
> > + * -FDT_ERR_BADSTATE,
> > + * -FDT_ERR_TRUNCATED, standard meanings
> > + */
> > +int fdt_overlay_apply(void *fdt, void *fdto);
> > +
> > /**/
> > /* Debugging / informational functions*/
> > /**/
> > diff --git a/lib/libfdt/Makefile b/lib/libfdt/Makefile
> > index 934d6142c3e9..4935bf012a75 100644
> > --- a/lib/libfdt/Makefile
> > +++ b/lib/libfdt/Makefile
> > @@ -6,4 +6,4 @@
> > #
> >
> > obj-y += fdt.o fdt_ro.o fdt_rw.o fdt_strerror.o fdt_sw.o fdt_wip.o \
> > - fdt_empty_tree.o fdt_addresses.o fdt_region.o
> > + fdt_empty_tree.o fdt_addresses.o fdt_region.o fdt_overlay.o
> > diff --git a/lib/libfdt/fdt_overlay.c b/lib/libfdt/fdt_overlay.c
> > new file mode 100644
> > index ..1e68e903c734
> > --- /dev/null
> > +++ b/lib/libfdt/fdt_overlay.c
> > @@ -0,0 +1,414 @@
> > +#include "libfdt_env.h"
> > +
> > +#include
> > +#include
> > +
> > +#include "libfdt_internal.h"
> > +
> > +static uint32_t fdt_overlay_get_target_phandle(const void *fdto, int node)
> > +{
> > + const uint32_t *val;
> > + int len;
> > +
> > + val = fdt_getprop(fdto, node, "target", &len);
> > + if (!val || (len != sizeof(*val)))
> > + return 0;
> > +
> > + return fdt32_to_cpu(*val);
> > +}
> > +
> > +static int fdt_overlay_get_target(const void *fdt, const void *fdto,
> > + int fragment)
> > +{
> > + uint32_t phandle;
> > + const char *path;
> > +
> > + /* Try first to do a phandle based lookup */
> > + phandle = fdt_overlay_get_target_phandle(fdto, fragment);
> > + if (phandle)
> > + return fdt_node_offset_by_phandle(fdt, phandle);
> > +
> > + /* And then a path based lookup */
> > + path = fdt_getprop(fdto, fragment, "target-path", NULL);
> > + if (!path)
> > + return -FDT_ERR_NOTFOUND;
> > +
> > + return fdt_path_offset(fdt, path);
> > +}
> > +
>
> Those targets are fine; beware there are patches with more target options.
>
> > +static int fdt_overlay_adjust_node_phandles(void *fdto, int node,
> > + uint32_t delta)
> > +{
> > + int property;
> > + int child;
> > +
> > + fdt_for_each_property(fdto, node, property) {
> > + const uint32_t *val;
> > + const char *name;
> > + uint32_t adj_val;
> > + int len;
> > + int ret;
> > +
> > + val = fdt_getprop_by_offset(fdto, property,
> > + &name, &len);
> > + if (!val || (len != sizeof(*val)))
>
> Superfluous parentheses.
>
> > + continue;
> > +
>
Re: [U-Boot] [PATCH] ARM: AM57xx: Enable FIT for HS Devices
On Tuesday 14 June 2016 04:55 AM, Andreas Dannenberg wrote: > Enable FIT support for AM57xx platforms using the high-security (HS) > device variant. > > Signed-off-by: Andreas Dannenberg Reviewed-by: Lokesh Vutla Thanks and regards, Lokesh > --- > > This patch is based on the the patch series [1] by Lokesh. Although > there is currently only 1 device supported by this defconfig the > SPL FIT support is needed in preparation for our upcoming secure > boot related patch series (which is actually the same reasoning > that applies to the AM437x HS-device related patch by Madan [2]). > > [1] https://www.mail-archive.com/u-boot@lists.denx.de/msg215702.html > [2] https://patchwork.ozlabs.org/patch/633961/ > > configs/am57xx_hs_evm_defconfig | 4 > 1 file changed, 4 insertions(+) > > diff --git a/configs/am57xx_hs_evm_defconfig b/configs/am57xx_hs_evm_defconfig > index ce377cb..6fe97ec 100644 > --- a/configs/am57xx_hs_evm_defconfig > +++ b/configs/am57xx_hs_evm_defconfig > @@ -37,3 +37,7 @@ CONFIG_SYS_NS16550=y > CONFIG_USB=y > CONFIG_USB_XHCI_HCD=y > CONFIG_USB_XHCI_DWC3=y > +CONFIG_FIT=y > +CONFIG_SPL_OF_LIBFDT=y > +CONFIG_SPL_LOAD_FIT=y > +CONFIG_OF_LIST="am57xx-beagle-x15" > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] HTTP access to u-boot-x86
On Mon, Jun 13, 2016 at 4:28 PM, Philipp, Damian wrote: > Hello U-Boot Developers, > > just to let you know, I found that http access to the repository > http://git.denx.de/u-boot-x86.git is broken. When I attempt to git clone, I > receive the following message: > > $ git clone http://git.denx.de/u-boot-x86.git > Cloning to 'u-boot-x86' ... > error: Unable to find 8609a7d6a0989a9ff6d886ffe11bcbb1e98748ed under > http://git.denx.de/u-boot-x86.git > Cannot obtain needed tree 8609a7d6a0989a9ff6d886ffe11bcbb1e98748ed > while processing commit 2883cc2d48e99fd1873ef8af03fee7966611b735. > error: fetch failed. > > Access to http://git.denx.de/u-boot.git works flawlessly. To ensure that this > is not a problem with a corporate proxy, I also attempted to access the > repositories from my home machine. I get the same error message for > http://git.denx.de/u-boot-x86.git, while I can clone the repo just fine using > git://git.denx.de/u-boot-x86.git. > +Tom, Wolfgang, Simon I am not sure what's the issue. I've always been using git protocol to do the clone. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 2/2] common: usb_storage : Implement logic to calculate optimal usb maximum trasfer blocks
> -Original Message-
> From: Marek Vasut [mailto:ma...@denx.de]
> Sent: Monday, June 13, 2016 7:07 PM
> To: Rajesh Bhagat ; u-boot@lists.denx.de
> Cc: s...@chromium.org; york sun ; Sriram Dash
> ; Rajesh Bhagat
> Subject: Re: [PATCH v5 2/2] common: usb_storage : Implement logic to calculate
> optimal usb maximum trasfer blocks
>
> On 06/13/2016 06:03 AM, Rajesh Bhagat wrote:
> > From: Rajesh Bhagat
> >
> > Implements the logic to calculate the optimal usb maximum trasfer
> > blocks instead of sending USB_MAX_XFER_BLK blocks which is 65535 and
> > 20 in case of EHCI and other USB protocols respectively.
> >
> > It defines USB_MIN_XFER_BLK/USB_MAX_XFER_BLK trasfer blocks that
> > should be checked for success starting from minimum to maximum, and
> > rest of the read/write are performed with that optimal value. It tries
> > to increase/ decrease the blocks in follwing scenarios:
> >
> > 1.decrease blocks: when read/write for a particular number of blocks
> > fails.
> > 2. increase blocks: when read/write for a particular number of blocks
> > pass and amount left to trasfer is greater than current number of
> > blocks.
> >
> > Currently changes are done for EHCI where min = 4096 and max = 65535
> > is taken. And for other cases code is left unchanged by keeping min =
> > max = 20.
> >
> > Signed-off-by: Sriram Dash
> > Signed-off-by: Rajesh Bhagat
> > ---
> > Changes in v5:
> > - None
> >
> > Changes in v4:
> > - Adds udev paramater in dec/inc_cur_xfer_blks function and adds
> >sanity check on it.
> > - Changes type of pos varible to unsigned int in
> > dec/inc_cur_xfer_blks
> > - Removes usage of pos varible from usb_stor_read/write
> >
> > Changes in v3:
> > - Adds cur_xfer_blks in struct usb_device to retain values
> > - Adds functions dec/inc_cur_xfer_blks to remove code duplication
> > - Moves check from macro to calling functions
> >
> > Changes in v2:
> > - Removes table to store blocks and use formula (1 << (12 + n)) - 1
> > - Adds logic to start from minimum, go to maximum in each read/write
> >
> > common/usb_storage.c | 67
> ++---
> > include/usb.h|1 +
> > 2 files changed, 63 insertions(+), 5 deletions(-)
> >
> > diff --git a/common/usb_storage.c b/common/usb_storage.c index
> > f060637..9b09412 100644
> > --- a/common/usb_storage.c
> > +++ b/common/usb_storage.c
> > @@ -106,11 +106,16 @@ struct us_data {
> > * enough free heap space left, but the SCSI READ(10) and WRITE(10)
> > commands
> are
> > * limited to 65535 blocks.
> > */
> > +#define USB_MIN_XFER_BLK 4095
> > #define USB_MAX_XFER_BLK 65535
> > #else
> > +#define USB_MIN_XFER_BLK 20
> > #define USB_MAX_XFER_BLK 20
> > #endif
> >
> > +#define GET_CUR_XFER_BLKS(blks)(LOG2((blks + 1) /
> (USB_MIN_XFER_BLK + 1)))
> > +#define CALC_CUR_XFER_BLKS(pos)((1 << (12 + pos)) - 1)
Hello Marek,
>
> Parenthesis around variables are missing.
>
Will take care in v6.
> > #ifndef CONFIG_BLK
> > static struct us_data usb_stor[USB_MAX_STOR_DEV]; #endif @@ -141,6
> > +146,44 @@ static void usb_show_progress(void)
> > debug(".");
> > }
> >
> > +static int dec_cur_xfer_blks(struct usb_device *udev) {
> > + /* decrease the cur_xfer_blks */
> > + unsigned int pos;
> > + unsigned short size;
> > +
> > + if (!udev)
> > + return -EINVAL;
> > +
> > + pos = GET_CUR_XFER_BLKS(udev->cur_xfer_blks);
> > + size = pos ? CALC_CUR_XFER_BLKS(pos - 1) : 0;
>
> If pos == 0 , the condition below will be true (size will be 2047), so this
> extra ternary
> is unnecessary.
>
Will take care in v6. Will remove the extra ternary operator used, as 2047 will
follow the
below check (size < USB_MIN_XFER_BLK) and code will work fine.
> > + if (size < USB_MIN_XFER_BLK)
> > + return -EINVAL;
> > +
> > + udev->cur_xfer_blks = size;
> > + return 0;
> > +}
> > +
> > +static int inc_cur_xfer_blks(struct usb_device *udev, lbaint_t blks)
> > +{
> > + /* try to increase the cur_xfer_blks */
> > + unsigned int pos;
> > + unsigned short size;
> > +
> > + if (!udev)
> > + return -EINVAL;
> > +
> > + pos = GET_CUR_XFER_BLKS(udev->cur_xfer_blks);
> > + size = CALC_CUR_XFER_BLKS(pos + 1);
> > +
> > + if (size > blks || size > USB_MAX_XFER_BLK)
> > + return -EINVAL;
>
> Why don't you clamp the size to min(blks, USB_MAX_XFER_BLK) instead ?
>
Do you mean below statement?
if (size > min(blks, USB_MAX_XFER_BLK))
return -EINVAL;
> > + udev->cur_xfer_blks = size;
> > + return 0;
> > +}
> > +
> >
> /**
> *
> > * show info on storage devices; 'usb start/init' must be invoked earlier
> > * as we only retrieve structures populated during devices
> > initialization @@ -1128,6 +1171,7 @@ static unsigned long
> usb_stor_read_write(struct blk_desc *block_dev,
> > struct usb_device *udev;
> > struct us_data *ss
Re: [U-Boot] [PATCH v5 1/2] common: usb_storage: Make common function for usb_stor_read/usb_stor_write
> -Original Message-
> From: Marek Vasut [mailto:ma...@denx.de]
> Sent: Monday, June 13, 2016 7:00 PM
> To: Rajesh Bhagat ; u-boot@lists.denx.de
> Cc: s...@chromium.org; york sun ; Sriram Dash
>
> Subject: Re: [PATCH v5 1/2] common: usb_storage: Make common function for
> usb_stor_read/usb_stor_write
>
> On 06/13/2016 06:03 AM, Rajesh Bhagat wrote:
> > Performs code cleanup by making common function for usb_stor_read/
> > usb_stor_write. Currently only difference in these fucntions is call
> > to usb_read_10/usb_write_10 scsi commands.
> >
> > Signed-off-by: Rajesh Bhagat
> > ---
> > Changes in v5:
> > - Converts USB_STOR_OPERATION_FUNC macro to a function
> > - Corrects the multi line comment accroding to coding style
> > - Renames variable to dev to remove code duplication
> >
> > Changes in v4:
> > - Adds code to make common function for read/write
> >
> > common/usb_storage.c | 129
> > +++--
> > 1 files changed, 40 insertions(+), 89 deletions(-)
> >
> > diff --git a/common/usb_storage.c b/common/usb_storage.c index
> > 7e6e52d..f060637 100644
> > --- a/common/usb_storage.c
> > +++ b/common/usb_storage.c
> > @@ -1104,12 +1104,22 @@ static void usb_bin_fixup(struct
> > usb_device_descriptor descriptor, } #endif /* CONFIG_USB_BIN_FIXUP
> > */
> >
> > +#define USB_STOR_OP_TYPE (is_write ? "write" : "read")
>
Hello Marek,
> I just noticed this gem here. It's a macro which uses a variable, but the
> variable is not
> passed in as it's argument. Just inline this, it's not worth having it as a
> macro here.
>
Will take care in v6. As pointed in last comment, I will be using __func__ and
remove this
macro which was just used to differentiate b/w read/write operations in debug
logs.
> > +static int usb_stor_operation(ccb *srb, struct us_data *ss, unsigned long
> > start,
> > + unsigned short blocks, bool is_write) {
> > + return is_write ? usb_write_10(srb, ss, start, blocks) :
> > + usb_read_10(srb, ss, start, blocks);
>
> usb_read_10() and usb_write_10() look exactly the same for all but the
> command .
> You should do this unification at that level instead.
>
Will take care in v6. Will unify the code to usb_read_write_10 and add is_write
parameter to
process different command. And then it can be called directly instead of making
a wrapper
function.
> > +}
> > +
> > #ifdef CONFIG_BLK
> > -static unsigned long usb_stor_read(struct udevice *dev, lbaint_t blknr,
> > - lbaint_t blkcnt, void *buffer)
> > +static unsigned long usb_stor_read_write(struct udevice *dev, lbaint_t
> > blknr,
> > +lbaint_t blkcnt, const void *buffer,
> > +bool is_write)
> > #else
> > -static unsigned long usb_stor_read(struct blk_desc *block_dev, lbaint_t
> > blknr,
> > - lbaint_t blkcnt, void *buffer)
> > +static unsigned long usb_stor_read_write(struct blk_desc *block_dev,
> > +lbaint_t blknr, lbaint_t blkcnt,
> > +const void *buffer, bool is_write)
> > #endif
> > {
> > lbaint_t start, blks;
> > @@ -1129,9 +1139,9 @@ static unsigned long usb_stor_read(struct
> > blk_desc *block_dev, lbaint_t blknr, #ifdef CONFIG_BLK
> > block_dev = dev_get_uclass_platdata(dev);
> > udev = dev_get_parent_priv(dev_get_parent(dev));
> > - debug("\nusb_read: udev %d\n", block_dev->devnum);
> > + debug("\nusb_%s: udev %d\n", USB_STOR_OP_TYPE, block_dev->devnum);
> > #else
> > - debug("\nusb_read: udev %d\n", block_dev->devnum);
> > + debug("\nusb_%s: udev %d\n", USB_STOR_OP_TYPE, block_dev->devnum);
>
> You can just use "\n%s: ..." and use __func__ instead of USB_STOR_OP_TYPE
> here,
> that'd be less cryptic than "usb_read:" and it's used all over the place
> already anyway.
>
Will take care in v6.
> > udev = usb_dev_desc[block_dev->devnum].priv;
> > if (!udev) {
> > debug("%s: No device\n", __func__); @@ -1146,11 +1156,15 @@
> > static
> > unsigned long usb_stor_read(struct blk_desc *block_dev, lbaint_t blknr,
> > start = blknr;
> > blks = blkcnt;
> >
> > - debug("\nusb_read: dev %d startblk " LBAF ", blccnt " LBAF " buffer %"
> > - PRIxPTR "\n", block_dev->devnum, start, blks, buf_addr);
> > + debug("\nusb_%s: dev %d startblk " LBAF ", blccnt " LBAF " buffer %"
> > + PRIxPTR "\n", USB_STOR_OP_TYPE, block_dev->devnum, start, blks,
> > + buf_addr);
>
> DTTO here.
Will take care in v6.
Best Regards,
Rajesh Bhagat
>
> > do {
> > - /* XXX need some comment here */
> > + /*
> > +* If read/write fails retry for max retry count else
> > +* return with number of blocks written successfully.
> > +*/
> > retry = 2;
> > srb->pdata = (unsigned char *)buf_addr;
> >
Re: [U-Boot] [PATCH v2 2/4] usb: dwc3: Add helper functions to enable snooping and burst settings
> -Original Message-
> From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
> Sent: Friday, June 10, 2016 6:05 AM
> To: Rajat Srivastava
> Cc: U-Boot Mailing List ; Lukasz Majewski
> ; Marek Vašut ; Albert ARIBAUD
> ; Prabhakar Kushwaha ;
> york sun ; Mingkai Hu ; Rajesh Bhagat
> ; Michal Simek ;
> felipe.ba...@linux.intel.com
> Subject: Re: [PATCH v2 2/4] usb: dwc3: Add helper functions to enable
> snooping and
> burst settings
>
> Hi,
>
> On 6 June 2016 at 03:16, Rajat Srivastava wrote:
> > Adds helper functions to enable snooping and outstanding burst beat
> > settings.
> >
> > Signed-off-by: Rajat Srivastava
> > Signed-off-by: Rajesh Bhagat
> > ---
> > Changes in v2:
> > - Removes SoC specific flags and added helper functions
> >
> > drivers/usb/dwc3/core.c | 45
> > +
> > drivers/usb/dwc3/core.h | 7 +++
> > 2 files changed, 52 insertions(+)
> >
> > diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index
> > 85cc96a..0b3c596 100644
> > --- a/drivers/usb/dwc3/core.c
> > +++ b/drivers/usb/dwc3/core.c
> > @@ -599,6 +599,51 @@ static void dwc3_core_exit_mode(struct dwc3 *dwc)
> >
> > #define DWC3_ALIGN_MASK(16 - 1)
> >
> > +void dwc3_core_incr_burst_enable(int index, int btype_incr_val,
> > +int breq_limit) {
> > + struct dwc3 *dwc;
> > + u32 reg;
> > +
> > + list_for_each_entry(dwc, &dwc3_list, list) {
Hello Simon,
>
> Ick - can this be converted to use driver model?
>
We have not moved to use driver model yet :( . Is it possible to pass these
register settings by some other mechanism ?
Best Regards,
Rajesh Bhagat
> > + if (dwc->index != index)
> > + continue;
> > +
> > + /*
> > +* Change burst beat and outstanding pipelined
> > +* transfers requests
> > +*/
> > + reg = dwc3_readl(dwc->regs, DWC3_GSBUSCFG0);
> > + reg = (reg & ~DWC3_INCR_BTYPE_MASK) | btype_incr_val;
> > + dwc3_writel(dwc->regs, DWC3_GSBUSCFG0, reg);
> > +
> > + reg = dwc3_readl(dwc->regs, DWC3_GSBUSCFG1);
> > + reg = (reg & ~DWC3_BREQ_LIMIT_MASK) | (breq_limit << 8);
> > + dwc3_writel(dwc->regs, DWC3_GSBUSCFG1, reg);
> > + break;
> > + }
> > +}
> > +
> > +void dwc3_core_set_snooping(int index, bool snoop) {
> > + struct dwc3 *dwc;
> > + u32 reg;
> > +
> > + list_for_each_entry(dwc, &dwc3_list, list) {
> > + if (dwc->index != index)
> > + continue;
> > +
> > + /* Enable/Disable snooping */
> > + reg = dwc3_readl(dwc->regs, DWC3_GSBUSCFG0);
> > + if (snoop)
> > + reg = reg | DWC3_SNOOP_ENABLE;
> > + else
> > + reg = reg & ~DWC3_SNOOP_ENABLE;
> > + dwc3_writel(dwc->regs, DWC3_GSBUSCFG0, reg);
> > + break;
> > + }
> > +}
> > +
> > /**
> > * dwc3_uboot_init - dwc3 core uboot initialization code
> > * @dwc3_dev: struct dwc3_device containing initialization data diff
> > --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h index
> > 72d2fcd..455e7fa 100644
> > --- a/drivers/usb/dwc3/core.h
> > +++ b/drivers/usb/dwc3/core.h
> > @@ -593,6 +593,13 @@ struct dwc3_hwparams {
> > /* HWPARAMS7 */
> > #define DWC3_RAM1_DEPTH(n) ((n) & 0x)
> >
> > +/* GSBUSCFG0 */
> > +#define DWC3_SNOOP_ENABLE (0x)
> > +#define DWC3_INCR_BTYPE_MASK (0xff)
> > +
> > +/* GSBUSCFG1 */
> > +#define DWC3_BREQ_LIMIT_MASK (0xf00)
> > +
> > struct dwc3_request {
> > struct usb_request request;
> > struct list_headlist;
> > --
> > 2.6.2.198.g614a2ac
> >
>
> Regards,
> Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/4] armv8/fsl-layerscape: add dwc3 gadget driver support
> -Original Message-
> From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
> Sent: Friday, June 10, 2016 6:05 AM
> To: Rajat Srivastava
> Cc: U-Boot Mailing List ; Lukasz Majewski
> ; Marek Vašut ; Albert ARIBAUD
> ; Prabhakar Kushwaha ;
> york sun ; Mingkai Hu ; Rajesh Bhagat
> ; Michal Simek ;
> felipe.ba...@linux.intel.com
> Subject: Re: [PATCH v2 3/4] armv8/fsl-layerscape: add dwc3 gadget driver
> support
>
> Hi,
>
> On 6 June 2016 at 03:16, Rajat Srivastava wrote:
> > Implements the dwc3 gadget driver support for LS1043 platform, and
> > performs below operations:
> > 1. Enables snooping support for DWC3 controller.
> > 2. Enables cache coherency in LS1043 platform.
> >
> > Signed-off-by: Rajat Srivastava
> > Signed-off-by: Rajesh Bhagat
> > Reviewed-by: Lukasz Majewski
> > ---
> > Changes in v2:
> > - Moves DWC3 driver specific code to helper functions
> > - Calls helper functions in SoC specific implementation
> >
> > arch/arm/cpu/armv8/fsl-layerscape/soc.c| 93
> ++
> > .../include/asm/arch-fsl-layerscape/immap_lsch2.h | 6 ++
> > 2 files changed, 99 insertions(+)
> >
> > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > index 0fb5c7f..cc07524 100644
> > --- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > +++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > @@ -17,6 +17,10 @@
> > #ifdef CONFIG_CHAIN_OF_TRUST
> > #include
> > #endif
> > +#include
> > +#include
> > +#include
> > +
> >
> > DECLARE_GLOBAL_DATA_PTR;
> >
> > @@ -318,9 +322,18 @@ void fsl_lsch2_early_init_f(void) #if
> > defined(CONFIG_FSL_QSPI) && !defined(CONFIG_QSPI_BOOT)
> > out_be32(&scfg->qspi_cfg, SCFG_QSPI_CLKSEL); #endif
> > + /* Make SEC and USB reads and writes snoopable */ #if
> > +defined(CONFIG_LS1043A)
> > + setbits_be32(&scfg->snpcnfgcr, SCFG_SNPCNFGCR_SECRDSNP |
> > +SCFG_SNPCNFGCR_SECWRSNP | SCFG_SNPCNFGCR_USB1RDSNP |
> > +SCFG_SNPCNFGCR_USB1WRSNP | SCFG_SNPCNFGCR_USB2RDSNP
> |
> > +SCFG_SNPCNFGCR_USB2WRSNP | SCFG_SNPCNFGCR_USB3RDSNP
> |
> > +SCFG_SNPCNFGCR_USB3WRSNP); #else
> > /* Make SEC reads and writes snoopable */
> > setbits_be32(&scfg->snpcnfgcr, SCFG_SNPCNFGCR_SECRDSNP |
> > SCFG_SNPCNFGCR_SECWRSNP);
> > +#endif
> >
> > /*
> > * Enable snoop requests and DVM message requests for @@
> > -336,6 +349,86 @@ void fsl_lsch2_early_init_f(void) } #endif
> >
> > +#ifdef CONFIG_USB_DWC3
> > +
> > +#if defined(CONFIG_LS1043A)
> > +static struct dwc3_device dwc3_device_data0 = {
> > + .maximum_speed = USB_SPEED_HIGH,
> > + .base = CONFIG_SYS_FSL_XHCI_USB1_ADDR,
> > + .dr_mode = USB_DR_MODE_PERIPHERAL,
> > + .index = 0,
> > +};
> > +
> > +static struct dwc3_device dwc3_device_data1 = {
> > + .maximum_speed = USB_SPEED_HIGH,
> > + .base = CONFIG_SYS_FSL_XHCI_USB2_ADDR,
> > + .dr_mode = USB_DR_MODE_PERIPHERAL,
> > + .index = 1,
> > +};
> > +
> > +static struct dwc3_device dwc3_device_data2 = {
> > + .maximum_speed = USB_SPEED_HIGH,
> > + .base = CONFIG_SYS_FSL_XHCI_USB3_ADDR,
> > + .dr_mode = USB_DR_MODE_PERIPHERAL,
> > + .index = 2,
> > +};
> > +
> > +int usb_gadget_handle_interrupts(int index) {
> > + dwc3_uboot_handle_interrupt(index);
> > + return 0;
> > +}
> > +#endif
> > +
> > +int board_usb_init(int index, enum usb_init_type init) {
> > + switch (init) {
> > + case USB_INIT_DEVICE:
> > + switch (index) {
> > +#if defined(CONFIG_LS1043A)
> > + case 0:
> > + dwc3_uboot_init(&dwc3_device_data0);
> > + break;
> > + case 1:
> > + dwc3_uboot_init(&dwc3_device_data1);
> > + break;
> > + case 2:
> > + dwc3_uboot_init(&dwc3_device_data2);
> > + break;
> > +#endif
>
Hello Simon,
> Can this use driver model? It seems odd to be adding new code like this.
>
Will it be OK to pass below values in dwc3_uboot_init function instead, if DM
is
not used?
Best Regards,
Rajesh Bhagat
> > + default:
> > + printf("Invalid Controller Index\n");
> > + return -1;
> > + }
> > +#if defined(CONFIG_LS1043A)
> > + dwc3_core_incr_burst_enable(index, 0xf, 0xf);
> > + dwc3_core_set_snooping(index, true); #endif
> > + break;
> > + default:
> > + break;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +int board_usb_cleanup(int index, enum usb_init_type init) {
> > + switch (init) {
> > + case USB_INIT_DEVICE:
> > +#if defined(CONFIG_LS1043A)
> > + dwc3_uboot_exit(index); #endif
> > + break;
> > +
[U-Boot] arc: axs103 compile broken ?
Hello Sjoerd, as I just write a tbot testcase, which checks patches, which moves a config option to Kconfig, I tested also to compile arc boards, and the first try immediately failed with: pollux:u-boot-dxr2 hs [master] $ make axs103_defconfig HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/zconf.lex.c SHIPPED scripts/kconfig/zconf.hash.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf # # configuration written to .config # pollux:u-boot-dxr2 hs [master] $ make -s -j8 all In file included from drivers/net/designware.c:21:0: drivers/net/designware.h:11:22: fatal error: asm/gpio.h: Datei oder Verzeichnis nicht gefunden #include ^ compilation terminated. scripts/Makefile.build:280: recipe for target 'drivers/net/designware.o' failed make[1]: *** [drivers/net/designware.o] Error 1 Makefile:1208: recipe for target 'drivers/net' failed make: *** [drivers/net] Error 2 make: *** Warte auf noch nicht beendete Prozesse... pollux:u-boot-dxr2 hs [master] $ looking into the git history of drivers/net/designware.c it seems to me, that the commit: commit 90b7fc924adf "net: designware: support phy reset device-tree bindings" added the missing include. $ find arch/arc/include/asm/ -name gpio.h $ I used the toolchain from: https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/tag/arc-2015.12 Some ideas? May I did something wrong? bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] powerpc/85xx: usb: Limit controllers initialized by usb_init()
Hi, I am looking for a way to limit which usb host interfaces are initiali- zed by usb_init() in order to skip unused interfaces. This is currently governed CONFIG_USB_MAX_CONTROLLER_COUNT, which is possible to redefine at the board level. However this doesn't cover more complex cases where a SoC has multiple host interfaces but a board using that SoC only uses a subset that is not necessarily contiguous. Does there currently exist a way to define such behavior, or should the functionality be added to usb_init() to support this? Thanks. Matthew Bright ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 22/27] net: phy: marvell: Add a missing errno.h header
On 13.6.2016 20:21, Joe Hershberger wrote: > Hi Simon, > > On Mon, Jun 13, 2016 at 12:30 AM, Simon Glass wrote: >> This corrects a build error on zynqmp. >> >> Signed-off-by: Simon Glass Maybe fix this address too. Thanks, Michal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 4/8] ARMv7: PSCI: add codes to save context ID for CPU_ON
From: Hongbo Zhang
According to latest PSCI specification, the context ID is needed by CPU_ON.
This patch saves context ID to the second lowest address of the stack (next to
where target PC is saved), and restores it to r0 when needed while target CPU
booting up.
Signed-off-by: Hongbo Zhang
Signed-off-by: Wang Dongsheng
---
arch/arm/cpu/armv7/nonsec_virt.S | 7 +++
arch/arm/cpu/armv7/psci.S| 4 +++-
arch/arm/include/asm/psci.h | 1 +
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/nonsec_virt.S b/arch/arm/cpu/armv7/nonsec_virt.S
index b7563ed..6566643 100644
--- a/arch/arm/cpu/armv7/nonsec_virt.S
+++ b/arch/arm/cpu/armv7/nonsec_virt.S
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
.arch_extension sec
.arch_extension virt
@@ -89,6 +90,12 @@ _secure_monitor:
movne r4, #0
mcrrne p15, 4, r4, r4, c14 @ Reset CNTVOFF to zero
1:
+#ifdef CONFIG_ARMV7_PSCI
+ bl psci_get_cpu_id
+ bl psci_get_cpu_stack_top
+ sub r0, r0, #PSCI_CONTEXT_ID_OFFSET
+ ldr r0, [r0]@ get Context ID in r0
+#endif
mov lr, ip
mov ip, #(F_BIT | I_BIT | A_BIT)@ Set A, I and F
tst lr, #1 @ Check for Thumb PC
diff --git a/arch/arm/cpu/armv7/psci.S b/arch/arm/cpu/armv7/psci.S
index 5b235df..3ba9e51 100644
--- a/arch/arm/cpu/armv7/psci.S
+++ b/arch/arm/cpu/armv7/psci.S
@@ -253,7 +253,7 @@ ENTRY(psci_enable_smp)
ENDPROC(psci_enable_smp)
.weak psci_enable_smp
-/* expects target CPU in r1, target PC in r2 */
+/* expects target CPU in r1, target PC in r2, target conetxt ID in r3 */
ENTRY(psci_cpu_on_common)
push{lr}
@@ -261,6 +261,8 @@ ENTRY(psci_cpu_on_common)
bl psci_get_cpu_stack_top @ get stack top of target CPU
sub r5, r0, #PSCI_TARGET_PC_OFFSET
str r2, [r5]@ store target PC
+ sub r5, r0, #PSCI_CONTEXT_ID_OFFSET
+ str r3, [r5]@ store target context ID
dsb
pop {pc}
diff --git a/arch/arm/include/asm/psci.h b/arch/arm/include/asm/psci.h
index cb08544..bedcd30 100644
--- a/arch/arm/include/asm/psci.h
+++ b/arch/arm/include/asm/psci.h
@@ -66,6 +66,7 @@
/* size of percpu stack, 1kB */
#define PSCI_PERCPU_STACK_SIZE 0x400
#define PSCI_TARGET_PC_OFFSET (PSCI_PERCPU_STACK_SIZE - 4)
+#define PSCI_CONTEXT_ID_OFFSET (PSCI_PERCPU_STACK_SIZE - 8)
#ifndef __ASSEMBLY__
int psci_update_dt(void *fdt);
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: Allow setenv to set net global variables
Hi Chris,
On Mon, Jun 13, 2016 at 5:52 PM, Chris Packham
wrote:
> On 06/14/2016 10:19 AM, Joe Hershberger wrote:
>> Hi Chris,
>>
>> On Mon, Jun 13, 2016 at 4:13 PM, Chris Packham
>> wrote:
>>> On 06/14/2016 06:34 AM, Joe Hershberger wrote:
Hi Chris,
On Sun, Jun 12, 2016 at 3:58 PM, Chris Packham
wrote:
> Hi Joe,
>
> On 06/11/2016 03:56 AM, Joe Hershberger wrote:
>> On Thu, Jun 9, 2016 at 8:40 PM, Matthew Bright
>> wrote:
>>> The patch fd3056337e6fcc introduces env callbacks to several of the net
>>> related env variables. These callbacks are responsible for updating the
>>> corresponding global variables internal to the net source code. However
>>> this behavior will be skipped if the source of the callbacks originated
>>> from setenv. This is based on the assumption that all current instances
>>> of setenv are invoked using the same global variables that the callback
>>> will eventually write to; therefore there is no need set them to the
>>> same value.
>>>
>>> As setenv is a public interface this assumption may not always hold. In
>>> our usage case we implement a user facing menu system for configuration
>>> of networking parameters. This ultimately lead to calling setenv rather
>>> than through the traditional interactive command line parser do_env_set.
>>> Therefore, in our usage case, setenv can be called for an "interactive"
>>> case. Consequently, the early return for non-interactive invocation are
>>> now removed and any call to setenv will update the corresponding states
>>> internal to the net source code as expected.
>>>
>>> Signed-off-by: Matthew Bright
>>> Reviewed-by: Hamish Martin
>>> Reviewed-by: Chris Packham
>>> ---
>>> net/net.c | 24
>>> 1 file changed, 24 deletions(-)
>>>
>>> diff --git a/net/net.c b/net/net.c
>>> index 1e1d23d..726b0f0 100644
>>> --- a/net/net.c
>>> +++ b/net/net.c
>>> @@ -209,9 +209,6 @@ int __maybe_unused net_busy_flag;
>>> static int on_bootfile(const char *name, const char *value, enum
>>> env_op op,
>>>int flags)
>>> {
>>> - if (flags & H_PROGRAMMATIC)
>>> - return 0;
>>> -
>>
>> Why can't you just change your menu to call the API that is
>> interactive instead of setenv?
>
> Which API are you referring to? _do_env_set() is static so the only
> public api would be run_command("setenv ipaddr ...") or have I missed
> something?
Yes, that's what I was referring to.
Another option would be to add an explicit function that provides this
directly. Maybe even make a generic version that accepts a flags
parameter, then implement the existing function as a call to this new
function which passes in a "programmatic" flag.
>>>
>>> That's what I was thinking. Because setenv is one of the exported
>>> functions for standalone applications I was wondering if instead of
>>> setenv() passing H_PROGRAMMATIC we add prog_setenv() (naming things is
>>> hard) for the net use-case since that is the only thing that currently
>>> checks H_PROGRAMMATIC.
>>
>> That might be OK. The only reservation I have about it is that the
>> setenv() function is generally a programmatic operation since only C
>> code can get to it. Only in the case where you are implementing some
>> more complex interaction (like your menu) is it not actually
>> programmatic. I just worry about it being misleading in the future.
>>
>
> Agreed. My initial reaction was that our menu should be treated like
> H_INTERACTIVE but there wasn't an easy way to achieve this.
>
> Do you have any feel for the direction of H_PROGRAMMATIC is going? Are
> we going to see more environment variables in other parts of the code
> that will get similar treatment.
Given that I implemented the code in question, I can't say I can give
an unbiased opinion about the direction. I would tend toward using
this same paradigm in other places. :)
I can prolly send an RFC tomorrow that shows what I have in mind for
addressing this.
Cheers,
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: AM57xx: Enable FIT for HS Devices
Enable FIT support for AM57xx platforms using the high-security (HS) device variant. Signed-off-by: Andreas Dannenberg --- This patch is based on the the patch series [1] by Lokesh. Although there is currently only 1 device supported by this defconfig the SPL FIT support is needed in preparation for our upcoming secure boot related patch series (which is actually the same reasoning that applies to the AM437x HS-device related patch by Madan [2]). [1] https://www.mail-archive.com/u-boot@lists.denx.de/msg215702.html [2] https://patchwork.ozlabs.org/patch/633961/ configs/am57xx_hs_evm_defconfig | 4 1 file changed, 4 insertions(+) diff --git a/configs/am57xx_hs_evm_defconfig b/configs/am57xx_hs_evm_defconfig index ce377cb..6fe97ec 100644 --- a/configs/am57xx_hs_evm_defconfig +++ b/configs/am57xx_hs_evm_defconfig @@ -37,3 +37,7 @@ CONFIG_SYS_NS16550=y CONFIG_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y +CONFIG_FIT=y +CONFIG_SPL_OF_LIBFDT=y +CONFIG_SPL_LOAD_FIT=y +CONFIG_OF_LIST="am57xx-beagle-x15" -- 2.6.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MinnowMax GPIO for USB3
Hi George, On Sun, Jun 12, 2016 at 5:26 PM, Bin Meng wrote: > On Sun, Jun 12, 2016 at 4:43 PM, Bin Meng wrote: >> Hi, >> >> My testing shows that only pin_usb_host_en1 is needed to turn on the >> power on the USB3 port. The USB2 port power is turned on by default. >> > > Seems I was confused by the GPIO pin number mapping. pin_usb_host_en1 > is used to control the USB2 port, while pin_usb_host_en0 is for USB3 > port. So I should say: > > My testing shows that only pin_usb_host_en1 is needed to turn on the > power on the USB2 (upper white) port. The USB3 (bottom blue) port > power is turned on by default. > > [snip] vinoth eswaran confirmed removing pin_usb_host_en0 node from device tree makes both usb ports work. However, that is just covering the real bug [1] here. Will you take time to prepare a patch that fixes the gpio driver? [1] http://lists.denx.de/pipermail/u-boot/2015-October/229469.html Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] x86: acpi: Disabling SoC functions defined in ASL on a per board basis
Hi George,
On Tue, Jun 14, 2016 at 12:12 AM, George McCollister
wrote:
> On Fri, Jun 10, 2016 at 7:25 PM, Bin Meng wrote:
>> Hi George,
>>
>> +Simon, Stefan
>>
>> On Fri, Jun 10, 2016 at 1:17 AM, George McCollister
>> wrote:
>>> Does anyone have any ideas on how we might go about disabling
>>> functions defined in arch/x86/include/asm/arch-*/acpi on a per board
>>> basis? With DT it's trivial to define all of the functions available
>>> on an SoC and default them to disabled in the .dtsi, then simply mark
>>> them as enabled in the board .dts if the board uses them. I need to
>>> disable the internal UART definition for the baytrail board I'm adding
>>> since if it's included the off chip UART gets killed when Linux does
>>> it's acpi_bus_scan.
>>>
>>
>> Which board are you using? Looks you are using a board that is similar
>> to conga-qeval20-qa3-e3845.
> I'm using an Advantech SOM-DB5800 carrier board with an SOM-6867 Com
> Express board installed. I have a patch almost ready to add it to
> u-boot. I'll need to make some changes to reflect recent patches and
> was hoping to get this issue and azalia configuration resolved as
> well. I could upstream it sooner but the UART will be broken in linux
> (unless hacked out of dsdt prior to build) and HD audio wouldn't work.
>
Great, that means we will have another baytrail board support :)
>>
>> See the TODO comments in arch/x86/include/asm/arch-baytrail/acpi/lpc.asl.
>>
>> /* Internal UART */
>> Device (IURT)
>> {
>> Name(_HID, EISAID("PNP0501"))
>> Name(_UID, 1)
>>
>> Method(_STA, 0, Serialized)
>> {
>> /*
>> * TODO:
>> *
>> * Need to hide the internal UART depending on whether
>> * internal UART is enabled or not so that external
>> * SuperIO UART can be exposed to system.
>> */
>> Store(1, UI3E)
>> Store(1, UI4E)
>> Store(1, C1EN)
>> Return (STA_VISIBLE)
>> }
>>
>> To solve this, we need introduce a variable that is set at runtime by
>> U-Boot to tell the ASL codes to hide the internal UART. This is
>> documented in README.x86 below as optional features, but I also
>> mentioned we will need this sooner or later.
> Okay, I see how this is handled in coreboot. Looks like global_nvs_t
> for fsp_baytrail in coreboot has over 20 parameters I suppose I'd just
> start with one and it would be expanded as needed. I need to
> investigate more about gnvs then maybe I can implement it, time
> permitting.
>
That's actually on my todo list. I will see if I can implement this
soon while leaving you to focus on HD audio.
>>
>> Features that are optional:
>> * ACPI global NVS support. We may need it to simplify ASL code logic if
>>utilizing NVS variables. Most likely we will need this sooner or later.
>>
>> Another place that will need such feature is the memory size. We need
>> tell ASL code to dynamically create the PCI memory space.
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot VESA driver Initialization
On Mon, Jun 13, 2016 at 5:41 PM, vinoth eswaran wrote: > Hello Mr.Bin, > Hello Mr.George McCollister, > > I am working on an embedded project to optimize Linux boot up time. I have > a camera application, which I need to run as fast as possible after powering > up the board. > > For this currently I am analyzing how can I optimize the U-boot. As of now, > u-boot takes around 3 to 4 seconds and most of the time is spent, around 2 > secs in initializing the VESA display. > > I have analyzed the sequence of VESA initialization flow and I have > identified that realmode_call under the function bios_run_on_x86() takes > more time -- around 1.7 Sec, > > realmode_call(addr + 0x0003, num_dev, 0x, 0x, 0x, 0x0, > 0x0); > > Do you have any idea why this is happening? > > I tried removing the VIDEO configuration from u-boot, though the boot up is > fast , the i915 driver from Linux is reporting an error -- 'i915 > :00:02.0: Invalid ROM contents' Can you point out which file in the kernel source that reports this? I cannot find such message in latest kernel source tree. > I understand that the Linux kernel expects the underlying boot loader to > setup some initialization which is missing in this case. > My understanding is that if we have native graphics driver in the kernel, then the bootloader does not need initialize the graphics hardware. > Do you know any methods by which I can speed up the video driver > initialization phase in u-boot. Please note that I don't need video support > during u-boot phase,I am not going to use any splash images. > Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot Minnowmax image overlaps with region './board/intel/minnowmax/vga.bin'
On Mon, Jun 13, 2016 at 8:04 PM, vinoth eswaran wrote: > Hello U-Boot developers, > > In Minnowmax board, I am trying to enable the debug messages of > u-boot. When I try to enable the debug messages either through adding > -DDEBUG flag in config.mk or by adding #define DEBUG in > include/common.h file , I am getting the following error messages. > > U-Boot image overlaps with region './board/intel/minnowmax/vga.bin' > U-Boot finishes at offset 798820, file starts at 79 > make: *** [u-boot.rom] Error 1 > > Any help on this is very much apreciated. Please adjust CONFIG_VGA_BIOS_ADDR so that they don't overlap. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] x86: baytrail: azalia DT configuration mock-up
Hi George,
On Mon, Jun 13, 2016 at 9:09 PM, George McCollister
wrote:
> On Fri, Jun 10, 2016 at 7:17 PM, Bin Meng wrote:
>> Hi George,
>>
>> On Fri, Jun 10, 2016 at 4:57 AM, George McCollister
>> wrote:
>>> I'm looking for feedback on this mock-up of fsp,azalia-config DT
>>> before I proceed to writing code. I included everything in fsp for
>>> context.
>>>
>>> fsp {
>>> compatible = "intel,baytrail-fsp";
>>> fsp,mrc-init-tseg-size = <0>;
>>> fsp,mrc-init-mmio-size = <0x800>;
>>> fsp,mrc-init-spd-addr1 = <0xa0>;
>>> fsp,mrc-init-spd-addr2 = <0xa2>;
>>> fsp,emmc-boot-mode = <2>;
>>> fsp,enable-sdio;
>>> fsp,enable-sdcard;
>>> fsp,enable-hsuart1;
>>> fsp,enable-spi;
>>> fsp,enable-sata;
>>> fsp,sata-mode = <1>;
>>> fsp,enable-azalia;
>>> fsp,azalia-config {
>>> compatible = "intel,baytrail-fsp-azalia-config";
>>
>> I believe this azalia config is platform-specific, so tagging it with
>> a baytrail-fsp- prefix is OK?
> Yes. As far as I can tell there aren't any other platforms with an
> identical azalia config structure.
> I plan on putting the code to handle this in
> arch/x86/cpu/baytrail/fsp_configs.c
> Do you think we should shorten the name to "intel,baytrail-fsp-ac"? If
> we leave it as is it will be the longest entry in compat_names[].
How about changing all "intel,baytrail-fsp" to "intel,byt-fsp"? ac
does not look straight-forward.
>
>>
>>> fsp,pme-enable = <1>;
>>> fsp,docking-supported = <1>;
>>> fsp,docking-attached = <0>;
>>> fsp,hdmi-codec-enable = <1>;
>>> fsp,azalia-v-ci-enable = <1>;
>>> fsp,rsvdbits = <0>;
>>> fsp,reset-wait-timer-us = <300>;
>>> alc262 {
>>> compatible = "fsp,azalia-verb-table";
>>
>> This generic name fsp,azalia-ver-table means it is suitable to all
>> platforms, correct?
> No, I was concerned with this name being too long. This will be
> specific to baytrail-fsp.
> How about "intel,baytrail-fsp-avt"?
>
>>
>>> fsp,vendor-device-id = <0x10ec0262>;
>>> fsp,sub-system-id = <0>;
>>> fsp,revision-id = <0xff>;
>>> fsp,front-panel-support = <1>;
>>> fsp,number-of-rear-jacks = <11>;
>>> fsp,number-of-front-jacks = <2>;
>>> fsp,verb-table-data = <
>>> /* Pin Complex (NID 0x11) */
>>> 0x01171cf0
>>> 0x01171d11
>>> 0x01171e11
>>> 0x01171f41
>>> /* Pin Complex (NID 0x12) */
>>> 0x01271cf0
>>> 0x01271d11
>>> 0x01271e11
>>> 0x01271f41
>>> /* Pin Complex (NID 0x14) */
>>> 0x01471c10
>>> 0x01471d40
>>> 0x01471e01
>>> 0x01471f01
>>> /* Pin Complex (NID 0x15) */
>>> 0x01571cf0
>>> 0x01571d11
>>> 0x01571e11
>>> 0x01571f41
>>> /* Pin Complex (NID 0x16) */
>>> 0x01671cf0
>>> 0x01671d11
>>> 0x01671e11
>>> 0x01671f41
>>> /* Pin Complex (NID 0x18) */
>>> 0x01871c20
>>> 0x01871d98
>>> 0x01871ea1
>>> 0x01871f01
>>> /* Pin Complex (NID 0x19) */
>>> 0x01971c21
>>> 0x01971d98
>>> 0x01971ea1
>>> 0x01971f02
>>> /* Pin Complex (NID 0x1A) */
>>> 0x01a71c2f
>
[U-Boot] [PATCH v5 0/8] ARMv7: PSCI: add PSCI v1.0 support
From: Hongbo Zhang v5 changes: - Give up fixing the potential bug of PSCI stack overlap with secure text end when there is more CPUs in system. Because I just want to keep this series as simple as it could be: adding basic PSCI v1.0 support and adding more PSCI v1.0 implements of our platform. While too compplicated patches in assembly language won't call for effective reviews, even I think there is potential bug of PSCI stack, let's fix it in sepetated patch later. - Move the patch of factoring out psci_cpu_on_common to earlier place 2/8, so that the following patches can only update the psci_cpu_on_common instead of touching each platform's psci_cpu_on, this reduces patches size obviously and make it easier for review. v4 changes: - since there is already PSCI v0.2 function IDs definition merged in 5a07abb, I give up my previous patches 1/11 and 2/11, and move previous 7/11 "ARMv7: PSCI: add PSCI v1.0 functions skeleton" as current first one 1/9 - accept Andre's comment to add the missed "arm,psci-0,2" into compatible string v3 changes: - patch 3/11, re-init the stack pointer to address like start of page instead of page end, because for ARM push operation, the stack pointer is encreased before storing data. - patch 10/11, delete the previous un-implemented cpu_suspend function for ls1 platform, because there is default blank functions for all those are not implemented in specific platform. v2 changes: - re-organize psci_cpu_on_common, this code should be called by each platform's psci_cpu_on, should not be a function calling each psci_cpu_on, all related functions are updated due to this change - update some registers usage, e.g. if r10 is used without push/pop, u-boot cannot launch rt-kernel - update some comments to be clearer, re-organize all patches for easier review - add patch to check already_on or on_pending for LS102XA This patch set contains two parts: ARMv7 PSCI common framework: fix some issues and add v1.0 support NXP (was Freescale) LS102XA: codes enhancement and add v1.0 implementation And this patch set was initially created by Dongsheng Wang. Hongbo Zhang (8): ARMv7: PSCI: add PSCI v1.0 functions skeleton ARMv7: PSCI: factor out reusable psci_cpu_on_common ARMv7: PSCI: update the place of saving target PC ARMv7: PSCI: add codes to save context ID for CPU_ON ARMv7: PSCI: ls102xa: check target CPU ID before further operations ARMv7: PSCI: ls102xa: check ALREADY_ON or ON_PENDING for CPU_ON ARMv7: PSCI: ls102xa: add more PSCI v1.0 functions implemention ARMv7: PSCI: ls102xa: move secure text section into OCRAM arch/arm/cpu/armv7/ls102xa/psci.S | 169 +++-- arch/arm/cpu/armv7/mx7/psci.S | 5 +- arch/arm/cpu/armv7/nonsec_virt.S | 7 ++ arch/arm/cpu/armv7/psci.S | 99 - arch/arm/cpu/armv7/sunxi/psci_sun6i.S | 5 +- arch/arm/cpu/armv7/sunxi/psci_sun7i.S | 5 +- arch/arm/cpu/armv7/virt-dt.c | 10 +- arch/arm/include/asm/arch-ls102xa/config.h | 3 +- arch/arm/include/asm/psci.h| 31 ++ arch/arm/mach-tegra/psci.S | 5 +- board/freescale/ls1021aqds/Makefile| 1 + board/freescale/ls1021aqds/psci.S | 36 ++ board/freescale/ls1021atwr/Makefile| 1 + board/freescale/ls1021atwr/psci.S | 28 + include/configs/ls1021aqds.h | 3 + include/configs/ls1021atwr.h | 3 + 16 files changed, 383 insertions(+), 28 deletions(-) create mode 100644 board/freescale/ls1021aqds/psci.S create mode 100644 board/freescale/ls1021atwr/psci.S -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] HTTP access to u-boot-x86
Dear Bin Meng, In message you wrote: > > I am not sure what's the issue. I've always been using git protocol to > do the clone. I also have no idea. For some reason, HTTP accesses are broken. I speculate that the gitweb code we run on our git server has become incompatible with recent versions of git. We've been planning an update 9and move to a new, faster machine) for a long time, but did not find the resources yet to complete it. In the mean time, using the github repo might be a workaround. I promise to take care ASAP. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "There was no difference between the behavior of a god and the operations of pure chance..." - Thomas Pynchon, _Gravity's Rainbow_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] arc: axs103 compile broken ?
Hi Heiko, On Tue, 2016-06-14 at 07:07 +0200, Heiko Schocher wrote: > Hello Sjoerd, > > as I just write a tbot testcase, which checks patches, which moves > a config option to Kconfig, I tested also to compile arc boards, and > the first try immediately failed with: > > pollux:u-boot-dxr2 hs [master] $ make axs103_defconfig > HOSTCC scripts/basic/fixdep > HOSTCC scripts/kconfig/conf.o > SHIPPED scripts/kconfig/zconf.tab.c > SHIPPED scripts/kconfig/zconf.lex.c > SHIPPED scripts/kconfig/zconf.hash.c > HOSTCC scripts/kconfig/zconf.tab.o > HOSTLD scripts/kconfig/conf > # > # configuration written to .config > # > pollux:u-boot-dxr2 hs [master] $ make -s -j8 all > In file included from drivers/net/designware.c:21:0: > drivers/net/designware.h:11:22: fatal error: asm/gpio.h: Datei oder > Verzeichnis nicht gefunden > #include > ^ > compilation terminated. > scripts/Makefile.build:280: recipe for target 'drivers/net/designware.o' > failed > make[1]: *** [drivers/net/designware.o] Error 1 > Makefile:1208: recipe for target 'drivers/net' failed > make: *** [drivers/net] Error 2 > make: *** Warte auf noch nicht beendete Prozesse... > pollux:u-boot-dxr2 hs [master] $ > > looking into the git history of drivers/net/designware.c it seems > to me, that the commit: > > commit 90b7fc924adf "net: designware: support phy reset device-tree bindings" > > added the missing include. > > $ find arch/arc/include/asm/ -name gpio.h > $ > > I used the toolchain from: > https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/tag/arc-2015.12 > > Some ideas? May I did something wrong? The problem happens because for ARC we don't have "gpio.h" in "arch/arc/include/asm". That's because we never needed one and I don't know what to put there except inclusion of "include/asm-generic/gpio.h". Indeed I or anybody else may send a patch to address that missing header for ARC. But for me it looks like improper solution - why multiply substances? We may instead just include headers from "asm-generic" by default and get rid of all senseless dummy arch/X/include/asm instances. -Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 3/8] ARMv7: PSCI: update the place of saving target PC
From: Hongbo Zhang
The legacy code saves target PC at stack top, this patch changes it to stack
bottom, because we will save more contents for PSCI v1.0, by this way we don't
need to adjust the stack pointer when more contents are saved.
Signed-off-by: Hongbo Zhang
Signed-off-by: Wang Dongsheng
---
arch/arm/cpu/armv7/psci.S | 9 +
arch/arm/include/asm/psci.h | 4
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/arch/arm/cpu/armv7/psci.S b/arch/arm/cpu/armv7/psci.S
index 3b92f1d..5b235df 100644
--- a/arch/arm/cpu/armv7/psci.S
+++ b/arch/arm/cpu/armv7/psci.S
@@ -259,7 +259,8 @@ ENTRY(psci_cpu_on_common)
mov r0, r1
bl psci_get_cpu_stack_top @ get stack top of target CPU
- str r2, [r0]@ store target PC at stack top
+ sub r5, r0, #PSCI_TARGET_PC_OFFSET
+ str r2, [r5]@ store target PC
dsb
pop {pc}
@@ -286,14 +287,13 @@ ENDPROC(psci_cpu_off_common)
@ expects CPU ID in r0 and returns stack top in r0
ENTRY(psci_get_cpu_stack_top)
- mov r5, #0x400 @ 1kB of stack per CPU
+ mov r5, #PSCI_PERCPU_STACK_SIZE @ 1kB of stack per CPU
mul r0, r0, r5
ldr r5, =psci_text_end @ end of monitor text
add r5, r5, #0x2000 @ Skip two pages
lsr r5, r5, #12 @ Align to start of page
lsl r5, r5, #12
- sub r5, r5, #4 @ reserve 1 word for target PC
sub r0, r5, r0 @ here's our stack!
bx lr
@@ -306,7 +306,8 @@ ENTRY(psci_cpu_entry)
bl psci_get_cpu_id @ CPU ID => r0
bl psci_get_cpu_stack_top @ stack top => r0
- ldr r0, [r0]@ target PC at stack top
+ sub r0, r0, #PSCI_TARGET_PC_OFFSET
+ ldr r0, [r0]@ get target PC
b _do_nonsec_entry
ENDPROC(psci_cpu_entry)
diff --git a/arch/arm/include/asm/psci.h b/arch/arm/include/asm/psci.h
index 2367ec0..cb08544 100644
--- a/arch/arm/include/asm/psci.h
+++ b/arch/arm/include/asm/psci.h
@@ -63,6 +63,10 @@
#define ARM_PSCI_1_0_FN_STAT_RESIDENCY ARM_PSCI_0_2_FN(16)
#define ARM_PSCI_1_0_FN_STAT_COUNT ARM_PSCI_0_2_FN(17)
+/* size of percpu stack, 1kB */
+#define PSCI_PERCPU_STACK_SIZE 0x400
+#define PSCI_TARGET_PC_OFFSET (PSCI_PERCPU_STACK_SIZE - 4)
+
#ifndef __ASSEMBLY__
int psci_update_dt(void *fdt);
void psci_board_init(void);
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v1] OMAP3: fix twister board
twister board was not updated after changing SPL defines, resulting in a broken board. Signed-off-by: Stefano Babic --- include/configs/tam3517-common.h | 16 1 file changed, 16 insertions(+) diff --git a/include/configs/tam3517-common.h b/include/configs/tam3517-common.h index efdc706..73ff416 100644 --- a/include/configs/tam3517-common.h +++ b/include/configs/tam3517-common.h @@ -207,6 +207,8 @@ #define CONFIG_SPL_LIBCOMMON_SUPPORT #define CONFIG_SPL_LIBDISK_SUPPORT #define CONFIG_SPL_I2C_SUPPORT +#define CONFIG_SPL_MMC_SUPPORT +#define CONFIG_SPL_FAT_SUPPORT #define CONFIG_SPL_LIBGENERIC_SUPPORT #define CONFIG_SPL_SERIAL_SUPPORT #define CONFIG_SPL_GPIO_SUPPORT @@ -219,12 +221,26 @@ #define CONFIG_SPL_TEXT_BASE 0x4020 /*CONFIG_SYS_SRAM_START*/ #define CONFIG_SPL_MAX_SIZE(54 * 1024) /* 8 KB for stack */ +#define CONFIG_SPL_STACK LOW_LEVEL_SRAM_STACK #define CONFIG_SYS_SPL_MALLOC_START0x8f00 #define CONFIG_SYS_SPL_MALLOC_SIZE 0x8 #define CONFIG_SPL_BSS_START_ADDR 0x8f08 /* end of RAM */ #define CONFIG_SPL_BSS_MAX_SIZE0x8 +#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR0x300 /* address 0x6 */ +#define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION 1 +#define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME"u-boot.img" + +/* FAT */ +#define CONFIG_SPL_FS_LOAD_KERNEL_NAME "uImage" +#define CONFIG_SPL_FS_LOAD_ARGS_NAME "args" + +/* RAW SD card / eMMC */ +#define CONFIG_SYS_MMCSD_RAW_MODE_KERNEL_SECTOR0x900 /* address 0x12 */ +#define CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTOR 0x80/* address 0x1 */ +#define CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTORS 0x80/* 64KiB */ + /* NAND boot config */ #define CONFIG_SYS_NAND_BUSWIDTH_16BIT #define CONFIG_SYS_NAND_PAGE_COUNT 64 -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 2/8] ARMv7: PSCI: factor out reusable psci_cpu_on_common
From: Hongbo Zhang
There are codes for saving target PC in each platform psci_cpu_on routines,
these can be factored out as psci_cpu_on_common.
Another purpose is that the codes of saving target PC will be changed a bit and
a new context ID will be saved in the following patches, then we can update the
psci_cpu_on_common mainly instead of touching every platform's psci_cpu_on
functions more times, this makes it easier for coding and being reviewed.
Signed-off-by: Hongbo Zhang
Signed-off-by: Wang Dongsheng
---
arch/arm/cpu/armv7/ls102xa/psci.S | 5 +
arch/arm/cpu/armv7/mx7/psci.S | 5 +
arch/arm/cpu/armv7/psci.S | 12
arch/arm/cpu/armv7/sunxi/psci_sun6i.S | 5 +
arch/arm/cpu/armv7/sunxi/psci_sun7i.S | 5 +
arch/arm/mach-tegra/psci.S| 5 +
6 files changed, 17 insertions(+), 20 deletions(-)
diff --git a/arch/arm/cpu/armv7/ls102xa/psci.S
b/arch/arm/cpu/armv7/ls102xa/psci.S
index cf5cd48..548c507 100644
--- a/arch/arm/cpu/armv7/ls102xa/psci.S
+++ b/arch/arm/cpu/armv7/ls102xa/psci.S
@@ -35,10 +35,7 @@ psci_cpu_on:
@ r1 = 0xf01
and r1, r1, #0xff
- mov r0, r1
- bl psci_get_cpu_stack_top
- str r2, [r0]
- dsb
+ bl psci_cpu_on_common
@ Get DCFG base address
movwr4, #(CONFIG_SYS_FSL_GUTS_ADDR & 0x)
diff --git a/arch/arm/cpu/armv7/mx7/psci.S b/arch/arm/cpu/armv7/mx7/psci.S
index 34c6ab3..74fdc4d 100644
--- a/arch/arm/cpu/armv7/mx7/psci.S
+++ b/arch/arm/cpu/armv7/mx7/psci.S
@@ -29,10 +29,7 @@ psci_arch_init:
psci_cpu_on:
push{lr}
- mov r0, r1
- bl psci_get_cpu_stack_top
- str r2, [r0]
- dsb
+ bl psci_cpu_on_common
ldr r2, =psci_cpu_entry
bl imx_cpu_on
diff --git a/arch/arm/cpu/armv7/psci.S b/arch/arm/cpu/armv7/psci.S
index 8e25300..3b92f1d 100644
--- a/arch/arm/cpu/armv7/psci.S
+++ b/arch/arm/cpu/armv7/psci.S
@@ -253,6 +253,18 @@ ENTRY(psci_enable_smp)
ENDPROC(psci_enable_smp)
.weak psci_enable_smp
+/* expects target CPU in r1, target PC in r2 */
+ENTRY(psci_cpu_on_common)
+ push{lr}
+
+ mov r0, r1
+ bl psci_get_cpu_stack_top @ get stack top of target CPU
+ str r2, [r0]@ store target PC at stack top
+ dsb
+
+ pop {pc}
+ENDPROC(psci_cpu_on_common)
+
ENTRY(psci_cpu_off_common)
push{lr}
diff --git a/arch/arm/cpu/armv7/sunxi/psci_sun6i.S
b/arch/arm/cpu/armv7/sunxi/psci_sun6i.S
index 90b5bfd..016e491 100644
--- a/arch/arm/cpu/armv7/sunxi/psci_sun6i.S
+++ b/arch/arm/cpu/armv7/sunxi/psci_sun6i.S
@@ -134,10 +134,7 @@ out: mcr p15, 0, r7, c1, c1, 0
psci_cpu_on:
push{lr}
- mov r0, r1
- bl psci_get_cpu_stack_top @ get stack top of target CPU
- str r2, [r0]@ store target PC at stack top
- dsb
+ bl psci_cpu_on_common
movwr0, #(SUN6I_CPUCFG_BASE & 0x)
movtr0, #(SUN6I_CPUCFG_BASE >> 16)
diff --git a/arch/arm/cpu/armv7/sunxi/psci_sun7i.S
b/arch/arm/cpu/armv7/sunxi/psci_sun7i.S
index e15d587..0ebb30e 100644
--- a/arch/arm/cpu/armv7/sunxi/psci_sun7i.S
+++ b/arch/arm/cpu/armv7/sunxi/psci_sun7i.S
@@ -123,10 +123,7 @@ out: mcr p15, 0, r7, c1, c1, 0
psci_cpu_on:
push{lr}
- mov r0, r1
- bl psci_get_cpu_stack_top @ get stack top of target CPU
- str r2, [r0]@ store target PC at stack top
- dsb
+ bl psci_cpu_on_common
movwr0, #(SUN7I_CPUCFG_BASE & 0x)
movtr0, #(SUN7I_CPUCFG_BASE >> 16)
diff --git a/arch/arm/mach-tegra/psci.S b/arch/arm/mach-tegra/psci.S
index b836da1..8a0147c 100644
--- a/arch/arm/mach-tegra/psci.S
+++ b/arch/arm/mach-tegra/psci.S
@@ -90,10 +90,7 @@ ENDPROC(psci_cpu_off)
ENTRY(psci_cpu_on)
push{lr}
- mov r0, r1
- bl psci_get_cpu_stack_top @ get stack top of target CPU
- str r2, [r0]@ store target PC at stack top
- dsb
+ bl psci_cpu_on_common
ldr r6, =TEGRA_RESET_EXCEPTION_VECTOR
ldr r5, =psci_cpu_entry
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] please pull u-boot-samsung master
2016년 6월 10일 금요일, Tom Rini님이 작성한 메시지: > On Fri, Jun 10, 2016 at 03:03:37PM +0900, Minkyu Kang wrote: > > On 30/05/16 11:39, Simon Glass wrote: > > > Hi Minkyu, > > > > > > On 30 May 2016 at 14:31, Minkyu Kang > wrote: > > >> > > >> Dear Simon, > > >> > > >> On 26/05/16 23:52, Tom Rini wrote: > > >>> On Thu, May 26, 2016 at 02:03:08PM +0900, Minkyu Kang wrote: > > >>> > > Dear Tom, > > > > The following changes since commit > fc15b9beed05dec6cc092c265042381a0eadb0e9: > > > > Merge branch 'master' of git://git.denx.de/u-boot-fsl-qoriq > (2016-05-24 13:42:03 -0400) > > > > are available in the git repository at: > > > > > > http://git.denx.de/u-boot-samsung > > > > for you to fetch changes up to > 086e13c5f6f79a68246d6b803cf4736cb6815e44: > > > > ARM: exynos: Disable serial support in SPL (2016-05-26 12:55:49 > +0900) > > > > >>> > > >>> With this applied snow, peach-pi, spring and peach-pit no longer > compile > > >>> due to an EFI issue, please investigate, thanks! > > >>> > > >> > > >> Due to CONFIG_DM_VIDEO is "y" on those boards, efi_loader cannot > refer lcd stuffs. > > >> Did I miss something? or could you please fix it? > > >> > > >> Thanks, > > >> Minkyu Kang. > > > > > > Yes I can take a look, but it may be next week. > > > > > > > Remind. > > Please take care! > > I've taken the samsung PR along with a patch from Alexander to add > DM_VIDEO support (initially) to the EFI GOP code so we're all good now. > > Good to hear! Thanks > -- > Tom > -- Thanks. Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] pci: Make load_oprom and run_oprom independent
At present should_load_oprom() calls board_should_run_oprom() to
determine whether oprom should be loaded. But sometimes we just
want to load oprom without running. Make them independent.
Signed-off-by: Bin Meng
---
drivers/pci/pci_rom.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/pci/pci_rom.c b/drivers/pci/pci_rom.c
index 3ae9231..a168559 100644
--- a/drivers/pci/pci_rom.c
+++ b/drivers/pci/pci_rom.c
@@ -41,10 +41,7 @@ __weak bool board_should_run_oprom(struct udevice *dev)
static bool should_load_oprom(struct udevice *dev)
{
- if (board_should_run_oprom(dev))
- return 1;
-
- return 0;
+ return true;
}
__weak uint32_t board_map_oprom_vendev(uint32_t vendev)
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] pci: Add board_ prefix to should_load_oprom() and make it weak
For consistency with board_should_run_oprom(), do the same to
should_load_oprom(). Board support codes can provide this one
to override the default weak one.
Signed-off-by: Bin Meng
---
drivers/pci/pci_rom.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pci_rom.c b/drivers/pci/pci_rom.c
index a168559..399055b 100644
--- a/drivers/pci/pci_rom.c
+++ b/drivers/pci/pci_rom.c
@@ -39,7 +39,7 @@ __weak bool board_should_run_oprom(struct udevice *dev)
return true;
}
-static bool should_load_oprom(struct udevice *dev)
+__weak bool board_should_load_oprom(struct udevice *dev)
{
return true;
}
@@ -273,7 +273,7 @@ int dm_pci_run_vga_bios(struct udevice *dev, int
(*int15_handler)(void),
return -ENODEV;
}
- if (!should_load_oprom(dev))
+ if (!board_should_load_oprom(dev))
return -ENXIO;
ret = pci_rom_probe(dev, &rom);
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] pci: Remove CONFIG_ALWAYS_LOAD_OPROM
This option is defined at nowhere. Remove it.
Signed-off-by: Bin Meng
---
drivers/pci/pci_rom.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/pci/pci_rom.c b/drivers/pci/pci_rom.c
index 9eb605b..3ae9231 100644
--- a/drivers/pci/pci_rom.c
+++ b/drivers/pci/pci_rom.c
@@ -41,8 +41,6 @@ __weak bool board_should_run_oprom(struct udevice *dev)
static bool should_load_oprom(struct udevice *dev)
{
- if (IS_ENABLED(CONFIG_ALWAYS_LOAD_OPROM))
- return 1;
if (board_should_run_oprom(dev))
return 1;
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot VESA driver Initialization
On Tue, Jun 14, 2016 at 2:57 PM, vinoth eswaran wrote: > Hello Bin, > > On Tue, Jun 14, 2016 at 4:04 AM, Bin Meng wrote: >> On Mon, Jun 13, 2016 at 5:41 PM, vinoth eswaran >> wrote: >>> Hello Mr.Bin, >>> Hello Mr.George McCollister, >>> >>> I am working on an embedded project to optimize Linux boot up time. I have >>> a camera application, which I need to run as fast as possible after powering >>> up the board. >>> >>> For this currently I am analyzing how can I optimize the U-boot. As of now, >>> u-boot takes around 3 to 4 seconds and most of the time is spent, around 2 >>> secs in initializing the VESA display. >>> >>> I have analyzed the sequence of VESA initialization flow and I have >>> identified that realmode_call under the function bios_run_on_x86() takes >>> more time -- around 1.7 Sec, >>> >>> realmode_call(addr + 0x0003, num_dev, 0x, 0x, 0x, 0x0, >>> 0x0); >>> >>> Do you have any idea why this is happening? >>> >>> I tried removing the VIDEO configuration from u-boot, though the boot up is >>> fast , the i915 driver from Linux is reporting an error -- 'i915 >>> :00:02.0: Invalid ROM contents' >> >> Can you point out which file in the kernel source that reports this? I >> cannot find such message in latest kernel source tree. >> > In U-boot I removed the VESA driver support by doing the following > changes, > > In Minnowmax_defconfig: > CONFIG_VIDEO_VESA=n > CONFIG_FRAMEBUFFER_SET_VESA_MODE=n > CONFIG_FRAMEBUFFER_VESA_MODE_11A=n > > In X86-common.h I commented out the macros defining the VIDEO Configuration, > > /* > #define CONFIG_VIDEO > #define CONFIG_VIDEO_SW_CURSOR > #define VIDEO_FB_16BPP_WORD_SWAP > #define CONFIG_VGA_AS_SINGLE_DEVICE > #define CONFIG_CFB_CONSOLE > #define CONFIG_CONSOLE_SCROLL_LINES 5 > */ > > After these changes in the Linux Kernel start up, I am seeing that the > i915 driver is not getting properly initialized. I have attached the > dmesg logs for your reference. > > [0.256735] i915 :00:02.0: Invalid ROM contents > [0.262230] [drm] failed to find VBIOS tables You can try u-boot-x86/pci-working branch, which provides you possibility to load the oprom without running. So that you won't see "Invalid ROM contents" and "failed to find VBIOS tables" anymore. > > The PCI bus its reporting error corresponds to INTEL VGA controller. > 00:02.0 VGA compatible controller: Intel Corporation Atom Processor > Z36xxx/Z37xxx Series Graphics & Display (rev 11) > > The error message is in the Linux source tree: > /drivers/pci/rom.c:dev_err(&pdev->dev, "Invalid ROM contents\n"); > > Though I am seeing i915 init_call returning 0 > > [0.720522] initcall i915_init+0x0/0x99 returned 0 after 456068 usecs. > > I am seeing the weston is not starting up properly. Please let me know > if you find any odd behaviour. > What is 'weston'? >>> I understand that the Linux kernel expects the underlying boot loader to >>> setup some initialization which is missing in this case. >>> >> >> My understanding is that if we have native graphics driver in the >> kernel, then the bootloader does not need initialize the graphics >> hardware. >> >>> Do you know any methods by which I can speed up the video driver >>> initialization phase in u-boot. Please note that I don't need video support >>> during u-boot phase,I am not going to use any splash images. I've tested with the patchset mentioned above, and it looks that the Intel i915 driver may still require vbios to be already run. I am not familiar with the i915 driver at all, but I am trying to investigate. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] spi: spi_flash: Dont set quad enable for micron in all cases
-Original Message-
From: Siva Durga Prasad Paladugu [mailto:siva.durga.palad...@xilinx.com]
Sent: Thursday, May 26, 2016 12:28 PM
To: u-boot@lists.denx.de
Cc: Michal Simek ; jagannadh.t...@gmail.com; Siva Durga
Prasad Paladugu
Subject: [PATCH v2 1/3] spi: spi_flash: Dont set quad enable for micron in all
cases
Dont set quad enable for micron devices in all cases Setting the quad enable
bit in micron expects all other commands like register reads on quad lines
which may not be supported by some controllers. Hence, dont set the quad enable
if controller driver sets the no_all_quad.
Hi Jagan,
Any comments on this series. If not, Please take this series.
Regards,
Siva
Signed-off-by: Siva Durga Prasad Paladugu
---
Changes for v2:
- Newly added in series.
---
drivers/mtd/spi/spi_flash.c | 13 -
include/spi.h |2 +-
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c index
5451725..5b22ae2 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -926,6 +926,8 @@ static int micron_quad_enable(struct spi_flash *flash)
static int set_quad_mode(struct spi_flash *flash, u8 idcode0) {
+ struct spi_slave *spi = flash->spi;
+
switch (idcode0) {
#ifdef CONFIG_SPI_FLASH_MACRONIX
case SPI_FLASH_CFI_MFR_MACRONIX:
@@ -938,7 +940,16 @@ static int set_quad_mode(struct spi_flash *flash, u8
idcode0) #endif #ifdef CONFIG_SPI_FLASH_STMICRO
case SPI_FLASH_CFI_MFR_STMICRO:
- return micron_quad_enable(flash);
+ /*
+* Set quad enable for micron only
+* if controller supports sending of
+* all commands on quad lines, otherwise
+* dont enable it
+*/
+ if (spi->no_all_quad)
+ return 0;
+ else
+ return micron_quad_enable(flash);
#endif
default:
printf("SF: Need set QEB func for %02x flash\n", idcode0); diff
--git a/include/spi.h b/include/spi.h index 4b88d39..17c6e4d 100644
--- a/include/spi.h
+++ b/include/spi.h
@@ -117,7 +117,7 @@ struct spi_slave {
unsigned int max_write_size;
void *memory_map;
u8 option;
-
+ u8 no_all_quad;
u8 flags;
#define SPI_XFER_BEGIN BIT(0) /* Assert CS before transfer */
#define SPI_XFER_END BIT(1) /* Deassert CS after transfer */
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/9] spi: zynq_qspi: Add quad support for zynq qspi
-Original Message-
From: Siva Durga Prasad Paladugu [mailto:siva.durga.palad...@xilinx.com]
Sent: Monday, June 06, 2016 3:15 PM
To: u-boot@lists.denx.de
Cc: Michal Simek ; jagannadh.t...@gmail.com; Siva Durga
Prasad Paladugu
Subject: [PATCH 1/9] spi: zynq_qspi: Add quad support for zynq qspi
Add quad commands supports for zynq qspi driver
Hi Jagan,
Any comments on this series. If not, Please take this series.
Regards,
Siva
Signed-off-by: Siva Durga Prasad Paladugu
---
- Tested on zc702 board
---
drivers/spi/zynq_qspi.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/spi/zynq_qspi.c b/drivers/spi/zynq_qspi.c index
b98663c..e636244 100644
--- a/drivers/spi/zynq_qspi.c
+++ b/drivers/spi/zynq_qspi.c
@@ -11,7 +11,9 @@
#include
#include
#include
+#include
#include
+#include "../mtd/spi/sf_internal.h"
DECLARE_GLOBAL_DATA_PTR;
@@ -156,6 +158,17 @@ static void zynq_qspi_init_hw(struct zynq_qspi_priv *priv)
writel(ZYNQ_QSPI_ENR_SPI_EN_MASK, ®s->enr); }
+static int zynq_qspi_child_pre_probe(struct udevice *bus) {
+ struct spi_slave *slave = dev_get_parent_priv(bus);
+
+ slave->mode_rx = QUAD_OUTPUT_FAST;
+ slave->mode = SPI_TX_QUAD;
+ slave->no_all_quad = 1;
+
+ return 0;
+}
+
static int zynq_qspi_probe(struct udevice *bus) {
struct zynq_qspi_platdata *plat = dev_get_platdata(bus); @@ -627,4
+640,5 @@ U_BOOT_DRIVER(zynq_qspi) = {
.platdata_auto_alloc_size = sizeof(struct zynq_qspi_platdata),
.priv_auto_alloc_size = sizeof(struct zynq_qspi_priv),
.probe = zynq_qspi_probe,
+ .child_pre_probe = zynq_qspi_child_pre_probe,
};
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 7/9] libfdt: Add overlay application function
Hi David,
> On Jun 14, 2016, at 03:25 , David Gibson wrote:
>
> On Fri, Jun 10, 2016 at 05:28:11PM +0300, Pantelis Antoniou wrote:
>> Hi Maxime,
>>
>>> On May 27, 2016, at 12:13 , Maxime Ripard
>>> wrote:
>>>
>>> The device tree overlays are a good way to deal with user-modifyable
>>> boards or boards with some kind of an expansion mechanism where we can
>>> easily plug new board in (like the BBB, the Raspberry Pi or the CHIP).
>>>
>>> Add a new function to merge overlays with a base device tree.
>>>
>>> Signed-off-by: Maxime Ripard
>>> ---
>>> include/libfdt.h | 30
>>> lib/libfdt/Makefile | 2 +-
>>> lib/libfdt/fdt_overlay.c | 414
>>> +++
>>> 3 files changed, 445 insertions(+), 1 deletion(-)
>>> create mode 100644 lib/libfdt/fdt_overlay.c
>>>
>>> diff --git a/include/libfdt.h b/include/libfdt.h
>>> index 1e01b2c7ebdf..783067e841a1 100644
>>> --- a/include/libfdt.h
>>> +++ b/include/libfdt.h
>>> @@ -1698,6 +1698,36 @@ int fdt_add_subnode(void *fdt, int parentoffset,
>>> const char *name);
>>> */
>>> int fdt_del_node(void *fdt, int nodeoffset);
>>>
>>> +/**
>>> + * fdt_overlay_apply - Applies a DT overlay on a base DT
>>> + * @fdt: pointer to the base device tree blob
>>> + * @fdto: pointer to the device tree overlay blob
>>> + *
>>> + * fdt_overlay_apply() will apply the given device tree overlay on the
>>> + * given base device tree.
>>> + *
>>> + * Expect the base device tree to be modified, even if the function
>>> + * returns an error.
>>> + *
>>
>> If the base tree has been modified on an error it is unsafe to use it
>> for booting. A valid strategy would be to scribble over the DT magic
>> number so that that blob is invalidated.
>>
>> What are the other people’s opinion on this?
>>
>>> + * returns:
>>> + * 0, on success
>>> + * -FDT_ERR_NOSPACE, there's not enough space in the base device tree
>>> + * -FDT_ERR_NOTFOUND, the overlay points to some inexistant nodes or
>>> + * properties in the base DT
>>> + * -FDT_ERR_BADPHANDLE, the phandles in the overlay do not have the right
>>> + * magic
>>> + * -FDT_ERR_INTERNAL,
>>> + * -FDT_ERR_BADLAYOUT,
>>> + * -FDT_ERR_BADMAGIC,
>>> + * -FDT_ERR_BADOFFSET,
>>> + * -FDT_ERR_BADPATH,
>>> + * -FDT_ERR_BADVERSION,
>>> + * -FDT_ERR_BADSTRUCTURE,
>>> + * -FDT_ERR_BADSTATE,
>>> + * -FDT_ERR_TRUNCATED, standard meanings
>>> + */
>>> +int fdt_overlay_apply(void *fdt, void *fdto);
>>> +
>>> /**/
>>> /* Debugging / informational functions*/
>>> /**/
>>> diff --git a/lib/libfdt/Makefile b/lib/libfdt/Makefile
>>> index 934d6142c3e9..4935bf012a75 100644
>>> --- a/lib/libfdt/Makefile
>>> +++ b/lib/libfdt/Makefile
>>> @@ -6,4 +6,4 @@
>>> #
>>>
>>> obj-y += fdt.o fdt_ro.o fdt_rw.o fdt_strerror.o fdt_sw.o fdt_wip.o \
>>> - fdt_empty_tree.o fdt_addresses.o fdt_region.o
>>> + fdt_empty_tree.o fdt_addresses.o fdt_region.o fdt_overlay.o
>>> diff --git a/lib/libfdt/fdt_overlay.c b/lib/libfdt/fdt_overlay.c
>>> new file mode 100644
>>> index ..1e68e903c734
>>> --- /dev/null
>>> +++ b/lib/libfdt/fdt_overlay.c
>>> @@ -0,0 +1,414 @@
>>> +#include "libfdt_env.h"
>>> +
>>> +#include
>>> +#include
>>> +
>>> +#include "libfdt_internal.h"
>>> +
>>> +static uint32_t fdt_overlay_get_target_phandle(const void *fdto, int node)
>>> +{
>>> + const uint32_t *val;
>>> + int len;
>>> +
>>> + val = fdt_getprop(fdto, node, "target", &len);
>>> + if (!val || (len != sizeof(*val)))
>>> + return 0;
>>> +
>>> + return fdt32_to_cpu(*val);
>>> +}
>>> +
>>> +static int fdt_overlay_get_target(const void *fdt, const void *fdto,
>>> + int fragment)
>>> +{
>>> + uint32_t phandle;
>>> + const char *path;
>>> +
>>> + /* Try first to do a phandle based lookup */
>>> + phandle = fdt_overlay_get_target_phandle(fdto, fragment);
>>> + if (phandle)
>>> + return fdt_node_offset_by_phandle(fdt, phandle);
>>> +
>>> + /* And then a path based lookup */
>>> + path = fdt_getprop(fdto, fragment, "target-path", NULL);
>>> + if (!path)
>>> + return -FDT_ERR_NOTFOUND;
>>> +
>>> + return fdt_path_offset(fdt, path);
>>> +}
>>> +
>>
>> Those targets are fine; beware there are patches with more target options.
>>
>>> +static int fdt_overlay_adjust_node_phandles(void *fdto, int node,
>>> + uint32_t delta)
>>> +{
>>> + int property;
>>> + int child;
>>> +
>>> + fdt_for_each_property(fdto, node, property) {
>>> + const uint32_t *val;
>>> + const char *name;
>>> + uint32_t adj_val;
>>> + int len;
>>> + int ret;
>>> +
>>> + val = fdt_getprop_by_offset(fdto, property,
>>> + &name, &len);
>>> + if (!val || (len != sizeof(*val
Re: [U-Boot] U-boot VESA driver Initialization
On Tue, Jun 14, 2016 at 11:13 AM, Bin Meng wrote: > On Tue, Jun 14, 2016 at 2:57 PM, vinoth eswaran wrote: >> Hello Mr.Bin, >> >> On Tue, Jun 14, 2016 at 4:04 AM, Bin Meng wrote: >>> On Mon, Jun 13, 2016 at 5:41 PM, vinoth eswaran >>> wrote: Hello Mr.Bin, Hello Mr.George McCollister, I am working on an embedded project to optimize Linux boot up time. I have a camera application, which I need to run as fast as possible after powering up the board. For this currently I am analyzing how can I optimize the U-boot. As of now, u-boot takes around 3 to 4 seconds and most of the time is spent, around 2 secs in initializing the VESA display. I have analyzed the sequence of VESA initialization flow and I have identified that realmode_call under the function bios_run_on_x86() takes more time -- around 1.7 Sec, realmode_call(addr + 0x0003, num_dev, 0x, 0x, 0x, 0x0, 0x0); Do you have any idea why this is happening? I tried removing the VIDEO configuration from u-boot, though the boot up is fast , the i915 driver from Linux is reporting an error -- 'i915 :00:02.0: Invalid ROM contents' >>> >>> Can you point out which file in the kernel source that reports this? I >>> cannot find such message in latest kernel source tree. >>> >> In U-boot I removed the VESA driver support by doing the following >> changes, >> >> In Minnowmax_defconfig: >> CONFIG_VIDEO_VESA=n >> CONFIG_FRAMEBUFFER_SET_VESA_MODE=n >> CONFIG_FRAMEBUFFER_VESA_MODE_11A=n >> >> In X86-common.h I commented out the macros defining the VIDEO Configuration, >> >> /* >> #define CONFIG_VIDEO >> #define CONFIG_VIDEO_SW_CURSOR >> #define VIDEO_FB_16BPP_WORD_SWAP >> #define CONFIG_VGA_AS_SINGLE_DEVICE >> #define CONFIG_CFB_CONSOLE >> #define CONFIG_CONSOLE_SCROLL_LINES 5 >> */ >> >> After these changes in the Linux Kernel start up, I am seeing that the >> i915 driver is not getting properly initialized. I have attached the >> dmesg logs for your reference. >> >> [0.256735] i915 :00:02.0: Invalid ROM contents >> [0.262230] [drm] failed to find VBIOS tables > > You can try u-boot-x86/pci-working branch, which provides you > possibility to load the oprom without running. So that you won't see > "Invalid ROM contents" and "failed to find VBIOS tables" anymore. > >> >> The PCI bus its reporting error corresponds to INTEL VGA controller. >> 00:02.0 VGA compatible controller: Intel Corporation Atom Processor >> Z36xxx/Z37xxx Series Graphics & Display (rev 11) >> >> The error message is in the Linux source tree: >> /drivers/pci/rom.c:dev_err(&pdev->dev, "Invalid ROM contents\n"); >> >> Though I am seeing i915 init_call returning 0 >> >> [0.720522] initcall i915_init+0x0/0x99 returned 0 after 456068 usecs. >> >> I am seeing the weston is not starting up properly. Please let me know >> if you find any odd behaviour. >> > > What is 'weston'? Weston is a display compositor based on wayland protocol. I am using this to run the camera (Video for Linux - weston client) application. For more information you can refer to, https://wayland.freedesktop.org/ I understand that the Linux kernel expects the underlying boot loader to setup some initialization which is missing in this case. >>> >>> My understanding is that if we have native graphics driver in the >>> kernel, then the bootloader does not need initialize the graphics >>> hardware. >>> Do you know any methods by which I can speed up the video driver initialization phase in u-boot. Please note that I don't need video support during u-boot phase,I am not going to use any splash images. > > I've tested with the patchset mentioned above, and it looks that the > Intel i915 driver may still require vbios to be already run. I am not > familiar with the i915 driver at all, but I am trying to investigate. > > Regards, > Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] SPL ext: cosmetic: correct error message in spl_load_image_ext()
Correct the error message in spl_load_image_ext() when image parsing
fails. Instead of "ext4fs_read failed" print "failed to parse image
header".
Signed-off-by: Petr Kulhavy
CC: Guillaume GARDET
---
common/spl/spl_ext.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/spl/spl_ext.c b/common/spl/spl_ext.c
index ade5496..074b31e 100644
--- a/common/spl/spl_ext.c
+++ b/common/spl/spl_ext.c
@@ -50,7 +50,7 @@ int spl_load_image_ext(struct blk_desc *block_dev,
err = spl_parse_image_header(header);
if (err < 0) {
- puts("spl: ext4fs_read failed\n");
+ puts("spl: failed to parse image header\n");
goto end;
}
--
2.5.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot VESA driver Initialization
On Tue, Jun 14, 2016 at 5:29 PM, vinoth eswaran wrote: > On Tue, Jun 14, 2016 at 11:13 AM, Bin Meng wrote: >> On Tue, Jun 14, 2016 at 2:57 PM, vinoth eswaran >> wrote: >>> Hello Mr.Bin, >>> >>> On Tue, Jun 14, 2016 at 4:04 AM, Bin Meng wrote: On Mon, Jun 13, 2016 at 5:41 PM, vinoth eswaran wrote: > Hello Mr.Bin, > Hello Mr.George McCollister, > > I am working on an embedded project to optimize Linux boot up time. I > have > a camera application, which I need to run as fast as possible after > powering > up the board. > > For this currently I am analyzing how can I optimize the U-boot. As of > now, > u-boot takes around 3 to 4 seconds and most of the time is spent, around 2 > secs in initializing the VESA display. > > I have analyzed the sequence of VESA initialization flow and I have > identified that realmode_call under the function bios_run_on_x86() takes > more time -- around 1.7 Sec, > > realmode_call(addr + 0x0003, num_dev, 0x, 0x, 0x, 0x0, > 0x0); > > Do you have any idea why this is happening? > > I tried removing the VIDEO configuration from u-boot, though the boot up > is > fast , the i915 driver from Linux is reporting an error -- 'i915 > :00:02.0: Invalid ROM contents' Can you point out which file in the kernel source that reports this? I cannot find such message in latest kernel source tree. >>> In U-boot I removed the VESA driver support by doing the following >>> changes, >>> >>> In Minnowmax_defconfig: >>> CONFIG_VIDEO_VESA=n >>> CONFIG_FRAMEBUFFER_SET_VESA_MODE=n >>> CONFIG_FRAMEBUFFER_VESA_MODE_11A=n >>> >>> In X86-common.h I commented out the macros defining the VIDEO Configuration, >>> >>> /* >>> #define CONFIG_VIDEO >>> #define CONFIG_VIDEO_SW_CURSOR >>> #define VIDEO_FB_16BPP_WORD_SWAP >>> #define CONFIG_VGA_AS_SINGLE_DEVICE >>> #define CONFIG_CFB_CONSOLE >>> #define CONFIG_CONSOLE_SCROLL_LINES 5 >>> */ >>> >>> After these changes in the Linux Kernel start up, I am seeing that the >>> i915 driver is not getting properly initialized. I have attached the >>> dmesg logs for your reference. >>> >>> [0.256735] i915 :00:02.0: Invalid ROM contents >>> [0.262230] [drm] failed to find VBIOS tables >> >> You can try u-boot-x86/pci-working branch, which provides you >> possibility to load the oprom without running. So that you won't see >> "Invalid ROM contents" and "failed to find VBIOS tables" anymore. >> >>> >>> The PCI bus its reporting error corresponds to INTEL VGA controller. >>> 00:02.0 VGA compatible controller: Intel Corporation Atom Processor >>> Z36xxx/Z37xxx Series Graphics & Display (rev 11) >>> >>> The error message is in the Linux source tree: >>> /drivers/pci/rom.c:dev_err(&pdev->dev, "Invalid ROM >>> contents\n"); >>> >>> Though I am seeing i915 init_call returning 0 >>> >>> [0.720522] initcall i915_init+0x0/0x99 returned 0 after 456068 usecs. >>> >>> I am seeing the weston is not starting up properly. Please let me know >>> if you find any odd behaviour. >>> >> >> What is 'weston'? > Weston is a display compositor based on wayland protocol. I am > using this to run the camera (Video for Linux - weston client) > application. > For more information you can refer to, > https://wayland.freedesktop.org/ > Thanks for the info. > I understand that the Linux kernel expects the underlying boot loader to > setup some initialization which is missing in this case. > My understanding is that if we have native graphics driver in the kernel, then the bootloader does not need initialize the graphics hardware. > Do you know any methods by which I can speed up the video driver > initialization phase in u-boot. Please note that I don't need video > support > during u-boot phase,I am not going to use any splash images. >> >> I've tested with the patchset mentioned above, and it looks that the >> Intel i915 driver may still require vbios to be already run. I am not >> familiar with the i915 driver at all, but I am trying to investigate. >> With vgabios not run by U-Boot, I got: / # dmesg | grep i915 [2.736902] [drm] Initialized i915 1.6.0 20150130 for :00:02.0 on minor 0 [2.812898] [drm] GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5 [2.813219] i915 :00:02.0: No connectors reported connected with modes [3.075881] i915 :00:02.0: fb0: inteldrmfb frame buffer device [3.082817] i915 :00:02.0: registered panic notifier With vgabios run by U-Boot, I got: / # dmesg | grep i915 [2.725559] [drm] Initialized i915 1.6.0 20150130 for :00:02.0 on minor 0 [2.880613] [drm] GMBUS [i915 gmbus vga] timed out, falling back to bit banging on pin 2 [4.644419] i915 :00:02.0: fb0: inteldrmfb frame buffer device [4.644422] i915 :00:02.0: registered panic n
[U-Boot] [PATCH] SPL: ext: remove redundant ifdef statement
Remove redundant #if defined(CONFIG_SPL_OS_BOOT) statement around
getenv() calls in spl_load_image_ext_os().
The whole function is surrounded by #ifdef CONFIG_SPL_OS_BOOT.
No functional change.
Signed-off-by: Petr Kulhavy
CC: Guillaume GARDET
---
common/spl/spl_ext.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/common/spl/spl_ext.c b/common/spl/spl_ext.c
index 074b31e..9a230d5 100644
--- a/common/spl/spl_ext.c
+++ b/common/spl/spl_ext.c
@@ -88,8 +88,7 @@ int spl_load_image_ext_os(struct blk_desc *block_dev, int
partition)
#endif
return -1;
}
-
-#if defined(CONFIG_SPL_ENV_SUPPORT) && defined(CONFIG_SPL_OS_BOOT)
+#if defined(CONFIG_SPL_ENV_SUPPORT)
file = getenv("falcon_args_file");
if (file) {
err = ext4fs_open(file, &filelen);
--
2.5.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [v2] Pull request: u-boot-ubi/master
Hello Tom, please pull from u-boot-ubi.git master The following changes since commit 6b3943f1b04be60f147ee540fbd72c4c7ea89f80: siemens,am33x: add draco etamin board (2016-06-09 13:53:13 -0400) are available in the git repository at: git://git.denx.de/u-boot-ubi.git master for you to fetch changes up to 1cb075c6c6ce1a46c3423e63013686e74457275c: splash_source: add support for ubifs formatted nand (2016-06-14 05:33:02 +0200) Eran Matityahu (1): splash_source: add support for ubifs formatted nand Marcin Niestroj (1): common: env_ubi: Clear environment buffer before reading common/env_ubi.c | 21 + common/splash_source.c | 59 +++ include/splash.h | 2 ++ 3 files changed, 78 insertions(+), 4 deletions(-) bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH v1 1/6] spl: dfu: add dfu support in SPL
Traditionally the DFU support is available only
as part 2nd stage boot loader(u-boot) and DFU
is not supported in SPL.
The SPL-DFU feature is useful for boards which has
only USB inteface and do not have external interface
like ethernet or MMC/SD to boot the board.
This patch add DFU support in SPL to flash boot inital
binary images to factory or bare-metal boards to
memory devices like SPI, eMMC, MMC/SD card using
USB interface.
This SPL-DFU support can be enabled through
Menuconfig->Boot Images->Enable SPL-DFU support
Signed-off-by: Ravi Babu
---
Kconfig | 33 +
common/Makefile | 26 +++---
common/command.c |2 +-
scripts/Makefile.spl | 13 +
4 files changed, 66 insertions(+), 8 deletions(-)
diff --git a/Kconfig b/Kconfig
index f53759a..969641e 100644
--- a/Kconfig
+++ b/Kconfig
@@ -285,6 +285,39 @@ config SPL_LOAD_FIT
particular it can handle selecting from multiple device tree
and passing the correct one to U-Boot.
+config SPL_DFU
+ bool "Enable SPL with DFU to load binaries to bootdevices using USB"
+ depends on USB && CMD_DFU && TARGET_DRA7XX_EVM
+ help
+ Currently the SPL does not have capability to load the
+ binaries or boot images to boot devices like eMMC,SPI,etc.
+ This feature enables the DFU (Device Firmware Upgarde) in SPL with
+ RAM device as default bootdevice. The ROM code will load and execute
+ the SPL/MLO dfu image. The user can flash the binaries to selected
+ dfu device partition from host-pc using dfu-utils.
+ This feature will be useful to flash the binaries to factory
+ or bare-metal boards using USB interface.
+
+choice
+ bool "DFU device selection"
+ depends on CMD_DFU && SPL_DFU
+
+config SPL_DFU_RAM
+ bool "RAM device"
+ depends on CMD_DFU
+ help
+select DDR memory device for flashing binary images to
+the selected partition using DFU.
+
+config SPL_DFU_SF
+ bool "SPI device"
+ depends on CMD_DFU && SPL_DFU
+ help
+select SPI flash memory device for flashing binary images to
+the selected partition using DFU.
+
+endchoice
+
config SYS_CLK_FREQ
depends on ARC || ARCH_SUNXI
int "CPU clock frequency"
diff --git a/common/Makefile b/common/Makefile
index b23f312..0fa441f 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -6,15 +6,30 @@
#
# core
-ifndef CONFIG_SPL_BUILD
-obj-y += init/
-obj-y += main.o
-obj-y += exports.o
+
+CONFIG_INC_DFU=y
+ifdef CONFIG_SPL_BUILD
+ifndef CONFIG_SPL_DFU
+CONFIG_INC_DFU=n
+endif
+endif
+
+ifeq ($(CONFIG_INC_DFU),y)
obj-y += hash.o
ifdef CONFIG_SYS_HUSH_PARSER
obj-y += cli_hush.o
endif
+obj-y += env_attr.o
+obj-y += env_callback.o
+obj-y += env_flags.o
+endif
+
+ifndef CONFIG_SPL_BUILD
+obj-y += init/
+obj-y += main.o
+obj-y += exports.o
+
# This option is not just y/n - it can have a numeric value
ifdef CONFIG_BOOTDELAY
obj-y += autoboot.o
@@ -34,9 +49,6 @@ obj-$(CONFIG_DISPLAY_BOARDINFO_LATE) += board_info.o
obj-$(CONFIG_CMD_BOOTM) += bootm.o bootm_os.o
# environment
-obj-y += env_attr.o
-obj-y += env_callback.o
-obj-y += env_flags.o
obj-$(CONFIG_ENV_IS_IN_DATAFLASH) += env_dataflash.o
obj-$(CONFIG_ENV_IS_IN_EEPROM) += env_eeprom.o
extra-$(CONFIG_ENV_IS_EMBEDDED) += env_embedded.o
diff --git a/common/command.c b/common/command.c
index e5d9b9c..d1c049c 100644
--- a/common/command.c
+++ b/common/command.c
@@ -520,7 +520,7 @@ enum command_ret_t cmd_process(int flag, int argc, char *
const argv[],
if (argc > cmdtp->maxargs)
rc = CMD_RET_USAGE;
-#if defined(CONFIG_CMD_BOOTD)
+#if defined(CONFIG_CMD_BOOTD) && !defined(CONFIG_SPL_BUILD)
/* avoid "bootd" recursion */
else if (cmdtp->cmd == do_bootd) {
if (flag & CMD_FLAG_BOOTD) {
diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index ec8d8f1..be74991 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -35,6 +35,13 @@ else
SPL_BIN := u-boot-spl
endif
+CONFIG_INC_DFU=y
+ifdef CONFIG_SPL_BUILD
+ifndef CONFIG_SPL_DFU
+CONFIG_INC_DFU=n
+endif
+endif
+
include $(srctree)/config.mk
include $(srctree)/arch/$(ARCH)/Makefile
@@ -56,6 +63,12 @@ libs-y += common/init/
libs-$(CONFIG_SPL_LIBCOMMON_SUPPORT) += common/ cmd/
libs-$(CONFIG_SPL_LIBDISK_SUPPORT) += disk/
libs-y += drivers/
+ifeq ($(CONFIG_INC_DFU),y)
+libs-y += drivers/dfu/
+libs-y += drivers/usb/gadget/
+libs-y += drivers/usb/gadget/udc/
+libs-y += drivers/usb/dwc3/
+endif
libs-y += dts/
libs-y += fs/
libs-$(CONFIG_SPL_LIBGENERIC_SUPPORT) += lib/
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH v1 2/6] spl: dfu: adding dfu support functions for SPL-DFU
Adding support functions to run dfu commands
Signed-off-by: Ravi Babu
---
common/spl/Makefile |1 +
common/spl/spl_dfu.c | 153 ++
include/spl.h| 10
3 files changed, 164 insertions(+)
create mode 100644 common/spl/spl_dfu.c
diff --git a/common/spl/Makefile b/common/spl/Makefile
index 2e0f695..7a34697 100644
--- a/common/spl/Makefile
+++ b/common/spl/Makefile
@@ -21,4 +21,5 @@ obj-$(CONFIG_SPL_USB_SUPPORT) += spl_usb.o
obj-$(CONFIG_SPL_FAT_SUPPORT) += spl_fat.o
obj-$(CONFIG_SPL_EXT_SUPPORT) += spl_ext.o
obj-$(CONFIG_SPL_SATA_SUPPORT) += spl_sata.o
+obj-$(CONFIG_SPL_DFU) += spl_dfu.o
endif
diff --git a/common/spl/spl_dfu.c b/common/spl/spl_dfu.c
new file mode 100644
index 000..8b8432b
--- /dev/null
+++ b/common/spl/spl_dfu.c
@@ -0,0 +1,153 @@
+/*
+ * (C) Copyright 2010
+ * Texas Instruments,
+ *
+ * Ravi B
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int run_dfu(int usb_index, char *interface, char *devstring)
+{
+ int ret;
+
+ ret = dfu_init_env_entities(interface, devstring);
+ if (ret)
+ goto done;
+
+ ret = CMD_RET_SUCCESS;
+
+ board_usb_init(usb_index, USB_INIT_DEVICE);
+ g_dnl_clear_detach();
+ g_dnl_register("usb_dnl_dfu");
+
+ while (1) {
+ if (ctrlc())
+ goto exit;
+
+ if (dfu_get_defer_flush()) {
+ /*
+* Call to usb_gadget_handle_interrupts() is necessary
+* to act on ZLP OUT transaction from HOST PC after
+* transmitting the whole file.
+*
+* If this ZLP OUT packet is NAK'ed, the HOST libusb
+* function fails after timeout (by default it is set to
+* 5 seconds). In such situation the dfu-util program
+* exits with error message.
+*/
+ usb_gadget_handle_interrupts(usb_index);
+ ret = dfu_flush(dfu_get_defer_flush(), NULL, 0, 0);
+ dfu_set_defer_flush(NULL);
+ if (ret) {
+ error("Deferred dfu_flush() failed!");
+ goto exit;
+ }
+ }
+
+ WATCHDOG_RESET();
+ usb_gadget_handle_interrupts(usb_index);
+ }
+exit:
+ g_dnl_unregister();
+ board_usb_cleanup(usb_index, USB_INIT_DEVICE);
+done:
+ dfu_free_entities();
+ g_dnl_clear_detach();
+
+ return ret;
+}
+
+int spl_dfu_cmd(int usbctrl, char *dfu_alt_info, char *interface, char *devstr)
+{
+ char *str_env;
+ int ret;
+
+ /* set default environment */
+ set_default_env(0);
+ str_env = getenv(dfu_alt_info);
+ if (!str_env) {
+ error("\"dfu_alt_info\" env variable not defined!\n");
+ return -EINVAL;
+ }
+
+ ret = setenv("dfu_alt_info", str_env);
+ if (ret) {
+ error("unable to set env variable \"dfu_alt_info\"!\n");
+ return -EINVAL;
+ }
+
+ /* invoke dfu command */
+ return run_dfu(usbctrl, interface, devstr);
+}
+
+int spl_dfu_mmc(int usb_index, int mmc_dev, char *dfu_alt_info)
+{
+ struct mmc *mmcdev;
+ struct mmc **mmc = &mmcdev;
+ int device = mmc_dev;
+ int ret;
+
+ /* initialize the mmc module */
+ mmc_initialize(0);
+
+ *mmc = find_mmc_device(device);
+ if (!*mmc) {
+ error("failed to find mmc device %d\n", device);
+ return -ENODEV;
+ }
+
+ ret = mmc_init(*mmc);
+ if (ret) {
+ error("spl: mmc init failed with error: %d\n", ret);
+ return ret;
+ }
+
+ return spl_dfu_cmd(usb_index, dfu_alt_info, "mmc", mmc_dev ? "1" : "0");
+}
+
+ulong spl_fit_ram_read(struct spl_load_info *load, ulong sector, ulong count,
+ void *buf)
+{
+ memcpy(buf, (void *)sector, count);
+ return count;
+}
+
+int spl_dfu_ram_load_image(void)
+{
+ int err = 0;
+ struct image_header *header;
+ unsigned int addr = 0x8020;
+ char *filename = (char *)addr;
+
+ header = (struct image_header *)(CONFIG_SYS_TEXT_BASE -
+ sizeof(struct image_header));
+
+ memcpy(header, filename, sizeof(struct image_header));
+
+ if (IS_ENABLED(CONFIG_SPL_LOAD_FIT)) {
+ struct spl_load_info load;
+ debug("Found FIT\n");
+ load.priv = NULL;
+ load.read = spl_fit_ram_read;
+
+ err = spl_load_simple_fit(&load, (ulong)filenam
[U-Boot] [RFC PATCH v1 3/6] dfu: spl: add generic spl-dfu function in common-spl
Add generic spl-dfu function in common-spl, specific
implemention for configuring dfu memory device is
done in platform board specific source file.
Signed-off-by: Ravi Babu
---
common/spl/spl.c |9 +
include/spl.h|1 +
2 files changed, 10 insertions(+)
diff --git a/common/spl/spl.c b/common/spl/spl.c
index 82e7f58..0726378 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -273,6 +273,11 @@ static void announce_boot_device(u32 boot_device)
static inline void announce_boot_device(u32 boot_device) { }
#endif
+__weak int spl_run_dfu(void)
+{
+ return 0;
+}
+
static int spl_load_image(u32 boot_device)
{
switch (boot_device) {
@@ -367,6 +372,9 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
spl_board_init();
#endif
+ if (spl_run_dfu())
+ goto os_boot;
+
board_boot_order(spl_boot_list);
for (i = 0; i < ARRAY_SIZE(spl_boot_list) &&
spl_boot_list[i] != BOOT_DEVICE_NONE; i++) {
@@ -381,6 +389,7 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
hang();
}
+os_boot:
switch (spl_image.os) {
case IH_OS_U_BOOT:
debug("Jumping to U-Boot\n");
diff --git a/include/spl.h b/include/spl.h
index 8849678..f21a76a 100644
--- a/include/spl.h
+++ b/include/spl.h
@@ -149,4 +149,5 @@ bool spl_was_boot_source(void);
int spl_dfu_mmc(int usb_index, int mmc_dev, char *dfu_alt_info);
int spl_dfu_cmd(int usbctrl, char *dfu_alt_info, char *interface, char
*devstr);
int spl_dfu_ram_load_image(void);
+int spl_run_dfu(void);
#endif
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH v1 5/6] dfu: spl: dra7x: enable SPL-dfu support for dra7x platform
Enable the SPL-DFU support for dra7x platform. Signed-off-by: Ravi Babu --- include/configs/dra7xx_evm.h |8 include/configs/ti_omap5_common.h |2 -- 2 files changed, 4 insertions(+), 6 deletions(-) diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h index e7fb469..686f5d4 100644 --- a/include/configs/dra7xx_evm.h +++ b/include/configs/dra7xx_evm.h @@ -44,7 +44,6 @@ #define CONFIG_SYS_OMAP_ABE_SYSCK -#ifndef CONFIG_SPL_BUILD /* Define the default GPT table for eMMC */ #define PARTS_DEFAULT \ /* Linux partitions */ \ @@ -119,6 +118,7 @@ DFU_ALT_INFO_QSPI /* Fastboot */ +#ifndef CONFIG_SPL_BUILD #define CONFIG_USB_FUNCTION_FASTBOOT #define CONFIG_CMD_FASTBOOT #define CONFIG_ANDROID_BOOT_IMAGE @@ -216,10 +216,10 @@ /* USB Device Firmware Update support */ #define CONFIG_USB_FUNCTION_DFU #define CONFIG_DFU_RAM - -#define CONFIG_DFU_MMC -#define CONFIG_DFU_RAM #define CONFIG_DFU_SF +#ifndef CONFIG_SPL_DFU +#define CONFIG_DFU_MMC +#endif /* SATA */ #define CONFIG_BOARD_LATE_INIT diff --git a/include/configs/ti_omap5_common.h b/include/configs/ti_omap5_common.h index 59f0f70..f9c6576 100644 --- a/include/configs/ti_omap5_common.h +++ b/include/configs/ti_omap5_common.h @@ -66,7 +66,6 @@ #define DFUARGS #endif -#ifndef CONFIG_SPL_BUILD #define CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG #define CONFIG_EXTRA_ENV_SETTINGS \ DEFAULT_LINUX_BOOT_ENV \ @@ -136,7 +135,6 @@ "setenv mmcroot /dev/mmcblk0p2 rw; " \ "run mmcboot;" \ "" -#endif /* * SPL related defines. The Public RAM memory map the ROM defines the -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH v1 4/6] dra7x: spl: dfu: adding SPL-DFU support for dra7x platform
Adding SPL-DFU support for dra7x platform. The DFU
support for dra7x includes QSPI, MMC/SD and eMMC
memory devices. The SPL-DFU memory devices can be
selected through meunconfig->Boot Images.
---
board/ti/dra7xx/evm.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
index c5f7190..bd1f5be 100644
--- a/board/ti/dra7xx/evm.c
+++ b/board/ti/dra7xx/evm.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include "mux_data.h"
#include "../common/board_detect.h"
@@ -706,6 +707,22 @@ int spl_start_uboot(void)
}
#endif
+#ifdef CONFIG_SPL_DFU
+int spl_run_dfu(void)
+{
+ int os_boot = 0;
+#ifdef CONFIG_SPL_DFU_SF
+ spl_dfu_cmd(0, "dfu_alt_info_qspi", "sf", "0:0:6400:0");
+#endif
+#ifdef CONFIG_SPL_DFU_RAM
+ spl_dfu_cmd(0, "dfu_alt_info_ram", "ram", "0");
+ spl_dfu_ram_load_image();
+ os_boot = 1;
+#endif
+ return os_boot;
+}
+#endif
+
#ifdef CONFIG_DRIVER_TI_CPSW
extern u32 *const omap_si_rev;
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH v1 0/6] SPL: DFU Support in SPL
Traditionally the DFU support is available only as part 2nd stage boot loader(u-boot) and DFU is not supported in SPL. The SPL-DFU feature is useful for boards which has only USB inteface and do not have external interface like ethernet or MMC/SD to boot the board. This feature enable DFU to be builtin part of SPL and boot the u-boot directly by loading u-boot image to RAM from PC using dfu-util. This patch series adds DFU support in SPL to flash binary images to factory or bare-metal boards to memory devices like SPI, RAM, eMMC, MMC/SD card using USB interface. As a reference, refer to application note [3] on SPL-DFU support based on 2014.07 u-boot. steps for SPL-DFU/RAM: 1) Soc ROMcode loads the u-boot-spl.bin(+DFU) to IRAM from PC host via usb interface and execute DFU(RAM/SPI). 2) if DFU/RAM is selected, then load u-boot.img to RAM using dfu-util from PC-host. 3) After loading u-boot, press ctrl+c to exit to jump to u-boot. Once u-boot steps for SPL-DFU/SPI: 1) Soc ROMcode loads the u-boot-spl.bin(+DFU) to IRAM from PC host via usb interface and execute DFU(RAM/SPI). 2) If DFU/SPI is selected, then load MLO/u-boot/kernel/dtb images directly to spi partitions. Note: I could not find better option to isolate dfu source to include/exclude in Makefile when SPL-DFU feature enabled/disabled, please suggest any better option. Tested on dra7xx SoCs family. [1] is EVM console output with SPL-DFU/SPI enabled. [2] is ubuntu host console output. references: [1] http://pastebin.ubuntu.com/16730701/ [2] http://pastebin.ubuntu.com/16730765/ [3] http://www.ti.com/lit/an/sprac33/sprac33.pdf Ravi Babu (6): spl: dfu: add dfu support in SPL spl: dfu: adding dfu support functions for SPL-DFU dfu: spl: add generic spl-dfu function in common-spl dra7x: spl: dfu: adding SPL-DFU support for dra7x platform dfu: spl: dra7x: enable SPL-dfu support for dra7x platform dfu: spl: am335x: SPL-DFU support for am335x Kconfig | 33 board/ti/am335x/board.c | 15 board/ti/dra7xx/evm.c | 17 common/Makefile | 26 +-- common/command.c |2 +- common/spl/Makefile |1 + common/spl/spl.c |9 +++ common/spl/spl_dfu.c | 154 + include/configs/am335x_evm.h | 17 +++- include/configs/dra7xx_evm.h |8 +- include/configs/ti_omap5_common.h |2 - include/spl.h | 11 +++ scripts/Makefile.spl | 13 13 files changed, 293 insertions(+), 15 deletions(-) create mode 100644 common/spl/spl_dfu.c -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH v1 6/6] dfu: spl: am335x: SPL-DFU support for am335x
enable the SPL-DFU support for am335x platform.
Signed-off-by: Ravi Babu
---
Kconfig |2 +-
board/ti/am335x/board.c | 15 +++
common/spl/spl_dfu.c |1 +
include/configs/am335x_evm.h | 17 -
4 files changed, 33 insertions(+), 2 deletions(-)
diff --git a/Kconfig b/Kconfig
index 969641e..c4eb4bd 100644
--- a/Kconfig
+++ b/Kconfig
@@ -287,7 +287,7 @@ config SPL_LOAD_FIT
config SPL_DFU
bool "Enable SPL with DFU to load binaries to bootdevices using USB"
- depends on USB && CMD_DFU && TARGET_DRA7XX_EVM
+ depends on USB && CMD_DFU && (TARGET_DRA7XX_EVM || TARGET_AM335X_EVM)
help
Currently the SPL does not have capability to load the
binaries or boot images to boot devices like eMMC,SPI,etc.
diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c
index 690c298..fe56004 100644
--- a/board/ti/am335x/board.c
+++ b/board/ti/am335x/board.c
@@ -246,6 +246,21 @@ const struct dpll_params dpll_ddr_evm_sk = {
const struct dpll_params dpll_ddr_bone_black = {
400, OSC-1, 1, -1, -1, -1, -1};
+#ifdef CONFIG_SPL_DFU
+int spl_run_dfu(void)
+{
+ int os_boot = 0;
+#ifdef CONFIG_SPL_DFU_SF
+ spl_dfu_cmd(0, "dfu_alt_info_qspi", "sf", "0:0:2400:0");
+#endif
+#ifdef CONFIG_SPL_DFU_RAM
+ spl_dfu_cmd(0, "dfu_alt_info_ram", "ram", "0");
+ spl_dfu_ram_load_image();
+ os_boot = 1;
+#endif
+ return os_boot;
+}
+#endif
void am33xx_spl_board_init(void)
{
int mpu_vdd;
diff --git a/common/spl/spl_dfu.c b/common/spl/spl_dfu.c
index 8b8432b..f2badb6 100644
--- a/common/spl/spl_dfu.c
+++ b/common/spl/spl_dfu.c
@@ -143,6 +143,7 @@ int spl_dfu_ram_load_image(void)
struct spl_load_info load;
debug("Found FIT\n");
load.priv = NULL;
+ load.bl_len = 1;
load.read = spl_fit_ram_read;
err = spl_load_simple_fit(&load, (ulong)filename, header);
diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index 1139526..558be7b 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -187,6 +187,9 @@
NETARGS \
DFUARGS \
BOOTENV
+#else
+#define CONFIG_EXTRA_ENV_SETTINGS \
+ DFUARGS
#endif
/* NS16550 Configuration */
@@ -297,12 +300,14 @@
#define CONFIG_AM335X_USB1_MODE MUSB_HOST
#ifndef CONFIG_SPL_USBETH_SUPPORT
+#ifndef CONFIG_SPL_DFU
/* Fastboot */
#define CONFIG_USB_FUNCTION_FASTBOOT
#define CONFIG_CMD_FASTBOOT
#define CONFIG_ANDROID_BOOT_IMAGE
#define CONFIG_FASTBOOT_BUF_ADDR CONFIG_SYS_LOAD_ADDR
#define CONFIG_FASTBOOT_BUF_SIZE 0x0700
+#endif
/* To support eMMC booting */
#define CONFIG_STORAGE_EMMC
@@ -314,9 +319,11 @@
#endif
#ifdef CONFIG_USB_MUSB_GADGET
+#ifndef CONFIG_SPL_DFU
#define CONFIG_USB_ETHER
#define CONFIG_USB_ETH_RNDIS
#define CONFIG_USBNET_HOST_ADDR"de:ad:be:af:00:00"
+#endif
#endif /* CONFIG_USB_MUSB_GADGET */
/*
@@ -348,9 +355,9 @@
#endif
/* USB Device Firmware Update support */
-#ifndef CONFIG_SPL_BUILD
#define CONFIG_USB_FUNCTION_DFU
#define CONFIG_DFU_MMC
+#define CONFIG_DFU_RAM
#define DFU_ALT_INFO_MMC \
"dfu_alt_info_mmc=" \
"boot part 0 1;" \
@@ -364,6 +371,7 @@
"spl-os-image fat 0 1;" \
"u-boot.img fat 0 1;" \
"uEnv.txt fat 0 1\0"
+#ifndef CONFIG_SPL_DFU
#ifdef CONFIG_NAND
#define CONFIG_DFU_NAND
#define DFU_ALT_INFO_NAND \
@@ -379,17 +387,24 @@
#else
#define DFU_ALT_INFO_NAND ""
#endif
+#endif
#define CONFIG_DFU_RAM
#define DFU_ALT_INFO_RAM \
"dfu_alt_info_ram=" \
"kernel ram 0x8020 0xD8;" \
"fdt ram 0x80F8 0x8;" \
"ramdisk ram 0x8100 0x400\0"
+#ifndef CONFIG_SPL_DFU
#define DFUARGS \
"dfu_alt_info_emmc=rawemmc raw 0 3751936\0" \
DFU_ALT_INFO_MMC \
DFU_ALT_INFO_RAM \
DFU_ALT_INFO_NAND
+#else
+#define DFUARGS \
+ "dfu_alt_info_emmc=rawemmc raw 0 3751936\0" \
+ DFU_ALT_INFO_MMC \
+ DFU_ALT_INFO_RAM
#endif
/*
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 1/2] powerpc/mpc85xx: SECURE BOOT- Enable chain of trust in SPL
As part of Chain of Trust for Secure boot, the SPL U-Boot will validate
the next level U-boot image. Add a new function spl_validate_uboot to
perform the validation.
Enable hardware crypto operations in SPL using SEC block.
In case of Secure Boot, PAMU is not bypassed. For allowing SEC block
access to CPC configured as SRAM, configure PAMU.
Reviewed-by: Ruchika Gupta
Signed-off-by: Aneesh Bansal
Signed-off-by: Sumit Garg
---
Changes in v2:
Patches rebased
Changes in v3:
Patches rebased
Changes in v4:
Generic changes in lib, drivers, common Makefiles removed from
this patchset. Rebased this patchset on top of patch [1], so this
patchset is dependent on patch [1].
[1]https://patchwork.ozlabs.org/patch/627664/
Changes in v5:
Check for def CONFIG_SPL_DM and ndef CONFIG_SPL_FRAMEWORK instead
of def CONFIG_DM macro to include call to dm_init_and_scan().
As dm_init_and_scan() is called as part of common SPL framework,
so no need to call it again but in case of powerpc platforms which
currently do not use common SPL framework, so need to include this
function call here.
arch/powerpc/cpu/mpc8xxx/fsl_pamu.c | 8 +
arch/powerpc/cpu/mpc8xxx/pamu_table.c | 8 +
arch/powerpc/include/asm/fsl_secure_boot.h | 28 +++
board/freescale/common/fsl_chain_of_trust.c | 54 +
drivers/crypto/fsl/jr.c | 16 +
drivers/mtd/nand/fsl_ifc_spl.c | 24 +
include/fsl_validate.h | 1 +
7 files changed, 139 insertions(+)
diff --git a/arch/powerpc/cpu/mpc8xxx/fsl_pamu.c
b/arch/powerpc/cpu/mpc8xxx/fsl_pamu.c
index 9421f1e..ede8e66 100644
--- a/arch/powerpc/cpu/mpc8xxx/fsl_pamu.c
+++ b/arch/powerpc/cpu/mpc8xxx/fsl_pamu.c
@@ -239,15 +239,23 @@ int pamu_init(void)
spaact_size = sizeof(struct paace) * NUM_SPAACT_ENTRIES;
/* Allocate space for Primary PAACT Table */
+#if (defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_PPAACT_ADDR))
+ ppaact = (void *)CONFIG_SPL_PPAACT_ADDR;
+#else
ppaact = memalign(PAMU_TABLE_ALIGNMENT, ppaact_size);
if (!ppaact)
return -1;
+#endif
memset(ppaact, 0, ppaact_size);
/* Allocate space for Secondary PAACT Table */
+#if (defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_SPAACT_ADDR))
+ sec = (void *)CONFIG_SPL_SPAACT_ADDR;
+#else
sec = memalign(PAMU_TABLE_ALIGNMENT, spaact_size);
if (!sec)
return -1;
+#endif
memset(sec, 0, spaact_size);
ppaact_phys = virt_to_phys((void *)ppaact);
diff --git a/arch/powerpc/cpu/mpc8xxx/pamu_table.c
b/arch/powerpc/cpu/mpc8xxx/pamu_table.c
index 26c5ea4..a8e6f51 100644
--- a/arch/powerpc/cpu/mpc8xxx/pamu_table.c
+++ b/arch/powerpc/cpu/mpc8xxx/pamu_table.c
@@ -28,6 +28,14 @@ void construct_pamu_addr_table(struct pamu_addr_tbl *tbl,
int *num_entries)
i++;
#endif
+#if (defined(CONFIG_SPL_BUILD) && (CONFIG_SYS_INIT_L3_VADDR))
+ tbl->start_addr[i] =
+ (uint64_t)virt_to_phys((void *)CONFIG_SYS_INIT_L3_VADDR);
+ tbl->size[i] = 256 * 1024; /* 256K CPC flash */
+ tbl->end_addr[i] = tbl->start_addr[i] + tbl->size[i] - 1;
+
+ i++;
+#endif
debug("PAMU address\t\t\tsize\n");
for (j = 0; j < i ; j++)
debug("%llx \t\t\t%llx\n", tbl->start_addr[j], tbl->size[j]);
diff --git a/arch/powerpc/include/asm/fsl_secure_boot.h
b/arch/powerpc/include/asm/fsl_secure_boot.h
index 826f9c9..99eec7f 100644
--- a/arch/powerpc/include/asm/fsl_secure_boot.h
+++ b/arch/powerpc/include/asm/fsl_secure_boot.h
@@ -72,6 +72,32 @@
#ifdef CONFIG_CHAIN_OF_TRUST
+#ifdef CONFIG_SPL_BUILD
+#define CONFIG_SPL_DM 1
+#define CONFIG_SPL_CRYPTO_SUPPORT
+#define CONFIG_SPL_HASH_SUPPORT
+#define CONFIG_SPL_RSA
+#define CONFIG_SPL_DRIVERS_MISC_SUPPORT
+/*
+ * PPAACT and SPAACT table for PAMU must be placed on DDR after DDR init
+ * due to space crunch on CPC and thus malloc will not work.
+ */
+#define CONFIG_SPL_PPAACT_ADDR 0x2e00
+#define CONFIG_SPL_SPAACT_ADDR 0x2f00
+#define CONFIG_SPL_JR0_LIODN_S 454
+#define CONFIG_SPL_JR0_LIODN_NS458
+/*
+ * Define the key hash for U-Boot here if public/private key pair used to
+ * sign U-boot are different from the SRK hash put in the fuse
+ * Example of defining KEY_HASH is
+ * #define CONFIG_SPL_UBOOT_KEY_HASH \
+ * "41066b564c6ffcef40ccbc1e0a5d0d519604000c785d97bbefd25e4d288d1c8b"
+ * else leave it defined as NULL
+ */
+
+#define CONFIG_SPL_UBOOT_KEY_HASH NULL
+#endif /* ifdef CONFIG_SPL_BUILD */
+
#define CONFIG_CMD_ESBC_VALIDATE
#define CONFIG_CMD_BLOB
#define CONFIG_FSL_SEC_MON
@@ -82,6 +108,7 @@
#define CONFIG_FSL_CAAM
#endif
+#ifndef CONFIG_SPL_BUILD
/* fsl_setenv_chain_of_trust() must be called from
* board_late_init()
*/
@@ -119,5 +146,6 @@
#endif /* #ifdef CONFIG_BOOTSCRIPT_COPY_RAM */
#include
+#endif /* #ifndef CONFIG_SPL_BUILD */
#e
[U-Boot] [PATCH v5 2/2] powerpc/mpc85xx: T104x: Add nand secure boot target
For mpc85xx SoCs, the core begins execution from address 0xFFFC. In non-secure boot scenario from NAND, this address will map to CPC configured as SRAM. But in case of secure boot, this default address always maps to IBR (Internal Boot ROM). The IBR code requires that the bootloader(U-boot) must lie in 0 to 3.5G address space i.e. 0x0 - 0xDFFF. For secure boot target from NAND, the text base for SPL is kept same as non-secure boot target i.e. 0xFFFx_ but the SPL U-boot binary will be copied to CPC configured as SRAM with address in 0-3.5G(0xBFFC_) As a the virtual and physical address of CPC would be different. The virtual address 0xFFFx_ needs to be mapped to physical address 0xBFFx_. Create a new PBI file to configure CPC as SRAM with address 0xBFFC and update DCFG SCRTACH1 register with location of Header required for secure boot. The changes are similar to commit 467a40dfe35f48d830f01a72617207d03ca85b4d powerpc/mpc85xx: SECURE BOOT- NAND secure boot target for P3041 While P3041 has a 1MB CPC and does not require SPL. On T104x, CPC is only 256K and thus SPL framework is used. The changes are only applicable for SPL U-Boot running out of CPC SRAM and not the next level U-Boot loaded on DDR. Reviewed-by: Ruchika Gupta Signed-off-by: Aneesh Bansal Signed-off-by: Sumit Garg --- Changes in v2: Patches rebased Changes in v3: Patches rebased Changes in v4: Generic changes in lib, drivers, common Makefiles removed from this patchset. Rebased this patchset on top of patch [1], so this patchset is dependent on patch [1]. [1]https://patchwork.ozlabs.org/patch/627664/ Changes in v5: Check for def CONFIG_SPL_DM and ndef CONFIG_SPL_FRAMEWORK instead of def CONFIG_DM macro to include call to dm_init_and_scan(). As dm_init_and_scan() is called as part of common SPL framework, so no need to call it again but in case of powerpc platforms which currently do not use common SPL framework, so need to include this function call here. arch/powerpc/cpu/mpc85xx/cpu_init.c| 4 +-- arch/powerpc/cpu/mpc85xx/start.S | 11 ++-- arch/powerpc/include/asm/fsl_secure_boot.h | 10 ++- board/freescale/t104xrdb/t104x_pbi_sb.cfg | 38 ++ board/freescale/t104xrdb/tlb.c | 15 +- configs/T1042RDB_PI_NAND_SECURE_BOOT_defconfig | 30 include/configs/T104xRDB.h | 29 +++- 7 files changed, 129 insertions(+), 8 deletions(-) create mode 100644 board/freescale/t104xrdb/t104x_pbi_sb.cfg create mode 100644 configs/T1042RDB_PI_NAND_SECURE_BOOT_defconfig diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c b/arch/powerpc/cpu/mpc85xx/cpu_init.c index 61f5639..ace4279 100644 --- a/arch/powerpc/cpu/mpc85xx/cpu_init.c +++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c @@ -439,7 +439,7 @@ ulong cpu_init_f(void) #ifdef CONFIG_SYS_DCSRBAR_PHYS ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR); #endif -#if defined(CONFIG_SECURE_BOOT) +#if defined(CONFIG_SECURE_BOOT) && !defined(CONFIG_SYS_RAMBOOT) struct law_entry law; #endif #ifdef CONFIG_MPC8548 @@ -459,7 +459,7 @@ ulong cpu_init_f(void) disable_tlb(14); disable_tlb(15); -#if defined(CONFIG_SECURE_BOOT) +#if defined(CONFIG_SECURE_BOOT) && !defined(CONFIG_SYS_RAMBOOT) /* Disable the LAW created for NOR flash by the PBI commands */ law = find_law(CONFIG_SYS_PBI_FLASH_BASE); if (law.index != -1) diff --git a/arch/powerpc/cpu/mpc85xx/start.S b/arch/powerpc/cpu/mpc85xx/start.S index 4c51225..0850727 100644 --- a/arch/powerpc/cpu/mpc85xx/start.S +++ b/arch/powerpc/cpu/mpc85xx/start.S @@ -1069,17 +1069,22 @@ create_init_ram_area: #elif !defined(CONFIG_SYS_RAMBOOT) && defined(CONFIG_SECURE_BOOT) /* create a temp mapping in AS = 1 for Flash mapping * created by PBL for ISBC code - */ +*/ create_tlb1_entry 15, \ 1, BOOKE_PAGESZ_1M, \ CONFIG_SYS_MONITOR_BASE & 0xfff0, MAS2_I|MAS2_G, \ CONFIG_SYS_PBI_FLASH_WINDOW & 0xfff0, MAS3_SX|MAS3_SW|MAS3_SR, \ 0, r6 -#elif defined(CONFIG_RAMBOOT_PBL) && defined(CONFIG_SECURE_BOOT) +/* For Targets without CONFIG_SPL like P3, P5 + * and for targets with CONFIG_SPL like T1, T2, T4, only for + * u-boot-spl i.e. CONFIG_SPL_BUILD + */ +#elif defined(CONFIG_RAMBOOT_PBL) && defined(CONFIG_SECURE_BOOT) && \ + (!defined(CONFIG_SPL) || defined(CONFIG_SPL_BUILD)) /* create a temp mapping in AS = 1 for mapping CONFIG_SYS_MONITOR_BASE * to L3 Address configured by PBL for ISBC code - */ +*/ create_tlb1_entry 15, \ 1, BOOKE_PAGESZ_1M, \ CONFIG_SYS_MONITOR_BASE & 0xfff0, MAS2_I|MAS2_G, \ diff --git a/arch/powerpc/include/asm/fsl_secure_boot.h b/arch/powerpc/include/asm/fsl_secure_boot.h index 99eec7f..2435cf8 100644 --- a/arch/powerpc/include/asm/fsl_secur
[U-Boot] [PATCH 1/4] DM: crypto/fsl: Enable rsa DM driver usage before relocation
Enable rsa signature verification in SPL framework before relocation for
verification of main u-boot.
Reviewed-by: Aneesh Bansal
Signed-off-by: Sumit Garg
---
drivers/crypto/fsl/fsl_rsa.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/crypto/fsl/fsl_rsa.c b/drivers/crypto/fsl/fsl_rsa.c
index cf1c4c1..5471504 100644
--- a/drivers/crypto/fsl/fsl_rsa.c
+++ b/drivers/crypto/fsl/fsl_rsa.c
@@ -53,6 +53,7 @@ U_BOOT_DRIVER(fsl_rsa_mod_exp) = {
.name = "fsl_rsa_mod_exp",
.id = UCLASS_MOD_EXP,
.ops= &fsl_mod_exp_ops,
+ .flags = DM_FLAG_PRE_RELOC,
};
U_BOOT_DEVICE(fsl_rsa) = {
--
1.8.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] SECURE_BOOT: Enable chain of trust in SPL framework
Override jump_to_image_no_args function to include validation of
u-boot image using spl_validate_uboot before jumping to u-boot image.
Also define macros in SPL framework to enable crypto operations.
Reviewed-by: Aneesh Bansal
Signed-off-by: Sumit Garg
---
arch/arm/include/asm/fsl_secure_boot.h | 25 +++--
board/freescale/common/fsl_chain_of_trust.c | 34 -
2 files changed, 56 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/fsl_secure_boot.h
b/arch/arm/include/asm/fsl_secure_boot.h
index 53cd755..3f76c9a 100644
--- a/arch/arm/include/asm/fsl_secure_boot.h
+++ b/arch/arm/include/asm/fsl_secure_boot.h
@@ -17,8 +17,6 @@
#ifdef CONFIG_CHAIN_OF_TRUST
#define CONFIG_CMD_ESBC_VALIDATE
-#define CONFIG_CMD_BLOB
-#define CONFIG_CMD_HASH
#define CONFIG_FSL_SEC_MON
#define CONFIG_SHA_HW_ACCEL
#define CONFIG_SHA_PROG_HW_ACCEL
@@ -28,6 +26,28 @@
#define CONFIG_FSL_CAAM
#endif
+#ifdef CONFIG_SPL_BUILD
+#define CONFIG_SPL_BOARD_INIT
+#define CONFIG_SPL_DM 1
+#define CONFIG_SPL_CRYPTO_SUPPORT
+#define CONFIG_SPL_HASH_SUPPORT
+#define CONFIG_SPL_RSA
+#define CONFIG_SPL_DRIVERS_MISC_SUPPORT
+/*
+ * Define the key hash for U-Boot here if public/private key pair used to
+ * sign U-boot are different from the SRK hash put in the fuse
+ * Example of defining KEY_HASH is
+ * #define CONFIG_SPL_UBOOT_KEY_HASH \
+ * "41066b564c6ffcef40ccbc1e0a5d0d519604000c785d97bbefd25e4d288d1c8b"
+ * else leave it defined as NULL
+ */
+
+#define CONFIG_SPL_UBOOT_KEY_HASH NULL
+#endif /* ifdef CONFIG_SPL_BUILD */
+
+#ifndef CONFIG_SPL_BUILD
+#define CONFIG_CMD_BLOB
+#define CONFIG_CMD_HASH
#define CONFIG_KEY_REVOCATION
#ifndef CONFIG_SYS_RAMBOOT
/* The key used for verification of next level images
@@ -92,5 +112,6 @@
#endif
#include
+#endif /* #ifndef CONFIG_SPL_BUILD */
#endif /* #ifdef CONFIG_CHAIN_OF_TRUST */
#endif
diff --git a/board/freescale/common/fsl_chain_of_trust.c
b/board/freescale/common/fsl_chain_of_trust.c
index 7bf9827..0f5ec35 100644
--- a/board/freescale/common/fsl_chain_of_trust.c
+++ b/board/freescale/common/fsl_chain_of_trust.c
@@ -10,6 +10,10 @@
#include
#include
+#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_FRAMEWORK)
+#include
+#endif
+
#ifdef CONFIG_ADDR_MAP
#include
#endif
@@ -113,7 +117,7 @@ void spl_validate_uboot(uint32_t hdr_addr, uintptr_t
img_addr)
* do not use common SPL framework, so need to call this function here.
*/
#if defined(CONFIG_SPL_DM) && (!defined(CONFIG_SPL_FRAMEWORK))
- dm_init_and_scan(false);
+ dm_init_and_scan(true);
#endif
res = fsl_secboot_validate(hdr_addr, CONFIG_SPL_UBOOT_KEY_HASH,
&img_addr);
@@ -121,4 +125,32 @@ void spl_validate_uboot(uint32_t hdr_addr, uintptr_t
img_addr)
if (res == 0)
printf("SPL: Validation of U-boot successful\n");
}
+
+#ifdef CONFIG_SPL_FRAMEWORK
+/* Override weak funtion defined in SPL framework to enable validation
+ * of main u-boot image before jumping to u-boot image.
+ */
+void __noreturn jump_to_image_no_args(struct spl_image_info *spl_image)
+{
+ typedef void __noreturn (*image_entry_noargs_t)(void);
+ uint32_t hdr_addr;
+
+ image_entry_noargs_t image_entry =
+ (image_entry_noargs_t)(unsigned long)spl_image->entry_point;
+
+ hdr_addr = (spl_image->entry_point + spl_image->size -
+ CONFIG_U_BOOT_HDR_SIZE);
+ spl_validate_uboot(hdr_addr, (uintptr_t)spl_image->entry_point);
+ /*
+* In case of failure in validation, spl_validate_uboot would
+* not return back in case of Production environment with ITS=1.
+* Thus U-Boot will not start.
+* In Development environment (ITS=0 and SB_EN=1), the function
+* may return back in case of non-fatal failures.
+*/
+
+ debug("image entry point: 0x%X\n", spl_image->entry_point);
+ image_entry();
+}
+#endif /* ifdef CONFIG_SPL_FRAMEWORK */
#endif /* ifdef CONFIG_SPL_BUILD */
--
1.8.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] SECURE_BOOT: Enable SD as a source for bootscript
Add support for reading bootscript and bootscript header from SD. Also renamed macros *_FLASH to *_DEVICE to represent SD alongwith NAND and NOR flash. Reviewed-by: Aneesh Bansal Signed-off-by: Sumit Garg --- arch/arm/include/asm/fsl_secure_boot.h | 43 -- arch/powerpc/include/asm/fsl_secure_boot.h | 4 +-- include/config_fsl_chain_trust.h | 18 - 3 files changed, 42 insertions(+), 23 deletions(-) diff --git a/arch/arm/include/asm/fsl_secure_boot.h b/arch/arm/include/asm/fsl_secure_boot.h index 3f76c9a..b35c271 100644 --- a/arch/arm/include/asm/fsl_secure_boot.h +++ b/arch/arm/include/asm/fsl_secure_boot.h @@ -78,37 +78,52 @@ "setenv hwconfig \'fsl_ddr:ctlr_intlv=null,bank_intlv=null\';" #else #define CONFIG_EXTRA_ENV \ - "setenv fdt_high 0xcfff;" \ - "setenv initrd_high 0xcfff;"\ + "setenv fdt_high 0x;" \ + "setenv initrd_high 0x;"\ "setenv hwconfig \'fsl_ddr:ctlr_intlv=null,bank_intlv=null\';" #endif /* Copying Bootscript and Header to DDR from NOR for LS2 and for rest, from * Non-XIP Memory (Nand/SD)*/ -#if defined(CONFIG_SYS_RAMBOOT) || defined(CONFIG_LS2080A) +#if defined(CONFIG_SYS_RAMBOOT) || defined(CONFIG_LS2080A) || \ + defined(CONFIG_SD_BOOT) #define CONFIG_BOOTSCRIPT_COPY_RAM #endif -/* The address needs to be modified according to NOR and DDR memory map */ +/* The address needs to be modified according to NOR, NAND, SD and + * DDR memory map + */ #ifdef CONFIG_LS2080A -#define CONFIG_BS_HDR_ADDR_FLASH 0x58392 -#define CONFIG_BS_ADDR_FLASH 0x58390 +#define CONFIG_BS_HDR_ADDR_DEVICE 0x58392 +#define CONFIG_BS_ADDR_DEVICE 0x58390 #define CONFIG_BS_HDR_ADDR_RAM 0xa392 #define CONFIG_BS_ADDR_RAM 0xa390 +#define CONFIG_BS_HDR_SIZE 0x2000 +#define CONFIG_BS_SIZE 0x1000 +#else +#ifdef CONFIG_SD_BOOT +/* For SD boot address and size are assigned in terms of sector + * offset and no. of sectors respectively. + */ +#define CONFIG_BS_HDR_ADDR_DEVICE 0x0800 +#define CONFIG_BS_ADDR_DEVICE 0x0840 +#define CONFIG_BS_HDR_SIZE 0x0010 +#define CONFIG_BS_SIZE 0x0008 #else -#define CONFIG_BS_HDR_ADDR_FLASH 0x600a -#define CONFIG_BS_ADDR_FLASH 0x6006 -#define CONFIG_BS_HDR_ADDR_RAM 0xa006 -#define CONFIG_BS_ADDR_RAM 0xa006 +#define CONFIG_BS_HDR_ADDR_DEVICE 0x600a +#define CONFIG_BS_ADDR_DEVICE 0x6006 +#define CONFIG_BS_HDR_SIZE 0x2000 +#define CONFIG_BS_SIZE 0x1000 +#endif /* #ifdef CONFIG_SD_BOOT */ +#define CONFIG_BS_HDR_ADDR_RAM 0x8100 +#define CONFIG_BS_ADDR_RAM 0x8102 #endif #ifdef CONFIG_BOOTSCRIPT_COPY_RAM #define CONFIG_BOOTSCRIPT_HDR_ADDR CONFIG_BS_HDR_ADDR_RAM -#define CONFIG_BS_HDR_SIZE 0x2000 #define CONFIG_BOOTSCRIPT_ADDR CONFIG_BS_ADDR_RAM -#define CONFIG_BS_SIZE 0x1000 #else -#define CONFIG_BOOTSCRIPT_HDR_ADDR CONFIG_BS_HDR_ADDR_FLASH -/* BS_HDR_SIZE, BOOTSCRIPT_ADDR and BS_SIZE are not required */ +#define CONFIG_BOOTSCRIPT_HDR_ADDR CONFIG_BS_HDR_ADDR_DEVICE +/* BOOTSCRIPT_ADDR is not required */ #endif #include diff --git a/arch/powerpc/include/asm/fsl_secure_boot.h b/arch/powerpc/include/asm/fsl_secure_boot.h index 2435cf8..7c39bdd 100644 --- a/arch/powerpc/include/asm/fsl_secure_boot.h +++ b/arch/powerpc/include/asm/fsl_secure_boot.h @@ -127,10 +127,10 @@ /* If Boot Script is not on NOR and is required to be copied on RAM */ #ifdef CONFIG_BOOTSCRIPT_COPY_RAM #define CONFIG_BS_HDR_ADDR_RAM 0x0001 -#define CONFIG_BS_HDR_ADDR_FLASH 0x0080 +#define CONFIG_BS_HDR_ADDR_DEVICE 0x0080 #define CONFIG_BS_HDR_SIZE 0x2000 #define CONFIG_BS_ADDR_RAM 0x00012000 -#define CONFIG_BS_ADDR_FLASH 0x00802000 +#define CONFIG_BS_ADDR_DEVICE 0x00802000 #define CONFIG_BS_SIZE 0x1000 #define CONFIG_BOOTSCRIPT_HDR_ADDR CONFIG_BS_HDR_ADDR_RAM diff --git a/include/config_fsl_chain_trust.h b/include/config_fsl_chain_trust.h index 566fd80..eb45e98 100644 --- a/include/config_fsl_chain_trust.h +++ b/include/config_fsl_chain_trust.h @@ -74,23 +74,27 @@ #ifdef CONFIG_BOOTSCRIPT_COPY_RAM #define CONFIG_BS_COPY_ENV \ "setenv bs_hdr_ram " __stringify(CONFIG_BS_HDR_ADDR_RAM)";" \ - "setenv bs_hdr_flash " __stringify(CONFIG_BS_HDR_ADDR_FLASH)";" \ + "setenv bs_hdr_device " __stringify(CONFIG_BS_HDR_ADDR_DEVICE)";" \ "setenv bs_hdr_size " __stringify(CONFIG_BS_HDR_SIZE)";" \ "setenv bs_ram " __stringify(CONFIG_BS_ADDR_RAM)";" \ - "setenv bs_flash " __stringify(CONFIG_BS_ADDR_FLASH)";" \ + "setenv bs_device " __stringify(CONFIG_BS_ADDR_DEVICE)";" \
[U-Boot] [PATCH 4/4] arm: ls1021atwr: Add SD secure boot target
Add SD secure boot target for ls1021atwr.
Implement board specific spl_board_init() to setup CAAM stream ID and
corresponding stream ID in SMMU. Change the u-boot size defined by a
macro for copying the main U-Boot by SPL to also include the u-boot
Secure Boot header size as header is appended to u-boot image. So header
will also be copied from SD to DDR.
Reviewed-by: Aneesh Bansal
Signed-off-by: Sumit Garg
---
board/freescale/ls1021atwr/ls1021atwr.c| 7 +
.../ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig| 31 ++
include/configs/ls1021atwr.h | 22 +++
3 files changed, 60 insertions(+)
create mode 100644 configs/ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig
diff --git a/board/freescale/ls1021atwr/ls1021atwr.c
b/board/freescale/ls1021atwr/ls1021atwr.c
index c69c9cb..77482a9 100644
--- a/board/freescale/ls1021atwr/ls1021atwr.c
+++ b/board/freescale/ls1021atwr/ls1021atwr.c
@@ -503,6 +503,13 @@ int board_init(void)
return 0;
}
+#if defined(CONFIG_SPL_BUILD)
+void spl_board_init(void)
+{
+ ls102xa_smmu_stream_id_init();
+}
+#endif
+
#ifdef CONFIG_BOARD_LATE_INIT
int board_late_init(void)
{
diff --git a/configs/ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig
b/configs/ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig
new file mode 100644
index 000..c735d6d
--- /dev/null
+++ b/configs/ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig
@@ -0,0 +1,31 @@
+CONFIG_ARM=y
+CONFIG_TARGET_LS1021ATWR=y
+CONFIG_SPL=y
+CONFIG_OF_BOARD_SETUP=y
+CONFIG_OF_STDOUT_VIA_ALIAS=y
+CONFIG_SYS_EXTRA_OPTIONS="RAMBOOT_PBL,SPL_FSL_PBL,SD_BOOT,SECURE_BOOT"
+CONFIG_BOOTDELAY=0
+CONFIG_HUSH_PARSER=y
+CONFIG_CMD_BOOTZ=y
+CONFIG_CMD_GREPENV=y
+CONFIG_CMD_MEMTEST=y
+CONFIG_CMD_MEMINFO=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_EXT2=y
+CONFIG_CMD_FAT=y
+CONFIG_NETDEVICES=y
+CONFIG_E1000=y
+CONFIG_SYS_NS16550=y
+CONFIG_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_OF_LIBFDT=y
+CONFIG_FIT=y
+CONFIG_FIT_VERBOSE=y
+CONFIG_RSA=y
+CONFIG_DM=y
diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h
index 0fb28ef..7f14851 100644
--- a/include/configs/ls1021atwr.h
+++ b/include/configs/ls1021atwr.h
@@ -123,7 +123,18 @@
#define CONFIG_SPL_SERIAL_SUPPORT
#define CONFIG_SPL_MMC_SUPPORT
#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR0xe8
+
+#ifdef CONFIG_SECURE_BOOT
+#define CONFIG_U_BOOT_HDR_SIZE (16 << 10)
+/*
+ * HDR would be appended at end of image and copied to DDR along
+ * with U-Boot image.
+ */
+#define CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS (0x400 + \
+ (CONFIG_U_BOOT_HDR_SIZE / 512)
+#else
#define CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS 0x400
+#endif /* ifdef CONFIG_SECURE_BOOT */
#define CONFIG_SPL_TEXT_BASE 0x1000
#define CONFIG_SPL_MAX_SIZE0x1a000
@@ -136,7 +147,18 @@
#define CONFIG_SYS_SPL_MALLOC_SIZE 0x10
#define CONFIG_SPL_BSS_START_ADDR 0x8010
#define CONFIG_SPL_BSS_MAX_SIZE0x8
+
+#ifdef CONFIG_U_BOOT_HDR_SIZE
+/*
+ * HDR would be appended at end of image and copied to DDR along
+ * with U-Boot image. Here u-boot max. size is 512K. So if binary
+ * size increases then increase this size in case of secure boot as
+ * it uses raw u-boot image instead of fit image.
+ */
+#define CONFIG_SYS_MONITOR_LEN (0x8 + CONFIG_U_BOOT_HDR_SIZE)
+#else
#define CONFIG_SYS_MONITOR_LEN 0x8
+#endif /* ifdef CONFIG_U_BOOT_HDR_SIZE */
#endif
#ifdef CONFIG_QSPI_BOOT
--
1.8.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/4] Add SECURE BOOT support in SPL framework
The patch-set does the following : 1. Enable chain of trust in SPL framework for ARM based platforms. 3. Add SD secure boot target for ls1021atwr platform. Sumit Garg (4): DM: crypto/fsl: Enable rsa DM driver usage before relocation SECURE_BOOT: Enable chain of trust in SPL framework SECURE_BOOT: Enable SD as a source for bootscript arm: ls1021atwr: Add SD secure boot target arch/arm/include/asm/fsl_secure_boot.h | 68 +- arch/powerpc/include/asm/fsl_secure_boot.h | 4 +- board/freescale/common/fsl_chain_of_trust.c| 34 ++- board/freescale/ls1021atwr/ls1021atwr.c| 7 +++ .../ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig| 31 ++ drivers/crypto/fsl/fsl_rsa.c | 1 + include/config_fsl_chain_trust.h | 18 +++--- include/configs/ls1021atwr.h | 22 +++ 8 files changed, 159 insertions(+), 26 deletions(-) create mode 100644 configs/ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig -- 1.8.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] U-boot VESA driver Unsupported software interrupt #0x15
Hello Mr.Bin, In the latest U-boot-x86 version I am seeing some error messages when I enable the debug messages in the bios.c file. I am checking the VESA driver initialization and it seems that for a particular functional call it takes more time to process. realmode_call(addr + 0x0003, num_dev, 0x, 0x, 0x, 0x0, 0x0); -- it takes around 2 seconds. Do you have any idea how to optimize this function call or why it is taking that much time. I tried to enable the debug messages to understand what is happening and found that there are some software interrupts that are not supported [0.325805 0.002018] Real mode stub @600: 919 bytes [0.328829 0.003024] Calling Option ROM at c, pci device 0x10... [1.850796 1.521967] Unsupported software interrupt #0x15 eax 0x90005f14 [1.877799 0.027003] Unsupported software interrupt #0x15 eax 0x5f35 [1.977798 0.09] done [1.978944 0.001146] VBE: Getting information about VESA mode 411a How can I disable this software interrupts ? Mit Freundlichen Grüßen VinothKumar +49 1798909072 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] x86: acpi: Disabling SoC functions defined in ASL on a per board basis
On Mon, Jun 13, 2016 at 8:45 PM, Bin Meng wrote:
> Hi George,
>
> On Tue, Jun 14, 2016 at 12:12 AM, George McCollister
> wrote:
>> On Fri, Jun 10, 2016 at 7:25 PM, Bin Meng wrote:
>>> Hi George,
>>>
>>> +Simon, Stefan
>>>
>>> On Fri, Jun 10, 2016 at 1:17 AM, George McCollister
>>> wrote:
Does anyone have any ideas on how we might go about disabling
functions defined in arch/x86/include/asm/arch-*/acpi on a per board
basis? With DT it's trivial to define all of the functions available
on an SoC and default them to disabled in the .dtsi, then simply mark
them as enabled in the board .dts if the board uses them. I need to
disable the internal UART definition for the baytrail board I'm adding
since if it's included the off chip UART gets killed when Linux does
it's acpi_bus_scan.
>>>
>>> Which board are you using? Looks you are using a board that is similar
>>> to conga-qeval20-qa3-e3845.
>> I'm using an Advantech SOM-DB5800 carrier board with an SOM-6867 Com
>> Express board installed. I have a patch almost ready to add it to
>> u-boot. I'll need to make some changes to reflect recent patches and
>> was hoping to get this issue and azalia configuration resolved as
>> well. I could upstream it sooner but the UART will be broken in linux
>> (unless hacked out of dsdt prior to build) and HD audio wouldn't work.
>>
>
> Great, that means we will have another baytrail board support :)
>
>>>
>>> See the TODO comments in arch/x86/include/asm/arch-baytrail/acpi/lpc.asl.
>>>
>>> /* Internal UART */
>>> Device (IURT)
>>> {
>>> Name(_HID, EISAID("PNP0501"))
>>> Name(_UID, 1)
>>>
>>> Method(_STA, 0, Serialized)
>>> {
>>> /*
>>> * TODO:
>>> *
>>> * Need to hide the internal UART depending on whether
>>> * internal UART is enabled or not so that external
>>> * SuperIO UART can be exposed to system.
>>> */
>>> Store(1, UI3E)
>>> Store(1, UI4E)
>>> Store(1, C1EN)
>>> Return (STA_VISIBLE)
>>> }
>>>
>>> To solve this, we need introduce a variable that is set at runtime by
>>> U-Boot to tell the ASL codes to hide the internal UART. This is
>>> documented in README.x86 below as optional features, but I also
>>> mentioned we will need this sooner or later.
>> Okay, I see how this is handled in coreboot. Looks like global_nvs_t
>> for fsp_baytrail in coreboot has over 20 parameters I suppose I'd just
>> start with one and it would be expanded as needed. I need to
>> investigate more about gnvs then maybe I can implement it, time
>> permitting.
>>
>
> That's actually on my todo list. I will see if I can implement this
> soon while leaving you to focus on HD audio.
Sounds great!
>
>>>
>>> Features that are optional:
>>> * ACPI global NVS support. We may need it to simplify ASL code logic if
>>>utilizing NVS variables. Most likely we will need this sooner or later.
>>>
>>> Another place that will need such feature is the memory size. We need
>>> tell ASL code to dynamically create the PCI memory space.
>
> Regards,
> Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] powerpc/85xx: usb: Limit controllers initialized by usb_init()
On 06/14/2016 07:40 AM, Matthew Bright wrote: > Hi, Hi, > I am looking for a way to limit which usb host interfaces are initiali- > zed by usb_init() in order to skip unused interfaces. This is currently > governed CONFIG_USB_MAX_CONTROLLER_COUNT, which is possible to redefine > at the board level. However this doesn't cover more complex cases where > a SoC has multiple host interfaces but a board using that SoC only uses > a subset that is not necessarily contiguous. > > Does there currently exist a way to define such behavior, or should the > functionality be added to usb_init() to support this? The driver model should allow you to do exactly that, though I don't know if it's supposed on the MPC85xx . > Thanks. > Matthew Bright > > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 2/2] common: usb_storage : Implement logic to calculate optimal usb maximum trasfer blocks
On 06/14/2016 05:41 AM, Rajesh Bhagat wrote:
>
>
>> -Original Message-
>> From: Marek Vasut [mailto:ma...@denx.de]
>> Sent: Monday, June 13, 2016 7:07 PM
>> To: Rajesh Bhagat ; u-boot@lists.denx.de
>> Cc: s...@chromium.org; york sun ; Sriram Dash
>> ; Rajesh Bhagat
>> Subject: Re: [PATCH v5 2/2] common: usb_storage : Implement logic to
>> calculate
>> optimal usb maximum trasfer blocks
>>
>> On 06/13/2016 06:03 AM, Rajesh Bhagat wrote:
>>> From: Rajesh Bhagat
>>>
>>> Implements the logic to calculate the optimal usb maximum trasfer
>>> blocks instead of sending USB_MAX_XFER_BLK blocks which is 65535 and
>>> 20 in case of EHCI and other USB protocols respectively.
>>>
>>> It defines USB_MIN_XFER_BLK/USB_MAX_XFER_BLK trasfer blocks that
>>> should be checked for success starting from minimum to maximum, and
>>> rest of the read/write are performed with that optimal value. It tries
>>> to increase/ decrease the blocks in follwing scenarios:
>>>
>>> 1.decrease blocks: when read/write for a particular number of blocks
>>> fails.
>>> 2. increase blocks: when read/write for a particular number of blocks
>>> pass and amount left to trasfer is greater than current number of
>>> blocks.
>>>
>>> Currently changes are done for EHCI where min = 4096 and max = 65535
>>> is taken. And for other cases code is left unchanged by keeping min =
>>> max = 20.
>>>
>>> Signed-off-by: Sriram Dash
>>> Signed-off-by: Rajesh Bhagat
>>> ---
>>> Changes in v5:
>>> - None
>>>
>>> Changes in v4:
>>> - Adds udev paramater in dec/inc_cur_xfer_blks function and adds
>>>sanity check on it.
>>> - Changes type of pos varible to unsigned int in
>>> dec/inc_cur_xfer_blks
>>> - Removes usage of pos varible from usb_stor_read/write
>>>
>>> Changes in v3:
>>> - Adds cur_xfer_blks in struct usb_device to retain values
>>> - Adds functions dec/inc_cur_xfer_blks to remove code duplication
>>> - Moves check from macro to calling functions
>>>
>>> Changes in v2:
>>> - Removes table to store blocks and use formula (1 << (12 + n)) - 1
>>> - Adds logic to start from minimum, go to maximum in each read/write
>>>
>>> common/usb_storage.c | 67
>> ++---
>>> include/usb.h|1 +
>>> 2 files changed, 63 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/common/usb_storage.c b/common/usb_storage.c index
>>> f060637..9b09412 100644
>>> --- a/common/usb_storage.c
>>> +++ b/common/usb_storage.c
>>> @@ -106,11 +106,16 @@ struct us_data {
>>> * enough free heap space left, but the SCSI READ(10) and WRITE(10)
>>> commands
>> are
>>> * limited to 65535 blocks.
>>> */
>>> +#define USB_MIN_XFER_BLK 4095
>>> #define USB_MAX_XFER_BLK 65535
>>> #else
>>> +#define USB_MIN_XFER_BLK 20
>>> #define USB_MAX_XFER_BLK 20
>>> #endif
>>>
>>> +#define GET_CUR_XFER_BLKS(blks)(LOG2((blks + 1) /
>> (USB_MIN_XFER_BLK + 1)))
>>> +#define CALC_CUR_XFER_BLKS(pos)((1 << (12 + pos)) - 1)
>
> Hello Marek,
>
>>
>> Parenthesis around variables are missing.
>>
>
> Will take care in v6.
>
>>> #ifndef CONFIG_BLK
>>> static struct us_data usb_stor[USB_MAX_STOR_DEV]; #endif @@ -141,6
>>> +146,44 @@ static void usb_show_progress(void)
>>> debug(".");
>>> }
>>>
>>> +static int dec_cur_xfer_blks(struct usb_device *udev) {
>>> + /* decrease the cur_xfer_blks */
>>> + unsigned int pos;
>>> + unsigned short size;
>>> +
>>> + if (!udev)
>>> + return -EINVAL;
>>> +
>>> + pos = GET_CUR_XFER_BLKS(udev->cur_xfer_blks);
>>> + size = pos ? CALC_CUR_XFER_BLKS(pos - 1) : 0;
>>
>> If pos == 0 , the condition below will be true (size will be 2047), so this
>> extra ternary
>> is unnecessary.
>>
>
> Will take care in v6. Will remove the extra ternary operator used, as 2047
> will follow the
> below check (size < USB_MIN_XFER_BLK) and code will work fine.
>
>>> + if (size < USB_MIN_XFER_BLK)
>>> + return -EINVAL;
>>> +
>>> + udev->cur_xfer_blks = size;
>>> + return 0;
>>> +}
>>> +
>>> +static int inc_cur_xfer_blks(struct usb_device *udev, lbaint_t blks)
>>> +{
>>> + /* try to increase the cur_xfer_blks */
>>> + unsigned int pos;
>>> + unsigned short size;
>>> +
>>> + if (!udev)
>>> + return -EINVAL;
>>> +
>>> + pos = GET_CUR_XFER_BLKS(udev->cur_xfer_blks);
>>> + size = CALC_CUR_XFER_BLKS(pos + 1);
>>> +
>>> + if (size > blks || size > USB_MAX_XFER_BLK)
>>> + return -EINVAL;
>>
>> Why don't you clamp the size to min(blks, USB_MAX_XFER_BLK) instead ?
>>
>
> Do you mean below statement?
>
> if (size > min(blks, USB_MAX_XFER_BLK))
> return -EINVAL;
Yes, if that makes sense.
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 2/2] common: usb_storage : Implement logic to calculate optimal usb maximum trasfer blocks
> -Original Message-
> From: Marek Vasut [mailto:ma...@denx.de]
> Sent: Tuesday, June 14, 2016 5:41 PM
> To: Rajesh Bhagat ; u-boot@lists.denx.de
> Cc: s...@chromium.org; york sun ; Sriram Dash
> ; Rajesh Bhagat
> Subject: Re: [PATCH v5 2/2] common: usb_storage : Implement logic to calculate
> optimal usb maximum trasfer blocks
>
> On 06/14/2016 05:41 AM, Rajesh Bhagat wrote:
> >
> >
> >> -Original Message-
> >> From: Marek Vasut [mailto:ma...@denx.de]
> >> Sent: Monday, June 13, 2016 7:07 PM
> >> To: Rajesh Bhagat ; u-boot@lists.denx.de
> >> Cc: s...@chromium.org; york sun ; Sriram Dash
> >> ; Rajesh Bhagat
> >> Subject: Re: [PATCH v5 2/2] common: usb_storage : Implement logic to
> >> calculate optimal usb maximum trasfer blocks
> >>
> >> On 06/13/2016 06:03 AM, Rajesh Bhagat wrote:
> >>> From: Rajesh Bhagat
> >>>
> >>> Implements the logic to calculate the optimal usb maximum trasfer
> >>> blocks instead of sending USB_MAX_XFER_BLK blocks which is 65535 and
> >>> 20 in case of EHCI and other USB protocols respectively.
> >>>
> >>> It defines USB_MIN_XFER_BLK/USB_MAX_XFER_BLK trasfer blocks that
> >>> should be checked for success starting from minimum to maximum, and
> >>> rest of the read/write are performed with that optimal value. It
> >>> tries to increase/ decrease the blocks in follwing scenarios:
> >>>
> >>> 1.decrease blocks: when read/write for a particular number of blocks
> >>> fails.
> >>> 2. increase blocks: when read/write for a particular number of
> >>> blocks pass and amount left to trasfer is greater than current
> >>> number of blocks.
> >>>
> >>> Currently changes are done for EHCI where min = 4096 and max = 65535
> >>> is taken. And for other cases code is left unchanged by keeping min
> >>> = max = 20.
> >>>
> >>> Signed-off-by: Sriram Dash
> >>> Signed-off-by: Rajesh Bhagat
> >>> ---
> >>> Changes in v5:
> >>> - None
> >>>
> >>> Changes in v4:
> >>> - Adds udev paramater in dec/inc_cur_xfer_blks function and adds
> >>>sanity check on it.
> >>> - Changes type of pos varible to unsigned int in
> >>> dec/inc_cur_xfer_blks
> >>> - Removes usage of pos varible from usb_stor_read/write
> >>>
> >>> Changes in v3:
> >>> - Adds cur_xfer_blks in struct usb_device to retain values
> >>> - Adds functions dec/inc_cur_xfer_blks to remove code duplication
> >>> - Moves check from macro to calling functions
> >>>
> >>> Changes in v2:
> >>> - Removes table to store blocks and use formula (1 << (12 + n)) - 1
> >>> - Adds logic to start from minimum, go to maximum in each
> >>> read/write
> >>>
> >>> common/usb_storage.c | 67
> >> ++---
> >>> include/usb.h|1 +
> >>> 2 files changed, 63 insertions(+), 5 deletions(-)
> >>>
> >>> diff --git a/common/usb_storage.c b/common/usb_storage.c index
> >>> f060637..9b09412 100644
> >>> --- a/common/usb_storage.c
> >>> +++ b/common/usb_storage.c
> >>> @@ -106,11 +106,16 @@ struct us_data {
> >>> * enough free heap space left, but the SCSI READ(10) and WRITE(10)
> >>> commands
> >> are
> >>> * limited to 65535 blocks.
> >>> */
> >>> +#define USB_MIN_XFER_BLK 4095
> >>> #define USB_MAX_XFER_BLK 65535
> >>> #else
> >>> +#define USB_MIN_XFER_BLK 20
> >>> #define USB_MAX_XFER_BLK 20
> >>> #endif
> >>>
> >>> +#define GET_CUR_XFER_BLKS(blks) (LOG2((blks + 1) /
> >> (USB_MIN_XFER_BLK + 1)))
> >>> +#define CALC_CUR_XFER_BLKS(pos) ((1 << (12 + pos)) - 1)
> >
> > Hello Marek,
> >
> >>
> >> Parenthesis around variables are missing.
> >>
> >
> > Will take care in v6.
> >
> >>> #ifndef CONFIG_BLK
> >>> static struct us_data usb_stor[USB_MAX_STOR_DEV]; #endif @@ -141,6
> >>> +146,44 @@ static void usb_show_progress(void)
> >>> debug(".");
> >>> }
> >>>
> >>> +static int dec_cur_xfer_blks(struct usb_device *udev) {
> >>> + /* decrease the cur_xfer_blks */
> >>> + unsigned int pos;
> >>> + unsigned short size;
> >>> +
> >>> + if (!udev)
> >>> + return -EINVAL;
> >>> +
> >>> + pos = GET_CUR_XFER_BLKS(udev->cur_xfer_blks);
> >>> + size = pos ? CALC_CUR_XFER_BLKS(pos - 1) : 0;
> >>
> >> If pos == 0 , the condition below will be true (size will be 2047),
> >> so this extra ternary is unnecessary.
> >>
> >
> > Will take care in v6. Will remove the extra ternary operator used, as
> > 2047 will follow the below check (size < USB_MIN_XFER_BLK) and code will
> > work
> fine.
> >
> >>> + if (size < USB_MIN_XFER_BLK)
> >>> + return -EINVAL;
> >>> +
> >>> + udev->cur_xfer_blks = size;
> >>> + return 0;
> >>> +}
> >>> +
> >>> +static int inc_cur_xfer_blks(struct usb_device *udev, lbaint_t
> >>> +blks) {
> >>> + /* try to increase the cur_xfer_blks */
> >>> + unsigned int pos;
> >>> + unsigned short size;
> >>> +
> >>> + if (!udev)
> >>> + return -EINVAL;
> >>> +
> >>> + pos = GET_CUR_XFER_BLKS(udev->cur_xfer_blks);
> >>> + size = CALC_CUR_XFER_BLKS(pos + 1);
> >>> +
> >>> + if (size > blks || size > USB_MAX_XFER_BLK)
> >>> + return -EINVAL;
> >>
Re: [U-Boot] U-boot VESA driver Unsupported software interrupt #0x15
On Tue, Jun 14, 2016 at 8:41 PM, vinoth eswaran wrote: > Hello Mr.Bin, > > In the latest U-boot-x86 version I am seeing some error messages when > I enable the debug messages in the bios.c file. > > I am checking the VESA driver initialization and it seems that for a > particular functional call it takes more time to process. > realmode_call(addr + 0x0003, num_dev, 0x, 0x, 0x, 0x0, > 0x0); -- it takes around 2 seconds. Do you have any idea how to > optimize this function call or why it is taking that much time. > This is 16-bit BIOS call. It is expected that it is slow. > I tried to enable the debug messages to understand what is happening > and found that there are some software interrupts that are not > supported > > [0.325805 0.002018] Real mode stub @600: 919 bytes > [0.328829 0.003024] Calling Option ROM at c, pci device 0x10... > [1.850796 1.521967] Unsupported software interrupt #0x15 eax 0x90005f14 > [1.877799 0.027003] Unsupported software interrupt #0x15 eax 0x5f35 > [1.977798 0.09] done > [1.978944 0.001146] VBE: Getting information about VESA mode 411a > > How can I disable this software interrupts ? > INT15 is Intel's custom vgabios call. This can be ignored, since it is working. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] common/Kconfig: Change the default BOOTDELAY to 2
The value of 0 is fairly uncommon while 2 is one of the more common ones so switch. Signed-off-by: Tom Rini --- common/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common/Kconfig b/common/Kconfig index 4d17b10..e691145 100644 --- a/common/Kconfig +++ b/common/Kconfig @@ -99,7 +99,7 @@ endmenu config BOOTDELAY int "delay in seconds before automatically booting" - default 0 + default 2 help Delay before automatically running bootcmd; set to -1 to disable autoboot. -- 2.8.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-x86 sf probe fail
Hi Hilbert, On 2 June 2016 at 19:40, Bin Meng wrote: > Hi Hilbert, > > On Thu, Jun 2, 2016 at 11:46 AM, Hilbert Tu(杜睿哲_Pegatron) > wrote: >> Hi Bin, >> >> Sorry for the late. >> >> I have checked with Intel's support and following is their response: >> On the other hand, for the question about ICH7 or ICH9. Unfortunately, the Bios Writers Guides (BWGs) or the EDS is unstated any information about ICH9. But, reviewing in section 22.4.1 on page 498 of the EDS specifies that the non-descriptor mode is the same as ICH7 mode. However, the non-descriptor mode is not supported and a valid Flash Descriptor is required for this SoC. >> >> So I think the current u-boot cannot support SPI access under Atom C2000 >> with Intel FSP. I am still working on how to read the related registers in >> u-boot since I am not sure the default SPI base address (0x1fff) is >> correct or not. If you know that, please advise. Thanks. > > I am confused, You said you were booting U-Boot from coreboot, so > U-Boot itself does not use Intel FSP. But here you mentioned Intel > FSP? > > The SPI base address 0x1 does not look correct. That's probably > the failure of SPI flash probe. You started another thread, but can we continue the discussion here? It sounds like you are using coreboot with an FSP. So U-Boot should be able to access SPI flash. I suggest you dig into the SPI driver in coreboot, and see if the SPI base address is the same. I agree with Bin that 1 sounds wrong. See the call to pch_get_spi_base() in the U-Boot SPI driver. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] configs: Re-sync BOOTDELAY changes
With updated moveconfig.py and an better default, re-generate the migration of BOOTDELAY to the defconfig. Signed-off-by: Tom Rini --- configs/A10-OLinuXino-Lime_defconfig | 1 + configs/A20-OLinuXino_MICRO_defconfig| 2 +- configs/A20-Olimex-SOM-EVB_defconfig | 2 +- configs/C29XPCIE_NAND_defconfig | 1 + configs/C29XPCIE_NOR_SECBOOT_defconfig | 1 + configs/C29XPCIE_SPIFLASH_SECBOOT_defconfig | 1 + configs/C29XPCIE_SPIFLASH_defconfig | 1 + configs/C29XPCIE_defconfig | 1 + configs/CHIP_defconfig | 2 +- configs/Chuwi_V7_CW0825_defconfig| 1 + configs/Cubieboard_defconfig | 1 + configs/Cubietruck_plus_defconfig| 1 + configs/Hyundai_A7HD_defconfig | 1 + configs/Linksprite_pcDuino_defconfig | 1 + configs/M5208EVBE_defconfig | 1 + configs/M5235EVB_Flash32_defconfig | 1 + configs/M5235EVB_defconfig | 1 + configs/M53017EVB_defconfig | 1 + configs/M5329AFEE_defconfig | 1 + configs/M5329BFEE_defconfig | 1 + configs/M5373EVB_defconfig | 1 + configs/M54451EVB_defconfig | 1 + configs/M54451EVB_stmicro_defconfig | 1 + configs/M54455EVB_a66_defconfig | 1 + configs/M54455EVB_defconfig | 1 + configs/M54455EVB_i66_defconfig | 1 + configs/M54455EVB_intel_defconfig| 1 + configs/M54455EVB_stm33_defconfig| 1 + configs/M5475AFE_defconfig | 1 + configs/M5475BFE_defconfig | 1 + configs/M5475CFE_defconfig | 1 + configs/M5475DFE_defconfig | 1 + configs/M5475EFE_defconfig | 1 + configs/M5475FFE_defconfig | 1 + configs/M5475GFE_defconfig | 1 + configs/M5485AFE_defconfig | 1 + configs/M5485BFE_defconfig | 1 + configs/M5485CFE_defconfig | 1 + configs/M5485DFE_defconfig | 1 + configs/M5485EFE_defconfig | 1 + configs/M5485FFE_defconfig | 1 + configs/M5485GFE_defconfig | 1 + configs/M5485HFE_defconfig | 1 + configs/Marsboard_A10_defconfig | 1 + configs/Mele_A1000_defconfig | 1 + configs/Merrii_A80_Optimus_defconfig | 1 + configs/Mini-X_defconfig | 1 + configs/P1023RDB_defconfig | 1 + configs/am335x_evm_defconfig | 8 +--- configs/am335x_evm_nor_defconfig | 1 + configs/am335x_evm_norboot_defconfig | 1 + configs/am335x_evm_spiboot_defconfig | 1 + configs/am335x_evm_usbspl_defconfig | 1 + configs/am335x_shc_defconfig | 1 - configs/am335x_shc_ict_defconfig | 1 - configs/am335x_shc_netboot_defconfig | 1 - configs/am335x_shc_prompt_defconfig | 1 - configs/am335x_shc_sdboot_defconfig | 1 - configs/am335x_shc_sdboot_prompt_defconfig | 1 - configs/am437x_hs_evm_defconfig | 3 ++- configs/am43xx_evm_ethboot_defconfig | 1 + configs/am43xx_evm_qspiboot_defconfig| 1 + configs/am43xx_evm_usbhost_boot_defconfig| 10 ++ configs/am57xx_evm_defconfig | 2 +- configs/am57xx_hs_evm_defconfig | 2 +- configs/amcore_defconfig | 1 + configs/apalis_t30_defconfig | 1 + configs/apx4devkit_defconfig | 1 + configs/aristainetos2_defconfig | 1 + configs/aristainetos2b_defconfig | 1 + configs/aristainetos_defconfig | 1 + configs/astro_mcf5373l_defconfig | 1 + configs/atngw100_defconfig | 1 + configs/atngw100mkii_defconfig | 1 + configs/atstk1002_defconfig | 1 + configs/ba10_tv_box_defconfig| 1 + configs/bct-brettl2_defconfig| 1 + configs/beaver_defconfig | 1 + configs/bf518f-ezbrd_defconfig | 1 + configs/bf526-ezbrd
[U-Boot] [PATCH] nand: doc: fix example ecc scheme calculation
Signed-off-by: Fabian Mewes --- doc/README.nand | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/README.nand b/doc/README.nand index 96ffc48..9aa6cc4 100644 --- a/doc/README.nand +++ b/doc/README.nand @@ -271,7 +271,7 @@ Platform specific options However, for 4K pagesize NAND NAND_PAGESIZE = 4096 - NAND_OOBSIZE = 64 + NAND_OOBSIZE = 224 ECC_BYTES = 26 2 + (4096 / 512) * 26 = 210 < NAND_OOBSIZE Thus BCH16 can be supported on 4K page NAND. -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/3] Series short description
The following series fixes som issues in the STM32 gpio driver --- Benjamin Tietz (3): stm32: gpio: fix otype access stm32: gpio_direction_output: make sure, output is set to push-pull stm32: gpio_get_value: always return 0 or 1 drivers/gpio/stm32_gpio.c |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) -- best regards Benjamin Tietz ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH2/3] stm32: gpio_direction_output: make sure, output is set to push-pull
otherwise, the output type is uninitialized --- drivers/gpio/stm32_gpio.c |1 + 1 file changed, 1 insertion(+) otherwise, the output type is uninitialized --- drivers/gpio/stm32_gpio.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpio/stm32_gpio.c b/drivers/gpio/stm32_gpio.c index 2457211..d092c8f 100644 --- a/drivers/gpio/stm32_gpio.c +++ b/drivers/gpio/stm32_gpio.c @@ -236,6 +236,7 @@ int gpio_direction_output(unsigned gpio, int value) #if defined(CONFIG_STM32F4) || defined(CONFIG_STM32F7) ctl.af = STM32_GPIO_AF0; ctl.mode = STM32_GPIO_MODE_OUT; + ctl.otype = STM32_GPIO_OTYPE_PP; ctl.pupd = STM32_GPIO_PUPD_NO; ctl.speed = STM32_GPIO_SPEED_50M; #elif defined(CONFIG_STM32F1) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH1/3] stm32: gpio: fix otype access
the GPIOx_OTYPER register has only one bit for every pin. --- drivers/gpio/stm32_gpio.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) the GPIOx_OTYPER register has only one bit for every pin. --- drivers/gpio/stm32_gpio.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpio/stm32_gpio.c b/drivers/gpio/stm32_gpio.c index 50f86d3..2457211 100644 --- a/drivers/gpio/stm32_gpio.c +++ b/drivers/gpio/stm32_gpio.c @@ -66,7 +66,7 @@ int stm32_gpio_config(const struct stm32_gpio_dsc *dsc, i = dsc->pin * 2; clrsetbits_le32(&gpio_regs->moder, 0x3 << i, ctl->mode << i); - clrsetbits_le32(&gpio_regs->otyper, 0x3 << i, ctl->otype << i); + clrsetbits_le32(&gpio_regs->otyper, 0x1 << dsc->pin, ctl->otype << dsc->pin); clrsetbits_le32(&gpio_regs->ospeedr, 0x3 << i, ctl->speed << i); clrsetbits_le32(&gpio_regs->pupdr, 0x3 << i, ctl->pupd << i); ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH3/3] stm32: gpio_get_value: always return 0 or 1
Previously, a set gpio had returned any power of 2. Some function check for 1 explicitly. --- drivers/gpio/stm32_gpio.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Previously, a set gpio had returned any power of 2. Some function check for 1 explicitly. --- drivers/gpio/stm32_gpio.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpio/stm32_gpio.c b/drivers/gpio/stm32_gpio.c index d092c8f..516dfcc 100644 --- a/drivers/gpio/stm32_gpio.c +++ b/drivers/gpio/stm32_gpio.c @@ -263,7 +263,7 @@ int gpio_get_value(unsigned gpio) dsc.port = stm32_gpio_to_port(gpio); dsc.pin = stm32_gpio_to_pin(gpio); - return stm32_gpin_get(&dsc); + return !!stm32_gpin_get(&dsc); } int gpio_set_value(unsigned gpio, int value) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] armv8: dts: fsl: Remove cpu nodes from Layerscape DTSIs
Currently layescape SoCs are not using cpu nodes. So removing
them in favour of compatibly with similar SoCs that
have different cores like LS2080A and LS2088A.
This has been tested on LS2080AQDS, LS1043ARDB, LS1012ARDB.
Signed-off-by: Prabhakar Kushwaha
Signed-off-by: Abhimanyu Saini
---
arch/arm/dts/fsl-ls1012a.dtsi | 12 -
arch/arm/dts/fsl-ls1043a.dtsi | 32 ---
arch/arm/dts/fsl-ls2080a.dtsi | 61 ---
3 files changed, 105 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1012a.dtsi b/arch/arm/dts/fsl-ls1012a.dtsi
index 546a87a..024527e 100644
--- a/arch/arm/dts/fsl-ls1012a.dtsi
+++ b/arch/arm/dts/fsl-ls1012a.dtsi
@@ -9,18 +9,6 @@
/ {
compatible = "fsl,ls1012a";
interrupt-parent = <&gic>;
- cpus {
- #address-cells = <2>;
- #size-cells = <0>;
-
- cpu0: cpu@0 {
- device_type = "cpu";
- compatible = "arm,cortex-a53";
- reg = <0x0 0x0>;
- clocks = <&clockgen 1 0>;
- };
-
- };
sysclk: sysclk {
compatible = "fixed-clock";
diff --git a/arch/arm/dts/fsl-ls1043a.dtsi b/arch/arm/dts/fsl-ls1043a.dtsi
index bf1dfe6..a8bffba 100644
--- a/arch/arm/dts/fsl-ls1043a.dtsi
+++ b/arch/arm/dts/fsl-ls1043a.dtsi
@@ -15,38 +15,6 @@
/ {
compatible = "fsl,ls1043a";
interrupt-parent = <&gic>;
- cpus {
- #address-cells = <2>;
- #size-cells = <0>;
-
- cpu0: cpu@0 {
- device_type = "cpu";
- compatible = "arm,cortex-a53";
- reg = <0x0 0x0>;
- clocks = <&clockgen 1 0>;
- };
-
- cpu1: cpu@1 {
- device_type = "cpu";
- compatible = "arm,cortex-a53";
- reg = <0x0 0x1>;
- clocks = <&clockgen 1 0>;
- };
-
- cpu2: cpu@2 {
- device_type = "cpu";
- compatible = "arm,cortex-a53";
- reg = <0x0 0x2>;
- clocks = <&clockgen 1 0>;
- };
-
- cpu3: cpu@3 {
- device_type = "cpu";
- compatible = "arm,cortex-a53";
- reg = <0x0 0x3>;
- clocks = <&clockgen 1 0>;
- };
- };
sysclk: sysclk {
compatible = "fixed-clock";
diff --git a/arch/arm/dts/fsl-ls2080a.dtsi b/arch/arm/dts/fsl-ls2080a.dtsi
index a5c579c..b29ba2e 100644
--- a/arch/arm/dts/fsl-ls2080a.dtsi
+++ b/arch/arm/dts/fsl-ls2080a.dtsi
@@ -12,67 +12,6 @@
#address-cells = <2>;
#size-cells = <2>;
- cpus {
- #address-cells = <2>;
- #size-cells = <0>;
-
- /*
-* We expect the enable-method for cpu's to be "psci", but this
-* is dependent on the SoC FW, which will fill this in.
-*
-* Currently supported enable-method is psci v0.2
-*/
-
- /* We have 4 clusters having 2 Cortex-A57 cores each */
- cpu@0 {
- device_type = "cpu";
- compatible = "arm,cortex-a57";
- reg = <0x0 0x0>;
- };
-
- cpu@1 {
- device_type = "cpu";
- compatible = "arm,cortex-a57";
- reg = <0x0 0x1>;
- };
-
- cpu@100 {
- device_type = "cpu";
- compatible = "arm,cortex-a57";
- reg = <0x0 0x100>;
- };
-
- cpu@101 {
- device_type = "cpu";
- compatible = "arm,cortex-a57";
- reg = <0x0 0x101>;
- };
-
- cpu@200 {
- device_type = "cpu";
- compatible = "arm,cortex-a57";
- reg = <0x0 0x200>;
- };
-
- cpu@201 {
- device_type = "cpu";
- compatible = "arm,cortex-a57";
- reg = <0x0 0x201>;
- };
-
- cpu@300 {
- device_type = "cpu";
- compatible = "arm,cortex-a57";
- reg = <0x0 0x300>;
- };
-
- cpu@301 {
- device_type = "cpu";
- compatible = "arm,cortex-a57";
- reg = <0x0 0x301>;
- };
- };
-
memory@8000 {
device_type = "memory";
reg = <0x 0x8000 0 0x8000>;
--
1.9.1
_
[U-Boot] [PATCH] Orphan dbau1x00 boards
I no longer have access to such a board Signed-off-by: Thomas Lange --- board/dbau1x00/MAINTAINERS | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/board/dbau1x00/MAINTAINERS b/board/dbau1x00/MAINTAINERS index b94ed81..21853ed 100644 --- a/board/dbau1x00/MAINTAINERS +++ b/board/dbau1x00/MAINTAINERS @@ -1,6 +1,6 @@ DBAU1X00 BOARD -M: Thomas Lange -S: Maintained +#M:- +S: Orphan (since 2016-06) F: board/dbau1x00/ F: include/configs/dbau1x00.h F: configs/dbau1000_defconfig -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] x86: baytrail: azalia DT configuration mock-up
On Mon, Jun 13, 2016 at 9:09 PM, Bin Meng wrote:
> Hi George,
>
> On Mon, Jun 13, 2016 at 9:09 PM, George McCollister
> wrote:
>> On Fri, Jun 10, 2016 at 7:17 PM, Bin Meng wrote:
>>> Hi George,
>>>
>>> On Fri, Jun 10, 2016 at 4:57 AM, George McCollister
>>> wrote:
I'm looking for feedback on this mock-up of fsp,azalia-config DT
before I proceed to writing code. I included everything in fsp for
context.
fsp {
compatible = "intel,baytrail-fsp";
fsp,mrc-init-tseg-size = <0>;
fsp,mrc-init-mmio-size = <0x800>;
fsp,mrc-init-spd-addr1 = <0xa0>;
fsp,mrc-init-spd-addr2 = <0xa2>;
fsp,emmc-boot-mode = <2>;
fsp,enable-sdio;
fsp,enable-sdcard;
fsp,enable-hsuart1;
fsp,enable-spi;
fsp,enable-sata;
fsp,sata-mode = <1>;
fsp,enable-azalia;
fsp,azalia-config {
compatible = "intel,baytrail-fsp-azalia-config";
>>>
>>> I believe this azalia config is platform-specific, so tagging it with
>>> a baytrail-fsp- prefix is OK?
>> Yes. As far as I can tell there aren't any other platforms with an
>> identical azalia config structure.
>> I plan on putting the code to handle this in
>> arch/x86/cpu/baytrail/fsp_configs.c
>> Do you think we should shorten the name to "intel,baytrail-fsp-ac"? If
>> we leave it as is it will be the longest entry in compat_names[].
>
> How about changing all "intel,baytrail-fsp" to "intel,byt-fsp"? ac
> does not look straight-forward.
That sounds fine to me, however I've run into a problem that might
delay this change.
Even with the hard coded verb table data the pin complex pin defaults
do not seem to be getting changed.
For example my verb table contains the following for node 0x11:
/* Pin Complex (NID 0x11) */
0x01171cf0,
0x01171d11,
0x01171e11,
0x01171f41,
This should set the pin default to 0x41f0 however in Linux,
/proc/asound/codec#0 shows "Pin Default 0x40f0" for Node 0x11. I'm
assuming the FSP is supposed to go through the verb-table-data and
actually run these commands against the codec. Are you aware of anyway
to get any feedback from the FSP code? As far as I can tell right now
the verb-table-data is doing nothing.
One thing that is a bit confusing is how it even figures out the
length of the verb table data. The only way I figure it can be doing
it is by assuming (number-of-rear-jacks + number-of-front-jacks) *
sizeof(uint32_t) * 4. I took a look at coreboot and EDKII source and
as far as I can tell what we're doing should work if coreboot and
EDKII actually work (which I haven't verified).
>
>>
>>>
fsp,pme-enable = <1>;
fsp,docking-supported = <1>;
fsp,docking-attached = <0>;
fsp,hdmi-codec-enable = <1>;
fsp,azalia-v-ci-enable = <1>;
fsp,rsvdbits = <0>;
fsp,reset-wait-timer-us = <300>;
alc262 {
compatible = "fsp,azalia-verb-table";
>>>
>>> This generic name fsp,azalia-ver-table means it is suitable to all
>>> platforms, correct?
>> No, I was concerned with this name being too long. This will be
>> specific to baytrail-fsp.
>> How about "intel,baytrail-fsp-avt"?
>>
>>>
fsp,vendor-device-id = <0x10ec0262>;
fsp,sub-system-id = <0>;
fsp,revision-id = <0xff>;
fsp,front-panel-support = <1>;
fsp,number-of-rear-jacks = <11>;
fsp,number-of-front-jacks = <2>;
fsp,verb-table-data = <
/* Pin Complex (NID 0x11) */
0x01171cf0
0x01171d11
0x01171e11
0x01171f41
/* Pin Complex (NID 0x12) */
0x01271cf0
0x01271d11
0x01271e11
0x01271f41
/* Pin Complex (NID 0x14) */
0x01471c10
0x01471d40
0x01471e01
0x01471f01
Re: [U-Boot] [PATCH 3/3] mmc: fsl: introduce wp_enable
Hi Peng, On Tue, Apr 26, 2016 at 3:54 AM, Peng Fan wrote: > Introudce wp_enable. If want to check WPSPL, then in board code, > need to set wp_enable to 1. > > Take i.MX6UL for example, to some boards, they do not use WP singal, > so they does not configure USDHC1_WP_SELECT_INPUT, and its default > value is 0(GPIO1_IO02). However GPIO1_IO02 is muxed for i2c usage and > SION bit set. So USDHC controller can always get wp signal and WPSPL > shows write protect and blocks driver continuing. This is not what > we want to see, so add wp_enable, and if set to 0, just omit the > WPSPL checking and this does not effect normal working of usdhc > controller. > > To DT case, add wp_gpio, if there is wp-gpios provided in dts, > wp_enable is set to 1; if no, set to 0. > > Signed-off-by: Peng Fan > Cc: Pantelis Antoniou > Cc: York Sun > Cc: Stefano Babic Just saw this issue on a mx6ul pico board: after adding I2C support then the eMMC could not longer be written: => saveenv Saving Environment to MMC... Writing to MMC(0)... The SD card is locked. Can not write to a locked card. mmc write failed failed Your patch allows me to write to the eMMC succesfully: Tested-by: Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MinnowMax GPIO for USB3
On Mon, Jun 13, 2016 at 8:55 PM, Bin Meng wrote: > Hi George, > > On Sun, Jun 12, 2016 at 5:26 PM, Bin Meng wrote: >> On Sun, Jun 12, 2016 at 4:43 PM, Bin Meng wrote: >>> Hi, >>> >>> My testing shows that only pin_usb_host_en1 is needed to turn on the >>> power on the USB3 port. The USB2 port power is turned on by default. >>> >> >> Seems I was confused by the GPIO pin number mapping. pin_usb_host_en1 >> is used to control the USB2 port, while pin_usb_host_en0 is for USB3 >> port. So I should say: >> >> My testing shows that only pin_usb_host_en1 is needed to turn on the >> power on the USB2 (upper white) port. The USB3 (bottom blue) port >> power is turned on by default. >> >> [snip] > > vinoth eswaran confirmed removing pin_usb_host_en0 node from device > tree makes both usb ports work. > > However, that is just covering the real bug [1] here. Will you take > time to prepare a patch that fixes the gpio driver? I re-worked my patch to fix the gpio driver only to discover that pinctrl_ich6 uses it's own function ich6_pinctrl_set_value. This is the problem with having these driver separate... Even if we were to change pinctrl_ich6 to do something similar (keep a cache of each banks value) the pin values could still be lost if they changed any gpio in the same bank with the gpio driver. I'll need to look at it a bit longer, maybe I'll come up with a solution. > > [1] http://lists.denx.de/pipermail/u-boot/2015-October/229469.html > > Regards, > Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] env: Add a setenv that allows passing flags
Hi Joe,
On 06/15/2016 07:01 AM, Joe Hershberger wrote:
> In some cases an interactive feature will be implemented using the
> programmatic APIs, so the developer will want "interactive" behavior as
> a result, so provide an API that will allow that to be specified.
>
> Signed-off-by: Joe Hershberger
Thanks looks great
Reviewed-by: Chris Packham
I'll also give it a test on some of our setups here and report back.
> ---
>
> cmd/nvedit.c | 11 ---
> include/common.h | 5 +++--
> 2 files changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/cmd/nvedit.c b/cmd/nvedit.c
> index b67563b..c7c24e3 100644
> --- a/cmd/nvedit.c
> +++ b/cmd/nvedit.c
> @@ -284,7 +284,7 @@ static int _do_env_set(int flag, int argc, char * const
> argv[], int env_flag)
> return 0;
> }
>
> -int setenv(const char *varname, const char *varvalue)
> +int setenv_w_flags(const char *varname, const char *varvalue, int flags)
> {
> const char * const argv[4] = { "setenv", varname, varvalue, NULL };
>
> @@ -293,9 +293,14 @@ int setenv(const char *varname, const char *varvalue)
> return 1;
>
> if (varvalue == NULL || varvalue[0] == '\0')
> - return _do_env_set(0, 2, (char * const *)argv, H_PROGRAMMATIC);
> + return _do_env_set(0, 2, (char * const *)argv, flags);
> else
> - return _do_env_set(0, 3, (char * const *)argv, H_PROGRAMMATIC);
> + return _do_env_set(0, 3, (char * const *)argv, flags);
> +}
> +
> +int setenv(const char *varname, const char *varvalue)
> +{
> + return setenv_w_flags(varname, varvalue, H_PROGRAMMATIC);
> }
>
> /**
> diff --git a/include/common.h b/include/common.h
> index f9f4605..199e0e2 100644
> --- a/include/common.h
> +++ b/include/common.h
> @@ -377,8 +377,9 @@ ulong getenv_hex(const char *varname, ulong default_val);
>* Return -1 if variable does not exist (default to true)
>*/
> int getenv_yesno(const char *var);
> -int saveenv (void);
> -int setenv (const char *, const char *);
> +int saveenv(void);
> +int setenv_w_flags(const char *varname, const char *varvalue, int flags);
> +int setenv(const char *varname, const char *varvalue);
> int setenv_ulong(const char *varname, ulong value);
> int setenv_hex(const char *varname, ulong value);
> /**
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] mmc: fsl: introduce wp_enable
Hi Peng, On Tue, Jun 14, 2016 at 8:01 PM, Fabio Estevam wrote: > Just saw this issue on a mx6ul pico board: after adding I2C support > then the eMMC could not longer be written: > > => saveenv > Saving Environment to MMC... > Writing to MMC(0)... > The SD card is locked. Can not write to a locked card. > > mmc write failed > failed > > Your patch allows me to write to the eMMC succesfully: > > Tested-by: Fabio Estevam Looks like this is an issue with the MX6UL IOMUXC, not the esdhc driver itself, so maybe we should not do this change for all other SoCs. If I manually do: => mw.l 20E066C 2 Then 'saveenv' works fine. Shouldn't we fix this in the MX6UL IOMUXC code instead? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] mmc: fsl: introduce wp_enable
Hi Fabio, On Tue, Jun 14, 2016 at 08:23:27PM -0300, Fabio Estevam wrote: >Hi Peng, > >On Tue, Jun 14, 2016 at 8:01 PM, Fabio Estevam wrote: > >> Just saw this issue on a mx6ul pico board: after adding I2C support >> then the eMMC could not longer be written: >> >> => saveenv >> Saving Environment to MMC... >> Writing to MMC(0)... >> The SD card is locked. Can not write to a locked card. >> >> mmc write failed >> failed >> >> Your patch allows me to write to the eMMC succesfully: >> >> Tested-by: Fabio Estevam Thanks. This patch set was posted some time ago. > >Looks like this is an issue with the MX6UL IOMUXC, not the esdhc >driver itself, so maybe we should not do this change for all other >SoCs. > >If I manually do: >=> mw.l 20E066C 2 >Then 'saveenv' works fine. > >Shouldn't we fix this in the MX6UL IOMUXC code instead? No. We can not avoid such issue for now. You changed register 20e066c'value to 2 2 means "CSI_DATA04_ALT8 — Selecting Pad: CSI_DATA04 for Mode: ALT8" Look at "Figure 31-3. Daisy chain illustration" of i.MX6UL RM, if changed to 2, that means you let CSI_DATA04 pad goes into usdhc1_wp. select input can not be closed or disabled, which will cause issues like what you met. Even worse, some one may need to redesign their board to avoid pin conflict. Regards, Peng. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] mmc: fsl: introduce wp_enable
Hi Peng, On Tue, Jun 14, 2016 at 10:17 PM, Peng Fan wrote: > No. We can not avoid such issue for now. You changed register 20e066c'value > to 2 > 2 means "CSI_DATA04_ALT8 — Selecting Pad: CSI_DATA04 for Mode: ALT8" > > Look at "Figure 31-3. Daisy chain illustration" of i.MX6UL RM, if changed to > 2, > that means you let CSI_DATA04 pad goes into usdhc1_wp. Yes, this was just a quick hack. I am not proposing this workaround :-) > select input can not be closed or disabled, which will cause issues like what > you met. Even worse, some one may need to redesign their board to avoid pin > conflict. Yes, I understood the problem and don't have any alternative suggestion at the moment. Pantelis/Stefano/Tom/York, Any feedback on this series, please? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] mmc: fsl: introduce wp_enable
Hi Fabio, On Tue, Jun 14, 2016 at 10:46:15PM -0300, Fabio Estevam wrote: >On Tue, Jun 14, 2016 at 10:17 PM, Peng Fan wrote: > Your patch allows me to write to the eMMC succesfully: Tested-by: Fabio Estevam >> >> Thanks. This patch set was posted some time ago. > >Care to resend this series, please? Ok. I will resend this series with your tested-by tag. Thanks, Peng. > >Thanks ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] mmc: fsl: introduce wp_enable
On Tue, Jun 14, 2016 at 10:17 PM, Peng Fan wrote: >>> Your patch allows me to write to the eMMC succesfully: >>> >>> Tested-by: Fabio Estevam > > Thanks. This patch set was posted some time ago. Care to resend this series, please? Thanks ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 1/3] mmc: fsl: reset to normal boot mode when eMMC fast boot
When booting in eMMC fast boot, MMC host does not exit from
boot mode after bootrom loading image. So the first command
'CMD0' sent in uboot will pull down the CMD line to low and
cause errors.
This patch cleans the MMC boot register in "mmc_init" to put the
MMC host back to normal mode.
Also clear DLL_CTRL delay line settings at USDHC initialization
to eliminate the pre-settings from boot rom.
Signed-off-by: Peng Fan
Cc: Pantelis Antoniou
Cc: York Sun
Cc: Stefano Babic
Cc: Fabio Estevam
---
V2:
Rebased to lastest u-boot master
drivers/mmc/fsl_esdhc.c | 38 +-
include/fsl_esdhc.h | 6 ++
2 files changed, 35 insertions(+), 9 deletions(-)
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index 57ad975..9cd582f 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -56,21 +56,27 @@ struct fsl_esdhc {
uintfevt; /* Force event register */
uintadmaes; /* ADMA error status register */
uintadsaddr;/* ADMA system address register */
- charreserved2[100]; /* reserved */
- uintvendorspec; /* Vendor Specific register */
- charreserved3[56]; /* reserved */
+ charreserved2[4];
+ uintdllctrl;
+ uintdllstat;
+ uintclktunectrlstatus;
+ charreserved3[84];
+ uintvendorspec;
+ uintmmcboot;
+ uintvendorspec2;
+ charreserved4[48];
uinthostver;/* Host controller version register */
- charreserved4[4]; /* reserved */
- uintdmaerraddr; /* DMA error address register */
charreserved5[4]; /* reserved */
- uintdmaerrattr; /* DMA error attribute register */
+ uintdmaerraddr; /* DMA error address register */
charreserved6[4]; /* reserved */
+ uintdmaerrattr; /* DMA error attribute register */
+ charreserved7[4]; /* reserved */
uinthostcapblt2;/* Host controller capabilities register 2 */
- charreserved7[8]; /* reserved */
+ charreserved8[8]; /* reserved */
uinttcr;/* Tuning control register */
- charreserved8[28]; /* reserved */
+ charreserved9[28]; /* reserved */
uintsddirctl; /* SD direction control register */
- charreserved9[712]; /* reserved */
+ charreserved10[712];/* reserved */
uintscr;/* eSDHC control register */
};
@@ -616,6 +622,20 @@ static int esdhc_init(struct mmc *mmc)
while ((esdhc_read32(®s->sysctl) & SYSCTL_RSTA) && --timeout)
udelay(1000);
+#if defined(CONFIG_FSL_USDHC)
+ /* RSTA doesn't reset MMC_BOOT register, so manually reset it */
+ esdhc_write32(®s->mmcboot, 0x0);
+ /* Reset MIX_CTRL and CLK_TUNE_CTRL_STATUS regs to 0 */
+ esdhc_write32(®s->mixctrl, 0x0);
+ esdhc_write32(®s->clktunectrlstatus, 0x0);
+
+ /* Put VEND_SPEC to default value */
+ esdhc_write32(®s->vendorspec, VENDORSPEC_INIT);
+
+ /* Disable DLL_CTRL delay line */
+ esdhc_write32(®s->dllctrl, 0x0);
+#endif
+
#ifndef ARCH_MXC
/* Enable cache snooping */
esdhc_write32(®s->scr, 0x0040);
diff --git a/include/fsl_esdhc.h b/include/fsl_esdhc.h
index fa760a5..78c67c8 100644
--- a/include/fsl_esdhc.h
+++ b/include/fsl_esdhc.h
@@ -35,6 +35,12 @@
#define SYSCTL_RSTC0x0200
#define SYSCTL_RSTD0x0400
+#define VENDORSPEC_CKEN0x4000
+#define VENDORSPEC_PEREN 0x2000
+#define VENDORSPEC_HCKEN 0x1000
+#define VENDORSPEC_IPGEN 0x0800
+#define VENDORSPEC_INIT0x20007809
+
#define IRQSTAT0x0002e030
#define IRQSTAT_DMAE (0x1000)
#define IRQSTAT_AC12E (0x0100)
--
2.6.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 2/3] fsl_esdhc: Update clock enable bits for USDHC
From: Ye Li The USDHC move the 4 clock bits CARD_CLK_SOFT_EN, IPG_PERCLK_SOFT_EN, HCLK_SOFT_EN, and IPG_CLK_SOFT_EN from sysctl register to vendorspec register. The driver uses RSTA to replace the clock gate off operation. But this is not a good solution. This is because: 1. when using RSTA, we should wait this bit to clear by itself. This is not implemeneted in the code. 2. After RSTA is set, it is recommended that the Host Driver reset the external card and reinitialize it. So in this patch, we change to use the vendorspec registers for these bits operation. Signed-off-by: Ye Li Signed-off-by: Peng Fan Cc: York Sun Cc: Stefano Babic Cc: Pantelis Antoniou Cc: Fabio Estevam --- V2: Rebased to latest U-Boot master drivers/mmc/fsl_esdhc.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c index 9cd582f..d3a18c0 100644 --- a/drivers/mmc/fsl_esdhc.c +++ b/drivers/mmc/fsl_esdhc.c @@ -538,7 +538,7 @@ static void set_sysctl(struct mmc *mmc, uint clock) clk = (pre_div << 8) | (div << 4); #ifdef CONFIG_FSL_USDHC - esdhc_setbits32(®s->sysctl, SYSCTL_RSTA); + esdhc_clrbits32(®s->vendorspec, VENDORSPEC_CKEN); #else esdhc_clrbits32(®s->sysctl, SYSCTL_CKEN); #endif @@ -548,7 +548,7 @@ static void set_sysctl(struct mmc *mmc, uint clock) udelay(1); #ifdef CONFIG_FSL_USDHC - esdhc_clrbits32(®s->sysctl, SYSCTL_RSTA); + esdhc_setbits32(®s->vendorspec, VENDORSPEC_PEREN | VENDORSPEC_CKEN); #else esdhc_setbits32(®s->sysctl, SYSCTL_PEREN | SYSCTL_CKEN); #endif @@ -643,6 +643,8 @@ static int esdhc_init(struct mmc *mmc) #ifndef CONFIG_FSL_USDHC esdhc_setbits32(®s->sysctl, SYSCTL_HCKEN | SYSCTL_IPGEN); +#else + esdhc_setbits32(®s->vendorspec, VENDORSPEC_HCKEN | VENDORSPEC_IPGEN); #endif /* Set the initial clock speed */ @@ -740,6 +742,9 @@ static int fsl_esdhc_init(struct fsl_esdhc_priv *priv) #ifndef CONFIG_FSL_USDHC esdhc_setbits32(®s->sysctl, SYSCTL_PEREN | SYSCTL_HCKEN | SYSCTL_IPGEN | SYSCTL_CKEN); +#else + esdhc_setbits32(®s->vendorspec, VENDORSPEC_PEREN | + VENDORSPEC_HCKEN | VENDORSPEC_IPGEN | VENDORSPEC_CKEN); #endif writel(SDHCI_IRQ_EN_BITS, ®s->irqstaten); -- 2.6.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Patch revisions
Hi Stephen, When you get a moment can you respin your driver-model patches? It would be good to get these in for the upcoming release... Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 7/9] libfdt: Add overlay application function
On Tue, Jun 14, 2016 at 12:22:23PM +0300, Pantelis Antoniou wrote:
> Hi David,
> > On Jun 14, 2016, at 03:25 , David Gibson
> > wrote:
> > On Fri, Jun 10, 2016 at 05:28:11PM +0300, Pantelis Antoniou wrote:
[snip]
> >>> +static int fdt_overlay_merge(void *dt, void *dto)
> >>> +{
> >>> + int root, fragment;
> >>> +
> >>> + root = fdt_path_offset(dto, "/");
> >>> + if (root < 0)
> >>> + return root;
> >>> +
> >>> + fdt_for_each_subnode(dto, fragment, root) {
> >>> + const char *name = fdt_get_name(dto, fragment, NULL);
> >>> + uint32_t target;
> >>> + int overlay;
> >>> + int ret;
> >>> +
> >>> + if (strncmp(name, "fragment", 8))
> >>> + continue;
> >>> +
> >>
> >> This is incorrect. The use of “fragment” is a convention only.
> >> The real test whether the node is an overlay fragment is that
> >> it contains a target property.
> >
> > Hmm.. I dislike that approach. First, it means that if new target
> > types are introduced in future, older code is likely to silently
> > ignore such fragments instead of realizing that it doesn't know how to
> > apply themm. Second, it raises weird issues if some node down within
> > a fragment also happens to have a property called "target”.
>
> Not really. If new targets are introduced then the fragment will be ignored.
Yes.. and that's bad.
> We can have an argument about what is better to do (report an error or
> ignore a fragment) but what it comes down to is that that applicator
> does not know how to handle the new target method.
Sure, let's have the argument. The overlay is constructed on the
assumption that all the pieces will be applied, or none of them. A
silent, partial application is an awful, awful failure mode. We
absolutely should report an error, and in order to do so we need to
know what are applicable fragments, whether or not we understand the
target designation (or any other meta-data the fragment has).
Given what's established so far, checking the name seems the obvious
way to do that.
> There is no issues with any target properties inside a fragment because
> the check is not made recursively.
Ok, so the real test you're proposing is "at the top level AND has a
target property".
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 3/3] mmc: fsl: introduce wp_enable
Introudce wp_enable. If want to check WPSPL, then in board code,
need to set wp_enable to 1.
Take i.MX6UL for example, to some boards, they do not use WP singal,
so they does not configure USDHC1_WP_SELECT_INPUT, and its default
value is 0(GPIO1_IO02). However GPIO1_IO02 is muxed for i2c usage and
SION bit set. So USDHC controller can always get wp signal and WPSPL
shows write protect and blocks driver continuing. This is not what
we want to see, so add wp_enable, and if set to 0, just omit the
WPSPL checking and this does not effect normal working of usdhc
controller.
To DT case, add wp_gpio, if there is wp-gpios provided in dts,
wp_enable is set to 1; if no, set to 0.
Signed-off-by: Peng Fan
Cc: Pantelis Antoniou
Cc: York Sun
Cc: Stefano Babic
Cc: Fabio Estevam
Tested-by: Fabio Estevam
---
V2:
Rebased to lastest U-Boot master. Add Fabio's tested-by tag.
drivers/mmc/fsl_esdhc.c | 21 ++---
include/fsl_esdhc.h | 1 +
2 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index d3a18c0..7ee5a24 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -91,7 +91,9 @@ struct fsl_esdhc {
* Following is used when Driver Model is enabled for MMC
* @dev: pointer for the device
* @non_removable: 0: removable; 1: non-removable
+ * @wp_enable: 1: enable checking wp; 0: no check
* @cd_gpio: gpio for card detection
+ * @wp_gpio: gpio for write protection
*/
struct fsl_esdhc_priv {
struct fsl_esdhc *esdhc_regs;
@@ -101,7 +103,9 @@ struct fsl_esdhc_priv {
struct mmc *mmc;
struct udevice *dev;
int non_removable;
+ int wp_enable;
struct gpio_desc cd_gpio;
+ struct gpio_desc wp_gpio;
};
/* Return the XFERTYP flags for a given command and data packet */
@@ -245,9 +249,12 @@ static int esdhc_setup_data(struct mmc *mmc, struct
mmc_data *data)
#endif
if (wml_value > WML_WR_WML_MAX)
wml_value = WML_WR_WML_MAX_VAL;
- if ((esdhc_read32(®s->prsstat) & PRSSTAT_WPSPL) == 0) {
- printf("\nThe SD card is locked. Can not write to a
locked card.\n\n");
- return TIMEOUT;
+ if (priv->wp_enable) {
+ if ((esdhc_read32(®s->prsstat) &
+ PRSSTAT_WPSPL) == 0) {
+ printf("\nThe SD card is locked. Can not write
to a locked card.\n\n");
+ return TIMEOUT;
+ }
}
esdhc_clrsetbits32(®s->wml, WML_WR_WML_MASK,
@@ -721,6 +728,7 @@ static int fsl_esdhc_cfg_to_priv(struct fsl_esdhc_cfg *cfg,
priv->esdhc_regs = (struct fsl_esdhc *)(unsigned long)(cfg->esdhc_base);
priv->bus_width = cfg->max_bus_width;
priv->sdhc_clk = cfg->sdhc_clk;
+ priv->wp_enable = cfg->wp_enable;
return 0;
};
@@ -963,6 +971,13 @@ static int fsl_esdhc_probe(struct udevice *dev)
&priv->cd_gpio, GPIOD_IS_IN);
}
+ priv->wp_enable = 1;
+
+ ret = gpio_request_by_name_nodev(fdt, node, "wp-gpios", 0,
+&priv->wp_gpio, GPIOD_IS_IN);
+ if (ret)
+ priv->wp_enable = 0;
+
/*
* TODO:
* Because lack of clk driver, if SDHC clk is not enabled,
diff --git a/include/fsl_esdhc.h b/include/fsl_esdhc.h
index 78c67c8..c6f4666 100644
--- a/include/fsl_esdhc.h
+++ b/include/fsl_esdhc.h
@@ -177,6 +177,7 @@ struct fsl_esdhc_cfg {
phys_addr_t esdhc_base;
u32 sdhc_clk;
u8 max_bus_width;
+ u8 wp_enable;
struct mmc_config cfg;
};
--
2.6.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/2] armv8: Support loading 32-bit OS in AArch32 execution state
Hi, Alex, > On 06/08/2016 07:14 AM, Alison Wang wrote: > > To support loading a 32-bit OS, the execution state will change from > > AArch64 to AArch32 when jumping to kernel. > > > > The architecture information will be got through checking FIT > > image, then U-Boot will load 32-bit OS or 64-bit OS automatically. > > > > Signed-off-by: Ebony Zhu > > Signed-off-by: Alison Wang > > Signed-off-by: Chenhui Zhao > > --- > > Changes in v4: > > - Correct config ARM64_SUPPORT_AARCH32. > > - Omit arch and ftaddr arguments. > > - Rename "xreg5" to "tmp". > > - Use xxx_RES1 to combine all RES1 fields in xxx register. > > - Use an immediate cmp directly. > > - Use #ifdef for CONFIG_ARM64_SUPPORT_AARCH32. > > > > Changes in v3: > > - Comments the functions and the arguments. > > - Rename the real parameters. > > - Use the macros instead of the magic values. > > - Remove the redundant codes. > > - Clean up all of the mess in boot_jump_linux(). > > - Add CONFIG_ARM64_SUPPORT_AARCH32 to detect for some ARM64 system > doesn't support AArch32 state. > > > > Changes in v2: > > - armv8_switch_to_el2_aarch32() is removed. armv8_switch_to_el2_m is > used > >to switch to AArch64 EL2 or AArch32 Hyp. > > - armv8_switch_to_el1_aarch32() is removed. armv8_switch_to_el1_m is > used > >to switch to AArch64 EL1 or AArch32 SVC. > > > > arch/arm/Kconfig| 6 ++ > > arch/arm/cpu/armv8/start.S | 1 + > > arch/arm/cpu/armv8/transition.S | 8 +- > > arch/arm/include/asm/macro.h| 172 > ++-- > > arch/arm/include/asm/system.h | 111 +- > > arch/arm/lib/bootm.c| 19 - > > common/image-fit.c | 19 - > > 7 files changed, 284 insertions(+), 52 deletions(-) > > > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > > index 77eab66..9cf4acd 100644 > > --- a/arch/arm/Kconfig > > +++ b/arch/arm/Kconfig > > @@ -91,6 +91,12 @@ config SYS_L2CACHE_OFF > > If SoC does not support L2CACHE or one do not want to enable > > L2CACHE, choose this option. > > > > +config ARM64_SUPPORT_AARCH32 > > + bool "ARM64 system support AArch32 execution state" > > + default y if ARM64 && !TARGET_THUNDERX_88XX > > + help > > + This ARM64 system supports AArch32 execution state. > > + > > choice > > prompt "Target select" > > default TARGET_HIKEY > > diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S > > index e933021..dd69501 100644 > > --- a/arch/arm/cpu/armv8/start.S > > +++ b/arch/arm/cpu/armv8/start.S > > @@ -234,6 +234,7 @@ WEAK(lowlevel_init) > > /* > > * All slaves will enter EL2 and optionally EL1. > > */ > > + ldr x3, =ES_TO_AARCH64 > > bl armv8_switch_to_el2 > > #ifdef CONFIG_ARMV8_SWITCH_TO_EL1 > > bl armv8_switch_to_el1 > > diff --git a/arch/arm/cpu/armv8/transition.S > b/arch/arm/cpu/armv8/transition.S > > index 253a39b..e61b6ae 100644 > > --- a/arch/arm/cpu/armv8/transition.S > > +++ b/arch/arm/cpu/armv8/transition.S > > @@ -11,13 +11,13 @@ > > #include > > > > ENTRY(armv8_switch_to_el2) > > - switch_el x0, 1f, 0f, 0f > > + switch_el x4, 1f, 0f, 0f > > 0:ret > > -1: armv8_switch_to_el2_m x0 > > +1: armv8_switch_to_el2_m x0, x3, x4 > > ENDPROC(armv8_switch_to_el2) > > > > ENTRY(armv8_switch_to_el1) > > - switch_el x0, 0f, 1f, 0f > > + switch_el x4, 0f, 1f, 0f > > 0:ret > > -1: armv8_switch_to_el1_m x0, x1 > > +1: armv8_switch_to_el1_m x0, x3, x4 > > ENDPROC(armv8_switch_to_el1) > > diff --git a/arch/arm/include/asm/macro.h > b/arch/arm/include/asm/macro.h > > index 9bb0efa..109724f 100644 > > --- a/arch/arm/include/asm/macro.h > > +++ b/arch/arm/include/asm/macro.h > > @@ -8,6 +8,9 @@ > > > > #ifndef __ASM_ARM_MACRO_H__ > > #define __ASM_ARM_MACRO_H__ > > + > > +#include > > + > > #ifdef __ASSEMBLY__ > > > > /* > > @@ -135,13 +138,20 @@ lr.reqx30 > > #endif > > .endm > > > > -.macro armv8_switch_to_el2_m, xreg1 > > - /* 64bit EL2 | HCE | SMD | RES1 (Bits[5:4]) | Non-secure EL0/EL1 > */ > > - mov \xreg1, #0x5b1 > > - msr scr_el3, \xreg1 > > +/* > > + * Switch from EL3 to EL2 for ARMv8 > > + * @ep: kernel entry point > > + * @flag: The execution state flag for lower exception > > + * level, ES_TO_AARCH64 or ES_TO_AARCH32 > > + * @tmp:temporary register > > + * > > + * x1 is machine nr and x2 is ftaddr, they will be passed > > + * to the guest. > > + */ > > +.macro armv8_switch_to_el2_m, ep, flag, tmp > > msr cptr_el3, xzr /* Disable coprocessor traps to EL3 > */ > > - mov \xreg1, #0x33ff > > - msr cptr_el2, \xreg1/* Disable coprocessor traps to EL2 */ > > + mov \tmp, #CPTR_EL2_RES1 > > + msr cptr_el2, \tmp /* Disable coprocessor traps to EL2 > */ > > > > /* Initialize Generic Timers */ > > msr cntvoff_el2, xzr > > @@ -152,45 +162,91 @@ lr.reqx30 > > * and
Re: [U-Boot] [PATCH] configs: Re-sync BOOTDELAY changes
Dear Tom Rini, In message <1465914280-5420-2-git-send-email-tr...@konsulko.com> you wrote: > With updated moveconfig.py and an better default, re-generate > the migration of BOOTDELAY to the defconfig. There are a number of changes that are unrelated to BOOTDELAY; should this eventually be split into two separate commits? > --- a/configs/A10-OLinuXino-Lime_defconfig > +++ b/configs/A10-OLinuXino-Lime_defconfig > @@ -1,5 +1,6 @@ > CONFIG_ARM=y > CONFIG_ARCH_SUNXI=y > +CONFIG_MACH_SUN4I=y > CONFIG_DRAM_CLK=480 > CONFIG_DRAM_EMR1=4 > CONFIG_SYS_CLK_FREQ=91200 > --- a/configs/Cubietruck_plus_defconfig > +++ b/configs/Cubietruck_plus_defconfig > @@ -4,6 +4,7 @@ CONFIG_MACH_SUN8I_A83T=y > CONFIG_DRAM_CLK=672 > CONFIG_DRAM_ZQ=15355 > CONFIG_DRAM_ODT_EN=y > +CONFIG_MMC0_CD_PIN="PF6" > CONFIG_USB0_VBUS_PIN="AXP0-VBUS-ENABLE" > CONFIG_USB0_VBUS_DET="AXP0-VBUS-DETECT" > CONFIG_USB0_ID_DET="PH11" etc. ? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The human mind ordinarily operates at only ten percent of its capaci- ty - the rest is overhead for the operating system. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] x86: fsp: Wrap setup_internal_uart() call with CONFIG_INTERNAL_UART
For any FSP enabled boards that want to enable debug UART support, setup_internal_uart() will be called, but this API is only available on BayTrail platform. Change to wrap it with CONFIG_INTERNAL_UART. Signed-off-by: Bin Meng --- arch/x86/lib/fsp/fsp_support.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/lib/fsp/fsp_support.c b/arch/x86/lib/fsp/fsp_support.c index b05dced..a480361 100644 --- a/arch/x86/lib/fsp/fsp_support.c +++ b/arch/x86/lib/fsp/fsp_support.c @@ -110,7 +110,7 @@ void fsp_init(u32 stack_top, u32 boot_mode, void *nvs_buf) struct upd_region *fsp_upd; #endif -#ifdef CONFIG_DEBUG_UART +#ifdef CONFIG_INTERNAL_UART setup_internal_uart(1); #endif -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] x86: baytrail: Introduce a Kconfig option for the internal UART
There are quite a number of BayTrail boards that uses an external SuperIO chipset to provide the legacy UART. For such cases, it's better to have a Kconfig option to enable the internal UART. So far BayleyBay and MinnowMax boards are using internal UART as the U-Boot console, enable this on these two boards. Signed-off-by: Bin Meng --- arch/x86/cpu/baytrail/Kconfig | 11 +++ configs/bayleybay_defconfig | 1 + configs/minnowmax_defconfig | 1 + 3 files changed, 13 insertions(+) diff --git a/arch/x86/cpu/baytrail/Kconfig b/arch/x86/cpu/baytrail/Kconfig index 407feb2..1c8ac37 100644 --- a/arch/x86/cpu/baytrail/Kconfig +++ b/arch/x86/cpu/baytrail/Kconfig @@ -7,3 +7,14 @@ config INTEL_BAYTRAIL bool select HAVE_FSP if !EFI + +if INTEL_BAYTRAIL +config INTERNAL_UART + bool "Enable the SoC integrated legacy UART" + help + There is a legacy UART integrated into the Bay Trail SoC. + A maximum baud rate of 115200 bps is supported. For this + reason, it is recommended that the UART port be used for + debug purposes only, eg: U-Boot console. + +endif diff --git a/configs/bayleybay_defconfig b/configs/bayleybay_defconfig index 9f1d7fb..0a71bb8 100644 --- a/configs/bayleybay_defconfig +++ b/configs/bayleybay_defconfig @@ -2,6 +2,7 @@ CONFIG_X86=y CONFIG_VENDOR_INTEL=y CONFIG_DEFAULT_DEVICE_TREE="bayleybay" CONFIG_TARGET_BAYLEYBAY=y +CONFIG_INTERNAL_UART=y CONFIG_HAVE_INTEL_ME=y CONFIG_ENABLE_MRC_CACHE=y CONFIG_SMP=y diff --git a/configs/minnowmax_defconfig b/configs/minnowmax_defconfig index 28b837d..ba2b7dc 100644 --- a/configs/minnowmax_defconfig +++ b/configs/minnowmax_defconfig @@ -2,6 +2,7 @@ CONFIG_X86=y CONFIG_VENDOR_INTEL=y CONFIG_DEFAULT_DEVICE_TREE="minnowmax" CONFIG_TARGET_MINNOWMAX=y +CONFIG_INTERNAL_UART=y CONFIG_HAVE_INTEL_ME=y CONFIG_ENABLE_MRC_CACHE=y CONFIG_SMP=y -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] mmc: fsl: introduce wp_enable
On 06/14/2016 06:35 PM, Fabio Estevam wrote: > Hi Peng, > > On Tue, Jun 14, 2016 at 10:17 PM, Peng Fan wrote: > >> No. We can not avoid such issue for now. You changed register 20e066c'value >> to 2 >> 2 means "CSI_DATA04_ALT8 — Selecting Pad: CSI_DATA04 for Mode: ALT8" >> >> Look at "Figure 31-3. Daisy chain illustration" of i.MX6UL RM, if changed to >> 2, >> that means you let CSI_DATA04 pad goes into usdhc1_wp. > > Yes, this was just a quick hack. I am not proposing this workaround :-) > >> select input can not be closed or disabled, which will cause issues like what >> you met. Even worse, some one may need to redesign their board to avoid pin >> conflict. > > Yes, I understood the problem and don't have any alternative > suggestion at the moment. > > Pantelis/Stefano/Tom/York, > > Any feedback on this series, please? > It looks good to me, but I didn't test it. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/5] tools: moveconfig: change class WorkDir to class ReferenceSource
The class WorkDir can be used in a very generic way, but currently it is only used for containing a reference source directory. This commit changes it for a more dedicated use. The move_config function can be more readable by enclosing the git-clone and git- checkout in the class constructor. Signed-off-by: Masahiro Yamada --- tools/moveconfig.py | 49 - 1 file changed, 28 insertions(+), 21 deletions(-) diff --git a/tools/moveconfig.py b/tools/moveconfig.py index 06ff4d9..f4e2580 100755 --- a/tools/moveconfig.py +++ b/tools/moveconfig.py @@ -880,23 +880,39 @@ class Slots: for board in failed_boards: f.write(board + '\n') -class WorkDir: -def __init__(self): -"""Create a new working directory.""" -self.work_dir = tempfile.mkdtemp() +class ReferenceSource: + +"""Reference source against which original configs should be parsed.""" + +def __init__(self, commit): +"""Create a reference source directory based on a specified commit. + +Arguments: + commit: commit to git-clone +""" +self.src_dir = tempfile.mkdtemp() +print "Cloning git repo to a separate work directory..." +subprocess.check_output(['git', 'clone', os.getcwd(), '.'], +cwd=self.src_dir) +print "Checkout '%s' to build the original autoconf.mk." % \ +subprocess.check_output(['git', 'rev-parse', '--short', commit]).strip() +subprocess.check_output(['git', 'checkout', commit], +stderr=subprocess.STDOUT, cwd=self.src_dir) def __del__(self): -"""Delete the working directory +"""Delete the reference source directory This function makes sure the temporary directory is cleaned away even if Python suddenly dies due to error. It should be done in here because it is guaranteed the destructor is always invoked when the instance of the class gets unreferenced. """ -shutil.rmtree(self.work_dir) +shutil.rmtree(self.src_dir) + +def get_dir(self): +"""Return the absolute path to the reference source directory.""" -def get(self): -return self.work_dir +return self.src_dir def move_config(configs, options): """Move config options to defconfig files. @@ -914,20 +930,11 @@ def move_config(configs, options): print 'Move ' + ', '.join(configs), print '(jobs: %d)\n' % options.jobs -reference_src_dir = '' - if options.git_ref: -work_dir = WorkDir() -reference_src_dir = work_dir.get() -print "Cloning git repo to a separate work directory..." -subprocess.check_output(['git', 'clone', os.getcwd(), '.'], -cwd=reference_src_dir) -print "Checkout '%s' to build the original autoconf.mk." % \ -subprocess.check_output(['git', 'rev-parse', '--short', -options.git_ref]).strip() -subprocess.check_output(['git', 'checkout', options.git_ref], -stderr=subprocess.STDOUT, -cwd=reference_src_dir) +reference_src = ReferenceSource(options.git_ref) +reference_src_dir = reference_src.get_dir() +else: +reference_src_dir = '' if options.defconfigs: defconfigs = [line.strip() for line in open(options.defconfigs)] -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] usb: ehci: only shutdown opened controller
If the usb controller is not running, no need to shutdown it, otherwise `usb stop` complains about: "EHCI failed to shut down host controller". To i.MX7D SDB, there are two usb ports, one Host, one OTG. If we only plug one udisk to the Host port and then `usb start`, the OTG controller for OTG port does not run actually. Then, if `usb stop`, the OTG controller for OTG port will also be shutdown, but it is not running. This patch adds a check to only shutdown the running controller. Signed-off-by: Peng Fan Cc: Marek Vasut Cc: Simon Glass Cc: Mateusz Kulikowski Cc: Hans de Goede Cc: "Stefan Brüns" Cc: Stephen Warren --- drivers/usb/host/ehci-hcd.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c index fa5d584..13aa70d 100644 --- a/drivers/usb/host/ehci-hcd.c +++ b/drivers/usb/host/ehci-hcd.c @@ -210,6 +210,9 @@ static int ehci_shutdown(struct ehci_ctrl *ctrl) return -EINVAL; cmd = ehci_readl(&ctrl->hcor->or_usbcmd); + /* If not run, directly return */ + if (!(cmd & CMD_RUN)) + return 0; cmd &= ~(CMD_PSE | CMD_ASE); ehci_writel(&ctrl->hcor->or_usbcmd, cmd); ret = handshake(&ctrl->hcor->or_usbsts, STS_ASS | STS_PSS, 0, -- 2.6.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
