[U-Boot] [PATCH v2] x86: conga-qeval20-qa3: Add README to explain the console UART options

[Stefan Roese]

This patch adds a small README to explain the 2 defconfig files and its
usage for the different console UART options.

Signed-off-by: Stefan Roese 
Reviewed-by: Bin Meng 
Cc: Simon Glass 
---
v2:
- Minor change in the text as suggested by Bin

 board/congatec/conga-qeval20-qa3-e3845/README | 23 +++
 1 file changed, 23 insertions(+)
 create mode 100644 board/congatec/conga-qeval20-qa3-e3845/README

diff --git a/board/congatec/conga-qeval20-qa3-e3845/README 
b/board/congatec/conga-qeval20-qa3-e3845/README
new file mode 100644
index 000..98ff992
--- /dev/null
+++ b/board/congatec/conga-qeval20-qa3-e3845/README
@@ -0,0 +1,23 @@
+--
+U-Boot console UART selection:
+--
+
+The U-Boot port for this congatec board currently supports two different
+configurations (defconfig files). The only difference is the UART that
+is used as the U-Boot console UART. The default defconfig file:
+
+conga-qeval20-qa3-e3845_defconfig
+
+provides this console on the UART0 which is provided via a Winbond
+Super-IO chip connected on the congatec Qseven 2.0 evaluation carrier
+board (conga-QEVAL). This UART is the one provided with a SubD9
+connector on the mainboard (the low one). The 2nd defconfig file:
+
+conga-qeval20-qa3-e3845-internal-uart_defconfig
+
+provides the U-Boot console on the BayTrail internal legacy UART,
+which is routed from the QSeven SoM to the X300 connector on the
+baseboard. Here is called COM2. The baseboard already provides the
+RS232 level shifters. So a TTL-USB UART adapter does not work in
+this case. The signals need to get connected directly to the
+RS232 level signals of the PC UART via some adapter cable.
-- 
2.9.3

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

Re: [U-Boot] [PATCH] arch: ifc: update the IFC IP input clock

[Scott Wood]

On 09/08/2016 08:46 PM, Prabhakar Kushwaha wrote:
> 
>> -Original Message-
>> From: Scott Wood
>> Sent: Friday, September 09, 2016 6:05 AM
>> To: Prabhakar Kushwaha ; york sun
>> ; u-boot@lists.denx.de
>> Subject: Re: [PATCH] arch: ifc: update the IFC IP input clock
>>
>> On 09/08/2016 07:05 PM, Prabhakar Kushwaha wrote:
>>>
 -Original Message-
 From: york sun
 Sent: Thursday, September 08, 2016 9:22 PM
 To: Prabhakar Kushwaha ; u-
 b...@lists.denx.de; Scott Wood 
 Subject: Re: [PATCH] arch: ifc: update the IFC IP input clock

 On 09/08/2016 02:33 AM, Prabhakar Kushwaha wrote:

 

>>> So better to print IP clock to avoid any confusion.
>>> IFC output clock will be printed when it is actually being used during
>> synchronous NOR, syn NAND.
>>
>> I am not against changing it to internal clock. But what are you going
>> to print on the console? I think it is confusing to say IFC or local bus
>> internal clock speed. Please also check how this clock is used and make
>> sure arch.lbc_clk is still correct, after passing to Linux.
>>
> arch.lbc_clk is only being used for eLBC for device tree fixup.
> And I checked the Linux eLBC driver. Looks like it is not using used.
>

 If this clock is not used, can we drop it completely?

>>>
>>> From my point of view Yes.
>>>
>>> Scott, Please advice
>>
>> Well, there is that patch from Matt Weber that is trying to guess the
>> IFC frequency in order to use NWAIT...  Not sure if we'll end up
>> actually using NWAIT 
> (Prabhakar, can you answer my question of whether
>> there is a better opcode to use with RNDOUT?) or ever sending a real
>> RNDOUT, or if we'll ever care about these newer NAND chips on eLBC, but
>> if U-Boot is currently writing the clock frequency into the device tree
>> I don't see why we'd rip it out.
>>
> 
> IFC frequency means IP clock or IP output clock?

External bus clock.  Which is currently being written to the device tree?

> If IP clock then other patch for eLBC still valid.  

What other patch?

