Re: [U-Boot] [PATCH v1 5/7] spl: add serial download protocol (SDP) support

[Stefan Agner]

On 2017-08-08 03:43, Lothar Waßmann wrote:
> Hi,
> 
> On Fri,  4 Aug 2017 16:38:11 -0700 Stefan Agner wrote:
>> From: Stefan Agner 
>>
>> Add USB serial download protocol support to SPL. If the SoC started
>> in recovery mode the SPL will immediately switch to SDP and wait for
>> further downloads/commands from the host side.
>>
>> Signed-off-by: Stefan Agner 
>> ---
>>
>>  common/spl/Kconfig  |  6 ++
>>  common/spl/Makefile |  1 +
>>  common/spl/spl_sdp.c| 38 ++
>>  drivers/usb/gadget/Makefile |  1 +
>>  4 files changed, 46 insertions(+)
>>  create mode 100644 common/spl/spl_sdp.c
>>
>> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
>> index 4de81392b0..95378b98a0 100644
>> --- a/common/spl/Kconfig
>> +++ b/common/spl/Kconfig
>> @@ -646,6 +646,12 @@ config SPL_DFU_RAM
>>
>>  endchoice
>>
>> +config SPL_USB_SDP_SUPPORT
>> +bool "Support SDP (Serial Download Protocol)"
>> +help
>> +  Enable Serial Download Protocol (SDP) device support in SPL. This
>> +  allows to download images into memory and execute (jump to) them
>> +  using the same protocol as implemented by the i.MX family's boot ROM.
>>  endif
>>
>>  config SPL_WATCHDOG_SUPPORT
>> diff --git a/common/spl/Makefile b/common/spl/Makefile
>> index 47a64dd7d0..a979560acf 100644
>> --- a/common/spl/Makefile
>> +++ b/common/spl/Makefile
>> @@ -29,4 +29,5 @@ obj-$(CONFIG_SPL_SATA_SUPPORT) += spl_sata.o
>>  obj-$(CONFIG_SPL_DFU_SUPPORT) += spl_dfu.o
>>  obj-$(CONFIG_SPL_SPI_LOAD) += spl_spi.o
>>  obj-$(CONFIG_SPL_RAM_SUPPORT) += spl_ram.o
>> +obj-$(CONFIG_SPL_USB_SDP_SUPPORT) += spl_sdp.o
>>  endif
>> diff --git a/common/spl/spl_sdp.c b/common/spl/spl_sdp.c
>> new file mode 100644
>> index 00..faa74b8bec
>> --- /dev/null
>> +++ b/common/spl/spl_sdp.c
>> @@ -0,0 +1,38 @@
>> +/*
>> + * (C) Copyright 2016 Toradex
>> + * Author: Stefan Agner 
>> + *
>> + * SPDX-License-Identifier: GPL-2.0+
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +DECLARE_GLOBAL_DATA_PTR;
>> +
>> +static int spl_sdp_load_image(struct spl_image_info *spl_image,
>> +  struct spl_boot_device *bootdev)
>> +{
>> +int ret;
>> +
>> +g_dnl_clear_detach();
>> +g_dnl_register("usb_dnl_sdp");
>> +
>> +ret = sdp_init();
>> +if (ret) {
>> +error("SDP init failed: %d", ret);
>> +return -ENODEV;
>> +}
>> +
>> +ret = sdp_handle();
>>
> This function (and sdp_init() above) always return 0. Do you expect to
> be changed in future? Otherwise the return type of those functions
> should be changed to void.
> 

I followed f_thor's approach here which use int in both functions, but
yeah, in the SDP case there is currently no error condition.

Not sure there will be one added in the future, I guess we could just
make it void for now.

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

Re: [U-Boot] [U-Boot, v0, 07/20] vsprintf.c: add wide string (%ls) support

[Rob Clark]

On Tue, Aug 8, 2017 at 6:03 PM, Heinrich Schuchardt  wrote:
> On 08/04/2017 09:31 PM, Rob Clark wrote:
>> This is convenient for efi_loader which deals a lot with utf16.
>>
>> Signed-off-by: Rob Clark 
>
> Please, put this patch together with
> [PATCH] vsprintf.c: add GUID printing
> https://patchwork.ozlabs.org/patch/798362/
> and
> [PATCH v0 06/20] common: add some utf16 handling helpers
> https://patchwork.ozlabs.org/patch/797968/
> into a separate patch series.
>
> These three patches can be reviewed independently of the efi_loader
> patches and probably will not be integrated via the efi-next tree.
>
>> ---
>>  lib/vsprintf.c | 30 --
>>  1 file changed, 28 insertions(+), 2 deletions(-)
>>
>> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
>> index 874a2951f7..0c40f852ce 100644
>> --- a/lib/vsprintf.c
>> +++ b/lib/vsprintf.c
>> @@ -17,6 +17,7 @@
>>  #include 
>>
>>  #include 
>> +#include 
>>
>>  #include 
>>  #define noinline __attribute__((noinline))
>> @@ -270,6 +271,26 @@ static char *string(char *buf, char *end, char *s, int 
>> field_width,
>>   return buf;
>>  }
>>
>> +static char *string16(char *buf, char *end, u16 *s, int field_width,
>> + int precision, int flags)
>> +{
>> + u16 *str = s ? s : L"";
> Please, do not use the L-notation here as it requires -fshort-wchar.
> As we currently cannot switch the complete project to C11 you cannot use
> the u-notation either.
>

actually, one thought..  unlike -fshort-wchar, we could probably
switch u-boot over to c11 piecemeal, if there are a lot of places
where things need to be fixed for c11.  For example start by switching
efi_loader and vsprintf.c ;-)

(I'm not completely sure what the issues are, so this may or may not
make sense.. but if c11 is causing a lot of compile errors all over
the place, this might be a reasonable approach.)

BR,
-R
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] driver: mmc: fsl_esdhc: Fix compiling warning

[York Sun]

Commit 4483b7eb added variable vqmmc_dev but only uses it under
CONFIG_DM_REGULATOR. Add the same macro to variable declaration to
get rid of compiling warning.

Signed-off-by: York Sun 
---

 drivers/mmc/fsl_esdhc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index c017e80..b69c9b7 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -966,7 +966,9 @@ static int fsl_esdhc_probe(struct udevice *dev)
struct fsl_esdhc_priv *priv = dev_get_priv(dev);
const void *fdt = gd->fdt_blob;
int node = dev_of_offset(dev);
+#ifdef CONFIG_DM_REGULATOR
struct udevice *vqmmc_dev;
+#endif
fdt_addr_t addr;
unsigned int val;
int ret;
-- 
2.7.4

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

Re: [U-Boot] [PATCH v1 4/7] cmd: add sdp command

[Łukasz Majewski]

On 08/05/2017 01:38 AM, Stefan Agner wrote:

From: Stefan Agner 

Add a new command to start USB Serial Download Protocol (SDP)
state machine.

Signed-off-by: Stefan Agner 
---

 cmd/Kconfig  |  7 +++
 cmd/Makefile |  1 +
 cmd/usb_gadget_sdp.c | 53 
 3 files changed, 61 insertions(+)
 create mode 100644 cmd/usb_gadget_sdp.c

diff --git a/cmd/Kconfig b/cmd/Kconfig
index f18efc1e88..87333b3a97 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -665,6 +665,13 @@ config CMD_DFU
  Enables the command "dfu" which is used to have U-Boot create a DFU
  class device via USB.

+config CMD_USB_SDP
+   bool "sdp"
+   select USB_FUNCTION_SDP
+   help
+ Enables the command "sdp" which is used to have U-Boot emulating the
+ Serial Download Protocol (SDP) via USB.
+
 config CMD_USB_MASS_STORAGE
bool "UMS usb mass storage"
help
diff --git a/cmd/Makefile b/cmd/Makefile
index bd231f24d8..e0b5940ba6 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -131,6 +131,7 @@ obj-$(CONFIG_CMD_FASTBOOT) += fastboot.o
 obj-$(CONFIG_CMD_FS_UUID) += fs_uuid.o

 obj-$(CONFIG_CMD_USB_MASS_STORAGE) += usb_mass_storage.o
+obj-$(CONFIG_CMD_USB_SDP) += usb_gadget_sdp.o
 obj-$(CONFIG_CMD_THOR_DOWNLOAD) += thordown.o
 obj-$(CONFIG_CMD_XIMG) += ximg.o
 obj-$(CONFIG_YAFFS2) += yaffs2.o
diff --git a/cmd/usb_gadget_sdp.c b/cmd/usb_gadget_sdp.c
new file mode 100644
index 00..09ddb4f3aa
--- /dev/null
+++ b/cmd/usb_gadget_sdp.c
@@ -0,0 +1,53 @@
+/*
+ * cmd_sdp.c -- sdp command
+ *
+ * Copyright (C) 2016 Toradex
+ * Author: Stefan Agner 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+static int do_sdp(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+   int ret = CMD_RET_SUCCESS;
+
+   if (argc < 2)
+   return CMD_RET_USAGE;
+
+   char *usb_controller = argv[1];
+   int controller_index = simple_strtoul(usb_controller, NULL, 0);
+   board_usb_init(controller_index, USB_INIT_DEVICE);
+
+   g_dnl_clear_detach();
+   g_dnl_register("usb_dnl_sdp");
+
+   ret = sdp_init();
+   if (ret) {
+   error("SDP init failed: %d", ret);
+   ret = CMD_RET_FAILURE;
+   goto exit;
+   }
+
+   ret = sdp_handle();
+   if (ret) {
+   error("SDP failed: %d", ret);
+   ret = CMD_RET_FAILURE;
+   goto exit;
+   }
+
+exit:
+   g_dnl_unregister();
+
+   return ret;
+}
+
+U_BOOT_CMD(sdp, 2, 1, do_sdp,
+   "Serial Downloader Protocol",
+   "\n"
+   "  - serial downloader protocol via \n"
+);



Reviewed-by: Łukasz Majewski 

--
Best regards,

Lukasz Majewski

--

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

Re: [U-Boot] [PATCH 09/15] ARM: DTS: stm32: add gpio compatible and aliases for stm32h743

[Vikas MANOCHA]

Hi Patrice,

> -Original Message-
> From: Patrice CHOTARD
> Sent: Friday, August 04, 2017 6:19 AM
> To: u-boot@lists.denx.de; albert.u.b...@aribaud.net; s...@chromium.org; Vikas 
> MANOCHA 
> Cc: Patrice CHOTARD ; Patrick DELAUNAY 
> ; Christophe KERELLO
> 
> Subject: [PATCH 09/15] ARM: DTS: stm32: add gpio compatible and aliases for 
> stm32h743
> 
> From: Patrice Chotard 
> 
> This is needed to bind stm32-gpio driver

Same, it should be fixed in previous patch " DTS: stm32: add stm32h743i-disco 
files"

Cheers,
Vikas

> 
> Signed-off-by: Patrice Chotard 
> ---
>  arch/arm/dts/stm32h743-pinctrl.dtsi | 11 +++
>  arch/arm/dts/stm32h743i-disco.dts   | 11 +++
>  2 files changed, 22 insertions(+)
> 
> diff --git a/arch/arm/dts/stm32h743-pinctrl.dtsi 
> b/arch/arm/dts/stm32h743-pinctrl.dtsi
> index d438818..f32d086 100644
> --- a/arch/arm/dts/stm32h743-pinctrl.dtsi
> +++ b/arch/arm/dts/stm32h743-pinctrl.dtsi
> @@ -54,6 +54,7 @@
>   gpioa: gpio@5802 {
>   gpio-controller;
>   #gpio-cells = <2>;
> + compatible = "st,stm32-gpio";
>   reg = <0x0 0x400>;
>   clocks = < GPIOA_CK>;
>   st,bank-name = "GPIOA";
> @@ -62,6 +63,7 @@
>   gpiob: gpio@58020400 {
>   gpio-controller;
>   #gpio-cells = <2>;
> + compatible = "st,stm32-gpio";
>   reg = <0x400 0x400>;
>   clocks = < GPIOB_CK>;
>   st,bank-name = "GPIOB";
> @@ -70,6 +72,7 @@
>   gpioc: gpio@58020800 {
>   gpio-controller;
>   #gpio-cells = <2>;
> + compatible = "st,stm32-gpio";
>   reg = <0x800 0x400>;
>   clocks = < GPIOC_CK>;
>   st,bank-name = "GPIOC";
> @@ -78,6 +81,7 @@
>   gpiod: gpio@58020c00 {
>   gpio-controller;
>   #gpio-cells = <2>;
> + compatible = "st,stm32-gpio";
>   reg = <0xc00 0x400>;
>   clocks = < GPIOD_CK>;
>   st,bank-name = "GPIOD";
> @@ -86,6 +90,7 @@
>   gpioe: gpio@58021000 {
>   gpio-controller;
>   #gpio-cells = <2>;
> + compatible = "st,stm32-gpio";
>   reg = <0x1000 0x400>;
>   clocks = < GPIOE_CK>;
>   st,bank-name = "GPIOE";
> @@ -94,6 +99,7 @@
>   gpiof: gpio@58021400 {
>   gpio-controller;
>   #gpio-cells = <2>;
> + compatible = "st,stm32-gpio";
>   reg = <0x1400 0x400>;
>   clocks = < GPIOF_CK>;
>   st,bank-name = "GPIOF";
> @@ -102,6 +108,7 @@
>   gpiog: gpio@58021800 {
>   gpio-controller;
>   #gpio-cells = <2>;
> + compatible = "st,stm32-gpio";
>   reg = <0x1800 0x400>;
>   clocks = < GPIOG_CK>;
>   st,bank-name = "GPIOG";
> @@ -110,6 +117,7 @@
>   gpioh: gpio@58021c00 {
>   gpio-controller;
>   #gpio-cells = <2>;
> + compatible = "st,stm32-gpio";
>   reg = <0x1c00 0x400>;
>   clocks = < GPIOH_CK>;
>   st,bank-name = "GPIOH";
> @@ -118,6 +126,7 @@
>   gpioi: gpio@58022000 {
>   gpio-controller;
>   #gpio-cells = <2>;
> + compatible = "st,stm32-gpio";
>   reg = <0x2000 0x400>;
>   clocks = < GPIOI_CK>;
>   st,bank-name = "GPIOI";
> @@ -126,6 +135,7 @@
>   gpioj: gpio@58022400 {
>   gpio-controller;
>   #gpio-cells = <2>;
> + compatible = "st,stm32-gpio";
>   reg = <0x2400 0x400>;
>   clocks = < GPIOJ_CK>;
>   

Re: [U-Boot] [PATCH v1 0/7] imx: add USB Serial Download Protocol (SDP) support

[Eric Nelson]

Hi Stefan,

On 08/07/2017 11:06 AM, Stefan Agner wrote:

Hi Eric,

On 2017-08-06 08:19, Eric Nelson wrote:

Hi Stefan,

On 08/04/2017 04:38 PM, Stefan Agner wrote:

From: Stefan Agner 

This series adds NXP's Serial Download Protocol (SDP) support via
USB for SPL/U-Boot. It allows to download U-Boot via USB from a
(recovered) SPL using the same tools used to download SPL itself
(specifically imx_usb, but also sb_loader seems to work).



Nice!


The idea has been brought up when the first targets started to make
use of SPL for DDR initialization, see:
https://lists.denx.de/pipermail/u-boot/2015-July/220330.html



There have been lots of discussions surrounding the use of SDP,
and this seems to be a nice alternative to using the i.MX "plugin"
mode that I explored a while back:

https://lists.denx.de/pipermail/u-boot/2017-July/thread.html#298266



Hm, wasn't aware of that particular effort, thanks for pointing to it.

From a quick glance, it did not work out so far, is this correct?


That's right. I believe that the trouble is in the return-to-ROM
process. I hacked together a form of "setjmp/longjmp" to try and
get it to work, but wasn't successful and the documentation for
the entry points had me confused.



I looked into plugin mode also a little bit, but I did not continue to
look into it after reading this sentence in the i.MX 6 RM:

8.7 Plugin Image
The boot ROM detects the image type using the plugin flag of the boot
data structure (see
Boot Data Structure). If the plugin flag is 1, then the ROM uses the
image as a plugin
function. The function must initialize the boot device and copy the
program image to the
final location. At the end the plugin function must return with the
program image
parameters. (See High level boot sequence for details about boot flow).



Hmm. That doesn't seem to match the existing code in the NXP U-Boot.



So if SPL should work as a plugin as NXP defines it, SPL is supposed to
load the image from somewhere. The boot ROM then only takes care about
image verification and further boot steps, but it's the plugins job to
get the image from somewhere and store it in RAM.



I think the documentation is just misleading, as NXP is using SPL
to load the payload in stages. The ROM is loading the portion
that goes into RAM after executing the plugin to initialize the
DDR controller (and PMIC if needed).


Afact this is not really helpful in our case. We would want the boot ROM
to go through the boot sequence (again).



Not the full boot sequence. We'd just want it to load the rest of the
image into external RAM.


Unless returning an error/invalid image causes the boot ROM to go
through boot sequence again?


I'm not clear on how errors are handled.


The nice thing with our own SDP implementation is we can reuse it even
from within U-Boot again, e.g. to download a kernel/initramfs



There are lots of nice things about having SDP implemented in
open-source "C" code and I'm inclined to give up on worrying about
"plugin" mode, at least for now.

My primary rationale for trying to get plugins to work was to prevent
the need to have a "full" U-Boot for initial programming of eMMC.

There is one other use case for plugins though, and that's the
"resume from LPSR" on i.MX7. In this case, RAM already has a
running kernel loaded, but the LPDDR is in self-refresh and
something needs to detect that during boot and return after
restoring the DDR registers.


The initial SDP implementation (patch 2) requires the payload to
have the imx specific headers (hence the move of the imx header
file in patch 1).

Patch 3 extends image header support beyond the SDP specification,
specifically implements also support for U-Boot headers. This
allows to use the same SPL/U-Boot binaries for recovery as used on
the regular boot device (SD/eMMC). For that to work also the host
side imx_usb tools needed an extension, currently available here:

https://github.com/toradex/imx_loader/tree/imx_usb_batch_mode_refactored

The full patchset allows to download SPL and U-Boot over USB to a
target in recovery mode using the same usb_imx utility:


imx_usb?



Yeah right, sorry.


The usb_imx utility also has a batch mode which allows to download
multiple artifacts with a single invocation. The details are
outlined in the imx_usb commit message:
https://github.com/toradex/imx_loader/commit/5434415d921f1cc4d22332d9558bed6d42db9f60

In case this patchset gets accepted in U-Boot, I plan to push the
imx_usb changes upstream as well.



Do you have numbers for how much code/data size this adds to SPL?



Besides the protocol implementation also general USB (gadget) support is
required, hence it adds quite a bit.

Without USB Gadget/SDP support (Apalis iMX6 SPL):

$ arm-linux-gnueabihf-size spl/u-boot-spl
textdata bss dec hex filename
   245523808  92   284526f24 spl/u-boot-spl

With USB Gadget/SDP support:

$ arm-linux-gnueabihf-size spl/u-boot-spl
text

Re: [U-Boot] [PATCH v1 2/7] usb: gadget: add SDP driver

[Łukasz Majewski]

Hi Stefan,


From: Stefan Agner 

Add SDP (Serial Downloader Protocol) implementation for U-Boot. The
protocol is used in NXP SoC's boot ROM and allows to download program
images. Beside that, it can also be used to read/write registers and
download complete Device Configuration Data (DCD) sets. This basic
implementation supports downloading images with the imx header format
and reading registers.

Signed-off-by: Stefan Agner 


Just some minor comments (despite comments from Lothar).


---

 drivers/usb/gadget/Kconfig  |   7 +
 drivers/usb/gadget/Makefile |   1 +
 drivers/usb/gadget/f_sdp.c  | 723 
 include/sdp.h   |  16 +
 4 files changed, 747 insertions(+)
 create mode 100644 drivers/usb/gadget/f_sdp.c
 create mode 100644 include/sdp.h

diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 261ed128ac..225b66bc95 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -103,6 +103,13 @@ config USB_GADGET_DOWNLOAD

 if USB_GADGET_DOWNLOAD

+config USB_FUNCTION_SDP
+   bool "Enable USB SDP (Serial Download Protocol)"
+   help
+ Enable Serial Download Protocol (SDP) device support in U-Boot. This
+ allows to download images into memory and execute (jump to) them
+ using the same protocol as implemented by the i.MX family's boot ROM.
+
 config G_DNL_MANUFACTURER
string "Vendor name of USB device"

diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile
index 5e316a7cff..6a007d1bcb 100644
--- a/drivers/usb/gadget/Makefile
+++ b/drivers/usb/gadget/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_USB_FUNCTION_THOR) += f_thor.o
 obj-$(CONFIG_USB_FUNCTION_DFU) += f_dfu.o
 obj-$(CONFIG_USB_FUNCTION_MASS_STORAGE) += f_mass_storage.o
 obj-$(CONFIG_USB_FUNCTION_FASTBOOT) += f_fastboot.o
+obj-$(CONFIG_USB_FUNCTION_SDP) += f_sdp.o
 endif
 endif
 ifdef CONFIG_USB_ETHER
diff --git a/drivers/usb/gadget/f_sdp.c b/drivers/usb/gadget/f_sdp.c
new file mode 100644
index 00..eb89695aaf
--- /dev/null
+++ b/drivers/usb/gadget/f_sdp.c
@@ -0,0 +1,723 @@
+/*
+ * f_sdp.c -- USB HID Serial Download Protocol
+ *
+ * Copyright (C) 2016 Toradex
		 - minor -> If you are going to prepare v2, please update the 
date.



+ * Author: Stefan Agner 
+ *
+ * This file implements the Serial Download Protocol (SDP) as specified in
+ * the i.MX 6 Reference Manual. The SDP is a USB HID based protocol and
+ * allows to download images directly to memory. The implementation
+ * works with the imx_loader (imx_usb) USB client software on host side.
+ *
+ * Not all commands are implemented, e.g. WRITE_REGISTER, DCD_WRITE and
+ * SKIP_DCD_HEADER are only stubs.
+ *
+ * Parts of the implementation are based on f_dfu and f_thor.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#define HID_REPORT_ID_MASK 0x00ff
+
+/*
+ * HID class requests
+ */
+#define HID_REQ_GET_REPORT 0x01
+#define HID_REQ_GET_IDLE   0x02
+#define HID_REQ_GET_PROTOCOL   0x03
+#define HID_REQ_SET_REPORT 0x09
+#define HID_REQ_SET_IDLE   0x0A
+#define HID_REQ_SET_PROTOCOL   0x0B
+
+#define HID_USAGE_PAGE_LEN 76
+
+struct hid_report {
+   u8 usage_page[HID_USAGE_PAGE_LEN];
+} __packed;
+
+#define SDP_READ_REGISTER  0x0101
+#define SDP_WRITE_REGISTER 0x0202
+#define SDP_WRITE_FILE 0x0404
+#define SDP_ERROR_STATUS   0x0505
+#define SDP_DCD_WRITE  0x0a0a
+#define SDP_JUMP_ADDRESS   0x0b0b
+#define SDP_SKIP_DCD_HEADER0x0c0c
+
+#define SDP_WRITE_FILE_COMPLETE0x
+#define SDP_WRITE_REGISTER_COMPLETE0x128A8A12
+#define SDP_SKIP_DCD_HEADER_COMPLETE   0x900DD009
+#define SDP_ERROR_IMXHEADER0x000a0533
+
+#define SDP_COMMAND_LEN16
+
+struct sdp_command {
+   u16 cmd;
+   u32 addr;
+   u8 format;
+   u32 cnt;
+   u32 data;
+   u8 rsvd;
+} __packed;
+
+enum sdp_state {
+   SDP_STATE_IDLE,
+   SDP_STATE_RX_DCD_DATA,
+   SDP_STATE_RX_FILE_DATA,
+   SDP_STATE_TX_SEC_CONF,
+   SDP_STATE_TX_SEC_CONF_BUSY,
+   SDP_STATE_TX_REGISTER,
+   SDP_STATE_TX_REGISTER_BUSY,
+   SDP_STATE_TX_STATUS,
+   SDP_STATE_TX_STATUS_BUSY,
+   SDP_STATE_JUMP,
+};
+
+struct f_sdp {
+   struct usb_function usb_function;
+
+   struct usb_descriptor_header**function;
+
+   u8  altsetting;
+   enum sdp_state  state;
+   enum sdp_state  next_state;
+   u32 dnl_address;
+   u32 dnl_bytes_remaining;
+   u32 jmp_address;
+   bool

Re: [U-Boot] [U-Boot, v0, 07/20] vsprintf.c: add wide string (%ls) support

[Rob Clark]

On Tue, Aug 8, 2017 at 6:03 PM, Heinrich Schuchardt  wrote:
> On 08/04/2017 09:31 PM, Rob Clark wrote:
>> This is convenient for efi_loader which deals a lot with utf16.
>>
>> Signed-off-by: Rob Clark 
>
> Please, put this patch together with
> [PATCH] vsprintf.c: add GUID printing
> https://patchwork.ozlabs.org/patch/798362/
> and
> [PATCH v0 06/20] common: add some utf16 handling helpers
> https://patchwork.ozlabs.org/patch/797968/
> into a separate patch series.
>
> These three patches can be reviewed independently of the efi_loader
> patches and probably will not be integrated via the efi-next tree.

I'll resend these as a separate patchset, and just not in next
revision of efi_loader patchset that it is a dependency

>> ---
>>  lib/vsprintf.c | 30 --
>>  1 file changed, 28 insertions(+), 2 deletions(-)
>>
>> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
>> index 874a2951f7..0c40f852ce 100644
>> --- a/lib/vsprintf.c
>> +++ b/lib/vsprintf.c
>> @@ -17,6 +17,7 @@
>>  #include 
>>
>>  #include 
>> +#include 
>>
>>  #include 
>>  #define noinline __attribute__((noinline))
>> @@ -270,6 +271,26 @@ static char *string(char *buf, char *end, char *s, int 
>> field_width,
>>   return buf;
>>  }
>>
>> +static char *string16(char *buf, char *end, u16 *s, int field_width,
>> + int precision, int flags)
>> +{
>> + u16 *str = s ? s : L"";
> Please, do not use the L-notation here as it requires -fshort-wchar.
> As we currently cannot switch the complete project to C11 you cannot use
> the u-notation either.

current plan was to either switch whole project to -fshort-wchar or
c11 and rework these patches (as well as a few patches in the
efi_loader patchset).  (In the c11 case, I'm not sure what we'll use
as the fmt string, since afaict that isn't specified.  We could use %S
although that seems to be a deprecated way to do %ls, or something
different like %A, I guess)..

how far are we from c11?  If there is stuff I can do to help let me
know.  If feasible, I'd rather do that first rather than have a bunch
of stuff in vsprintf and elsewhere that needs to be cleaned up later
after the switch.

>
>> + int len = utf16_strnlen(str, precision);
>> + u8 utf8[len * MAX_UTF8_PER_UTF16];
>
> Didn't you forget 1 byte for \0 here?
>
> This is what strlnlen does:
>
> The strnlen() function returns the number of characters in the string
> pointed to by s, **excluding** the terminating null byte ('\0'), but at
> most maxlen.
>
> I would expect the exclusion of the terminating null word by an
> utf16_strnlen function.

you are right, but fixing the wrong problem.. the code is definitely
wrong since length of a utf16 string != length of a utf8 string, and
we don't need to append a null terminator.. so my logic below using
'len' is wrong.  I'll fix that in the next version.

>> + int i;
>> +
>> + *utf16_to_utf8(utf8, str, len) = '\0';
>> +
>> + if (!(flags & LEFT))
>> + while (len < field_width--)
>> + ADDCH(buf, ' ');
>> + for (i = 0; i < len; ++i)
>> + ADDCH(buf, utf8[i]);
>> + while (len < field_width--)
>> + ADDCH(buf, ' ');
>> + return buf;
>> +}
>> +
>>  #ifdef CONFIG_CMD_NET
>>  static const char hex_asc[] = "0123456789abcdef";
>>  #define hex_asc_lo(x)hex_asc[((x) & 0x0f)]
>> @@ -528,8 +549,13 @@ repeat:
>>   continue;
>>
>>   case 's':
>> - str = string(str, end, va_arg(args, char *),
>> -  field_width, precision, flags);
>> + if (qualifier == 'l') {
>
> %ls refers to wchar with implementation dependent width in the C standard.
> There is no qualifier for 16-bit wchar. Couldn't we use %us here in
> reference to the u-notation ( u'MyString' ). This would leave the path
> open for a standard compliant '%ls'.

hmm, yeah, that is a clever idea, and I like it better than %A or %S..
so if we go the c11 route I'll do that.  The c11 committee should have
thought of that ;-)

BR,
-R

> Best regards
>
> Heinrich
>
>> + str = string16(str, end, va_arg(args, u16 *),
>> +field_width, precision, flags);
>> + } else {
>> + str = string(str, end, va_arg(args, char *),
>> +  field_width, precision, flags);
>> + }
>>   continue;
>>
>>   case 'p':
>>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 08/15] ARM: DTS: stm32: update usart compatible string for stm32h743

[Vikas MANOCHA]

Hi Patrice,

> -Original Message-
> From: Patrice CHOTARD
> Sent: Friday, August 04, 2017 6:19 AM
> To: u-boot@lists.denx.de; albert.u.b...@aribaud.net; s...@chromium.org; Vikas 
> MANOCHA 
> Cc: Patrice CHOTARD ; Patrick DELAUNAY 
> ; Christophe KERELLO
> 
> Subject: [PATCH 08/15] ARM: DTS: stm32: update usart compatible string for 
> stm32h743
> 
> From: Patrice Chotard 
> 
> Align STM32H7 serial compatible string with the one which will be available 
> in next kernel tag. The bindings has been acked by Rob
> Herring [1].
> This compatible string will be usefull to add stm32h7 specific feature for 
> this serial driver.

Please merge this patch with previous patch "ARM: DTS: stm32: add 
stm32h743i-disco files"
H7 usart sting is already part of driver code which is patch 02 of the series.

Cheers,
Vikas

