Re: [PATCH v2] arm: apple: t602x: Add missing MMIO regions to memmap

[Eric Curtin]

On Fri, 1 Dec 2023 at 07:20, Janne Grunau via B4 Relay
 wrote:
>
> From: Janne Grunau 
>
> The memory maps for Apple's M2 Pro/Max/Ultra left MMIO space out which
> was not used by any driver at the time. The display out exposed as
> simple-framebuffer use a power-domain controlled by a device in an
> unmapped region.
> Add a map covering this region as well as another MMIO region in the
> range 0x4'' - 0x5''. The added regions cover all MMIO
> annotated in Apple's device tree in this range.
>
> Signed-off-by: Janne Grunau 

Review comments addressed.

Reviewed-by: Eric Curtin 

Is mise le meas/Regards,

Eric Curtin

> ---
> Changes in v2:
> - use SZ_1G as block size
> - Link to v1: 
> https://lore.kernel.org/r/20231130-apple_t602x_extend_memmap-v1-1-cd96b251d...@jannau.net
> ---
>  arch/arm/mach-apple/board.c | 48 
> +
>  1 file changed, 48 insertions(+)
>
> diff --git a/arch/arm/mach-apple/board.c b/arch/arm/mach-apple/board.c
> index 47393babbc..7a6151a972 100644
> --- a/arch/arm/mach-apple/board.c
> +++ b/arch/arm/mach-apple/board.c
> @@ -370,6 +370,22 @@ static struct mm_region t6020_mem_map[] = {
> .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
>  PTE_BLOCK_NON_SHARE |
>  PTE_BLOCK_PXN | PTE_BLOCK_UXN
> +   }, {
> +   /* I/O */
> +   .virt = 0x4,
> +   .phys = 0x4,
> +   .size = SZ_1G,
> +   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> +   PTE_BLOCK_NON_SHARE |
> +   PTE_BLOCK_PXN | PTE_BLOCK_UXN
> +   }, {
> +   /* I/O */
> +   .virt = 0x48000,
> +   .phys = 0x48000,
> +   .size = SZ_1G,
> +   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> +   PTE_BLOCK_NON_SHARE |
> +   PTE_BLOCK_PXN | PTE_BLOCK_UXN
> }, {
> /* I/O */
> .virt = 0x58000,
> @@ -471,6 +487,22 @@ static struct mm_region t6022_mem_map[] = {
> .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
>  PTE_BLOCK_NON_SHARE |
>  PTE_BLOCK_PXN | PTE_BLOCK_UXN
> +   }, {
> +   /* I/O */
> +   .virt = 0x4,
> +   .phys = 0x4,
> +   .size = SZ_1G,
> +   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> +   PTE_BLOCK_NON_SHARE |
> +   PTE_BLOCK_PXN | PTE_BLOCK_UXN
> +   }, {
> +   /* I/O */
> +   .virt = 0x48000,
> +   .phys = 0x48000,
> +   .size = SZ_1G,
> +   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> +   PTE_BLOCK_NON_SHARE |
> +   PTE_BLOCK_PXN | PTE_BLOCK_UXN
> }, {
> /* I/O */
> .virt = 0x58000,
> @@ -551,6 +583,22 @@ static struct mm_region t6022_mem_map[] = {
> .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
>  PTE_BLOCK_NON_SHARE |
>  PTE_BLOCK_PXN | PTE_BLOCK_UXN
> +   }, {
> +   /* I/O */
> +   .virt = 0x24,
> +   .phys = 0x24,
> +   .size = SZ_1G,
> +   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> +   PTE_BLOCK_NON_SHARE |
> +   PTE_BLOCK_PXN | PTE_BLOCK_UXN
> +   }, {
> +   /* I/O */
> +   .virt = 0x248000,
> +   .phys = 0x248000,
> +   .size = SZ_1G,
> +   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> +   PTE_BLOCK_NON_SHARE |
> +   PTE_BLOCK_PXN | PTE_BLOCK_UXN
> }, {
> /* I/O */
> .virt = 0x258000,
>
> ---
> base-commit: 43f2873fa98b1da6eb56d756315c7bd7db63db27
> change-id: 20231130-apple_t602x_extend_memmap-c82c522ca8c0
>
> Best regards,
> --
> Janne Grunau 
>
>

Re: [NEW FEATURE] RFC: Add Intel GMBUS support

[Eric Schikschneit]

Hello,

That is correct. The new later revision Baytrail chips do not reliably 
initialize video upon boot. I have taken a significant amount of time to 
analyze the issue. The SOCs produced after 2019 show this issue, although I 
dont have the specific SKU or stepping details as our production team has not 
been logging that data. We have several hundred of these SOCs in inventory and 
are seeing a 20% failure rate resulting in these boards being marked bad. The 
vendor (Advantech) uses an AMI BIOS on the SOM which we replace with U-Boot. 
The AMI BIOS is able to reliably initialize the video on the SOCs in question. 
I have captured the communication on the GMBUS for both the U-Boot 
initialization and the AMI initialization. Both can be clearly seen running the 
Intel VBIOS, but the vendors BIOS then additionally gathers data approx 100ms 
later from the GMBUS to be used to properly initialize the GPU. This can be 
seen on the google drive link below in the file "Logic-Capture.png". I have 
also done a register dump comparison between a known good SOC and a known bad 
SOC. The register "PIPEAFRAMECOUNT", offset 0x70040 can be seen that the 
monitor does not report back sufficient VSYNC on the newer silicon. This can be 
seen on the google drive link below in the file "Register-Comparison.png". I 
have also included the full register dumps in the text files. If you would like 
I can add the actual Logic capture files for further inspection. The Intel doc 
"intel-os-gfx-prm-vol10-display.pdf" does not show confidential or NDA so I 
believe this is a public document that we can use to implement the needed 
features.

Google Drive with referenced data:
https://drive.google.com/drive/folders/1OpXT7Faks2sfIKBIv-JmhEYeLzFYwvmF?usp=sharing



Eric Schikschneit
Senior Embedded Linux Engineer III  ​

NovaTech, LLC
13555 W. 107th Street | Lenexa, LS 66215​
O: 913.451.1880​
  ​
novatechautomation.com | NovaTechLinkedIn
Receipt of this email implies compliance with our terms and conditions.


From: Bin Meng 
Sent: Thursday, September 21, 2023 8:14 PM
To: Eric Schikschneit; Simon Glass
Cc: u-boot@lists.denx.de
Subject: Re: [NEW FEATURE] RFC: Add Intel GMBUS support

+Simon

Hi Eric,

On Fri, Sep 22, 2023 at 6:10 AM Eric Schikschneit
 wrote:
>
> I have begun working on adding support for the Intel Graphics Management bus 
> to U-Boot. Currently the x86 bring up process (as explored on the Baytrail 
> series of Atom SOCs) relys on the Intel Video BIOS to do all setup and 
> configuration of the GPU. This method of adding video support works on 
> earlier versions of the silicon. With later versions I have found that the 
> OEM BIOS needs to capture the monitor data over the GMBUS in order to 
> initialize the GPU properly. I have logic analyzer captures available for 
> anyone who is curious. My purpose for this patch is a skeleton placeholder 
> that I will be working from, and I am asking for community collaboration with 
> this. I have hardware available for testing as needed, and some details can 
> be provided upon request.

Would you share the documentation that describes the Intel GM bus, if
publicly available?

Based on the info you provided, did you mean with later new revision
BayTrail chips, the video bios initialization is not enough in U-Boot?
AFAIU, the U-Boot BayTrail support relies on Intel FSP to do any
chipset-specific work, including the video bios setup.

Regards,
Bin

[NEW FEATURE] RFC: Add Intel GMBUS support

[Eric Schikschneit]

I have begun working on adding support for the Intel Graphics Management bus to 
U-Boot. Currently the x86 bring up process (as explored on the Baytrail series 
of Atom SOCs) relys on the Intel Video BIOS to do all setup and configuration 
of the GPU. This method of adding video support works on earlier versions of 
the silicon. With later versions I have found that the OEM BIOS needs to 
capture the monitor data over the GMBUS in order to initialize the GPU 
properly. I have logic analyzer captures available for anyone who is curious. 
My purpose for this patch is a skeleton placeholder that I will be working 
from, and I am asking for community collaboration with this. I have hardware 
available for testing as needed, and some details can be provided upon request.



Eric Schikschneit
Senior Embedded Linux Engineer III  ​
  
NovaTech, LLC
13555 W. 107th Street | Lenexa, LS 66215​
O: 913.451.1880​
  ​
novatechautomation.com | NovaTechLinkedIn 
Receipt of this email implies compliance with our terms and conditions.From 66ef768fce7c41fd784b622b92c07f201982a678 Mon Sep 17 00:00:00 2001
From: Eric Schikschneit 
Date: Thu, 21 Sep 2023 16:11:23 -0500
Subject: [PATCH] WIP: Add Intel GMBUS support

This will allow uboot to communicate over the GMBUS to an attached
monitor to gather EDID information in order to properly setup video
during the boot process.

This is being tested as it is being developed on an Intel Bayrail SOC.

Signed-off-by: Eric Schikschneit 
---
 drivers/video/Kconfig |  5 +++
 drivers/video/Makefile|  1 +
 drivers/video/intel_gmbus.c   | 77 +++
 drivers/video/psb_intel_reg.h | 55 +
 4 files changed, 138 insertions(+)
 create mode 100644 drivers/video/intel_gmbus.c
 create mode 100644 drivers/video/psb_intel_reg.h

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index ed0b21f2a7..7bc433d9af 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -683,4 +683,9 @@ config VIDEO_DT_SIMPLEFB
 	  The video output is initialized by U-Boot, and kept by the
 	  kernel.
 
+config VIDEO_INTEL_BAYTRAIL
+	bool "Enable GMBUS support for Intel Baytrail SOCs"
+	help
+	  Enables support for interfacing with monitors to gather EDID
+	  information to aid video bringup.
 endmenu
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 0f41a23193..4ff710e41a 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -56,6 +56,7 @@ obj-$(CONFIG_VIDEO_SIMPLE) += simplefb.o
 obj-$(CONFIG_VIDEO_TEGRA20) += tegra.o
 obj-$(CONFIG_VIDEO_VCXK) += bus_vcxk.o
 obj-$(CONFIG_VIDEO_VESA) += vesa.o
+obj-$(CONFIG_VIDEO_INTEL_BAYTRAIL) += intel_gmbus.o
 
 obj-y += bridge/
 obj-y += sunxi/
diff --git a/drivers/video/intel_gmbus.c b/drivers/video/intel_gmbus.c
new file mode 100644
index 00..e23e8030f2
--- /dev/null
+++ b/drivers/video/intel_gmbus.c
@@ -0,0 +1,77 @@
+/* This file is loosly based off of the file found in the linux kernel,
+ * modified for use with u-boot.
+ * File in kernel: drivers/gpu/drm/gma500/intel_gmbus.c
+ * 
+ * Authors:
+ * Eric Schikschneit 
+
+#include "psb_intel_reg.h"
+
+// struct intel_gpio {
+// 	struct i2c_adapter adapter;
+// 	struct i2c_algo_bit_data algo;
+// 	struct drm_psb_private *dev_priv;
+// 	u32 reg;
+// };
+
+#define GMBUS_REG_READ(reg) ioread32(dev_priv->gmbus_reg + (reg))
+#define GMBUS_REG_WRITE(reg, val) iowrite32((val), dev_priv->gmbus_reg + (reg))
+
+void intel_gmbus_i2c_reset() {
+}
+
+static void intel_gmbus_i2c_quirk_set() {
+}
+
+static u32 intel_gmbus_get_reserved() {
+return 0;
+}
+
+static void intel_gmbus_set_clock (void *data, int state_high) {
+}
+
+static int intel_gmbus_get_clock(void *data) {
+return 0;
+}
+
+static void intel_gmbus_set_data(void *data, int state_high) {
+}
+
+static int intel_gmbus_get_data(void *data) {
+return 0;
+}
+
+static struct i2c_adapter * intel_gmbus_gpio_create() { // Use u-boot compatible struct
+return;
+}
+
+static int intel_gmbus_i2c_quirk_xfer() {
+return 0;
+}
+
+static int intel_gmbus_xfer() {
+return 0;
+}
+
+static u32 intel_gmbus_func() {
+return 0;
+}
+
+void intel_gmbus_setup() {
+}
+
+void intel_gmbus_set_speed(struct pci_dev_t *dev) {
+}
+
+void intel_gmbus_get_speed(struct pci_dev_t *dev) {
+}
+
+void intel_gmbus_force_bit() {
+}
+
+void intel_gmbus_teardown() {
+}
+
diff --git a/drivers/video/psb_intel_reg.h b/drivers/video/psb_intel_reg.h
new file mode 100644
index 00..51ba722177
--- /dev/null
+++ b/drivers/video/psb_intel_reg.h
@@ -0,0 +1,55 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2009, Intel Corporation.
+ * Modified for uboot by Eric Schikschneit (eric.schikschn...@novatechautomation.com)
+ */
+#ifndef __PSB_INTEL_REG_H__
+#define __PSB_INTEL_REG_H__
+
+#define GMBUS0			0x5100 /* clock/port select */
+#define   GMBUS_RATE_100KHZ	(0<<8)
+#define   GMBUS_RATE_50KHZ	(1<<8)
+#define   GMBUS_RATE

Re: [PATCH 5/8] mx6memcal: Remove SPL_USB_HOST

[Eric Nelson]

Thanks Tom.

On 6/12/22 17:02, Tom Rini wrote:

As this particular platform is intended to be loaded and run a specific
set of routines in SPL, we do not need the ability to further use the
USB as a host device in SPL.  Disable this support.

Cc: Eric Nelson 
Signed-off-by: Tom Rini 
---
Please correct me if I'm wrong here and I'll update the subsequent patch
that lead me to discover this.
---
  configs/mx6memcal_defconfig | 1 -
  1 file changed, 1 deletion(-)

diff --git a/configs/mx6memcal_defconfig b/configs/mx6memcal_defconfig
index a1bc95bb4a1c..021e8a6151ee 100644
--- a/configs/mx6memcal_defconfig
+++ b/configs/mx6memcal_defconfig
@@ -16,7 +16,6 @@ CONFIG_SYS_MEMTEST_START=0x1000
  CONFIG_SYS_MEMTEST_END=0x2000
  CONFIG_SUPPORT_RAW_INITRD=y
  CONFIG_SYS_SPL_MALLOC=y
-CONFIG_SPL_USB_HOST=y
  CONFIG_SPL_WATCHDOG=y
  CONFIG_HUSH_PARSER=y
  CONFIG_SYS_MAXARGS=32


Acked-by: Eric Nelson 

Re: [PATCH 07/18] mx6memcal: Disable USB GADGET in SPL

[Eric Nelson]

Hi Tom,

On 5/25/21 9:45 AM, Tom Rini wrote:
> On Tue, May 25, 2021 at 09:19:30AM -0700, Eric Nelson wrote:
>> Hi Tom,
>>
>> On 5/25/21 8:47 AM, Tom Rini wrote:
>>> On Tue, May 25, 2021 at 07:10:29AM -0700, Eric Nelson wrote:
>>>
>>>> Since the proper U-Boot doesn't do anything at the moment, I don't think
>>>> this hurts much.
>>>>
>>>> My usage of mx6memcal generally ends after SPL spits out calibration
>>>> values, and I suspect the same is true for other users, so
>>>>
>>>> Acked-by: Eric Nelson 
>>> But don't you need SPL gadget support to easily load this in?
>>>
>> No. The calibration is done by the SPL running in internal RAM.
> ... ah, yes, sorry, I'm with you now.  ROM loads via gadget, SPL runs,
> does memcalc, displays values, then you move on to the real board.
>

And test under Linux, where you can exercise things with the GPU and VPU
active.

Testing under U-Boot doesn't tend to find calibration errors.

It would be helpful to test under U-Boot by adding support for changing up
the DDR frequencies (as done in the NXP test), but that's something for
another day.

Re: [PATCH 07/18] mx6memcal: Disable USB GADGET in SPL

[Eric Nelson]

Hi Tom,

On 5/25/21 8:47 AM, Tom Rini wrote:
> On Tue, May 25, 2021 at 07:10:29AM -0700, Eric Nelson wrote:
>
>> Since the proper U-Boot doesn't do anything at the moment, I don't think
>> this hurts much.
>>
>> My usage of mx6memcal generally ends after SPL spits out calibration
>> values, and I suspect the same is true for other users, so
>>
>> Acked-by: Eric Nelson 
> But don't you need SPL gadget support to easily load this in?
>
No. The calibration is done by the SPL running in internal RAM.

Re: [PATCH 07/18] mx6memcal: Disable USB GADGET in SPL

[Eric Nelson]

Since the proper U-Boot doesn't do anything at the moment, I don't think
this hurts much.

My usage of mx6memcal generally ends after SPL spits out calibration
values, and I suspect the same is true for other users, so

Acked-by: Eric Nelson 

On 5/22/21 5:47 AM, Tom Rini wrote:
> As this board does not use CONFIG_OF_CONTROL and the DM_USB migration
> deadline has passed, disable USB_GADGET support.
> 
> Cc: Eric Nelson 
> Cc: Stefano Babic 
> Signed-off-by: Tom Rini 
> ---
> I realize this removes an important functional part of the board.  I
> suspect the path forward here is to make a generic mx6 device tree to
> use here, so that the USB functionality keeps working.
> ---
>  configs/mx6memcal_defconfig | 9 -
>  1 file changed, 9 deletions(-)
> 
> diff --git a/configs/mx6memcal_defconfig b/configs/mx6memcal_defconfig
> index 41ff942cf1ce..a860fbe77738 100644
> --- a/configs/mx6memcal_defconfig
> +++ b/configs/mx6memcal_defconfig
> @@ -16,9 +16,6 @@ CONFIG_SPL=y
>  CONFIG_SUPPORT_RAW_INITRD=y
>  CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg,SPL"
>  CONFIG_SPL_USB_HOST_SUPPORT=y
> -CONFIG_SPL_USB_GADGET=y
> -CONFIG_SPL_USB_ETHER=y
> -CONFIG_SPL_USB_SDP_SUPPORT=y
>  CONFIG_SPL_WATCHDOG_SUPPORT=y
>  CONFIG_HUSH_PARSER=y
>  # CONFIG_CMD_BOOTD is not set
> @@ -45,11 +42,5 @@ CONFIG_BOUNCE_BUFFER=y
>  # CONFIG_MMC is not set
>  CONFIG_FSL_USDHC=y
>  CONFIG_MXC_UART=y
> -CONFIG_USB=y
> -CONFIG_USB_GADGET=y
> -CONFIG_USB_GADGET_MANUFACTURER="FSL"
> -CONFIG_USB_GADGET_VENDOR_NUM=0x0525
> -CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5
> -CONFIG_CI_UDC=y
>  CONFIG_OF_LIBFDT=y
>  # CONFIG_EFI_LOADER is not set
> 

Re: [PATCH v2 13/14] blkcache: Extend blkcache_init to cover CONFIG_NEEDS_MANUAL_RELOC

[Eric Nelson]

On 7/10/20 3:19 AM, Ovidiu Panait wrote:

Extend manual relocation of block_cache list pointers to all platforms that
enable CONFIG_NEEDS_MANUAL_RELOC. Remove m68k-specific checks and provide a
single implementation that adds gd->reloc_off to the pre-relocation
pointers.

Cc: Angelo Durgehello 
Reviewed-by: Simon Glass 
Signed-off-by: Ovidiu Panait 
---
v2 updates:
- add reviewed-by tag



Reviewed-by: Eric Nelson 

Re: [PATCH 2/8] mx6memcal: Finish migration to defconfig options

[Eric Nelson]

Reviewed by: Eric Nelson 

On 5/26/20 12:06 PM, Tom Rini wrote:

The config header for this platform uses '#undef' in a number of cases.
All of the MMC related ones were already handled correctly in the
defconfig file.  In the case of CONFIG_CMD_FUSE, the command was being
built and enabled via defconfig.  Disable it in the defconfig, cleanup
the header.

Cc: Eric Nelson 
Signed-off-by: Tom Rini 
---
  configs/mx6memcal_defconfig | 1 +
  include/configs/mx6memcal.h | 5 -
  2 files changed, 1 insertion(+), 5 deletions(-)

diff --git a/configs/mx6memcal_defconfig b/configs/mx6memcal_defconfig
index 8b5e0ff9b134..ed24b7996b6b 100644
--- a/configs/mx6memcal_defconfig
+++ b/configs/mx6memcal_defconfig
@@ -33,6 +33,7 @@ CONFIG_CMD_MEMINFO=y
  CONFIG_CMD_MEMTEST=y
  CONFIG_SYS_MEMTEST_START=0x1000
  CONFIG_SYS_MEMTEST_END=0x2000
+# CONFIG_CMD_FUSE is not set
  # CONFIG_CMD_LOADB is not set
  # CONFIG_CMD_LOADS is not set
  CONFIG_CMD_CACHE=y
diff --git a/include/configs/mx6memcal.h b/include/configs/mx6memcal.h
index 3d79a7e43765..b774b167f648 100644
--- a/include/configs/mx6memcal.h
+++ b/include/configs/mx6memcal.h
@@ -13,11 +13,6 @@
  #include "mx6_common.h"
  #include "imx6_spl.h"
  
-#undef CONFIG_MMC

-#undef CONFIG_SPL_MMC_SUPPORT
-#undef CONFIG_GENERIC_MMC
-#undef CONFIG_CMD_FUSE
-
  #define CONFIG_SYS_MALLOC_LEN (64 * 1024 * 1024)
  
  #define CONFIG_MXC_UART

Re: [PATCH v3] riscv: add Kconfig entries for the F and D ISA extensions support

[Eric Lin]

Hi Bin,

Bin Meng  於 2020年2月4日 週二 下午11:50寫道：
>
> On Thu, Jun 6, 2019 at 5:06 PM Eric Lin  wrote:
> >
> > This patch adds Kconfig entries for the F (Single-Precision)
> > and D (Double-Precision) floating point instruction-set extensions.
> >
> > Signed-off-by: Eric Lin 
> > ---
> > Changes for v2:
> > - Grammatical correction in commit message "adds"
> > - Fixed the config name to indicate both F and D
> >
> > Changes for v3:
> > - Separate the config name for ISA_F and ISA_D
> >
> >  arch/riscv/Kconfig  | 14 ++
> >  arch/riscv/Makefile | 16 ++++
> >  2 files changed, 26 insertions(+), 4 deletions(-)
> >
>
> Reviewed-by: Bin Meng 
>
> @Eric Lin  @Rick Chen
>
> This patch was never applied. Do we still need this patch?
>

I think this patch is unnecessary now. Thanks.

> Regards,
> Bin

Regards,
Eric

[PATCH] common: blk: fix comment about blkcache_read return value

[Eric Nelson]

The blkcache_read() routine returns 1 (true) to indicate that a block was
found in the cache and returned, or 0 if not.

Signed-off-by: Eric Nelson 
---
 include/blk.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/blk.h b/include/blk.h
index 65db69f5d9..6f541bb2ba 100644
--- a/include/blk.h
+++ b/include/blk.h
@@ -129,7 +129,7 @@ int blkcache_init(void);
  * @param blksz - size in bytes of each block
  * @param buf - buffer to contain cached data
  *
- * @return - '1' if block returned from cache, '0' otherwise.
+ * @return - 1 if block returned from cache, 0 otherwise.
  */
 int blkcache_read(int iftype, int dev,
  lbaint_t start, lbaint_t blkcnt,
-- 
2.17.1

Re: [PATCH] common: add blkcache init

[Eric Nelson]

Thanks Angelo,

On 1/21/20 2:37 AM, Angelo Dureghello wrote:

From: Angelo Durgehello 

On m68k, block_cache list is relocated, but next and prev list
pointers are not adjusted to the relocated struct list_head address,
so the first iteration over the block_cache list hangs.

This patch initializes the block_cache list after relocation.

Signed-off-by: Angelo Durgehello 
---
Changes for v2:
- call blkcache_init directly
---
  common/board_r.c | 3 +++
  drivers/block/blkcache.c | 9 -
  include/blk.h| 6 ++
  3 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/common/board_r.c b/common/board_r.c
index 8a0c1114e7..4f56c19fcc 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -864,6 +864,9 @@ static init_fnc_t init_sequence_r[] = {
  #endif
  #if defined(CONFIG_PRAM)
initr_mem,
+#endif
+#ifdef CONFIG_BLOCK_CACHE
+   blkcache_init,
  #endif
run_main_loop,
  };
diff --git a/drivers/block/blkcache.c b/drivers/block/blkcache.c
index 1fa64989d3..f603aa129d 100644
--- a/drivers/block/blkcache.c
+++ b/drivers/block/blkcache.c
@@ -21,13 +21,20 @@ struct block_cache_node {
char *cache;
  };
  
-static LIST_HEAD(block_cache);

+static struct list_head block_cache;
  
  static struct block_cache_stats _stats = {

.max_blocks_per_entry = 8,
.max_entries = 32
  };
  
+int blkcache_init(void)

+{
+   INIT_LIST_HEAD(_cache);
+
+   return 0;
+}
+
  static struct block_cache_node *cache_find(int iftype, int devnum,
   lbaint_t start, lbaint_t blkcnt,
   unsigned long blksz)
diff --git a/include/blk.h b/include/blk.h
index d0c033aece..65db69f5d9 100644
--- a/include/blk.h
+++ b/include/blk.h
@@ -113,6 +113,12 @@ struct blk_desc {
(PAD_SIZE(size, blk_desc->blksz))
  
  #if CONFIG_IS_ENABLED(BLOCK_CACHE)

+
+/**
+ * blkcache_init() - initialize the block cache list pointers
+ */
+int blkcache_init(void);
+
  /**
   * blkcache_read() - attempt to read a set of blocks from cache
   *



This looks good to me.

Reviewed-by: Eric Nelson 

Re: [U-Boot] [PATCH] ARM: mx6: pmu: Expose PMU LDO configuration interface

[Eric Nelson]

Hi Marek,

On 11/26/19 1:35 AM, Marek Vasut wrote:

Make the PMU LDO configuration interface available to board code,
so that board code can reconfigure the internal LDOs of the SoC.

Signed-off-by: Marek Vasut 
Cc: Eric Nelson 
Cc: Fabio Estevam 
Cc: Stefano Babic 
---
  arch/arm/include/asm/arch-mx6/sys_proto.h | 8 
  arch/arm/mach-imx/mx6/soc.c   | 8 +---
  2 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/arch/arm/include/asm/arch-mx6/sys_proto.h 
b/arch/arm/include/asm/arch-mx6/sys_proto.h
index 4bf7dff8b4..1e5fa1a75e 100644
--- a/arch/arm/include/asm/arch-mx6/sys_proto.h
+++ b/arch/arm/include/asm/arch-mx6/sys_proto.h
@@ -20,6 +20,14 @@
  int imx6_pcie_toggle_power(void);
  int imx6_pcie_toggle_reset(void);
  
+enum ldo_reg {

+   LDO_ARM,
+   LDO_SOC,
+   LDO_PU,
+};
+
+int set_ldo_voltage(enum ldo_reg ldo, u32 mv);
+
  /**
   * iomuxc_set_rgmii_io_voltage - set voltage level of RGMII/USB pins
   *
diff --git a/arch/arm/mach-imx/mx6/soc.c b/arch/arm/mach-imx/mx6/soc.c
index 6dccee484c..3560dd7ee7 100644
--- a/arch/arm/mach-imx/mx6/soc.c
+++ b/arch/arm/mach-imx/mx6/soc.c
@@ -23,12 +23,6 @@
  #include 
  #include 
  
-enum ldo_reg {

-   LDO_ARM,
-   LDO_SOC,
-   LDO_PU,
-};
-
  struct scu_regs {
u32 ctrl;
u32 config;
@@ -254,7 +248,7 @@ static void clear_ldo_ramp(void)
   * Possible values are from 0.725V to 1.450V in steps of
   * 0.025V (25mV).
   */
-static int set_ldo_voltage(enum ldo_reg ldo, u32 mv)
+int set_ldo_voltage(enum ldo_reg ldo, u32 mv)
  {
struct anatop_regs *anatop = (struct anatop_regs *)ANATOP_BASE_ADDR;
u32 val, step, old, reg = readl(>reg_core);



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

Re: [U-Boot] [PATCH 3/4] ARM: mx6: ddr: Configure all SDQS pullups using loop

[Eric Nelson]

Hi Marek,

On 11/26/19 1:34 AM, Marek Vasut wrote:

Instead of explicitly setting up each SDQS register, use a loop.
No functional change.

Signed-off-by: Marek Vasut 
Cc: Eric Nelson 
Cc: Fabio Estevam 
Cc: Stefano Babic 
---
  arch/arm/mach-imx/mx6/ddr.c | 27 ---
  1 file changed, 8 insertions(+), 19 deletions(-)

diff --git a/arch/arm/mach-imx/mx6/ddr.c b/arch/arm/mach-imx/mx6/ddr.c
index e917b04f3d..b2402f75db 100644
--- a/arch/arm/mach-imx/mx6/ddr.c
+++ b/arch/arm/mach-imx/mx6/ddr.c
@@ -249,25 +249,14 @@ static void mmdc_set_sdqs(bool set)
  {
struct mx6dq_iomux_ddr_regs *mx6_ddr_iomux =
(struct mx6dq_iomux_ddr_regs *)MX6DQ_IOM_DDR_BASE;
-
-   if (set) {
-   setbits_le32(_ddr_iomux->dram_sdqs0, 0x7000);
-   setbits_le32(_ddr_iomux->dram_sdqs1, 0x7000);
-   setbits_le32(_ddr_iomux->dram_sdqs2, 0x7000);
-   setbits_le32(_ddr_iomux->dram_sdqs3, 0x7000);
-   setbits_le32(_ddr_iomux->dram_sdqs4, 0x7000);
-   setbits_le32(_ddr_iomux->dram_sdqs5, 0x7000);
-   setbits_le32(_ddr_iomux->dram_sdqs6, 0x7000);
-   setbits_le32(_ddr_iomux->dram_sdqs7, 0x7000);
-   } else {
-   clrbits_le32(_ddr_iomux->dram_sdqs0, 0x7000);
-   clrbits_le32(_ddr_iomux->dram_sdqs1, 0x7000);
-   clrbits_le32(_ddr_iomux->dram_sdqs2, 0x7000);
-   clrbits_le32(_ddr_iomux->dram_sdqs3, 0x7000);
-   clrbits_le32(_ddr_iomux->dram_sdqs4, 0x7000);
-   clrbits_le32(_ddr_iomux->dram_sdqs5, 0x7000);
-   clrbits_le32(_ddr_iomux->dram_sdqs6, 0x7000);
-   clrbits_le32(_ddr_iomux->dram_sdqs7, 0x7000);
+   u32 sdqs = (u32)(_ddr_iomux->dram_sdqs0);
+   int i;
+
+   for (i = 0; i < 8; i++) {
+   if (set)
+   setbits_le32(sdqs + (4 * i), 0x7000);
+   else
+   clrbits_le32(sdqs + (4 * i), 0x7000);
}
  }
  



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

Re: [U-Boot] [PATCH 4/4] ARM: mx6: ddr: Add support for iMX6SX

[Eric Nelson]

Hi Marek,

On 11/26/19 1:34 AM, Marek Vasut wrote:

This patch adds support for iMX6SX MMDC into the DDR calibration
code. The only difference between MX6DQ and MX6SX is that the SX
has 2 SDQS registers, while the DQ has 8.

Signed-off-by: Marek Vasut 
Cc: Eric Nelson 
Cc: Fabio Estevam 
Cc: Stefano Babic 
---
  arch/arm/mach-imx/mx6/ddr.c | 18 ++
  1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-imx/mx6/ddr.c b/arch/arm/mach-imx/mx6/ddr.c
index b2402f75db..8ed8b79c8b 100644
--- a/arch/arm/mach-imx/mx6/ddr.c
+++ b/arch/arm/mach-imx/mx6/ddr.c
@@ -247,12 +247,22 @@ int mmdc_do_write_level_calibration(struct 
mx6_ddr_sysinfo const *sysinfo)
  
  static void mmdc_set_sdqs(bool set)

  {
-   struct mx6dq_iomux_ddr_regs *mx6_ddr_iomux =
+   struct mx6dq_iomux_ddr_regs *mx6dq_ddr_iomux =
(struct mx6dq_iomux_ddr_regs *)MX6DQ_IOM_DDR_BASE;
-   u32 sdqs = (u32)(_ddr_iomux->dram_sdqs0);
-   int i;
+   struct mx6sx_iomux_ddr_regs *mx6sx_ddr_iomux =
+   (struct mx6sx_iomux_ddr_regs *)MX6SX_IOM_DDR_BASE;
+   int i, sdqs_cnt;
+   u32 sdqs;
+
+   if (is_mx6sx()) {
+   sdqs = (u32)(_ddr_iomux->dram_sdqs0);
+   sdqs_cnt = 2;
+   } else {/* MX6DQ */
+   sdqs = (u32)(_ddr_iomux->dram_sdqs0);
+   sdqs_cnt = 8;
+   }
  
-	for (i = 0; i < 8; i++) {

+   for (i = 0; i < sdqs_cnt; i++) {
if (set)
setbits_le32(sdqs + (4 * i), 0x7000);
else



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

Re: [U-Boot] [PATCH 2/4] ARM: mx6: ddr: Factor out SDQS configuration code

[Eric Nelson]

Hi Marek,

On 11/26/19 1:34 AM, Marek Vasut wrote:

Pull out the code turning SDQS pullups on and off into a separate
function, since it is replicated in two places in the code and it
is the single place in the entire function which is SoC dependent.

Signed-off-by: Marek Vasut 
Cc: Eric Nelson 
Cc: Fabio Estevam 
Cc: Stefano Babic 
---
  arch/arm/mach-imx/mx6/ddr.c | 46 ++---
  1 file changed, 28 insertions(+), 18 deletions(-)

diff --git a/arch/arm/mach-imx/mx6/ddr.c b/arch/arm/mach-imx/mx6/ddr.c
index e6f69e904f..e917b04f3d 100644
--- a/arch/arm/mach-imx/mx6/ddr.c
+++ b/arch/arm/mach-imx/mx6/ddr.c
@@ -245,12 +245,36 @@ int mmdc_do_write_level_calibration(struct 
mx6_ddr_sysinfo const *sysinfo)
return errors;
  }
  
+static void mmdc_set_sdqs(bool set)

+{
+   struct mx6dq_iomux_ddr_regs *mx6_ddr_iomux =
+   (struct mx6dq_iomux_ddr_regs *)MX6DQ_IOM_DDR_BASE;
+
+   if (set) {
+   setbits_le32(_ddr_iomux->dram_sdqs0, 0x7000);
+   setbits_le32(_ddr_iomux->dram_sdqs1, 0x7000);
+   setbits_le32(_ddr_iomux->dram_sdqs2, 0x7000);
+   setbits_le32(_ddr_iomux->dram_sdqs3, 0x7000);
+   setbits_le32(_ddr_iomux->dram_sdqs4, 0x7000);
+   setbits_le32(_ddr_iomux->dram_sdqs5, 0x7000);
+   setbits_le32(_ddr_iomux->dram_sdqs6, 0x7000);
+   setbits_le32(_ddr_iomux->dram_sdqs7, 0x7000);
+   } else {
+   clrbits_le32(_ddr_iomux->dram_sdqs0, 0x7000);
+   clrbits_le32(_ddr_iomux->dram_sdqs1, 0x7000);
+   clrbits_le32(_ddr_iomux->dram_sdqs2, 0x7000);
+   clrbits_le32(_ddr_iomux->dram_sdqs3, 0x7000);
+   clrbits_le32(_ddr_iomux->dram_sdqs4, 0x7000);
+   clrbits_le32(_ddr_iomux->dram_sdqs5, 0x7000);
+   clrbits_le32(_ddr_iomux->dram_sdqs6, 0x7000);
+   clrbits_le32(_ddr_iomux->dram_sdqs7, 0x7000);
+   }
+}
+
  int mmdc_do_dqs_calibration(struct mx6_ddr_sysinfo const *sysinfo)
  {
struct mmdc_p_regs *mmdc0 = (struct mmdc_p_regs *)MMDC_P0_BASE_ADDR;
struct mmdc_p_regs *mmdc1 = (struct mmdc_p_regs *)MMDC_P1_BASE_ADDR;
-   struct mx6dq_iomux_ddr_regs *mx6_ddr_iomux =
-   (struct mx6dq_iomux_ddr_regs *)MX6DQ_IOM_DDR_BASE;
bool cs0_enable;
bool cs1_enable;
bool cs0_enable_initial;
@@ -272,14 +296,7 @@ int mmdc_do_dqs_calibration(struct mx6_ddr_sysinfo const 
*sysinfo)
setbits_le32(>mapsr, 0x1);
  
  	/* set DQS pull ups */

-   setbits_le32(_ddr_iomux->dram_sdqs0, 0x7000);
-   setbits_le32(_ddr_iomux->dram_sdqs1, 0x7000);
-   setbits_le32(_ddr_iomux->dram_sdqs2, 0x7000);
-   setbits_le32(_ddr_iomux->dram_sdqs3, 0x7000);
-   setbits_le32(_ddr_iomux->dram_sdqs4, 0x7000);
-   setbits_le32(_ddr_iomux->dram_sdqs5, 0x7000);
-   setbits_le32(_ddr_iomux->dram_sdqs6, 0x7000);
-   setbits_le32(_ddr_iomux->dram_sdqs7, 0x7000);
+   mmdc_set_sdqs(true);
  
  	/* Save old RALAT and WALAT values */

esdmisc_val = readl(>mdmisc);
@@ -524,14 +541,7 @@ int mmdc_do_dqs_calibration(struct mx6_ddr_sysinfo const 
*sysinfo)
writel(esdmisc_val, >mdmisc);
  
  	/* Clear DQS pull ups */

-   clrbits_le32(_ddr_iomux->dram_sdqs0, 0x7000);
-   clrbits_le32(_ddr_iomux->dram_sdqs1, 0x7000);
-   clrbits_le32(_ddr_iomux->dram_sdqs2, 0x7000);
-   clrbits_le32(_ddr_iomux->dram_sdqs3, 0x7000);
-   clrbits_le32(_ddr_iomux->dram_sdqs4, 0x7000);
-   clrbits_le32(_ddr_iomux->dram_sdqs5, 0x7000);
-   clrbits_le32(_ddr_iomux->dram_sdqs6, 0x7000);
-   clrbits_le32(_ddr_iomux->dram_sdqs7, 0x7000);
+   mmdc_set_sdqs(false);
  
  	/* Re-enable SDE (chip selects) if they were set initially */

if (cs1_enable_initial)



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

Re: [U-Boot] [PATCH 1/4] ARM: mx6: ddr: Make debug prints work with tiny printf

[Eric Nelson]

Hi Marek,

On 11/26/19 1:34 AM, Marek Vasut wrote:

The %08X format returns just zeroes with tiny printf, which is
horribly confusing, especially when debugging DRAM calibration
problems. Change the format to %08x (with lowercase x), which
behaves correctly with either implementation of printf in SPL.

Signed-off-by: Marek Vasut 
Cc: Eric Nelson 
Cc: Fabio Estevam 
Cc: Stefano Babic 
---
  arch/arm/mach-imx/mx6/ddr.c | 24 
  1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-imx/mx6/ddr.c b/arch/arm/mach-imx/mx6/ddr.c
index 84b9236249..e6f69e904f 100644
--- a/arch/arm/mach-imx/mx6/ddr.c
+++ b/arch/arm/mach-imx/mx6/ddr.c
@@ -214,14 +214,14 @@ int mmdc_do_write_level_calibration(struct 
mx6_ddr_sysinfo const *sysinfo)
writel(esdmisc_val, >mdref);
writel(zq_val, >mpzqhwctrl);
  
-	debug("\tMMDC_MPWLDECTRL0 after write level cal: 0x%08X\n",

+   debug("\tMMDC_MPWLDECTRL0 after write level cal: 0x%08x\n",
  readl(>mpwldectrl0));
-   debug("\tMMDC_MPWLDECTRL1 after write level cal: 0x%08X\n",
+   debug("\tMMDC_MPWLDECTRL1 after write level cal: 0x%08x\n",
  readl(>mpwldectrl1));
if (sysinfo->dsize == 2) {
-   debug("\tMMDC_MPWLDECTRL0 after write level cal: 0x%08X\n",
+   debug("\tMMDC_MPWLDECTRL0 after write level cal: 0x%08x\n",
  readl(>mpwldectrl0));
-   debug("\tMMDC_MPWLDECTRL1 after write level cal: 0x%08X\n",
+   debug("\tMMDC_MPWLDECTRL1 after write level cal: 0x%08x\n",
  readl(>mpwldectrl1));
}
  
@@ -557,20 +557,20 @@ int mmdc_do_dqs_calibration(struct mx6_ddr_sysinfo const *sysinfo)

 */
debug("MMDC registers updated from calibration\n");
debug("Read DQS gating calibration:\n");
-   debug("\tMPDGCTRL0 PHY0 = 0x%08X\n", readl(>mpdgctrl0));
-   debug("\tMPDGCTRL1 PHY0 = 0x%08X\n", readl(>mpdgctrl1));
+   debug("\tMPDGCTRL0 PHY0 = 0x%08x\n", readl(>mpdgctrl0));
+   debug("\tMPDGCTRL1 PHY0 = 0x%08x\n", readl(>mpdgctrl1));
if (sysinfo->dsize == 2) {
-   debug("\tMPDGCTRL0 PHY1 = 0x%08X\n", readl(>mpdgctrl0));
-   debug("\tMPDGCTRL1 PHY1 = 0x%08X\n", readl(>mpdgctrl1));
+   debug("\tMPDGCTRL0 PHY1 = 0x%08x\n", readl(>mpdgctrl0));
+   debug("\tMPDGCTRL1 PHY1 = 0x%08x\n", readl(>mpdgctrl1));
}
debug("Read calibration:\n");
-   debug("\tMPRDDLCTL PHY0 = 0x%08X\n", readl(>mprddlctl));
+   debug("\tMPRDDLCTL PHY0 = 0x%08x\n", readl(>mprddlctl));
if (sysinfo->dsize == 2)
-   debug("\tMPRDDLCTL PHY1 = 0x%08X\n", readl(>mprddlctl));
+   debug("\tMPRDDLCTL PHY1 = 0x%08x\n", readl(>mprddlctl));
debug("Write calibration:\n");
-   debug("\tMPWRDLCTL PHY0 = 0x%08X\n", readl(>mpwrdlctl));
+   debug("\tMPWRDLCTL PHY0 = 0x%08x\n", readl(>mpwrdlctl));
if (sysinfo->dsize == 2)
-   debug("\tMPWRDLCTL PHY1 = 0x%08X\n", readl(>mpwrdlctl));
+   debug("\tMPWRDLCTL PHY1 = 0x%08x\n", readl(>mpwrdlctl));
  
  	/*

 * Registers below are for debugging purposes.  These print out



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

Re: [U-Boot] [PATCH 2/5] common: add blkcache init

[Eric Nelson]

Hi Angelo,

On 11/25/19 2:59 AM, Angelo Dureghello wrote:

Hi Eric,

On Sun, Nov 24, 2019 at 5:00 PM Eric Nelson  wrote:


Hi Angelo,

On 11/23/19 3:47 PM, Angelo Dureghello wrote:

From: Angelo Durgehello 

On m68k, block_cache list is relocated, but next and prev list
pointers are not adjusted to the relocated struct list_head address,
so the first iteration over the block_cache list hangs.

This patch initializes the block_cache list after relocation.

Signed-off-by: Angelo Durgehello 
---
   common/board_r.c | 12 
   drivers/block/blkcache.c |  7 ++-
   include/blk.h|  6 ++
   3 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/common/board_r.c b/common/board_r.c
index 65720849cd..13e70a5ffb 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -628,6 +628,15 @@ static int initr_bedbug(void)
   }
   #endif

+#ifdef CONFIG_BLOCK_CACHE
+static int initr_blkcache(void)
+{
+ blkcache_init();
+
+ return 0;
+}
+#endif
+


Why the extra level of indirection?


   static int run_main_loop(void)
   {
   #ifdef CONFIG_SANDBOX
@@ -832,6 +841,9 @@ static init_fnc_t init_sequence_r[] = {
   #endif
   #if defined(CONFIG_PRAM)
   initr_mem,
+#endif
+#ifdef CONFIG_BLOCK_CACHE


It seems you could call blkcache_init from here directly:



reason for this is to maintain "initr_" naming convention, used from
quite all the initr_ calls,
as i.e. static int initr_mmc(void) that's doing the same.



Okay. I think this isn't a hard rule though (see log_init,
stdio_init_tables, etc).

I'm not sure that it would be a bad thing to rename blkcache_init
to initr_blkcache to indicate the usage.




+ initr_blkcache,
   #endif
   run_main_loop,
   };
diff --git a/drivers/block/blkcache.c b/drivers/block/blkcache.c
index 1fa64989d3..bf0fa1ea6f 100644
--- a/drivers/block/blkcache.c
+++ b/drivers/block/blkcache.c
@@ -21,13 +21,18 @@ struct block_cache_node {
   char *cache;
   };

-static LIST_HEAD(block_cache);
+static struct list_head block_cache;

   static struct block_cache_stats _stats = {
   .max_blocks_per_entry = 8,
   .max_entries = 32
   };

+void blkcache_init(void)
+{
+ INIT_LIST_HEAD(_cache);
+}
+
   static struct block_cache_node *cache_find(int iftype, int devnum,
  lbaint_t start, lbaint_t blkcnt,
  unsigned long blksz)
diff --git a/include/blk.h b/include/blk.h
index d0c033aece..7070fd6af3 100644
--- a/include/blk.h
+++ b/include/blk.h
@@ -113,6 +113,12 @@ struct blk_desc {
   (PAD_SIZE(size, blk_desc->blksz))

   #if CONFIG_IS_ENABLED(BLOCK_CACHE)
+
+/**
+ * blkcache_init() - initialize the block cache list pointers
+ */
+void blkcache_init(void);
+
   /**
* blkcache_read() - attempt to read a set of blocks from cache
*




Regards,
--
Angelo Dureghello



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

Re: [U-Boot] [PATCH 2/5] common: add blkcache init

[Eric Nelson]

Hi Angelo,

On 11/25/19 2:59 AM, Angelo Dureghello wrote:

Hi Eric,

On Sun, Nov 24, 2019 at 5:00 PM Eric Nelson  wrote:


Hi Angelo,

On 11/23/19 3:47 PM, Angelo Dureghello wrote:

From: Angelo Durgehello 

On m68k, block_cache list is relocated, but next and prev list
pointers are not adjusted to the relocated struct list_head address,
so the first iteration over the block_cache list hangs.

This patch initializes the block_cache list after relocation.

Signed-off-by: Angelo Durgehello 
---
   common/board_r.c | 12 
   drivers/block/blkcache.c |  7 ++-
   include/blk.h|  6 ++
   3 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/common/board_r.c b/common/board_r.c
index 65720849cd..13e70a5ffb 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -628,6 +628,15 @@ static int initr_bedbug(void)
   }
   #endif

+#ifdef CONFIG_BLOCK_CACHE
+static int initr_blkcache(void)
+{
+ blkcache_init();
+
+ return 0;
+}
+#endif
+


Why the extra level of indirection?


   static int run_main_loop(void)
   {
   #ifdef CONFIG_SANDBOX
@@ -832,6 +841,9 @@ static init_fnc_t init_sequence_r[] = {
   #endif
   #if defined(CONFIG_PRAM)
   initr_mem,
+#endif
+#ifdef CONFIG_BLOCK_CACHE


It seems you could call blkcache_init from here directly:



reason for this is to maintain "initr_" naming convention, used from
quite all the initr_ calls,
as i.e. static int initr_mmc(void) that's doing the same.



Okay. I think this isn't a hard rule though (see log_init,
stdio_init_tables, etc).

I'm not sure that it would be a bad thing to rename blkcache_init
to initr_blkcache to indicate the usage.




+ initr_blkcache,
   #endif
   run_main_loop,
   };
diff --git a/drivers/block/blkcache.c b/drivers/block/blkcache.c
index 1fa64989d3..bf0fa1ea6f 100644
--- a/drivers/block/blkcache.c
+++ b/drivers/block/blkcache.c
@@ -21,13 +21,18 @@ struct block_cache_node {
   char *cache;
   };

-static LIST_HEAD(block_cache);
+static struct list_head block_cache;

   static struct block_cache_stats _stats = {
   .max_blocks_per_entry = 8,
   .max_entries = 32
   };

+void blkcache_init(void)
+{
+ INIT_LIST_HEAD(_cache);
+}
+
   static struct block_cache_node *cache_find(int iftype, int devnum,
  lbaint_t start, lbaint_t blkcnt,
  unsigned long blksz)
diff --git a/include/blk.h b/include/blk.h
index d0c033aece..7070fd6af3 100644
--- a/include/blk.h
+++ b/include/blk.h
@@ -113,6 +113,12 @@ struct blk_desc {
   (PAD_SIZE(size, blk_desc->blksz))

   #if CONFIG_IS_ENABLED(BLOCK_CACHE)
+
+/**
+ * blkcache_init() - initialize the block cache list pointers
+ */
+void blkcache_init(void);
+
   /**
* blkcache_read() - attempt to read a set of blocks from cache
*




Regards,
--
Angelo Dureghello



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

Re: [U-Boot] [PATCH 2/5] common: add blkcache init

[Eric Nelson]

Hi Angelo,

On 11/23/19 3:47 PM, Angelo Dureghello wrote:

From: Angelo Durgehello 

On m68k, block_cache list is relocated, but next and prev list
pointers are not adjusted to the relocated struct list_head address,
so the first iteration over the block_cache list hangs.

This patch initializes the block_cache list after relocation.

Signed-off-by: Angelo Durgehello 
---
  common/board_r.c | 12 
  drivers/block/blkcache.c |  7 ++-
  include/blk.h|  6 ++
  3 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/common/board_r.c b/common/board_r.c
index 65720849cd..13e70a5ffb 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -628,6 +628,15 @@ static int initr_bedbug(void)
  }
  #endif
  
+#ifdef CONFIG_BLOCK_CACHE

+static int initr_blkcache(void)
+{
+   blkcache_init();
+
+   return 0;
+}
+#endif
+


Why the extra level of indirection?


  static int run_main_loop(void)
  {
  #ifdef CONFIG_SANDBOX
@@ -832,6 +841,9 @@ static init_fnc_t init_sequence_r[] = {
  #endif
  #if defined(CONFIG_PRAM)
initr_mem,
+#endif
+#ifdef CONFIG_BLOCK_CACHE


It seems you could call blkcache_init from here directly:


+   initr_blkcache,
  #endif
run_main_loop,
  };
diff --git a/drivers/block/blkcache.c b/drivers/block/blkcache.c
index 1fa64989d3..bf0fa1ea6f 100644
--- a/drivers/block/blkcache.c
+++ b/drivers/block/blkcache.c
@@ -21,13 +21,18 @@ struct block_cache_node {
char *cache;
  };
  
-static LIST_HEAD(block_cache);

+static struct list_head block_cache;
  
  static struct block_cache_stats _stats = {

.max_blocks_per_entry = 8,
.max_entries = 32
  };
  
+void blkcache_init(void)

+{
+   INIT_LIST_HEAD(_cache);
+}
+
  static struct block_cache_node *cache_find(int iftype, int devnum,
   lbaint_t start, lbaint_t blkcnt,
   unsigned long blksz)
diff --git a/include/blk.h b/include/blk.h
index d0c033aece..7070fd6af3 100644
--- a/include/blk.h
+++ b/include/blk.h
@@ -113,6 +113,12 @@ struct blk_desc {
(PAD_SIZE(size, blk_desc->blksz))
  
  #if CONFIG_IS_ENABLED(BLOCK_CACHE)

+
+/**
+ * blkcache_init() - initialize the block cache list pointers
+ */
+void blkcache_init(void);
+
  /**
   * blkcache_read() - attempt to read a set of blocks from cache
   *



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

[U-Boot] [PATCH] Add validation for icache/dcache arguments - arguments different from off/on/flush are currently silently ignored.

[eric . perie]

From: Eric Perie 

Signed-off-by: Eric Perie 
---
 cmd/cache.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/cmd/cache.c b/cmd/cache.c
index 233f428054..2c687173a8 100644
--- a/cmd/cache.c
+++ b/cmd/cache.c
@@ -22,7 +22,7 @@ void __weak invalidate_icache_all(void)
 static int do_icache(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
 {
switch (argc) {
-   case 2: /* on / off */
+   case 2: /* on / off / flush */
switch (parse_argv(argv[1])) {
case 0:
icache_disable();
@@ -33,6 +33,8 @@ static int do_icache(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
case 2:
invalidate_icache_all();
break;
+   default:
+   return CMD_RET_USAGE;
}
break;
case 1: /* get status */
@@ -54,7 +56,7 @@ void __weak flush_dcache_all(void)
 static int do_dcache(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
 {
switch (argc) {
-   case 2: /* on / off */
+   case 2: /* on / off / flush */
switch (parse_argv(argv[1])) {
case 0:
dcache_disable();
@@ -65,6 +67,8 @@ static int do_dcache(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
case 2:
flush_dcache_all();
break;
+   default:
+   return CMD_RET_USAGE;
}
break;
case 1: /* get status */
-- 
2.22.0

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

Re: [U-Boot] Want a Das U-Boot project logo

[Eric S. Raymond]

Peter Robinson :
> > Interested?
> 
> It already has this one
> https://gitlab.denx.de/u-boot/u-boot/blob/master/tools/logos/u-boot_logo.svg

Hm.  Doesn't show up on the home page.  I did check.

Very well then, good luck and good hunting.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond


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

[U-Boot] Want a Das U-Boot project logo

[Eric S. Raymond]

A few days ago I became aware of the existence of Das U-Boot.  It appers
you're doing good technical work, and the bilingual pun appeals to
my sense of humor. This makes me want to do the project a good turn.
And, it turns out, I think I can.

I recently launched an effort called Loadsharers.  You can read about
it at http://loadsharers.net and I hope that will motivate you to join
the network and spread the word about it.

The Loadsharers network needed a logo.  I am not a professional
graphics designer, but given access to a clip-art archive and a copy
of the GIMP I am not bad at putting together something simple and 
serviceable. Besides the Loadsharers logo I have also designed the
logos on these pages:

https://gpsd.io/
https://ntpsec.org/

(I'm also the technical lead of both projects.)

The Atlas image that I chose for Loadsharers turns out to be owned by 
Shutterstock.  I bought the rights to use it yesterday.  But it turns
out the minimum package you can buy from them is a 5-image licenses.  This 
means I have free license options on four Shutterstock images of my
choice over the next year.

It would amuse me to trawl Shutterstock's archive, fire up a copy of
Inkscape or the GIMP, and design a logo for Das U-boot.  I have in
mind something themed around a periscope or periscope reticle.

Interested?
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

The kind of charity you can force out of people nourishes about as much as
the kind of love you can buy --- and spreads even nastier diseases.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3] riscv: add Kconfig entries for the F and D ISA extensions support

[Eric Lin]

This patch adds Kconfig entries for the F (Single-Precision)
and D (Double-Precision) floating point instruction-set extensions.

Signed-off-by: Eric Lin 
---
Changes for v2:
- Grammatical correction in commit message "adds"
- Fixed the config name to indicate both F and D

Changes for v3:
- Separate the config name for ISA_F and ISA_D

 arch/riscv/Kconfig  | 14 ++
 arch/riscv/Makefile | 16 
 2 files changed, 26 insertions(+), 4 deletions(-)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 362f3cdc65..7a2463ffe2 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -91,6 +91,20 @@ config RISCV_ISA_C
  when building U-Boot, which results in compressed instructions in the
  U-Boot binary.
 
+config RISCV_ISA_F
+   bool "Emit single-precision floating-point instructions"
+   help
+ Adds "F" to the ISA subsets that the toolchain is allowed to emit
+ when building U-Boot, which results in single-precision instructions
+ in the U-Boot binary.
+
+config RISCV_ISA_D
+   bool "Emit double-precision floating-point instructions"
+   help
+ Adds "D" to the ISA subsets that the toolchain is allowed to emit
+ when building U-Boot, which results in double-precision instructions
+ in the U-Boot binary.
+
 config RISCV_ISA_A
def_bool y
 
diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
index 0b80eb8d86..f834d11720 100644
--- a/arch/riscv/Makefile
+++ b/arch/riscv/Makefile
@@ -5,15 +5,23 @@
 
 ifeq ($(CONFIG_ARCH_RV64I),y)
ARCH_BASE = rv64im
-   ABI = lp64
+   ABI := lp64
 endif
 ifeq ($(CONFIG_ARCH_RV32I),y)
ARCH_BASE = rv32im
-   ABI = ilp32
+   ABI := ilp32
 endif
 ifeq ($(CONFIG_RISCV_ISA_A),y)
ARCH_A = a
 endif
+ifeq ($(CONFIG_RISCV_ISA_F),y)
+   ARCH_F = f
+   ABI := $(ABI)f
+endif
+ifeq ($(CONFIG_RISCV_ISA_D),y)
+   ARCH_D = fd
+   ABI := $(ABI)d
+endif
 ifeq ($(CONFIG_RISCV_ISA_C),y)
ARCH_C = c
 endif
@@ -24,8 +32,8 @@ ifeq ($(CONFIG_CMODEL_MEDANY),y)
CMODEL = medany
 endif
 
-ARCH_FLAGS = -march=$(ARCH_BASE)$(ARCH_A)$(ARCH_C) -mabi=$(ABI) \
--mcmodel=$(CMODEL)
+ARCH_FLAGS = -march=$(ARCH_BASE)$(ARCH_A)$(ARCH_F)$(ARCH_D)$(ARCH_C) 
-mabi=$(ABI) \
+-mcmodel=$(CMODEL)
 
 PLATFORM_CPPFLAGS  += $(ARCH_FLAGS)
 CFLAGS_EFI += $(ARCH_FLAGS)
-- 
2.17.0

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

Re: [U-Boot] [PATCH v2] riscv: add Kconfig entries for the F and D ISA extensions support

[Eric Lin]

Hi Bin
>
> Hi Eric,
>
> On Tue, Jun 4, 2019 at 1:51 PM Eric Lin  wrote:
> >
> > This patch adds Kconfig entries for the F (Single-Precision)
> > and D (Double-Precision) floating point instruction-set extensions.
> >
> > Signed-off-by: Eric Lin 
> > ---
> > Changes for v2:
> > - Grammatical correction in commit message "adds"
> > - Fixed the config name to indicate both F and D
> >
> >  arch/riscv/Kconfig  |  7 +++
> >  arch/riscv/Makefile | 12 
> >  2 files changed, 15 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> > index 362f3cdc65..e7a76c67cc 100644
> > --- a/arch/riscv/Kconfig
> > +++ b/arch/riscv/Kconfig
> > @@ -91,6 +91,13 @@ config RISCV_ISA_C
> >   when building U-Boot, which results in compressed instructions in 
> > the
> >   U-Boot binary.
> >
> > +config RISCV_ISA_FD
>
> Again like I said in the v1 patch, I am not in favor of adding such to
> U-Boot, but if we have to add such, I think we need add finer control
> of single-precision and double-precision via 2 options, one for ISA_F
> and one for ISA_D. It's possible that toolchain only supports ISA_F,
> although I should say that's a bit weird.
>

OK, I see. I'll modify the patch as below:

 +config RISCV_ISA_F
+   bool "Emit single-precision floating-point instructions"
+   help
+ Adds "F" to the ISA subsets that the toolchain is allowed to emit
+ when building U-Boot, which results in single-precision instructions
+ in the U-Boot binary.
+
+config RISCV_ISA_D
+   bool "Emit double-precision floating-point instructions"
+   help
+ Adds "D" to the ISA subsets that the toolchain is allowed to emit
+ when building U-Boot, which results in double-precision instructions
+ in the U-Boot binary.

 ifeq ($(CONFIG_RISCV_ISA_A),y)
ARCH_A = a
 endif
+ifeq ($(CONFIG_RISCV_ISA_F),y)
+   ARCH_F = f
+   ABI := $(ABI)f
+endif
+ifeq ($(CONFIG_RISCV_ISA_D),y)
+   ARCH_D = fd
+   ABI := $(ABI)d
+endif
 ifeq ($(CONFIG_RISCV_ISA_C),y)
ARCH_C = c
 endif

-ARCH_FLAGS = -march=$(ARCH_BASE)$(ARCH_A)$(ARCH_C) -mabi=$(ABI) \
--mcmodel=$(CMODEL)
+ARCH_FLAGS = -march=$(ARCH_BASE)$(ARCH_A)$(ARCH_F)$(ARCH_D)$(ARCH_C)
-mabi=$(ABI) \
+-mcmodel=$(CMODEL)

The ISA_D -march will imply fd

> > +   bool "Emit Floating-point instructions"
> > +   help
> > + Adds "F" and "D" to the ISA subsets that the toolchain is allowed 
> > to emit
> > + when building U-Boot, which results in Single and 
> > Double-precision instructions
> > + in the U-Boot binary.
> > +
> >  config RISCV_ISA_A
> > def_bool y
> >
> > diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
> > index 0b80eb8d86..5a5c8e75f0 100644
> > --- a/arch/riscv/Makefile
> > +++ b/arch/riscv/Makefile
> > @@ -5,15 +5,19 @@
> >
> >  ifeq ($(CONFIG_ARCH_RV64I),y)
> > ARCH_BASE = rv64im
> > -   ABI = lp64
> > +   ABI := lp64
> >  endif
> >  ifeq ($(CONFIG_ARCH_RV32I),y)
> > ARCH_BASE = rv32im
> > -   ABI = ilp32
> > +   ABI := ilp32
> >  endif
> >  ifeq ($(CONFIG_RISCV_ISA_A),y)
> > ARCH_A = a
> >  endif
> > +ifeq ($(CONFIG_RISCV_ISA_FD),y)
> > +   ARCH_FD = fd
> > +   ABI := $(ABI)d
> > +endif
> >  ifeq ($(CONFIG_RISCV_ISA_C),y)
> > ARCH_C = c
> >  endif
> > @@ -24,8 +28,8 @@ ifeq ($(CONFIG_CMODEL_MEDANY),y)
> > CMODEL = medany
> >  endif
> >
> > -ARCH_FLAGS = -march=$(ARCH_BASE)$(ARCH_A)$(ARCH_C) -mabi=$(ABI) \
> > --mcmodel=$(CMODEL)
> > +ARCH_FLAGS = -march=$(ARCH_BASE)$(ARCH_A)$(ARCH_FD)$(ARCH_C) -mabi=$(ABI) \
> > +-mcmodel=$(CMODEL)
> >
> >  PLATFORM_CPPFLAGS  += $(ARCH_FLAGS)
> >  CFLAGS_EFI += $(ARCH_FLAGS)
> > --
>
> Regards,
> Bin

Thanks for your review

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

[U-Boot] [PATCH v2] riscv: add Kconfig entries for the F and D ISA extensions support

[Eric Lin]

This patch adds Kconfig entries for the F (Single-Precision)
and D (Double-Precision) floating point instruction-set extensions.

Signed-off-by: Eric Lin 
---
Changes for v2:
- Grammatical correction in commit message "adds"
- Fixed the config name to indicate both F and D 

 arch/riscv/Kconfig  |  7 +++
 arch/riscv/Makefile | 12 
 2 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 362f3cdc65..e7a76c67cc 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -91,6 +91,13 @@ config RISCV_ISA_C
  when building U-Boot, which results in compressed instructions in the
  U-Boot binary.
 
+config RISCV_ISA_FD
+   bool "Emit Floating-point instructions"
+   help
+ Adds "F" and "D" to the ISA subsets that the toolchain is allowed to 
emit
+ when building U-Boot, which results in Single and Double-precision 
instructions
+ in the U-Boot binary.
+
 config RISCV_ISA_A
def_bool y
 
diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
index 0b80eb8d86..5a5c8e75f0 100644
--- a/arch/riscv/Makefile
+++ b/arch/riscv/Makefile
@@ -5,15 +5,19 @@
 
 ifeq ($(CONFIG_ARCH_RV64I),y)
ARCH_BASE = rv64im
-   ABI = lp64
+   ABI := lp64
 endif
 ifeq ($(CONFIG_ARCH_RV32I),y)
ARCH_BASE = rv32im
-   ABI = ilp32
+   ABI := ilp32
 endif
 ifeq ($(CONFIG_RISCV_ISA_A),y)
ARCH_A = a
 endif
+ifeq ($(CONFIG_RISCV_ISA_FD),y)
+   ARCH_FD = fd
+   ABI := $(ABI)d
+endif
 ifeq ($(CONFIG_RISCV_ISA_C),y)
ARCH_C = c
 endif
@@ -24,8 +28,8 @@ ifeq ($(CONFIG_CMODEL_MEDANY),y)
CMODEL = medany
 endif
 
-ARCH_FLAGS = -march=$(ARCH_BASE)$(ARCH_A)$(ARCH_C) -mabi=$(ABI) \
--mcmodel=$(CMODEL)
+ARCH_FLAGS = -march=$(ARCH_BASE)$(ARCH_A)$(ARCH_FD)$(ARCH_C) -mabi=$(ABI) \
+-mcmodel=$(CMODEL)
 
 PLATFORM_CPPFLAGS  += $(ARCH_FLAGS)
 CFLAGS_EFI += $(ARCH_FLAGS)
-- 
2.17.0

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

[U-Boot] Fwd: [PATCH] riscv: add Kconfig entries for the F and D ISA extensions support

[Eric Lin]

Hi Bin

Bin Meng  於 2019年5月22日 週三 下午5:25寫道：
>
> Hi Eric,
>
> On Wed, May 22, 2019 at 4:23 PM  wrote:
> >
> > Hi Bin,
> >
> > > -Original Message-
> > > From: Bin Meng [mailto:bmeng...@gmail.com]
> > > Sent: Tuesday, May 21, 2019 3:56 PM
> > > To: Eric Te-Sheng Lin(林德晟)
> > > Cc: U-Boot Mailing List; Lukas Auer; Anup Patel; Rick Jian-Zhi Chen(陳建志);
> > > Greentime Ying-Han Hu(胡英漢); dslin1...@gmail.com
> > > Subject: Re: [PATCH] riscv: add Kconfig entries for the F and D ISA 
> > > extensions
> > > support
> > >
> > > Hi Eric,
> > >
> > > On Tue, May 21, 2019 at 3:18 PM Eric Lin  wrote:
> > > >
> > > > This patch add Kconfig entries for the F (Single-Precision)
> > >
> > > adds
> > >
> >
> > OK I'll correct it as adds
> >
> > > > and D (Double-Precision) floating point instruction-set extensions.
> > > >
> > >
> > > Could you please provide reason that why U-Boot has to be compiled using 
> > > F/D
> > > extension?
> > >
> >
> > Cause on AE350 platform, we have two different kinds of toolchain v5d 
> > (support I/M/A/C/F/D ISA) and
> > v5 (support I/M/A/C ISA). If we use the v5d toolchain to build U-Boot it 
> > will build fail, so we would like to add F/D extension on U-Boot.
>
> I don't understand. What difference do these two toochains have? Isn't
> the v5d toolchain's default -march string be pre-configured to imafd?
> But even if the toolchain is pre-configured to generate fd
> instruction, I think it can be override by the compiler flags. Can you
> please share the details of the toolchain you used? I suspect you have
> to fix your toolchain, not U-Boot.
>

It's seems the ABI issue. Because our toolchain don't support
multilib, the v5d toolchain libraries ABI is ilp64d.
If I use the v5d toolchain to build U-Boot with -mabi=lp64, it will
get link error as below:
...
riscv64-linux-ld.bfd:
/nds64le-linux-glibc-v5d/bin/../lib/gcc/riscv64-linux/7.3.0/libgcc.a(save-restore.o):
can't link double-float modules with soft-float modules
riscv64-linux-ld.bfd: failed to merge target specific data of file
/nds64le-linux-glibc-v5d/bin/../lib/gcc/riscv64-linux/7.3.0/libgcc.a(save-restore.o)
examples/standalone/Makefile:62: recipe for target
'examples/standalone/hello_world' failed
...

so we would like to override the compiler flag mabi to lp64d.

> >
> > > > Signed-off-by: Eric Lin 
> > > > ---
> > > >  arch/riscv/Kconfig  |  8 
> > > >  arch/riscv/Makefile | 12 
> > > >  2 files changed, 16 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index
> > > > 362f3cdc65..a8031fa230 100644
> > > > --- a/arch/riscv/Kconfig
> > > > +++ b/arch/riscv/Kconfig
> > > > @@ -91,6 +91,14 @@ config RISCV_ISA_C
> > > >   when building U-Boot, which results in compressed instructions
> > > in the
> > > >   U-Boot binary.
> > > >
> > > > +config RISCV_ISA_F
> > > > +   bool "Emit Floating-point instructions"
> > > > +   default n
> > >
> > > this can be dropped as default is n
> >
> > OK, I'll drop it
> >
> > > > +   help
> > > > + Adds "F" to the ISA subsets that the toolchain is allowed to 
> > > > emit
> > > > + when building U-Boot, which results in Single and
> > > > + Double-precision instructions
> > >
> > > This does not match what the config name says. The config name is for F 
> > > and it
> > > cannot indicate both F and D here.
> > >
> >
> > OK, I'll correct it as follows to cover F and D:
> > config RISCV_ISA_FD
> > bool "Emit Floating-point instructions"
> > help
> >   Adds "F" and "D" to the ISA subsets that the toolchain is allowed to 
> > emit
> >   when building U-Boot, which results in Single and Double-precision 
> > instructions
> >   in the U-Boot binary.
> >
> >
> > > > + in the U-Boot binary.
> > > > +
> > > >  config RISCV_ISA_A
> > > > def_bool y
> > > >
> > > > diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile index
> > > > 0b80eb8d86..87ec0ea4b5 100644
> > > > --- a/arch/riscv/Makefile
> > > > +++ b/arch/riscv/Makefile
> >

[U-Boot] Fwd: [PATCH] riscv: add Kconfig entries for the F and D ISA extensions support

[Eric Lin]

Hi Bin

Bin Meng  於 2019年5月22日 週三 下午5:25寫道：
>
> Hi Eric,
>
> On Wed, May 22, 2019 at 4:23 PM  wrote:
> >
> > Hi Bin,
> >
> > > -Original Message-
> > > From: Bin Meng [mailto:bmeng...@gmail.com]
> > > Sent: Tuesday, May 21, 2019 3:56 PM
> > > To: Eric Te-Sheng Lin(林德晟)
> > > Cc: U-Boot Mailing List; Lukas Auer; Anup Patel; Rick Jian-Zhi Chen(陳建志);
> > > Greentime Ying-Han Hu(胡英漢); dslin1...@gmail.com
> > > Subject: Re: [PATCH] riscv: add Kconfig entries for the F and D ISA 
> > > extensions
> > > support
> > >
> > > Hi Eric,
> > >
> > > On Tue, May 21, 2019 at 3:18 PM Eric Lin  wrote:
> > > >
> > > > This patch add Kconfig entries for the F (Single-Precision)
> > >
> > > adds
> > >
> >
> > OK I'll correct it as adds
> >
> > > > and D (Double-Precision) floating point instruction-set extensions.
> > > >
> > >
> > > Could you please provide reason that why U-Boot has to be compiled using 
> > > F/D
> > > extension?
> > >
> >
> > Cause on AE350 platform, we have two different kinds of toolchain v5d 
> > (support I/M/A/C/F/D ISA) and
> > v5 (support I/M/A/C ISA). If we use the v5d toolchain to build U-Boot it 
> > will build fail, so we would like to add F/D extension on U-Boot.
>
> I don't understand. What difference do these two toochains have? Isn't
> the v5d toolchain's default -march string be pre-configured to imafd?
> But even if the toolchain is pre-configured to generate fd
> instruction, I think it can be override by the compiler flags. Can you
> please share the details of the toolchain you used? I suspect you have
> to fix your toolchain, not U-Boot.
>

It's seems the ABI issue. Because our toolchain don't support
multilib, the v5d toolchain libraries ABI is ilp64d.
If I use the v5d toolchain to build U-Boot with -mabi=lp64, it will
get link error as below:
...
riscv64-linux-ld.bfd:
/nds64le-linux-glibc-v5d/bin/../lib/gcc/riscv64-linux/7.3.0/libgcc.a(save-restore.o):
can't link double-float modules with soft-float modules
riscv64-linux-ld.bfd: failed to merge target specific data of file
/nds64le-linux-glibc-v5d/bin/../lib/gcc/riscv64-linux/7.3.0/libgcc.a(save-restore.o)
examples/standalone/Makefile:62: recipe for target
'examples/standalone/hello_world' failed
...

so we would like to override the compiler flag mabi to lp64d.

> >
> > > > Signed-off-by: Eric Lin 
> > > > ---
> > > >  arch/riscv/Kconfig  |  8 
> > > >  arch/riscv/Makefile | 12 
> > > >  2 files changed, 16 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index
> > > > 362f3cdc65..a8031fa230 100644
> > > > --- a/arch/riscv/Kconfig
> > > > +++ b/arch/riscv/Kconfig
> > > > @@ -91,6 +91,14 @@ config RISCV_ISA_C
> > > >   when building U-Boot, which results in compressed instructions
> > > in the
> > > >   U-Boot binary.
> > > >
> > > > +config RISCV_ISA_F
> > > > +   bool "Emit Floating-point instructions"
> > > > +   default n
> > >
> > > this can be dropped as default is n
> >
> > OK, I'll drop it
> >
> > > > +   help
> > > > + Adds "F" to the ISA subsets that the toolchain is allowed to 
> > > > emit
> > > > + when building U-Boot, which results in Single and
> > > > + Double-precision instructions
> > >
> > > This does not match what the config name says. The config name is for F 
> > > and it
> > > cannot indicate both F and D here.
> > >
> >
> > OK, I'll correct it as follows to cover F and D:
> > config RISCV_ISA_FD
> > bool "Emit Floating-point instructions"
> > help
> >   Adds "F" and "D" to the ISA subsets that the toolchain is allowed to 
> > emit
> >   when building U-Boot, which results in Single and Double-precision 
> > instructions
> >   in the U-Boot binary.
> >
> >
> > > > + in the U-Boot binary.
> > > > +
> > > >  config RISCV_ISA_A
> > > > def_bool y
> > > >
> > > > diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile index
> > > > 0b80eb8d86..87ec0ea4b5 100644
> > > > --- a/arch/riscv/Makefile
> > > > +++ b/arch/riscv/Makefile
> >

Re: [U-Boot] [PATCH] riscv: add Kconfig entries for the F and D ISA extensions support

[Eric Lin]

Hi Bin

Bin Meng  於 2019年5月22日 週三 下午5:25寫道：
>
> Hi Eric,
>
> On Wed, May 22, 2019 at 4:23 PM  wrote:
> >
> > Hi Bin,
> >
> > > -Original Message-
> > > From: Bin Meng [mailto:bmeng...@gmail.com]
> > > Sent: Tuesday, May 21, 2019 3:56 PM
> > > To: Eric Te-Sheng Lin(林德晟)
> > > Cc: U-Boot Mailing List; Lukas Auer; Anup Patel; Rick Jian-Zhi Chen(陳建志);
> > > Greentime Ying-Han Hu(胡英漢); dslin1...@gmail.com
> > > Subject: Re: [PATCH] riscv: add Kconfig entries for the F and D ISA 
> > > extensions
> > > support
> > >
> > > Hi Eric,
> > >
> > > On Tue, May 21, 2019 at 3:18 PM Eric Lin  wrote:
> > > >
> > > > This patch add Kconfig entries for the F (Single-Precision)
> > >
> > > adds
> > >
> >
> > OK I'll correct it as adds
> >
> > > > and D (Double-Precision) floating point instruction-set extensions.
> > > >
> > >
> > > Could you please provide reason that why U-Boot has to be compiled using 
> > > F/D
> > > extension?
> > >
> >
> > Cause on AE350 platform, we have two different kinds of toolchain v5d 
> > (support I/M/A/C/F/D ISA) and
> > v5 (support I/M/A/C ISA). If we use the v5d toolchain to build U-Boot it 
> > will build fail, so we would like to add F/D extension on U-Boot.
>
> I don't understand. What difference do these two toochains have? Isn't
> the v5d toolchain's default -march string be pre-configured to imafd?
> But even if the toolchain is pre-configured to generate fd
> instruction, I think it can be override by the compiler flags. Can you
> please share the details of the toolchain you used? I suspect you have
> to fix your toolchain, not U-Boot.
>

It's seems the ABI issue. Because our toolchain don't support
multilib, the v5d toolchain libraries ABI is ilp64d.
If I use the v5d toolchain to build U-Boot with -mabi=lp64, it will
get link error as below:
...
riscv64-linux-ld.bfd:
/nds64le-linux-glibc-v5d/bin/../lib/gcc/riscv64-linux/7.3.0/libgcc.a(save-restore.o):
can't link double-float modules with soft-float modules
riscv64-linux-ld.bfd: failed to merge target specific data of file
/nds64le-linux-glibc-v5d/bin/../lib/gcc/riscv64-linux/7.3.0/libgcc.a(save-restore.o)
examples/standalone/Makefile:62: recipe for target
'examples/standalone/hello_world' failed
...

so we would like to override the compiler flag mabi to lp64d.

> >
> > > > Signed-off-by: Eric Lin 
> > > > ---
> > > >  arch/riscv/Kconfig  |  8 
> > > >  arch/riscv/Makefile | 12 
> > > >  2 files changed, 16 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index
> > > > 362f3cdc65..a8031fa230 100644
> > > > --- a/arch/riscv/Kconfig
> > > > +++ b/arch/riscv/Kconfig
> > > > @@ -91,6 +91,14 @@ config RISCV_ISA_C
> > > >   when building U-Boot, which results in compressed instructions
> > > in the
> > > >   U-Boot binary.
> > > >
> > > > +config RISCV_ISA_F
> > > > +   bool "Emit Floating-point instructions"
> > > > +   default n
> > >
> > > this can be dropped as default is n
> >
> > OK, I'll drop it
> >
> > > > +   help
> > > > + Adds "F" to the ISA subsets that the toolchain is allowed to 
> > > > emit
> > > > + when building U-Boot, which results in Single and
> > > > + Double-precision instructions
> > >
> > > This does not match what the config name says. The config name is for F 
> > > and it
> > > cannot indicate both F and D here.
> > >
> >
> > OK, I'll correct it as follows to cover F and D:
> > config RISCV_ISA_FD
> > bool "Emit Floating-point instructions"
> > help
> >   Adds "F" and "D" to the ISA subsets that the toolchain is allowed to 
> > emit
> >   when building U-Boot, which results in Single and Double-precision 
> > instructions
> >   in the U-Boot binary.
> >
> >
> > > > + in the U-Boot binary.
> > > > +
> > > >  config RISCV_ISA_A
> > > > def_bool y
> > > >
> > > > diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile index
> > > > 0b80eb8d86..87ec0ea4b5 100644
> > > > --- a/arch/riscv/Makefile
> > > > +++ b/arch/riscv/Makefile
> >

[U-Boot] [PATCH] riscv: add Kconfig entries for the F and D ISA extensions support

[Eric Lin]

This patch add Kconfig entries for the F (Single-Precision)
and D (Double-Precision) floating point instruction-set extensions.

Signed-off-by: Eric Lin 
---
 arch/riscv/Kconfig  |  8 
 arch/riscv/Makefile | 12 
 2 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 362f3cdc65..a8031fa230 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -91,6 +91,14 @@ config RISCV_ISA_C
  when building U-Boot, which results in compressed instructions in the
  U-Boot binary.
 
+config RISCV_ISA_F
+   bool "Emit Floating-point instructions"
+   default n
+   help
+ Adds "F" to the ISA subsets that the toolchain is allowed to emit
+ when building U-Boot, which results in Single and Double-precision 
instructions
+ in the U-Boot binary.
+
 config RISCV_ISA_A
def_bool y
 
diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
index 0b80eb8d86..87ec0ea4b5 100644
--- a/arch/riscv/Makefile
+++ b/arch/riscv/Makefile
@@ -5,15 +5,19 @@
 
 ifeq ($(CONFIG_ARCH_RV64I),y)
ARCH_BASE = rv64im
-   ABI = lp64
+   ABI := lp64
 endif
 ifeq ($(CONFIG_ARCH_RV32I),y)
ARCH_BASE = rv32im
-   ABI = ilp32
+   ABI := ilp32
 endif
 ifeq ($(CONFIG_RISCV_ISA_A),y)
ARCH_A = a
 endif
+ifeq ($(CONFIG_RISCV_ISA_F),y)
+   ARCH_F = fd
+   ABI := $(ABI)d
+endif
 ifeq ($(CONFIG_RISCV_ISA_C),y)
ARCH_C = c
 endif
@@ -24,8 +28,8 @@ ifeq ($(CONFIG_CMODEL_MEDANY),y)
CMODEL = medany
 endif
 
-ARCH_FLAGS = -march=$(ARCH_BASE)$(ARCH_A)$(ARCH_C) -mabi=$(ABI) \
--mcmodel=$(CMODEL)
+ARCH_FLAGS = -march=$(ARCH_BASE)$(ARCH_A)$(ARCH_F)$(ARCH_C) -mabi=$(ABI) \
+-mcmodel=$(CMODEL)
 
 PLATFORM_CPPFLAGS  += $(ARCH_FLAGS)
 CFLAGS_EFI += $(ARCH_FLAGS)
-- 
2.17.0

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

[U-Boot] sun50i: Allwinner A64: Add LVDS video support - question about how to proceed

[Kamps, John-Eric]

Hi all. 
I'm new in working with the community and where I can ask question about how 
something should be done. 

I need LVDS on the Allwinner A64 and checked the source code. 
There is the code for sunxi (A20 and so on) with the file "sunxi_display.c" 
and the new one for my sun50i (A64) "sunxi_de2.c". 
both are sharing files between each other but for sun50i the sunxi_display.c is 
disabled from kconfig for my chip. 

I see 2 ways to enable LVDS on sun50i, but I don't know in which direction the 
development should go. I can enable in KCONFIG that the sunxi_display could be 
also build for A64, but I think it has a reason why this is disabled and only 
the sunxi_de2 system should be used, or?

So going the way that there was a patch to enable the LCD over the sunxi_de2 
file (git: 1d7eef3f3fbd82796a4ced3adda0a9041393141d). I can add the needed 
pinmux settings in the corresponding files and enable in kconfig that there is 
also the menu to setup CONFIG_VIDEO_LCD_IF_LVDS and 
CONFIG_VIDEO_LCD_IF_PARALLEL like for CONFIG_VIDEO_SUNXI. Also with the other 
settings there.

Is these the correct way to add them?

If yes how the backlight will be used and added? Because the sunxi_display.c 
has it integrated with getting the extra settings from menuconfig. Is it needed 
to add the same settings as well to sunxi_lcd.c like in sunxi_display.c? Or is 
there a different system to enable backlight in the future from the information 
of the dts-files? If yes did someone can give me a hint where I can find 
something about it?

Thanks a lot
Kind regards
John-Eric Kamps

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

[U-Boot] [PATCH] imx: iomux-v3: fix IOMUX_PADS for single-CPU variant

[Eric Nelson]

When compiling for a single CPU variant (e.g. MX6Q or MX6DL),
the IOMUX constants are named MX6_PAD_blah, not MX6Q_PAD_blah.

Fix the macros IOMUX_PADS and SETUP_IOMUX_PAD to reflect this.

Signed-off-by: Eric Nelson 
---
 arch/arm/include/asm/mach-imx/iomux-v3.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/mach-imx/iomux-v3.h 
b/arch/arm/include/asm/mach-imx/iomux-v3.h
index bb93058..4be1c53 100644
--- a/arch/arm/include/asm/mach-imx/iomux-v3.h
+++ b/arch/arm/include/asm/mach-imx/iomux-v3.h
@@ -267,9 +267,9 @@ if (is_mx6dq() || is_mx6dqp()) {
\
 #define SETUP_IOMUX_PADS(x)\
imx_iomux_v3_setup_multiple_pads(x, ARRAY_SIZE(x)/2)
 #elif defined(CONFIG_MX6Q) || defined(CONFIG_MX6D)
-#define IOMUX_PADS(x) MX6Q_##x
+#define IOMUX_PADS(x) MX6_##x
 #define SETUP_IOMUX_PAD(def)   \
-   imx_iomux_v3_setup_pad(MX6Q_##def);
+   imx_iomux_v3_setup_pad(MX6_##def);
 #define SETUP_IOMUX_PADS(x)\
imx_iomux_v3_setup_multiple_pads(x, ARRAY_SIZE(x))
 #elif defined(CONFIG_MX6UL) || defined(CONFIG_MX6ULL)
-- 
2.7.4

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

Re: [U-Boot] [PATCH] ARM: mx6: ddr: Add write leveling correction code

[Eric Nelson]

Hi Marek,

Thanks for this update and the detailed notes.

On 03/29/2018 06:04 PM, Marek Vasut wrote:

When the DDR calibration is enabled, a situation may happen that it
will fail on a few select boards out of a whole production lot. In
particular, after the first write leveling stage, the MPWLDECTRLx
registers will contain a value 0x1nn , for nn usually being 0x7f or
slightly lower.

What this means is that the HW write leveling detected that the DQS
rising edge on one or more bundles arrives slightly _after_ CLK and
therefore when the DDR DRAM samples CLK on the DQS rising edge, the
CLK signal is already high (cfr. AN4467 rev2 Figure 7 on page 18).

The HW write leveling then ends up adding almost an entire cycle (thus
the 0x17f) to the DQS delay, which indeed aligns it, but also triggers
subsequent calibration failure in DQS gating due to this massive offset.

There are two observations here:
- If the MPWLDECTRLx value is corrected from 0x17f to 0x0 , then the
   DQS gating passes, the entire calibration passes as well and the
   DRAM is perfectly stable even under massive load.
- When using the NXP DRAM calibrator for iMX6/7, the value 0x17f or so
   in MPWLDECTRx register is not there, but it is replaced by 0x0 as one
   would expect.

Someone from NXP finally explains why, quoting [1]:

 "
 Having said all that, the DDR Stress Test does something that we
 do not advertise to the users. The Stress Test iself looks at the
 values of the MPWLDECTRL0/1 fields before reporting results, and
 if it sees any filed with a value greater than 200/256 delay
 (reported as half-cycle = 0x1 and ABS_OFFSET > 0x48), the DDR
 Stress test will reset the Write Leveling delay for this lane
 to 0x000 and not report it in the log.

 The reason that the DDR Stress test does this is because a delay
 of more than 78% a clock cycle means that the DQS edge is arriving
 within the JEDEC tolerence of 25% of the clock edge. In most cases,
 DQS is arriving < 5% tCK of the SDCLK edge in the early case, and
 it does not make sense to delay the DQS strobe almost a full clock
 cycle and add extra latency to each Write burst just to make the
 two edges align exactly. In this case, we are guilty of making a
 decision for the customer without telling them we are doing it so
 that we don't have to provide the above explanation to every customer.
 They don't need to know it.
 "

This patch adds the correction described above, that is if the MPWLDECTRx
value is over 0x148, the value is corrected back to 0x0.

[1] https://community.nxp.com/thread/456246

Signed-off-by: Marek Vasut <ma...@denx.de>
Cc: Stefano Babic <sba...@denx.de>
---
  arch/arm/mach-imx/mx6/ddr.c | 24 
  1 file changed, 24 insertions(+)

diff --git a/arch/arm/mach-imx/mx6/ddr.c b/arch/arm/mach-imx/mx6/ddr.c
index 43b77cfa41..6e5e40dd1a 100644
--- a/arch/arm/mach-imx/mx6/ddr.c
+++ b/arch/arm/mach-imx/mx6/ddr.c
@@ -85,6 +85,23 @@ static void modify_dg_result(u32 *reg_st0, u32 *reg_st1, u32 
*reg_ctrl)
writel(val_ctrl, reg_ctrl);
  }
  
+static void correct_mpwldectr_result(void *reg)

+{
+   /* Limit is 200/256 of CK, which is WL_HC_DELx | 0x48. */
+   const unsigned int limit = 0x148;
+   u32 val = readl(reg);
+   u32 old = val;
+


Nit: I think "val &= 0x" would be slightly easier to read
instead of the "<< 16":


+   if ((val & 0x17f) > limit)
+   val &= 0x << 16;
+
+   if (((val >> 16) & 0x17f) > limit)
+   val &= 0x;
+
+   if (old != val)
+   writel(val, reg);
+}
+
  int mmdc_do_write_level_calibration(struct mx6_ddr_sysinfo const *sysinfo)
  {
struct mmdc_p_regs *mmdc0 = (struct mmdc_p_regs *)MMDC_P0_BASE_ADDR;
@@ -176,6 +193,13 @@ int mmdc_do_write_level_calibration(struct mx6_ddr_sysinfo 
const *sysinfo)
errors |= 4;
}
  
+	correct_mpwldectr_result(>mpwldectrl0);

+   correct_mpwldectr_result(>mpwldectrl1);
+   if (sysinfo->dsize == 2) {
+   correct_mpwldectr_result(>mpwldectrl0);
+   correct_mpwldectr_result(>mpwldectrl1);
+   }
+
/*
 * User should issue MRS command to exit write leveling mode
 * through Load Mode Register command



Otherwise,

Reviewed-by: Eric Nelson <e...@nelint.com>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [RFC PATCH] SPL: allow fall-back to SDP boot

[Eric Nelson]

When SDP is enabled, allow it to be invoked as a fall-back
to allow re-programming a board with a full U-Boot loaded
over USB.

Signed-off-by: Eric Nelson <e...@nelint.com>
---
Since SDP loading is triggered through BOOT_DEVICE_BOARD, I'm not sure
if this should be specific to SDP.

 common/spl/spl.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/common/spl/spl.c b/common/spl/spl.c
index 76c1963..5bbd4ed 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -373,6 +373,9 @@ static int boot_from_devices(struct spl_image_info 
*spl_image,
 
 void board_init_r(gd_t *dummy1, ulong dummy2)
 {
+#ifdef CONFIG_SPL_USB_SDP_SUPPORT
+   int i;
+#endif
u32 spl_boot_list[] = {
BOOT_DEVICE_NONE,
BOOT_DEVICE_NONE,
@@ -417,6 +420,15 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
 #endif
board_boot_order(spl_boot_list);
 
+#ifdef CONFIG_SPL_USB_SDP_SUPPORT
+   for (i = 0; i < ARRAY_SIZE(spl_boot_list); i++) {
+   if (spl_boot_list[i] == BOOT_DEVICE_NONE) {
+   spl_boot_list[i] = BOOT_DEVICE_BOARD;
+   break;
+   }
+   }
+#endif
+
if (boot_from_devices(_image, spl_boot_list,
  ARRAY_SIZE(spl_boot_list))) {
puts("SPL: failed to boot from all boot devices\n");
-- 
2.7.4

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

[U-Boot] [PATCH] mx6memcal: fix comment in board header file

[Eric Nelson]

The board header file included a reference to the starting point
from nitrogen6x.h, but since so much changed, the file bears
little resemblance to that file.

Signed-off-by: Eric Nelson <e...@nelint.com>
---
 include/configs/mx6memcal.h | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/include/configs/mx6memcal.h b/include/configs/mx6memcal.h
index 28c67c4..5be8ce4 100644
--- a/include/configs/mx6memcal.h
+++ b/include/configs/mx6memcal.h
@@ -1,8 +1,7 @@
 /*
- * Copyright (C) 2010-2011 Freescale Semiconductor, Inc.
+ * Copyright (C) 2010-2018 Freescale Semiconductor, Inc.
  *
- * Configuration settings for the Boundary Devices Nitrogen6X
- * and Freescale i.MX6Q Sabre Lite boards.
+ * Configuration settings for the virtual mx6memcal board.
  *
  * SPDX-License-Identifier:GPL-2.0+
  */
-- 
2.7.4

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

[U-Boot] [PATCH 2/2] mx6memcal: enable SDP support

[Eric Nelson]

The initial implementation of mx6memcal reset the CPU after
running the memory calibration procedure because the generic
board has no information about which boot devices are available.

Now that we have SDP support in SPL, use it to allow a full
U-Boot to be uploaded (i.e. to use "mtest").

Signed-off-by: Eric Nelson <e...@nelint.com>
---
 board/freescale/mx6memcal/spl.c |  1 -
 configs/mx6memcal_defconfig | 10 ++
 include/configs/mx6memcal.h |  2 ++
 3 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/board/freescale/mx6memcal/spl.c b/board/freescale/mx6memcal/spl.c
index 8ee89ff..805fdab 100644
--- a/board/freescale/mx6memcal/spl.c
+++ b/board/freescale/mx6memcal/spl.c
@@ -452,5 +452,4 @@ void board_init_f(ulong dummy)
display_calibration();
}
}
-   reset_cpu(0);
 }
diff --git a/configs/mx6memcal_defconfig b/configs/mx6memcal_defconfig
index b27330c..d3720dc 100644
--- a/configs/mx6memcal_defconfig
+++ b/configs/mx6memcal_defconfig
@@ -8,6 +8,10 @@ CONFIG_SPL_SERIAL_SUPPORT=y
 CONFIG_SPL_WATCHDOG_SUPPORT=y
 CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg,SPL,MX6QDL"
 CONFIG_SPL=y
+CONFIG_SPL_USB_HOST_SUPPORT=y
+CONFIG_SPL_USB_GADGET_SUPPORT=y
+CONFIG_SPL_USBETH_SUPPORT=y
+CONFIG_SPL_USB_SDP_SUPPORT=y
 CONFIG_HUSH_PARSER=y
 # CONFIG_CMD_BOOTD is not set
 # CONFIG_CMD_BOOTM is not set
@@ -29,4 +33,10 @@ CONFIG_CMD_MEMTEST=y
 # CONFIG_CMD_NFS is not set
 CONFIG_CMD_CACHE=y
 # CONFIG_MMC is not set
+CONFIG_USB=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_MANUFACTURER="FSL"
+CONFIG_USB_GADGET_VENDOR_NUM=0x0525
+CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5
+CONFIG_CI_UDC=y
 CONFIG_REGEX=y
diff --git a/include/configs/mx6memcal.h b/include/configs/mx6memcal.h
index f5238a5..28c67c4 100644
--- a/include/configs/mx6memcal.h
+++ b/include/configs/mx6memcal.h
@@ -56,4 +56,6 @@
 
 #define CONFIG_ENV_SIZE(8 * 1024)
 
+#define CONFIG_MXC_USB_PORTSC  PORT_PTS_UTMI
+
 #endif/* __CONFIG_H */
-- 
2.7.4

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

[U-Boot] [PATCH 1/2] mx6memcal: launder through savedefconfig

[Eric Nelson]

This patch just changes the order of configuration items in
mx6memcal_defconfig to match the Kconfig layout, making it easier
to track changes made using menuconfig.

Signed-off-by: Eric Nelson <e...@nelint.com>
---
 configs/mx6memcal_defconfig | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/configs/mx6memcal_defconfig b/configs/mx6memcal_defconfig
index 9a3bb83..b27330c 100644
--- a/configs/mx6memcal_defconfig
+++ b/configs/mx6memcal_defconfig
@@ -9,25 +9,24 @@ CONFIG_SPL_WATCHDOG_SUPPORT=y
 CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg,SPL,MX6QDL"
 CONFIG_SPL=y
 CONFIG_HUSH_PARSER=y
-# CONFIG_MMC is not set
 # CONFIG_CMD_BOOTD is not set
 # CONFIG_CMD_BOOTM is not set
 # CONFIG_CMD_ELF is not set
 # CONFIG_CMD_IMI is not set
-# CONFIG_CMD_IMLS is not set
 # CONFIG_CMD_XIMG is not set
 # CONFIG_CMD_EXPORTENV is not set
 # CONFIG_CMD_IMPORTENV is not set
 # CONFIG_CMD_EDITENV is not set
 # CONFIG_CMD_SAVEENV is not set
 # CONFIG_CMD_ENV_EXISTS is not set
-CONFIG_CMD_MEMTEST=y
 CONFIG_CMD_MEMINFO=y
-# CONFIG_CMD_LOADB is not set
-# CONFIG_CMD_LOADS is not set
+CONFIG_CMD_MEMTEST=y
 # CONFIG_CMD_FLASH is not set
 # CONFIG_CMD_FPGA is not set
+# CONFIG_CMD_LOADB is not set
+# CONFIG_CMD_LOADS is not set
 # CONFIG_CMD_NET is not set
 # CONFIG_CMD_NFS is not set
 CONFIG_CMD_CACHE=y
+# CONFIG_MMC is not set
 CONFIG_REGEX=y
-- 
2.7.4

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

[U-Boot] [PATCH V2] imx: mx7dsabresd: include BLK for MMC/eMMC support of driver model

[Eric Nelson]

Commit 6fbbcfd introduced device-tree support for MMC devices on
the mx7sabresd boards and didn't include BLK, which requires BLK.

Commit 8ae5bb3 did the same for secure boot.

Fix both by allowing blk-uclass (BLK) support.

Tested-by: Fabio Estevam <feste...@gmail.com>
Signed-off-by: Eric Nelson <e...@nelint.com>
---
V2 includes the updated to mx7dsabresd_secure_defconfig
 configs/mx7dsabresd_defconfig| 1 -
 configs/mx7dsabresd_secure_defconfig | 1 -
 2 files changed, 2 deletions(-)

diff --git a/configs/mx7dsabresd_defconfig b/configs/mx7dsabresd_defconfig
index 795c4f2..144fb50 100644
--- a/configs/mx7dsabresd_defconfig
+++ b/configs/mx7dsabresd_defconfig
@@ -38,7 +38,6 @@ CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_OF_CONTROL=y
-# CONFIG_BLK is not set
 CONFIG_DFU_MMC=y
 CONFIG_DFU_RAM=y
 CONFIG_DM_GPIO=y
diff --git a/configs/mx7dsabresd_secure_defconfig 
b/configs/mx7dsabresd_secure_defconfig
index bd68831..d1af138 100644
--- a/configs/mx7dsabresd_secure_defconfig
+++ b/configs/mx7dsabresd_secure_defconfig
@@ -40,7 +40,6 @@ CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_OF_CONTROL=y
-# CONFIG_BLK is not set
 CONFIG_DFU_MMC=y
 CONFIG_DFU_RAM=y
 CONFIG_DM_GPIO=y
-- 
2.7.4

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

Re: [U-Boot] [PATCH] imx: mx7dsabresd: include BLK for MMC/eMMC support of driver model

[Eric Nelson]

Hi Tom,

On 10/11/2017 01:51 PM, Tom Rini wrote:

On Wed, Oct 11, 2017 at 05:50:04PM -0300, Fabio Estevam wrote:

Hi Eric,

That was the fix I was waiting for, thanks!

On Wed, Oct 11, 2017 at 5:29 PM, Eric Nelson <e...@nelint.com> wrote:

Please add a commit log and explain that this fixes a regression.


Change-Id: I1bdfffe782a61a4c688f1bb56e85448024cd497b


Please remove this line.

Also, when you send a v2, please do the same change in
mx7dsabresd_secure_defconfig.


Signed-off-by: Eric Nelson <e...@nelint.com>


Now I can boot a kernel successfully, thanks:

Tested-by: Fabio Estevam <fabio.este...@nxp.com>


Is there perhaps a dependency here we need to enforce via Kconfig so
this isn't a game of whack-a-mole?  Thanks!



We have a "default Y if DM" for it, which should be enough.

http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/block/Kconfig;h=26760895f99dd53370f9077f5b7213a1a6f241fe;hb=HEAD#l3

Commit 6fbbcfd explicitly disabled it when converting to
DM_MMC (secure_defconfig followed suit in commit 8ae5bb3), and
that's where the trouble came in.

Hmmm. A quick search shows that quite a few configurations
have this choice (CONFIG_DM_MMC without CONFIG_BLK):

~u-boot/configs$ git grep -l CONFIG_DM_MMC=y | xargs grep BLK
am335x_boneblack_vboot_defconfig:# CONFIG_BLK is not set
am335x_evm_defconfig:# CONFIG_BLK is not set
am335x_hs_evm_defconfig:# CONFIG_BLK is not set
am43xx_evm_defconfig:# CONFIG_BLK is not set
am43xx_evm_usbhost_boot_defconfig:# CONFIG_BLK is not set
am43xx_hs_evm_defconfig:# CONFIG_BLK is not set
am57xx_evm_defconfig:# CONFIG_BLK is not set
am57xx_hs_evm_defconfig:# CONFIG_BLK is not set
k2g_evm_defconfig:# CONFIG_BLK is not set
k2g_hs_evm_defconfig:# CONFIG_BLK is not set
ls1012aqds_qspi_defconfig:# CONFIG_BLK is not set
ls1012ardb_qspi_defconfig:# CONFIG_BLK is not set
mx6slevk_defconfig:# CONFIG_BLK is not set
mx6slevk_spinor_defconfig:# CONFIG_BLK is not set
mx6sllevk_defconfig:# CONFIG_BLK is not set
mx6sllevk_plugin_defconfig:# CONFIG_BLK is not set
mx6sxsabreauto_defconfig:# CONFIG_BLK is not set
mx6ull_14x14_evk_defconfig:# CONFIG_BLK is not set
mx6ull_14x14_evk_plugin_defconfig:# CONFIG_BLK is not set
mx7ulp_evk_defconfig:# CONFIG_BLK is not set
mx7ulp_evk_plugin_defconfig:# CONFIG_BLK is not set
omap3_logic_defconfig:# CONFIG_BLK is not set
pic32mzdask_defconfig:# CONFIG_BLK is not set

Are all of these broken?

I don't have any of the other boards, and am not in a
position to say whether there's a legitimate use case
for DM_MMC without BLK.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] imx: mx7dsabresd: include BLK for MMC/eMMC support of driver model

[Eric Nelson]

Hi Fabio,

On 10/11/2017 01:50 PM, Fabio Estevam wrote:

Hi Eric,

That was the fix I was waiting for, thanks!



Glad to hear it.


On Wed, Oct 11, 2017 at 5:29 PM, Eric Nelson <e...@nelint.com> wrote:

Please add a commit log and explain that this fixes a regression.



Okay. If you insist ;)


Change-Id: I1bdfffe782a61a4c688f1bb56e85448024cd497b


Please remove this line.



Oops. I think we need to refresh checkpatch. I think the
version in the kernel tree checks for that.


Also, when you send a v2, please do the same change in
mx7dsabresd_secure_defconfig.



Okay.


Signed-off-by: Eric Nelson <e...@nelint.com>


Now I can boot a kernel successfully, thanks:

Tested-by: Fabio Estevam <fabio.este...@nxp.com>



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

[U-Boot] [PATCH] imx: mx7dsabresd: include BLK for MMC/eMMC support of driver model

[Eric Nelson]

Change-Id: I1bdfffe782a61a4c688f1bb56e85448024cd497b
Signed-off-by: Eric Nelson <e...@nelint.com>
---
 configs/mx7dsabresd_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/configs/mx7dsabresd_defconfig b/configs/mx7dsabresd_defconfig
index 795c4f2..144fb50 100644
--- a/configs/mx7dsabresd_defconfig
+++ b/configs/mx7dsabresd_defconfig
@@ -38,7 +38,6 @@ CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_OF_CONTROL=y
-# CONFIG_BLK is not set
 CONFIG_DFU_MMC=y
 CONFIG_DFU_RAM=y
 CONFIG_DM_GPIO=y
-- 
2.7.4

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

Re: [U-Boot] [PATCH V2] imx: mx7: Add support for USB and normal boot modes

[Eric Nelson]

Hi Stefano,

On 10/02/2017 06:21 AM, Stefano Babic wrote:

On 31/08/2017 00:13, Eric Nelson wrote:

This adds support for two additional boot modes on the i.MX7D SoC, which
is most useful when doing U-Boot development on this chip.

1. "bmode usb" can be used to force the ROM boot loader's serial
2. "bmode normal" can be used to revert to the normal boot mode
as specified by fuses and BOOT_MODE pins

Signed-off-by: Eric Nelson <e...@nelint.com>
---
V2 adds "normal" mode as suggested by Troy Kisky
  arch/arm/mach-imx/mx7/soc.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-imx/mx7/soc.c b/arch/arm/mach-imx/mx7/soc.c
index 87bf105..15be42a 100644
--- a/arch/arm/mach-imx/mx7/soc.c
+++ b/arch/arm/mach-imx/mx7/soc.c
@@ -372,6 +372,9 @@ void set_wdog_reset(struct wdog_regs *wdog)
   * to SBMR1, which will determine the boot device.
   */
  const struct boot_mode soc_boot_modes[] = {
+   {"normal",MAKE_CFGVAL(0x00, 0x00, 0x00, 0x00)},
+   {"usb",   MAKE_CFGVAL(0x01, 0x00, 0x00, 0x00)},
+
{"ecspi1:0",  MAKE_CFGVAL(0x00, 0x60, 0x00, 0x00)},
{"ecspi1:1",  MAKE_CFGVAL(0x40, 0x62, 0x00, 0x00)},
{"ecspi1:2",  MAKE_CFGVAL(0x80, 0x64, 0x00, 0x00)},



Sorry, it was for a long time in the queue - discussion in thread is
spreading away from the original review (I had errouneosly set it to
Changes requested).

Applied to u-boot-imx, -master, thanks !



Sorry, but we rejected this patch (because it doesn't work).

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

Regards,


Eric

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

Re: [U-Boot] [PATCH v3 2/2] imx_common: detect USB serial downloader reliably

[Eric Nelson]

Hi Stefan,

Thanks for this patch.

On 09/13/2017 02:29 PM, Stefan Agner wrote:

From: Stefan Agner <stefan.ag...@toradex.com>

The current mechanism using SCR/GPR registers work well when
the serial downloader boot mode has been selected explicitly
(either via boot mode pins or using bmode command). However,
in case the system entered boot ROM due to unbootable primary
boot devices (e.g. empty eMMC), the SPL fails to detect that
it has been downloaded through serial loader and tries to
continue booting from eMMC:
   Trying to boot from MMC1
   mmc_load_image_raw_sector: mmc block read error
   SPL: failed to boot from all boot devices
   ### ERROR ### Please RESET the board ###

The only known way to reliably detect USB serial downloader
is by checking the USB PHY receiver block power state...

Signed-off-by: Stefan Agner <stefan.ag...@toradex.com>
Acked-by: Marcel Ziswiler <marcel.ziswi...@toradex.com>
Tested-by: Fabio Estevam <fabio.este...@nxp.com>
---

Changes in v4:
- Rename macro to is_usbotg_phy_active()

Changes in v3:
- Fix spelling and grammar

Changes in v2:
- Add comment that we infer boot ROM behavior from USB PHY state

  arch/arm/mach-imx/spl.c | 12 
  1 file changed, 12 insertions(+)

diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c
index 258578ac25..534cc6504d 100644
--- a/arch/arm/mach-imx/spl.c
+++ b/arch/arm/mach-imx/spl.c
@@ -31,6 +31,18 @@ u32 spl_boot_device(void)
if (((bmode >> 24) & 0x03) == 0x01) /* Serial Downloader */
return BOOT_DEVICE_BOARD;
  
+	/*

+* The above method does not detect that the boot ROM used
+* serial downloader in case the boot ROM decided to use the
+* serial downloader as a fall back (primary boot source failed).
+*
+* Infer that the boot ROM used the USB serial downloader by
+* checking whether the USB PHY is currently active... This
+* assumes that SPL did not (yet) initialize the USB PHY...
+*/
+   if (is_otgusb_phy_active())
+   return BOOT_DEVICE_BOARD;
+
/* BOOT_CFG1[7:4] - see IMX6DQRM Table 8-8 */
switch ((reg & IMX6_BMODE_MASK) >> IMX6_BMODE_SHIFT) {
 /* EIM: See 8.5.1, Table 8-9 */



Reviewed-by: Eric Nelson <e...@nelint.com>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 1/2] imx: add macro to detect whether USB PHY is active

[Eric Nelson]

On 09/13/2017 02:29 PM, Stefan Agner wrote:

From: Stefan Agner <stefan.ag...@toradex.com>

This macro allows to detect whether the USB PHY is active. This
is helpful to detect if the boot ROM has previously started the
USB serial downloader.

The idea is taken from the mfgtool support in the NXP U-Boot:
http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/commit/?h=imx_v2016.03_4.1.15_2.0.0_ga=a352ed3c5184b95c4c9f7468f5fbb5f43de5e412

Signed-off-by: Stefan Agner <stefan.ag...@toradex.com>
Acked-by: Marcel Ziswiler <marcel.ziswi...@toradex.com>
Tested-by: Fabio Estevam <fabio.este...@nxp.com>
---

Changes in v4:
- Rename macro to is_usbotg_phy_active()

Changes in v3: None
Changes in v2:
- Move macro to sys_proto.h
- Renamed from is_boot_from_usb() to is_usbphy_active()
- Use defines for register offset and field
- Remove tab after define
- Remove comment since the actual "magic" is happening and
   documented at usage side

  arch/arm/include/asm/arch-mx6/sys_proto.h | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/arch/arm/include/asm/arch-mx6/sys_proto.h 
b/arch/arm/include/asm/arch-mx6/sys_proto.h
index 14f5d948c9..ba73943260 100644
--- a/arch/arm/include/asm/arch-mx6/sys_proto.h
+++ b/arch/arm/include/asm/arch-mx6/sys_proto.h
@@ -6,3 +6,10 @@
   */
  
  #include 


I'd be more worried about these macro names (asking that they also
include "OTG") if they weren't defined in such close proximity to
their only use.


+
+#define USBPHY_PWD 0x
+
+#define USBPHY_PWD_RXPWDRX (1 << 20) /* receiver block power down */
+
+#define is_usbotg_phy_active(void) (!(readl(USB_PHY0_BASE_ADDR + USBPHY_PWD) & 
\
+  USBPHY_PWD_RXPWDRX))



Otherwise,

Reviewed-by: Eric Nelson <e...@nelint.com>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 1/2] imx: add macro to detect whether USB PHY is active

[Eric Nelson]

Hi Stefan,

On 09/13/2017 12:47 PM, Stefan Agner wrote:

On 2017-09-13 02:19, Stefano Babic wrote:

Hi Eric, Stefan,

On 13/09/2017 02:30, Eric Nelson wrote:

Hi Stefan,

I hate to be fussy about this, but I don't think I saw a reply
to my earlier comment about the term "USB PHY".

https://lists.denx.de/pipermail/u-boot/2017-September/305123.html

Since i.MX6 SoCs have USB **Host** Phy's as well as the USB OTG Phy,
this patch is a bit misleading.

There's no reference to OTG anywhere in this or patch 2.



Hm, sorry I missed that.


No worries. We're here to nag...



To be consistent with the names, Eric is right. We have PHY0 for OTG and
PHY1 for Host. If you still want to use as name is_usbphy_active, then
this should take as parameter the phy number, or you switch to a "otg"
name to ensure that it is only for the OTG interface.


For the registers itself I followed the notation used in chapter 66 and
arch/arm/include/asm/arch-mx6/imx-regs.h.

Renaming the function macro makes sense I agree.

The USB serial downloader only works with the OTG USB PHY anyway, so I
will rename it. I like to have USB still in there, how about:

is_usbotg_phy_active()



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

Re: [U-Boot] [PATCH v3 1/2] imx: add macro to detect whether USB PHY is active

[Eric Nelson]

Hi Stefan,

I hate to be fussy about this, but I don't think I saw a reply
to my earlier comment about the term "USB PHY".

https://lists.denx.de/pipermail/u-boot/2017-September/305123.html

Since i.MX6 SoCs have USB **Host** Phy's as well as the USB OTG Phy,
this patch is a bit misleading.

There's no reference to OTG anywhere in this or patch 2.

On 09/12/2017 04:54 PM, Stefan Agner wrote:

From: Stefan Agner <stefan.ag...@toradex.com>

This macro allows to detect whether the USB PHY is active. This
is helpful to detect if the boot ROM has previously started the
USB serial downloader.

The idea is taken from the mfgtool support in the NXP U-Boot:
http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/commit/?h=imx_v2016.03_4.1.15_2.0.0_ga=a352ed3c5184b95c4c9f7468f5fbb5f43de5e412

Signed-off-by: Stefan Agner <stefan.ag...@toradex.com>
Acked-by: Marcel Ziswiler <marcel.ziswi...@toradex.com>
Tested-by: Fabio Estevam <fabio.este...@nxp.com>
---

Changes in v3: None
Changes in v2:
- Move macro to sys_proto.h
- Renamed from is_boot_from_usb() to is_usbphy_active()
- Use defines for register offset and field
- Remove tab after define
- Remove comment since the actual "magic" is happening and
   documented at usage side

  arch/arm/include/asm/arch-mx6/sys_proto.h | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/arch/arm/include/asm/arch-mx6/sys_proto.h 
b/arch/arm/include/asm/arch-mx6/sys_proto.h
index 14f5d948c9..9d4b1d6768 100644
--- a/arch/arm/include/asm/arch-mx6/sys_proto.h
+++ b/arch/arm/include/asm/arch-mx6/sys_proto.h
@@ -6,3 +6,10 @@
   */
  
  #include 

+
+#define USBPHY_PWD 0x
+
+#define USBPHY_PWD_RXPWDRX (1 << 20) /* receiver block power down */
+
+#define is_usbphy_active(void) (!(readl(USB_PHY0_BASE_ADDR + USBPHY_PWD) & \
+      USBPHY_PWD_RXPWDRX))



Regards,


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

Re: [U-Boot] [PATCH v2 2/2] imx_common: detect USB serial downloader reliably

[Eric Nelson]

Hi Stefan,

On 09/08/2017 05:35 PM, Fabio Estevam wrote:

On Fri, Sep 8, 2017 at 8:35 PM, Stefan Agner  wrote:


+   /*
+* The above method does not detect that the boot ROM used
+* serial downloader in case the boot ROM descided to use the 


Typo: decided



You know you're on the right track when the only comments about
your patch are about naming, spelling and grammar ;)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 2/2] imx_common: detect USB serial downloader reliably

[Eric Nelson]

Hi Stefan,

On 09/08/2017 05:16 PM, Stefan Agner wrote:

On 2017-09-08 16:41, Eric Nelson wrote:

On 09/08/2017 04:35 PM, Stefan Agner wrote:

From: Stefan Agner <stefan.ag...@toradex.com>







Nit: should be "did not initialize" instead of "initialized".


Sorry, don't get that. Below I write "did not (yet) initialized"...



The proper English usage here is "did not (yet) initialize".

You don't need the past tense after "did not".

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

Re: [U-Boot] [PATCH v2 2/2] imx_common: detect USB serial downloader reliably

[Eric Nelson]

Hi Stefan,

On 09/08/2017 04:35 PM, Stefan Agner wrote:

From: Stefan Agner 

The current mechanism using SCR/GPR registers work well when
the serial downloader boot mode has been selected explicitly
(either via boot mode pins or using bmode command). However,
in case the system entered boot ROM due to unbootable primary
boot devices (e.g. empty eMMC), the SPL fails to detect that
it has been downloaded through serial loader and tries to
continue booting from eMMC:
   Trying to boot from MMC1
   mmc_load_image_raw_sector: mmc block read error
   SPL: failed to boot from all boot devices
   ### ERROR ### Please RESET the board ###

The only known way to reliably detect USB serial downloader
is by checking the USB PHY receiver block power state...

Signed-off-by: Stefan Agner 
Acked-by: Marcel Ziswiler 
Tested-by: Fabio Estevam 
---

Changes in v2:
- Add comment that we infer boot ROM behavior from USB PHY state

  arch/arm/mach-imx/spl.c | 12 
  1 file changed, 12 insertions(+)

diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c
index 258578ac25..f3fec81de7 100644
--- a/arch/arm/mach-imx/spl.c
+++ b/arch/arm/mach-imx/spl.c
@@ -31,6 +31,18 @@ u32 spl_boot_device(void)
if (((bmode >> 24) & 0x03) == 0x01) /* Serial Downloader */
return BOOT_DEVICE_BOARD;
  
+	/*

+* The above method does not detect that the boot ROM used
+* serial downloader in case the boot ROM descided to use the
+* serial downloader as a fall back (primary boot source failed).
+*


Nit: should be "did not initialize" instead of "initialized".

Otherwise, this is a nice comment that describes the situation.


+* Infer that the boot ROM used the USB serial downloader by
+* checking whether the USB PHY is currently active... This
+* assumes that SPL did not (yet) initialized the USB PHY...
+*/
+   if (is_usbphy_active())
+   return BOOT_DEVICE_BOARD;
+
/* BOOT_CFG1[7:4] - see IMX6DQRM Table 8-8 */
switch ((reg & IMX6_BMODE_MASK) >> IMX6_BMODE_SHIFT) {
 /* EIM: See 8.5.1, Table 8-9 */


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

Re: [U-Boot] [PATCH v2 1/2] imx: add macro to detect whether USB PHY is active

[Eric Nelson]

Hi Stefan,

On 09/08/2017 04:35 PM, Stefan Agner wrote:

From: Stefan Agner 

This macro allows to detect whether the USB PHY is active. This
is helpful to detect if the boot ROM has previously started the
USB serial downloader.

The idea is taken from the mfgtool support in the NXP U-Boot:
http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/commit/?h=imx_v2016.03_4.1.15_2.0.0_ga=a352ed3c5184b95c4c9f7468f5fbb5f43de5e412

Signed-off-by: Stefan Agner 
Acked-by: Marcel Ziswiler 
Tested-by: Fabio Estevam 
---

Changes in v2:
- Move macro to sys_proto.h
- Renamed from is_boot_from_usb() to is_usbphy_active()
- Use defines for register offset and field
- Remove tab after define
- Remove comment since the actual "magic" is happening and
   documented at usage side

  arch/arm/include/asm/arch-mx6/sys_proto.h | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/arch/arm/include/asm/arch-mx6/sys_proto.h 
b/arch/arm/include/asm/arch-mx6/sys_proto.h
index 14f5d948c9..9d4b1d6768 100644
--- a/arch/arm/include/asm/arch-mx6/sys_proto.h
+++ b/arch/arm/include/asm/arch-mx6/sys_proto.h
@@ -6,3 +6,10 @@
   */
  
  #include 

+
+#define USBPHY_PWD 0x
+
+#define USBPHY_PWD_RXPWDRX (1 << 20) /* receiver block power down */
+


At least MX6 and MX7 have USB Host PHY as well as USB OTG.

How about is_otgphy_active() instead?


+#define is_usbphy_active(void) (!(readl(USB_PHY0_BASE_ADDR + USBPHY_PWD) & \
+  USBPHY_PWD_RXPWDRX))


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

Re: [U-Boot] video: ipu_common: fix build error

[Eric Nelson]

On 09/06/2017 11:01 PM, Lothar Waßmann wrote:

On Wed, 6 Sep 2017 10:34:33 -0700 Eric Nelson wrote:

On 09/05/2017 06:16 PM, Peng Fan wrote:

On Mon, Sep 04, 2017 at 07:48:56PM -0700, Eric Nelson wrote:

Hi Peng,

Can you tell that I'm hunting a bug in an old version?

I'm seeing a **very** intermittent regression between U-Boot
versions 2015.07 and 2016.05 and happened to spot something
in this patch.

On 04/27/2016 07:07 PM, Peng Fan wrote:

Some toolchains fail to build
"clk->rate = (u64)(clk->parent->rate * 16) / div;"
And the cast usage is wrong.

Use the following code to fix the issue,
"
do_div(parent_rate, div);
clk->rate = parent_rate;
"

Reported-by: Peter Robinson <pbrobin...@gmail.com>
Signed-off-by: Peng Fan <van.free...@gmail.com>
Cc: Stefano Babic <sba...@denx.de>
Cc: Fabio Estevam <fabio.este...@nxp.com>
Cc: Tom Rini <tr...@konsulko.com>
Cc: Anatolij Gustschin <ag...@denx.de>
Cc: Peter Robinson <pbrobin...@gmail.com>
Reviewed-by: Tom Rini <tr...@konsulko.com>
Tested-by: Peter Robinson <pbrobin...@gmail.com>
---

Hi Peter,

   Please help test this patch to see whether this fix your issue or not.
   Thanks for pointing out this issue.

Thanks,
Peng.

   drivers/video/ipu_common.c | 4 +++-
   1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/video/ipu_common.c b/drivers/video/ipu_common.c
index 36d4b23..5676a0f 100644
--- a/drivers/video/ipu_common.c
+++ b/drivers/video/ipu_common.c
@@ -352,7 +352,9 @@ static int ipu_pixel_clk_set_rate(struct clk *clk, unsigned 
long rate)
 */
__raw_writel((div / 16) << 16, DI_BS_CLKGEN1(clk->id));


Did we lose a multiply by 16 in this change?


We already have "parent_rate = (unsigned long long)clk->parent->rate * 16;"
in this function.



Hmmm. So this patch also fixed a bug, since we previously had
**two** multiply-by-16's:


No! The 'second' multiply by 16 used the clk->parent->rate, not the
'parent_rate' which was multiplied by 16...

| parent_rate = (unsigned long long)clk->parent->rate * 16;
[...]
| clk->rate = (u64)(clk->parent->rate * 16) / div;



Doh! I clearly missed that.

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

Re: [U-Boot] [PATCH] ipu_common: Let the MX6 IPU clock be calculated in run-time

[Eric Nelson]

Thanks Fabio,

On 09/06/2017 09:49 AM, Fabio Estevam wrote:

From: Fabio Estevam <fabio.este...@nxp.com>

MX6Q/QP IPU operates at 264MHz and MX6DL IPU at 198MHz.

When running a SPL target, which supports multiple MX6 variants we cannot
properly setup the IPU clock frequency via CONFIG_IPUV3_CLK option as
such decision is done in build-time currently.

Remove the CONFIG_IPUV3_CLK option and let the IPU clock frequency be
configured in run-time on mx6.

Reported-by: Eric Nelson <e...@nelint.com>
Signed-off-by: Fabio Estevam <fabio.este...@nxp.com>
---
Changes since v1:
- Improve the mx6 detection logic (Troy)

  drivers/video/ipu_common.c| 14 +-
  include/configs/advantech_dms-ba16.h  |  1 -
  include/configs/apalis_imx6.h |  1 -
  include/configs/aristainetos-common.h |  1 -
  include/configs/cgtqmx6eval.h |  4 
  include/configs/cm_fx6.h  |  1 -
  include/configs/colibri_imx6.h|  1 -
  include/configs/embestmx6boards.h |  1 -
  include/configs/ge_bx50v3.h   |  1 -
  include/configs/gw_ventana.h  |  1 -
  include/configs/imx6-engicam.h|  1 -
  include/configs/m53evk.h  |  1 -
  include/configs/mx51evk.h |  1 -
  include/configs/mx53cx9020.h  |  1 -
  include/configs/mx53loco.h|  1 -
  include/configs/mx6cuboxi.h   |  1 -
  include/configs/mx6sabre_common.h |  5 -
  include/configs/nitrogen6x.h  |  1 -
  include/configs/novena.h  |  1 -
  include/configs/tbs2910.h |  1 -
  include/configs/wandboard.h   |  1 -
  scripts/config_whitelist.txt  |  1 -
  22 files changed, 13 insertions(+), 29 deletions(-)

diff --git a/drivers/video/ipu_common.c b/drivers/video/ipu_common.c
index f8d4488..a9584b8 100644
--- a/drivers/video/ipu_common.c
+++ b/drivers/video/ipu_common.c
@@ -19,6 +19,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include "ipu.h"
  #include "ipu_regs.h"
@@ -81,6 +82,11 @@ struct ipu_ch_param {
  
  #define IPU_SW_RST_TOUT_USEC	(1)
  
+#define IPUV3_CLK_MX51		13300

+#define IPUV3_CLK_MX53 2
+#define IPUV3_CLK_MX6Q 26400
+#define IPUV3_CLK_MX6DL19800
+
  void clk_enable(struct clk *clk)
  {
if (clk) {
@@ -196,7 +202,6 @@ static void clk_ipu_disable(struct clk *clk)
  
  static struct clk ipu_clk = {

.name = "ipu_clk",
-   .rate = CONFIG_IPUV3_CLK,
  #if defined(CONFIG_MX51) || defined(CONFIG_MX53)
.enable_reg = (u32 *)(CCM_BASE_ADDR +
offsetof(struct mxc_ccm_reg, CCGR5)),
@@ -476,6 +481,13 @@ int ipu_probe(void)
g_pixel_clk[1] = _clk[1];
  
  	g_ipu_clk = _clk;

+#if defined(CONFIG_MX51)
+   g_ipu_clk->rate = IPUV3_CLK_MX51;
+#elif defined(CONFIG_MX53)
+   g_ipu_clk->rate = IPUV3_CLK_MX53;
+#else
+   g_ipu_clk->rate = is_mx6sdl() ? IPUV3_CLK_MX6DL : IPUV3_CLK_MX6Q;
+#endif
debug("ipu_clk = %u\n", clk_get_rate(g_ipu_clk));
g_ldb_clk = _clk;
debug("ldb_clk = %u\n", clk_get_rate(g_ldb_clk));
diff --git a/include/configs/advantech_dms-ba16.h 
b/include/configs/advantech_dms-ba16.h
index 6329bf6..6e380d0 100644
--- a/include/configs/advantech_dms-ba16.h
+++ b/include/configs/advantech_dms-ba16.h
@@ -260,7 +260,6 @@
  #define CONFIG_BMP_16BPP
  #define CONFIG_VIDEO_LOGO
  #define CONFIG_VIDEO_BMP_LOGO
-#define CONFIG_IPUV3_CLK26000
  #define CONFIG_IMX_HDMI
  #define CONFIG_IMX_VIDEO_SKIP
  #endif
diff --git a/include/configs/apalis_imx6.h b/include/configs/apalis_imx6.h
index 16af141..f10ce6d 100644
--- a/include/configs/apalis_imx6.h
+++ b/include/configs/apalis_imx6.h
@@ -124,7 +124,6 @@
  #define CONFIG_BMP_16BPP
  #define CONFIG_VIDEO_LOGO
  #define CONFIG_VIDEO_BMP_LOGO
-#define CONFIG_IPUV3_CLK   26000
  #define CONFIG_CONSOLE_MUX
  #define CONFIG_IMX_HDMI
  #define CONFIG_IMX_VIDEO_SKIP
diff --git a/include/configs/aristainetos-common.h 
b/include/configs/aristainetos-common.h
index 1c28fcf..3afc7a6 100644
--- a/include/configs/aristainetos-common.h
+++ b/include/configs/aristainetos-common.h
@@ -217,7 +217,6 @@
  #define CONFIG_BMP_16BPP
  #define CONFIG_VIDEO_LOGO
  #define CONFIG_VIDEO_BMP_LOGO
-#define CONFIG_IPUV3_CLK 19800
  #define CONFIG_IMX_VIDEO_SKIP
  
  #define CONFIG_PWM_IMX

diff --git a/include/configs/cgtqmx6eval.h b/include/configs/cgtqmx6eval.h
index 4996a89..6a6c063 100644
--- a/include/configs/cgtqmx6eval.h
+++ b/include/configs/cgtqmx6eval.h
@@ -87,10 +87,6 @@
  #define CONFIG_BMP_16BPP
  #define CONFIG_VIDEO_LOGO
  #define CONFIG_VIDEO_BMP_LOGO
-#ifdef CONFIG_MX6DL
-#define CONFIG_IPUV3_CLK 19800
-#else
-#define CONFIG_IPUV3_CLK 26400
  #endif
  #define CONFIG_IMX_HDMI
  
diff --git a/include/configs/cm_fx6.h b/include/configs/cm_fx6.h

index 4f45be1..5d4b670 100644
--- a/include/config

Re: [U-Boot] [U-Boot,2/3] imx: mx6: correct IPU clock

[Eric Nelson]

Thanks Ye (and Peng).

On 09/06/2017 02:37 AM, Ye Li wrote:

On 9/5/2017 6:33 PM, Eric Nelson wrote:

Hi Peng,

Pardon the reference to an old update, but do you have a description
of the symptoms that brought about this patch?

On 03/09/2016 01:07 AM, Peng Fan wrote:

The CONFIG_IPUV3_CLK should be 26400, to i.MX6DL, it should be
19800.

Signed-off-by: Peng Fan <van.free...@gmail.com>
Signed-off-by: Sandor Yu <sandor...@nxp.com>
Cc: Stefano Babic <sba...@denx.de>
Cc: Fabio Estevam <fabio.este...@nxp.com>
Cc: Peter Robinson <pbrobin...@gmail.com>
---
include/configs/mx6sabre_common.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/include/configs/mx6sabre_common.h 
b/include/configs/mx6sabre_common.h
index 29d1f91..a6d821b 100644
--- a/include/configs/mx6sabre_common.h
+++ b/include/configs/mx6sabre_common.h
@@ -225,7 +225,11 @@
#define CONFIG_BMP_16BPP
#define CONFIG_VIDEO_LOGO
#define CONFIG_VIDEO_BMP_LOGO
-#define CONFIG_IPUV3_CLK 26000
+#ifdef CONFIG_MX6DL
+#define CONFIG_IPUV3_CLK 19800
+#else
+#define CONFIG_IPUV3_CLK 26400
+#endif



Note that this should probably be applied for other boards
which are compiled for multiple CPU types.

At least the Boundary Nitrogen boards, but probably others
like Wand have ordering options for DL or Solo processors
and may need the reduced clock rate.



#define CONFIG_IMX_HDMI
#define CONFIG_IMX_VIDEO_SKIP



Please advise,


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



CONFIG_IPUV3_CLK is used to indicate the default rate for IPU HSP clock.
The IPU driver in u-boot won't calculate the HSP clock rate according to
CCM registers, it needs this setting to know current rate. 198Mhz is the
correct value on DL not the 264Mhz.

If you select IPU DI clock (pixel clock) derived from HSP clock not the
external clock like LDB DI clock, I believe the 264Mhz will cause problem.



Do you know what sort of problem was seen (if any)?

Please advise,


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

Re: [U-Boot] video: ipu_common: fix build error

[Eric Nelson]

Thanks Peng.

On 09/05/2017 06:16 PM, Peng Fan wrote:

On Mon, Sep 04, 2017 at 07:48:56PM -0700, Eric Nelson wrote:

Hi Peng,

Can you tell that I'm hunting a bug in an old version?

I'm seeing a **very** intermittent regression between U-Boot
versions 2015.07 and 2016.05 and happened to spot something
in this patch.

On 04/27/2016 07:07 PM, Peng Fan wrote:

Some toolchains fail to build
"clk->rate = (u64)(clk->parent->rate * 16) / div;"
And the cast usage is wrong.

Use the following code to fix the issue,
"
   do_div(parent_rate, div);
   clk->rate = parent_rate;
"

Reported-by: Peter Robinson <pbrobin...@gmail.com>
Signed-off-by: Peng Fan <van.free...@gmail.com>
Cc: Stefano Babic <sba...@denx.de>
Cc: Fabio Estevam <fabio.este...@nxp.com>
Cc: Tom Rini <tr...@konsulko.com>
Cc: Anatolij Gustschin <ag...@denx.de>
Cc: Peter Robinson <pbrobin...@gmail.com>
Reviewed-by: Tom Rini <tr...@konsulko.com>
Tested-by: Peter Robinson <pbrobin...@gmail.com>
---

Hi Peter,

  Please help test this patch to see whether this fix your issue or not.
  Thanks for pointing out this issue.

Thanks,
Peng.

  drivers/video/ipu_common.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/video/ipu_common.c b/drivers/video/ipu_common.c
index 36d4b23..5676a0f 100644
--- a/drivers/video/ipu_common.c
+++ b/drivers/video/ipu_common.c
@@ -352,7 +352,9 @@ static int ipu_pixel_clk_set_rate(struct clk *clk, unsigned 
long rate)
 */
__raw_writel((div / 16) << 16, DI_BS_CLKGEN1(clk->id));


Did we lose a multiply by 16 in this change?


We already have "parent_rate = (unsigned long long)clk->parent->rate * 16;"
in this function.



Hmmm. So this patch also fixed a bug, since we previously had
**two** multiply-by-16's:

http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/video/ipu_common.c;hb=3cb4f25cc702db17455583599d0940c81337a17a

Regards,


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

Re: [U-Boot] video: ipu_common: fix build error

[Eric Nelson]

Hi Fabio,

On 09/05/2017 06:33 AM, Fabio Estevam wrote:

Hi Eric,

On Mon, Sep 4, 2017 at 11:49 PM, Eric Nelson <e...@nelint.com> wrote:

Hi Peng,

Can you tell that I'm hunting a bug in an old version?

I'm seeing a **very** intermittent regression between U-Boot
versions 2015.07 and 2016.05 and happened to spot something
in this patch.


Just curious: how does the regression manifest itself?



With **some** televisions at a client site, on **some** power-on
cycles, the HDMI output under Linux doesn't seem to be generated
properly.

We haven't been able to reproduce it in-house, so testing is
taking a while, and we haven't (yet) determined if the
divisor patch has anything to do with the problem.

We are running on an i.MX6DL, but the IPU clock frequency
change doesn't fix the issue (running at 19.8MHz instead of
26MHz).

All we know at the moment is that version 2015.07 works and
2016.05 fails with essentially no changes to the board files.

We're doing this remotely across time zones with limited access
to failing machine(s), so it may take the rest of the week
before we know for sure.

I'll update the thread when we nail it down.

Regards,


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

Re: [U-Boot] [PATCH v1 1/2] imx: add macro to detect whether USB has been initialized

[Eric Nelson]

Hi Stefano,

On 09/05/2017 04:16 AM, Stefano Babic wrote:

Hi Stefan,
On 05/09/2017 03:21, Stefan Agner wrote:

From: Stefan Agner <stefan.ag...@toradex.com>

This macro allows to detect whether the boot ROM initialized USB
already (serial downloader). This is helpful to reliably detect
if the system has been recovered via USB serial downloader.

Signed-off-by: Stefan Agner <stefan.ag...@toradex.com>
Acked-by: Marcel Ziswiler <marcel.ziswi...@toradex.com>
---
Hi Stefano,

I noted already in my initial post that detection of serial
downloader mode is somewhat brittle:
https://lists.denx.de/pipermail/u-boot/2017-August/301952.html

This came up quite fast now also for other boards:
https://www.mail-archive.com/u-boot@lists.denx.de/msg262234.html

We use this patches since quite some time. Also NXP uses this
detection method to start their mfgr tools...


Then it seems to be an "undocumented feature" rather a hack.



This patch only detects that the OTG PHY is active, so it's
not really a hack.

The next patch uses this to infer how it happened (booted using
SDP), and since I don't think there's another way for that to
happen, it also seems to be reasonable.

Can you think of another way that the OTG PHY could be alive
when the code is hit in SPL?

... A comment to that effect is probably in order though.

Please advise,


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

Re: [U-Boot] [PATCH v1 1/2] imx: add macro to detect whether USB has been initialized

[Eric Nelson]

Hi Stefan,

On 09/04/2017 09:50 PM, Stefan Agner wrote:

On 2017-09-04 19:57, Eric Nelson wrote:

On 09/04/2017 06:21 PM, Stefan Agner wrote:





+
+/*
+ * If ROM fell back to USB recover mode, USBPH0_PWD will be clear to use USB
+ * If boot from the other mode, USB0_PWD will keep reset value
+ */
+#defineis_boot_from_usb(void) (!(readl(USB_PHY0_BASE_ADDR) & (1<<20)))
+
   #endif /* __ASSEMBLER__*/
   #endif /* __ASM_ARCH_MX6_IMX_REGS_H__ */


If I'm reading your comment correctly, the RXPWDRX bit will be set (the
PHY will be powered down) unless it was enabled by the Boot ROM.

Won't this also be clear if you've run 'usb start' under U-Boot?


Yes, this only works before a USB initialization...



Based on this, I'd recommend changing the macro name to something
like "is_udc_active" to reflect it's true meaning.


This should be fine for the use case I have in mind (see patch 2).

Note this idea is borrowed from NXP downstream and seems to work here:
http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/tree/arch/arm/include/asm/arch-mx7/imx-regs.h?h=imx_v2016.03_4.1.15_2.0.0_ga#n1204



Understood.

Using this detection mechanism in SPL (where there isn't another path
for initializing the UDC) makes sense.

Regards,


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

Re: [U-Boot] [U-Boot,2/3] imx: mx6: correct IPU clock

[Eric Nelson]

Hi Stefano,

On 09/05/2017 06:30 AM, Stefano Babic wrote:

On 05/09/2017 14:56, Fabio Estevam wrote:

Hi Eric,

On Mon, Sep 4, 2017 at 11:37 PM, Eric Nelson <ericnelso...@gmail.com> wrote:


--- a/include/configs/mx6sabre_common.h
+++ b/include/configs/mx6sabre_common.h
@@ -225,7 +225,11 @@
   #define CONFIG_BMP_16BPP
   #define CONFIG_VIDEO_LOGO
   #define CONFIG_VIDEO_BMP_LOGO
-#define CONFIG_IPUV3_CLK 26000
+#ifdef CONFIG_MX6DL
+#define CONFIG_IPUV3_CLK 19800
+#else
+#define CONFIG_IPUV3_CLK 26400
+#endif




Note that this should probably be applied for other boards
which are compiled for multiple CPU types.

At least the Boundary Nitrogen boards, but probably others
like Wand have ordering options for DL or Solo processors
and may need the reduced clock rate.


Agreed. The clock frequency decision should be done in run-time rather
than in build-time.


I agree, too. We have mechanism to take decisions at run time, at least
based on SOC type. Anyway, Anatolji has already merged this - should be
better to revert it ?



I don't think it should be reverted until we have a run-time decision
in place, or we'll re-introduce whatever problem the higher rate
caused, at least on SABRE boards with Solo or Dual-Lite processors.

I'm still wondering whether Peng has a description of the ramifications
of the higher rate on DL/Solo processors.

Regards,


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

Re: [U-Boot] video: ipu_common: fix build error

[Eric Nelson]

Hi Peng,

Can you tell that I'm hunting a bug in an old version?

I'm seeing a **very** intermittent regression between U-Boot
versions 2015.07 and 2016.05 and happened to spot something
in this patch.

On 04/27/2016 07:07 PM, Peng Fan wrote:

Some toolchains fail to build
"clk->rate = (u64)(clk->parent->rate * 16) / div;"
And the cast usage is wrong.

Use the following code to fix the issue,
"
   do_div(parent_rate, div);
   clk->rate = parent_rate;
"

Reported-by: Peter Robinson <pbrobin...@gmail.com>
Signed-off-by: Peng Fan <van.free...@gmail.com>
Cc: Stefano Babic <sba...@denx.de>
Cc: Fabio Estevam <fabio.este...@nxp.com>
Cc: Tom Rini <tr...@konsulko.com>
Cc: Anatolij Gustschin <ag...@denx.de>
Cc: Peter Robinson <pbrobin...@gmail.com>
Reviewed-by: Tom Rini <tr...@konsulko.com>
Tested-by: Peter Robinson <pbrobin...@gmail.com>
---

Hi Peter,

  Please help test this patch to see whether this fix your issue or not.
  Thanks for pointing out this issue.

Thanks,
Peng.

  drivers/video/ipu_common.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/video/ipu_common.c b/drivers/video/ipu_common.c
index 36d4b23..5676a0f 100644
--- a/drivers/video/ipu_common.c
+++ b/drivers/video/ipu_common.c
@@ -352,7 +352,9 @@ static int ipu_pixel_clk_set_rate(struct clk *clk, unsigned 
long rate)
 */
__raw_writel((div / 16) << 16, DI_BS_CLKGEN1(clk->id));
  


Did we lose a multiply by 16 in this change?


-   clk->rate = (u64)(clk->parent->rate * 16) / div;
+   do_div(parent_rate, div);
+
+   clk->rate = parent_rate;
  
  	return 0;

  }



Please advise,


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

Re: [U-Boot] [U-Boot,2/3] imx: mx6: correct IPU clock

[Eric Nelson]

Hi Peng,

Pardon the reference to an old update, but do you have a description
of the symptoms that brought about this patch?

On 03/09/2016 01:07 AM, Peng Fan wrote:

The CONFIG_IPUV3_CLK should be 26400, to i.MX6DL, it should be
19800.

Signed-off-by: Peng Fan <van.free...@gmail.com>
Signed-off-by: Sandor Yu <sandor...@nxp.com>
Cc: Stefano Babic <sba...@denx.de>
Cc: Fabio Estevam <fabio.este...@nxp.com>
Cc: Peter Robinson <pbrobin...@gmail.com>
---
  include/configs/mx6sabre_common.h | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/include/configs/mx6sabre_common.h 
b/include/configs/mx6sabre_common.h
index 29d1f91..a6d821b 100644
--- a/include/configs/mx6sabre_common.h
+++ b/include/configs/mx6sabre_common.h
@@ -225,7 +225,11 @@
  #define CONFIG_BMP_16BPP
  #define CONFIG_VIDEO_LOGO
  #define CONFIG_VIDEO_BMP_LOGO
-#define CONFIG_IPUV3_CLK 26000
+#ifdef CONFIG_MX6DL
+#define CONFIG_IPUV3_CLK 19800
+#else
+#define CONFIG_IPUV3_CLK 26400
+#endif



Note that this should probably be applied for other boards
which are compiled for multiple CPU types.

At least the Boundary Nitrogen boards, but probably others
like Wand have ordering options for DL or Solo processors
and may need the reduced clock rate.



  #define CONFIG_IMX_HDMI
  #define CONFIG_IMX_VIDEO_SKIP
  


Please advise,


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

Re: [U-Boot] [PATCH v1 1/2] imx: add macro to detect whether USB has been initialized

[Eric Nelson]

Hi Stefan,

On 09/04/2017 06:21 PM, Stefan Agner wrote:

From: Stefan Agner <stefan.ag...@toradex.com>

This macro allows to detect whether the boot ROM initialized USB
already (serial downloader). This is helpful to reliably detect
if the system has been recovered via USB serial downloader.

Signed-off-by: Stefan Agner <stefan.ag...@toradex.com>
Acked-by: Marcel Ziswiler <marcel.ziswi...@toradex.com>
---
Hi Stefano,

I noted already in my initial post that detection of serial
downloader mode is somewhat brittle:
https://lists.denx.de/pipermail/u-boot/2017-August/301952.html

This came up quite fast now also for other boards:
https://www.mail-archive.com/u-boot@lists.denx.de/msg262234.html

We use this patches since quite some time. Also NXP uses this
detection method to start their mfgr tools... Altough a hack,
maybe we should still add it upstream?

--
Stefan


  arch/arm/include/asm/arch-mx6/imx-regs.h | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/arch/arm/include/asm/arch-mx6/imx-regs.h 
b/arch/arm/include/asm/arch-mx6/imx-regs.h
index 86e267087a..895ef4de83 100644
--- a/arch/arm/include/asm/arch-mx6/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx6/imx-regs.h
@@ -985,5 +985,12 @@ struct pwm_regs {
u32 pr;
u32 cnr;
  };


It seems as if you've already named a constant, so you might as well
#define and use it (USBPH0_PWD or USB0_PWD).

The reference manual seems to call it RXPWDRX though.


+
+/*
+ * If ROM fell back to USB recover mode, USBPH0_PWD will be clear to use USB
+ * If boot from the other mode, USB0_PWD will keep reset value
+ */
+#defineis_boot_from_usb(void) (!(readl(USB_PHY0_BASE_ADDR) & (1<<20)))
+
  #endif /* __ASSEMBLER__*/
  #endif /* __ASM_ARCH_MX6_IMX_REGS_H__ */


If I'm reading your comment correctly, the RXPWDRX bit will be set (the
PHY will be powered down) unless it was enabled by the Boot ROM.

Won't this also be clear if you've run 'usb start' under U-Boot?

Please advise,


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

Re: [U-Boot] video: ipu_common: fix build error

[Eric Nelson]

Hi Peng,

Can you tell that I'm hunting a bug in an old version?

I'm seeing a **very** intermittent regression between U-Boot
versions 2015.07 and 2016.05 and happened to spot something
in this patch.

On 04/27/2016 07:07 PM, Peng Fan wrote:

Some toolchains fail to build
"clk->rate = (u64)(clk->parent->rate * 16) / div;"
And the cast usage is wrong.

Use the following code to fix the issue,
"
   do_div(parent_rate, div);
   clk->rate = parent_rate;
"

Reported-by: Peter Robinson <pbrobin...@gmail.com>
Signed-off-by: Peng Fan <van.free...@gmail.com>
Cc: Stefano Babic <sba...@denx.de>
Cc: Fabio Estevam <fabio.este...@nxp.com>
Cc: Tom Rini <tr...@konsulko.com>
Cc: Anatolij Gustschin <ag...@denx.de>
Cc: Peter Robinson <pbrobin...@gmail.com>
Reviewed-by: Tom Rini <tr...@konsulko.com>
Tested-by: Peter Robinson <pbrobin...@gmail.com>
---

Hi Peter,

  Please help test this patch to see whether this fix your issue or not.
  Thanks for pointing out this issue.

Thanks,
Peng.

  drivers/video/ipu_common.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/video/ipu_common.c b/drivers/video/ipu_common.c
index 36d4b23..5676a0f 100644
--- a/drivers/video/ipu_common.c
+++ b/drivers/video/ipu_common.c
@@ -352,7 +352,9 @@ static int ipu_pixel_clk_set_rate(struct clk *clk, unsigned 
long rate)
 */
__raw_writel((div / 16) << 16, DI_BS_CLKGEN1(clk->id));
  


Did you intend to lose a multiply by 16 here?


-   clk->rate = (u64)(clk->parent->rate * 16) / div;
+   do_div(parent_rate, div);
+
+   clk->rate = parent_rate;
  
  	return 0;

  }



Please advise,


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

Re: [U-Boot] [U-Boot,2/3] imx: mx6: correct IPU clock

[Eric Nelson]

Hi all,

Adding my normal e-mail account to the chain, since the other account
isn't registered on the list.

On 09/04/2017 07:37 PM, Eric Nelson wrote:

Hi Peng,

Pardon the reference to an old update, but do you have a description
of the symptoms that brought about this patch?

On 03/09/2016 01:07 AM, Peng Fan wrote:

The CONFIG_IPUV3_CLK should be 26400, to i.MX6DL, it should be
19800.

Signed-off-by: Peng Fan <van.free...@gmail.com>
Signed-off-by: Sandor Yu <sandor...@nxp.com>
Cc: Stefano Babic <sba...@denx.de>
Cc: Fabio Estevam <fabio.este...@nxp.com>
Cc: Peter Robinson <pbrobin...@gmail.com>
---
  include/configs/mx6sabre_common.h | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/include/configs/mx6sabre_common.h 
b/include/configs/mx6sabre_common.h

index 29d1f91..a6d821b 100644
--- a/include/configs/mx6sabre_common.h
+++ b/include/configs/mx6sabre_common.h
@@ -225,7 +225,11 @@
  #define CONFIG_BMP_16BPP
  #define CONFIG_VIDEO_LOGO
  #define CONFIG_VIDEO_BMP_LOGO
-#define CONFIG_IPUV3_CLK 26000
+#ifdef CONFIG_MX6DL
+#define CONFIG_IPUV3_CLK 19800
+#else
+#define CONFIG_IPUV3_CLK 26400
+#endif



Note that this should probably be applied for other boards
which are compiled for multiple CPU types.

At least the Boundary Nitrogen boards, but probably others
like Wand have ordering options for DL or Solo processors
and may need the reduced clock rate.



  #define CONFIG_IMX_HDMI
  #define CONFIG_IMX_VIDEO_SKIP


Please advise,


Eric


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

Re: [U-Boot] [PATCH V2] imx: mx7: Add support for USB and normal boot modes

[Eric Nelson]

On 08/31/2017 04:11 PM, Fabio Estevam wrote:

Troy,

On Thu, Aug 31, 2017 at 7:53 PM, Troy Kisky
 wrote:

On 8/31/2017 2:28 PM, Troy Kisky wrote:



Maybe if you change the WDOG pinmux it might work ?




Worked for me

=> mm.l 302c
302c: 0003 ? 0
302c0004: 0001 ? q
=> bmod usb
resetting ...



Ok, but did you manage to successfully transfer u-boot via imx_usb_loader?

It did not work for me.



Ditto here. The OTG port didn't re-enumerate.


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

Re: [U-Boot] [PATCH V2] imx: mx7: Add support for USB and normal boot modes

[Eric Nelson]

On 08/31/2017 03:53 PM, Troy Kisky wrote:

On 8/31/2017 2:28 PM, Troy Kisky wrote:



Maybe if you change the WDOG pinmux it might work ?




Worked for me

=> mm.l 302c
302c: 0003 ? 0
302c0004: 0001 ? q
=> bmod usb
resetting ...



Hmm...

On SABRE-SD or Nitrogen7?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH V2] imx: mx7: Add support for USB and normal boot modes

[Eric Nelson]

Thanks Troy (and Peng),

On 08/31/2017 02:28 PM, Troy Kisky wrote:

On 8/31/2017 6:56 AM, Fabio Estevam wrote:

On Thu, Aug 31, 2017 at 10:35 AM, Fabio Estevam <feste...@gmail.com> wrote:

On Wed, Aug 30, 2017 at 7:13 PM, Eric Nelson <e...@nelint.com> wrote:

This adds support for two additional boot modes on the i.MX7D SoC, which
is most useful when doing U-Boot development on this chip.

1. "bmode usb" can be used to force the ROM boot loader's serial
2. "bmode normal" can be used to revert to the normal boot mode
as specified by fuses and BOOT_MODE pins

Signed-off-by: Eric Nelson <e...@nelint.com>


I tried testing your patch on a imx7d sabresd, but it seems there is
an issue with bmode that is unrelated to your patch.

I also did:

diff --git a/configs/mx7dsabresd_defconfig b/configs/mx7dsabresd_defconfig
index 8f2e33a..c70fde8 100644
--- a/configs/mx7dsabresd_defconfig
+++ b/configs/mx7dsabresd_defconfig
@@ -5,7 +5,6 @@ CONFIG_VIDEO=y
  # CONFIG_ARMV7_VIRT is not set
  CONFIG_IMX_RDC=y
  CONFIG_IMX_BOOTAUX=y
-# CONFIG_CMD_BMODE is not set
  CONFIG_DEFAULT_DEVICE_TREE="imx7d-sdb"
  CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/freescale/mx7dsabresd/imximage.cfg"
  CONFIG_BOOTDELAY=3

so that bmode command can be added.

However I am getting:

=> bmode usb
bmode - 


I missed to add 'add_board_boot_modes(board_boot_modes);'

Now I get:

=> bmode usb
resetting ...


U-Boot 2017.09-rc2-36996-g63af4b0-dirty (Aug 31 2017 - 10:53:12 -0300)

CPU:   Freescale i.MX7D rev1.2 1000 MHz (running at 792 MHz)
CPU:   Commercial temperature grade (0C to 95C) at 41C


Note the POR here (I would expect it to be WDOG).


Reset cause: POR
Model: Freescale i.MX7 SabreSD Board
Board: i.MX7D SABRESD in non-secure mode
DRAM:  1 GiB






I got this response from Peng when I asked him back in March of last year.


For now, bmode does not work. Since bmode use warm reset, but we now use
wdog to directly reset pmic. So bmode will not work.

Please check your code to see whether your board connect WDOG_B to pmic reset 
pin and have wdog

pinmux settings.


Thanks,
Peng.


Maybe if you change the WDOG pinmux it might work ?



The mx7dsabresd has GPIO1_IO00 configured for WDOG, and overriding it
does get rid of the POR.

Unfortunately, it also doesn't allow "bmode usb" to function.

=> mm 302c
302c: 0003 ? 0
302c0004:  ? x
=> bmode usb
resetting ...

(crickets here)

Based on this:

Rejected-by: Eric Nelson <e...@nelint.com>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2] imx: imx7d: remove CamelCase from ENET_xMHz macros

[Eric Nelson]

Update these macros to use all upper-case to avoid checkpatch
warnings:

ENET_25MHz,
ENET_50MHz,
ENET_125MHz,

Signed-off-by: Eric Nelson <e...@nelint.com>
---
V2 fixes a couple of references in mx7/clock.c
 arch/arm/include/asm/arch-mx7/clock.h | 6 +++---
 arch/arm/mach-imx/mx7/clock.c | 6 +++---
 board/freescale/mx7dsabresd/mx7dsabresd.c | 2 +-
 board/technexion/pico-imx7d/pico-imx7d.c  | 2 +-
 board/toradex/colibri_imx7/colibri_imx7.c | 2 +-
 5 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/arm/include/asm/arch-mx7/clock.h 
b/arch/arm/include/asm/arch-mx7/clock.h
index 688d236..3b115ad 100644
--- a/arch/arm/include/asm/arch-mx7/clock.h
+++ b/arch/arm/include/asm/arch-mx7/clock.h
@@ -318,9 +318,9 @@ struct clk_root_map {
 };
 
 enum enet_freq {
-   ENET_25MHz,
-   ENET_50MHz,
-   ENET_125MHz,
+   ENET_25MHZ,
+   ENET_50MHZ,
+   ENET_125MHZ,
 };
 
 u32 get_root_clk(enum clk_root_index clock_id);
diff --git a/arch/arm/mach-imx/mx7/clock.c b/arch/arm/mach-imx/mx7/clock.c
index 2cfde46..8150faa 100644
--- a/arch/arm/mach-imx/mx7/clock.c
+++ b/arch/arm/mach-imx/mx7/clock.c
@@ -966,15 +966,15 @@ int set_clk_enet(enum enet_freq type)
clock_enable(CCGR_ENET2, 0);
 
switch (type) {
-   case ENET_125MHz:
+   case ENET_125MHZ:
enet1_ref = ENET1_REF_CLK_ROOT_FROM_PLL_ENET_MAIN_125M_CLK;
enet2_ref = ENET2_REF_CLK_ROOT_FROM_PLL_ENET_MAIN_125M_CLK;
break;
-   case ENET_50MHz:
+   case ENET_50MHZ:
enet1_ref = ENET1_REF_CLK_ROOT_FROM_PLL_ENET_MAIN_50M_CLK;
enet2_ref = ENET2_REF_CLK_ROOT_FROM_PLL_ENET_MAIN_50M_CLK;
break;
-   case ENET_25MHz:
+   case ENET_25MHZ:
enet1_ref = ENET1_REF_CLK_ROOT_FROM_PLL_ENET_MAIN_25M_CLK;
enet2_ref = ENET2_REF_CLK_ROOT_FROM_PLL_ENET_MAIN_25M_CLK;
break;
diff --git a/board/freescale/mx7dsabresd/mx7dsabresd.c 
b/board/freescale/mx7dsabresd/mx7dsabresd.c
index a681ece..5819b18 100644
--- a/board/freescale/mx7dsabresd/mx7dsabresd.c
+++ b/board/freescale/mx7dsabresd/mx7dsabresd.c
@@ -260,7 +260,7 @@ static int setup_fec(void)
(IOMUXC_GPR_GPR1_GPR_ENET1_TX_CLK_SEL_MASK |
 IOMUXC_GPR_GPR1_GPR_ENET1_CLK_DIR_MASK), 0);
 
-   return set_clk_enet(ENET_125MHz);
+   return set_clk_enet(ENET_125MHZ);
 }
 
 
diff --git a/board/technexion/pico-imx7d/pico-imx7d.c 
b/board/technexion/pico-imx7d/pico-imx7d.c
index b4c9be7..67bab51 100644
--- a/board/technexion/pico-imx7d/pico-imx7d.c
+++ b/board/technexion/pico-imx7d/pico-imx7d.c
@@ -182,7 +182,7 @@ static int setup_fec(void)
(IOMUXC_GPR_GPR1_GPR_ENET1_TX_CLK_SEL_MASK |
IOMUXC_GPR_GPR1_GPR_ENET1_CLK_DIR_MASK), 0);
 
-   return set_clk_enet(ENET_125MHz);
+   return set_clk_enet(ENET_125MHZ);
 }
 
 int board_phy_config(struct phy_device *phydev)
diff --git a/board/toradex/colibri_imx7/colibri_imx7.c 
b/board/toradex/colibri_imx7/colibri_imx7.c
index 5cb14b4..13b2b57 100644
--- a/board/toradex/colibri_imx7/colibri_imx7.c
+++ b/board/toradex/colibri_imx7/colibri_imx7.c
@@ -280,7 +280,7 @@ static int setup_fec(void)
IOMUXC_GPR_GPR1_GPR_ENET1_TX_CLK_SEL_MASK);
 #endif
 
-   return set_clk_enet(ENET_50MHz);
+   return set_clk_enet(ENET_50MHZ);
 }
 
 int board_phy_config(struct phy_device *phydev)
-- 
2.7.4

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

Re: [U-Boot] [PATCH V2] imx: mx7: Add support for USB and normal boot modes

[Eric Nelson]

Hi Fabio,

On 08/31/2017 06:56 AM, Fabio Estevam wrote:

On Thu, Aug 31, 2017 at 10:35 AM, Fabio Estevam <feste...@gmail.com> wrote:

Hi Eric,

On Wed, Aug 30, 2017 at 7:13 PM, Eric Nelson <e...@nelint.com> wrote:

This adds support for two additional boot modes on the i.MX7D SoC, which
is most useful when doing U-Boot development on this chip.

1. "bmode usb" can be used to force the ROM boot loader's serial
2. "bmode normal" can be used to revert to the normal boot mode
as specified by fuses and BOOT_MODE pins

Signed-off-by: Eric Nelson <e...@nelint.com>


I tried testing your patch on a imx7d sabresd, but it seems there is
an issue with bmode that is unrelated to your patch.

I also did:

diff --git a/configs/mx7dsabresd_defconfig b/configs/mx7dsabresd_defconfig
index 8f2e33a..c70fde8 100644
--- a/configs/mx7dsabresd_defconfig
+++ b/configs/mx7dsabresd_defconfig
@@ -5,7 +5,6 @@ CONFIG_VIDEO=y
  # CONFIG_ARMV7_VIRT is not set
  CONFIG_IMX_RDC=y
  CONFIG_IMX_BOOTAUX=y
-# CONFIG_CMD_BMODE is not set
  CONFIG_DEFAULT_DEVICE_TREE="imx7d-sdb"
  CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/freescale/mx7dsabresd/imximage.cfg"
  CONFIG_BOOTDELAY=3

so that bmode command can be added.

However I am getting:

=> bmode usb
bmode - 


I missed to add 'add_board_boot_modes(board_boot_modes);'

Now I get:

=> bmode usb
resetting ...


U-Boot 2017.09-rc2-36996-g63af4b0-dirty (Aug 31 2017 - 10:53:12 -0300)

CPU:   Freescale i.MX7D rev1.2 1000 MHz (running at 792 MHz)
CPU:   Commercial temperature grade (0C to 95C) at 41C
Reset cause: POR
Model: Freescale i.MX7 SabreSD Board
Board: i.MX7D SABRESD in non-secure mode
DRAM:  1 GiB
PMIC: PFUZE3000 DEV_ID=0x30 REV_ID=0x11
MMC:
MMC Device 0 not found
*** Warning - No MMC card found, using default environment

Video: 480x272x24
In:serial
Out:   serial
Err:   serial
Net:   FEC0
Hit any key to stop autoboot:  0
=>

So the board is resetting instead of going into serial download mode.

Any ideas?



I'm not sure. Since I'm currently working with a board with no
fuses blown, I'm getting USB mode either way ;)...

I have an MX7 SABRE SD and I'll try it out there.

Regards,


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

[U-Boot] [PATCH] imx: imx7d: remove CamelCase from ENET_xMHz macros

[Eric Nelson]

Update these macros to use all upper-case to avoid checkpatch
warnings:

ENET_25MHz,
ENET_50MHz,
ENET_125MHz,

Signed-off-by: Eric Nelson <e...@nelint.com>
---
 arch/arm/include/asm/arch-mx7/clock.h | 6 +++---
 arch/arm/mach-imx/mx7/clock.c | 2 +-
 board/freescale/mx7dsabresd/mx7dsabresd.c | 2 +-
 board/technexion/pico-imx7d/pico-imx7d.c  | 2 +-
 board/toradex/colibri_imx7/colibri_imx7.c | 2 +-
 5 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm/include/asm/arch-mx7/clock.h 
b/arch/arm/include/asm/arch-mx7/clock.h
index 688d236..3b115ad 100644
--- a/arch/arm/include/asm/arch-mx7/clock.h
+++ b/arch/arm/include/asm/arch-mx7/clock.h
@@ -318,9 +318,9 @@ struct clk_root_map {
 };
 
 enum enet_freq {
-   ENET_25MHz,
-   ENET_50MHz,
-   ENET_125MHz,
+   ENET_25MHZ,
+   ENET_50MHZ,
+   ENET_125MHZ,
 };
 
 u32 get_root_clk(enum clk_root_index clock_id);
diff --git a/arch/arm/mach-imx/mx7/clock.c b/arch/arm/mach-imx/mx7/clock.c
index 2cfde46..423d697 100644
--- a/arch/arm/mach-imx/mx7/clock.c
+++ b/arch/arm/mach-imx/mx7/clock.c
@@ -970,7 +970,7 @@ int set_clk_enet(enum enet_freq type)
enet1_ref = ENET1_REF_CLK_ROOT_FROM_PLL_ENET_MAIN_125M_CLK;
enet2_ref = ENET2_REF_CLK_ROOT_FROM_PLL_ENET_MAIN_125M_CLK;
break;
-   case ENET_50MHz:
+   case ENET_50MHZ:
enet1_ref = ENET1_REF_CLK_ROOT_FROM_PLL_ENET_MAIN_50M_CLK;
enet2_ref = ENET2_REF_CLK_ROOT_FROM_PLL_ENET_MAIN_50M_CLK;
break;
diff --git a/board/freescale/mx7dsabresd/mx7dsabresd.c 
b/board/freescale/mx7dsabresd/mx7dsabresd.c
index a681ece..5819b18 100644
--- a/board/freescale/mx7dsabresd/mx7dsabresd.c
+++ b/board/freescale/mx7dsabresd/mx7dsabresd.c
@@ -260,7 +260,7 @@ static int setup_fec(void)
(IOMUXC_GPR_GPR1_GPR_ENET1_TX_CLK_SEL_MASK |
 IOMUXC_GPR_GPR1_GPR_ENET1_CLK_DIR_MASK), 0);
 
-   return set_clk_enet(ENET_125MHz);
+   return set_clk_enet(ENET_125MHZ);
 }
 
 
diff --git a/board/technexion/pico-imx7d/pico-imx7d.c 
b/board/technexion/pico-imx7d/pico-imx7d.c
index b4c9be7..67bab51 100644
--- a/board/technexion/pico-imx7d/pico-imx7d.c
+++ b/board/technexion/pico-imx7d/pico-imx7d.c
@@ -182,7 +182,7 @@ static int setup_fec(void)
(IOMUXC_GPR_GPR1_GPR_ENET1_TX_CLK_SEL_MASK |
IOMUXC_GPR_GPR1_GPR_ENET1_CLK_DIR_MASK), 0);
 