> 
> For IFC: Code needs to be added for device tree fixup for PowerPC, ARM SoC. 
> It is missing for now :(

No, we don't want to introduce new clock-frequency fixups.  If we need
this on IFC we should add a clocks property.  But if we already have
clock-frequency on eLBC then no reason not to use that if needed.

-Scott

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

Re: [U-Boot] [PATCH 2/2] configs: Migrate CONFIG_USB_STORAGE

[Masahiro Yamada]

2016-09-09 10:19 GMT+09:00 Tom Rini :
> In some cases we were missing CONFIG_USB=y so enable that when needed.
>
> Signed-off-by: Tom Rini 
> ---
> The only change here is that due to how we deal with cmd/disk.c today
> we once again link this file in and get the strings on am43xx_evm* in
> SPL.  This will be fixed in another patch.


Reviewed-by: Masahiro Yamada 


BTW,

$ git grep CONFIG_USB=y configs/*_defconfig | wc
669 669   30938
$ git grep CONFIG_USB_STORAGE=y configs/*_defconfig | wc
650 650   35349


With this series, we will have 669 boards with CONFIG_USB.
Of the 669 boards, 650 boards define CONFIG_USB_STORAGE.

Perhaps, "default y" might be suitable for USB_STORAGE, but
we can flip the default later if we find it useful.

Anyway, let's move forward the Kconfig migration for now.
If we have all the defines in defconfigs,
we can reconsider the default and dependency any time later.


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

Re: [U-Boot] [PATCH v1 2/2] clk: at91: Add .ops callback for clk_generic

[Wenyou.Yang]

Hi Stephen,

> -Original Message-
> From: Stephen Warren [mailto:swar...@wwwdotorg.org]
> Sent: 2016年9月3日 1:38
> To: Wenyou Yang - A41535 
> Cc: swar...@nvidia.com; u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH v1 2/2] clk: at91: Add .ops callback for 
> clk_generic
> 
> On 09/01/2016 07:46 PM, wenyou.y...@microchip.com wrote:
> > Hi Stephen,
> >
> >>> Subject: [PATCH v1 2/2] clk: at91: Add .ops callback for clk_generic
> >>>
> >>> To avoid the wild pointer as NULL->of_xlate, add an empty .ops
> >>> callback for the clk_generic driver.
> >>
> >> This shouldn't be needed. If this driver isn't a clock provider, and
> >> it cannot be a clock provider without implementing and clock ops,
> >> then nothing should be calling of_xlate through its ops pointer, and the 
> >> driver
> shouldn't be a UCLASS_CLK.
> >
> > The Atmel clock tree structure has some difference, take the following spi0
> node as an example.
> > The 'spi0' node use the 'clocks' phandle to refer to the 'spi0_clk' node to 
> > enable
> its clock.
> >
> > The 'spi0_clk' doesn't provide .ops->enable(), only its peripheral ID via 
> > 'reg'
> property.
> > It uses its parent node (i.e. periph32ck) .ops->enable(), shared with other 
> > sibling
> nodes.
> >
> > These nodes as 'spi0_clk' don't have .compatible, which is bound with the
> 'clk_generic' driver.
> > If not provide .ops for the 'clk_generic' driver, it will produce the
> > wild pointer as NULL->of_xlate when call clk_get_by_index() in the spi 
> > driver.
> 
> The way clocks are looked in in DT currently requires that:
> 
> 1) The phandle in the clocks property is parsed. That is the node ID of 
> _clk
> is found.
> 
> 2) All devices of UCLASS_CLK are search to find the device with .of_offset 
> that
> matches the phandle parsed in (1) above.
> 
> 3) That device's driver's uclass ops of_xlate is called to translate the rest 
> of the
> client node's clock specifier (in your case, there are 0 cells, so no data is
> extracted, but the U-Boot core clock node doesn't know that, since this is 
> binding-
> specific).
> 
> Thus, there /must/ be a struct udevice for the spi0_clk node, and it must 
> have an
> ops pointer, and either a working of_xlate pointer or NULL to use the default 
> xlate
> function.
> 
> This is all simply how the code works; your driver must fit into this 
> mechanism.
> 
> Now, the one way your driver would be able to defer all clock operations to 
> the
> driver for the periph32ck node is if the of_xlate for the spi0_clk node were 
> to edit
> the struct clk's .dev field to point it back at the driver for the periph32ck 
> node, and
> set a value in struct clk's .id field that is hard-coded rather than derived 
> from the
> client's DT clock specifier. However, I know you aren't using that technique, 
> since
> your patch relies on the default of_xlate function for the spi0_clk node 
> (since you
> provide an ops pointer, but don't fill in any of the function pointers within 
> it, and
> hence the of_xlate pointer defaults to NULL, and hence clk_get_by_index() uses
> clk_of_xlate_default().
> 
> So here's how you need to make it work:
> 
> 1)
> 
> A driver should exist for the periph32ck node. This driver's uclass is likely 
> *not*
> UCLASS_CLK since it doesn't provide any clocks; there is no #clock-cells
> property in ths node in DT.
> 
> This driver needs to somehow create a device for each child node, so that the
> clock core can find those devices.
> 
> 2)
> 
> The device for the spi0_clk node needs to be UCLASS_CLK, needs to provide an
> ops pointer, and can either use the default of_xlate or provide a custom one 
> if
> needed. request and free ops are also required.
> 
> In particular, the ops pointer for this device *must* provide some other 
> clock ops
> so that clients can do something useful with the clock. At least one of 
> enable,
> disable, get_rate, set_rate are required.
> 
> Now, the *implementation* of this driver can call functions in the parent 
> driver if
> you need, so that all the code is in one place. There's nothing preventing 
> that.

Thank you very much for your direction.


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

Re: [U-Boot] [PATCH v7 01/12] clk: Use dummy clk_get_by_* functions when CONFIG_CLK is disabled

[Masahiro Yamada]

2016-09-08 15:47 GMT+09:00 Paul Burton :
> The implementations of clk_get_by_index & clk_get_by_name are only
> available when CONFIG_CLK is enabled.

Unless I am missing something,
I think this statement also applies to other clk API functions
such as clk_request(), clk_free(), clk_get_rate(), etc.


> Provide the dummies when this is
> not the case in order to avoid build failures.

Why are other functions OK without dummy stubs?




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

[U-Boot] [PATCH v3 7/7] configs: Adds a defconfig for K2E High Security EVM

[Srinivas, Madan]

Add a new defconfig file for the K2E High Security EVM.

This defconfig is the same as for the non-secure part, except for:
CONFIG_TI_SECURE_DEVICE option set to 'y'
CONFIG_FIT option set to 'y'
CONFIG_FIT_IMAGE_POST_PROCESS option set to 'y'

Enables the platform-specific post-processing of FIT-extracted blobs such
as Kernel, DTB, and initramfs on TI K2E high-security (HS) devices
which will ultimately invokes TI proprietary secure functions
that performs secure processing such as blob authentication and
decryption.

Signed-off-by: Vitaly Andrianov 
Signed-off-by: Madan Srinivas 
Reviewed-by: Tom Rini 

---

Changes in v3: None
Changes in v2:
- Updates k2e_hs_evm_defconfig to reduce the delta seen if one
  regenerates it using savedefconfig or similar tools.

 configs/k2e_hs_evm_defconfig | 43 
+++

 1 file changed, 43 insertions(+)
 create mode 100644 configs/k2e_hs_evm_defconfig

diff --git a/configs/k2e_hs_evm_defconfig b/configs/k2e_hs_evm_defconfig
new file mode 100644
index 000..fc8f22a
--- /dev/null
+++ b/configs/k2e_hs_evm_defconfig
@@ -0,0 +1,43 @@
+CONFIG_ARM=y
+CONFIG_ARCH_KEYSTONE=y
+CONFIG_TARGET_K2E_EVM=y
+CONFIG_TI_SECURE_DEVICE=y
+CONFIG_DM_SERIAL=y
+CONFIG_DEFAULT_DEVICE_TREE="k2e-evm"
+CONFIG_SPL=y
+CONFIG_FIT=y
+CONFIG_OF_BOARD_SETUP=y
+CONFIG_FIT_IMAGE_POST_PROCESS=y
+CONFIG_HUSH_PARSER=y
+CONFIG_SYS_PROMPT="K2E EVM # "
+CONFIG_CMD_BOOTZ=y
+# CONFIG_CMD_IMLS is not set
+CONFIG_CMD_ASKENV=y
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_NAND=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_SPI=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_USB=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_EXT2=y
+CONFIG_CMD_EXT4=y
+CONFIG_CMD_EXT4_WRITE=y
+CONFIG_CMD_FAT=y
+CONFIG_CMD_FS_GENERIC=y
+CONFIG_OF_CONTROL=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_DM=y
+CONFIG_TI_AEMIF=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_DM_ETH=y
+CONFIG_SYS_NS16550=y
+CONFIG_DM_SPI=y
+CONFIG_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
--
2.7.4

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

[U-Boot] [PATCH v3 6/7] doc: Updates info on using keystone secure devices, from TI

[Srinivas, Madan]

Add a section describing the secure boot image used on
keystone secure devices.

This patch applies on top of the patch
doc: Update info on using AM33xx secure devices from TI
submitted by Andrew Davis

Signed-off-by: Madan Srinivas 
Reviewed-by: Tom Rini 

---

Changes in v3: None
Changes in v2:
- Updates the secure keystone image name to u-boot_HS_MLO
  in README.ti-secure to match with the changes made to
  config.mk in this series version.

 doc/README.ti-secure | 20 
 1 file changed, 20 insertions(+)

diff --git a/doc/README.ti-secure b/doc/README.ti-secure
index 9b0fbf9..84c7206 100644
--- a/doc/README.ti-secure
+++ b/doc/README.ti-secure
@@ -133,6 +133,26 @@ Booting of U-Boot SPL
u-boot-spl_HS_X-LOADER - boot image for all other flash memories
including QSPI and NOR flash

+Invoking the script for Keystone Secure Devices
+=
+
+create-boot-image.sh \
+   
+
+ is currently ignored and reserved for future use.
+
+ is the full path and filename of the public world boot
+loader binary file (only u-boot.bin is currently supported on
+   keystone devices, u-boot-spl.bin is not currently supported).
+
+ is the full path and filename of the final secure
+image. The output binary images should be used in place of the 
standard
+non-secure binary images (see the platform-specific user's 
guides and

+releases notes for how the non-secure images are typically used)
+u-boot_HS_MLO - signed and encrypted boot image that can
+   be used to boot from all media. Secure boot from SPI NOR
+   flash is not currently supported.
+
 Booting of Primary U-Boot (u-boot.img)
 ==

--
2.7.4

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

[U-Boot] [PATCH v3 5/7] arm: mach-keystone: config.mk: Adds support for secure, images on K2

[Srinivas, Madan]

Adds an additional image type needed for supporting secure keystone
devices. The build generates u-boot_HS_MLO which can be used to boot
from all media on secure keystone devices.

Signed-off-by: Madan Srinivas 

Cc: Andrew F. Davis 
---

Changes in v3:
- Corrects commit message in patch 5/7 in this series to refer
  to u-boot_HS_MLO

Changes in v2:
- Changes the target for secure keystone devices in config.mk
  to u-boot_HS_MLO to keep it in line with the MLO target that
  is built for non-secure keystone devices.

 arch/arm/mach-keystone/config.mk | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/mach-keystone/config.mk 
b/arch/arm/mach-keystone/config.mk

index 9ae1e9a..32fef42 100644
--- a/arch/arm/mach-keystone/config.mk
+++ b/arch/arm/mach-keystone/config.mk
@@ -5,9 +5,15 @@
 # SPDX-License-Identifier: GPL-2.0+
 #

+include  $(srctree)/$(CPUDIR)/omap-common/config_secure.mk
+
 ifndef CONFIG_SPL_BUILD
+ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
+ALL-y += u-boot_HS_MLO
+else
 ALL-y += MLO
 endif
+endif

 MKIMAGEFLAGS_u-boot-spl.gph = -A $(ARCH) -T gpimage -C none \
-a $(CONFIG_SPL_TEXT_BASE) -e $(CONFIG_SPL_TEXT_BASE) -n SPL
--
2.7.4

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

[U-Boot] [PATCH v3 4/7] arm: omap-common: Enable support for K2 HS devices in, u-boot

[Srinivas, Madan]

Like the OMAP54xx, AM43xx & AM33xx family SoCs, the keystone family
of SoCs also have high security enabled models. Allow K2E devices to
be built with HS Device Type Support.

This patch applies on top of the patch
ti: omap-common: Allow AM33xx devices to be built securely
submitted by Andrew Davis

Signed-off-by: Vitaly Andrianov 
Signed-off-by: Madan Srinivas 
Acked-by: Andrew F. Davis 
Reviewed-by: Tom Rini 
---

Changes in v3: None
Changes in v2: None

 arch/arm/cpu/armv7/omap-common/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv7/omap-common/Kconfig 
b/arch/arm/cpu/armv7/omap-common/Kconfig

index 4daccd9..91d6b2c 100644
--- a/arch/arm/cpu/armv7/omap-common/Kconfig
+++ b/arch/arm/cpu/armv7/omap-common/Kconfig
@@ -1,6 +1,6 @@
 config TI_SECURE_DEVICE
bool "HS Device Type Support"
-   depends on OMAP54XX || AM43XX || AM33XX
+   depends on OMAP54XX || AM43XX || AM33XX || ARCH_KEYSTONE
help
  If a high secure (HS) device type is being used, this config
  must be set. This option impacts various aspects of the
--
2.7.4

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

[U-Boot] [PATCH v3 3/7] arm: omap-common: adds secure image name common to, OMAP and keystone

[Srinivas, Madan]

As K2 can directly boot u-boot, add u-boot_HS_MLO as the
secure image while booting secure K2 devicesr, for all
boot modes other than SPI flash.

Signed-off-by: Madan Srinivas 
Reviewed-by: Tom Rini 

---

Changes in v3: None
Changes in v2:
- Adds a new name for the signed output image in config_secure.mk
  to keep it in line with the image name used by non-secure keystone
  devices.

 arch/arm/cpu/armv7/omap-common/config_secure.mk | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/cpu/armv7/omap-common/config_secure.mk 
b/arch/arm/cpu/armv7/omap-common/config_secure.mk

index 1122439..0ece3f8 100644
--- a/arch/arm/cpu/armv7/omap-common/config_secure.mk
+++ b/arch/arm/cpu/armv7/omap-common/config_secure.mk
@@ -76,6 +76,12 @@ u-boot-spl_HS_ISSW: $(obj)/u-boot-spl.bin
 u-boot-spl_HS_SPI_X-LOADER: $(obj)/u-boot-spl.bin
$(call if_changed,mkomapsecimg)

+# For supporting single stage boot on keystone, the image is a full u-boot
+# file, not an SPL. This will work for all boot devices, other than SPI
+# flash
+u-boot_HS_MLO: $(obj)/u-boot.bin
+   $(call if_changed,mkomapsecimg)
+
 # For supporting single stage XiP QSPI on AM43xx, the image is a full 
u-boot

 # file, not an SPL. In this case the mkomapsecimg command looks for a
 # u-boot-HS_* prefix
--
2.7.4

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

[U-Boot] [PATCH RESEND v3 2/7] arm: mach-keystone: Implements FIT post-processing, call for keystone SoCs

[Srinivas, Madan]

This commit implements the board_fit_image_post_process() function for
the keystone architecture. Unlike OMAP class devices, security
functions in keystone are not handled in the ROM.
The interface to the secure functions is TI proprietary and depending
on the keystone platform, the security functions like encryption,
decryption and authentication might even be offloaded to other secure
processing elements in the SoC.
The boot monitor acts as the gateway to these secure functions and the
boot monitor for secure devices is available as part of the SECDEV
package for KS2. For more details refer doc/README.ti-secure

Signed-off-by: Vitaly Andrianov 
Signed-off-by: Madan Srinivas 

Cc: Lokesh Vutla 
Cc: Dan Murphy 
---

Changes in v3: None
Changes in v2:
- The following changes are  made to mon.c based on review comments
Adds NULL pointer check before calling authentication interface
Removes an unnecessary printf
Updates size of signed FIT blob after post processing removes header

 arch/arm/mach-keystone/mon.c | 55

 1 file changed, 55 insertions(+)

diff --git a/arch/arm/mach-keystone/mon.c b/arch/arm/mach-keystone/mon.c
index 256f630..a952ed2 100644
--- a/arch/arm/mach-keystone/mon.c
+++ b/arch/arm/mach-keystone/mon.c
@@ -12,10 +12,31 @@
 #include 
 asm(".arch_extension sec\n\t");

+#ifdef CONFIG_TI_SECURE_DEVICE
+#define KS2_HS_AUTH_FN_OFFSET  8
+#define KS2_HS_SEC_HEADER_LEN  0x60
+#define KS2_AUTH_CMD   "2"
+/**
+ * (*fn_auth)() - Invokes security functions using a
+ * proprietary TI interface. This binary and source for
+ * this is available in the secure development package or
+ * SECDEV. For details on how to access this please refer
+ * doc/README.ti-secure
+ *
+ * @first param:   no. of parameters
+ * @second param:  parameter list
+ * @return non-zero value on success, zero on error
+ */
+static unsigned int (*fn_auth)(int, char * const []);
+#endif
+
 int mon_install(u32 addr, u32 dpsc, u32 freq)
 {
int result;

+#ifdef CONFIG_TI_SECURE_DEVICE
+   fn_auth = (void *)(addr + KS2_HS_AUTH_FN_OFFSET);
+#endif
__asm__ __volatile__ (
"stmfd r13!, {lr}\n"
"mov r0, %1\n"
@@ -61,3 +82,37 @@ int mon_power_off(int core_id)
: "cc", "r0", "r1", "memory");
return  result;
 }
+
+#ifdef CONFIG_TI_SECURE_DEVICE
+static void k2_hs_auth(void *addr)
+{
+   char *argv1 = KS2_AUTH_CMD;
+   char argv2[32];
+   char *argv[3] = {NULL, argv1, argv2};
+   int ret = 0;
+
+   sprintf(argv2, "0x%08x", (u32)addr);
+
+   if (fn_auth)
+   ret = fn_auth(3, argv);
+
+   if (ret == 0)
+   hang();
+}
+
+void board_fit_image_post_process(void **p_image, size_t *p_size)
+{
+   void *dst = *p_image;
+   void *src = dst + KS2_HS_SEC_HEADER_LEN;
+
+   k2_hs_auth(*p_image);
+
+   /*
+   * Overwrite the image headers  after authentication
+   * and decryption. Update size to relect removal
+   * of header.
+   */
+   *p_size -= KS2_HS_SEC_HEADER_LEN;
+   memcpy(dst, src, *p_size);
+}
+#endif
--
2.7.4



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

Re: [U-Boot] [PATCH 2/3] rockchip: add usb mass storage feature support for rk3036

[陈豪]

Hi,


2016-09-06 9:03 GMT+08:00 Simon Glass :
> On 29 August 2016 at 11:26, Jacob Chen  wrote:
>> From: "jacob2.chen" 
>>
>> Enable ums feature for rk3036 boards, so that we can mount the mmc
>> device to PC.
>>
>> Signed-off-by: jacob2.chen 
>> ---
>>
>>  include/configs/rk3036_common.h | 4 
>>  1 file changed, 4 insertions(+)
>
> Acked-by: Simon Glass 

This patch has no relations with other patchs.
Can we merge it alone?


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

[U-Boot] [PATCH v3 1/7] include: image.h: Fixes build warning with, CONFIG_FIT_IMAGE_POST_PROCESS

[Srinivas, Madan]

The function board_fit_image_post_process is defined only when the config
CONFIG_FIT_IMAGE_POST_PROCESS is enabled. For secure systems that do not
use SPL but use FIT kernel images, only CONFIG_FIT_IMAGE_POST_PROCESS will
be defined, which will result in an implicit declaration of function
'board_fit_image_post_process' warning while building u-boot. This
patch fixes this warning.

Signed-off-by: Madan Srinivas 
Acked-by: Andrew F. Davis 
Reviewed-by: Tom Rini 

---

Changes in v3: None
Changes in v2:
- Corrects typo in commit message for PATCH 1/7 in this series

 include/image.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/image.h b/include/image.h
index 64da722..6884421 100644
--- a/include/image.h
+++ b/include/image.h
@@ -1245,7 +1245,8 @@ void android_print_contents(const struct 
andr_img_hdr *hdr);

  */
 int board_fit_config_name_match(const char *name);

-#ifdef CONFIG_SPL_FIT_IMAGE_POST_PROCESS
+#if defined(CONFIG_SPL_FIT_IMAGE_POST_PROCESS) || \
+   defined(CONFIG_FIT_IMAGE_POST_PROCESS)
 /**
  * board_fit_image_post_process() - Do any post-process on FIT binary data
  *
--
2.7.4

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

[U-Boot] [PATCH v3 0/7] Adds support for secure boot on Keystone SoCs (K2E)

[Srinivas, Madan]

This series adds support for secure keystone family of devices, more
specifically for K2E (Edison).This work is similar to what has already
been done for the AM43xx and AM57xx SoCs and leverages much of the
infrastructure from them.

The big difference here is the ROM on keystone2 devices does not provide
any APIs for image authentication. Rather, the image authentication and
decryption routines and other security functions are provided by
software and can run on the ARM in Trustzone as well as on secure DSPs.

A component known as the boot monitor acts as they gateway to this secure
processing, and abstracts out the details from the public world. Unlike
OMAP class devices, where u-boot calls ROM APIs, u-boot calls into the boot-
monitor on keystone devices.

Other than this difference, most of the secure framework for AMxx and
DRAxx devices have been re-used.

Couple of other points to note :-

-Support for SPL on secure keystone devices is still TBD,
so boot from SPI flash, which needs SPL, is not supported currently
on K2 devices.

-A single image will work across all other boot media for secure K2
devices.

Changes in v3:
- Corrects commit message in patch 5/7 in this series to refer
  to u-boot_HS_MLO

Changes in v2:
- Corrects typo in commit message for PATCH 1/7 in this series
- The following changes are  made to mon.c based on review comments
Adds NULL pointer check before calling authentication interface
Removes an unnecessary printf
Updates size of signed FIT blob after post processing removes header
- Adds a new name for the signed output image in config_secure.mk
  to keep it in line with the image name used by non-secure keystone
  devices.
- Changes the target for secure keystone devices in config.mk
  to u-boot_HS_MLO to keep it in line with the MLO target that
  is built for non-secure keystone devices.
- Updates the secure keystone image name to u-boot_HS_MLO
  in README.ti-secure to match with the changes made to
  config.mk in this series version.
- Updates k2e_hs_evm_defconfig to reduce the delta seen if one
  regenerates it using savedefconfig or similar tools.

Madan Srinivas (4):
  include: image.h: Fixes build warning with
CONFIG_FIT_IMAGE_POST_PROCESS
  arm: omap-common: adds secure image name common to OMAP and keystone
  arm: mach-keystone: config.mk: Adds support for secure images on K2
  doc: Updates info on using keystone secure devices from TI

Vitaly Andrianov (3):
  arm: mach-keystone: Implements FIT post-processing call for keystone
SoCs
  arm: omap-common: Enable support for K2 HS devices in u-boot
  configs: Adds a defconfig for K2E High Security EVM

 arch/arm/cpu/armv7/omap-common/Kconfig  |  2 +-
 arch/arm/cpu/armv7/omap-common/config_secure.mk |  6 +++
 arch/arm/mach-keystone/config.mk|  6 +++
 arch/arm/mach-keystone/mon.c| 55 
+

 configs/k2e_hs_evm_defconfig| 43 +++
 doc/README.ti-secure| 20 +
 include/image.h |  3 +-
 7 files changed, 133 insertions(+), 2 deletions(-)
 create mode 100644 configs/k2e_hs_evm_defconfig

--
2.7.4

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

Re: [U-Boot] [PATCH] arch: ifc: update the IFC IP input clock

[Prabhakar Kushwaha]

> -Original Message-
> From: Scott Wood
> Sent: Friday, September 09, 2016 6:05 AM
> To: Prabhakar Kushwaha ; york sun
> ; u-boot@lists.denx.de
> Subject: Re: [PATCH] arch: ifc: update the IFC IP input clock
> 
> On 09/08/2016 07:05 PM, Prabhakar Kushwaha wrote:
> >
> >> -Original Message-
> >> From: york sun
> >> Sent: Thursday, September 08, 2016 9:22 PM
> >> To: Prabhakar Kushwaha ; u-
> >> b...@lists.denx.de; Scott Wood 
> >> Subject: Re: [PATCH] arch: ifc: update the IFC IP input clock
> >>
> >> On 09/08/2016 02:33 AM, Prabhakar Kushwaha wrote:
> >>
> >> 
> >>
> > So better to print IP clock to avoid any confusion.
> > IFC output clock will be printed when it is actually being used during
>  synchronous NOR, syn NAND.
> 
>  I am not against changing it to internal clock. But what are you going
>  to print on the console? I think it is confusing to say IFC or local bus
>  internal clock speed. Please also check how this clock is used and make
>  sure arch.lbc_clk is still correct, after passing to Linux.
> 
> >>> arch.lbc_clk is only being used for eLBC for device tree fixup.
> >>> And I checked the Linux eLBC driver. Looks like it is not using used.
> >>>
> >>
> >> If this clock is not used, can we drop it completely?
> >>
> >
> > From my point of view Yes.
> >
> > Scott, Please advice
> 
> Well, there is that patch from Matt Weber that is trying to guess the
> IFC frequency in order to use NWAIT...  Not sure if we'll end up
> actually using NWAIT 
(Prabhakar, can you answer my question of whether
> there is a better opcode to use with RNDOUT?) or ever sending a real
> RNDOUT, or if we'll ever care about these newer NAND chips on eLBC, but
> if U-Boot is currently writing the clock frequency into the device tree
> I don't see why we'd rip it out.
> 

IFC frequency means IP clock or IP output clock?

If IP clock then other patch for eLBC still valid.  
If there is possibility of this frequency may require for future flash. I agree 
we should keep device tree fix-up code for eLBC. 

For IFC: Code needs to be added for device tree fixup for PowerPC, ARM SoC. 
It is missing for now :(

Regarding RDNOUT, let me check and come back on the mail thread.

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

[U-Boot] [PATCH v2 7/7] config: evb-rk3399: enable pwm regulator

[Kever Yang]

Enable the pwm regulator for evb-rk3399.

Signed-off-by: Kever Yang 
Acked-by: Simon Glass 
---

Changes in v2: None

 configs/evb-rk3399_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/evb-rk3399_defconfig b/configs/evb-rk3399_defconfig
index 1e7575d..6468620 100644
--- a/configs/evb-rk3399_defconfig
+++ b/configs/evb-rk3399_defconfig
@@ -29,6 +29,7 @@ CONFIG_PINCTRL=y
 CONFIG_ROCKCHIP_RK3399_PINCTRL=y
 CONFIG_DM_PWM=y
 CONFIG_PWM_ROCKCHIP=y
+CONFIG_REGULATOR_PWM=y
 CONFIG_RAM=y
 CONFIG_SYS_NS16550=y
 CONFIG_DEBUG_UART=y
-- 
1.9.1

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

[U-Boot] [PATCH v2 6/7] dts: evb-rk3399: add init voltage node for vdd-center

[Kever Yang]

Add a regulator-init-microvolt for vdd_center regulator
so that we can get a init value for driver probe.
Not like pmic regulator, the PWM regulator do not have a
known default output value, so we would like to init the
regulator when driver probe.

Signed-off-by: Kever Yang 
---

Changes in v2:
- update the commit message

 arch/arm/dts/rk3399-evb.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/dts/rk3399-evb.dts b/arch/arm/dts/rk3399-evb.dts
index bd7801b..fa60e19 100644
--- a/arch/arm/dts/rk3399-evb.dts
+++ b/arch/arm/dts/rk3399-evb.dts
@@ -23,6 +23,7 @@
regulator-name = "vdd_center";
regulator-min-microvolt = <80>;
regulator-max-microvolt = <140>;
+   regulator-init-microvolt = <95>;
regulator-always-on;
regulator-boot-on;
status = "okay";
-- 
1.9.1

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

[U-Boot] [PATCH v2 5/7] Kconfig: rockchip: enable DM_PWM and DM_REGULATOR

[Kever Yang]

Enable DM_PWM and DM_REGULATOR on rockchip SoCs.

Signed-off-by: Kever Yang 
Acked-by: Simon Glass 
---

Changes in v2: None

 arch/arm/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 4928206..c877f5d 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -863,6 +863,8 @@ config ARCH_ROCKCHIP
select DM_SPI
select DM_SPI_FLASH
select DM_USB if USB
+   select DM_PWM
+   select DM_REGULATOR
 
 config TARGET_THUNDERX_88XX
bool "Support ThunderX 88xx"
-- 
1.9.1

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

[U-Boot] [PATCH v2 4/7] rockchip: evb_rk3399: init vdd_center regulator

[Kever Yang]

Add vdd_center pwm regulator get_device to
enable this regulator.

Signed-off-by: Kever Yang 
Acked-by: Simon Glass 
---

Changes in v2:
- add Acked-by tag from Simon and commit message fix

 board/rockchip/evb_rk3399/evb-rk3399.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/board/rockchip/evb_rk3399/evb-rk3399.c 
b/board/rockchip/evb_rk3399/evb-rk3399.c
index f595a54..5e6ce7c 100644
--- a/board/rockchip/evb_rk3399/evb-rk3399.c
+++ b/board/rockchip/evb_rk3399/evb-rk3399.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -41,6 +42,11 @@ int board_init(void)
goto out;
}
 
+   /* rk3399 need init vdd_center to get correct output voltage */
+   ret = regulator_get_by_platname("vdd_center", );
+   if (ret)
+   debug("%s: Cannot get vdd_center regulator\n", __func__);
+
ret = regulator_get_by_platname("vcc5v0_host", );
if (ret) {
debug("%s vcc5v0_host init fail! ret %d\n", __func__, ret);
-- 
1.9.1

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

[U-Boot] [PATCH v2 3/7] power: regulator: add pwm regulator

[Kever Yang]

add driver support for pwm regulator.

Signed-off-by: Elaine Zhang 
Signed-off-by: Kever Yang 
---

Changes in v2:
- add comments for pwm_regulator_info struct member
- do not init pwm_id if there is none
- other fix for comments from Simon

 drivers/power/regulator/Kconfig |  10 ++
 drivers/power/regulator/Makefile|   1 +
 drivers/power/regulator/pwm_regulator.c | 160 
 3 files changed, 171 insertions(+)
 create mode 100644 drivers/power/regulator/pwm_regulator.c

diff --git a/drivers/power/regulator/Kconfig b/drivers/power/regulator/Kconfig
index 17f22dd..c7e88c0 100644
--- a/drivers/power/regulator/Kconfig
+++ b/drivers/power/regulator/Kconfig
@@ -42,6 +42,16 @@ config DM_REGULATOR_PFUZE100
features for REGULATOR PFUZE100. The driver implements get/set api for:
value, enable and mode.
 
+config REGULATOR_PWM
+   bool "Enable driver for PWM regulators"
+   depends on DM_REGULATOR
+   ---help---
+   Enable support for the PWM regulator functions which voltage are
+   controlled by PWM duty ratio. Some of Rockchip board using this kind
+   of regulator. The driver implements get/set api for the various BUCKS.
+   This driver is controlled by a device tree node
+   which includes voltage limits.
+
 config DM_REGULATOR_MAX77686
bool "Enable Driver Model for REGULATOR MAX77686"
depends on DM_REGULATOR && DM_PMIC_MAX77686
diff --git a/drivers/power/regulator/Makefile b/drivers/power/regulator/Makefile
index 1590d85..ab461ec 100644
--- a/drivers/power/regulator/Makefile
+++ b/drivers/power/regulator/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_$(SPL_)DM_REGULATOR) += regulator-uclass.o
 obj-$(CONFIG_REGULATOR_ACT8846) += act8846.o
 obj-$(CONFIG_DM_REGULATOR_MAX77686) += max77686.o
 obj-$(CONFIG_DM_REGULATOR_PFUZE100) += pfuze100.o
+obj-$(CONFIG_REGULATOR_PWM) += pwm_regulator.o
 obj-$(CONFIG_$(SPL_)DM_REGULATOR_FIXED) += fixed.o
 obj-$(CONFIG_REGULATOR_RK808) += rk808.o
 obj-$(CONFIG_REGULATOR_S5M8767) += s5m8767.o
diff --git a/drivers/power/regulator/pwm_regulator.c 
b/drivers/power/regulator/pwm_regulator.c
new file mode 100644
index 000..abecb5f
--- /dev/null
+++ b/drivers/power/regulator/pwm_regulator.c
@@ -0,0 +1,160 @@
+/*
+ * Copyright (C) 2016 Rockchip Electronics Co., Ltd
+ *
+ * Based on kernel drivers/regulator/pwm-regulator.c
+ * Copyright (C) 2014 - STMicroelectronics Inc.
+ * Author: Lee Jones 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct pwm_regulator_info {
+   /* pwm id corresponding to the PWM driver */
+   int pwm_id;
+   /* the period of one PWM cycle */
+   int period_ns;
+   struct udevice *pwm;
+   /* initialize voltage of regulator */
+   unsigned int init_voltage;
+   /* the maximum voltage of regulator */
+   unsigned int max_voltage;
+   /* the minimum voltage of regulator */
+   unsigned int min_voltage;
+   /* the current voltage of regulator */
+   unsigned int volt_uV;
+};
+
+static int pwm_regulator_enable(struct udevice *dev, bool enable)
+{
+   struct pwm_regulator_info *priv = dev_get_priv(dev);
+
+   return pwm_set_enable(priv->pwm, priv->pwm_id, enable);
+}
+
+static int pwm_voltage_to_duty_cycle_percentage(struct udevice *dev, int 
req_uV)
+{
+   struct pwm_regulator_info *priv = dev_get_priv(dev);
+   int min_uV = priv->min_voltage;
+   int max_uV = priv->max_voltage;
+   int diff = max_uV - min_uV;
+
+   return 100 - (((req_uV * 100) - (min_uV * 100)) / diff);
+}
+
+static int pwm_regulator_get_voltage(struct udevice *dev)
+{
+   struct pwm_regulator_info *priv = dev_get_priv(dev);
+
+   return priv->volt_uV;
+}
+
+static int pwm_regulator_set_voltage(struct udevice *dev, int uvolt)
+{
+   struct pwm_regulator_info *priv = dev_get_priv(dev);
+   int duty_cycle;
+   int ret = 0;
+
+   duty_cycle = pwm_voltage_to_duty_cycle_percentage(dev, uvolt);
+
+   ret = pwm_set_config(priv->pwm, priv->pwm_id,
+   (priv->period_ns / 100) * duty_cycle, priv->period_ns);
+   if (ret) {
+   dev_err(dev, "Failed to configure PWM\n");
+   return ret;
+   }
+
+   ret = pwm_set_enable(priv->pwm, priv->pwm_id, true);
+   if (ret) {
+   dev_err(dev, "Failed to enable PWM\n");
+   return ret;
+   }
+   priv->volt_uV = uvolt;
+   return ret;
+}
+
+static int pwm_regulator_ofdata_to_platdata(struct udevice *dev)
+{
+   struct pwm_regulator_info *priv = dev_get_priv(dev);
+   struct fdtdec_phandle_args args;
+   const void *blob = gd->fdt_blob;
+   int node = dev->of_offset;
+   int ret;
+
+   ret = fdtdec_parse_phandle_with_args(blob, node, "pwms", "#pwm-cells",

[U-Boot] [PATCH v2 2/7] rockchip: rkpwm: fix the register sequence

[Kever Yang]

Reference to kernel source code, rockchip pwm has three
type, we are using v2 for rk3288 and rk3399, so let's
update the register to sync with pwm_data_v2 in kernel.

Signed-off-by: Kever Yang 
Acked-by: Simon Glass 
---

Changes in v2: None

 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 08ff945..5d9a178 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 period_hpr;
u32 duty_lpr;
+   u32 period_hpr;
u32 ctrl;
 };
 check_member(rk3288_pwm, ctrl, 0xc);
-- 
1.9.1

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

[U-Boot] [PATCH v2 1/7] rockchip: rk3399: update PPLL and pmu_pclk frequency

[Kever Yang]

Update PPLL to 676MHz and PMU_PCLK to 48MHz, because:
1. 48MHz can make sure the pwm can get exact 50% duty ratio, but 99MHz
can not,
2. We think 48MHz is fast enough for pmu pclk and it is lower power cost
than 99MHz,
3. PPLL 676 MHz and PMU_PCLK 48MHz are the clock rate we are using
internally for kernel,it suppose not to change the bus clock like pmu_pclk
in kernel, so we want to change it in uboot.

Signed-off-by: Kever Yang 
---

Changes in v2: None

 arch/arm/include/asm/arch-rockchip/cru_rk3399.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/arch-rockchip/cru_rk3399.h 
b/arch/arm/include/asm/arch-rockchip/cru_rk3399.h
index c919f47..6776e48 100644
--- a/arch/arm/include/asm/arch-rockchip/cru_rk3399.h
+++ b/arch/arm/include/asm/arch-rockchip/cru_rk3399.h
@@ -64,9 +64,9 @@ check_member(rk3399_cru, sdio1_con[1], 0x594);
 #define APLL_HZ(600*MHz)
 #define GPLL_HZ(594*MHz)
 #define CPLL_HZ(384*MHz)
-#define PPLL_HZ(594*MHz)
+#define PPLL_HZ(676*MHz)
 
-#define PMU_PCLK_HZ(99*MHz)
+#define PMU_PCLK_HZ(48*MHz)
 
 #define ACLKM_CORE_HZ  (300*MHz)
 #define ATCLK_CORE_HZ  (300*MHz)
-- 
1.9.1

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

[U-Boot] [PATCH v2 0/7] add pwm regulator driver

[Kever Yang]

This patch set add pwm regulator driver and enable it
on rk3399, also do some update and fix to make the regulator
driver work properly.


Changes in v2:
- add comments for pwm_regulator_info struct member
- do not init pwm_id if there is none
- other fix for comments from Simon
- add Acked-by tag from Simon and commit message fix
- update the commit message

Kever Yang (7):
  rockchip: rk3399: update PPLL and pmu_pclk frequency
  rockchip: rkpwm: fix the register sequence
  power: regulator: add pwm regulator
  rockchip: evb_rk3399: init vdd_center regulator
  Kconfig: rockchip: enable DM_PWM and DM_REGULATOR
  dts: evb-rk3399: add init voltage node for vdd-center
  config: evb-rk3399: enable pwm regulator

 arch/arm/Kconfig|   2 +
 arch/arm/dts/rk3399-evb.dts |   1 +
 arch/arm/include/asm/arch-rockchip/cru_rk3399.h |   4 +-
 arch/arm/include/asm/arch-rockchip/pwm.h|   2 +-
 board/rockchip/evb_rk3399/evb-rk3399.c  |   6 +
 configs/evb-rk3399_defconfig|   1 +
 drivers/power/regulator/Kconfig |  10 ++
 drivers/power/regulator/Makefile|   1 +
 drivers/power/regulator/pwm_regulator.c | 160 
 9 files changed, 184 insertions(+), 3 deletions(-)
 create mode 100644 drivers/power/regulator/pwm_regulator.c

-- 
1.9.1

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

Re: [U-Boot] config USB_STORAGE: defconfig vs include header

[Tom Rini]

On Fri, Sep 09, 2016 at 10:09:56AM +0900, Masahiro Yamada wrote:
> 2016-09-09 5:17 GMT+09:00 Tom Rini :
> > On Thu, Sep 08, 2016 at 02:13:21PM -0400, Tom Rini wrote:
> >> On Thu, Sep 08, 2016 at 09:58:13AM -0600, Stephen Warren wrote:
> >> > On 09/07/2016 07:29 PM, Masahiro Yamada wrote:
> >> > >Hi Stephen
> >> > >
> >> > >
> >> > >2016-09-08 1:15 GMT+09:00 Stephen Warren :
> >> > >>Masahiro,
> >> > >>
> >> > >>In patch 6e7e9294d321 "usb: add basic USB configs in Kconfig", you 
> >> > >>added
> >> > >>"config USB_STORAGE" to drivers/usb/Kconfig. However, it's still just
> >> > >>#defined by many include/configs/*.h rather than being defined in
> >> > >>configs/*_defconfig. Is that a problem? It seems to work in practice, 
> >> > >>but
> >> > >>leads people adding new boards to put the definition in 
> >> > >>configs/*_defconfig
> >> > >>which then may be inconsistent with similar existing boards which have 
> >> > >>it
> >> > >>defined in include/configs/*.h.
> >> > >
> >> > >Once we create an entry in Kconfig,
> >> > >all the defines in include/configs/*.h should be moved.
> >> >
> >> > That's what I imagined. The commit above didn't do that though; are
> >> > you planning on sending a fix?
> >>
> >> Since those are often conflict-happy I'll take care of it.  I probably
> >> intended to, even.
> >
> > So, yay for moveconfig.suspicious being a thing now.  A number of boards
> > set CONFIG_USB_STORAGE without CONFIG_USB=y in their defconfig file, so
> > they lost CONFIG_USB_STORAGE in migration.  Confirming that yes, really,
> > nothing else is added or dropped when we set CONFIG_USB=y in the
> > defconfig files as well (unit testing was good, testing the world now).
> 
> I thought so.
> 
> A little bit manual intervention
> is needed for those suspicious boards.
> (add CONFIGs by your own script and re-sync)
> 
> I hope this is not too painful...

Nope, it was rather smooth and got me to notice another problem, that is
a little harder to solve "cleanly" until we have Simon's SPL series in.

> Thanks for taking care of this!

Thanks for making the tools!

-- 
Tom


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

Re: [U-Boot] config USB_STORAGE: defconfig vs include header

[Masahiro Yamada]

2016-09-09 5:17 GMT+09:00 Tom Rini :
> On Thu, Sep 08, 2016 at 02:13:21PM -0400, Tom Rini wrote:
>> On Thu, Sep 08, 2016 at 09:58:13AM -0600, Stephen Warren wrote:
>> > On 09/07/2016 07:29 PM, Masahiro Yamada wrote:
>> > >Hi Stephen
>> > >
>> > >
>> > >2016-09-08 1:15 GMT+09:00 Stephen Warren :
>> > >>Masahiro,
>> > >>
>> > >>In patch 6e7e9294d321 "usb: add basic USB configs in Kconfig", you added
>> > >>"config USB_STORAGE" to drivers/usb/Kconfig. However, it's still just
>> > >>#defined by many include/configs/*.h rather than being defined in
>> > >>configs/*_defconfig. Is that a problem? It seems to work in practice, but
>> > >>leads people adding new boards to put the definition in 
>> > >>configs/*_defconfig
>> > >>which then may be inconsistent with similar existing boards which have it
>> > >>defined in include/configs/*.h.
>> > >
>> > >Once we create an entry in Kconfig,
>> > >all the defines in include/configs/*.h should be moved.
>> >
>> > That's what I imagined. The commit above didn't do that though; are
>> > you planning on sending a fix?
>>
>> Since those are often conflict-happy I'll take care of it.  I probably
>> intended to, even.
>
> So, yay for moveconfig.suspicious being a thing now.  A number of boards
> set CONFIG_USB_STORAGE without CONFIG_USB=y in their defconfig file, so
> they lost CONFIG_USB_STORAGE in migration.  Confirming that yes, really,
> nothing else is added or dropped when we set CONFIG_USB=y in the
> defconfig files as well (unit testing was good, testing the world now).

I thought so.

A little bit manual intervention
is needed for those suspicious boards.
(add CONFIGs by your own script and re-sync)

I hope this is not too painful...


Thanks for taking care of this!

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

Re: [U-Boot] [PATCH] arch: ifc: update the IFC IP input clock

[Scott Wood]

On 09/08/2016 07:05 PM, Prabhakar Kushwaha wrote:
> 
>> -Original Message-
>> From: york sun
>> Sent: Thursday, September 08, 2016 9:22 PM
>> To: Prabhakar Kushwaha ; u-
>> b...@lists.denx.de; Scott Wood 
>> Subject: Re: [PATCH] arch: ifc: update the IFC IP input clock
>>
>> On 09/08/2016 02:33 AM, Prabhakar Kushwaha wrote:
>>
>> 
>>
> So better to print IP clock to avoid any confusion.
> IFC output clock will be printed when it is actually being used during
 synchronous NOR, syn NAND.

 I am not against changing it to internal clock. But what are you going
 to print on the console? I think it is confusing to say IFC or local bus
 internal clock speed. Please also check how this clock is used and make
 sure arch.lbc_clk is still correct, after passing to Linux.

>>> arch.lbc_clk is only being used for eLBC for device tree fixup.
>>> And I checked the Linux eLBC driver. Looks like it is not using used.
>>>
>>
>> If this clock is not used, can we drop it completely?
>>
> 
> From my point of view Yes. 
> 
> Scott, Please advice

Well, there is that patch from Matt Weber that is trying to guess the
IFC frequency in order to use NWAIT...  Not sure if we'll end up
actually using NWAIT (Prabhakar, can you answer my question of whether
there is a better opcode to use with RNDOUT?) or ever sending a real
RNDOUT, or if we'll ever care about these newer NAND chips on eLBC, but
if U-Boot is currently writing the clock frequency into the device tree
I don't see why we'd rip it out.

-Scott

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

Re: [U-Boot] [Patch v6 8/9] armv8: ls1046ardb: Add LS1046ARDB board support

[Prabhakar Kushwaha]

Hi York,

> -Original Message-
> From: york sun
> Sent: Thursday, September 08, 2016 10:51 PM
> To: Q.Y. Gong ; u-boot@lists.denx.de
> Cc: Prabhakar Kushwaha ; Vincent Hu
> ; S.H. Xie ; Z.Q. Hou
> ; Wenbin Song ; Shengzhou
> Liu 
> Subject: Re: [Patch v6 8/9] armv8: ls1046ardb: Add LS1046ARDB board support
> 
> On 09/07/2016 03:08 AM, Gong Qianyu wrote:
> > From: Mingkai Hu 
> >
> > LS1046ARDB Specification:
> > -
> > Memory subsystem:
> >  * 8GByte DDR4 SDRAM (64bit bus)
> >  * 512 Mbyte NAND flash
> >  * Two 64 Mbyte high-speed SPI flash
> >  * SD connector to interface with the SD memory card
> >  * On-board 4G eMMC
> >
> > Ethernet:
> >  * Two XFI 10G ports
> >  * Two SGMII ports
> >  * Two RGMII ports
> >
> > PCIe:
> >  * PCIe1 (SerDes2 Lane0) to miniPCIe slot
> >  * PCIe2 (SerDes2 Lane1) to x2 PCIe slot
> >  * PCIe3 (SerDes2 Lane2) to x4 PCIe slot
> >
> > SATA:
> >  * SerDes2 Lane3 to SATA port
> >
> > USB 3.0: one super speed USB 3.0 type A port
> >  one Micro-AB port
> >
> > UART: supports two UARTs up to 115200 bps for console
> 
> The board specification doesn't belong to commit message. Instead, you
> can add what features have been supported, such as boot source, any
> important commands, special care to prepare the image, etc.
> 

As such there is no guideline about what should be in commit message of a board 
support.
I request you to guide us with about required things in board support commit 
message.

It will help future board support patches.

--prabhakar


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

Re: [U-Boot] [PATCH] arch: ifc: update the IFC IP input clock

[Prabhakar Kushwaha]

> -Original Message-
> From: york sun
> Sent: Thursday, September 08, 2016 9:22 PM
> To: Prabhakar Kushwaha ; u-
> b...@lists.denx.de; Scott Wood 
> Subject: Re: [PATCH] arch: ifc: update the IFC IP input clock
> 
> On 09/08/2016 02:33 AM, Prabhakar Kushwaha wrote:
> 
> 
> 
> >>> So better to print IP clock to avoid any confusion.
> >>> IFC output clock will be printed when it is actually being used during
> >> synchronous NOR, syn NAND.
> >>
> >> I am not against changing it to internal clock. But what are you going
> >> to print on the console? I think it is confusing to say IFC or local bus
> >> internal clock speed. Please also check how this clock is used and make
> >> sure arch.lbc_clk is still correct, after passing to Linux.
> >>
> > arch.lbc_clk is only being used for eLBC for device tree fixup.
> > And I checked the Linux eLBC driver. Looks like it is not using used.
> >
> 
> If this clock is not used, can we drop it completely?
> 

>From my point of view Yes. 

Scott, Please advice

--prabhakar

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

Re: [U-Boot] [PATCH v3 7/8] arch, board: squash lines for immediate return

[Angelo Dureghello]

On 06/09/2016 15:17, Masahiro Yamada wrote:

Remove unneeded variables and assignments.

Signed-off-by: Masahiro Yamada 
---

Changes in v3:
  - More fixes

 arch/arm/cpu/arm920t/imx/timer.c  |  6 +-
 arch/arm/cpu/armv7/am33xx/sys_info.c  |  4 +---
 arch/arm/cpu/sa1100/timer.c   |  5 +
 arch/arm/mach-zynq/cpu.c  |  8 ++--
 arch/blackfin/cpu/interrupts.c|  5 +
 arch/m68k/lib/time.c  |  4 +---
 arch/powerpc/cpu/mpc512x/cpu.c|  6 +-
 arch/powerpc/cpu/mpc83xx/cpu.c|  6 +-
 arch/xtensa/lib/time.c|  5 +
 board/amcc/bamboo/bamboo.c|  6 +-
 board/amcc/bubinga/bubinga.c  |  5 +
 board/amcc/canyonlands/canyonlands.c  |  6 +-
 board/corscience/tricorder/tricorder-eeprom.c | 20 +---
 board/freescale/common/zm7300.c   |  4 +---
 board/samsung/goni/goni.c |  8 +---
 board/ti/omap5_uevm/evm.c |  5 +
 16 files changed, 21 insertions(+), 82 deletions(-)

diff --git a/arch/arm/cpu/arm920t/imx/timer.c b/arch/arm/cpu/arm920t/imx/timer.c
index b62558f..178422a 100644
--- a/arch/arm/cpu/arm920t/imx/timer.c
+++ b/arch/arm/cpu/arm920t/imx/timer.c
@@ -78,11 +78,7 @@ unsigned long long get_ticks(void)
  */
 ulong get_tbclk (void)
 {
-   ulong tbclk;
-
-   tbclk = CONFIG_SYS_HZ;
-
-   return tbclk;
+   return CONFIG_SYS_HZ;
 }

 /*
diff --git a/arch/arm/cpu/armv7/am33xx/sys_info.c 
b/arch/arm/cpu/armv7/am33xx/sys_info.c
index 52a6824..f42eee1 100644
--- a/arch/arm/cpu/armv7/am33xx/sys_info.c
+++ b/arch/arm/cpu/armv7/am33xx/sys_info.c
@@ -65,9 +65,7 @@ u32 get_device_type(void)
  */
 u32 get_sysboot_value(void)
 {
-   int mode;
-   mode = readl(>statusreg) & (SYSBOOT_MASK);
-   return mode;
+   return readl(>statusreg) & SYSBOOT_MASK;
 }

 #ifdef CONFIG_DISPLAY_CPUINFO
diff --git a/arch/arm/cpu/sa1100/timer.c b/arch/arm/cpu/sa1100/timer.c
index 0a0006b..90e2128 100644
--- a/arch/arm/cpu/sa1100/timer.c
+++ b/arch/arm/cpu/sa1100/timer.c
@@ -66,8 +66,5 @@ unsigned long long get_ticks(void)
  */
 ulong get_tbclk (void)
 {
-   ulong tbclk;
-
-   tbclk = CONFIG_SYS_HZ;
-   return tbclk;
+   return CONFIG_SYS_HZ;
 }
diff --git a/arch/arm/mach-zynq/cpu.c b/arch/arm/mach-zynq/cpu.c
index 914b1fe..ba9171e 100644
--- a/arch/arm/mach-zynq/cpu.c
+++ b/arch/arm/mach-zynq/cpu.c
@@ -43,12 +43,8 @@ int arch_cpu_init(void)

 unsigned int zynq_get_silicon_version(void)
 {
-   unsigned int ver;
-
-   ver = (readl(_base->mctrl) &
-  ZYNQ_SILICON_VER_MASK) >> ZYNQ_SILICON_VER_SHIFT;
-
-   return ver;
+   return (readl(_base->mctrl) & ZYNQ_SILICON_VER_MASK)
+   >> ZYNQ_SILICON_VER_SHIFT;
 }

 void reset_cpu(ulong addr)
diff --git a/arch/blackfin/cpu/interrupts.c b/arch/blackfin/cpu/interrupts.c
index 45c92c3..abb7dc1 100644
--- a/arch/blackfin/cpu/interrupts.c
+++ b/arch/blackfin/cpu/interrupts.c
@@ -47,10 +47,7 @@ unsigned long long get_ticks(void)
  */
 ulong get_tbclk(void)
 {
-   ulong tbclk;
-
-   tbclk = CONFIG_SYS_HZ;
-   return tbclk;
+   return CONFIG_SYS_HZ;
 }

 void enable_interrupts(void)
diff --git a/arch/m68k/lib/time.c b/arch/m68k/lib/time.c
index 3163354..cb90c83 100644
--- a/arch/m68k/lib/time.c
+++ b/arch/m68k/lib/time.c
@@ -192,7 +192,5 @@ unsigned long usec2ticks(unsigned long usec)
  */
 ulong get_tbclk(void)
 {
-   ulong tbclk;
-   tbclk = CONFIG_SYS_HZ;
-   return tbclk;
+   return CONFIG_SYS_HZ;
 }
diff --git a/arch/powerpc/cpu/mpc512x/cpu.c b/arch/powerpc/cpu/mpc512x/cpu.c
index 8508e8d..4ee91e1 100644
--- a/arch/powerpc/cpu/mpc512x/cpu.c
+++ b/arch/powerpc/cpu/mpc512x/cpu.c
@@ -95,11 +95,7 @@ do_reset (cmd_tbl_t * cmdtp, int flag, int argc, char * 
const argv[])
  */
 unsigned long get_tbclk (void)
 {
-   ulong tbclk;
-
-   tbclk = (gd->bus_clk + 3L) / 4L;
-
-   return tbclk;
+   return (gd->bus_clk + 3L) / 4L;
 }


diff --git a/arch/powerpc/cpu/mpc83xx/cpu.c b/arch/powerpc/cpu/mpc83xx/cpu.c
index 3809309..c87f0fd 100644
--- a/arch/powerpc/cpu/mpc83xx/cpu.c
+++ b/arch/powerpc/cpu/mpc83xx/cpu.c
@@ -173,11 +173,7 @@ do_reset (cmd_tbl_t * cmdtp, int flag, int argc, char * 
const argv[])

 unsigned long get_tbclk(void)
 {
-   ulong tbclk;
-
-   tbclk = (gd->bus_clk + 3L) / 4L;
-
-   return tbclk;
+   return (gd->bus_clk + 3L) / 4L;
 }


diff --git a/arch/xtensa/lib/time.c b/arch/xtensa/lib/time.c
index 1332072..915eb51 100644
--- a/arch/xtensa/lib/time.c
+++ b/arch/xtensa/lib/time.c
@@ -104,10 +104,7 @@ unsigned long long get_ticks(void)
  */
 ulong get_tbclk(void)
 {
-   ulong tbclk;
-
-   tbclk = CONFIG_SYS_HZ;
-   return tbclk;
+   return CONFIG_SYS_HZ;
 }

 #if XCHAL_HAVE_CCOUNT
diff --git 

Re: [U-Boot] [PATCH] Fix fastboot boot address

[Tom Rini]

On Thu, Sep 08, 2016 at 08:51:57PM +, peter.ch...@data61.csiro.au wrote:

> Fastboot loads an image at CONFIG_FASTBOOT_BUF_ADDR, but currently
> tells do_bootm() to look for an image at $loadaddr.  This breaks if
> CONFIG_FASTBOOT_BUF_ADDR is different from the current user-set
> loadaddr.
> 
> Instead, tell do_bootm() to pick up the image where it was laoded.
> 
> Signed-off-by: Peter Chubb 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 3/3 v2] test/fs: strip carriage-return from sandbox output

[Tom Rini]