> 
> [1] https://lkml.org/lkml/2017/7/17/739
> 
> Signed-off-by: Patrice Chotard 
> ---
>  arch/arm/dts/stm32h743.dtsi | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/dts/stm32h743.dtsi b/arch/arm/dts/stm32h743.dtsi index 
> 30b5cb4..fd926a7 100644
> --- a/arch/arm/dts/stm32h743.dtsi
> +++ b/arch/arm/dts/stm32h743.dtsi
> @@ -76,7 +76,7 @@
>   };
> 
>   usart1: serial@40011000 {
> - compatible = "st,stm32f7-usart", "st,stm32f7-uart";
> + compatible = "st,stm32h7-usart", "st,stm32h7-uart";
>   reg = <0x40011000 0x400>;
>   interrupts = <37>;
>   status = "disabled";
> @@ -84,7 +84,7 @@
>   };
> 
>   usart2: serial@40004400 {
> - compatible = "st,stm32f7-usart", "st,stm32f7-uart";
> + compatible = "st,stm32h7-usart", "st,stm32h7-uart";
>   reg = <0x40004400 0x400>;
>   interrupts = <38>;
>   status = "disabled";
> --
> 1.9.1

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

Re: [U-Boot] [U-Boot, v0, 07/20] vsprintf.c: add wide string (%ls) support

[Rob Clark]

On Tue, Aug 8, 2017 at 7:08 PM, Heinrich Schuchardt  wrote:
> On 08/09/2017 12:44 AM, Rob Clark wrote:
>> On Tue, Aug 8, 2017 at 6:03 PM, Heinrich Schuchardt  
>> wrote:
>>> On 08/04/2017 09:31 PM, Rob Clark wrote:
 This is convenient for efi_loader which deals a lot with utf16.

 Signed-off-by: Rob Clark 
>>>
>>> Please, put this patch together with
>>> [PATCH] vsprintf.c: add GUID printing
>>> https://patchwork.ozlabs.org/patch/798362/
>>> and
>>> [PATCH v0 06/20] common: add some utf16 handling helpers
>>> https://patchwork.ozlabs.org/patch/797968/
>>> into a separate patch series.
>>>
>>> These three patches can be reviewed independently of the efi_loader
>>> patches and probably will not be integrated via the efi-next tree.
>>
>> I'll resend these as a separate patchset, and just not in next
>> revision of efi_loader patchset that it is a dependency
>>
 ---
  lib/vsprintf.c | 30 --
  1 file changed, 28 insertions(+), 2 deletions(-)

 diff --git a/lib/vsprintf.c b/lib/vsprintf.c
 index 874a2951f7..0c40f852ce 100644
 --- a/lib/vsprintf.c
 +++ b/lib/vsprintf.c
 @@ -17,6 +17,7 @@
  #include 

  #include 
 +#include 

  #include 
  #define noinline __attribute__((noinline))
 @@ -270,6 +271,26 @@ static char *string(char *buf, char *end, char *s, 
 int field_width,
   return buf;
  }

 +static char *string16(char *buf, char *end, u16 *s, int field_width,
 + int precision, int flags)
 +{
 + u16 *str = s ? s : L"";
>>> Please, do not use the L-notation here as it requires -fshort-wchar.
>>> As we currently cannot switch the complete project to C11 you cannot use
>>> the u-notation either.
>>
>> current plan was to either switch whole project to -fshort-wchar or
>> c11 and rework these patches (as well as a few patches in the
>> efi_loader patchset).  (In the c11 case, I'm not sure what we'll use
>> as the fmt string, since afaict that isn't specified.  We could use %S
>> although that seems to be a deprecated way to do %ls, or something
>> different like %A, I guess)..
>>
>> how far are we from c11?  If there is stuff I can do to help let me
>> know.  If feasible, I'd rather do that first rather than have a bunch
>> of stuff in vsprintf and elsewhere that needs to be cleaned up later
>> after the switch.
>
> buildman downloads very old compilers (gcc < 4.8) from kernel.org which
> do not support C11.
> Travis CI uses Ubuntu 14.04 with gcc 4.8.4 which incorrectly throws an
> error for disk/part.c in C11 mode.

ugg, 4.8 is pretty old..   Not sure how much older than 4.8 buildman
uses.  It seems like *some* c11 was supported w/ >=4.6 so if we
approach the conversion piecemeal (for example skipping code that
triggers gcc bugs on old compilers) we might be able to keep 4.8.4
working until travis provides something newer.

(btw, even going back say 8 fedora releases or more, I've used distro
packaged arm and aarch64 toolchains exclusively.. are there that many
distro's where we really can't assume availability of an
cross-toolchain?  If there isn't something newer from kernel.org can
we just drop relying on ancient prebuilt toolchains?  I'm anyways not
hugely a fan of downloading binary executables from even kernel.org,
instead of using something from a distro build system which I at least
know is very locked down.)

> To get things right we would have to
> * build our own cross tool chains based on a current gcc version
> * use our own tool chain in Travis for x86-64 or use a docker
>   container with a current gcc version.
>
> In the long run heading for C11 would be the right thing to do.
> Until then use an initializer { '<', 'N', 'U', 'L', 'L', '>' }.
> It looks ugly but does not consume more bytes once compiled.
>

Sure, that I'm less worried about, as much as adding stuff that is
very soon going to be legacy.  Even in vfprintf.c it isn't such a big
deal, as efi_loader where it would be more cumbersome.

Maybe we can write out u"" longhand in vsprintf.c as you
suggest, but restrict efi_loader to gcc >= 4.9?  That seems like it
shouldn't be a problem for any arm/arm64 device and it shouldn't be a
problem for any device that is likely to have an efi payload to load
in the first place..

BR,
-R
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v1 0/7] imx: add USB Serial Download Protocol (SDP) support

[Łukasz Majewski]

Hi Stefan,


From: Stefan Agner 

This series adds NXP's Serial Download Protocol (SDP) support via
USB for SPL/U-Boot. It allows to download U-Boot via USB from a
(recovered) SPL using the same tools used to download SPL itself
(specifically imx_usb, but also sb_loader seems to work).


If I might ask - could you prepare some ./doc/README.sdp entry for v2?

I mean some kind of howto for using this feature?

Nothing long - just the most important commands (imx_usb?) including the 
list of supported (and not) features.




The idea has been brought up when the first targets started to make
use of SPL for DDR initialization, see:
https://lists.denx.de/pipermail/u-boot/2015-July/220330.html

The initial SDP implementation (patch 2) requires the payload to
have the imx specific headers (hence the move of the imx header
file in patch 1).

Patch 3 extends image header support beyond the SDP specification,
specifically implements also support for U-Boot headers. This
allows to use the same SPL/U-Boot binaries for recovery as used on
the regular boot device (SD/eMMC). For that to work also the host
side imx_usb tools needed an extension, currently available here:

https://github.com/toradex/imx_loader/tree/imx_usb_batch_mode_refactored

The full patchset allows to download SPL and U-Boot over USB to a
target in recovery mode using the same usb_imx utility:

The usb_imx utility also has a batch mode which allows to download
multiple artifacts with a single invocation. The details are
outlined in the imx_usb commit message:
https://github.com/toradex/imx_loader/commit/5434415d921f1cc4d22332d9558bed6d42db9f60

In case this patchset gets accepted in U-Boot, I plan to push the
imx_usb changes upstream as well.


Thanks for the patch set. It would definitely facilitate work with IMX SoCs.




Stefan Agner (7):
  imx: move imximage header to common location
  usb: gadget: add SDP driver
  usb: gadget: sdp: extend images compatible for jumps
  cmd: add sdp command
  spl: add serial download protocol (SDP) support
  apalis/colibri_imx6: use independent USB PID for SPL
  apalis/colibri_imx6: enable SDP by default

 board/toradex/apalis_imx6/apalis_imx6.c   |  13 +
 board/toradex/colibri_imx6/colibri_imx6.c |  13 +
 cmd/Kconfig   |   7 +
 cmd/Makefile  |   1 +
 cmd/usb_gadget_sdp.c  |  53 +++
 common/spl/Kconfig|   6 +
 common/spl/Makefile   |   1 +
 common/spl/spl_sdp.c  |  38 ++
 configs/apalis_imx6_defconfig |   4 +
 configs/colibri_imx6_defconfig|   4 +
 drivers/usb/gadget/Kconfig|   7 +
 drivers/usb/gadget/Makefile   |   2 +
 drivers/usb/gadget/f_sdp.c| 739 ++
 {tools => include}/imximage.h |   0
 include/sdp.h |  16 +
 15 files changed, 904 insertions(+)
 create mode 100644 cmd/usb_gadget_sdp.c
 create mode 100644 common/spl/spl_sdp.c
 create mode 100644 drivers/usb/gadget/f_sdp.c
 rename {tools => include}/imximage.h (100%)
 create mode 100644 include/sdp.h




--
Best regards,

Lukasz Majewski

--

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

Re: [U-Boot] [PATCH v1 1/7] imx: move imximage header to common location

[Łukasz Majewski]

On 08/05/2017 01:38 AM, Stefan Agner wrote:

From: Stefan Agner 

Move the imximage.h header file to a common location so we can make
use of it from U-Boot too.

Signed-off-by: Stefan Agner 
---

 {tools => include}/imximage.h | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename {tools => include}/imximage.h (100%)

diff --git a/tools/imximage.h b/include/imximage.h
similarity index 100%
rename from tools/imximage.h
rename to include/imximage.h



Reviewed-by: Łukasz Majewski 

--
Best regards,

Lukasz Majewski

--

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

Re: [U-Boot] [U-Boot, v0, 06/20] common: add some utf16 handling helpers

[Heinrich Schuchardt]

On 08/04/2017 09:31 PM, Rob Clark wrote:
> We'll eventually want these in a few places in efi_loader, and also
> vsprintf.
> 
> Signed-off-by: Rob Clark 
> ---
>  common/Makefile  |  1 +
>  common/charset.c | 81 
> 
>  include/charset.h| 18 ++
>  lib/efi_loader/efi_console.c | 17 ++
>  4 files changed, 103 insertions(+), 14 deletions(-)
>  create mode 100644 common/charset.c
>  create mode 100644 include/charset.h
> 
> diff --git a/common/Makefile b/common/Makefile
> index 60681c845c..44c8e1ba52 100644
> --- a/common/Makefile
> +++ b/common/Makefile
> @@ -175,5 +175,6 @@ obj-$(CONFIG_CMD_DFU) += dfu.o
>  obj-y += command.o
>  obj-y += s_record.o
>  obj-y += xyzModem.o
> +obj-y += charset.o
>  
>  CFLAGS_env_embedded.o := -Wa,--no-warn -DENV_CRC=$(shell tools/envcrc 
> 2>/dev/null)
> diff --git a/common/charset.c b/common/charset.c
> new file mode 100644
> index 00..eaff2e542e
> --- /dev/null
> +++ b/common/charset.c
> @@ -0,0 +1,81 @@
> +/*
> + *  charset conversion utils
> + *
> + *  Copyright (c) 2017 Rob Clark
> + *
> + *  SPDX-License-Identifier: GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +
> +/*
> + * utf8/utf16 conversion mostly lifted from grub
> + */
> +
> +size_t utf16_strlen(uint16_t *in)
> +{
> + size_t i;
> + for (i = 0; in[i]; i++);
> + return i;
> +}
> +
> +size_t utf16_strnlen(const uint16_t *in, size_t count)
> +{
> + size_t i;
> + for (i = 0; count-- && in[i]; i++);
> + return i;
> +}
> +
> +/* Convert UTF-16 to UTF-8.  */
> +uint8_t *utf16_to_utf8(uint8_t *dest, const uint16_t *src, size_t size)
> +{
> + uint32_t code_high = 0;
> +
> + while (size--) {

We should not read past the trailing null world. Check *src == 0 somewhere.

> + uint32_t code = *src++;
> +
> + if (code_high) {
> + if (code >= 0xDC00 && code <= 0xDFFF) {
> + /* Surrogate pair.  */
> + code = ((code_high - 0xD800) << 10) + (code - 
> 0xDC00) + 0x1;
> +
> + *dest++ = (code >> 18) | 0xF0;
> + *dest++ = ((code >> 12) & 0x3F) | 0x80;
> + *dest++ = ((code >> 6) & 0x3F) | 0x80;
> + *dest++ = (code & 0x3F) | 0x80;
> + } else {
> + /* Error...  */
> + *dest++ = '?';
> + /* *src may be valid. Don't eat it.  */
> + src--;
> + }
> +
> + code_high = 0;
> + } else {
> + if (code <= 0x007F) {
> + *dest++ = code;
> + } else if (code <= 0x07FF) {
> + *dest++ = (code >> 6) | 0xC0;
> + *dest++ = (code & 0x3F) | 0x80;
> + } else if (code >= 0xD800 && code <= 0xDBFF) {
> + code_high = code;
> + continue;
> + } else if (code >= 0xDC00 && code <= 0xDFFF) {
> + /* Error... */
> + *dest++ = '?';

The error handling is somewhat inconsistent:

No output if code 0xD800-0xDBFF is the last word.
Output '?' for 0xDC00-0xDFFF where not expected.
Output extraneous '?' for 0xD800-0xDBFF not followed by 0xDC00-0xDBFF.

Best regards

Heinrich

> + } else if (code < 0x1) {
> + *dest++ = (code >> 12) | 0xE0;
> + *dest++ = ((code >> 6) & 0x3F) | 0x80;
> + *dest++ = (code & 0x3F) | 0x80;
> + } else {
> + *dest++ = (code >> 18) | 0xF0;
> + *dest++ = ((code >> 12) & 0x3F) | 0x80;
> + *dest++ = ((code >> 6) & 0x3F) | 0x80;
> + *dest++ = (code & 0x3F) | 0x80;
> + }
> + }
> + }
> +
> + return dest;
> +}
> diff --git a/include/charset.h b/include/charset.h
> new file mode 100644
> index 00..2ee1172182
> --- /dev/null
> +++ b/include/charset.h
> @@ -0,0 +1,18 @@
> +/*
> + *  charset conversion utils
> + *
> + *  Copyright (c) 2017 Rob Clark
> + *
> + *  SPDX-License-Identifier: GPL-2.0+
> + */
> +
> +#ifndef __CHARSET_H_
> +#define __CHARSET_H_
> +
> +#define MAX_UTF8_PER_UTF16 4
> +
> +size_t utf16_strlen(uint16_t *in);
> +size_t utf16_strnlen(const uint16_t *in, size_t count);
> +uint8_t *utf16_to_utf8(uint8_t *dest, const uint16_t *src, size_t size);
> +
> +#endif /* __CHARSET_H_ */
> diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
> index 5ebce4b544..3fc82b8726 100644
> --- a/lib/efi_loader/efi_console.c
> +++ 

Re: [U-Boot] [U-Boot, v0, 07/20] vsprintf.c: add wide string (%ls) support

[Alexander Graf]

> Am 09.08.2017 um 00:08 schrieb Heinrich Schuchardt :
> 
>> On 08/09/2017 12:44 AM, Rob Clark wrote:
>>> On Tue, Aug 8, 2017 at 6:03 PM, Heinrich Schuchardt  
>>> wrote:
 On 08/04/2017 09:31 PM, Rob Clark wrote:
 This is convenient for efi_loader which deals a lot with utf16.
 
 Signed-off-by: Rob Clark 
>>> 
>>> Please, put this patch together with
>>> [PATCH] vsprintf.c: add GUID printing
>>> https://patchwork.ozlabs.org/patch/798362/
>>> and
>>> [PATCH v0 06/20] common: add some utf16 handling helpers
>>> https://patchwork.ozlabs.org/patch/797968/
>>> into a separate patch series.
>>> 
>>> These three patches can be reviewed independently of the efi_loader
>>> patches and probably will not be integrated via the efi-next tree.
>> 
>> I'll resend these as a separate patchset, and just not in next
>> revision of efi_loader patchset that it is a dependency
>> 
 ---
 lib/vsprintf.c | 30 --
 1 file changed, 28 insertions(+), 2 deletions(-)
 
 diff --git a/lib/vsprintf.c b/lib/vsprintf.c
 index 874a2951f7..0c40f852ce 100644
 --- a/lib/vsprintf.c
 +++ b/lib/vsprintf.c
 @@ -17,6 +17,7 @@
 #include 
 
 #include 
 +#include 
 
 #include 
 #define noinline __attribute__((noinline))
 @@ -270,6 +271,26 @@ static char *string(char *buf, char *end, char *s, 
 int field_width,
  return buf;
 }
 
 +static char *string16(char *buf, char *end, u16 *s, int field_width,
 + int precision, int flags)
 +{
 + u16 *str = s ? s : L"";
>>> Please, do not use the L-notation here as it requires -fshort-wchar.
>>> As we currently cannot switch the complete project to C11 you cannot use
>>> the u-notation either.
>> 
>> current plan was to either switch whole project to -fshort-wchar or
>> c11 and rework these patches (as well as a few patches in the
>> efi_loader patchset).  (In the c11 case, I'm not sure what we'll use
>> as the fmt string, since afaict that isn't specified.  We could use %S
>> although that seems to be a deprecated way to do %ls, or something
>> different like %A, I guess)..
>> 
>> how far are we from c11?  If there is stuff I can do to help let me
>> know.  If feasible, I'd rather do that first rather than have a bunch
>> of stuff in vsprintf and elsewhere that needs to be cleaned up later
>> after the switch.
> 
> buildman downloads very old compilers (gcc < 4.8) from kernel.org which
> do not support C11.
> Travis CI uses Ubuntu 14.04 with gcc 4.8.4 which incorrectly throws an
> error for disk/part.c in C11 mode.
> 
> To get things right we would have to
> * build our own cross tool chains based on a current gcc version
> * use our own tool chain in Travis for x86-64 or use a docker
>  container with a current gcc version.
> 
> In the long run heading for C11 would be the right thing to do.
> Until then use an initializer { '<', 'N', 'U', 'L', 'L', '>' }.

Don't forget the , 0 :)

Alex

> It looks ugly but does not consume more bytes once compiled.
> 
> Regards
> 
> Heinrich
> 
>> 
>>> 
 + int len = utf16_strnlen(str, precision);
 + u8 utf8[len * MAX_UTF8_PER_UTF16];
>>> 
>>> Didn't you forget 1 byte for \0 here?
>>> 
>>> This is what strlnlen does:
>>> 
>>> The strnlen() function returns the number of characters in the string
>>> pointed to by s, **excluding** the terminating null byte ('\0'), but at
>>> most maxlen.
>>> 
>>> I would expect the exclusion of the terminating null word by an
>>> utf16_strnlen function.
>> 
>> you are right, but fixing the wrong problem.. the code is definitely
>> wrong since length of a utf16 string != length of a utf8 string, and
>> we don't need to append a null terminator.. so my logic below using
>> 'len' is wrong.  I'll fix that in the next version.
>> 
 + int i;
 +
 + *utf16_to_utf8(utf8, str, len) = '\0';
 +
 + if (!(flags & LEFT))
 + while (len < field_width--)
 + ADDCH(buf, ' ');
 + for (i = 0; i < len; ++i)
 + ADDCH(buf, utf8[i]);
 + while (len < field_width--)
 + ADDCH(buf, ' ');
 + return buf;
 +}
 +
 #ifdef CONFIG_CMD_NET
 static const char hex_asc[] = "0123456789abcdef";
 #define hex_asc_lo(x)hex_asc[((x) & 0x0f)]
 @@ -528,8 +549,13 @@ repeat:
  continue;
 
  case 's':
 - str = string(str, end, va_arg(args, char *),
 -  field_width, precision, flags);
 + if (qualifier == 'l') {
>>> 
>>> %ls refers to wchar with implementation dependent width in the C standard.
>>> There is no qualifier for 16-bit wchar. Couldn't we use %us here in
>>> reference to the u-notation ( u'MyString' ). This would leave the path
>>> open for a standard compliant '%ls'.

Re: [U-Boot] [U-Boot, v0, 06/20] common: add some utf16 handling helpers

[Rob Clark]

On Tue, Aug 8, 2017 at 6:50 PM, Heinrich Schuchardt  wrote:
> On 08/04/2017 09:31 PM, Rob Clark wrote:
>> We'll eventually want these in a few places in efi_loader, and also
>> vsprintf.
>>
>> Signed-off-by: Rob Clark 
>> ---
>>  common/Makefile  |  1 +
>>  common/charset.c | 81 
>> 
>>  include/charset.h| 18 ++
>>  lib/efi_loader/efi_console.c | 17 ++
>>  4 files changed, 103 insertions(+), 14 deletions(-)
>>  create mode 100644 common/charset.c
>>  create mode 100644 include/charset.h
>>
>> diff --git a/common/Makefile b/common/Makefile
>> index 60681c845c..44c8e1ba52 100644
>> --- a/common/Makefile
>> +++ b/common/Makefile
>> @@ -175,5 +175,6 @@ obj-$(CONFIG_CMD_DFU) += dfu.o
>>  obj-y += command.o
>>  obj-y += s_record.o
>>  obj-y += xyzModem.o
>> +obj-y += charset.o
>>
>>  CFLAGS_env_embedded.o := -Wa,--no-warn -DENV_CRC=$(shell tools/envcrc 
>> 2>/dev/null)
>> diff --git a/common/charset.c b/common/charset.c
>> new file mode 100644
>> index 00..eaff2e542e
>> --- /dev/null
>> +++ b/common/charset.c
>> @@ -0,0 +1,81 @@
>> +/*
>> + *  charset conversion utils
>> + *
>> + *  Copyright (c) 2017 Rob Clark
>> + *
>> + *  SPDX-License-Identifier: GPL-2.0+
>> + */
>> +
>> +#include 
>> +#include 
>> +
>> +/*
>> + * utf8/utf16 conversion mostly lifted from grub
>> + */
>> +
>> +size_t utf16_strlen(uint16_t *in)
>> +{
>> + size_t i;
>> + for (i = 0; in[i]; i++);
>> + return i;
>> +}
>> +
>> +size_t utf16_strnlen(const uint16_t *in, size_t count)
>> +{
>> + size_t i;
>> + for (i = 0; count-- && in[i]; i++);
>> + return i;
>> +}
>> +
>> +/* Convert UTF-16 to UTF-8.  */
>> +uint8_t *utf16_to_utf8(uint8_t *dest, const uint16_t *src, size_t size)
>> +{
>> + uint32_t code_high = 0;
>> +
>> + while (size--) {
>
> We should not read past the trailing null world. Check *src == 0 somewhere.

so, all the places this is used in u-boot, and all the places I've
seen it used in grub (which is where this code comes from.. I won't
claim to the a utfN expert, this is the first time I've looked at this
sort of thing), you already know the string length.. either via
"protocol" (ie. you know the size of the file-path efi_device_path
element) or you have to do one of the utf16_strlen() variants before
calling this to know the size of the output string.

so utf16_to_utf8() shouldn't rely on null terminators, that seems like
it is just a sign the caller is doing something wrong.

Not sure if there is an equiv to WARN_ON() in u-boot.. maybe just
assert()?  But checking for null should be more of an
assert()/WARN_ON() sort of thing, imho.

I'll add an assert(size == utf16_strnlen(src, size)) (unless someone
has something better to suggest)

>> + uint32_t code = *src++;
>> +
>> + if (code_high) {
>> + if (code >= 0xDC00 && code <= 0xDFFF) {
>> + /* Surrogate pair.  */
>> + code = ((code_high - 0xD800) << 10) + (code - 
>> 0xDC00) + 0x1;
>> +
>> + *dest++ = (code >> 18) | 0xF0;
>> + *dest++ = ((code >> 12) & 0x3F) | 0x80;
>> + *dest++ = ((code >> 6) & 0x3F) | 0x80;
>> + *dest++ = (code & 0x3F) | 0x80;
>> + } else {
>> + /* Error...  */
>> + *dest++ = '?';
>> + /* *src may be valid. Don't eat it.  */
>> + src--;
>> + }
>> +
>> + code_high = 0;
>> + } else {
>> + if (code <= 0x007F) {
>> + *dest++ = code;
>> + } else if (code <= 0x07FF) {
>> + *dest++ = (code >> 6) | 0xC0;
>> + *dest++ = (code & 0x3F) | 0x80;
>> + } else if (code >= 0xD800 && code <= 0xDBFF) {
>> + code_high = code;
>> + continue;
>> + } else if (code >= 0xDC00 && code <= 0xDFFF) {
>> + /* Error... */
>> + *dest++ = '?';
>
> The error handling is somewhat inconsistent:
>
> No output if code 0xD800-0xDBFF is the last word.
> Output '?' for 0xDC00-0xDFFF where not expected.
> Output extraneous '?' for 0xD800-0xDBFF not followed by 0xDC00-0xDBFF.

if you have something better to suggest I look at let me know.  Seems
like (and I'm assuming the grub code can't be too bad since it boots a
whole lot of linux systems every day) this should only happen with a
malformed utf16 string?

(for the record, my only contribution to this code is utf16_strnlen()
and comments (and correcting grub2's painful indentation style :-P))

BR,
-R


> Best 

Re: [U-Boot] [U-Boot, v0, 07/20] vsprintf.c: add wide string (%ls) support

[Alexander Graf]

On 09.08.17 00:39, Rob Clark wrote:

On Tue, Aug 8, 2017 at 7:08 PM, Heinrich Schuchardt  wrote:

On 08/09/2017 12:44 AM, Rob Clark wrote:

On Tue, Aug 8, 2017 at 6:03 PM, Heinrich Schuchardt  wrote:

On 08/04/2017 09:31 PM, Rob Clark wrote:

This is convenient for efi_loader which deals a lot with utf16.

Signed-off-by: Rob Clark 


Please, put this patch together with
[PATCH] vsprintf.c: add GUID printing
https://patchwork.ozlabs.org/patch/798362/
and
[PATCH v0 06/20] common: add some utf16 handling helpers
https://patchwork.ozlabs.org/patch/797968/
into a separate patch series.

These three patches can be reviewed independently of the efi_loader
patches and probably will not be integrated via the efi-next tree.


I'll resend these as a separate patchset, and just not in next
revision of efi_loader patchset that it is a dependency


---
  lib/vsprintf.c | 30 --
  1 file changed, 28 insertions(+), 2 deletions(-)

diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 874a2951f7..0c40f852ce 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -17,6 +17,7 @@
  #include 

  #include 
+#include 

  #include 
  #define noinline __attribute__((noinline))
@@ -270,6 +271,26 @@ static char *string(char *buf, char *end, char *s, int 
field_width,
   return buf;
  }

+static char *string16(char *buf, char *end, u16 *s, int field_width,
+ int precision, int flags)
+{
+ u16 *str = s ? s : L"";

Please, do not use the L-notation here as it requires -fshort-wchar.
As we currently cannot switch the complete project to C11 you cannot use
the u-notation either.


current plan was to either switch whole project to -fshort-wchar or
c11 and rework these patches (as well as a few patches in the
efi_loader patchset).  (In the c11 case, I'm not sure what we'll use
as the fmt string, since afaict that isn't specified.  We could use %S
although that seems to be a deprecated way to do %ls, or something
different like %A, I guess)..

how far are we from c11?  If there is stuff I can do to help let me
know.  If feasible, I'd rather do that first rather than have a bunch
of stuff in vsprintf and elsewhere that needs to be cleaned up later
after the switch.


buildman downloads very old compilers (gcc < 4.8) from kernel.org which
do not support C11.
Travis CI uses Ubuntu 14.04 with gcc 4.8.4 which incorrectly throws an
error for disk/part.c in C11 mode.


ugg, 4.8 is pretty old..   Not sure how much older than 4.8 buildman
uses.  It seems like *some* c11 was supported w/ >=4.6 so if we
approach the conversion piecemeal (for example skipping code that
triggers gcc bugs on old compilers) we might be able to keep 4.8.4
working until travis provides something newer.

(btw, even going back say 8 fedora releases or more, I've used distro
packaged arm and aarch64 toolchains exclusively.. are there that many
distro's where we really can't assume availability of an
cross-toolchain?  If there isn't something newer from kernel.org can
we just drop relying on ancient prebuilt toolchains?  I'm anyways not
hugely a fan of downloading binary executables from even kernel.org,
instead of using something from a distro build system which I at least
know is very locked down.)


To get things right we would have to
* build our own cross tool chains based on a current gcc version
* use our own tool chain in Travis for x86-64 or use a docker
   container with a current gcc version.

In the long run heading for C11 would be the right thing to do.
Until then use an initializer { '<', 'N', 'U', 'L', 'L', '>' }.
It looks ugly but does not consume more bytes once compiled.



Sure, that I'm less worried about, as much as adding stuff that is
very soon going to be legacy.  Even in vfprintf.c it isn't such a big
deal, as efi_loader where it would be more cumbersome.

Maybe we can write out u"" longhand in vsprintf.c as you
suggest, but restrict efi_loader to gcc >= 4.9?  That seems like it
shouldn't be a problem for any arm/arm64 device and it shouldn't be a
problem for any device that is likely to have an efi payload to load
in the first place..


I don't understand? We enable EFI_LOADER on all arm/arm64 systems for a 
good reason, so they all get checked by travis. If we break travis, that 
won't do anyone any good.


I do remember however that Tom wanted to set certain compiler versions 
as minimum required versions. Tom, do you remember which one that was?



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

Re: [U-Boot] [U-Boot, v0, 07/20] vsprintf.c: add wide string (%ls) support

[Heinrich Schuchardt]

On 08/04/2017 09:31 PM, Rob Clark wrote:
> This is convenient for efi_loader which deals a lot with utf16.
> 
> Signed-off-by: Rob Clark 

Please, put this patch together with
[PATCH] vsprintf.c: add GUID printing
https://patchwork.ozlabs.org/patch/798362/
and
[PATCH v0 06/20] common: add some utf16 handling helpers
https://patchwork.ozlabs.org/patch/797968/
into a separate patch series.

These three patches can be reviewed independently of the efi_loader
patches and probably will not be integrated via the efi-next tree.

> ---
>  lib/vsprintf.c | 30 --
>  1 file changed, 28 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> index 874a2951f7..0c40f852ce 100644
> --- a/lib/vsprintf.c
> +++ b/lib/vsprintf.c
> @@ -17,6 +17,7 @@
>  #include 
>  
>  #include 
> +#include 
>  
>  #include 
>  #define noinline __attribute__((noinline))
> @@ -270,6 +271,26 @@ static char *string(char *buf, char *end, char *s, int 
> field_width,
>   return buf;
>  }
>  
> +static char *string16(char *buf, char *end, u16 *s, int field_width,
> + int precision, int flags)
> +{
> + u16 *str = s ? s : L"";
Please, do not use the L-notation here as it requires -fshort-wchar.
As we currently cannot switch the complete project to C11 you cannot use
the u-notation either.

> + int len = utf16_strnlen(str, precision);
> + u8 utf8[len * MAX_UTF8_PER_UTF16];

Didn't you forget 1 byte for \0 here?

This is what strlnlen does:

The strnlen() function returns the number of characters in the string
pointed to by s, **excluding** the terminating null byte ('\0'), but at
most maxlen.

I would expect the exclusion of the terminating null word by an
utf16_strnlen function.

> + int i;
> +
> + *utf16_to_utf8(utf8, str, len) = '\0';
> +
> + if (!(flags & LEFT))
> + while (len < field_width--)
> + ADDCH(buf, ' ');
> + for (i = 0; i < len; ++i)
> + ADDCH(buf, utf8[i]);
> + while (len < field_width--)
> + ADDCH(buf, ' ');
> + return buf;
> +}
> +
>  #ifdef CONFIG_CMD_NET
>  static const char hex_asc[] = "0123456789abcdef";
>  #define hex_asc_lo(x)hex_asc[((x) & 0x0f)]
> @@ -528,8 +549,13 @@ repeat:
>   continue;
>  
>   case 's':
> - str = string(str, end, va_arg(args, char *),
> -  field_width, precision, flags);
> + if (qualifier == 'l') {

%ls refers to wchar with implementation dependent width in the C standard.
There is no qualifier for 16-bit wchar. Couldn't we use %us here in
reference to the u-notation ( u'MyString' ). This would leave the path
open for a standard compliant '%ls'.

Best regards

Heinrich

> + str = string16(str, end, va_arg(args, u16 *),
> +field_width, precision, flags);
> + } else {
> + str = string(str, end, va_arg(args, char *),
> +  field_width, precision, flags);
> + }
>   continue;
>  
>   case 'p':
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v1 3/7] usb: gadget: sdp: extend images compatible for jumps

[Łukasz Majewski]

Hi Stefan,


From: Stefan Agner 

Support U-Boot images in SPL so that u-boot.img files can be
directly downloaded and executed. Furthermore support U-Boot
scripts download and execution in full U-Boot so that custom
recovery actions can be downloaded from the host in a third
step.

Signed-off-by: Stefan Agner 


Reviewed-by: Łukasz Majewski 


---

 drivers/usb/gadget/f_sdp.c | 20 ++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/f_sdp.c b/drivers/usb/gadget/f_sdp.c
index eb89695aaf..9a752843f0 100644
--- a/drivers/usb/gadget/f_sdp.c
+++ b/drivers/usb/gadget/f_sdp.c
@@ -29,6 +29,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 

 #define HID_REPORT_ID_MASK 0x00ff
@@ -672,8 +674,22 @@ static void sdp_handle_in_ep(void)
sdp_func->state = SDP_STATE_TX_REGISTER_BUSY;
break;
case SDP_STATE_JUMP:
-   printf("Checking imxheader at 0x%08x\n", f_sdp->jmp_address);
-   status = sdp_jump_imxheader((void *)f_sdp->jmp_address);
+   printf("Jumping to header at 0x%08x\n", sdp_func->jmp_address);
+   status = sdp_jump_imxheader((void *)sdp_func->jmp_address);
+
+   /* If imx header fails, try some U-Boot specific headers */
+   if (status) {
+#ifdef CONFIG_SPL_BUILD
+   /* In SPL, allow jumps to U-Boot images */
+   struct spl_image_info spl_image = {};
+   spl_parse_image_header(_image,
+   (struct image_header *)sdp_func->jmp_address);
+   jump_to_image_no_args(_image);
+#else
+   /* In U-Boot, allow jumps to scripts */
+   source(sdp_func->jmp_address, "script@1");
+#endif
+   }

sdp_func->next_state = SDP_STATE_IDLE;
sdp_func->error_status = status;




--
Best regards,

Lukasz Majewski

--

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

Re: [U-Boot] [U-Boot, v0, 07/20] vsprintf.c: add wide string (%ls) support

[Heinrich Schuchardt]

On 08/09/2017 12:44 AM, Rob Clark wrote:
> On Tue, Aug 8, 2017 at 6:03 PM, Heinrich Schuchardt  
> wrote:
>> On 08/04/2017 09:31 PM, Rob Clark wrote:
>>> This is convenient for efi_loader which deals a lot with utf16.
>>>
>>> Signed-off-by: Rob Clark 
>>
>> Please, put this patch together with
>> [PATCH] vsprintf.c: add GUID printing
>> https://patchwork.ozlabs.org/patch/798362/
>> and
>> [PATCH v0 06/20] common: add some utf16 handling helpers
>> https://patchwork.ozlabs.org/patch/797968/
>> into a separate patch series.
>>
>> These three patches can be reviewed independently of the efi_loader
>> patches and probably will not be integrated via the efi-next tree.
> 
> I'll resend these as a separate patchset, and just not in next
> revision of efi_loader patchset that it is a dependency
> 
>>> ---
>>>  lib/vsprintf.c | 30 --
>>>  1 file changed, 28 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
>>> index 874a2951f7..0c40f852ce 100644
>>> --- a/lib/vsprintf.c
>>> +++ b/lib/vsprintf.c
>>> @@ -17,6 +17,7 @@
>>>  #include 
>>>
>>>  #include 
>>> +#include 
>>>
>>>  #include 
>>>  #define noinline __attribute__((noinline))
>>> @@ -270,6 +271,26 @@ static char *string(char *buf, char *end, char *s, int 
>>> field_width,
>>>   return buf;
>>>  }
>>>
>>> +static char *string16(char *buf, char *end, u16 *s, int field_width,
>>> + int precision, int flags)
>>> +{
>>> + u16 *str = s ? s : L"";
>> Please, do not use the L-notation here as it requires -fshort-wchar.
>> As we currently cannot switch the complete project to C11 you cannot use
>> the u-notation either.
> 
> current plan was to either switch whole project to -fshort-wchar or
> c11 and rework these patches (as well as a few patches in the
> efi_loader patchset).  (In the c11 case, I'm not sure what we'll use
> as the fmt string, since afaict that isn't specified.  We could use %S
> although that seems to be a deprecated way to do %ls, or something
> different like %A, I guess)..
> 
> how far are we from c11?  If there is stuff I can do to help let me
> know.  If feasible, I'd rather do that first rather than have a bunch
> of stuff in vsprintf and elsewhere that needs to be cleaned up later
> after the switch.

buildman downloads very old compilers (gcc < 4.8) from kernel.org which
do not support C11.
Travis CI uses Ubuntu 14.04 with gcc 4.8.4 which incorrectly throws an
error for disk/part.c in C11 mode.

To get things right we would have to
* build our own cross tool chains based on a current gcc version
* use our own tool chain in Travis for x86-64 or use a docker
  container with a current gcc version.

In the long run heading for C11 would be the right thing to do.
Until then use an initializer { '<', 'N', 'U', 'L', 'L', '>' }.
It looks ugly but does not consume more bytes once compiled.

Regards

Heinrich

> 
>>
>>> + int len = utf16_strnlen(str, precision);
>>> + u8 utf8[len * MAX_UTF8_PER_UTF16];
>>
>> Didn't you forget 1 byte for \0 here?
>>
>> This is what strlnlen does:
>>
>> The strnlen() function returns the number of characters in the string
>> pointed to by s, **excluding** the terminating null byte ('\0'), but at
>> most maxlen.
>>
>> I would expect the exclusion of the terminating null word by an
>> utf16_strnlen function.
> 
> you are right, but fixing the wrong problem.. the code is definitely
> wrong since length of a utf16 string != length of a utf8 string, and
> we don't need to append a null terminator.. so my logic below using
> 'len' is wrong.  I'll fix that in the next version.
> 
>>> + int i;
>>> +
>>> + *utf16_to_utf8(utf8, str, len) = '\0';
>>> +
>>> + if (!(flags & LEFT))
>>> + while (len < field_width--)
>>> + ADDCH(buf, ' ');
>>> + for (i = 0; i < len; ++i)
>>> + ADDCH(buf, utf8[i]);
>>> + while (len < field_width--)
>>> + ADDCH(buf, ' ');
>>> + return buf;
>>> +}
>>> +
>>>  #ifdef CONFIG_CMD_NET
>>>  static const char hex_asc[] = "0123456789abcdef";
>>>  #define hex_asc_lo(x)hex_asc[((x) & 0x0f)]
>>> @@ -528,8 +549,13 @@ repeat:
>>>   continue;
>>>
>>>   case 's':
>>> - str = string(str, end, va_arg(args, char *),
>>> -  field_width, precision, flags);
>>> + if (qualifier == 'l') {
>>
>> %ls refers to wchar with implementation dependent width in the C standard.
>> There is no qualifier for 16-bit wchar. Couldn't we use %us here in
>> reference to the u-notation ( u'MyString' ). This would leave the path
>> open for a standard compliant '%ls'.
> 
> hmm, yeah, that is a clever idea, and I like it better than %A or %S..
> so if we go the c11 route I'll do that.  The c11 committee should have
> thought of that ;-)
> 
> BR,
> -R
> 
>> Best regards
>>
>> Heinrich
>>
>>> + str = 

Re: [U-Boot] [U-Boot, v0, 07/20] vsprintf.c: add wide string (%ls) support

[Rob Clark]

On Tue, Aug 8, 2017 at 7:55 PM, Alexander Graf  wrote:
>
>
> On 09.08.17 00:39, Rob Clark wrote:
>>
>> On Tue, Aug 8, 2017 at 7:08 PM, Heinrich Schuchardt 
>> wrote:
>>>
>>> On 08/09/2017 12:44 AM, Rob Clark wrote:

 On Tue, Aug 8, 2017 at 6:03 PM, Heinrich Schuchardt 
 wrote:
>
> On 08/04/2017 09:31 PM, Rob Clark wrote:
>>
>> This is convenient for efi_loader which deals a lot with utf16.
>>
>> Signed-off-by: Rob Clark 
>
>
> Please, put this patch together with
> [PATCH] vsprintf.c: add GUID printing
> https://patchwork.ozlabs.org/patch/798362/
> and
> [PATCH v0 06/20] common: add some utf16 handling helpers
> https://patchwork.ozlabs.org/patch/797968/
> into a separate patch series.
>
> These three patches can be reviewed independently of the efi_loader
> patches and probably will not be integrated via the efi-next tree.


 I'll resend these as a separate patchset, and just not in next
 revision of efi_loader patchset that it is a dependency

>> ---
>>   lib/vsprintf.c | 30 --
>>   1 file changed, 28 insertions(+), 2 deletions(-)
>>
>> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
>> index 874a2951f7..0c40f852ce 100644
>> --- a/lib/vsprintf.c
>> +++ b/lib/vsprintf.c
>> @@ -17,6 +17,7 @@
>>   #include 
>>
>>   #include 
>> +#include 
>>
>>   #include 
>>   #define noinline __attribute__((noinline))
>> @@ -270,6 +271,26 @@ static char *string(char *buf, char *end, char
>> *s, int field_width,
>>return buf;
>>   }
>>
>> +static char *string16(char *buf, char *end, u16 *s, int field_width,
>> + int precision, int flags)
>> +{
>> + u16 *str = s ? s : L"";
>
> Please, do not use the L-notation here as it requires -fshort-wchar.
> As we currently cannot switch the complete project to C11 you cannot
> use
> the u-notation either.


 current plan was to either switch whole project to -fshort-wchar or
 c11 and rework these patches (as well as a few patches in the
 efi_loader patchset).  (In the c11 case, I'm not sure what we'll use
 as the fmt string, since afaict that isn't specified.  We could use %S
 although that seems to be a deprecated way to do %ls, or something
 different like %A, I guess)..

 how far are we from c11?  If there is stuff I can do to help let me
 know.  If feasible, I'd rather do that first rather than have a bunch
 of stuff in vsprintf and elsewhere that needs to be cleaned up later
 after the switch.
>>>
>>>
>>> buildman downloads very old compilers (gcc < 4.8) from kernel.org which
>>> do not support C11.
>>> Travis CI uses Ubuntu 14.04 with gcc 4.8.4 which incorrectly throws an
>>> error for disk/part.c in C11 mode.
>>
>>
>> ugg, 4.8 is pretty old..   Not sure how much older than 4.8 buildman
>> uses.  It seems like *some* c11 was supported w/ >=4.6 so if we
>> approach the conversion piecemeal (for example skipping code that
>> triggers gcc bugs on old compilers) we might be able to keep 4.8.4
>> working until travis provides something newer.
>>
>> (btw, even going back say 8 fedora releases or more, I've used distro
>> packaged arm and aarch64 toolchains exclusively.. are there that many
>> distro's where we really can't assume availability of an
>> cross-toolchain?  If there isn't something newer from kernel.org can
>> we just drop relying on ancient prebuilt toolchains?  I'm anyways not
>> hugely a fan of downloading binary executables from even kernel.org,
>> instead of using something from a distro build system which I at least
>> know is very locked down.)
>>
>>> To get things right we would have to
>>> * build our own cross tool chains based on a current gcc version
>>> * use our own tool chain in Travis for x86-64 or use a docker
>>>container with a current gcc version.
>>>
>>> In the long run heading for C11 would be the right thing to do.
>>> Until then use an initializer { '<', 'N', 'U', 'L', 'L', '>' }.
>>> It looks ugly but does not consume more bytes once compiled.
>>>
>>
>> Sure, that I'm less worried about, as much as adding stuff that is
>> very soon going to be legacy.  Even in vfprintf.c it isn't such a big
>> deal, as efi_loader where it would be more cumbersome.
>>
>> Maybe we can write out u"" longhand in vsprintf.c as you
>> suggest, but restrict efi_loader to gcc >= 4.9?  That seems like it
>> shouldn't be a problem for any arm/arm64 device and it shouldn't be a
>> problem for any device that is likely to have an efi payload to load
>> in the first place..
>
>
> I don't understand? We enable EFI_LOADER on all arm/arm64 systems for a good
> reason, so they all get checked by travis. If we break travis, that won't do
> anyone any good.

I was more thinking if 

Re: [U-Boot] [PATCH] armv8: layerscape platform pcie link up state judgment strongly

[Xiaowei Bao]

Hi York,

I will pay attention to the case of the case in commit message. 

This patch is for some special reset times for longer pcie devices, in this 
case, the pcie device may on polling compliance state, the RC considers the 
pcie device is link up, but the pcie device is not link up, only the L0 state 
is link up state. So add the link up status judgement mechanisms.

About 100ms timeout, the pcie spec does not specify the link up timeout time, 
and the link up state is determined by a state machine. The state machine 
implementation is relatively complex, refer to uboot of other platform pcie 
link up state to determine the realization of the mechanism, we evaluated a 
timeout, in detect state consider the pcie device is link down, in L0 state 
consider the pcie device is link up, within  100ms in other states can be 
restored to the L0 state considers the pcie device is link up .

Thanks

-Original Message-
From: York Sun 
Sent: Tuesday, August 08, 2017 6:56 AM
To: Xiaowei Bao ; u-boot@lists.denx.de; Priyanka Jain 
; Z.q. Hou ; M.h. Lian 
; s...@chromium.org
Subject: Re: [PATCH] armv8: layerscape platform pcie link up state judgment 
strongly

On 08/02/2017 07:58 PM, Bao Xiaowei wrote:
> modifiy the ls_pcie_link_up function, add the following three judging
> mechanisms:
> 
> detect state: return link down status;
> L0 state: return link up status;
> other state: delay about 100ms retrieve Status Returns the 
> corresponding link status;

Please pay attention to your upper case and lower case in commit message.

What does the spec say about the timeout? Is 100ms the right time? If so, 
please put a comment in the source code.

> 
> Signed-off-by: Bao Xiaowei 
> ---
>   drivers/pci/pcie_layerscape.c | 17 +
>   1 file changed, 13 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/pci/pcie_layerscape.c 
> b/drivers/pci/pcie_layerscape.c index 7565e2f..4446ac9 100644
> --- a/drivers/pci/pcie_layerscape.c
> +++ b/drivers/pci/pcie_layerscape.c
> @@ -65,13 +65,22 @@ static int ls_pcie_ltssm(struct ls_pcie *pcie)
>   
>   static int ls_pcie_link_up(struct ls_pcie *pcie)
>   {
> - int ltssm;
> + int ltssm, i;
>   
>   ltssm = ls_pcie_ltssm(pcie);
> - if (ltssm < LTSSM_PCIE_L0)
> + if ((ltssm == 0) || (ltssm == 1))
>   return 0;
> -
> - return 1;
> + else if (ltssm == LTSSM_PCIE_L0)
> + return 1;
> + else {
> + for (i = 0; i < 100; i++) {
> + udelay(1000);
> + ltssm = ls_pcie_ltssm(pcie);
> + if (ltssm == LTSSM_PCIE_L0)
> + return 1;
> + }
> + return 0;
> + }

A comment to summary the logic would be nice.

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

Re: [U-Boot] [PATCH v0 21/20] efi_loader: hack for archs that cannot do unaligned accesses

[Ard Biesheuvel]

On 8 August 2017 at 07:52, Alexander Graf  wrote:
>
>
>> Am 07.08.2017 um 23:18 schrieb Rob Clark :
>>
>> On Mon, Aug 7, 2017 at 5:14 PM, Mark Kettenis  
>> wrote:
 From: Alexander Graf 
 Date: Mon, 7 Aug 2017 21:19:37 +0100

> On 05.08.17 21:31, Rob Clark wrote:
>> On Sat, Aug 5, 2017 at 4:05 PM, Heinrich Schuchardt  
>> wrote:
>>> On 08/05/2017 08:43 PM, Rob Clark wrote:
 On Sat, Aug 5, 2017 at 1:06 PM, Rob Clark  wrote:
> On Sat, Aug 5, 2017 at 12:52 PM, Heinrich Schuchardt 
>  wrote:
>> On 08/05/2017 06:16 PM, Rob Clark wrote:
>>> On Sat, Aug 5, 2017 at 12:12 PM, Heinrich Schuchardt 
>>>  wrote:
 On 08/05/2017 05:58 PM, Rob Clark wrote:
 Some arch's have trouble with unaligned accesses.  Technically
 EFI device-path structs should be byte aligned, and the next node
 in the path starts immediately after the previous.  Meaning that
 a pointer to an 'struct efi_device_path' is not necessarily word
 aligned.  See section 10.3.1 in v2.7 of UEFI spec.

 This causes problems not just for u-boot, but also most/all EFI
 payloads loaded by u-boot on these archs.  Fortunately the common
 practice for traversing a device path is to rely on the length
 field in the header, rather than the specified length of the
 particular device path type+subtype.  So the EFI_DP_PAD() macro
 will add the specified number of bytes to the tail of device path
 structs to pad them to word alignment.

 Technically this is non-compliant, BROKEN_UNALIGNED should *only*
 be defined on archs that cannot do unaligned accesses.

 Signed-off-by: Rob Clark 
 ---
 I'm not sure if there are other arch's that need -DBROKEN_UNALIGNED

 Mark, this is untested but I think it should solve your crash on 
 the
 Banana Pi.  Could you give it a try when you get a chance?

  arch/arm/config.mk   |  2 +-
  include/efi_api.h| 30 
 ++
  lib/efi_loader/efi_device_path.c |  3 +++
  3 files changed, 34 insertions(+), 1 deletion(-)

 diff --git a/arch/arm/config.mk b/arch/arm/config.mk
 index 1a9db4..067dc93a9d 100644
 --- a/arch/arm/config.mk
 +++ b/arch/arm/config.mk
 @@ -28,7 +28,7 @@ LLVMS_RELFLAGS  := $(call 
 cc-option,-mllvm,) \
   $(call cc-option,-arm-use-movt=0,)
  PLATFORM_RELFLAGS+= $(LLVM_RELFLAGS)

 -PLATFORM_CPPFLAGS += -D__ARM__
 +PLATFORM_CPPFLAGS += -D__ARM__ -DBROKEN_UNALIGNED
>>>
>>> NAK
>>>
>>> We have more then ARM. And other architectures also create 
>>> exceptions
>>> for unaligned access.
>>>
>>> I hate platform specific code. It should not be used outside /arch.
>>>
>>> To play it save you should not use _packed at all!
>>> Use memcpy to transfer between aligned and unaligned memory.
>>
>> except for reasons I explained in the thread on the patch that added
>> the __packed in the first place.  Sorry, this is ugly but we have to
>> do it.
>>
>> BR,
>> -R
>
> According to the UEFI standard the nodes in paths are not to be 
> assumed
> to be aligned.
>
> So even if you use padding bytes in paths that you pass to the EFI
> application you should not expect that the EFI application does the
> same. Expect the EFI application either to remove them or send new 
> nodes
> without padding.
>
> To the idea of padding bytes and __packed does not make sense.

 Ok, to be fair, you are right about device-paths passed too u-boot.
 On BROKEN_UNALIGNED archs, we should sanitise with a copy to an
 aligned device-path in *addition* to what I proposed.  I can make a
 patch to add a helper to do this a bit later.
>>>
>>> so thinking about this a bit, I have two options in mind:
>>>
>>>  + efi_dp_sanitize() + efi_dp_free() helpers that are no-ops on
>>>archs that can do unaligned access, but efi_dp_sanitize() always
>>>allocates and copies on BROKEN_UNALIGNED archs and efi_dp_free()
>>>always free's on BROKEN_UNALIGNED archs, even if the dp passed
>>>from efi payload doesn't require 

Re: [U-Boot] [PATCH 1/3] ARM: i.MX6: exclude the ARM errata from i.MX6 UP system

[Peng Fan]

> -Original Message-
> From: Stefano Babic [mailto:sba...@denx.de]
> Sent: Tuesday, August 08, 2017 4:50 PM
> To: Peng Fan ; sba...@denx.de
> Cc: van.free...@gmail.com; u-boot@lists.denx.de; Fabio Estevam
> 
> Subject: Re: [PATCH 1/3] ARM: i.MX6: exclude the ARM errata from i.MX6 UP
> system
> 
> Hi Peng,
> 
> On 08/08/2017 07:34, Peng Fan wrote:
> > The ARM errata 751472, 794072, 761320 only applied to the following
> > configuration:
> >
> > This erratum affects configurations with either:
> > - One processor if the ACP is present
> > - Two or more processors
> >
> 
> Apart that I agree that such as work-around should be applied just to the
> affected SOCs, which is the issues to apply them to the whole MX6 family ?
> 
> For example, 751472 requires to set CP15 bit 11 with a specific sequence. 
> Right,
> single core MX6 do not need it, but even if this is set in this way, is there 
> a side-
> effect ? Just curious...

I have no idea about there is side effect if applying them to single core mx6.
But we better apply them only affected SoCs.

Regards,
Peng.
> 
> > i.MX6 family does not have the ACP and thus only the MPCore system
> > will be impacted, which are the i.MX6DQ, i.MX6DL, and i.MX6QP.
> >
> > Signed-off-by: Peng Fan 
> > Cc: Stefano Babic 
> > Cc: Fabio Estevam 
> > ---
> >  arch/arm/mach-imx/mx6/Kconfig | 15 +++
> >  1 file changed, 11 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/arm/mach-imx/mx6/Kconfig
> > b/arch/arm/mach-imx/mx6/Kconfig index bb2ce33..2be67e1 100644
> > --- a/arch/arm/mach-imx/mx6/Kconfig
> > +++ b/arch/arm/mach-imx/mx6/Kconfig
> > @@ -1,24 +1,31 @@
> >  if ARCH_MX6
> >
> > +config MX6_SMP
> > +   select ARM_ERRATA_751472
> > +   select ARM_ERRATA_761320
> > +   select ARM_ERRATA_794072
> > +   bool
> > +
> >  config MX6
> > +   select ARM_ERRATA_743622 if !MX6UL
> > bool
> > default y
> > -   select ARM_ERRATA_743622 if !MX6UL
> > -   select ARM_ERRATA_751472 if !MX6UL
> > -   select ARM_ERRATA_761320 if !MX6UL
> > -   select ARM_ERRATA_794072 if !MX6UL
> > imply CMD_FUSE
> >
> >  config MX6D
> > +   select MX6_SMP
> > bool
> >
> >  config MX6DL
> > +   select MX6_SMP
> > bool
> >
> >  config MX6Q
> > +   select MX6_SMP
> > bool
> >
> >  config MX6QDL
> > +   select MX6_SMP
> > bool
> >
> >  config MX6S
> >
> 
> Best regards,
> Stefano
> 
> --
> 
> =
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
> 
> =
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] imx: mx6: select ARM_ERRATA_845369

[Stefano Babic]

On 08/08/2017 07:34, Peng Fan wrote:
> Select ARM_ERRATA_845369 for i.MX6DQ/DL/QP.
> 
> Signed-off-by: Peng Fan 
> ---
>  arch/arm/mach-imx/mx6/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/mach-imx/mx6/Kconfig b/arch/arm/mach-imx/mx6/Kconfig
> index 2be67e1..4eed100 100644
> --- a/arch/arm/mach-imx/mx6/Kconfig
> +++ b/arch/arm/mach-imx/mx6/Kconfig
> @@ -4,6 +4,7 @@ config MX6_SMP
>   select ARM_ERRATA_751472
>   select ARM_ERRATA_761320
>   select ARM_ERRATA_794072
> + select ARM_ERRATA_845369
>   bool
>  
>  config MX6
> 

Reviewed-by: Stefano Babic 

Best regards,
Stefano Babic

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

Re: [U-Boot] [PATCH 2/3] arm: Implement workaround for Cortex-A9 errata 845369

[Stefano Babic]

On 08/08/2017 07:34, Peng Fan wrote:
> Under very rare timing circumstances, transitioning into streaming
> mode might create a data corruption. Present on Two or more processors
> or 1 core with ACP, all revisions. This erratum can be worked round
> by setting bit[22] of the undocumented Diagnostic Control Register to 1.
> 
> Signed-off-by: Peng Fan 
> Cc: Albert Aribaud 
> Cc: Tom Rini 
> Cc: Stefano Babic 
> Cc: Fabio Estevam 
> ---
>  arch/arm/Kconfig   | 3 +++
>  arch/arm/cpu/armv7/start.S | 6 ++
>  2 files changed, 9 insertions(+)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 7f6ab4a..787f2b1 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -97,6 +97,9 @@ config ARM_ERRATA_833069
>  config ARM_ERRATA_833471
>   bool
>  
> +config ARM_ERRATA_845369
> +   bool
> +
>  config ARM_ERRATA_852421
>   bool
>  
> diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
> index f06fd28..7b84a7a 100644
> --- a/arch/arm/cpu/armv7/start.S
> +++ b/arch/arm/cpu/armv7/start.S
> @@ -187,6 +187,12 @@ ENTRY(cpu_init_cp15)
>   mcr p15, 0, r0, c15, c0, 1  @ write diagnostic register
>  #endif
>  
> +#ifdef CONFIG_ARM_ERRATA_845369
> + mrc p15, 0, r0, c15, c0, 1  @ read diagnostic register
> + orr r0, r0, #1 << 22@ set bit #22
> + mcr p15, 0, r0, c15, c0, 1  @ write diagnostic register
> +#endif
> +
>   mov r5, lr  @ Store my Caller
>   mrc p15, 0, r1, c0, c0, 0   @ r1 has Read Main ID Register (MIDR)
>   mov r3, r1, lsr #20 @ get variant field
> 

Reviewed-by: Stefano Babic 

Best regards,
Stefano Babic

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

Re: [U-Boot] [PATCH 1/6 v3] x86: dfi: Add option to select different config headers for baseboards

[Stefan Roese]

Hi Bin,

On 06.08.2017 11:17, Bin Meng wrote:

On Sun, Aug 6, 2017 at 1:13 PM, Stefan Roese  wrote:

Hi Bin,


On 06.08.2017 02:48, Bin Meng wrote:


On Sun, Aug 6, 2017 at 12:49 AM, Stefan Roese  wrote:


This patch adds the infrastructure to define different config headers
with different configurations and default environment for the baseboards
that can now be selected via Kconfig. The new configuration for the
theadorable-x86-dfi-bt700 is also added.

Signed-off-by: Stefan Roese 
Cc: Simon Glass 
Cc: Bin Meng 
---
v3:
- Rebased on latest master
- Removed unused macros from config headers



Sorry for your rebase due to the u-boot-x86/master changes.


v2:
- Added Bin's reviewed-by

   board/dfi/Kconfig   | 18 +--
   board/dfi/dfi-bt700/Kconfig |  7 ++---
   board/dfi/dfi-bt700/MAINTAINERS |  1 +
   configs/dfi-bt700-q7x-151_defconfig |  4 ++-
   configs/theadorable-x86-dfi-bt700_defconfig |  5 ++-
   include/configs/theadorable-x86-dfi-bt700.h | 47
+
   6 files changed, 72 insertions(+), 10 deletions(-)
   create mode 100644 include/configs/theadorable-x86-dfi-bt700.h

diff --git a/board/dfi/Kconfig b/board/dfi/Kconfig
index d2a1d78783..5488f68ed2 100644
--- a/board/dfi/Kconfig
+++ b/board/dfi/Kconfig
@@ -8,10 +8,9 @@ if VENDOR_DFI

   choice
  prompt "Mainboard model"
-   optional

-config TARGET_DFI_BT700
-   bool "DFI BT700 BayTrail"
+config TARGET_Q7X_151_DFI_BT700
+   bool "DFI BT700 BayTrail on DFI Q7X-151 baseboard"
  imply SCSI
  help
This is the DFI Q7X-151 baseboard equipped with the
@@ -23,6 +22,19 @@ config TARGET_DFI_BT700
Note that PCIE_ECAM_BASE is set up by the FSP so the value
used
by U-Boot matches that value.

+config TARGET_THEADORABLE_X86_DFI_BT700
+   bool "DFI BT700 BayTrail on theadorable-x86 baseboard"
+   imply SCSI
+   help
+ This is the theadorable-x86 baseboard equipped with the
+ DFI BayTrail Bt700 SoM. It contains an Atom E3845 with
+ Ethernet (in non-PCIe-x4 configuration), micro-SD, USB 2,
+ USB 3, SATA, serial console and DisplayPort video out.
+ It requires some binary blobs - see README.x86 for details.
+
+ Note that PCIE_ECAM_BASE is set up by the FSP so the value used
+ by U-Boot matches that value.
+
   endchoice

   source "board/dfi/dfi-bt700/Kconfig"
diff --git a/board/dfi/dfi-bt700/Kconfig b/board/dfi/dfi-bt700/Kconfig
index 81a2575d11..61bd182dd7 100644
--- a/board/dfi/dfi-bt700/Kconfig
+++ b/board/dfi/dfi-bt700/Kconfig
@@ -1,5 +1,3 @@
-if TARGET_DFI_BT700
-
   config SYS_BOARD
  default "dfi-bt700"

@@ -10,7 +8,8 @@ config SYS_SOC
  default "baytrail"

   config SYS_CONFIG_NAME
-   default "dfi-bt700"
+   default "dfi-bt700" if TARGET_Q7X_151_DFI_BT700
+   default "theadorable-x86-dfi-bt700" if
TARGET_THEADORABLE_X86_DFI_BT700

   config SYS_TEXT_BASE
  default 0xfff0 if !EFI_STUB
@@ -27,5 +26,3 @@ config BOARD_SPECIFIC_OPTIONS # dummy

   config PCIE_ECAM_BASE
  default 0xe000
-
-endif
diff --git a/board/dfi/dfi-bt700/MAINTAINERS
b/board/dfi/dfi-bt700/MAINTAINERS
index 6639787814..a99a7250b8 100644
--- a/board/dfi/dfi-bt700/MAINTAINERS
+++ b/board/dfi/dfi-bt700/MAINTAINERS
@@ -3,6 +3,7 @@ M:  Stefan Roese 
   S: Maintained
   F: board/dfi/dfi-bt700
   F: include/configs/dfi-bt700.h
+F: include/configs/theadorable-x86-dfi-bt700.h
   F: configs/dfi-bt700-q7x-151_defconfig
   F: configs/theadorable-x86-dfi-bt700_defconfig
   F: arch/x86/dts/dfi-bt700.dtsi
diff --git a/configs/dfi-bt700-q7x-151_defconfig
b/configs/dfi-bt700-q7x-151_defconfig
index 13d911c78c..783239b999 100644
--- a/configs/dfi-bt700-q7x-151_defconfig
+++ b/configs/dfi-bt700-q7x-151_defconfig
@@ -1,13 +1,13 @@
   CONFIG_X86=y
   CONFIG_VENDOR_DFI=y
   CONFIG_DEFAULT_DEVICE_TREE="dfi-bt700-q7x-151"
-CONFIG_TARGET_DFI_BT700=y
   CONFIG_DEBUG_UART=y
   CONFIG_SMP=y
   CONFIG_HAVE_VGA_BIOS=y
   CONFIG_GENERATE_PIRQ_TABLE=y
   CONFIG_GENERATE_MP_TABLE=y
   CONFIG_GENERATE_ACPI_TABLE=y
+CONFIG_HAVE_ACPI_RESUME=y
   CONFIG_SEABIOS=y
   CONFIG_FIT=y
   CONFIG_FIT_SIGNATURE=y
@@ -43,6 +43,8 @@ CONFIG_SYSCON=y
   CONFIG_CPU=y
   CONFIG_DM_I2C=y
   CONFIG_NUVOTON_NCT6102D=y
+CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_SPI_FLASH_WINBOND=y



Normally there is just one SPI flash on the board. Can you confirm
that? Please change the board Kconfig file to select SPI flash, like
http://patchwork.ozlabs.org/patch/795356/.



I some cases, we equip these boards with SPI flash chips from
different manufacturers. So yes, this is correct. And to make
this selection of flash chips more user friendly (for potential
changes in the future), it seems easier to me to select them via
Kconfig (menuconfig) than to select 

[U-Boot] [PATCH v2 1/5] arm: socfpga: Make spl_boot_device accessible to U-boot

[tien . fong . chee]

From: Tien Fong Chee 

This function is required in both SPL and U-boot such as checking
boot device type, which is required for locating flash where U-boot
image, and FPGA design are stored.

Signed-off-by: Tien Fong Chee 
---
 arch/arm/mach-socfpga/misc.c | 30 ++
 arch/arm/mach-socfpga/spl.c  | 29 -
 2 files changed, 30 insertions(+), 29 deletions(-)

diff --git a/arch/arm/mach-socfpga/misc.c b/arch/arm/mach-socfpga/misc.c
index 00eff90..e7d5ae8 100644
--- a/arch/arm/mach-socfpga/misc.c
+++ b/arch/arm/mach-socfpga/misc.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -26,6 +27,9 @@ DECLARE_GLOBAL_DATA_PTR;
 static const struct pl310_regs *const pl310 =
(struct pl310_regs *)CONFIG_SYS_PL310_BASE;
 
+static struct socfpga_system_manager *sysmgr_regs =
+   (struct socfpga_system_manager *)SOCFPGA_SYSMGR_ADDRESS;
+
 struct bsel bsel_str[] = {
{ "rsvd", "Reserved", },
{ "fpga", "FPGA (HPS2FPGA Bridge)", },
@@ -37,6 +41,32 @@ struct bsel bsel_str[] = {
{ "qspi", "QSPI Flash (3.0V)", },
 };
 
+u32 spl_boot_device(void)
+{
+   const u32 bsel = readl(_regs->bootinfo);
+
+   switch (SYSMGR_GET_BOOTINFO_BSEL(bsel)) {
+   case 0x1:   /* FPGA (HPS2FPGA Bridge) */
+   return BOOT_DEVICE_RAM;
+   case 0x2:   /* NAND Flash (1.8V) */
+   case 0x3:   /* NAND Flash (3.0V) */
+   socfpga_per_reset(SOCFPGA_RESET(NAND), 0);
+   return BOOT_DEVICE_NAND;
+   case 0x4:   /* SD/MMC External Transceiver (1.8V) */
+   case 0x5:   /* SD/MMC Internal Transceiver (3.0V) */
+   socfpga_per_reset(SOCFPGA_RESET(SDMMC), 0);
+   socfpga_per_reset(SOCFPGA_RESET(DMA), 0);
+   return BOOT_DEVICE_MMC1;
+   case 0x6:   /* QSPI Flash (1.8V) */
+   case 0x7:   /* QSPI Flash (3.0V) */
+   socfpga_per_reset(SOCFPGA_RESET(QSPI), 0);
+   return BOOT_DEVICE_SPI;
+   default:
+   printf("Invalid boot device (bsel=%08x)!\n", bsel);
+   hang();
+   }
+}
+
 int dram_init(void)
 {
gd->ram_size = get_ram_size((long *)PHYS_SDRAM_1, PHYS_SDRAM_1_SIZE);
diff --git a/arch/arm/mach-socfpga/spl.c b/arch/arm/mach-socfpga/spl.c
index 71bae82..175d546 100644
--- a/arch/arm/mach-socfpga/spl.c
+++ b/arch/arm/mach-socfpga/spl.c
@@ -37,35 +37,6 @@ static struct nic301_registers *nic301_regs =
(struct nic301_registers *)SOCFPGA_L3REGS_ADDRESS;
 #endif
 
-static const struct socfpga_system_manager *sysmgr_regs =
-   (struct socfpga_system_manager *)SOCFPGA_SYSMGR_ADDRESS;
-
-u32 spl_boot_device(void)
-{
-   const u32 bsel = readl(_regs->bootinfo);
-
-   switch (SYSMGR_GET_BOOTINFO_BSEL(bsel)) {
-   case 0x1:   /* FPGA (HPS2FPGA Bridge) */
-   return BOOT_DEVICE_RAM;
-   case 0x2:   /* NAND Flash (1.8V) */
-   case 0x3:   /* NAND Flash (3.0V) */
-   socfpga_per_reset(SOCFPGA_RESET(NAND), 0);
-   return BOOT_DEVICE_NAND;
-   case 0x4:   /* SD/MMC External Transceiver (1.8V) */
-   case 0x5:   /* SD/MMC Internal Transceiver (3.0V) */
-   socfpga_per_reset(SOCFPGA_RESET(SDMMC), 0);
-   socfpga_per_reset(SOCFPGA_RESET(DMA), 0);
-   return BOOT_DEVICE_MMC1;
-   case 0x6:   /* QSPI Flash (1.8V) */
-   case 0x7:   /* QSPI Flash (3.0V) */
-   socfpga_per_reset(SOCFPGA_RESET(QSPI), 0);
-   return BOOT_DEVICE_SPI;
-   default:
-   printf("Invalid boot device (bsel=%08x)!\n", bsel);
-   hang();
-   }
-}
-
 #ifdef CONFIG_SPL_MMC_SUPPORT
 u32 spl_boot_mode(const u32 boot_device)
 {
-- 
2.2.0

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

[U-Boot] [PATCH v2 0/5] Add flash to fpga intermediate driver

[tien . fong . chee]

From: Tien Fong Chee 

This patchset adding intermediate driver called cff driver to support all the
FPGA program operations between FPGA manager and flash. This version mainly
resolved comments from Marek in [v1]. This series is working on top of
u-boot.git - http://git.denx.de/?p=u-boot.git;a=summary 

[v1]: https://www.mail-archive.com/u-boot@lists.denx.de/msg258316.html

Tien Fong Chee (5):
  arm: socfpga: Make spl_boot_device accessible to U-boot
  arm: socfpga: Add checking function on FPGA setting in FDT
  configs: Add FPGA loadfs config for Arria 10
  arm: socfpga: Add intermediate driver between flash and FPGA manager
  arm: socfpga: Enable cff driver build

 arch/arm/mach-socfpga/Makefile|   1 +
 arch/arm/mach-socfpga/cff.c   | 582 ++
 arch/arm/mach-socfpga/include/mach/cff.h  |  40 ++
 arch/arm/mach-socfpga/include/mach/misc.h |   1 +
 arch/arm/mach-socfpga/misc.c  |  30 ++
 arch/arm/mach-socfpga/misc_arria10.c  |  20 +
 arch/arm/mach-socfpga/spl.c   |  29 --
 configs/socfpga_arria10_defconfig |   1 +
 include/configs/socfpga_arria10_socdk.h   |   6 +
 9 files changed, 681 insertions(+), 29 deletions(-)
 create mode 100644 arch/arm/mach-socfpga/cff.c
 create mode 100644 arch/arm/mach-socfpga/include/mach/cff.h

-- 
2.2.0

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

[U-Boot] [PATCH v2 3/5] configs: Add FPGA loadfs config for Arria 10

[tien . fong . chee]

From: Tien Fong Chee 

This config allow FPGA design loaded from FAT fs to FPGA manager.

Signed-off-by: Tien Fong Chee 
---
 configs/socfpga_arria10_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/socfpga_arria10_defconfig 
b/configs/socfpga_arria10_defconfig
index 53ab66f..d555743 100644
--- a/configs/socfpga_arria10_defconfig
+++ b/configs/socfpga_arria10_defconfig
@@ -29,3 +29,4 @@ CONFIG_DWAPB_GPIO=y
 CONFIG_DM_MMC=y
 CONFIG_SYS_NS16550=y
 CONFIG_USE_TINY_PRINTF=y
+CONFIG_CMD_FPGA_LOADFS=y
-- 
2.2.0

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

[U-Boot] [PATCH v2 2/5] arm: socfpga: Add checking function on FPGA setting in FDT

[tien . fong . chee]

From: Tien Fong Chee 

Function for checking FPGA early release setting which is defined
by user in FDT chosen section. This function would be used by
later driver in decision applying appropriate FPGA configuration in
early release or full FPGA booting mode.

Signed-off-by: Tien Fong Chee 
---
 arch/arm/mach-socfpga/include/mach/misc.h |  1 +
 arch/arm/mach-socfpga/misc_arria10.c  | 20 
 2 files changed, 21 insertions(+)

diff --git a/arch/arm/mach-socfpga/include/mach/misc.h 
b/arch/arm/mach-socfpga/include/mach/misc.h
index 0b65783..e003f8a 100644
--- a/arch/arm/mach-socfpga/include/mach/misc.h
+++ b/arch/arm/mach-socfpga/include/mach/misc.h
@@ -26,6 +26,7 @@ static inline void socfpga_fpga_add(void) {}
 unsigned int dedicated_uart_com_port(const void *blob);
 unsigned int shared_uart_com_port(const void *blob);
 unsigned int uart_com_port(const void *blob);
+int is_early_release_fpga_config(const void *blob);
 #endif
 
 #endif /* _MISC_H_ */
diff --git a/arch/arm/mach-socfpga/misc_arria10.c 
b/arch/arm/mach-socfpga/misc_arria10.c
index 9d751f6..2d6e977 100644
--- a/arch/arm/mach-socfpga/misc_arria10.c
+++ b/arch/arm/mach-socfpga/misc_arria10.c
@@ -235,6 +235,26 @@ unsigned int uart_com_port(const void *blob)
return shared_uart_com_port(blob);
 }
 
+int is_chosen_boolean_true(const void *blob, const char *name)
+{
+   int node;
+   int rval = 0;
+
+   node = fdt_subnode_offset(blob, 0, "chosen");
+
+   if (node >= 0)
+   rval = fdtdec_get_bool(blob, node, name);
+
+   return rval;
+}
+
+int is_early_release_fpga_config(const void *blob)
+{
+   static const char *name = "early-release-fpga-config";
+
+   return is_chosen_boolean_true(blob, name);
+}
+
 /*
  * Print CPU information
  */
-- 
2.2.0

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

Re: [U-Boot] [PATCH] mtd: spi: sf_dataflash: Add print message while erase error

[Jagan Teki]

On Thu, Aug 3, 2017 at 8:54 PM, Simon Glass  wrote:
> On 20 July 2017 at 23:26, Wenyou Yang  wrote:
>> Add the print message to tell us why the erase operation doesn't work.
>>
>> Signed-off-by: Wenyou Yang 
>> ---
>>
>>  drivers/mtd/spi/sf_dataflash.c | 10 --
>>  1 file changed, 8 insertions(+), 2 deletions(-)
>
> Reviewed-by: Simon Glass 

Applied to u-boot-spi/master

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/5] imx: mx6: soc: fix mx6sll settings

[Peng Fan]

There is not LDO_SOC/PU/ARM/MMDC1 on i.MX6SLL, also no need to gate/ungate
all PFDs to make PFD working.

Signed-off-by: Peng Fan 
Cc: Stefano Babic 
Cc: Fabio Estevam 
---
 arch/arm/mach-imx/mx6/soc.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-imx/mx6/soc.c b/arch/arm/mach-imx/mx6/soc.c
index af31673..9c3c8dd 100644
--- a/arch/arm/mach-imx/mx6/soc.c
+++ b/arch/arm/mach-imx/mx6/soc.c
@@ -234,6 +234,10 @@ static int set_ldo_voltage(enum ldo_reg ldo, u32 mv)
u32 val, step, old, reg = readl(>reg_core);
u8 shift;
 
+   /* No LDO_SOC/PU/ARM */
+   if (is_mx6sll())
+   return 0;
+
if (mv < 725)
val = 0x00; /* Power gated off */
else if (mv > 1450)
@@ -293,7 +297,7 @@ static void clear_mmdc_ch_mask(void)
reg = readl(_ccm->ccdr);
 
/* Clear MMDC channel mask */
-   if (is_mx6sx() || is_mx6ul() || is_mx6ull() || is_mx6sl())
+   if (is_mx6sx() || is_mx6ul() || is_mx6ull() || is_mx6sl() || 
is_mx6sll())
reg &= ~(MXC_CCM_CCDR_MMDC_CH1_HS_MASK);
else
reg &= ~(MXC_CCM_CCDR_MMDC_CH1_HS_MASK | 
MXC_CCM_CCDR_MMDC_CH0_HS_MASK);
@@ -495,6 +499,10 @@ uint mmc_get_env_part(struct mmc *mmc)
 
 int board_postclk_init(void)
 {
+   /* NO LDO SOC on i.MX6SLL */
+   if (is_mx6sll())
+   return 0;
+
set_ldo_voltage(LDO_SOC, 1175); /* Set VDDSOC to 1.175V */
 
return 0;
@@ -576,7 +584,7 @@ void s_init(void)
u32 mask528;
u32 reg, periph1, periph2;
 
-   if (is_mx6sx() || is_mx6ul() || is_mx6ull())
+   if (is_mx6sx() || is_mx6ul() || is_mx6ull() || is_mx6sll())
return;
 
/* Due to hardware limitation, on MX6Q we need to gate/ungate all PFDs
-- 
2.6.2

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

[U-Boot] [PATCH 4/5] imx: mx6sx: select OSC as uart's clk parent

[Peng Fan]

As M4 is sourcing UART clk from OSC, to make UART work
when M4 is enabled, need to select OSC as clk parent,
24M OSC is enough for debug UART in uboot.

Signed-off-by: Peng Fan 
Cc: Stefano Babic 
Cc: Fabio Estevam 
---
 arch/arm/mach-imx/mx6/soc.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/mach-imx/mx6/soc.c b/arch/arm/mach-imx/mx6/soc.c
index e2ecc3a..b4ec11a 100644
--- a/arch/arm/mach-imx/mx6/soc.c
+++ b/arch/arm/mach-imx/mx6/soc.c
@@ -364,6 +364,7 @@ int arch_cpu_init(void)
 {
struct sched_ctrl_regs *regs =
(struct sched_ctrl_regs *)MF2_SCHED_BASE_ADDR;
+   struct mxc_ccm_reg *ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
 
init_aips();
 
@@ -434,6 +435,9 @@ int arch_cpu_init(void)
 
imx_set_wdog_powerdown(false); /* Disable PDE bit of WMCR register */
 
+   if (is_mx6sx())
+   setbits_le32(>cscdr1, MXC_CCM_CSCDR1_UART_CLK_SEL);
+
/*
 * To resolve USB camera bandwidth issue, the patch sets
 * recommended AQoS setting from IC team value for peripheral
-- 
2.6.2

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

Re: [U-Boot] [PATCH v0 21/20] efi_loader: hack for archs that cannot do unaligned accesses

[Rob Clark]

On Tue, Aug 8, 2017 at 2:52 AM, Alexander Graf  wrote:
>
>
>> Am 07.08.2017 um 23:18 schrieb Rob Clark :
>>
>> On Mon, Aug 7, 2017 at 5:14 PM, Mark Kettenis  
>> wrote:
 From: Alexander Graf 
 Date: Mon, 7 Aug 2017 21:19:37 +0100

> On 05.08.17 21:31, Rob Clark wrote:
>> On Sat, Aug 5, 2017 at 4:05 PM, Heinrich Schuchardt  
>> wrote:
>>> On 08/05/2017 08:43 PM, Rob Clark wrote:
 On Sat, Aug 5, 2017 at 1:06 PM, Rob Clark  wrote:
> On Sat, Aug 5, 2017 at 12:52 PM, Heinrich Schuchardt 
>  wrote:
>> On 08/05/2017 06:16 PM, Rob Clark wrote:
>>> On Sat, Aug 5, 2017 at 12:12 PM, Heinrich Schuchardt 
>>>  wrote:
 On 08/05/2017 05:58 PM, Rob Clark wrote:
 Some arch's have trouble with unaligned accesses.  Technically
 EFI device-path structs should be byte aligned, and the next node
 in the path starts immediately after the previous.  Meaning that
 a pointer to an 'struct efi_device_path' is not necessarily word
 aligned.  See section 10.3.1 in v2.7 of UEFI spec.

 This causes problems not just for u-boot, but also most/all EFI
 payloads loaded by u-boot on these archs.  Fortunately the common
 practice for traversing a device path is to rely on the length
 field in the header, rather than the specified length of the
 particular device path type+subtype.  So the EFI_DP_PAD() macro
 will add the specified number of bytes to the tail of device path
 structs to pad them to word alignment.

 Technically this is non-compliant, BROKEN_UNALIGNED should *only*
 be defined on archs that cannot do unaligned accesses.

 Signed-off-by: Rob Clark 
 ---
 I'm not sure if there are other arch's that need -DBROKEN_UNALIGNED

 Mark, this is untested but I think it should solve your crash on 
 the
 Banana Pi.  Could you give it a try when you get a chance?

  arch/arm/config.mk   |  2 +-
  include/efi_api.h| 30 
 ++
  lib/efi_loader/efi_device_path.c |  3 +++
  3 files changed, 34 insertions(+), 1 deletion(-)

 diff --git a/arch/arm/config.mk b/arch/arm/config.mk
 index 1a9db4..067dc93a9d 100644
 --- a/arch/arm/config.mk
 +++ b/arch/arm/config.mk
 @@ -28,7 +28,7 @@ LLVMS_RELFLAGS  := $(call 
 cc-option,-mllvm,) \
   $(call cc-option,-arm-use-movt=0,)
  PLATFORM_RELFLAGS+= $(LLVM_RELFLAGS)

 -PLATFORM_CPPFLAGS += -D__ARM__
 +PLATFORM_CPPFLAGS += -D__ARM__ -DBROKEN_UNALIGNED
>>>
>>> NAK
>>>
>>> We have more then ARM. And other architectures also create 
>>> exceptions
>>> for unaligned access.
>>>
>>> I hate platform specific code. It should not be used outside /arch.
>>>
>>> To play it save you should not use _packed at all!
>>> Use memcpy to transfer between aligned and unaligned memory.
>>
>> except for reasons I explained in the thread on the patch that added
>> the __packed in the first place.  Sorry, this is ugly but we have to
>> do it.
>>
>> BR,
>> -R
>
> According to the UEFI standard the nodes in paths are not to be 
> assumed
> to be aligned.
>
> So even if you use padding bytes in paths that you pass to the EFI
> application you should not expect that the EFI application does the
> same. Expect the EFI application either to remove them or send new 
> nodes
> without padding.
>
> To the idea of padding bytes and __packed does not make sense.

 Ok, to be fair, you are right about device-paths passed too u-boot.
 On BROKEN_UNALIGNED archs, we should sanitise with a copy to an
 aligned device-path in *addition* to what I proposed.  I can make a
 patch to add a helper to do this a bit later.
>>>
>>> so thinking about this a bit, I have two options in mind:
>>>
>>>  + efi_dp_sanitize() + efi_dp_free() helpers that are no-ops on
>>>archs that can do unaligned access, but efi_dp_sanitize() always
>>>allocates and copies on BROKEN_UNALIGNED archs and efi_dp_free()
>>>always free's on BROKEN_UNALIGNED archs, even if the dp passed
>>>from efi payload doesn't 

[U-Boot] [PATCH v2 4/5] arm: socfpga: Add intermediate driver between flash and FPGA manager

[tien . fong . chee]

From: Tien Fong Chee 

Configuration flip-flop driver is mainly used for handling the FPGA program
operation where the FPGA image loading from the flash into FPGA manager.

Signed-off-by: Tien Fong Chee 
---
 arch/arm/mach-socfpga/cff.c  | 582 +++
 arch/arm/mach-socfpga/include/mach/cff.h |  40 +++
 include/configs/socfpga_arria10_socdk.h  |   6 +
 3 files changed, 628 insertions(+)
 create mode 100644 arch/arm/mach-socfpga/cff.c
 create mode 100644 arch/arm/mach-socfpga/include/mach/cff.h

diff --git a/arch/arm/mach-socfpga/cff.c b/arch/arm/mach-socfpga/cff.c
new file mode 100644
index 000..ccee5e9
--- /dev/null
+++ b/arch/arm/mach-socfpga/cff.c
@@ -0,0 +1,582 @@
+/*
+ * COPYRIGHT (C) 2017 Intel Corporation 
+ *
+ * SPDX-License-Identifier:GPL-2.0
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define RBF_UNENCRYPTED 0xa65c
+#define RBF_ENCRYPTED 0xa65d
+#define ARRIA10RBF_PERIPH 0x0001
+#define ARRIA10RBF_CORE 0x8001
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static int flash_type = -1;
+
+struct mmc *mmc;
+
+/* Local functions */
+static int cff_flash_read(struct cff_flash_info *cff_flashinfo, u32 *buffer,
+   u32 *buffer_sizebytes);
+static int cff_flash_preinit(struct cff_flash_info *cff_flashinfo,
+   fpga_fs_info *fpga_fsinfo, u32 *buffer, u32 *buffer_sizebytes);
+#ifdef CONFIG_CMD_FPGA_LOADFS
+static const char *get_cff_filename(const void *fdt, int *len, u32 core);
+#else
+static int get_cff_offset(const void *fdt, u32 core);
+#endif
+
+static struct mmc *init_mmc_device(int dev, bool force_init)
+{
+   struct mmc *mmc;
+
+   mmc = find_mmc_device(dev);
+   if (!mmc) {
+   printf("no mmc device at slot %x\n", dev);
+   return NULL;
+   }
+
+   if (force_init)
+   mmc->has_init = 0;
+   if (mmc_init(mmc))
+   return NULL;
+
+   return mmc;
+}
+
+static int cff_flash_probe(struct cff_flash_info *cff_flashinfo)
+{
+   int dev = 0;
+
+   if(BOOT_DEVICE_MMC1 == flash_type)
+   {
+   mmc = init_mmc_device(dev, true);
+
+   if (!mmc)
+   return -ENOTBLK;
+
+#ifdef CONFIG_CMD_FPGA_LOADFS
+   /* we are looking at the FAT partition */
+   if (fat_register_device(mmc_get_blk_desc(mmc),
+   cff_flashinfo->sdmmc_flashinfo.dev_part)) {
+   printf("Failed to set filesystem to FAT.\n");
+   return -EPERM;
+   }
+#endif
+   }
+
+   return flash_type;
+}
+
+static int flash_read(struct cff_flash_info *cff_flashinfo,
+   u32 size_read,
+   u32 *buffer_ptr)
+{
+   size_t ret = EEXIST;
+#ifdef CONFIG_CMD_FPGA_LOADFS
+   loff_t actread;
+#endif
+
+   if(BOOT_DEVICE_MMC1 == flash_type) {
+#ifdef CONFIG_CMD_FPGA_LOADFS
+   ret = fat_read_file(cff_flashinfo->sdmmc_flashinfo.filename,
+   buffer_ptr, cff_flashinfo->flash_offset,
+size_read, );
+
+   if (ret || actread != size_read) {
+   printf("Failed to read %s from FAT %d ",
+   cff_flashinfo->sdmmc_flashinfo.filename,
+ret);
+   printf("!= %d.\n", size_read);
+   return -EPERM;
+   } else
+   ret = actread;
+#else
+   u32 blk = cff_flashinfo->flash_offset/mmc->read_bl_len;
+   u32 cnt = size_read / mmc->read_bl_len;
+
+   if (!cnt)
+   cnt = 1;
+
+   if((size_read % mmc->read_bl_len) &&
+   (size_read >= mmc->read_bl_len))
+   cnt++;
+
+   ret = blk_dread(mmc_get_blk_desc(mmc), blk, cnt,
+buffer_ptr);
+
+   if (cnt != ret)
+   return -EPERM;
+#endif
+   }
+
+   return ret;
+}
+
+#ifdef CONFIG_CMD_FPGA_LOADFS
+const char *get_cff_filename(const void *fdt, int *len, u32 core)
+{
+   const char *cff_filename = NULL;
+   const char *cell;
+   int nodeoffset;
+   nodeoffset = fdt_subnode_offset(fdt, 0, "chosen");
+
+   if (nodeoffset >= 0) {
+   if (core)
+   cell = fdt_getprop(fdt,
+   nodeoffset,
+   "cffcore-file",
+   len);
+   else
+   cell = fdt_getprop(fdt, nodeoffset, "cff-file", len);
+
+   if (cell)
+   cff_filename = cell;
+   }
+
+   return cff_filename;
+}
+#else
+static int get_cff_offset(const void *fdt, u32 

Re: [U-Boot] [RFC PATCH 1/1] dm: core: add clocks node scan

[Patrice CHOTARD]

Hi Simon

On 08/06/2017 07:16 AM, Simon Glass wrote:
> Hi Patrice,
> 
> On 31 July 2017 at 09:12,   wrote:
>> From: Patrice Chotard 
>>
>> Currently, all fixed-clock declared in "clocks" node in device tree
>> can be binded by clk_fixed_rate.c driver only if the "simple-bus"
>> compatible string is set inside "clocks" node.
>> This constraint has been invoked here [1].
>>
>> This patch offers a solution to avoid adding "simple-bus" compatible
>> string to "clocks" node.
>>
>> [1] https://patchwork.ozlabs.org/patch/558837/
>>
>> Signed-off-by: Patrice Chotard 
>> ---
>>   drivers/core/root.c | 13 +
>>   1 file changed, 13 insertions(+)
>>
>> diff --git a/drivers/core/root.c b/drivers/core/root.c
>> index d691d6f..f285df8 100644
>> --- a/drivers/core/root.c
>> +++ b/drivers/core/root.c
>> @@ -312,6 +312,12 @@ int dm_scan_fdt(const void *blob, bool pre_reloc_only)
>>   #endif
>>  return dm_scan_fdt_node(gd->dm_root, blob, 0, pre_reloc_only);
>>   }
>> +#else
>> +static int dm_scan_fdt_node(struct udevice *parent, const void *blob,
>> +   int offset, bool pre_reloc_only)
>> +{
>> +   return 0;
>> +}
>>   #endif
>>
>>   __weak int dm_scan_other(bool pre_reloc_only)
>> @@ -322,6 +328,7 @@ __weak int dm_scan_other(bool pre_reloc_only)
>>   int dm_init_and_scan(bool pre_reloc_only)
>>   {
>>  int ret;
>> +   int node;
>>
>>  ret = dm_init(IS_ENABLED(CONFIG_OF_LIVE));
>>  if (ret) {
>> @@ -340,6 +347,12 @@ int dm_init_and_scan(bool pre_reloc_only)
>>  debug("dm_scan_fdt() failed: %d\n", ret);
>>  return ret;
>>  }
>> +
>> +   /* bind fixed-clock */
>> +   node = fdt_path_offset(gd->fdt_blob, "/clocks");
> 
> This needs to support livetree, so I think you want ofnode_path() here.

Yes, i will update it

> 
>> +   if (node >= 0)
>> +   dm_scan_fdt_node(gd->dm_root, gd->fdt_blob, node,
>> +pre_reloc_only);
> 
> See dm_scan_fdt() for what you need to do here.

I have no choice, i need to use dm_scan_fdt_node() with clocks node's 
offset to force dt scan of clocks node to ensure that all its sub-node 
will be binded.

> 
>>  }
>>
>>  ret = dm_scan_other(pre_reloc_only);
>> --
>> 1.9.1
>>
> 
> Also please can you make sandbox have a clock in this node, and add a
> test for it to test/dm/clk.c ?

yes, sure

> 
> Regards,
> Simon

Thanks

Patrice

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

Re: [U-Boot] [PATCH v1 0/7] imx: add USB Serial Download Protocol (SDP) support

[Stefano Babic]

Hi Stefan,

On 07/08/2017 20:06, Stefan Agner wrote:
> Hi Eric,
> 
> On 2017-08-06 08:19, Eric Nelson wrote:
>> Hi Stefan,
>>
>> On 08/04/2017 04:38 PM, Stefan Agner wrote:
>>> From: Stefan Agner 
>>>
>>> This series adds NXP's Serial Download Protocol (SDP) support via
>>> USB for SPL/U-Boot. It allows to download U-Boot via USB from a
>>> (recovered) SPL using the same tools used to download SPL itself
>>> (specifically imx_usb, but also sb_loader seems to work).
>>>
>>
>> Nice!
>>
>>> The idea has been brought up when the first targets started to make
>>> use of SPL for DDR initialization, see:
>>> https://lists.denx.de/pipermail/u-boot/2015-July/220330.html
>>>
>>
>> There have been lots of discussions surrounding the use of SDP,
>> and this seems to be a nice alternative to using the i.MX "plugin"
>> mode that I explored a while back:
>>
>> https://lists.denx.de/pipermail/u-boot/2017-July/thread.html#298266
>>
> 
> Hm, wasn't aware of that particular effort, thanks for pointing to it.
> From a quick glance, it did not work out so far, is this correct?
> 
> I looked into plugin mode also a little bit, but I did not continue to
> look into it after reading this sentence in the i.MX 6 RM:
> 
> 8.7 Plugin Image
> The boot ROM detects the image type using the plugin flag of the boot
> data structure (see
> Boot Data Structure). If the plugin flag is 1, then the ROM uses the
> image as a plugin
> function. The function must initialize the boot device and copy the
> program image to the
> final location. At the end the plugin function must return with the
> program image
> parameters. (See High level boot sequence for details about boot flow).
> 
> 
> So if SPL should work as a plugin as NXP defines it, SPL is supposed to
> load the image from somewhere. The boot ROM then only takes care about
> image verification and further boot steps, but it's the plugins job to
> get the image from somewhere and store it in RAM.
> 

Right, and this is also the weak point. There are also some cases (at
least, in some projects of mine) where this conflicts with the setup of
the RAM controller. We need to set the RAM controller to load the code
or to fight with the limitation of the IRAM.

> Afact this is not really helpful in our case. We would want the boot ROM
> to go through the boot sequence (again).

Agree. This makes the whole boot process easier to understand - and not
to mention the fact that code of BootROM is not officially published,
and we cannot know what it exactly does.

> 
> Unless returning an error/invalid image causes the boot ROM to go
> through boot sequence again?
> 
> 
> The nice thing with our own SDP implementation is we can reuse it even
> from within U-Boot again, e.g. to download a kernel/initramfs

Right - I think SDP is a nice solution, and thanks for your effort !

> 
>>> The initial SDP implementation (patch 2) requires the payload to
>>> have the imx specific headers (hence the move of the imx header
>>> file in patch 1).
>>>
>>> Patch 3 extends image header support beyond the SDP specification,
>>> specifically implements also support for U-Boot headers. This
>>> allows to use the same SPL/U-Boot binaries for recovery as used on
>>> the regular boot device (SD/eMMC). For that to work also the host
>>> side imx_usb tools needed an extension, currently available here:
>>>
>>> https://github.com/toradex/imx_loader/tree/imx_usb_batch_mode_refactored
>>>
>>> The full patchset allows to download SPL and U-Boot over USB to a
>>> target in recovery mode using the same usb_imx utility:
>>
>> imx_usb?
>>
> 
> Yeah right, sorry.

But what about to merge into the official imx_usb repo ?

> 
>>> The usb_imx utility also has a batch mode which allows to download
>>> multiple artifacts with a single invocation. The details are
>>> outlined in the imx_usb commit message:
>>> https://github.com/toradex/imx_loader/commit/5434415d921f1cc4d22332d9558bed6d42db9f60
>>>
>>> In case this patchset gets accepted in U-Boot, I plan to push the
>>> imx_usb changes upstream as well.
>>>
>>
>> Do you have numbers for how much code/data size this adds to SPL?
>>
> 
> Besides the protocol implementation also general USB (gadget) support is
> required, hence it adds quite a bit.
> 
> 
> Without USB Gadget/SDP support (Apalis iMX6 SPL):
> 
> $ arm-linux-gnueabihf-size spl/u-boot-spl
>textdata bss dec hex filename
>   245523808  92   284526f24 spl/u-boot-spl
> 
> 
> With USB Gadget/SDP support:
> 
> $ arm-linux-gnueabihf-size spl/u-boot-spl
>textdata bss dec hex filename
>   4254946791984   49212c03c spl/u-boot-spl


mmmhhh...ok, I see.

> 
> 
>> I believe some i.MX users have struggled to stay within the
>> size of internal RAM.
> 
> Hm, I think the limit is somewhere around 64kiB? In our case we are
> still well below...

I will try to build. The issue is with MX6 Solo (and some lower level
MX6) because it has 64KB IRAM and due 

[U-Boot] [PATCH v2 5/5] arm: socfpga: Enable cff driver build

[tien . fong . chee]

From: Tien Fong Chee 

Enable cff driver build which is needed as intermediate driver for handling
operation of FPGA program between feeding FPGA design from flash into FPGA
manager.

Signed-off-by: Tien Fong Chee 
---
 arch/arm/mach-socfpga/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
index 286bfef..23fb322 100644
--- a/arch/arm/mach-socfpga/Makefile
+++ b/arch/arm/mach-socfpga/Makefile
@@ -28,6 +28,7 @@ obj-y += clock_manager_arria10.o
 obj-y  += misc_arria10.o
 obj-y  += pinmux_arria10.o
 obj-y  += reset_manager_arria10.o
+obj-y  += cff.o
 endif
 
 ifdef CONFIG_SPL_BUILD
-- 
2.2.0

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

Re: [U-Boot] [PATCH 1/2] sf: add support for GD25Q256

[Andy Yan]

Hi Jagan:

2017-08-07 16:44 GMT+08:00 Jagan Teki :

> On Fri, Aug 4, 2017 at 3:03 PM, Andy Yan  wrote:
> > Add support for GD25Q256, a 32MiB SPI Nor
> > flash from Gigadevice.
> >
> > Signed-off-by: Andy Yan 
> > ---
> >
> >  drivers/mtd/spi/sf_internal.h   | 1 +
> >  drivers/mtd/spi/spi_flash.c | 7 ---
> >  drivers/mtd/spi/spi_flash_ids.c | 1 +
> >  3 files changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/mtd/spi/sf_internal.h
> b/drivers/mtd/spi/sf_internal.h
> > index 839cdbe..357b3bc 100644
> > --- a/drivers/mtd/spi/sf_internal.h
> > +++ b/drivers/mtd/spi/sf_internal.h
> > @@ -37,6 +37,7 @@ enum spi_nor_option_flags {
> >  #define SPI_FLASH_CFI_MFR_SST  0xbf
> >  #define SPI_FLASH_CFI_MFR_WINBOND  0xef
> >  #define SPI_FLASH_CFI_MFR_ATMEL0x1f
> > +#define SPI_FLASH_CIF_MFR_GIGADEVICE   0xc8
> >
> >  /* Erase commands */
> >  #define CMD_ERASE_4K   0x20
> > diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
> > index 0034a28..cf23077 100644
> > --- a/drivers/mtd/spi/spi_flash.c
> > +++ b/drivers/mtd/spi/spi_flash.c
> > @@ -74,7 +74,7 @@ static int write_sr(struct spi_flash *flash, u8 ws)
> > return 0;
> >  }
> >
> > -#if defined(CONFIG_SPI_FLASH_SPANSION) || defined(CONFIG_SPI_FLASH_
> WINBOND)
> > +#if defined(CONFIG_SPI_FLASH_SPANSION) || defined(CONFIG_SPI_FLASH_WINBOND)
> || defined(CONFIG_SPI_FLASH_GIGADEVICE)
> >  static int read_cr(struct spi_flash *flash, u8 *rc)
> >  {
> > int ret;
> > @@ -807,7 +807,7 @@ int stm_unlock(struct spi_flash *flash, u32 ofs,
> size_t len)
> >  #endif
> >
> >
> > -#ifdef CONFIG_SPI_FLASH_MACRONIX
> > +#if defined(CONFIG_SPI_FLASH_MACRONIX) || defined(CONFIG_SPI_FLASH_
> GIGADEVICE)
>
> So GB and Macronix has same procedure bit for Quadenable? in that case
> why you need read_cr bcz it is part of spansion.
>


 Sorr, I forgot remove it. It has been removed in V2.



> thanks!
> --
> Jagan Teki
> Free Software Engineer | www.openedev.com
> U-Boot, Linux | Upstream Maintainer
> Hyderabad, India.
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [linux-sunxi] [PATCH 1/2] sunxi: add PRCM secure switch register definition

[icenowy]

在 2017-08-08 12:13，Chen-Yu Tsai 写道：

On Thu, Jul 20, 2017 at 2:00 PM, Icenowy Zheng  wrote:

Some new Allwinner SoCs' PRCM has a secure switch register, which
controls the access to some clock and power registers in PRCM block.

Add the definition of this register and its bits in the PRCM header
file.

Signed-off-by: Icenowy Zheng 


Could you provide a reference as to where or how you found out
about this?


https://github.com/tinalinux/brandy/blob/r18-v0.9/arm-trusted-firmware-1.0/plat/sun50iw1p1/sunxi_security.c#L105



Thanks
ChenYu

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

[U-Boot] [PATCH 2/5] imx: mx6qp add AQoS setting for IPU

[Peng Fan]

Bypass QoS for IPU and increase bankwidth threshold
for PRE to get better performance for video.

Signed-off-by: Peng Fan 
Cc: Stefano Babic 
Cc: Fabio Estevam 
---
 arch/arm/include/asm/arch-mx6/imx-regs.h | 47 
 arch/arm/mach-imx/mx6/clock.c| 37 +++--
 2 files changed, 82 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/arch-mx6/imx-regs.h 
b/arch/arm/include/asm/arch-mx6/imx-regs.h
index 86e2670..5468d59 100644
--- a/arch/arm/include/asm/arch-mx6/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx6/imx-regs.h
@@ -74,6 +74,8 @@
 #define GPV0_BASE_ADDR  0x00B0
 #define GPV1_BASE_ADDR  0x00C0
 
+#define MF2_SCHED_BASE_ADDR0x00BB
+
 #define AIPS1_ARB_BASE_ADDR 0x0200
 #define AIPS1_ARB_END_ADDR  0x020F
 #define AIPS2_ARB_BASE_ADDR 0x0210
@@ -985,5 +987,50 @@ struct pwm_regs {
u32 pr;
u32 cnr;
 };
+
+/* For i.MX6DQP */
+#define AQOS_G2D_ID0
+#define AQOS_G3DPRIM_READ_ID   1
+#define AQOS_G3DPRIM_WRITE_ID  2
+#define AQOS_G3DSEC_READ_ID3
+#define AQOS_G3DSEC_WRITE_ID   4
+#define AQOS_MPCORE0_ID5
+#define AQOS_MPCORE1_ID6
+#define AQOS_IPU1_ID   7
+#define AQOS_IPU2_ID   8
+#define AQOS_OPENVG_ID 9
+#define AQOS_FAST1FARIC_ID 10
+#define AQOS_PRE0_ID   11
+#define AQOS_PRE1_ID   12
+#define AQOS_PRE2_ID   13
+#define AQOS_PRE3_ID   14
+
+struct aqos_regs {
+   u32 coreid;
+   u32 revid;
+   u32 priority;
+   u32 mode;
+   u32 bandwidth;
+   u32 saturation;
+   u32 extcontrol;
+   u32 reserved[25];
+};
+
+struct sched_ctrl_regs {
+   u32 coreid;
+   u32 revid;
+   u32 ddrconf;
+   u32 ddrtiming;
+   u32 ddrmode;
+   u32 readlatency;
+   u32 res0[4];
+   u32 ipu1;
+   u32 ipu2;
+   u32 res1[2];
+   u32 active;
+   u32 res2[49];
+   struct aqos_regs aqos[0];
+};
+
 #endif /* __ASSEMBLER__*/
 #endif /* __ASM_ARCH_MX6_IMX_REGS_H__ */
diff --git a/arch/arm/mach-imx/mx6/clock.c b/arch/arm/mach-imx/mx6/clock.c
index 1f2739e..73250aa 100644
--- a/arch/arm/mach-imx/mx6/clock.c
+++ b/arch/arm/mach-imx/mx6/clock.c
@@ -1297,7 +1297,33 @@ int do_mx6_showclocks(cmd_tbl_t *cmdtp, int flag, int 
argc, char * const argv[])
return 0;
 }
 
-#ifndef CONFIG_MX6SX
+static void pre_misc_setting(void)
+{
+   struct sched_ctrl_regs *regs =
+   (struct sched_ctrl_regs *)MF2_SCHED_BASE_ADDR;
+
+   /* Bypass IPU1 QoS generator */
+   writel(0x0002, >aqos[AQOS_IPU1_ID].mode);
+   /* Bypass IPU2 QoS generator */
+   writel(0x0002, >aqos[AQOS_IPU2_ID].mode);
+   /* Bandwidth THR for of PRE0 */
+   writel(0x0200, >aqos[AQOS_PRE0_ID].bandwidth);
+   /* Bandwidth THR for of PRE1 */
+   writel(0x0200, >aqos[AQOS_PRE1_ID].bandwidth);
+   /* Bandwidth THR for of PRE2 */
+   writel(0x0200, >aqos[AQOS_PRE2_ID].bandwidth);
+   /* Bandwidth THR for of PRE3 */
+   writel(0x0200, >aqos[AQOS_PRE3_ID].bandwidth);
+   /* Saturation THR for of PRE0 */
+   writel(0x0010, >aqos[AQOS_PRE0_ID].saturation);
+   /* Saturation THR for of PRE1 */
+   writel(0x0010, >aqos[AQOS_PRE1_ID].saturation);
+   /* Saturation THR for of PRE2 */
+   writel(0x0010, >aqos[AQOS_PRE2_ID].saturation);
+   /* Saturation THR for of PRE */
+   writel(0x0010, >aqos[AQOS_PRE3_ID].saturation);
+}
+
 void enable_ipu_clock(void)
 {
struct mxc_ccm_reg *mxc_ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
@@ -1309,9 +1335,16 @@ void enable_ipu_clock(void)
if (is_mx6dqp()) {
setbits_le32(_ccm->CCGR6, MXC_CCM_CCGR6_PRG_CLK0_MASK);
setbits_le32(_ccm->CCGR3, MXC_CCM_CCGR3_IPU2_IPU_MASK);
+
+   /*
+* Since CONFIG_VIDEO_IPUV3 is always set in
+* mx6sabre_common.h and this misc setting is
+* a must for mx6qp, this position is ok to for
+* such settings.
+*/
+   pre_misc_setting();
}
 }
-#endif
 
 #if defined(CONFIG_MX6Q) || defined(CONFIG_MX6D) || defined(CONFIG_MX6DL) || \
defined(CONFIG_MX6S)
-- 
2.6.2

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

[U-Boot] [PATCH 3/5] imx: mx6qp: Adjust AQos settings for peripherals

[Peng Fan]

To resolve USB camera bandwidth issue, the patch sets recommended AQoS
setting from IC team value for peripheral and only on imx6qp.

Signed-off-by: Peng Fan 
Cc: Stefano Babic 
Cc: Fabio Estevam 
---
 arch/arm/mach-imx/mx6/soc.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/mach-imx/mx6/soc.c b/arch/arm/mach-imx/mx6/soc.c
index 9c3c8dd..e2ecc3a 100644
--- a/arch/arm/mach-imx/mx6/soc.c
+++ b/arch/arm/mach-imx/mx6/soc.c
@@ -362,6 +362,9 @@ static void set_preclk_from_osc(void)
 
 int arch_cpu_init(void)
 {
+   struct sched_ctrl_regs *regs =
+   (struct sched_ctrl_regs *)MF2_SCHED_BASE_ADDR;
+
init_aips();
 
/* Need to clear MMDC_CHx_MASK to make warm reset work. */
@@ -431,6 +434,14 @@ int arch_cpu_init(void)
 
imx_set_wdog_powerdown(false); /* Disable PDE bit of WMCR register */
 
+   /*
+* To resolve USB camera bandwidth issue, the patch sets
+* recommended AQoS setting from IC team value for peripheral
+* and only on imx6qp.
+*/
+   if (is_mx6dqp())
+   writel(0x8201, >aqos[AQOS_FAST1FARIC_ID].priority);
+
init_src();
 
return 0;
-- 
2.6.2

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

[U-Boot] [PATCH 5/5] imx: mx6sl: simplify code using setbits_le32

[Peng Fan]

Simplify code by removing set_preclk_from_osc with directly setbits_le32.

Signed-off-by: Peng Fan 
Cc: Stefano Babic 
Cc: Fabio Estevam 
---
 arch/arm/mach-imx/mx6/soc.c | 17 ++---
 1 file changed, 2 insertions(+), 15 deletions(-)

diff --git a/arch/arm/mach-imx/mx6/soc.c b/arch/arm/mach-imx/mx6/soc.c
index b4ec11a..976179e 100644
--- a/arch/arm/mach-imx/mx6/soc.c
+++ b/arch/arm/mach-imx/mx6/soc.c
@@ -348,18 +348,6 @@ static void init_bandgap(void)
}
 }
 
-#ifdef CONFIG_MX6SL
-static void set_preclk_from_osc(void)
-{
-   struct mxc_ccm_reg *mxc_ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
-   u32 reg;
-
-   reg = readl(_ccm->cscmr1);
-   reg |= MXC_CCM_CSCMR1_PER_CLK_SEL_MASK;
-   writel(reg, _ccm->cscmr1);
-}
-#endif
-
 int arch_cpu_init(void)
 {
struct sched_ctrl_regs *regs =
@@ -429,9 +417,8 @@ int arch_cpu_init(void)
}
 
/* Set perclk to source from OSC 24MHz */
-#if defined(CONFIG_MX6SL)
-   set_preclk_from_osc();
-#endif
+   if (is_mx6sl())
+   setbits_le32(>cscmr1, MXC_CCM_CSCMR1_PER_CLK_SEL_MASK);
 
imx_set_wdog_powerdown(false); /* Disable PDE bit of WMCR register */
 
-- 
2.6.2

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

Re: [U-Boot] [PATCH] config: ls1012aqds: Add USB EHCI support for ls1012aqds

[Prabhakar Kushwaha]

> -Original Message-
> From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of
> yinbo@nxp.com
> Sent: Thursday, July 27, 2017 3:19 PM
> To: u-boot@lists.denx.de
> Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
> ; Mihai Emilian Bantea ;
> Horia Geantă ; Marc Zyngier
> ; Gang Liu ; open list  ker...@vger.kernel.org>; Scott Wood ; Rajat Srivastava
> ; Yinbo Zhu ; moderated
> list:ARM64 PORT (AARCH64 ARCHITECTURE)  ker...@lists.infradead.org>
> Subject: [U-Boot] [PATCH] config: ls1012aqds: Add USB EHCI support for
> ls1012aqds
> 
> From: Rajesh Bhagat 
> 
> Add USB EHCI support for ls1012aqds platform
> 
> Signed-off-by: Rajat Srivastava 
> Signed-off-by: Rajesh Bhagat 
> Signed-off-by: yinbo.zhu 
> ---
>  arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h | 1 +
>  include/configs/ls1012aqds.h   | 2 ++
>  include/usb/ehci-ci.h  | 2 +-
>  3 files changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
> b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
> index 8ad199f..4afc338 100644
> --- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
> +++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
> @@ -35,6 +35,7 @@
>  #define CONFIG_SYS_XHCI_USB1_ADDR(CONFIG_SYS_IMMR +
> 0x01f0)
>  #define CONFIG_SYS_XHCI_USB2_ADDR(CONFIG_SYS_IMMR +
> 0x0200)
>  #define CONFIG_SYS_XHCI_USB3_ADDR(CONFIG_SYS_IMMR +
> 0x0210)
> +#define CONFIG_SYS_EHCI_USB1_ADDR(CONFIG_SYS_IMMR +
> 0x0760)
>  #define CONFIG_SYS_PCIE1_ADDR(CONFIG_SYS_IMMR +
> 0x240)
>  #define CONFIG_SYS_PCIE2_ADDR(CONFIG_SYS_IMMR +
> 0x250)
>  #define CONFIG_SYS_PCIE3_ADDR(CONFIG_SYS_IMMR +
> 0x260)
> diff --git a/include/configs/ls1012aqds.h b/include/configs/ls1012aqds.h
> index 5b8500b..55f2578 100644
> --- a/include/configs/ls1012aqds.h
> +++ b/include/configs/ls1012aqds.h
> @@ -115,6 +115,8 @@
> 
>  #ifdef CONFIG_HAS_FSL_DR_USB
>  #define CONFIG_USB_EHCI_FSL
> +#define CONFIG_USB_ULPI
> +#define CONFIG_USB_ULPI_VIEWPORT
>  #define CONFIG_EHCI_HCD_INIT_AFTER_RESET
>  #endif
> 
> diff --git a/include/usb/ehci-ci.h b/include/usb/ehci-ci.h
> index 847b698..cd3eb47 100644
> --- a/include/usb/ehci-ci.h
> +++ b/include/usb/ehci-ci.h
> @@ -156,7 +156,7 @@
>  #elif defined(CONFIG_MPC85xx)
>  #define CONFIG_SYS_FSL_USB1_ADDR CONFIG_SYS_MPC85xx_USB1_ADDR
>  #define CONFIG_SYS_FSL_USB2_ADDR CONFIG_SYS_MPC85xx_USB2_ADDR
> -#elif defined(CONFIG_ARCH_LS1021A)
> +#elif defined(CONFIG_LS102XA) || defined(CONFIG_ARCH_LS1012A)