-   return set_clk_enet(ENET_125MHz);
+   return set_clk_enet(ENET_125MHZ);
 }
 
 int board_phy_config(struct phy_device *phydev)
diff --git a/board/toradex/colibri_imx7/colibri_imx7.c 
b/board/toradex/colibri_imx7/colibri_imx7.c
index 5cb14b4..13b2b57 100644
--- a/board/toradex/colibri_imx7/colibri_imx7.c
+++ b/board/toradex/colibri_imx7/colibri_imx7.c
@@ -280,7 +280,7 @@ static int setup_fec(void)
IOMUXC_GPR_GPR1_GPR_ENET1_TX_CLK_SEL_MASK);
 #endif
 
-   return set_clk_enet(ENET_50MHz);
+   return set_clk_enet(ENET_50MHZ);
 }
 
 int board_phy_config(struct phy_device *phydev)
-- 
2.7.4

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

Re: [U-Boot] [PATCH V2] imx: mx7: Add support for USB and normal boot modes

[Eric Nelson]

Sorry for the spam.

I resent this by mistake.

On 08/30/2017 03:13 PM, Eric Nelson wrote:

This adds support for two additional boot modes on the i.MX7D SoC, which
is most useful when doing U-Boot development on this chip.

1. "bmode usb" can be used to force the ROM boot loader's serial
2. "bmode normal" can be used to revert to the normal boot mode
as specified by fuses and BOOT_MODE pins