On Thu, Sep 08, 2016 at 10:28:44PM +0200, Stefan Bruens wrote:
> On Donnerstag, 11. August 2016 22:52:05 CEST you wrote:
> > DM added carriage-returns to every newline. Strip everything after the
> > 32 character long mdsum.
> > 
> > Signed-off-by: Stefan Brüns 
> > ---
> >  test/fs/fs-test.sh | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/test/fs/fs-test.sh b/test/fs/fs-test.sh
> > index 043e5d0..171b1de 100755
> > --- a/test/fs/fs-test.sh
> > +++ b/test/fs/fs-test.sh
> > @@ -402,7 +402,7 @@ check_md5() {
> > # the 7th field is the actual md5
> > md5_src=`grep -A3 "$1" "$2" | grep "md5 for"`
> > md5_src=($md5_src)
> > -   md5_src=${md5_src[6]}
> > +   md5_src=${md5_src[6]:0:32}
> > 
> > # The md5 list, each line is of the form:
> > # - 
> 
> This issue has been fixed in a different way.
> 
> Superseded-by: 634a4d2e825ba2effc01298ca194cd5cb09f6e3a
> "fs-test.sh: Correct check_md5() test with newlines"

Ug, sorry I missed this.  On the plus side, I hit this (and cursed and
fixed it) since I'm running fs-test.sh automatically on every batch of
commits I bring in now, and it errors if the output changes.

-- 
Tom


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

[U-Boot] [PATCH] Fix fastboot boot address

[Peter.Chubb]

Fastboot loads an image at CONFIG_FASTBOOT_BUF_ADDR, but currently
tells do_bootm() to look for an image at $loadaddr.  This breaks if
CONFIG_FASTBOOT_BUF_ADDR is different from the current user-set
loadaddr.

Instead, tell do_bootm() to pick up the image where it was laoded.

Signed-off-by: Peter Chubb 
---
 drivers/usb/gadget/f_fastboot.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c
index 2160b1c..6d02248 100644
--- a/drivers/usb/gadget/f_fastboot.c
+++ b/drivers/usb/gadget/f_fastboot.c
@@ -553,7 +553,7 @@ static void do_bootm_on_complete(struct usb_ep *ep, struct 
usb_request *req)
 
puts("Booting kernel..\n");
 
-   sprintf(boot_addr_start, "0x%lx", load_addr);
+   sprintf(boot_addr_start, "0x%lx", CONFIG_FASTBOOT_BUF_ADDR);
do_bootm(NULL, 0, 2, bootm_args);
 
/* This only happens if image is somehow faulty so we start over */
-- 
2.9.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] Fix fastboot boot address Fastboot loads an image at CONFIG_FASTBOOT_BUF_ADDR, but currently tells do_bootm() to look for an image at $loadaddr. This breaks if CONFIG_FASTBOOT_BUF_ADD

[Peter.Chubb]

Instead, tell do_bootm() to pick up the image where it was laoded.

Signed-off-by: Peter Chubb 
---
 drivers/usb/gadget/f_fastboot.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c
index 2160b1c..6d02248 100644
--- a/drivers/usb/gadget/f_fastboot.c
+++ b/drivers/usb/gadget/f_fastboot.c
@@ -553,7 +553,7 @@ static void do_bootm_on_complete(struct usb_ep *ep, struct 
usb_request *req)
 
puts("Booting kernel..\n");
 
-   sprintf(boot_addr_start, "0x%lx", load_addr);
+   sprintf(boot_addr_start, "0x%lx", CONFIG_FASTBOOT_BUF_ADDR);
do_bootm(NULL, 0, 2, bootm_args);
 
/* This only happens if image is somehow faulty so we start over */
-- 
2.9.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] "_ENTRY" is both a struct and a typedef?

[Peter.Chubb]

> "Robert" == Robert P J Day  writes:

Robert>   from lib/hashtable.c:

Robert>   typedef struct _ENTRY { int used; ENTRY entry; } _ENTRY;

Robert> ok, that's just kind of creepy ... defining a typedef over top
Robert> of a struct of the same name. does anyone else find that
Robert> strange?

It's standard practice in some C styles.  Personally I'd delete the
struct tag, as the typedef should be used everywhere instead.

Peter C
-- 
Dr Peter Chubb Tel: +61 2 9490 5852  http://ts.data61.csiro.au/
Trustworthy Systems Group   Data61 (formerly NICTA)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3 v2] test/fs: strip carriage-return from sandbox output

[Stefan Bruens]

On Donnerstag, 11. August 2016 22:52:05 CEST you wrote:
> DM added carriage-returns to every newline. Strip everything after the
> 32 character long mdsum.
> 
> Signed-off-by: Stefan Brüns 
> ---
>  test/fs/fs-test.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/test/fs/fs-test.sh b/test/fs/fs-test.sh
> index 043e5d0..171b1de 100755
> --- a/test/fs/fs-test.sh
> +++ b/test/fs/fs-test.sh
> @@ -402,7 +402,7 @@ check_md5() {
>   # the 7th field is the actual md5
>   md5_src=`grep -A3 "$1" "$2" | grep "md5 for"`
>   md5_src=($md5_src)
> - md5_src=${md5_src[6]}
> + md5_src=${md5_src[6]:0:32}
> 
>   # The md5 list, each line is of the form:
>   # - 

This issue has been fixed in a different way.

Superseded-by: 634a4d2e825ba2effc01298ca194cd5cb09f6e3a
"fs-test.sh: Correct check_md5() test with newlines"

Kind regards,

Stefan

-- 
Stefan Brüns  /  Bergstraße 21  /  52062 Aachen
home: +49 241 53809034 mobile: +49 151 50412019
work: +49 2405 49936-424
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] config USB_STORAGE: defconfig vs include header

[Tom Rini]

On Thu, Sep 08, 2016 at 02:13:21PM -0400, Tom Rini wrote:
> On Thu, Sep 08, 2016 at 09:58:13AM -0600, Stephen Warren wrote:
> > On 09/07/2016 07:29 PM, Masahiro Yamada wrote:
> > >Hi Stephen
> > >
> > >
> > >2016-09-08 1:15 GMT+09:00 Stephen Warren :
> > >>Masahiro,
> > >>
> > >>In patch 6e7e9294d321 "usb: add basic USB configs in Kconfig", you added
> > >>"config USB_STORAGE" to drivers/usb/Kconfig. However, it's still just
> > >>#defined by many include/configs/*.h rather than being defined in
> > >>configs/*_defconfig. Is that a problem? It seems to work in practice, but
> > >>leads people adding new boards to put the definition in 
> > >>configs/*_defconfig
> > >>which then may be inconsistent with similar existing boards which have it
> > >>defined in include/configs/*.h.
> > >
> > >Once we create an entry in Kconfig,
> > >all the defines in include/configs/*.h should be moved.
> > 
> > That's what I imagined. The commit above didn't do that though; are
> > you planning on sending a fix?
> 
> Since those are often conflict-happy I'll take care of it.  I probably
> intended to, even.

So, yay for moveconfig.suspicious being a thing now.  A number of boards
set CONFIG_USB_STORAGE without CONFIG_USB=y in their defconfig file, so
they lost CONFIG_USB_STORAGE in migration.  Confirming that yes, really,
nothing else is added or dropped when we set CONFIG_USB=y in the
defconfig files as well (unit testing was good, testing the world now).

-- 
Tom


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

Re: [U-Boot] EHCI timed out on TD - token=0x80008d80

[Marek Vasut]

On 09/08/2016 03:19 PM, Andreas Neubacher wrote:
> Hi Marek & Team :), i'm facing the same issue as Manju and all the
> others on the web (see mail below). i've tested it on different
> hardware-platforms and different uboot-versions... - ATMEL G45 (custom
> board), uboot 2015.01 - ATMEL G45 (custom board), uboot 2013.03 - ATMEL
> SAMA5D36 (custom board), uboot 2016.03 - ATMEL SAMA5D36 (custom board),
> uboot-mainline what we did: we are using usb-memory-sticks for updating
> our complete system (rootfs, kernel, etc.) and somtimes copy files
> larger than 50MB from USB to RAM (fatload usb 0 $loadaddr file.bin).
> we've tested different speed-classes, different stick-sizes and
> different quality-standards of the usb-sticks. from all the different
> type of sticks we've tested, we found some 'bad sticks' where we get the
> error-msg EHCI timed out on TD - token=0x9e008d80 EHCI timed out on TD -
> token=0x1e008d80 EHCI timed out on TD - token=0x1e008d80 ... in all
> uboot-versions and on all different boards the behaviour is the same ->
> so IMHO the issue depends on the 'bad usb-stick(s)' we are using. so we
> investigated the 'bad usb-sticks' with different diagnostic-tools on
> windows(10) and linux(ubuntu) host-machines without any result... means:
> it looks like the 'bad-stick' on any host-machine is working as expected
> (good r/w performance, no timeouts, no issues, etc.) if i can do further
> investigations please let me know :) br, Andy

Let me repeat what Fabio said:
"
Does setting USB_MAX_XFER_BLK to 32767 solve this issue?
"
(or try setting it lower)

I spent too much time and money already on trying to track down all
these weird issues the USB sticks have. If you have some magic solution,
patches are welcome ;-/

> Hello Marek,
> 
> 
> If the USB is detected successfully, then below are the logs.
> 
> 
> U-Boot > usb start
> (Re)start USB...
> USB0:   USB EHCI 1.00
> scanning bus 0 for devices... New Device 0
> usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 
> length 0x40
> set address 1
> usb_control_msg: request: 0x5, requesttype: 0x0, value 0x1 index 0x0 length 
> 0x0
> usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 
> length 0x12
> usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 
> length 0x9
> usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 
> length 0x19
> get_conf_no 0 Result 25, wLength 25
> if 0, ep 0
> ##EP epmaxpacketin[1] = 8
> set configuration 1
> usb_control_msg: request: 0x9, requesttype: 0x0, value 0x1 index 0x0 length 
> 0x0
> new device strings: Mfr=1, Product=2, SerialNumber=0
> usb_control_msg: request: 0x6, requesttype: 0x80, value 0x300 index 0x0 
> length 0xFF
> USB device number 1 default language ID 0x1
> usb_control_msg: request: 0x6, requesttype: 0x80, value 0x301 index 0x1 
> length 0xFF
> usb_control_msg: request: 0x6, requesttype: 0x80, value 0x302 index 0x1 
> length 0xFF
> Manufacturer u-boot
> Product  EHCI Host Controller
> SerialNumber
> usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 index 0x0 
> length 0x4
> usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 index 0x0 
> length 0x8
> usb_control_msg: request: 0x0, requesttype: 0xA0, value 0x0 index 0x0 length 
> 0x4
> usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x1 length 
> 0x0
> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 
> 0x4
> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 
> 0x4
> usb_control_msg: request: 0x1, requesttype: 0x23, value 0x10 index 0x1 length 
> 0x0
> usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x1 length 
> 0x0
> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 
> 0x4
> usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x1 length 
> 0x0
> New Device 1
> usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 
> length 0x40
> usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x1 length 
> 0x0
> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 
> 0x4
> usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x1 length 
> 0x0
> set address 2
> usb_control_msg: request: 0x5, requesttype: 0x0, value 0x2 index 0x0 length 
> 0x0
> usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 
> length 0x12
> usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 
> length 0x9
> usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 
> length 0x20
> get_conf_no 0 Result 32, wLength 32
> if 0, ep 0
> if 0, ep 1
> ##EP epmaxpacketin[1] = 512
> ##EP epmaxpacketout[2] = 512
> set configuration 1
> usb_control_msg: request: 0x9, requesttype: 0x0, value 0x1 index 0x0 length 
> 0x0
> new device strings: Mfr=1, Product=2, SerialNumber=3
> usb_control_msg: request: 0x6, requesttype: 0x80, value 0x300 index 0x0 

Re: [U-Boot] [Patch v6 5/9] armv8: fsl-layerscape: spl: remove BSS clearing and board_init_r

[york sun]

On 09/07/2016 03:08 AM, Gong Qianyu wrote:
> As per the top level U-Boot README "Board Initialisation Flow"
> section, board_init_f() should return without calling board_init_r()
> directly.
> Clearing BSS and calling board_init_r() will be done in crt0_64.S.
>
> Signed-off-by: Gong Qianyu 
> ---
> v6:
>  - No change.
> v5:
>  - New Patch.
>
>  arch/arm/cpu/armv8/fsl-layerscape/spl.c | 5 -
>  1 file changed, 5 deletions(-)
>
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/spl.c 
> b/arch/arm/cpu/armv8/fsl-layerscape/spl.c
> index 19e34fa..b8e1d75 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/spl.c
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/spl.c
> @@ -62,13 +62,8 @@ void board_init_f(ulong dummy)
>   i2c_init_all();
>  #endif
>   dram_init();
> -
> - /* Clear the BSS */
> - memset(__bss_start, 0, __bss_end - __bss_start);
> -
>  #ifdef CONFIG_LAYERSCAPE_NS_ACCESS
>   enable_layerscape_ns_access();
>  #endif
> - board_init_r(NULL, 0);
>  }
>  #endif
>

Qianyu,

This looks OK but it breaks LS2080ARDB NAND boot. Please investigate.

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

Re: [U-Boot] [PATCH 0/2] Add sdram capacity auto detect for rk3288

[Vagrant Cascadian]

On 2016-09-08, Kever Yang wrote:
> The rk3288 spl size is very close to 32KB while the rk3288 bootrom
> has the limitation of maximum size of SPL is 32KB. After apply this
> patch, the SPL size will exceed 32KB if we do not enable macro
> CONFIG_ROCKCHIP_SPL_BACK_TO_BROM.
>
> I think this patch is usful and should be go upstream other than the
> size issue.
>
> This patch has test with 2GB DDR3 and 2GB/4GB LPDDR3.

Thanks for the patch!

Unfortunately, fails to build the firefly-rk3288 target, using
arm-linux-gnueabihf-gcc (Debian 6.1.1-9) 6.1.1 20160705, applied to
u-boot master 01c5075506afcb7a74e0db8600af8979f45881b5:

  CC  spl/arch/arm/mach-rockchip/rk3288/sdram_rk3288.o
arch/arm/mach-rockchip/rk3288/sdram_rk3288.c: In function
  'conv_of_platdata':
arch/arm/mach-rockchip/rk3288/sdram_rk3288.c:1042:30: error: 'struct
  dtd_rockchip_rk3288_dmc' has no member named 'rockchip_num_channels';
  did you mean 'rockchip_noc'?
  plat->num_channels = of_plat->rockchip_num_channels;
  ^~
arch/arm/mach-rockchip/rk3288/sdram_rk3288.c:1035:6: warning: unused
  variable 'i' [-Wunused-variable]
  int i, ret;
  ^
scripts/Makefile.build:280: recipe for target
  'spl/arch/arm/mach-rockchip/rk3288/sdram_rk3288.o' failed
make[3]: *** [spl/arch/arm/mach-rockchip/rk3288/sdram_rk3288.o] Error 1
scripts/Makefile.build:425: recipe for target
  'spl/arch/arm/mach-rockchip/rk3288' failed
make[2]: *** [spl/arch/arm/mach-rockchip/rk3288] Error 2
scripts/Makefile.spl:292: recipe for target 'spl/arch/arm/mach-rockchip'
  failed
make[1]: *** [spl/arch/arm/mach-rockchip] Error 2
Makefile:1334: recipe for target 'spl/u-boot-spl' failed
make: *** [spl/u-boot-spl] Error 2


live well,
  vagrant


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

Re: [U-Boot] [RFC] bootm: fix passing argc to standalone apps

[Tom Rini]

On Thu, Sep 08, 2016 at 10:24:44AM +0100, Zubair Lutfullah Kakakhel wrote:
> Hi,
> 
> On 09/08/2016 09:23 AM, Zubair Lutfullah Kakakhel wrote:
> >This bug appears in b6396403 which makes u-boot unable to pass
> >arguments via bootm to a standalone application without this patch.
> >
> >Steps to reproduce.
> >
> >Compile a u-boot. Use mkimage to package the standalone hello_world.bin
> >file.
> >
> >e.g. For the MIPS Boston platform
> >
> >mkimage -n "hello" -A mips -O u-boot -C none -T standalone \
> > -a 0x8020 -d hello_world.bin \
> > -ep 0x8020 hello_out
> >
> >Then tftp hello_out and run it using
> >
> >boston # dhcp 192.168.154.45:hello_out
> >...
> >boston # bootm $loadaddr 123 321
> >
> >Without the patch the following output is observed.
> >
> >Example expects ABI version 8
> >Actual U-Boot ABI version 8
> >Hello World
> >argc = 0
> >argv[0] = "0x8800"
> >
> >With the patch, you see the following.
> >
> >boston # bootm $loadaddr 123 321
> >   Image Name:   hello
> >   Image Type:   MIPS U-Boot Standalone Program (uncompressed)
> >   Data Size:1240 Bytes = 1.2 KiB
> >   Load Address: 8020
> >   Entry Point:  8020
> >   Verifying Checksum ... OK
> >   Loading Standalone Program ... OK
> >Example expects ABI version 8
> >Actual U-Boot ABI version 8
> >Hello World
> >argc = 0
> argc = 3
> >argv[0] = "0x8800"
> argv[1] = 123
> argv[2] = 321
> 
> Copy paste fluke in the git log. Sorry.
> The above appears in reality
> 
> Regards,
> ZubairLK
> 
> >Hit any key to exit ...
> >
> >The go command at the entry point seems to work.
> >
> >boston # go 0x8020 123 321
> >Example expects ABI version 8
> >Actual U-Boot ABI version 8
> >Hello World
> >argc = 3
> >argv[0] = "0x8020"
> >argv[1] = "123"
> >argv[2] = "321"
> >argv[3] = ""
> >Hit any key to exit ...
> >
> >Signed-off-by: Zubair Lutfullah Kakakhel 
> >
> >---
> >
> >Tested on the MIPS Boston platform.
> >---
> > common/bootm.c | 4 +---
> > 1 file changed, 1 insertion(+), 3 deletions(-)
> >
> >diff --git a/common/bootm.c b/common/bootm.c
> >index a4d22a6..b2c0912 100644
> >--- a/common/bootm.c
> >+++ b/common/bootm.c
> >@@ -619,10 +619,8 @@ int do_bootm_states(cmd_tbl_t *cmdtp, int flag, int 
> >argc, char * const argv[],
> > if (!ret && (states & BOOTM_STATE_FINDOS))
> > ret = bootm_find_os(cmdtp, flag, argc, argv);
> >
> >-if (!ret && (states & BOOTM_STATE_FINDOTHER)) {
> >+if (!ret && (states & BOOTM_STATE_FINDOTHER))
> > ret = bootm_find_other(cmdtp, flag, argc, argv);
> >-argc = 0;   /* consume the args */
> >-}
> >
> > /* Load the OS */
> > if (!ret && (states & BOOTM_STATE_LOADOS)) {

Can you re-send with a corrected commit log?  Thanks.

-- 
Tom


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

Re: [U-Boot] [PATCH 0/3] Fastboot MBR and generic partition support

[Tom Rini]

On Wed, Sep 07, 2016 at 03:06:41PM +0200, Petr Kulhavy wrote:

> This set extends the Fastboot implementation from GPT-only to any partition
> support.  Further it adds a special target "mbr" (configurable) to write the
> DOS MBR.
> 
> Petr Kulhavy (3):
>   disk: part: implement generic function part_get_info_by_name()
>   fastboot: add support for writing MBR
>   disk: part: refactor generic name creation for DOS and ISO
> 
>  README  |  7 +
>  common/fb_mmc.c | 44 +++--
>  disk/part.c | 58 +
>  disk/part_amiga.c   |  1 +
>  disk/part_dos.c | 52 +++---
>  disk/part_efi.c | 20 +
>  disk/part_iso.c | 26 ++---
>  disk/part_mac.c |  1 +
>  doc/README.android-fastboot | 38 +
>  include/part.h  | 69 
> +
>  10 files changed, 224 insertions(+), 92 deletions(-)

Can you please do a follow up patch where you move both
CONFIG_FASTBOOT_GPT_NAME and CONFIG_FASTBOOT_MBR_NAME in to
cmd/fastboot/Kconfig ?  And then clean up the code since a name will
always be set.  Thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH 3/3] disk: part: refactor generic name creation for DOS and ISO

[Tom Rini]

On Wed, Sep 07, 2016 at 03:06:44PM +0200, Petr Kulhavy wrote:

> In both DOS and ISO partition tables the same code to create partition name
> like "hda1" was repeated.
> 
> Code moved to into a new function part_set_generic_name() in part.c and 
> optimized.
> Added recognition of MMC and SD types, name is like "mmcsda1".
> 
> Signed-off-by: Petr Kulhavy 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 2/3] fastboot: add support for writing MBR

[Tom Rini]

On Wed, Sep 07, 2016 at 03:06:43PM +0200, Petr Kulhavy wrote:

> Add special target "mbr" (otherwise configurable via CONFIG_FASTBOOT_MBR_NAME)
> to write MBR partition table.
> Partitions are now searched using the generic function which finds any
> partiiton by name. For MBR the partition names hda1, sda1, etc. are used.
> 
> Signed-off-by: Petr Kulhavy 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 1/3] disk: part: implement generic function part_get_info_by_name()

[Tom Rini]

On Wed, Sep 07, 2016 at 03:06:42PM +0200, Petr Kulhavy wrote:

> So far partition search by name has been supported only on the EFI partition
> table. This patch extends the search to all partition tables.
> 
> Rename part_get_info_efi_by_name() to part_get_info_by_name(), move it from
> part_efi.c into part.c and make it a generic function which traverses all part
> drivers and searches all partitions (in the order given by the linked list).
> 
> For this a new variable struct part_driver.max_entries is added, which limits
> the number of partitions searched. For EFI this was GPT_ENTRY_NUMBERS.
> Similarly the limit is defined for DOS, ISO, MAC and AMIGA partition tables.
> 
> Signed-off-by: Petr Kulhavy 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] RFC: 'fastboot boot' uses wrong address when calling bootm

[Tom Rini]

On Wed, Sep 07, 2016 at 09:37:48AM +, peter.ch...@data61.csiro.au wrote:
> Hi Folks,
>If you set CONFIG_FASTBOOT_BUF_ADDR to anything other than the same
>as $loadaddr then the call to do_bootm() in the fastboot code
>will call do_bootm on a memory region that has nothing to do with
>the image downloaded.  Sometimes the result is a hung system, other
>times the system reboots.
> 
>I'm not sure of the correct fix.  The possibilities are:
>1. Get rid of CONFIG_FASTBOOT_BUF_ADDR and use $loadaddr
>instead.  All the defconfigs that enable fastboot currently set
>CONFIG_FASTBOOT_BUF_ADDR to the same value as CONFIG_LOADADDR at
>present.
> 
>2. memcpy from the downloaded image to $loadaddr if possible.  This
>would allow other payloads than ANDROID boot images, with a bit
>more work. (For example, I'd love to be able to boot ELF images
>using fastboot -- which doesn't work at present, because the
>entry point in the elf header isn't used)
> 
>3. The simplest: call do_bootm() with the address where the
>image has just been downloaded.  The attached patch does this.
> 
> What do you think?

Since it's possible that one would want the buf addr to be different
from loadaddr later on, I think #3 is the path of least surprise, please
re-submit as a formal patch, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] ARM: Respect CONFIG_SPL_STACK define in lowlevel_init.S

[Tom Rini]

On Mon, Sep 05, 2016 at 06:36:10AM +0300, Siarhei Siamashka wrote:

> The SPL and U-Boot proper may use different initial stack
> locations, which are configured via CONFIG_SPL_STACK and
> CONFIG_SYS_INIT_SP_ADDR defines. The lowlevel_init.S
> code needs to handle this in the same way as crt0.S
> 
> Without this fix, setting the U-Boot stack location to some
> place, which is not safely accessible by the SPL (such as
> the DRAM), causes a very early SPL deadlock.
> 
> Signed-off-by: Siarhei Siamashka 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] config USB_STORAGE: defconfig vs include header

[Tom Rini]