Why CONFIG_ARCH_LS1021A has been replaced by CONFIG_LS102XA?

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

Re: [U-Boot] [PATCH] x86: Remove dead ISA related codes

[Bin Meng]

On Sun, Aug 6, 2017 at 1:16 PM, Simon Glass  wrote:
> On 3 August 2017 at 23:52, Bin Meng  wrote:
>> Neither new design uses ISA bus, nor does any U-Boot codes use these
>> codes. Remove them.
>>
>> Signed-off-by: Bin Meng 
>> ---
>>
>>  arch/x86/include/asm/io.h | 74 
>> +--
>>  1 file changed, 8 insertions(+), 66 deletions(-)
>>
>
> Reviewed-by: Simon Glass 

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v0 21/20] efi_loader: hack for archs that cannot do unaligned accesses

[Alexander Graf]

> Am 07.08.2017 um 23:18 schrieb Rob Clark :
> 
> On Mon, Aug 7, 2017 at 5:14 PM, Mark Kettenis  wrote:
>>> From: Alexander Graf 
>>> Date: Mon, 7 Aug 2017 21:19:37 +0100
>>> 
 On 05.08.17 21:31, Rob Clark wrote:
> On Sat, Aug 5, 2017 at 4:05 PM, Heinrich Schuchardt  
> wrote:
>> On 08/05/2017 08:43 PM, Rob Clark wrote:
>>> On Sat, Aug 5, 2017 at 1:06 PM, Rob Clark  wrote:
 On Sat, Aug 5, 2017 at 12:52 PM, Heinrich Schuchardt 
  wrote:
> On 08/05/2017 06:16 PM, Rob Clark wrote:
>> On Sat, Aug 5, 2017 at 12:12 PM, Heinrich Schuchardt 
>>  wrote:
>>> On 08/05/2017 05:58 PM, Rob Clark wrote:
>>> Some arch's have trouble with unaligned accesses.  Technically
>>> EFI device-path structs should be byte aligned, and the next node
>>> in the path starts immediately after the previous.  Meaning that
>>> a pointer to an 'struct efi_device_path' is not necessarily word
>>> aligned.  See section 10.3.1 in v2.7 of UEFI spec.
>>> 
>>> This causes problems not just for u-boot, but also most/all EFI
>>> payloads loaded by u-boot on these archs.  Fortunately the common
>>> practice for traversing a device path is to rely on the length
>>> field in the header, rather than the specified length of the
>>> particular device path type+subtype.  So the EFI_DP_PAD() macro
>>> will add the specified number of bytes to the tail of device path
>>> structs to pad them to word alignment.
>>> 
>>> Technically this is non-compliant, BROKEN_UNALIGNED should *only*
>>> be defined on archs that cannot do unaligned accesses.
>>> 
>>> Signed-off-by: Rob Clark 
>>> ---
>>> I'm not sure if there are other arch's that need -DBROKEN_UNALIGNED
>>> 
>>> Mark, this is untested but I think it should solve your crash on the
>>> Banana Pi.  Could you give it a try when you get a chance?
>>> 
>>>  arch/arm/config.mk   |  2 +-
>>>  include/efi_api.h| 30 
>>> ++
>>>  lib/efi_loader/efi_device_path.c |  3 +++
>>>  3 files changed, 34 insertions(+), 1 deletion(-)
>>> 
>>> diff --git a/arch/arm/config.mk b/arch/arm/config.mk
>>> index 1a9db4..067dc93a9d 100644
>>> --- a/arch/arm/config.mk
>>> +++ b/arch/arm/config.mk
>>> @@ -28,7 +28,7 @@ LLVMS_RELFLAGS  := $(call 
>>> cc-option,-mllvm,) \
>>>   $(call cc-option,-arm-use-movt=0,)
>>>  PLATFORM_RELFLAGS+= $(LLVM_RELFLAGS)
>>> 
>>> -PLATFORM_CPPFLAGS += -D__ARM__
>>> +PLATFORM_CPPFLAGS += -D__ARM__ -DBROKEN_UNALIGNED
>> 
>> NAK
>> 
>> We have more then ARM. And other architectures also create exceptions
>> for unaligned access.
>> 
>> I hate platform specific code. It should not be used outside /arch.
>> 
>> To play it save you should not use _packed at all!
>> Use memcpy to transfer between aligned and unaligned memory.
> 
> except for reasons I explained in the thread on the patch that added
> the __packed in the first place.  Sorry, this is ugly but we have to
> do it.
> 
> BR,
> -R
 
 According to the UEFI standard the nodes in paths are not to be assumed
 to be aligned.
 
 So even if you use padding bytes in paths that you pass to the EFI
 application you should not expect that the EFI application does the
 same. Expect the EFI application either to remove them or send new 
 nodes
 without padding.
 
 To the idea of padding bytes and __packed does not make sense.
>>> 
>>> Ok, to be fair, you are right about device-paths passed too u-boot.
>>> On BROKEN_UNALIGNED archs, we should sanitise with a copy to an
>>> aligned device-path in *addition* to what I proposed.  I can make a
>>> patch to add a helper to do this a bit later.
>> 
>> so thinking about this a bit, I have two options in mind:
>> 
>>  + efi_dp_sanitize() + efi_dp_free() helpers that are no-ops on
>>archs that can do unaligned access, but efi_dp_sanitize() always
>>allocates and copies on BROKEN_UNALIGNED archs and efi_dp_free()
>>always free's on BROKEN_UNALIGNED archs, even if the dp passed
>>from efi payload doesn't require it.
>> 
>>  + efi_dp_sanitize() that is no-op on archs that can do unaligned
>>access but only allocates/copies when passed a device path that
>>would result in 

Re: [U-Boot] [PATCH 1/3] ARM: i.MX6: exclude the ARM errata from i.MX6 UP system

[Stefano Babic]

Hi Peng,

On 08/08/2017 07:34, Peng Fan wrote:
> The ARM errata 751472, 794072, 761320 only applied
> to the following configuration:
> 
> This erratum affects configurations with either:
> - One processor if the ACP is present
> - Two or more processors
> 

Apart that I agree that such as work-around should be applied just to
the affected SOCs, which is the issues to apply them to the whole MX6
family ?

For example, 751472 requires to set CP15 bit 11 with a specific
sequence. Right, single core MX6 do not need it, but even if this is set
in this way, is there a side-effect ? Just curious...

> i.MX6 family does not have the ACP and thus only the MPCore system
> will be impacted, which are the i.MX6DQ, i.MX6DL, and i.MX6QP.
> 
> Signed-off-by: Peng Fan 
> Cc: Stefano Babic 
> Cc: Fabio Estevam 
> ---
>  arch/arm/mach-imx/mx6/Kconfig | 15 +++
>  1 file changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/mach-imx/mx6/Kconfig b/arch/arm/mach-imx/mx6/Kconfig
> index bb2ce33..2be67e1 100644
> --- a/arch/arm/mach-imx/mx6/Kconfig
> +++ b/arch/arm/mach-imx/mx6/Kconfig
> @@ -1,24 +1,31 @@
>  if ARCH_MX6
>  
> +config MX6_SMP
> + select ARM_ERRATA_751472
> + select ARM_ERRATA_761320
> + select ARM_ERRATA_794072
> + bool
> +
>  config MX6
> + select ARM_ERRATA_743622 if !MX6UL
>   bool
>   default y
> - select ARM_ERRATA_743622 if !MX6UL
> - select ARM_ERRATA_751472 if !MX6UL
> - select ARM_ERRATA_761320 if !MX6UL
> - select ARM_ERRATA_794072 if !MX6UL
>   imply CMD_FUSE
>  
>  config MX6D
> + select MX6_SMP
>   bool
>  
>  config MX6DL
> + select MX6_SMP
>   bool
>  
>  config MX6Q
> + select MX6_SMP
>   bool
>  
>  config MX6QDL
> + select MX6_SMP
>   bool
>  
>  config MX6S
> 

Best regards,
Stefano

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

Re: [U-Boot] [PATCH] fsl-lsch2: csu: correct the workaround A-010315

[Z.q. Hou]

Hi York,

Thanks a lot for your comments!

