Re: [U-Boot] usb command missing?

[Lukasz Majewski]

Hi Duncan,

> In the latest git download the usb command appears turned off.
> 
> I checked make menuconfig and usb appears turned on.

If you could share the arch and board on which you work on?

> 
> I compared the .config file with my previous, older .config 
> command and all the usb defines appeared to be the same.
> 
> Please help me understand how I can get this command working.
> 
> u-boot reports the usb command is unknown.
> 
> Thanks
> Duncan Hare




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


pgpSyRlnUdn2H.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] usb command missing?

[Duncan Hare]

In the latest git download the usb command appears turned off.

I checked make menuconfig and usb appears turned on.

I compared the .config file with my previous, older .config 
command and all the usb defines appeared to be the same.

Please help me understand how I can get this command working.

u-boot reports the usb command is unknown.

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

[U-Boot] [PATCH] tools: Include U-Boot libfdt headers from their actual path

[Paul Kocialkowski]

There are no headers for libfdt in lib/libfdt, as they are instead
located in scripts/dtc/libfdt. Specifying lib/libfdt for headers
inclusion in host tools results in using the system libfdt headers,
which is not what we want. Change this to the proper path.

Signed-off-by: Paul Kocialkowski 
---
 tools/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/Makefile b/tools/Makefile
index d3387fad69..f38f68ee47 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -244,7 +244,7 @@ endif # !LOGO_BMP
 #
 HOST_EXTRACFLAGS += -include $(srctree)/include/compiler.h \
$(patsubst -I%,-idirafter%, $(filter -I%, $(UBOOTINCLUDE))) \
-   -I$(srctree)/lib/libfdt \
+   -I$(srctree)/scripts/dtc/libfdt \
-I$(srctree)/tools \
-DUSE_HOSTCC \
-D__KERNEL_STRICT_NAMES \
-- 
2.16.2

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

Re: [U-Boot] [RFC] ns16550: Add support for AUX regs usage on some ARC SoCs

[Alexey Brodkin]

Hi Simon,

On Thu, 2018-02-22 at 10:29 -0700, Simon Glass wrote:
> Hi Alexey,
> 
> On 22 February 2018 at 09:23, Alexey Brodkin
>  wrote:
> > Hi Simon,
> > 
> > On Thu, 2018-02-22 at 09:17 -0700, Simon Glass wrote:

[snip]

> > > I think a separate driver might be better, unless we want to make the
> > > read/write interface go through regmap or similar?
> > 
> > But in case of ARC's AUX regs portmap won't help because those AUX regs are
> > couldn't be mapped - that a completely different address space and we may
> > only access them via dedicated instructions (LR vs LD and SR vs ST).
> 
> Well...
> 
> 1. With a separate driver, you can do whatever you want :-) I know it
> introduces code duplication though...

Exactly I hate to introduce another driver which will be 99,9% the same
as an existing one and then we'll need to care of it as well.

> 2. With regmap you can add your own regmap driver, and again do
> whatever you want. I can help with that if it sounds attractive

Ok so I took a look at regmap in Linux kernel and indeed that
will solve our problem: we'll have a regmap-mmio.c and regmap-arcaux.c
with appropriate implementation of accessors but I'm not really sure
it worth the trouble. Or your idea was to move all the different #ifdefs from
serial_{in|out}_shift() to the corresponding regmap implementations such that
we have something like below:
 regmap-mem32-le.c
 regmap-mem32-be.c
 regmap-portmapped.c
 etc
?

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

[U-Boot] [PATCH 1/1] input: indicate that code page 437 is used

[Heinrich Schuchardt]

Add a comment indicating that the German key map assumes code page 437.

Add support for character ² (square sign) in the German key map.

Signed-off-by: Heinrich Schuchardt 
---
 drivers/input/input.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/input/input.c b/drivers/input/input.c
index 26da3a95ff0..a33f7e94bf4 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -83,6 +83,9 @@ static unsigned char kbd_ctrl_xlate[] = {
'\r', 0xff, '/',  '*',
 };
 
+/*
+ * German keymap. Special letters are mapped according to code page 437.
+ */
 static const uchar kbd_plain_xlate_german[] = {
0xff, 0x1b,  '1',  '2',  '3',  '4',  '5',  '6', /* scan 00-07 */
 '7',  '8',  '9',  '0', 0xe1, '\'', 0x08, '\t', /* scan 08-0F */
@@ -124,7 +127,7 @@ static unsigned char kbd_shift_xlate_german[] = {
 };
 
 static unsigned char kbd_right_alt_xlate_german[] = {
-   0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 00-07 */
+   0xff, 0xff, 0xff, 0xfd, 0xff, 0xff, 0xff, 0xff, /* scan 00-07 */
 '{',  '[',  ']',  '}', '\\', 0xff, 0xff, 0xff, /* scan 08-0F */
 '@', 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 10-17 */
0xff, 0xff, 0xff,  '~', 0xff, 0xff, 0xff, 0xff, /* scan 18-1F */
-- 
2.16.1

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

Re: [U-Boot] [PATCH v3 2/2] efi_loader: provide new doc/README.uefi

[Leif Lindholm]

On Fri, Mar 02, 2018 at 07:58:50PM +0100, Heinrich Schuchardt wrote:
> Provides information about
> 
> - usage of the bootefi command
> - overview of UEFI
> - interaction between U-Boot and EFI drivers
> 
> Signed-off-by: Heinrich Schuchardt 

Well, from my point of view:
Reviewed-by: Leif Lindholm 
or
Acked-by: Leif Lindholm 
(whichever makes more sense).

Many thanks!

/
Leif

> ---
> v3
>   rename README.efi to README.uefi
>   use UEFI instead of EFI where applicable
> v2
>   split the patch in two: one deleteing all old lines, the other
>   adding the new ones
>   update README contents
> ---
>  MAINTAINERS |   2 +-
>  doc/README.efi  |   0
>  doc/README.uefi | 332 
> 
>  3 files changed, 333 insertions(+), 1 deletion(-)
>  delete mode 100644 doc/README.efi
>  create mode 100644 doc/README.uefi
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 077828cf1d4..da799b551d9 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -290,7 +290,7 @@ EFI PAYLOAD
>  M:   Alexander Graf 
>  S:   Maintained
>  T:   git git://github.com/agraf/u-boot.git
> -F:   doc/README.efi
> +F:   doc/README.uefi
>  F:   doc/README.iscsi
>  F:   include/efi*
>  F:   include/pe.h
> diff --git a/doc/README.efi b/doc/README.efi
> deleted file mode 100644
> index e69de29bb2d..000
> diff --git a/doc/README.uefi b/doc/README.uefi
> new file mode 100644
> index 000..7403be36146
> --- /dev/null
> +++ b/doc/README.uefi
> @@ -0,0 +1,332 @@
> +
> +
> +# UEFI on U-Boot
> +
> +The Unified Extensible Firmware Interface Specification (UEFI) [1] has become
> +the default for booting on AArch64 and x86 systems. It provides a stable API 
> for
> +the interaction of drivers and applications with the firmware. The API 
> comprises
> +access to block storage, network, and console to name a few. The Linux kernel
> +and boot loaders like GRUB or the FreeBSD loader can be executed.
> +
> +## Building for UEFI
> +
> +The UEFI standard supports only little endian systems. The UEFI support can 
> be
> +activated for ARM and x86 by specifying
> +
> +CONFIG_CMD_BOOTEFI=y
> +CONFIG_EFI_LOADER=y
> +
> +in the .config file.
> +
> +Support for attaching virtual block devices, e.g. iSCSI drives connected by 
> the
> +loaded UEFI application [3], requires
> +
> +CONFIG_BLK=y
> +CONFIG_PARTITIONS=y
> +
> +### Executing a UEFI binary
> +
> +The bootefi command is used to start UEFI applications or to install UEFI
> +drivers. It takes two parameters
> +
> +bootefi  [fdt address]
> +
> +* image address - the memory address of the UEFI binary
> +* fdt address - the memory address of the flattened device tree
> +
> +Below you find the output of an example session starting GRUB.
> +
> +=> load mmc 0:2 ${fdt_addr_r} boot/dtb
> +29830 bytes read in 14 ms (2 MiB/s)
> +=> load mmc 0:1 ${kernel_addr_r} efi/debian/grubaa64.efi
> +reading efi/debian/grubaa64.efi
> +120832 bytes read in 7 ms (16.5 MiB/s)
> +=> bootefi ${kernel_addr_r} ${fdt_addr_r}
> +
> +The environment variable 'bootargs' is passed as load options in the UEFI 
> system
> +table. The Linux kernel EFI stub uses the load options as command line
> +arguments.
> +
> +### Executing the boot manager
> +
> +The UEFI specfication foresees to define boot entries and boot sequence via 
> UEFI
> +variables. Booting according to these variables is possible via
> +
> +bootefi bootmgr [fdt address]
> +
> +As of U-Boot v2018.03 UEFI variables are not persisted and cannot be set at
> +runtime.
> +
> +### Executing the built in hello world application
> +
> +A hello world UEFI application can be built with
> +
> +CONFIG_CMD_BOOTEFI_HELLO_COMPILE=y
> +
> +It can be embedded into the U-Boot binary with
> +
> +CONFIG_CMD_BOOTEFI_HELLO=y
> +
> +The bootefi command is used to start the embedded hello world application.
> +
> +bootefi hello [fdt address]
> +
> +Below you find the output of an example session.
> +
> +=> bootefi hello ${fdtcontroladdr}
> +## Starting EFI application at 0100 ...
> +WARNING: using memory device/image path, this may confuse some payloads!
> +Hello, world!
> +Running on UEFI 2.7
> +Have SMBIOS table
> +Have device tree
> +Load options: root=/dev/sdb3 init=/sbin/init rootwait ro
> +## Application terminated, r = 0
> +
> +The environment variable fdtcontroladdr points to U-Boot's internal device 
> tree
> +(if available).
> +
> +### Executing the built-in selftest
> +
> +An UEFI selftest suite can be embedded in U-Boot by building with
> +
> +CONFIG_CMD_BOOTEFI_SELFTEST=y
> +
> +For testing the UEFI implementation the bootefi command can be used to start 
> the
> +selftest.
> +
> +bootefi selftest [fdt address]
> +
> +The environment variable 'efi_selftest' can be used to select a single test. 
> If
> +it is not provided 

Re: [U-Boot] RPi3 Not autobooting from SD-card. {Scanned}

[Peter Robinson]

On Fri, Mar 2, 2018 at 10:47 AM, Göran Lundberg  wrote:
> Hi!
> I'm trying to boot from u-boot on a Raspberry Pi 3. But for some reason it
> isn't autobooting on the SD-card.
>
> Is it possible to get more debug output on the screen console? I don't have
> a serial console at the moment.
> The output on the screen is:
>
> Net:   No ehternet found.
> starting USB...
> USB:Core Release 2.80a
> scanning bus 0 for devices... 4 USB Devices found
>scanning usb for storage devices... 0 Storage Device(s) found
> Hit any key to stop autoboot:   0
> U-Boot>
>
> Shouldn't it mention mmc somewhere in the boot message?
>
> The first command I type on the prompt is always failing, it's not
> outputting anything. Just a new prompt on the next line. The next commands i
> type in are working. Which seems strange.
> I got boot.scr set up right, except graphic settings which are wrong. It is
> booting the kernel when I type 'run bootcmd'. But only after I type in
> another command before it.
> It seems like it's not detecting the SD-card (mmc0) until I have typed
> anything into the prompt.
>
> Do I have to set any other env variable for it to autoboot? I would have
> printed the output of printenv here, but since I don't have a serial
> console, retyping everything is very time consuming.
> printenv seems to have the right settings. It's basically a full console
> screen of variables. It just doesn't seem to load them until I type in
> another command before it.
>
> boot_targets=mmc0 usb0 pxe dhcp
> Which seems right to me.
>
> I compiled the latest u-boot from github.
>
> If you need more info please let me know and I'll post it.
>
> Hope that anyone can point me in the right direction here. Would really
> appreciate it.

I'm seeing the same issues with 2018.03 rc3.

I'm not sure what the issue is and I've not had time to investigate it
further yet, but if you type "boot" and hit enter it should boot,
sometimes you actually have to type it twice. It will boot but I'm not
sure which bits here have causes this regression.

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

[U-Boot] [PATCH 1/1] video: indicate code page of bitmap fonts

[Heinrich Schuchardt]

Add comments clarifying that the bitmap fonts support code page 437.

Signed-off-by: Heinrich Schuchardt 
---
 drivers/video/vidconsole-uclass.c | 2 +-
 include/video_font_4x6.h  | 4 ++--
 include/video_font_data.h | 2 ++
 3 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/video/vidconsole-uclass.c 
b/drivers/video/vidconsole-uclass.c
index 6f3988d49ea..5553d629b98 100644
--- a/drivers/video/vidconsole-uclass.c
+++ b/drivers/video/vidconsole-uclass.c
@@ -13,7 +13,7 @@
 #include 
 #include 
 #include 
-#include /* Get font data, width and height */
+#include /* Bitmap font for code page 437 */
 
 /*
  * Structure to describe a console color
diff --git a/include/video_font_4x6.h b/include/video_font_4x6.h
index 6aeed092ad4..64c5ed2eda4 100644
--- a/include/video_font_4x6.h
+++ b/include/video_font_4x6.h
@@ -1,5 +1,5 @@
-/* Hand composed "Minuscule" 4x6 font, with binary data generated using
- * Perl stub.
+/* Hand composed "Minuscule" 4x6 font for code page 437, with binary data
+ * generated using Perl stub.
  *
  * Use 'perl -x mini_4x6.c < mini_4x6.c > new_version.c' to regenerate
  * binary data.
diff --git a/include/video_font_data.h b/include/video_font_data.h
index 346a162f56f..d52526a63c8 100644
--- a/include/video_font_data.h
+++ b/include/video_font_data.h
@@ -3,6 +3,8 @@
  * Paolo Scaffardi, AIRVENT SAM s.p.a - RIMINI(ITALY), arse...@tin.it
  *
  * SPDX-License-Identifier:GPL-2.0+
+ *
+ * This file contains an 8x16 bitmap font for code page 437.
  */
 
 #ifndef _VIDEO_FONT_DATA_
-- 
2.16.1

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

[U-Boot] [PATCH v3 1/2] efi_loader: delete doc/README.efi

[Heinrich Schuchardt]

Delete README.efi. It is replaced by a further patch.

Signed-off-by: Heinrich Schuchardt 
---
v3
no change
v2
delete all lines instead of complete file
---
 doc/README.efi | 86 --
 1 file changed, 86 deletions(-)

diff --git a/doc/README.efi b/doc/README.efi
index 956f5bfa0c6..e69de29bb2d 100644
--- a/doc/README.efi
+++ b/doc/README.efi
@@ -1,86 +0,0 @@
-#
-# Copyright (C) 2015 Google, Inc
-#
-# SPDX-License-Identifier: GPL-2.0+
-#
-
-EFI on U-Boot
-=
-This document provides information about the implementation of the UEFI API [1]
-in U-Boot.
-
-
-=== Table of Contents ===
-
-Motivation
-How do I get it?
-Status
-Future work
-
-
-Motivation
---
-
-With this API support in place, you can run any UEFI payload (such as the Linux
-kernel, grub2 or gummiboot) on U-Boot. This dramatically simplifies boot loader
-configuration, as U-Boot based systems now look and feel (almost) the same way
-as TianoCore based systems.
-
-How do I get it?
-
-
-EFI support for 32bit ARM and AArch64 is already included in U-Boot. All you
-need to do is enable
-
-  CONFIG_CMD_BOOTEFI=y
-  CONFIG_EFI_LOADER=y
-
-in your .config file and you will automatically get a bootefi command to run
-an efi application as well as snippet in the default distro boot script that
-scans for removable media efi binaries as fallback.
-
-Status
---
-
-I am successfully able to run grub2 and Linux EFI binaries with this code on
-ARMv7 as well as AArch64 systems.
-
-When enabled, the resulting U-Boot binary only grows by ~10KB, so it's very
-light weight.
-
-All storage devices are directly accessible from the uEFI payload
-
-Removable media booting (search for /efi/boot/boota{a64,arm}.efi) is supported.
-
-Simple use cases like "Plug this SD card into my ARM device and it just
-boots into grub which boots into Linux", work very well.
-
-
-Running HelloWord.efi
--
-
-You can run a simple 'hello world' EFI program in U-Boot.
-Enable the option CONFIG_CMD_BOOTEFI_HELLO.
-
-Then you can boot into U-Boot and type:
-
-   > bootefi hello
-
-The 'hello world EFI' program will then run, print a message and exit.
-
-
-Future work

-
-Of course, there are still a few things one could do on top:
-
-   - Improve disk media detection (don't scan, use what information we
-have)
-   - Add EFI variable support using NVRAM
-   - Add GFX support
-   - Make EFI Shell work
-   - Network device support
-   - Support for payload exit
-   - Payload Watchdog support
-
-[1] http://uefi.org/
-- 
2.16.1

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

[U-Boot] [PATCH v3 2/2] efi_loader: provide new doc/README.uefi

[Heinrich Schuchardt]

Provides information about

- usage of the bootefi command
- overview of UEFI
- interaction between U-Boot and EFI drivers

Signed-off-by: Heinrich Schuchardt 
---
v3
rename README.efi to README.uefi
use UEFI instead of EFI where applicable
v2
split the patch in two: one deleteing all old lines, the other
adding the new ones
update README contents
---
 MAINTAINERS |   2 +-
 doc/README.efi  |   0
 doc/README.uefi | 332 
 3 files changed, 333 insertions(+), 1 deletion(-)
 delete mode 100644 doc/README.efi
 create mode 100644 doc/README.uefi

diff --git a/MAINTAINERS b/MAINTAINERS
index 077828cf1d4..da799b551d9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -290,7 +290,7 @@ EFI PAYLOAD
 M: Alexander Graf 
 S: Maintained
 T: git git://github.com/agraf/u-boot.git
-F: doc/README.efi
+F: doc/README.uefi
 F: doc/README.iscsi
 F: include/efi*
 F: include/pe.h
diff --git a/doc/README.efi b/doc/README.efi
deleted file mode 100644
index e69de29bb2d..000
diff --git a/doc/README.uefi b/doc/README.uefi
new file mode 100644
index 000..7403be36146
--- /dev/null
+++ b/doc/README.uefi
@@ -0,0 +1,332 @@
+
+
+# UEFI on U-Boot
+
+The Unified Extensible Firmware Interface Specification (UEFI) [1] has become
+the default for booting on AArch64 and x86 systems. It provides a stable API 
for
+the interaction of drivers and applications with the firmware. The API 
comprises
+access to block storage, network, and console to name a few. The Linux kernel
+and boot loaders like GRUB or the FreeBSD loader can be executed.
+
+## Building for UEFI
+
+The UEFI standard supports only little endian systems. The UEFI support can be
+activated for ARM and x86 by specifying
+
+CONFIG_CMD_BOOTEFI=y
+CONFIG_EFI_LOADER=y
+
+in the .config file.
+
+Support for attaching virtual block devices, e.g. iSCSI drives connected by the
+loaded UEFI application [3], requires
+
+CONFIG_BLK=y
+CONFIG_PARTITIONS=y
+
+### Executing a UEFI binary
+
+The bootefi command is used to start UEFI applications or to install UEFI
+drivers. It takes two parameters
+
+bootefi  [fdt address]
+
+* image address - the memory address of the UEFI binary
+* fdt address - the memory address of the flattened device tree
+
+Below you find the output of an example session starting GRUB.
+
+=> load mmc 0:2 ${fdt_addr_r} boot/dtb
+29830 bytes read in 14 ms (2 MiB/s)
+=> load mmc 0:1 ${kernel_addr_r} efi/debian/grubaa64.efi
+reading efi/debian/grubaa64.efi
+120832 bytes read in 7 ms (16.5 MiB/s)
+=> bootefi ${kernel_addr_r} ${fdt_addr_r}
+
+The environment variable 'bootargs' is passed as load options in the UEFI 
system
+table. The Linux kernel EFI stub uses the load options as command line
+arguments.
+
+### Executing the boot manager
+
+The UEFI specfication foresees to define boot entries and boot sequence via 
UEFI
+variables. Booting according to these variables is possible via
+
+bootefi bootmgr [fdt address]
+
+As of U-Boot v2018.03 UEFI variables are not persisted and cannot be set at
+runtime.
+
+### Executing the built in hello world application
+
+A hello world UEFI application can be built with
+
+CONFIG_CMD_BOOTEFI_HELLO_COMPILE=y
+
+It can be embedded into the U-Boot binary with
+
+CONFIG_CMD_BOOTEFI_HELLO=y
+
+The bootefi command is used to start the embedded hello world application.
+
+bootefi hello [fdt address]
+
+Below you find the output of an example session.
+
+=> bootefi hello ${fdtcontroladdr}
+## Starting EFI application at 0100 ...
+WARNING: using memory device/image path, this may confuse some payloads!
+Hello, world!
+Running on UEFI 2.7
+Have SMBIOS table
+Have device tree
+Load options: root=/dev/sdb3 init=/sbin/init rootwait ro
+## Application terminated, r = 0
+
+The environment variable fdtcontroladdr points to U-Boot's internal device tree
+(if available).
+
+### Executing the built-in selftest
+
+An UEFI selftest suite can be embedded in U-Boot by building with
+
+CONFIG_CMD_BOOTEFI_SELFTEST=y
+
+For testing the UEFI implementation the bootefi command can be used to start 
the
+selftest.
+
+bootefi selftest [fdt address]
+
+The environment variable 'efi_selftest' can be used to select a single test. If
+it is not provided all tests are executed except those marked as 'on request'.
+If the environment variable is set to 'list' a list of all tests is shown.
+
+Below you can find the output of an example session.
+
+=> setenv efi_selftest simple network protocol
+=> bootefi selftest
+Testing EFI API implementation
+Selected test: 'simple network protocol'
+Setting up 'simple network protocol'
+Setting up 'simple network protocol' succeeded
+Executing 'simple network protocol'
+DHCP Discover
+DHCP reply received from 192.168.76.2 

[U-Boot] [PATCH v3 0/2] efi_loader: provide new doc/README.efi

[Heinrich Schuchardt]

Provides information about

- usage of the bootefi command
- overview of UEFI
- interaction between U-Boot and EFI drivers

---
v3
rename README.efi to README.uefi
use UEFI instead of EFI where applicable
v2
split the patch in two: one deleteing all old lines, the other
adding the new ones
update README contents
---

Heinrich Schuchardt (2):
  efi_loader: delete doc/README.efi
  efi_loader: provide new doc/README.uefi

 doc/README.efi  |  86 ---
 doc/README.uefi | 332 
 2 files changed, 332 insertions(+), 86 deletions(-)
 delete mode 100644 doc/README.efi
 create mode 100644 doc/README.uefi

-- 
2.16.1

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

Re: [U-Boot] U-Boot

[Nicolas Ferre]

On 01/03/2018 at 20:55, Mariano Coromac wrote:
I found the problem. In my header file I was reading from eMMC device 1. 
Not 0. That's why the operations with mmc worked in command line but did 
not on startup.

Please correct me if I'm mistaken but I have a couple questions.
1) Do I need a partition in my eMMC in order to boot the Linux kernel?
When I run "mmc part" it shows no partition at all.
2) When U-Boot finishes compiling it generates a .dtb with the name of 
my custom board. I need to write this file (alongside zImage) inside my 
eMMC for my Linux Kernel to boot right?


Actually no: the .dtb from U-Boot is for U-Boot to use. For loading the 
Linux kernel, you must use the .dtb that is produced by the compilation 
of the kernel (in arch/arm/boot/dts/)




When I try to boot the kernel it hangs in here:
=> boot
reading p_a5_tab_reva.dtb
13699 bytes read in 18 ms (743.2 KiB/s)
reading zImage
3749624 bytes read in 298 ms (12 MiB/s)
## Flattened Device Tree blob at 2100
    Booting using the fdt blob at 0x2100
    Loading Device Tree to 27b7d000, end 27b83582 ... OK

Starting kernel ...

What do you think of this? Perhaps is regarding the kernel itself or 
maybe is a UBoot configuration?



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

Re: [U-Boot] [PATCH] watchdog: omap_wdt: improve watchdog reset path

[Sam Protsenko]