On Thu, Sep 08, 2016 at 09:58:13AM -0600, Stephen Warren wrote:
> On 09/07/2016 07:29 PM, Masahiro Yamada wrote:
> >Hi Stephen
> >
> >
> >2016-09-08 1:15 GMT+09:00 Stephen Warren :
> >>Masahiro,
> >>
> >>In patch 6e7e9294d321 "usb: add basic USB configs in Kconfig", you added
> >>"config USB_STORAGE" to drivers/usb/Kconfig. However, it's still just
> >>#defined by many include/configs/*.h rather than being defined in
> >>configs/*_defconfig. Is that a problem? It seems to work in practice, but
> >>leads people adding new boards to put the definition in configs/*_defconfig
> >>which then may be inconsistent with similar existing boards which have it
> >>defined in include/configs/*.h.
> >
> >Once we create an entry in Kconfig,
> >all the defines in include/configs/*.h should be moved.
> 
> That's what I imagined. The commit above didn't do that though; are
> you planning on sending a fix?

Since those are often conflict-happy I'll take care of it.  I probably
intended to, even.

-- 
Tom


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

Re: [U-Boot] [Patch v6 8/9] armv8: ls1046ardb: Add LS1046ARDB board support

[york sun]

On 09/07/2016 03:08 AM, Gong Qianyu wrote:
> From: Mingkai Hu 
>
> LS1046ARDB Specification:
> -
> Memory subsystem:
>  * 8GByte DDR4 SDRAM (64bit bus)
>  * 512 Mbyte NAND flash
>  * Two 64 Mbyte high-speed SPI flash
>  * SD connector to interface with the SD memory card
>  * On-board 4G eMMC
>
> Ethernet:
>  * Two XFI 10G ports
>  * Two SGMII ports
>  * Two RGMII ports
>
> PCIe:
>  * PCIe1 (SerDes2 Lane0) to miniPCIe slot
>  * PCIe2 (SerDes2 Lane1) to x2 PCIe slot
>  * PCIe3 (SerDes2 Lane2) to x4 PCIe slot
>
> SATA:
>  * SerDes2 Lane3 to SATA port
>
> USB 3.0: one super speed USB 3.0 type A port
>one Micro-AB port
>
> UART: supports two UARTs up to 115200 bps for console

The board specification doesn't belong to commit message. Instead, you 
can add what features have been supported, such as boot source, any 
important commands, special care to prepare the image, etc.

York

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

[U-Boot] "_ENTRY" is both a struct and a typedef?

[Robert P. J. Day]

  from lib/hashtable.c:

  typedef struct _ENTRY {
int used;
ENTRY entry;
  } _ENTRY;

ok, that's just kind of creepy ... defining a typedef over top of a
struct of the same name. does anyone else find that strange?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: [U-Boot] [PATCH v2 2/7] arm: mach-keystone: Implements FIT post-processing call for keystone SoCs

[Srinivas, Madan]

On 9/6/2016 9:34 AM, Tom Rini wrote:

On Thu, Sep 01, 2016 at 01:04:37AM -0400, Madan Srinivas wrote:


From: Vitaly Andrianov 

This commit implements the board_fit_image_post_process() function for
the keystone architecture. Unlike OMAP class devices, security
functions in keystone are not handled in the ROM.
The interface to the secure functions is TI proprietary and depending
on the keystone platform, the security functions like encryption,
decryption and authentication might even be offloaded to other secure
processing elements in the SoC.
The boot monitor acts as the gateway to these secure functions and the
boot monitor for secure devices is available as part of the SECDEV
package for KS2. For more details refer doc/README.ti-secure

Signed-off-by: Vitaly Andrianov 
Signed-off-by: Madan Srinivas 

Cc: Lokesh Vutla 
Cc: Dan Murphy 


First, what is done to ensure that the magic blob we're offloading to
isn't malicious?
The magic blob is signed and authenticated as part of the boot flow to 
ensure that it is not malicious.

Second, this appears to be missing cache flushes
that're done in arch/arm/cpu/armv7/omap-common/sec-common.c and, well,
why can't we re-use the existing code?  Given how rarely IP blocks are
written from scratch rather than being an evolution of a previous block
Valid point Tom, but this case is the exception to that rule - the 
Keystone and the OMAP ROMs were developed independently, the keystone 
ROMs were based on DSP ROMs, not on OMAP, and therefore the code 
omap-common/in sec-common.c cannot be reused at all for keystone - the 
calling conventions, parameters APIs are all different.

I can't imagine that we can't make the code there be re-used nor that we
don't need / couldn't use the flushing and alignment checks nor status
messages.  Thanks!

Unlike OMAP, in keystone2 for eg, the authentication is also done by 
DSP, so the code in sec-common.c cannot be reused at all. Even if K2 ROM 
APIs are used, the calling conventions are different. Also, unlike OMAP, 
the boot monitor has a secure and non-secure component (everything gets 
authenticated).


Again in OMAP the authentication is always done using only ROM APIs, 
whereas in keystone the authentication and decryption can be done using 
ROM, Secure ARM libraries or Secure DSP libraries. Using the current 
scheme, this can be achieved simply by selecting a different boot 
monitor binary to include in the signing step, the same u-boot binary 
will work for all three authentication schemes.


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

Re: [U-Boot] config USB_STORAGE: defconfig vs include header

[Stephen Warren]

On 09/07/2016 07:29 PM, Masahiro Yamada wrote:

Hi Stephen


2016-09-08 1:15 GMT+09:00 Stephen Warren :

Masahiro,

In patch 6e7e9294d321 "usb: add basic USB configs in Kconfig", you added
"config USB_STORAGE" to drivers/usb/Kconfig. However, it's still just
#defined by many include/configs/*.h rather than being defined in
configs/*_defconfig. Is that a problem? It seems to work in practice, but
leads people adding new boards to put the definition in configs/*_defconfig
which then may be inconsistent with similar existing boards which have it
defined in include/configs/*.h.


Once we create an entry in Kconfig,
all the defines in include/configs/*.h should be moved.


That's what I imagined. The commit above didn't do that though; are you 
planning on sending a fix?

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

Re: [U-Boot] image-fit: switch ENOLINK to ENOENT

[Jonathan Gray]

On Thu, Sep 08, 2016 at 11:17:12AM -0400, Tom Rini wrote:
> On Thu, Sep 08, 2016 at 11:53:48PM +1000, Jonathan Gray wrote:
> > On Thu, Sep 08, 2016 at 09:15:45AM -0400, Tom Rini wrote:
> > > On Thu, Sep 08, 2016 at 11:06:34PM +1000, Jonathan Gray wrote:
> > > > On Thu, Sep 08, 2016 at 08:48:53AM -0400, Tom Rini wrote:
> > > > > On Thu, Sep 08, 2016 at 10:01:52PM +1000, Jonathan Gray wrote:
> > > > > > On Wed, Sep 07, 2016 at 02:00:19PM -0400, Tom Rini wrote:
> > > > > > > On Sat, Sep 03, 2016 at 08:30:14AM +1000, Jonathan Gray wrote:
> > > > > > > 
> > > > > > > > ENOLINK is not required by POSIX and does not exist on OpenBSD
> > > > > > > > and likely other systems.
> > > > > > > > 
> > > > > > > > Signed-off-by: Jonathan Gray 
> > > > > > > 
> > > > > > > Applied to u-boot/master, thanks!
> > > > > > 
> > > > > > Thanks for applying this and the other patch.
> > > > > > 
> > > > > > In tools/kwboot.c I've also locally changed EPROTO and EBADMSG as 
> > > > > > they
> > > > > > aren't on OpenBSD either.
> > > > > > 
> > > > > > They are in POSIX however so I am trying to get them into OpenBSD,
> > > > > > but it will need some time to be scheduled as introducing errnos
> > > > > > involves cranking the major version of libc due to the size of the 
> > > > > > array
> > > > > > with errno strings changing.
> > > > > > 
> > > > > > I wasn't sure if the following would be accepted for that reason,
> > > > > > thoughts?
> > > > > 
> > > > > Well, looking over the code in question, we're talking about error
> > > > > handling during xmodem transfers.  What are the errno values that get
> > > > > used there by xmodem tools?  Thanks!
> > > > 
> > > > I don't see how xmodem tools would use those errno values themselves?
> > > > From what I understood, kwboot attaches directly to serial /dev devices
> > > > and handles xmodem and terminal emulation itself.
> > > > 
> > > > In the kwboot case nothing in the return path seems to check for
> > > > specific errno values.  The return sequence looks like
> > > > 
> > > > kwboot_xm_sendblock
> > > > kwboot_xmodem
> > > > main
> > > > perror("xmodem");
> > > 
> > > Right.  But we're also using it to indicate to the caller that there was
> > > a problem.  I can see using EIO for unknown error but I don't like
> > > ECONNREFUSED for an explicit NAK.  So what I'm asking is, what's passed
> > > around in other tools when you get a NAK reply in xmodem?
> > 
> > I haven't found any that display an errno based string
> > 
> > http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr.bin/cu/xmodem.c?rev=HEAD=text/plain
> > 
> > lrzsz src/lsz.c
> > zperr(_("NAK on sector")); (prints to stderr non-fatally without errno)
> > 
> > kermit code seems to be quite hard to follow...
> > 
> > The list of errnos currently implemented on OpenBSD can be found here:
> > http://man.openbsd.org/OpenBSD-current/man2/intro.2
> > 
> > The strings perror/strerror(errno) use can be found here
> > http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/lib/libc/gen/errlist.c?rev=HEAD=text/plain
> > And in the above manual page.
> > 
> > ENOMSG "No message of desired type." might work
> > 
> > Though it is documented as
> > 
> > "An IPC message queue does not contain a message of the desired type,
> > or a message catalog does not contain the requested message."
> > 
> > on OpenBSD and in POSIX as
> > 
> > "No message of the desired type. The message queue does not contain a
> > message of the required type during XSI interprocess communication."
> > 
> > Neither EBADMSG or ENOMSG appear to be documented in glibc beyond
> > mentioning that they are valid values?
> > 
> > https://www.gnu.org/software/libc/manual/html_node/Error-Codes.html
> 
> EBADMSG and ENOMSG just fall back to POSIX.1.  Is it really hard to
> carry a patch to U-Boot in OpenBSD until the libc can be updated for
> some POSIX errno values?

Having the patch until then is fine.

We already carry patches to convert a few targets to support
distro_bootcmd so our efi bootloader gets loaded automatically.

Mostly taken from looking at patches linux distributions have,
though some of these are marked as incomplete and I'm not clear
on which have been properly proposed on the u-boot list.

cm-fx6/utilite
http://pkgs.fedoraproject.org/cgit/rpms/uboot-tools.git/tree/port-utilite-to-distro-generic-boot-commands.patch
omap3 beagle
https://github.com/openSUSE/u-boot/commit/8ea945ff9d5f57f626167d41b1c59d9518fb60b2.patch
omap5/beagleboard x15
https://anonscm.debian.org/git/collab-maint/u-boot.git/tree/debian/patches/am57xx/omap5_distro_bootcmd?h=experimental-2016.09

others not yet used:

odroid x2/u3
https://anonscm.debian.org/git/collab-maint/u-boot.git/tree/debian/patches/odroid/0001-Convert-odroid-to-use-distro_bootcmd.patch?h=experimental-2016.09
mvebu/clearfog
http://pkgs.fedoraproject.org/cgit/rpms/uboot-tools.git/tree/mvebu-enable-generic-distro-boot-config.patch
nitrogen6x/sabre lite

Re: [U-Boot] [PATCH] arch: ifc: update the IFC IP input clock

[york sun]

On 09/08/2016 02:33 AM, Prabhakar Kushwaha wrote:



>>> So better to print IP clock to avoid any confusion.
>>> IFC output clock will be printed when it is actually being used during
>> synchronous NOR, syn NAND.
>>
>> I am not against changing it to internal clock. But what are you going
>> to print on the console? I think it is confusing to say IFC or local bus
>> internal clock speed. Please also check how this clock is used and make
>> sure arch.lbc_clk is still correct, after passing to Linux.
>>
> arch.lbc_clk is only being used for eLBC for device tree fixup.
> And I checked the Linux eLBC driver. Looks like it is not using used.
>

If this clock is not used, can we drop it completely?

York

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

Re: [U-Boot] ZynqMP breakage

[Michal Simek]

Hi Simon,

On 6.9.2016 16:23, Simon Glass wrote:
> Hi Michal,
> 
> On 6 September 2016 at 07:40, Michal Simek  wrote:
>> Hi,
>>
>> On 6.9.2016 14:57, Simon Glass wrote:
>>> Hi Alex,
>>>
>>> On 6 September 2016 at 06:55, Alexander Graf  wrote:
 On 09/06/2016 02:52 PM, Simon Glass wrote:
>
> Hi Alex,
>
> On 6 September 2016 at 03:09, Alexander Graf  wrote:
>>
>> On 09/06/2016 03:05 AM, Simon Glass wrote:
>>>
>>> Hi Alex,
>>>
>>> On 5 September 2016 at 04:51, Alexander Graf  wrote:

 On 08/19/2016 08:45 AM, Michal Simek wrote:
>
> On 16.8.2016 20:39, Alexander Graf wrote:
>>
>> Hi Michal,
>>
>> I just tried to run the latest u-boot master + a few patches to
>> implement
>> generic PSCI RTS support on zynqmp and got this:
>>
>> e
>> U-Boot 2016.09-rc1-00453-ga0592f1 (Aug 16 2016 - 20:27:40 +0200)
>> Xilinx
>> ZynqMP ZCU102
>>
>> I2C:   ready
>> DRAM:  4 GiB
>> EL Level:   EL2
>> MMC:   sdhci@ff17: 0
>> Using default environment
>>
>> In:serial@ff00
>> Out:   serial@ff00
>> Err:   serial@ff00
>> Bootmode: SD_MODE1
>> SCSI:  SATA link 0 timeout.
>> Target spinup took 0 ms.
>> AHCI 0001.0301 32 slots 2 ports 6 Gbps 0x3 impl SATA mode
>> flags: 64bit ncq pm clo only pmp fbss pio slum part ccc apst
>> scanning bus for devices...
>> "Synchronous Abort" handler, esr 0x9604
>> ELR: 7ff42d20
>> LR:  7ff3ff10
>> x0 :  x1 : 
>> x2 : 0001 x3 : 7df1aa80
>> x4 :  x5 : 0001
>> x6 : 0200 x7 : 0004
>> x8 : 7ff9f800 x9 : 0008
>> x10: 7ff9f8f0 x11: 
>> x12:  x13: 
>> x14: 7ff8242f x15: 7ff82435
>> x16: 7ff84388 x17: 7ff84388
>> x18: 7df1ade8 x19: 7df1aa80
>> x20: 7ff92cb8 x21: 7ff9f800
>> x22: 7ff9f000 x23: 0078
>> x24: 7ff9f8f0 x25: 
>> x26: 7ff9f800 x27: 7ff9f000
>> x28: 7ff9fb00 x29: 7df1aca0
>>
>> Resetting CPU ...
>>
>> resetting …
>>
>> Is this a known problem?
>
> Is this issue with usb?
> I have usb off on zcu102 that's why if this usb issue
> I am not aware about it.


 After a bit of digging, turns out it's CONFIG_BLK. If I disable that
 things
 work again (albeit without mmc access, since that one requires
 CONFIG_BLK
 now).
>>>
>>> I don't have a zynqmp device, so cannot test with that unfortunately.
>>
>>
>> Well, QEMU supports zcu102 emulation in the latest version, so you could
>> use
>> that to emulate the board:
>>
>>$ qemu-system-aarch64 -M xlnx-zcu102 -kernel u-boot.elf -nographic -m
>> 2G
>> -drive file=u-boot,id=d,if=none -device ide-drive,drive=d,bus=ide.0
>>
>> However, I don't see the data abort with the emulated device, only with
>> actual hardware. Probably because real hardware is more upset about
>> reading
>> from address 0 ;). But I can provoke the oops even in QEMU if I unmap the
>> first page from the memory map using the patch below.
>>
>> The oops happens in blk_dread because block_dev->bdev is NULL.
>
> Yes, this field really should be removed. As the comment says it's a
> hangover from pre-CONFIG_BLK where functions use a struct blk_dev * to
> specify the block device instead of a struct udevice *. It came up
> recently on a patch you sent also which is why I am so against using
> it.
>
> That said, I'm not sure why it is unset. The path should be:
>
> sdhci_bind()
> mmc_bind()
> blk_create_devicef()
> blk_create_device()
> which sets:
>
> desc->bdev = dev;
>
> [snip]


 The special case about ZynqMP is that it has 2 storage backends, one that
 uses DM (the sdhc controller) and one that isn't converted to DM (the AHCI
 controller). I guess something goes wrong with the latter.
>>>
>>> OK, well it would be good to convert it. It certainly won't work
>>> without it and I'm a little surprised that it compiles :-)
>>
>> probably good time to convert it. Driver itself has only sata init
>> sequence and then it is just compatible with ahci. That's why conversion
>> should be pretty easy.
>>
>> Simon: Which driver should I use as inspiration for 

Re: [U-Boot] image-fit: switch ENOLINK to ENOENT

[Tom Rini]

On Thu, Sep 08, 2016 at 11:53:48PM +1000, Jonathan Gray wrote:
> On Thu, Sep 08, 2016 at 09:15:45AM -0400, Tom Rini wrote:
> > On Thu, Sep 08, 2016 at 11:06:34PM +1000, Jonathan Gray wrote:
> > > On Thu, Sep 08, 2016 at 08:48:53AM -0400, Tom Rini wrote:
> > > > On Thu, Sep 08, 2016 at 10:01:52PM +1000, Jonathan Gray wrote:
> > > > > On Wed, Sep 07, 2016 at 02:00:19PM -0400, Tom Rini wrote:
> > > > > > On Sat, Sep 03, 2016 at 08:30:14AM +1000, Jonathan Gray wrote:
> > > > > > 
> > > > > > > ENOLINK is not required by POSIX and does not exist on OpenBSD
> > > > > > > and likely other systems.
> > > > > > > 
> > > > > > > Signed-off-by: Jonathan Gray 
> > > > > > 
> > > > > > Applied to u-boot/master, thanks!
> > > > > 
> > > > > Thanks for applying this and the other patch.
> > > > > 
> > > > > In tools/kwboot.c I've also locally changed EPROTO and EBADMSG as they
> > > > > aren't on OpenBSD either.
> > > > > 
> > > > > They are in POSIX however so I am trying to get them into OpenBSD,
> > > > > but it will need some time to be scheduled as introducing errnos
> > > > > involves cranking the major version of libc due to the size of the 
> > > > > array
> > > > > with errno strings changing.
> > > > > 
> > > > > I wasn't sure if the following would be accepted for that reason,
> > > > > thoughts?
> > > > 
> > > > Well, looking over the code in question, we're talking about error
> > > > handling during xmodem transfers.  What are the errno values that get
> > > > used there by xmodem tools?  Thanks!
> > > 
> > > I don't see how xmodem tools would use those errno values themselves?
> > > From what I understood, kwboot attaches directly to serial /dev devices
> > > and handles xmodem and terminal emulation itself.
> > > 
> > > In the kwboot case nothing in the return path seems to check for
> > > specific errno values.  The return sequence looks like
> > > 
> > > kwboot_xm_sendblock
> > > kwboot_xmodem
> > > main
> > > perror("xmodem");
> > 
> > Right.  But we're also using it to indicate to the caller that there was
> > a problem.  I can see using EIO for unknown error but I don't like
> > ECONNREFUSED for an explicit NAK.  So what I'm asking is, what's passed
> > around in other tools when you get a NAK reply in xmodem?
> 
> I haven't found any that display an errno based string
> 
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr.bin/cu/xmodem.c?rev=HEAD=text/plain
> 
> lrzsz src/lsz.c
> zperr(_("NAK on sector")); (prints to stderr non-fatally without errno)
> 
> kermit code seems to be quite hard to follow...
> 
> The list of errnos currently implemented on OpenBSD can be found here:
> http://man.openbsd.org/OpenBSD-current/man2/intro.2
> 
> The strings perror/strerror(errno) use can be found here
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/lib/libc/gen/errlist.c?rev=HEAD=text/plain
> And in the above manual page.
> 
> ENOMSG "No message of desired type." might work
> 
> Though it is documented as
> 
> "An IPC message queue does not contain a message of the desired type,
> or a message catalog does not contain the requested message."
> 
> on OpenBSD and in POSIX as
> 
> "No message of the desired type. The message queue does not contain a
> message of the required type during XSI interprocess communication."
> 
> Neither EBADMSG or ENOMSG appear to be documented in glibc beyond
> mentioning that they are valid values?
> 
> https://www.gnu.org/software/libc/manual/html_node/Error-Codes.html

EBADMSG and ENOMSG just fall back to POSIX.1.  Is it really hard to
carry a patch to U-Boot in OpenBSD until the libc can be updated for
some POSIX errno values?

-- 
Tom


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

Re: [U-Boot] [PATCH] armv8: ls1043a: Extend the size for SPL

[Ruchika Gupta]

Hi Qianyu,

There are plans to enable secure boot on LS1043 soon and it would require the 
SPL flow. The patches for same are already available on LS1020. 

Additionally we would also have drivers for CAAM for validation of next level 
image. Approx 48K of area needs to be reserved for this.  Out of this 48K , 
last 32K of space in OCRAM is reserved for use by Boot ROM and 16K needs to be 
reserved for header of uboot.

Is DEBUG being enabled by default in SPL ? What is the reason for increasing 
the functionality in SPL. Ideally SPL's role should be limited to DDR Init and 
copying of image from the boot source.

Regards,
Ruchika


-Original Message-
From: Q.Y. Gong 
Sent: Thursday, September 08, 2016 12:32 PM
To: Prabhakar Kushwaha ; york sun 
; Ruchika Gupta ; u-boot@lists.denx.de
Cc: Vincent Hu 
Subject: RE: [PATCH] armv8: ls1043a: Extend the size for SPL

Hi Prabhakar,

Does secure boot enable SPL on LS1043A?
I only see secure boot for NOR boot.

As there won't be enough space for SPL soon, I don't think it could support 
secure boot and SPL at the same time.

Regards,
Qianyu

> -Original Message-
> From: Prabhakar Kushwaha
> Sent: Thursday, September 08, 2016 2:35 PM
> To: Q.Y. Gong ; york sun ; 
> Ruchika Gupta ; u-boot@lists.denx.de
> Cc: Vincent Hu 
> Subject: RE: [PATCH] armv8: ls1043a: Extend the size for SPL
> 
> Hi Gong,
> 
> You have increased SPL size to 124KB. It is very high.
> As per my understanding 40K has been reserved for headers to be used 
> during secure boot.
> 
> Have you consider the secure boot case?
> 
> Regards,
> Prabhakar
> 
> > -Original Message-
> > From: Q.Y. Gong
> > Sent: Thursday, September 08, 2016 8:04 AM
> > To: york sun ; u-boot@lists.denx.de
> > Cc: Prabhakar Kushwaha ; Vincent Hu 
> > 
> > Subject: RE: [PATCH] armv8: ls1043a: Extend the size for SPL
> >
> > Hi York,
> >
> > > -Original Message-
> > > From: york sun
> > > Sent: Wednesday, September 07, 2016 11:36 PM
> > > To: Q.Y. Gong ; u-boot@lists.denx.de
> > > Cc: Prabhakar Kushwaha ; Vincent Hu 
> > > 
> > > Subject: Re: [PATCH] armv8: ls1043a: Extend the size for SPL
> > >
> > > On 09/07/2016 03:33 AM, Gong Qianyu wrote:
> > > > The SPL images are growing much bigger especially when DEBUG is ON.
> > > > So need to fix the values for them.
> > > >
> > > > Signed-off-by: Gong Qianyu 
> > > > ---
> > > >  include/configs/ls1043a_common.h | 25 -
> > > >  1 file changed, 16 insertions(+), 9 deletions(-)
> > > >
> > > > diff --git a/include/configs/ls1043a_common.h
> > > > b/include/configs/ls1043a_common.h
> > > > index e55fcb2..fa20e6d 100644
> > > > --- a/include/configs/ls1043a_common.h
> > > > +++ b/include/configs/ls1043a_common.h
> > > > @@ -69,16 +69,22 @@
> > > >  #define CONFIG_SPL_SERIAL_SUPPORT  #define 
> > > > CONFIG_SPL_DRIVERS_MISC_SUPPORT  #define
> CONFIG_SPL_MMC_SUPPORT
> > > > -#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR
> > >   0xf0
> > > > +#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR
> > >   0x110
> > > >  #define CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS 0x500
> > > >
> > > >  #define CONFIG_SPL_TEXT_BASE   0x1000
> > > > -#define CONFIG_SPL_MAX_SIZE0x1d000
> > > > -#define CONFIG_SPL_STACK   0x1001e000
> > > > -#define CONFIG_SPL_PAD_TO  0x1d000
> > > > +/*
> > > > + * CONFIG_SPL_MAX_SIZE is limited by OCRAM memory size(128 KiB) 
> > > > +and
> > > > + * a reserved stack size(4 KiB).
> > > > + * So notice that even if DEBUG is ON, the SPL
> > > > +image(spl/u-boot-spl.bin)
> > > > + * should not be > 124 KiB.
> > > > + */
> > >
> > > Qianyu,
> > >
> > > It is good to see comment here. However, I am concerned about your
> > calculation.
> > > Beside the image and stack, the early MMU tables are at the 
> > > beginning of
> > OCRAM.
> > > Did you count them?
> > >
> > > York
> >
> > No. We don't set up MMU tables in SPL stage on LS1043A/LS1046A.
> > Seems so far only LS2080A has done that in SPL.
> >
> >
> > Regards,
> > Qianyu

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

[U-Boot] [PATCH v6] spi: pl022_spi: Add support for ARM PL022 spi controller

[Michael Brandl]

Dear U-Boot (SPI) Developers,

this patch seems to be my only chance to get spi working without/before Linux.

I'm a student from Augsburg (Germany) experimenting with the Hikey Board from 
96boards.
The hi6220 processor from HiSilicon isn't fully documented, there is just one 
document called Function Description:
http://mirror.lemaker.org/Hi6220V100_Multi-Mode_Application_Processor_Function_Description.pdf

U-Boot already supports the Hikey Board to be loaded from ARM Trusted Firmware 
(ATF) but only UART and SDMMC is supported by now.
I cloned the u-boot-spi.git and tried to integrate this patch but I'm not 
experienced enough to adjust the specific config for the Hikey Board.

Taking a look at armv7 devices with spi support I started like this:

+++ b/arch/arm/include/asm/arch-hi6220/hi6220.h

+/*Hi6220V100_Multi-Mode_Application_Processor_Function_Description on p.5-45*/
+#define HI6220_SPI_BASE0xF7106000

 
+++ b/include/configs/hikey.h


+/* Synchronous Serial Port PL022 for SPI */
+#define CONFIG_PL022_SPI


+++ b/board/hisilicon/hikey/hikey.c

 int board_init(void)
 {
+#ifdef CONFIG_PL022_SPI
+   hikey_spi0_hw_init();
+#endif
return 0;
 }


+static void hikey_spi0_hw_init(void)
+{
+   hi6220_pinmux_config(PERIPH_ID_SPI0)
+// at91_set_pio_output(AT91_PIO_PORTC, 3, 1);  /* SPI0_CS0 */
+   gpio_request(0, "PWR_HOLD_GPIO0_0");
+   gpio_direction_output(0, 1);
+
+   /* Enable clock */
+// at91_periph_clk_enable(ATMEL_ID_SPI0);
+/* from Kernel { HI6220_SPI_CLK, "spi_clk", "clk_150m", 
CLK_SET_RATE_PARENT|CLK_IGNORE_UNUSED, 0x230, 9,  0, }, */
+   hi6220_clk_enable(PERI_CLK0_SPI0, _sc->clk3_en);
+
+}
+#endif /* CONFIG_PL022_SPI */
+
 


+++ b/arch/arm/cpu/armv8/hisilicon/pinmux.c
 
+static void hi6220_spi_config(int peripheral)

+{
+   switch (peripheral) {
+   case PERIPH_ID_SPI0:
+// at91_set_a_periph(AT91_PIO_PORTC, 0, 0);/* SPI0_MISO */
+// at91_set_a_periph(AT91_PIO_PORTC, 1, 0);/* SPI0_MOSI */
+// at91_set_a_periph(AT91_PIO_PORTC, 2, 0);/* SPI0_SPCK */
+   break;
+
+   case PERIPH_ID_SPI1:
+   break;
+
+   default:
+   debug("%s: invalid peripheral %d", __func__, peripheral);
+   return;
+   }
+}

Maybe you can help me to get spi working on Hikey. My overall aim is to port 
the pl022 driver then to ARM TF ... maybe also that could be interessing for 
you.

With kind Regards,
Michael Brandl



On Wed, Jan 8, 2014 at 2:49 PM, Armando Visconti
http://lists.denx.de/mailman/listinfo/u-boot>> 
wrote:
/Hello Jagan, />//>/Sorry for late reply. />//>//>//>/On 12/20/2013 8:03 PM, Jagan Teki wrote: />>//>>/On Fri, Oct 4, 2013 at 12:20 PM, Jagan Teki > />>/wrote: />>>//>>>/Hi Vipin, />>>//>>>/I have few quick comments, please fix it. />>>/Please use the u-boot-spi.git with master-probe branch for testing this />>>/driver. />>>/Let me know for any issues/concerns. />>>//>>>/On Wed, Jun 12, 2013 at 7:55 PM, Jagan Teki > />>>/wrote: ////Thanks for v6 sent. ////Have you tested this? //on which board, include/configs/*.h file? ////-- //Thanks, //Jagan. ////On Wed, Jun 12, 2013 at 6:17 PM, Armando Visconti //> wrote: />//>/This patch adds the support for the ARM PL022 SPI controller for the />/standard />/variant (0x00041022), which has a 16bit wide and 8 locations deep TX/RX />/FIFO. />//>/Signed-off-by: Armando Visconti > />/Signed-off-by: Vipin Kumar > />/Acked-by: Stefan Roese > />/--- />/v5->v6 />//>/1. Make use of spi_alloc_slave() macro. />/2. Changed the identation on 'if statement' as requested />/by Jagan. />//>/drivers/spi/Makefile | 1 + />/drivers/spi/pl022_spi.c | 308 />/ />/2 files changed, 309 insertions(+) />/create mode 100644 drivers/spi/pl022_spi.c />//>/diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile />/index d08609e..b6443b1 100644 />/--- a/drivers/spi/Makefile />/+++ b/drivers/spi/Makefile />/@@ -47,6 +47,7 @@ COBJS-$(CONFIG_MXC_SPI) += mxc_spi.o />/COBJS-$(CONFIG_MXS_SPI) += mxs_spi.o />/COBJS-$(CONFIG_OC_TINY_SPI) += oc_tiny_spi.o />/COBJS-$(CONFIG_OMAP3_SPI) += omap3_spi.o />/+COBJS-$(CONFIG_PL022_SPI) += pl022_spi.o />/COBJS-$(CONFIG_SOFT_SPI) += soft_spi.o />/COBJS-$(CONFIG_SH_SPI) += sh_spi.o />/COBJS-$(CONFIG_FSL_ESPI) += fsl_espi.o
 />/diff --git a/drivers/spi/pl022_spi.c b/drivers/spi/pl022_spi.c />/new file mode 100644 />/index 000..5b47413 />/--- 

[U-Boot] EHCI timed out on TD - token=0x80008d80

[Andreas Neubacher]

Hi Marek & Team :),

i'm facing the same issue as Manju and all the others on the web (see mail
below). i've tested it on different hardware-platforms and different
uboot-versions...
- ATMEL G45 (custom board), uboot 2015.01
- ATMEL G45 (custom board), uboot 2013.03
- ATMEL SAMA5D36 (custom board), uboot 2016.03
- ATMEL SAMA5D36 (custom board), uboot-mainline

what we did:
we are using usb-memory-sticks for updating our complete
system (rootfs, kernel, etc.) and somtimes copy files larger than 50MB from
USB to RAM (fatload usb 0 $loadaddr file.bin).
we've tested different speed-classes, different stick-sizes and different
quality-standards of the usb-sticks. from all the different type of sticks
we've tested, we found some 'bad sticks' where we get the error-msg

EHCI timed out on TD - token=0x9e008d80
EHCI timed out on TD - token=0x1e008d80
EHCI timed out on TD - token=0x1e008d80

... in all uboot-versions and on all different boards the behaviour is the same
-> so IMHO the issue depends on the 'bad usb-stick(s)' we are using.

so we investigated the 'bad usb-sticks' with different diagnostic-tools on
windows(10) and linux(ubuntu) host-machines without any result...

means: it looks like the 'bad-stick' on any host-machine is working as
expected (good r/w performance, no timeouts, no issues, etc.)


if i can do further investigations please let me know :)


br,
Andy



Hello Marek,


If the USB is detected successfully, then below are the logs.


U-Boot > usb start
(Re)start USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... New Device 0
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index
0x0 length 0x40
set address 1
usb_control_msg: request: 0x5, requesttype: 0x0, value 0x1 index 0x0 length 0x0
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index
0x0 length 0x12
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index
0x0 length 0x9
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index
0x0 length 0x19
get_conf_no 0 Result 25, wLength 25
if 0, ep 0
##EP epmaxpacketin[1] = 8
set configuration 1
usb_control_msg: request: 0x9, requesttype: 0x0, value 0x1 index 0x0 length 0x0
new device strings: Mfr=1, Product=2, SerialNumber=0
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x300 index
0x0 length 0xFF
USB device number 1 default language ID 0x1
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x301 index
0x1 length 0xFF
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x302 index
0x1 length 0xFF
Manufacturer u-boot
Product  EHCI Host Controller
SerialNumber
usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 index
0x0 length 0x4
usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 index
0x0 length 0x8
usb_control_msg: request: 0x0, requesttype: 0xA0, value 0x0 index 0x0 length 0x4
usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x1 length 0x0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4
usb_control_msg: request: 0x1, requesttype: 0x23, value 0x10 index 0x1
length 0x0
usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x1 length 0x0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4
usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x1
length 0x0
New Device 1
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index
0x0 length 0x40
usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x1 length 0x0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4
usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x1
length 0x0
set address 2
usb_control_msg: request: 0x5, requesttype: 0x0, value 0x2 index 0x0 length 0x0
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index
0x0 length 0x12
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index
0x0 length 0x9
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index
0x0 length 0x20
get_conf_no 0 Result 32, wLength 32
if 0, ep 0
if 0, ep 1
##EP epmaxpacketin[1] = 512
##EP epmaxpacketout[2] = 512
set configuration 1
usb_control_msg: request: 0x9, requesttype: 0x0, value 0x1 index 0x0 length 0x0
new device strings: Mfr=1, Product=2, SerialNumber=3
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x300 index
0x0 length 0xFF
USB device number 2 default language ID 0x409
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x301 index
0x409 length 0xFF
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x302 index
0x409 length 0xFF
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x303 index
0x409 length 0xFF
Manufacturer JetFlash
Product  Mass Storage Device
SerialNumber 99TL2DWA1OQMAIUS
2 USB Device(s) found
USB1:   USB EHCI 1.00
scanning bus 1 for devices... New Device 2
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index
0x0 

[U-Boot] ddr: Invalid SPD module type definitions for SO-DIMM with ECC

[Ralf Göbel]

Hi,

it think the SPD module type definitions for DDR4 SO-DIMM with ECC in the
file include/ddr_spd.h are swapped:

#define DDR4_SPD_MODULETYPE_72B_SO_UDIMM(0x08)
#define DDR4_SPD_MODULETYPE_72B_SO_RDIMM(0x09)

According to JEDEC document SPD4.1.2.L-4, UDIMM is 0x9 and RDIMM is 0x8.
Can someone verify this?

Regards,
Ralf

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

Re: [U-Boot] [PATCH] usb: gadget: ci_udc: fix suspend/resume of USB Mass Storage

[John Tobias]

Hi Fabio,

On Thu, Sep 8, 2016 at 4:05 AM, Fabio Estevam  wrote:
> Hi John,
>
> On Wed, Aug 24, 2016 at 2:25 AM, John Tobias  wrote:
>
>> I tried to following combinations below but, the return
>> SETUP(r.bRequestType, r.bRequest) doesn't match at all.
>>
>> SETUP(USB_DIR_IN | USB_RECIP_DEVICE, USB_REQ_GET_STATUS)
>> SETUP(USB_RECIP_DEVICE, USB_REQ_GET_STATUS)
>> SETUP(USB_DIR_IN, USB_REQ_GET_STATUS)
>>
>>> I don't think it's correct to remove the bRequestType checking altogether.
>>
>> Looking at the fsl_udc_core.c
>> http://lxr.free-electrons.com/source/drivers/usb/gadget/udc/fsl_udc_core.c#L1405
>> looks identical.
>
> This is the old udc driver for the non-dt imx.
>
> Currently we use drivers/usb/chipidea/udc.c, which also seems to match
> what you do in your patch.
>
> Regards,
>
> Fabio Estevam

Thanks for the info and clarification.

Btw, any updates with this patch?.

Regards,

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

[U-Boot] [RFC PATCH 1/2] dm: Add support for scsi/sata based devices

[Michal Simek]

All sata based drivers are bind and corresponding block
device is created. Based on this find_scsi_device() is able
to get back block device based on scsi_curr_dev pointer.

intr_scsi() is commented now but it can be replaced by calling
find_scsi_device() and scsi_scan().

scsi_dev_desc[] is commented out but common/scsi.c heavily depends on
it. That's why CONFIG_SYS_SCSI_MAX_DEVICE is hardcoded to 1 and symbol
is reassigned to a block description allocated by uclass.
There is only one block description by device now but it doesn't need to
be correct when more devices are present.

scsi_bind() ensures corresponding block device creation.
uclass post_probe (scsi_post_probe()) is doing low level init.

SCSI/SATA DM based drivers requires to have 64bit base address as
the first entry in platform data structure to setup mmio_base.

Signed-off-by: Michal Simek 
---

 cmd/scsi.c  | 38 ++
 common/board_r.c|  4 ++--
 common/scsi.c   | 17 -
 drivers/block/ahci-uclass.c | 38 ++
 drivers/block/ahci.c| 30 ++
 include/ahci.h  |  2 +-
 include/sata.h  |  3 +++
 include/scsi.h  | 15 ++-
 8 files changed, 134 insertions(+), 13 deletions(-)

diff --git a/cmd/scsi.c b/cmd/scsi.c
index 387ca1a262ab..dc1176610672 100644
--- a/cmd/scsi.c
+++ b/cmd/scsi.c
@@ -10,6 +10,7 @@
  */
 #include 
 #include 
+#include 
 #include 
 
 static int scsi_curr_dev; /* current device */
@@ -25,6 +26,23 @@ int do_scsiboot(cmd_tbl_t *cmdtp, int flag, int argc, char 
*const argv[])
 /*
  * scsi command intepreter
  */