> -Original Message-
> From: York Sun
> Sent: 2017年8月8日 5:18
> To: Z.q. Hou ; u-boot@lists.denx.de
> Subject: Re: [PATCH] fsl-lsch2: csu: correct the workaround A-010315
> 
> On 07/03/2017 03:07 AM, Zhiqiang Hou wrote:
> > From: Hou Zhiqiang 
> >
> > The implementation of workaround A-010315 is wrong, it updated other
> > IP's CSU registers.
> >
> > Signed-off-by: Hou Zhiqiang 
> > ---
> >   board/freescale/common/ns_access.c | 20 ++--
> >   include/fsl_csu.h  |  2 +-
> >   2 files changed, 11 insertions(+), 11 deletions(-)
> >
> > diff --git a/board/freescale/common/ns_access.c
> > b/board/freescale/common/ns_access.c
> > index 1c2287d..0c3a54c 100644
> > --- a/board/freescale/common/ns_access.c
> > +++ b/board/freescale/common/ns_access.c
> > @@ -10,15 +10,15 @@
> >   #include 
> >   #include 
> >
> > -void set_devices_ns_access(struct csu_ns_dev *ns_dev, u16 val)
> > +void set_devices_ns_access(unsigned long index, u16 val)
> >   {
> > u32 *base = (u32 *)CONFIG_SYS_FSL_CSU_ADDR;
> > u32 *reg;
> > uint32_t tmp;
> >
> > -   reg = base + ns_dev->ind / 2;
> > +   reg = base + index / 2;
> > tmp = in_be32(reg);
> > -   if (ns_dev->ind % 2 == 0) {
> > +   if (index % 2 == 0) {
> > tmp &= 0x;
> > tmp |= val << 16;
> > } else {
> > @@ -34,7 +34,7 @@ static void enable_devices_ns_access(struct
> csu_ns_dev *ns_dev, uint32_t num)
> > int i;
> >
> > for (i = 0; i < num; i++)
> > -   set_devices_ns_access(ns_dev + i, ns_dev[i].val);
> > +   set_devices_ns_access(ns_dev[i].ind, ns_dev[i].val);
> >   }
> >
> >   void enable_layerscape_ns_access(void) @@ -50,20 +50,20 @@ void
> > set_pcie_ns_access(int pcie, u16 val)
> > switch (pcie) {
> >   #ifdef CONFIG_PCIE1
> > case PCIE1:
> > -   set_devices_ns_access(_dev[CSU_CSLX_PCIE1], val);
> > -   set_devices_ns_access(_dev[CSU_CSLX_PCIE1_IO], val);
> > +   set_devices_ns_access(CSU_CSLX_PCIE1, val);
> > +   set_devices_ns_access(CSU_CSLX_PCIE1_IO, val);
> > return;
> >   #endif
> >   #ifdef CONFIG_PCIE2
> > case PCIE2:
> > -   set_devices_ns_access(_dev[CSU_CSLX_PCIE2], val);
> > -   set_devices_ns_access(_dev[CSU_CSLX_PCIE2_IO], val);
> > +   set_devices_ns_access(CSU_CSLX_PCIE2, val);
> > +   set_devices_ns_access(CSU_CSLX_PCIE2_IO, val);
> > return;
> >   #endif
> >   #ifdef CONFIG_PCIE3
> > case PCIE3:
> > -   set_devices_ns_access(_dev[CSU_CSLX_PCIE3], val);
> > -   set_devices_ns_access(_dev[CSU_CSLX_PCIE3_IO], val);
> > +   set_devices_ns_access(CSU_CSLX_PCIE3, val);
> > +   set_devices_ns_access(CSU_CSLX_PCIE3_IO, val);
> > return;
> >   #endif
> > default:
> > diff --git a/include/fsl_csu.h b/include/fsl_csu.h index
> > 8582ac0..027a811 100644
> > --- a/include/fsl_csu.h
> > +++ b/include/fsl_csu.h
> > @@ -30,7 +30,7 @@ struct csu_ns_dev {
> >   };
> >
> >   void enable_layerscape_ns_access(void);
> > -void set_devices_ns_access(struct csu_ns_dev *ns_dev, u16 val);
> > +void set_devices_ns_access(unsigned long, u16 val);
> >   void set_pcie_ns_access(int pcie, u16 val);
> >
> >   #endif
> >
> 
> Zhiqiang,
> 
> Your subject and commit message both say fixing the workaround for
> A010315 but the change is for non-secure access. Did you mismatch them?

No, this patch is to fix a error of workaround A-010315.
The function set_pcie_ns_access() is wrongly implemented during add wordaround 
A-010315.
The structure array ns_dev has a member 'ind' which is initialized by 
CSU_CSLX_*, the mistake is I use its member 'ind' as the index of array ns_dev, 
actually it should use the 'ind' directly to address the PCIe's CSL register 
(CSL_base + CSU_CSLX_PCIE*).
With the current argument list of set_pcie_ns_access(struct csu_ns_dev *ns_dev, 
u16 val), it hard to find and set the specified IP block's non-secure access, 
so this patch also changed the first argument to the 'ind' of structure 
csu_ns_dev.

Thanks,
Zhiqiang

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

Re: [U-Boot] [PATCH v2 5/5] arm: socfpga: Enable cff driver build

[Chee, Tien Fong]

On Sel, 2017-08-08 at 11:32 +0200, Marek Vasut wrote:
> On 08/08/2017 11:12 AM, tien.fong.c...@intel.com wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > Enable cff driver build which is needed as intermediate driver for
> > handling
> > operation of FPGA program between feeding FPGA design from flash
> > into FPGA
> > manager.
> > 
> > Signed-off-by: Tien Fong Chee 
> > ---
> >  arch/arm/mach-socfpga/Makefile | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-
> > socfpga/Makefile
> > index 286bfef..23fb322 100644
> > --- a/arch/arm/mach-socfpga/Makefile
> > +++ b/arch/arm/mach-socfpga/Makefile
> > @@ -28,6 +28,7 @@ obj-y += clock_manager_arria10.o
> >  obj-y  += misc_arria10.o
> >  obj-y  += pinmux_arria10.o
> >  obj-y  += reset_manager_arria10.o
> > +obj-y  += cff.o
> Keep the list sorted ...
> 
Okay.
> > 
> >  endif
> >  
> >  ifdef CONFIG_SPL_BUILD
> > 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH V2] spi: mxc_spi: support driver model

[Peng Fan]

Add driver model support for mxc spi driver.
Most functions are restructured to be reused by DM and non-DM.
Tested on mx6slevk/mx6qsabresd board.

Signed-off-by: Peng Fan 
Cc: Jagan Teki 
cc: Stefano Babic 
---

V2:
 return -ENODEV when dev_get_addr not return a valid value.
 Pass error value from dm_gpio_set_value to caller, if error happends.

 drivers/spi/mxc_spi.c | 181 +-
 1 file changed, 149 insertions(+), 32 deletions(-)

diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c
index e1562c3..41f0cfc 100644
--- a/drivers/spi/mxc_spi.c
+++ b/drivers/spi/mxc_spi.c
@@ -5,6 +5,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -14,6 +15,8 @@
 #include 
 #include 
 
+DECLARE_GLOBAL_DATA_PTR;
+
 #ifdef CONFIG_MX27
 /* i.MX27 has a completely wrong register layout and register definitions in 
the
  * datasheet, the correct one is in the Freescale's Linux driver */
@@ -22,10 +25,6 @@
 "See linux mxc_spi driver from Freescale for details."
 #endif
 
-static unsigned long spi_bases[] = {
-   MXC_SPI_BASE_ADDRESSES
-};
-
 __weak int board_spi_cs_gpio(unsigned bus, unsigned cs)
 {
return -1;
@@ -51,6 +50,7 @@ struct mxc_spi_slave {
int ss_pol;
unsigned intmax_hz;
unsigned intmode;
+   struct gpio_desc ss;
 };
 
 static inline struct mxc_spi_slave *to_mxc_spi_slave(struct spi_slave *slave)
@@ -58,19 +58,24 @@ static inline struct mxc_spi_slave *to_mxc_spi_slave(struct 
spi_slave *slave)
return container_of(slave, struct mxc_spi_slave, slave);
 }
 
-void spi_cs_activate(struct spi_slave *slave)
+static void mxc_spi_cs_activate(struct mxc_spi_slave *mxcs)
 {
-   struct mxc_spi_slave *mxcs = to_mxc_spi_slave(slave);
-   if (mxcs->gpio > 0)
-   gpio_set_value(mxcs->gpio, mxcs->ss_pol);
+   if (CONFIG_IS_ENABLED(DM_SPI)) {
+   dm_gpio_set_value(>ss, mxcs->ss_pol);
+   } else {
+   if (mxcs->gpio > 0)
+   gpio_set_value(mxcs->gpio, mxcs->ss_pol);
+   }
 }
 
-void spi_cs_deactivate(struct spi_slave *slave)
+static void mxc_spi_cs_deactivate(struct mxc_spi_slave *mxcs)
 {
-   struct mxc_spi_slave *mxcs = to_mxc_spi_slave(slave);
-   if (mxcs->gpio > 0)
-   gpio_set_value(mxcs->gpio,
- !(mxcs->ss_pol));
+   if (CONFIG_IS_ENABLED(DM_SPI)) {
+   dm_gpio_set_value(>ss, !(mxcs->ss_pol));
+   } else {
+   if (mxcs->gpio > 0)
+   gpio_set_value(mxcs->gpio, !(mxcs->ss_pol));
+   }
 }
 
 u32 get_cspi_div(u32 div)
@@ -211,10 +216,9 @@ static s32 spi_cfg_mxc(struct mxc_spi_slave *mxcs, 
unsigned int cs)
 }
 #endif
 
-int spi_xchg_single(struct spi_slave *slave, unsigned int bitlen,
+int spi_xchg_single(struct mxc_spi_slave *mxcs, unsigned int bitlen,
const u8 *dout, u8 *din, unsigned long flags)
 {
-   struct mxc_spi_slave *mxcs = to_mxc_spi_slave(slave);
int nbytes = DIV_ROUND_UP(bitlen, 8);
u32 data, cnt, i;
struct cspi_regs *regs = (struct cspi_regs *)mxcs->base;
@@ -327,8 +331,9 @@ int spi_xchg_single(struct spi_slave *slave, unsigned int 
bitlen,
 
 }
 
-int spi_xfer(struct spi_slave *slave, unsigned int bitlen, const void *dout,
-   void *din, unsigned long flags)
+static int mxc_spi_xfer_internal(struct mxc_spi_slave *mxcs,
+unsigned int bitlen, const void *dout,
+void *din, unsigned long flags)
 {
int n_bytes = DIV_ROUND_UP(bitlen, 8);
int n_bits;
@@ -337,11 +342,11 @@ int spi_xfer(struct spi_slave *slave, unsigned int 
bitlen, const void *dout,
u8 *p_outbuf = (u8 *)dout;
u8 *p_inbuf = (u8 *)din;
 
-   if (!slave)
-   return -1;
+   if (!mxcs)
+   return -EINVAL;
 
if (flags & SPI_XFER_BEGIN)
-   spi_cs_activate(slave);
+   mxc_spi_cs_activate(mxcs);
 
while (n_bytes > 0) {
if (n_bytes < MAX_SPI_BYTES)
@@ -351,7 +356,7 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen, 
const void *dout,
 
n_bits = blk_size * 8;
 
-   ret = spi_xchg_single(slave, n_bits, p_outbuf, p_inbuf, 0);
+   ret = spi_xchg_single(mxcs, n_bits, p_outbuf, p_inbuf, 0);
 
if (ret)
return ret;
@@ -363,12 +368,39 @@ int spi_xfer(struct spi_slave *slave, unsigned int 
bitlen, const void *dout,
}
 
if (flags & SPI_XFER_END) {
-   spi_cs_deactivate(slave);
+   mxc_spi_cs_deactivate(mxcs);
}
 
return 0;
 }
 
+static int mxc_spi_claim_bus_internal(struct mxc_spi_slave *mxcs, int cs)
+{
+   struct cspi_regs *regs = (struct cspi_regs *)mxcs->base;
+   int ret;
+
+   reg_write(>rxdata, 1);
+   udelay(1);
+   

Re: [U-Boot] [PATCH 1/1] i2c: add i2c driver for stm32

[Heiko Schocher]

Hi Simon, Patrice,

Am 06.08.2017 um 07:15 schrieb Simon Glass:

Hi Patrice,

On 25 July 2017 at 10:02,   wrote:

From: Patrice Chotard 

Add i2c driver which can be used on both STM32F7 and STM32H7.
This I2C block supports the following features:
  _ Slave and master modes
  _ Multimaster capability
  _ Standard-mode (up to 100 kHz)
  _ Fast-mode (up to 400 kHz)
  _ Fast-mode Plus (up to 1 MHz)
  _ 7-bit and 10-bit addressing mode
  _ Multiple 7-bit slave addresses (2 addresses, 1 with configurable mask)
  _ All 7-bit addresses acknowledge mode
  _ General call
  _ Programmable setup and hold times
  _ Easy to use event management
  _ Optional clock stretching
  _ Software reset

Signed-off-by: Christophe Kerello 
Signed-off-by: Patrice Chotard 
---
  doc/device-tree-bindings/i2c/i2c-stm32.txt |  30 ++
  drivers/i2c/Kconfig|   7 +
  drivers/i2c/Makefile   |   1 +
  drivers/i2c/stm32f7_i2c.c  | 839 +
  4 files changed, 877 insertions(+)
  create mode 100644 doc/device-tree-bindings/i2c/i2c-stm32.txt
  create mode 100644 drivers/i2c/stm32f7_i2c.c


[...]

diff --git a/drivers/i2c/stm32f7_i2c.c b/drivers/i2c/stm32f7_i2c.c
new file mode 100644
index 000..255b38a
--- /dev/null
+++ b/drivers/i2c/stm32f7_i2c.c
@@ -0,0 +1,839 @@
+/*
+ * (C) Copyright 2017 STMicroelectronics
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+/* STM32 I2C registers */
+struct stm32_i2c_regs {
+   u32 cr1;/* I2C control register 1 */
+   u32 cr2;/* I2C control register 2 */
+   u32 oar1;   /* I2C own address 1 register */
+   u32 oar2;   /* I2C own address 2 register */
+   u32 timingr;/* I2C timing register */
+   u32 timeoutr;   /* I2C timeout register */
+   u32 isr;/* I2C interrupt and status register */
+   u32 icr;/* I2C interrupt clear register */
+   u32 pecr;   /* I2C packet error checking register */
+   u32 rxdr;   /* I2C receive data register */
+   u32 txdr;   /* I2C transmit data register */
+};
+
+#define STM32_I2C_CR1  0x00
+#define STM32_I2C_CR2  0x04


Do you really need these STM32_I2C prefixes?


Why not? I think this makes it clearer reading the drivers code.
Beside of this, I am in sync with Simons comments.

@Patrice: Can you prepare a v2 please? Thanks!

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
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v1 5/7] spl: add serial download protocol (SDP) support

[Stefan Agner]

Stefano,

One question below:

On 2017-08-04 16:38, Stefan Agner wrote:
> From: Stefan Agner 
> 
> Add USB serial download protocol support to SPL. If the SoC started
> in recovery mode the SPL will immediately switch to SDP and wait for
> further downloads/commands from the host side.
> 
> Signed-off-by: Stefan Agner 
> ---
> 
>  common/spl/Kconfig  |  6 ++
>  common/spl/Makefile |  1 +
>  common/spl/spl_sdp.c| 38 ++
>  drivers/usb/gadget/Makefile |  1 +
>  4 files changed, 46 insertions(+)
>  create mode 100644 common/spl/spl_sdp.c
> 
> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> index 4de81392b0..95378b98a0 100644
> --- a/common/spl/Kconfig
> +++ b/common/spl/Kconfig
> @@ -646,6 +646,12 @@ config SPL_DFU_RAM
>  
>  endchoice
>  
> +config SPL_USB_SDP_SUPPORT
> + bool "Support SDP (Serial Download Protocol)"
> + help
> +   Enable Serial Download Protocol (SDP) device support in SPL. This
> +   allows to download images into memory and execute (jump to) them
> +   using the same protocol as implemented by the i.MX family's boot ROM.
>  endif
>  
>  config SPL_WATCHDOG_SUPPORT
> diff --git a/common/spl/Makefile b/common/spl/Makefile
> index 47a64dd7d0..a979560acf 100644
> --- a/common/spl/Makefile
> +++ b/common/spl/Makefile
> @@ -29,4 +29,5 @@ obj-$(CONFIG_SPL_SATA_SUPPORT) += spl_sata.o
>  obj-$(CONFIG_SPL_DFU_SUPPORT) += spl_dfu.o
>  obj-$(CONFIG_SPL_SPI_LOAD) += spl_spi.o
>  obj-$(CONFIG_SPL_RAM_SUPPORT) += spl_ram.o
> +obj-$(CONFIG_SPL_USB_SDP_SUPPORT) += spl_sdp.o
>  endif
> diff --git a/common/spl/spl_sdp.c b/common/spl/spl_sdp.c
> new file mode 100644
> index 00..faa74b8bec
> --- /dev/null
> +++ b/common/spl/spl_sdp.c
> @@ -0,0 +1,38 @@
> +/*
> + * (C) Copyright 2016 Toradex
> + * Author: Stefan Agner 
> + *
> + * SPDX-License-Identifier:  GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +static int spl_sdp_load_image(struct spl_image_info *spl_image,
> +   struct spl_boot_device *bootdev)
> +{
> + int ret;
> +
> + g_dnl_clear_detach();
> + g_dnl_register("usb_dnl_sdp");
> +
> + ret = sdp_init();
> + if (ret) {
> + error("SDP init failed: %d", ret);
> + return -ENODEV;
> + }
> +
> + ret = sdp_handle();
> + if (ret) {
> + error("SDP failed: %d", ret);
> + return -ENODEV;
> + }
> +
> + return 0;
> +}
> +SPL_LOAD_IMAGE_METHOD("USB SDP", 0, BOOT_DEVICE_UART, spl_sdp_load_image);


We currently use BOOT_DEVICE_UART when serial downloader boot mode is
detected. This can be either USB or UART...

In fact, USB is probably much more often used since only 6UL/ULL have
UART serial downloader support afact...

There is BOOT_DEVICE_BOARD which is used by e.g. Sunxi in case the boot
ROM mechanism is used, what do you think, should be change that?

Ideally we should be able to discriminate between USB and UART. But I
don't think its possible... (the USBPH0_PWD method likely does not work
since even in the UART case the boot ROM will initialize the USB PHY
first, at least according to the flow diagram in ULL's Chapter 9...)

The i.MX 7 which has the new Boot Information block actually only
support USB serial downloader...

Thoughts?

--
Stefan


> diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile
> index 6a007d1bcb..7258099c1c 100644
> --- a/drivers/usb/gadget/Makefile
> +++ b/drivers/usb/gadget/Makefile
> @@ -11,6 +11,7 @@ obj-$(CONFIG_USB_ETHER) += epautoconf.o config.o usbstring.o
>  ifdef CONFIG_SPL_BUILD
>  obj-$(CONFIG_SPL_USB_GADGET_SUPPORT) += g_dnl.o
>  obj-$(CONFIG_SPL_DFU_SUPPORT) += f_dfu.o
> +obj-$(CONFIG_SPL_USB_SDP_SUPPORT) += f_sdp.o
>  endif
>  
>  # new USB gadget layer dependencies
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] ls1046aqds: update the defaule mtdparts

[Xiaowei Bao]

Hi York,

The default partition is mainly to facilitate the test staff to view the 
partition information of the storage medium, And the jira ticket also carry by 
the test staff, I am not sure if it need to push the opensource.

Qspi did not do partition processing, because of hardware design reason, the 
different boot mode need different pbl.bin, and the Qspi is only 16M, our 
partition rule is 64M include all of images, so did not do partition of Qspi.

Thanks

-Original Message-
From: York Sun 
Sent: Wednesday, August 09, 2017 12:41 AM
To: Xiaowei Bao ; Mingkai Hu ; Sumit 
Garg ; u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH] ls1046aqds: update the defaule mtdparts

On 08/07/2017 07:48 PM, Xiaowei Bao wrote:
> Hi York,
> 
> This patch is for the ls1046aqds platform, In order to facilitate the test 
> staff and customers to view the detailed partition information, so didn't 
> define a larger partition to include all images, and the partition rule  is 
> discussed internally as the default partitioning standard for the layerscape 
> platform.

If you start to partition flashes by every image, are you going to do the same 
for QSPI?

> 
> thanks
> 
> -Original Message-
> From: York Sun
> Sent: Tuesday, August 08, 2017 6:31 AM
> To: Xiaowei Bao ; Mingkai Hu 
> ; Sumit Garg ; 
> u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH] ls1046aqds: update the defaule mtdparts
> 
> On 07/12/2017 04:44 AM, xiaowei.bao wrote:
>> From: Bao Xiaowei 
>>
>> modify the include/configs/ls1046aqds.h file, according to the latest 
>> partion rules, norflash nandflash dspiflash detailed partion as follows:
>>
>> mtd0: 0010 0002 "nor_bank0_rcw"
>> mtd1: 0020 0002 "nor_bank0_uboot"
>> mtd2: 0010 0002 "nor_bank0_uboot_env"
>> mtd3: 0020 0002 "nor_bank0_ppa"
>> mtd4: 0030 0002 "nor_bank0_secure_boot"
>> mtd5: 0060 0002 "nor_bank0_dppa_qe"
>> mtd6: 0010 0002 "nor_bank0_dtb"
>> mtd7: 0100 0002 "nor_bank0_kernel"
>> mtd8: 0200 0002 "nor_bank0_rootfs"
>> mtd9: 0010 0002 "nor_bank4_rcw"
>> mtd10: 0020 0002 "nor_bank4_uboot"
>> mtd11: 0020 0002 "nor_bank4_uboot_env"
>> mtd12: 0010 0002 "nor_bank4_ppa"
>> mtd13: 0030 0002 "nor_bank4_secure_boot"
>> mtd14: 0060 0002 "nor_bank4_dppa_qe"
>> mtd15: 0010 0002 "nor_bank4_dtb"
>> mtd16: 0100 0002 "nor_bank4_kernel"
>> mtd17: 0200 0002 "nor_bank4_rootfs"

When you boot from bank4, your partition name will not match the physical bank.

>> mtd18: 0010 0004 "nand_rcw"
>> mtd19: 0020 0004 "nand_uboot"
>> mtd20: 0010 0004 "nand_uboot_env"
>> mtd21: 0020 0004 "nand_ppa"
>> mtd22: 0030 0004 "nand_secure_boot"
>> mtd23: 0060 0004 "nand_dppa_qe"
>> mtd24: 0010 0004 "nand_dtb"
>> mtd25: 0100 0004 "nand_kernel"
>> mtd26: 0200 0004 "nand_rootfs"
>> mtd27: 1c00 0004 "nand_free"
>> mtd28: 0100 0001 "spi0_free"
>> mtd29: 0008 1000 "spi1_free"
>> mtd30: 0080 1000 "spi2_free"
> 
> Do we really need to expose every image as individual partition? It is only 
> useful if we need to access them under Linux. What's the chance to update 
> U-Boot environmental variables under Linux? If you really to do so, you can 
> probably be fine by defining a larger partition to include all images used 
> for U-Boot. Agree?

My point is, who uses these partitions? If it is only for testing, you can keep 
this variable local, or leave it to your test script. You are not going to use 
default values of ipaddr, or serverip, are you? Why do you rely on the default 
value of mtdparts? It doesn't even get used by U-Boot itself.

York

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

Re: [U-Boot] [PATCH] fsl-lsch2: csu: correct the workaround A-010315

[Z.q. Hou]

Hi York,

> -Original Message-
> From: York Sun
> Sent: 2017年8月9日 0:17
> To: Z.q. Hou ; u-boot@lists.denx.de
> Subject: Re: [PATCH] fsl-lsch2: csu: correct the workaround A-010315
> 
> On 08/07/2017 11:31 PM, Z.q. Hou wrote:
> > Hi York,
> >
> > Thanks a lot for your comments!
> >
> >> -Original Message-
> >> From: York Sun
> >> Sent: 2017年8月8日 5:18
> >> To: Z.q. Hou ; u-boot@lists.denx.de
> >> Subject: Re: [PATCH] fsl-lsch2: csu: correct the workaround A-010315
> >>
> >> On 07/03/2017 03:07 AM, Zhiqiang Hou wrote:
> >>> From: Hou Zhiqiang 
> >>>
> >>> The implementation of workaround A-010315 is wrong, it updated other
> >>> IP's CSU registers.
> >>>
> >>> Signed-off-by: Hou Zhiqiang 
> >>> ---
> >>>board/freescale/common/ns_access.c | 20 ++--
> >>>include/fsl_csu.h  |  2 +-
> >>>2 files changed, 11 insertions(+), 11 deletions(-)
> >>>
> >>> diff --git a/board/freescale/common/ns_access.c
> >>> b/board/freescale/common/ns_access.c
> >>> index 1c2287d..0c3a54c 100644
> >>> --- a/board/freescale/common/ns_access.c
> >>> +++ b/board/freescale/common/ns_access.c
> >>> @@ -10,15 +10,15 @@
> >>>#include 
> >>>#include 
> >>>
> >>> -void set_devices_ns_access(struct csu_ns_dev *ns_dev, u16 val)
> >>> +void set_devices_ns_access(unsigned long index, u16 val)
> >>>{
> >>>   u32 *base = (u32 *)CONFIG_SYS_FSL_CSU_ADDR;
> >>>   u32 *reg;
> >>>   uint32_t tmp;
> >>>
> >>> - reg = base + ns_dev->ind / 2;
> >>> + reg = base + index / 2;
> >>>   tmp = in_be32(reg);
> >>> - if (ns_dev->ind % 2 == 0) {
> >>> + if (index % 2 == 0) {
> >>>   tmp &= 0x;
> >>>   tmp |= val << 16;
> >>>   } else {
> >>> @@ -34,7 +34,7 @@ static void enable_devices_ns_access(struct
> >> csu_ns_dev *ns_dev, uint32_t num)
> >>>   int i;
> >>>
> >>>   for (i = 0; i < num; i++)
> >>> - set_devices_ns_access(ns_dev + i, ns_dev[i].val);
> >>> + set_devices_ns_access(ns_dev[i].ind, ns_dev[i].val);
> >>>}
> >>>
> >>>void enable_layerscape_ns_access(void) @@ -50,20 +50,20 @@ void
> >>> set_pcie_ns_access(int pcie, u16 val)
> >>>   switch (pcie) {
> >>>#ifdef CONFIG_PCIE1
> >>>   case PCIE1:
> >>> - set_devices_ns_access(_dev[CSU_CSLX_PCIE1], val);
> >>> - set_devices_ns_access(_dev[CSU_CSLX_PCIE1_IO], val);
> >>> + set_devices_ns_access(CSU_CSLX_PCIE1, val);
> >>> + set_devices_ns_access(CSU_CSLX_PCIE1_IO, val);
> >>>   return;
> >>>#endif
> >>>#ifdef CONFIG_PCIE2
> >>>   case PCIE2:
> >>> - set_devices_ns_access(_dev[CSU_CSLX_PCIE2], val);
> >>> - set_devices_ns_access(_dev[CSU_CSLX_PCIE2_IO], val);
> >>> + set_devices_ns_access(CSU_CSLX_PCIE2, val);
> >>> + set_devices_ns_access(CSU_CSLX_PCIE2_IO, val);
> >>>   return;
> >>>#endif
> >>>#ifdef CONFIG_PCIE3
> >>>   case PCIE3:
> >>> - set_devices_ns_access(_dev[CSU_CSLX_PCIE3], val);
> >>> - set_devices_ns_access(_dev[CSU_CSLX_PCIE3_IO], val);
> >>> + set_devices_ns_access(CSU_CSLX_PCIE3, val);
> >>> + set_devices_ns_access(CSU_CSLX_PCIE3_IO, val);
> >>>   return;
> >>>#endif
> >>>   default:
> >>> diff --git a/include/fsl_csu.h b/include/fsl_csu.h index
> >>> 8582ac0..027a811 100644
> >>> --- a/include/fsl_csu.h
> >>> +++ b/include/fsl_csu.h
> >>> @@ -30,7 +30,7 @@ struct csu_ns_dev {
> >>>};
> >>>
> >>>void enable_layerscape_ns_access(void);
> >>> -void set_devices_ns_access(struct csu_ns_dev *ns_dev, u16 val);
> >>> +void set_devices_ns_access(unsigned long, u16 val);
> >>>void set_pcie_ns_access(int pcie, u16 val);
> >>>
> >>>#endif
> >>>
> >>
> >> Zhiqiang,
> >>
> >> Your subject and commit message both say fixing the workaround for
> >> A010315 but the change is for non-secure access. Did you mismatch them?
> >
> > No, this patch is to fix a error of workaround A-010315.
> > The function set_pcie_ns_access() is wrongly implemented during add
> wordaround A-010315.
> > The structure array ns_dev has a member 'ind' which is initialized by
> CSU_CSLX_*, the mistake is I use its member 'ind' as the index of array 
> ns_dev,
> actually it should use the 'ind' directly to address the PCIe's CSL register
> (CSL_base + CSU_CSLX_PCIE*).
> > With the current argument list of set_pcie_ns_access(struct csu_ns_dev
> *ns_dev, u16 val), it hard to find and set the specified IP block's non-secure
> access, so this patch also changed the first argument to the 'ind' of 
> structure
> csu_ns_dev.
> >
> 
> Zhiqiang,
> 
> Thanks for the explanation. I will try to rephase the commit message with the
> information you provided.

Ok, thanks a lot!

- Zhiqiang

___
U-Boot mailing list

Re: [U-Boot] [linux-sunxi] [PATCH 1/2] sunxi: add PRCM secure switch register definition

[Chen-Yu Tsai]

On Tue, Aug 8, 2017 at 2:46 PM,   wrote:
> 在 2017-08-08 12:13，Chen-Yu Tsai 写道：
>>
>> On Thu, Jul 20, 2017 at 2:00 PM, Icenowy Zheng  wrote:
>>>
>>> Some new Allwinner SoCs' PRCM has a secure switch register, which
>>> controls the access to some clock and power registers in PRCM block.
>>>
>>> Add the definition of this register and its bits in the PRCM header
>>> file.
>>>
>>> Signed-off-by: Icenowy Zheng 
>>
>>
>> Could you provide a reference as to where or how you found out
>> about this?
>
>
> https://github.com/tinalinux/brandy/blob/r18-v0.9/arm-trusted-firmware-1.0/plat/sun50iw1p1/sunxi_security.c#L105

I assume you've mapped out what each bit means by testing it?

Tested-by: Chen-Yu Tsai 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [linux-sunxi] [PATCH 1/2] sunxi: add PRCM secure switch register definition

[icenowy]

在 2017-08-09 11:46，Chen-Yu Tsai 写道：

On Tue, Aug 8, 2017 at 2:46 PM,   wrote:

在 2017-08-08 12:13，Chen-Yu Tsai 写道：


On Thu, Jul 20, 2017 at 2:00 PM, Icenowy Zheng  
wrote:


Some new Allwinner SoCs' PRCM has a secure switch register, which
controls the access to some clock and power registers in PRCM block.

Add the definition of this register and its bits in the PRCM header
file.

Signed-off-by: Icenowy Zheng 



Could you provide a reference as to where or how you found out
about this?



https://github.com/tinalinux/brandy/blob/r18-v0.9/arm-trusted-firmware-1.0/plat/sun50iw1p1/sunxi_security.c#L105


I assume you've mapped out what each bit means by testing it?


Yes.

Toggling bit 0 will make at least 0x0 (CPUS_CFG_REG) inaccessible.
Toggling bit 1 will make at least 0x40 and 0x44 (PLL_CTRL_REG{0,1})
inaccessible.
Toggling bit 2 will make at least 0x120 (VDD_SYS_PWR_RST)
inaccessible.

(The register names are from http://linux-sunxi.org/PRCM )



Tested-by: Chen-Yu Tsai 

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

Re: [U-Boot] [PATCH 1/1] armv8: ls2080a: Increase env size for qspi boot

[Santan Kumar]

> -Original Message-
> From: York Sun
> Sent: Tuesday, August 08, 2017 11:26 PM
> To: Santan Kumar ; u-boot@lists.denx.de
> Cc: Priyanka Jain 
> Subject: Re: [PATCH 1/1] armv8: ls2080a: Increase env size for qspi boot
> 
> On 06/23/2017 03:07 AM, Santan Kumar wrote:
> > Increase env size from 64kb to 256kb for qspi boot
> >
> > Signed-off-by: Santan Kumar 
> > Signed-off-by: Priyanka Jain 
> > ---
> > This patch is split version of another patch
> >
> >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpat
> >
> chwork.ozlabs.org%2Fpatch%2F773670%2F=01%7C01%7Cyork.sun%40
> nxp.co
> >
> m%7Cf71f395a0cb94adb322b08d4ba1fb900%7C686ea1d3bc2b4c6fa92cd99c5c
> 30163
> >
> 5%7C0=%2FvMEmB84i5peyUh4JMHi6k%2Fc5cm76x1JMftBeLSANWc%
> 3D
> > d=0
> >
> >   include/configs/ls2080a_common.h | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/include/configs/ls2080a_common.h
> > b/include/configs/ls2080a_common.h
> > index e311d0b..68191f2 100644
> > --- a/include/configs/ls2080a_common.h
> > +++ b/include/configs/ls2080a_common.h
> > @@ -34,7 +34,7 @@
> >   #define CONFIG_ENV_IS_IN_SPI_FLASH
> >   #define CONFIG_ENV_SIZE   0x2000  /* 8KB */
> >   #define CONFIG_ENV_OFFSET 0x30/* 3MB */
> > -#define CONFIG_ENV_SECT_SIZE   0x1
> > +#define CONFIG_ENV_SECT_SIZE   0x4
> >   #endif
> >
> >   #define CONFIG_SUPPORT_RAW_INITRD
> >
> 
> 
> Santan,
> 
> You are increasing the sector size, not the env size. Is this what you intend 
> to
> do?
> 
> York

[Santan] Yes, my intent is to increase the sector size, because the env erase 
will work in the multiple of 
256kb. If you want I can change the commit message.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/1][v2] armv8: ls2080a: Increase env sector size for qspi boot

[Santan Kumar]

Increase env sector size from 64kb to 256kb for qspi boot

Signed-off-by: Santan Kumar 
Signed-off-by: Priyanka Jain 
---
Changes for v2:
 -Change the commit message

 include/configs/ls2080a_common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/ls2080a_common.h b/include/configs/ls2080a_common.h
index e311d0b..68191f2 100644
--- a/include/configs/ls2080a_common.h
+++ b/include/configs/ls2080a_common.h
@@ -34,7 +34,7 @@
 #define CONFIG_ENV_IS_IN_SPI_FLASH
 #define CONFIG_ENV_SIZE0x2000  /* 8KB */
 #define CONFIG_ENV_OFFSET  0x30/* 3MB */
-#define CONFIG_ENV_SECT_SIZE   0x1
+#define CONFIG_ENV_SECT_SIZE   0x4
 #endif
 
 #define CONFIG_SUPPORT_RAW_INITRD
-- 
1.9.1

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

[U-Boot] [PATCH] drivers: spi: Remove atmel_dataflash_spi driver

[Wenyou Yang]

This driver is replaced by the SPI-flash-based AT45xxx DataFlash
driver, which supports the driver model and device tree, the
atmel_dataflash_spi driver will not be used any more.

Signed-off-by: Wenyou Yang 
---

 drivers/spi/Makefile  |   1 -
 drivers/spi/atmel_dataflash_spi.c | 184 --
 2 files changed, 185 deletions(-)
 delete mode 100644 drivers/spi/atmel_dataflash_spi.c

diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 9f8b86de76..7b598fd988 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -17,7 +17,6 @@ endif
 
 obj-$(CONFIG_ALTERA_SPI) += altera_spi.o
 obj-$(CONFIG_ATH79_SPI) += ath79_spi.o
-obj-$(CONFIG_ATMEL_DATAFLASH_SPI) += atmel_dataflash_spi.o
 obj-$(CONFIG_ATMEL_SPI) += atmel_spi.o
 obj-$(CONFIG_CADENCE_QSPI) += cadence_qspi.o cadence_qspi_apb.o
 obj-$(CONFIG_CF_SPI) += cf_spi.o
diff --git a/drivers/spi/atmel_dataflash_spi.c 
b/drivers/spi/atmel_dataflash_spi.c
deleted file mode 100644
index a2e9c00ea6..00
--- a/drivers/spi/atmel_dataflash_spi.c
+++ /dev/null
@@ -1,184 +0,0 @@
-/*
- * Driver for ATMEL DataFlash support
- * Author : Hamid Ikdoumi (Atmel)
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-/*
- * This driver desperately needs rework:
- *
- * - use structure SoC access
- * - get rid of including asm/arch/at91_spi.h
- * - remove asm/arch/at91_spi.h
- * - get rid of all CONFIG_ATMEL_LEGACY defines and uses
- *
- * 02-Aug-2010 Reinhard Meyer 
- */
-
-#include 
-#ifndef CONFIG_ATMEL_LEGACY
-# define CONFIG_ATMEL_LEGACY
-#endif
-#include 
-#include 
-
-#include 
-
-#include 
-#include 
-
-#include "atmel_spi.h"
-
-#include 
-#include 
-#include 
-
-#include 
-
-#define AT91_SPI_PCS0_DATAFLASH_CARD   0xE /* Chip Select 0: NPCS0%1110 */
-#define AT91_SPI_PCS1_DATAFLASH_CARD   0xD /* Chip Select 1: NPCS1%1101 */
-#define AT91_SPI_PCS2_DATAFLASH_CARD   0xB /* Chip Select 2: NPCS2%1011 */
-#define AT91_SPI_PCS3_DATAFLASH_CARD   0x7 /* Chip Select 3: NPCS3%0111 */
-
-void AT91F_SpiInit(void)
-{
-   /* Reset the SPI */
-   writel(AT91_SPI_SWRST, ATMEL_BASE_SPI0 + AT91_SPI_CR);
-
-   /* Configure SPI in Master Mode with No CS selected !!! */
-   writel(AT91_SPI_MSTR | AT91_SPI_MODFDIS | AT91_SPI_PCS,
-  ATMEL_BASE_SPI0 + AT91_SPI_MR);
-
-   /* Configure CS0 */
-   writel(AT91_SPI_NCPHA |
-  (AT91_SPI_DLYBS & DATAFLASH_TCSS) |
-  (AT91_SPI_DLYBCT & DATAFLASH_TCHS) |
-  ((get_mck_clk_rate() / AT91_SPI_CLK) << 8),
-  ATMEL_BASE_SPI0 + AT91_SPI_CSR(0));
-
-#ifdef CONFIG_SYS_DATAFLASH_LOGIC_ADDR_CS1
-   /* Configure CS1 */
-   writel(AT91_SPI_NCPHA |
-  (AT91_SPI_DLYBS & DATAFLASH_TCSS) |
-  (AT91_SPI_DLYBCT & DATAFLASH_TCHS) |
-  ((get_mck_clk_rate() / AT91_SPI_CLK) << 8),
-  ATMEL_BASE_SPI0 + AT91_SPI_CSR(1));
-#endif
-#ifdef CONFIG_SYS_DATAFLASH_LOGIC_ADDR_CS2
-   /* Configure CS2 */
-   writel(AT91_SPI_NCPHA |
-  (AT91_SPI_DLYBS & DATAFLASH_TCSS) |
-  (AT91_SPI_DLYBCT & DATAFLASH_TCHS) |
-  ((get_mck_clk_rate() / AT91_SPI_CLK) << 8),
-  ATMEL_BASE_SPI0 + AT91_SPI_CSR(2));
-#endif
-#ifdef CONFIG_SYS_DATAFLASH_LOGIC_ADDR_CS3
-   /* Configure CS3 */
-   writel(AT91_SPI_NCPHA |
-  (AT91_SPI_DLYBS & DATAFLASH_TCSS) |
-  (AT91_SPI_DLYBCT & DATAFLASH_TCHS) |
-  ((get_mck_clk_rate() / AT91_SPI_CLK) << 8),
-  ATMEL_BASE_SPI0 + AT91_SPI_CSR(3));
-#endif
-
-   /* SPI_Enable */
-   writel(AT91_SPI_SPIEN, ATMEL_BASE_SPI0 + AT91_SPI_CR);
-
-   while (!(readl(ATMEL_BASE_SPI0 + AT91_SPI_SR) & AT91_SPI_SPIENS))
-   ;
-
-   /*
-* Add tempo to get SPI in a safe state.
-* Should not be needed for new silicon (Rev B)
-*/
-   udelay(50);
-   readl(ATMEL_BASE_SPI0 + AT91_SPI_SR);
-   readl(ATMEL_BASE_SPI0 + AT91_SPI_RDR);
-
-}
-
-void AT91F_SpiEnable(int cs)
-{
-   unsigned long mode;
-
-   mode = readl(ATMEL_BASE_SPI0 + AT91_SPI_MR);
-   mode &= ~AT91_SPI_PCS;
-
-   switch (cs) {
-   case 0:
-   mode |= AT91_SPI_PCS0_DATAFLASH_CARD << 16;
-   break;
-   case 1:
-   mode |= AT91_SPI_PCS1_DATAFLASH_CARD << 16;
-   break;
-   case 2:
-   mode |= AT91_SPI_PCS2_DATAFLASH_CARD << 16;
-   break;
-   case 3:
-   mode |= AT91_SPI_PCS3_DATAFLASH_CARD << 16;
-   break;
-   }
-
-   writel(mode, ATMEL_BASE_SPI0 + AT91_SPI_MR);
-
-   /* SPI_Enable */
-   writel(AT91_SPI_SPIEN, ATMEL_BASE_SPI0 + AT91_SPI_CR);
-}
-
-unsigned int AT91F_SpiWrite1(AT91PS_DataflashDesc pDesc);
-
-unsigned int AT91F_SpiWrite(AT91PS_DataflashDesc pDesc)
-{
-   unsigned int timeout;
-   unsigned int timebase;
-
-   pDesc->state = 

Re: [U-Boot] [U-Boot, v0, 07/20] vsprintf.c: add wide string (%ls) support

[Rob Clark]

On Tue, Aug 8, 2017 at 8:14 PM, Rob Clark  wrote:
> On Tue, Aug 8, 2017 at 7:55 PM, Alexander Graf  wrote:
>>
>>
>> On 09.08.17 00:39, Rob Clark wrote:
>>>
>>> On Tue, Aug 8, 2017 at 7:08 PM, Heinrich Schuchardt 
>>> wrote:

 On 08/09/2017 12:44 AM, Rob Clark wrote:
>
> On Tue, Aug 8, 2017 at 6:03 PM, Heinrich Schuchardt 
> wrote:
>>
>> On 08/04/2017 09:31 PM, Rob Clark wrote:
>>>
>>> This is convenient for efi_loader which deals a lot with utf16.
>>>
>>> Signed-off-by: Rob Clark 
>>
>>
>> Please, put this patch together with
>> [PATCH] vsprintf.c: add GUID printing
>> https://patchwork.ozlabs.org/patch/798362/
>> and
>> [PATCH v0 06/20] common: add some utf16 handling helpers
>> https://patchwork.ozlabs.org/patch/797968/
>> into a separate patch series.
>>
>> These three patches can be reviewed independently of the efi_loader
>> patches and probably will not be integrated via the efi-next tree.
>
>
> I'll resend these as a separate patchset, and just not in next
> revision of efi_loader patchset that it is a dependency
>
>>> ---
>>>   lib/vsprintf.c | 30 --
>>>   1 file changed, 28 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
>>> index 874a2951f7..0c40f852ce 100644
>>> --- a/lib/vsprintf.c
>>> +++ b/lib/vsprintf.c
>>> @@ -17,6 +17,7 @@
>>>   #include 
>>>
>>>   #include 
>>> +#include 
>>>
>>>   #include 
>>>   #define noinline __attribute__((noinline))
>>> @@ -270,6 +271,26 @@ static char *string(char *buf, char *end, char
>>> *s, int field_width,
>>>return buf;
>>>   }
>>>
>>> +static char *string16(char *buf, char *end, u16 *s, int field_width,
>>> + int precision, int flags)
>>> +{
>>> + u16 *str = s ? s : L"";
>>
>> Please, do not use the L-notation here as it requires -fshort-wchar.
>> As we currently cannot switch the complete project to C11 you cannot
>> use
>> the u-notation either.
>
>
> current plan was to either switch whole project to -fshort-wchar or
> c11 and rework these patches (as well as a few patches in the
> efi_loader patchset).  (In the c11 case, I'm not sure what we'll use
> as the fmt string, since afaict that isn't specified.  We could use %S
> although that seems to be a deprecated way to do %ls, or something
> different like %A, I guess)..
>
> how far are we from c11?  If there is stuff I can do to help let me
> know.  If feasible, I'd rather do that first rather than have a bunch
> of stuff in vsprintf and elsewhere that needs to be cleaned up later
> after the switch.


 buildman downloads very old compilers (gcc < 4.8) from kernel.org which
 do not support C11.
 Travis CI uses Ubuntu 14.04 with gcc 4.8.4 which incorrectly throws an
 error for disk/part.c in C11 mode.
>>>
>>>
>>> ugg, 4.8 is pretty old..   Not sure how much older than 4.8 buildman
>>> uses.  It seems like *some* c11 was supported w/ >=4.6 so if we
>>> approach the conversion piecemeal (for example skipping code that
>>> triggers gcc bugs on old compilers) we might be able to keep 4.8.4
>>> working until travis provides something newer.
>>>
>>> (btw, even going back say 8 fedora releases or more, I've used distro
>>> packaged arm and aarch64 toolchains exclusively.. are there that many
>>> distro's where we really can't assume availability of an
>>> cross-toolchain?  If there isn't something newer from kernel.org can
>>> we just drop relying on ancient prebuilt toolchains?  I'm anyways not
>>> hugely a fan of downloading binary executables from even kernel.org,
>>> instead of using something from a distro build system which I at least
>>> know is very locked down.)
>>>
 To get things right we would have to
 * build our own cross tool chains based on a current gcc version
 * use our own tool chain in Travis for x86-64 or use a docker
container with a current gcc version.

 In the long run heading for C11 would be the right thing to do.
 Until then use an initializer { '<', 'N', 'U', 'L', 'L', '>' }.
 It looks ugly but does not consume more bytes once compiled.

>>>
>>> Sure, that I'm less worried about, as much as adding stuff that is
>>> very soon going to be legacy.  Even in vfprintf.c it isn't such a big
>>> deal, as efi_loader where it would be more cumbersome.
>>>
>>> Maybe we can write out u"" longhand in vsprintf.c as you
>>> suggest, but restrict efi_loader to gcc >= 4.9?  That seems like it
>>> shouldn't be a problem for any arm/arm64 device and it shouldn't be a
>>> problem for any device that is likely to have an efi payload to load
>>> in the first place..
>>
>>
>> I don't 

Re: [U-Boot] [PATCH 2/2] sunxi: switch PRCM to non-secure on H3/H5 SoCs

[Chen-Yu Tsai]

On Thu, Jul 27, 2017 at 3:31 AM, Maxime Ripard
 wrote:
> On Wed, Jul 26, 2017 at 07:55:24PM +0800, icen...@aosc.io wrote:
>> 在 2017-07-20 14:00，Icenowy Zheng 写道：
>> > The PRCM of H3/H5 SoCs have a secure/non-secure switch, which controls
>> > the access to some clock/power related registers in PRCM.
>> >
>> > Current Linux kernel will access the CPUS (AR100) clock in the PRCM
>> > block, so the PRCM should be switched to non-secure.
>> >
>> > Add code to switch the PRCM to non-secure.
>>
>> Ping.
>>
>> Maxime and Jagan, can you merge this patchset?
>>
>> This is necessary for R_CCU to work properly on H3.
>
> Acked-by: Maxime Ripard 

Tested-by: Chen-Yu Tsai 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] Configs: Migrate CONFIG_SYS_I2C_OMAP34XX to CONFIG_SYS_I2C_OMAP24XX

[Heiko Schocher]

Hello Adam,

Am 07.08.2017 um 20:11 schrieb Adam Ford:

The driver is for all boards 24XX and up, so let's eliminate the
extra option called CONFIG_SYS_I2C_OMAP34XX since the driver checks
for CONFIG_OMAP34XX we don't need CONFIG_SYS_I2C_OMAP34XX.

Signed-off-by: Adam Ford 
---
  arch/arm/mach-omap2/omap3/clock.c   | 2 +-
  board/compulab/cm_t35/cm_t35.c  | 2 +-
  board/logicpd/am3517evm/am3517evm.c | 2 +-
  board/ti/am3517crane/am3517crane.c  | 2 +-
  board/ti/evm/evm.c  | 2 +-
  drivers/i2c/Makefile| 1 -
  include/configs/am3517_crane.h  | 2 +-
  include/configs/am3517_evm.h| 2 +-
  include/configs/cm_t35.h| 2 +-
  include/configs/cm_t3517.h  | 2 +-
  include/configs/cm_t54.h| 2 +-
  include/configs/devkit8000.h| 2 +-
  include/configs/mcx.h   | 2 +-
  include/configs/nokia_rx51.h| 2 +-
  include/configs/omap3_evm.h | 2 +-
  include/configs/omap3_logic.h   | 2 +-
  include/configs/omap3_overo.h   | 2 +-
  include/configs/omap3_pandora.h | 2 +-
  include/configs/omap3_zoom1.h   | 2 +-
  include/configs/sniper.h| 2 +-
  include/configs/tam3517-common.h| 2 +-
  include/configs/tao3530.h   | 2 +-
  include/configs/tricorder.h | 2 +-
  scripts/config_whitelist.txt| 1 -
  24 files changed, 22 insertions(+), 24 deletions(-)


Thanks!

Reviewed-by: Heiko Schocher 

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

Re: [U-Boot] [PATCH 1/1] armv8: ls2080a: Increase env size for qspi boot

[York Sun]

> On Aug 8, 2017, at 21:21, Santan Kumar  wrote:
> 
> 
> 
>> -Original Message-
>> From: York Sun
>> Sent: Tuesday, August 08, 2017 11:26 PM
>> To: Santan Kumar ; u-boot@lists.denx.de
>> Cc: Priyanka Jain 
>> Subject: Re: [PATCH 1/1] armv8: ls2080a: Increase env size for qspi boot
>> 
>>> On 06/23/2017 03:07 AM, Santan Kumar wrote:
>>> Increase env size from 64kb to 256kb for qspi boot
>>> 
>>> Signed-off-by: Santan Kumar 
>>> Signed-off-by: Priyanka Jain 
>>> ---
>>> This patch is split version of another patch
>>> 
>>> 
>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpat
>>> 
>> chwork.ozlabs.org%2Fpatch%2F773670%2F=01%7C01%7Cyork.sun%40
>> nxp.co
>>> 
>> m%7Cf71f395a0cb94adb322b08d4ba1fb900%7C686ea1d3bc2b4c6fa92cd99c5c
>> 30163
>>> 
>> 5%7C0=%2FvMEmB84i5peyUh4JMHi6k%2Fc5cm76x1JMftBeLSANWc%
>> 3D
>>> d=0
>>> 
>>>  include/configs/ls2080a_common.h | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>> 
>>> diff --git a/include/configs/ls2080a_common.h
>>> b/include/configs/ls2080a_common.h
>>> index e311d0b..68191f2 100644
>>> --- a/include/configs/ls2080a_common.h
>>> +++ b/include/configs/ls2080a_common.h
>>> @@ -34,7 +34,7 @@
>>>  #define CONFIG_ENV_IS_IN_SPI_FLASH
>>>  #define CONFIG_ENV_SIZE0x2000  /* 8KB */
>>>  #define CONFIG_ENV_OFFSET0x30/* 3MB */
>>> -#define CONFIG_ENV_SECT_SIZE0x1
>>> +#define CONFIG_ENV_SECT_SIZE0x4
>>>  #endif
>>> 
>>>  #define CONFIG_SUPPORT_RAW_INITRD
>>> 
>> 
>> 
>> Santan,
>> 
>> You are increasing the sector size, not the env size. Is this what you 
>> intend to
>> do?
>> 
>> York
> 
> [Santan] Yes, my intent is to increase the sector size, because the env erase 
> will work in the multiple of 
>256kb. If you want I can change the commit message.

Please resend with fixed subject and commit message. Thanks. 

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

Re: [U-Boot] [PATCH v2 4/5] arm: socfpga: Add intermediate driver between flash and FPGA manager

[Chee, Tien Fong]

On Sel, 2017-08-08 at 12:11 +0200, Marek Vasut wrote:
> On 08/08/2017 12:06 PM, Chee, Tien Fong wrote:
> > 
> > On Sel, 2017-08-08 at 11:32 +0200, Marek Vasut wrote:
> > > 
> > > On 08/08/2017 11:12 AM, tien.fong.c...@intel.com wrote:
> > > > 
> > > > 
> > > > From: Tien Fong Chee 
> > > > 
> > > > Configuration flip-flop driver is mainly used for handling the
> > > > FPGA
> > > > program
> > > > operation where the FPGA image loading from the flash into FPGA
> > > > manager.
> > > I don't understand what this driver is for , sorry.
> > > 
> > this is core driver for handling fpga program operation from flash
> > to
> > fpga manager. I can improve the message. Let me know if you have
> > other
> > comment need to add.
> Yes, it's not clear what this driver is for. It dabbles into multiple
> subsystems , but I don't understand how is this useful.
> 
> > 
> > > 
> > > Coding style issues are present (camel case, wrong comment style,
> > > use
> > > checkpatch).
> > > 
> > Okay, i will run checkpatch.
> You should always run checkpatch before submitting patches.
> 
> > 
> > > 
> > > If this is for some FPGA loading, can this functionality be
> > > scripted
> > > instead?
> > > 
> > Sorry, i'm not getting you. How functionality be scripted? Could
> > you
> > provide some example or details explanation?
> ie. "load" (from fs) + "fpga load" (program FPGA) commands ?
> I think the fpga command already has some support for loading from FS
> too.
> 
Currently, we already have fpga load commands in fpga driver, fpga rbf
is loaded to memory, and programmed to fpga from memory, where memory
location would be decided by user, it could be OCRAM or SDRAM.

for fpga loadfs command, i plan to implement it after having complete
boot to U-boot console, since this is quite complex and involving some
hardware workaround issue, and some use case scenarios need to be
considerd. For example reconfiguring fpga with periperal rbf can
corrupt the sdram since sdram IOs is part of the fpga periph rbf. I
need console to run a lot different scenarios testing.

We still need cff.c, because most functionality in cff.c are required
by fpga loadfs command.
> > 
> > Thanks.
> > > 
> > > > 
> > > > 
> > > > Signed-off-by: Tien Fong Chee 
> > > > ---
> > > >  arch/arm/mach-socfpga/cff.c  | 582
> > > > +++
> > > >  arch/arm/mach-socfpga/include/mach/cff.h |  40 +++
> > > >  include/configs/socfpga_arria10_socdk.h  |   6 +
> > > >  3 files changed, 628 insertions(+)
> > > >  create mode 100644 arch/arm/mach-socfpga/cff.c
> > > >  create mode 100644 arch/arm/mach-socfpga/include/mach/cff.h
> > > > 
> > > > diff --git a/arch/arm/mach-socfpga/cff.c b/arch/arm/mach-
> > > > socfpga/cff.c
> > > > new file mode 100644
> > > > index 000..ccee5e9
> > > > --- /dev/null
> > > > +++ b/arch/arm/mach-socfpga/cff.c
> > > > @@ -0,0 +1,582 @@
> > > > +/*
> > > > + * COPYRIGHT (C) 2017 Intel Corporation 
> > > > + *
> > > > + * SPDX-License-Identifier:GPL-2.0
> > > > + */
> > > > +
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +
> > > > +#define RBF_UNENCRYPTED 0xa65c
> > > > +#define RBF_ENCRYPTED 0xa65d
> > > > +#define ARRIA10RBF_PERIPH 0x0001
> > > > +#define ARRIA10RBF_CORE 0x8001
> > > > +
> > > > +DECLARE_GLOBAL_DATA_PTR;
> > > > +
> > > > +static int flash_type = -1;
> > > > +
> > > > +struct mmc *mmc;
> > > > +
> > > > +/* Local functions */
> > > > +static int cff_flash_read(struct cff_flash_info
> > > > *cff_flashinfo,
> > > > u32 *buffer,
> > > > +   u32 *buffer_sizebytes);
> > > > +static int cff_flash_preinit(struct cff_flash_info
> > > > *cff_flashinfo,
> > > > +   fpga_fs_info *fpga_fsinfo, u32 *buffer, u32
> > > > *buffer_sizebytes);
> > > > +#ifdef CONFIG_CMD_FPGA_LOADFS
> > > > +static const char *get_cff_filename(const void *fdt, int *len,
> > > > u32
> > > > core);
> > > > +#else
> > > > +static int get_cff_offset(const void *fdt, u32 core);
> > > > +#endif
> > > > +
> > > > +static struct mmc *init_mmc_device(int dev, bool force_init)
> > > > +{
> > > > +   struct mmc *mmc;
> > > > +
> > > > +   mmc = find_mmc_device(dev);
> > > > +   if (!mmc) {
> > > > +   printf("no mmc device at slot %x\n", dev);
> > > > +   return NULL;
> > > > +   }
> > > > +
> > > > +   if (force_init)
> > > > +   mmc->has_init = 0;
> > > > +   if (mmc_init(mmc))
> > > > +   return NULL;
> > > > +
> > > > +   return mmc;
> > > > +}
> > > > +
> > > > +static int cff_flash_probe(struct cff_flash_info
> > > > *cff_flashinfo)
> > > > +{
> > > > +   int dev = 0;
> > > > +
> > > > +   if(BOOT_DEVICE_MMC1 

Re: [U-Boot] [PATCH v2 08/15] dm: mmc: sunxi: Pass private data around explicitly

[Chen-Yu Tsai]

Hi Simon,

On Wed, Jul 5, 2017 at 3:31 AM, Simon Glass  wrote:
> At present the driver-private data is obtained in various functions by
> various means. With driver model this is provided automatically. Without
> driver model it comes from a C array declared at the top of the file.
>
> Adjust internal functions so that they are passed the private data as
> a parameter, allowing the caller to obtain it using either means.
>
> Signed-off-by: Simon Glass 

eMMC is currently broken for sunxi on my Orangepi Plus 2E.
I've narrowed it down to this patch.

It seems the driver or device is now referencing the wrong
controller. On versions before this patch, for MMC1 (or eMMC):

=> mmc dev 1
switch to partitions #0, OK
mmc1(part 0) is current device
=> mmc info
Device: SUNXI SD/MMC
Manufacturer ID: 15
OEM: 100
Name: AWPD3
Tran Speed: 5200
Rd Block Len: 512
MMC version 5.0
High Capacity: Yes
Capacity: 14.6 GiB
Bus Width: 8-bit
Erase Group Size: 512 KiB
HC WP Group Size: 8 MiB
User Capacity: 14.6 GiB WRREL
Boot Capacity: 4 MiB ENH
RPMB Capacity: 4 MiB ENH


On later versions I get:

=> mmc dev 1
switch to partitions #0, OK
mmc1 is current device
=> mmc info
Device: SUNXI SD/MMC
Manufacturer ID: 27
OEM: 5048
Name: SD08G
Tran Speed: 5000
Rd Block Len: 512
SD version 3.0
High Capacity: Yes
Capacity: 7.4 GiB
Bus Width: 1-bit
Erase Group Size: 512 Bytes


For reference, mmc0 looks like:

=> mmc dev 0
switch to partitions #0, OK
mmc0 is current device
=> mmc info
Device: SUNXI SD/MMC
Manufacturer ID: 27
OEM: 5048
Name: SD08G
Tran Speed: 5000
Rd Block Len: 512
SD version 3.0
High Capacity: Yes
Capacity: 7.4 GiB
Bus Width: 4-bit
Erase Group Size: 512 Bytes


So it seems somewhere down the line, the driver is getting
passed the wrong set of priv data.

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

Re: [U-Boot] [PATCH] i2c: designware: Allow sending restart conditions

[Heiko Schocher]

Hello Marek,

Am 07.08.2017 um 20:45 schrieb Marek Vasut:

Allow sending restart conditions upon direction change as this is
required by some chips.

Signed-off-by: Marek Vasut 
Cc: Stefan Roese 
Cc: Alexey Brodkin 
Cc: Heiko Schocher 
---
  drivers/i2c/designware_i2c.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)


Thanks!
Reviewed-by: Heiko Schocher 

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

Re: [U-Boot] [PATCH v2 2/5] arm: socfpga: Add checking function on FPGA setting in FDT

[Chee, Tien Fong]

On Sel, 2017-08-08 at 11:29 +0200, Marek Vasut wrote:
> On 08/08/2017 11:12 AM, tien.fong.c...@intel.com wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > Function for checking FPGA early release setting which is defined
> > by user in FDT chosen section. This function would be used by
> > later driver in decision applying appropriate FPGA configuration in
> > early release or full FPGA booting mode.
> Isn't this a property of the FPGA driver ?
> Shouldn't this have altr, prefix ?
> Did this go through DT binding review?
> 
This is our own define under chosen section. This is flag to tell U-
boot what kind of boot and what kind of fpga configuration we want
during boot.
> > 
> > Signed-off-by: Tien Fong Chee 
> > ---
> >  arch/arm/mach-socfpga/include/mach/misc.h |  1 +
> >  arch/arm/mach-socfpga/misc_arria10.c  | 20
> > 
> >  2 files changed, 21 insertions(+)
> > 
> > diff --git a/arch/arm/mach-socfpga/include/mach/misc.h
> > b/arch/arm/mach-socfpga/include/mach/misc.h
> > index 0b65783..e003f8a 100644
> > --- a/arch/arm/mach-socfpga/include/mach/misc.h
> > +++ b/arch/arm/mach-socfpga/include/mach/misc.h
> > @@ -26,6 +26,7 @@ static inline void socfpga_fpga_add(void) {}
> >  unsigned int dedicated_uart_com_port(const void *blob);
> >  unsigned int shared_uart_com_port(const void *blob);
> >  unsigned int uart_com_port(const void *blob);
> > +int is_early_release_fpga_config(const void *blob);
> >  #endif
> >  
> >  #endif /* _MISC_H_ */
> > diff --git a/arch/arm/mach-socfpga/misc_arria10.c b/arch/arm/mach-
> > socfpga/misc_arria10.c
> > index 9d751f6..2d6e977 100644
> > --- a/arch/arm/mach-socfpga/misc_arria10.c
> > +++ b/arch/arm/mach-socfpga/misc_arria10.c
> > @@ -235,6 +235,26 @@ unsigned int uart_com_port(const void *blob)
> >     return shared_uart_com_port(blob);
> >  }
> >  
> > +int is_chosen_boolean_true(const void *blob, const char *name)
> > +{
> > +   int node;
> > +   int rval = 0;
> > +
> > +   node = fdt_subnode_offset(blob, 0, "chosen");
> > +
> > +   if (node >= 0)
> > +   rval = fdtdec_get_bool(blob, node, name);
> > +
> > +   return rval;
> > +}
> > +
> > +int is_early_release_fpga_config(const void *blob)
> > +{
> > +   static const char *name = "early-release-fpga-config";
> > +
> > +   return is_chosen_boolean_true(blob, name);
> > +}
> > +
> >  /*
> >   * Print CPU information
> >   */
> > 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 00/10] This patch set represent Marvell mvpp2 driver fixes

[Stefan Roese]

Hi Joe,

On 08.08.2017 17:57, Joe Hershberger wrote:

Hi Stefan (and Stefan),

On Tue, Aug 8, 2017 at 7:05 AM, Stefan Roese  wrote:

Hi Joe,

On 11.07.2017 10:04, Stefan Roese wrote:


On 21.06.2017 10:31, stef...@malvell.com wrote:


Huh? Sent from a typo email address?


Where is the problem with the Stefan Chulski's email address?
Sorry, I can't spot it.


That's pretty tedious. I
recommend fixing your git config. And if that's fine, I recommend
using patman so this won't happen again.



From: Stefan Chulski 

Issues were found during internal QA phase.

Stefan Chulski (10):
net: mvpp2x: Add GPIO configuration support
net: mvpp2x: fix phy connected to wrong mdio issue
net: mvpp2x: Enable GoP packet padding in TX
net: mvpp2x: fix BM configuration overrun issue
net: mvpp2x: decrease size of AGGR_TXQ and CPU_DESC_CHUNK
net: mvpp2x: remove MBUS configurations from MvPP22 driver
net: mvpp2x: Remove IRQ configuration from u-boot
net: mvpp2x: Set BM pool high address
net: mvpp2x: remove TX drain from transmit routine
net: mvpp2x: Set BM poll size once during priv probe

   drivers/net/mvpp2.c | 189
++--
   1 file changed, 94 insertions(+), 95 deletions(-)



Joe, do you have any comments on these mvpp2 patches?



Gently ping on these patches again. Joe, do you have any comments
on these? Do you want to take these patches via your tree? Or
should I push them if you don't have any objections?


Reviewing now. I generally use patchwork to remember what I have to
do. I guess if I didn't rely on that I would set up better work queue
email filters. Sorry for the delay.

I figured since the series is assigned to you in PW, that you wanted
it through your tree. I'm fine either way.


I assume that Tom assigned them to me (I didn't do it at least).
But I can definitely pull these patches via the Marvell tree, once
all open issues are resolved and all patches have your Acked-by
tag.

Thanks for the review!

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

Re: [U-Boot] [PATCH v0 21/20] efi_loader: hack for archs that cannot do unaligned accesses

[Rob Clark]

On Tue, Aug 8, 2017 at 7:32 AM, Leif Lindholm  wrote:
> On Tue, Aug 08, 2017 at 09:11:14AM +0100, Ard Biesheuvel wrote:
>> On 8 August 2017 at 07:52, Alexander Graf  wrote:
>> >
>> >
>> >> Am 07.08.2017 um 23:18 schrieb Rob Clark :
>> >>
>> >> This is problematic around file nodes in the device path.  Adding the
>> >> padding bytes to the end of each device-path struct would "solve"
>> >> that, and if pre-aarch64 we are aiming at "good enough to work", I
>> >> kinda think that this the approach we should go for.  Other than
>> >> file-path nodes, the rest of the issues in u-boot should be solved by
>> >> addition of missing __packed on 'struct efi_device_path' (which I've
>> >> added locally and will be in the next revision of the patchset).
>> >
>> > Let's ask Leif and Ard if that is actually correct. If I remember
>> > correctly, edk2 some times leverages automatic padding from the
>> > compiler on structs.
>>
>> I guess that that might work, if U-boot is the only agent
>> instantiating device path structures. But what do you mean by
>> 'correct' in this context?
>
> Well, if that is the case, are we risking the ability to in the future
> support loading drivers or protocols at runtime. (This would for
> example exclude Shim compatibility or running the UEFI Shell.)
>

My proposal (and this is only for <=armv6 and armv7 until someone gets
around to enabling mmu and disabling alignment faults) is to add
padding bytes at the end of the various device-path structs to at
least keep the structs (and things like utf16 string in file-path
struct) aligned, and rely on efi payload and u-boot to be compiled
with -mno-unaligned-access if it needs to access fields within the
device-path structs.

This is *essentially* what u-boot does implicitly at the moment (by
missing __packed attribute on certain structs).  I want to fix that on
aarch64, but without the padding bytes it causes a some unaligned
accesses in u-boot on armv7 devices.

I think the goal for armv7 is more to have enough uefi for grub and
OpenBSD's bootloader.  If fancy things like loading drivers and
protocols at runtime doesn't work, well these didn't work before so I
won't loose much sleep.  But I would like that to work properly on
aarch64.

BR,
-R
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1] arm: mvebu: remove self assignment

[Stefan Roese]

On 30.07.2017 21:51, Heinrich Schuchardt wrote:

Assigning dev_num to itself is superfluous.

Signed-off-by: Heinrich Schuchardt 
---
  drivers/ddr/marvell/a38x/ddr3_training_centralization.c | 2 --
  1 file changed, 2 deletions(-)

diff --git a/drivers/ddr/marvell/a38x/ddr3_training_centralization.c 
b/drivers/ddr/marvell/a38x/ddr3_training_centralization.c
index 9d216da96d..2909ae3c6f 100644
--- a/drivers/ddr/marvell/a38x/ddr3_training_centralization.c
+++ b/drivers/ddr/marvell/a38x/ddr3_training_centralization.c
@@ -697,8 +697,6 @@ int ddr3_tip_print_centralization_result(u32 dev_num)
u32 if_id = 0, bus_id = 0;
struct hws_topology_map *tm = ddr3_get_topology_map();
  
-	dev_num = dev_num;

-
printf("Centralization Results\n");
printf("I/F0 Result[0 - success 1-fail 2 - state_2 3 - state_3] ...\n");
for (if_id = 0; if_id <= MAX_INTERFACE_NUM - 1; if_id++) {



Reviewed-by: Stefan Roese 

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

Re: [U-Boot] [PATCH 1/1] arm: mvebu: ddr3_debug: remove self assignments

[Stefan Roese]

On 30.07.2017 21:54, Heinrich Schuchardt wrote:

Remove superfluous self assignements.

Signed-off-by: Heinrich Schuchardt 
---
  drivers/ddr/marvell/a38x/ddr3_debug.c | 9 -
  1 file changed, 9 deletions(-)

diff --git a/drivers/ddr/marvell/a38x/ddr3_debug.c 
b/drivers/ddr/marvell/a38x/ddr3_debug.c
index 12b5b04109..a704a3e9d3 100644
--- a/drivers/ddr/marvell/a38x/ddr3_debug.c
+++ b/drivers/ddr/marvell/a38x/ddr3_debug.c
@@ -327,8 +327,6 @@ int ddr3_tip_print_log(u32 dev_num, u32 mem_addr)
u32 if_id = 0;
struct hws_topology_map *tm = ddr3_get_topology_map();
  
-	mem_addr = mem_addr;

-
  #ifndef EXCLUDE_SWITCH_DEBUG
if ((is_validate_window_per_if != 0) ||
(is_validate_window_per_pup != 0)) {
@@ -820,7 +818,6 @@ static int ddr3_tip_access_atr(u32 dev_num, u32 flag_id, 
u32 value, u32 **ptr)
u32 tmp_val = 0, if_id = 0, pup_id = 0;
struct hws_topology_map *tm = ddr3_get_topology_map();
  
-	dev_num = dev_num;

*ptr = NULL;
  
  	switch (flag_id) {

@@ -1169,8 +1166,6 @@ int print_adll(u32 dev_num, u32 adll[MAX_INTERFACE_NUM * 
MAX_BUS_NUM])
u32 i, j;
struct hws_topology_map *tm = ddr3_get_topology_map();
  
-	dev_num = dev_num;

-
for (j = 0; j < tm->num_of_bus_per_interface; j++) {
VALIDATE_ACTIVE(tm->bus_act_mask, j);
for (i = 0; i < MAX_INTERFACE_NUM; i++) {
@@ -1229,8 +1224,6 @@ int ddr3_tip_sweep_test(u32 dev_num, u32 test_type,
u32 reg_addr = 0;
struct hws_topology_map *tm = ddr3_get_topology_map();
  
-	mem_addr = mem_addr;

-
if (test_type == 0) {
reg_addr = 1;
ui_mask_bit = 0x3f;
@@ -1301,8 +1294,6 @@ int ddr3_tip_run_sweep_test(int dev_num, u32 repeat_num, 
u32 direction,
u32 max_cs = hws_ddr3_tip_max_cs_get();
struct hws_topology_map *tm = ddr3_get_topology_map();
  
-	repeat_num = repeat_num;

-
if (mode == 1) {
/* per pup */
start_pup = 0;



Reviewed-by: Stefan Roese 

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

Re: [U-Boot] [PATCH v0 21/20] efi_loader: hack for archs that cannot do unaligned accesses

[Mark Kettenis]

> From: Rob Clark 
> Date: Mon, 7 Aug 2017 18:18:50 -0400
> 
> On Mon, Aug 7, 2017 at 5:14 PM, Mark Kettenis  wrote:
> >> From: Alexander Graf 
> >> Date: Mon, 7 Aug 2017 21:19:37 +0100
> >>
> >> On 05.08.17 21:31, Rob Clark wrote:
> >> > On Sat, Aug 5, 2017 at 4:05 PM, Heinrich Schuchardt  
> >> > wrote:
> >> >> On 08/05/2017 08:43 PM, Rob Clark wrote:
> >> >>> On Sat, Aug 5, 2017 at 1:06 PM, Rob Clark  wrote:
> >>  On Sat, Aug 5, 2017 at 12:52 PM, Heinrich Schuchardt 
> >>   wrote:
> >> > On 08/05/2017 06:16 PM, Rob Clark wrote:
> >> >> On Sat, Aug 5, 2017 at 12:12 PM, Heinrich Schuchardt 
> >> >>  wrote:
> >> >>> On 08/05/2017 05:58 PM, Rob Clark wrote:
> >>  Some arch's have trouble with unaligned accesses.  Technically
> >>  EFI device-path structs should be byte aligned, and the next node
> >>  in the path starts immediately after the previous.  Meaning that
> >>  a pointer to an 'struct efi_device_path' is not necessarily word
> >>  aligned.  See section 10.3.1 in v2.7 of UEFI spec.
> >> 
> >>  This causes problems not just for u-boot, but also most/all EFI
> >>  payloads loaded by u-boot on these archs.  Fortunately the common
> >>  practice for traversing a device path is to rely on the length
> >>  field in the header, rather than the specified length of the
> >>  particular device path type+subtype.  So the EFI_DP_PAD() macro
> >>  will add the specified number of bytes to the tail of device path
> >>  structs to pad them to word alignment.
> >> 
> >>  Technically this is non-compliant, BROKEN_UNALIGNED should *only*
> >>  be defined on archs that cannot do unaligned accesses.
> >> 
> >>  Signed-off-by: Rob Clark 
> >>  ---
> >>  I'm not sure if there are other arch's that need 
> >>  -DBROKEN_UNALIGNED
> >> 
> >>  Mark, this is untested but I think it should solve your crash on 
> >>  the
> >>  Banana Pi.  Could you give it a try when you get a chance?
> >> 
> >>    arch/arm/config.mk   |  2 +-
> >>    include/efi_api.h| 30 
> >>  ++
> >>    lib/efi_loader/efi_device_path.c |  3 +++
> >>    3 files changed, 34 insertions(+), 1 deletion(-)
> >> 
> >>  diff --git a/arch/arm/config.mk b/arch/arm/config.mk
> >>  index 1a9db4..067dc93a9d 100644
> >>  --- a/arch/arm/config.mk
> >>  +++ b/arch/arm/config.mk
> >>  @@ -28,7 +28,7 @@ LLVMS_RELFLAGS  := $(call 
> >>  cc-option,-mllvm,) \
> >> $(call cc-option,-arm-use-movt=0,)
> >>    PLATFORM_RELFLAGS+= $(LLVM_RELFLAGS)
> >> 
> >>  -PLATFORM_CPPFLAGS += -D__ARM__
> >>  +PLATFORM_CPPFLAGS += -D__ARM__ -DBROKEN_UNALIGNED
> >> >>>
> >> >>> NAK
> >> >>>
> >> >>> We have more then ARM. And other architectures also create 
> >> >>> exceptions
> >> >>> for unaligned access.
> >> >>>
> >> >>> I hate platform specific code. It should not be used outside /arch.
> >> >>>
> >> >>> To play it save you should not use _packed at all!
> >> >>> Use memcpy to transfer between aligned and unaligned memory.
> >> >>
> >> >> except for reasons I explained in the thread on the patch that added
> >> >> the __packed in the first place.  Sorry, this is ugly but we have to
> >> >> do it.
> >> >>
> >> >> BR,
> >> >> -R
> >> >
> >> > According to the UEFI standard the nodes in paths are not to be 
> >> > assumed
> >> > to be aligned.
> >> >
> >> > So even if you use padding bytes in paths that you pass to the EFI
> >> > application you should not expect that the EFI application does the
> >> > same. Expect the EFI application either to remove them or send new 
> >> > nodes
> >> > without padding.
> >> >
> >> > To the idea of padding bytes and __packed does not make sense.
> >> 
> >>  Ok, to be fair, you are right about device-paths passed too u-boot.
> >>  On BROKEN_UNALIGNED archs, we should sanitise with a copy to an
> >>  aligned device-path in *addition* to what I proposed.  I can make a
> >>  patch to add a helper to do this a bit later.
> >> >>>
> >> >>> so thinking about this a bit, I have two options in mind:
> >> >>>
> >> >>>   + efi_dp_sanitize() + efi_dp_free() helpers that are no-ops on
> >> >>> archs that can do unaligned access, but efi_dp_sanitize() always
> >> >>> allocates and copies on BROKEN_UNALIGNED archs and efi_dp_free()
> >> >>> always free's on BROKEN_UNALIGNED archs, even if the dp passed

[U-Boot] [PATCH v2 1/2] dm: core: add clocks node scan

[patrice.chotard]

From: Patrice Chotard 

Currently, all fixed-clock declared in "clocks" node in device tree
can be binded by clk_fixed_rate.c driver only if each of them have
the "simple-bus" compatible string.
This constraint has been invoked here [1].

This patch offers a solution to avoid adding "simple-bus" compatible
string to nodes that are not busses.

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

Signed-off-by: Patrice Chotard 
---

v2: _ implement this feature in dm_extended_scan_dt() which can be called 
  from test/dm/test-main.c to insure that test scan DT clocks
  sub-nodes
_ replace fdt_path_offset() by ofnode_path()

 drivers/core/root.c | 34 --
 include/dm/root.h   | 14 ++
 2 files changed, 46 insertions(+), 2 deletions(-)

diff --git a/drivers/core/root.c b/drivers/core/root.c
index d691d6f..748ef9c 100644
--- a/drivers/core/root.c
+++ b/drivers/core/root.c
@@ -312,8 +312,38 @@ int dm_scan_fdt(const void *blob, bool pre_reloc_only)
 #endif
return dm_scan_fdt_node(gd->dm_root, blob, 0, pre_reloc_only);
 }
+#else
+static int dm_scan_fdt_node(struct udevice *parent, const void *blob,
+   int offset, bool pre_reloc_only)
+{
+   return 0;
+}
 #endif
 
+int dm_extended_scan_dt(const void *blob, bool pre_reloc_only)
+{
+   int node, ret;
+
+   ret = dm_scan_fdt(gd->fdt_blob, pre_reloc_only);
+   if (ret) {
+   debug("dm_scan_fdt() failed: %d\n", ret);
+   return ret;
+   }
+
+   /* bind fixed-clock */
+   node = ofnode_to_offset(ofnode_path("/clocks"));
+   /* if no DT "clocks" node, no need to go further */
+   if (node < 0)
+   return ret;
+
+   ret = dm_scan_fdt_node(gd->dm_root, gd->fdt_blob, node,
+  pre_reloc_only);
+   if (ret)
+   debug("dm_scan_fdt_node() failed: %d\n", ret);
+
+   return ret;
+}
+
 __weak int dm_scan_other(bool pre_reloc_only)
 {
return 0;
@@ -335,9 +365,9 @@ int dm_init_and_scan(bool pre_reloc_only)
}
 
if (CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)) {
-   ret = dm_scan_fdt(gd->fdt_blob, pre_reloc_only);
+   ret = dm_extended_scan_dt(gd->fdt_blob, pre_reloc_only);
if (ret) {
-   debug("dm_scan_fdt() failed: %d\n", ret);
+   debug("dm_extended_scan_dt() failed: %d\n", ret);
return ret;
}
}
diff --git a/include/dm/root.h b/include/dm/root.h
index 50a6011..3426830 100644
--- a/include/dm/root.h
+++ b/include/dm/root.h
@@ -56,6 +56,20 @@ int dm_scan_platdata(bool pre_reloc_only);
 int dm_scan_fdt(const void *blob, bool pre_reloc_only);
 
 /**
+ * dm_extended_scan_dt() - Scan the device tree and bind drivers
+ *
+ * This scans the device tree and creates a driver for each node.
+ * the top-level subnodes are examined and also all sub-nodes of "clocks"
+ * node
+ *
+ * @blob: Pointer to device tree blob
+ * @pre_reloc_only: If true, bind only drivers with the DM_FLAG_PRE_RELOC
+ * flag. If false bind all drivers.
+ * @return 0 if OK, -ve on error
+ */
+int dm_extended_scan_dt(const void *blob, bool pre_reloc_only);
+
+/**
  * dm_scan_other() - Scan for other devices
  *
  * Some devices may not be visible to Driver Model. This weak function can
-- 
1.9.1

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

[U-Boot] [PATCH v2 0/2] dm: core: add clocks node scan

[patrice.chotard]

From: Patrice Chotard 

v2: _ implement this feature in dm_extended_scan_dt() which can be called 
  from test/dm/test-main.c to insure that test scan DT clocks
  sub-nodes
_ replace fdt_path_offset() by ofnode_path()
_ update sandbox dedicated test

Patrice Chotard (2):
  dm: core: add clocks node scan
  dm: test: replace dm_scan_dt() by of dm_extended_scan_fdt() in
dm_do_test

 arch/sandbox/dts/test.dts | 10 ++
 drivers/core/root.c   | 34 --
 include/dm/root.h | 14 ++
 test/dm/test-main.c   |  2 +-
 4 files changed, 53 insertions(+), 7 deletions(-)

-- 
1.9.1

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

[U-Boot] [PATCH v2 5/6] power: as3722: add as3722_ldo_set_voltage signature to header file

[Marcel Ziswiler]

From: Marcel Ziswiler 

Just like the already present as3722_sd_set_voltage() add the currently
missing signature of the as3722_ldo_set_voltage() function to its header
file.

Signed-off-by: Marcel Ziswiler 
Reviewed-by: Simon Glass 
---

Changes in v2:
- Add Simon's reviewed-by.

 include/power/as3722.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/power/as3722.h b/include/power/as3722.h
index b3dc7b6..128df49 100644
--- a/include/power/as3722.h
+++ b/include/power/as3722.h
@@ -26,5 +26,6 @@
 #define AS3722_GPIO_CONTROL_INVERT (1 << 7)
 
 int as3722_sd_set_voltage(struct udevice *dev, unsigned int sd, u8 value);
+int as3722_ldo_set_voltage(struct udevice *dev, unsigned int ldo, u8 value);
 
 #endif /* __POWER_AS3722_H__ */
-- 
2.9.4

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

[U-Boot] [PATCH v2 6/6] apalis-tk1: fix pcie reset for reliable gigabit ethernet operation

[Marcel Ziswiler]

From: Marcel Ziswiler 

It turns out that the current PCIe reset implementation in the PCIe
board init function is not quite working reliably due to PCIe reset
timing violations. Fix this by overriding the
tegra_pcie_board_port_reset() function.

Also allow optionally bringing up the PCIe switch as found on the Apalis
Evaluation board. Note however that the Apalis PCIe port is also left
disabled in the device tree by default.

Signed-off-by: Marcel Ziswiler 
---

Changes in v2: None

 board/toradex/apalis-tk1/apalis-tk1.c | 247 +-
 include/configs/apalis-tk1.h  |   1 +
 2 files changed, 155 insertions(+), 93 deletions(-)

diff --git a/board/toradex/apalis-tk1/apalis-tk1.c 
b/board/toradex/apalis-tk1/apalis-tk1.c
index 5de61e7..ad3f5ec 100644
--- a/board/toradex/apalis-tk1/apalis-tk1.c
+++ b/board/toradex/apalis-tk1/apalis-tk1.c
@@ -5,17 +5,26 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 
 #include "../common/tdx-common.h"
 #include "pinmux-config-apalis-tk1.h"
 
-#define LAN_RESET_N TEGRA_GPIO(S, 2)
+#define LAN_DEV_OFF_N  TEGRA_GPIO(O, 6)
+#define LAN_RESET_NTEGRA_GPIO(S, 2)
+#define LAN_WAKE_N TEGRA_GPIO(O, 5)
+#ifdef APALIS_TK1_PCIE_EVALBOARD_INIT
+#define PEX_PERST_NTEGRA_GPIO(DD, 1) /* Apalis GPIO7 */
+#define RESET_MOCI_CTRLTEGRA_GPIO(U, 4)
+#endif /* APALIS_TK1_PCIE_EVALBOARD_INIT */
 
 int arch_misc_init(void)
 {
@@ -59,123 +68,175 @@ void pinmux_init(void)
 }
 
 #ifdef CONFIG_PCI_TEGRA
-int tegra_pcie_board_init(void)
+/* TODO: Convert to driver model */
+static int as3722_sd_enable(struct udevice *pmic, unsigned int sd)
 {
-   /* TODO: Convert to driver model
-   struct udevice *pmic;
int err;
 
-   err = as3722_init();
+   if (sd > 6)
+   return -EINVAL;
+
+   err = pmic_clrsetbits(pmic, AS3722_SD_CONTROL, 0, 1 << sd);
if (err) {
-   error("failed to initialize AS3722 PMIC: %d\n", err);
+   error("failed to update SD control register: %d", err);
return err;
}
 
-   err = as3722_sd_enable(pmic, 4);
-   if (err < 0) {
-   error("failed to enable SD4: %d\n", err);
-   return err;
-   }
+   return 0;
+}
 
-   err = as3722_sd_set_voltage(pmic, 4, 0x24);
-   if (err < 0) {
-   error("failed to set SD4 voltage: %d\n", err);
-   return err;
-   }
+/* TODO: Convert to driver model */
+static int as3722_ldo_enable(struct udevice *pmic, unsigned int ldo)
+{
+   int err;
+   u8 ctrl_reg = AS3722_LDO_CONTROL0;
 
-   err = as3722_gpio_configure(pmic, 1, AS3722_GPIO_OUTPUT_VDDH |
-AS3722_GPIO_INVERT);
-   if (err < 0) {
-   error("failed to configure GPIO#1 as output: %d\n", err);
-   return err;
-   }
+   if (ldo > 11)
+   return -EINVAL;
 
-   err = as3722_gpio_direction_output(pmic, 2, 1);
-   if (err < 0) {
-   error("failed to set GPIO#2 high: %d\n", err);
-   return err;
+   if (ldo > 7) {
+   ctrl_reg = AS3722_LDO_CONTROL1;
+   ldo -= 8;
}
-   */
 
-   /* Reset I210 Gigabit Ethernet Controller */
-   gpio_request(LAN_RESET_N, "LAN_RESET_N");
-   gpio_direction_output(LAN_RESET_N, 0);
-
-   /*
-* Make sure we don't get any back feeding from LAN_WAKE_N resp.
-* DEV_OFF_N
-*/
-   gpio_request(TEGRA_GPIO(O, 5), "LAN_WAKE_N");
-   gpio_direction_output(TEGRA_GPIO(O, 5), 0);
-
-   gpio_request(TEGRA_GPIO(O, 6), "LAN_DEV_OFF_N");
-   gpio_direction_output(TEGRA_GPIO(O, 6), 0);
-
-   /* Make sure LDO9 and LDO10 are initially enabled @ 0V */
-   /* TODO: Convert to driver model
-   err = as3722_ldo_enable(pmic, 9);
-   if (err < 0) {
-   error("failed to enable LDO9: %d\n", err);
-   return err;
-   }
-   err = as3722_ldo_enable(pmic, 10);
-   if (err < 0) {
-   error("failed to enable LDO10: %d\n", err);
-   return err;
-   }
-   err = as3722_ldo_set_voltage(pmic, 9, 0x80);
-   if (err < 0) {
-   error("failed to set LDO9 voltage: %d\n", err);
-   return err;
-   }
-   err = as3722_ldo_set_voltage(pmic, 10, 0x80);
-   if (err < 0) {
-   error("failed to set LDO10 voltage: %d\n", err);
+   err = pmic_clrsetbits(pmic, ctrl_reg, 0, 1 << ldo);
+   if (err) {
+   error("failed to update LDO control register: %d", err);
return err;
}
-   */
 
-   mdelay(100);
+   return 0;
+}
 
-   /* Make sure controller gets enabled by disabling DEV_OFF_N */
-   gpio_set_value(TEGRA_GPIO(O, 6), 1);
+int tegra_pcie_board_init(void)
+{
+   struct 

[U-Boot] [PATCH v2 2/6] apalis-tk1: add missing as3722 gpio0 configuration

[Marcel Ziswiler]

From: Marcel Ziswiler 

As the AS3722 GPIO0 is also a not connected on our Apalis TK1 module
explicitly configure it to high-impedance as well.

Signed-off-by: Marcel Ziswiler 
Reviewed-by: Simon Glass 
---

Changes in v2:
- Add Simon's reviewed-by.

 arch/arm/dts/tegra124-apalis.dts | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/dts/tegra124-apalis.dts b/arch/arm/dts/tegra124-apalis.dts
index 2fc0384..fe08d3e 100644
--- a/arch/arm/dts/tegra124-apalis.dts
+++ b/arch/arm/dts/tegra124-apalis.dts
@@ -1683,9 +1683,9 @@
bias-pull-up;
};
 
-   gpio1_3_4_5_6 {
-   pins = "gpio1", "gpio3", "gpio4",
-  "gpio5", "gpio6";
+   gpio0_1_3_4_5_6 {
+   pins = "gpio0", "gpio1", "gpio3",
+  "gpio4", "gpio5", "gpio6";
bias-high-impedance;
};
};
-- 
2.9.4

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

[U-Boot] [PATCH v2 4/6] pci: tegra: introduce weak tegra_pcie_board_port_reset() function

[Marcel Ziswiler]

From: Marcel Ziswiler 

Introduce a weak tegra_pcie_board_port_reset() function by default
calling the existing tegra_pcie_port_reset() function. Additionally add
a tegra_pcie_port_index_of_port() function to retrieve the specific PCIe
port index if required. This allows overriding the PCIe port reset
functionality from board specific code as e.g. required for Apalis T30
and Apalis TK1.

Signed-off-by: Marcel Ziswiler 
---

Changes in v2:
- Incorporate Stephen's review feedback by introducing a
  tegra_pcie_port_index_of_port() function as well as a board-specific
  reset override function.

 drivers/pci/pci_tegra.c | 28 
 include/pci_tegra.h |  9 +
 2 files changed, 29 insertions(+), 8 deletions(-)
 create mode 100644 include/pci_tegra.h

diff --git a/drivers/pci/pci_tegra.c b/drivers/pci/pci_tegra.c
index cb5cf8b..cb0a30c 100644
--- a/drivers/pci/pci_tegra.c
+++ b/drivers/pci/pci_tegra.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -893,21 +894,32 @@ static unsigned long tegra_pcie_port_get_pex_ctrl(struct 
tegra_pcie_port *port)
return ret;
 }
 
-static void tegra_pcie_port_reset(struct tegra_pcie_port *port)
+void tegra_pcie_port_reset(void *port)
 {
-   unsigned long ctrl = tegra_pcie_port_get_pex_ctrl(port);
+   unsigned long ctrl = tegra_pcie_port_get_pex_ctrl(
+   (struct tegra_pcie_port *)port);
unsigned long value;
 
/* pulse reset signel */
-   value = afi_readl(port->pcie, ctrl);
+   value = afi_readl(((struct tegra_pcie_port *)port)->pcie, ctrl);
value &= ~AFI_PEX_CTRL_RST;
-   afi_writel(port->pcie, value, ctrl);
+   afi_writel(((struct tegra_pcie_port *)port)->pcie, value, ctrl);
 
udelay(2000);
 
-   value = afi_readl(port->pcie, ctrl);
+   value = afi_readl(((struct tegra_pcie_port *)port)->pcie, ctrl);
value |= AFI_PEX_CTRL_RST;
-   afi_writel(port->pcie, value, ctrl);
+   afi_writel(((struct tegra_pcie_port *)port)->pcie, value, ctrl);
+}
+
+int tegra_pcie_port_index_of_port(void *port)
+{
+   return ((struct tegra_pcie_port *)port)->index;
+}
+
+void __weak tegra_pcie_board_port_reset(void *port)
+{
+   tegra_pcie_port_reset(port);
 }
 
 static void tegra_pcie_port_enable(struct tegra_pcie_port *port)
@@ -928,7 +940,7 @@ static void tegra_pcie_port_enable(struct tegra_pcie_port 
*port)
 
afi_writel(pcie, value, ctrl);
 
-   tegra_pcie_port_reset(port);
+   tegra_pcie_board_port_reset(port);
 
if (soc->force_pca_enable) {
value = rp_readl(port, RP_VEND_CTL2);
@@ -979,7 +991,7 @@ static bool tegra_pcie_port_check_link(struct 
tegra_pcie_port *port)
} while (--timeout);
 
 retry:
-   tegra_pcie_port_reset(port);
+   tegra_pcie_board_port_reset(port);
} while (--retries);
 
return false;
diff --git a/include/pci_tegra.h b/include/pci_tegra.h
new file mode 100644
index 000..13ee908
--- /dev/null
+++ b/include/pci_tegra.h
@@ -0,0 +1,9 @@
+/*
+ * Copyright (c) 2017 Toradex, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+int tegra_pcie_port_index_of_port(void *port);
+
+void tegra_pcie_port_reset(void *port);
-- 
2.9.4

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

[U-Boot] [PATCH 1/3] apalis_t30: describe pcie ports

[Marcel Ziswiler]

From: Marcel Ziswiler 

Add some more comments describing the various PCIe ports available.

Signed-off-by: Marcel Ziswiler 
---

 arch/arm/dts/tegra30-apalis.dts | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/dts/tegra30-apalis.dts b/arch/arm/dts/tegra30-apalis.dts
index 0b84dae..0852d8d 100644
--- a/arch/arm/dts/tegra30-apalis.dts
+++ b/arch/arm/dts/tegra30-apalis.dts
@@ -43,16 +43,19 @@
vddio-pex-ctl-supply = <_3v3_reg>;
hvdd-pex-supply = <_3v3_reg>;
 
+   /* Apalis Type Specific 4 Lane PCIe */
pci@1,0 {
/* TS_DIFF1/2/3/4 left disabled */
nvidia,num-lanes = <4>;
};
 
+   /* Apalis PCIe */
pci@2,0 {
/* PCIE1_RX/TX left disabled */
nvidia,num-lanes = <1>;
};
 
+   /* I210 Gigabit Ethernet Controller (On-module) */
pci@3,0 {
status = "okay";
nvidia,num-lanes = <1>;
-- 
2.9.4

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

[U-Boot] [PATCH 0/3] fix apalis_t30 optional pcie operation

[Marcel Ziswiler]

This series addresses a PCIe reliability issue as observed on Apalis T30
related to a PCIe reset timing violation.

This series depends on Simon's work available at u-boot-dm/master plus
my previous series "move apalis t30/tk1, colibri t20/t30 to livetree"
and "fix apalis-tk1 pcie gigabit ethernet operation".

This series is available at 
http://git.toradex.com/cgit/u-boot-toradex.git/log/?h=for-next


Marcel Ziswiler (3):
  apalis_t30: describe pcie ports
  apalis_t30: fix pcie port 0 and 1 pin muxing
  apalis_t30: fix optional pcie port reset for reliable pcie operation

 arch/arm/dts/tegra30-apalis.dts|  3 ++
 board/toradex/apalis_t30/apalis_t30.c  | 47 ++
 .../toradex/apalis_t30/pinmux-config-apalis_t30.h  | 12 +++---
 include/configs/apalis_t30.h   |  1 +
 4 files changed, 57 insertions(+), 6 deletions(-)

-- 
2.9.4

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

Re: [U-Boot] [PATCH 3/3] dm: core: Add livetree documentation

[Łukasz Majewski]

On 08/05/2017 11:45 PM, Simon Glass wrote:

Add some documentation for the live device tree support in U-Boot. This
was missing from the initial series.

Signed-off-by: Simon Glass 
Suggested-by: Lukasz Majewski 
---

 doc/driver-model/livetree.txt | 272 ++
 1 file changed, 272 insertions(+)
 create mode 100644 doc/driver-model/livetree.txt

diff --git a/doc/driver-model/livetree.txt b/doc/driver-model/livetree.txt
new file mode 100644
index 00..630f70bb85
--- /dev/null
+++ b/doc/driver-model/livetree.txt
@@ -0,0 +1,272 @@
+Driver Model with Live Device Tree
+==
+
+
+Introduction
+
+
+Traditionally U-Boot has used a 'flat' device tree. This means that it
+reads directly from the device tree binary structure. It is called a flat
+device tree because nodes are listed one after the other, with the
+hierarchy detected by tags in the format.
+
+This document describes U-Boot's support for a 'live' device tree, meaning
+that the tree is loaded into a hierarchical data structure within U-Boot.
+
+
+Motivation
+--
+
+The flat device tree has several advantages:
+
+- it is the format produced by the device tree compiler, so no translation
+is needed
+
+- it is fairly compact (e.g. there is no need for pointers)
+
+- it ia accessed by the libfdt library, which is well tested and stable

^^^ is


+
+
+However the flat device tree does have some limitations. Adding new
+properties can involve copying large amounts of data around to make room.
+The overall tree has a fixed maximum size so sometimes the tree must be
+rebuilt in a new location to create more space. Even if not adding new
+properties or nodes, scanning the tree can be slow. For example, finding
+the parent of a node is a slow process. Reading from nodes involves a
+small amount parsing which takes a little time.
+
+Driver model scans the entire device tree sequentially on start-up which
+avoids the worst of the flat tree's limitations. But if the tree is to be
+modified at run-time, a live tree is much faster. Even if no modification
+is necessary, parsing the tree once and using a live tree from then on
+seems to save a little time.
+
+
+Implementation
+--
+
+In U-Boot a live device tree ('livetree') is currently supported only
+after relocation. Therefore we need a mechanism to specify a device
+tree node regardless of whether it is in the flat tree or livetree.
+
+The 'ofnode' type provides this. An ofnode can point to either a flat tree
+node (when the live tree node is not yet set up) or a livetree node. The
+caller of an ofnode function does not need to worry about these details.
+
+The main users of the information in a device tree are  drivers. These have
+a 'struct udevice *' which is attached to a device tree node. Therefore it
+makes sense to be able to read device tree  properties using the
+'struct udevice *', rather than having to obtain the ofnode first.
+
+The 'dev_read_...()' interface provides this. It allows properties to be
+easily read from the device tree using only a device pointer. Under the
+hood it uses ofnode so it works with both flat and live device trees.
+
+
+Enabling livetree
+-
+
+CONFIG_OF_LIVE enables livetree. When this option is enabled, the flat
+tree will be used in SPL and before relocation in U-Boot proper. Just
+before relocation a livetree is built, and this is used for U-Boot proper
+after relocation.
+
+Most checks for livetree use CONFIG_IS_ENABLED(OF_LIVE). This means that
+for SPL, the CONFIG_SPL_OF_LIVE option is checked. At present this does
+not exist, since SPL coes not support livetree.

 does?


+
+
+Porting drivers
+---
+
+Many existing drivers use the fdtdec interface to read device tree
+properties. This only works with a flat device tree. The drivers should be
+converted to use the dev_read_() interface.
+
+For example, the old code may be like this:
+
+struct udevice *bus;
+const void *blob = gd->fdt_blob;
+int node = dev_of_offset(bus);
+
+i2c_bus->regs = (struct i2c_ctlr *)devfdt_get_addr(dev);
+plat->frequency = fdtdec_get_int(blob, node, "spi-max-frequency", 50);
+
+The new code is:
+
+struct udevice *bus;
+
+i2c_bus->regs = (struct i2c_ctlr *)dev_read_addr(dev);
+plat->frequency = dev_read_u32_default(bus, "spi-max-frequency", 50);
+
+The dev_read_...() interface is more convenient and works with both the
+flat and live device trees. See include/dm/read.h for a list of functions.
+
+Where properties must be read from sub-nodes or other nodes, you must fall
+back to using ofnode. For example, for old code like this:
+
+const void *blob = gd->fdt_blob;
+int subnode;
+
+fdt_for_each_subnode(subnode, blob, dev_of_offset(dev)) {
+freq = fdtdec_get_int(blob, node, "spi-max-frequency", 50);
+...
+}
+
+you should use:

Re: [U-Boot] [PATCH v1 0/7] imx: add USB Serial Download Protocol (SDP) support

[Marcel Ziswiler]

Hi Stefano

On Tue, 2017-08-08 at 11:15 +0200, Stefano Babic wrote:
> Hi Stefan,
> 
> On 07/08/2017 20:06, Stefan Agner wrote:
> > Hi Eric,
> > 
> > On 2017-08-06 08:19, Eric Nelson wrote:
> > > Hi Stefan,
> > > 
> > > On 08/04/2017 04:38 PM, Stefan Agner wrote:
> > > > From: Stefan Agner 
> > > > 
> > > > This series adds NXP's Serial Download Protocol (SDP) support
> > > > via
> > > > USB for SPL/U-Boot. It allows to download U-Boot via USB from a
> > > > (recovered) SPL using the same tools used to download SPL
> > > > itself
> > > > (specifically imx_usb, but also sb_loader seems to work).
> > > > 
> > > 
> > > Nice!
> > > 
> > > > The idea has been brought up when the first targets started to
> > > > make
> > > > use of SPL for DDR initialization, see:
> > > > https://lists.denx.de/pipermail/u-boot/2015-July/220330.html
> > > > 
> > > 
> > > There have been lots of discussions surrounding the use of SDP,
> > > and this seems to be a nice alternative to using the i.MX
> > > "plugin"
> > > mode that I explored a while back:
> > > 
> > > https://lists.denx.de/pipermail/u-boot/2017-July/thread.html#2982
> > > 66
> > > 
> > 
> > Hm, wasn't aware of that particular effort, thanks for pointing to
> > it.
> > From a quick glance, it did not work out so far, is this correct?
> > 
> > I looked into plugin mode also a little bit, but I did not continue
> > to
> > look into it after reading this sentence in the i.MX 6 RM:
> > 
> > 8.7 Plugin Image
> > The boot ROM detects the image type using the plugin flag of the
> > boot
> > data structure (see
> > Boot Data Structure). If the plugin flag is 1, then the ROM uses
> > the
> > image as a plugin
> > function. The function must initialize the boot device and copy the
> > program image to the
> > final location. At the end the plugin function must return with the
> > program image
> > parameters. (See High level boot sequence for details about boot
> > flow).
> > 
> > 
> > So if SPL should work as a plugin as NXP defines it, SPL is
> > supposed to
> > load the image from somewhere. The boot ROM then only takes care
> > about
> > image verification and further boot steps, but it's the plugins job
> > to
> > get the image from somewhere and store it in RAM.
> > 
> 
> Right, and this is also the weak point. There are also some cases (at
> least, in some projects of mine) where this conflicts with the setup
> of
> the RAM controller. We need to set the RAM controller to load the
> code
> or to fight with the limitation of the IRAM.
> 
> > Afact this is not really helpful in our case. We would want the
> > boot ROM
> > to go through the boot sequence (again).
> 
> Agree. This makes the whole boot process easier to understand - and
> not
> to mention the fact that code of BootROM is not officially published,
> and we cannot know what it exactly does.
> 
> > 
> > Unless returning an error/invalid image causes the boot ROM to go
> > through boot sequence again?
> > 
> > 
> > The nice thing with our own SDP implementation is we can reuse it
> > even
> > from within U-Boot again, e.g. to download a kernel/initramfs
> 
> Right - I think SDP is a nice solution, and thanks for your effort !
> 
> > 
> > > > The initial SDP implementation (patch 2) requires the payload
> > > > to
> > > > have the imx specific headers (hence the move of the imx header
> > > > file in patch 1).
> > > > 
> > > > Patch 3 extends image header support beyond the SDP
> > > > specification,
> > > > specifically implements also support for U-Boot headers. This
> > > > allows to use the same SPL/U-Boot binaries for recovery as used
> > > > on
> > > > the regular boot device (SD/eMMC). For that to work also the
> > > > host
> > > > side imx_usb tools needed an extension, currently available
> > > > here:
> > > > 
> > > > https://github.com/toradex/imx_loader/tree/imx_usb_batch_mode_r
> > > > efactored
> > > > 
> > > > The full patchset allows to download SPL and U-Boot over USB to
> > > > a
> > > > target in recovery mode using the same usb_imx utility:
> > > 
> > > imx_usb?
> > > 
> > 
> > Yeah right, sorry.
> 
> But what about to merge into the official imx_usb repo ?

Yes, of course as Stefan mentioned before that is planned once this
made it into U-Boot proper.

> > > > The usb_imx utility also has a batch mode which allows to
> > > > download
> > > > multiple artifacts with a single invocation. The details are
> > > > outlined in the imx_usb commit message:
> > > > https://github.com/toradex/imx_loader/commit/5434415d921f1cc4d2
> > > > 2332d9558bed6d42db9f60
> > > > 
> > > > In case this patchset gets accepted in U-Boot, I plan to push
> > > > the
> > > > imx_usb changes upstream as well.
> > > > 
> > > 
> > > Do you have numbers for how much code/data size this adds to SPL?
> > > 
> > 
> > Besides the protocol implementation also general USB (gadget)
> > support is
> > required, hence it adds quite a bit.
> > 
> > 
> > Without USB Gadget/SDP support (Apalis iMX6 SPL):
> > 

Re: [U-Boot] [PATCH 00/10] This patch set represent Marvell mvpp2 driver fixes

[Stefan Roese]

Hi Joe,

On 11.07.2017 10:04, Stefan Roese wrote:

On 21.06.2017 10:31, stef...@malvell.com wrote:

From: Stefan Chulski 

Issues were found during internal QA phase.

Stefan Chulski (10):
   net: mvpp2x: Add GPIO configuration support
   net: mvpp2x: fix phy connected to wrong mdio issue
   net: mvpp2x: Enable GoP packet padding in TX
   net: mvpp2x: fix BM configuration overrun issue
   net: mvpp2x: decrease size of AGGR_TXQ and CPU_DESC_CHUNK
   net: mvpp2x: remove MBUS configurations from MvPP22 driver
   net: mvpp2x: Remove IRQ configuration from u-boot
   net: mvpp2x: Set BM pool high address
   net: mvpp2x: remove TX drain from transmit routine
   net: mvpp2x: Set BM poll size once during priv probe

  drivers/net/mvpp2.c | 189 
++--

  1 file changed, 94 insertions(+), 95 deletions(-)


Joe, do you have any comments on these mvpp2 patches?


Gently ping on these patches again. Joe, do you have any comments
on these? Do you want to take these patches via your tree? Or
should I push them if you don't have any objections?

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

Re: [U-Boot] [PATCH 1/1] arm: mvebu: avoid possible NULL dereference

[Stefan Roese]

On 30.07.2017 20:40, Heinrich Schuchardt wrote:

It does not make sense to check if info is NULL after
dereferencing it.

The problem was indicated by cppcheck.

Signed-off-by: Heinrich Schuchardt 
---
  arch/arm/mach-mvebu/serdes/axp/high_speed_env_lib.c | 10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-mvebu/serdes/axp/high_speed_env_lib.c 
b/arch/arm/mach-mvebu/serdes/axp/high_speed_env_lib.c
index b0e193b78c..525576a4fc 100644
--- a/arch/arm/mach-mvebu/serdes/axp/high_speed_env_lib.c
+++ b/arch/arm/mach-mvebu/serdes/axp/high_speed_env_lib.c
@@ -354,16 +354,16 @@ int serdes_phy_config(void)
}
  
  	info = board_serdes_cfg_get(PEX_MODE_GET(satr11));

-   DEBUG_INIT_FULL_S("info->line0_7= 0x");
-   DEBUG_INIT_FULL_D(info->line0_7, 8);
-   DEBUG_INIT_FULL_S("   info->line8_15= 0x");
-   DEBUG_INIT_FULL_D(info->line8_15, 8);
-   DEBUG_INIT_FULL_S("\n");
  
  	if (info == NULL) {

DEBUG_INIT_S("Hight speed PHY Error #1\n");
return MV_ERROR;
}
+   DEBUG_INIT_FULL_S("info->line0_7= 0x");
+   DEBUG_INIT_FULL_D(info->line0_7, 8);
+   DEBUG_INIT_FULL_S("   info->line8_15= 0x");
+   DEBUG_INIT_FULL_D(info->line8_15, 8);
+   DEBUG_INIT_FULL_S("\n");
  
  	if (config_module & ETM_MODULE_DETECT) {	/* step 0.9 ETM */

DEBUG_INIT_FULL_S("ETM module detect Step 0.9:\n");



Reviewed-by: Stefan Roese 

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

Re: [U-Boot] [PATCH] mvebu: turris_omnia: Fix PEX vs SATA detection for board topology

[Stefan Roese]

On 04.08.2017 15:28, Marek Behún wrote:

The I2C reading in the PEX vs SATA detection code often fails on the
first try. Try three times, as the code for EEPROM reading does.

Signed-off-by: Marek Behun 
---
  board/CZ.NIC/turris_omnia/turris_omnia.c | 11 ---
  1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c 
b/board/CZ.NIC/turris_omnia/turris_omnia.c
index 86926f8050..a4275091d2 100644
--- a/board/CZ.NIC/turris_omnia/turris_omnia.c
+++ b/board/CZ.NIC/turris_omnia/turris_omnia.c
@@ -90,7 +90,7 @@ static struct serdes_map board_serdes_map_sata[] = {
  static bool omnia_detect_sata(void)
  {
struct udevice *bus, *dev;
-   int ret;
+   int ret, retry = 3;
u16 mode;
  
  	puts("SERDES0 card detect: ");

@@ -106,8 +106,13 @@ static bool omnia_detect_sata(void)
return false;
}
  
-	ret = dm_i2c_read(dev, OMNIA_I2C_MCU_ADDR_STATUS, (uchar *) , 2);

-   if (ret) {
+   for (; retry > 0; --retry) {
+   ret = dm_i2c_read(dev, OMNIA_I2C_MCU_ADDR_STATUS, (uchar *) 
, 2);
+   if (!ret)
+   break;
+   }
+
+   if (!retry) {
puts("I2C read failed! Default PEX\n");
return false;
}



Applied to u-boot-marvell/master.

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

Re: [U-Boot] [PATCH] spi: mxc_spi: support driver model

[Peng Fan]

> -Original Message-
> From: Lothar Waßmann [mailto:l...@karo-electronics.de]
> Sent: Tuesday, August 08, 2017 6:20 PM
> To: Peng Fan 
> Cc: ja...@openedev.com; u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH] spi: mxc_spi: support driver model
> 
> Hi,
> 
> On Tue,  8 Aug 2017 18:00:01 +0800 Peng Fan wrote:
> > Add driver model support for mxc spi driver.
> > Most functions are restructured to be reused by DM and non-DM.
> > Tested on mx6slevk/mx6qsabresd board.
> >
> > Signed-off-by: Peng Fan 
> > Cc: Jagan Teki 
> > cc: Stefano Babic 
> > ---
> >  drivers/spi/mxc_spi.c | 183
> > +-
> >  1 file changed, 150 insertions(+), 33 deletions(-)
> >
> > diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c index
> > e1562c3..44fed94 100644
> > --- a/drivers/spi/mxc_spi.c
> > +++ b/drivers/spi/mxc_spi.c
> > @@ -5,6 +5,7 @@
> >   */
> >
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -14,6 +15,8 @@
> >  #include 
> >  #include 
> >
> > +DECLARE_GLOBAL_DATA_PTR;
> > +
> >  #ifdef CONFIG_MX27
> >  /* i.MX27 has a completely wrong register layout and register definitions 
> > in
> the
> >   * datasheet, the correct one is in the Freescale's Linux driver */
> > @@ -22,10 +25,6 @@  "See linux mxc_spi driver from Freescale for
> > details."
> >  #endif
> >
> > -static unsigned long spi_bases[] = {
> > -   MXC_SPI_BASE_ADDRESSES
> > -};
> > -
> >  __weak int board_spi_cs_gpio(unsigned bus, unsigned cs)  {
> > return -1;
> > @@ -51,6 +50,7 @@ struct mxc_spi_slave {
> > int ss_pol;
> > unsigned intmax_hz;
> > unsigned intmode;
> > +   struct gpio_desc ss;
> >  };
> >
> >  static inline struct mxc_spi_slave *to_mxc_spi_slave(struct spi_slave
> > *slave) @@ -58,19 +58,24 @@ static inline struct mxc_spi_slave
> *to_mxc_spi_slave(struct spi_slave *slave)
> > return container_of(slave, struct mxc_spi_slave, slave);  }
> >
> > -void spi_cs_activate(struct spi_slave *slave)
> > +static void mxc_spi_cs_activate(struct mxc_spi_slave *mxcs)
> >  {
> > -   struct mxc_spi_slave *mxcs = to_mxc_spi_slave(slave);
> > -   if (mxcs->gpio > 0)
> > -   gpio_set_value(mxcs->gpio, mxcs->ss_pol);
> > +   if (CONFIG_IS_ENABLED(DM_SPI)) {
> >
> Shouldn't this be DM_GPIO rather than DM_SPI?

When DM_SPI is enabled, the mxcs->ss will be initialized in the driver probe.
So keep DM_SPI here.

> 
> > +   dm_gpio_set_value(>ss, mxcs->ss_pol);
> > +   } else {
> > +   if (mxcs->gpio > 0)
> > +   gpio_set_value(mxcs->gpio, mxcs->ss_pol);
> > +   }
> >  }
> >
> > -void spi_cs_deactivate(struct spi_slave *slave)
> > +static void mxc_spi_cs_deactivate(struct mxc_spi_slave *mxcs)
> >  {
> > -   struct mxc_spi_slave *mxcs = to_mxc_spi_slave(slave);
> > -   if (mxcs->gpio > 0)
> > -   gpio_set_value(mxcs->gpio,
> > - !(mxcs->ss_pol));
> > +   if (CONFIG_IS_ENABLED(DM_SPI)) {
> dto.

Same as above.

> 
> > +   dm_gpio_set_value(>ss, !(mxcs->ss_pol));
> > +   } else {
> > +   if (mxcs->gpio > 0)
> > +   gpio_set_value(mxcs->gpio, !(mxcs->ss_pol));
> > +   }
> >  }
> >
> >  u32 get_cspi_div(u32 div)
> > @@ -211,10 +216,9 @@ static s32 spi_cfg_mxc(struct mxc_spi_slave
> > *mxcs, unsigned int cs)  }  #endif
> >
> > -int spi_xchg_single(struct spi_slave *slave, unsigned int bitlen,
> > +int spi_xchg_single(struct mxc_spi_slave *mxcs, unsigned int bitlen,
> > const u8 *dout, u8 *din, unsigned long flags)  {
> > -   struct mxc_spi_slave *mxcs = to_mxc_spi_slave(slave);
> > int nbytes = DIV_ROUND_UP(bitlen, 8);
> > u32 data, cnt, i;
> > struct cspi_regs *regs = (struct cspi_regs *)mxcs->base; @@ -327,8
> > +331,9 @@ int spi_xchg_single(struct spi_slave *slave, unsigned int
> > bitlen,
> >
> >  }
> >
> > -int spi_xfer(struct spi_slave *slave, unsigned int bitlen, const void 
> > *dout,
> > -   void *din, unsigned long flags)
> > +static int mxc_spi_xfer_internal(struct mxc_spi_slave *mxcs,
> > +unsigned int bitlen, const void *dout,
> > +void *din, unsigned long flags)
> >  {
> > int n_bytes = DIV_ROUND_UP(bitlen, 8);
> > int n_bits;
> > @@ -337,11 +342,11 @@ int spi_xfer(struct spi_slave *slave, unsigned int
> bitlen, const void *dout,
> > u8 *p_outbuf = (u8 *)dout;
> > u8 *p_inbuf = (u8 *)din;
> >
> > -   if (!slave)
> > -   return -1;
> > +   if (!mxcs)
> > +   return -EINVAL;
> >
> > if (flags & SPI_XFER_BEGIN)
> > -   spi_cs_activate(slave);
> > +   mxc_spi_cs_activate(mxcs);
> >
> > while (n_bytes > 0) {
> > if (n_bytes < MAX_SPI_BYTES)
> > @@ -351,7 +356,7 @@ int spi_xfer(struct spi_slave *slave, unsigned int
> > bitlen, const void *dout,
> >
> > n_bits = blk_size * 8;
> >
> > -   ret = 

[U-Boot] Please pull u-boot-cfi-flash/master

[Stefan Roese]

Hi Tom,

please pull the following small cleanup from Marek in the
flash.h header.

Thanks,
Stefan


The following changes since commit eaa90e5df2a4a1cb12fb73571978a9379242d0b5:

  common/env_embedded.c: rename PPCENV/PPCTEXT macros (2017-08-04 20:38:39 
-0400)

are available in the git repository at:

  git://www.denx.de/git/u-boot-cfi-flash.git 

for you to fetch changes up to bd2d489e248dada86a557c8d2ee4f914a2b0c8eb:

  mtd: cfi: Zap CFI_FLASH_SHIFT_WIDTH redefinition (2017-08-08 14:29:48 +0200)


Marek Vasut (1):
  mtd: cfi: Zap CFI_FLASH_SHIFT_WIDTH redefinition

 include/flash.h | 2 --
 1 file changed, 2 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 1/6] configs: apalis-tk1: fix boot failure using ext4 rootfs

[Marcel Ziswiler]

From: Sanchayan Maity 

Trying to boot from an ext4 rootfs fails due to us defaulting to ext3.
While the downstream T20/T30 L4T kernel has issues with ext4 later TK1
L4T should work just fine with it. Hence enable ext4 for sdboot and
usbboot on TK1.

Signed-off-by: Sanchayan Maity 
Acked-by: Marcel Ziswiler 
---

Changes in v2: None

 include/configs/apalis-tk1.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/configs/apalis-tk1.h b/include/configs/apalis-tk1.h
index d6b226c..bb46768 100644
--- a/include/configs/apalis-tk1.h
+++ b/include/configs/apalis-tk1.h
@@ -87,7 +87,7 @@
"&& setenv dtbparam ${fdt_addr_r}\0"
 
 #define SD_BOOTCMD \
-   "sdargs=ip=off root=/dev/mmcblk1p2 rw rootfstype=ext3 rootwait\0" \
+   "sdargs=ip=off root=/dev/mmcblk1p2 rw rootfstype=ext4 rootwait\0" \
"sdboot=run setup; setenv bootargs ${defargs} ${sdargs} ${setupargs} " \
"${vidargs}; echo Booting from SD card in 8bit slot...; " \
"run sddtbload; load mmc 1:1 ${kernel_addr_r} " \
@@ -98,7 +98,7 @@
"&& setenv dtbparam ${fdt_addr_r}\0"
 
 #define USB_BOOTCMD \
-   "usbargs=ip=off root=/dev/sda2 rw rootfstype=ext3 rootwait\0" \
+   "usbargs=ip=off root=/dev/sda2 rw rootfstype=ext4 rootwait\0" \
"usbboot=run setup; setenv bootargs ${defargs} ${setupargs} " \
"${usbargs} ${vidargs}; echo Booting from USB stick...; " \
"usb start && run usbdtbload; load usb 0:1 ${kernel_addr_r} " \
-- 
2.9.4

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

Re: [U-Boot] [PATCH v0 21/20] efi_loader: hack for archs that cannot do unaligned accesses

[Rob Clark]

On Tue, Aug 8, 2017 at 8:26 AM, Mark Kettenis  wrote:
>> From: Rob Clark 
>> Date: Mon, 7 Aug 2017 18:18:50 -0400
>>
>> On Mon, Aug 7, 2017 at 5:14 PM, Mark Kettenis  
>> wrote:
>> >> From: Alexander Graf 
>> >> Date: Mon, 7 Aug 2017 21:19:37 +0100
>> >>
>> >> For AArch64 things are different. There we should strive for full UEFI
>> >> compliance as it's "the future" :).
>> >
>> > Even there just making things work would be good enough for me ;).
>> > Our AArach64 bootloader is almost identical to the AArch32 one and
>> > works on a real UEFI implementation as well (SoftIron Overdrive 1000).
>> >
>>
>> I think we should make the aarch64 implementation fully compliant (ie.
>> addition of missing __packed's and no extra padding bytes).  I won't
>> loose sleep if some efi payloads don't work on pre-aarch64 (we should
>> be able to keep things that were working before working).  If adding
>> missing __packed breaks things on platforms that can't do unaligned
>> access, the solution is not to remove __packed, but to conditionally
>> add padding bytes at the end of the struct.  That way we keep things
>> working as before on the old platforms, but make things work correctly
>> on aarch64.
>>
>> I'll add back my patch for EFI_DP_PAD() to this patchset, since this
>> seems like the sensible way forward.
>
> Adding padding does not magically align things on a >8-bit boundary.
> And as Peter pointed out, the hard drive device path type is
> inherently unalignable.  The UEFI payload simply has to deal with
> that.  If grub/shim/fallback.efi is currently broken, it will have to
> be fixed to be usable with U-Boot on 32-bit ARM.
>
> The problem that needs to be fixed is the manipulation of device path
> nodes in U-Boot itself.  Using __packed and -mno-aligned-access should
> take care of any parsing done through the device path node struct
> types.  But whenever a member of such a struct is passed to some other
> function that function should be careful not to do unaligned access.
> After you fixed the GUID printing code it seems ascii2unicode() is the
> only function left that does an unaligned access.  Perhaps the
> solution here is to simply stop using file path nodes in U-Boot like
> you already suggested.  Or otherwise just do the ascii2unicode()
> conversion into a suitably aligned buffer and memcpy() that into
> place.
>

It is also a problem with all the utf16 string handling, which shows
up all over the place.  For example if efi payload (or
efi_load_image()) took the file path string from a device-path, which
was unaligned.  I'm not really a fan of trying to deal with this
everywhere, since it is making the code much more cumbersome for the
benefit of platforms that are broken (and still will be broken in ways
we cannot prevent) from an EFI standpoint.

So I'm pretty much NAK on playing whack-a-mole with unaligned utf16
string handling in u-boot.  Padding bytes at end of device-path
structs won't solve everything.. that can only be done by making
unaligned accesses work.  (And hey, maybe we can trap the faults and
emulate on armv6 if someone cares enough?)  But the padding bytes will
keep things working to the extent that they work today, in an
non-obtrusive way, that is good enough for armv6/armv7 and it lets us
fix things properly on aarch64.  So that is progress.

(And I kind of agree with Leif from the other email on this thread
that efi_*install* should probably scream scary warning msgs on
BROKEN_UNALIGNED platforms.)

BR,
-R
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] Please pull u-boot-marvell/master

[Stefan Roese]

Hi Tom,

please pull the following mvebu board fix from Marek.

Thanks,
Stefan


The following changes since commit eaa90e5df2a4a1cb12fb73571978a9379242d0b5:

  common/env_embedded.c: rename PPCENV/PPCTEXT macros (2017-08-04 20:38:39 
-0400)

are available in the git repository at:

  git://www.denx.de/git/u-boot-marvell.git 

for you to fetch changes up to 8daa3468b52f89e069bca469a68b866c2583a4a5:

  mvebu: turris_omnia: Fix PEX vs SATA detection for board topology (2017-08-08 
14:20:26 +0200)


Marek Behún (1):
  mvebu: turris_omnia: Fix PEX vs SATA detection for board topology

 board/CZ.NIC/turris_omnia/turris_omnia.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] mtd: cfi: Zap CFI_FLASH_SHIFT_WIDTH redefinition

[Stefan Roese]

On 21.07.2017 23:12, Marek Vasut wrote:

This is defined twice in the same file, with the same value, likely
because of some patch merge issue. Pick the uglier one and nuke it.

Signed-off-by: Marek Vasut 
Cc: Tom Rini 


Applied to u-boot-cfi-flash/master.

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

[U-Boot] [PATCH v2 2/2] dm: test: replace dm_scan_dt() by of dm_extended_scan_fdt() in dm_do_test

[patrice.chotard]

From: Patrice Chotard 

This allows to scan the DT including all "clocks" node's sub-nodes
in which fixed-clock are defined.
All fixed-clock should be defined inside a clocks node which collect all
external oscillators. Until now, all clocks sub-nodes can't be binded except
if the "simple-bus" compatible string is added which is a hack.

Update test.dts by moving clk_fixed node inside clocks.

Signed-off-by: Patrice Chotard 
---

v2: _ none

 arch/sandbox/dts/test.dts | 10 ++
 test/dm/test-main.c   |  2 +-
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index 65b2f8e..e67d428 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -127,10 +127,12 @@
compatible = "denx,u-boot-fdt-test";
};
 
-   clk_fixed: clk-fixed {
-   compatible = "fixed-clock";
-   #clock-cells = <0>;
-   clock-frequency = <1234>;
+   clocks {
+   clk_fixed: clk-fixed {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <1234>;
+   };
};
 
clk_sandbox: clk-sbox {
diff --git a/test/dm/test-main.c b/test/dm/test-main.c
index 9d88d31..ab3e35b 100644
--- a/test/dm/test-main.c
+++ b/test/dm/test-main.c
@@ -92,7 +92,7 @@ static int dm_do_test(struct unit_test_state *uts, struct 
unit_test *test,
if (test->flags & DM_TESTF_PROBE_TEST)
ut_assertok(do_autoprobe(uts));
if (test->flags & DM_TESTF_SCAN_FDT)
-   ut_assertok(dm_scan_fdt(gd->fdt_blob, false));
+   ut_assertok(dm_extended_scan_dt(gd->fdt_blob, false));
 
/*
 * Silence the console and rely on console reocrding to get
-- 
1.9.1

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

Re: [U-Boot] [PATCH v0 21/20] efi_loader: hack for archs that cannot do unaligned accesses

[Leif Lindholm]

On Tue, Aug 08, 2017 at 08:01:10AM -0400, Rob Clark wrote:
> On Tue, Aug 8, 2017 at 7:32 AM, Leif Lindholm  
> wrote:
> > On Tue, Aug 08, 2017 at 09:11:14AM +0100, Ard Biesheuvel wrote:
> >> On 8 August 2017 at 07:52, Alexander Graf  wrote:
> >> >> Am 07.08.2017 um 23:18 schrieb Rob Clark :
> >> >>
> >> >> This is problematic around file nodes in the device path.  Adding the
> >> >> padding bytes to the end of each device-path struct would "solve"
> >> >> that, and if pre-aarch64 we are aiming at "good enough to work", I
> >> >> kinda think that this the approach we should go for.  Other than
> >> >> file-path nodes, the rest of the issues in u-boot should be solved by
> >> >> addition of missing __packed on 'struct efi_device_path' (which I've
> >> >> added locally and will be in the next revision of the patchset).
> >> >
> >> > Let's ask Leif and Ard if that is actually correct. If I remember
> >> > correctly, edk2 some times leverages automatic padding from the
> >> > compiler on structs.
> >>
> >> I guess that that might work, if U-boot is the only agent
> >> instantiating device path structures. But what do you mean by
> >> 'correct' in this context?
> >
> > Well, if that is the case, are we risking the ability to in the future
> > support loading drivers or protocols at runtime. (This would for
> > example exclude Shim compatibility or running the UEFI Shell.)
> 
> My proposal (and this is only for <=armv6 and armv7 until someone gets
> around to enabling mmu and disabling alignment faults) is to add
> padding bytes at the end of the various device-path structs to at
> least keep the structs (and things like utf16 string in file-path
> struct) aligned, and rely on efi payload and u-boot to be compiled
> with -mno-unaligned-access if it needs to access fields within the
> device-path structs.
> 
> This is *essentially* what u-boot does implicitly at the moment (by
> missing __packed attribute on certain structs).  I want to fix that on
> aarch64, but without the padding bytes it causes a some unaligned
> accesses in u-boot on armv7 devices.
>
> I think the goal for armv7 is more to have enough uefi for grub and
> OpenBSD's bootloader.  If fancy things like loading drivers and
> protocols at runtime doesn't work, well these didn't work before so I
> won't loose much sleep.  But I would like that to work properly on
> aarch64.

I'm all for the just enough approach (I just keep hoping for feature
creep). If this means certain aspects will not be supportable, what I
want is for it to be not supportable in a predictable manner.

So I guess what I'd like is that if we do this, then we either turn
the efi_*install_* functions back into just returning
EFI_OUT_OF_RESOURCES on these platforms, or worst case make them
scream bloody murder (but progress and hope for the best - like [1]).

[1] https://lists.denx.de/pipermail/u-boot/2016-January/241454.html

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

[U-Boot] [PATCH v2 0/6] fix apalis-tk1 pcie gigabit ethernet operation

[Marcel Ziswiler]

This series addresses a gigabit Ethernet reliability issue as observed
on Apalis TK1 related to a PCIe reset timing violation.

This series depends on Simon's work available at u-boot-dm/master plus
my previous series "move apalis t30/tk1, colibri t20/t30 to livetree".

This series is available at 
http://git.toradex.com/cgit/u-boot-toradex.git/log/?h=for-next

Changes in v2:
- Add Simon's reviewed-by.
- New bug fix.
- Incorporate Stephen's review feedback by introducing a
  tegra_pcie_port_index_of_port() function as well as a board-specific
  reset override function.
- Add Simon's reviewed-by.

Marcel Ziswiler (5):
  apalis-tk1: add missing as3722 gpio0 configuration
  power: as3722: fix ldo_get/set_enable for ldo index bigger than 7
  pci: tegra: introduce weak tegra_pcie_board_port_reset() function
  power: as3722: add as3722_ldo_set_voltage signature to header file
  apalis-tk1: fix pcie reset for reliable gigabit ethernet operation

Sanchayan Maity (1):
  configs: apalis-tk1: fix boot failure using ext4 rootfs

 arch/arm/dts/tegra124-apalis.dts   |   6 +-
 board/toradex/apalis-tk1/apalis-tk1.c  | 247 ++---
 drivers/pci/pci_tegra.c|  28 +++-
 drivers/power/regulator/as3722_regulator.c |  16 +-
 include/configs/apalis-tk1.h   |   5 +-
 include/pci_tegra.h|   9 ++
 include/power/as3722.h |   4 +-
 7 files changed, 206 insertions(+), 109 deletions(-)
 create mode 100644 include/pci_tegra.h

-- 
2.9.4

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

[U-Boot] [PATCH v2 3/6] power: as3722: fix ldo_get/set_enable for ldo index bigger than 7

[Marcel Ziswiler]

From: Marcel Ziswiler 

Fix ldo_get_enable() and ldo_set_enable() functions for LDOs with an
index > 7. Turns out there are actually two separate AS3722_LDO_CONTROL
registers AS3722_LDO_CONTROL0 and AS3722_LDO_CONTROL1. Actually make use
of both. While at it also actually use the enable parameter of the
ldo_set_enable() function which now truly allows disabling as opposed to
only enabling LDOs.

Signed-off-by: Marcel Ziswiler 
---

Changes in v2:
- New bug fix.

 drivers/power/regulator/as3722_regulator.c | 16 ++--
 include/power/as3722.h |  3 ++-
 2 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/drivers/power/regulator/as3722_regulator.c 
b/drivers/power/regulator/as3722_regulator.c
index 3e1e6f1..eb4c465 100644
--- a/drivers/power/regulator/as3722_regulator.c
+++ b/drivers/power/regulator/as3722_regulator.c
@@ -69,10 +69,16 @@ static int ldo_set_value(struct udevice *dev, int uvolt)
 static int ldo_set_enable(struct udevice *dev, bool enable)
 {
struct udevice *pmic = dev_get_parent(dev);
+   u8 ctrl_reg = AS3722_LDO_CONTROL0;
int ldo = dev->driver_data;
int ret;
 
-   ret = pmic_clrsetbits(pmic, AS3722_LDO_CONTROL, 0, 1 << ldo);
+   if (ldo > 7) {
+   ctrl_reg = AS3722_LDO_CONTROL1;
+   ldo -= 8;
+   }
+
+   ret = pmic_clrsetbits(pmic, ctrl_reg, !enable << ldo, enable << ldo);
if (ret < 0) {
debug("%s: failed to write LDO control register: %d", __func__,
  ret);
@@ -85,10 +91,16 @@ static int ldo_set_enable(struct udevice *dev, bool enable)
 static int ldo_get_enable(struct udevice *dev)
 {
struct udevice *pmic = dev_get_parent(dev);
+   u8 ctrl_reg = AS3722_LDO_CONTROL0;
int ldo = dev->driver_data;
int ret;
 
-   ret = pmic_reg_read(pmic, AS3722_LDO_CONTROL);
+   if (ldo > 7) {
+   ctrl_reg = AS3722_LDO_CONTROL1;
+   ldo -= 8;
+   }
+
+   ret = pmic_reg_read(pmic, ctrl_reg);
if (ret < 0) {
debug("%s: failed to read SD control register: %d", __func__,
  ret);
diff --git a/include/power/as3722.h b/include/power/as3722.h
index cb4b188..b3dc7b6 100644
--- a/include/power/as3722.h
+++ b/include/power/as3722.h
@@ -14,7 +14,8 @@
 #define AS3722_SD_VOLTAGE(n) (0x00 + (n))
 #define AS3722_LDO_VOLTAGE(n) (0x10 + (n))
 #define AS3722_SD_CONTROL 0x4d
-#define AS3722_LDO_CONTROL 0x4e
+#define AS3722_LDO_CONTROL0 0x4e
+#define AS3722_LDO_CONTROL1 0x4f
 #define AS3722_ASIC_ID1 0x90
 #define AS3722_ASIC_ID2 0x91
 
-- 
2.9.4

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

[U-Boot] [PATCH 2/3] apalis_t30: fix pcie port 0 and 1 pin muxing

[Marcel Ziswiler]

From: Marcel Ziswiler 

Fix optional Apalis type specific 4 lane PCIe port 0 and Apalis PCIe
port 1 pin muxing.

Signed-off-by: Marcel Ziswiler 
---

 board/toradex/apalis_t30/pinmux-config-apalis_t30.h | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/board/toradex/apalis_t30/pinmux-config-apalis_t30.h 
b/board/toradex/apalis_t30/pinmux-config-apalis_t30.h
index e0b00ea..6c30631 100644
--- a/board/toradex/apalis_t30/pinmux-config-apalis_t30.h
+++ b/board/toradex/apalis_t30/pinmux-config-apalis_t30.h
@@ -285,14 +285,14 @@ static struct pmux_pingrp_config tegra3_pinmux_common[] = 
{
DEFAULT_PINMUX(SPI1_CS0_N_PX6, SPI1, NORMAL, NORMAL, INPUT),
DEFAULT_PINMUX(SPI1_MISO_PX7, SPI1, NORMAL, NORMAL, INPUT),
 
-   DEFAULT_PINMUX(PEX_L0_PRSNT_N_PDD0, PCIE, NORMAL, NORMAL, INPUT),
-   DEFAULT_PINMUX(PEX_L0_RST_N_PDD1, PCIE, NORMAL, NORMAL, OUTPUT),
-   DEFAULT_PINMUX(PEX_L0_CLKREQ_N_PDD2, PCIE, NORMAL, NORMAL, INPUT),
+   DEFAULT_PINMUX(PEX_L0_PRSNT_N_PDD0, RSVD2, NORMAL, NORMAL, OUTPUT),
+   DEFAULT_PINMUX(PEX_L0_RST_N_PDD1, RSVD2, NORMAL, NORMAL, OUTPUT),
+   DEFAULT_PINMUX(PEX_L0_CLKREQ_N_PDD2, RSVD2, NORMAL, NORMAL, INPUT),
DEFAULT_PINMUX(PEX_WAKE_N_PDD3, PCIE, NORMAL, NORMAL, INPUT),
 
-   DEFAULT_PINMUX(PEX_L1_PRSNT_N_PDD4, PCIE, DOWN, TRISTATE, OUTPUT), /* 
NC */
-   DEFAULT_PINMUX(PEX_L1_RST_N_PDD5, PCIE, DOWN, TRISTATE, OUTPUT), /* NC 
*/
-   DEFAULT_PINMUX(PEX_L1_CLKREQ_N_PDD6, PCIE, DOWN, TRISTATE, OUTPUT), /* 
NC */
+   DEFAULT_PINMUX(PEX_L1_PRSNT_N_PDD4, RSVD2, DOWN, TRISTATE, OUTPUT), /* 
NC */
+   DEFAULT_PINMUX(PEX_L1_RST_N_PDD5, RSVD2, DOWN, TRISTATE, OUTPUT), /* NC 
*/
+   DEFAULT_PINMUX(PEX_L1_CLKREQ_N_PDD6, RSVD2, DOWN, TRISTATE, OUTPUT), /* 
NC */
DEFAULT_PINMUX(PEX_L2_PRSNT_N_PDD7, PCIE, NORMAL, NORMAL, INPUT),
DEFAULT_PINMUX(PEX_L2_RST_N_PCC6, PCIE, NORMAL, NORMAL, OUTPUT),
DEFAULT_PINMUX(PEX_L2_CLKREQ_N_PCC7, PCIE, NORMAL, NORMAL, INPUT),
-- 
2.9.4

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

[U-Boot] [PATCH 3/3] apalis_t30: fix optional pcie port reset for reliable pcie operation

[Marcel Ziswiler]

From: Marcel Ziswiler 

Allow optionally bringing up the Apalis type specific 4 lane PCIe port
as well as the PCIe switch as found on the Apalis Evaluation board. In
order to avoid violating the PCIe reset timing do this by overriding the
tegra_pcie_board_port_reset() function. Note however that both the
Apalis type specific 4 lane PCIe port as well as the regular Apalis PCIe
port are also left disabled in the device tree by default.

Signed-off-by: Marcel Ziswiler 
---

 board/toradex/apalis_t30/apalis_t30.c | 47 +++
 include/configs/apalis_t30.h  |  1 +
 2 files changed, 48 insertions(+)

diff --git a/board/toradex/apalis_t30/apalis_t30.c 
b/board/toradex/apalis_t30/apalis_t30.c
index 827eefd..e997429 100644
--- a/board/toradex/apalis_t30/apalis_t30.c
+++ b/board/toradex/apalis_t30/apalis_t30.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "../common/tdx-common.h"
 
 #include "pinmux-config-apalis_t30.h"
@@ -23,6 +24,11 @@ DECLARE_GLOBAL_DATA_PTR;
 #define PMU_I2C_ADDRESS0x2D
 #define MAX_I2C_RETRY  3
 
+#ifdef APALIS_T30_PCIE_EVALBOARD_INIT
+#define PEX_PERST_NTEGRA_GPIO(S, 7) /* Apalis GPIO7 */
+#define RESET_MOCI_CTRLTEGRA_GPIO(I, 4)
+#endif /* APALIS_T30_PCIE_EVALBOARD_INIT */
+
 int arch_misc_init(void)
 {
if (readl(NV_PA_BASE_SRAM + NVBOOTINFOTABLE_BOOTTYPE) ==
@@ -107,6 +113,47 @@ int tegra_pcie_board_init(void)
return err;
}
 
+#ifdef APALIS_T30_PCIE_EVALBOARD_INIT
+   gpio_request(PEX_PERST_N, "PEX_PERST_N");
+   gpio_request(RESET_MOCI_CTRL, "RESET_MOCI_CTRL");
+#endif /* APALIS_T30_PCIE_EVALBOARD_INIT */
+
return 0;
 }
+
+void tegra_pcie_board_port_reset(void *port)
+{
+   int index = tegra_pcie_port_index_of_port(port);
+   if (index == 2) { /* I210 Gigabit Ethernet Controller (On-module) */
+   tegra_pcie_port_reset(port);
+#ifdef APALIS_T30_PCIE_EVALBOARD_INIT
+   } else if (index == 1) { /* Apalis PCIe */
+   /*
+* As port 0 and 1 share the same RESET_MOCI only assert it once
+* for both ports below to avoid loosing the previously brought
+* up port again.
+*/
+   } else if (index == 0) { /* Apalis Type Specific 4 Lane PCIe */
+   /*
+* Reset PLX PEX 8605 PCIe Switch plus PCIe devices on Apalis
+* Evaluation Board
+*/
+   gpio_direction_output(PEX_PERST_N, 0);
+   gpio_direction_output(RESET_MOCI_CTRL, 0);
+
+   /*
+* Must be asserted for 100 ms after power and clocks are stable
+*/
+   mdelay(100);
+
+   gpio_set_value(PEX_PERST_N, 1);
+   /*
+* Err_5: PEX_REFCLK_OUTpx/nx Clock Outputs is not Guaranteed
+* Until 900 us After PEX_PERST# De-assertion
+*/
+   mdelay(1);
+   gpio_set_value(RESET_MOCI_CTRL, 1);
+#endif /* APALIS_T30_PCIE_EVALBOARD_INIT */
+   }
+}
 #endif /* CONFIG_PCI_TEGRA */
diff --git a/include/configs/apalis_t30.h b/include/configs/apalis_t30.h
index daa3be0..f2a8b03 100644
--- a/include/configs/apalis_t30.h
+++ b/include/configs/apalis_t30.h
@@ -36,6 +36,7 @@
 
 /* PCI host support */
 #define CONFIG_CMD_PCI
+#undef APALIS_T30_PCIE_EVALBOARD_INIT
 
 /* PCI networking support */
 #define CONFIG_E1000_NO_NVM
-- 
2.9.4

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

Re: [U-Boot] [PATCH 2/6 v5] x86: conga: Add option to select different config headers for baseboards

[Bin Meng]

Hi Stefan,

On Tue, Aug 8, 2017 at 6:06 PM, Bin Meng  wrote:
> On Tue, Aug 8, 2017 at 5:52 PM, Stefan Roese  wrote:
>> This patch adds the infrastructure to define different config headers
>> with different configurations and default environment for the baseboards
>> that can now be selected via Kconfig. The new configuration for the
>> theadorable-x86-conga-qa3-e3845 is also added. Also the new defconfig
>> file for this new target is added.
>>
>> Signed-off-by: Stefan Roese 
>> Cc: Simon Glass 
>> Cc: Bin Meng 
>> ---
>> v5:
>> - Added imply for some SPI NOR chips to the board Kconfig file
>>
>> v4:
>> - Remove Gigadevice and Macronix flash support
>>
>> v3:
>> - Rebased on latest master
>> - Removed unused macros from config headers
>>
>> v2:
>> - Added Bin's reviewed-by
>>
>>  board/congatec/Kconfig | 11 +
>>  board/congatec/conga-qeval20-qa3-e3845/Kconfig |  9 ++--
>>  board/congatec/conga-qeval20-qa3-e3845/MAINTAINERS |  2 +
>>  configs/theadorable-x86-conga-qa3-e3845_defconfig  | 54 
>> ++
>>  include/configs/theadorable-x86-conga-qa3-e3845.h  | 38 +++
>>  5 files changed, 109 insertions(+), 5 deletions(-)
>>  create mode 100644 configs/theadorable-x86-conga-qa3-e3845_defconfig
>>  create mode 100644 include/configs/theadorable-x86-conga-qa3-e3845.h
>>
>
> Reviewed-by: Bin Meng 

For some reason, this patch fails in buildman testing:

02: x86: conga: Add option to select different config headers for baseboards
-make[2]: *** [theadorable-x86-conga-qa3-e3845_defconfig] Error 1
-make[1]: *** [theadorable-x86-conga-qa3-e3845_defconfig] Error 2
+../arch/x86/lib/acpi_s3.c:14:25: error: expected declaration
specifiers or '...' before '*' token
+ static void asmlinkage (*acpi_do_wakeup)(void *vector) = (void *)WAKEUP_BASE;
+ ^
+  acpi_do_wakeup(vector);
+  ^
+make[2]: *** [arch/x86/lib/acpi_s3.o] Error 1
+make[1]: *** [arch/x86/lib] Error 2
w+../arch/x86/lib/acpi_s3.c: In function 'acpi_jump_to_wakeup':
w+../arch/x86/lib/acpi_s3.c:22:2: warning: implicit declaration of
function 'acpi_do_wakeup' [-Wimplicit-function-declaration]

But this failure disappears in patch [05/06]:

05: x86: conga: theadorable-x86-conga-qa3-e3845_defconfig: Misc
defconfig updates
   x86: theadorable-x86-conga-qa3-e3845
-../arch/x86/lib/acpi_s3.c:14:25: error: expected declaration
specifiers or '...' before '*' token
- static void asmlinkage (*acpi_do_wakeup)(void *vector) = (void *)WAKEUP_BASE;
- ^
-  acpi_do_wakeup(vector);
-  ^
-make[2]: *** [arch/x86/lib/acpi_s3.o] Error 1
-make[1]: *** [arch/x86/lib] Error 2
w-../arch/x86/lib/acpi_s3.c: In function 'acpi_jump_to_wakeup':
w-../arch/x86/lib/acpi_s3.c:22:2: warning: implicit declaration of
function 'acpi_do_wakeup' [-Wimplicit-function-declaration]

Could you please have a look at this? Thanks!

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

Re: [U-Boot] [PATCH 2/6 v5] x86: conga: Add option to select different config headers for baseboards

[Stefan Roese]

Hi Bin,

On 08.08.2017 12:29, Bin Meng wrote:

On Tue, Aug 8, 2017 at 6:06 PM, Bin Meng  wrote:

On Tue, Aug 8, 2017 at 5:52 PM, Stefan Roese  wrote:

This patch adds the infrastructure to define different config headers
with different configurations and default environment for the baseboards
that can now be selected via Kconfig. The new configuration for the
theadorable-x86-conga-qa3-e3845 is also added. Also the new defconfig
file for this new target is added.

Signed-off-by: Stefan Roese 
Cc: Simon Glass 
Cc: Bin Meng 
---
v5:
- Added imply for some SPI NOR chips to the board Kconfig file

v4:
- Remove Gigadevice and Macronix flash support

v3:
- Rebased on latest master
- Removed unused macros from config headers

v2:
- Added Bin's reviewed-by

  board/congatec/Kconfig | 11 +
  board/congatec/conga-qeval20-qa3-e3845/Kconfig |  9 ++--
  board/congatec/conga-qeval20-qa3-e3845/MAINTAINERS |  2 +
  configs/theadorable-x86-conga-qa3-e3845_defconfig  | 54 ++
  include/configs/theadorable-x86-conga-qa3-e3845.h  | 38 +++
  5 files changed, 109 insertions(+), 5 deletions(-)
  create mode 100644 configs/theadorable-x86-conga-qa3-e3845_defconfig
  create mode 100644 include/configs/theadorable-x86-conga-qa3-e3845.h



Reviewed-by: Bin Meng 


For some reason, this patch fails in buildman testing:

02: x86: conga: Add option to select different config headers for baseboards
-make[2]: *** [theadorable-x86-conga-qa3-e3845_defconfig] Error 1
-make[1]: *** [theadorable-x86-conga-qa3-e3845_defconfig] Error 2
+../arch/x86/lib/acpi_s3.c:14:25: error: expected declaration
specifiers or '...' before '*' token
+ static void asmlinkage (*acpi_do_wakeup)(void *vector) = (void *)WAKEUP_BASE;
+ ^
+  acpi_do_wakeup(vector);
+  ^
+make[2]: *** [arch/x86/lib/acpi_s3.o] Error 1
+make[1]: *** [arch/x86/lib] Error 2
w+../arch/x86/lib/acpi_s3.c: In function 'acpi_jump_to_wakeup':
w+../arch/x86/lib/acpi_s3.c:22:2: warning: implicit declaration of
function 'acpi_do_wakeup' [-Wimplicit-function-declaration]

But this failure disappears in patch [05/06]:

05: x86: conga: theadorable-x86-conga-qa3-e3845_defconfig: Misc
defconfig updates
x86: theadorable-x86-conga-qa3-e3845
-../arch/x86/lib/acpi_s3.c:14:25: error: expected declaration
specifiers or '...' before '*' token
- static void asmlinkage (*acpi_do_wakeup)(void *vector) = (void *)WAKEUP_BASE;
- ^
-  acpi_do_wakeup(vector);
-  ^
-make[2]: *** [arch/x86/lib/acpi_s3.o] Error 1
-make[1]: *** [arch/x86/lib] Error 2
w-../arch/x86/lib/acpi_s3.c: In function 'acpi_jump_to_wakeup':
w-../arch/x86/lib/acpi_s3.c:22:2: warning: implicit declaration of
function 'acpi_do_wakeup' [-Wimplicit-function-declaration]

Could you please have a look at this? Thanks!


I've seen this issue as well and am unable to tell, why this fails
in this configuration and in others not.

With patch 5/6 applied, the problem is gone though. Do you have an
idea, where this issue might come from?

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

Re: [U-Boot] [PATCH v4] usb: kbd: don't fail with iomux

[Bin Meng]

Hi Rob,

On Tue, Aug 8, 2017 at 6:48 PM, Rob Clark  wrote:
> On Tue, Aug 8, 2017 at 6:42 AM, Bin Meng  wrote:
>> Hi Rob,
>>
>> On Tue, Aug 8, 2017 at 3:51 AM, Rob Clark  wrote:
>>> stdin might not be set, which would cause iomux_doenv() to fail
>>> therefore causing probe_usb_keyboard() to fail.  Furthermore if we do
>>> have iomux enabled, the sensible thing (in terms of user experience)
>>> would be to simply add ourselves to the list of stdin devices.
>>>
>>> This fixes an issue with usbkbd on dragonboard410c with distro-
>>> bootcmd, where stdin is not set (so stdinname is null).
>>>
>>> Signed-off-by: Rob Clark 
>>> ---
>>> v2: address Bin's review comments
>>> v3: fix fail with free()ing if usbkbd is already in stdin env variable
>>> pointed out by Simon
>>> v4: use if (CONFIG_IS_ENABLED(CONSOLE_MUX)) { ... }
>>>
>>>  common/usb_kbd.c  | 46 +++---
>>>  include/console.h |  2 --
>>>  2 files changed, 31 insertions(+), 17 deletions(-)
>>>
>>> diff --git a/common/usb_kbd.c b/common/usb_kbd.c
>>> index d2d29cc98f..8edeb6c4f5 100644
>>> --- a/common/usb_kbd.c
>>> +++ b/common/usb_kbd.c
>>> @@ -516,23 +516,39 @@ static int probe_usb_keyboard(struct usb_device *dev)
>>> return error;
>>>
>>> stdinname = getenv("stdin");
>>> -#if CONFIG_IS_ENABLED(CONSOLE_MUX)
>>> -   error = iomux_doenv(stdin, stdinname);
>>> -   if (error)
>>> -   return error;
>>> -#else
>>> -   /* Check if this is the standard input device. */
>>> -   if (strcmp(stdinname, DEVNAME))
>>> -   return 1;
>>> +   if (CONFIG_IS_ENABLED(CONSOLE_MUX)) {
>>> +   char *devname = DEVNAME;
>>> +   char *newstdin = NULL;
>>> +   /*
>>> +* stdin might not be set yet.. either way, with console-
>>> +* mux the sensible thing to do is add ourselves to the
>>> +* list of stdio devices:
>>> +*/
>>> +   if (stdinname && !strstr(stdinname, DEVNAME)) {
>>> +   newstdin = malloc(strlen(stdinname) +
>>> + strlen(","DEVNAME) + 1);
>>> +   sprintf(newstdin, "%s,"DEVNAME, stdinname);
>>> +   stdinname = newstdin;
>>> +   } else if (!stdinname) {
>>> +   stdinname = devname;
>>> +   }
>>> +   error = iomux_doenv(stdin, stdinname);
>>> +   free(newstdin);
>>
>> Sorry I should have asked this before: isn't free(devname) OK? In
>> previous version, it has a test logic to see whether free is needed.
>
> it was in the first version of my patch, until I added the &&!strstr()
> bit to avoid adding usbkbd a second time to stdin if stdin already
> contained usbkbd.  Now we have a case where stdinname is the ptr
> returned from getenv() which we probably don't want to free() ;-)
>

Ah yes, I misread the codes. It's free(newstdin) not free(stdinname).
Thanks for the clarification.

Reviewed-by: Bin Meng 

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