On 1 March 2018 at 16:33, Tom Rini  wrote:
> On Thu, Mar 01, 2018 at 04:10:44PM +0200, Ruslan Bilovol wrote:
>> Hi Lukasz,
>>
>> On Thu, Mar 1, 2018 at 12:53 PM, Lukasz Majewski  wrote:
>> > Hi Ruslan,
>> >
>> >> Remove busy looping during watchdog reset.
>> >> Each polling of W_PEND_WTGR bit ("finish posted
>> >> write") after watchdog reset takes 120-140us
>> >> on BeagleBone Black board. Current U-Boot code
>> >> has watchdog resets in random places and often
>> >> there is situation when watchdog is reset
>> >> few times in a row in nested functions.
>> >> This adds extra delays and slows the whole system.
>> >>
>> >> Instead of polling W_PEND_WTGR bit, we skip
>> >> watchdog reset if the bit is set. Anyway, watchdog
>> >> is in the middle of reset *right now*, so we can
>> >> just return.
>> >
>> > It seems like similar problem may be in the Linux kernel driver:
>> > v4.16-rc1/source/drivers/watchdog/omap_wdt.c#L74
>> >
>> > Linux driver also waits for the write.
>>
>> Right, Linux driver has similar code but it doesn't affect performance.
>> This is because of watchdog usage in Linux, it is enabled and
>> reset by userspace. This is quite rare event.
>> Moreover, since Linux has interrupts enabled and has scheduling,
>> such busy loops in the omap driver are not very different to
>> just mdelay() usage. The system can handle interrupts, and can
>> even do preemption if PREEMPT is enabled.
>> So use of such busy loops in that particular case shouldn't cause
>> any noticeable performance issues.
>
> True.  But, can you also submit a patch to the kernel side (and CC me) ?
> That's far more likely to get the attention of the engineers that might
> know of corner cases with the various SoC families where we might need
> to keep doing what we're doing or other possible problems.  Thanks!
>

Some additional input from my side.

My previous measurements were wrong, due to usage of slow USB hub port
on my laptop. Using another USB port I have next transfer speed for
"fastboot flash" operation:
 - without patch: 2.84 MiB/sec
 - with patch: 7.81  MiB/sec

So it gives us about 2.75 times improvement, as stated by Ruslan in
his commit message. Also, I tested that WDT continues to work
correctly, and it does (tried several use-cases, and also debug patch
with infinite loop). So again:

Tested-by: Sam Protsenko 

Also:

Reviewed-by: Sam Protsenko 

I checked the code and I can say that there shouldn't be any concerns
about WDT functionality with this patch. By the way, in my opinion,
for kernel this patch doesn't make much sense, and there might be even
confusion in case we send it... If there any concerns about it, we can
invite related engineers in this discussion, asking them to review
this.

Overall, I think this patch is "must have" in U-Boot, as it gives us
dramatic improvement without any drawbacks, especially for AM335x
boards. It's probably the best approach for WDT reset procedure until
interrupts are enabled for ARM architecture (if we even consider it).

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

Re: [U-Boot] [PATCH] scripts: use CROSS_COMPILE environment variable

[Stefan Agner]

Hi Lukasz,

On 02.03.2018 17:33, Lukasz Majewski wrote:
> Hi Stefan,
> 
>> From: Stefan Agner 
>>
>> Make sure we use objcopy from the cross compiler toolchain.
>>
>> Signed-off-by: Stefan Agner 
>> ---
>>  scripts/get_default_envs.sh | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/scripts/get_default_envs.sh b/scripts/get_default_envs.sh
>> index 7955db60e5..84e9f51695 100755
>> --- a/scripts/get_default_envs.sh
>> +++ b/scripts/get_default_envs.sh
>> @@ -24,7 +24,8 @@ cp ${env_obj_file_path} ${ENV_OBJ_FILE_COPY}
>>
>>  # NOTE: objcopy saves its output to file passed in
>>  # (copy_env_common.o in this case)
>> -objcopy -O binary -j ".rodata.default_environment"
>> ${ENV_OBJ_FILE_COPY} +${CROSS_COMPILE}objcopy -O binary -j
>> ".rodata.default_environment" \
>> +${ENV_OBJ_FILE_COPY}
> 
> Stefan, could you check if this is not already solved in newest
> mainline?
> 
> It seems like this is v2 or v1 of the patch. The v3 was finally pulled
> to main line:
> 
> +${OBJCOPY} -O binary -j ".rodata.default_environment"
> ${ENV_OBJ_FILE_COPY}
> 

Oh I see there is a patch on master yes.

It seems not to work here though:
$ ./scripts/get_default_envs.sh .
arm-linux-gnueabihf-objcopy:stPZVLWM: Invalid operation

Need to look closer

--
Stefan

>>
>>  # Replace default '\0' with '\n' and sort entries
>>  tr '\0' '\n' < ${ENV_OBJ_FILE_COPY} | sort -u
> 
> 
> 
> 
> 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] [linux-sunxi] Re: [PATCH v3 13/20] Revert: arm64: allwinner: a64: pine64: Use dcdc1 regulator for mmc0

[Andre Przywara]

Hi,

On 02/03/18 16:32, Vincent Legoll wrote:
> Hi,
> 
> On Fri, Mar 2, 2018 at 5:24 PM, Andre Przywara  wrote:
>> Regarding the whole forward/backward compatibility:
>> I clearly see the difficulty in coming up with a "perfect" DT from day
>> one, especially for badly documented SoCs, where mainlining is driven by
>> hobbyists. So I was wondering if we introduce a grace period, where we
>> declare the DT "unstable" or "subject to incompatible changes" for some
>> releases (not too many). In hindsight we might declare 4.12 the stable
>> DT base for the A64, for instance.
>> This would allow us to start upstreaming early, with a small feature set
>> only (just serial + clocks + pinctrl, as for the H6). Additional
>> features (PMIC) might then add small incompatibilities (like this one
>> here), until we are reasonably confident about the DT.
>> Does that sound useful?
> 
> Kind of "staging" for DT ?

Yeah, somewhat, though I would like to see this moved out of the Linux
context ;-) Actually this would also simplify collaboration with other
stakeholders (U-Boot, *BSD, Your-toy-OS), as they can participate in the
discussion without being bound to some particular release cycle or
special upstreaming process.
And ideally the DT would not be in the Linux tree in the first place, to
not give people the idea of it being a "Linux config file".

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

Re: [U-Boot] [linux-sunxi] Re: [PATCH v3 13/20] Revert: arm64: allwinner: a64: pine64: Use dcdc1 regulator for mmc0

[Vincent Legoll]

Hi,

On Fri, Mar 2, 2018 at 5:24 PM, Andre Przywara  wrote:
> Regarding the whole forward/backward compatibility:
> I clearly see the difficulty in coming up with a "perfect" DT from day
> one, especially for badly documented SoCs, where mainlining is driven by
> hobbyists. So I was wondering if we introduce a grace period, where we
> declare the DT "unstable" or "subject to incompatible changes" for some
> releases (not too many). In hindsight we might declare 4.12 the stable
> DT base for the A64, for instance.
> This would allow us to start upstreaming early, with a small feature set
> only (just serial + clocks + pinctrl, as for the H6). Additional
> features (PMIC) might then add small incompatibilities (like this one
> here), until we are reasonably confident about the DT.
> Does that sound useful?

Kind of "staging" for DT ?

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

Re: [U-Boot] [PATCH] cmd: nvedit: add whitelist option for env import

[Quentin Schulz]

Hi all,

On Thu, Jan 04, 2018 at 11:39:15AM +0100, Quentin Schulz wrote:
> While the `env export` can take as parameters variables to be exported,
> `env import` does not have such a mechanism of variable selection.
> 
> Let's add a `-w` option that asks `env import` to look for the
> `whitelisted_vars` env variable for a space-separated list of variables
> that are whitelisted.
> 
> Every env variable present in env at `addr` and in `whitelisted_vars`
> env variable will override the value of the variable in the current env.
> All the remaining variables are left untouched.
> 
> One of its use case could be to load a secure environment from the
> signed U-Boot binary and load only a handful of variables from an
> other, unsecure, environment without completely losing control of
> U-Boot.
> 
> Signed-off-by: Quentin Schulz 

It's been two months since I posted this patch and there hasn't been any
review.

Is there something to improve?
Is there an other approach to take?

I'm all ears.

Thanks,
Quentin

> ---
>  cmd/nvedit.c | 71 
> ++--
>  1 file changed, 64 insertions(+), 7 deletions(-)
> 
> diff --git a/cmd/nvedit.c b/cmd/nvedit.c
> index 4e79d03856..9f983b41a1 100644
> --- a/cmd/nvedit.c
> +++ b/cmd/nvedit.c
> @@ -971,7 +971,7 @@ sep_err:
>  
>  #ifdef CONFIG_CMD_IMPORTENV
>  /*
> - * env import [-d] [-t [-r] | -b | -c] addr [size]
> + * env import [-d] [-t [-r] | -b | -c] [-w] addr [size]
>   *   -d: delete existing environment before importing;
>   *   otherwise overwrite / append to existing definitions
>   *   -t: assume text format; either "size" must be given or the
> @@ -982,6 +982,10 @@ sep_err:
>   *   for line endings. Only effective in addition to -t.
>   *   -b: assume binary format ('\0' separated, "\0\0" terminated)
>   *   -c: assume checksum protected environment format
> + *   -w: specify that whitelisting of variables should be used when
> + *   importing environment. The space-separated list of variables
> + *   that should override the ones in current environment is stored
> + *   in `whitelisted_vars`.
>   *   addr:   memory address to read from
>   *   size:   length of input data; if missing, proper '\0'
>   *   termination is mandatory
> @@ -991,11 +995,16 @@ static int do_env_import(cmd_tbl_t *cmdtp, int flag,
>  {
>   ulong   addr;
>   char*cmd, *ptr;
> + char**array = NULL;
>   charsep = '\n';
>   int chk = 0;
>   int fmt = 0;
>   int del = 0;
>   int crlf_is_lf = 0;
> + int wl = 0;
> + int wl_count = 0;
> + int ret;
> + unsigned int i;
>   size_t  size;
>  
>   cmd = *argv;
> @@ -1026,6 +1035,9 @@ static int do_env_import(cmd_tbl_t *cmdtp, int flag,
>   case 'd':
>   del = 1;
>   break;
> + case 'w':
> + wl = 1;
> + break;
>   default:
>   return CMD_RET_USAGE;
>   }
> @@ -1082,14 +1094,59 @@ static int do_env_import(cmd_tbl_t *cmdtp, int flag,
>   ptr = (char *)ep->data;
>   }
>  
> - if (himport_r(_htab, ptr, size, sep, del ? 0 : H_NOCLEAR,
> - crlf_is_lf, 0, NULL) == 0) {
> + if(wl) {
> + char *str, *token, *tmp;
> + wl_count = 1;
> +
> + str = env_get("whitelisted_vars");
> + if (!str) {
> + puts("## Error: whitelisted_vars is not set.\n");
> + return CMD_RET_USAGE;
> + }
> +
> + tmp = malloc(sizeof(char) * (strlen(str) + 1));
> + strcpy(tmp, str);
> +
> + token = strchr(tmp, ' ');
> + while (!token) {
> + wl_count++;
> + token = strchr(token + 1, ' ');
> + }
> +
> + strcpy(tmp, str);
> +
> + array = malloc(sizeof(char *) * wl_count);
> + wl_count = 0;
> +
> + token = strtok(tmp, " ");
> + while (token) {
> + array[wl_count] = malloc(sizeof(char) *
> +  (strlen(token) + 1));
> + strcpy(array[wl_count], token);
> + wl_count++;
> + token = strtok(NULL, " ");
> + }
> +
> + free(tmp);
> + }
> +
> + ret = himport_r(_htab, ptr, size, sep, del ? 0 : H_NOCLEAR,
> + crlf_is_lf, wl ? wl_count : 0, wl ? array : NULL);
> + if (!ret) {
>   pr_err("Environment import failed: errno = %d\n", errno);
> - return 1;
> + ret = 1;
> + } else {
> + gd->flags |= GD_FLG_ENV_READY;
> + ret = 0;

Re: [U-Boot] [PATCH] scripts: use CROSS_COMPILE environment variable

[Lukasz Majewski]

Hi Stefan,

> From: Stefan Agner 
> 
> Make sure we use objcopy from the cross compiler toolchain.
> 
> Signed-off-by: Stefan Agner 
> ---
>  scripts/get_default_envs.sh | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/scripts/get_default_envs.sh b/scripts/get_default_envs.sh
> index 7955db60e5..84e9f51695 100755
> --- a/scripts/get_default_envs.sh
> +++ b/scripts/get_default_envs.sh
> @@ -24,7 +24,8 @@ cp ${env_obj_file_path} ${ENV_OBJ_FILE_COPY}
>  
>  # NOTE: objcopy saves its output to file passed in
>  # (copy_env_common.o in this case)
> -objcopy -O binary -j ".rodata.default_environment"
> ${ENV_OBJ_FILE_COPY} +${CROSS_COMPILE}objcopy -O binary -j
> ".rodata.default_environment" \
> + ${ENV_OBJ_FILE_COPY}

Stefan, could you check if this is not already solved in newest
mainline?

It seems like this is v2 or v1 of the patch. The v3 was finally pulled
to main line:

+${OBJCOPY} -O binary -j ".rodata.default_environment"
${ENV_OBJ_FILE_COPY}

>  
>  # Replace default '\0' with '\n' and sort entries
>  tr '\0' '\n' < ${ENV_OBJ_FILE_COPY} | sort -u




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


pgp49E94mfqwl.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] scripts: use CROSS_COMPILE environment variable

[Stefan Agner]

From: Stefan Agner 

Make sure we use objcopy from the cross compiler toolchain.

Signed-off-by: Stefan Agner 
---
 scripts/get_default_envs.sh | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/scripts/get_default_envs.sh b/scripts/get_default_envs.sh
index 7955db60e5..84e9f51695 100755
--- a/scripts/get_default_envs.sh
+++ b/scripts/get_default_envs.sh
@@ -24,7 +24,8 @@ cp ${env_obj_file_path} ${ENV_OBJ_FILE_COPY}
 
 # NOTE: objcopy saves its output to file passed in
 # (copy_env_common.o in this case)
-objcopy -O binary -j ".rodata.default_environment" ${ENV_OBJ_FILE_COPY}
+${CROSS_COMPILE}objcopy -O binary -j ".rodata.default_environment" \
+   ${ENV_OBJ_FILE_COPY}
 
 # Replace default '\0' with '\n' and sort entries
 tr '\0' '\n' < ${ENV_OBJ_FILE_COPY} | sort -u
-- 
2.16.2

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

Re: [U-Boot] [PATCH v3 13/20] Revert: arm64: allwinner: a64: pine64: Use dcdc1 regulator for mmc0

[Andre Przywara]

Hi,

On 02/03/18 15:58, Maxime Ripard wrote:
> On Fri, Mar 02, 2018 at 12:56:52AM +, Andre Przywara wrote:
>> Linux kernels before 4.12-rc1 don't know about the AXP803 PMIC, so can't
>> enable the MMC driver with the current DT anymore, because that now
>> depends on this regulator.
> 
> Given that only I2C, USB and MMC were supported at the time, is it
> really worth it? There's a lot of incentive to move to a newer kernel
> given the minimal support it had at the time.

Yeah, this is somewhat true, although serial, USB and MMC are somewhat
enough if one uses a USB Ethernet or WiFi adapter. And the kernel choice
might not always a decision of the user (thinking of distributions here).
But I was actually unsure about this as well, and wanted to hear some
opinions.

One thing that comes to mind is other OSes. Does anyone know how if for
instance FreeBSD supports the AXP and its Linux bindings? The whole goal
of this series is to allow booting OSes with U-Boot's DT copy
($fdtcontroladdr), so if this patch would make their life easier, it
might be worth it.

Regarding the whole forward/backward compatibility:
I clearly see the difficulty in coming up with a "perfect" DT from day
one, especially for badly documented SoCs, where mainlining is driven by
hobbyists. So I was wondering if we introduce a grace period, where we
declare the DT "unstable" or "subject to incompatible changes" for some
releases (not too many). In hindsight we might declare 4.12 the stable
DT base for the A64, for instance.
This would allow us to start upstreaming early, with a small feature set
only (just serial + clocks + pinctrl, as for the H6). Additional
features (PMIC) might then add small incompatibilities (like this one
here), until we are reasonably confident about the DT.
Does that sound useful?

So I am not insisting on this patch, but wanted to point out the
problems that those seemingly innocent DT changes create and would be
happy if we can at least try to avoid them in the future.

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

Re: [U-Boot] [PATCH v3 09/20] sunxi: disable direct MMC environment for 64 bit boards

[Andre Przywara]

Hi,

On 02/03/18 15:56, Maxime Ripard wrote:
> Hi,
> 
> On Fri, Mar 02, 2018 at 12:56:48AM +, Andre Przywara wrote:
>> Since the dawn of time for the Allwinner support in mainline U-Boot
>> we store the environment to the SD card and write directly at
>> 544KB from the beginning of the device. This leads to problems when
>> the U-Boot proper image grows beyond 504KB and eventually overlaps.
>> With one release of having the environment preferably in a FAT
>> partition, let's now turn off the MMC variant fallback, so we get back
>> all the space we need to implement features.
>> In case someone desperately needs to turn direct MMC environment back
>> on, let's move that to 896KB (128K below 1MB), so that we won't be
>> easily limited anymore.
>>
>> Signed-off-by: Andre Przywara 
>> ---
>>  env/Kconfig| 5 +++--
>>  include/configs/sunxi-common.h | 2 +-
>>  2 files changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/env/Kconfig b/env/Kconfig
>> index a3c6298273..b404855542 100644
>> --- a/env/Kconfig
>> +++ b/env/Kconfig
>> @@ -152,7 +152,7 @@ config ENV_IS_IN_MMC
>>  bool "Environment in an MMC device"
>>  depends on !CHAIN_OF_TRUST
>>  depends on MMC
>> -default y if ARCH_SUNXI
>> +default y if ARCH_SUNXI && !ARM64
> 
> I'd go even further and remove it for everyone.

Fine, if you say so!

> 
>>  default y if ARCH_EXYNOS4
>>  default y if MX6SX || MX7D
>>  default y if TEGRA30 || TEGRA124
>> @@ -443,7 +443,8 @@ config ENV_OFFSET
>>  hex "Environment Offset"
>>  depends on !ENV_IS_IN_UBI
>>  depends on !ENV_IS_NOWHERE
>> -default 0x88000 if ARCH_SUNXI
>> +default 0x88000 if ARCH_SUNXI && !ARM64
>> +default 0xe if ARCH_SUNXI && ARM64
> 
> However, I'm not sure why that would be needed. I would rather keep
> the old value to have an easy fallback to the old environment, given
> that you disable a few things afterwards.

Yeah, fair enough. Wasn't so sure about it anyway.

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

Re: [U-Boot] [PATCH v3 00/20] sunxi: sync H3, H5, A64 DTs from mainline Linux

[Maxime Ripard]

On Fri, Mar 02, 2018 at 12:56:39AM +, Andre Przywara wrote:
> This is an extended version of the EMAC DT binding update, this time
> including the full Linux DTs for all H3, H5 and A64 boards.
> Patch 01 should be merged *now*, to leave some hint in the README for
> the v2018.03 release. Without building ARM Trusted Firmware with DEBUG=0
> many H5 boards and the Pine64 can't be built successfully at the moment.
> 
> The old v2 EMAC DT update series is in patches 02-08, it prepares U-Boot's
> EMAC driver for using the new DT binding used in Linux, also updates
> the DTs to the new EMAC DT node already.
> 
> This time I added patches to sync the whole U-Boot DT files for the
> mentioned SoCs with those from Linux. However this first requires lifting
> the space limit we currently have due to the raw MMC environment.
> Patch 09 disables that for 64 bit sunxi boards, to give us finally some
> space. Patch 10 consequently reverts the disabling of features we saw a
> few weeks ago to migitate the size problem.
> 
> Patches 11-20 then brings in the Linux DTs, split by SoCs, with the .dtsi
> files first, then the board files.
> 
> Merging the H3 and H5 device tree files brings in significant changes,
> also to the structure of the .dtsi files. However U-Boot's own DT usage
> is pretty limited, so it doesn't matter.
> 
> The huge benefit of syncing the DTs is that we can use U-Boot's DT copy
> to directly pass it to the kernel, avoiding to actually load a .dtb file
> from somewhere. To allows seamless and automatic UEFI booting, so
> distribution installer images should just work (TM).
> 
> As a goodie the final patch brings in the actual SoPine + baseboard DT
> files, which we were completely missing so far.
> 
> Please let me know if that looks good. I am happy to rearrange or squash
> patches, but I tried to avoid huge commits, for the sake of reviewability.

Apart from the comments on the two patches I already sent,
Acked-by: Maxime Ripard 

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


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

Re: [U-Boot] [PATCH v3 13/20] Revert: arm64: allwinner: a64: pine64: Use dcdc1 regulator for mmc0

[Maxime Ripard]

On Fri, Mar 02, 2018 at 12:56:52AM +, Andre Przywara wrote:
> Linux kernels before 4.12-rc1 don't know about the AXP803 PMIC, so can't
> enable the MMC driver with the current DT anymore, because that now
> depends on this regulator.

Given that only I2C, USB and MMC were supported at the time, is it
really worth it? There's a lot of incentive to move to a newer kernel
given the minimal support it had at the time.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


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

Re: [U-Boot] [PATCH v3 09/20] sunxi: disable direct MMC environment for 64 bit boards

[Maxime Ripard]

Hi,

On Fri, Mar 02, 2018 at 12:56:48AM +, Andre Przywara wrote:
> Since the dawn of time for the Allwinner support in mainline U-Boot
> we store the environment to the SD card and write directly at
> 544KB from the beginning of the device. This leads to problems when
> the U-Boot proper image grows beyond 504KB and eventually overlaps.
> With one release of having the environment preferably in a FAT
> partition, let's now turn off the MMC variant fallback, so we get back
> all the space we need to implement features.
> In case someone desperately needs to turn direct MMC environment back
> on, let's move that to 896KB (128K below 1MB), so that we won't be
> easily limited anymore.
> 
> Signed-off-by: Andre Przywara 
> ---
>  env/Kconfig| 5 +++--
>  include/configs/sunxi-common.h | 2 +-
>  2 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/env/Kconfig b/env/Kconfig
> index a3c6298273..b404855542 100644
> --- a/env/Kconfig
> +++ b/env/Kconfig
> @@ -152,7 +152,7 @@ config ENV_IS_IN_MMC
>   bool "Environment in an MMC device"
>   depends on !CHAIN_OF_TRUST
>   depends on MMC
> - default y if ARCH_SUNXI
> + default y if ARCH_SUNXI && !ARM64

I'd go even further and remove it for everyone.

>   default y if ARCH_EXYNOS4
>   default y if MX6SX || MX7D
>   default y if TEGRA30 || TEGRA124
> @@ -443,7 +443,8 @@ config ENV_OFFSET
>   hex "Environment Offset"
>   depends on !ENV_IS_IN_UBI
>   depends on !ENV_IS_NOWHERE
> - default 0x88000 if ARCH_SUNXI
> + default 0x88000 if ARCH_SUNXI && !ARM64
> + default 0xe if ARCH_SUNXI && ARM64

However, I'm not sure why that would be needed. I would rather keep
the old value to have an easy fallback to the old environment, given
that you disable a few things afterwards.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


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

Re: [U-Boot] U-Boot

[Lothar Waßmann]

Hi,

On Thu, 1 Mar 2018 13:55:19 -0600 Mariano Coromac wrote:
> I found the problem. In my header file I was reading from eMMC device 1.
> Not 0. That's why the operations with mmc worked in command line but did
> not on startup.
> Please correct me if I'm mistaken but I have a couple questions.
> 1) Do I need a partition in my eMMC in order to boot the Linux kernel?
> When I run "mmc part" it shows no partition at all.
> 2) When U-Boot finishes compiling it generates a .dtb with the name of my
> custom board. I need to write this file (alongside zImage) inside my eMMC
> for my Linux Kernel to boot right?
> When I try to boot the kernel it hangs in here:
> => boot
> reading p_a5_tab_reva.dtb
> 13699 bytes read in 18 ms (743.2 KiB/s)
> reading zImage
> 3749624 bytes read in 298 ms (12 MiB/s)
> ## Flattened Device Tree blob at 2100
>Booting using the fdt blob at 0x2100
>Loading Device Tree to 27b7d000, end 27b83582 ... OK
> 
> Starting kernel ...
> 
> What do you think of this? Perhaps is regarding the kernel itself or maybe
> is a UBoot configuration?
>
My guess is that the fdt is out of reach for the kernel.
Try setting the fdt_high variable to limit the range where U-Boot will
copy the fdt.
fdt_high= will prevent copying the fdt at all, other values
specify the upper limit for the memory address where the fdt will end
after copying.


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

[U-Boot] [PATCH v2 05/10] video: add MIPI DSI host controller bridge

[yannick fertre]

Add a Synopsys Designware MIPI DSI host bridge driver, based on the
Rockchip version from rockchip/dw-mipi-dsi.c with phy & bridge APIs.

Signed-off-by: yannick fertre 
---
 drivers/video/Kconfig   |   9 +
 drivers/video/Makefile  |   1 +
 drivers/video/dw_mipi_dsi.c | 822 
 include/dw_mipi_dsi.h   |  32 ++
 4 files changed, 864 insertions(+)
 create mode 100644 drivers/video/dw_mipi_dsi.c
 create mode 100644 include/dw_mipi_dsi.h

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index b5fc535..0f641d7 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -657,6 +657,15 @@ config VIDEO_DW_HDMI
  rather requires a SoC-specific glue driver to call it), it
  can not be enabled from the configuration menu.
 
+config VIDEO_DW_MIPI_DSI
+   bool
+   help
+ Enables the common driver code for the Designware MIPI DSI
+ block found in SoCs from various vendors.
+ As this does not provide any functionality by itself (but
+ rather requires a SoC-specific glue driver to call it), it
+ can not be enabled from the configuration menu.
+
 config VIDEO_SIMPLE
bool "Simple display driver for preconfigured display"
help
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 65002af..50be569 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -53,6 +53,7 @@ obj-$(CONFIG_FORMIKE) += formike.o
 obj-$(CONFIG_LG4573) += lg4573.o
 obj-$(CONFIG_AM335X_LCD) += am335x-fb.o
 obj-$(CONFIG_VIDEO_DW_HDMI) += dw_hdmi.o
+obj-$(CONFIG_VIDEO_DW_MIPI_DSI) += dw_mipi_dsi.o
 obj-${CONFIG_VIDEO_MIPI_DSI} += mipi_display.o
 obj-$(CONFIG_VIDEO_SIMPLE) += simplefb.o
 obj-${CONFIG_VIDEO_TEGRA124} += tegra124/
diff --git a/drivers/video/dw_mipi_dsi.c b/drivers/video/dw_mipi_dsi.c
new file mode 100644
index 000..d7bd92d
--- /dev/null
+++ b/drivers/video/dw_mipi_dsi.c
@@ -0,0 +1,822 @@
+/*
+ * Copyright (C) 2016, Fuzhou Rockchip Electronics Co., Ltd
+ * Copyright (C) 2018, STMicroelectronics - All Rights Reserved
+ * Author(s): Philippe Cornu  for STMicroelectronics.
+ *   Yannick Fertre  for STMicroelectronics.
+ *
+ * Modified by Yannick Fertre 
+ * This generic Synopsys DesignWare MIPI DSI host driver is based on the
+ * bridge synopsys from drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c (kernel
+ * linux).
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define HWVER_131  0x31333100  /* IP version 1.31 */
+
+#define DSI_VERSION0x00
+#define VERSIONGENMASK(31, 8)
+
+#define DSI_PWR_UP 0x04
+#define RESET  0
+#define POWERUPBIT(0)
+
+#define DSI_CLKMGR_CFG 0x08
+#define TO_CLK_DIVISION(div)   (((div) & 0xff) << 8)
+#define TX_ESC_CLK_DIVISION(div)   ((div) & 0xff)
+
+#define DSI_DPI_VCID   0x0c
+#define DPI_VCID(vcid) ((vcid) & 0x3)
+
+#define DSI_DPI_COLOR_CODING   0x10
+#define LOOSELY18_EN   BIT(8)
+#define DPI_COLOR_CODING_16BIT_1   0x0
+#define DPI_COLOR_CODING_16BIT_2   0x1
+#define DPI_COLOR_CODING_16BIT_3   0x2
+#define DPI_COLOR_CODING_18BIT_1   0x3
+#define DPI_COLOR_CODING_18BIT_2   0x4
+#define DPI_COLOR_CODING_24BIT 0x5
+
+#define DSI_DPI_CFG_POL0x14
+#define COLORM_ACTIVE_LOW  BIT(4)
+#define SHUTD_ACTIVE_LOW   BIT(3)
+#define HSYNC_ACTIVE_LOW   BIT(2)
+#define VSYNC_ACTIVE_LOW   BIT(1)
+#define DATAEN_ACTIVE_LOW  BIT(0)
+
+#define DSI_DPI_LP_CMD_TIM 0x18
+#define OUTVACT_LPCMD_TIME(p)  (((p) & 0xff) << 16)
+#define INVACT_LPCMD_TIME(p)   ((p) & 0xff)
+
+#define DSI_DBI_VCID   0x1c
+#define DSI_DBI_CFG0x20
+#define DSI_DBI_PARTITIONING_EN0x24
+#define DSI_DBI_CMDSIZE0x28
+
+#define DSI_PCKHDL_CFG 0x2c
+#define CRC_RX_EN  BIT(4)
+#define ECC_RX_EN  BIT(3)
+#define BTA_EN BIT(2)
+#define EOTP_RX_EN BIT(1)
+#define EOTP_TX_EN BIT(0)
+
+#define DSI_GEN_VCID   0x30
+
+#define DSI_MODE_CFG   0x34
+#define ENABLE_VIDEO_MODE  0
+#define ENABLE_CMD_MODEBIT(0)
+
+#define DSI_VID_MODE_CFG   0x38
+#define ENABLE_LOW_POWER   (0x3f << 8)
+#define ENABLE_LOW_POWER_MASK  (0x3f << 8)
+#define VID_MODE_TYPE_NON_BURST_SYNC_PULSES0x0
+#define VID_MODE_TYPE_NON_BURST_SYNC_EVENTS0x1
+#define 