+#ifdef CONFIG_DM_SATA
+struct udevice *find_scsi_device(int dev_num)
+{
+   struct udevice *bdev;
+   int ret;
+
+   ret = blk_get_device(IF_TYPE_SCSI, dev_num, );
+
+   if (ret) {
+   printf("SCSI Device %d not found\n", dev_num);
+   return NULL;
+   }
+
+   return bdev;
+}
+#endif
+
 int do_scsi(cmd_tbl_t *cmdtp, int flag, int argc, char *const argv[])
 {
switch (argc) {
@@ -35,7 +53,18 @@ int do_scsi(cmd_tbl_t *cmdtp, int flag, int argc, char 
*const argv[])
if (strncmp(argv[1], "res", 3) == 0) {
printf("\nReset SCSI\n");
scsi_bus_reset();
+
+#if defined(CONFIG_DM_SATA)
+   struct udevice *bdev;
+
+   bdev = find_scsi_device(scsi_curr_dev);
+   if (!bdev)
+   return CMD_RET_FAILURE;
+
+   scsi_scan(1, bdev);
+#else
scsi_scan(1);
+#endif
return 0;
}
if (strncmp(argv[1], "inf", 3) == 0) {
@@ -51,7 +80,16 @@ int do_scsi(cmd_tbl_t *cmdtp, int flag, int argc, char 
*const argv[])
return 0;
}
if (strncmp(argv[1], "scan", 4) == 0) {
+#if defined(CONFIG_DM_SATA)
+   struct udevice *bdev;
+
+   bdev = find_scsi_device(scsi_curr_dev);
+   if (!bdev)
+   return CMD_RET_FAILURE;
+   scsi_scan(1, bdev);
+#else
scsi_scan(1);
+#endif
return 0;
}
if (strncmp(argv[1], "part", 4) == 0) {
diff --git a/common/board_r.c b/common/board_r.c
index d959ad3c6f90..f3ea457507de 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -620,7 +620,7 @@ static int initr_ambapp_print(void)
 }
 #endif
 
-#if defined(CONFIG_SCSI)
+#if defined(CONFIG_SCSI) && !defined(CONFIG_DM_SATA)
 static int initr_scsi(void)
 {
puts("SCSI:  ");
@@ -923,7 +923,7 @@ init_fnc_t init_sequence_r[] = {
initr_ambapp_print,
 #endif
 #endif
-#ifdef CONFIG_SCSI
+#if defined(CONFIG_SCSI) && !defined(CONFIG_DM_SATA)
INIT_FUNC_WATCHDOG_RESET
initr_scsi,
 #endif
diff --git a/common/scsi.c b/common/scsi.c
index dbbf4043b22a..1726898b06e2 100644
--- a/common/scsi.c
+++ b/common/scsi.c
@@ -26,7 +26,7 @@
 #define SCSI_VEND_ID 0x10b9
 #define SCSI_DEV_ID  0x5288
 
-#elif !defined(CONFIG_SCSI_AHCI_PLAT)
+#elif !defined(CONFIG_SCSI_AHCI_PLAT) && !defined(CONFIG_DM_SATA)
 #error no scsi device defined
 #endif
 #define SCSI_DEV_LIST {SCSI_VEND_ID, SCSI_DEV_ID}
@@ -43,7 +43,13 @@ static int scsi_max_devs; /* number of highest available 
scsi device */
 
 static int scsi_curr_dev; /* current device */
 
+#if !defined(CONFIG_DM_SATA)
 static struct blk_desc scsi_dev_desc[CONFIG_SYS_SCSI_MAX_DEVICE];
+#else
+#undef CONFIG_SYS_SCSI_MAX_DEVICE
+#define CONFIG_SYS_SCSI_MAX_DEVICE 1
+#define CONFIG_SYS_SCSI_MAX_LUN1
+#endif
 
 /* almost the maximum amount of the scsi_ext command.. */
 #define SCSI_MAX_READ_BLK 0x
@@ -160,6 +166,7 @@ static ulong scsi_read(struct blk_desc *block_dev, 

[U-Boot] [RFC PATCH 2/2] block: Move ceva driver to DM

[Michal Simek]

This patch also includes ARM64 zynqmp changes:
- Remove platform non DM initialization
- Remove hardcoded sata base address

Signed-off-by: Michal Simek 
---

There are probably more things to test and to check but
on my platform I can connect only one HDD. But IP itself
have two ports which are not handled properly.
I have tried to reuse as much infrastructure as is available.
There need to be cleanup for SATA/SCSI/AHCI names.

There is also sata cmd and it is a question if make sense to keep it in
the tree because it is subset of scsi commands.

scsi scan needs to be called first and maybe make sense to call it
automatically as was done before.

Simon: Please check if I did it at least partially right.

TODO:
CONFIG_DM_SATA should be moved to Kconfig

LOG:

ZynqMP> scsi scan
SATA link 0 timeout.
Target spinup took 0 ms.
AHCI 0001.0301 32 slots 2 ports 6 Gbps 0x3 impl SATA mode
flags: 64bit ncq pm clo only pmp fbss pio slum part ccc apst
scanning bus for devices...
  Device 0: (1:0) Vendor: ATA Prod.: KINGSTON SVP200S Rev: 501A
Type: Hard Disk
Capacity: 57241.8 MB = 55.9 GB (117231408 x 512)
Found 1 device(s).
ZynqMP> ls sata 0
   4096 .
   4096 ..
   4096 bin
   4096 boot
   4096 dev
  12288 etc
   4096 home
   4096 lib
   4096 lost+found
   4096 media
   4096 mnt
   4096 opt
   4096 proc
   4096 root
   4096 run

---
 arch/arm/include/asm/arch-zynqmp/hardware.h |  2 --
 board/xilinx/zynqmp/zynqmp.c| 11 ---
 drivers/block/sata_ceva.c   | 49 +++--
 include/configs/xilinx_zynqmp.h |  7 +++--
 4 files changed, 52 insertions(+), 17 deletions(-)

diff --git a/arch/arm/include/asm/arch-zynqmp/hardware.h 
b/arch/arm/include/asm/arch-zynqmp/hardware.h
index 456c1b0902e5..3e311eed8765 100644
--- a/arch/arm/include/asm/arch-zynqmp/hardware.h
+++ b/arch/arm/include/asm/arch-zynqmp/hardware.h
@@ -18,8 +18,6 @@
 
 #define ARASAN_NAND_BASEADDR   0xFF10
 
-#define ZYNQMP_SATA_BASEADDR   0xFD0C
-
 #define ZYNQMP_USB0_XHCI_BASEADDR  0xFE20
 #define ZYNQMP_USB1_XHCI_BASEADDR  0xFE30
 
diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index 566b5e8d2afa..f96d5804f56f 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -300,17 +300,6 @@ void reset_cpu(ulong addr)
 {
 }
 
-#ifdef CONFIG_SCSI_AHCI_PLAT
-void scsi_init(void)
-{
-#if defined(CONFIG_SATA_CEVA)
-   init_sata(0);
-#endif
-   ahci_init((void __iomem *)ZYNQMP_SATA_BASEADDR);
-   scsi_scan(1);
-}
-#endif
-
 int board_late_init(void)
 {
u32 reg = 0;
diff --git a/drivers/block/sata_ceva.c b/drivers/block/sata_ceva.c
index dcc3b90b17f1..27b771d7f2a3 100644
--- a/drivers/block/sata_ceva.c
+++ b/drivers/block/sata_ceva.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -73,10 +74,9 @@
 #define DRV_NAME   "ahci-ceva"
 #define CEVA_FLAG_BROKEN_GEN2  1
 
-int init_sata(int dev)
+int ceva_init_sata(ulong mmio)
 {
ulong tmp;
-   ulong mmio = ZYNQMP_SATA_BASEADDR;
int i;
 
/*
@@ -111,3 +111,48 @@ int init_sata(int dev)
}
return 0;
 }
+
+static int sata_ceva_probe(struct udevice *dev)
+{
+   struct scsi_platdata *plat = dev_get_platdata(dev);
+
+   ceva_init_sata(plat->base);
+   return 0;
+}
+
+static int sata_ceva_bind(struct udevice *dev)
+{
+   int ret;
+
+   ret = scsi_bind(dev);
+   if (ret)
+   return ret;
+
+   return 0;
+}
+
+static const struct udevice_id sata_ceva_ids[] = {
+   { .compatible = "ceva,ahci-1v84" },
+   { }
+};
+
+static int sata_ceva_ofdata_to_platdata(struct udevice *dev)
+{
+   struct scsi_platdata *plat = dev_get_platdata(dev);
+
+   plat->base = dev_get_addr(dev);
+   if (plat->base == FDT_ADDR_T_NONE)
+   return -EINVAL;
+
+   return 0;
+}
+
+U_BOOT_DRIVER(ceva_host_blk) = {
+   .name = "ceva_sata",
+   .id = UCLASS_AHCI,
+   .of_match = sata_ceva_ids,
+   .bind = sata_ceva_bind,
+   .probe = sata_ceva_probe,
+   .ofdata_to_platdata = sata_ceva_ofdata_to_platdata,
+   .platdata_auto_alloc_size = sizeof(struct scsi_platdata),
+};
diff --git a/include/configs/xilinx_zynqmp.h b/include/configs/xilinx_zynqmp.h
index b9986bebe6e1..f7abb8e6c44c 100644
--- a/include/configs/xilinx_zynqmp.h
+++ b/include/configs/xilinx_zynqmp.h
@@ -189,15 +189,18 @@
 # define CONFIG_SYS_EEPROM_SIZE(64 * 1024)
 #endif
 
-#ifdef CONFIG_SATA_CEVA
+
+#if defined(CONFIG_SATA_CEVA) && !defined(CONFIG_SPL_BUILD)
+#define CONFIG_DM_SATA
 #define CONFIG_LIBATA
 #define CONFIG_SCSI_AHCI
-#define CONFIG_SCSI_AHCI_PLAT
 #define CONFIG_SYS_SCSI_MAX_SCSI_ID2
 #define CONFIG_SYS_SCSI_MAX_LUN1
 #define CONFIG_SYS_SCSI_MAX_DEVICE (CONFIG_SYS_SCSI_MAX_SCSI_ID * \

Re: [U-Boot] image-fit: switch ENOLINK to ENOENT

[Jonathan Gray]

On Thu, Sep 08, 2016 at 09:15:45AM -0400, Tom Rini wrote:
> On Thu, Sep 08, 2016 at 11:06:34PM +1000, Jonathan Gray wrote:
> > On Thu, Sep 08, 2016 at 08:48:53AM -0400, Tom Rini wrote:
> > > On Thu, Sep 08, 2016 at 10:01:52PM +1000, Jonathan Gray wrote:
> > > > On Wed, Sep 07, 2016 at 02:00:19PM -0400, Tom Rini wrote:
> > > > > On Sat, Sep 03, 2016 at 08:30:14AM +1000, Jonathan Gray wrote:
> > > > > 
> > > > > > ENOLINK is not required by POSIX and does not exist on OpenBSD
> > > > > > and likely other systems.
> > > > > > 
> > > > > > Signed-off-by: Jonathan Gray 
> > > > > 
> > > > > Applied to u-boot/master, thanks!
> > > > 
> > > > Thanks for applying this and the other patch.
> > > > 
> > > > In tools/kwboot.c I've also locally changed EPROTO and EBADMSG as they
> > > > aren't on OpenBSD either.
> > > > 
> > > > They are in POSIX however so I am trying to get them into OpenBSD,
> > > > but it will need some time to be scheduled as introducing errnos
> > > > involves cranking the major version of libc due to the size of the array
> > > > with errno strings changing.
> > > > 
> > > > I wasn't sure if the following would be accepted for that reason,
> > > > thoughts?
> > > 
> > > Well, looking over the code in question, we're talking about error
> > > handling during xmodem transfers.  What are the errno values that get
> > > used there by xmodem tools?  Thanks!
> > 
> > I don't see how xmodem tools would use those errno values themselves?
> > From what I understood, kwboot attaches directly to serial /dev devices
> > and handles xmodem and terminal emulation itself.
> > 
> > In the kwboot case nothing in the return path seems to check for
> > specific errno values.  The return sequence looks like
> > 
> > kwboot_xm_sendblock
> > kwboot_xmodem
> > main
> > perror("xmodem");
> 
> Right.  But we're also using it to indicate to the caller that there was
> a problem.  I can see using EIO for unknown error but I don't like
> ECONNREFUSED for an explicit NAK.  So what I'm asking is, what's passed
> around in other tools when you get a NAK reply in xmodem?

I haven't found any that display an errno based string

http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr.bin/cu/xmodem.c?rev=HEAD=text/plain

lrzsz src/lsz.c
zperr(_("NAK on sector")); (prints to stderr non-fatally without errno)

kermit code seems to be quite hard to follow...

The list of errnos currently implemented on OpenBSD can be found here:
http://man.openbsd.org/OpenBSD-current/man2/intro.2

The strings perror/strerror(errno) use can be found here
http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/lib/libc/gen/errlist.c?rev=HEAD=text/plain
And in the above manual page.

ENOMSG "No message of desired type." might work

Though it is documented as

"An IPC message queue does not contain a message of the desired type,
or a message catalog does not contain the requested message."

on OpenBSD and in POSIX as

"No message of the desired type. The message queue does not contain a
message of the required type during XSI interprocess communication."

Neither EBADMSG or ENOMSG appear to be documented in glibc beyond
mentioning that they are valid values?

https://www.gnu.org/software/libc/manual/html_node/Error-Codes.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V4 1/2] mmc: sd: extracting erase related information from sd status

[Jaehoon Chung]

Hi Peng,

On 09/08/2016 10:51 AM, Peng Fan wrote:
> On Thu, Sep 08, 2016 at 10:49:53AM +0900, Jaehoon Chung wrote:
>> Hi Peng,
>>
>> On 09/08/2016 10:42 AM, Peng Fan wrote:
>>> Hi Jaehoon,
>>> On Wed, Sep 07, 2016 at 03:52:53PM +0900, Jaehoon Chung wrote:
 Hi Peng,

 On 09/01/2016 12:13 PM, Peng Fan wrote:
> Add function to read SD_STATUS information.
> According to the information, get erase_timeout/erase_size/erase_offset.
> Add a structure sd_ssr to include the erase related information.

 Sorry for late..I'm testing with your patch on my SD-card.
 After that, I will apply yours. Before applied this, i will check more 
 carefully for not doing previous my mistake.
>>>
>>> The issue in the previous patch set is that linux/size.h is not included in 
>>> sandbox.h.
>>> In this patchset, I include linux/size.h in mmc.h:)
>>
>> Right, i have checked the test of building with your patch.
>> There is no problem..just i want to run your patch for erasing SD-card. 
>> Could you wait for one day?
> 
> Yeah. Ok for me :)

I have tested with your patch.. (Same command yours "time mmc erase 0x10 
0x2000")

Before applied your patch..it took 18.212 seconds

After applied your patch. 0.548 seconds. Great!

I applied on u-boot-mmc. Thanks!

> 
> Thanks,
> Peng.
> 
> 
> 

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

Re: [U-Boot] [PATCH v3 1/8] mmc: squash lines for immediate return

[Jaehoon Chung]

On 09/06/2016 10:17 PM, Masahiro Yamada wrote:
> These functions can be much simpler by squashing lines for immediate
> return.
> 
> For *_bind() callbacks, they will be a simple wrapper function of an
> upper-level bind API.
> 
> For mmc_set_{boot_bus_width,part_conf}, they will be a wrapper of
> mmc_switch().
> 
> Signed-off-by: Masahiro Yamada 

Reviewed-by: Jaehoon Chung 

Best Regards,
Jaehoon Chung

> ---
> 
> Changes in v3: None
> 
>  drivers/mmc/atmel_sdhci.c |  7 +--
>  drivers/mmc/exynos_dw_mmc.c   |  7 +--
>  drivers/mmc/mmc_boot.c| 28 
>  drivers/mmc/msm_sdhci.c   |  7 +--
>  drivers/mmc/rockchip_dw_mmc.c |  7 +--
>  drivers/mmc/rockchip_sdhci.c  |  7 +--
>  drivers/mmc/sandbox_mmc.c |  7 +--
>  drivers/mmc/zynq_sdhci.c  |  7 +--
>  8 files changed, 15 insertions(+), 62 deletions(-)
> 
> diff --git a/drivers/mmc/atmel_sdhci.c b/drivers/mmc/atmel_sdhci.c
> index dd6bd33..d8f8087 100644
> --- a/drivers/mmc/atmel_sdhci.c
> +++ b/drivers/mmc/atmel_sdhci.c
> @@ -136,13 +136,8 @@ static int atmel_sdhci_probe(struct udevice *dev)
>  static int atmel_sdhci_bind(struct udevice *dev)
>  {
>   struct atmel_sdhci_plat *plat = dev_get_platdata(dev);
> - int ret;
>  
> - ret = sdhci_bind(dev, >mmc, >cfg);
> - if (ret)
> - return ret;
> -
> - return 0;
> + return sdhci_bind(dev, >mmc, >cfg);
>  }
>  
>  static const struct udevice_id atmel_sdhci_ids[] = {
> diff --git a/drivers/mmc/exynos_dw_mmc.c b/drivers/mmc/exynos_dw_mmc.c
> index 57271f1..568fed7 100644
> --- a/drivers/mmc/exynos_dw_mmc.c
> +++ b/drivers/mmc/exynos_dw_mmc.c
> @@ -284,13 +284,8 @@ static int exynos_dwmmc_probe(struct udevice *dev)
>  static int exynos_dwmmc_bind(struct udevice *dev)
>  {
>   struct exynos_mmc_plat *plat = dev_get_platdata(dev);
> - int ret;
>  
> - ret = dwmci_bind(dev, >mmc, >cfg);
> - if (ret)
> - return ret;
> -
> - return 0;
> + return dwmci_bind(dev, >mmc, >cfg);
>  }
>  
>  static const struct udevice_id exynos_dwmmc_ids[] = {
> diff --git a/drivers/mmc/mmc_boot.c b/drivers/mmc/mmc_boot.c
> index 756a982..ac6f56f 100644
> --- a/drivers/mmc/mmc_boot.c
> +++ b/drivers/mmc/mmc_boot.c
> @@ -85,16 +85,10 @@ int mmc_boot_partition_size_change(struct mmc *mmc, 
> unsigned long bootsize,
>   */
>  int mmc_set_boot_bus_width(struct mmc *mmc, u8 width, u8 reset, u8 mode)
>  {
> - int err;
> -
> - err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_BOOT_BUS_WIDTH,
> -  EXT_CSD_BOOT_BUS_WIDTH_MODE(mode) |
> -  EXT_CSD_BOOT_BUS_WIDTH_RESET(reset) |
> -  EXT_CSD_BOOT_BUS_WIDTH_WIDTH(width));
> -
> - if (err)
> - return err;
> - return 0;
> + return mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_BOOT_BUS_WIDTH,
> +   EXT_CSD_BOOT_BUS_WIDTH_MODE(mode) |
> +   EXT_CSD_BOOT_BUS_WIDTH_RESET(reset) |
> +   EXT_CSD_BOOT_BUS_WIDTH_WIDTH(width));
>  }
>  
>  /*
> @@ -106,16 +100,10 @@ int mmc_set_boot_bus_width(struct mmc *mmc, u8 width, 
> u8 reset, u8 mode)
>   */
>  int mmc_set_part_conf(struct mmc *mmc, u8 ack, u8 part_num, u8 access)
>  {
> - int err;
> -
> - err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_PART_CONF,
> -  EXT_CSD_BOOT_ACK(ack) |
> -  EXT_CSD_BOOT_PART_NUM(part_num) |
> -  EXT_CSD_PARTITION_ACCESS(access));
> -
> - if (err)
> - return err;
> - return 0;
> + return mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_PART_CONF,
> +   EXT_CSD_BOOT_ACK(ack) |
> +   EXT_CSD_BOOT_PART_NUM(part_num) |
> +   EXT_CSD_PARTITION_ACCESS(access));
>  }
>  
>  /*
> diff --git a/drivers/mmc/msm_sdhci.c b/drivers/mmc/msm_sdhci.c
> index 8d4399e..1b82991 100644
> --- a/drivers/mmc/msm_sdhci.c
> +++ b/drivers/mmc/msm_sdhci.c
> @@ -190,13 +190,8 @@ static int msm_ofdata_to_platdata(struct udevice *dev)
>  static int msm_sdc_bind(struct udevice *dev)
>  {
>   struct msm_sdhc_plat *plat = dev_get_platdata(dev);
> - int ret;
>  
> - ret = sdhci_bind(dev, >mmc, >cfg);
> - if (ret)
> - return ret;
> -
> - return 0;
> + return sdhci_bind(dev, >mmc, >cfg);
>  }
>  
>  static const struct udevice_id msm_mmc_ids[] = {
> diff --git a/drivers/mmc/rockchip_dw_mmc.c b/drivers/mmc/rockchip_dw_mmc.c
> index 020a59b..859760b 100644
> --- a/drivers/mmc/rockchip_dw_mmc.c
> +++ b/drivers/mmc/rockchip_dw_mmc.c
> @@ -142,13 +142,8 @@ static int rockchip_dwmmc_probe(struct udevice *dev)
>  static int rockchip_dwmmc_bind(struct udevice *dev)
>  {
>   struct rockchip_mmc_plat *plat = dev_get_platdata(dev);
> - int ret;
>  
> - ret = dwmci_bind(dev, >mmc, >cfg);
> - if (ret)
> - return ret;

Re: [U-Boot] [PATCH 1/4] Revert "sunxi: Move the SPL stack top to 0x1A000 on Allwinner A64/A80"

[Andre Przywara]

Hi,

On 08/09/16 11:51, Siarhei Siamashka wrote:
> On Mon, 5 Sep 2016 09:23:00 +0100
> Andre Przywara  wrote:
> 
>> Hi,
>>
>> On 05/09/16 05:12, Siarhei Siamashka wrote:
>>> On Mon,  5 Sep 2016 01:32:38 +0100
>>> Andre Przywara  wrote:
>>>   
 This commit moved the SPL stack into SRAM C, which worked when the SPL
 set the AHB1 clock down to 100 MHz to cope with the flaky SRAM C access
 from the CPU.
 However booting with boot0 (and thus not using SPL at all) we still run
 with a 200 MHz AHB1, so any access to SRAM C is prone to fail.
 Since this commit does _not_ only affect the SPL code, but also the
 U-Boot proper, we fail when booting with boot0.  
>>>
>>> Yes, it unfortunately affected both the SPL and the U-Boot
>>> proper because currently both CONFIG_SPL_STACK and
>>> CONFIG_SYS_INIT_SP_ADDR defines affect the SPL stack
>>> location and in practice this only works in a predictable
>>> way if they are set to the same value. I have sent a patch
>>> to address this problem (but the fix may be unsafe for
>>> v2016.09 because many ARM platforms are affected):
>>>
>>> https://patchwork.ozlabs.org/patch/665608/
>>>
>>> After this problem is resolved, the CONFIG_SYS_INIT_SP_ADDR
>>> define can be decoupled from CONFIG_SPL_STACK and configured to
>>> even use the DRAM instead of thrashing some part of the scarce
>>> SRAM space (which may be already occupied by the OpenRISC
>>> firmware and/or the ATF at the time when the U-Boot proper is
>>> starting).
>>>   
 As the introduction of tiny-printf reduced the size of the SPL, we
 can afford to have the SPL stack in SRAM A1.  
>>>
>>> We still need to check how much space is really available. The FIT
>>> support is rather heavyweight and we may want to enable some other
>>> features too.  
>>
>> Yes, I had to learn this yesterday ;-)
>> So 64-bit SPL works for me now with Jens' DRAM support patches (yeah!),
>> but enabling FIT support makes mksunxiboot barf about the file being to
>> big. The actual SPL code is about 31K, so maybe I can talk mksunxiboot
>> into relaxing its alignment requirements a bit (from 8K down to 512) and
>> also increase the available SRAM size - it says 0x7600 for sun4i, is
>> this still true to newer SoCs/BROMs?
> 
> We have this information in the linux-sunxi wiki since a long time ago
> (at least for the SoC variants that I have and could experiment with)
> and it is available here:
> 
> https://linux-sunxi.org/BROM#U-Boot_SPL_limitations
> 
> All the new SoCs have a 32K size limit for the SPL code, which can be
> loaded by the BROM. Older A10/A20 SoCs artificially limit it to 24K,
> probably trying to forcefully encourage the users to have 8K stack in
> the remaining part of the SRAM A1.
> 
> On A64, we have 32K of SRAM A1. Then we have 108K of SRAM C, which is a
> continuation of SRAM A1 in the address space thus making it look like a
> nice single 140K chunk. Then we also have 64K of SRAM A2, which is
> supposed to be used by the OpenRISC core and is the only memory area,
> which has a reasonable performance when used by OpenRISC:
> 
> https://linux-sunxi.org/AR100#Memory_Map
> 
> The idea was to let the BROM load up to 32K of the SPL code to the
> SRAM A1 (like it normally does) and then have 8K of stack a bit higher
> in the address space in SRAM C. But it turned out that the SRAM C is a
> bit quirky and suffers from data corruption problems if we reclock
> AHB1 too early.
> 
> Now there are two possible ways to move forward on A64:
>   1) Try to use SRAM C in such a way that it does not fail (and hope
>  that no additional quirks get discovered later).
>   2) Move the initial SPL stack to SRAM A2.
> 
> If we move everything to SRAM A2, then we will have to make sure that
> all the SRAM users (the FEL storage area, the SPL stack, the ATF and
> the yet to be implemented OpenRISC firmware) never clash with each
> other.

So I moved the initial stack into SRAM A2 already, which made SPL to
work in AArch64 (in contrast to having the stack at the end of SRAM A1,
which breaks quite early - though I managed to see the SPL banner ;-)
But I agree that we need to teach FEL about it as well and this may
break actually loading things like ATF into SRAM A2 with FEL then.

> About the 31K code size. This does not look good and is very close to
> the BROM limit (32K). Just using a different compiler may bring us into
> a trouble. Or some minor code tweaks and feature additions.

I totally agree. A nasty drawback is already that I can't enable debug.

>> Trying this in the past (with libdram) and compiling for (32-bit) Thumb2
>> worked, but I need to check what the actual size with Jens' patches are
>> these days for Thumb2.
> 
> We have already discussed this off-list a long time ago. I know that
> both you and Alexander Graf are generally in favour of compiling the
> SPL as 64-bit code.
> 
> I think that this is the usual case of utility versus 

Re: [U-Boot] image-fit: switch ENOLINK to ENOENT

[Tom Rini]

On Thu, Sep 08, 2016 at 11:06:34PM +1000, Jonathan Gray wrote:
> On Thu, Sep 08, 2016 at 08:48:53AM -0400, Tom Rini wrote:
> > On Thu, Sep 08, 2016 at 10:01:52PM +1000, Jonathan Gray wrote:
> > > On Wed, Sep 07, 2016 at 02:00:19PM -0400, Tom Rini wrote:
> > > > On Sat, Sep 03, 2016 at 08:30:14AM +1000, Jonathan Gray wrote:
> > > > 
> > > > > ENOLINK is not required by POSIX and does not exist on OpenBSD
> > > > > and likely other systems.
> > > > > 
> > > > > Signed-off-by: Jonathan Gray 
> > > > 
> > > > Applied to u-boot/master, thanks!
> > > 
> > > Thanks for applying this and the other patch.
> > > 
> > > In tools/kwboot.c I've also locally changed EPROTO and EBADMSG as they
> > > aren't on OpenBSD either.
> > > 
> > > They are in POSIX however so I am trying to get them into OpenBSD,
> > > but it will need some time to be scheduled as introducing errnos
> > > involves cranking the major version of libc due to the size of the array
> > > with errno strings changing.
> > > 
> > > I wasn't sure if the following would be accepted for that reason,
> > > thoughts?
> > 
> > Well, looking over the code in question, we're talking about error
> > handling during xmodem transfers.  What are the errno values that get
> > used there by xmodem tools?  Thanks!
> 
> I don't see how xmodem tools would use those errno values themselves?
> From what I understood, kwboot attaches directly to serial /dev devices
> and handles xmodem and terminal emulation itself.
> 
> In the kwboot case nothing in the return path seems to check for
> specific errno values.  The return sequence looks like
> 
> kwboot_xm_sendblock
> kwboot_xmodem
> main
> perror("xmodem");

Right.  But we're also using it to indicate to the caller that there was
a problem.  I can see using EIO for unknown error but I don't like
ECONNREFUSED for an explicit NAK.  So what I'm asking is, what's passed
around in other tools when you get a NAK reply in xmodem?

-- 
Tom


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

Re: [U-Boot] image-fit: switch ENOLINK to ENOENT

[Jonathan Gray]

On Thu, Sep 08, 2016 at 08:48:53AM -0400, Tom Rini wrote:
> On Thu, Sep 08, 2016 at 10:01:52PM +1000, Jonathan Gray wrote:
> > On Wed, Sep 07, 2016 at 02:00:19PM -0400, Tom Rini wrote:
> > > On Sat, Sep 03, 2016 at 08:30:14AM +1000, Jonathan Gray wrote:
> > > 
> > > > ENOLINK is not required by POSIX and does not exist on OpenBSD
> > > > and likely other systems.
> > > > 
> > > > Signed-off-by: Jonathan Gray 
> > > 
> > > Applied to u-boot/master, thanks!
> > 
> > Thanks for applying this and the other patch.
> > 
> > In tools/kwboot.c I've also locally changed EPROTO and EBADMSG as they
> > aren't on OpenBSD either.
> > 
> > They are in POSIX however so I am trying to get them into OpenBSD,
> > but it will need some time to be scheduled as introducing errnos
> > involves cranking the major version of libc due to the size of the array
> > with errno strings changing.
> > 
> > I wasn't sure if the following would be accepted for that reason,
> > thoughts?
> 
> Well, looking over the code in question, we're talking about error
> handling during xmodem transfers.  What are the errno values that get
> used there by xmodem tools?  Thanks!

I don't see how xmodem tools would use those errno values themselves?
>From what I understood, kwboot attaches directly to serial /dev devices
and handles xmodem and terminal emulation itself.

In the kwboot case nothing in the return path seems to check for
specific errno values.  The return sequence looks like

kwboot_xm_sendblock
kwboot_xmodem
main
perror("xmodem");
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 2/2] dts: rk3288: remove node in dmc which not need anymore

[Kever Yang]

Since we implement the dram capacity auto detect, we don't
need to set the channel number and sdram-channel in dts.

Signed-off-by: Kever Yang 
---

 arch/arm/dts/rk3288-evb.dts  | 3 ---
 arch/arm/dts/rk3288-fennec.dts   | 3 ---
 arch/arm/dts/rk3288-firefly.dts  | 2 --
 arch/arm/dts/rk3288-miniarm.dts  | 3 ---
 arch/arm/dts/rk3288-popmetal.dts | 3 ---
 arch/arm/dts/rk3288-rock2-square.dts | 2 --
 arch/arm/dts/rk3288-veyron.dtsi  | 2 --
 7 files changed, 18 deletions(-)

diff --git a/arch/arm/dts/rk3288-evb.dts b/arch/arm/dts/rk3288-evb.dts
index 3e1ee58..3f03e13 100644
--- a/arch/arm/dts/rk3288-evb.dts
+++ b/arch/arm/dts/rk3288-evb.dts
@@ -17,7 +17,6 @@
 };
 
  {
-   rockchip,num-channels = <2>;
rockchip,pctl-timing = <0x215 0xc8 0x0 0x35 0x26 0x2 0x70 0x2000d
0x6 0x0 0x8 0x4 0x17 0x24 0xd 0x6
0x4 0x8 0x4 0x76 0x4 0x0 0x30 0x0
@@ -25,8 +24,6 @@
0x8 0x1f4>;
rockchip,phy-timing = <0x48d7dd93 0x187008d8 0x121076
0x0 0xc3 0x6 0x2>;
-   /* Add a dummy value to cause of-platdata think this is bytes */
-   rockchip,sdram-channel = /bits/ 8 <0x2 0xa 0x3 0x2 0x2 0x0 0xe 0xe 
0xff>;
rockchip,sdram-params = <0x20d266a4 0x5b6 2 53300 6 9 0>;
 };
 
diff --git a/arch/arm/dts/rk3288-fennec.dts b/arch/arm/dts/rk3288-fennec.dts
index 36e9f3d..66ddf8d 100644
--- a/arch/arm/dts/rk3288-fennec.dts
+++ b/arch/arm/dts/rk3288-fennec.dts
@@ -17,7 +17,6 @@
 };
 
  {
-   rockchip,num-channels = <2>;
rockchip,pctl-timing = <0x215 0xc8 0x0 0x35 0x26 0x2 0x70 0x2000d
0x6 0x0 0x8 0x4 0x17 0x24 0xd 0x6
0x4 0x8 0x4 0x76 0x4 0x0 0x30 0x0
@@ -25,8 +24,6 @@
0x8 0x1f4>;
rockchip,phy-timing = <0x48d7dd93 0x187008d8 0x121076
0x0 0xc3 0x6 0x2>;
-   /* Add a dummy value to cause of-platdata think this is bytes */
-   rockchip,sdram-channel = /bits/ 8 <0x2 0xa 0x3 0x2 0x2 0x0 0xe 0xe 
0xff>;
rockchip,sdram-params = <0x20d266a4 0x5b6 2 53300 6 9 0>;
 };
 
diff --git a/arch/arm/dts/rk3288-firefly.dts b/arch/arm/dts/rk3288-firefly.dts
index 3176d50..97568a3 100644
--- a/arch/arm/dts/rk3288-firefly.dts
+++ b/arch/arm/dts/rk3288-firefly.dts
@@ -22,7 +22,6 @@
 };
 
  {
-   rockchip,num-channels = <2>;
rockchip,pctl-timing = <0x29a 0xc8 0x1f8 0x42 0x4e 0x4 0xea 0xa
0x5 0x0 0xa 0x7 0x19 0x24 0xa 0x7
0x5 0xa 0x5 0x200 0x5 0x10 0x40 0x0
@@ -31,7 +30,6 @@
rockchip,phy-timing = <0x48f9aab4 0xea0910 0x1002c200
0xa60 0x40 0x10 0x0>;
/* Add a dummy value to cause of-platdata think this is bytes */
-   rockchip,sdram-channel = /bits/ 8 <0x1 0xa 0x3 0x2 0x1 0x0 0xf 0xf 
0xff>;
rockchip,sdram-params = <0x30B25564 0x627 3 66600 3 9 1>;
 };
 
