[U-Boot] [RFC PATCH V2] common: image-fdt: support dts from the second address of android image

[Michael Trimarchi]

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 
---
 common/image-android.c | 21 +
 common/image-fdt.c | 12 
 include/image.h|  2 ++
 3 files changed, 35 insertions(+)

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..732a1a3 100644
--- a/common/image-fdt.c
+++ b/common/image-fdt.c
@@ -345,6 +345,14 @@ 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: {
+   ulong fdt_data, fdt_len;
+   android_image_get_dts(buf, _data, _len);
+   goto boot_fdt;
+   }
+   break;
+#endif
case IMAGE_FORMAT_FIT:
/*
 * This case will catch both: new uImage format
@@ -400,6 +408,10 @@ int boot_get_fdt(int flag, int argc, char * const argv[], 
uint8_t arch,
 
image_multi_getimg(images->legacy_hdr_os, 2, _data,
   _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

-- 
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO  -  Founder  Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
|  [`as] http://www.amarulasolutions.com   |
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [RFC PATCH] common: image-fdt: support dts from the second address of android image

[Michael Trimarchi]

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 
---
 common/image-fdt.c | 26 ++
 include/image.h|  2 ++
 2 files changed, 28 insertions(+)

diff --git a/common/image-fdt.c b/common/image-fdt.c
index 6cac7db..782c489 100644
--- a/common/image-fdt.c
+++ b/common/image-fdt.c
@@ -345,6 +345,31 @@ 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: {
+   ulong fdt_data, fdt_len;
+   android_image_get_dts(buf, _data, _len);
+   if (fdt_len) {
+   fdt_blob = (char *)fdt_data;
+   printf("   Booting using the fdt at 
0x%p\n", fdt_blob);
+
+   if (fdt_check_header(fdt_blob) != 0) {
+   fdt_error("image is not a fdt");
+   goto error;
+   }
+
+   if (fdt_totalsize(fdt_blob) != fdt_len) 
{
+   fdt_error("fdt size != image 
size");
+   goto error;
+   }
+   goto boot_fdt;
+   } else {
+   debug("## No Flattened Device Tree\n");
+   goto no_fdt;
+   }
+   }
+   break;
+#endif
case IMAGE_FORMAT_FIT:
/*
 * This case will catch both: new uImage format
@@ -422,6 +447,7 @@ int boot_get_fdt(int flag, int argc, char * const argv[], 
uint8_t arch,
goto no_fdt;
}
 
+boot_fdt:
*of_flat_tree = fdt_blob;
*of_size = fdt_totalsize(fdt_blob);
debug("   of_flat_tree at 0x%08lx size 0x%08lx\n",
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

-- 
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO  -  Founder  Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
|  [`as] http://www.amarulasolutions.com   |
___
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

[Joe Hershberger]

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.

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

[Joe Hershberger]

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 
> Signed-off-by: Simon Glass 
> ---
>
>  drivers/net/phy/marvell.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
> index d2e68d4..8de0574 100644
> --- a/drivers/net/phy/marvell.c
> +++ b/drivers/net/phy/marvell.c
> @@ -8,6 +8,7 @@
>   */
>  #include 
>  #include 
> +#include 
>  #include 

Maybe we can go ahead and apply this:

https://patchwork.ozlabs.org/patch/605766/

Otherwise,

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

Re: [U-Boot] [PATCH] pico-imx6ul: Add USB Host support

[Fabio Estevam]

On Mon, Jun 13, 2016 at 1:01 PM, Vanessa Maegima
 wrote:
> Add USB host support.
>
> Tested by connecting a USB pen drive:
>
> => usb start
> starting USB...
> USB0:   Port not available.
> USB1:   USB EHCI 1.00
> scanning bus 1 for devices... 2 USB Device(s) found
>scanning usb for storage devices... 1 Storage Device(s) found
>
> Signed-off-by: Vanessa Maegima 

Reviewed-by: Fabio Estevam 
___
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

[George McCollister]

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.

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

>
> 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] [PATCHV5 4/6] ARMv8/Layerscape: switch SMP method accordingly

[york sun]

On 06/13/2016 01:30 AM, Zhiqiang Hou wrote:
> Hi York,
>
>> -Original Message-
>> From: Zhiqiang Hou
>> Sent: 2016年6月12日 12:31
>> To: york sun ; u-boot@lists.denx.de;
>> albert.u.b...@aribaud.net; scottw...@freescale.com;
>> mingkai...@freescale.com; york...@freescale.com; le...@freescale.com;
>> prabha...@freescale.com; bhupesh.sha...@freescale.com
>> Subject: RE: [PATCHV5 4/6] ARMv8/Layerscape: switch SMP method accordingly
>>
>> Hi York,
>>
>> Thanks for your comments!
>>
>>> -Original Message-
>>> From: york sun
>>> Sent: 2016年6月12日 12:07
>>> To: Zhiqiang Hou ; u-boot@lists.denx.de;
>>> albert.u.b...@aribaud.net; scottw...@freescale.com;
>>> mingkai...@freescale.com; york...@freescale.com; le...@freescale.com;
>>> prabha...@freescale.com; bhupesh.sha...@freescale.com
>>> Subject: Re: [PATCHV5 4/6] ARMv8/Layerscape: switch SMP method
>>> accordingly
>>>
>>> On 06/11/2016 08:58 PM, Zhiqiang Hou wrote:
 Hi York,

 Thanks for your comments!

> -Original Message-
> From: York Sun [mailto:york@nxp.com]
> Sent: 2016年6月8日 8:56
> To: Zhiqiang Hou ; u-boot@lists.denx.de;
> albert.u.b...@aribaud.net; scottw...@freescale.com;
> mingkai...@freescale.com; york...@freescale.com;
> le...@freescale.com; prabha...@freescale.com;
> bhupesh.sha...@freescale.com
> Subject: Re: [PATCHV5 4/6] ARMv8/Layerscape: switch SMP method
> accordingly
>
> On 06/04/2016 11:40 PM, Zhiqiang Hou wrote:
>> From: Hou Zhiqiang 
>>
>> If the PSCI and PPA is ready, skip the fixup for spin-table and
>> waking secondary cores. If not, change SMP method to spin-table,
>> and the device node of PSCI will be removed.
>>
>> Signed-off-by: Hou Zhiqiang 
>> ---
>> V5:
>>- Changed the checking if the PSCI feature is ready to read the psci 
>> version.
>>
>> V4:
>>- Reordered this patch.
>>
>>arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 17 +---
>> arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 36
>> +
>>2 files changed, 50 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
>> b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
>> index 672a453..eb566cd 100644
>> --- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
>> +++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
>> @@ -23,6 +23,9 @@
>>#ifdef CONFIG_FSL_ESDHC
>>#include 
>>#endif
>> +#ifdef CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT #include
>> + #endif
>>
>>DECLARE_GLOBAL_DATA_PTR;
>>
>> @@ -618,6 +621,7 @@ int arch_early_init_r(void)  {  #ifdef CONFIG_MP
>>  int rv = 1;
>> +bool psci_support = false;
>>#endif
>>
>>#ifdef CONFIG_SYS_FSL_ERRATUM_A009635 @@ -625,9 +629,16 @@ int
>> arch_early_init_r(void)  #endif
>>
>>#ifdef CONFIG_MP
>> -rv = fsl_layerscape_wake_seconday_cores();
>> -if (rv)
>> -printf("Did not wake secondary cores\n");
>> +#if defined(CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT) &&
> defined(CONFIG_ARMV8_PSCI)
>> +/* Check the psci version to determine if the psci is supported 
>> */
>> +psci_support = (int)sec_firmware_support_psci_version() > 0 ?
>> +true : false;
>
> Another comment, even if the function can be used to indicate if
> psci is available, do you have to cast it to (int)? I think this can be 
> simplified as
>   psci_support = sec_firmware_support_psci_version() > 0;

 The type of this func return value is 'unsigned int', so the cast is 
 necessary.
>>>
>>> The return value of function sec_firmware_support_psci_version() may
>>> need some work. It has three results
>>>
>>> Positive numbers mean success (presuming bit 31 is not used by major number.
>>> Need to check with PPA code) Zero means image is not valid Negative
>>> numbers means errors
>>
>> In PSCI spec v1.0, the bit 31 is used by major number, and the type of the 
>> return
>> value is uint, but there isn't any other description for the return value. I 
>> don't know
>> why the PPA isn't consistent with PSCI spec.
>
> I misunderstand your words, and the PPA is consistent with PSCI spec.
> Will take your suggestion that presuming bit 31 isn't used by major number to 
> handle
> the return value.

Zhiqiang,

I didn't suggest to discard bit 31. If PSCI uses bit 31, you can't 
presume it otherwise. In this case, you cannot return negative value 
directly. You may process the version number to fit in an int variable, 
or find another way to indicate an error.

York

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

[U-Boot] [PATCH] pico-imx6ul: Add USB Host support

[Vanessa Maegima]

Add USB host support.

Tested by connecting a USB pen drive:

=> usb start
starting USB... 
USB0:   Port not available. 
USB1:   USB EHCI 1.00   
scanning bus 1 for devices... 2 USB Device(s) found 
   scanning usb for storage devices... 1 Storage Device(s) found

Signed-off-by: Vanessa Maegima 
---
 board/technexion/pico-imx6ul/pico-imx6ul.c | 24 +++-
 include/configs/pico-imx6ul.h  |  2 +-
 2 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/board/technexion/pico-imx6ul/pico-imx6ul.c 
b/board/technexion/pico-imx6ul/pico-imx6ul.c
index c038d43..bdf32f4 100644
--- a/board/technexion/pico-imx6ul/pico-imx6ul.c
+++ b/board/technexion/pico-imx6ul/pico-imx6ul.c
@@ -59,6 +59,9 @@ static iomux_v3_cfg_t const usdhc1_pads[] = {
MX6_PAD_NAND_CLE__USDHC1_DATA7 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
 };
 
+#define USB_OTHERREGS_OFFSET   0x800
+#define UCTRL_PWR_POL  (1 << 9)
+
 static iomux_v3_cfg_t const usb_otg_pad[] = {
MX6_PAD_GPIO1_IO00__ANATOP_OTG1_ID | MUX_PAD_CTRL(OTG_ID_PAD_CTRL),
 };
@@ -98,7 +101,26 @@ int board_early_init_f(void)
 
 int board_usb_phy_mode(int port)
 {
-   return USB_INIT_DEVICE;
+   if (port == 1)
+   return USB_INIT_HOST;
+   else
+   return USB_INIT_DEVICE;
+}
+
+int board_ehci_hcd_init(int port)
+{
+   u32 *usbnc_usb_ctrl;
+
+   if (port > 1)
+   return -EINVAL;
+
+   usbnc_usb_ctrl = (u32 *)(USB_BASE_ADDR + USB_OTHERREGS_OFFSET +
+port * 4);
+
+   /* Set Power polarity */
+   setbits_le32(usbnc_usb_ctrl, UCTRL_PWR_POL);
+
+   return 0;
 }
 
 int board_init(void)
diff --git a/include/configs/pico-imx6ul.h b/include/configs/pico-imx6ul.h
index d848ead..01edc03 100644
--- a/include/configs/pico-imx6ul.h
+++ b/include/configs/pico-imx6ul.h
@@ -42,7 +42,7 @@
 #define CONFIG_EHCI_HCD_INIT_AFTER_RESET
 #define CONFIG_MXC_USB_PORTSC  (PORT_PTS_UTMI | PORT_PTS_PTW)
 #define CONFIG_MXC_USB_FLAGS   0
-#define CONFIG_USB_MAX_CONTROLLER_COUNT1 /* Only OTG1 port enabled */
+#define CONFIG_USB_MAX_CONTROLLER_COUNT2
 
 #define CONFIG_CI_UDC
 #define CONFIG_USBD_HS
-- 
1.9.1

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

Re: [U-Boot] [PATCH v3 11/11] sunxi: Add PSCI implementation in C

[Hans de Goede]

Hi,

On 13-06-16 12:58, Chen-Yu Tsai wrote:

On Mon, Jun 13, 2016 at 5:49 PM, Hans de Goede  wrote:

Hi,

On 13-06-16 04:50, Chen-Yu Tsai wrote:


On Fri, Jun 10, 2016 at 9:40 PM, Hans de Goede 
wrote:


Hi,

On 07-06-16 04:54, Chen-Yu Tsai wrote:



To make the PSCI backend more maintainable and easier to port to newer
SoCs, rewrite the current PSCI implementation in C.

Some inline assembly bits are required to access coprocessor registers.
PSCI stack setup is the only part left completely in assembly. In theory
this part could be split out of psci_arch_init into a separate common
function, and psci_arch_init could be completely in C.

Signed-off-by: Chen-Yu Tsai 




I tried merging this in my tree to add it to u-boot-sunxi/next, but
unfortunately it triggers a bug in gcc-6.1, I've filed a bug with
gcc to get this fixed:

https://bugzilla.redhat.com/show_bug.cgi?id=1344717



Interesting. Seems like the compiler should be emitting LDMFD instead
of POP, or a POP followed by a SUBS/MOVS.



Also cp15_read_scr / cp15_write_scr are missing __secure notations.



Do you want me to send a new version for this?



No, I already have a local branch with this fixed.

As for getting this merged and Tom's "go for it"
comment earlier, I consider this a blocker for merging, sorry.

I hope that the gcc folks can resolve this soon and that I can
get the Fedora devs to deploy a fix soon-ish. I'm not sure what
other distros are doing wrt jumping to gcc-6.1, but having code
in u-boot master which does not build with the latest gcc seems
like a bad idea.


This is marked as resolved upstream:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70830

And Debian/Ubuntu seems to have pulled the fix into their latest
unstable package:


http://metadata.ftp-master.debian.org/changelogs//main/g/gcc-6/gcc-6_6.1.1-6_changelog

I'm not familiar with Fedora, though you could reference the GCC
PR I listed above and have them pull in the fix.


Yes it indeed is that bug, thanks for finding that. I've done a local
Fedora cross-gcc build with the patches from that bug applied and that
fixes things.

I've added these patches to my sunxi-wip branch now and I'll send
them out in my next pull-req, after the dust surrounding the
BOOTDELAY changes settles.


Interesting that Fedora only provides one version of GCC though.


Fedora always contains the latest gcc, glibc, etc. Given that it is
Red Hat's community distro and that we employ a lot of gcc / glibc
developers we try to follow upstream as close as possible.


Regards,

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

Re: [U-Boot] [PATCH v2 0/5] Urgent fixes for misconverted CONFIG_BOOTDELAY

[Tom Rini]

On Mon, Jun 13, 2016 at 03:51:31PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 13-06-16 15:07, Wolfgang Denk wrote:
> >Dear Tom,
> >
> >In message <20160613124715.GT11619@bill-the-cat> you wrote:
> >>
> >>>BTW, would you consider changing the default of BOOTDELAY
> >>>from 0 to 3 ?
> >>
> >>I'm going to move it over to 2 as I want to encourage people in general
> >>to move over to the distro defaults values.
> >
> >I'm not sure if such a low value is a good idea.  There are a few
> >boards
> 
> I think that _few_ is the key word here, defaults should be what is
> good for most / allmost all boards. These few boards can set a different
> BOOTDELAY in their defconfig

Exactly.  The point of Kconfig is that it's easy to deviate from the
defaults when your use case requires it.

-- 
Tom


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

Re: [U-Boot] [PATCH v2 0/5] Urgent fixes for misconverted CONFIG_BOOTDELAY

[Hans de Goede]

Hi,

On 13-06-16 15:07, Wolfgang Denk wrote:

Dear Tom,

In message <20160613124715.GT11619@bill-the-cat> you wrote:



BTW, would you consider changing the default of BOOTDELAY
from 0 to 3 ?


I'm going to move it over to 2 as I want to encourage people in general
to move over to the distro defaults values.


I'm not sure if such a low value is a good idea.  There are a few
boards


I think that _few_ is the key word here, defaults should be what is
good for most / allmost all boards. These few boards can set a different
BOOTDELAY in their defconfig

Regards,

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

Re: [U-Boot] [PATCH RESEND 1/2 v2] linux-compat: Use original kern_levels.h for kernel debug levels

[Tom Rini]

On Mon, Jun 13, 2016 at 12:36:04PM +, Alexey Brodkin wrote:
> Hi Tom,
> 
> On Fri, 2016-06-10 at 15:20 -0400, Tom Rini wrote:
> > On Fri, Jun 10, 2016 at 03:42:30PM +0300, Alexey Brodkin wrote:
> > > 
> > > Even currently in U-Boot we don't really use kernel debug levels
> > > we do have quite a lot of code that was copy-pasted from Linux kernel
> > > and so contains symbols like KERN_DEBUG and alike.
> > > 
> > > We used to just define those symbols which is fine if it is used in
> > > constructions like:
> > > ->8--
> > > printk(KERN_DEBUG "My debug message");
> > > ->8--
> > > 
> > > But in other places where the symbol gets passed as a separate
> > > argument (which we also have but luckily all of them are intself
> > > dummy stubs in U-Boot) that won't work.
> > > 
> > > Now as a preparation to introduction of a real implementation of
> > > print_hex_dump() we need those symbols to be defined as something real
> > > so we're taking them as they are from Linux kernel.
> >
> > Contents are fine but you need to say what version of the kernel you get
> > it from.
> 
> This is taken from 4.7-rc2.
> 
> Given print_hex_dump() requires rework in a sense that we want to replace
> existing print_buffer() with it maybe we apply this patch because it has
> no dependencies on anything else?
> 
> If you want I may resend it with added info about kernel version used for
> copy, or alternatively you may fixup it on patch application.

Please just update the commit message here for the next iteration on
this patch set, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH v2 0/5] Urgent fixes for misconverted CONFIG_BOOTDELAY