[U-Boot] [PATCH v2 07/10] video: add support of panel rm68200

[yannick fertre]

Support for Raydium rm68200 720p dsi 2dl video mode panel.

Signed-off-by: yannick fertre 
---
 drivers/video/Kconfig   |   8 +
 drivers/video/Makefile  |   1 +
 drivers/video/raydium-rm68200.c | 329 
 3 files changed, 338 insertions(+)
 create mode 100644 drivers/video/raydium-rm68200.c

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 0f641d7..2561c59 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -328,6 +328,14 @@ config VIDEO_LCD_ORISETECH_OTM8009A
---help---
Support for Orise Tech otm8009a 480p dsi 2dl video mode panel.
 
+config VIDEO_LCD_RAYDIUM_RM68200
+   bool "RM68200 DSI LCD panel support"
+   depends on DM_VIDEO
+   select VIDEO_MIPI_DSI
+   default n
+   ---help---
+   Support for Raydium rm68200 720x1280 dsi 2dl video mode panel.
+
 config VIDEO_LCD_SSD2828
bool "SSD2828 bridge chip"
default n
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 50be569..1a6c8d3 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -38,6 +38,7 @@ obj-$(CONFIG_VIDEO_DA8XX) += da8xx-fb.o videomodes.o
 obj-$(CONFIG_VIDEO_LCD_ANX9804) += anx9804.o
 obj-$(CONFIG_VIDEO_LCD_HITACHI_TX18D42VM) += hitachi_tx18d42vm_lcd.o
 obj-$(CONFIG_VIDEO_LCD_ORISETECH_OTM8009A) += orisetech_otm8009a.o
+obj-$(CONFIG_VIDEO_LCD_RAYDIUM_RM68200) += raydium-rm68200.o
 obj-$(CONFIG_VIDEO_LCD_SSD2828) += ssd2828.o
 obj-$(CONFIG_VIDEO_MB862xx) += mb862xx.o videomodes.o
 obj-$(CONFIG_VIDEO_MX3) += mx3fb.o videomodes.o
diff --git a/drivers/video/raydium-rm68200.c b/drivers/video/raydium-rm68200.c
new file mode 100644
index 000..46afb58
--- /dev/null
+++ b/drivers/video/raydium-rm68200.c
@@ -0,0 +1,329 @@
+/*
+ * Copyright (C) 2018 STMicroelectronics - All Rights Reserved
+ * Author(s): Yannick Fertre  for STMicroelectronics.
+ *   Philippe Cornu  for STMicroelectronics.
+ *
+ * This rm68200 panel driver is based on the panel driver from
+ * drivers/gpu/drm/panel/panel-raydium-rm68200.c (kernel linux)
+ *
+ * SPDX-License-Identifier: GPL-2.0
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define DRV_NAME "raydium_rm68200"
+
+/*** Manufacturer Command Set ***/
+#define MCS_CMD_MODE_SW0xFE /* CMD Mode Switch */
+#define MCS_CMD1_UCS   0x00 /* User Command Set (UCS = CMD1) */
+#define MCS_CMD2_P00x01 /* Manufacture Command Set Page0 (CMD2 P0) */
+#define MCS_CMD2_P10x02 /* Manufacture Command Set Page1 (CMD2 P1) */
+#define MCS_CMD2_P20x03 /* Manufacture Command Set Page2 (CMD2 P2) */
+#define MCS_CMD2_P30x04 /* Manufacture Command Set Page3 (CMD2 P3) */
+
+/* CMD2 P0 commands (Display Options and Power) */
+#define MCS_STBCTR 0x12 /* TE1 Output Setting Zig-Zag Connection */
+#define MCS_SGOPCTR0x16 /* Source Bias Current */
+#define MCS_SDCTR  0x1A /* Source Output Delay Time */
+#define MCS_INVCTR 0x1B /* Inversion Type */
+#define MCS_EXT_PWR_IC 0x24 /* External PWR IC Control */
+#define MCS_SETAVDD0x27 /* PFM Control for AVDD Output */
+#define MCS_SETAVEE0x29 /* PFM Control for AVEE Output */
+#define MCS_BT2CTR 0x2B /* DDVDL Charge Pump Control */
+#define MCS_BT3CTR 0x2F /* VGH Charge Pump Control */
+#define MCS_BT4CTR 0x34 /* VGL Charge Pump Control */
+#define MCS_VCMCTR 0x46 /* VCOM Output Level Control */
+#define MCS_SETVGN 0x52 /* VG M/S N Control */
+#define MCS_SETVGP 0x54 /* VG M/S P Control */
+#define MCS_SW_CTRL0x5F /* Interface Control for PFM and MIPI */
+
+/* CMD2 P2 commands (GOA Timing Control) - no description in datasheet */
+#define GOA_VSTV1  0x00
+#define GOA_VSTV2  0x07
+#define GOA_VCLK1  0x0E
+#define GOA_VCLK2  0x17
+#define GOA_VCLK_OPT1  0x20
+#define GOA_BICLK1 0x2A
+#define GOA_BICLK2 0x37
+#define GOA_BICLK3 0x44
+#define GOA_BICLK4 0x4F
+#define GOA_BICLK_OPT1 0x5B
+#define GOA_BICLK_OPT2 0x60
+#define MCS_GOA_GPO1   0x6D
+#define MCS_GOA_GPO2   0x71
+#define MCS_GOA_EQ 0x74
+#define MCS_GOA_CLK_GALLON 0x7C
+#define MCS_GOA_FS_SEL00x7E
+#define MCS_GOA_FS_SEL10x87
+#define MCS_GOA_FS_SEL20x91
+#define MCS_GOA_FS_SEL30x9B
+#define MCS_GOA_BS_SEL00xAC
+#define MCS_GOA_BS_SEL10xB5
+#define MCS_GOA_BS_SEL20xBF
+#define MCS_GOA_BS_SEL30xC9
+#define MCS_GOA_BS_SEL40xD3
+
+/* CMD2 P3 commands (Gamma) */
+#define MCS_GAMMA_VP   0x60 /* Gamma VP1~VP16 */
+#define MCS_GAMMA_VN   0x70 /* Gamma VN1~VN16 */
+
+struct rm68200_panel_priv {
+   struct udevice *reg;
+   struct udevice *backlight;
+   struct gpio_desc reset;
+};
+
+static void rm68200_dcs_write_buf(struct udevice *dev, const void *data,
+ size_t len)
+{
+   struct mipi_dsi_panel_plat *plat = 

[U-Boot] [PATCH v2 02/10] video: stm32: stm32_ltdc: update debug log

[yannick fertre]

Replace  macro debug by pr_error, pr_warn or pr_info.

Signed-off-by: yannick fertre 
---
 drivers/video/stm32/stm32_ltdc.c | 62 
 1 file changed, 31 insertions(+), 31 deletions(-)

diff --git a/drivers/video/stm32/stm32_ltdc.c b/drivers/video/stm32/stm32_ltdc.c
index bd9c0de..e95f35c 100644
--- a/drivers/video/stm32/stm32_ltdc.c
+++ b/drivers/video/stm32/stm32_ltdc.c
@@ -176,13 +176,13 @@ static u32 stm32_ltdc_get_pixel_format(enum 
video_log2_bpp l2bpp)
case VIDEO_BPP2:
case VIDEO_BPP4:
default:
-   debug("%s: warning %dbpp not supported yet, %dbpp instead\n",
- __func__, VNBITS(l2bpp), VNBITS(VIDEO_BPP16));
+   pr_warn("%s: warning %dbpp not supported yet, %dbpp instead\n",
+   __func__, VNBITS(l2bpp), VNBITS(VIDEO_BPP16));
pf = PF_RGB565;
break;
}
 
-   debug("%s: %d bpp -> ltdc pf %d\n", __func__, VNBITS(l2bpp), pf);
+   pr_info("%s: %d bpp -> ltdc pf %d\n", __func__, VNBITS(l2bpp), pf);
 
return (u32)pf;
 }
@@ -249,7 +249,7 @@ static void stm32_ltdc_set_mode(struct stm32_ltdc_priv 
*priv,
 
/* Signal polarities */
val = 0;
-   debug("%s: timing->flags 0x%08x\n", __func__, timings->flags);
+   pr_info("%s: timing->flags 0x%08x\n", __func__, timings->flags);
if (timings->flags & DISPLAY_FLAGS_HSYNC_HIGH)
val |= GCR_HSPOL;
if (timings->flags & DISPLAY_FLAGS_VSYNC_HIGH)
@@ -343,26 +343,26 @@ static int stm32_ltdc_probe(struct udevice *dev)
 
priv->regs = (void *)dev_read_addr(dev);
if ((fdt_addr_t)priv->regs == FDT_ADDR_T_NONE) {
-   debug("%s: ltdc dt register address error\n", __func__);
+   pr_err("%s: ltdc dt register address error\n", __func__);
return -EINVAL;
}
 
ret = clk_get_by_index(dev, 0, );
if (ret) {
-   debug("%s: peripheral clock get error %d\n", __func__, ret);
+   pr_err("%s: peripheral clock get error %d\n", __func__, ret);
return ret;
}
 
ret = clk_enable();
if (ret) {
-   debug("%s: peripheral clock enable error %d\n",
- __func__, ret);
+   pr_err("%s: peripheral clock enable error %d\n",
+  __func__, ret);
return ret;
}
 
ret = reset_get_by_index(dev, 0, );
if (ret) {
-   debug("%s: missing ltdc hardware reset\n", __func__);
+   pr_err("%s: missing ltdc hardware reset\n", __func__);
return -ENODEV;
}
 
@@ -372,41 +372,40 @@ static int stm32_ltdc_probe(struct udevice *dev)
 #ifdef CONFIG_VIDEO_BRIDGE
ret = uclass_get_device(UCLASS_VIDEO_BRIDGE, 0, );
if (ret) {
-   debug("%s: No video bridge, or no backlight on bridge\n",
- __func__);
+   pr_info("%s: No video bridge, or no backlight on bridge\n",
+   __func__);
}
 
if (bridge) {
ret = video_bridge_attach(bridge);
if (ret) {
-   debug("%s: fail to attach bridge\n", __func__);
+   pr_err("%s: fail to attach bridge\n", __func__);
return ret;
}
}
 #endif
ret = uclass_first_device(UCLASS_PANEL, );
if (ret) {
-   debug("%s: panel device error %d\n", __func__, ret);
+   pr_err("%s: panel device error %d\n", __func__, ret);
return ret;
}
 
ret = fdtdec_decode_display_timing(gd->fdt_blob, dev_of_offset(panel),
   0, );
if (ret) {
-   debug("%s: decode display timing error %d\n",
- __func__, ret);
+   pr_err("%s: decode display timing error %d\n", __func__, ret);
return ret;
}
 
rate = clk_set_rate(, timings.pixelclock.typ);
if (rate < 0) {
-   debug("%s: fail to set pixel clock %d hz %d hz\n",
- __func__, timings.pixelclock.typ, rate);
+   pr_err("%s: fail to set pixel clock %d hz %d hz\n",
+  __func__, timings.pixelclock.typ, rate);
return rate;
}
 
-   debug("%s: Set pixel clock req %d hz get %d hz\n", __func__,
- timings.pixelclock.typ, rate);
+   pr_info("%s: Set pixel clock req %d hz get %d hz\n", __func__,
+   timings.pixelclock.typ, rate);
 
/* TODO Below parameters are hard-coded for the moment... */
priv->l2bpp = VIDEO_BPP16;
@@ -417,12 +416,12 @@ static int stm32_ltdc_probe(struct udevice *dev)
priv->crop_h = timings.vactive.typ;
priv->alpha = 0xFF;
 
-   debug("%s: %dx%d %dbpp frame buffer at 0x%lx\n", __func__,
-

[U-Boot] [PATCH v2 09/10] arm: dts: stm32: add display for STM32F769 disco board

[yannick fertre]

Enable the display controller, mipi dsi bridge & panel.
Set panel display timings.

Signed-off-by: yannick fertre 
---
 arch/arm/dts/stm32f769-disco.dts | 71 
 1 file changed, 71 insertions(+)

diff --git a/arch/arm/dts/stm32f769-disco.dts b/arch/arm/dts/stm32f769-disco.dts
index 59c9d31..82985b9 100644
--- a/arch/arm/dts/stm32f769-disco.dts
+++ b/arch/arm/dts/stm32f769-disco.dts
@@ -42,6 +42,7 @@
 
 /dts-v1/;
 #include "stm32f746.dtsi"
+#include 
 #include 
 
 / {
@@ -264,3 +265,73 @@
bus-width = <4>;
max-frequency = <2500>;
 };
+
+ {
+   status = "okay";
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ltdc_out_dsi: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_in>;
+   };
+   };
+};
+
+ {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "okay";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   dsi_in: endpoint {
+   remote-endpoint = <_out_dsi>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+   dsi_out: endpoint {
+   remote-endpoint = <_panel_in>;
+   };
+   };
+   };
+
+   panel-dsi@0 {
+   compatible = "orisetech,otm8009a";
+   reg = <0>; /* dsi virtual channel (0..3) */
+   reset-gpios = < 15 GPIO_ACTIVE_LOW>;
+   status = "okay";
+
+   port {
+   dsi_panel_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   display-timings {
+   timing@0 {
+   clock-frequency = <32729000>;
+   hactive = <480>;
+   hfront-porch = <120>;
+   hback-porch = <63>;
+   hsync-len = <120>;
+   vactive = <800>;
+   vfront-porch = <12>;
+   vback-porch = <12>;
+   vsync-len = <12>;
+   hsync-active = <0>;
+   vsync-active = <0>;
+   de-active = <0>;
+   pixelclk-active = <1>;
+   };
+   };
+   };
+};
-- 
1.9.1

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

[U-Boot] [PATCH v2 06/10] video: add support of STM32 MIPI DSI controller driver

[yannick fertre]

Add the STM32 DSI controller driver that uses the Synopsys DesignWare
MIPI DSI host controller bridge.

Signed-off-by: yannick fertre 
---
 drivers/video/stm32/Kconfig |  10 +
 drivers/video/stm32/Makefile|   1 +
 drivers/video/stm32/stm32_dsi.c | 427 
 3 files changed, 438 insertions(+)
 create mode 100644 drivers/video/stm32/stm32_dsi.c

diff --git a/drivers/video/stm32/Kconfig b/drivers/video/stm32/Kconfig
index 113a2bb..2ea6f18 100644
--- a/drivers/video/stm32/Kconfig
+++ b/drivers/video/stm32/Kconfig
@@ -15,6 +15,16 @@ menuconfig VIDEO_STM32
  DSI. This option enables these supports which can be used on
  devices which have RGB TFT or DSI display connected.
 
+config VIDEO_STM32_DSI
+   bool "Enable STM32 DSI video support"
+   depends on VIDEO_STM32
+   select VIDEO_MIPI_DSI
+   select VIDEO_BRIDGE
+   select VIDEO_DW_MIPI_DSI
+   help
+ This option enables support DSI internal bridge which can be used on
+ devices which have DSI display connected.
+
 config VIDEO_STM32_MAX_XRES
int "Maximum horizontal resolution (for memory allocation purposes)"
depends on VIDEO_STM32
diff --git a/drivers/video/stm32/Makefile b/drivers/video/stm32/Makefile
index 372a2e1..f8c3ff7 100644
--- a/drivers/video/stm32/Makefile
+++ b/drivers/video/stm32/Makefile
@@ -8,3 +8,4 @@
 #
 
 obj-${CONFIG_VIDEO_STM32} = stm32_ltdc.o
+obj-${CONFIG_VIDEO_STM32_DSI} += stm32_dsi.o
diff --git a/drivers/video/stm32/stm32_dsi.c b/drivers/video/stm32/stm32_dsi.c
new file mode 100644
index 000..3e26433
--- /dev/null
+++ b/drivers/video/stm32/stm32_dsi.c
@@ -0,0 +1,427 @@
+/*
+ * Copyright (C) 2018 STMicroelectronics - All Rights Reserved
+ * Author(s): Philippe Cornu  for STMicroelectronics.
+ *   Yannick Fertre  for STMicroelectronics.
+ *
+ * This driver is based on the mipi dsi driver from
+ * drivers/gpu/drm/stm/dw_mipi_dsi-stm.c (kernel linux).
+ *
+ * SPDX-License-Identifier: GPL-2.0
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define HWVER_130  0x31333000  /* IP version 1.30 */
+#define HWVER_131  0x31333100  /* IP version 1.31 */
+
+/* DSI digital registers & bit definitions */
+#define DSI_VERSION0x00
+#define VERSIONGENMASK(31, 8)
+
+/*
+ * DSI wrapper registers & bit definitions
+ * Note: registers are named as in the Reference Manual
+ */
+#define DSI_WCFGR  0x0400  /* Wrapper ConFiGuration Reg */
+#define WCFGR_DSIM BIT(0)  /* DSI Mode */
+#define WCFGR_COLMUX   GENMASK(3, 1)   /* COLor MUltipleXing */
+
+#define DSI_WCR0x0404  /* Wrapper Control Reg */
+#define WCR_DSIEN  BIT(3)  /* DSI ENable */
+
+#define DSI_WISR   0x040C  /* Wrapper Interrupt and Status Reg */
+#define WISR_PLLLS BIT(8)  /* PLL Lock Status */
+#define WISR_RRS   BIT(12) /* Regulator Ready Status */
+
+#define DSI_WPCR0  0x0418  /* Wrapper Phy Conf Reg 0 */
+#define WPCR0_UIX4 GENMASK(5, 0)   /* Unit Interval X 4 */
+#define WPCR0_TDDL BIT(16) /* Turn Disable Data Lanes */
+
+#define DSI_WRPCR  0x0430  /* Wrapper Regulator & Pll Ctrl Reg */
+#define WRPCR_PLLENBIT(0)  /* PLL ENable */
+#define WRPCR_NDIV GENMASK(8, 2)   /* pll loop DIVision Factor */
+#define WRPCR_IDF  GENMASK(14, 11) /* pll Input Division Factor */
+#define WRPCR_ODF  GENMASK(17, 16) /* pll Output Division Factor */
+#define WRPCR_REGENBIT(24) /* REGulator ENable */
+#define WRPCR_BGRENBIT(28) /* BandGap Reference ENable */
+#define IDF_MIN1
+#define IDF_MAX7
+#define NDIV_MIN   10
+#define NDIV_MAX   125
+#define ODF_MIN1
+#define ODF_MAX8
+
+/* dsi color format coding according to the datasheet */
+enum dsi_color {
+   DSI_RGB565_CONF1,
+   DSI_RGB565_CONF2,
+   DSI_RGB565_CONF3,
+   DSI_RGB666_CONF1,
+   DSI_RGB666_CONF2,
+   DSI_RGB888,
+};
+
+#define LANE_MIN_KBPS  31250
+#define LANE_MAX_KBPS  50
+
+/* Timeout for regulator on/off, pll lock/unlock & fifo empty */
+#define TIMEOUT_US 20
+
+struct stm32_dsi_priv {
+   struct mipi_dsi_device device;
+   void __iomem *base;
+   struct udevice *panel;
+   u32 pllref_clk;
+   u32 hw_version;
+   int lane_min_kbps;
+   int lane_max_kbps;
+};
+
+static inline void dsi_write(struct stm32_dsi_priv *dsi, u32 reg, u32 val)
+{
+   writel(val, dsi->base + reg);
+}
+
+static inline u32 dsi_read(struct stm32_dsi_priv *dsi, u32 reg)
+{
+   return readl(dsi->base + reg);
+}
+
+static inline void 

[U-Boot] [PATCH v2 08/10] arm: dts: stm32: add dsi for STM32F746

[yannick fertre]

Add mipi dsi bridge node in device-tree.

Signed-off-by: yannick fertre 
---
 arch/arm/dts/stm32f746.dtsi | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/dts/stm32f746.dtsi b/arch/arm/dts/stm32f746.dtsi
index e4d32bf..4ec954d 100644
--- a/arch/arm/dts/stm32f746.dtsi
+++ b/arch/arm/dts/stm32f746.dtsi
@@ -332,6 +332,18 @@
u-boot,dm-pre-reloc;
status = "disabled";
};
+
+   dsi: dsi@40016c00 {
+   compatible = "st,stm32-dsi";
+   reg = <0x40016C00 0x800>;
+   resets = < STM32F7_APB2_RESET(DSI)>;
+   clocks =  < 0 STM32F7_APB2_CLOCK(DSI)>,
+ < 0 STM32F7_APB2_CLOCK(LTDC)>,
+ <_hse>;
+   clock-names = "pclk", "px_clk", "ref";
+   u-boot,dm-pre-reloc;
+   status = "disabled";
+   };
};
 };
 
-- 
1.9.1

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

[U-Boot] [PATCH v2 10/10] board: Add STM32F769 SoC, discovery board support

[yannick fertre]

Signed-off-by: yannick fertre 
---
 configs/stm32f769-disco_defconfig | 63 +++
 1 file changed, 63 insertions(+)
 create mode 100644 configs/stm32f769-disco_defconfig