diff --git a/arch/arm/dts/rk3288-miniarm.dts b/arch/arm/dts/rk3288-miniarm.dts
index c741082..9083028 100644
--- a/arch/arm/dts/rk3288-miniarm.dts
+++ b/arch/arm/dts/rk3288-miniarm.dts
@@ -17,7 +17,6 @@
 };
 
  {
-   rockchip,num-channels = <2>;
rockchip,pctl-timing = <0x29a 0xc8 0x1f8 0x42 0x4e 0x4 0xea 0xa
0x5 0x0 0xa 0x7 0x19 0x24 0xa 0x7
0x5 0xa 0x5 0x200 0x5 0x10 0x40 0x0
@@ -25,8 +24,6 @@
0x5 0x0>;
rockchip,phy-timing = <0x48f9aab4 0xea0910 0x1002c200
0xa60 0x40 0x10 0x0>;
-   /* Add a dummy value to cause of-platdata think this is bytes */
-   rockchip,sdram-channel = /bits/ 8 <0x1 0xa 0x3 0x2 0x1 0x0 0xf 0xf 
0xff>;
rockchip,sdram-params = <0x30B25564 0x627 3 66600 3 9 1>;
 };
 
diff --git a/arch/arm/dts/rk3288-popmetal.dts b/arch/arm/dts/rk3288-popmetal.dts
index 3f61a61..284d5ed 100644
--- a/arch/arm/dts/rk3288-popmetal.dts
+++ b/arch/arm/dts/rk3288-popmetal.dts
@@ -17,7 +17,6 @@
 };
 
  {
-   rockchip,num-channels = <2>;
rockchip,pctl-timing = <0x29a 0xc8 0x1f8 0x42 0x4e 0x4 0xea 0xa
0x5 0x0 0xa 0x7 0x19 0x24 0xa 0x7
0x5 0xa 0x5 0x200 0x5 0x10 0x40 0x0
@@ -25,8 +24,6 @@
0x5 0x0>;
rockchip,phy-timing = <0x48f9aab4 0xea0910 0x1002c200
0xa60 0x40 0x10 0x0>;
-   /* Add a dummy value to cause of-platdata think this is bytes */
-   rockchip,sdram-channel = /bits/ 8 <0x1 0xa 0x3 0x2 0x1 0x0 0xf 0xf 
0xff>;
rockchip,sdram-params = <0x30B25564 0x627 3 66600 3 9 1>;
 };
 