Signed-off-by: Eric Nelson <e...@nelint.com>
---
V2 adds "normal" mode as suggested by Troy Kisky
  arch/arm/mach-imx/mx7/soc.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-imx/mx7/soc.c b/arch/arm/mach-imx/mx7/soc.c
index 87bf105..15be42a 100644
--- a/arch/arm/mach-imx/mx7/soc.c
+++ b/arch/arm/mach-imx/mx7/soc.c
@@ -372,6 +372,9 @@ void set_wdog_reset(struct wdog_regs *wdog)
   * to SBMR1, which will determine the boot device.
   */
  const struct boot_mode soc_boot_modes[] = {
+   {"normal",MAKE_CFGVAL(0x00, 0x00, 0x00, 0x00)},
+   {"usb",   MAKE_CFGVAL(0x01, 0x00, 0x00, 0x00)},
+
{"ecspi1:0",  MAKE_CFGVAL(0x00, 0x60, 0x00, 0x00)},
{"ecspi1:1",  MAKE_CFGVAL(0x40, 0x62, 0x00, 0x00)},
{"ecspi1:2",  MAKE_CFGVAL(0x80, 0x64, 0x00, 0x00)},



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

[U-Boot] [PATCH V2] imx: mx7: Add support for USB and normal boot modes

[Eric Nelson]

This adds support for two additional boot modes on the i.MX7D SoC, which
is most useful when doing U-Boot development on this chip.

1. "bmode usb" can be used to force the ROM boot loader's serial
2. "bmode normal" can be used to revert to the normal boot mode
   as specified by fuses and BOOT_MODE pins

Signed-off-by: Eric Nelson <e...@nelint.com>
---
V2 adds "normal" mode as suggested by Troy Kisky
 arch/arm/mach-imx/mx7/soc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-imx/mx7/soc.c b/arch/arm/mach-imx/mx7/soc.c
index 87bf105..15be42a 100644
--- a/arch/arm/mach-imx/mx7/soc.c
+++ b/arch/arm/mach-imx/mx7/soc.c
@@ -372,6 +372,9 @@ void set_wdog_reset(struct wdog_regs *wdog)
  * to SBMR1, which will determine the boot device.
  */
 const struct boot_mode soc_boot_modes[] = {
+   {"normal",  MAKE_CFGVAL(0x00, 0x00, 0x00, 0x00)},
+   {"usb", MAKE_CFGVAL(0x01, 0x00, 0x00, 0x00)},
+
{"ecspi1:0",MAKE_CFGVAL(0x00, 0x60, 0x00, 0x00)},
{"ecspi1:1",MAKE_CFGVAL(0x40, 0x62, 0x00, 0x00)},
{"ecspi1:2",MAKE_CFGVAL(0x80, 0x64, 0x00, 0x00)},
-- 
2.7.4

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

[U-Boot] [PATCH V2] imx: mx7: Add support for USB and normal boot modes

[Eric Nelson]

This adds support for two additional boot modes on the i.MX7D SoC, which
is most useful when doing U-Boot development on this chip.

1. "bmode usb" can be used to force the ROM boot loader's serial
2. "bmode normal" can be used to revert to the normal boot mode
   as specified by fuses and BOOT_MODE pins

Signed-off-by: Eric Nelson <e...@nelint.com>
---
V2 adds "normal" mode as suggested by Troy Kisky
 arch/arm/mach-imx/mx7/soc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-imx/mx7/soc.c b/arch/arm/mach-imx/mx7/soc.c
index 87bf105..15be42a 100644
--- a/arch/arm/mach-imx/mx7/soc.c
+++ b/arch/arm/mach-imx/mx7/soc.c
@@ -372,6 +372,9 @@ void set_wdog_reset(struct wdog_regs *wdog)
  * to SBMR1, which will determine the boot device.
  */
 const struct boot_mode soc_boot_modes[] = {
+   {"normal",  MAKE_CFGVAL(0x00, 0x00, 0x00, 0x00)},
+   {"usb", MAKE_CFGVAL(0x01, 0x00, 0x00, 0x00)},
+
{"ecspi1:0",MAKE_CFGVAL(0x00, 0x60, 0x00, 0x00)},
{"ecspi1:1",MAKE_CFGVAL(0x40, 0x62, 0x00, 0x00)},
{"ecspi1:2",MAKE_CFGVAL(0x80, 0x64, 0x00, 0x00)},
-- 
2.7.4

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

Re: [U-Boot] [PATCH] imx: mx7: Add support for USB boot mode

[Eric Nelson]

Hi Troy,

On 08/29/2017 11:55 AM, Troy Kisky wrote:

On 8/29/2017 7:37 AM, Eric Nelson wrote:

Hi Troy,

On 08/28/2017 09:42 AM, Troy Kisky wrote:

On 8/27/2017 3:04 PM, Eric Nelson wrote:

This adds support for USB boot mode on the i.MX7D SoC, which
is most useful when doing U-Boot development on this chip.

i.e., it enables you to enter the ROM boot loader's serial
download protocol using the command:

=> bmode usb

Signed-off-by: Eric Nelson <e...@nelint.com>
---
   arch/arm/mach-imx/mx7/soc.c | 2 ++
   1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-imx/mx7/soc.c b/arch/arm/mach-imx/mx7/soc.c
index 87bf105..63ee59f 100644
--- a/arch/arm/mach-imx/mx7/soc.c
+++ b/arch/arm/mach-imx/mx7/soc.c
@@ -372,6 +372,8 @@ void set_wdog_reset(struct wdog_regs *wdog)
* to SBMR1, which will determine the boot device.
*/
   const struct boot_mode soc_boot_modes[] = {


You might want to add

+   {"normal",  MAKE_CFGVAL(0x00, 0x00, 0x00, 0x00)},


while you're at it, to undo with "bmode normal"



Normal, meaning "don't override"?

Why would you want to do this?

Please advise,


Hi Eric!


If you do "bmode usb" and then use "imx_usb" to load a new u-boot.
You may want to do "bmode normal", so that a watchdog reset from
the linux kernel or from u-boot will work as expected, instead of
starting the ROM USB downloader again.



Got it.

It keeps you from reaching for the power or reset button after
using "bmode usb" or somesuch.

I'll ship a V2 momentarily.

Regards,


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

Re: [U-Boot] [PATCH] imx: mx7: Add support for USB boot mode

[Eric Nelson]

Hi Troy,

On 08/28/2017 09:42 AM, Troy Kisky wrote:

On 8/27/2017 3:04 PM, Eric Nelson wrote:

This adds support for USB boot mode on the i.MX7D SoC, which
is most useful when doing U-Boot development on this chip.

i.e., it enables you to enter the ROM boot loader's serial
download protocol using the command:

=> bmode usb

Signed-off-by: Eric Nelson <e...@nelint.com>
---
  arch/arm/mach-imx/mx7/soc.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-imx/mx7/soc.c b/arch/arm/mach-imx/mx7/soc.c
index 87bf105..63ee59f 100644
--- a/arch/arm/mach-imx/mx7/soc.c
+++ b/arch/arm/mach-imx/mx7/soc.c
@@ -372,6 +372,8 @@ void set_wdog_reset(struct wdog_regs *wdog)
   * to SBMR1, which will determine the boot device.
   */
  const struct boot_mode soc_boot_modes[] = {


You might want to add

+   {"normal",  MAKE_CFGVAL(0x00, 0x00, 0x00, 0x00)},


while you're at it, to undo with "bmode normal"



Normal, meaning "don't override"?

Why would you want to do this?

Please advise,


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

[U-Boot] [PATCH] imx: mx7: Add support for USB boot mode

[Eric Nelson]

This adds support for USB boot mode on the i.MX7D SoC, which
is most useful when doing U-Boot development on this chip.

i.e., it enables you to enter the ROM boot loader's serial
download protocol using the command:

=> bmode usb

Signed-off-by: Eric Nelson <e...@nelint.com>
---
 arch/arm/mach-imx/mx7/soc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-imx/mx7/soc.c b/arch/arm/mach-imx/mx7/soc.c
index 87bf105..63ee59f 100644
--- a/arch/arm/mach-imx/mx7/soc.c
+++ b/arch/arm/mach-imx/mx7/soc.c
@@ -372,6 +372,8 @@ void set_wdog_reset(struct wdog_regs *wdog)
  * to SBMR1, which will determine the boot device.
  */
 const struct boot_mode soc_boot_modes[] = {
+   {"usb", MAKE_CFGVAL(0x01, 0x00, 0x00, 0x00)},
+
{"ecspi1:0",MAKE_CFGVAL(0x00, 0x60, 0x00, 0x00)},
{"ecspi1:1",MAKE_CFGVAL(0x40, 0x62, 0x00, 0x00)},
{"ecspi1:2",MAKE_CFGVAL(0x80, 0x64, 0x00, 0x00)},
-- 
2.7.4

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

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

[Eric Nelson]

Hi Stefan,

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

Hi Eric,

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

Hi Stefan,

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

From: Stefan Agner <stefan.ag...@toradex.com>

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



Nice!


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



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

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



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

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


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



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

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



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



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



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


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



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


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


I'm not clear on how errors are handled.


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



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

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

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


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

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

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

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


imx_usb?



Yeah right, sorry.


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

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



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



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

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

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

With USB Gadge

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

[Eric Nelson]

Hi Stefan,

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

From: Stefan Agner <stefan.ag...@toradex.com>

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



Nice!


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



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

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


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

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

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

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


imx_usb?


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

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



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

I believe some i.MX users have struggled to stay within the
size of internal RAM.

Regards,


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

Re: [U-Boot] [RFC PATCH 1/9] mx6: Add board mx6memcal for use in validating DDR

[Eric Nelson]

Hi Fabio,

On Fri, Jul 14, 2017 at 12:01 PM, Fabio Estevam <feste...@gmail.com> wrote:

> Hi Eric,
>
> On Fri, Jul 14, 2017 at 2:58 PM, Eric Nelson <e...@nelint.com> wrote:
>
> > I set this aside because I wasn't able to get the "return to
> > RBL" code working and figured I'd try to reverse-engineer the API.
> >
> > Any hints you have in that area would be helpful, and will solve
> > that other long-standing issue of how to live with SPL on i.MX.
>
> Sorry, but what does "return to RBL" mean?
>
>
I was trying to get the SPL to act as a plugin in this patch set, so we
could send
a full U-Boot with a memory test as a payload, but got stuck on the details.

https://lists.denx.de/pipermail/u-boot/2016-June/258784.html

Looking back at the patch set, the plugin support wasn't explicitly
included.

I sent some notes in November:

https://lists.denx.de/pipermail/u-boot/2016-November/271647.html

And there was some follow-up in January:

https://lists.denx.de/pipermail/u-boot/2017-January/278518.html
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC PATCH 1/9] mx6: Add board mx6memcal for use in validating DDR

[Eric Nelson]

Hi Fabio,

On 07/14/2017 07:18 AM, Fabio Estevam wrote:

Hi Eric,

On Tue, Nov 1, 2016 at 5:13 PM, Eric Nelson <e...@nelint.com> wrote:

This is a virtual "board" that uses configuration files and
Kconfig to define the memory layout used by a real board during
the board bring-up process.

It generates an SPL image that can be loaded using imx_usb or
SB_LOADER.exe.

When run, it will generate a set of calibration constants for
use in either or both a DCD configuration file for boards that
use u-boot.imx or struct mx6_mmdc_calibration for boards that
boot via SPL.

In essence, it is a configurable, open-source variant of the
Freescale ddr-stress tool.

 https://community.nxp.com/docs/DOC-105652

File mx6memcal_defconfig configures the board for use with
mx6sabresd or mx6qsabreauto.


Do you still have plans on refreshing this series?



Plans is a strong word, but I certainly hope to find some time
to continue this effort.

I haven't been doing too many new board bring-ups lately though,
so it moved away from my front burner.

I set this aside because I wasn't able to get the "return to
RBL" code working and figured I'd try to reverse-engineer the API.

Any hints you have in that area would be helpful, and will solve
that other long-standing issue of how to live with SPL on i.MX.


It does seem very useful.



It is, and even the RFC patch allows very quick testing of
large numbers of boards to gather calibration data.

Regards,


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

[U-Boot] [PATCH v3 2/3] rockchip: video: Makefile: Add soc specific driver for rk3288 mipi dsi

[Eric Gao]

Signed-off-by: Eric Gao <eric@rock-chips.com>
---

Changes in v2: None
Changes in v1: None

 drivers/video/rockchip/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/video/rockchip/Makefile b/drivers/video/rockchip/Makefile
index 600743c..8005003 100644
--- a/drivers/video/rockchip/Makefile
+++ b/drivers/video/rockchip/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_DISPLAY_ROCKCHIP_LVDS) += rk_lvds.o
 obj-hdmi-$(CONFIG_ROCKCHIP_RK3288) += rk3288_hdmi.o
 obj-hdmi-$(CONFIG_ROCKCHIP_RK3399) += rk3399_hdmi.o
 obj-$(CONFIG_DISPLAY_ROCKCHIP_HDMI) += rk_hdmi.o $(obj-hdmi-y)
+obj-mipi-$(CONFIG_ROCKCHIP_RK3288) += rk3288_mipi.o
 obj-mipi-$(CONFIG_ROCKCHIP_RK3399) += rk3399_mipi.o
 obj-$(CONFIG_DISPLAY_ROCKCHIP_MIPI) += rk_mipi.o $(obj-mipi-y)
 endif
-- 
1.9.1


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

[U-Boot] [PATCH v3 3/3] rockchip: video: defconfig: Add mipi dsi support for evb-rk3288

[Eric Gao]

Add support for rk3288 mipi dsi.

Signed-off-by: Eric Gao <eric@rock-chips.com>
Reviewed-by: Simon Glass <s...@chromium.org>

---

Changes in v2: None
Changes in v1:
-Make the subject more intelligible.

 configs/evb-rk3288_defconfig | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/configs/evb-rk3288_defconfig b/configs/evb-rk3288_defconfig
index 227150d..fb5599d 100644
--- a/configs/evb-rk3288_defconfig
+++ b/configs/evb-rk3288_defconfig
@@ -6,8 +6,8 @@ CONFIG_ROCKCHIP_SPL_BACK_TO_BROM=y
 CONFIG_TARGET_EVB_RK3288=y
 CONFIG_SPL_STACK_R_ADDR=0x8
 CONFIG_DEFAULT_DEVICE_TREE="rk3288-evb"
+CONFIG_DEBUG_UART=y
 CONFIG_SILENT_CONSOLE=y
-CONFIG_CONSOLE_MUX=y
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x2000
@@ -55,12 +55,16 @@ CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_PWM_ROCKCHIP=y
 CONFIG_RAM=y
 CONFIG_SPL_RAM=y
-CONFIG_DEBUG_UART=y
 CONFIG_DEBUG_UART_BASE=0xff69
 CONFIG_DEBUG_UART_CLOCK=2400
 CONFIG_DEBUG_UART_SHIFT=2
 CONFIG_SYS_NS16550=y
 CONFIG_SYSRESET=y
+CONFIG_DM_VIDEO=y
+CONFIG_DISPLAY=y
+CONFIG_VIDEO_ROCKCHIP=y
+CONFIG_VIDEO_ROCKCHIP_MAX_YRES=1200
+CONFIG_DISPLAY_ROCKCHIP_MIPI=y
 CONFIG_USE_TINY_PRINTF=y
 CONFIG_CMD_DHRYSTONE=y
 CONFIG_ERRNO_STR=y
-- 
1.9.1


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

[U-Boot] [PATCH v3 0/3] Add mipi dsi support for evb-rk3288.

[Eric Gao]

Changes in v2:
-Cancel the force convert for dev_read_addr return value type.
-Change regs type from "void __iomem" to "uintptr_t" for the head file.

Changes in v1:
-Change function name from rk_display_enable to rk_mipi_enable.
-Use IS_ERR to judge the return status.
-Use dev_read_addr to replace devfdt_get_addr.
-Make the subject more intelligible.

Eric Gao (3):
  rockchip: video: mipi: Add rk3288 soc specific driver for mipi dsi
  rockchip: video: Makefile: Add soc specific driver for rk3288 mipi dsi
  rockchip: video: defconfig: Add mipi dsi support for evb-rk3288

 configs/evb-rk3288_defconfig |   8 +-
 drivers/video/rockchip/Makefile  |   1 +
 drivers/video/rockchip/rk3288_mipi.c | 191 +++
 drivers/video/rockchip/rk_mipi.h |   2 +-
 4 files changed, 199 insertions(+), 3 deletions(-)
 create mode 100644 drivers/video/rockchip/rk3288_mipi.c

-- 
1.9.1


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

[U-Boot] [PATCH v3 2/3] rockchip: video: mipi: Split mipi driver into common and specific parts

[Eric Gao]

To compatible with different rockchip soc, we split the mipi dirver into
common and soc specific parts, and all the soc share the common
functions from common driver part.

Signed-off-by: Eric Gao <eric@rock-chips.com>

---

Changes in v2:
-Use dev_read_addr to replace devfdt_get_addr.

Changes in v1:
-Delete the unused variable.

 drivers/video/rockchip/rk3399_mipi.c | 183 +++
 drivers/video/rockchip/rk_mipi.c | 170 ++--
 drivers/video/rockchip/rk_mipi.h |  32 ++
 3 files changed, 221 insertions(+), 164 deletions(-)
 create mode 100644 drivers/video/rockchip/rk3399_mipi.c
 create mode 100644 drivers/video/rockchip/rk_mipi.h

diff --git a/drivers/video/rockchip/rk3399_mipi.c 
b/drivers/video/rockchip/rk3399_mipi.c
new file mode 100644
index 000..c1690bd
--- /dev/null
+++ b/drivers/video/rockchip/rk3399_mipi.c
@@ -0,0 +1,183 @@
+/*
+ * Copyright (c) 2017, Fuzhou Rockchip Electronics Co., Ltd
+ * Author: Eric Gao <eric@rock-chips.com>
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "rk_mipi.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* Select mipi dsi source, big or little vop */
+static int rk_mipi_dsi_source_select(struct udevice *dev)
+{
+   struct rk_mipi_priv *priv = dev_get_priv(dev);
+   struct rk3399_grf_regs *grf = priv->grf;
+   struct display_plat *disp_uc_plat = dev_get_uclass_platdata(dev);
+
+   /* Select the video source */
+   switch (disp_uc_plat->source_id) {
+   case VOP_B:
+   rk_clrsetreg(>soc_con20, GRF_DSI0_VOP_SEL_MASK,
+GRF_DSI0_VOP_SEL_B << GRF_DSI0_VOP_SEL_SHIFT);
+   break;
+   case VOP_L:
+   rk_clrsetreg(>soc_con20, GRF_DSI0_VOP_SEL_MASK,
+GRF_DSI0_VOP_SEL_L << GRF_DSI0_VOP_SEL_SHIFT);
+   break;
+   default:
+   debug("%s: Invalid VOP id\n", __func__);
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+/* Setup mipi dphy working mode */
+static void rk_mipi_dphy_mode_set(struct udevice *dev)
+{
+   struct rk_mipi_priv *priv = dev_get_priv(dev);
+   struct rk3399_grf_regs *grf = priv->grf;
+   int val;
+
+   /* Set Controller as TX mode */
+   val = GRF_DPHY_TX0_RXMODE_DIS << GRF_DPHY_TX0_RXMODE_SHIFT;
+   rk_clrsetreg(>soc_con22, GRF_DPHY_TX0_RXMODE_MASK, val);
+
+   /* Exit tx stop mode */
+   val |= GRF_DPHY_TX0_TXSTOPMODE_DIS << GRF_DPHY_TX0_TXSTOPMODE_SHIFT;
+   rk_clrsetreg(>soc_con22, GRF_DPHY_TX0_TXSTOPMODE_MASK, val);
+
+   /* Disable turnequest */
+   val |= GRF_DPHY_TX0_TURNREQUEST_DIS << GRF_DPHY_TX0_TURNREQUEST_SHIFT;
+   rk_clrsetreg(>soc_con22, GRF_DPHY_TX0_TURNREQUEST_MASK, val);
+}
+
+/*
+ * This function is called by rk_display_init() using rk_mipi_dsi_enable() and
+ * rk_mipi_phy_enable() to initialize mipi controller and dphy. If success,
+ * enable backlight.
+ */
+static int rk_display_enable(struct udevice *dev, int panel_bpp,
+ const struct display_timing *timing)
+{
+   int ret;
+   struct rk_mipi_priv *priv = dev_get_priv(dev);
+
+   /* Fill the mipi controller parameter */
+   priv->ref_clk = 24 * MHz;
+   priv->sys_clk = priv->ref_clk;
+   priv->pix_clk = timing->pixelclock.typ;
+   priv->phy_clk = priv->pix_clk * 6;
+   priv->txbyte_clk = priv->phy_clk / 8;
+   priv->txesc_clk = 20 * MHz;
+
+   /* Select vop port, big or little */
+   rk_mipi_dsi_source_select(dev);
+
+   /* Set mipi dphy work mode */
+   rk_mipi_dphy_mode_set(dev);
+
+   /* Config  and enable mipi dsi according to timing */
+   ret = rk_mipi_dsi_enable(dev, timing);
+   if (ret) {
+   debug("%s: rk_mipi_dsi_enable() failed (err=%d)\n",
+ __func__, ret);
+   return ret;
+   }
+
+   /* Config and enable mipi phy */
+   ret = rk_mipi_phy_enable(dev);
+   if (ret) {
+   debug("%s: rk_mipi_phy_enable() failed (err=%d)\n",
+ __func__, ret);
+   return ret;
+   }
+
+   /* Enable backlight */
+   ret = panel_enable_backlight(priv->panel);
+   if (ret) {
+   debug("%s: panel_enable_backlight() failed (err=%d)\n",
+ __func__, ret);
+   return ret;
+   }
+
+   return 0;
+}
+
+static int rk_mipi_ofdata_to_platdata(struct udevice *dev)
+{
+   struct rk_mipi_priv *priv = dev_get_priv(dev);
+
+   priv->grf = syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
+   if (priv->grf <= 0) {
+   

[U-Boot] [PATCH v3 3/3] rockchop: video: mipi: Makefile: Add soc specfic driver for rk3399 mipi dsi

[Eric Gao]

Add Makefile item for soc specific driver for rk3399 mipi dsi.

Signed-off-by: Eric Gao <eric@rock-chips.com>
---

Changes in v2: None
Changes in v1: None

 drivers/video/rockchip/Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/video/rockchip/Makefile b/drivers/video/rockchip/Makefile
index 872dc0f..600743c 100644
--- a/drivers/video/rockchip/Makefile
+++ b/drivers/video/rockchip/Makefile
@@ -14,5 +14,6 @@ obj-$(CONFIG_DISPLAY_ROCKCHIP_LVDS) += rk_lvds.o
 obj-hdmi-$(CONFIG_ROCKCHIP_RK3288) += rk3288_hdmi.o
 obj-hdmi-$(CONFIG_ROCKCHIP_RK3399) += rk3399_hdmi.o
 obj-$(CONFIG_DISPLAY_ROCKCHIP_HDMI) += rk_hdmi.o $(obj-hdmi-y)
-obj-$(CONFIG_DISPLAY_ROCKCHIP_MIPI) += rk_mipi.o
+obj-mipi-$(CONFIG_ROCKCHIP_RK3399) += rk3399_mipi.o
+obj-$(CONFIG_DISPLAY_ROCKCHIP_MIPI) += rk_mipi.o $(obj-mipi-y)
 endif
-- 
1.9.1


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

[U-Boot] [PATCH v3 1/3] rockchip: defconfig: Increase max video resolution for mipi panel

[Eric Gao]

The mipi panel used on evb-rk3399 has a 1920x1200 resolution. But now
the max resolution is 1920x1080. So increase it.

Signed-off-by: Eric Gao <eric@rock-chips.com>

---

Changes in v2: None
Changes in v1:
-Add title.

 configs/evb-rk3399_defconfig | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/configs/evb-rk3399_defconfig b/configs/evb-rk3399_defconfig
index c189e75..1b30f24 100644
--- a/configs/evb-rk3399_defconfig
+++ b/configs/evb-rk3399_defconfig
@@ -6,6 +6,7 @@ CONFIG_SYS_MALLOC_F_LEN=0x4000
 CONFIG_ROCKCHIP_RK3399=y
 CONFIG_SPL_STACK_R_ADDR=0x8
 CONFIG_DEFAULT_DEVICE_TREE="rk3399-evb"
+CONFIG_DEBUG_UART=y
 CONFIG_FIT=y
 CONFIG_SPL_LOAD_FIT=y
 # CONFIG_DISPLAY_CPUINFO is not set
@@ -23,6 +24,7 @@ CONFIG_CMD_TIME=y
 CONFIG_SPL_OF_CONTROL=y
 CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names 
interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
 CONFIG_SPL_OF_PLATDATA=y
+CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_REGMAP=y
 CONFIG_SPL_REGMAP=y
 CONFIG_SYSCON=y
@@ -34,12 +36,8 @@ CONFIG_SYS_I2C_ROCKCHIP=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ROCKCHIP=y
-CONFIG_DM_PMIC=y
-CONFIG_PMIC_RK808=y
-CONFIG_REGULATOR_RK808=y
 CONFIG_DM_ETH=y
 CONFIG_ETH_DESIGNWARE=y
-CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_GMAC_ROCKCHIP=y
 CONFIG_PINCTRL=y
 CONFIG_SPL_PINCTRL=y
@@ -53,7 +51,6 @@ CONFIG_PWM_ROCKCHIP=y
 CONFIG_RAM=y
 CONFIG_SPL_RAM=y
 CONFIG_BAUDRATE=150
-CONFIG_DEBUG_UART=y
 CONFIG_DEBUG_UART_BASE=0xFF1A
 CONFIG_DEBUG_UART_CLOCK=2400
 CONFIG_DEBUG_UART_SHIFT=2
@@ -68,6 +65,7 @@ CONFIG_USB_STORAGE=y
 CONFIG_DM_VIDEO=y
 CONFIG_DISPLAY=y
 CONFIG_VIDEO_ROCKCHIP=y
+CONFIG_VIDEO_ROCKCHIP_MAX_YRES=1200
 CONFIG_DISPLAY_ROCKCHIP_MIPI=y
 CONFIG_USE_TINY_PRINTF=y
 CONFIG_ERRNO_STR=y
-- 
1.9.1


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

[U-Boot] [PATCH v3 0/3] Split rockchip mipi driver into common and specific parts.

[Eric Gao]

This patch series split the rockchip mipi dsi driver into common and
specific parts to make it possible that different soc share the most
common code.


Changes in v2:
-Use dev_read_addr to replace devfdt_get_addr.

Changes in v1:
-Add title.
-Delete the unused variable.

Eric Gao (3):
  rockchip: defconfig: Increase max video resolution for mipi panel
  rockchip: video: mipi: Split mipi driver into common and specific
parts
  rockchop: video: mipi: Makefile: Add soc specfic driver for rk3399
mipi dsi

 configs/evb-rk3399_defconfig |   8 +-
 drivers/video/rockchip/Makefile  |   3 +-
 drivers/video/rockchip/rk3399_mipi.c | 183 +++
 drivers/video/rockchip/rk_mipi.c | 170 ++--
 drivers/video/rockchip/rk_mipi.h |  32 ++
 5 files changed, 226 insertions(+), 170 deletions(-)
 create mode 100644 drivers/video/rockchip/rk3399_mipi.c
 create mode 100644 drivers/video/rockchip/rk_mipi.h

-- 
1.9.1


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

[U-Boot] [PATCH v2] rockchip: video: mipi: Modify format type for debug message

[Eric Gao]

Modify format type for debug message.

Signed-off-by: Eric Gao <eric@rock-chips.com>

---

Changes in v1:
-Change the debug message format type because of the change the variable.

 drivers/video/rockchip/rk_mipi.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/video/rockchip/rk_mipi.c b/drivers/video/rockchip/rk_mipi.c
index 1ccd247..1199a30 100644
--- a/drivers/video/rockchip/rk_mipi.c
+++ b/drivers/video/rockchip/rk_mipi.c
@@ -437,14 +437,14 @@ static int rk_mipi_ofdata_to_platdata(struct udevice *dev)
 
priv->grf = syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
if (priv->grf <= 0) {
-   debug("%s: Get syscon grf failed (ret=%llu)\n",
- __func__, (u64)priv->grf);
+   debug("%s: Get syscon grf failed (ret=%p)\n",
+ __func__, priv->grf);
return  -ENXIO;
}
priv->regs = devfdt_get_addr(dev);
if (priv->regs <= 0) {
-   debug("%s: Get MIPI dsi address failed (ret=%llu)\n", __func__,
- (u64)priv->regs);
+   debug("%s: Get MIPI dsi address failed (ret=%lu)\n", __func__,
+ priv->regs);
return  -ENXIO;
}
 
-- 
1.9.1


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

[U-Boot] [PATCH v4] rockchip: video: mipi: Modify variable type for arm32 compatibility

[Eric Gao]

Some address relevant varibable is defined originally as u64. To
compatible with arm32, this patch change them to uintptr_t type.

Signed-off-by: Eric Gao <eric@rock-chips.com>
Reviewed-by: Simon Glass <s...@chromium.org>

---

Changes in v3:
-Cancel the force convert for devfdt_get_addr's return value type.
-Change the addr tye from uintptr_t * to uintptr_t

Changes in v2:
-Change the address base variable from "uintptr_t *" to "uintptr_t"

Changes in v1:
-Change the address base variable to uintptr_t * type.

 drivers/video/rockchip/rk_mipi.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/video/rockchip/rk_mipi.c b/drivers/video/rockchip/rk_mipi.c
index ad00397..1ccd247 100644
--- a/drivers/video/rockchip/rk_mipi.c
+++ b/drivers/video/rockchip/rk_mipi.c
@@ -40,7 +40,7 @@ DECLARE_GLOBAL_DATA_PTR;
  * @txesc_clk: clock for tx esc mode
  */
 struct rk_mipi_priv {
-   void __iomem *regs;
+   uintptr_t regs;
struct rk3399_grf_regs *grf;
struct udevice *panel;
struct mipi_dsi *dsi;
@@ -76,13 +76,13 @@ static int rk_mipi_read_timing(struct udevice *dev,
  *use define in rk_mipi.h directly for this parameter
  *  @val: value that will be write to specified bits of register
  */
-static void rk_mipi_dsi_write(u32 regs, u32 reg, u32 val)
+static void rk_mipi_dsi_write(uintptr_t regs, u32 reg, u32 val)
 {
u32 dat;
u32 mask;
u32 offset = (reg >> OFFSET_SHIFT) & 0xff;
u32 bits = (reg >> BITS_SHIFT) & 0xff;
-   u64 addr = (reg >> ADDR_SHIFT) + regs;
+   uintptr_t addr = (reg >> ADDR_SHIFT) + regs;
 
/* Mask for specifiled bits,the corresponding bits will be clear */
mask = ~((0x << offset) & (0x >> (32 - offset - bits)));
@@ -108,7 +108,7 @@ static int rk_mipi_dsi_enable(struct udevice *dev,
int node, timing_node;
int val;
struct rk_mipi_priv *priv = dev_get_priv(dev);
-   u64 regs = (u64)priv->regs;
+   uintptr_t regs = priv->regs;
struct display_plat *disp_uc_plat = dev_get_uclass_platdata(dev);
u32 txbyte_clk = priv->txbyte_clk;
u32 txesc_clk = priv->txesc_clk;
@@ -224,7 +224,7 @@ static int rk_mipi_dsi_enable(struct udevice *dev,
 }
 
 /* rk mipi dphy write function. It is used to write test data to dphy */
-static void rk_mipi_phy_write(u32 regs, unsigned char test_code,
+static void rk_mipi_phy_write(uintptr_t regs, unsigned char test_code,
  unsigned char *test_data, unsigned char size)
 {
int i = 0;
@@ -253,7 +253,7 @@ static int rk_mipi_phy_enable(struct udevice *dev)
 {
int i;
struct rk_mipi_priv *priv = dev_get_priv(dev);
-   u64 regs = (u64)priv->regs;
+   uintptr_t regs = priv->regs;
u64 fbdiv;
u64 prediv = 1;
u32 max_fbdiv = 512;
@@ -441,7 +441,7 @@ static int rk_mipi_ofdata_to_platdata(struct udevice *dev)
  __func__, (u64)priv->grf);
return  -ENXIO;
}
-   priv->regs = (void *)devfdt_get_addr(dev);
+   priv->regs = devfdt_get_addr(dev);
if (priv->regs <= 0) {
debug("%s: Get MIPI dsi address failed (ret=%llu)\n", __func__,
  (u64)priv->regs);
-- 
1.9.1


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

[U-Boot] [PATCH v3] rockchip: video: mipi: Modify variable type for arm32 compatibility

[Eric Gao]

Some address relevant varibable is defined originally as u64. To
compatible with arm32, this patch change them to uintptr_t type.

Signed-off-by: Eric Gao <eric@rock-chips.com>
Reviewed-by: Simon Glass <s...@chromium.org>

---

Changes in v2:
-Change the address base variable from "uintptr_t *" to "uintptr_t"

Changes in v1:
-Change the address base variable to uintptr_t * type.

 drivers/video/rockchip/rk_mipi.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/video/rockchip/rk_mipi.c b/drivers/video/rockchip/rk_mipi.c
index ad00397..521256e 100644
--- a/drivers/video/rockchip/rk_mipi.c
+++ b/drivers/video/rockchip/rk_mipi.c
@@ -40,7 +40,7 @@ DECLARE_GLOBAL_DATA_PTR;
  * @txesc_clk: clock for tx esc mode
  */
 struct rk_mipi_priv {
-   void __iomem *regs;
+   uintptr_t regs;
struct rk3399_grf_regs *grf;
struct udevice *panel;
struct mipi_dsi *dsi;
@@ -76,13 +76,13 @@ static int rk_mipi_read_timing(struct udevice *dev,
  *use define in rk_mipi.h directly for this parameter
  *  @val: value that will be write to specified bits of register
  */
-static void rk_mipi_dsi_write(u32 regs, u32 reg, u32 val)
+static void rk_mipi_dsi_write(uintptr_t regs, u32 reg, u32 val)
 {
u32 dat;
u32 mask;
u32 offset = (reg >> OFFSET_SHIFT) & 0xff;
u32 bits = (reg >> BITS_SHIFT) & 0xff;
-   u64 addr = (reg >> ADDR_SHIFT) + regs;
+   uintptr_t *addr = (reg >> ADDR_SHIFT) + regs;
 
/* Mask for specifiled bits,the corresponding bits will be clear */
mask = ~((0x << offset) & (0x >> (32 - offset - bits)));
@@ -108,7 +108,7 @@ static int rk_mipi_dsi_enable(struct udevice *dev,
int node, timing_node;
int val;
struct rk_mipi_priv *priv = dev_get_priv(dev);
-   u64 regs = (u64)priv->regs;
+   uintptr_t regs = priv->regs;
struct display_plat *disp_uc_plat = dev_get_uclass_platdata(dev);
u32 txbyte_clk = priv->txbyte_clk;
u32 txesc_clk = priv->txesc_clk;
@@ -224,7 +224,7 @@ static int rk_mipi_dsi_enable(struct udevice *dev,
 }
 
 /* rk mipi dphy write function. It is used to write test data to dphy */
-static void rk_mipi_phy_write(u32 regs, unsigned char test_code,
+static void rk_mipi_phy_write(uintptr_t regs, unsigned char test_code,
  unsigned char *test_data, unsigned char size)
 {
int i = 0;
@@ -253,7 +253,7 @@ static int rk_mipi_phy_enable(struct udevice *dev)
 {
int i;
struct rk_mipi_priv *priv = dev_get_priv(dev);
-   u64 regs = (u64)priv->regs;
+   uintptr_t regs = priv->regs;
u64 fbdiv;
u64 prediv = 1;
u32 max_fbdiv = 512;
-- 
1.9.1


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

[U-Boot] [PATCH v1] rockchip: pwm: fix: pwm dosen't work on rk3288

[Eric Gao]

According to rk3288 spec, the pwm register order is:
PWM_PWM0_CNT,
PWM_PWM0_PERIOD_HPR,
PWM_PWM0_DUTY_LPR,
PWM_PWM0_CTRL

but the source code's order is:
struct rk3288_pwm {
u32 cnt;
u32 duty_lpr;
u32 period_hpr;
u32 ctrl;
};

So, correct it here. It is the same as RK3399

Signed-off-by: Eric Gao <eric@rock-chips.com>

---

 arch/arm/include/asm/arch-rockchip/pwm.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/arch-rockchip/pwm.h 
b/arch/arm/include/asm/arch-rockchip/pwm.h
index 5d9a178..08ff945 100644
--- a/arch/arm/include/asm/arch-rockchip/pwm.h
+++ b/arch/arm/include/asm/arch-rockchip/pwm.h
@@ -10,8 +10,8 @@
 
 struct rk3288_pwm {
u32 cnt;
-   u32 duty_lpr;
u32 period_hpr;
+   u32 duty_lpr;
u32 ctrl;
 };
 check_member(rk3288_pwm, ctrl, 0xc);
-- 
1.9.1


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

[U-Boot] [PATCH v2 1/3] rockchip: video: mipi: Add rk3288 soc specific driver for mipi dsi

[Eric Gao]

Add rk3288 soc specific driver for mipi dsi.

Signed-off-by: Eric Gao <eric@rock-chips.com>

---

Changes in v1:
-Change function name from rk_display_enable to rk_mipi_enable.
-Use IS_ERR to judge the return status.
-Use dev_read_addr to replace devfdt_get_addr.

 drivers/video/rockchip/rk3288_mipi.c | 191 +++
 1 file changed, 191 insertions(+)
 create mode 100644 drivers/video/rockchip/rk3288_mipi.c

diff --git a/drivers/video/rockchip/rk3288_mipi.c 
b/drivers/video/rockchip/rk3288_mipi.c
new file mode 100644
index 000..a0d3544
--- /dev/null
+++ b/drivers/video/rockchip/rk3288_mipi.c
@@ -0,0 +1,191 @@
+/*
+ * Copyright (c) 2017, Fuzhou Rockchip Electronics Co., Ltd
+ * Author: Eric Gao <eric@rock-chips.com>
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "rk_mipi.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define MHz 100
+
+/* Select mipi dsi source, big or little vop */
+static int rk_mipi_dsi_source_select(struct udevice *dev)
+{
+   struct rk_mipi_priv *priv = dev_get_priv(dev);
+   struct rk3288_grf *grf = priv->grf;
+   struct display_plat *disp_uc_plat = dev_get_uclass_platdata(dev);
+
+   /* Select the video source */
+   switch (disp_uc_plat->source_id) {
+   case VOP_B:
+   rk_clrsetreg(>soc_con6, RK3288_DSI0_LCDC_SEL_MASK,
+RK3288_DSI0_LCDC_SEL_BIG
+<< RK3288_DSI0_LCDC_SEL_SHIFT);
+   break;
+   case VOP_L:
+   rk_clrsetreg(>soc_con6, RK3288_DSI0_LCDC_SEL_MASK,
+RK3288_DSI0_LCDC_SEL_LIT
+<< RK3288_DSI0_LCDC_SEL_SHIFT);
+   break;
+   default:
+   debug("%s: Invalid VOP id\n", __func__);
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+/* Setup mipi dphy working mode */
+static void rk_mipi_dphy_mode_set(struct udevice *dev)
+{
+   struct rk_mipi_priv *priv = dev_get_priv(dev);
+   struct rk3288_grf *grf = priv->grf;
+   int val;
+
+   /* Set Controller as TX mode */
+   val = RK3288_DPHY_TX0_RXMODE_DIS << RK3288_DPHY_TX0_RXMODE_SHIFT;
+   rk_clrsetreg(>soc_con8, RK3288_DPHY_TX0_RXMODE_MASK, val);
+
+   /* Exit tx stop mode */
+   val |= RK3288_DPHY_TX0_TXSTOPMODE_EN
+   << RK3288_DPHY_TX0_TXSTOPMODE_SHIFT;
+   rk_clrsetreg(>soc_con8,
+RK3288_DPHY_TX0_TXSTOPMODE_MASK, val);
+
+   /* Disable turnequest */
+   val |= RK3288_DPHY_TX0_TURNREQUEST_EN
+   << RK3288_DPHY_TX0_TURNREQUEST_SHIFT;
+   rk_clrsetreg(>soc_con8,
+RK3288_DPHY_TX0_TURNREQUEST_MASK, val);
+}
+
+/*
+ * This function is called by rk_display_init() using rk_mipi_dsi_enable() and
+ * rk_mipi_phy_enable() to initialize mipi controller and dphy. If success,
+ * enable backlight.
+ */
+static int rk_mipi_enable(struct udevice *dev, int panel_bpp,
+ const struct display_timing *timing)
+{
+   int ret;
+   struct rk_mipi_priv *priv = dev_get_priv(dev);
+
+   /* Fill the mipi controller parameter */
+   priv->ref_clk = 24 * MHz;
+   priv->sys_clk = priv->ref_clk;
+   priv->pix_clk = timing->pixelclock.typ;
+   priv->phy_clk = priv->pix_clk * 6;
+   priv->txbyte_clk = priv->phy_clk / 8;
+   priv->txesc_clk = 20 * MHz;
+
+   /* Select vop port, big or little */
+   rk_mipi_dsi_source_select(dev);
+
+   /* Set mipi dphy work mode */
+   rk_mipi_dphy_mode_set(dev);
+
+   /* Config  and enable mipi dsi according to timing */
+   ret = rk_mipi_dsi_enable(dev, timing);
+   if (ret) {
+   debug("%s: rk_mipi_dsi_enable() failed (err=%d)\n",
+ __func__, ret);
+   return ret;
+   }
+
+   /* Config and enable mipi phy */
+   ret = rk_mipi_phy_enable(dev);
+   if (ret) {
+   debug("%s: rk_mipi_phy_enable() failed (err=%d)\n",
+ __func__, ret);
+   return ret;
+   }
+
+   /* Enable backlight */
+   ret = panel_enable_backlight(priv->panel);
+   if (ret) {
+   debug("%s: panel_enable_backlight() failed (err=%d)\n",
+ __func__, ret);
+   return ret;
+   }
+
+   return 0;
+}
+
+static int rk_mipi_ofdata_to_platdata(struct udevice *dev)
+{
+   struct rk_mipi_priv *priv = dev_get_priv(dev);
+
+   priv->grf = syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
+   if (IS_ERR(priv->grf)) {
+   debug("%s: Get syscon grf failed (ret=%p)\n",
+  

[U-Boot] [PATCH v2 2/3] rockchip: video: Makefile: Add soc specific driver for rk3288 mipi dsi

[Eric Gao]

Signed-off-by: Eric Gao <eric@rock-chips.com>
---

Changes in v1: None

 drivers/video/rockchip/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/video/rockchip/Makefile b/drivers/video/rockchip/Makefile
index 600743c..8005003 100644
--- a/drivers/video/rockchip/Makefile
+++ b/drivers/video/rockchip/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_DISPLAY_ROCKCHIP_LVDS) += rk_lvds.o
 obj-hdmi-$(CONFIG_ROCKCHIP_RK3288) += rk3288_hdmi.o
 obj-hdmi-$(CONFIG_ROCKCHIP_RK3399) += rk3399_hdmi.o
 obj-$(CONFIG_DISPLAY_ROCKCHIP_HDMI) += rk_hdmi.o $(obj-hdmi-y)
+obj-mipi-$(CONFIG_ROCKCHIP_RK3288) += rk3288_mipi.o
 obj-mipi-$(CONFIG_ROCKCHIP_RK3399) += rk3399_mipi.o
 obj-$(CONFIG_DISPLAY_ROCKCHIP_MIPI) += rk_mipi.o $(obj-mipi-y)
 endif
-- 
1.9.1


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

[U-Boot] [PATCH v2 3/3] rockchip: video: defconfig: Add mipi dsi support for evb-rk3288

[Eric Gao]

Add support for rk3288 mipi dsi.

Signed-off-by: Eric Gao <eric@rock-chips.com>
Reviewed-by: Simon Glass <s...@chromium.org>

---

Changes in v1:
-Make the subject more intelligible.

 configs/evb-rk3288_defconfig | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/configs/evb-rk3288_defconfig b/configs/evb-rk3288_defconfig
index 227150d..fb5599d 100644
--- a/configs/evb-rk3288_defconfig
+++ b/configs/evb-rk3288_defconfig
@@ -6,8 +6,8 @@ CONFIG_ROCKCHIP_SPL_BACK_TO_BROM=y
 CONFIG_TARGET_EVB_RK3288=y
 CONFIG_SPL_STACK_R_ADDR=0x8
 CONFIG_DEFAULT_DEVICE_TREE="rk3288-evb"
+CONFIG_DEBUG_UART=y
 CONFIG_SILENT_CONSOLE=y
-CONFIG_CONSOLE_MUX=y
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x2000
@@ -55,12 +55,16 @@ CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_PWM_ROCKCHIP=y
 CONFIG_RAM=y
 CONFIG_SPL_RAM=y
-CONFIG_DEBUG_UART=y
 CONFIG_DEBUG_UART_BASE=0xff69
 CONFIG_DEBUG_UART_CLOCK=2400
 CONFIG_DEBUG_UART_SHIFT=2
 CONFIG_SYS_NS16550=y
 CONFIG_SYSRESET=y
+CONFIG_DM_VIDEO=y
+CONFIG_DISPLAY=y
+CONFIG_VIDEO_ROCKCHIP=y
+CONFIG_VIDEO_ROCKCHIP_MAX_YRES=1200
+CONFIG_DISPLAY_ROCKCHIP_MIPI=y
 CONFIG_USE_TINY_PRINTF=y
 CONFIG_CMD_DHRYSTONE=y
 CONFIG_ERRNO_STR=y
-- 
1.9.1


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

[U-Boot] [PATCH v2 0/3] Add mipi dsi support for evb-rk3288.

[Eric Gao]

Changes in v1:
-Change function name from rk_display_enable to rk_mipi_enable.
-Use IS_ERR to judge the return status.
-Use dev_read_addr to replace devfdt_get_addr.
-Make the subject more intelligible.

Eric Gao (3):
  rockchip: video: mipi: Add rk3288 soc specific driver for mipi dsi
  rockchip: video: Makefile: Add soc specific driver for rk3288 mipi dsi
  rockchip: video: defconfig: Add mipi dsi support for evb-rk3288

 configs/evb-rk3288_defconfig |   8 +-
 drivers/video/rockchip/Makefile  |   1 +
 drivers/video/rockchip/rk3288_mipi.c | 191 +++
 3 files changed, 198 insertions(+), 2 deletions(-)
 create mode 100644 drivers/video/rockchip/rk3288_mipi.c

-- 
1.9.1


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

[U-Boot] [PATCH v2] rockchip: video: mipi: Modify variable type for arm32 compatibility

[Eric Gao]

Some address relevant varibable is defined originally as u64. To
compatible with arm32, this patch change them to "void __iomem *" type.

Signed-off-by: Eric Gao <eric@rock-chips.com>

---

Changes in v1:
-Change the address base variable to uintptr_t type.

 drivers/video/rockchip/rk_mipi.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/video/rockchip/rk_mipi.c b/drivers/video/rockchip/rk_mipi.c
index ad00397..a9522ce 100644
--- a/drivers/video/rockchip/rk_mipi.c
+++ b/drivers/video/rockchip/rk_mipi.c
@@ -40,7 +40,7 @@ DECLARE_GLOBAL_DATA_PTR;
  * @txesc_clk: clock for tx esc mode
  */
 struct rk_mipi_priv {
-   void __iomem *regs;
+   uintptr_t *regs;
struct rk3399_grf_regs *grf;
struct udevice *panel;
struct mipi_dsi *dsi;
@@ -76,13 +76,13 @@ static int rk_mipi_read_timing(struct udevice *dev,
  *use define in rk_mipi.h directly for this parameter
  *  @val: value that will be write to specified bits of register
  */
-static void rk_mipi_dsi_write(u32 regs, u32 reg, u32 val)
+static void rk_mipi_dsi_write(uintptr_t *regs, u32 reg, u32 val)
 {
u32 dat;
u32 mask;
u32 offset = (reg >> OFFSET_SHIFT) & 0xff;
u32 bits = (reg >> BITS_SHIFT) & 0xff;
-   u64 addr = (reg >> ADDR_SHIFT) + regs;
+   uintptr_t *addr = (reg >> ADDR_SHIFT) + regs;
 
/* Mask for specifiled bits,the corresponding bits will be clear */
mask = ~((0x << offset) & (0x >> (32 - offset - bits)));
@@ -108,7 +108,7 @@ static int rk_mipi_dsi_enable(struct udevice *dev,
int node, timing_node;
int val;
struct rk_mipi_priv *priv = dev_get_priv(dev);
-   u64 regs = (u64)priv->regs;
+   uintptr_t *regs = priv->regs;
struct display_plat *disp_uc_plat = dev_get_uclass_platdata(dev);
u32 txbyte_clk = priv->txbyte_clk;
u32 txesc_clk = priv->txesc_clk;
@@ -224,7 +224,7 @@ static int rk_mipi_dsi_enable(struct udevice *dev,
 }
 
 /* rk mipi dphy write function. It is used to write test data to dphy */
-static void rk_mipi_phy_write(u32 regs, unsigned char test_code,
+static void rk_mipi_phy_write(uintptr_t *regs, unsigned char test_code,
  unsigned char *test_data, unsigned char size)
 {
int i = 0;
@@ -253,7 +253,7 @@ static int rk_mipi_phy_enable(struct udevice *dev)
 {
int i;
struct rk_mipi_priv *priv = dev_get_priv(dev);
-   u64 regs = (u64)priv->regs;
+   uintptr_t *regs = priv->regs;
u64 fbdiv;
u64 prediv = 1;
u32 max_fbdiv = 512;
-- 
1.9.1


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

[U-Boot] [PATCH v1] rockchip: video: mipi: Modify variable type for arm32 compatibility

[Eric Gao]

Some address relevant varibable is defined originally as u64. To
compatible with arm32, this patch change them to "void __iomem *" type.

Signed-off-by: Eric Gao <eric@rock-chips.com>

---

Changes in v1:
-Change the address base variable to uintptr_t type.

 drivers/video/rockchip/rk_mipi.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/video/rockchip/rk_mipi.c b/drivers/video/rockchip/rk_mipi.c
index ad00397..a9522ce 100644
--- a/drivers/video/rockchip/rk_mipi.c
+++ b/drivers/video/rockchip/rk_mipi.c
@@ -40,7 +40,7 @@ DECLARE_GLOBAL_DATA_PTR;
  * @txesc_clk: clock for tx esc mode
  */
 struct rk_mipi_priv {
-   void __iomem *regs;
+   uintptr_t *regs;
struct rk3399_grf_regs *grf;
struct udevice *panel;
struct mipi_dsi *dsi;
@@ -76,13 +76,13 @@ static int rk_mipi_read_timing(struct udevice *dev,
  *use define in rk_mipi.h directly for this parameter
  *  @val: value that will be write to specified bits of register
  */
-static void rk_mipi_dsi_write(u32 regs, u32 reg, u32 val)
+static void rk_mipi_dsi_write(uintptr_t *regs, u32 reg, u32 val)
 {
u32 dat;
u32 mask;
u32 offset = (reg >> OFFSET_SHIFT) & 0xff;
u32 bits = (reg >> BITS_SHIFT) & 0xff;
-   u64 addr = (reg >> ADDR_SHIFT) + regs;
+   uintptr_t *addr = (reg >> ADDR_SHIFT) + regs;
 
/* Mask for specifiled bits,the corresponding bits will be clear */
mask = ~((0x << offset) & (0x >> (32 - offset - bits)));
@@ -108,7 +108,7 @@ static int rk_mipi_dsi_enable(struct udevice *dev,
int node, timing_node;
int val;
struct rk_mipi_priv *priv = dev_get_priv(dev);
-   u64 regs = (u64)priv->regs;
+   uintptr_t *regs = priv->regs;
struct display_plat *disp_uc_plat = dev_get_uclass_platdata(dev);
u32 txbyte_clk = priv->txbyte_clk;
u32 txesc_clk = priv->txesc_clk;
@@ -224,7 +224,7 @@ static int rk_mipi_dsi_enable(struct udevice *dev,
 }
 
 /* rk mipi dphy write function. It is used to write test data to dphy */
-static void rk_mipi_phy_write(u32 regs, unsigned char test_code,
+static void rk_mipi_phy_write(uintptr_t *regs, unsigned char test_code,
  unsigned char *test_data, unsigned char size)
 {
int i = 0;
@@ -253,7 +253,7 @@ static int rk_mipi_phy_enable(struct udevice *dev)
 {
int i;
struct rk_mipi_priv *priv = dev_get_priv(dev);
-   u64 regs = (u64)priv->regs;
+   uintptr_t *regs = priv->regs;
u64 fbdiv;
u64 prediv = 1;
u32 max_fbdiv = 512;
-- 
1.9.1


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

[U-Boot] [PATCH v2 3/3] rockchop: video: mipi: Makefile: Add soc specfic driver for rk3399 mipi dsi

[Eric Gao]

Add Makefile item for soc specific driver for rk3399 mipi dsi.

Signed-off-by: Eric Gao <eric@rock-chips.com>
---

Changes in v1: None

 drivers/video/rockchip/Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/video/rockchip/Makefile b/drivers/video/rockchip/Makefile
index 872dc0f..600743c 100644
--- a/drivers/video/rockchip/Makefile
+++ b/drivers/video/rockchip/Makefile
@@ -14,5 +14,6 @@ obj-$(CONFIG_DISPLAY_ROCKCHIP_LVDS) += rk_lvds.o
 obj-hdmi-$(CONFIG_ROCKCHIP_RK3288) += rk3288_hdmi.o
 obj-hdmi-$(CONFIG_ROCKCHIP_RK3399) += rk3399_hdmi.o
 obj-$(CONFIG_DISPLAY_ROCKCHIP_HDMI) += rk_hdmi.o $(obj-hdmi-y)
-obj-$(CONFIG_DISPLAY_ROCKCHIP_MIPI) += rk_mipi.o
+obj-mipi-$(CONFIG_ROCKCHIP_RK3399) += rk3399_mipi.o
+obj-$(CONFIG_DISPLAY_ROCKCHIP_MIPI) += rk_mipi.o $(obj-mipi-y)
 endif
-- 
1.9.1


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

[U-Boot] [PATCH v2 2/3] rockchip: video: mipi: Split mipi driver into common and specific parts

[Eric Gao]

To compatible with different rockchip soc, we split the mipi dirver into
common and soc specific parts, and all the soc share the common
functions from common driver part.

Signed-off-by: Eric Gao <eric@rock-chips.com>
---

Changes in v1: None

 drivers/video/rockchip/rk3399_mipi.c | 183 +++
 drivers/video/rockchip/rk_mipi.c | 172 ++--
 drivers/video/rockchip/rk_mipi.h |  32 ++
 3 files changed, 222 insertions(+), 165 deletions(-)
 create mode 100644 drivers/video/rockchip/rk3399_mipi.c
 create mode 100644 drivers/video/rockchip/rk_mipi.h

diff --git a/drivers/video/rockchip/rk3399_mipi.c 
b/drivers/video/rockchip/rk3399_mipi.c
new file mode 100644
index 000..bac43e4
--- /dev/null
+++ b/drivers/video/rockchip/rk3399_mipi.c
@@ -0,0 +1,183 @@
+/*
+ * Copyright (c) 2017, Fuzhou Rockchip Electronics Co., Ltd
+ * Author: Eric Gao <eric@rock-chips.com>
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "rk_mipi.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* Select mipi dsi source, big or little vop */
+static int rk_mipi_dsi_source_select(struct udevice *dev)
+{
+   struct rk_mipi_priv *priv = dev_get_priv(dev);
+   struct rk3399_grf_regs *grf = priv->grf;
+   struct display_plat *disp_uc_plat = dev_get_uclass_platdata(dev);
+
+   /* Select the video source */
+   switch (disp_uc_plat->source_id) {
+   case VOP_B:
+   rk_clrsetreg(>soc_con20, GRF_DSI0_VOP_SEL_MASK,
+GRF_DSI0_VOP_SEL_B << GRF_DSI0_VOP_SEL_SHIFT);
+   break;
+   case VOP_L:
+   rk_clrsetreg(>soc_con20, GRF_DSI0_VOP_SEL_MASK,
+GRF_DSI0_VOP_SEL_L << GRF_DSI0_VOP_SEL_SHIFT);
+   break;
+   default:
+   debug("%s: Invalid VOP id\n", __func__);
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+/* Setup mipi dphy working mode */
+static void rk_mipi_dphy_mode_set(struct udevice *dev)
+{
+   struct rk_mipi_priv *priv = dev_get_priv(dev);
+   struct rk3399_grf_regs *grf = priv->grf;
+   int val;
+
+   /* Set Controller as TX mode */
+   val = GRF_DPHY_TX0_RXMODE_DIS << GRF_DPHY_TX0_RXMODE_SHIFT;
+   rk_clrsetreg(>soc_con22, GRF_DPHY_TX0_RXMODE_MASK, val);
+
+   /* Exit tx stop mode */
+   val |= GRF_DPHY_TX0_TXSTOPMODE_DIS << GRF_DPHY_TX0_TXSTOPMODE_SHIFT;
+   rk_clrsetreg(>soc_con22, GRF_DPHY_TX0_TXSTOPMODE_MASK, val);
+
+   /* Disable turnequest */
+   val |= GRF_DPHY_TX0_TURNREQUEST_DIS << GRF_DPHY_TX0_TURNREQUEST_SHIFT;
+   rk_clrsetreg(>soc_con22, GRF_DPHY_TX0_TURNREQUEST_MASK, val);
+}
+
+/*
+ * This function is called by rk_display_init() using rk_mipi_dsi_enable() and
+ * rk_mipi_phy_enable() to initialize mipi controller and dphy. If success,
+ * enable backlight.
+ */
+static int rk_display_enable(struct udevice *dev, int panel_bpp,
+ const struct display_timing *timing)
+{
+   int ret;
+   struct rk_mipi_priv *priv = dev_get_priv(dev);
+
+   /* Fill the mipi controller parameter */
+   priv->ref_clk = 24 * MHz;
+   priv->sys_clk = priv->ref_clk;
+   priv->pix_clk = timing->pixelclock.typ;
+   priv->phy_clk = priv->pix_clk * 6;
+   priv->txbyte_clk = priv->phy_clk / 8;
+   priv->txesc_clk = 20 * MHz;
+
+   /* Select vop port, big or little */
+   rk_mipi_dsi_source_select(dev);
+
+   /* Set mipi dphy work mode */
+   rk_mipi_dphy_mode_set(dev);
+
+   /* Config  and enable mipi dsi according to timing */
+   ret = rk_mipi_dsi_enable(dev, timing);
+   if (ret) {
+   debug("%s: rk_mipi_dsi_enable() failed (err=%d)\n",
+ __func__, ret);
+   return ret;
+   }
+
+   /* Config and enable mipi phy */
+   ret = rk_mipi_phy_enable(dev);
+   if (ret) {
+   debug("%s: rk_mipi_phy_enable() failed (err=%d)\n",
+ __func__, ret);
+   return ret;
+   }
+
+   /* Enable backlight */
+   ret = panel_enable_backlight(priv->panel);
+   if (ret) {
+   debug("%s: panel_enable_backlight() failed (err=%d)\n",
+ __func__, ret);
+   return ret;
+   }
+
+   return 0;
+}
+
+static int rk_mipi_ofdata_to_platdata(struct udevice *dev)
+{
+   struct rk_mipi_priv *priv = dev_get_priv(dev);
+
+   priv->grf = syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
+   if (priv->grf <= 0) {
+   debug("%s: Get syscon grf failed (ret=%p)\n",
+ __func__, pri

[U-Boot] [PATCH v2 1/3] rockchip: defconfig: Increase max video resolution for mipi panel

[Eric Gao]

The mipi panel used on evb-rk3399 has a 1920x1200 resolution. But now
the max resolution is 1920x1080. So increase it.

Signed-off-by: Eric Gao <eric@rock-chips.com>

---

Changes in v1:
-Add title.

 configs/evb-rk3399_defconfig | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/configs/evb-rk3399_defconfig b/configs/evb-rk3399_defconfig
index c189e75..1b30f24 100644
--- a/configs/evb-rk3399_defconfig
+++ b/configs/evb-rk3399_defconfig
@@ -6,6 +6,7 @@ CONFIG_SYS_MALLOC_F_LEN=0x4000
 CONFIG_ROCKCHIP_RK3399=y
 CONFIG_SPL_STACK_R_ADDR=0x8
 CONFIG_DEFAULT_DEVICE_TREE="rk3399-evb"
+CONFIG_DEBUG_UART=y
 CONFIG_FIT=y
 CONFIG_SPL_LOAD_FIT=y
 # CONFIG_DISPLAY_CPUINFO is not set
@@ -23,6 +24,7 @@ CONFIG_CMD_TIME=y
 CONFIG_SPL_OF_CONTROL=y
 CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names 
interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
 CONFIG_SPL_OF_PLATDATA=y
+CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_REGMAP=y
 CONFIG_SPL_REGMAP=y
 CONFIG_SYSCON=y
@@ -34,12 +36,8 @@ CONFIG_SYS_I2C_ROCKCHIP=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ROCKCHIP=y
-CONFIG_DM_PMIC=y
-CONFIG_PMIC_RK808=y
-CONFIG_REGULATOR_RK808=y
 CONFIG_DM_ETH=y
 CONFIG_ETH_DESIGNWARE=y
-CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_GMAC_ROCKCHIP=y
 CONFIG_PINCTRL=y
 CONFIG_SPL_PINCTRL=y
@@ -53,7 +51,6 @@ CONFIG_PWM_ROCKCHIP=y
 CONFIG_RAM=y
 CONFIG_SPL_RAM=y
 CONFIG_BAUDRATE=150
-CONFIG_DEBUG_UART=y
 CONFIG_DEBUG_UART_BASE=0xFF1A
 CONFIG_DEBUG_UART_CLOCK=2400
 CONFIG_DEBUG_UART_SHIFT=2
@@ -68,6 +65,7 @@ CONFIG_USB_STORAGE=y
 CONFIG_DM_VIDEO=y
 CONFIG_DISPLAY=y
 CONFIG_VIDEO_ROCKCHIP=y
+CONFIG_VIDEO_ROCKCHIP_MAX_YRES=1200
 CONFIG_DISPLAY_ROCKCHIP_MIPI=y
 CONFIG_USE_TINY_PRINTF=y
 CONFIG_ERRNO_STR=y
-- 
1.9.1


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

[U-Boot] [PATCH v2 0/3] Split rockchip mipi driver into common and specific parts.

[Eric Gao]

This patch series split the rockchip mipi dsi driver into common and
specific parts to make it possible that different soc share the most
common code.


Changes in v1:
-Add title.

Eric Gao (3):
  rockchip: defconfig: Increase max video resolution for mipi panel
  rockchip: video: mipi: Split mipi driver into common and specific
parts
  rockchop: video: mipi: Makefile: Add soc specfic driver for rk3399
mipi dsi

 configs/evb-rk3399_defconfig |   8 +-
 drivers/video/rockchip/Makefile  |   3 +-
 drivers/video/rockchip/rk3399_mipi.c | 183 +++
 drivers/video/rockchip/rk_mipi.c | 172 ++--
 drivers/video/rockchip/rk_mipi.h |  32 ++
 5 files changed, 227 insertions(+), 171 deletions(-)
 create mode 100644 drivers/video/rockchip/rk3399_mipi.c
 create mode 100644 drivers/video/rockchip/rk_mipi.h

-- 
1.9.1


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