[Wolfgang Denk]

Dear Tom,

In message <20160613124715.GT11619@bill-the-cat> you wrote:
> 
> > BTW, would you consider changing the default of BOOTDELAY
> > from 0 to 3 ?
> 
> I'm going to move it over to 2 as I want to encourage people in general
> to move over to the distro defaults values.

I'm not sure if such a low value is a good idea.  There are a few
boards out there that use USB serial adapters for console, which are
board powered (vs. bus powered).  That means they start registering
with a host only when the board powers up.  With a 2 second timeout it
is usually impossible to break into the interactive mode, as you
cannot connect fast enough to the /dev/ttyUSB*.  Just my $0.02

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
Niemand altert einfach dadurch, dass die Jahre vergehen.
Wir altern, indem wir unsere Ideale aufgeben.
___
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

[Marek Vasut]

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)

Parenthesis around variables are missing.

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

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

> + 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;
>   int retry;
> + bool retry_flag = false;
>   ccb *srb = _ccb;
>  #ifdef CONFIG_BLK
>   struct blk_desc *block_dev;
> @@ -1167,26 +1211,36 @@ static unsigned long usb_stor_read_write(struct 
> blk_desc *block_dev,
>*/
>   retry = 2;
>   srb->pdata = (unsigned char *)buf_addr;
> - if (blks > USB_MAX_XFER_BLK)
> - smallblks = USB_MAX_XFER_BLK;
> + if (blks > udev->cur_xfer_blks)
> + smallblks = udev->cur_xfer_blks;
>   else
>   smallblks = (unsigned short) blks;
>  retry_it:
> - if (smallblks == USB_MAX_XFER_BLK)
> + debug("usb_%s: retry #%d, 

Re: [U-Boot] [PATCH v5 1/2] common: usb_storage: Make common function for usb_stor_read/usb_stor_write

[Marek Vasut]

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

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.

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

> +}
> +
>  #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.

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

>   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;
>   if (blks > USB_MAX_XFER_BLK)
> @@ -1162,8 +1176,8 @@ retry_it:
>   usb_show_progress();
>   srb->datalen = block_dev->blksz * smallblks;
>   srb->pdata = (unsigned char *)buf_addr;
> - if (usb_read_10(srb, ss, start, smallblks)) {
> - debug("Read ERROR\n");
> + if (usb_stor_operation(srb, ss, start, smallblks, is_write)) {
> + debug("%s ERROR\n", USB_STOR_OP_TYPE);
>   usb_request_sense(srb, ss);
>   if (retry--)
>   goto retry_it;
> @@ -1176,9 +1190,9 @@ retry_it:
>   } while (blks != 0);
>   ss->flags &= ~USB_READY;
>  
> - debug("usb_read: end startblk " LBAF
> + debug("usb_%s: end startblk " LBAF
> ", blccnt %x buffer %" PRIxPTR "\n",
> -   start, smallblks, 

Re: [U-Boot] [Patch v4 0/5] Supporting ARM v8 USB errata for FSL

[Marek Vasut]

On 06/13/2016 06:28 AM, Sriram Dash wrote:
> The patch-set does the following :
> 
> 1. Adds support for ARM for USB Erratum Checking code for implementing the
> USB Erratum for fsl.
> 2. Performs code cleanup to reduce redundancy when adding fsl device
> tree fixup.
> 3. Implements Erratum A008751 for LS2 platform.
> 
> Sriram Dash (5):
>   arm64: fsl-layerscape: add get_svr and IS_SVR_REV helper
>   usb: xhci: fsl: code cleanup for device tree fixup for fsl usb
> controllers
>   fsl: usb: make errata function common for PPC and ARM
>   armv8/ls2080: Remove workaround for erratum A008751
>   usb: xhci: fsl: Add workaround for USB erratum A-008751


Applied all, thanks.

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

[U-Boot] [PATCH v2 2/2] arm, am335x: siemens: enable DM/DTS support

[Heiko Schocher]

enable basic DM/DTS support for the siemens am335x based boards.

Signed-off-by: Heiko Schocher 
---

Changes in v2:
- rebase to "siemens,am33x: add draco etamin board"
  6b3943f1b04be60f147ee540fbd72c4c7ea89f80
- add patch "fix etamin defconfig", as etamin defconfig
  does not contain USB_MUSB_* and CONFIG_G_DNL_*
  defines

 arch/arm/Kconfig   |  18 +
 arch/arm/dts/Makefile  |   8 +-
 arch/arm/dts/am335x-draco.dts  | 152 
 arch/arm/dts/am335x-draco.dtsi | 169 +
 arch/arm/dts/am335x-pxm2.dtsi  | 539 +
 arch/arm/dts/am335x-pxm50.dts  |  59 
 arch/arm/dts/am335x-rut.dts| 611 +
 configs/draco_defconfig|   6 +
 configs/etamin_defconfig   |  19 +
 configs/pxm2_defconfig |   6 +
 configs/rastaban_defconfig |   6 +
 configs/rut_defconfig  |   6 +
 configs/thuban_defconfig   |   6 +
 include/configs/siemens-am33x-common.h |   2 +
 14 files changed, 1605 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/dts/am335x-draco.dts
 create mode 100644 arch/arm/dts/am335x-draco.dtsi
 create mode 100644 arch/arm/dts/am335x-pxm2.dtsi
 create mode 100644 arch/arm/dts/am335x-pxm50.dts
 create mode 100644 arch/arm/dts/am335x-rut.dts

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e75c4c0..6a4e710 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -350,31 +350,49 @@ config TARGET_DRACO
bool "Support draco"
select CPU_V7
select SUPPORT_SPL
+   select DM
+   select DM_SERIAL
+   select DM_GPIO
 
 config TARGET_THUBAN
bool "Support thuban"
select CPU_V7
select SUPPORT_SPL
+   select DM
+   select DM_SERIAL
+   select DM_GPIO
 
 config TARGET_RASTABAN
bool "Support rastaban"
select CPU_V7
select SUPPORT_SPL
+   select DM
+   select DM_SERIAL
+   select DM_GPIO
 
 config TARGET_ETAMIN
 bool "Support etamin"
 select CPU_V7
 select SUPPORT_SPL
+   select DM
+   select DM_SERIAL
+   select DM_GPIO
 
 config TARGET_PXM2
bool "Support pxm2"
select CPU_V7
select SUPPORT_SPL
+   select DM
+   select DM_SERIAL
+   select DM_GPIO
 
 config TARGET_RUT
bool "Support rut"
select CPU_V7
select SUPPORT_SPL
+   select DM
+   select DM_SERIAL
+   select DM_GPIO
 
 config TARGET_PENGWYN
bool "Support pengwyn"
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 602fab1..5530661 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -95,10 +95,14 @@ dtb-$(CONFIG_ARCH_ZYNQMP) += \
zynqmp-zc1751-xm016-dc2.dtb \
zynqmp-zc1751-xm018-dc4.dtb \
zynqmp-zc1751-xm019-dc5.dtb
-dtb-$(CONFIG_AM33XX) += am335x-boneblack.dtb am335x-bone.dtb am335x-evm.dtb \
+dtb-$(CONFIG_AM33XX) += am335x-boneblack.dtb am335x-bone.dtb \
+   am335x-draco.dtb \
+   am335x-evm.dtb \
am335x-evmsk.dtb \
am335x-bonegreen.dtb \
-   am335x-icev2.dtb
+   am335x-icev2.dtb \
+   am335x-pxm50.dtb \
+   am335x-rut.dtb
 dtb-$(CONFIG_AM43XX) += am437x-gp-evm.dtb am437x-sk-evm.dtb\
am43x-epos-evm.dtb \
am437x-idk-evm.dtb
diff --git a/arch/arm/dts/am335x-draco.dts b/arch/arm/dts/am335x-draco.dts
new file mode 100644
index 000..25d0480
--- /dev/null
+++ b/arch/arm/dts/am335x-draco.dts
@@ -0,0 +1,152 @@
+/*
+ * Support for Siemens DRACO board
+ *
+ * Copyright (C) 2014 - Lukas Stockmann 
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/dts-v1/;
+
+#include "am33xx.dtsi"
+#include "am335x-draco.dtsi"
+#include 
+
+/ {
+   model = "Siemens DRACO";
+   compatible = "siemens,draco", "ti,am33xx";
+
+   /* ethernet alias is needed for the MAC address passing from U-Boot */
+   aliases {
+   ethernet0 = _emac0;
+   mdio-gpio0 = 
+   };
+
+   gpio-keys {
+   compatible = "gpio-keys";
+   button0 {
+   label = "button0";
+   gpios = < 27 GPIO_ACTIVE_LOW>;
+   linux,code = ; /* button0 */
+   };
+   button1 {
+   label = "button1";
+   gpios = < 23 GPIO_ACTIVE_LOW>;
+   linux,code = ; /* button1 */
+   };
+   };
+
+   ocp {
+   debugss: debugss@4b00 {
+   compatible = "ti,debugss";
+   ti,hwmods = "debugss";
+   reg = <0x4b00 100>;
+   status = "disabled";
+

[U-Boot] [PATCH v2 1/2] arm, am335x: siemens: update etamin defconfig

[Heiko Schocher]

add missing USB_MUSB_* and CONFIG_G_DNL_*
board configuration.

Signed-off-by: Heiko Schocher 
---

Changes in v2:
- new in v2

 configs/etamin_defconfig | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/configs/etamin_defconfig b/configs/etamin_defconfig
index 6c747df..f86f4a3 100644
--- a/configs/etamin_defconfig
+++ b/configs/etamin_defconfig
@@ -14,5 +14,11 @@ CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_WINBOND=y
 CONFIG_SYS_NS16550=y
 CONFIG_USB=y
+CONFIG_USB_MUSB_HOST=y
+CONFIG_USB_MUSB_GADGET=y
 CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_DOWNLOAD=y
+CONFIG_G_DNL_MANUFACTURER="Siemens AG"
+CONFIG_G_DNL_VENDOR_NUM=0x0908
+CONFIG_G_DNL_PRODUCT_NUM=0x02d2
 CONFIG_OF_LIBFDT=y
-- 
2.5.5

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

[U-Boot] [PATCH v2 0/2] arm, am335x: siemens: enable DM/DTS support

[Heiko Schocher]

This patchserie adds DM/DTS support for the siemens am335x
based boards. Add in the v2 an etamin_defconfig fix patch,
as in mainline missing some USB_MUSB_* and CONFIG_G_DNL_*
config options currently.

replaces patch:
https://patchwork.ozlabs.org/patch/626016/

This patchseries is based on the patches, already in mainline:
[U-Boot,v3,1/7] siemens,am33x: add ubi fastmap support
http://patchwork.ozlabs.org/patch/631340/

[U-Boot,v3,2/7] ubi: add new ubi command "ubi detach"
http://patchwork.ozlabs.org/patch/631342/

[U-Boot,v3,3/7] nand: add nand mtd concat support
http://patchwork.ozlabs.org/patch/631341/

[U-Boot,v3,4/7] mtd: nand: omap: allow to switch to BCH16
http://patchwork.ozlabs.org/patch/631345/

[U-Boot,v3,5/7] am335x, dxr2: get ECC sType from I2C eeprom
http://patchwork.ozlabs.org/patch/631344/

[U-Boot,v3,6/7] dfu, nand, ubi: fix erasing after write finish
http://patchwork.ozlabs.org/patch/631343/

[U-Boot,v3,7/7] siemens,am33x: add draco etamin board
http://patchwork.ozlabs.org/patch/631347/

Changes in v2:
- rebase to "siemens,am33x: add draco etamin board"
  6b3943f1b04be60f147ee540fbd72c4c7ea89f80
- add patch "fix etamin defconfig", as etamin defconfig
  does not contain USB_MUSB_* and CONFIG_G_DNL_*
  defines

Heiko Schocher (2):
  arm, am335x: siemens: update etamin defconfig
  arm, am335x: siemens: enable DM/DTS support

 arch/arm/Kconfig   |  18 +
 arch/arm/dts/Makefile  |   8 +-
 arch/arm/dts/am335x-draco.dts  | 152 
 arch/arm/dts/am335x-draco.dtsi | 169 +
 arch/arm/dts/am335x-pxm2.dtsi  | 539 +
 arch/arm/dts/am335x-pxm50.dts  |  59 
 arch/arm/dts/am335x-rut.dts| 611 +
 configs/draco_defconfig|   6 +
 configs/etamin_defconfig   |  25 ++
 configs/pxm2_defconfig |   6 +
 configs/rastaban_defconfig |   6 +
 configs/rut_defconfig  |   6 +
 configs/thuban_defconfig   |   6 +
 include/configs/siemens-am33x-common.h |   2 +
 14 files changed, 1611 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/dts/am335x-draco.dts
 create mode 100644 arch/arm/dts/am335x-draco.dtsi
 create mode 100644 arch/arm/dts/am335x-pxm2.dtsi
 create mode 100644 arch/arm/dts/am335x-pxm50.dts
 create mode 100644 arch/arm/dts/am335x-rut.dts

-- 
2.5.5

___
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

[George McCollister]

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

>
>> 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
>> 0x01a71d30
>> 0x01a71e81
>> 0x01a71f01
>> /* Pin Complex */
>>   

Re: [U-Boot] [PATCH v2 0/5] Urgent fixes for misconverted CONFIG_BOOTDELAY

[Tom Rini]

On Mon, Jun 13, 2016 at 08:15:43AM +0900, Masahiro Yamada wrote:
> Hi Tom,
> 
> 
> 2016-06-13 6:07 GMT+09:00 Masahiro Yamada :
> > Hi Tom,
> >
> > 2016-06-13 1:50 GMT+09:00 Tom Rini :
> >> On Sat, Jun 11, 2016 at 06:44:07PM +0900, Masahiro Yamada wrote:
> >>
> >>>
> >>> Masahiro Yamada (5):
> >>>   ARM: stm32: remove unused CONFIG_AUTOBOOT
> >>>   autoboot: follow-up cleanup after CONFIG_BOOTDELAY moves
> >>>   tools: fix define2mk.sed to not add quotes around negative integers
> >>>   autoboot: fix a bunch of misconversion of CONFIG_BOOTDELAY
> >>>   autoboot: add CONFIG_AUTOBOOT to allow to not compile autoboot.c
> >>
> >> Please put together a PR with everything except the defconfig changes,
> >> along with the other moveconfig.py related fixes for me and I'll go
> >> unbreak everything (along with Hans' patch).  Thanks!
> >
> >
> > Please let me confirm the ones I should include in my PR.
> >
> > moveconfig patches and these three?
> >
> >>>   ARM: stm32: remove unused CONFIG_AUTOBOOT
> >>>   autoboot: follow-up cleanup after CONFIG_BOOTDELAY moves
> >>>   tools: fix define2mk.sed to not add quotes around negative integers
> >
> 
> Done.

Thanks!  Poking things now.

> BTW, would you consider changing the default of BOOTDELAY
> from 0 to 3 ?

I'm going to move it over to 2 as I want to encourage people in general
to move over to the distro defaults values.

-- 
Tom


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

[U-Boot] Please pull ARC changes

[Alexey Brodkin]

Hi Tom,

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

for you to fetch changes up to fc1e8fbbb2ea73139c2eadf2f174d6c3fc4ee03f:

  axs103: Bump CPU frequency from 50MHz to 100MHz (2016-06-13 14:38:05 +0200)


Alexey Brodkin (5):
  arc/cache: really do invalidate_dcache_all() even if IOC exists
  arc/cache: Flush & invalidate all caches right before enabling IOC
  board: axs10x: Flush entire cache after programming reset vector
  arc: Update data accessors with use of memory barriers
  axs103: Bump CPU frequency from 50MHz to 100MHz

 arch/arc/include/asm/io.h  | 95 
++--
 arch/arc/lib/cache.c   | 10 -
 board/synopsys/axs101/axs101.c |  2 +-
 configs/axs103_defconfig   |  2 +-
 4 files changed, 86 insertions(+), 23 deletions(-)

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

Re: [U-Boot] [PATCH RESEND 1/2 v2] linux-compat: Use original kern_levels.h for kernel debug levels

[Alexey Brodkin]

Hi Tom,

On Fri, 2016-06-10 at 15:20 -0400, Tom Rini wrote:
> On Fri, Jun 10, 2016 at 03:42:30PM +0300, Alexey Brodkin wrote:
> > 
> > Even currently in U-Boot we don't really use kernel debug levels
> > we do have quite a lot of code that was copy-pasted from Linux kernel
> > and so contains symbols like KERN_DEBUG and alike.
> > 
> > We used to just define those symbols which is fine if it is used in
> > constructions like:
> > ->8--
> > printk(KERN_DEBUG "My debug message");
> > ->8--
> > 
> > But in other places where the symbol gets passed as a separate
> > argument (which we also have but luckily all of them are intself
> > dummy stubs in U-Boot) that won't work.
> > 
> > Now as a preparation to introduction of a real implementation of
> > print_hex_dump() we need those symbols to be defined as something real
> > so we're taking them as they are from Linux kernel.
>
> Contents are fine but you need to say what version of the kernel you get
> it from.

This is taken from 4.7-rc2.

Given print_hex_dump() requires rework in a sense that we want to replace
existing print_buffer() with it maybe we apply this patch because it has
no dependencies on anything else?

If you want I may resend it with added info about kernel version used for
copy, or alternatively you may fixup it on patch application.

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

[U-Boot] [PATCH 2/2] board_f: prevent misleading "Watchdog enabled" output

[Anatolij Gustschin]

Output the "Watchdog enabled" message only if hw_watchdog_init()
call really happened.

Signed-off-by: Anatolij Gustschin 
---
 common/board_f.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/board_f.c b/common/board_f.c
index 0e2e6bc..9f6e4cc 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -120,8 +120,8 @@ static int init_func_watchdog_init(void)
defined(CONFIG_DESIGNWARE_WATCHDOG) || \
defined(CONFIG_IMX_WATCHDOG))
hw_watchdog_init();
-# endif
puts("   Watchdog enabled\n");
+# endif
WATCHDOG_RESET();
 
return 0;
-- 
1.7.9.5

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

[U-Boot] [PATCH 1/2] board_f: init designware watchdog if CONFIG_DESIGNWARE_WATCHDOG=y

[Anatolij Gustschin]

The designware watchdog init is skipped even if CONFIG_DESIGNWARE_WATCHDOG
is enabled. Fix it.

Signed-off-by: Anatolij Gustschin 
---
 common/board_f.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/common/board_f.c b/common/board_f.c
index 622093a..0e2e6bc 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -117,6 +117,7 @@ static int init_func_watchdog_init(void)
 # if defined(CONFIG_HW_WATCHDOG) && (defined(CONFIG_BLACKFIN) || \
defined(CONFIG_M68K) || defined(CONFIG_MICROBLAZE) || \
defined(CONFIG_SH) || defined(CONFIG_AT91SAM9_WATCHDOG) || \
+   defined(CONFIG_DESIGNWARE_WATCHDOG) || \
defined(CONFIG_IMX_WATCHDOG))
hw_watchdog_init();
 # endif
-- 
1.7.9.5

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

[U-Boot] U-boot Minnowmax image overlaps with region './board/intel/minnowmax/vga.bin'

[vinoth eswaran]

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.

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

[U-Boot] [PATCH] arm: Fix setjmp

[Alexander Graf]

The setjmp/longjmp implementation did not work on thumb1 implementations
because it used instruction encodings that don't exist on thumb1 yet.

This patch limits itself to thumb1 instruction set for 32bit arm and
removes a superfluous printf along the way.

Signed-off-by: Alexander Graf 
---
 arch/arm/include/asm/setjmp.h | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/arch/arm/include/asm/setjmp.h b/arch/arm/include/asm/setjmp.h
index b8b85b7..ae738b2 100644
--- a/arch/arm/include/asm/setjmp.h
+++ b/arch/arm/include/asm/setjmp.h
@@ -43,13 +43,14 @@ static inline int setjmp(jmp_buf jmp)
 #else
asm volatile(
 #ifdef CONFIG_SYS_THUMB_BUILD
-   "adr r0, jmp_target + 1\n"
+   "adr r0, jmp_target\n"
+   "add r0, r0, $1\n"
 #else
"adr r0, jmp_target\n"
 #endif
"mov r1, %1\n"
"mov r2, sp\n"
-   "stm r1, {r0, r2, r4, r5, r6, r7}\n"
+   "stm r1!, {r0, r2, r4, r5, r6, r7}\n"
"b 2f\n"
"jmp_target: "
"mov %0, #1\n"
@@ -61,8 +62,6 @@ static inline int setjmp(jmp_buf jmp)
  "cc", "memory");
 #endif
 
-printf("%s:%d target=%#lx\n", __func__, __LINE__, jmp->target);
-
return r;
 }
 
@@ -84,7 +83,7 @@ static inline __noreturn void longjmp(jmp_buf jmp)
 #else
asm volatile(
"mov r1, %0\n"
-   "ldm r1, {r0, r2, r4, r5, r6, r7}\n"
+   "ldm r1!, {r0, r2, r4, r5, r6, r7}\n"
"mov sp, r2\n"
"bx r0\n"
:
-- 
1.8.5.6

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

Re: [U-Boot] [PATCH v3 11/11] sunxi: Add PSCI implementation in C

[Chen-Yu Tsai]

On Mon, Jun 13, 2016 at 5:49 PM, Hans de Goede  wrote:
> Hi,
>
> On 13-06-16 04:50, Chen-Yu Tsai wrote:
>>
>> On Fri, Jun 10, 2016 at 9:40 PM, Hans de Goede 
>> wrote:
>>>
>>> Hi,
>>>
>>> On 07-06-16 04:54, Chen-Yu Tsai wrote:


 To make the PSCI backend more maintainable and easier to port to newer
 SoCs, rewrite the current PSCI implementation in C.

 Some inline assembly bits are required to access coprocessor registers.
 PSCI stack setup is the only part left completely in assembly. In theory
 this part could be split out of psci_arch_init into a separate common
 function, and psci_arch_init could be completely in C.

 Signed-off-by: Chen-Yu Tsai 
>>>
>>>
>>>
>>> I tried merging this in my tree to add it to u-boot-sunxi/next, but
>>> unfortunately it triggers a bug in gcc-6.1, I've filed a bug with
>>> gcc to get this fixed:
>>>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1344717
>>
>>
>> Interesting. Seems like the compiler should be emitting LDMFD instead
>> of POP, or a POP followed by a SUBS/MOVS.
>>
>>>
>>> Also cp15_read_scr / cp15_write_scr are missing __secure notations.
>>
>>
>> Do you want me to send a new version for this?
>
>
> No, I already have a local branch with this fixed.
>
> As for getting this merged and Tom's "go for it"
> comment earlier, I consider this a blocker for merging, sorry.
>
> I hope that the gcc folks can resolve this soon and that I can
> get the Fedora devs to deploy a fix soon-ish. I'm not sure what
> other distros are doing wrt jumping to gcc-6.1, but having code
> in u-boot master which does not build with the latest gcc seems
> like a bad idea.

This is marked as resolved upstream:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70830

And Debian/Ubuntu seems to have pulled the fix into their latest
unstable package:


http://metadata.ftp-master.debian.org/changelogs//main/g/gcc-6/gcc-6_6.1.1-6_changelog

I'm not familiar with Fedora, though you could reference the GCC
PR I listed above and have them pull in the fix.

Interesting that Fedora only provides one version of GCC though.

Regards
ChenYu

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

Re: [U-Boot] [PATCH 24/27] dm: zynq: usb: Convert to CONFIG_DM_USB

[Michal Simek]

Hi Simon,

2016-06-13 7:30 GMT+02:00 Simon Glass :

> Convert zynq USB to driver model. It does not actually work, but the error
> is similar.
>
>
The first one is working. That low level init failed is there because there
are two usb controllers and one is not wired.
If you put usb stick to zybo you will see storage device there.

That's why this patch is breaking usb support.

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

[Maxime Ripard]

Hi Pantelis,

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?

That would probably be safer yes, I'll change that.

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

Ack.

> > +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.
> 
> > +   target = fdt_overlay_get_target(dt, dto, fragment);
> > +   if (target < 0)
> > +   return target;
> > +
> 
> So you could do ‘if (target < 0) continue;’ or handle a more complex error 
> code.

Ok, will change.

> I would caution against the liberal use of malloc in libfdt. We’re
> possibly running in a constrained environment; a custom extents
> based (non freeing) allocator should be better.

David had the same comments, and I will drop the mallocs entirely.

> We need some figures about memory consumption when this is enabled,
> and a CONFIG option to disable it.

The current code (before and after that patch) adds 18kB to a
sandbox_defconfig.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


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

Re: [U-Boot] [PATCH v3 11/11] sunxi: Add PSCI implementation in C

[Hans de Goede]

Hi,

On 13-06-16 04:50, Chen-Yu Tsai wrote:

On Fri, Jun 10, 2016 at 9:40 PM, Hans de Goede  wrote:

Hi,

On 07-06-16 04:54, Chen-Yu Tsai wrote:


To make the PSCI backend more maintainable and easier to port to newer
SoCs, rewrite the current PSCI implementation in C.

Some inline assembly bits are required to access coprocessor registers.
PSCI stack setup is the only part left completely in assembly. In theory
this part could be split out of psci_arch_init into a separate common
function, and psci_arch_init could be completely in C.

Signed-off-by: Chen-Yu Tsai 



I tried merging this in my tree to add it to u-boot-sunxi/next, but
unfortunately it triggers a bug in gcc-6.1, I've filed a bug with
gcc to get this fixed:

https://bugzilla.redhat.com/show_bug.cgi?id=1344717


Interesting. Seems like the compiler should be emitting LDMFD instead
of POP, or a POP followed by a SUBS/MOVS.



Also cp15_read_scr / cp15_write_scr are missing __secure notations.


Do you want me to send a new version for this?


No, I already have a local branch with this fixed.

As for getting this merged and Tom's "go for it"
comment earlier, I consider this a blocker for merging, sorry.

I hope that the gcc folks can resolve this soon and that I can
get the Fedora devs to deploy a fix soon-ish. I'm not sure what
other distros are doing wrt jumping to gcc-6.1, but having code
in u-boot master which does not build with the latest gcc seems
like a bad idea.

Regards,

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

[U-Boot] U-boot VESA driver Initialization

[vinoth eswaran]

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'
I understand that the Linux kernel expects the underlying boot loader to
setup some initialization which is missing in this case.

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.


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] [PATCH] pico-imx6ul: Add Ethernet support

[Stefano Babic]

On 10/06/2016 17:07, Diego Dorta wrote:
> Pico-imx6ul has a KSZ8081 Ethernet PHY.
> 
> Add support for it.
> 
> Signed-off-by: Diego Dorta 
> ---
>  board/technexion/pico-imx6ul/pico-imx6ul.c | 84 
> ++
>  include/configs/pico-imx6ul.h  | 10 
>  2 files changed, 94 insertions(+)
> 
> diff --git a/board/technexion/pico-imx6ul/pico-imx6ul.c 
> b/board/technexion/pico-imx6ul/pico-imx6ul.c
> index c038d43..fc746ec 100644
> --- a/board/technexion/pico-imx6ul/pico-imx6ul.c
> +++ b/board/technexion/pico-imx6ul/pico-imx6ul.c
> @@ -16,6 +16,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -34,6 +36,87 @@ DECLARE_GLOBAL_DATA_PTR;
>   PAD_CTL_PUS_47K_UP  | PAD_CTL_SPEED_LOW |   \
>   PAD_CTL_DSE_80ohm   | PAD_CTL_SRE_FAST  | PAD_CTL_HYS)
>  
> +#define MDIO_PAD_CTRL  (PAD_CTL_PUS_100K_UP | PAD_CTL_PUE | \
> + PAD_CTL_DSE_48ohm   | PAD_CTL_SRE_FAST | PAD_CTL_ODE)
> +
> +#define ENET_PAD_CTRL  (PAD_CTL_PUS_100K_UP | PAD_CTL_PUE | \
> + PAD_CTL_SPEED_HIGH   |   \
> + PAD_CTL_DSE_48ohm   | PAD_CTL_SRE_FAST)
> +
> +#define ENET_CLK_PAD_CTRL  (PAD_CTL_DSE_40ohm   | PAD_CTL_SRE_FAST)
> +
> +#define RMII_PHY_RESET IMX_GPIO_NR(1, 28)
> +
> +static iomux_v3_cfg_t const fec_pads[] = {
> + MX6_PAD_ENET1_TX_EN__ENET2_MDC  | MUX_PAD_CTRL(MDIO_PAD_CTRL),
> + MX6_PAD_ENET1_TX_DATA1__ENET2_MDIO  | MUX_PAD_CTRL(MDIO_PAD_CTRL),
> + MX6_PAD_ENET2_TX_DATA0__ENET2_TDATA00   | MUX_PAD_CTRL(ENET_PAD_CTRL),
> + MX6_PAD_ENET2_TX_DATA1__ENET2_TDATA01   | MUX_PAD_CTRL(ENET_PAD_CTRL),
> + MX6_PAD_ENET2_TX_CLK__ENET2_REF_CLK2| 
> MUX_PAD_CTRL(ENET_CLK_PAD_CTRL),
> + MX6_PAD_ENET2_TX_EN__ENET2_TX_EN| MUX_PAD_CTRL(ENET_PAD_CTRL),
> + MX6_PAD_ENET2_RX_DATA0__ENET2_RDATA00   | MUX_PAD_CTRL(ENET_PAD_CTRL),
> + MX6_PAD_ENET2_RX_DATA1__ENET2_RDATA01   | MUX_PAD_CTRL(ENET_PAD_CTRL),
> + MX6_PAD_ENET2_RX_EN__ENET2_RX_EN| MUX_PAD_CTRL(ENET_PAD_CTRL),
> + MX6_PAD_ENET2_RX_ER__ENET2_RX_ER| MUX_PAD_CTRL(ENET_PAD_CTRL),
> + MX6_PAD_UART4_TX_DATA__GPIO1_IO28   | MUX_PAD_CTRL(NO_PAD_CTRL),
> +};
> +
> +static void setup_iomux_fec(void)
> +{
> + imx_iomux_v3_setup_multiple_pads(fec_pads, ARRAY_SIZE(fec_pads));
> +}
> +
> +int board_eth_init(bd_t *bis)
> +{
> + setup_iomux_fec();
> +
> + gpio_direction_output(RMII_PHY_RESET, 0);
> + /*
> +  * According to KSZ8081MNX-RNB manual:
> +  * For warm reset, the reset (RST#) pin should be asserted low for a
> +  * minimum of 500μs.  The strap-in pin values are read and updated
> +  * at the de-assertion of reset.
> +  */
> + udelay(500);
> +
> + gpio_direction_output(RMII_PHY_RESET, 1);
> + /*
> +  * According to KSZ8081MNX-RNB manual:
> +  * After the de-assertion of reset, wait a minimum of 100μs before
> +  * starting programming on the MIIM (MDC/MDIO) interface.
> +  */
> + udelay(100);
> +
> + return fecmxc_initialize(bis);
> +}
> +
> +static int setup_fec(void)
> +{
> + struct iomuxc *const iomuxc_regs = (struct iomuxc *)IOMUXC_BASE_ADDR;
> + int ret;
> +
> + clrsetbits_le32(_regs->gpr[1], IOMUX_GPR1_FEC2_MASK,
> + IOMUX_GPR1_FEC2_CLOCK_MUX1_SEL_MASK);
> +
> + ret = enable_fec_anatop_clock(1, ENET_50MHZ);
> + if (ret)
> + return ret;
> +
> + enable_enet_clk(1);
> +
> + return 0;
> +}
> +
> +int board_phy_config(struct phy_device *phydev)
> +{
> + phy_write(phydev, MDIO_DEVAD_NONE, 0x1f, 0x8190);
> +
> + if (phydev->drv->config)
> + phydev->drv->config(phydev);
> +
> + return 0;
> +}
> +
>  int dram_init(void)
>  {
>   gd->ram_size = imx_ddr_size();
> @@ -106,6 +189,7 @@ int board_init(void)
>   /* Address of boot parameters */
>   gd->bd->bi_boot_params = PHYS_SDRAM + 0x100;
>  
> + setup_fec();
>   setup_usb();
>  
>   return 0;
> diff --git a/include/configs/pico-imx6ul.h b/include/configs/pico-imx6ul.h
> index d848ead..73e37e1 100644
> --- a/include/configs/pico-imx6ul.h
> +++ b/include/configs/pico-imx6ul.h
> @@ -17,6 +17,16 @@
>  #define CONFIG_DISPLAY_CPUINFO
>  #define CONFIG_DISPLAY_BOARDINFO
>  
> +/* Network support */
> +
> +#define CONFIG_FEC_MXC
> +#define CONFIG_MII
> +#define IMX_FEC_BASE ENET2_BASE_ADDR
> +#define CONFIG_FEC_MXC_PHYADDR   0x1
> +#define CONFIG_FEC_XCV_TYPE  RMII
> +#define CONFIG_PHYLIB
> +#define CONFIG_PHY_MICREL
> +
>  /* Size of malloc() pool */
>  #define CONFIG_SYS_MALLOC_LEN(16 * SZ_1M)
>  
> 

Reviewed-by: Stefano Babic 

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 

Re: [U-Boot] [PATCH v2 5/9] libfdt: Add iterator over properties

[Maxime Ripard]

Hi Pantelis,

On Fri, Jun 10, 2016 at 05:04:45PM +0300, Pantelis Antoniou wrote:
> 
> > On May 27, 2016, at 12:13 , Maxime Ripard 
> >  wrote:
> > 
> > Implement a macro based on fdt_first_property_offset and
> > fdt_next_property_offset that provides a convenience to iterate over all
> > the properties of a given node.
> > 
> > Signed-off-by: Maxime Ripard 
> > ---
> > include/libfdt.h | 24 
> > 1 file changed, 24 insertions(+)
> > 
> > diff --git a/include/libfdt.h b/include/libfdt.h
> > index 74b1d149c2dd..4e8eb9ede3a4 100644
> > --- a/include/libfdt.h
> > +++ b/include/libfdt.h
> > @@ -441,6 +441,30 @@ int fdt_first_property_offset(const void *fdt, int 
> > nodeoffset);
> > int fdt_next_property_offset(const void *fdt, int offset);
> > 
> > /**
> > + * fdt_for_each_property - iterate over all properties of a node
> > + * @fdt:   FDT blob (const void *)
> > + * @node:  node offset (int)
> > + * @property:  property offset (int)
> > + *
> > + * This is actually a wrapper around a for loop and would be used like so:
> > + *
> > + * fdt_for_each_property(fdt, node, property) {
> > + * ...
> > + * use property
> > + * ...
> > + * }
> > + *
> > + * Note that this is implemented as a macro and property is used as
> > + * iterator in the loop. It should therefore be a locally allocated
> > + * variable. The node variable on the other hand is never modified, so
> > + * it can be constant or even a literal.
> > + */
> > +#define fdt_for_each_property(fdt, node, property) \
> > +   for (property = fdt_first_property_offset(fdt, node);   \
> > +property >= 0; \
> > +property = fdt_next_property_offset(fdt, property))
> > +
> > +/**
> >  * fdt_get_property_by_offset - retrieve the property at a given offset
> >  * @fdt: pointer to the device tree blob
> >  * @offset: offset of the property to retrieve
> > -- 
> > 2.8.2
> > 
> 
> Acked-by: Pantelis Antoniou 
> 
> I’d like to see this merged in dtc upstream please too.

This has been sent. David made a couple of comments, I'll address them
and respin.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


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

Re: [U-Boot] [PATCH v2 4/9] libfdt: Add new headers and defines

[Maxime Ripard]

Hi David,

On Sat, Jun 11, 2016 at 08:30:35PM +1000, David Gibson wrote:
> On Fri, Jun 10, 2016 at 05:03:36PM +0300, Pantelis Antoniou wrote:
> > Hi Maxime,
> > 
> > > On May 27, 2016, at 12:13 , Maxime Ripard 
> > >  wrote:
> > > 
> > > The libfdt overlay support introduces a bunch of new includes and
> > > functions.
> > > 
> > > Make sure we are able to build it by adding the needed glue.
> > > 
> > > Signed-off-by: Maxime Ripard 
> > > ---
> > > include/libfdt_env.h | 7 +++
> > > 1 file changed, 7 insertions(+)
> > > 
> > > diff --git a/include/libfdt_env.h b/include/libfdt_env.h
> > > index 273b5d30f867..2d2196031332 100644
> > > --- a/include/libfdt_env.h
> > > +++ b/include/libfdt_env.h
> > > @@ -23,6 +23,13 @@ typedef __be64 fdt64_t;
> > > #define fdt64_to_cpu(x)   be64_to_cpu(x)
> > > #define cpu_to_fdt64(x)   cpu_to_be64(x)
> > > 
> > > +#ifdef __UBOOT__
> > > +#include "malloc.h"
> > > +#include "vsprintf.h"
> > > +
> > > +#define strtol(cp, endp, base)   simple_strtol(cp, endp, base)
> > > +#endif
> > > +
> > > /* adding a ramdisk needs 0x44 bytes in version 2008.10 */
> > > #define FDT_RAMDISK_OVERHEAD  0x80
> > > 
> > 
> > We need to figure out what the upstream libfdt/dtc maintainer’s take is on 
> > this is.
> > For u-boot we’re fine and for now it’s OK.
> 
> These were sent to the upstream dtc list as well.
> 
> The concept is fine, but there are a number of problems in the
> implementation.  I sent detailed review comments on the upstream
> versions, haven't seen a respin yet.

Yes, thanks a lot for your comments, I'll address them and resend a
new serie.

(it might not be before a couple of weeks though).

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


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

[U-Boot] HTTP access to u-boot-x86

[Philipp, Damian]

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.

Best Regards

Damian Philipp

Software Development Engineer 
RDE1

Vector Informatik GmbH
Ingersheimer Str. 24
70499 Stuttgart
Germany
Tel.: +49 711 80670-3656
Fax: +49 711 80670-399
mailto: damian.phil...@vector.com
Internet: www.vector.com

Head Office: Stuttgart
Commercial Register: Amtsgericht Stuttgart, HRB 17317
Managing Directors:
Dr. Thomas Beck, Thomas Riegraf


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

Re: [U-Boot] [PATCHV5 4/6] ARMv8/Layerscape: switch SMP method accordingly

[Zhiqiang Hou]

Hi York,

> -Original Message-
> From: Zhiqiang Hou
> Sent: 2016年6月12日 12:31
> To: york sun ; u-boot@lists.denx.de;
> albert.u.b...@aribaud.net; scottw...@freescale.com;
> mingkai...@freescale.com; york...@freescale.com; le...@freescale.com;
> prabha...@freescale.com; bhupesh.sha...@freescale.com
> Subject: RE: [PATCHV5 4/6] ARMv8/Layerscape: switch SMP method accordingly
> 
> Hi York,
> 
> Thanks for your comments!
> 
> > -Original Message-
> > From: york sun
> > Sent: 2016年6月12日 12:07
> > To: Zhiqiang Hou ; u-boot@lists.denx.de;
> > albert.u.b...@aribaud.net; scottw...@freescale.com;
> > mingkai...@freescale.com; york...@freescale.com; le...@freescale.com;
> > prabha...@freescale.com; bhupesh.sha...@freescale.com
> > Subject: Re: [PATCHV5 4/6] ARMv8/Layerscape: switch SMP method
> > accordingly
> >
> > On 06/11/2016 08:58 PM, Zhiqiang Hou wrote:
> > > Hi York,
> > >
> > > Thanks for your comments!
> > >
> > >> -Original Message-
> > >> From: York Sun [mailto:york@nxp.com]
> > >> Sent: 2016年6月8日 8:56
> > >> To: Zhiqiang Hou ; u-boot@lists.denx.de;
> > >> albert.u.b...@aribaud.net; scottw...@freescale.com;
> > >> mingkai...@freescale.com; york...@freescale.com;
> > >> le...@freescale.com; prabha...@freescale.com;
> > >> bhupesh.sha...@freescale.com
> > >> Subject: Re: [PATCHV5 4/6] ARMv8/Layerscape: switch SMP method
> > >> accordingly
> > >>
> > >> On 06/04/2016 11:40 PM, Zhiqiang Hou wrote:
> > >>> From: Hou Zhiqiang 
> > >>>
> > >>> If the PSCI and PPA is ready, skip the fixup for spin-table and
> > >>> waking secondary cores. If not, change SMP method to spin-table,
> > >>> and the device node of PSCI will be removed.
> > >>>
> > >>> Signed-off-by: Hou Zhiqiang 
> > >>> ---
> > >>> V5:
> > >>>   - Changed the checking if the PSCI feature is ready to read the psci 
> > >>> version.
> > >>>
> > >>> V4:
> > >>>   - Reordered this patch.
> > >>>
> > >>>   arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 17 +---
> > >>> arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 36
> > >>> +
> > >>>   2 files changed, 50 insertions(+), 3 deletions(-)
> > >>>
> > >>> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> > >>> b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> > >>> index 672a453..eb566cd 100644
> > >>> --- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> > >>> +++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> > >>> @@ -23,6 +23,9 @@
> > >>>   #ifdef CONFIG_FSL_ESDHC
> > >>>   #include 
> > >>>   #endif
> > >>> +#ifdef CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT #include
> > >>> + #endif
> > >>>
> > >>>   DECLARE_GLOBAL_DATA_PTR;
> > >>>
> > >>> @@ -618,6 +621,7 @@ int arch_early_init_r(void)  {  #ifdef CONFIG_MP
> > >>> int rv = 1;
> > >>> +   bool psci_support = false;
> > >>>   #endif
> > >>>
> > >>>   #ifdef CONFIG_SYS_FSL_ERRATUM_A009635 @@ -625,9 +629,16 @@ int
> > >>> arch_early_init_r(void)  #endif
> > >>>
> > >>>   #ifdef CONFIG_MP
> > >>> -   rv = fsl_layerscape_wake_seconday_cores();
> > >>> -   if (rv)
> > >>> -   printf("Did not wake secondary cores\n");
> > >>> +#if defined(CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT) &&
> > >> defined(CONFIG_ARMV8_PSCI)
> > >>> +   /* Check the psci version to determine if the psci is supported 
> > >>> */
> > >>> +   psci_support = (int)sec_firmware_support_psci_version() > 0 ?
> > >>> +   true : false;
> > >>
> > >> Another comment, even if the function can be used to indicate if
> > >> psci is available, do you have to cast it to (int)? I think this can be 
> > >> simplified as
> > >>  psci_support = sec_firmware_support_psci_version() > 0;
> > >
> > > The type of this func return value is 'unsigned int', so the cast is 
> > > necessary.
> >
> > The return value of function sec_firmware_support_psci_version() may
> > need some work. It has three results
> >
> > Positive numbers mean success (presuming bit 31 is not used by major number.
> > Need to check with PPA code) Zero means image is not valid Negative
> > numbers means errors
> 
> In PSCI spec v1.0, the bit 31 is used by major number, and the type of the 
> return
> value is uint, but there isn't any other description for the return value. I 
> don't know
> why the PPA isn't consistent with PSCI spec.

I misunderstand your words, and the PPA is consistent with PSCI spec.
Will take your suggestion that presuming bit 31 isn't used by major number to 
handle
the return value.
 
> > If the error code doesn't include -EINVAL, you can return -EINVAL in
> > case of an invalid image. Then you can have
> > sec_firmware_support_psci_version() return int.
> >

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

Re: [U-Boot] [PATCH v2 4/5] autoboot: fix a bunch of misconversion of CONFIG_BOOTDELAY

[Stefano Babic]

Hi,

On 11/06/2016 13:31, Hans de Goede wrote:
> Hi,
> 
> On 11-06-16 11:44, Masahiro Yamada wrote:
>> Commit bb597c0eeb7e ("common: bootdelay: move CONFIG_BOOTDELAY into
>> a Kconfig option") made a number of misconversion.
>>
>> [1] CONFIG_BOOTDELAY=-1 all gone
>> [2] CONFIG_BOOTDELAY=1 all gone
>> [3] CONFIG_BOOTDELAY=2 all gone
>> [4] Conditionally defined CONFIG_BOOTDELAY all gone
>>
>> All of the misconverted boards now use the default value,
>> CONFIG_BOOTDELAY=0, which came from the Kconfig entry.
>>
>> I am imagining some reasons for this.
>>
>> For [1], due to the bug of tools/scripts/define2mk.sed (now fixed),
>>   #define CONFIG_BOOTDELAY -1
>> was converted to
>>   CONFIG_BOOTDELAY="-1"
>> in the include/autoconf.mk, so the tools/moveconfig.py regarded it
>> as a string type option, and failed to move it.
>>
>> For [2], as you see in the comment block in the define2mk.sed,
>>   #define CONFIG_BOOTDELAY 1
>> is converted to
>>   CONFIG_BOOTDELAY=y
>> in the include/autoconf.mk.  This needs a special care because we do
>> not know whether we are moving a bool option with value y or an
>> integer option with value 1.  A recently-sent patch fixes this issue.
>>
>> I do not understand the reason for [3].
>>
>> [4] is another case the current moveconfig cannot handle correctly.
>> If the define is surrounded by #ifndef CONFIG_BOOTDELAY like follows,
>> the default value from Kconfig entry beats the define in C header.
>>
>>   #ifndef CONFIG_BOOTDELAY
>>   #define CONFIG_BOOTDELAY  3
>>   #endif
>>
>> Joe's patch can solve this issue.
>>
>> Anyway, I ran the newest moveconfig tool based on commit 3191d8408053
>> (=immediately prior to the bad commit) to generate this patch.
>>
>> Signed-off-by: Masahiro Yamada 
>> ---
>>
>> Changes in v2:
>>   - Fix case [4]
>>
>>  configs/A10-OLinuXino-Lime_defconfig  | 1 +
>>  configs/A10s-OLinuXino-M_defconfig| 1 +
>>  configs/A13-OLinuXinoM_defconfig  | 1 +
>>  configs/A13-OLinuXino_defconfig   | 1 +
>>  configs/A20-OLinuXino-Lime2_defconfig | 1 +
>>  configs/A20-OLinuXino-Lime_defconfig  | 1 +
>>  configs/A20-OLinuXino_MICRO_defconfig | 1 +
>>  configs/A20-Olimex-SOM-EVB_defconfig  | 1 +
>>  configs/Ainol_AW1_defconfig   | 1 +
>>  configs/Ampe_A76_defconfig| 1 +
>>  configs/Auxtek-T003_defconfig | 1 +
>>  configs/Auxtek-T004_defconfig | 1 +
>>  configs/Bananapi_defconfig| 1 +
>>  configs/Bananapro_defconfig   | 1 +
>>  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| 1 +
>>  configs/CSQ_CS908_defconfig   | 1 +
>>  configs/Chuwi_V7_CW0825_defconfig | 1 +
>>  configs/Colombus_defconfig| 1 +
>>  configs/Cubieboard2_defconfig | 1 +
>>  configs/Cubieboard_defconfig  | 1 +
>>  configs/Cubietruck_defconfig  | 1 +
>>  configs/Cubietruck_plus_defconfig | 1 +
>>  configs/Empire_electronix_d709_defconfig  | 1 +
>>  configs/Hummingbird_A31_defconfig | 1 +
>>  configs/Hyundai_A7HD_defconfig| 1 +
>>  configs/Itead_Ibox_A20_defconfig  | 1 +
>>  configs/Lamobo_R1_defconfig   | 1 +
>>  configs/Linksprite_pcDuino3_Nano_defconfig| 1 +
>>  configs/Linksprite_pcDuino3_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/M54418TWR_defconfig   | 1 +
>>  configs/M54418TWR_nand_mii_defconfig  | 1 +
>>  configs/M54418TWR_nand_rmii_defconfig | 1 +
>>  configs/M54418TWR_nand_rmii_lowfreq_defconfig | 1 +
>>  configs/M54418TWR_serial_mii_defconfig| 1 +
>>  configs/M54418TWR_serial_rmii_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 +
>>  

Re: [U-Boot] [PATCH v2 0/5] Urgent fixes for misconverted CONFIG_BOOTDELAY

[Heiko Schocher]

Hello Masahiro,

Am 13.06.2016 um 09:53 schrieb yamada.masah...@socionext.com:

Hi Heiko.


Hmm... didn;t you had a script, with which you checked all board binaries
if they are the same before and after one patch? That could be a solution
for doing such Kconfig moves ...


When I converted lots of Makefiles for Kbuild migration more than 2 years ago,
I hacked  include/timestamp.h, include/version.h, and MAKEALL
to show MD5SUM for each board.


You can generate a reproducible build with settings SOURCE_DATE_EPOCH
see README, so the hacks in include/timestamp.h and include/version.h
are not longer necessary.


I noted a small tip in the page 9 of the following slide:
http://www.denx.de/wiki/pub/U-Boot/MiniSummitELCE2014/uboot2014_kconfig.pdf

But, MAKEALL will be removed sooner or later.


Instead, I found an interesting option in Buildman.

   -K, --show-config Show configuration changes in summary (both board
 config files and Kconfig)


I tried it, but the output seems too noisy to check the diff...
(unless I am missing something.)


I do not know, if this is possible with buildman.
Maybe it is possible to add a buildman option to add
printing a md5sum for the resulting images?

bye,
Heiko





-Original Message-
From: Heiko Schocher [mailto:h...@denx.de]
Sent: Monday, June 13, 2016 2:42 PM
To: Yamada, Masahiro/山田 真弘
Cc: Tom Rini; Steve Rae; Lucas Stach; Dimitar Penev; Viresh Kumar; Lars
Poeschel; Albert ARIBAUD (3ADEV); U-Boot Mailing List; Magnus Lilja; Soeren
Moch; Przemyslaw Marczak; Eric Bénard; Valentin Yakovenkov; Wolfgang
Wegner; Stefan Roese; Mark Jonas; Richard Hu; Chander Kashyap; Valentin
Longchamp; Akshay Saraswat; Stephen Warren; Otavio Salvador; Angelo
Dureghello; Peter Meerwald; Thomas Lange; Thomas Abraham; Holger Brunck;
Ash Charles; Ian Campbell; Lauri Hintsala; Markus Niebel; Stefan Agner;
Sergei Poselenov; Tim Kryger; Thomas Weber; Gilles Gameiro; Robert Baldyga;
Phil Han; Lucile Quirion; Lukasz Dalek; Adrian Alonso; Fabio Estevam; Sergey
Kostanbaev; Christophe Ricard; Zoltan Herpai; Nobuhiro Iwamatsu; Oleksandr
Zhadan and Michael Durrant; Vladimir Zapolskiy; Aleksei Mamlin; Po Liu;
Vipin Kumar; Gong Qianyu; Priit Laes; huang lin; Marcel Ziswiler; Joe
Hershberger; Werner Pfister; Felipe Balbi; Kamil Lulko; Marcus Cooper; Tom
Warren; Lothar Felten; I-SYST Micromodule; Enric Balletbo i Serra; Jelle
de Jong; M.Hasewinkel (MHA); Alban Bedel; Daniel Allred; TsiChung Liew
Subject: Re: [U-Boot] [PATCH v2 0/5] Urgent fixes for misconverted
CONFIG_BOOTDELAY

Hello Masahiro,

Am 13.06.2016 um 01:15 schrieb Masahiro Yamada:

Hi Tom,


2016-06-13 6:07 GMT+09:00 Masahiro Yamada

:

Hi Tom,

2016-06-13 1:50 GMT+09:00 Tom Rini :

On Sat, Jun 11, 2016 at 06:44:07PM +0900, Masahiro Yamada wrote:



Masahiro Yamada (5):
ARM: stm32: remove unused CONFIG_AUTOBOOT
autoboot: follow-up cleanup after CONFIG_BOOTDELAY moves
tools: fix define2mk.sed to not add quotes around negative integers
autoboot: fix a bunch of misconversion of CONFIG_BOOTDELAY
autoboot: add CONFIG_AUTOBOOT to allow to not compile autoboot.c


Please put together a PR with everything except the defconfig
changes, along with the other moveconfig.py related fixes for me and
I'll go unbreak everything (along with Hans' patch).  Thanks!



Please let me confirm the ones I should include in my PR.

moveconfig patches and these three?


ARM: stm32: remove unused CONFIG_AUTOBOOT
autoboot: follow-up cleanup after CONFIG_BOOTDELAY moves
tools: fix define2mk.sed to not add quotes around negative
integers




Done.


BTW, would you consider changing the default of BOOTDELAY from 0 to 3
?


Damn, Tom suggested me to change it to 2  and in my rebase to
2016.05-rc1 accidently I used the wrong value

I am sorry for all the trouble ...

Hmm... didn;t you had a script, with which you checked all board binaries
if they are the same before and after one patch? That could be a solution
for doing such Kconfig moves ...

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


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

Re: [U-Boot] [PATCH v2 4/5] autoboot: fix a bunch of misconversion of CONFIG_BOOTDELAY

[Maxime Ripard]

Hi,

On Sat, Jun 11, 2016 at 01:31:29PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 11-06-16 11:44, Masahiro Yamada wrote:
> >Commit bb597c0eeb7e ("common: bootdelay: move CONFIG_BOOTDELAY into
> >a Kconfig option") made a number of misconversion.
> >
> >[1] CONFIG_BOOTDELAY=-1 all gone
> >[2] CONFIG_BOOTDELAY=1 all gone
> >[3] CONFIG_BOOTDELAY=2 all gone
> >[4] Conditionally defined CONFIG_BOOTDELAY all gone
> >
> >All of the misconverted boards now use the default value,
> >CONFIG_BOOTDELAY=0, which came from the Kconfig entry.
> >
> >I am imagining some reasons for this.
> >
> >For [1], due to the bug of tools/scripts/define2mk.sed (now fixed),
> >  #define CONFIG_BOOTDELAY -1
> >was converted to
> >  CONFIG_BOOTDELAY="-1"
> >in the include/autoconf.mk, so the tools/moveconfig.py regarded it
> >as a string type option, and failed to move it.
> >
> >For [2], as you see in the comment block in the define2mk.sed,
> >  #define CONFIG_BOOTDELAY 1
> >is converted to
> >  CONFIG_BOOTDELAY=y
> >in the include/autoconf.mk.  This needs a special care because we do
> >not know whether we are moving a bool option with value y or an
> >integer option with value 1.  A recently-sent patch fixes this issue.
> >
> >I do not understand the reason for [3].
> >
> >[4] is another case the current moveconfig cannot handle correctly.
> >If the define is surrounded by #ifndef CONFIG_BOOTDELAY like follows,
> >the default value from Kconfig entry beats the define in C header.
> >
> >  #ifndef CONFIG_BOOTDELAY
> >  #define CONFIG_BOOTDELAY  3
> >  #endif
> >
> >Joe's patch can solve this issue.
> >
> >Anyway, I ran the newest moveconfig tool based on commit 3191d8408053
> >(=immediately prior to the bad commit) to generate this patch.
> >
> >Signed-off-by: Masahiro Yamada 
> >---
> >
> >Changes in v2:
> >  - Fix case [4]
> >
> > configs/A10-OLinuXino-Lime_defconfig  | 1 +
> > configs/A10s-OLinuXino-M_defconfig| 1 +
> > configs/A13-OLinuXinoM_defconfig  | 1 +
> > configs/A13-OLinuXino_defconfig   | 1 +
> > configs/A20-OLinuXino-Lime2_defconfig | 1 +
> > configs/A20-OLinuXino-Lime_defconfig  | 1 +
> > configs/A20-OLinuXino_MICRO_defconfig | 1 +
> > configs/A20-Olimex-SOM-EVB_defconfig  | 1 +
> > configs/Ainol_AW1_defconfig   | 1 +
> > configs/Ampe_A76_defconfig| 1 +
> > configs/Auxtek-T003_defconfig | 1 +
> > configs/Auxtek-T004_defconfig | 1 +
> > configs/Bananapi_defconfig| 1 +
> > configs/Bananapro_defconfig   | 1 +
> > 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| 1 +
> > configs/CSQ_CS908_defconfig   | 1 +
> > configs/Chuwi_V7_CW0825_defconfig | 1 +
> > configs/Colombus_defconfig| 1 +
> > configs/Cubieboard2_defconfig | 1 +
> > configs/Cubieboard_defconfig  | 1 +
> > configs/Cubietruck_defconfig  | 1 +
> > configs/Cubietruck_plus_defconfig | 1 +
> > configs/Empire_electronix_d709_defconfig  | 1 +
> > configs/Hummingbird_A31_defconfig | 1 +
> > configs/Hyundai_A7HD_defconfig| 1 +
> > configs/Itead_Ibox_A20_defconfig  | 1 +
> > configs/Lamobo_R1_defconfig   | 1 +
> > configs/Linksprite_pcDuino3_Nano_defconfig| 1 +
> > configs/Linksprite_pcDuino3_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/M54418TWR_defconfig   | 1 +
> > configs/M54418TWR_nand_mii_defconfig  | 1 +
> > configs/M54418TWR_nand_rmii_defconfig | 1 +
> > configs/M54418TWR_nand_rmii_lowfreq_defconfig | 1 +
> > configs/M54418TWR_serial_mii_defconfig| 1 +
> > configs/M54418TWR_serial_rmii_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| 

Re: [U-Boot] [PATCH v2 0/5] Urgent fixes for misconverted CONFIG_BOOTDELAY

[yamada.masahiro]

Hi Heiko.

> Hmm... didn;t you had a script, with which you checked all board binaries
> if they are the same before and after one patch? That could be a solution
> for doing such Kconfig moves ...

When I converted lots of Makefiles for Kbuild migration more than 2 years ago,
I hacked  include/timestamp.h, include/version.h, and MAKEALL
to show MD5SUM for each board.

I noted a small tip in the page 9 of the following slide:
http://www.denx.de/wiki/pub/U-Boot/MiniSummitELCE2014/uboot2014_kconfig.pdf

But, MAKEALL will be removed sooner or later.


Instead, I found an interesting option in Buildman.

  -K, --show-config Show configuration changes in summary (both board
config files and Kconfig)


I tried it, but the output seems too noisy to check the diff...
(unless I am missing something.)



> -Original Message-
> From: Heiko Schocher [mailto:h...@denx.de]
> Sent: Monday, June 13, 2016 2:42 PM
> To: Yamada, Masahiro/山田 真弘
> Cc: Tom Rini; Steve Rae; Lucas Stach; Dimitar Penev; Viresh Kumar; Lars
> Poeschel; Albert ARIBAUD (3ADEV); U-Boot Mailing List; Magnus Lilja; Soeren
> Moch; Przemyslaw Marczak; Eric Bénard; Valentin Yakovenkov; Wolfgang
> Wegner; Stefan Roese; Mark Jonas; Richard Hu; Chander Kashyap; Valentin
> Longchamp; Akshay Saraswat; Stephen Warren; Otavio Salvador; Angelo
> Dureghello; Peter Meerwald; Thomas Lange; Thomas Abraham; Holger Brunck;
> Ash Charles; Ian Campbell; Lauri Hintsala; Markus Niebel; Stefan Agner;
> Sergei Poselenov; Tim Kryger; Thomas Weber; Gilles Gameiro; Robert Baldyga;
> Phil Han; Lucile Quirion; Lukasz Dalek; Adrian Alonso; Fabio Estevam; Sergey
> Kostanbaev; Christophe Ricard; Zoltan Herpai; Nobuhiro Iwamatsu; Oleksandr
> Zhadan and Michael Durrant; Vladimir Zapolskiy; Aleksei Mamlin; Po Liu;
> Vipin Kumar; Gong Qianyu; Priit Laes; huang lin; Marcel Ziswiler; Joe
> Hershberger; Werner Pfister; Felipe Balbi; Kamil Lulko; Marcus Cooper; Tom
> Warren; Lothar Felten; I-SYST Micromodule; Enric Balletbo i Serra; Jelle
> de Jong; M.Hasewinkel (MHA); Alban Bedel; Daniel Allred; TsiChung Liew
> Subject: Re: [U-Boot] [PATCH v2 0/5] Urgent fixes for misconverted
> CONFIG_BOOTDELAY
> 
> Hello Masahiro,
> 
> Am 13.06.2016 um 01:15 schrieb Masahiro Yamada:
> > Hi Tom,
> >
> >
> > 2016-06-13 6:07 GMT+09:00 Masahiro Yamada
> :
> >> Hi Tom,
> >>
> >> 2016-06-13 1:50 GMT+09:00 Tom Rini :
> >>> On Sat, Jun 11, 2016 at 06:44:07PM +0900, Masahiro Yamada wrote:
> >>>
> 
>  Masahiro Yamada (5):
> ARM: stm32: remove unused CONFIG_AUTOBOOT
> autoboot: follow-up cleanup after CONFIG_BOOTDELAY moves
> tools: fix define2mk.sed to not add quotes around negative integers
> autoboot: fix a bunch of misconversion of CONFIG_BOOTDELAY
> autoboot: add CONFIG_AUTOBOOT to allow to not compile autoboot.c
> >>>
> >>> Please put together a PR with everything except the defconfig
> >>> changes, along with the other moveconfig.py related fixes for me and
> >>> I'll go unbreak everything (along with Hans' patch).  Thanks!
> >>
> >>
> >> Please let me confirm the ones I should include in my PR.
> >>
> >> moveconfig patches and these three?
> >>
> ARM: stm32: remove unused CONFIG_AUTOBOOT
> autoboot: follow-up cleanup after CONFIG_BOOTDELAY moves
> tools: fix define2mk.sed to not add quotes around negative
>  integers
> >>
> >
> > Done.
> >
> >
> > BTW, would you consider changing the default of BOOTDELAY from 0 to 3
> > ?
> 
> Damn, Tom suggested me to change it to 2  and in my rebase to
> 2016.05-rc1 accidently I used the wrong value
> 
> I am sorry for all the trouble ...
> 
> Hmm... didn;t you had a script, with which you checked all board binaries
> if they are the same before and after one patch? That could be a solution
> for doing such Kconfig moves ...
> 
> bye,
> Heiko
> --
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v3 2/2] nand: extend nand torture

[Max Krummenacher]

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], )) {
+   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,10 @@ Miscellaneous and testing commands:
   automate actions following a nand->write() error. This would e.g. be required
   in order to program or update safely firmware to NAND, especially for the UBI
   part of such firmware.
+  Optionally, a second parameter size can 

[U-Boot] [PATCH v3 1/2] nand: nand torture: follow sync with linux v4.6

[Max Krummenacher]

follow parameter name change (nand to mtd) to fix compiler error.

Signed-off-by: Max Krummenacher 

---

Changes in v3:
- none

Changes in v2:
- Patch v1 1/1 went into master, but Scott's patch series syncing
  with kernel v4.6 introduced an additional compile time error.

 drivers/mtd/nand/nand_util.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/nand_util.c b/drivers/mtd/nand/nand_util.c
index 5bba66a..e8bcc34 100644
--- a/drivers/mtd/nand/nand_util.c
+++ b/drivers/mtd/nand/nand_util.c
@@ -820,7 +820,7 @@ int nand_torture(struct mtd_info *mtd, loff_t offset)
 {
u_char patterns[] = {0xa5, 0x5a, 0x00};
struct erase_info instr = {
-   .mtd = nand,
+   .mtd = mtd,
.addr = offset,
.len = mtd->erasesize,
};
-- 
2.5.5

___
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

[Chris Packham]

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.

> ---
>  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([0]);
> -   u32 addr_hi = __get_unaligned_le16([4]);
> +   u32 addr_lo = get_unaligned_le32([0]);
> +   u32 addr_hi = get_unaligned_le16([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

[U-Boot] [PATCH] net: smsc95xx: Use correct get_unaligned functions

[Mark Tomlinson]

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
Reviewed-by: Chris Packham 
---
 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([0]);
-   u32 addr_hi = __get_unaligned_le16([4]);
+   u32 addr_lo = get_unaligned_le32([0]);
+   u32 addr_hi = get_unaligned_le16([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

Re: [U-Boot] [PATCH v2 0/5] Urgent fixes for misconverted CONFIG_BOOTDELAY

[Heiko Schocher]

Hello Masahiro,

Am 13.06.2016 um 01:15 schrieb Masahiro Yamada:

Hi Tom,


2016-06-13 6:07 GMT+09:00 Masahiro Yamada :

Hi Tom,

2016-06-13 1:50 GMT+09:00 Tom Rini :

On Sat, Jun 11, 2016 at 06:44:07PM +0900, Masahiro Yamada wrote:



Masahiro Yamada (5):
   ARM: stm32: remove unused CONFIG_AUTOBOOT
   autoboot: follow-up cleanup after CONFIG_BOOTDELAY moves
   tools: fix define2mk.sed to not add quotes around negative integers
   autoboot: fix a bunch of misconversion of CONFIG_BOOTDELAY
   autoboot: add CONFIG_AUTOBOOT to allow to not compile autoboot.c


Please put together a PR with everything except the defconfig changes,
along with the other moveconfig.py related fixes for me and I'll go
unbreak everything (along with Hans' patch).  Thanks!



Please let me confirm the ones I should include in my PR.

moveconfig patches and these three?


   ARM: stm32: remove unused CONFIG_AUTOBOOT
   autoboot: follow-up cleanup after CONFIG_BOOTDELAY moves
   tools: fix define2mk.sed to not add quotes around negative integers




Done.


BTW, would you consider changing the default of BOOTDELAY
from 0 to 3 ?


Damn, Tom suggested me to change it to 2  and in my rebase to
2016.05-rc1 accidently I used the wrong value

I am sorry for all the trouble ...

Hmm... didn;t you had a script, with which you checked all board
binaries if they are the same before and after one patch? That could
be a solution for doing such Kconfig moves ...

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

[U-Boot] [PATCH 00/27] dm: mmc: Add driver-model support for MMC operations

[Simon Glass]

At present MMC does not use driver model for its operations. It uses its own
structure and passes a struct mmc instead of a struct udevice.

This series addresses this by adding driver-model operations for MMC. The
conversion process is also started, with patches for rockchip, zynq and
qualcomm.

The zynq patches are a starting point only and need more work.


Simon Glass (27):
  dm: mmc: dwmmc: Add comments to the dwmmc setup functions
  rockchip: Use 'select' instead of defaults in Kconfig
  mmc: Add function declarations for mmc_bread() and mmc_switch_part()
  dm: mmc: Move CONFIG_BLK code into the mmc uclass
  dm: mmc: Move non-CONFIG_BLK code into mmc_legacy.c
  mmc: Move MMC boot code into its own file
  dm: mmc: rockchip: Support only CONFIG_BLK
  mmc: Move tracing code into separate functions
  rockchip: Disable CONFIG_SDHCI
  dm: mmc: Add a way to use driver model for MMC operations
  dm: mmc: dwmmc: Support CONFIG_DM_MMC_OPS
  dm: mmc: rockchip: Enable CONFIG_DM_MMC_OPS for all boards
  rockchip: Add MAINTAINER files for kylin_rk3036, evb_rk3036
  dm: sandbox: Convert to use CONFIG_CMD_MMC_OPS
  dm: mmc: sdhci: Refactor configuration setup to support DM
  dm: mmc: sdhci: Support CONFIG_BLK and CONFIG_DM_MMC_OPS
  dm: mmc: msm_sdhci: Support CONFIG_BLK and CONFIG_DM_MMC_OPS
  dm: mmc: Move dragonboard410c to use CONFIG_BLK and CONFIG_DM_MMC_OPS
  dm: mmc: msmsdhic: Drop old MMC code
  dm: spl: mmc: Support CONFIG_BLK in SPL MMC
  dm: dfu: mmc: Support CONFIG_BLK in DFU for MMC
  net: phy: marvell: Add a missing errno.h header
  zynq: Increase the early malloc() size
  dm: zynq: usb: Convert to CONFIG_DM_USB
  dm: mmc: zynq: Convert zynq to use driver model for MMC
  dm: mmc: Enable DM_MMC_OPS by default with DM_MMC
  dm: blk: Enable CONFIG_BLK if DM_MMC is enabled

 arch/Kconfig|   1 +
 arch/arm/Kconfig|  18 ++
 arch/arm/cpu/armv8/zynqmp/Kconfig   |   4 +
 arch/arm/mach-rockchip/Kconfig  |  27 ---
 arch/arm/mach-zynq/Kconfig  |   3 +
 board/evb_rk3036/evb_rk3036/MAINTAINERS |   6 +
 board/kylin/kylin_rk3036/MAINTAINERS|   6 +
 common/spl/spl_mmc.c|   6 +-
 configs/dragonboard410c_defconfig   |   2 +
 configs/sandbox_defconfig   |   4 +-
 drivers/block/Kconfig   |   1 +
 drivers/dfu/dfu_mmc.c   |  11 +-
 drivers/mmc/Kconfig |  12 +-
 drivers/mmc/Makefile|   3 +
 drivers/mmc/dw_mmc.c|  33 +++
 drivers/mmc/mmc-uclass.c| 146 +
 drivers/mmc/mmc.c   | 371 +---
 drivers/mmc/mmc_boot.c  | 131 +++
 drivers/mmc/mmc_legacy.c|  91 
 drivers/mmc/mmc_private.h   |  47 
 drivers/mmc/msm_sdhci.c |  38 +++-
 drivers/mmc/rockchip_dw_mmc.c   |  14 +-
 drivers/mmc/sandbox_mmc.c   |  17 +-
 drivers/mmc/sdhci.c | 147 -
 drivers/mmc/zynq_sdhci.c|  39 +++-
 drivers/net/phy/marvell.c   |   1 +
 drivers/usb/host/ehci-zynq.c| 102 +
 include/configs/rk3036_common.h |   1 -
 include/configs/rk3288_common.h |   1 -
 include/dwmmc.h |  73 +++
 include/mmc.h   |  66 +-
 include/sdhci.h |  80 +++
 32 files changed, 1006 insertions(+), 496 deletions(-)
 create mode 100644 drivers/mmc/mmc_boot.c

-- 
2.8.0.rc3.226.g39d4020

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

[U-Boot] Pull request: u-boot-ubi/master

[Heiko Schocher]

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

  common: env_ubi: Clear environment buffer before reading (2016-06-13 06:41:20 
+0200)


Marcin Niestroj (1):
  common: env_ubi: Clear environment buffer before reading

 common/env_ubi.c | 21 +
 1 file changed, 21 insertions(+)

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

Re: [U-Boot] BOOT_DELAY broken

[Wolfgang Denk]

Dear Sergey,

In message  you wrote:
> OK, it is broken in last commit. Totally broken.

So what?  Shit happens.  Calm down, it's only ones and zeroes.

> I do NOT have time chasing this -- I'm in firefighting mode now with 14
> hours workdays because of this Tuesday deadline -- but guys, WTF!?

Nobody asked you to fix that.  And that deadline thing is your
problem, not ours, right?  So please don't offload your frustration
and stress to others.

> I could understand somebody submitting such a stupid patch affecting
> _HUNDREDS_ of boards without thinking of consequences but why had it
> been accepted and applied to uboot-master right away? There are other
> things that are broken and won't compile but trivial one-line patches
> fixing that breakage are silently ignored but such a enormous screwup
> leaving holes all over is accepted right away without any checking...

Who says "without checking"?  As far as I know this patch has passed
buildman compile tests, plus runtime tests on all boards available to
the poster (which is more than the average developer has).

> Please do _NOT_ make such things any more. And if you do care please
> take my vehement NACK to this entire thing. I suggest it would be better
> to rollback that patch in its entirety -- there is too much work to fix
> the damage and there is absolutely no reason for this change at all in
> the first place.

Wrong approach.  If there are such obscure dependencies in U-Boot code
they SHOULD be cleaned up.  And yes, this can - and will -
occasionally cause temporary breakage, sometimes even in a large
scale.  But bugs are for fixing.  Bad code needs to be improved, not
to be conservated and never touched.  I strongly recommend to sort out
the remaining issues and fix the problems instead of ignoring them.
Papering over known issues has never been a clever idea.

> Sorry for ranting but I simply could not stand it...

I can understand your frustration, especially when working under
stress.  But eventually you may want to re-read your posting, think
about the tone which sounds extremely aggressive and insulting to me,
and then - maybe? - apologize to Heiko?

Thanks.

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
Monday is an awful way to spend one seventh of your life.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 29/55] dm: Add a tool to generate C code from a device tree

[Simon Glass]

This tool can produce C struct definitions and C platform data tables.
This is used to support the of-platdata feature.

Signed-off-by: Simon Glass 
---

Changes in v2: None

 tools/dtoc/dtoc|   1 +
 tools/dtoc/dtoc.py | 365 +
 2 files changed, 366 insertions(+)
 create mode 12 tools/dtoc/dtoc
 create mode 100755 tools/dtoc/dtoc.py

diff --git a/tools/dtoc/dtoc b/tools/dtoc/dtoc
new file mode 12
index 000..896ca44
--- /dev/null
+++ b/tools/dtoc/dtoc
@@ -0,0 +1 @@
+dtoc.py
\ No newline at end of file
diff --git a/tools/dtoc/dtoc.py b/tools/dtoc/dtoc.py
new file mode 100755
index 000..6a2f6ef
--- /dev/null
+++ b/tools/dtoc/dtoc.py
@@ -0,0 +1,365 @@
+#!/usr/bin/python
+#
+# Copyright (C) 2016 Google, Inc
+# Written by Simon Glass 
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+from optparse import OptionError, OptionParser
+import os
+import sys
+
+import fdt_util
+
+# Bring in the patman libraries
+our_path = os.path.dirname(os.path.realpath(__file__))
+sys.path.append(os.path.join(our_path, '../patman'))
+
+# Bring in either the normal fdt library (which relies on libfdt) or the
+# fallback one (which uses fdtget and is slower). Both provide the same
+# interfface for this file to use.
+try:
+from fdt import Fdt
+import fdt
+have_libfdt = True
+except ImportError:
+have_libfdt = False
+from fdt_fallback import Fdt
+import fdt_fallback as fdt
+
+import struct
+
+# When we see these properties we ignore them - i.e. do not create a structure 
member
+PROP_IGNORE_LIST = [
+'#address-cells',
+'#gpio-cells',
+'#size-cells',
+'compatible',
+'linux,phandle',
+"status",
+'phandle',
+]
+
+# C type declarations for the tyues we support
+TYPE_NAMES = {
+fdt_util.TYPE_INT: 'fdt32_t',
+fdt_util.TYPE_BYTE: 'unsigned char',
+fdt_util.TYPE_STRING: 'const char *',
+fdt_util.TYPE_BOOL: 'bool',
+};
+
+STRUCT_PREFIX = 'dtd_'
+VAL_PREFIX = 'dtv_'
+
+def Conv_name_to_c(name):
+"""Convert a device-tree name to a C identifier
+
+Args:
+name:   Name to convert
+Return:
+String containing the C version of this name
+"""
+str = name.replace('@', '_at_')
+str = str.replace('-', '_')
+str = str.replace(',', '_')
+str = str.replace('/', '__')
+return str
+
+def TabTo(num_tabs, str):
+if len(str) >= num_tabs * 8:
+return str + ' '
+return str + '\t' * (num_tabs - len(str) / 8)
+
+class DtbPlatdata:
+"""Provide a means to convert device tree binary data to platform data
+
+The output of this process is C structures which can be used in space-
+constrained encvironments where the ~3KB code overhead of device tree
+code is not affordable.
+
+Properties:
+fdt: Fdt object, referencing the device tree
+_dtb_fname: Filename of the input device tree binary file
+_valid_nodes: A list of Node object with compatible strings
+_options: Command-line options
+_phandle_node: A dict of nodes indexed by phandle number (1, 2...)
+_outfile: The current output file (sys.stdout or a real file)
+_lines: Stashed list of output lines for outputting in the future
+_phandle_node: A dict of Nodes indexed by phandle (an integer)
+"""
+def __init__(self, dtb_fname, options):
+self._dtb_fname = dtb_fname
+self._valid_nodes = None
+self._options = options
+self._phandle_node = {}
+self._outfile = None
+self._lines = []
+
+def SetupOutput(self, fname):
+"""Set up the output destination
+
+Once this is done, future calls to self.Out() will output to this
+file.
+
+Args:
+fname: Filename to send output to, or '-' for stdout
+"""
+if fname == '-':
+self._outfile = sys.stdout
+else:
+self._outfile = open(fname, 'w')
+
+def Out(self, str):
+"""Output a string to the output file
+
+Args:
+str: String to output
+"""
+self._outfile.write(str)
+
+def Buf(self, str):
+"""Buffer up a string to send later
+
+Args:
+str: String to add to our 'buffer' list
+"""
+self._lines.append(str)
+
+def GetBuf(self):
+"""Get the contents of the output buffer, and clear it
+
+Returns:
+The output buffer, which is then cleared for future use
+"""
+lines = self._lines
+self._lines = []
+return lines
+
+def GetValue(self, type, value):
+"""Get a value as a C expression
+
+For integers this returns a byte-swapped (little-endian) hex string
+For bytes this returns a hex string, e.g. 0x12
+For strings this returns a literal string enclosed in quotes
+For booleans this return 'true'
+
+Args:
+type: Data 

[U-Boot] [PATCH v2 37/55] dm: Don't attach the device tree to SPL with of-platdata

[Simon Glass]

When of-platdata is used in SPL we don't use the device tree. So there is no
point in attaching it. Adjust the Makefile to skip attaching the device tree
when of-platdata is enabled.

Signed-off-by: Simon Glass 
---

Changes in v2: None

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

diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index 324b03f..3ba9742 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -173,7 +173,7 @@ cmd_cat = cat $(filter-out $(PHONY), $^) > $@
 quiet_cmd_copy = COPY$@
   cmd_copy = cp $< $@
 
-ifeq ($(CONFIG_SPL_OF_CONTROL)$(CONFIG_OF_SEPARATE),yy)
+ifeq 
($(CONFIG_SPL_OF_CONTROL)$(CONFIG_OF_SEPARATE)$(CONFIG_SPL_OF_PLATDATA),yy)
 $(obj)/$(SPL_BIN)-dtb.bin: $(obj)/$(SPL_BIN)-nodtb.bin 
$(obj)/$(SPL_BIN)-pad.bin \
$(obj)/$(SPL_BIN).dtb FORCE
$(call if_changed,cat)
-- 
2.8.0.rc3.226.g39d4020

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

[U-Boot] [PATCH v2 55/55] dm: Update the of-platdata README for the new features

[Simon Glass]

Revise the content based on the v2 additions. This is kept as a separate
patch to avoid confusing those who have already reviewed the v1 series.

Signed-off-by: Simon Glass 
Suggested-by: Tom Rini 
---

Changes in v2:
- Add support for rockchip
- Various minor enhancements to the v1 implementation

 doc/driver-model/of-plat.txt | 107 ++-
 1 file changed, 75 insertions(+), 32 deletions(-)

diff --git a/doc/driver-model/of-plat.txt b/doc/driver-model/of-plat.txt
index 96b9b46..01b835f 100644
--- a/doc/driver-model/of-plat.txt
+++ b/doc/driver-model/of-plat.txt
@@ -19,24 +19,28 @@ SoCs require a 16KB SPL image which must include a full MMC 
stack. In this
 case the overhead of device tree access may be too great.
 
 It is possible to create platform data manually by defining C structures
-for it, and referencing that data in a U_BOOT_DEVICE() declaration. This
-bypasses the use of device tree completely, but is an available option for
-SPL.
+for it, and reference that data in a U_BOOT_DEVICE() declaration. This
+bypasses the use of device tree completely, effectively creating a parallel
+configuration mechanism. But it is an available option for SPL.
 
-As an alternative, a new 'of-platdata' feature is provided. This converts
+As an alternative, a new 'of-platdata' feature is provided. This converts the
 device tree contents into C code which can be compiled into the SPL binary.
 This saves the 3KB of code overhead and perhaps a few hundred more bytes due
 to more efficient storage of the data.
 
+Note: Quite a bit of thought has gone into the design of this feature.
+However it still has many rough edges and comments and suggestions are
+strongly encouraged! Quite possibly there is a much better approach.
+
 
 Caveats
 ---
 
 There are many problems with this features. It should only be used when
-stricly necessary. Notable problems include:
+strictly necessary. Notable problems include:
 
-   - Device tree does not describe data types but the C code must define a
-type for each property. Thesee are guessed using heuristics which
+   - Device tree does not describe data types. But the C code must define a
+type for each property. These are guessed using heuristics which
 are wrong in several fairly common cases. For example an 8-byte value
 is considered to be a 2-item integer array, and is byte-swapped. A
 boolean value that is not present means 'false', but cannot be
@@ -45,14 +49,15 @@ stricly necessary. Notable problems include:
 
- Naming of nodes and properties is automatic. This means that they follow
 the naming in the device tree, which may result in C identifiers that
-look a bit strange
+look a bit strange.
 
- It is not possible to find a value given a property name. Code must use
 the associated C member variable directly in the code. This makes
 the code less robust in the face of device-tree changes. It also
 makes it very unlikely that your driver code will be useful for more
 than one SoC. Even if the code is common, each SoC will end up with
-a different C struct and format for the platform data.
+a different C struct name, and a likely a different format for the
+platform data.
 
- The platform data is provided to drivers as a C structure. The driver
 must use the same structure to access the data. Since a driver
@@ -112,7 +117,6 @@ struct dtd_rockchip_rk3288_dw_mshc {
 fdt32_t interrupts[3];
 fdt32_t num_slots;
 fdt32_t reg[2];
-boolu_boot_dm_pre_reloc;
 fdt32_t vmmc_supply;
 };
 
@@ -125,7 +129,10 @@ static struct dtd_rockchip_rk3288_dw_mshc 
dtv_dwmmc_at_ff0c = {
 .clock_freq_min_max = {0x61a80, 0x8f0d180},
 .vmmc_supply= 0xb,
 .num_slots  = 0x1,
-.clocks = {{_clock_controller_at_ff76, 456}, 
{_clock_controller_at_ff76, 68}, {_clock_controller_at_ff76, 
114}, {_clock_controller_at_ff76, 118}},
+.clocks = {{_clock_controller_at_ff76, 456},
+   {_clock_controller_at_ff76, 68},
+   {_clock_controller_at_ff76, 114},
+   {_clock_controller_at_ff76, 118}},
 .cap_mmc_highspeed  = true,
 .disable_wp = true,
 .bus_width  = 0x4,
@@ -136,6 +143,7 @@ static struct dtd_rockchip_rk3288_dw_mshc 
dtv_dwmmc_at_ff0c = {
 U_BOOT_DEVICE(dwmmc_at_ff0c) = {
 .name   = "rockchip_rk3288_dw_mshc",
 .platdata   = _dwmmc_at_ff0c,
+.platdata_size  = sizeof(dtv_dwmmc_at_ff0c),
 };
 
 The device is then instantiated at run-time and the platform data can be
@@ -149,15 +157,31 @@ 

Re: [U-Boot] [PATCH] i2c_eeprom: Add reading support

[Mario Six]

Hi Simon,

On Fri, Jun 10, 2016 at 2:35 AM, Simon Glass  wrote:
> Hi Mario,
>
> On 2 June 2016 at 07:07, Mario Six  wrote:
>> This patch implements the reading functionality for the generic I2C
>> EEPROM driver, which was just a non-functional stub until now.
>>
>> Since the page size will be of importance for the writing support, we
>> add suitable members to the private data structure to keep track of it.
>>
>> Compatibility strings for a range of at24c* chips are added.
>>
>> Signed-off-by: Mario Six 
>> ---
>>
>> Writing functionality doesn't quite work yet; but with these I2C EEPROMs
>> reading is probably more important, anyway.
>>
>
> Looks OK to me, with some comments below.
>
>> ---
>>  drivers/misc/Kconfig  |  5 +
>>  drivers/misc/i2c_eeprom.c | 57 
>> ---
>>  include/i2c_eeprom.h  |  4 
>>  3 files changed, 58 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
>> index 2373037..66453d5 100644
>> --- a/drivers/misc/Kconfig
>> +++ b/drivers/misc/Kconfig
>> @@ -144,4 +144,9 @@ config QFW
>>   Hidden option to enable QEMU fw_cfg interface. This will be 
>> selected by
>>   either CONFIG_CMD_QFW or CONFIG_GENERATE_ACPI_TABLE.
>>
>> +config I2C_EEPROM
>> +   bool "Enable driver for generic I2C-attached EEPROMs"
>> +   depends on DM
>> +   help
>> + Enable a generic driver for EEPROMs attached via I2C.
>>  endmenu
>> diff --git a/drivers/misc/i2c_eeprom.c b/drivers/misc/i2c_eeprom.c
>> index 814134a..d59f126 100644
>> --- a/drivers/misc/i2c_eeprom.c
>> +++ b/drivers/misc/i2c_eeprom.c
>> @@ -10,10 +10,20 @@
>>  #include 
>>  #include 
>>
>> +DECLARE_GLOBAL_DATA_PTR;
>> +
>>  static int i2c_eeprom_read(struct udevice *dev, int offset, uint8_t *buf,
>>int size)
>>  {
>> -   return -ENODEV;
>> +   struct i2c_eeprom *data = dev_get_priv(dev);
>> +   struct udevice *chip;
>> +
>> +   if (i2c_get_chip(dev->parent, data->addr, data->olen, )) {
>> +   printf("i2c_get_chip failed\n");
>> +   return -1;
>
> What is this call for? Won't the I2C device already be set up? You
> should be able to do:
>
> struct udevice *chip = dev_get_parent_platdata(dev);
>

Indeed. Reading it again, I don't even need to get the chip at all, I can just
use the device that is passed in for the dm_i2c_read call. Will fix in v2.

>> +   }
>> +
>> +   return dm_i2c_read(chip, offset, buf, size);
>>  }
>>
>>  static int i2c_eeprom_write(struct udevice *dev, int offset,
>> @@ -27,23 +37,54 @@ struct i2c_eeprom_ops i2c_eeprom_std_ops = {
>> .write  = i2c_eeprom_write,
>>  };
>>
>> +static int i2c_eeprom_std_ofdata_to_platdata(struct udevice *dev)
>> +{
>> +   int addr, olen;
>> +   struct i2c_eeprom *priv = dev_get_priv(dev);
>> +   u64 data = dev_get_driver_data(dev);
>> +
>> +   addr = fdtdec_get_int(gd->fdt_blob, dev->of_offset, "reg", 0);
>> +   priv->addr = addr;
>> +
>> +   olen = fdtdec_get_int(gd->fdt_blob, dev->of_offset,
>> + "u-boot,i2c-offset-len", 1);
>> +   priv->olen = olen;
>> +
>> +   /* 6 bit -> page size of up to 2^63 (should be sufficient) */
>> +   priv->pagewidth = data & 0x3F;
>> +   priv->pagesize = (1 << priv->pagewidth);
>> +
>> +   return 0;
>> +}
>> +
>>  int i2c_eeprom_std_probe(struct udevice *dev)
>>  {
>> return 0;
>>  }
>>
>>  static const struct udevice_id i2c_eeprom_std_ids[] = {
>> -   { .compatible = "i2c-eeprom" },
>> +   { .compatible = "i2c-eeprom", .data = 0 },
>> +   { .compatible = "atmel,24c01a", .data = 3 },
>> +   { .compatible = "atmel,24c02", .data = 3 },
>> +   { .compatible = "atmel,24c04", .data = 4 },
>> +   { .compatible = "atmel,24c08a", .data = 4 },
>> +   { .compatible = "atmel,24c16a", .data = 4 },
>> +   { .compatible = "atmel,24c32", .data = 5 },
>> +   { .compatible = "atmel,24c64", .data = 5 },
>> +   { .compatible = "atmel,24c128", .data = 6 },
>> +   { .compatible = "atmel,24c256", .data = 6 },
>> +   { .compatible = "atmel,24c512", .data = 6 },
>> { }
>>  };
>>
>>  U_BOOT_DRIVER(i2c_eeprom_std) = {
>> -   .name   = "i2c_eeprom",
>> -   .id = UCLASS_I2C_EEPROM,
>> -   .of_match   = i2c_eeprom_std_ids,
>> -   .probe  = i2c_eeprom_std_probe,
>> -   .priv_auto_alloc_size = sizeof(struct i2c_eeprom),
>> -   .ops= _eeprom_std_ops,
>> +   .name   = "i2c_eeprom",
>> +   .id = UCLASS_I2C_EEPROM,
>> +   .of_match   = i2c_eeprom_std_ids,
>> +   .probe  = i2c_eeprom_std_probe,
>> +   .ofdata_to_platdata = i2c_eeprom_std_ofdata_to_platdata,
>> +   .priv_auto_alloc_size   = sizeof(struct i2c_eeprom),
>> +   .ops