diff --git a/arch/arm/dts/rk3288-rock2-square.dts 
b/arch/arm/dts/rk3288-rock2-square.dts
index 2c30355..11c580a 100644
--- a/arch/arm/dts/rk3288-rock2-square.dts
+++ b/arch/arm/dts/rk3288-rock2-square.dts
@@ -184,7 +184,6 @@
 };
 
  {
-   rockchip,num-channels = <2>;
rockchip,pctl-timing = <0x29a 0xc8 0x1f8 0x42 0x4e 0x4 0xea 0xa
0x5 0x0 0xa 0x7 0x19 0x24 0xa 0x7
0x5 0xa 0x5 0x200 0x5 0x10 0x40 0x0
@@ -192,7 +191,6 @@
0x5 0x0>;

[U-Boot] [PATCH 1/2] rk3288: sdram: auto-detect the capacity

[Kever Yang]

Add support for rk3288 dram capacity auto detect, support DDR3 and
LPDDR3, DDR2 is not supported.
The program will automatically detect:
- channel number
- rank number
- column address number
- row address number

The dts file do not need to describe those info after apply this patch.

Signed-off-by: Kever Yang 
---

 arch/arm/mach-rockchip/rk3288/sdram_rk3288.c | 237 ++-
 1 file changed, 198 insertions(+), 39 deletions(-)

diff --git a/arch/arm/mach-rockchip/rk3288/sdram_rk3288.c 
b/arch/arm/mach-rockchip/rk3288/sdram_rk3288.c
index cf9ef2e..faabbd4 100644
--- a/arch/arm/mach-rockchip/rk3288/sdram_rk3288.c
+++ b/arch/arm/mach-rockchip/rk3288/sdram_rk3288.c
@@ -57,6 +57,10 @@ struct rk3288_sdram_params {
struct regmap *map;
 };
 
+#define TEST_PATTEN0x5aa5f00f
+#define DQS_GATE_TRAINING_ERROR_RANK0  (1 << 4)
+#define DQS_GATE_TRAINING_ERROR_RANK1  (2 << 4)
+
 #ifdef CONFIG_SPL_BUILD
 static void copy_to_reg(u32 *dest, const u32 *src, u32 n)
 {
@@ -214,7 +218,7 @@ static void ddr_set_en_bst_odt(struct rk3288_grf *grf, uint 
channel,
 }
 
 static void pctl_cfg(u32 channel, struct rk3288_ddr_pctl *pctl,
-const struct rk3288_sdram_params *sdram_params,
+struct rk3288_sdram_params *sdram_params,
 struct rk3288_grf *grf)
 {
unsigned int burstlen;
@@ -264,7 +268,7 @@ static void pctl_cfg(u32 channel, struct rk3288_ddr_pctl 
*pctl,
 }
 
 static void phy_cfg(const struct chan_info *chan, u32 channel,
-   const struct rk3288_sdram_params *sdram_params)
+   struct rk3288_sdram_params *sdram_params)
 {
struct rk3288_ddr_publ *publ = chan->publ;
struct rk3288_msch *msch = chan->msch;
@@ -446,7 +450,7 @@ static void set_bandwidth_ratio(const struct chan_info 
*chan, u32 channel,
 }
 
 static int data_training(const struct chan_info *chan, u32 channel,
-const struct rk3288_sdram_params *sdram_params)
+struct rk3288_sdram_params *sdram_params)
 {
unsigned int j;
int ret = 0;
@@ -549,7 +553,7 @@ static void move_to_access_state(const struct chan_info 
*chan)
 }
 
 static void dram_cfg_rbc(const struct chan_info *chan, u32 chnum,
-const struct rk3288_sdram_params *sdram_params)
+struct rk3288_sdram_params *sdram_params)
 {
struct rk3288_ddr_publ *publ = chan->publ;
 
@@ -563,7 +567,7 @@ static void dram_cfg_rbc(const struct chan_info *chan, u32 
chnum,
 }
 
 static void dram_all_config(const struct dram_info *dram,
-   const struct rk3288_sdram_params *sdram_params)
+   struct rk3288_sdram_params *sdram_params)
 {
unsigned int chan;
u32 sys_reg = 0;
@@ -589,9 +593,173 @@ static void dram_all_config(const struct dram_info *dram,
writel(sys_reg, >pmu->sys_reg[2]);
rk_clrsetreg(>sgrf->soc_con2, 0x1f, sdram_params->base.stride);
 }
+const int ddrconf_table[] = {
+   /* col  row */
+   0,
+   ((1 << 4) | 1),
+   ((2 << 4) | 1),
+   ((3 << 4) | 1),
+   ((4 << 4) | 1),
+   ((1 << 4) | 2),
+   ((2 << 4) | 2),
+   ((3 << 4) | 2),
+   ((1 << 4) | 0),
+   ((2 << 4) | 0),
+   ((3 << 4) | 0),
+   0,
+   0,
+   0,
+   0,
+   ((4 << 4) | 2),
+};
+
+static int sdram_rank_bw_detect(struct dram_info *dram, int channel,
+   struct rk3288_sdram_params *sdram_params)
+{
+   int reg;
+   int need_trainig = 0;
+   const struct chan_info *chan = >chan[channel];
+   struct rk3288_ddr_publ *publ = chan->publ;
+
+   if (-1 == data_training(chan, channel, sdram_params)) {
+   reg = readl(>datx8[0].dxgsr[0]);
+   /* Check the result for rank 0 */
+   if ((channel == 0) && (reg & DQS_GATE_TRAINING_ERROR_RANK0)) {
+   debug("data training fail!\n");
+   return -EIO;
+   } else if ((channel == 1) &&
+  (reg & DQS_GATE_TRAINING_ERROR_RANK0)) {
+   sdram_params->num_channels = 1;
+   }
+
+   /* Check the result for rank 1 */
+   if (reg & DQS_GATE_TRAINING_ERROR_RANK1) {
+   sdram_params->ch[channel].rank = 1;
+   clrsetbits_le32(>pgcr, 0xF << 18,
+   sdram_params->ch[channel].rank << 18);
+   need_trainig = 1;
+   }
+   reg = readl(>datx8[2].dxgsr[0]);
+   if (reg & (1 << 4)) {
+   sdram_params->ch[channel].bw = 1;
+   set_bandwidth_ratio(chan, channel,
+   sdram_params->ch[channel].bw,
+   dram->grf);
+   need_trainig = 1;
+   }

[U-Boot] [PATCH 0/2] Add sdram capacity auto detect for rk3288

[Kever Yang]

The rk3288 spl size is very close to 32KB while the rk3288 bootrom
has the limitation of maximum size of SPL is 32KB. After apply this
patch, the SPL size will exceed 32KB if we do not enable macro
CONFIG_ROCKCHIP_SPL_BACK_TO_BROM.

I think this patch is usful and should be go upstream other than the
size issue.

This patch has test with 2GB DDR3 and 2GB/4GB LPDDR3.



Kever Yang (2):
  rk3288: sdram: auto-detect the capacity
  dts: rk3288: remove node in dmc which not need anymore

 arch/arm/dts/rk3288-evb.dts  |   3 -
 arch/arm/dts/rk3288-fennec.dts   |   3 -
 arch/arm/dts/rk3288-firefly.dts  |   2 -
 arch/arm/dts/rk3288-miniarm.dts  |   3 -
 arch/arm/dts/rk3288-popmetal.dts |   3 -
 arch/arm/dts/rk3288-rock2-square.dts |   2 -
 arch/arm/dts/rk3288-veyron.dtsi  |   2 -
 arch/arm/mach-rockchip/rk3288/sdram_rk3288.c | 237 ++-
 8 files changed, 198 insertions(+), 57 deletions(-)

-- 
1.9.1

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

Re: [U-Boot] image-fit: switch ENOLINK to ENOENT

[Tom Rini]

On Thu, Sep 08, 2016 at 10:01:52PM +1000, Jonathan Gray wrote:
> On Wed, Sep 07, 2016 at 02:00:19PM -0400, Tom Rini wrote:
> > On Sat, Sep 03, 2016 at 08:30:14AM +1000, Jonathan Gray wrote:
> > 
> > > ENOLINK is not required by POSIX and does not exist on OpenBSD
> > > and likely other systems.
> > > 
> > > Signed-off-by: Jonathan Gray 
> > 
> > Applied to u-boot/master, thanks!
> 
> Thanks for applying this and the other patch.
> 
> In tools/kwboot.c I've also locally changed EPROTO and EBADMSG as they
> aren't on OpenBSD either.
> 
> They are in POSIX however so I am trying to get them into OpenBSD,
> but it will need some time to be scheduled as introducing errnos
> involves cranking the major version of libc due to the size of the array
> with errno strings changing.
> 
> I wasn't sure if the following would be accepted for that reason,
> thoughts?

Well, looking over the code in question, we're talking about error
handling during xmodem transfers.  What are the errno values that get
used there by xmodem tools?  Thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] arch: ifc: update the IFC IP input clock

[Prabhakar Kushwaha]

> -Original Message-
> From: york sun
> Sent: Thursday, September 08, 2016 7:33 AM
> To: Prabhakar Kushwaha ; u-
> b...@lists.denx.de
> Subject: Re: [PATCH] arch: ifc: update the IFC IP input clock
> 
> On 09/07/2016 06:30 PM, Prabhakar Kushwaha wrote:
> >
> >> -Original Message-
> >> From: york sun
> >> Sent: Wednesday, September 07, 2016 9:17 PM
> >> To: Prabhakar Kushwaha ; u-
> >> b...@lists.denx.de
> >> Subject: Re: [PATCH] arch: ifc: update the IFC IP input clock
> >>
> >> On 09/06/2016 07:42 PM, Prabhakar Kushwaha wrote:
> >>>
>  -Original Message-
>  From: york sun
>  Sent: Tuesday, September 06, 2016 9:10 PM
>  To: Prabhakar Kushwaha ; u-
>  b...@lists.denx.de
>  Subject: Re: [PATCH] arch: ifc: update the IFC IP input clock
> 
>  On 09/06/2016 04:15 AM, Prabhakar Kushwaha wrote:
> > IFC IP clock is always a constant divisor of platform clock
> > pre-defined per SoC. Clock Control register (CCR) used in
> > current implementation governs IFC IP output clock.
> >
> > So update IFC IP clock to be defined as per predefined clock
> > divisor of platform clock.
> >
> > Signed-off-by: Prabhakar Kushwaha 
> > ---
> >  README  |  3 +++
> >  arch/arm/cpu/armv7/ls102xa/clock.c  | 10 ++
> >  arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c | 10 ++
> >  arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c | 10 ++
> >  arch/arm/include/asm/arch-fsl-layerscape/config.h   |  3 +++
> >  arch/arm/include/asm/arch-ls102xa/config.h  |  1 +
> >  arch/powerpc/cpu/mpc85xx/speed.c| 10 ++
> >  arch/powerpc/include/asm/config_mpc85xx.h   |  9 +
> >  8 files changed, 24 insertions(+), 32 deletions(-)
> 
>  Prabkahar,
> 
>  Two concerns here
> 
>  1, it is not only IFC for powerpc. Older SoCs have local bus. That's why
>  the variable is named freq_localbus..
> 
> >>>
> >>> As per my understanding, Issue is valid for eLBC SoC also.
> >>> Just wanted to confirm from internal IP team before spinning patch to fix 
> >>> it.
> >>>
>  2, what's the reason for this change? Is it wrong to use ccr to
>  calculate the clock? Or is it because recent Layerscape SoCs have
>  platform PLL different from platform clock? If the latter, can we limit
>  the fix to platform clock and not changing powerpc?
> 
> >>>
> >>> CCR governs the IFC output clock.
> >>> This clock is used for synchronous NOR, NAND flashes. It is nowhere govern
> >> IFC IP internal clock.
> >>>
> >>> It is true since conception of IFC. Unfortunately code written is wrong 
> >>> since
> >> P1010.
> >>> It is confusing everyone.
> >>>
> >>
> >> Are you saying the freq_localbus should be the internal clock, not
> >> output clock? As far as I can remember, this variable has always be used
> >> for output clock since 85xx. I am open to the idea to change to internal
> >> clock only if it makes sense. Browsing the code, I see this variable is
> >> used for information only, except for setting arch.lbc_clk.
> >>
> >
> > Everyone believe it to be IFC internal clock not the output clock.
> 
> Not everyone.
> 
> > As I always used to get query from customers about wrong IFC speed.
> >
> > So better to print IP clock to avoid any confusion.
> > IFC output clock will be printed when it is actually being used during
> synchronous NOR, syn NAND.
> 
> I am not against changing it to internal clock. But what are you going
> to print on the console? I think it is confusing to say IFC or local bus
> internal clock speed. Please also check how this clock is used and make
> sure arch.lbc_clk is still correct, after passing to Linux.
> 
arch.lbc_clk is only being used for eLBC for device tree fixup.  
And I checked the Linux eLBC driver. Looks like it is not using used. 

No device tree fixup is being done for IFC.

--prabhakar




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

Re: [U-Boot] [PATCH] sunxi: musb: Power off OTG port VBUS when disabled

[Ian Campbell]

On Wed, 2016-09-07 at 14:25 +0800, Chen-Yu Tsai wrote:
> The Linux kernel musb driver expects...

I don't much like this line of reasoning/explanation for changes to u-
boot. I appreciate that it might seem like all the world is Linux
(especially in sunxi context) but the right way to descibe these
changes IMHO is "A sensible behaviour for firmware is to ... because
..." i.e. to consider the general case.

Otherwise I might be tempted to say things like...

>  VBUS to be off while initializing
> musb. Having it on results in a repeating string of warnings, followed
> > by an unusable peripheral.

... this sounds like it might be a Linux bug, perhaps it should be
fixed there?

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

Re: [U-Boot] image-fit: switch ENOLINK to ENOENT

[Jonathan Gray]

On Wed, Sep 07, 2016 at 02:00:19PM -0400, Tom Rini wrote:
> On Sat, Sep 03, 2016 at 08:30:14AM +1000, Jonathan Gray wrote:
> 
> > ENOLINK is not required by POSIX and does not exist on OpenBSD
> > and likely other systems.
> > 
> > Signed-off-by: Jonathan Gray 
> 
> Applied to u-boot/master, thanks!

Thanks for applying this and the other patch.

In tools/kwboot.c I've also locally changed EPROTO and EBADMSG as they
aren't on OpenBSD either.

They are in POSIX however so I am trying to get them into OpenBSD,
but it will need some time to be scheduled as introducing errnos
involves cranking the major version of libc due to the size of the array
with errno strings changing.

I wasn't sure if the following would be accepted for that reason,
thoughts?

FreeBSD and NetBSD seems to have definitions for both already.

diff --git a/tools/kwboot.c b/tools/kwboot.c
index 26b3949..9b50b32 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -402,13 +402,13 @@ kwboot_xm_sendblock(int fd, struct kwboot_block *block)
rc = 0;
break;
case NAK:
-   errno = EBADMSG;
+   errno = ECONNREFUSED;
break;
case CAN:
errno = ECANCELED;
break;
default:
-   errno = EPROTO;
+   errno = EIO;
break;
}
 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] sunxi: Sync h3-orangepi dts files with kernel

[Ian Campbell]

On Sat, 2016-09-03 at 13:12 +0200, Hans de Goede wrote:
> This adds an emac node to the orangepi-2 dts (not yet merged
> upstream,
> but in u-boot we already have emac support); fixes the alphetically
> sorting of nodes in sun8i-h3-orangepi-plus.dts and disables some
> usb controllers in sun8i-h3-orangepi-plus.dts which are only used
> on the plus2e, as upstream has decided to do a separate dts files
> for the plus2e.
> 
> Signed-off-by: Hans de Goede 

After these three patches does the state of the dts files now match the
state of the files upstream, modulo things which are still in flight to
upstream (so maybe I should ask "...match the intended/eventual
state...")? If so then:

Acked-by: Ian Campbell 


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

Re: [U-Boot] [PATCH v2] sunxi: display: Use PWM to drive backlight where applicable

[Ian Campbell]

On Fri, 2016-08-26 at 16:21 +0200, Hans de Goede wrote:
> 
> > 
> > Reviewed by: Peter Korsgaard 
> 
> Thank you.

Acked-by: Ian Campbell 

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

Re: [U-Boot] [PATCH] sun5i: Add defconfig and dts file for the Empire Electronix M712 tablet

[Ian Campbell]

On Fri, 2016-08-26 at 16:11 +0200, Hans de Goede wrote:
> Add a defconfig and dts file for the Empire Electronix M712 tablet,
> this
> is a 7" A13 tablet, with micro-usb (otg), headphone and micro-sd
> slots on
> the outside. It uses a Goodix gt811 touchscreen controller, a
> RTL8188CTV
> wifi chip and a DMART06 (1238a4) accelerometer.
> 
> The dts file is identical to the one submitted to the upstream
> kernel.
> 
> Signed-off-by: Hans de Goede 

Acked-by: Ian Campbell 

(sorry for the delay, I was on vacation and this got mixed in with all
the other random u-boot stuff I get cc-d on so I missed it)

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

Re: [U-Boot] [PATCH 1/9] MIPS: Add arch-wide arch_cpu_init

[Marek Vasut]

On 09/08/2016 01:21 PM, Paul Burton wrote:
> 
> 
> On 08/09/16 11:47, Marek Vasut wrote:
>> On 09/08/2016 12:36 PM, Paul Burton wrote:
>>> On 08/09/16 11:02, Marek Vasut wrote:
 On 09/07/2016 07:48 PM, Paul Burton wrote:
> Add an implementation of arch_cpu_init that covers all MIPS boards, in
> preparation for performing various pieces of initialisation there in
> later patches.
>
> In order to allow the ath79 code to continue performing initialisation
> at this point in the boot, it's converted to use a new mach_cpu_init
> function which is called from arch_cpu_init.
>
> Signed-off-by: Paul Burton 

 [...]

 Hi!

> diff --git a/arch/mips/include/asm/u-boot-mips.h 
> b/arch/mips/include/asm/u-boot-mips.h
> index 1f527bb..0eaf32b 100644
> --- a/arch/mips/include/asm/u-boot-mips.h
> +++ b/arch/mips/include/asm/u-boot-mips.h
> @@ -5,4 +5,16 @@
>  #ifndef _U_BOOT_MIPS_H_
>  #define _U_BOOT_MIPS_H_
>  
> +/**
> + * mach_cpu_init() - Perform SoC/machine-specific CPU initialisation
> + *
> + * This is called from arch_cpu_init() to allow for SoC/machine-level 
> code to
> + * perform any CPU initialisation it may require.

 Just call this function from arch_cpu_init() in various places instead
 of replacing arch_cpu_init() with it all over the place. Also rename it
 to arch_cpu_init_common() to make it more obvious what this does .
>>>
>>> Hi Marek,
>>
>> Hi,
>>
>>> That's "backwards" compared with what this code actually does -
>>> arch_cpu_init becomes the common function (ie. is arch-wide as in the
>>> patch subject) and mach_cpu_init is for use by machines/SoCs - ie. code
>>> under arch/mips/mach-*.
>>
>> For machines, we already have board_cpu_init() , for SoCs we have
>> arch_cpu_init() . Reading through the patchset, I understand the
>> purpose, but then the content of mach_cpu_init() looks like some
>> common arch init bit to me.
> 
> Hi Marek,
> 
> The content of the only implementation of mach_cpu_init is some
> ath79-specific chip ID stuff. I'm not sure how you think that's "common
> arch init"?
> 
> Right now without this patch you're right - arch_cpu_init is used by
> SoCs (well, one SoC - ath79). This patch changes that so that
> arch_cpu_init is used by the arch code & mach_cpu_init is used by the
> SoC/machine code under arch/mips/mach-*. That seems like the most
> logical way to handle it to me.

It also introduces discrepancy with ARM and other architectures though.

> I get that arch_cpu_init is also used by SoCs on some other
> architectures (arm & x86 seemingly), but not on all - there's precedent
> for an arch-wide implementation in arc, avr32, blackfin, nios2 or xtensa.

Most of which are dead/unmaintained though.

Seems like this might need some further cleanup/clarification then.

>>
> + */
> +#ifdef CONFIG_MACH_CPU_INIT
> +void mach_cpu_init(void);
> +#else
> +static inline void mach_cpu_init(void) {}

 Implement this as __weak int and you can nuke the ifdefery .
>>>
>>> I could make it weak, but then we don't let the compiler optimise it out
>>> entirely for builds that don't need it (ie. everything except ath79).
>>
>> Did you try it ?
> 
> I didn't, but the compiler will have to emit the call as it won't be
> known whether there's an implementation of the function until link time
> so it will obviously have a small cost (unless LTO is used). Having said
> that I see the U-Boot wiki seems to indicate that weak is preferred so
> I'm ok with changing it.

btw if you want to go ahead with adding the mach_cpu_init(), you might
want to consider adding it into the board_f.c initcalls , so other
arches can convert to it.

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

Re: [U-Boot] [PATCH 1/9] MIPS: Add arch-wide arch_cpu_init

[Paul Burton]

On 08/09/16 11:47, Marek Vasut wrote:
> On 09/08/2016 12:36 PM, Paul Burton wrote:
>> On 08/09/16 11:02, Marek Vasut wrote:
>>> On 09/07/2016 07:48 PM, Paul Burton wrote:
 Add an implementation of arch_cpu_init that covers all MIPS boards, in
 preparation for performing various pieces of initialisation there in
 later patches.

 In order to allow the ath79 code to continue performing initialisation
 at this point in the boot, it's converted to use a new mach_cpu_init
 function which is called from arch_cpu_init.

 Signed-off-by: Paul Burton 
>>>
>>> [...]
>>>
>>> Hi!
>>>
 diff --git a/arch/mips/include/asm/u-boot-mips.h 
 b/arch/mips/include/asm/u-boot-mips.h
 index 1f527bb..0eaf32b 100644
 --- a/arch/mips/include/asm/u-boot-mips.h
 +++ b/arch/mips/include/asm/u-boot-mips.h
 @@ -5,4 +5,16 @@
  #ifndef _U_BOOT_MIPS_H_
  #define _U_BOOT_MIPS_H_
  
 +/**
 + * mach_cpu_init() - Perform SoC/machine-specific CPU initialisation
 + *
 + * This is called from arch_cpu_init() to allow for SoC/machine-level 
 code to
 + * perform any CPU initialisation it may require.
>>>
>>> Just call this function from arch_cpu_init() in various places instead
>>> of replacing arch_cpu_init() with it all over the place. Also rename it
>>> to arch_cpu_init_common() to make it more obvious what this does .
>>
>> Hi Marek,
> 
> Hi,
> 
>> That's "backwards" compared with what this code actually does -
>> arch_cpu_init becomes the common function (ie. is arch-wide as in the
>> patch subject) and mach_cpu_init is for use by machines/SoCs - ie. code
>> under arch/mips/mach-*.
> 
> For machines, we already have board_cpu_init() , for SoCs we have
> arch_cpu_init() . Reading through the patchset, I understand the
> purpose, but then the content of mach_cpu_init() looks like some
> common arch init bit to me.

Hi Marek,

The content of the only implementation of mach_cpu_init is some
ath79-specific chip ID stuff. I'm not sure how you think that's "common
arch init"?

Right now without this patch you're right - arch_cpu_init is used by
SoCs (well, one SoC - ath79). This patch changes that so that
arch_cpu_init is used by the arch code & mach_cpu_init is used by the
SoC/machine code under arch/mips/mach-*. That seems like the most
logical way to handle it to me.

I get that arch_cpu_init is also used by SoCs on some other
architectures (arm & x86 seemingly), but not on all - there's precedent
for an arch-wide implementation in arc, avr32, blackfin, nios2 or xtensa.

> 
 + */
 +#ifdef CONFIG_MACH_CPU_INIT
 +void mach_cpu_init(void);
 +#else
 +static inline void mach_cpu_init(void) {}
>>>
>>> Implement this as __weak int and you can nuke the ifdefery .
>>
>> I could make it weak, but then we don't let the compiler optimise it out
>> entirely for builds that don't need it (ie. everything except ath79).
> 
> Did you try it ?

I didn't, but the compiler will have to emit the call as it won't be
known whether there's an implementation of the function until link time
so it will obviously have a small cost (unless LTO is used). Having said
that I see the U-Boot wiki seems to indicate that weak is preferred so
I'm ok with changing it.

Thanks,
Paul

> 
>> I'd say that since the #ifdefery here is confined to this one case in
>> the header (which is a pretty common approach) it's ugliness is kept
>> minimal & its cost on binaries & runtime is as low as it can be at zero.
> 
> Even if it costs 4 bytes more, one less ifdef is one good ifdef.
> 
>> Daniel - do you have a preference?
>>
>>>
 +#endif
 +
  #endif /* _U_BOOT_MIPS_H_ */
 diff --git a/arch/mips/mach-ath79/cpu.c b/arch/mips/mach-ath79/cpu.c
 index 5756a06..a556b73 100644
 --- a/arch/mips/mach-ath79/cpu.c
 +++ b/arch/mips/mach-ath79/cpu.c
 @@ -46,7 +46,7 @@ static const struct ath79_soc_desc desc[] = {
{ATH79_SOC_QCA9561, "9561", REV_ID_MAJOR_QCA9561,   0},
  };
  
 -int arch_cpu_init(void)
 +void mach_cpu_init(void)
>>>
>>> See above.
>>>
  {
void __iomem *base;
enum ath79_soc_type soc = ATH79_SOC_UNKNOWN;
 @@ -98,7 +98,6 @@ int arch_cpu_init(void)
gd->arch.soc = soc;
gd->arch.rev = rev;
gd->arch.ver = ver;
 -  return 0;
>>>
>>> That's a nope, keep the return value.
>>
>> The implementation always returns zero, so I see no point.
> 
> It does for now, but arch_cpu_init() can fail, so I see a point in
> propagating return values.
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] mmc: dw_mmc: change the read/write order under fifo mode

[Jaehoon Chung]

On 09/08/2016 12:43 PM, Ziyuan Xu wrote:
> 
> 
> On 2016年09月07日 14:50, Jaehoon Chung wrote:
>> On 09/07/2016 03:14 PM, Ziyuan Xu wrote:
>>> hi Jaehoon,
>>>
>>>
>>> On 2016年08月30日 17:54, Jaehoon Chung wrote:
 Hi Jacob,

 On 08/30/2016 02:26 AM, Jacob Chen wrote:
> From: "jacob2.chen" 
>
> The former implement have a bug.
> It will cause wrong data reading sometimes.
 Could you explain what bug is there?
> Signed-off-by: jacob2.chen 
 Could you change from jacob2.chen to your name?

> ---
>
>drivers/mmc/dw_mmc.c | 32 +---
>1 file changed, 17 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
> index afc674d..f072739 100644
> --- a/drivers/mmc/dw_mmc.c
> +++ b/drivers/mmc/dw_mmc.c
> @@ -120,35 +120,37 @@ static int dwmci_data_transfer(struct dwmci_host 
> *host, struct mmc_data *data)
>  if (host->fifo_mode && size) {
>len = 0;
> -if (data->flags == MMC_DATA_READ) {
> -if ((dwmci_readl(host, DWMCI_RINTSTS) &
> - DWMCI_INTMSK_RXDR)) {
> +if (data->flags == MMC_DATA_READ &&
> +(mask & DWMCI_INTMSK_RXDR)) {
> +while (size) {
>len = dwmci_readl(host, DWMCI_STATUS);
>len = (len >> DWMCI_FIFO_SHIFT) &
> -DWMCI_FIFO_MASK;
> +DWMCI_FIFO_MASK;
 this changing is related with bug?
>>> I just hit this bug on rk3036 board.
>> This changing is just an indentation, isn't?
>> It looks like unnecessary modifying.
>>
>>> When DTO interrupt occurred, there are any remaining data still in FIFO due 
>>> to RX FIFO threshold is larger than remaining data. It also causes that 
>>> dwmmc didn't trigger RXDR interrupt.
>>> It's responsibility of driver to read remaining bytes on seeing DTO 
>>> interrupt. So we need rework dwmci_data_transfer w/ pio mode.
>> Sure, your bug is possible to occur..but my mean is that modified 
>> DWMCI_FIFO_MASK isn't related with your entire bug.
> 
> Okay I see. If I understand correctly, you recommend that set fifo-depth to 
> 1, so that host can trigger RXDR interrupt as soon as 1 bytes data come in.
> I think it's inefficient.

Well, my meaning is " len = (len >> DWMCI_FIFO_SHIFT) & DWMCI_FIFO_MASK;"

> -DWMCI_FIFO_MASK;
> +DWMCI_FIFO_MASK;

It doesn't need to modify. There is no reason to change.

> 
>>
>> Best Regards,
>> Jaehoon Chung
>>
>len = min(size, len);
>for (i = 0; i < len; i++)
>*buf++ =
> -dwmci_readl(host, DWMCI_DATA);
> -dwmci_writel(host, DWMCI_RINTSTS,
> - DWMCI_INTMSK_RXDR);
> +dwmci_readl(host,
> +DWMCI_DATA);
> +size = size > len ? (size - len) : 0;
>}
> -} else {
> -if ((dwmci_readl(host, DWMCI_RINTSTS) &
> - DWMCI_INTMSK_TXDR)) {
> +dwmci_writel(host, DWMCI_RINTSTS,
> + DWMCI_INTMSK_RXDR);
> +} else if (data->flags == MMC_DATA_WRITE &&
> +   (mask & DWMCI_INTMSK_TXDR)) {
 data->flags == MMC_DATA_WRITE doesn't need..flags are only two..
 one is MMC_DATA_READ, otherwise it's MMC_DATA_WRITE.

> +while (size) {
>len = dwmci_readl(host, DWMCI_STATUS);
>len = fifo_depth - ((len >>
> -   DWMCI_FIFO_SHIFT) &
> -   DWMCI_FIFO_MASK);
> + DWMCI_FIFO_SHIFT) &
> +DWMCI_FIFO_MASK);
 ditto.


> -   DWMCI_FIFO_SHIFT) &
> -   DWMCI_FIFO_MASK);
> + DWMCI_FIFO_SHIFT) &
> +DWMCI_FIFO_MASK);

Ditto.

Best Regards,
Jaehoon Chung


 Best Regards,
 Jaehoon Chung

>len = min(size, len);
>for (i = 0; i < len; i++)
>dwmci_writel(host, DWMCI_DATA,
> *buf++);
> -dwmci_writel(host, DWMCI_RINTSTS,
> - DWMCI_INTMSK_TXDR);
> +size = size > len ? (size - len) : 0;
>}
> +dwmci_writel(host, DWMCI_RINTSTS,
> + 

Re: [U-Boot] [PATCH] arch: ifc: update the IFC IP input clock

[Prabhakar Kushwaha]

> -Original Message-
> From: york sun
> Sent: Wednesday, September 07, 2016 9:17 PM
> To: Prabhakar Kushwaha ; u-
> b...@lists.denx.de
> Subject: Re: [PATCH] arch: ifc: update the IFC IP input clock
> 
> On 09/06/2016 07:42 PM, Prabhakar Kushwaha wrote:
> >
> >> -Original Message-
> >> From: york sun
> >> Sent: Tuesday, September 06, 2016 9:10 PM
> >> To: Prabhakar Kushwaha ; u-
> >> b...@lists.denx.de
> >> Subject: Re: [PATCH] arch: ifc: update the IFC IP input clock
> >>
> >> On 09/06/2016 04:15 AM, Prabhakar Kushwaha wrote:
> >>> IFC IP clock is always a constant divisor of platform clock
> >>> pre-defined per SoC. Clock Control register (CCR) used in
> >>> current implementation governs IFC IP output clock.
> >>>
> >>> So update IFC IP clock to be defined as per predefined clock
> >>> divisor of platform clock.
> >>>
> >>> Signed-off-by: Prabhakar Kushwaha 
> >>> ---
> >>>  README  |  3 +++
> >>>  arch/arm/cpu/armv7/ls102xa/clock.c  | 10 ++
> >>>  arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c | 10 ++
> >>>  arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c | 10 ++
> >>>  arch/arm/include/asm/arch-fsl-layerscape/config.h   |  3 +++
> >>>  arch/arm/include/asm/arch-ls102xa/config.h  |  1 +
> >>>  arch/powerpc/cpu/mpc85xx/speed.c| 10 ++
> >>>  arch/powerpc/include/asm/config_mpc85xx.h   |  9 +
> >>>  8 files changed, 24 insertions(+), 32 deletions(-)
> >>
> >> Prabkahar,
> >>
> >> Two concerns here
> >>
> >> 1, it is not only IFC for powerpc. Older SoCs have local bus. That's why
> >> the variable is named freq_localbus..
> >>
> >
> > As per my understanding, Issue is valid for eLBC SoC also.
> > Just wanted to confirm from internal IP team before spinning patch to fix 
> > it.
> >
> >> 2, what's the reason for this change? Is it wrong to use ccr to
> >> calculate the clock? Or is it because recent Layerscape SoCs have
> >> platform PLL different from platform clock? If the latter, can we limit
> >> the fix to platform clock and not changing powerpc?
> >>
> >
> > CCR governs the IFC output clock.
> > This clock is used for synchronous NOR, NAND flashes. It is nowhere govern
> IFC IP internal clock.
> >
> > It is true since conception of IFC. Unfortunately code written is wrong 
> > since
> P1010.
> > It is confusing everyone.
> >
> 
> Are you saying the freq_localbus should be the internal clock, not
> output clock? As far as I can remember, this variable has always be used
> for output clock since 85xx. I am open to the idea to change to internal
> clock only if it makes sense. Browsing the code, I see this variable is
> used for information only, except for setting arch.lbc_clk.
> 
 
Everyone believe it to be IFC internal clock not the output clock. 
As I always used to get query from customers about wrong IFC speed.  

So better to print IP clock to avoid any confusion.
IFC output clock will be printed when it is actually being used during 
synchronous NOR, syn NAND.
Please note it is currently not being supported by IFC. 

--prabhakar


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

Re: [U-Boot] [PATCH 1/3] mmc: dw_mmc: change the read/write order under fifo mode

[Ziyuan Xu]

On 2016年09月07日 14:50, Jaehoon Chung wrote:

On 09/07/2016 03:14 PM, Ziyuan Xu wrote:

hi Jaehoon,


On 2016年08月30日 17:54, Jaehoon Chung wrote:

Hi Jacob,

On 08/30/2016 02:26 AM, Jacob Chen wrote:

From: "jacob2.chen" 

The former implement have a bug.
It will cause wrong data reading sometimes.

Could you explain what bug is there?

Signed-off-by: jacob2.chen 

Could you change from jacob2.chen to your name?


---

   drivers/mmc/dw_mmc.c | 32 +---
   1 file changed, 17 insertions(+), 15 deletions(-)

diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index afc674d..f072739 100644
--- a/drivers/mmc/dw_mmc.c
+++ b/drivers/mmc/dw_mmc.c
@@ -120,35 +120,37 @@ static int dwmci_data_transfer(struct dwmci_host *host, 
struct mmc_data *data)
 if (host->fifo_mode && size) {
   len = 0;
-if (data->flags == MMC_DATA_READ) {
-if ((dwmci_readl(host, DWMCI_RINTSTS) &
- DWMCI_INTMSK_RXDR)) {
+if (data->flags == MMC_DATA_READ &&
+(mask & DWMCI_INTMSK_RXDR)) {
+while (size) {
   len = dwmci_readl(host, DWMCI_STATUS);
   len = (len >> DWMCI_FIFO_SHIFT) &
-DWMCI_FIFO_MASK;
+DWMCI_FIFO_MASK;

this changing is related with bug?

I just hit this bug on rk3036 board.

This changing is just an indentation, isn't?
It looks like unnecessary modifying.


When DTO interrupt occurred, there are any remaining data still in FIFO due to 
RX FIFO threshold is larger than remaining data. It also causes that dwmmc 
didn't trigger RXDR interrupt.
It's responsibility of driver to read remaining bytes on seeing DTO interrupt. 
So we need rework dwmci_data_transfer w/ pio mode.

Sure, your bug is possible to occur..but my mean is that modified 
DWMCI_FIFO_MASK isn't related with your entire bug.


Okay I see. If I understand correctly, you recommend that set fifo-depth 
to 1, so that host can trigger RXDR interrupt as soon as 1 bytes data 
come in.

I think it's inefficient.



Best Regards,
Jaehoon Chung


   len = min(size, len);
   for (i = 0; i < len; i++)
   *buf++ =
-dwmci_readl(host, DWMCI_DATA);
-dwmci_writel(host, DWMCI_RINTSTS,
- DWMCI_INTMSK_RXDR);
+dwmci_readl(host,
+DWMCI_DATA);
+size = size > len ? (size - len) : 0;
   }
-} else {
-if ((dwmci_readl(host, DWMCI_RINTSTS) &
- DWMCI_INTMSK_TXDR)) {
+dwmci_writel(host, DWMCI_RINTSTS,
+ DWMCI_INTMSK_RXDR);
+} else if (data->flags == MMC_DATA_WRITE &&
+   (mask & DWMCI_INTMSK_TXDR)) {

data->flags == MMC_DATA_WRITE doesn't need..flags are only two..
one is MMC_DATA_READ, otherwise it's MMC_DATA_WRITE.


+while (size) {
   len = dwmci_readl(host, DWMCI_STATUS);
   len = fifo_depth - ((len >>
-   DWMCI_FIFO_SHIFT) &
-   DWMCI_FIFO_MASK);
+ DWMCI_FIFO_SHIFT) &
+DWMCI_FIFO_MASK);

ditto.

Best Regards,
Jaehoon Chung


   len = min(size, len);
   for (i = 0; i < len; i++)
   dwmci_writel(host, DWMCI_DATA,
*buf++);
-dwmci_writel(host, DWMCI_RINTSTS,
- DWMCI_INTMSK_TXDR);
+size = size > len ? (size - len) : 0;
   }
+dwmci_writel(host, DWMCI_RINTSTS,
+ DWMCI_INTMSK_TXDR);
   }
-size = size > len ? (size - len) : 0;
   }
 /* Data arrived correctly. */


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















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

Re: [U-Boot] [PATCH 8/9] MIPS: L2 cache support

[Paul Burton]

On 08/09/16 11:40, Marek Vasut wrote:
> On 09/08/2016 12:31 PM, Paul Burton wrote:
>> On 08/09/16 11:04, Marek Vasut wrote:
>>> On 09/07/2016 07:48 PM, Paul Burton wrote:
 This patch adds support for initialising & maintaining L2 caches on MIPS
 systems. The L2 cache configuration may be advertised through either
 coprocessor 0 or the MIPS Coherence Manager depending upon the system,
 and support for both is included.

 If the L2 can be bypassed then we bypass it early in boot & initialise
 the L1 caches first, such that we can start making use of the L1
 instruction cache as early as possible. Otherwise we initialise the L2
 first such that the L1s have no opportunity to generate access to the
 uninitialised L2.

 Signed-off-by: Paul Burton 
 ---

  arch/mips/Kconfig   |   6 ++
  arch/mips/include/asm/cm.h  |  38 
  arch/mips/include/asm/global_data.h |   3 +
  arch/mips/include/asm/mipsregs.h|   5 +
  arch/mips/lib/cache.c   |  62 -
  arch/mips/lib/cache_init.S  | 180 
 +++-
  6 files changed, 288 insertions(+), 6 deletions(-)

 diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
 index 732d129..8f97727 100644
 --- a/arch/mips/Kconfig
 +++ b/arch/mips/Kconfig
 @@ -301,6 +301,12 @@ config MIPS_L1_CACHE_SHIFT
default "4" if MIPS_L1_CACHE_SHIFT_4
default "5"
  
 +config MIPS_L2_CACHE
 +  bool
 +  help
 +Select this if your system includes an L2 cache and you want U-Boot
 +to initialise & maintain it.
 +
  config DYNAMIC_IO_PORT_BASE
bool
  
 diff --git a/arch/mips/include/asm/cm.h b/arch/mips/include/asm/cm.h
 index 0261733..62ecef2 100644
 --- a/arch/mips/include/asm/cm.h
 +++ b/arch/mips/include/asm/cm.h
 @@ -12,8 +12,46 @@
  #define GCR_BASE  0x0008
  #define GCR_BASE_UPPER0x000c
  #define GCR_REV   0x0030
 +#define GCR_L2_CONFIG 0x0130
 +#define GCR_L2_TAG_ADDR   0x0600
 +#define GCR_L2_TAG_ADDR_UPPER 0x0604
 +#define GCR_L2_TAG_STATE  0x0608
 +#define GCR_L2_TAG_STATE_UPPER0x060c
 +#define GCR_L2_DATA   0x0610
 +#define GCR_L2_DATA_UPPER 0x0614
  
  /* GCR_REV CM versions */
  #define GCR_REV_CM3   0x0800
  
 +/* GCR_L2_CONFIG fields */
 +#define GCR_L2_CONFIG_ASSOC_SHIFT 0
 +#define GCR_L2_CONFIG_ASSOC_BITS  8
 +#define GCR_L2_CONFIG_LINESZ_SHIFT8
 +#define GCR_L2_CONFIG_LINESZ_BITS 4
 +#define GCR_L2_CONFIG_SETSZ_SHIFT 12
 +#define GCR_L2_CONFIG_SETSZ_BITS  4
 +#define GCR_L2_CONFIG_BYPASS  (1 << 20)
 +
 +#ifndef __ASSEMBLY__
 +
 +#include 
 +
 +static inline void *mips_cm_base(void)
 +{
 +  return (void *)CKSEG1ADDR(CONFIG_MIPS_CM_BASE);
 +}
 +
 +static inline unsigned long mips_cm_l2_line_size(void)
 +{
 +  unsigned long l2conf, line_sz;
 +
 +  l2conf = __raw_readl(mips_cm_base() + GCR_L2_CONFIG);
 +
 +  line_sz = l2conf >> GCR_L2_CONFIG_LINESZ_SHIFT;
 +  line_sz &= GENMASK(GCR_L2_CONFIG_LINESZ_BITS - 1, 0);
 +  return line_sz ? (2 << line_sz) : 0;
 +}
>>>
>>> Drop the inline stuff, the compiler can decide that itself, especially
>>> on static functions. The inline is only a hint anyway.
>>>
>>> [...]
>>
>> Hi Marek,
>>
>> Nope - inline does have an impact for functions in headers. If it's not
>> there & a file includes a header but doesn't use *all* of the functions
>> in it then the compiler will warn about the functions being unused. With
>> inline that isn't the case. Thus "static inline" is used quite
>> extensively in many of the headers under include/.
> 
> Uh, I didn't notice these functions were placed in a header file. Is
> that really necessary at all or can you move them to a C file ?

I could move them, but then the compiler wouldn't get an opportunity to
inline these short functions. I don't see any downside to keeping these
in the same place as the registers they access are defined.

Thanks,
Paul

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

Re: [U-Boot] [PATCH] usb: gadget: ci_udc: fix suspend/resume of USB Mass Storage

[Fabio Estevam]

Hi John,

On Wed, Aug 24, 2016 at 2:25 AM, John Tobias  wrote:

> I tried to following combinations below but, the return
> SETUP(r.bRequestType, r.bRequest) doesn't match at all.
>
> SETUP(USB_DIR_IN | USB_RECIP_DEVICE, USB_REQ_GET_STATUS)
> SETUP(USB_RECIP_DEVICE, USB_REQ_GET_STATUS)
> SETUP(USB_DIR_IN, USB_REQ_GET_STATUS)
>
>> I don't think it's correct to remove the bRequestType checking altogether.
>
> Looking at the fsl_udc_core.c
> http://lxr.free-electrons.com/source/drivers/usb/gadget/udc/fsl_udc_core.c#L1405
> looks identical.

This is the old udc driver for the non-dt imx.

Currently we use drivers/usb/chipidea/udc.c, which also seems to match
what you do in your patch.

Regards,

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

Re: [U-Boot] [PATCH 1/9] MIPS: Add arch-wide arch_cpu_init

[Marek Vasut]

On 09/08/2016 12:36 PM, Paul Burton wrote:
> On 08/09/16 11:02, Marek Vasut wrote:
>> On 09/07/2016 07:48 PM, Paul Burton wrote:
>>> Add an implementation of arch_cpu_init that covers all MIPS boards, in
>>> preparation for performing various pieces of initialisation there in
>>> later patches.
>>>
>>> In order to allow the ath79 code to continue performing initialisation
>>> at this point in the boot, it's converted to use a new mach_cpu_init
>>> function which is called from arch_cpu_init.
>>>
>>> Signed-off-by: Paul Burton 
>>
>> [...]
>>
>> Hi!
>>
>>> diff --git a/arch/mips/include/asm/u-boot-mips.h 
>>> b/arch/mips/include/asm/u-boot-mips.h
>>> index 1f527bb..0eaf32b 100644
>>> --- a/arch/mips/include/asm/u-boot-mips.h
>>> +++ b/arch/mips/include/asm/u-boot-mips.h
>>> @@ -5,4 +5,16 @@
>>>  #ifndef _U_BOOT_MIPS_H_
>>>  #define _U_BOOT_MIPS_H_
>>>  
>>> +/**
>>> + * mach_cpu_init() - Perform SoC/machine-specific CPU initialisation
>>> + *
>>> + * This is called from arch_cpu_init() to allow for SoC/machine-level code 
>>> to
>>> + * perform any CPU initialisation it may require.
>>
>> Just call this function from arch_cpu_init() in various places instead
>> of replacing arch_cpu_init() with it all over the place. Also rename it
>> to arch_cpu_init_common() to make it more obvious what this does .
> 
> Hi Marek,

Hi,

> That's "backwards" compared with what this code actually does -
> arch_cpu_init becomes the common function (ie. is arch-wide as in the
> patch subject) and mach_cpu_init is for use by machines/SoCs - ie. code
> under arch/mips/mach-*.

For machines, we already have board_cpu_init() , for SoCs we have
arch_cpu_init() . Reading through the patchset, I understand the
purpose, but then the content of mach_cpu_init() looks like some
common arch init bit to me.

>>> + */
>>> +#ifdef CONFIG_MACH_CPU_INIT
>>> +void mach_cpu_init(void);
>>> +#else
>>> +static inline void mach_cpu_init(void) {}
>>
>> Implement this as __weak int and you can nuke the ifdefery .
> 
> I could make it weak, but then we don't let the compiler optimise it out
> entirely for builds that don't need it (ie. everything except ath79).

Did you try it ?

> I'd say that since the #ifdefery here is confined to this one case in
> the header (which is a pretty common approach) it's ugliness is kept
> minimal & its cost on binaries & runtime is as low as it can be at zero.

Even if it costs 4 bytes more, one less ifdef is one good ifdef.

> Daniel - do you have a preference?
> 
>>
>>> +#endif
>>> +
>>>  #endif /* _U_BOOT_MIPS_H_ */
>>> diff --git a/arch/mips/mach-ath79/cpu.c b/arch/mips/mach-ath79/cpu.c
>>> index 5756a06..a556b73 100644
>>> --- a/arch/mips/mach-ath79/cpu.c
>>> +++ b/arch/mips/mach-ath79/cpu.c
>>> @@ -46,7 +46,7 @@ static const struct ath79_soc_desc desc[] = {
>>> {ATH79_SOC_QCA9561, "9561", REV_ID_MAJOR_QCA9561,   0},
>>>  };
>>>  
>>> -int arch_cpu_init(void)
>>> +void mach_cpu_init(void)
>>
>> See above.
>>
>>>  {
>>> void __iomem *base;
>>> enum ath79_soc_type soc = ATH79_SOC_UNKNOWN;
>>> @@ -98,7 +98,6 @@ int arch_cpu_init(void)
>>> gd->arch.soc = soc;
>>> gd->arch.rev = rev;
>>> gd->arch.ver = ver;
>>> -   return 0;
>>
>> That's a nope, keep the return value.
> 
> The implementation always returns zero, so I see no point.

It does for now, but arch_cpu_init() can fail, so I see a point in
propagating return values.

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

Re: [U-Boot] [PATCH] Various, accumulated typos collected from around the tree.

[Stefan Roese]

On 07.09.2016 20:27, Robert P. J. Day wrote:


Fix various misspellings of:

 * deprecated
 * partition
 * preceding,preceded
 * preparation
 * its versus it's
 * export
 * existing
 * scenario
 * redundant
 * remaining
 * value
 * architecture

Signed-off-by: Robert P. J. Day 


Reviewed-by: Stefan Roese 

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

Re: [U-Boot] [PATCH 1/4] Revert "sunxi: Move the SPL stack top to 0x1A000 on Allwinner A64/A80"

[Siarhei Siamashka]

On Mon, 5 Sep 2016 09:23:00 +0100
Andre Przywara  wrote:

> Hi,
> 
> On 05/09/16 05:12, Siarhei Siamashka wrote:
> > On Mon,  5 Sep 2016 01:32:38 +0100
> > Andre Przywara  wrote:
> >   
> >> This commit moved the SPL stack into SRAM C, which worked when the SPL
> >> set the AHB1 clock down to 100 MHz to cope with the flaky SRAM C access
> >> from the CPU.
> >> However booting with boot0 (and thus not using SPL at all) we still run
> >> with a 200 MHz AHB1, so any access to SRAM C is prone to fail.
> >> Since this commit does _not_ only affect the SPL code, but also the
> >> U-Boot proper, we fail when booting with boot0.  
> > 
> > Yes, it unfortunately affected both the SPL and the U-Boot
> > proper because currently both CONFIG_SPL_STACK and
> > CONFIG_SYS_INIT_SP_ADDR defines affect the SPL stack
> > location and in practice this only works in a predictable
> > way if they are set to the same value. I have sent a patch
> > to address this problem (but the fix may be unsafe for
> > v2016.09 because many ARM platforms are affected):
> > 
> > https://patchwork.ozlabs.org/patch/665608/
> > 
> > After this problem is resolved, the CONFIG_SYS_INIT_SP_ADDR
> > define can be decoupled from CONFIG_SPL_STACK and configured to
> > even use the DRAM instead of thrashing some part of the scarce
> > SRAM space (which may be already occupied by the OpenRISC
> > firmware and/or the ATF at the time when the U-Boot proper is
> > starting).
> >   
> >> As the introduction of tiny-printf reduced the size of the SPL, we
> >> can afford to have the SPL stack in SRAM A1.  
> > 
> > We still need to check how much space is really available. The FIT
> > support is rather heavyweight and we may want to enable some other
> > features too.  
> 
> Yes, I had to learn this yesterday ;-)
> So 64-bit SPL works for me now with Jens' DRAM support patches (yeah!),
> but enabling FIT support makes mksunxiboot barf about the file being to
> big. The actual SPL code is about 31K, so maybe I can talk mksunxiboot
> into relaxing its alignment requirements a bit (from 8K down to 512) and
> also increase the available SRAM size - it says 0x7600 for sun4i, is
> this still true to newer SoCs/BROMs?

We have this information in the linux-sunxi wiki since a long time ago
(at least for the SoC variants that I have and could experiment with)
and it is available here:

https://linux-sunxi.org/BROM#U-Boot_SPL_limitations

All the new SoCs have a 32K size limit for the SPL code, which can be
loaded by the BROM. Older A10/A20 SoCs artificially limit it to 24K,
probably trying to forcefully encourage the users to have 8K stack in
the remaining part of the SRAM A1.

On A64, we have 32K of SRAM A1. Then we have 108K of SRAM C, which is a
continuation of SRAM A1 in the address space thus making it look like a
nice single 140K chunk. Then we also have 64K of SRAM A2, which is
supposed to be used by the OpenRISC core and is the only memory area,
which has a reasonable performance when used by OpenRISC:

https://linux-sunxi.org/AR100#Memory_Map

The idea was to let the BROM load up to 32K of the SPL code to the
SRAM A1 (like it normally does) and then have 8K of stack a bit higher
in the address space in SRAM C. But it turned out that the SRAM C is a
bit quirky and suffers from data corruption problems if we reclock
AHB1 too early.

Now there are two possible ways to move forward on A64:
  1) Try to use SRAM C in such a way that it does not fail (and hope
 that no additional quirks get discovered later).
  2) Move the initial SPL stack to SRAM A2.

If we move everything to SRAM A2, then we will have to make sure that
all the SRAM users (the FEL storage area, the SPL stack, the ATF and
the yet to be implemented OpenRISC firmware) never clash with each
other.

About the 31K code size. This does not look good and is very close to
the BROM limit (32K). Just using a different compiler may bring us into
a trouble. Or some minor code tweaks and feature additions.

> Trying this in the past (with libdram) and compiling for (32-bit) Thumb2
> worked, but I need to check what the actual size with Jens' patches are
> these days for Thumb2.

We have already discussed this off-list a long time ago. I know that
both you and Alexander Graf are generally in favour of compiling the
SPL as 64-bit code.

I think that this is the usual case of utility versus fashion. Everyone
wants to plug every hole with 64-bit ARM code right now just because it
is new and innovative. But this fad will fade away in a few years. Now
just imagine an alternative reality, where ARM64 is an old and boring
thing, while Thumb2 is a recent invention to improve code density in
microcontrollers and other code space constrained systems. I'm sure
that everyone would be trying to find a way to replace the legacy
bloated 64-bit ARM code in the SPL with the new and shiny Thumb2
stuff for improving code density ;-)

If we take a pragmatic approach 

Re: [U-Boot] [PATCH 8/9] MIPS: L2 cache support

[Marek Vasut]

On 09/08/2016 12:31 PM, Paul Burton wrote:
> On 08/09/16 11:04, Marek Vasut wrote:
>> On 09/07/2016 07:48 PM, Paul Burton wrote:
>>> This patch adds support for initialising & maintaining L2 caches on MIPS
>>> systems. The L2 cache configuration may be advertised through either
>>> coprocessor 0 or the MIPS Coherence Manager depending upon the system,
>>> and support for both is included.
>>>
>>> If the L2 can be bypassed then we bypass it early in boot & initialise
>>> the L1 caches first, such that we can start making use of the L1
>>> instruction cache as early as possible. Otherwise we initialise the L2
>>> first such that the L1s have no opportunity to generate access to the
>>> uninitialised L2.
>>>
>>> Signed-off-by: Paul Burton 
>>> ---
>>>
>>>  arch/mips/Kconfig   |   6 ++
>>>  arch/mips/include/asm/cm.h  |  38 
>>>  arch/mips/include/asm/global_data.h |   3 +
>>>  arch/mips/include/asm/mipsregs.h|   5 +
>>>  arch/mips/lib/cache.c   |  62 -
>>>  arch/mips/lib/cache_init.S  | 180 
>>> +++-
>>>  6 files changed, 288 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
>>> index 732d129..8f97727 100644
>>> --- a/arch/mips/Kconfig
>>> +++ b/arch/mips/Kconfig
>>> @@ -301,6 +301,12 @@ config MIPS_L1_CACHE_SHIFT
>>> default "4" if MIPS_L1_CACHE_SHIFT_4
>>> default "5"
>>>  
>>> +config MIPS_L2_CACHE
>>> +   bool
>>> +   help
>>> + Select this if your system includes an L2 cache and you want U-Boot
>>> + to initialise & maintain it.
>>> +
>>>  config DYNAMIC_IO_PORT_BASE
>>> bool
>>>  
>>> diff --git a/arch/mips/include/asm/cm.h b/arch/mips/include/asm/cm.h
>>> index 0261733..62ecef2 100644
>>> --- a/arch/mips/include/asm/cm.h
>>> +++ b/arch/mips/include/asm/cm.h
>>> @@ -12,8 +12,46 @@
>>>  #define GCR_BASE   0x0008
>>>  #define GCR_BASE_UPPER 0x000c
>>>  #define GCR_REV0x0030
>>> +#define GCR_L2_CONFIG  0x0130
>>> +#define GCR_L2_TAG_ADDR0x0600
>>> +#define GCR_L2_TAG_ADDR_UPPER  0x0604
>>> +#define GCR_L2_TAG_STATE   0x0608
>>> +#define GCR_L2_TAG_STATE_UPPER 0x060c
>>> +#define GCR_L2_DATA0x0610
>>> +#define GCR_L2_DATA_UPPER  0x0614
>>>  
>>>  /* GCR_REV CM versions */
>>>  #define GCR_REV_CM30x0800
>>>  
>>> +/* GCR_L2_CONFIG fields */
>>> +#define GCR_L2_CONFIG_ASSOC_SHIFT  0
>>> +#define GCR_L2_CONFIG_ASSOC_BITS   8
>>> +#define GCR_L2_CONFIG_LINESZ_SHIFT 8
>>> +#define GCR_L2_CONFIG_LINESZ_BITS  4
>>> +#define GCR_L2_CONFIG_SETSZ_SHIFT  12
>>> +#define GCR_L2_CONFIG_SETSZ_BITS   4
>>> +#define GCR_L2_CONFIG_BYPASS   (1 << 20)
>>> +
>>> +#ifndef __ASSEMBLY__
>>> +
>>> +#include 
>>> +
>>> +static inline void *mips_cm_base(void)
>>> +{
>>> +   return (void *)CKSEG1ADDR(CONFIG_MIPS_CM_BASE);
>>> +}
>>> +
>>> +static inline unsigned long mips_cm_l2_line_size(void)
>>> +{
>>> +   unsigned long l2conf, line_sz;
>>> +
>>> +   l2conf = __raw_readl(mips_cm_base() + GCR_L2_CONFIG);
>>> +
>>> +   line_sz = l2conf >> GCR_L2_CONFIG_LINESZ_SHIFT;
>>> +   line_sz &= GENMASK(GCR_L2_CONFIG_LINESZ_BITS - 1, 0);
>>> +   return line_sz ? (2 << line_sz) : 0;
>>> +}
>>
>> Drop the inline stuff, the compiler can decide that itself, especially
>> on static functions. The inline is only a hint anyway.
>>
>> [...]
> 
> Hi Marek,
> 
> Nope - inline does have an impact for functions in headers. If it's not
> there & a file includes a header but doesn't use *all* of the functions
> in it then the compiler will warn about the functions being unused. With
> inline that isn't the case. Thus "static inline" is used quite
> extensively in many of the headers under include/.