diff --git a/configs/stm32f769-disco_defconfig 
b/configs/stm32f769-disco_defconfig
new file mode 100644
index 000..ac34076
--- /dev/null
+++ b/configs/stm32f769-disco_defconfig
@@ -0,0 +1,63 @@
+CONFIG_ARM=y
+CONFIG_STM32=y
+CONFIG_SYS_MALLOC_F_LEN=0xC00
+CONFIG_STM32F7=y
+CONFIG_TARGET_STM32F746_DISCO=y
+CONFIG_DEFAULT_DEVICE_TREE="stm32f769-disco"
+CONFIG_BOOTDELAY=3
+CONFIG_USE_BOOTARGS=y
+CONFIG_BOOTARGS="console=ttyS0,115200 earlyprintk consoleblank=0 
ignore_loglevel"
+# CONFIG_DISPLAY_CPUINFO is not set
+# CONFIG_DISPLAY_BOARDINFO is not set
+CONFIG_BOARD_EARLY_INIT_F=y
+CONFIG_HUSH_PARSER=y
+CONFIG_SYS_PROMPT="U-Boot > "
+CONFIG_AUTOBOOT_KEYED=y
+CONFIG_AUTOBOOT_PROMPT="Hit SPACE in %d seconds to stop autoboot.\n"
+CONFIG_AUTOBOOT_STOP_STR=" "
+CONFIG_CMD_BOOTZ=y
+# CONFIG_CMD_FPGA is not set
+CONFIG_CMD_GPT=y
+# CONFIG_RANDOM_UUID is not set
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_SNTP=y
+CONFIG_CMD_DNS=y
+CONFIG_CMD_LINK_LOCAL=y
+CONFIG_CMD_BMP=y
+CONFIG_CMD_TIMER=y
+CONFIG_CMD_EXT2=y
+CONFIG_CMD_EXT4=y
+CONFIG_CMD_FAT=y
+CONFIG_CMD_FS_GENERIC=y
+# CONFIG_DOS_PARTITION is not set
+CONFIG_OF_CONTROL=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_NETCONSOLE=y
+# CONFIG_BLK is not set
+CONFIG_DM_MMC=y
+# CONFIG_SPL_DM_MMC is not set
+CONFIG_ARM_PL180_MMCI=y
+CONFIG_MTD=y
+CONFIG_MTD_NOR_FLASH=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_DM_ETH=y
+CONFIG_ETH_DESIGNWARE=y
+# CONFIG_PINCTRL_FULL is not set
+CONFIG_DM_SPI=y
+CONFIG_STM32_QSPI=y
+CONFIG_DM_VIDEO=y
+CONFIG_BACKLIGHT_GPIO=y
+CONFIG_VIDEO_LCD_ORISETECH_OTM8009A=y
+CONFIG_VIDEO_STM32=y
+CONFIG_VIDEO_STM32_DSI=y
+CONFIG_VIDEO_STM32_MAX_XRES=480
+CONFIG_VIDEO_STM32_MAX_YRES=800
+CONFIG_OF_LIBFDT_OVERLAY=y
+# CONFIG_EFI_LOADER is not set
-- 
1.9.1

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

[U-Boot] [PATCH v2 04/10] video: add support of panel OTM8009A

[yannick fertre]

Support for Orise Tech otm8009a 480p dsi 2dl video mode panel.

Signed-off-by: yannick fertre 
---
 drivers/video/Kconfig  |   8 +
 drivers/video/Makefile |   1 +
 drivers/video/orisetech_otm8009a.c | 329 +
 3 files changed, 338 insertions(+)
 create mode 100644 drivers/video/orisetech_otm8009a.c

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 1981298..b5fc535 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -320,6 +320,14 @@ config VIDEO_LCD_ANX9804
from a parallel LCD interface and translate it on the fy into a DP
interface for driving eDP TFT displays. It uses I2C for configuration.
 
+config VIDEO_LCD_ORISETECH_OTM8009A
+   bool "OTM8009A DSI LCD panel support"
+   depends on DM_VIDEO
+   select VIDEO_MIPI_DSI
+   default n
+   ---help---
+   Support for Orise Tech otm8009a 480p dsi 2dl video mode panel.
+
 config VIDEO_LCD_SSD2828
bool "SSD2828 bridge chip"
default n
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 6f42cca..65002af 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_VIDEO_COREBOOT) += coreboot.o
 obj-$(CONFIG_VIDEO_DA8XX) += da8xx-fb.o videomodes.o
 obj-$(CONFIG_VIDEO_LCD_ANX9804) += anx9804.o
 obj-$(CONFIG_VIDEO_LCD_HITACHI_TX18D42VM) += hitachi_tx18d42vm_lcd.o
+obj-$(CONFIG_VIDEO_LCD_ORISETECH_OTM8009A) += orisetech_otm8009a.o
 obj-$(CONFIG_VIDEO_LCD_SSD2828) += ssd2828.o
 obj-$(CONFIG_VIDEO_MB862xx) += mb862xx.o videomodes.o
 obj-$(CONFIG_VIDEO_MX3) += mx3fb.o videomodes.o
diff --git a/drivers/video/orisetech_otm8009a.c 
b/drivers/video/orisetech_otm8009a.c
new file mode 100644
index 000..79f2da8
--- /dev/null
+++ b/drivers/video/orisetech_otm8009a.c
@@ -0,0 +1,329 @@
+/*
+ * Copyright (C) 2018 STMicroelectronics - All Rights Reserved
+ * Author(s): Yannick Fertre  for STMicroelectronics.
+ *   Philippe Cornu  for STMicroelectronics.
+ *
+ * This otm8009a panel driver is based on the panel driver from
+ * drivers/gpu/drm/panel/panel-orisetech-otm8009a.c (kernel linux)
+ *
+ * SPDX-License-Identifier: GPL-2.0
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define DRV_NAME "orisetech_otm8009a"
+
+#define OTM8009A_BACKLIGHT_DEFAULT 240
+#define OTM8009A_BACKLIGHT_MAX 255
+
+/* Manufacturer Command Set */
+#define MCS_ADRSFT 0x  /* Address Shift Function */
+#define MCS_PANSET 0xB3A6  /* Panel Type Setting */
+#define MCS_SD_CTRL0xC0A2  /* Source Driver Timing Setting */
+#define MCS_P_DRV_M0xC0B4  /* Panel Driving Mode */
+#define MCS_OSC_ADJ0xC181  /* Oscillator Adjustment for Idle/Normal mode */
+#define MCS_RGB_VID_SET0xC1A1  /* RGB Video Mode Setting */
+#define MCS_SD_PCH_CTRL0xC480  /* Source Driver Precharge Control */
+#define MCS_NO_DOC10xC48A  /* Command not documented */
+#define MCS_PWR_CTRL1  0xC580  /* Power Control Setting 1 */
+#define MCS_PWR_CTRL2  0xC590  /* Power Control Setting 2 for Normal Mode */
+#define MCS_PWR_CTRL4  0xC5B0  /* Power Control Setting 4 for DC Voltage */
+#define MCS_PANCTRLSET10xCB80  /* Panel Control Setting 1 */
+#define MCS_PANCTRLSET20xCB90  /* Panel Control Setting 2 */
+#define MCS_PANCTRLSET30xCBA0  /* Panel Control Setting 3 */
+#define MCS_PANCTRLSET40xCBB0  /* Panel Control Setting 4 */
+#define MCS_PANCTRLSET50xCBC0  /* Panel Control Setting 5 */
+#define MCS_PANCTRLSET60xCBD0  /* Panel Control Setting 6 */
+#define MCS_PANCTRLSET70xCBE0  /* Panel Control Setting 7 */
+#define MCS_PANCTRLSET80xCBF0  /* Panel Control Setting 8 */
+#define MCS_PANU2D10xCC80  /* Panel U2D Setting 1 */
+#define MCS_PANU2D20xCC90  /* Panel U2D Setting 2 */
+#define MCS_PANU2D30xCCA0  /* Panel U2D Setting 3 */
+#define MCS_PAND2U10xCCB0  /* Panel D2U Setting 1 */
+#define MCS_PAND2U20xCCC0  /* Panel D2U Setting 2 */
+#define MCS_PAND2U30xCCD0  /* Panel D2U Setting 3 */
+#define MCS_GOAVST 0xCE80  /* GOA VST Setting */
+#define MCS_GOACLKA1   0xCEA0  /* GOA CLKA1 Setting */
+#define MCS_GOACLKA3   0xCEB0  /* GOA CLKA3 Setting */
+#define MCS_GOAECLK0xCFC0  /* GOA ECLK Setting */
+#define MCS_NO_DOC20xCFD0  /* Command not documented */
+#define MCS_GVDDSET0xD800  /* GVDD/NGVDD */
+#define MCS_VCOMDC 0xD900  /* VCOM Voltage Setting */
+#define MCS_GMCT2_2P   0xE100  /* Gamma Correction 2.2+ Setting */
+#define MCS_GMCT2_2N   0xE200  /* Gamma Correction 2.2- Setting */
+#define MCS_NO_DOC30xF5B6  /* Command not documented */
+#define MCS_CMD2_ENA1  0xFF00  /* Enable Access Command2 "CMD2" */
+#define MCS_CMD2_ENA2  0xFF80  /* Enable Access Orise Command2 */
+
+struct otm8009a_panel_priv {
+   struct udevice *reg;
+   struct 

[U-Boot] [PATCH v2 03/10] video: add support of MIPI DSI interface

[yannick fertre]

Mipi_display.c contains a set of dsi helpers.
This file is a copy of file drm_mipi_dsi.c (linux kernel).

Signed-off-by: yannick fertre 
---
 drivers/video/Kconfig|   7 +
 drivers/video/Makefile   |   1 +
 drivers/video/mipi_display.c | 807 +++
 include/mipi_display.h   | 257 +-
 4 files changed, 1071 insertions(+), 1 deletion(-)
 create mode 100644 drivers/video/mipi_display.c

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 2fc0def..1981298 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -75,6 +75,13 @@ config VIDEO_ANSI
  Enable ANSI escape sequence decoding for a more fully functional
  console.
 
+config VIDEO_MIPI_DSI
+   bool "Support MIPI DSI interface"
+   depends on DM_VIDEO
+   default y if DM_VIDEO
+   help
+ Support MIPI DSI interface for driving a MIPI compatible LCD panel.
+
 config CONSOLE_NORMAL
bool "Support a simple text console"
depends on DM_VIDEO
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index dfafe08..6f42cca 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_FORMIKE) += formike.o
 obj-$(CONFIG_LG4573) += lg4573.o
 obj-$(CONFIG_AM335X_LCD) += am335x-fb.o
 obj-$(CONFIG_VIDEO_DW_HDMI) += dw_hdmi.o
+obj-${CONFIG_VIDEO_MIPI_DSI} += mipi_display.o
 obj-$(CONFIG_VIDEO_SIMPLE) += simplefb.o
 obj-${CONFIG_VIDEO_TEGRA124} += tegra124/
 obj-${CONFIG_EXYNOS_FB} += exynos/
diff --git a/drivers/video/mipi_display.c b/drivers/video/mipi_display.c
new file mode 100644
index 000..d90ff5d
--- /dev/null
+++ b/drivers/video/mipi_display.c
@@ -0,0 +1,807 @@
+/*
+ * MIPI DSI Bus
+ *
+ * Copyright (C) 2012-2013, Samsung Electronics, Co., Ltd.
+ * Copyright (C) 2018 STMicroelectronics - All Rights Reserved
+ * Andrzej Hajda 
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
+ * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+ * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
+ * USE OR OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * DOC: dsi helpers
+ *
+ * These functions contain some common logic and helpers to deal with MIPI DSI
+ * peripherals.
+ *
+ * Helpers are provided for a number of standard MIPI DSI command as well as a
+ * subset of the MIPI DCS command set.
+ */
+
+/**
+ * mipi_dsi_attach - attach a DSI device to its DSI host
+ * @dsi: DSI peripheral
+ */
+int mipi_dsi_attach(struct mipi_dsi_device *dsi)
+{
+   const struct mipi_dsi_host_ops *ops = dsi->host->ops;
+
+   if (!ops || !ops->attach)
+   return -ENOSYS;
+
+   return ops->attach(dsi->host, dsi);
+}
+EXPORT_SYMBOL(mipi_dsi_attach);
+
+/**
+ * mipi_dsi_detach - detach a DSI device from its DSI host
+ * @dsi: DSI peripheral
+ */
+int mipi_dsi_detach(struct mipi_dsi_device *dsi)
+{
+   const struct mipi_dsi_host_ops *ops = dsi->host->ops;
+
+   if (!ops || !ops->detach)
+   return -ENOSYS;
+
+   return ops->detach(dsi->host, dsi);
+}
+EXPORT_SYMBOL(mipi_dsi_detach);
+
+static ssize_t mipi_dsi_device_transfer(struct mipi_dsi_device *dsi,
+   struct mipi_dsi_msg *msg)
+{
+   const struct mipi_dsi_host_ops *ops = dsi->host->ops;
+
+   if (!ops || !ops->transfer)
+   return -ENOSYS;
+
+   if (dsi->mode_flags & MIPI_DSI_MODE_LPM)
+   msg->flags |= MIPI_DSI_MSG_USE_LPM;
+
+   return ops->transfer(dsi->host, msg);
+}
+
+/**
+ * mipi_dsi_packet_format_is_short - check if a packet is of the short format
+ * @type: MIPI DSI data type of the packet
+ *
+ * Return: true if the packet for the given data type is a short packet, false
+ * otherwise.
+ */
+bool mipi_dsi_packet_format_is_short(u8 type)
+{
+   switch (type) {
+   case MIPI_DSI_V_SYNC_START:
+   case MIPI_DSI_V_SYNC_END:
+   case MIPI_DSI_H_SYNC_START:
+   case MIPI_DSI_H_SYNC_END:
+

[U-Boot] [PATCH v2 01/10] video: stm32: stm32_ltdc: add bridge to display controller

[yannick fertre]

Manage a bridge insert between the display controller & a panel.

Signed-off-by: yannick fertre 
---
 drivers/video/stm32/stm32_ltdc.c | 107 ++-
 1 file changed, 71 insertions(+), 36 deletions(-)

diff --git a/drivers/video/stm32/stm32_ltdc.c b/drivers/video/stm32/stm32_ltdc.c
index e160c77..bd9c0de 100644
--- a/drivers/video/stm32/stm32_ltdc.c
+++ b/drivers/video/stm32/stm32_ltdc.c
@@ -8,6 +8,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -15,12 +16,12 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
 struct stm32_ltdc_priv {
void __iomem *regs;
-   struct display_timing timing;
enum video_log2_bpp l2bpp;
u32 bg_col_argb;
u32 crop_x, crop_y, crop_w, crop_h;
@@ -210,23 +211,23 @@ static void stm32_ltdc_enable(struct stm32_ltdc_priv 
*priv)
setbits_le32(priv->regs + LTDC_GCR, GCR_LTDCEN);
 }
 
-static void stm32_ltdc_set_mode(struct stm32_ltdc_priv *priv)
+static void stm32_ltdc_set_mode(struct stm32_ltdc_priv *priv,
+   struct display_timing *timings)
 {
void __iomem *regs = priv->regs;
-   struct display_timing *timing = >timing;
u32 hsync, vsync, acc_hbp, acc_vbp, acc_act_w, acc_act_h;
u32 total_w, total_h;
u32 val;
 
/* Convert video timings to ltdc timings */
-   hsync = timing->hsync_len.typ - 1;
-   vsync = timing->vsync_len.typ - 1;
-   acc_hbp = hsync + timing->hback_porch.typ;
-   acc_vbp = vsync + timing->vback_porch.typ;
-   acc_act_w = acc_hbp + timing->hactive.typ;
-   acc_act_h = acc_vbp + timing->vactive.typ;
-   total_w = acc_act_w + timing->hfront_porch.typ;
-   total_h = acc_act_h + timing->vfront_porch.typ;
+   hsync = timings->hsync_len.typ - 1;
+   vsync = timings->vsync_len.typ - 1;
+   acc_hbp = hsync + timings->hback_porch.typ;
+   acc_vbp = vsync + timings->vback_porch.typ;
+   acc_act_w = acc_hbp + timings->hactive.typ;
+   acc_act_h = acc_vbp + timings->vactive.typ;
+   total_w = acc_act_w + timings->hfront_porch.typ;
+   total_h = acc_act_h + timings->vfront_porch.typ;
 
/* Synchronization sizes */
val = (hsync << 16) | vsync;
@@ -248,14 +249,14 @@ static void stm32_ltdc_set_mode(struct stm32_ltdc_priv 
*priv)
 
/* Signal polarities */
val = 0;
-   debug("%s: timing->flags 0x%08x\n", __func__, timing->flags);
-   if (timing->flags & DISPLAY_FLAGS_HSYNC_HIGH)
+   debug("%s: timing->flags 0x%08x\n", __func__, timings->flags);
+   if (timings->flags & DISPLAY_FLAGS_HSYNC_HIGH)
val |= GCR_HSPOL;
-   if (timing->flags & DISPLAY_FLAGS_VSYNC_HIGH)
+   if (timings->flags & DISPLAY_FLAGS_VSYNC_HIGH)
val |= GCR_VSPOL;
-   if (timing->flags & DISPLAY_FLAGS_DE_HIGH)
+   if (timings->flags & DISPLAY_FLAGS_DE_HIGH)
val |= GCR_DEPOL;
-   if (timing->flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
+   if (timings->flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
val |= GCR_PCPOL;
clrsetbits_le32(regs + LTDC_GCR,
GCR_HSPOL | GCR_VSPOL | GCR_DEPOL | GCR_PCPOL, val);
@@ -331,7 +332,11 @@ static int stm32_ltdc_probe(struct udevice *dev)
struct video_uc_platdata *uc_plat = dev_get_uclass_platdata(dev);
struct video_priv *uc_priv = dev_get_uclass_priv(dev);
struct stm32_ltdc_priv *priv = dev_get_priv(dev);
-   struct udevice *panel;
+#ifdef CONFIG_VIDEO_BRIDGE
+   struct udevice *bridge = NULL;
+#endif
+   struct udevice *panel = NULL;
+   struct display_timing timings;
struct clk pclk;
struct reset_ctl rst;
int rate, ret;
@@ -364,63 +369,93 @@ static int stm32_ltdc_probe(struct udevice *dev)
/* Reset */
reset_deassert();
 
-   ret = uclass_first_device(UCLASS_PANEL, );
+#ifdef CONFIG_VIDEO_BRIDGE
+   ret = uclass_get_device(UCLASS_VIDEO_BRIDGE, 0, );
if (ret) {
-   debug("%s: panel device error %d\n", __func__, ret);
-   return ret;
+   debug("%s: No video bridge, or no backlight on bridge\n",
+ __func__);
}
 
-   ret = panel_enable_backlight(panel);
+   if (bridge) {
+   ret = video_bridge_attach(bridge);
+   if (ret) {
+   debug("%s: fail to attach bridge\n", __func__);
+   return ret;
+   }
+   }
+#endif
+   ret = uclass_first_device(UCLASS_PANEL, );
if (ret) {
-   debug("%s: panel %s enable backlight error %d\n",
- __func__, panel->name, ret);
+   debug("%s: panel device error %d\n", __func__, ret);
return ret;
}
 
-   ret = fdtdec_decode_display_timing(gd->fdt_blob,
-  dev_of_offset(dev), 0,

[U-Boot] [PATCH v2 00/10] splash screen on the stm32f769 disco board

[yannick fertre]

Version 2:
- Replace debug log by pr_error, pr_warn or pr_info.
- Rework bridge between ltdc & dsi panel
- Rework backligh management (with or witout gpio)
- Rework panel otm8009a
- Add new panel raydium rm68200

Version 1:
- Initial commit

This serie contains all patchsets needed for displaying a splash screen 
on the stm32f769 disco board.

yannick fertre (10):
  video: stm32: stm32_ltdc: add bridge to display controller
  video: stm32: stm32_ltdc: update debug log
  video: add support of MIPI DSI interface
  video: add support of panel OTM8009A
  video: add MIPI DSI host controller bridge
  video: add support of STM32 MIPI DSI controller driver
  video: add support of panel rm68200
  arm: dts: stm32: add dsi for STM32F746
  arm: dts: stm32: add display for STM32F769 disco board
  board: Add STM32F769 SoC, discovery board support

 arch/arm/dts/stm32f746.dtsi|  12 +
 arch/arm/dts/stm32f769-disco.dts   |  71 
 configs/stm32f769-disco_defconfig  |  63 +++
 drivers/video/Kconfig  |  32 ++
 drivers/video/Makefile |   4 +
 drivers/video/dw_mipi_dsi.c| 822 +
 drivers/video/mipi_display.c   | 807 
 drivers/video/orisetech_otm8009a.c | 329 +++
 drivers/video/raydium-rm68200.c| 329 +++
 drivers/video/stm32/Kconfig|  10 +
 drivers/video/stm32/Makefile   |   1 +
 drivers/video/stm32/stm32_dsi.c| 427 +++
 drivers/video/stm32/stm32_ltdc.c   | 144 ---
 include/dw_mipi_dsi.h  |  32 ++
 include/mipi_display.h | 257 +++-
 15 files changed, 3285 insertions(+), 55 deletions(-)
 create mode 100644 configs/stm32f769-disco_defconfig
 create mode 100644 drivers/video/dw_mipi_dsi.c
 create mode 100644 drivers/video/mipi_display.c
 create mode 100644 drivers/video/orisetech_otm8009a.c
 create mode 100644 drivers/video/raydium-rm68200.c
 create mode 100644 drivers/video/stm32/stm32_dsi.c
 create mode 100644 include/dw_mipi_dsi.h

-- 
1.9.1

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

[U-Boot] [PATCH v2 7/9] arm: dts: stm32: add display for STM32F746 disco board

[yannick fertre]

Enable the display controller , panel & backlight.
Set panel display timings & set the RGB data bus.

Signed-off-by: yannick fertre 
---
 arch/arm/dts/stm32f746-disco.dts | 70 
 1 file changed, 70 insertions(+)

diff --git a/arch/arm/dts/stm32f746-disco.dts b/arch/arm/dts/stm32f746-disco.dts
index 9e8d2a0..e47f762 100644
--- a/arch/arm/dts/stm32f746-disco.dts
+++ b/arch/arm/dts/stm32f746-disco.dts
@@ -89,6 +89,37 @@
compatible = "st,button1";
button-gpio = < 11 0>;
};
+
+   backlight: backlight {
+   compatible = "gpio-backlight";
+   gpios = < 3 0>;
+   status = "okay";
+   };
+
+   panel-rgb@0 {
+   compatible = "simple-panel";
+   backlight = <>;
+   enable-gpios = < 12 0>;
+   status = "okay";
+
+   display-timings {
+   timing@0 {
+   clock-frequency = <900>;
+   hactive = <480>;
+   vactive = <272>;
+   hfront-porch = <2>;
+   hback-porch = <2>;
+   hsync-len = <41>;
+   vfront-porch = <2>;
+   vback-porch = <2>;
+   vsync-len = <10>;
+   hsync-active = <0>;
+   vsync-active = <0>;
+   de-active = <0>;
+   pixelclk-active = <1>;
+   };
+   };
+   };
 };
 
 _hse {
@@ -183,6 +214,40 @@
  slew-rate = <2>;
};
};
+
+   ltdc_pins: ltdc@0 {
+   pins {
+   pinmux = ,
+  ,
+  ,
+  ,
+  ,
+  ,
+  ,
+  ,
+  ,
+  ,
+  ,
+  ,
+  ,
+  ,
+  ,
+  ,
+  ,
+  ,
+  ,
+  ,
+  ,
+  ,
+  ,
+  ,
+  ,
+  ,
+  ,
+  ;
+   slew-rate = <2>;
+   };
+   };
 };
 
  {
@@ -250,3 +315,8 @@
bus-width = <4>;
max-frequency = <2500>;
 };
+
+ {
+   status = "okay";
+   pinctrl-0 = <_pins>;
+};
-- 
1.9.1

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

[U-Boot] [PATCH v2 6/9] arm: dts: stm32: add ltdc for STM32F746

[yannick fertre]

From: Philippe CORNU 

Add display controller node in device-tree.

Signed-off-by: yannick fertre 
---
 arch/arm/dts/stm32f746.dtsi | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/dts/stm32f746.dtsi b/arch/arm/dts/stm32f746.dtsi
index 46d148e..e4d32bf 100644
--- a/arch/arm/dts/stm32f746.dtsi
+++ b/arch/arm/dts/stm32f746.dtsi
@@ -323,6 +323,15 @@
pinctrl-names = "default", "opendrain";
max-frequency = <4800>;
};
+
+   ltdc: display-controller@40016800 {
+   compatible = "st,stm32-ltdc";
+   reg = <0x40016800 0x200>;
+   resets = < STM32F7_APB2_RESET(LTDC)>;
+   clocks = < 0 STM32F7_APB2_CLOCK(LTDC)>;
+   u-boot,dm-pre-reloc;
+   status = "disabled";
+   };
};
 };
 
-- 
1.9.1

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

[U-Boot] [PATCH v2 9/9] board: Add display to STM32F746 SoC discovery board

[yannick fertre]

Signed-off-by: yannick fertre 
---
 configs/stm32f746-disco_defconfig | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/configs/stm32f746-disco_defconfig 
b/configs/stm32f746-disco_defconfig
index f8fa198..0bc9c01 100644
--- a/configs/stm32f746-disco_defconfig
+++ b/configs/stm32f746-disco_defconfig
@@ -28,6 +28,7 @@ CONFIG_CMD_PING=y
 CONFIG_CMD_SNTP=y
 CONFIG_CMD_DNS=y
 CONFIG_CMD_LINK_LOCAL=y
+CONFIG_CMD_BMP=y
 CONFIG_CMD_TIMER=y
 CONFIG_CMD_EXT2=y
 CONFIG_CMD_EXT4=y