Uh, I didn't notice these functions were placed in a header file. Is
that really necessary at all or can you move them to a C file ?

> Thanks,
> Paul
> 


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

Re: [U-Boot] [PATCH 8/9] MIPS: L2 cache support

[Paul Burton]

On 08/09/16 11:31, Paul Burton wrote:
> Nope - inline does have an impact for functions in headers. If it's not
> there & a file includes a header but doesn't use *all* of the functions
> in it then the compiler will warn about the functions being unused.

Or rather, I should say a vaguely modern gcc will warn about unused
functions.

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

Re: [U-Boot] [PATCH 8/9] MIPS: L2 cache support

[Paul Burton]

On 08/09/16 11:04, Marek Vasut wrote:
> On 09/07/2016 07:48 PM, Paul Burton wrote:
>> This patch adds support for initialising & maintaining L2 caches on MIPS
>> systems. The L2 cache configuration may be advertised through either
>> coprocessor 0 or the MIPS Coherence Manager depending upon the system,
>> and support for both is included.
>>
>> If the L2 can be bypassed then we bypass it early in boot & initialise
>> the L1 caches first, such that we can start making use of the L1
>> instruction cache as early as possible. Otherwise we initialise the L2
>> first such that the L1s have no opportunity to generate access to the
>> uninitialised L2.
>>
>> Signed-off-by: Paul Burton 
>> ---
>>
>>  arch/mips/Kconfig   |   6 ++
>>  arch/mips/include/asm/cm.h  |  38 
>>  arch/mips/include/asm/global_data.h |   3 +
>>  arch/mips/include/asm/mipsregs.h|   5 +
>>  arch/mips/lib/cache.c   |  62 -
>>  arch/mips/lib/cache_init.S  | 180 
>> +++-
>>  6 files changed, 288 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
>> index 732d129..8f97727 100644
>> --- a/arch/mips/Kconfig
>> +++ b/arch/mips/Kconfig
>> @@ -301,6 +301,12 @@ config MIPS_L1_CACHE_SHIFT
>>  default "4" if MIPS_L1_CACHE_SHIFT_4
>>  default "5"
>>  
>> +config MIPS_L2_CACHE
>> +bool
>> +help
>> +  Select this if your system includes an L2 cache and you want U-Boot
>> +  to initialise & maintain it.
>> +
>>  config DYNAMIC_IO_PORT_BASE
>>  bool
>>  
>> diff --git a/arch/mips/include/asm/cm.h b/arch/mips/include/asm/cm.h
>> index 0261733..62ecef2 100644
>> --- a/arch/mips/include/asm/cm.h
>> +++ b/arch/mips/include/asm/cm.h
>> @@ -12,8 +12,46 @@
>>  #define GCR_BASE0x0008
>>  #define GCR_BASE_UPPER  0x000c
>>  #define GCR_REV 0x0030
>> +#define GCR_L2_CONFIG   0x0130
>> +#define GCR_L2_TAG_ADDR 0x0600
>> +#define GCR_L2_TAG_ADDR_UPPER   0x0604
>> +#define GCR_L2_TAG_STATE0x0608
>> +#define GCR_L2_TAG_STATE_UPPER  0x060c
>> +#define GCR_L2_DATA 0x0610
>> +#define GCR_L2_DATA_UPPER   0x0614
>>  
>>  /* GCR_REV CM versions */
>>  #define GCR_REV_CM3 0x0800
>>  
>> +/* GCR_L2_CONFIG fields */
>> +#define GCR_L2_CONFIG_ASSOC_SHIFT   0
>> +#define GCR_L2_CONFIG_ASSOC_BITS8
>> +#define GCR_L2_CONFIG_LINESZ_SHIFT  8
>> +#define GCR_L2_CONFIG_LINESZ_BITS   4
>> +#define GCR_L2_CONFIG_SETSZ_SHIFT   12
>> +#define GCR_L2_CONFIG_SETSZ_BITS4
>> +#define GCR_L2_CONFIG_BYPASS(1 << 20)
>> +
>> +#ifndef __ASSEMBLY__
>> +
>> +#include 
>> +
>> +static inline void *mips_cm_base(void)
>> +{
>> +return (void *)CKSEG1ADDR(CONFIG_MIPS_CM_BASE);
>> +}
>> +
>> +static inline unsigned long mips_cm_l2_line_size(void)
>> +{
>> +unsigned long l2conf, line_sz;
>> +
>> +l2conf = __raw_readl(mips_cm_base() + GCR_L2_CONFIG);
>> +
>> +line_sz = l2conf >> GCR_L2_CONFIG_LINESZ_SHIFT;
>> +line_sz &= GENMASK(GCR_L2_CONFIG_LINESZ_BITS - 1, 0);
>> +return line_sz ? (2 << line_sz) : 0;
>> +}
> 
> Drop the inline stuff, the compiler can decide that itself, especially
> on static functions. The inline is only a hint anyway.
> 
> [...]

Hi Marek,

Nope - inline does have an impact for functions in headers. If it's not
there & a file includes a header but doesn't use *all* of the functions
in it then the compiler will warn about the functions being unused. With
inline that isn't the case. Thus "static inline" is used quite
extensively in many of the headers under include/.

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

Re: [U-Boot] [PATCH 1/9] MIPS: Add arch-wide arch_cpu_init

[Paul Burton]

On 08/09/16 11:02, Marek Vasut wrote:
> On 09/07/2016 07:48 PM, Paul Burton wrote:
>> Add an implementation of arch_cpu_init that covers all MIPS boards, in
>> preparation for performing various pieces of initialisation there in
>> later patches.
>>
>> In order to allow the ath79 code to continue performing initialisation
>> at this point in the boot, it's converted to use a new mach_cpu_init
>> function which is called from arch_cpu_init.
>>
>> Signed-off-by: Paul Burton 
> 
> [...]
> 
> Hi!
> 
>> diff --git a/arch/mips/include/asm/u-boot-mips.h 
>> b/arch/mips/include/asm/u-boot-mips.h
>> index 1f527bb..0eaf32b 100644
>> --- a/arch/mips/include/asm/u-boot-mips.h
>> +++ b/arch/mips/include/asm/u-boot-mips.h
>> @@ -5,4 +5,16 @@
>>  #ifndef _U_BOOT_MIPS_H_
>>  #define _U_BOOT_MIPS_H_
>>  
>> +/**
>> + * mach_cpu_init() - Perform SoC/machine-specific CPU initialisation
>> + *
>> + * This is called from arch_cpu_init() to allow for SoC/machine-level code 
>> to
>> + * perform any CPU initialisation it may require.
> 
> Just call this function from arch_cpu_init() in various places instead
> of replacing arch_cpu_init() with it all over the place. Also rename it
> to arch_cpu_init_common() to make it more obvious what this does .

Hi Marek,

That's "backwards" compared with what this code actually does -
arch_cpu_init becomes the common function (ie. is arch-wide as in the
patch subject) and mach_cpu_init is for use by machines/SoCs - ie. code
under arch/mips/mach-*.

>> + */
>> +#ifdef CONFIG_MACH_CPU_INIT
>> +void mach_cpu_init(void);
>> +#else
>> +static inline void mach_cpu_init(void) {}
> 
> Implement this as __weak int and you can nuke the ifdefery .

I could make it weak, but then we don't let the compiler optimise it out
entirely for builds that don't need it (ie. everything except ath79).

I'd say that since the #ifdefery here is confined to this one case in
the header (which is a pretty common approach) it's ugliness is kept
minimal & its cost on binaries & runtime is as low as it can be at zero.

Daniel - do you have a preference?

> 
>> +#endif
>> +
>>  #endif /* _U_BOOT_MIPS_H_ */
>> diff --git a/arch/mips/mach-ath79/cpu.c b/arch/mips/mach-ath79/cpu.c
>> index 5756a06..a556b73 100644
>> --- a/arch/mips/mach-ath79/cpu.c
>> +++ b/arch/mips/mach-ath79/cpu.c
>> @@ -46,7 +46,7 @@ static const struct ath79_soc_desc desc[] = {
>>  {ATH79_SOC_QCA9561, "9561", REV_ID_MAJOR_QCA9561,   0},
>>  };
>>  
>> -int arch_cpu_init(void)
>> +void mach_cpu_init(void)
> 
> See above.
> 
>>  {
>>  void __iomem *base;
>>  enum ath79_soc_type soc = ATH79_SOC_UNKNOWN;
>> @@ -98,7 +98,6 @@ int arch_cpu_init(void)
>>  gd->arch.soc = soc;
>>  gd->arch.rev = rev;
>>  gd->arch.ver = ver;
>> -return 0;
> 
> That's a nope, keep the return value.

The implementation always returns zero, so I see no point.

Thanks,
Paul

> 
>>  }
>>  
>>  int print_cpuinfo(void)
>>
> 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] input: specify the default of I8042_KEYB in more correct manner

[Marek Vasut]

On 09/08/2016 11:47 AM, Masahiro Yamada wrote:
> Creating multiple entries of "config FOO" often gives us bad
> experiences.  In this case, we should specify "default X86"
> as platforms that want this keyboard by default.

Yep, I like this patch:

Acked-by: Marek Vasut 

btw on some of my computers , the 8042 is physically removable ;-)

> Signed-off-by: Masahiro Yamada 
> ---
> 
>  arch/x86/Kconfig  | 3 ---
>  drivers/input/Kconfig | 1 +
>  2 files changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 9207549..ac2d598 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -546,9 +546,6 @@ config I8254_TIMER
> Intel 8254 timer contains three counters which have fixed uses.
> Include this to have U-Boot set up the timer correctly.
>  
> -config I8042_KEYB
> - default y
> -
>  config SEABIOS
>   bool "Support booting SeaBIOS"
>   help
> diff --git a/drivers/input/Kconfig b/drivers/input/Kconfig
> index d560328..b3873c1 100644
> --- a/drivers/input/Kconfig
> +++ b/drivers/input/Kconfig
> @@ -17,6 +17,7 @@ config CROS_EC_KEYB
>  config I8042_KEYB
>   bool "Enable Intel i8042 keyboard support"
>   depends on DM_KEYBOARD
> + default X86
>   help
> This adds a driver for the i8042 keyboard controller, allowing the
> keyboard to be used on devices which support this controller. The
> 


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

Re: [U-Boot] [PATCH 8/9] MIPS: L2 cache support

[Marek Vasut]

On 09/07/2016 07:48 PM, Paul Burton wrote:
> This patch adds support for initialising & maintaining L2 caches on MIPS
> systems. The L2 cache configuration may be advertised through either
> coprocessor 0 or the MIPS Coherence Manager depending upon the system,
> and support for both is included.
> 
> If the L2 can be bypassed then we bypass it early in boot & initialise
> the L1 caches first, such that we can start making use of the L1
> instruction cache as early as possible. Otherwise we initialise the L2
> first such that the L1s have no opportunity to generate access to the
> uninitialised L2.
> 
> Signed-off-by: Paul Burton 
> ---
> 
>  arch/mips/Kconfig   |   6 ++
>  arch/mips/include/asm/cm.h  |  38 
>  arch/mips/include/asm/global_data.h |   3 +
>  arch/mips/include/asm/mipsregs.h|   5 +
>  arch/mips/lib/cache.c   |  62 -
>  arch/mips/lib/cache_init.S  | 180 
> +++-
>  6 files changed, 288 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
> index 732d129..8f97727 100644
> --- a/arch/mips/Kconfig
> +++ b/arch/mips/Kconfig
> @@ -301,6 +301,12 @@ config MIPS_L1_CACHE_SHIFT
>   default "4" if MIPS_L1_CACHE_SHIFT_4
>   default "5"
>  
> +config MIPS_L2_CACHE
> + bool
> + help
> +   Select this if your system includes an L2 cache and you want U-Boot
> +   to initialise & maintain it.
> +
>  config DYNAMIC_IO_PORT_BASE
>   bool
>  
> diff --git a/arch/mips/include/asm/cm.h b/arch/mips/include/asm/cm.h
> index 0261733..62ecef2 100644
> --- a/arch/mips/include/asm/cm.h
> +++ b/arch/mips/include/asm/cm.h
> @@ -12,8 +12,46 @@
>  #define GCR_BASE 0x0008
>  #define GCR_BASE_UPPER   0x000c
>  #define GCR_REV  0x0030
> +#define GCR_L2_CONFIG0x0130
> +#define GCR_L2_TAG_ADDR  0x0600
> +#define GCR_L2_TAG_ADDR_UPPER0x0604
> +#define GCR_L2_TAG_STATE 0x0608
> +#define GCR_L2_TAG_STATE_UPPER   0x060c
> +#define GCR_L2_DATA  0x0610
> +#define GCR_L2_DATA_UPPER0x0614
>  
>  /* GCR_REV CM versions */
>  #define GCR_REV_CM3  0x0800
>  
> +/* GCR_L2_CONFIG fields */
> +#define GCR_L2_CONFIG_ASSOC_SHIFT0
> +#define GCR_L2_CONFIG_ASSOC_BITS 8
> +#define GCR_L2_CONFIG_LINESZ_SHIFT   8
> +#define GCR_L2_CONFIG_LINESZ_BITS4
> +#define GCR_L2_CONFIG_SETSZ_SHIFT12
> +#define GCR_L2_CONFIG_SETSZ_BITS 4
> +#define GCR_L2_CONFIG_BYPASS (1 << 20)
> +
> +#ifndef __ASSEMBLY__
> +
> +#include 
> +
> +static inline void *mips_cm_base(void)
> +{
> + return (void *)CKSEG1ADDR(CONFIG_MIPS_CM_BASE);
> +}
> +
> +static inline unsigned long mips_cm_l2_line_size(void)
> +{
> + unsigned long l2conf, line_sz;
> +
> + l2conf = __raw_readl(mips_cm_base() + GCR_L2_CONFIG);
> +
> + line_sz = l2conf >> GCR_L2_CONFIG_LINESZ_SHIFT;
> + line_sz &= GENMASK(GCR_L2_CONFIG_LINESZ_BITS - 1, 0);
> + return line_sz ? (2 << line_sz) : 0;
> +}

Drop the inline stuff, the compiler can decide that itself, especially
on static functions. The inline is only a hint anyway.

[...]


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

Re: [U-Boot] [PATCH 1/9] MIPS: Add arch-wide arch_cpu_init

[Marek Vasut]

On 09/07/2016 07:48 PM, Paul Burton wrote:
> Add an implementation of arch_cpu_init that covers all MIPS boards, in
> preparation for performing various pieces of initialisation there in
> later patches.
> 
> In order to allow the ath79 code to continue performing initialisation
> at this point in the boot, it's converted to use a new mach_cpu_init
> function which is called from arch_cpu_init.
> 
> Signed-off-by: Paul Burton 

[...]

Hi!

> diff --git a/arch/mips/include/asm/u-boot-mips.h 
> b/arch/mips/include/asm/u-boot-mips.h
> index 1f527bb..0eaf32b 100644
> --- a/arch/mips/include/asm/u-boot-mips.h
> +++ b/arch/mips/include/asm/u-boot-mips.h
> @@ -5,4 +5,16 @@
>  #ifndef _U_BOOT_MIPS_H_
>  #define _U_BOOT_MIPS_H_
>  
> +/**
> + * mach_cpu_init() - Perform SoC/machine-specific CPU initialisation
> + *
> + * This is called from arch_cpu_init() to allow for SoC/machine-level code to
> + * perform any CPU initialisation it may require.

Just call this function from arch_cpu_init() in various places instead
of replacing arch_cpu_init() with it all over the place. Also rename it
to arch_cpu_init_common() to make it more obvious what this does .

> + */
> +#ifdef CONFIG_MACH_CPU_INIT
> +void mach_cpu_init(void);
> +#else
> +static inline void mach_cpu_init(void) {}

Implement this as __weak int and you can nuke the ifdefery .

> +#endif
> +
>  #endif /* _U_BOOT_MIPS_H_ */
> diff --git a/arch/mips/mach-ath79/cpu.c b/arch/mips/mach-ath79/cpu.c
> index 5756a06..a556b73 100644
> --- a/arch/mips/mach-ath79/cpu.c
> +++ b/arch/mips/mach-ath79/cpu.c
> @@ -46,7 +46,7 @@ static const struct ath79_soc_desc desc[] = {
>   {ATH79_SOC_QCA9561, "9561", REV_ID_MAJOR_QCA9561,   0},
>  };
>  
> -int arch_cpu_init(void)
> +void mach_cpu_init(void)

See above.

>  {
>   void __iomem *base;
>   enum ath79_soc_type soc = ATH79_SOC_UNKNOWN;
> @@ -98,7 +98,6 @@ int arch_cpu_init(void)
>   gd->arch.soc = soc;
>   gd->arch.rev = rev;
>   gd->arch.ver = ver;
> - return 0;

That's a nope, keep the return value.

>  }
>  
>  int print_cpuinfo(void)
> 


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

[U-Boot] [PATCH 2/2] input: specify the default of I8042_KEYB in more correct manner

[Masahiro Yamada]

Creating multiple entries of "config FOO" often gives us bad
experiences.  In this case, we should specify "default X86"
as platforms that want this keyboard by default.

Signed-off-by: Masahiro Yamada 
---

 arch/x86/Kconfig  | 3 ---
 drivers/input/Kconfig | 1 +
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 9207549..ac2d598 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -546,9 +546,6 @@ config I8254_TIMER
  Intel 8254 timer contains three counters which have fixed uses.
  Include this to have U-Boot set up the timer correctly.
 
-config I8042_KEYB
-   default y
-
 config SEABIOS
bool "Support booting SeaBIOS"
help
diff --git a/drivers/input/Kconfig b/drivers/input/Kconfig
index d560328..b3873c1 100644
--- a/drivers/input/Kconfig
+++ b/drivers/input/Kconfig
@@ -17,6 +17,7 @@ config CROS_EC_KEYB
 config I8042_KEYB
bool "Enable Intel i8042 keyboard support"
depends on DM_KEYBOARD
+   default X86
help
  This adds a driver for the i8042 keyboard controller, allowing the
  keyboard to be used on devices which support this controller. The
-- 
1.9.1

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

[U-Boot] [PATCH 1/2] sandbox, x86: select DM_KEYBOARD instead of default y entry

[Masahiro Yamada]

Once we migrate to DM-based drivers, we cannot go back to legacy
ones, i.e. config options like DM_* are not user-configurable.

Make SANDBOX and X86 select DM_KEYBOARD like other platforms do.

Signed-off-by: Masahiro Yamada 
---

 arch/Kconfig | 2 ++
 arch/sandbox/Kconfig | 3 ---
 arch/x86/Kconfig | 3 ---
 3 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/arch/Kconfig b/arch/Kconfig
index d718a68..ffc7b45 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -62,6 +62,7 @@ config SANDBOX
bool "Sandbox"
select SUPPORT_OF_CONTROL
select DM
+   select DM_KEYBOARD
select DM_SPI_FLASH
select DM_SERIAL
select DM_I2C
@@ -83,6 +84,7 @@ config X86
select HAVE_PRIVATE_LIBGCC
select SUPPORT_OF_CONTROL
select DM
+   select DM_KEYBOARD
select DM_SERIAL
select DM_GPIO
select DM_SPI
diff --git a/arch/sandbox/Kconfig b/arch/sandbox/Kconfig
index d4c1ee0..c931c0b 100644
--- a/arch/sandbox/Kconfig
+++ b/arch/sandbox/Kconfig
@@ -25,7 +25,4 @@ config PCI
  used on some devices to allow the CPU to communicate with its
  peripherals.
 
-config DM_KEYBOARD
-   default y
-
 endmenu
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 5193ee7..9207549 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -549,9 +549,6 @@ config I8254_TIMER
 config I8042_KEYB
default y
 
-config DM_KEYBOARD
-   default y
-
 config SEABIOS
bool "Support booting SeaBIOS"
help
-- 
1.9.1

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

Re: [U-Boot] [PATCH v2 01/44] Correct defconfigs using savedefconfig

[Masahiro Yamada]

2016-09-07 22:05 GMT+09:00 Tom Rini :
> On Wed, Sep 07, 2016 at 01:03:23PM +0900, Masahiro Yamada wrote:
>> 2016-09-07 3:01 GMT+09:00 Tom Rini :
>> > On Mon, Sep 05, 2016 at 11:47:00AM +0900, Masahiro Yamada wrote:
>> >> 2016-08-30 9:21 GMT+09:00 Simon Glass :
>> >> > Update the defconfig files to match their canonical form, as produced by
>> >> > 'make safedefconfig'.
>> >> >
>> >> > This is the result of running 'tools/moveconfig.py -s' on the tree.
>> >> >
>> >> > Signed-off-by: Simon Glass 
>> >>
>> >> >
>> >> > diff --git a/configs/10m50_defconfig b/configs/10m50_defconfig
>> >> > index 15952af..0e3ad96 100644
>> >> > --- a/configs/10m50_defconfig
>> >> > +++ b/configs/10m50_defconfig
>> >> > @@ -1,7 +1,7 @@
>> >> >  CONFIG_NIOS2=y
>> >> >  CONFIG_SYS_CONFIG_NAME="10m50_devboard"
>> >> > -CONFIG_DM_SERIAL=y
>> >> >  CONFIG_DM_GPIO=y
>> >> > +CONFIG_DM_SERIAL=y
>> >> >  CONFIG_DEFAULT_DEVICE_TREE="10m50_devboard"
>> >> >  CONFIG_FIT=y
>> >> >  CONFIG_OF_BOARD_SETUP=y
>> >> > diff --git a/configs/3c120_defconfig b/configs/3c120_defconfig
>> >> > index b19c956..0c3fbde 100644
>> >> > --- a/configs/3c120_defconfig
>> >> > +++ b/configs/3c120_defconfig
>> >> > @@ -1,7 +1,7 @@
>> >> >  CONFIG_NIOS2=y
>> >> >  CONFIG_SYS_CONFIG_NAME="3c120_devboard"
>> >> > -CONFIG_DM_SERIAL=y
>> >> >  CONFIG_DM_GPIO=y
>> >> > +CONFIG_DM_SERIAL=y
>> >> >  CONFIG_DEFAULT_DEVICE_TREE="3c120_devboard"
>> >> >  CONFIG_FIT=y
>> >> >  CONFIG_OF_BOARD_SETUP=y
>> >>
>> >>
>> >>
>> >> If the following patch is applied
>> >> http://patchwork.ozlabs.org/patch/664076/
>> >> the savedefconfig sync will produce completely different
>> >> results for these defconfigs.
>> >>
>> >>
>> >> The "make savedefconfig" sorts CONFIGs
>> >> in the order as Kconfig entries are parsed.
>> >>
>> >> In other words, the canonical order changes
>> >> every time bare default entries are added/removed
>> >> in board/*/Kconfig.
>> >>
>> >>
>> >> We are just repeating mad churn...
>> >
>> > Yes, but it's churn we have to live with until everything is migrated,
>> > no?
>> >
>>
>> I am OK with adding CONFIG to defconfig files.
>>
>> But I often see CONFIGs moving up/down
>> every time we sync defconfigs,
>> most of them are unrelated to what we want to move.
>>
>>
>> The cause is that people often add
>>   config FOO
>> default y
>>
>> around in board/*/Kconfig
>> (and eventually I fix it).
>
> OK, fair point, I need to be better about catching those when they sneak
> in.


Anyway, current defconfigs are heavily out of sync,
so we need to sync them at some point.
(maybe right after the upcoming release?)


BTW,
This kind of patch becomes stale soon.
I guess Tom can do global sync any time suitable for him,
instead of letting a huge patch fly in the ML.
Or somebody can request it like
"Hey, I want to work on Kconfig moves, but before that, please sync
the mainline!".



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

Re: [U-Boot] [RFC] bootm: fix passing argc to standalone apps

[Zubair Lutfullah Kakakhel]

Hi,

On 09/08/2016 09:23 AM, Zubair Lutfullah Kakakhel wrote:

This bug appears in b6396403 which makes u-boot unable to pass
arguments via bootm to a standalone application without this patch.

Steps to reproduce.

Compile a u-boot. Use mkimage to package the standalone hello_world.bin
file.

e.g. For the MIPS Boston platform

mkimage -n "hello" -A mips -O u-boot -C none -T standalone \
 -a 0x8020 -d hello_world.bin \
 -ep 0x8020 hello_out

Then tftp hello_out and run it using

boston # dhcp 192.168.154.45:hello_out
...
boston # bootm $loadaddr 123 321

Without the patch the following output is observed.

Example expects ABI version 8
Actual U-Boot ABI version 8
Hello World
argc = 0
argv[0] = "0x8800"

With the patch, you see the following.

boston # bootm $loadaddr 123 321
   Image Name:   hello
   Image Type:   MIPS U-Boot Standalone Program (uncompressed)
   Data Size:1240 Bytes = 1.2 KiB
   Load Address: 8020
   Entry Point:  8020
   Verifying Checksum ... OK
   Loading Standalone Program ... OK
Example expects ABI version 8
Actual U-Boot ABI version 8
Hello World
argc = 0

argc = 3

argv[0] = "0x8800"

argv[1] = 123
argv[2] = 321

Copy paste fluke in the git log. Sorry.
The above appears in reality

Regards,
ZubairLK


Hit any key to exit ...

The go command at the entry point seems to work.

boston # go 0x8020 123 321
Example expects ABI version 8
Actual U-Boot ABI version 8
Hello World
argc = 3
argv[0] = "0x8020"
argv[1] = "123"
argv[2] = "321"
argv[3] = ""
Hit any key to exit ...

Signed-off-by: Zubair Lutfullah Kakakhel 

---

Tested on the MIPS Boston platform.
---
 common/bootm.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/common/bootm.c b/common/bootm.c
index a4d22a6..b2c0912 100644
--- a/common/bootm.c
+++ b/common/bootm.c
@@ -619,10 +619,8 @@ int do_bootm_states(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[],
if (!ret && (states & BOOTM_STATE_FINDOS))
ret = bootm_find_os(cmdtp, flag, argc, argv);

-   if (!ret && (states & BOOTM_STATE_FINDOTHER)) {
+   if (!ret && (states & BOOTM_STATE_FINDOTHER))
ret = bootm_find_other(cmdtp, flag, argc, argv);
-   argc = 0;   /* consume the args */
-   }

/* Load the OS */
if (!ret && (states & BOOTM_STATE_LOADOS)) {


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

[U-Boot] [RFC] bootm: fix passing argc to standalone apps

[Zubair Lutfullah Kakakhel]

This bug appears in b6396403 which makes u-boot unable to pass
arguments via bootm to a standalone application without this patch.

Steps to reproduce.

Compile a u-boot. Use mkimage to package the standalone hello_world.bin
file.

e.g. For the MIPS Boston platform

mkimage -n "hello" -A mips -O u-boot -C none -T standalone \
 -a 0x8020 -d hello_world.bin \
 -ep 0x8020 hello_out

Then tftp hello_out and run it using

boston # dhcp 192.168.154.45:hello_out
...
boston # bootm $loadaddr 123 321

Without the patch the following output is observed.

Example expects ABI version 8
Actual U-Boot ABI version 8
Hello World
argc = 0
argv[0] = "0x8800"

With the patch, you see the following.

boston # bootm $loadaddr 123 321
   Image Name:   hello
   Image Type:   MIPS U-Boot Standalone Program (uncompressed)
   Data Size:1240 Bytes = 1.2 KiB
   Load Address: 8020
   Entry Point:  8020
   Verifying Checksum ... OK
   Loading Standalone Program ... OK
Example expects ABI version 8
Actual U-Boot ABI version 8
Hello World
argc = 0
argv[0] = "0x8800"
Hit any key to exit ...

The go command at the entry point seems to work.

boston # go 0x8020 123 321
Example expects ABI version 8
Actual U-Boot ABI version 8
Hello World
argc = 3
argv[0] = "0x8020"
argv[1] = "123"
argv[2] = "321"
argv[3] = ""
Hit any key to exit ...

Signed-off-by: Zubair Lutfullah Kakakhel 

---

Tested on the MIPS Boston platform.
---
 common/bootm.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/common/bootm.c b/common/bootm.c
index a4d22a6..b2c0912 100644
--- a/common/bootm.c
+++ b/common/bootm.c
@@ -619,10 +619,8 @@ int do_bootm_states(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[],
if (!ret && (states & BOOTM_STATE_FINDOS))
ret = bootm_find_os(cmdtp, flag, argc, argv);
 
-   if (!ret && (states & BOOTM_STATE_FINDOTHER)) {
+   if (!ret && (states & BOOTM_STATE_FINDOTHER))
ret = bootm_find_other(cmdtp, flag, argc, argv);
-   argc = 0;   /* consume the args */
-   }
 
/* Load the OS */
if (!ret && (states & BOOTM_STATE_LOADOS)) {
-- 
1.9.1

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