@@ -52,5 +53,10 @@ CONFIG_ETH_DESIGNWARE=y
 # CONFIG_PINCTRL_FULL is not set
 CONFIG_DM_SPI=y
 CONFIG_STM32_QSPI=y
+CONFIG_DM_VIDEO=y
+CONFIG_BACKLIGHT_GPIO=y
+CONFIG_VIDEO_STM32=y
+CONFIG_VIDEO_STM32_MAX_XRES=480
+CONFIG_VIDEO_STM32_MAX_YRES=640
 CONFIG_OF_LIBFDT_OVERLAY=y
 # CONFIG_EFI_LOADER is not set
-- 
1.9.1

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

[U-Boot] [PATCH v2 5/9] video: stm32: stm32_ltdc: set the blending factor

[yannick fertre]

Set the blending factor regarding the pixel format

Signed-off-by: yannick fertre 
---
 drivers/video/stm32/stm32_ltdc.c | 41 ++--
 1 file changed, 35 insertions(+), 6 deletions(-)

diff --git a/drivers/video/stm32/stm32_ltdc.c b/drivers/video/stm32/stm32_ltdc.c
index 6c3557b..e160c77 100644
--- a/drivers/video/stm32/stm32_ltdc.c
+++ b/drivers/video/stm32/stm32_ltdc.c
@@ -138,7 +138,9 @@ struct stm32_ltdc_priv {
 #define LXCFBLNR_CFBLN GENMASK(10, 0)  /* Color Frame Buffer Line Number */
 
 #define BF1_PAXCA  0x600   /* Pixel Alpha x Constant Alpha */
+#define BF1_CA 0x400   /* Constant Alpha */
 #define BF2_1PAXCA 0x007   /* 1 - (Pixel Alpha x Constant Alpha) */
+#define BF2_1CA0x005   /* 1 - Constant Alpha */
 
 enum stm32_ltdc_pix_fmt {
PF_ARGB = 0,
@@ -161,11 +163,17 @@ static u32 stm32_ltdc_get_pixel_format(enum 
video_log2_bpp l2bpp)
pf = PF_RGB565;
break;
 
+   case VIDEO_BPP32:
+   pf = PF_ARGB;
+   break;
+
+   case VIDEO_BPP8:
+   pf = PF_L8;
+   break;
+
case VIDEO_BPP1:
case VIDEO_BPP2:
case VIDEO_BPP4:
-   case VIDEO_BPP8:
-   case VIDEO_BPP32:
default:
debug("%s: warning %dbpp not supported yet, %dbpp instead\n",
  __func__, VNBITS(l2bpp), VNBITS(VIDEO_BPP16));
@@ -178,6 +186,23 @@ static u32 stm32_ltdc_get_pixel_format(enum video_log2_bpp 
l2bpp)
return (u32)pf;
 }
 
+static bool has_alpha(u32 fmt)
+{
+   switch (fmt) {
+   case PF_ARGB:
+   case PF_ARGB1555:
+   case PF_ARGB:
+   case PF_AL44:
+   case PF_AL88:
+   return true;
+   case PF_RGB888:
+   case PF_RGB565:
+   case PF_L8:
+   default:
+   return false;
+   }
+}
+
 static void stm32_ltdc_enable(struct stm32_ltdc_priv *priv)
 {
/* Reload configuration immediately & enable LTDC */
@@ -247,6 +272,7 @@ static void stm32_ltdc_set_layer1(struct stm32_ltdc_priv 
*priv, ulong fb_addr)
u32 line_length;
u32 bus_width;
u32 val, tmp, bpp;
+   u32 format;
 
x0 = priv->crop_x;
x1 = priv->crop_x + priv->crop_w - 1;
@@ -277,15 +303,18 @@ static void stm32_ltdc_set_layer1(struct stm32_ltdc_priv 
*priv, ulong fb_addr)
clrsetbits_le32(regs + LTDC_L1CFBLR, LXCFBLR_CFBLL | LXCFBLR_CFBP, val);
 
/* Pixel format */
-   val = stm32_ltdc_get_pixel_format(priv->l2bpp);
-   clrsetbits_le32(regs + LTDC_L1PFCR, LXPFCR_PF, val);
+   format = stm32_ltdc_get_pixel_format(priv->l2bpp);
+   clrsetbits_le32(regs + LTDC_L1PFCR, LXPFCR_PF, format);
 
/* Constant alpha value */
clrsetbits_le32(regs + LTDC_L1CACR, LXCACR_CONSTA, priv->alpha);
 
+   /* Specifies the blending factors : with or without pixel alpha */
+   /* Manage hw-specific capabilities */
+   val = has_alpha(format) ? BF1_PAXCA | BF2_1PAXCA : BF1_CA | BF2_1CA;
+
/* Blending factors */
-   clrsetbits_le32(regs + LTDC_L1BFCR, LXBFCR_BF2 | LXBFCR_BF1,
-   BF1_PAXCA | BF2_1PAXCA);
+   clrsetbits_le32(regs + LTDC_L1BFCR, LXBFCR_BF2 | LXBFCR_BF1, val);
 
/* Frame buffer line number */
clrsetbits_le32(regs + LTDC_L1CFBLNR, LXCFBLNR_CFBLN, priv->crop_h);
-- 
1.9.1

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

[U-Boot] [PATCH v2 1/9] video: stm32: stm32_ltdc: add reset

[yannick fertre]

Add reset of LTDC display controller.

Signed-off-by: yannick fertre 
---
 drivers/video/stm32/stm32_ltdc.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/video/stm32/stm32_ltdc.c b/drivers/video/stm32/stm32_ltdc.c
index b417ac2..d8784f1 100644
--- a/drivers/video/stm32/stm32_ltdc.c
+++ b/drivers/video/stm32/stm32_ltdc.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -302,6 +303,7 @@ static int stm32_ltdc_probe(struct udevice *dev)
struct stm32_ltdc_priv *priv = dev_get_priv(dev);
struct udevice *panel;
struct clk pclk, pxclk;
+   struct reset_ctl rst;
int ret;
 
priv->regs = (void *)dev_read_addr(dev);
@@ -316,6 +318,15 @@ static int stm32_ltdc_probe(struct udevice *dev)
return ret;
}
 
+   ret = reset_get_by_index(dev, 0, );
+   if (ret) {
+   debug("%s: missing ltdc hardware reset\n", __func__);
+   return -ENODEV;
+   }
+
+   /* Reset */
+   reset_deassert();
+
ret = panel_enable_backlight(panel);
if (ret) {
debug("%s: panel %s enable backlight error %d\n",
-- 
1.9.1

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

[U-Boot] [PATCH v2 4/9] video: stm32: stm32_ltdc: missing set of line interrupt position

[yannick fertre]

Set LIPCR (line interrupt position conf) register with line length.

Signed-off-by: yannick fertre 
---
 drivers/video/stm32/stm32_ltdc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/video/stm32/stm32_ltdc.c b/drivers/video/stm32/stm32_ltdc.c
index 08e0afc..6c3557b 100644
--- a/drivers/video/stm32/stm32_ltdc.c
+++ b/drivers/video/stm32/stm32_ltdc.c
@@ -219,6 +219,8 @@ static void stm32_ltdc_set_mode(struct stm32_ltdc_priv 
*priv)
val = (total_w << 16) | total_h;
clrsetbits_le32(regs + LTDC_TWCR, TWCR_TOTALH | TWCR_TOTALW, val);
 
+   setbits_le32(regs + LTDC_LIPCR, acc_act_h + 1);
+
/* Signal polarities */
val = 0;
debug("%s: timing->flags 0x%08x\n", __func__, timing->flags);
-- 
1.9.1

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

[U-Boot] [PATCH v2 0/9] splash screen on the stm32f746 disco board

[yannick fertre]

Version 2:
- Add patch to display bitmap stmicroelectronics_uboot_logo_8bit_rle
- Add patch to defconfig to add splash screen
- Rename panel in dts.

Version 1:
- Initial commit

This serie contains all patchsets needed for displaying a splash screen 
on the stm32f746 disco board & some display features (reset, blending & line
interrupt position).

Philippe CORNU (1):
  arm: dts: stm32: add ltdc for STM32F746

yannick fertre (8):
  video: stm32: stm32_ltdc: add reset
  video: stm32: stm32_ltdc: update file header & footer
  video: stm32: stm32_ltdc: set rate of the pixel clock
  video: stm32: stm32_ltdc: missing set of line interrupt position
  video: stm32: stm32_ltdc: set the blending factor
  arm: dts: stm32: add display for STM32F746 disco board
  stm32f7: board: add splash screen
  board: Add display to STM32F746 SoC discovery board

 arch/arm/dts/stm32f746-disco.dts   |   70 +
 arch/arm/dts/stm32f746.dtsi|9 +
 board/st/stm32f746-disco/stm32f746-disco.c |9 +
 configs/stm32f746-disco_defconfig  |6 +
 drivers/video/stm32/stm32_ltdc.c   |  117 +-
 include/configs/stm32f746-disco.h  |   10 +
 include/st_logo_data.h | 3267 
 7 files changed, 3453 insertions(+), 35 deletions(-)
 create mode 100644 include/st_logo_data.h

-- 
1.9.1

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

[U-Boot] [PATCH v2 3/9] video: stm32: stm32_ltdc: set rate of the pixel clock

[yannick fertre]

pxclk is useless to set pixel clock.

Signed-off-by: yannick fertre 
---
 drivers/video/stm32/stm32_ltdc.c | 52 ++--
 1 file changed, 29 insertions(+), 23 deletions(-)

diff --git a/drivers/video/stm32/stm32_ltdc.c b/drivers/video/stm32/stm32_ltdc.c
index 8d89b58..08e0afc 100644
--- a/drivers/video/stm32/stm32_ltdc.c
+++ b/drivers/video/stm32/stm32_ltdc.c
@@ -301,9 +301,9 @@ static int stm32_ltdc_probe(struct udevice *dev)
struct video_priv *uc_priv = dev_get_uclass_priv(dev);
struct stm32_ltdc_priv *priv = dev_get_priv(dev);
struct udevice *panel;
-   struct clk pclk, pxclk;
+   struct clk pclk;
struct reset_ctl rst;
-   int ret;
+   int rate, ret;
 
priv->regs = (void *)dev_read_addr(dev);
if ((fdt_addr_t)priv->regs == FDT_ADDR_T_NONE) {
@@ -311,9 +311,16 @@ static int stm32_ltdc_probe(struct udevice *dev)
return -EINVAL;
}
 
-   ret = uclass_first_device(UCLASS_PANEL, );
+   ret = clk_get_by_index(dev, 0, );
if (ret) {
-   debug("%s: panel device error %d\n", __func__, ret);
+   debug("%s: peripheral clock get error %d\n", __func__, ret);
+   return ret;
+   }
+
+   ret = clk_enable();
+   if (ret) {
+   debug("%s: peripheral clock enable error %d\n",
+ __func__, ret);
return ret;
}
 
@@ -326,6 +333,12 @@ static int stm32_ltdc_probe(struct udevice *dev)
/* Reset */
reset_deassert();
 
+   ret = uclass_first_device(UCLASS_PANEL, );
+   if (ret) {
+   debug("%s: panel device error %d\n", __func__, ret);
+   return ret;
+   }
+
ret = panel_enable_backlight(panel);
if (ret) {
debug("%s: panel %s enable backlight error %d\n",
@@ -333,31 +346,24 @@ static int stm32_ltdc_probe(struct udevice *dev)
return ret;
}
 
-   ret = fdtdec_decode_display_timing(gd->fdt_blob, dev_of_offset(dev),
-  0, >timing);
+   ret = fdtdec_decode_display_timing(gd->fdt_blob,
+  dev_of_offset(dev), 0,
+  >timing);
if (ret) {
-   debug("%s: decode display timing error %d\n", __func__, ret);
+   debug("%s: decode display timing error %d\n",
+ __func__, ret);
return -EINVAL;
}
 
-   ret = clk_get_by_name(dev, "pclk", );
-   if (ret) {
-   debug("%s: peripheral clock get error %d\n", __func__, ret);
-   return ret;
+   rate = clk_set_rate(, priv->timing.pixelclock.typ);
+   if (rate < 0) {
+   debug("%s: fail to set pixel clock %d hz %d hz\n",
+ __func__, priv->timing.pixelclock.typ, rate);
+   return rate;
}
 
-   ret = clk_enable();
-   if (ret) {
-   debug("%s: peripheral clock enable error %d\n", __func__, ret);
-   return ret;
-   }
-
-   /* Verify pixel clock value if any & inform user accordingly */
-   ret = clk_get_by_name(dev, "pxclk", );
-   if (!ret) {
-   if (clk_get_rate() != priv->timing.pixelclock.typ)
-   printf("Warning: please adjust ltdc pixel clock\n");
-   }
+   debug("%s: Set pixel clock req %d hz get %d hz\n", __func__,
+ priv->timing.pixelclock.typ, rate);
 
/* TODO Below parameters are hard-coded for the moment... */
priv->l2bpp = VIDEO_BPP16;
-- 
1.9.1

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

[U-Boot] [PATCH v2 2/9] video: stm32: stm32_ltdc: update file header & footer

[yannick fertre]

Modified copyright & driver name.

Signed-off-by: yannick fertre 
---
 drivers/video/stm32/stm32_ltdc.c | 17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/drivers/video/stm32/stm32_ltdc.c b/drivers/video/stm32/stm32_ltdc.c
index d8784f1..8d89b58 100644
--- a/drivers/video/stm32/stm32_ltdc.c
+++ b/drivers/video/stm32/stm32_ltdc.c
@@ -1,8 +1,7 @@
 /*
- * Copyright (C) STMicroelectronics SA 2017
- *
- * Authors: Philippe Cornu 
- *  Yannick Fertre 
+ * Copyright (C) 2017-2018 STMicroelectronics - All Rights Reserved
+ * Author(s): Philippe Cornu  for STMicroelectronics.
+ *   Yannick Fertre  for STMicroelectronics.
  *
  * SPDX-License-Identifier: GPL-2.0+
  */
@@ -408,10 +407,10 @@ static const struct udevice_id stm32_ltdc_ids[] = {
 };
 
 U_BOOT_DRIVER(stm32_ltdc) = {
-   .name   = "stm32_ltdc",
-   .id = UCLASS_VIDEO,
-   .of_match = stm32_ltdc_ids,
-   .probe  = stm32_ltdc_probe,
-   .bind   = stm32_ltdc_bind,
+   .name   = "stm32_display",
+   .id = UCLASS_VIDEO,
+   .of_match   = stm32_ltdc_ids,
+   .probe  = stm32_ltdc_probe,
+   .bind   = stm32_ltdc_bind,
.priv_auto_alloc_size   = sizeof(struct stm32_ltdc_priv),
 };
-- 
1.9.1

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

Re: [U-Boot] [PATCH] watchdog: omap_wdt: improve watchdog reset path

[Lukasz Majewski]

Hi Ruslan,

> Hi Lukasz,
> 
> On Thu, Mar 1, 2018 at 12:53 PM, Lukasz Majewski 
> wrote:
> > Hi Ruslan,
> >  
> >> Remove busy looping during watchdog reset.
> >> Each polling of W_PEND_WTGR bit ("finish posted
> >> write") after watchdog reset takes 120-140us
> >> on BeagleBone Black board. Current U-Boot code
> >> has watchdog resets in random places and often
> >> there is situation when watchdog is reset
> >> few times in a row in nested functions.
> >> This adds extra delays and slows the whole system.
> >>
> >> Instead of polling W_PEND_WTGR bit, we skip
> >> watchdog reset if the bit is set. Anyway, watchdog
> >> is in the middle of reset *right now*, so we can
> >> just return.  
> >
> > It seems like similar problem may be in the Linux kernel driver:
> > v4.16-rc1/source/drivers/watchdog/omap_wdt.c#L74
> >
> > Linux driver also waits for the write.  
> 
> Right, Linux driver has similar code but it doesn't affect
> performance. This is because of watchdog usage in Linux, it is
> enabled and reset by userspace. This is quite rare event.
> Moreover, since Linux has interrupts enabled and has scheduling,
> such busy loops in the omap driver are not very different to
> just mdelay() usage. The system can handle interrupts, and can
> even do preemption if PREEMPT is enabled.
> So use of such busy loops in that particular case shouldn't cause
> any noticeable performance issues.
> 
> In U-Boot we have polling instead of interrupts and something like
> cooperative multitasking. Also watchdog resets much more often,
> and such busy pollings in the driver delay execution of other code.
> 
> For example, in DFU we have indefinite loop, something like:
>--->  
>   |   dfu_write()
>   |   watchdog_reset()
>   |   ...
>   |   handle_usb()
>   |  `- watchdog_reset()
>   |   ` ...
>   `'
> 
> And each delay caused by watchdog reset adds significant
> overhead comparing to handling USB events or writing to the
> storage.
> 
> So as bottom line, we don't need to do similar change in
> Linux driver because there is almost no impact on performance
> in that case. But in case of U-Boot which uses polling instead
> of interrupts, this patch causes such a big performance
> improvement.

Thank you for this work - it really improves speed considerably :-).

Reviewed-by: Lukasz Majewski 

> 
> Best regards,
> Ruslan
> 
> >  
> >>
> >> This noticeably increases performance of the
> >> system. Below are some measurements on BBB:
> >>  - DFU upload over USB 15% faster
> >>  - fastboot image upload   3x times faster
> >>  - USB ep0 transfers with 4k packets   20% faster
> >>
> >> Signed-off-by: Ruslan Bilovol 
> >> ---
> >>  drivers/watchdog/omap_wdt.c | 21 +++--
> >>  1 file changed, 15 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/drivers/watchdog/omap_wdt.c
> >> b/drivers/watchdog/omap_wdt.c index 7b1f429..d724c96 100644
> >> --- a/drivers/watchdog/omap_wdt.c
> >> +++ b/drivers/watchdog/omap_wdt.c
> >> @@ -53,16 +53,25 @@ void hw_watchdog_reset(void)
> >>  {
> >>   struct wd_timer *wdt = (struct wd_timer *)WDT_BASE;
> >>
> >> - /* wait for posted write to complete */
> >> - while ((readl(>wdtwwps)) & WDT_WWPS_PEND_WTGR)
> >> - ;
> >> + /*
> >> +  * Somebody just triggered watchdog reset and write to WTGR
> >> register
> >> +  * is in progress. It is resetting right now, no need to
> >> trigger it
> >> +  * again
> >> +  */
> >> + if ((readl(>wdtwwps)) & WDT_WWPS_PEND_WTGR)
> >> + return;
> >>
> >>   wdt_trgr_pattern = ~wdt_trgr_pattern;
> >>   writel(wdt_trgr_pattern, >wdtwtgr);
> >>
> >> - /* wait for posted write to complete */
> >> - while ((readl(>wdtwwps) & WDT_WWPS_PEND_WTGR))
> >> - ;
> >> + /*
> >> +  * Don't wait for posted write to complete, i.e. don't check
> >> +  * WDT_WWPS_PEND_WTGR bit in WWPS register. There is no
> >> writes to
> >> +  * WTGR register outside of this func, and if entering it
> >> +  * we see WDT_WWPS_PEND_WTGR bit set, it means watchdog reset
> >> +  * was just triggered. This prevents us from wasting time in
> >> busy
> >> +  * polling of WDT_WWPS_PEND_WTGR bit.
> >> +  */
> >>  }
> >>
> >>  static int omap_wdt_set_timeout(unsigned int timeout)  
> >
> >
> >
> >
> > 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  




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


pgpMDbXOwluHT.pgp
Description: OpenPGP digital 

[U-Boot] [PATCH] dm: i2c: implement gpio-based I2C deblock

[Alexander Kochetkov]

The commit extract gpio description from device tree,
setup pins and toggle them until I2C slave device
release SDA.

Any comments? Ideas?

Could someone review the patch and tell that should
I do with it in order to bring the patch to u-boot?

Signed-off-by: Alexander Kochetkov 
---
 drivers/i2c/i2c-uclass.c |   95 +-
 1 file changed, 93 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/i2c-uclass.c b/drivers/i2c/i2c-uclass.c
index 920811a..a451e41 100644
--- a/drivers/i2c/i2c-uclass.c
+++ b/drivers/i2c/i2c-uclass.c
@@ -11,6 +11,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #define I2C_MAX_OFFSET_LEN 4
 
@@ -445,9 +447,96 @@ int i2c_get_chip_offset_len(struct udevice *dev)
return chip->offset_len;
 }
 
+static void i2c_gpio_set_pin(struct gpio_desc *pin, int bit)
+{
+   if (bit)
+   dm_gpio_set_dir_flags(pin, GPIOD_IS_IN);
+   else
+   dm_gpio_set_dir_flags(pin, GPIOD_IS_OUT |
+  GPIOD_ACTIVE_LOW |
+  GPIOD_IS_OUT_ACTIVE);
+}
+
+static int i2c_gpio_get_pin(struct gpio_desc *pin)
+{
+   return dm_gpio_get_value(pin);
+}
+
+static void i2c_deblock_gpio_run(struct gpio_desc *sda_pin, struct gpio_desc 
*scl_pin)
+{
+   int counter = 16;
+
+   i2c_gpio_set_pin(sda_pin, 1);
+   i2c_gpio_set_pin(scl_pin, 1);
+   udelay(5);
+
+   while (counter-- >= 0) {
+   i2c_gpio_set_pin(scl_pin, 1);
+   udelay(5);
+   i2c_gpio_set_pin(scl_pin, 0);
+   udelay(5);
+   if (i2c_gpio_get_pin(sda_pin))
+   break;
+   }
+
+   i2c_gpio_set_pin(sda_pin, 0);
+   udelay(5);
+
+   i2c_gpio_set_pin(scl_pin, 1);
+   udelay(5);
+
+   i2c_gpio_set_pin(sda_pin, 1);
+   udelay(5);
+}
+
+enum {
+   PIN_SDA = 0,
+   PIN_SCL,
+   PIN_COUNT,
+};
+
+static int i2c_deblock_gpio(struct udevice *bus)
+{
+   struct gpio_desc gpios[PIN_COUNT];
+   int ret;
+
+   ret = gpio_request_list_by_name(bus, "gpios", gpios,
+   ARRAY_SIZE(gpios), GPIOD_IS_IN);
+   if (ret != ARRAY_SIZE(gpios)) {
+   debug("%s: I2C Node '%s' has no 'gpios' property %s\n", 
__func__,
+ dev_read_name(bus), bus->name);
+   if (ret >= 0) {
+   gpio_free_list(bus, gpios, ret);
+   ret = -ENOENT;
+   }
+   goto out;
+   }
+
+   ret = pinctrl_select_state(bus, "gpio");
+   if (ret) {
+   debug("%s: I2C Node '%s' has no 'gpio' pinctrl state. %s\n", 
__func__,
+ dev_read_name(bus), bus->name);
+   goto out_no_pinctrl;
+   }
+
+   i2c_deblock_gpio_run([PIN_SDA], [PIN_SCL]);
+
+   ret = pinctrl_select_state(bus, "default");
+   if (ret) {
+   debug("%s: I2C Node '%s' has no 'default' pinctrl state. %s\n", 
__func__,
+ dev_read_name(bus), bus->name);
+   }
+
+out_no_pinctrl:
+   gpio_free_list(bus, gpios, ARRAY_SIZE(gpios));
+out:
+   return ret;
+}
+
 int i2c_deblock(struct udevice *bus)
 {
struct dm_i2c_ops *ops = i2c_get_ops(bus);
+   int ret;
 
/*
 * We could implement a software deblocking here if we could get
@@ -457,8 +546,10 @@ int i2c_deblock(struct udevice *bus)
 *
 * See https://patchwork.ozlabs.org/patch/399040/
 */
-   if (!ops->deblock)
-   return -ENOSYS;
+   if (!ops->deblock) {
+   ret = i2c_deblock_gpio(bus);
+   return ret ? -ENOSYS : 0;
+   }
 
return ops->deblock(bus);
 }
-- 
1.7.9.5

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

[U-Boot] [PATCH] Makefile: always preserve output for images that can contain HAB Blocks

[Rasmus Villemoes]

The current makefile logic disables creation of the
SPL.log/u-boot-ivt.img.log etc. files when V=1 is given on the command
line, the rationale presumably being that the user wants and gets the
information on the console.

However, from general principles, I don't think a higher V= level
should affect which build artifacts get generated (and certainly
shouldn't produce fewer). Concretely, it's also a problem that when
doing a V=1 build in a terminal, the relevant HAB blocks lines easily
drown in all the other V=1 output. And build systems such as Yocto by
default pass V=1, so in that case the information gets hidden away in
the do_compile log file, making it nigh impossible to create a recipe
for creating signed U-boot images.

So change the logic so that for V=0, the mkimage output is redirected
to MKIMAGEOUTPUT (which is also the current behaviour), while for any
other value of V, we _additionally_ write the information to make's
stdout, whatever that might be.

Signed-off-by: Rasmus Villemoes 
---
My first attempt did

$(if $(KBUILD_VERBOSE:0=), | tee , >) $(MKIMAGEOUTPUT)

but we can't use a pipeline, since tee is always succesful, so we
would not propagate errors from mkimage.

 Makefile | 4 ++--
 scripts/Makefile.lib | 2 +-
 scripts/Makefile.spl | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/Makefile b/Makefile
index 50abc979ad..2eb1b1a22f 100644
--- a/Makefile
+++ b/Makefile
@@ -840,11 +840,11 @@ MKIMAGEOUTPUT ?= /dev/null
 
 quiet_cmd_mkimage = MKIMAGE $@
 cmd_mkimage = $(objtree)/tools/mkimage $(MKIMAGEFLAGS_$(@F)) -d $< $@ \
-   $(if $(KBUILD_VERBOSE:1=), >$(MKIMAGEOUTPUT))
+   >$(MKIMAGEOUTPUT) $(if $(KBUILD_VERBOSE:0=), && cat $(MKIMAGEOUTPUT))
 
 quiet_cmd_mkfitimage = MKIMAGE $@
 cmd_mkfitimage = $(objtree)/tools/mkimage $(MKIMAGEFLAGS_$(@F)) -f 
$(U_BOOT_ITS) -E $@ \
-   $(if $(KBUILD_VERBOSE:1=), >$(MKIMAGEOUTPUT))
+   >$(MKIMAGEOUTPUT) $(if $(KBUILD_VERBOSE:0=), && cat $(MKIMAGEOUTPUT))
 
 quiet_cmd_cat = CAT $@
 cmd_cat = cat $(filter-out $(PHONY), $^) > $@
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 8f21653136..c6b3f69064 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -521,7 +521,7 @@ cmd_xzmisc = (cat $(filter-out FORCE,$^) | \
 MKIMAGEOUTPUT ?= /dev/null
 quiet_cmd_mkimage = MKIMAGE $@
 cmd_mkimage = $(objtree)/tools/mkimage $(MKIMAGEFLAGS_$(@F)) -d $< $@ \
-   $(if $(KBUILD_VERBOSE:1=), >$(MKIMAGEOUTPUT))
+   >$(MKIMAGEOUTPUT) $(if $(KBUILD_VERBOSE:0=), && cat $(MKIMAGEOUTPUT))
 
 # fdtgrep
 # ---
diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index 2993ade41e..7f2908d799 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -144,7 +144,7 @@ MKIMAGEOUTPUT ?= /dev/null
 
 quiet_cmd_mkimage = MKIMAGE $@
 cmd_mkimage = $(objtree)/tools/mkimage $(MKIMAGEFLAGS_$(@F)) -d $< $@ \
-   $(if $(KBUILD_VERBOSE:1=), >$(MKIMAGEOUTPUT))
+   >$(MKIMAGEOUTPUT) $(if $(KBUILD_VERBOSE:0=), && cat $(MKIMAGEOUTPUT))
 
 MKIMAGEFLAGS_MLO = -T omapimage -a $(CONFIG_SPL_TEXT_BASE)
 
-- 
2.15.1

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

Re: [U-Boot] Building for MIPS on OSX with OpenWRT toolchain

[Daniel Schwierzeck]

Hi Ward,

On 02.03.2018 01:02, Ward Willats wrote:
> Greetings from California:
> 
> I am a poor sinner trying to build u-boot from source on Max OSX. Forgive me.
> 
> I have a custom MIPS board with a u-boot from a 3rd-party vendor and we'd 
> like to replace it. The board is MIPS-based and runs OpenWRT/LEDE.
> 
> So...I grabbed the u-boot git repo, stuck it on a case-sensitive filesystem, 
> set up environment variables to allow the OpwenWRT MIPS cross compiler to 
> work, wrote a "hello world" program in the u-boot root directory and cross 
> compiled in on the command line without problem, and then turned my attention 
> to u-boot.
> 
> Thought it would be good to see if I could get something running in QEMU 
> first, so
> 
> Did this:
> 
>   make  -j1 V=1 ARCH=mips CROSS_COMPILE=mipsel-openwrt-linux- distclean
>   make  -j1 V=1 ARCH=mips CROSS_COMPILE=mipsel-openwrt-linux- 
> qemu_mipsel_defconfig
>   make  -j1 V=1 ARCH=mips CROSS_COMPILE=mipsel-openwrt-linux-
> 
> The first target it tries to build is "tools" using the HOSTCC (x86 LLVM from 
> xcode, masquerading as gcc). It gets as far as AIS Image then poops out 
> because it tries to use the MIPS version of byteorder.h, even though it 
> compiling with HOSTCC:
> 
>   ./arch/mips/include/asm/byteorder.h:70:4: error: "MIPS, but neither 
> __MIPSEB__, nor __MIPSEL__???"
>   #  error "MIPS, but neither __MIPSEB__, nor __MIPSEL__???"
> 
> Is the system expecting a native/host byteorder.h to be present when using 
> HOSTCC that is to be discovered before the compiler drops into arch/mips? If 
> so, how does that work? Or is this a corner-case bug?

Looks like a corner-case bug with LLVM. I think on a Linux system with HOST GCC 
the header guard "#ifndef _ASM_BYTEORDER_H" prevents 
arch/mips/include/asm/byteorder.h from being pre-processed by the host 
compiler. Maybe with LLVM _ASM_BYTEORDER_H is never defined by not having 
another byteorder.h in the include chain.

> 
> If I set CROSS_BUILD_TOOLS=1, obviously this problem goes away.
> 
> OR, if I use defconfig (sandbox) to get everything all x86-ish and compile 
> with 
> 
>   make -j1 V=1 tools
> 
> ...then it compiles the tools just fine (well, it can't find openssl headers, 
> and doesn't seem to pay attention to KCFLAGS= when I try to tell it where 
> they are, but that's a different problem).
> 
> Anyway, before I start hacking make files and what-not, thought I'd check in 
> and see if the gurus had any thoughts ?
> 
> Thanks
> 
> -- Ward
> 

-- 
- Daniel



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

[U-Boot] RPi3 Not autobooting from SD-card. {Scanned}

[Göran Lundberg]

Hi!
I'm trying to boot from u-boot on a Raspberry Pi 3. But for some reason 
it isn't autobooting on the SD-card.


Is it possible to get more debug output on the screen console? I don't 
have a serial console at the moment.

The output on the screen is:

Net:   No ehternet found.
starting USB...
USB:Core Release 2.80a
scanning bus 0 for devices... 4 USB Devices found
   scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:   0
U-Boot>

Shouldn't it mention mmc somewhere in the boot message?

The first command I type on the prompt is always failing, it's not 
outputting anything. Just a new prompt on the next line. The next 
commands i type in are working. Which seems strange.
I got boot.scr set up right, except graphic settings which are wrong. It 
is booting the kernel when I type 'run bootcmd'. But only after I type 
in another command before it.
It seems like it's not detecting the SD-card (mmc0) until I have typed 
anything into the prompt.


Do I have to set any other env variable for it to autoboot? I would have 
printed the output of printenv here, but since I don't have a serial 
console, retyping everything is very time consuming.
printenv seems to have the right settings. It's basically a full console 
screen of variables. It just doesn't seem to load them until I type in 
another command before it.


boot_targets=mmc0 usb0 pxe dhcp
Which seems right to me.

I compiled the latest u-boot from github.

If you need more info please let me know and I'll post it.

Hope that anyone can point me in the right direction here. Would really 
appreciate it.


Regards
Göran Lundberg

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

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

[U-Boot] Building for MIPS on OSX with OpenWRT toolchain

[Ward Willats]

Greetings from California:

I am a poor sinner trying to build u-boot from source on Max OSX. Forgive me.

I have a custom MIPS board with a u-boot from a 3rd-party vendor and we'd like 
to replace it. The board is MIPS-based and runs OpenWRT/LEDE.

So...I grabbed the u-boot git repo, stuck it on a case-sensitive filesystem, 
set up environment variables to allow the OpwenWRT MIPS cross compiler to work, 
wrote a "hello world" program in the u-boot root directory and cross compiled 
in on the command line without problem, and then turned my attention to u-boot.

Thought it would be good to see if I could get something running in QEMU first, 
so

Did this:

  make  -j1 V=1 ARCH=mips CROSS_COMPILE=mipsel-openwrt-linux- distclean
  make  -j1 V=1 ARCH=mips CROSS_COMPILE=mipsel-openwrt-linux- 
qemu_mipsel_defconfig
  make  -j1 V=1 ARCH=mips CROSS_COMPILE=mipsel-openwrt-linux-

The first target it tries to build is "tools" using the HOSTCC (x86 LLVM from 
xcode, masquerading as gcc). It gets as far as AIS Image then poops out because 
it tries to use the MIPS version of byteorder.h, even though it compiling with 
HOSTCC:

  ./arch/mips/include/asm/byteorder.h:70:4: error: "MIPS, but neither 
__MIPSEB__, nor __MIPSEL__???"
  #  error "MIPS, but neither __MIPSEB__, nor __MIPSEL__???"

Is the system expecting a native/host byteorder.h to be present when using 
HOSTCC that is to be discovered before the compiler drops into arch/mips? If 
so, how does that work? Or is this a corner-case bug?

If I set CROSS_BUILD_TOOLS=1, obviously this problem goes away.

OR, if I use defconfig (sandbox) to get everything all x86-ish and compile with 

  make -j1 V=1 tools

...then it compiles the tools just fine (well, it can't find openssl headers, 
and doesn't seem to pay attention to KCFLAGS= when I try to tell it where they 
are, but that's a different problem).

Anyway, before I start hacking make files and what-not, thought I'd check in 
and see if the gurus had any thoughts ?

Thanks

-- Ward






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

[U-Boot] Keymap problem {Scanned}

[Göran Lundberg]

Hi! I have a problem with the keymap for the u-boot command line on 
Raspberry Pi. Which keymap is u-boot using? Can it be changed somehow?
The problem I have is primarily not being able to write the backslash 
character \. I have a Swedish keyboard and I have basically tried every 
possible key combination there is with no luck. The keyboard is working 
just fine in raspbian. The backslash character should be between Z and 
the shift key. At least on en_GB keymap. But when I press that key there 
is no output at all, even with CTRL/SHIFT/ALT pressed there is no output 
at all, which seems strange.


Can you change the keymap? Anyone got an idea how to write backslash on 
a Swedish keyboard?


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

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

Re: [U-Boot] Kernel panic - not syncing: VFS: Unable to mount rootfs on unknown-block (1, 0)

[Stefano Babic]

Hi Zoran,

On 26/02/2018 11:57, Zoran S wrote:
> Hello Stefano,
> 
>> If it canot be mounted, the cause is in the most of cases in a missing
>> configuration in kernel, like initrd not supported, missing compression
>> type, and so on.
> 
> After some investigation, I found that you were correct, most likely.
> I did this investigation on two similar platforms, in two different
> environments (since one is corporate one, with some firewalls around,
> another is outside of the reach, simply it hangs on the open net, my
> private setup). Just to be sure that I excluded all the corporate
> security influences.
> 
> I used the off shelf kernel for BBB (BeagleBone Black), using YOCTO
> Project (Rocko release) to compile form the scratch, with assurance
> that this kernel is set correctly (configuration wise).
> 
> After several days of testing (since my U-Boot skills are a bit rusty,
> so I assumed I am scripting wrong), I have concluded that I have a
> correct U-Boot setup, but that the kernel image is not set correctly
> (as you suggested), since I tested it with at least 5 differently
> compiled ramdisks.
> 
> I found one BBB kernel on Linaro site (this one is Debian one, Linux
> beaglebone 4.9.0-4-armmp #1 SMP Debian 4.9.65-3 (2017-12-03) armv7l
> GNU/Linux), and tried it with minimal setup (have no idea what/how
> .config looks like), including ramdiskfs-es (I tested it with several
> ones, all compiled in the same YOCTO Rocko package) and DTB from the
> same.
> 
> It worked for me from the very first time (on both setups).
> 

ok - this confirms that the defconfig for kernel in Yocto build does not
contain enough to start from ramdisk.

> Conclusion is: Something in .config is wrong. What? This needs some
> serious investigation, since I think the failed one is also set to use
> ramdisk.

Usually, some of these are missing:

CONFIG_BLK_DEV_INITRD=y
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y
CONFIG_RD_LZ4=y

Of course, not all of them can be necessary, I am just speculating.

I would also check (but they should be on) the CONFIG_DECOMPRESS_*
options and if not, you could turn them on.


> 
> I would like to thank you for the hint.

You're welcoime,

Best regards,
Stefano

> 
> Best Regards,
> Zoran Stojsavljevic
> ___
> 
> On Wed, Feb 21, 2018 at 5:31 PM, Stefano Babic  wrote:
>> Hi Zoran,
>>
>> On 21/02/2018 11:45, Zoran S wrote:
>>> Hello to U-Boot list,
>>>
>>> I have encountered an interesting problem which I do not entirely
>>> understand. I am trying to boot MLO and u-boot.bin from the SD Card,
>>> and rest from the initramfs.
>>>
>>> I tried several initramfs images, and so far I am always failing on
>>> the same place:
>>> [2.135533] No filesystem could mount root, tried:
>>> [2.135541]  ext2
>>> [2.140682]
>>> [2.144262] Kernel panic - not syncing: VFS: Unable to mount root
>>> fs on unknown-block(1,0)
>>> [2.153034] ---[ end Kernel panic - not syncing: VFS: Unable to
>>> mount root fs on unknown-block(1,0)
>>>
>>> I have tried mostly .gz images (cpio.gz and ext2.gz). Does not help.
>>> Even does not with ext2.gz after YOCTO is done. In order to do it
>>> correctly, I MUST to add U-Boot header, and I do this with the
>>> following command:
>>>
>>> mkimage -n 'Ramdisk Image'  -A arm -O linux -T ramdisk -C gzip -d
>>> initramfs.ext2.gz initramfs.uImage
>>>
>>> And the image I actually supply is: initramfs.uImage
>>>
>>> Then, the following happens:
>>>
>>> => run netloadfdt
>>> link up on port 0, speed 100, full duplex
>>> Using cpsw device
>>> TFTP from server 192.168.15.2; our IP address is 192.168.15.20
>>> Filename 'am335x-boneblack.dtb'.
>>> Load address: 0x8800
>>> Loading: ###
>>>  697.3 KiB/s
>>> done
>>> Bytes transferred = 35016 (88c8 hex)
>>> => run netloadimage
>>> link up on port 0, speed 100, full duplex
>>> Using cpsw device
>>> TFTP from server 192.168.15.2; our IP address is 192.168.15.20
>>> Filename 'zImage'.
>>> Load address: 0x8200
>>> Loading: #
>>>  #
>>>  #
>>>  #
>>>  
>>>  772.5 KiB/s
>>> done
>>> Bytes transferred = 4161160 (3f7e88 hex)
>>> => tftp 0x8808 initramfs.uImage
>>> link up on port 0, speed 100, full duplex
>>> Using cpsw device
>>> TFTP from server 192.168.15.2; our IP address is 192.168.15.20
>>> Filename 'initramfs.uImage'.
>>> Load address: 0x8808
>>> Loading: #
>>>  #
>>>
>>>  [snap]
>>>
>>>  ###
>>>  767.6 KiB/s
>>> done
>>> Bytes transferred = 46599246 (2c70c4e hex)
>>> 

[U-Boot] [PATCH v2 2/2] mmc: zynq_sdhci: use correct quirk if CONFIG_ZYNQ_HISPD_BROKEN is defined

[Hannes Schmelzer]

The 'SDHCI_QUIRK_NO_HISPD_BIT' is used wrong here. The purpose of this
quirk is to tell the sdhci-driver that the IP-core doesn't have a "high-
speed-enable" bit in its registers.

With this commit we change this to the correct quirk:
SDHCI_QUIRK_BROKEN_HISPD_MODE

Signed-off-by: Hannes Schmelzer 
---

Changes in v2: None

 drivers/mmc/zynq_sdhci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/zynq_sdhci.c b/drivers/mmc/zynq_sdhci.c
index 0fddb42..8899e72 100644
--- a/drivers/mmc/zynq_sdhci.c
+++ b/drivers/mmc/zynq_sdhci.c
@@ -58,7 +58,7 @@ static int arasan_sdhci_probe(struct udevice *dev)
   SDHCI_QUIRK_BROKEN_R1B;
 
 #ifdef CONFIG_ZYNQ_HISPD_BROKEN
-   host->quirks |= SDHCI_QUIRK_NO_HISPD_BIT;
+   host->quirks |= SDHCI_QUIRK_BROKEN_HISPD_MODE;
 #endif
 
host->max_clk = clock;
-- 
2.7.4


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

[U-Boot] [PATCH v2 1/2] mmc: sdhci: add SDHCI_QUIRK_BROKEN_HISPD_MODE

[Hannes Schmelzer]

From: Hannes Schmelzer 

Some IP-core implementations of the SDHCI have different troubles on the
silicon where they are placed.

On ZYNQ platform for example Xilinx doesn't accept the hold timing of an
eMMC chip which operates in High-Speed mode and must be forced to
operate in non high-speed mode. To get rid of this
"SDHCI_QUIRK_BROKEN_HISPD_MODE" is introduced.

For more details about this refer to the Xilinx answer-recor #5
https://www.xilinx.com/support/answers/5.html

This commit:
- doesn't set HISPD bit on the host-conroller
- reflects this fact within the host-controller capabilities

Upon this the layer above (mmc-driver) can setup the card correctly.

Otherwise the MMC card will be switched into high-speed mode and causes
possible timing violation on the host-controller side.

Signed-off-by: Hannes Schmelzer 

jh80.ch...@samsung.com

Signed-off-by: Hannes Schmelzer 
---

Changes in v2:
- don't use the SDHCI_QUIRK_NO_HISPD_BIT for getting rid of this,
since this quirk was designed for another purpose. Instead introduce the
new SDHCI_QUIRK_BROKEN_HISPD_MODE quirk.

 drivers/mmc/sdhci.c | 8 
 include/sdhci.h | 6 ++
 2 files changed, 14 insertions(+)

diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index d31793a..2df4214 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -465,6 +465,9 @@ static int sdhci_set_ios(struct mmc *mmc)
if (host->quirks & SDHCI_QUIRK_NO_HISPD_BIT)
ctrl &= ~SDHCI_CTRL_HISPD;
 
+   if (host->quirks & SDHCI_QUIRK_BROKEN_HISPD_MODE)
+   ctrl &= ~SDHCI_CTRL_HISPD;
+
sdhci_writeb(host, ctrl, SDHCI_HOST_CONTROL);
 
/* If available, call the driver specific "post" set_ios() function */
@@ -602,6 +605,11 @@ int sdhci_setup_cfg(struct mmc_config *cfg, struct 
sdhci_host *host,
cfg->host_caps &= ~MMC_MODE_8BIT;
}
 
+   if (host->quirks & SDHCI_QUIRK_BROKEN_HISPD_MODE) {
+   cfg->host_caps &= ~MMC_MODE_HS;
+   cfg->host_caps &= ~MMC_MODE_HS_52MHz;
+   }
+
if (host->host_caps)
cfg->host_caps |= host->host_caps;
 
diff --git a/include/sdhci.h b/include/sdhci.h
index 7e84012..9c75d08 100644
--- a/include/sdhci.h
+++ b/include/sdhci.h
@@ -213,6 +213,12 @@
 #define SDHCI_QUIRK_BROKEN_R1B (1 << 2)
 #define SDHCI_QUIRK_NO_HISPD_BIT   (1 << 3)
 #define SDHCI_QUIRK_BROKEN_VOLTAGE (1 << 4)
+/*
+ * SDHCI_QUIRK_BROKEN_HISPD_MODE
+ * the hardware cannot operate correctly in high-speed mode,
+ * this quirk forces the sdci host-controller to non high-speed mode
+ */
+#define SDHCI_QUIRK_BROKEN_HISPD_MODE  BIT(5)
 #define SDHCI_QUIRK_WAIT_SEND_CMD  (1 << 6)
 #define SDHCI_QUIRK_USE_WIDE8  (1 << 8)
 
-- 
2.7.4


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

[U-Boot] Question related to flash organisation

[Christophe LEROY]

On my powerpc 8xx board, I have an AM29LV160DB boot flash which is 
organised as follows:

- One 16kb block
- Two 8kb block
- One 32kb block
- Thirty one 64kb blocks

At the time being, u-boot is a single piece occupying the 320 first 
kbytes, then the environment is stored in the following 64kb block


The environment being quite tiny, I would like to store it in one of the 
first small blocks. Is that feasible to have the startup .text stuff in 
the first 16k block, then a hole for the environment then the rest of 
.text after ?


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

Re: [U-Boot] [PATCH] spi: Zap mpc8xx_spi driver

[Christophe LEROY]

Le 26/02/2018 à 15:43, Jagan Teki a écrit :

- Driver not used by any boards


This driver should be used by MCR3000 board. For the time
being SPI is not activated on that board because we are struggling
with u-boot size. I'm working on re-activating SPI soon on this board.

I also have another board that I'm planing to include in the near 
future. That board stores ethernet addresses in an SPI E2PROM, so this

driver will be mandatory for it.

Therefore, please do not drop it now. It will be converted to DM before 
the deadline.


Christophe


- No update on 'dm conversion'

Signed-off-by: Jagan Teki 
---
  drivers/spi/Kconfig  |   6 -
  drivers/spi/Makefile |   1 -
  drivers/spi/mpc8xx_spi.c | 336 ---
  3 files changed, 343 deletions(-)
  delete mode 100644 drivers/spi/mpc8xx_spi.c

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 235a8c7d73..fd3f115ccf 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -274,12 +274,6 @@ config LPC32XX_SSP
help
  Enable support for SPI on LPC32xx
  
-config MPC8XX_SPI

-   bool "MPC8XX SPI Driver"
-   depends on 8xx
-   help
- Enable support for SPI on MPC8XX
-
  config MPC8XXX_SPI
bool "MPC8XXX SPI Driver"
help
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 4b6000fd9a..f104836630 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -31,7 +31,6 @@ obj-$(CONFIG_FSL_QSPI) += fsl_qspi.o
  obj-$(CONFIG_ICH_SPI) +=  ich.o
  obj-$(CONFIG_KIRKWOOD_SPI) += kirkwood_spi.o
  obj-$(CONFIG_LPC32XX_SSP) += lpc32xx_ssp.o
-obj-$(CONFIG_MPC8XX_SPI) += mpc8xx_spi.o
  obj-$(CONFIG_MPC8XXX_SPI) += mpc8xxx_spi.o
  obj-$(CONFIG_MVEBU_A3700_SPI) += mvebu_a3700_spi.o
  obj-$(CONFIG_MXC_SPI) += mxc_spi.o
diff --git a/drivers/spi/mpc8xx_spi.c b/drivers/spi/mpc8xx_spi.c
deleted file mode 100644
index b5bd558526..00
--- a/drivers/spi/mpc8xx_spi.c
+++ /dev/null
@@ -1,336 +0,0 @@
-/*
- * Copyright (c) 2001 Navin Boppuri / Prashant Patel
- * ,
- * 
- * Copyright (c) 2001 Gerd Mennchen 
- * Copyright (c) 2001 Wolfgang Denk, DENX Software Engineering, .
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-/*
- * MPC8xx CPM SPI interface.
- *
- * Parts of this code are probably not portable and/or specific to
- * the board which I used for the tests. Please send fixes/complaints
- * to w...@denx.de
- *
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#define SPI_EEPROM_WREN0x06
-#define SPI_EEPROM_RDSR0x05
-#define SPI_EEPROM_READ0x03
-#define SPI_EEPROM_WRITE   0x02
-
-/* ---
- * Offset for initial SPI buffers in DPRAM:
- * We need a 520 byte scratch DPRAM area to use at an early stage.
- * It is used between the two initialization calls (spi_init_f()
- * and spi_init_r()).
- * The value 0xb00 makes it far enough from the start of the data
- * area (as well as from the stack pointer).
- * --- */
-#ifndefCONFIG_SYS_SPI_INIT_OFFSET
-#defineCONFIG_SYS_SPI_INIT_OFFSET  0xB00
-#endif
-
-#define CPM_SPI_BASE_RXCPM_SPI_BASE
-#define CPM_SPI_BASE_TX(CPM_SPI_BASE + sizeof(cbd_t))
-
-/* ---
- * Function prototypes
- * --- */
-ssize_t spi_xfer(size_t);
-
-/* ---
- * Variables
- * --- */
-
-#define MAX_BUFFER 0x104
-
-/* --
- * Initially we place the RX and TX buffers at a fixed location in DPRAM!
- * -- */
-static uchar *rxbuf =
-   (uchar *)&((cpm8xx_t *)&((immap_t *)CONFIG_SYS_IMMR)->im_cpm)->cp_dpmem
-   [CONFIG_SYS_SPI_INIT_OFFSET];
-static uchar *txbuf =
-   (uchar *)&((cpm8xx_t *)&((immap_t *)CONFIG_SYS_IMMR)->im_cpm)->cp_dpmem
-   [CONFIG_SYS_SPI_INIT_OFFSET+MAX_BUFFER];
-
-/* **
- *
- *  Function:spi_init_f
- *
- *  Description: Init SPI-Controller (ROM part)
- *
- *  return:  ---
- *
- * *** */
-void spi_init_f(void)
-{
-   immap_t __iomem *immr = (immap_t __iomem *)CONFIG_SYS_IMMR;
-   cpm8xx_t __iomem *cp = >im_cpm;
-   spi_t __iomem *spi = (spi_t __iomem *)>cp_dparam[PROFF_SPI];
-   cbd_t __iomem *tbdf, *rbdf;
-
-   /* Disable relocation */
-   out_be16(>spi_rpbase, 0);
-
-/* 1 */
-   /* 
-* Initialize Port B SPI pins -> page 34-8 MPC860UM
-* (we are only in Master Mode 

[U-Boot] [PATCH v2 10/10] powerpc: mpc8xx: refactorise reginfo

[Christophe Leroy]

reginfo is redundant with some of the commands in immap.c, so
move reginfo into that file and remove duplicated info.

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/cpu/mpc8xx/Makefile  |  1 -
 arch/powerpc/cpu/mpc8xx/immap.c   | 20 +++
 arch/powerpc/cpu/mpc8xx/reginfo.c | 71 ---
 3 files changed, 20 insertions(+), 72 deletions(-)
 delete mode 100644 arch/powerpc/cpu/mpc8xx/reginfo.c

diff --git a/arch/powerpc/cpu/mpc8xx/Makefile b/arch/powerpc/cpu/mpc8xx/Makefile
index 40f38923ece..35ff18a7b3b 100644
--- a/arch/powerpc/cpu/mpc8xx/Makefile
+++ b/arch/powerpc/cpu/mpc8xx/Makefile
@@ -12,6 +12,5 @@ obj-y += cpu_init.o
 obj-$(CONFIG_OF_LIBFDT) += fdt.o
 obj-$(CONFIG_CMD_IMMAP) += immap.o
 obj-y  += interrupts.o
-obj-$(CONFIG_CMD_REGINFO) += reginfo.o
 obj-y  += speed.o
 obj-y  += cache.o
diff --git a/arch/powerpc/cpu/mpc8xx/immap.c b/arch/powerpc/cpu/mpc8xx/immap.c
index dfe5dc21251..7059a4eb063 100644
--- a/arch/powerpc/cpu/mpc8xx/immap.c
+++ b/arch/powerpc/cpu/mpc8xx/immap.c
@@ -342,6 +342,26 @@ static int do_brginfo(cmd_tbl_t *cmdtp, int flag, int 
argc, char * const argv[])
return 0;
 }
 
+#ifdef CONFIG_CMD_REGINFO
+void print_reginfo(void)
+{
+   immap_t __iomem *immap  = (immap_t __iomem *)CONFIG_SYS_IMMR;
+   sit8xx_t __iomem *timers = >im_sit;
+
+   printf("\nSystem Configuration registers\n"
+   "\tIMMR\t0x%08X\n", mfspr(SPRN_IMMR));
+   do_siuinfo(NULL, 0, 0, NULL);
+
+   printf("Memory Controller Registers\n");
+   do_memcinfo(NULL, 0, 0, NULL);
+
+   printf("\nSystem Integration Timers\n");
+   printf("\tTBSCR\t0x%04X\tRTCSC\t0x%04X\n",
+  in_be16(>sit_tbscr), in_be16(>sit_rtcsc));
+   printf("\tPISCR\t0x%04X\n", in_be16(>sit_piscr));
+}
+#endif
+
 /***/
 
 U_BOOT_CMD(
diff --git a/arch/powerpc/cpu/mpc8xx/reginfo.c 
b/arch/powerpc/cpu/mpc8xx/reginfo.c
deleted file mode 100644
index 1f6e606e52a..000
--- a/arch/powerpc/cpu/mpc8xx/reginfo.c
+++ /dev/null
@@ -1,71 +0,0 @@
-/*
- * (C) Copyright 2000
- * Subodh Nijsure, SkyStream Networks, snijs...@skystream.com
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#include 
-#include 
-#include 
-#include 
-
-void print_reginfo(void)
-{
-   immap_t __iomem *immap  = (immap_t __iomem *)CONFIG_SYS_IMMR;
-   memctl8xx_t __iomem *memctl = >im_memctl;
-   sysconf8xx_t __iomem *sysconf = >im_siu_conf;
-   sit8xx_t __iomem *timers = >im_sit;
-
-   /* Hopefully more PowerPC  knowledgable people will add code to display
-* other useful registers
-*/
-
-   printf("\nSystem Configuration registers\n"
-   "\tIMMR\t0x%08X\n", mfspr(SPRN_IMMR));
-
-   printf("\tSIUMCR\t0x%08X", in_be32(>sc_siumcr));
-   printf("\tSYPCR\t0x%08X\n", in_be32(>sc_sypcr));
-
-   printf("\tSWT\t0x%08X", in_be32(>sc_swt));
-   printf("\tSWSR\t0x%04X\n", in_be16(>sc_swsr));
-
-   printf("\tSIPEND\t0x%08X\tSIMASK\t0x%08X\n",
-  in_be32(>sc_sipend), in_be32(>sc_simask));
-   printf("\tSIEL\t0x%08X\tSIVEC\t0x%08X\n",
-  in_be32(>sc_siel), in_be32(>sc_sivec));
-   printf("\tTESR\t0x%08X\tSDCR\t0x%08X\n",
-  in_be32(>sc_tesr), in_be32(>sc_sdcr));
-
-   printf("Memory Controller Registers\n");
-   printf("\tBR0\t0x%08X\tOR0\t0x%08X\n", in_be32(>memc_br0),
-  in_be32(>memc_or0));
-   printf("\tBR1\t0x%08X\tOR1\t0x%08X\n", in_be32(>memc_br1),
-  in_be32(>memc_or1));
-   printf("\tBR2\t0x%08X\tOR2\t0x%08X\n", in_be32(>memc_br2),
-  in_be32(>memc_or2));
-   printf("\tBR3\t0x%08X\tOR3\t0x%08X\n", in_be32(>memc_br3),
-  in_be32(>memc_or3));
-   printf("\tBR4\t0x%08X\tOR4\t0x%08X\n", in_be32(>memc_br4),
-  in_be32(>memc_or4));
-   printf("\tBR5\t0x%08X\tOR5\t0x%08X\n", in_be32(>memc_br5),
-  in_be32(>memc_or5));
-   printf("\tBR6\t0x%08X\tOR6\t0x%08X\n", in_be32(>memc_br6),
-  in_be32(>memc_or6));
-   printf("\tBR7\t0x%08X\tOR7\t0x%08X\n", in_be32(>memc_br7),
-  in_be32(>memc_or7));
-   printf("\n\tmamr\t0x%08X\tmbmr\t0x%08X\n", in_be32(>memc_mamr),
-  in_be32(>memc_mbmr));
-   printf("\tmstat\t0x%04X\tmptpr\t0x%04X\n", in_be16(>memc_mstat),
-  in_be16(>memc_mptpr));
-   printf("\tmdr\t0x%08X\n", in_be32(>memc_mdr));
-
-   printf("\nSystem Integration Timers\n");
-   printf("\tTBSCR\t0x%04X\tRTCSC\t0x%04X\n",
-  in_be16(>sit_tbscr), in_be16(>sit_rtcsc));
-   printf("\tPISCR\t0x%04X\n", in_be16(>sit_piscr));
-
-   /*
-* May be some CPM info here?
-*/
-}
-- 
2.13.3

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

[U-Boot] [PATCH v2 04/10] soft_i2c: cleanup - no mpc8xx support

[Christophe Leroy]

commit 907208c452999 ("powerpc: Partialy restore core of mpc8xx")
didn't bring back support for I2C on the mpc8xx

Signed-off-by: Christophe Leroy 
---
 drivers/i2c/soft_i2c.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/i2c/soft_i2c.c b/drivers/i2c/soft_i2c.c
index 4fd5551a228..cc9c5ef356f 100644
--- a/drivers/i2c/soft_i2c.c
+++ b/drivers/i2c/soft_i2c.c
@@ -25,9 +25,6 @@
 #include 
 #endif
 #endif
-#if defined(CONFIG_8xx)
-#include 
-#endif
 #include 
 
 #if defined(CONFIG_SOFT_I2C_GPIO_SCL)
-- 
2.13.3

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

[U-Boot] [PATCH v2 07/10] powerpc: mpc8xx: get rid of get_immr()

[Christophe Leroy]

Function get_immr() is almost not used and doesn't bring much
added value. Just replace it with mfspr(SPRN_IMMR) at the two
needed places.

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/cpu/mpc8xx/cpu.c | 7 +++
 arch/powerpc/cpu/mpc8xx/reginfo.c | 2 +-
 arch/powerpc/cpu/mpc8xx/speed.c   | 3 +--
 arch/powerpc/include/asm/ppc.h| 8 
 4 files changed, 5 insertions(+), 15 deletions(-)

diff --git a/arch/powerpc/cpu/mpc8xx/cpu.c b/arch/powerpc/cpu/mpc8xx/cpu.c
index 1883440db34..0eabb714d31 100644
--- a/arch/powerpc/cpu/mpc8xx/cpu.c
+++ b/arch/powerpc/cpu/mpc8xx/cpu.c
@@ -36,7 +36,7 @@ DECLARE_GLOBAL_DATA_PTR;
 
 static int check_CPU(long clock, uint pvr, uint immr)
 {
-   immap_t __iomem *immap = (immap_t __iomem *)(immr & 0x);
+   immap_t __iomem *immap = (immap_t __iomem *)CONFIG_SYS_IMMR;
uint k;
char buf[32];
 
@@ -90,7 +90,7 @@ static int check_CPU(long clock, uint pvr, uint immr)
 int checkcpu(void)
 {
ulong clock = gd->cpu_clk;
-   uint immr = get_immr(0);/* Return full IMMR contents */
+   uint immr = mfspr(SPRN_IMMR);   /* Return full IMMR contents */
uint pvr = get_pvr();
 
puts("CPU:   ");
@@ -237,8 +237,7 @@ int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * 
const argv[])
  */
 unsigned long get_tbclk(void)
 {
-   uint immr = get_immr(0);/* Return full IMMR contents */
-   immap_t __iomem *immap = (immap_t __iomem *)(immr & 0x);
+   immap_t __iomem *immap = (immap_t __iomem *)CONFIG_SYS_IMMR;
ulong oscclk, factor, pll;
 
if (in_be32(>im_clkrst.car_sccr) & SCCR_TBS)
diff --git a/arch/powerpc/cpu/mpc8xx/reginfo.c 
b/arch/powerpc/cpu/mpc8xx/reginfo.c
index 277d2753b25..1f6e606e52a 100644
--- a/arch/powerpc/cpu/mpc8xx/reginfo.c
+++ b/arch/powerpc/cpu/mpc8xx/reginfo.c
@@ -22,7 +22,7 @@ void print_reginfo(void)
 */
 
printf("\nSystem Configuration registers\n"
-   "\tIMMR\t0x%08X\n", get_immr(0));
+   "\tIMMR\t0x%08X\n", mfspr(SPRN_IMMR));
 
printf("\tSIUMCR\t0x%08X", in_be32(>sc_siumcr));
printf("\tSYPCR\t0x%08X\n", in_be32(>sc_sypcr));
diff --git a/arch/powerpc/cpu/mpc8xx/speed.c b/arch/powerpc/cpu/mpc8xx/speed.c
index fa8f87cbc5e..f8eb4a13eaf 100644
--- a/arch/powerpc/cpu/mpc8xx/speed.c
+++ b/arch/powerpc/cpu/mpc8xx/speed.c
@@ -17,8 +17,7 @@ DECLARE_GLOBAL_DATA_PTR;
  */
 int get_clocks(void)
 {
-   uint immr = get_immr(0);/* Return full IMMR contents */
-   immap_t __iomem *immap = (immap_t __iomem *)(immr & 0x);
+   immap_t __iomem *immap = (immap_t __iomem *)CONFIG_SYS_IMMR;
uint sccr = in_be32(>im_clkrst.car_sccr);
uint divider = 1 << (((sccr & SCCR_DFBRG11) >> 11) * 2);
 
diff --git a/arch/powerpc/include/asm/ppc.h b/arch/powerpc/include/asm/ppc.h
index 5e0aa08be93..db289ed7072 100644
--- a/arch/powerpc/include/asm/ppc.h
+++ b/arch/powerpc/include/asm/ppc.h
@@ -40,14 +40,6 @@
 
 #include 
 
-#if defined(CONFIG_8xx)
-static inline uint get_immr(uint mask)
-{
-   uint immr = mfspr(SPRN_IMMR);
-
-   return mask ? (immr & mask) : immr;
-}
-#endif
 static inline uint get_pvr(void)
 {
return mfspr(PVR);
-- 
2.13.3

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

[U-Boot] [PATCH v2 08/10] powerpc: mpc8xx: Change CONFIG_8xx to CONFIG_MPC8xx

[Christophe Leroy]

CONFIG_8xx doesn't mean much outside of arch/powerpc/
This patch renames it CONFIG_MPC8xx just like CONFIG_MPC85xx etc ...
It also renames 8xx_immap.h to immap_8xx.h to be consistent with
other file names.

Signed-off-by: Christophe Leroy 
---
 api/api_platform-powerpc.c| 2 +-
 arch/powerpc/Kconfig  | 2 +-
 arch/powerpc/cpu/mpc8xx/Kconfig   | 2 +-
 arch/powerpc/cpu/mpc8xx/immap.c   | 2 +-
 arch/powerpc/include/asm/cache.h  | 6 +++---
 arch/powerpc/include/asm/global_data.h| 2 +-
 arch/powerpc/include/asm/{8xx_immap.h => immap_8xx.h} | 0
 arch/powerpc/include/asm/iopin_8xx.h  | 2 +-
 arch/powerpc/include/asm/ppc.h| 4 ++--
 cmd/bdinfo.c  | 2 +-
 configs/MCR3000_defconfig | 2 +-
 drivers/net/Kconfig   | 2 +-
 drivers/serial/Kconfig| 2 +-
 drivers/spi/Kconfig   | 2 +-
 include/asm-generic/u-boot.h  | 2 +-
 include/commproc.h| 2 +-
 include/mpc8xx.h  | 4 ++--
 include/ppc_asm.tmpl  | 6 +++---
 18 files changed, 23 insertions(+), 23 deletions(-)
 rename arch/powerpc/include/asm/{8xx_immap.h => immap_8xx.h} (100%)

diff --git a/api/api_platform-powerpc.c b/api/api_platform-powerpc.c
index 9e9bc63b2f5..aae7ddee959 100644
--- a/api/api_platform-powerpc.c
+++ b/api/api_platform-powerpc.c
@@ -30,7 +30,7 @@ int platform_sys_info(struct sys_info *si)
si->clk_bus = gd->bus_clk;
si->clk_cpu = gd->cpu_clk;
 
-#if defined(CONFIG_8xx) || defined(CONFIG_E500) || defined(CONFIG_MPC86xx)
+#if defined(CONFIG_MPC8xx) || defined(CONFIG_E500) || defined(CONFIG_MPC86xx)
 #define bi_bar bi_immr_base
 #elif defined(CONFIG_MPC83xx)
 #define bi_bar bi_immrbar
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index b20837b473f..af45cfe8498 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -30,7 +30,7 @@ config MPC86xx
select SYS_FSL_DDR_BE
imply CMD_REGINFO
 
-config 8xx
+config MPC8xx
bool "MPC8xx"
select BOARD_EARLY_INIT_F
imply CMD_REGINFO
diff --git a/arch/powerpc/cpu/mpc8xx/Kconfig b/arch/powerpc/cpu/mpc8xx/Kconfig
index 5a7db335ed2..f1123173765 100644
--- a/arch/powerpc/cpu/mpc8xx/Kconfig
+++ b/arch/powerpc/cpu/mpc8xx/Kconfig
@@ -1,5 +1,5 @@
 menu "mpc8xx CPU"
-   depends on 8xx
+   depends on MPC8xx
 
 config SYS_CPU
default "mpc8xx"
diff --git a/arch/powerpc/cpu/mpc8xx/immap.c b/arch/powerpc/cpu/mpc8xx/immap.c
index 2284979dd65..dfe5dc21251 100644
--- a/arch/powerpc/cpu/mpc8xx/immap.c
+++ b/arch/powerpc/cpu/mpc8xx/immap.c
@@ -12,7 +12,7 @@
 #include 
 #include 
 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/powerpc/include/asm/cache.h b/arch/powerpc/include/asm/cache.h
index 0801d2c3677..445a366807d 100644
--- a/arch/powerpc/include/asm/cache.h
+++ b/arch/powerpc/include/asm/cache.h
@@ -7,7 +7,7 @@
 #include 
 
 /* bytes per L1 cache line */
-#if defined(CONFIG_8xx)
+#if defined(CONFIG_MPC8xx)
 #defineL1_CACHE_SHIFT  4
 #elif defined(CONFIG_PPC64BRIDGE)
 #define L1_CACHE_SHIFT 7
@@ -72,7 +72,7 @@ void disable_cpc_sram(void);
 #define L2CACHE_NONE   0x03/* NONE */
 #define L2CACHE_PARITY  0x08/* Mask for L2 Cache Parity Protected bit */
 
-#ifdef CONFIG_8xx
+#ifdef CONFIG_MPC8xx
 /* Cache control on the MPC8xx is provided through some additional
  * special purpose registers.
  */
@@ -139,6 +139,6 @@ static inline void wr_dc_adr(uint val)
mtspr(DC_ADR, val);
 }
 #endif
-#endif /* CONFIG_8xx */
+#endif /* CONFIG_MPC8xx */
 
 #endif
diff --git a/arch/powerpc/include/asm/global_data.h 
b/arch/powerpc/include/asm/global_data.h
index 35a02b61a44..016dc19cb4c 100644
--- a/arch/powerpc/include/asm/global_data.h
+++ b/arch/powerpc/include/asm/global_data.h
@@ -19,7 +19,7 @@ struct arch_global_data {
u8 sdhc_adapter;
 #endif
 #endif
-#if defined(CONFIG_8xx)
+#if defined(CONFIG_MPC8xx)
unsigned long brg_clk;
 #endif
 #if defined(CONFIG_CPM2)
diff --git a/arch/powerpc/include/asm/8xx_immap.h 
b/arch/powerpc/include/asm/immap_8xx.h
similarity index 100%
rename from arch/powerpc/include/asm/8xx_immap.h
rename to arch/powerpc/include/asm/immap_8xx.h
diff --git a/arch/powerpc/include/asm/iopin_8xx.h 
b/arch/powerpc/include/asm/iopin_8xx.h
index 15679a2db55..3b4e1b64a41 100644
--- a/arch/powerpc/include/asm/iopin_8xx.h
+++ b/arch/powerpc/include/asm/iopin_8xx.h
@@ -11,7 +11,7 @@
 #define _ASM_IOPIN_8XX_H_
 
 #include 
-#include 
+#include 
 #include 
 
 #ifdef __KERNEL__
diff --git a/arch/powerpc/include/asm/ppc.h b/arch/powerpc/include/asm/ppc.h
index db289ed7072..ec7adddc5e3 100644
--- 

[U-Boot] [PATCH v2 09/10] powerpc: 8xx: get rid of the multiple PVR_ values

[Christophe Leroy]

None of those values are used at the time being.
Just keep one and call it PVR_8xx

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/include/asm/processor.h | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/include/asm/processor.h 
b/arch/powerpc/include/asm/processor.h
index 57b11b83657..6fbe8c46b31 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -973,10 +973,8 @@
  * differentiated by the version number in the Communication Processor
  * Module (CPM).
  */
-#define PVR_8210x0050
-#define PVR_823PVR_821
-#define PVR_850PVR_821
-#define PVR_860PVR_821
+#define PVR_8xx0x0050
+
 #define PVR_7400   0x000C
 
 /*
-- 
2.13.3

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

[U-Boot] [PATCH v2 05/10] boards: MCR3000: cleanup config

[Christophe Leroy]

Some config is redundant with Kconfig. Fix it.
Also remove unused configs
Move SDRAM_MAX_SIZE in the only place it is used

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/Kconfig |  1 +
 board/cssi/MCR3000/MCR3000.c |  2 ++
 configs/MCR3000_defconfig|  2 ++
 include/configs/MCR3000.h| 22 --
 4 files changed, 5 insertions(+), 22 deletions(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index e4b3043fa22..3a2653ff0d3 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -32,6 +32,7 @@ config MPC86xx
 
 config 8xx
bool "MPC8xx"
+   select BOARD_EARLY_INIT_F
imply CMD_REGINFO
 
 endchoice
diff --git a/board/cssi/MCR3000/MCR3000.c b/board/cssi/MCR3000/MCR3000.c
index c9288818049..6939a2cf617 100644
--- a/board/cssi/MCR3000/MCR3000.c
+++ b/board/cssi/MCR3000/MCR3000.c
@@ -16,6 +16,8 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
+#define SDRAM_MAX_SIZE (32 * 1024 * 1024)
+
 static const uint cs1_dram_table_66[] = {
/* DRAM - single read. (offset 0 in upm RAM) */
0x0F3DFC04, 0x0FEFBC04, 0x00BE7804, 0x0FFDF400,
diff --git a/configs/MCR3000_defconfig b/configs/MCR3000_defconfig
index 108cf00154a..6a29f9de1ef 100644
--- a/configs/MCR3000_defconfig
+++ b/configs/MCR3000_defconfig
@@ -71,3 +71,5 @@ CONFIG_MPC8XX_FEC=y
 CONFIG_SHA256=y
 CONFIG_LZMA=y
 CONFIG_OF_LIBFDT=y
+CONFIG_USE_BOOTCOMMAND=y
+CONFIG_BOOTCOMMAND="run flashboot"
diff --git a/include/configs/MCR3000.h b/include/configs/MCR3000.h
index 29e61c7c222..ab90ea20d8f 100644
--- a/include/configs/MCR3000.h
+++ b/include/configs/MCR3000.h
@@ -9,7 +9,6 @@
 #define __CONFIG_H
 
 /* High Level Configuration Options */
-#define CONFIG_BOARD_EARLY_INIT_F  1   /* Call board_early_init_f */
 #define CONFIG_MISC_INIT_R 1   /* Call misc_init_r */
 
 #define CONFIG_EXTRA_ENV_SETTINGS  \
@@ -55,25 +54,16 @@
"${ofl_args}; " \
"bootm ${loadaddr} - 0xf0\0"
 
-#define CONFIG_BOOTDELAY   5
-
 #define CONFIG_IPADDR  192.168.0.3
 #define CONFIG_SERVERIP192.168.0.1
 #define CONFIG_NETMASK 255.0.0.0
 
-#define CONFIG_BOOTCOMMAND "run flashboot"
-
 #define CONFIG_LOADS_ECHO  1   /* echo on for serial download  */
-#undef CONFIG_LOADS_BAUD_CHANGE/* don't allow baudrate change  */
 
 #define CONFIG_WATCHDOG1   /* watchdog enabled */
 
 /* Miscellaneous configurable options */
 
-#ifdef CONFIG_HUSH_PARSER
-#defineCONFIG_SYS_PROMPT_HUSH_PS2  "S3K> "
-#endif
-
 #define CONFIG_SYS_MEMTEST_START   0x2000
 #define CONFIG_SYS_MEMTEST_END 0x0080
 
@@ -91,7 +81,6 @@
 
 /* RAM configuration (note that CONFIG_SYS_SDRAM_BASE must be zero) */
 #defineCONFIG_SYS_SDRAM_BASE   0x
-#define SDRAM_MAX_SIZE (32 * 1024 * 1024)
 
 /* FLASH organization */
 #define CONFIG_SYS_FLASH_BASE  CONFIG_SYS_TEXT_BASE
@@ -121,24 +110,13 @@
 #define CONFIG_ENV_OFFSET  (CONFIG_ENV_ADDR - CONFIG_SYS_FLASH_BASE)
 #define CONFIG_ENV_OVERWRITE   1
 
-/* Cache Configuration */
-#define CONFIG_SYS_CACHELINE_SIZE  16
-
 /* Ethernet configuration part */
 #define CONFIG_SYS_DISCOVER_PHY1
-#ifdef CONFIG_MPC8XX_FEC
 #define CONFIG_MII_INIT1
-#endif
 
 /* NAND configuration part */
 #define CONFIG_SYS_MAX_NAND_DEVICE 1
 #define CONFIG_SYS_NAND_MAX_CHIPS  1
 #define CONFIG_SYS_NAND_BASE   0x0C00
 
-/* Internal Definitions */
-
-/* Boot Flags*/
-#defineBOOTFLAG_COLD   0x01
-#define BOOTFLAG_WARM  0x02
-
 #endif /* __CONFIG_H */
-- 
2.13.3

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

[U-Boot] [PATCH v2 06/10] powerpc: mpc8xx: cleaning up watchdog

[Christophe Leroy]

In preparation of migration to DM watchdog, clean up a bit.

The 8xx watchdog really is a HW watchdog, so declare it as is
then it goes through Kconfig

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/Kconfig   |  1 +
 arch/powerpc/cpu/mpc8xx/cpu.c  | 20 +---
 arch/powerpc/cpu/mpc8xx/cpu_init.c |  4 +---
 include/configs/MCR3000.h  |  2 --
 include/watchdog.h |  5 -
 5 files changed, 7 insertions(+), 25 deletions(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 3a2653ff0d3..b20837b473f 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -34,6 +34,7 @@ config 8xx
bool "MPC8xx"
select BOARD_EARLY_INIT_F
imply CMD_REGINFO
+   imply HW_WATCHDOG
 
 endchoice
 
diff --git a/arch/powerpc/cpu/mpc8xx/cpu.c b/arch/powerpc/cpu/mpc8xx/cpu.c
index 1e0ea28a918..1883440db34 100644
--- a/arch/powerpc/cpu/mpc8xx/cpu.c
+++ b/arch/powerpc/cpu/mpc8xx/cpu.c
@@ -273,26 +273,16 @@ unsigned long get_tbclk(void)
 
 /* - */
 
-#if defined(CONFIG_WATCHDOG)
-void watchdog_reset(void)
+#if defined(CONFIG_HW_WATCHDOG)
+void hw_watchdog_reset(void)
 {
+   immap_t __iomem *immr = (immap_t __iomem *)CONFIG_SYS_IMMR;
int re_enable = disable_interrupts();
 
-   reset_8xx_watchdog((immap_t __iomem *)CONFIG_SYS_IMMR);
-   if (re_enable)
-   enable_interrupts();
-}
-#endif /* CONFIG_WATCHDOG */
-
-#if defined(CONFIG_WATCHDOG)
-
-void reset_8xx_watchdog(immap_t __iomem *immr)
-{
-   /*
-* All other boards use the MPC8xx Internal Watchdog
-*/
out_be16(>im_siu_conf.sc_swsr, 0x556c);   /* write magic1 */
out_be16(>im_siu_conf.sc_swsr, 0xaa39);   /* write magic2 */
+   if (re_enable)
+   enable_interrupts();
 }
 #endif /* CONFIG_WATCHDOG */
 
diff --git a/arch/powerpc/cpu/mpc8xx/cpu_init.c 
b/arch/powerpc/cpu/mpc8xx/cpu_init.c
index 3c9c4b19753..654d559eeb8 100644
--- a/arch/powerpc/cpu/mpc8xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc8xx/cpu_init.c
@@ -34,9 +34,7 @@ void cpu_init_f(immap_t __iomem *immr)
 
out_be32(>im_siu_conf.sc_sypcr, CONFIG_SYS_SYPCR);
 
-#if defined(CONFIG_WATCHDOG)
-   reset_8xx_watchdog(immr);
-#endif /* CONFIG_WATCHDOG */
+   WATCHDOG_RESET();
 
/* SIUMCR - contains debug pin configuration (11-6) */
setbits_be32(>im_siu_conf.sc_siumcr, CONFIG_SYS_SIUMCR);
diff --git a/include/configs/MCR3000.h b/include/configs/MCR3000.h
index ab90ea20d8f..9a89089a504 100644
--- a/include/configs/MCR3000.h
+++ b/include/configs/MCR3000.h
@@ -60,8 +60,6 @@
 
 #define CONFIG_LOADS_ECHO  1   /* echo on for serial download  */
 
-#define CONFIG_WATCHDOG1   /* watchdog enabled */
-
 /* Miscellaneous configurable options */
 
 #define CONFIG_SYS_MEMTEST_START   0x2000
diff --git a/include/watchdog.h b/include/watchdog.h
index 64b59f107ad..52f4c506b04 100644
--- a/include/watchdog.h
+++ b/include/watchdog.h
@@ -72,11 +72,6 @@ int init_func_watchdog_reset(void);
  * Prototypes from $(CPU)/cpu.c.
  */
 
-/* MPC 8xx */
-#if defined(CONFIG_8xx) && !defined(__ASSEMBLY__)
-   void reset_8xx_watchdog(immap_t __iomem *immr);
-#endif
-
 #if defined(CONFIG_HW_WATCHDOG) && !defined(__ASSEMBLY__)
void hw_watchdog_init(void);
 #endif
-- 
2.13.3

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

[U-Boot] [PATCH v2 03/10] board: MCR3000: Increase Monitor size

[Christophe Leroy]

U-boot doesn't fit anymore in a 256kb area, increase it to 320kb

Signed-off-by: Christophe Leroy 
---
 include/configs/MCR3000.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/configs/MCR3000.h b/include/configs/MCR3000.h
index 6b03873ce87..29e61c7c222 100644
--- a/include/configs/MCR3000.h
+++ b/include/configs/MCR3000.h
@@ -25,7 +25,7 @@
"ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:" \
"mcr3k:eth0:off;"   \
"${ofl_args}; " \
-   "bootm 0x0406 - 0x0405\0"   \
+   "bootm 0x0407 - 0x0406\0"   \
"tftpboot=setenv bootargs " \
"${console_args} "  \
"ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:" \
@@ -46,7 +46,7 @@
"${console_args} "  \
"ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:" \
"mcr3k:eth0:off;"   \
-   "bootm 0x0406 - 0x0405\0"   \
+   "bootm 0x0407 - 0x0406\0"   \
"dhcpboot=dhcp ${loadaddr} ${filename};"\
"tftp 0xf0 mcr3000.dtb;"\
"setenv bootargs "  \
@@ -108,7 +108,7 @@
  * the maximum mapped by the Linux kernel during initialization.
  */
 #defineCONFIG_SYS_BOOTMAPSZ(8 << 20)
-#defineCONFIG_SYS_MONITOR_LEN  (256 << 10)
+#defineCONFIG_SYS_MONITOR_LEN  (320 << 10)
 #define CONFIG_SYS_MONITOR_BASECONFIG_SYS_TEXT_BASE
 #define CONFIG_SYS_MALLOC_LEN  (4096 << 10)
 
-- 
2.13.3

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

[U-Boot] [PATCH v2 02/10] board: MCR3000: replace mtd->priv by mtd_to_nand()

[Christophe Leroy]

Since commit 17cb4b8f327eb ("mtd: nand: Add+use mtd_to/from_nand and
nand_get/set_controller_data"), mtd_to_nand() has to be used instead
of mtd->priv

Signed-off-by: Christophe Leroy 
---
 board/cssi/MCR3000/nand.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/cssi/MCR3000/nand.c b/board/cssi/MCR3000/nand.c
index 8e5b0d0618f..4c6fc865f23 100644
--- a/board/cssi/MCR3000/nand.c
+++ b/board/cssi/MCR3000/nand.c
@@ -17,7 +17,7 @@
 
 static void nand_hwcontrol(struct mtd_info *mtdinfo, int cmd, unsigned int 
ctrl)
 {
-   struct nand_chip *this  = mtdinfo->priv;
+   struct nand_chip *this  = mtd_to_nand(mtdinfo);
immap_t __iomem *immr   = (immap_t __iomem *)CONFIG_SYS_IMMR;
unsigned short pddat= 0;
 
-- 
2.13.3

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

[U-Boot] [PATCH v2 01/10] powerpc: mpc8xx: initialisation of global data

[Christophe Leroy]

Global data pointer has to be initialised
Global data area has to be zeroised

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/cpu/mpc8xx/cpu_init.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/powerpc/cpu/mpc8xx/cpu_init.c 
b/arch/powerpc/cpu/mpc8xx/cpu_init.c
index dc601a12976..3c9c4b19753 100644
--- a/arch/powerpc/cpu/mpc8xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc8xx/cpu_init.c
@@ -12,6 +12,8 @@
 #include 
 #include 
 
+DECLARE_GLOBAL_DATA_PTR;
+
 /*
  * Breath some life into the CPU...
  *
@@ -24,6 +26,10 @@ void cpu_init_f(immap_t __iomem *immr)
memctl8xx_t __iomem *memctl = >im_memctl;
ulong reg;
 
+   gd = (gd_t *)(CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_GBL_DATA_OFFSET);
+   /* Clear initial global data */
+   memset((void *)gd, 0, sizeof(*gd));
+
/* SYPCR - contains watchdog control (11-9) */
 
out_be32(>im_siu_conf.sc_sypcr, CONFIG_SYS_SYPCR);
-- 
2.13.3

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

[U-Boot] [PATCH v2 00/10] Powerpc: mpc8xx: cleanup before migration to DM model

[Christophe Leroy]

The purpose of this serie is to clean the mpc8xx code a bit prior to moving
to OF and DM model.

Christophe Leroy (10):
  powerpc: mpc8xx: initialisation of global data
  board: MCR3000: replace mtd->priv by mtd_to_nand()
  board: MCR3000: Increase Monitor size
  soft_i2c: cleanup - no mpc8xx support
  boards: MCR3000: cleanup config
  powerpc: mpc8xx: cleaning up watchdog
  powerpc: mpc8xx: get rid of get_immr()
  powerpc: mpc8xx: Change CONFIG_8xx to CONFIG_MPC8xx
  powerpc: 8xx: get rid of the multiple PVR_ values
  powerpc: mpc8xx: refactorise reginfo

 api/api_platform-powerpc.c |  2 +-
 arch/powerpc/Kconfig   |  4 +-
 arch/powerpc/cpu/mpc8xx/Kconfig|  2 +-
 arch/powerpc/cpu/mpc8xx/Makefile   |  1 -
 arch/powerpc/cpu/mpc8xx/cpu.c  | 27 +++-
 arch/powerpc/cpu/mpc8xx/cpu_init.c | 10 ++-
 arch/powerpc/cpu/mpc8xx/immap.c| 22 ++-
 arch/powerpc/cpu/mpc8xx/reginfo.c  | 71 --
 arch/powerpc/cpu/mpc8xx/speed.c|  3 +-
 arch/powerpc/include/asm/cache.h   |  6 +-
 arch/powerpc/include/asm/global_data.h |  2 +-
 .../include/asm/{8xx_immap.h => immap_8xx.h}   |  0
 arch/powerpc/include/asm/iopin_8xx.h   |  2 +-
 arch/powerpc/include/asm/ppc.h | 12 +---
 arch/powerpc/include/asm/processor.h   |  6 +-
 board/cssi/MCR3000/MCR3000.c   |  2 +
 board/cssi/MCR3000/nand.c  |  2 +-
 cmd/bdinfo.c   |  2 +-
 configs/MCR3000_defconfig  |  4 +-
 drivers/i2c/soft_i2c.c |  3 -
 drivers/net/Kconfig|  2 +-
 drivers/serial/Kconfig |  2 +-
 drivers/spi/Kconfig|  2 +-
 include/asm-generic/u-boot.h   |  2 +-
 include/commproc.h |  2 +-
 include/configs/MCR3000.h  | 30 +
 include/mpc8xx.h   |  4 +-
 include/ppc_asm.tmpl   |  6 +-
 include/watchdog.h |  5 --
 29 files changed, 71 insertions(+), 167 deletions(-)
 delete mode 100644 arch/powerpc/cpu/mpc8xx/reginfo.c
 rename arch/powerpc/include/asm/{8xx_immap.h => immap_8xx.h} (100%)

-- 
2.13.3

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

Re: [U-Boot] [UBOOT PATCH v2 2/2] arm64: zynqmp: mmc: Added Kconfig support for CONFIG_ZYNQ_SDHCI1

[Michal Simek]

On 2.3.2018 10:01, Jaehoon Chung wrote:
> On 03/02/2018 04:44 PM, Michal Simek wrote:
>> On 2.3.2018 07:27, Jaehoon Chung wrote:
>>> On 03/02/2018 12:13 AM, Michal Simek wrote:
 On 28.2.2018 08:42, Jaehoon Chung wrote:
> Hi,
>
> On 02/28/2018 03:28 PM, Vipul Kumar wrote:
>> This patch added Kconfig support for CONFIG_ZYNQ_SDHCI1 and
>> enabled it in defconfig.
>
> I think that CONFIG_ZYNQ_SDHCI1 is meaningful when CONFIG_ZYNQ_SDHCI0 is 
> enabled.
> It's used in zynqmp.c and spl.c ..like below..
>
> #if defined(CONFIG_ZYNQ_SDHCI0) && defined(CONFIG_ZYNQ_SDHCI1)
> 
> #endif
>
> If CONFIG_ZYNQ_SDHCI0 isn't enabled, doesn't it need to set 
> CONFIG_ZYNQ_SDHCI1 in defconfigs.
>
> If i missed something, let me know, plz.

 you are right. Dependency should be

 config ZYNQ_SDHCI1
...
depends on ZYNQ_SDHCI0
>>>
>>> Hmm. I didn't check fully, but it seems that it's possible to use only one 
>>> config.
>>> I will check in more detail. After that, resend the email. :)
>>
>> I can't also see any issue with using just one symbol with proper name.
> 
> Maybe you know more than me about zynq boards.
> In SPL, it seems that it needs to add some config in spl.c for distinguishing 
> boot device.
> But in not SPL, if zynq boards are supported the device-tree, then can you 
> use the below concept?
> 
> commit 02ad33aa3a84821c8d9a6c4f167f143f6248b084
> Author: Jaehoon Chung 
> Date:   Thu Feb 2 13:41:14 2017 +0900
> 
> mmc: mmc-uclass: use the fixed devnum with alias node
> 
> If there are alias nodes as "mmc", use the devnum as alias index
> number.
> This patch is for fixing a problem of Exynos4 series.
> Problem is the below thing.
> 
> Current legacy mode:
> EXYNOS DWMMC: 0, SAMSUNG SDHCI: 1
> 
> After using DM:
> SAMSUNG SDHCI: 0, EXYNOS DWMMC: 1
> 
> Dev index is swapped.
> Then u-boot can't find the kernel image..because it is already set to 0 
> as mmcdev.
> If change from legacy to DM, also needs to touch all exynos4 config file.
> For using simply, just supporting the fixed devnum with alias node is 
> better than it.
> 
> Usage:
> alaise {
> 
> mmc0 =  /* eMMC */
> mmc1 =  /* SD */
> ...
> }
> 

Chips are supporting booting from SD0 or SD1 controller.

#define SD_MODE 0x0003 /* sd 0 */
#define SD_MODE10x0005 /* sd 1 */
#define EMMC_MODE   0x0006
#define SD1_LSHFT_MODE  0x000E /* SD1 Level shifter */

It means on systems which has only sd0 or sd1 we are setting up alias as
mmc0 =  (sd0)
or
mmc0 =  (sd1)

It means dev 0 is used all the time.

In case of system with both controllers on the same board you need to
have two aliases. Normally like this.
mmc0 =  (sd0)
mmc1 =  (sd1)

In case you choose to boot from sd1 default behavior should be that all
images are on sd1 that's why boot device needs to be setup.
When you load the same u-boot to sd0 it should boot from sd0.

Changing aliases for certain boot mode configuration should just work
but that's not intention. Normally the same boot files can be loaded to
sd, qspi, nand, jtag, you setup boot mode and they should primary boot
from that boot device and that's what that logic is about.

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

Re: [U-Boot] [PATCH] watchdog: omap_wdt: improve watchdog reset path

[Lokesh Vutla]

On Thursday 01 March 2018 06:45 AM, Ruslan Bilovol wrote:
> Remove busy looping during watchdog reset.
> Each polling of W_PEND_WTGR bit ("finish posted
> write") after watchdog reset takes 120-140us
> on BeagleBone Black board. Current U-Boot code
> has watchdog resets in random places and often
> there is situation when watchdog is reset
> few times in a row in nested functions.
> This adds extra delays and slows the whole system.
> 
> Instead of polling W_PEND_WTGR bit, we skip
> watchdog reset if the bit is set. Anyway, watchdog
> is in the middle of reset *right now*, so we can
> just return.
> 
> This noticeably increases performance of the
> system. Below are some measurements on BBB:
>  - DFU upload over USB 15% faster
>  - fastboot image upload   3x times faster
>  - USB ep0 transfers with 4k packets   20% faster
> 
> Signed-off-by: Ruslan Bilovol 


Thanks and regards,
Lokesh

> ---
>  drivers/watchdog/omap_wdt.c | 21 +++--
>  1 file changed, 15 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
> index 7b1f429..d724c96 100644
> --- a/drivers/watchdog/omap_wdt.c
> +++ b/drivers/watchdog/omap_wdt.c
> @@ -53,16 +53,25 @@ void hw_watchdog_reset(void)
>  {
>   struct wd_timer *wdt = (struct wd_timer *)WDT_BASE;
>  
> - /* wait for posted write to complete */
> - while ((readl(>wdtwwps)) & WDT_WWPS_PEND_WTGR)
> - ;
> + /*
> +  * Somebody just triggered watchdog reset and write to WTGR register
> +  * is in progress. It is resetting right now, no need to trigger it
> +  * again
> +  */
> + if ((readl(>wdtwwps)) & WDT_WWPS_PEND_WTGR)
> + return;
>  
>   wdt_trgr_pattern = ~wdt_trgr_pattern;
>   writel(wdt_trgr_pattern, >wdtwtgr);
>  
> - /* wait for posted write to complete */
> - while ((readl(>wdtwwps) & WDT_WWPS_PEND_WTGR))
> - ;
> + /*
> +  * Don't wait for posted write to complete, i.e. don't check
> +  * WDT_WWPS_PEND_WTGR bit in WWPS register. There is no writes to
> +  * WTGR register outside of this func, and if entering it
> +  * we see WDT_WWPS_PEND_WTGR bit set, it means watchdog reset
> +  * was just triggered. This prevents us from wasting time in busy
> +  * polling of WDT_WWPS_PEND_WTGR bit.
> +  */
>  }
>  
>  static int omap_wdt_set_timeout(unsigned int timeout)
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [UBOOT PATCH v2 2/2] arm64: zynqmp: mmc: Added Kconfig support for CONFIG_ZYNQ_SDHCI1

[Jaehoon Chung]

On 03/02/2018 04:44 PM, Michal Simek wrote:
> On 2.3.2018 07:27, Jaehoon Chung wrote:
>> On 03/02/2018 12:13 AM, Michal Simek wrote:
>>> On 28.2.2018 08:42, Jaehoon Chung wrote:
 Hi,

 On 02/28/2018 03:28 PM, Vipul Kumar wrote:
> This patch added Kconfig support for CONFIG_ZYNQ_SDHCI1 and
> enabled it in defconfig.

 I think that CONFIG_ZYNQ_SDHCI1 is meaningful when CONFIG_ZYNQ_SDHCI0 is 
 enabled.
 It's used in zynqmp.c and spl.c ..like below..

 #if defined(CONFIG_ZYNQ_SDHCI0) && defined(CONFIG_ZYNQ_SDHCI1)
 
 #endif

 If CONFIG_ZYNQ_SDHCI0 isn't enabled, doesn't it need to set 
 CONFIG_ZYNQ_SDHCI1 in defconfigs.

 If i missed something, let me know, plz.
>>>
>>> you are right. Dependency should be
>>>
>>> config ZYNQ_SDHCI1
>>> ...
>>> depends on ZYNQ_SDHCI0
>>
>> Hmm. I didn't check fully, but it seems that it's possible to use only one 
>> config.
>> I will check in more detail. After that, resend the email. :)
> 
> I can't also see any issue with using just one symbol with proper name.

Maybe you know more than me about zynq boards.
In SPL, it seems that it needs to add some config in spl.c for distinguishing 
boot device.
But in not SPL, if zynq boards are supported the device-tree, then can you use 
the below concept?

commit 02ad33aa3a84821c8d9a6c4f167f143f6248b084
Author: Jaehoon Chung 
Date:   Thu Feb 2 13:41:14 2017 +0900

mmc: mmc-uclass: use the fixed devnum with alias node

If there are alias nodes as "mmc", use the devnum as alias index
number.
This patch is for fixing a problem of Exynos4 series.
Problem is the below thing.

Current legacy mode:
EXYNOS DWMMC: 0, SAMSUNG SDHCI: 1

After using DM:
SAMSUNG SDHCI: 0, EXYNOS DWMMC: 1

Dev index is swapped.
Then u-boot can't find the kernel image..because it is already set to 0 as 
mmcdev.
If change from legacy to DM, also needs to touch all exynos4 config file.
For using simply, just supporting the fixed devnum with alias node is 
better than it.

Usage:
alaise {

mmc0 =  /* eMMC */
mmc1 =  /* SD */
...
}

Best Regards,
Jaehoon Chung

> 
> M
> 
> 
> 

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

[U-Boot] [PATCH] pinctrl: Kconfig: Fix typo

[Marek Behún]

Signed-off-by: Marek Behun 
---
 drivers/pinctrl/Kconfig | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 0a4dd3c0cf..ad0b8daba6 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -47,9 +47,9 @@ config PINMUX
default y
help
  This option enables pin multiplexing through the generic pinctrl
- framework. Most SoCs have their own own multiplexing arrangement
- where a single pin can be used for several functions. An SoC pinctrl
- driver allows the required function to be selected for each pin.
+ framework. Most SoCs have their own multiplexing arrangement where
+ a single pin can be used for several functions. An SoC pinctrl driver
+ allows the required function to be selected for each pin.
  The driver is typically controlled by the device tree.
 
 config PINCONF
-- 
2.16.1

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

Re: [U-Boot] [PULL] u-boot-sh/master

[Marek Vasut]

On 03/02/2018 03:32 AM, Tom Rini wrote:
> On Thu, Mar 01, 2018 at 06:34:29PM +0100, Marek Vasut wrote:
> 
>> The following changes since commit 4bafceff0e9e5a36908031e41c69a6b37e82da58:
>>
>>   Merge git://git.denx.de/u-boot-mmc (2018-02-25 22:28:59 -0500)
>>
>> are available in the Git repository at:
>>
>>   git://git.denx.de/u-boot-sh.git master
>>
>> for you to fetch changes up to 44c5580f1c6c5665ff6217d1411aab2b74188195:
>>
>>   ARM: rmobile: Build u-boot-spl.srec on Gen2 (2018-02-27 21:05:35 +0100)
>>
> 
> Applied to u-boot/next, thanks!

This was for current release, the Kconfig conversion will be for next. I
am CIing that since yesterday.

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

Re: [U-Boot] [PATCH 04/13] mmc: uniphier-sd: Add R8A77965 M3N entries

[Jaehoon Chung]

On 03/02/2018 06:14 AM, Marek Vasut wrote:
> Add entries for the R8A77965 M3N SoC.
> 
> Signed-off-by: Marek Vasut 
> Cc: Nobuhiro Iwamatsu 
> Cc: Jaehoon Chung 
> Cc: Masahiro Yamada 

Reviewed-by: Jaehoon Chung 

Best Regards,
Jaehoon Chung

> ---
>  drivers/mmc/uniphier-sd.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/mmc/uniphier-sd.c b/drivers/mmc/uniphier-sd.c
> index a080674c8a..525b1702b9 100644
> --- a/drivers/mmc/uniphier-sd.c
> +++ b/drivers/mmc/uniphier-sd.c
> @@ -854,6 +854,7 @@ static const struct udevice_id uniphier_sd_match[] = {
>   { .compatible = "renesas,sdhi-r8a7794", .data = 0 },
>   { .compatible = "renesas,sdhi-r8a7795", .data = UNIPHIER_SD_CAP_64BIT },
>   { .compatible = "renesas,sdhi-r8a7796", .data = UNIPHIER_SD_CAP_64BIT },
> + { .compatible = "renesas,sdhi-r8a77965", .data = UNIPHIER_SD_CAP_64BIT 
> },
>   { .compatible = "renesas,sdhi-r8a77970", .data = UNIPHIER_SD_CAP_64BIT 
> },
>   { .compatible = "renesas,sdhi-r8a77995", .data = UNIPHIER_SD_CAP_64BIT 
> },
>   { .compatible = "socionext,uniphier-sdhc", .data = 0 },
> 

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

Re: [U-Boot] [PATCH] mmc: sdhci: consider SDHCI_QUIRK_NO_HISPD_BIT in host_caps

[Hannes Schmelzer]

> 
> Dear Hannes,
Dear Jaehoon,

> >> Instead, its bit is used to other purpose.
> > 
> > Please explain me more about this other purpose,
> > maybe i'm missunterstand here something.
> 
> SD Host Controller has the HOST Controller register (Offset 0x28).
> BIT[2] is "High speed enable".
> - BIT[2] : 0 - Normal Speed mode
> - BIT[2] : 1 - High Speed mode.
> This bit is "RW" attribute.
> 
> And Samsung SoC also has the HOST Controller register (offset 0x28).
> BIT[2] is "Output Edge Inversion". 
> - BIT[2] : 0 - Rising edge output.
> - BIT[2] : 1 - Falling edge output.
> 
> "High speed enable" bit is standard. but Samsung SoC is using it for 
other purpose.
> So I had added the quirks for SDHCI_QUIRK_NO_HISPD_BIT.
> It means that there is no 'high speed bit'.

OK. Many thanks for clarifying this.
I took a look to the ZYNQ TRM and an the register 0x28 of the sdhci 
controller,
here we have standard behaviour where bit[2] controls the high speed 
stuff.

The conclusion of this is, that the "zynq_sdhci.c" uses the 
SDHCI_QUIRK_NO_HISPD_BIT
wrong and this must be fixed.

I did grep for the "CONFIG_ZYNQ_HISPD_BROKEN" within source tree and 
observed
that nobody or no boards except mine uses this #define.
This would explain that, i call it this bug, is unnoticed yet.

> 
> If your patch is applied, Samsung SoC can work the unexpected behavior.
> 
> If your ip also doesn't use this bit, then no problem. 
> But your patch tried to use the other purpose.

OK.

> 
> > 
> > Maybe i've to introduce some new quirk, which tells the ip-core and 
the 
> > other layers> above not using HIGH_SPEED. But i think still this is 
the right one ... 
> 
> Well, i don't want to add the new quirk, if there is a solution not to 
add the quriks.
> If really needs, you need to add the SDHCI_QUIRK_BROKEN_HISPD_MODE.
> 
> #define SDHCI_QUIRK_BROKEN_HISPD_MODE (1 << 5)

OK. But i fear that we've to introduce this new quirk.
Because in real life mistakes in hardware-design (in this case chip 
design) happen and
we software guys have to workaround them.

https://www.xilinx.com/support/answers/5.html

> 
> and change from SDHCI_QUIRK_NO_HSIPD_BIT to 
SDHCI_QUIRK_BROKEN_HISPD_MODE in 
> zynq_sdhci.c.

I will do so.

I will also send some V2 of my patch, with doing:

- add this new QUIRK
- fix the zynq_sdhci.c
- consider this quirk in the host_cap


> 
> I will update the descriptions about quirks. Because it can be confused 
what 
> purpose is used.

Great, so it will be more readable in the future.

> 
> Best Regards,
> Jaehoon Chung
cheers,
Hannes


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