Re: [U-Boot] [PATCH v4 00/10] Improvements for the dwc3_generic driver

[Jean-Jacques Hiblot]

On 06/12/2018 21:56, Loic Devulder wrote:

Hi,

I re-tested this series on Khadas VIM1 and it still fix the USB issue I
had with 'usb reset' (I already tested v2 patches).

I just have a message and I'm not sure that I had it last time:
"Error disabling PHY supply
Can't shutdown USB PHY1 for dwc3@c900"

But USB stack looks ok, I can plug/unplug USB key  and do the reset, all
works as expected.

Since my last test lot of changes has been done in Amlogic SoCs, maybe
it's because of this?

So if you want you can add my tested-by flag.
Tested-by: Loic Devulder 

Thank you for testing


On 11/29/18 10:52 AM, Jean-Jacques Hiblot wrote:

This series aims at bringing improvements to the dwc3_generic driver so
that it can be used by most of the platforms using the dwc3 controller.

I tested this on with DRA7 and AM57x platforms for both Peripheral and Host
operations. The code to enable DM USB host & dev support for those
platforms will be submitted in a separate series.

Michal Simek has tested this series:
" I have tested it on zcu100 with usb stick, usb to ethernet converter and
also dfu.
Tested-by: Michal Simek "

Enhancements:
- use separate Kconfig option for DM USB Periphal and DM USB Host. This
allow platforms to keep their non-DM USB peripheral code and use the DM
USB host.
- fixes the bind/probe confusion in dwc3_generic. The probe is done when
the USB device is first needed.
- handles PHYs when in the peripheral mode. The code to handle the PHYs is
shared with the host side
- handles clock and reset
- bind host controller to the more generic driver 'xhci-dwc3'


Changes in v4:
- rebased on latest U-Boot
- renamed DM_USB_DEV as DM_USB_GADGET
- Add a new commit to create a new UCLASS for USB gadget drivers

Changes in v3:
- fixes bug dwc3_setup_phy(): the phy arrays wasn't returned. This was
   visible only when the device is removed.
- Stub the DWC3 PHY operations if CONFIG_IS_ENABLED(PHY) is false.
   This fixes all build issues but one (evb-rk3328).
- Fix build issue with evb-rk3328 by enabling CONFIG_USB_DWC3. This has
   little impact on the footprint and should not break the runtime as the
   xhci-rockchip driver has its own probe function.
   Nevertheless this was !!! NOT TESTED !!! by lack of hw

Changes in v2:
- Updated commit log
- Fixed typo in thordown.c
- select DM_USB_DEV by default for zynqmp platforms

Jean-Jacques Hiblot (10):
   usb: gadget: Do not call board_usb_xxx() directly in USB gadget
 drivers
   usb: introduce a separate config option for DM USB device
   usb: udc: implement DM versions of
 usb_gadget_initialize()/_release()/_handle_interrupt()
   dwc3_generic: do not probe the USB device driver when it's bound
   dwc3: move phy operation to core.c
   dm: usb: create a new UCLASS ID for USB gadget devices
   configs: evb-rk3328: Enable CONFIG_USB_DWC3
   dwc3-generic: Handle the PHYs, the clocks and the reset lines
   dwc3-generic: Add select_dr_mode operation
   usb: dwc3: Fix a compilation error with the edison defconfig

  arch/arm/Kconfig|   2 +
  board/sunxi/board.c |   2 +-
  cmd/fastboot.c  |   4 +-
  cmd/rockusb.c   |   4 +-
  cmd/thordown.c  |   4 +-
  cmd/usb_gadget_sdp.c|   4 +-
  cmd/usb_mass_storage.c  |   4 +-
  common/dfu.c|   6 +-
  configs/evb-rk3328_defconfig|   1 +
  drivers/usb/Kconfig |  14 +++
  drivers/usb/dwc3/Kconfig|   7 +-
  drivers/usb/dwc3/core.c |  89 ++-
  drivers/usb/dwc3/dwc3-generic.c | 208 
  drivers/usb/dwc3/ep0.c  |   2 +-
  drivers/usb/gadget/ether.c  |  40 ++-
  drivers/usb/gadget/udc/Makefile |   4 +
  drivers/usb/gadget/udc/udc-core.c   |   3 +-
  drivers/usb/gadget/udc/udc-uclass.c |  58 ++
  drivers/usb/host/xhci-dwc3.c|  95 ++--
  drivers/usb/musb-new/omap2430.c |   2 +-
  drivers/usb/musb-new/sunxi.c|   2 +-
  include/dm/uclass-id.h  |   1 +
  include/dwc3-uboot.h|  19 
  include/linux/usb/gadget.h  |  18 
  24 files changed, 401 insertions(+), 192 deletions(-)
  create mode 100644 drivers/usb/gadget/udc/udc-uclass.c


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

Re: [U-Boot] [PATCH] ARM: mvebu: sync Armada-38x dts with Linux 4.20

[Stefan Roese]

On 07.12.18 04:21, Chris Packham wrote:

Sync the Armada-38x device tree files with Linux 4.20-rc5. The changes
not taken are new compatible strings for the uart and nand flash
controller. The nand binding is best updated if/when the mtd/nand
infrastructure is updated.

Signed-off-by: Chris Packham 
---
I've updated the clearfog and controlcenterdc boards enough for them to
compile. In the case of clearfog there are a lot of changes in Linux so
it's probably best if the board maintainer looks at what is needed.
controlcenterdc isn't in linux so again I've just done enough for
compilation.


Thanks for working on this. Its very likely though, that this patch
will conflict with the "spi-flash: switch to "jedec, spi-nor" binding"
patch series from Neil Armstrong though.

Nevertheless:

Reviewed-by: Stefan Roese 

Thanks,
Stefan



  arch/arm/dts/armada-380.dtsi|  44 +--
  arch/arm/dts/armada-385.dtsi|  63 +
  arch/arm/dts/armada-388-clearfog.dts|  25 +-
  arch/arm/dts/armada-388.dtsi|  43 +--
  arch/arm/dts/armada-38x-controlcenterdc.dts |  68 ++---
  arch/arm/dts/armada-38x.dtsi| 283 
  6 files changed, 237 insertions(+), 289 deletions(-)

diff --git a/arch/arm/dts/armada-380.dtsi b/arch/arm/dts/armada-380.dtsi
index 5102d19cc8f4..cff1269f3fbf 100644
--- a/arch/arm/dts/armada-380.dtsi
+++ b/arch/arm/dts/armada-380.dtsi
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
  /*
   * Device Tree Include file for Marvell Armada 380 SoC.
   *
@@ -6,44 +7,6 @@
   * Lior Amsalem 
   * Gregory CLEMENT 
   * Thomas Petazzoni 
- *
- * This file is dual-licensed: you can use it either under the terms
- * of the GPL or the X11 license, at your option. Note that this dual
- * licensing only applies to this file, and not this project as a
- * whole.
- *
- *  a) This file is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of the
- * License, or (at your option) any later version.
- *
- * This file is distributed in the hope that it will be useful
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * Or, alternatively
- *
- *  b) Permission is hereby granted, free of charge, to any person
- * obtaining a copy of this software and associated documentation
- * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use
- * copy, modify, merge, publish, distribute, sublicense, and/or
- * sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following
- * conditions:
- *
- * The above copyright notice and this permission notice shall be
- * included in all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
- * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
- * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
- * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
- * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
- * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
- * OTHER DEALINGS IN THE SOFTWARE.
   */
  
  #include "armada-38x.dtsi"

@@ -71,7 +34,7 @@
};
};
  
-		pcie-controller {

+   pcie {
compatible = "marvell,armada-370-pcie";
status = "disabled";
device_type = "pci";
@@ -104,6 +67,7 @@
#interrupt-cells = <1>;
ranges = <0x8200 0 0 0x8200 0x1 0 1 0
  0x8100 0 0 0x8100 0x1 0 1 0>;
+   bus-range = <0x00 0xff>;
interrupt-map-mask = <0 0 0 0>;
interrupt-map = <0 0 0 0 &gic GIC_SPI 29 
IRQ_TYPE_LEVEL_HIGH>;
marvell,pcie-port = <0>;
@@ -122,6 +86,7 @@
#interrupt-cells = <1>;
ranges = <0x8200 0 0 0x8200 0x2 0 1 0
  0x8100 0 0 0x8100 0x2 0 1 0>;
+   bus-range = <0x00 0xff>;
interrupt-map-mask = <0 0 0 0>;
interrupt-map = <0 0 0 0 &gic GIC_SPI 33 
IRQ_TYPE_LEVEL_HIGH>;
marvell,pcie-port = <1>;
@@ -140,6 +105,7 @@
#interrupt-cells = <1>;
 

Re: [U-Boot] [PATCH] ARM: mvebu: define CONFIG_BLK for db-88f6820-amc

[Stefan Roese]

On 07.12.18 04:19, Chris Packham wrote:

db-88f6820-amc uses CONFIG_DM_USB and CONFIG_USB_STORAGE already so
define CONFIG_BLK to prepare it for full conversion to DM.

Signed-off-by: Chris Packham 


Reviewed-by: Stefan Roese 

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

Re: [U-Boot] [RFC PATCH v2 00/11] SF: Migrate to Linux SPI NOR framework

[Vignesh R]

On 07/12/18 12:47 AM, Simon Goldschmidt wrote:
> Am 06.12.2018 um 18:39 schrieb Vignesh R:
>> On 06/12/18 10:06 PM, Simon Goldschmidt wrote:
>>> Am 06.12.2018 um 14:54 schrieb Simon Goldschmidt:
 On Thu, Dec 6, 2018 at 2:45 PM Vignesh R  wrote:
> On 06/12/18 2:15 AM, Simon Goldschmidt wrote:
>> Am 05.12.2018 um 07:55 schrieb Simon Goldschmidt:
>>> On Wed, Dec 5, 2018 at 7:51 AM Vignesh R  wrote:
> [...]
[...]
>>> Had a quick test with both standard and tiny in SPL and both configs now
>>> work on my board. I haven't tested SFDP as you said it does not works on
>>> Cadence QSPI. (I tested compiling it though, and that works now.)
>>>
> 
> After enabling DEBUG in spi-mem.c, I see that we're changing to 4-byte 
> mode (via b7h) instead of using 4-byte opcodes. Unfortunately, this 
> conflicts with the boot rom using the default read opcose in 3-byte mode 
> on warm reboot.
> 
> Do you plan to change this or would this be fixed by parsing SFDP?
> 

Oh, I see n25q256a entry is missing SPI_NOR_4B_OPCODES flag in the
spi_nor_ids table. In non SFDP configuration adding SPI_NOR_4B_OPCODES
flag should avoid sending 0xb7 and use 4-byte opcodes directly. May be
you could give that a try?

>>
>> I used below hack to test SFDP with Cadence QSPI:
> 
> Just by accident, I saw that enabling the SFDP config does not seem to 
> break booting. But it still switches to 4-byte mode, so it probably just 
> fails to parse and continues the non-SFDP way?
> 

For stateless 4-byte addressing mode with SFDP, we need to parse JEDEC
4-byte Address Instruction Parameter Header and Table (part of JESD216B)
to get 4 byte addressing opcode.
We need to port this patch once accepted to Linux kernel:
https://lore.kernel.org/patchwork/patch/1022200/

>>
>> diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
>> index a8af35203035..9dbf9aa7d20c 100644
>> --- a/drivers/spi/cadence_qspi_apb.c
>> +++ b/drivers/spi/cadence_qspi_apb.c
>> @@ -559,7 +559,7 @@ int cadence_qspi_apb_indirect_read_setup(struct 
>> cadence_spi_platdata *plat,
>>  /* Configure the opcode */
>>  rd_reg = cmdbuf[0] << CQSPI_REG_RD_INSTR_OPCODE_LSB;
>>   
>> -   if (rx_width & SPI_RX_QUAD)
>> +   if (rx_width & SPI_RX_QUAD && (cmdbuf[0] != 0x5a))
> 
> But this is Spansion-specific, right?
> 

Nope, SFDP command operates in 1-1-1 mode for all flash devices. But if
you don't have rx width set to 4 in DT, above hack is not needed and
SFDP parsing would work fine with Cadence QSPI.


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

Re: [U-Boot] [PATCH] pinctrl: meson: axg: Fix GPIO pin offsets

[Kevin Hilman]

Carlo Caione  writes:

> The pin number (first and last) in the bank definition is missing the
> pin base offset shifting. This is causing a miscalculation when
> retrieving the register and pin offsets in the GPIO driver causing the
> 'gpio' command to drive the wrong pins / GPIOs in the second GPIO chip
> (the AO bank is driven correctly because the shifting is already 0).
>
> Signed-off-by: Carlo Caione 

This looks like it could use a Fixes: tag for stable.

Kevin

> ---
>  drivers/pinctrl/meson/pinctrl-meson-axg.c | 22 +++---
>  1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/pinctrl/meson/pinctrl-meson-axg.c 
> b/drivers/pinctrl/meson/pinctrl-meson-axg.c
> index a54fbce910..3bbbe817b4 100644
> --- a/drivers/pinctrl/meson/pinctrl-meson-axg.c
> +++ b/drivers/pinctrl/meson/pinctrl-meson-axg.c
> @@ -14,7 +14,7 @@
>  
>  #include "pinctrl-meson-axg.h"
>  
> -#define EE_OFF   14
> +#define EE_OFF   15
>  
>  /* emmc */
>  static const unsigned int emmc_nand_d0_pins[] = {BOOT_0};
> @@ -893,17 +893,17 @@ static struct meson_pmx_func 
> meson_axg_aobus_functions[] = {
>  };
>  
>  static struct meson_bank meson_axg_periphs_banks[] = {
> - /*   namefirst  last  pullen  pulldir out in  */
> - BANK("Z",GPIOZ_0,   GPIOZ_10, 3,  0,  3,  0,  9,  0,  10, 0,  11, 
> 0),
> - BANK("BOOT", BOOT_0,BOOT_14,  4,  0,  4,  0,  12, 0,  13, 0,  14, 
> 0),
> - BANK("A",GPIOA_0,   GPIOA_20, 0,  0,  0,  0,  0,  0,  1,  0,  2,  
> 0),
> - BANK("X",GPIOX_0,   GPIOX_22, 2,  0,  2,  0,  6,  0,  7,  0,  8,  
> 0),
> - BANK("Y",GPIOY_0,   GPIOY_15, 1,  0,  1,  0,  3,  0,  4,  0,  5,  
> 0),
> + /*   namefirst  lastpullen  
> pulldir out in  */
> + BANK("Z",PIN(GPIOZ_0, EE_OFF),  PIN(GPIOZ_10, EE_OFF), 3,  0,  
> 3,  0,  9,  0,  10, 0,  11, 0),
> + BANK("BOOT", PIN(BOOT_0, EE_OFF),   PIN(BOOT_14, EE_OFF),  4,  0,  
> 4,  0,  12, 0,  13, 0,  14, 0),
> + BANK("A",PIN(GPIOA_0, EE_OFF),  PIN(GPIOA_20, EE_OFF), 0,  0,  
> 0,  0,  0,  0,  1,  0,  2,  0),
> + BANK("X",PIN(GPIOX_0, EE_OFF),  PIN(GPIOX_22, EE_OFF), 2,  0,  
> 2,  0,  6,  0,  7,  0,  8,  0),
> + BANK("Y",PIN(GPIOY_0, EE_OFF),  PIN(GPIOY_15, EE_OFF), 1,  0,  
> 1,  0,  3,  0,  4,  0,  5,  0),
>  };
>  
>  static struct meson_bank meson_axg_aobus_banks[] = {
> - /*   namefirst  last   pullen  pulldir out in  
> */
> - BANK("AO",   GPIOAO_0,  GPIOAO_13, 0,  16,  0, 0,  0,  0,  0, 16,  1,  
> 0),
> + /*   namefirst  last  pullen  pulldir   
>   out in  */
> + BANK("AO",   PIN(GPIOAO_0, 0),  PIN(GPIOAO_13, 0), 0,  16,  0, 0,  0,  
> 0,  0, 16,  1,  0),
>  };
>  
>  static struct meson_pmx_bank meson_axg_periphs_pmx_banks[] = {
> @@ -931,11 +931,11 @@ static struct meson_axg_pmx_data 
> meson_axg_aobus_pmx_banks_data = {
>  
>  struct meson_pinctrl_data meson_axg_periphs_pinctrl_data = {
>   .name   = "periphs-banks",
> - .pin_base   = 11,
> + .pin_base   = 15,
>   .groups = meson_axg_periphs_groups,
>   .funcs  = meson_axg_periphs_functions,
>   .banks  = meson_axg_periphs_banks,
> - .num_pins   = 100,
> + .num_pins   = 86,
>   .num_groups = ARRAY_SIZE(meson_axg_periphs_groups),
>   .num_funcs  = ARRAY_SIZE(meson_axg_periphs_functions),
>   .num_banks  = ARRAY_SIZE(meson_axg_periphs_banks),
> -- 
> 2.19.1
>
>
> ___
> linux-amlogic mailing list
> linux-amlo...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: mx5: Enable WDT and bootcounter on M53Menlo

[Marek Vasut]

On 12/06/2018 09:30 PM, Tom Rini wrote:
> On Mon, Dec 03, 2018 at 11:12:54PM +0100, Marek Vasut wrote:
>> Enable watchdog and bootcounter support on the M53Menlo board.
>>
>> Signed-off-by: Marek Vasut 
>> Cc: Stefano Babic 
>> ---
>>  configs/m53menlo_defconfig | 7 +++
>>  include/configs/m53menlo.h | 5 +
>>  2 files changed, 12 insertions(+)
>>
>> diff --git a/configs/m53menlo_defconfig b/configs/m53menlo_defconfig
>> index 795f8a3ebc..8e26431969 100644
>> --- a/configs/m53menlo_defconfig
>> +++ b/configs/m53menlo_defconfig
>> @@ -20,6 +20,7 @@ CONFIG_SYS_CONSOLE_IS_IN_ENV=y
>>  CONFIG_VERSION_VARIABLE=y
>>  CONFIG_SPL_BOARD_INIT=y
>>  CONFIG_SPL_NAND_SUPPORT=y
>> +CONFIG_SPL_WATCHDOG_SUPPORT=y
>>  CONFIG_HUSH_PARSER=y
>>  CONFIG_CMD_ASKENV=y
>>  CONFIG_CMD_GREPENV=y
>> @@ -33,6 +34,7 @@ CONFIG_CMD_DHCP=y
>>  CONFIG_CMD_MII=y
>>  CONFIG_CMD_PING=y
>>  CONFIG_CMD_BMP=y
>> +CONFIG_CMD_BOOTCOUNT=y
>>  CONFIG_CMD_DATE=y
>>  CONFIG_CMD_BTRFS=y
>>  CONFIG_CMD_EXT4=y
>> @@ -44,6 +46,11 @@ CONFIG_MTDIDS_DEFAULT="nand0=mxc_nand"
>>  
>> CONFIG_MTDPARTS_DEFAULT="mtdparts=mxc_nand:1m(u-boot),512k(env1),512k(env2),-(ubi)"
>>  CONFIG_CMD_UBI=y
>>  CONFIG_ENV_IS_IN_NAND=y
>> +CONFIG_BOOTCOUNT_LIMIT=y
>> +CONFIG_BOOTCOUNT_BOOTLIMIT=3
>> +CONFIG_SYS_BOOTCOUNT_SINGLEWORD=y
>> +CONFIG_SYS_BOOTCOUNT_ADDR=0x53FA401C
>> +CONFIG_SYS_BOOTCOUNT_MAGIC=0x0B01C041
>>  CONFIG_FSL_ESDHC=y
>>  CONFIG_NAND=y
>>  CONFIG_NAND_MXC=y
>> diff --git a/include/configs/m53menlo.h b/include/configs/m53menlo.h
>> index 94214b135d..bef0c9b31d 100644
>> --- a/include/configs/m53menlo.h
>> +++ b/include/configs/m53menlo.h
>> @@ -158,6 +158,11 @@
>>  /* IIM Fuses */
>>  #define CONFIG_FSL_IIM
>>  
>> +/* Watchdog */
>> +#define CONFIG_HW_WATCHDOG
>> +#define CONFIG_IMX_WATCHDOG
> 
> At least these two symbols are in Kconfig today, please use them (and
> maybe some guard symbol is missing), thanks.

Fixed

>> +#define CONFIG_WATCHDOG_TIMEOUT_MSECS 8000
> 
> This one isn't migrated yet, so I can't complain, only beg for a
> migration :)

Should be doable by running the script, there don't seem to be any
intricacies involved with this one.

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

[U-Boot] [PATCH] ARM: mvebu: sync Armada-38x dts with Linux 4.20

[Chris Packham]

Sync the Armada-38x device tree files with Linux 4.20-rc5. The changes
not taken are new compatible strings for the uart and nand flash
controller. The nand binding is best updated if/when the mtd/nand
infrastructure is updated.

Signed-off-by: Chris Packham 
---
I've updated the clearfog and controlcenterdc boards enough for them to
compile. In the case of clearfog there are a lot of changes in Linux so
it's probably best if the board maintainer looks at what is needed.
controlcenterdc isn't in linux so again I've just done enough for
compilation.

 arch/arm/dts/armada-380.dtsi|  44 +--
 arch/arm/dts/armada-385.dtsi|  63 +
 arch/arm/dts/armada-388-clearfog.dts|  25 +-
 arch/arm/dts/armada-388.dtsi|  43 +--
 arch/arm/dts/armada-38x-controlcenterdc.dts |  68 ++---
 arch/arm/dts/armada-38x.dtsi| 283 
 6 files changed, 237 insertions(+), 289 deletions(-)

diff --git a/arch/arm/dts/armada-380.dtsi b/arch/arm/dts/armada-380.dtsi
index 5102d19cc8f4..cff1269f3fbf 100644
--- a/arch/arm/dts/armada-380.dtsi
+++ b/arch/arm/dts/armada-380.dtsi
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
 /*
  * Device Tree Include file for Marvell Armada 380 SoC.
  *
@@ -6,44 +7,6 @@
  * Lior Amsalem 
  * Gregory CLEMENT 
  * Thomas Petazzoni 
- *
- * This file is dual-licensed: you can use it either under the terms
- * of the GPL or the X11 license, at your option. Note that this dual
- * licensing only applies to this file, and not this project as a
- * whole.
- *
- *  a) This file is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of the
- * License, or (at your option) any later version.
- *
- * This file is distributed in the hope that it will be useful
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * Or, alternatively
- *
- *  b) Permission is hereby granted, free of charge, to any person
- * obtaining a copy of this software and associated documentation
- * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use
- * copy, modify, merge, publish, distribute, sublicense, and/or
- * sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following
- * conditions:
- *
- * The above copyright notice and this permission notice shall be
- * included in all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
- * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
- * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
- * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
- * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
- * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
- * OTHER DEALINGS IN THE SOFTWARE.
  */
 
 #include "armada-38x.dtsi"
@@ -71,7 +34,7 @@
};
};
 
-   pcie-controller {
+   pcie {
compatible = "marvell,armada-370-pcie";
status = "disabled";
device_type = "pci";
@@ -104,6 +67,7 @@
#interrupt-cells = <1>;
ranges = <0x8200 0 0 0x8200 0x1 0 1 0
  0x8100 0 0 0x8100 0x1 0 1 0>;
+   bus-range = <0x00 0xff>;
interrupt-map-mask = <0 0 0 0>;
interrupt-map = <0 0 0 0 &gic GIC_SPI 29 
IRQ_TYPE_LEVEL_HIGH>;
marvell,pcie-port = <0>;
@@ -122,6 +86,7 @@
#interrupt-cells = <1>;
ranges = <0x8200 0 0 0x8200 0x2 0 1 0
  0x8100 0 0 0x8100 0x2 0 1 0>;
+   bus-range = <0x00 0xff>;
interrupt-map-mask = <0 0 0 0>;
interrupt-map = <0 0 0 0 &gic GIC_SPI 33 
IRQ_TYPE_LEVEL_HIGH>;
marvell,pcie-port = <1>;
@@ -140,6 +105,7 @@
#interrupt-cells = <1>;
ranges = <0x8200 0 0 0x8200 0x3 0 1 0
  0x8100 0 0 0x8100 0x3 0 1 0>;
+   bus-range = <0x00 0xff>;
interrupt-map-mask = <0 0 0 0>;
 

[U-Boot] [PATCH] ARM: mvebu: define CONFIG_BLK for db-88f6820-amc

[Chris Packham]

db-88f6820-amc uses CONFIG_DM_USB and CONFIG_USB_STORAGE already so
define CONFIG_BLK to prepare it for full conversion to DM.

Signed-off-by: Chris Packham 
---

 configs/db-88f6820-amc_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/configs/db-88f6820-amc_defconfig b/configs/db-88f6820-amc_defconfig
index dd58198a5469..9068a584060a 100644
--- a/configs/db-88f6820-amc_defconfig
+++ b/configs/db-88f6820-amc_defconfig
@@ -43,6 +43,9 @@ CONFIG_EFI_PARTITION=y
 CONFIG_DEFAULT_DEVICE_TREE="armada-385-amc"
 CONFIG_ENV_IS_IN_SPI_FLASH=y
 CONFIG_SPL_OF_TRANSLATE=y
+CONFIG_BLK=y
+# CONFIG_SPL_BLK is not set
+# CONFIG_BLOCK_CACHE is not set
 CONFIG_DM_I2C=y
 CONFIG_SYS_I2C_MVTWSI=y
 # CONFIG_MMC is not set
-- 
2.19.2

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

Re: [U-Boot] [PATCH 0/4] efi_loader: non-volatile variables support

[Takahiro Akashi]

# My patch is more or less a RFC to raise attention.

On Wed, Dec 05, 2018 at 11:53:42AM +0530, Sumit Garg wrote:
> Hi Akashi,
> 
> On Wed, 28 Nov 2018 at 11:28, AKASHI Takahiro
>  wrote:
> >
> > As the subject suggested, this patch set allows any efi variable to be
> > volatile or non-volatile as UEFI specification describes.
> >
> > With my efishell patch[1] with patch #2, you can try as follows:
> >   => efi setvar PlatformLang en
> >   => efi setvar -nv BootNext =H0200
> >   => env save
> >
> 
> How do you expect usage of "EFI_VARIABLE_NON_VOLATILE" attribute to
> work during boot-time services as we don't have "env save" command
> option as a boot-time service?
> 
> Take example scenario with EDK2 shell launched from u-boot and tries
> to set non-volatile efi variable.

I know the issue, but

> IMHO, support should be added to "efi_set_variable" to save variable
> with "EFI_VARIABLE_NON_VOLATILE" attribute to non volatile storage.

I also hesitate to implement such a behavior to efi_set_variable
as it ends up writing to flash every time. Please note that data on
storage is a sorted list in plain text and so updating it can be painful.

-Takahiro Akashi


> -Sumit
> 
> > BootNext will be preserved across reboot, while PlatformLang not.
> >
> > Please note that, currently, setvar command does not automatically
> > append NON_VOLATILE attribute, while UEFI specification expects that
> > PlatformLang be non-volatile, you'd better also specify -nv for
> > this variable here.
> >
> > Patch #2/#3 depend on my efishell patch[1].
> > Patch #4 depends on my BootNext patch[2].
> >
> > Patch[1] and [2] have not been merged yet, so patch#1 can be applied
> > on its own.
> >
> > [1] https://lists.denx.de/pipermail/u-boot/2018-November/346450.html
> > [2] https://lists.denx.de/pipermail/u-boot/2018-November/349281.html
> >
> > AKASHI Takahiro (4):
> >   efi_loader: support non-volatile variable behavior
> >   cmd: efishell: support -nv option to setvar sub-command
> >   cmd: efishell: make Boot/BootOrder variable non-volatile
> >   efi_loader: bootmgr: make BootNext non-volatile
> >
> >  cmd/efishell.c| 20 ---
> >  env/env.c |  4 +++
> >  include/efi_loader.h  |  1 +
> >  lib/efi_loader/efi_bootmgr.c  |  3 +-
> >  lib/efi_loader/efi_variable.c | 64 +--
> >  5 files changed, 84 insertions(+), 8 deletions(-)
> >
> > --
> > 2.19.1
> >
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2] rockchip: rk3288-evb: dts: remove 'vmmc' from emmc node

[Kever Yang]

Hi Philipp,

On 12/06/2018 09:50 PM, Philipp Tomsich wrote:
> +Tom
>
>> On 05.12.2018, at 03:25, Kever Yang  wrote:
>>
>> The U-Boot eMMC does not need to care about the power for Rockchip
>> SoC, because if the board is using eMMC, the power will default on
>> (for bootrom), and we do not do power management for it like kernel,
>> so the 'vmmc', 'vqmmc' is only useful for SD in U-Boot.
>>
>> This make U-Boot can boot into kernel even if the pmic driver is
>> broken.
> If the PMIC driver is broken, we should fix the PMIC driver.
> I would feel more comfortable w/o this statement.
>
>> The rk3288-evb dts may be used in many boards using rockchip reference
>> schematic but with little change, so we hope it can be more robust to
>> boot into next stage.
> Again, this is not how the DTS should be used.  I believe that Heiko, Fabio 
> and
> I had already highlighted this in comments to the earlier thread.

    Not sure if you have read my previous mail for answer all your comments,

I do agree DTS should represent the hardware, but please note that the DTS

is no kind of standard, and people always choose what they need and add

those part in there dts, but not always add all the property and
everyone use

the same model. I would say there are many boards does not have this
'vmmc-supply'

in there emmc node.

There are many dts properties only available in U-Boot, and many dts
properties

only available in kernel, and I'm very sure the properity 'vmmc-supply'
in rockchip evbs

is not need, the emmc can works very good with default pmic config. A
remove of

this property does not trying to describe something not belong to this
board, but only

ignore something that not important or even redundant.

Only eMMC driver is the one must work in a bootloader, and it should
boot into next

stage even all other drivers can not work.

Rockchip can not upstream all the board dts from different customers,
and I believe

there are much much more boards with different vendor's SoCs, we should
care a

little more about the robust of the bootloader.

Rockchip private U-Boot is trying to use one dts per SoC instead of one
dts per board,

and if the basic driver(timer, mmc) works, we can boot into kernel in
emmc, the pmic/clock is to

make it faster, and all other feature, like led, display, key, usb
gadget, are plus to the

basic function, and we always make basic function works.


Thanks,

- Kever

>
> I am willing to move ahead with these and simply merge them, if either Tom or
> Simon agree that they are fine with a DTS that describes one board and is then
> used for incompatible (if they were compatible, this change wasn’t needed)
> boards...
>
>> Signed-off-by: Kever Yang 
> Reviewed-by: Philipp Tomsich 
>
>> ---
>>
>> Changes in v2:
>> - only update for rk3288-evb, remove change for other boards.
>>
>> arch/arm/dts/rk3288-evb.dtsi | 2 --
>> 1 file changed, 2 deletions(-)
>>
>> diff --git a/arch/arm/dts/rk3288-evb.dtsi b/arch/arm/dts/rk3288-evb.dtsi
>> index ce75bd5d28..04902c0bd3 100644
>> --- a/arch/arm/dts/rk3288-evb.dtsi
>> +++ b/arch/arm/dts/rk3288-evb.dtsi
>> @@ -150,8 +150,6 @@
>>  num-slots = <1>;
>>  pinctrl-names = "default";
>>  pinctrl-0 = <&emmc_clk>, <&emmc_cmd>, <&emmc_pwr>, <&emmc_bus8>;
>> -vmmc-supply = <&vcc_io>;
>> -vqmmc-supply = <&vcc_flash>;
>>  status = "okay";
>> };
>>
>> -- 
>> 2.18.0
>>
>



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

[U-Boot] [PATCH V2] arm: mx5: Enable WDT and bootcounter on M53Menlo

[Marek Vasut]

Enable watchdog and bootcounter support on the M53Menlo board.

Signed-off-by: Marek Vasut 
Cc: Stefano Babic 
---
V2: Move CONFIG_{HW,IMX}_WATCHDOG to Kconfig
---
 configs/m53menlo_defconfig | 8 
 include/configs/m53menlo.h | 3 +++
 2 files changed, 11 insertions(+)

diff --git a/configs/m53menlo_defconfig b/configs/m53menlo_defconfig
index dd7aed324f..e05030 100644
--- a/configs/m53menlo_defconfig
+++ b/configs/m53menlo_defconfig
@@ -20,6 +20,7 @@ CONFIG_SYS_CONSOLE_IS_IN_ENV=y
 CONFIG_VERSION_VARIABLE=y
 CONFIG_SPL_BOARD_INIT=y
 CONFIG_SPL_NAND_SUPPORT=y
+CONFIG_SPL_WATCHDOG_SUPPORT=y
 CONFIG_HUSH_PARSER=y
 CONFIG_CMD_ASKENV=y
 CONFIG_CMD_GREPENV=y
@@ -33,6 +34,7 @@ CONFIG_CMD_DHCP=y
 CONFIG_CMD_MII=y
 CONFIG_CMD_PING=y
 CONFIG_CMD_BMP=y
+CONFIG_CMD_BOOTCOUNT=y
 CONFIG_CMD_DATE=y
 CONFIG_CMD_BTRFS=y
 CONFIG_CMD_EXT4=y
@@ -44,6 +46,11 @@ CONFIG_MTDIDS_DEFAULT="nand0=mxc_nand"
 
CONFIG_MTDPARTS_DEFAULT="mtdparts=mxc_nand:1m(u-boot),512k(env1),512k(env2),-(ubi)"
 CONFIG_CMD_UBI=y
 CONFIG_ENV_IS_IN_NAND=y
+CONFIG_BOOTCOUNT_LIMIT=y
+CONFIG_BOOTCOUNT_BOOTLIMIT=3
+CONFIG_SYS_BOOTCOUNT_SINGLEWORD=y
+CONFIG_SYS_BOOTCOUNT_ADDR=0x53FA401C
+CONFIG_SYS_BOOTCOUNT_MAGIC=0x0B01C041
 CONFIG_FSL_ESDHC=y
 CONFIG_NAND=y
 CONFIG_NAND_MXC=y
@@ -58,5 +65,6 @@ CONFIG_USB_ETHER_MCS7830=y
 CONFIG_USB_ETHER_SMSC95XX=y
 CONFIG_VIDEO=y
 # CONFIG_VIDEO_SW_CURSOR is not set
+CONFIG_IMX_WATCHDOG=y
 CONFIG_FAT_WRITE=y
 CONFIG_OF_LIBFDT=y
diff --git a/include/configs/m53menlo.h b/include/configs/m53menlo.h
index 3fca28da6b..0e03bb31a7 100644
--- a/include/configs/m53menlo.h
+++ b/include/configs/m53menlo.h
@@ -157,6 +157,9 @@
 /* IIM Fuses */
 #define CONFIG_FSL_IIM
 
+/* Watchdog */
+#define CONFIG_WATCHDOG_TIMEOUT_MSECS 8000
+
 /*
  * Boot Linux
  */
-- 
2.18.0

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

Re: [U-Boot] [U-Boot, PATCHv3, 2/4] dm: MIGRATION: Add migration plan for DM_USB

[Tom Rini]

On Fri, Dec 07, 2018 at 01:05:24PM +1300, Chris Packham wrote:
> On Thu, Dec 6, 2018 at 1:23 AM Tom Rini  wrote:
> >
> > On Wed, Dec 05, 2018 at 08:14:14AM +0100, Stefan Roese wrote:
> > > Hi Tom,
> > >
> > > On 04.12.18 05:49, Tom Rini wrote:
> > > >On Thu, Nov 29, 2018 at 06:21:12PM -0500, Tom Rini wrote:
> > > >
> > > >>As much of the USB system has been migrated to DM now, formalize a
> > > >>deadline for migration.
> > > >>
> > > >>Reviewed-by: Marek Vasut 
> > > >>Reviewed-by: Simon Glass 
> > > >>Signed-off-by: Tom Rini 
> > > >
> > > >Applied to u-boot/master, thanks!
> > >
> > > Just a quick note on this, since I just tested compiling current
> > > mainline on MVEBU "theadorable_debug". Here I get:
> > >
> > > = WARNING ==
> > > This board does not use CONFIG_DM_USB. Please update
> > > the board to use CONFIG_DM_USB before the v2019.07 release.
> > > Failure to update by the deadline may result in board removal.
> > > See doc/driver-model/MIGRATION.txt for more info.
> > > 
> > > = WARNING ==
> > > This board does not use CONFIG_DM_SCSI. Please update
> > > the storage controller to use CONFIG_DM_SCSI before the v2019.07 release.
> > > Failure to update by the deadline may result in board removal.
> > > See doc/driver-model/MIGRATION.txt for more info.
> > > 
> > >
> > > The DM_SCSI warning seems to be okay, because of the not converted
> > > ATA driver sata_mv.c (the controller is unfortunately not AHCI
> > > compatible). I hope to find some time shortly to work on this.
> > >
> > > But the board definitely uses DM_USB:
> > >
> > > $ gg DM_USB configs/theadorable_debug_defconfig
> > > configs/theadorable_debug_defconfig:CONFIG_DM_USB=y
> > >
> > > So the DM_USB warning seems to be wrong here.
> >
> > I think you're "stuck" here because you can't turn on CONFIG_BLK to
> > silence the CONFIG_DM_USB warning without then breaking sata_mv.c.  The
> > CONFIG_DM_USB migration isn't complete until you're also using
> > CONFIG_BLK.
> 
> On a related note. I'm looking at adding a new board and have
> CONFIG_DM_USB and CONFIG_USB_STORAGE enabled but I trip over the same
> warning. This board doesn't enable SATA so I'm not trapped like the
> theadorable boards but enabling CONFIG_BLK just to silence the warning
> seems a bit wrong. Am I missing something?

No, enabling CONFIG_BLK is what's needed.  We can't select/depend on it
in all cases that we would like yet but enabling it enables other
functionality.

-- 
Tom


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

Re: [U-Boot] [U-Boot, PATCHv3, 2/4] dm: MIGRATION: Add migration plan for DM_USB

[Chris Packham]

On Thu, Dec 6, 2018 at 1:23 AM Tom Rini  wrote:
>
> On Wed, Dec 05, 2018 at 08:14:14AM +0100, Stefan Roese wrote:
> > Hi Tom,
> >
> > On 04.12.18 05:49, Tom Rini wrote:
> > >On Thu, Nov 29, 2018 at 06:21:12PM -0500, Tom Rini wrote:
> > >
> > >>As much of the USB system has been migrated to DM now, formalize a
> > >>deadline for migration.
> > >>
> > >>Reviewed-by: Marek Vasut 
> > >>Reviewed-by: Simon Glass 
> > >>Signed-off-by: Tom Rini 
> > >
> > >Applied to u-boot/master, thanks!
> >
> > Just a quick note on this, since I just tested compiling current
> > mainline on MVEBU "theadorable_debug". Here I get:
> >
> > = WARNING ==
> > This board does not use CONFIG_DM_USB. Please update
> > the board to use CONFIG_DM_USB before the v2019.07 release.
> > Failure to update by the deadline may result in board removal.
> > See doc/driver-model/MIGRATION.txt for more info.
> > 
> > = WARNING ==
> > This board does not use CONFIG_DM_SCSI. Please update
> > the storage controller to use CONFIG_DM_SCSI before the v2019.07 release.
> > Failure to update by the deadline may result in board removal.
> > See doc/driver-model/MIGRATION.txt for more info.
> > 
> >
> > The DM_SCSI warning seems to be okay, because of the not converted
> > ATA driver sata_mv.c (the controller is unfortunately not AHCI
> > compatible). I hope to find some time shortly to work on this.
> >
> > But the board definitely uses DM_USB:
> >
> > $ gg DM_USB configs/theadorable_debug_defconfig
> > configs/theadorable_debug_defconfig:CONFIG_DM_USB=y
> >
> > So the DM_USB warning seems to be wrong here.
>
> I think you're "stuck" here because you can't turn on CONFIG_BLK to
> silence the CONFIG_DM_USB warning without then breaking sata_mv.c.  The
> CONFIG_DM_USB migration isn't complete until you're also using
> CONFIG_BLK.

On a related note. I'm looking at adding a new board and have
CONFIG_DM_USB and CONFIG_USB_STORAGE enabled but I trip over the same
warning. This board doesn't enable SATA so I'm not trapped like the
theadorable boards but enabling CONFIG_BLK just to silence the warning
seems a bit wrong. Am I missing something?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: rockchip: rv1108: Fix booting with initramfs

[Philipp Tomsich]

Otavio,

> On 07.12.2018, at 00:00, Otavio Salvador  
> wrote:
> 
> Hello Philipp,
> 
> On Thu, Dec 6, 2018 at 11:46 AM Philipp Tomsich
>  wrote:
>>> On 04.12.2018, at 14:49, Otavio Salvador  wrote:
>>> We move the ramdisk_addr_r to 0x6800 and disable the initrd and
>>> fdt relocation, so the initramfs works out of box.
>>> 
>>> Signed-off-by: Otavio Salvador 
>> 
>> Reviewed-by: Philipp Tomsich 
> 
> As you sent the PR for Rockchip tree, do you mind if Tom applies this
> one directly?

I am preparing another PR to go out prior to RC2.
There’s a number of bug-fixes that have collected over this week.

Unfortunately, this is not as quick and painless as it could as not everyone
runs their patches through Travis.

Thanks,
Phil.



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

Re: [U-Boot] [PATCH] ARM: rockchip: rv1108: Fix booting with initramfs

[Otavio Salvador]

Hello Philipp,

On Thu, Dec 6, 2018 at 11:46 AM Philipp Tomsich
 wrote:
> > On 04.12.2018, at 14:49, Otavio Salvador  wrote:
> > We move the ramdisk_addr_r to 0x6800 and disable the initrd and
> > fdt relocation, so the initramfs works out of box.
> >
> > Signed-off-by: Otavio Salvador 
>
> Reviewed-by: Philipp Tomsich 

As you sent the PR for Rockchip tree, do you mind if Tom applies this
one directly?

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 0/6] Add support for DM_USB and DM_USB_DEV to TI's K2G platforms

[Lukasz Majewski]

Hi Jean-Jacques, Marek,

> The K2G platforms can use the generic DWC3 driver instead of relying
> on the keystone-xhci driver.
> Benefits are:
> - moving toward DM
> - brings USB gadget for free
> - allows us to remove some code
> 
> Tested on:
> - K2G EVM
> 

I'm not sure if I shall wait for Marek's PR to Tom (preferred) or send
new PR to Marek?

Marek what do you think?

> 
> Changes in v2:
> - rebased on latest version of u-boot-usb/master
> - use DM_USB_GADGET instead of DM_USB_DEV
> 
> Jean-Jacques Hiblot (6):
>   usb: dwc3-generic: make it compatible with "ti,keystone-dwc3"
>   board: ks2_evm: Enable the USB clocks if DM_USB is used
>   ARM: dts: k2g-evm: enable USB0 and USB1
>   PHY: Add phy driver for the keystone USB PHY
>   usb: host: replace xhci-keystone driver by the generic dwc3 driver
>   configs: k2g_evm: Enable DFU on K2G EVM
> 
>  arch/arm/dts/keystone-k2g-evm.dts|  28 
>  arch/arm/dts/keystone-k2g.dtsi   |  56 
>  board/ti/ks2_evm/board.c |  12 ++
>  configs/k2e_evm_defconfig|   7 +
>  configs/k2e_hs_evm_defconfig |   7 +
>  configs/k2g_evm_defconfig|  12 ++
>  configs/k2g_hs_evm_defconfig |  12 ++
>  configs/k2hk_evm_defconfig   |   7 +
>  configs/k2hk_hs_evm_defconfig|   7 +
>  configs/k2l_evm_defconfig|   7 +
>  configs/k2l_hs_evm_defconfig |   7 +
>  drivers/phy/Kconfig  |  10 ++
>  drivers/phy/Makefile |   1 +
>  drivers/phy/keystone-usb-phy.c   | 109 
>  drivers/usb/dwc3/dwc3-generic.c  |   1 +
>  drivers/usb/host/Makefile|   1 -
>  drivers/usb/host/xhci-keystone.c | 240
> ---
> include/configs/ti_armv7_keystone2.h |  17 ++- 18 files changed, 294
> insertions(+), 247 deletions(-) create mode 100644
> drivers/phy/keystone-usb-phy.c delete mode 100644
> drivers/usb/host/xhci-keystone.c
> 




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de


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

Re: [U-Boot] [PATCH v3 00/19] DM_I2C_COMPAT removal for all ti platforms

[Adam Ford]

On Tue, Nov 27, 2018 at 11:04 PM Heiko Schocher  wrote:
>
> Hello Adam,
>
> Am 26.11.2018 um 20:18 schrieb Adam Ford:
> > On Sat, Oct 27, 2018 at 4:46 PM Adam Ford  wrote:
> >>
> >> On Mon, Oct 22, 2018 at 9:13 AM Jean-Jacques Hiblot  
> >> wrote:
> >>>
> >>> This series remove the usage of the DM_I2C_COMPAT option for all the ti
> >>> platforms. It also takes this opportunity to not disable DM_I2C in the 
> >>> SPL.
> >>>
> >>> There are a couples of issues to fix:
> >>> - CMD_EEPROM does not support the DM API. Fixed by removing this option
> >>>when DM_I2C is used without DM_I2C_COMPAT
> >>> - i2c_get_chip_for_busnum() does not work when OF_CONTROL is not used
> >>>(as is the case with am33xx SPL).
> >>> - The I2C driver do not support DM_I2C without OF_CONTROL.
> >>> - Most of the PMIC drivers do not support the I2C DM API.
> >>> - Board detection is done prior DM initialization. Fixed by moving it 
> >>> after
> >>>DM is initialized. That move breaks the DRA7 platforms (The fixes for
> >>>that are at the last 5 patches this series)
> >>>
> >>> When all this is taken care of DM_I2C_COMPAT can be removed and DM_I2C
> >>> enabled in the SPL.
> >>>
> >>> This has been tested with the following boards:
> >>> - am437x SK
> >>> - am335x SK
> >>> - am335x beaglebone (both DM and non-DM config)
> >>> - dra76 evm
> >>> - am572 evm
> >>> - k2g evm
> >>>
> >>> The following targets may be impacted by the changes related to
> >>> SPL_OF_CONTROL and SPL_OF_PLATDATA:
> >>> - am3517_evm_defconfig
> >>> - omap3_logic_defconfig
> >>> - chromebit_mickey_defconfig
> >>> - chromebook_jerry_defconfig
> >>> - chromebook_minnie_defconfig
> >>> - evb-rk3399_defconfig
> >>> - rock_defconfig
> >>>
> >>> It would be nice it some of you could try to boot them.
> >>>
> >>>
> >> I applied the entire 19-patch series and it worked for me.  Thanks!
> >>
> >> Tested-by Adam Ford  #omap3_logic & am3517_evm
> >>
> >
> > Out of curiosity, are there any pending reasons we cannot apply this?
> > I was hoping to see the warning reminding me that DM_I2C_COMPAT should
> > be removed, and this seems to address that.
>
> Yes, good question ... v3 looks good to me ... Hmm... I cannot find
> your patches in patchwork, may this is the reason, why I missed them!
>
> Aha, just saved your email to a file ... and see:
> [...]
> Subject: [U-Boot] [PATCH v3 01/19] cmd: Kconfig: Do not include EEPROM if 
>   DM_I2C is used
> without DM_I2C_COMPAT
> X-BeenThere: u-boot@lists.denx.de
> X-Mailman-Version: 2.1.18
> [...]
> Content-Type: text/plain; charset="utf-8"
> Content-Transfer-Encoding: base64
> Errors-To: u-boot-boun...@lists.denx.de
> Sender: "U-Boot" 
>
> VGhlIGltcGxlbWVudGF0aW9uIG9mIHRoZSBFRVBST00gY29tbWFuZHMgZG9lcyBub3Qgc3VwcG9y
> dCB0aGUgRE0gSTJDIEFQSS4KUHJldmVudCBjb21waWxhdGlvbiBicmVha2FnZSBieSBub3QgZW5h
> [...]
>
> May patchwork has problems with:
>
> Content-Transfer-Encoding: base64
>
> I also have to find out now, how te get to your patch ... Hmm,
> seems when I mark all the text in my EMail client and than copy&paste
> the text into a file, this works ... but doing this is errorprone
> and makes a lot of work ...
>
> May I ask you, if you can resend your series in plain text ?
>

Jean-Jacques -

Can you comment and/or resend?

I'd love to see these patches applied.

Thanks

adam
> Beside of this I am fine with this patchseries, many thanks for
> doing this work! You can add my
>
> Reviewed-by: Heiko Schocher 
>
> bye,
> Heiko
> >
> > thanks
> >
> > adam
> >>
> >> adam
> >>> Changes in v3:
> >>> - removed commit introducing dm_i2c_probe_device(). Instead probe the
> >>>presence of the chip on the I2C bus in i2c_get_chip_for_busnum().
> >>> - fdtdec_resetup() need not call fdtdec_setup() when only a single DTB is
> >>>used.
> >>> - Add documentation in README-fdt-control explaining why and how to use
> >>>fdtdec_resetup()
> >>>
> >>> Changes in v2:
> >>> - Add missing commit log to the commit disabling CMD_EEPROM when non-DM 
> >>> API
> >>>is not available
> >>> - don't use the DT to find the req_seq number if SPL_OF_PLATDATA is used.
> >>>Instead do it as if SPL_OF_CONTROL is not defined.
> >>> - Also add DM_I2C support to the twl6030 driver
> >>> - remove the remaining non-DM I2C API call for pdu001 board.
> >>> - Fixed warning in power_init_board() for the am43xx ti boards.
> >>>
> >>> Andreas Dannenberg (1):
> >>>ti: common: board_detect: Allow DM I2C without CONFIG_DM_I2C_COMPAT
> >>>
> >>> Jean-Jacques Hiblot (17):
> >>>cmd: Kconfig: Do not include EEPROM if DM_I2C is used without
> >>>  DM_I2C_COMPAT
> >>>dm: i2c: Make i2c_get_chip_for_busnum() fail if the chip is not
> >>>  detected
> >>>dm: device: Allow using uclass_find_device_by_seq() without OF_CONTROL
> >>>configs: am335x: am57x: dra7x: Enable CONFIG_SPL_DM_SEQ_ALIAS
> >>>i2c: omap24xx_i2c: Use platdata to probe the device
> >>>am335x: Register the I2C controllers if DM_I2C is used.
> >>>dts: am43x: 

[U-Boot] Unable to saveenv to MMC

[Robin Polak]

Hello.

  I'm having trouble persisting my environment variables to the SD Card
onto which I have FAT formatted and then written U-Boot to using the
following command:

sudo dd if=u-boot-sunxi-with-spl.bin of=/dev/disk2 bs=1024 seek=8

I get the following error when booting a Linksprite_pcDuino3_Nano with the
SD Card I've built:

U-Boot SPL 2018.11 (Dec 06 2018 - 17:57:48 +)
DRAM: 1024 MiB
CPU: 91200Hz, AXI/AHB/APB: 3/2/2
Trying to boot from MMC1


U-Boot 2018.11 (Dec 06 2018 - 17:57:48 +) Allwinner Technology

CPU:   Allwinner A20 (SUN7I)
Model: LinkSprite pcDuino3 Nano
I2C:   ready
DRAM:  1 GiB
MMC:   SUNXI SD/MMC: 0
Loading Environment from FAT... Unable to use mmc 0:0... In:serial
Out:   serial
Err:   serial
SCSI:  SATA link 0 timeout.
AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
flags: ncq stag pm led clo only pmp pio slum part ccc apst

Net:   eth0: ethernet@1c5
starting USB...
USB0:   USB EHCI 1.00
USB1:   USB OHCI 1.0
USB2:   USB EHCI 1.00
USB3:   USB OHCI 1.0
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 2 for devices... 1 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0
=> saveenv
Saving Environment to FAT... Unable to use mmc 0:0... Failed (1)

Thank you for any light that may be shed upon this error.

-- 
--
Robin Polak
ro...@robinpolak.com
917-494-2080
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 7/7] doc: ti-secure: Add ULO info for AM57xx/DRA7xx secure devices from TI

[Tom Rini]

On Wed, Dec 05, 2018 at 11:51:36AM -0600, Andrew F. Davis wrote:

> Booting from UART and USB on HS devices is now supported for this
> platform. Update documentation for the same.
> 
> Signed-off-by: Andrew F. Davis 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] Please pull u-boot-rockchip

[Tom Rini]

On Thu, Dec 06, 2018 at 04:09:42PM +0100, Philipp Tomsich wrote:

> Tom,
> 
> the following changes have gone through Travis prior to the rebase and tagging
> as https://travis-ci.org/ptomsich/u-boot-rockchip/builds/464122086
> 
> Thanks,
> Philipp.
> 
> 
> The following changes since commit 2a055ea53260ac8addeeb94eb671172844bc9106:
> 
>   Merge tag 'dm-pull-5dec18' of git://git.denx.de/u-boot-dm (2018-12-05 
> 20:32:25 -0500)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-rockchip.git for-master-20181206
> 
> for you to fetch changes up to 467877341a4169f1a8c50b7ebe4c0e6fd28da727:
> 
>   rockchip: rk3399: Add Ficus EE board support (2018-12-06 16:04:49 +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH v2 5/7] defconfigs: Add config for DRA7xx High Security EVM with USB Boot support

[Tom Rini]

On Wed, Dec 05, 2018 at 11:51:34AM -0600, Andrew F. Davis wrote:

> Add a new defconfig file for the DRA7xx High Security EVM. This config
> is specific for the case of USB booting.
> 
> Signed-off-by: Andrew F. Davis 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH v2] common: fdt_support: print hexadecimal numbers in debug

[Tom Rini]

On Thu, Dec 06, 2018 at 03:20:47PM +0530, Sekhar Nori wrote:

> We usually deal with hexadecimal addresses and sizes in
> device-tree. Its much easier if debug logs print hexadecimal
> values too.
> 
> Reviewed-by: Simon Glass 
> Signed-off-by: Sekhar Nori 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH v2 6/7] defconfigs: Add config for AM57xx High Security EVM with USB/UART Boot support

[Tom Rini]

On Wed, Dec 05, 2018 at 11:51:35AM -0600, Andrew F. Davis wrote:

> Add a new defconfig file for the AM57xx High Security EVM. This config
> is specific for the case of USB/UART booting.
> 
> Signed-off-by: Andrew F. Davis 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH] spl: fix build failure with !CONFIG_SPL_PCI_SUPPORT

[Tom Rini]

On Thu, Dec 06, 2018 at 03:40:08PM +0530, Sekhar Nori wrote:

> Building U-Boot with CONFIG_PCI and CONFIG_DM_PCI enabled, but
> CONFIG_SPL_PCI_SUPPORT disabled, results in following linker
> error:
> 
> lib/built-in.o: In function `fdtdec_get_pci_bar32':
> lib/fdtdec.c:305: undefined reference to `dm_pci_read_bar32'
> fdtdec.c:305:(.text.fdtdec_get_pci_bar32+0x24): relocation truncated to fit: 
> R_AARCH64_CALL26 against undefined symbol `dm_pci_read_bar32'
> 
> This is because reference to dm_pci_read_bar32() remains in lib/fdtdec.c
> while SPL build does not descend into drivers/pci directory in
> drivers/Makefile if CONFIG_SPL_PCI_SUPPORT is not enabled.
> 
> Fix this by applying appropriate #define guards in lib/fdtdec.c.
> It looks like ns16550.c has the same problem, so fixed that too.
> 
> To simplify this, CONFIG_SPL_PCI_SUPPORT is renamed to CONFIG_SPL_PCI
> (enables use of CONFIG_IS_ENABLED() macro).
> 
> Suggested-by: Vignesh R 
> Signed-off-by: Sekhar Nori 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH v2 4/7] ARM: mach-omap2: Kconfig: Allow OMAP5 devices to set entry point

[Tom Rini]

On Wed, Dec 05, 2018 at 11:51:33AM -0600, Andrew F. Davis wrote:

> Like AM33xx and AM43xx, DRA7xx and AM57xx devices may need to
> have an non-standard boot address in memory. This may be due
> to the device being a high security variant, which place the
> Initial SoftWare (ISW) after certificates and secure software.
> 
> Allow these devices to set this from Kconfig.
> 
> Signed-off-by: Andrew F. Davis 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH v2 2/7] dfu: Make DFU support more SPL friendly

[Tom Rini]

On Wed, Dec 05, 2018 at 11:51:31AM -0600, Andrew F. Davis wrote:

> Do this by using $(SPL_) in Makefiles and CONFIG_IS_ENABLED in C code.
> This ensures the files and features are only built into the right build
> for which they are enabled. Using the macros to simplify this patch was
> made possible by the config symbol rename done in the last patch.
> 
> Signed-off-by: Andrew F. Davis 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH v2 3/7] dfu: Remove dependency on HUSH parser in SPL

[Tom Rini]

On Wed, Dec 05, 2018 at 11:51:32AM -0600, Andrew F. Davis wrote:

> CLI support with the HUSH parser is not currently SPL safe due to it's
> use of realloc. That function is not defined for SPLs that use
> SYS_MALLOC_SIMPLE. CLI support can be built in to SPL and some functions
> do work, but use of some like run_command() will cause build to fail.
> When no SPL code calls this function build works as the compiler removes
> this unreachable code so the unresolved symbols are ignored.
> 
> If DFU support is enabled in SPL then MMU DFU support may get brought in
> also, this code does make a call to run_command() causing build to fail
> if the HUSH parser is not built-in. To break this odd and unneeded
> dependency chain we use CONFIG_IS_ENABLED where appropriate to prevent
> calls into HUSH code from SPL. This also removes our need to pull in the
> rather unrelated source file when SPL_DFU is defined.
> 
> Signed-off-by: Andrew F. Davis 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH v2 1/7] spl: Kconfig: Drop the _SUPPORT postfix from SPL_DFU

[Tom Rini]

On Wed, Dec 05, 2018 at 11:51:30AM -0600, Andrew F. Davis wrote:

> The symbol CONFIG_SPL_DFU_SUPPORT in SPL build has the same
> meaning as CONFIG_DFU in regular U-Boot. Drop the _SUPPORT
> to allow for cleaner use in code.
> 
> Signed-off-by: Andrew F. Davis 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH] defconfigs: am335x_hs_evm: Sync HS and non-HS defconfigs

[Tom Rini]

On Wed, Dec 05, 2018 at 12:33:33PM -0600, Andrew F. Davis wrote:

> Sync new additions to non-HS defconfig with HS defconfig.
> 
> Signed-off-by: Andrew F. Davis 

Reviewed-by: Tom Rini 

-- 
Tom


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

[U-Boot] [PATCH] travis: Add check for configs without MAINTAINERS entries

[Tom Rini]

The genboardscfg.py script will emit a WARNING message if we have new
defconfig files that are not listed in a MAINTAINERS file.  Make new
cases of this a failure we catch in Travis-CI.

Signed-off-by: Tom Rini 
---
 .travis.yml | 4 
 1 file changed, 4 insertions(+)

diff --git a/.travis.yml b/.travis.yml
index a061f02399c0..4c4336746e69 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -332,6 +332,10 @@ matrix:
 - name: "sloccount"
   script:
 - sloccount .
+# ensure all configs have MAINTAINERS entries
+- name: "Check for configs without MAINTAINERS entry"
+  script:
+- if [ `./tools/genboardscfg.py -f 2>&1 | wc -l` -ne 0 ]; then exit 1; 
fi
 
 # test/py
 - name: "test/py sandbox"
-- 
2.7.4

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

Re: [U-Boot] [PATCH v4 00/10] Improvements for the dwc3_generic driver

[Loic Devulder]

Hi,

I re-tested this series on Khadas VIM1 and it still fix the USB issue I
had with 'usb reset' (I already tested v2 patches).

I just have a message and I'm not sure that I had it last time:
"Error disabling PHY supply
Can't shutdown USB PHY1 for dwc3@c900"

But USB stack looks ok, I can plug/unplug USB key  and do the reset, all
works as expected.

Since my last test lot of changes has been done in Amlogic SoCs, maybe
it's because of this?

So if you want you can add my tested-by flag.
Tested-by: Loic Devulder 

On 11/29/18 10:52 AM, Jean-Jacques Hiblot wrote:
> 
> This series aims at bringing improvements to the dwc3_generic driver so
> that it can be used by most of the platforms using the dwc3 controller.
> 
> I tested this on with DRA7 and AM57x platforms for both Peripheral and Host
> operations. The code to enable DM USB host & dev support for those
> platforms will be submitted in a separate series.
> 
> Michal Simek has tested this series:
> " I have tested it on zcu100 with usb stick, usb to ethernet converter and
> also dfu.
> Tested-by: Michal Simek "
> 
> Enhancements:
> - use separate Kconfig option for DM USB Periphal and DM USB Host. This
> allow platforms to keep their non-DM USB peripheral code and use the DM
> USB host.
> - fixes the bind/probe confusion in dwc3_generic. The probe is done when
> the USB device is first needed.
> - handles PHYs when in the peripheral mode. The code to handle the PHYs is
> shared with the host side
> - handles clock and reset
> - bind host controller to the more generic driver 'xhci-dwc3'
> 
> 
> Changes in v4:
> - rebased on latest U-Boot
> - renamed DM_USB_DEV as DM_USB_GADGET
> - Add a new commit to create a new UCLASS for USB gadget drivers
> 
> Changes in v3:
> - fixes bug dwc3_setup_phy(): the phy arrays wasn't returned. This was
>   visible only when the device is removed.
> - Stub the DWC3 PHY operations if CONFIG_IS_ENABLED(PHY) is false.
>   This fixes all build issues but one (evb-rk3328).
> - Fix build issue with evb-rk3328 by enabling CONFIG_USB_DWC3. This has
>   little impact on the footprint and should not break the runtime as the
>   xhci-rockchip driver has its own probe function.
>   Nevertheless this was !!! NOT TESTED !!! by lack of hw
> 
> Changes in v2:
> - Updated commit log
> - Fixed typo in thordown.c
> - select DM_USB_DEV by default for zynqmp platforms
> 
> Jean-Jacques Hiblot (10):
>   usb: gadget: Do not call board_usb_xxx() directly in USB gadget
> drivers
>   usb: introduce a separate config option for DM USB device
>   usb: udc: implement DM versions of
> usb_gadget_initialize()/_release()/_handle_interrupt()
>   dwc3_generic: do not probe the USB device driver when it's bound
>   dwc3: move phy operation to core.c
>   dm: usb: create a new UCLASS ID for USB gadget devices
>   configs: evb-rk3328: Enable CONFIG_USB_DWC3
>   dwc3-generic: Handle the PHYs, the clocks and the reset lines
>   dwc3-generic: Add select_dr_mode operation
>   usb: dwc3: Fix a compilation error with the edison defconfig
> 
>  arch/arm/Kconfig|   2 +
>  board/sunxi/board.c |   2 +-
>  cmd/fastboot.c  |   4 +-
>  cmd/rockusb.c   |   4 +-
>  cmd/thordown.c  |   4 +-
>  cmd/usb_gadget_sdp.c|   4 +-
>  cmd/usb_mass_storage.c  |   4 +-
>  common/dfu.c|   6 +-
>  configs/evb-rk3328_defconfig|   1 +
>  drivers/usb/Kconfig |  14 +++
>  drivers/usb/dwc3/Kconfig|   7 +-
>  drivers/usb/dwc3/core.c |  89 ++-
>  drivers/usb/dwc3/dwc3-generic.c | 208 
> 
>  drivers/usb/dwc3/ep0.c  |   2 +-
>  drivers/usb/gadget/ether.c  |  40 ++-
>  drivers/usb/gadget/udc/Makefile |   4 +
>  drivers/usb/gadget/udc/udc-core.c   |   3 +-
>  drivers/usb/gadget/udc/udc-uclass.c |  58 ++
>  drivers/usb/host/xhci-dwc3.c|  95 ++--
>  drivers/usb/musb-new/omap2430.c |   2 +-
>  drivers/usb/musb-new/sunxi.c|   2 +-
>  include/dm/uclass-id.h  |   1 +
>  include/dwc3-uboot.h|  19 
>  include/linux/usb/gadget.h  |  18 
>  24 files changed, 401 insertions(+), 192 deletions(-)
>  create mode 100644 drivers/usb/gadget/udc/udc-uclass.c
> 

-- 
Loic Devulder  | ldevulder@irc
0x175A963893C85F55 | D220 DEF5 56A3 DE00 9DAA 78BA 175A 9638 93C8 5F55
Senior QA Engineer | Container & Storage Solutions Quality Assurance
team (qa-css)
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB,
21284 (AG Nuernberg)



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

Re: [U-Boot] [PATCH] arm: mx5: Enable WDT and bootcounter on M53Menlo

[Tom Rini]

On Mon, Dec 03, 2018 at 11:12:54PM +0100, Marek Vasut wrote:
> Enable watchdog and bootcounter support on the M53Menlo board.
> 
> Signed-off-by: Marek Vasut 
> Cc: Stefano Babic 
> ---
>  configs/m53menlo_defconfig | 7 +++
>  include/configs/m53menlo.h | 5 +
>  2 files changed, 12 insertions(+)
> 
> diff --git a/configs/m53menlo_defconfig b/configs/m53menlo_defconfig
> index 795f8a3ebc..8e26431969 100644
> --- a/configs/m53menlo_defconfig
> +++ b/configs/m53menlo_defconfig
> @@ -20,6 +20,7 @@ CONFIG_SYS_CONSOLE_IS_IN_ENV=y
>  CONFIG_VERSION_VARIABLE=y
>  CONFIG_SPL_BOARD_INIT=y
>  CONFIG_SPL_NAND_SUPPORT=y
> +CONFIG_SPL_WATCHDOG_SUPPORT=y
>  CONFIG_HUSH_PARSER=y
>  CONFIG_CMD_ASKENV=y
>  CONFIG_CMD_GREPENV=y
> @@ -33,6 +34,7 @@ CONFIG_CMD_DHCP=y
>  CONFIG_CMD_MII=y
>  CONFIG_CMD_PING=y
>  CONFIG_CMD_BMP=y
> +CONFIG_CMD_BOOTCOUNT=y
>  CONFIG_CMD_DATE=y
>  CONFIG_CMD_BTRFS=y
>  CONFIG_CMD_EXT4=y
> @@ -44,6 +46,11 @@ CONFIG_MTDIDS_DEFAULT="nand0=mxc_nand"
>  
> CONFIG_MTDPARTS_DEFAULT="mtdparts=mxc_nand:1m(u-boot),512k(env1),512k(env2),-(ubi)"
>  CONFIG_CMD_UBI=y
>  CONFIG_ENV_IS_IN_NAND=y
> +CONFIG_BOOTCOUNT_LIMIT=y
> +CONFIG_BOOTCOUNT_BOOTLIMIT=3
> +CONFIG_SYS_BOOTCOUNT_SINGLEWORD=y
> +CONFIG_SYS_BOOTCOUNT_ADDR=0x53FA401C
> +CONFIG_SYS_BOOTCOUNT_MAGIC=0x0B01C041
>  CONFIG_FSL_ESDHC=y
>  CONFIG_NAND=y
>  CONFIG_NAND_MXC=y
> diff --git a/include/configs/m53menlo.h b/include/configs/m53menlo.h
> index 94214b135d..bef0c9b31d 100644
> --- a/include/configs/m53menlo.h
> +++ b/include/configs/m53menlo.h
> @@ -158,6 +158,11 @@
>  /* IIM Fuses */
>  #define CONFIG_FSL_IIM
>  
> +/* Watchdog */
> +#define CONFIG_HW_WATCHDOG
> +#define CONFIG_IMX_WATCHDOG

At least these two symbols are in Kconfig today, please use them (and
maybe some guard symbol is missing), thanks.

> +#define CONFIG_WATCHDOG_TIMEOUT_MSECS 8000

This one isn't migrated yet, so I can't complain, only beg for a
migration :)

-- 
Tom


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

Re: [U-Boot] [RFC PATCH v2 00/11] SF: Migrate to Linux SPI NOR framework

[Simon Goldschmidt]

Am 06.12.2018 um 19:25 schrieb Vignesh R:

Hi Jagan,

On 06-Dec-18 10:44 PM, Jagan Teki wrote:

On Tue, Dec 4, 2018 at 5:56 PM Vignesh R  wrote:


U-Boot SPI NOR support (sf layer) is quite outdated as it does not
support 4 byte addressing opcodes, SFDP table parsing and different types of
quad mode enable sequences. Many newer flashes no longer support BANK
registers used by sf layer to a access >16MB space.
Also, many SPI controllers have special MMIO interfaces which provide
accelerated read/write access but require knowledge of flash parameters
to make use of it. Recent spi-mem layer provides a way to support such
flashes but sf layer isn't using that.
This patch series syncs SPI NOR framework from Linux v4.19. It also adds
spi-mem support on top.
So, we gain 4byte addressing support and SFDP support. This makes
migrating to U-Boot MTD framework easier.


We(someone) has proposed this sync before, but we(at-least I) rely on
implementing via DM not direct sync to Linux.


As I said in my cover letter, U-Boot sf layer is unable to support newer
flashes mainly due to lack of 4 byte addressing and proper support for
MMIO capable SPI controllers.
My idea of fixing this is to borrow _features_ from Linux SPI NOR "as
is". All that's needed is stateless 4 byte addressing, SFDP
parsing(optionally), Quad/Octal support and spi-mem like abstraction for
MMIO capable Controllers. I see no point in re-coding them from ground up.


And this is exactly why I'm testing this series: it's the only series 
I've seen in the last months that seems to properly handle 4-byte 
addressing (even if it does not fully do that for me, yet, but it's 
still RFC).


I have a bug in my hardware that requires me to put the chip back to 
3-byte mode manually up to now. I've sent a patch for that and this 
patch has been rejected.


So now I'm testing this series to see if it allows me to run U-Boot 
mainline on my board without additional patches required.


Simon



Could you be more specific on what you would like to see here in DM way?
I have no issues in adapting this code to any framework here in U-Boot.
Linux has driver model and SPI NOR subsystem is a framework and
therefore any code ported from Linux will inherently have those
abstractions. The only difference I see wrt your code in branch below vs
this series is SPI-NOR uclass. This can be easily achieved by moving
nor->ops out of struct spi_nor into uclass abstraction.
Upstream Linux is anyways merging m25p80 and spi-nor so I did not see a
need for SPI NOR uclass. I am okay to change that if you insist on
having it.



ofcourse other
subsystems might have doing this but I literally don't propose to do
that, since it may fire the u-boot implementation in future.



Could you explain what might be possible issues in future? I will work
on it.


If you really get things up further, try to check this DM based
spi-nor here[1] and lets discuss on u-boot point-of-view. I've paused
this because of non-dm code, but I'm thinking we even re-change this
to fit MTD driver-model (this is my TODO, once spi dm migration done).


AFAICS, Non DM code is not going away anytime soon. Meanwhile, IMHO,
lack of 4 byte addressing support is significantly hampering new
development (as evident from number of people trying to add 4 byte
addressing support.)


[1] http://git.denx.de/?p=u-boot-spi.git;a=shortlog;h=refs/heads/next-working



IIRC, last post of this branch was in January 2018. And looking at my
inbox, its seems that 4 byte addressing was broken in that series.
If you add 4 byte addressing + SFDP parsing logic + spi-mem support to
above branch, I am pretty sure you spi-nor.c would look almost the same
to whats there in this series.

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



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

Re: [U-Boot] [RFC PATCH v2 00/11] SF: Migrate to Linux SPI NOR framework

[Simon Goldschmidt]

Am 06.12.2018 um 18:39 schrieb Vignesh R:



On 06/12/18 10:06 PM, Simon Goldschmidt wrote:

Am 06.12.2018 um 14:54 schrieb Simon Goldschmidt:

On Thu, Dec 6, 2018 at 2:45 PM Vignesh R  wrote:


Hi Simon,

On 06/12/18 2:15 AM, Simon Goldschmidt wrote:

Am 05.12.2018 um 07:55 schrieb Simon Goldschmidt:

On Wed, Dec 5, 2018 at 7:51 AM Vignesh R  wrote:

[...]

I did some compilation tests first and I'm happy to say that with the
SPL_SPI_FLASH_TINY option enabled, my SPL is about 1900 byte smaller
than before :-)

However, my socfpga socrates board does not boot. I'll have to
investigate why. I just applied this series and compiled for
socfpga_socrates_defconfig. Is there anything else I should have changed
to make it work?



Oops, that's unfortunate.
Just to be sure, does SPL fail to come up or SPL fails to load U-Boot
from flash? Is this with SPL_SPI_FLASH_TINY enabled?


I tried both TINY and standard. Both are failing to load U-Boot (I get
the standard error message that loading from SPI flash failed).


Could you enable debug prints at the end of spi_mem_exec_op() in
drivers/spi/spi-mem.c to see what commands are sent and their responses?


OK, I'll do that.


I have TI EVM with Cadence QSPI(like SoCFPGA) but with a Spansion flash
and that seems to work fine with both full and tiny stack.


OK, so I enabled some debugging and the first issue is that U-Boot has
SNOR_MFR_MICRON and SNOR_MFR_ST while Linux only has SNOR_MFR_MICRON but
defines it to CFI_MFR_ST (0x20, U-Boot ends up with 0x2c). While this
might be correct, it leads to my n25q256a not being handled as
"micron-like" and the code falls through to using Spansion-like opcode
(0x17) that my chip does not understand.



Oops, sorry, the micron chip I had has CFI MFR id of 0x2c, so I
overlooked this. I have updated this now.


However, after changing this (and using opcode 0xb7 to bring the chip
into 4 byte mode, including 0x06 for write-enable), it still does not
work as it uses the 'READ' opcode 0x03 instead of the 'FAST READ' opcode
0x0b that U-Boot used until now. The problem here might be that 'READ'
cannot do Quad-SPI (4-4-4) and I'm not sure the Cadence driver can
handle Extended-SPI (1-1-1) that the 'READ' command is limited to...



I had accidentally dropped Fast Read from SPI NOR layer and have sync'd
it up now.  I see that in socfpga dts, flash does not contain:
spi-rx-bus-width = <4>;


We can add that if it helps. I'll try to update the upstream Linux dts
anyway to add "jeded,spi-nor" compatible once Neil's series is
applied.


Therefore SPI NOR layer falls back to READ (even though its a QSPI
flash). But nevertheless with updated branch[1] you should see falling
back to FAST READ with Cadence QSPI on your board (and 1-1-4, if rx bus
width is 4).


Using SFDP would probably help, but that doesn't compile (as I wrote in
the other thread).



Sorry for that. I have fixed that up and tested SFDP parsing logic with
a Spansion flash. Note that Cadence QSPI wont support SFDP parsing as
driver enables Quad mode for all reads and SFDP is only 1-1-1.


Oh, I haven't really looked into that yet. That's sad.



Yes, thats one of the motivation for this series. I wanted to use same driver
to support Cadence Octal SPI IP but this simply wasn't possible due disconnect 
b/w SF and SPI layer.
I plan to fix Cadence QSPI by moving to spi-mem layer once SF layer is in place




On the other hand, enabling SFDP will increase the text/rodata size for
SPL. We might need to remove the non-SFDP and write code as a counter
measure to prevent increasing code size.



That's not an option as Flash devices (even though have same JEDEC ID)
manufactured before JESD216 std dont have SFDP populated. So, we will
need to have both non-SFDP and SFDP support with option to disable SFDP
(for size and boot time optimizations).


Well, my idea was if you'd know that all the flash chips on your board
supported it, you'd be safe. It would only be a Kconfig option to
reduce binary size (get rid of the flash IDs table).

But if SFDP doesn't work for QSPI anyway, that's not the best idea, I guess...




Yeah, current U-Boot SPI layer does not allow SPI Flash layer to communicate
bus width to SPI controller drivers. Either drivers capable of supporting
Quad mode should move to spi-mem framework or spi_xfer() interface needs to be 
expanded.


Thanks for all the debugging! It would be great if you could try below
branch and let me know if it fixes all the issues.
If yes, I will remove RFC and post new series.


Sure, I'll try to find the time soon.


Had a quick test with both standard and tiny in SPL and both configs now
work on my board. I haven't tested SFDP as you said it does not works on
Cadence QSPI. (I tested compiling it though, and that works now.)



After enabling DEBUG in spi-mem.c, I see that we're changing to 4-byte 
mode (via b7h) instead of using 4-byte opcodes. Unfortunately, this 
conflicts with the boot rom using the default read opcose in 3-byte mode 
on warm

Re: [U-Boot] [RESENT PATCH 1/2] rockchip: rk3128: use ROCKCHIP_BOOT_MODE_REG to update reboot flag

[Simon Glass]

Hi Philipp,

On Thu, 6 Dec 2018 at 11:23, Philipp Tomsich
 wrote:
>
>
>
> > On 06.12.2018, at 19:18, Simon Glass  wrote:
> >
> > Hi Philipp,
> >
> > On Thu, 6 Dec 2018 at 04:02, Philipp Tomsich
> >  wrote:
> >>
> >> Simon,
> >>
> >>> On 06.12.2018, at 02:31, Simon Glass  wrote:
> >>>
> >>> Hi Philipp,
> >>>
> >>> On Thu, 29 Nov 2018 at 13:57, Philipp Tomsich
> >>>  wrote:
> 
>  Simon,
> 
>  On 29.11.2018, at 19:43, Simon Glass  wrote:
> 
>  Hi Kever,
> 
>  On Wed, 28 Nov 2018 at 18:10, Kever Yang  
>  wrote:
> 
> 
>  Hi Philipp,
> 
> 
>  On 11/28/2018 05:07 PM, Philipp Tomsich wrote:
> 
>  Kever,
> 
>  On 28.11.2018, at 03:04, Kever Yang  wrote:
> 
>  Use ROCKCHIP_BOOT_MODE_REG instead of grf structure so that
>  we can re-use the source code later.
> 
>  Signed-off-by: Kever Yang 
> 
>  NAK, as there are still pending changes.
> 
>  Yes, I got that, and I send out my comments on your comments with no
>  more response.
> 
>  See below for the reminder, in case this got lost.
> 
>  ---
> 
>  arch/arm/mach-rockchip/Kconfig| 1 +
>  arch/arm/mach-rockchip/rk3128-board.c | 5 +
>  2 files changed, 2 insertions(+), 4 deletions(-)
> 
>  diff --git a/arch/arm/mach-rockchip/Kconfig 
>  b/arch/arm/mach-rockchip/Kconfig
>  index 145d96b1f0..94a03e2a38 100644
>  --- a/arch/arm/mach-rockchip/Kconfig
>  +++ b/arch/arm/mach-rockchip/Kconfig
>  @@ -179,6 +179,7 @@ config TPL_ROCKCHIP_BACK_TO_BROM
>  config ROCKCHIP_BOOT_MODE_REG
>    hex "Rockchip boot mode flag register address"
>    default 0x200081c8 if ROCKCHIP_RK3036
>  +default 0x100a0038 if ROCKCHIP_RK3128
>    default 0x20004040 if ROCKCHIP_RK3188
>    default 0x110005c8 if ROCKCHIP_RK322X
>    default 0xff730094 if ROCKCHIP_RK3288
> 
>  As previously discussed: these should all go into header files, as they 
>  are not user-configurable.
>  This affects multiple patch series (as I requested the same for the 
>  STIMER address).
> 
>  I believe you mention about this: 
>  http://patchwork.ozlabs.org/patch/891462/
>  Now the model in u-boot rockchip channel is:
>  - People send out patches to mailing list;
>  - The patch get an ACK patch and review patch may request for change in
>  1 week~4 months;
>  - According to the maintainer's comment, people reply for why the patch
>  like this,
>  and maybe the patch do not need to change just like what the
>  maintainer want.
>  - BUT, there will never be more reply/comments.
>  - Then, people have to resend the patches they think it may be
>  reasonable, and maintainer
>  then complain people doesn't address his comment.
> 
>  For this patch, I think:
>  - This is not an first patch for this operation, this just make rk3128
>  work like other SoCs, it's not a new feature;
>  - This kind of default value setting is all over the U-Boot project, I'm
>  not say it's correct,
>  but it's a good solution and convenient for us to use the same object
>  with different value in different SoCs,
>  It's much better to separate them into more then 10 header files or
>  lots of "#ifdef CONFIG_ROCKCHIIP_RK3128"
>  in one header files.
> 
>  I hope I can get reply for this mail this time.
> 
>  Hi Simon,
>   Could you help to comment on this?
> 
> 
>  What happens if the user changes the value?
> 
>  Can this go in the device tree?
> 
>  It seems like this should be in a driver, to me. We have a SYSCON
>  driver for GRF. Should we add an ioctl-type interface to it?
> 
> 
>  This affects a number of settings by now, including the addresses for the
>  debug UARTs, secure timer base addresses and the boot-mode register.
> 
>  What we’d really need would be a “read/write named-register” operation
>  (which could either be an ioctl or a new read/write operation that takes 
>  a
>  selector that can then internally be mapped onto an actual address).
>  However, this would require a custom syscon for each chip (or at least a
>  per-chip driver-data), which also doesn’t sound like a desirable design.
> >>>
> >>> I assume it would come from the device tree.
> >>>
> >>> To me this seems like a reasonable design. Yes it would need per-chip
> >>> DT settings, or perhaps driver data.
> >>>
> >>> But I believe we alreayd have a syscon_.c for each chip.
> >>
> >> Yes, there are syscon_*.c files per chip, but these only contain the 
> >> compatible
> >> tables and reuse the generic syscon implementation.
> >>
> >> I’ll take a stab at creating a RFC series to extend the generic syscon 
> >> with an
> >> ‘read/write named register’ mechanism.
> >
> > OK, but I think it might be better to use something like ioctl(), if

Re: [U-Boot] [RFC PATCH v2 00/11] SF: Migrate to Linux SPI NOR framework

[Vignesh R]

Hi Jagan,

On 06-Dec-18 10:44 PM, Jagan Teki wrote:
> On Tue, Dec 4, 2018 at 5:56 PM Vignesh R  wrote:
>>
>> U-Boot SPI NOR support (sf layer) is quite outdated as it does not
>> support 4 byte addressing opcodes, SFDP table parsing and different types of
>> quad mode enable sequences. Many newer flashes no longer support BANK
>> registers used by sf layer to a access >16MB space.
>> Also, many SPI controllers have special MMIO interfaces which provide
>> accelerated read/write access but require knowledge of flash parameters
>> to make use of it. Recent spi-mem layer provides a way to support such
>> flashes but sf layer isn't using that.
>> This patch series syncs SPI NOR framework from Linux v4.19. It also adds
>> spi-mem support on top.
>> So, we gain 4byte addressing support and SFDP support. This makes
>> migrating to U-Boot MTD framework easier.
> 
> We(someone) has proposed this sync before, but we(at-least I) rely on
> implementing via DM not direct sync to Linux. 

As I said in my cover letter, U-Boot sf layer is unable to support newer
flashes mainly due to lack of 4 byte addressing and proper support for
MMIO capable SPI controllers.
My idea of fixing this is to borrow _features_ from Linux SPI NOR "as
is". All that's needed is stateless 4 byte addressing, SFDP
parsing(optionally), Quad/Octal support and spi-mem like abstraction for
MMIO capable Controllers. I see no point in re-coding them from ground up.

Could you be more specific on what you would like to see here in DM way?
I have no issues in adapting this code to any framework here in U-Boot.
Linux has driver model and SPI NOR subsystem is a framework and
therefore any code ported from Linux will inherently have those
abstractions. The only difference I see wrt your code in branch below vs
this series is SPI-NOR uclass. This can be easily achieved by moving
nor->ops out of struct spi_nor into uclass abstraction.
Upstream Linux is anyways merging m25p80 and spi-nor so I did not see a
need for SPI NOR uclass. I am okay to change that if you insist on
having it.


> ofcourse other
> subsystems might have doing this but I literally don't propose to do
> that, since it may fire the u-boot implementation in future.
> 

Could you explain what might be possible issues in future? I will work
on it.

> If you really get things up further, try to check this DM based
> spi-nor here[1] and lets discuss on u-boot point-of-view. I've paused
> this because of non-dm code, but I'm thinking we even re-change this
> to fit MTD driver-model (this is my TODO, once spi dm migration done).
> 
AFAICS, Non DM code is not going away anytime soon. Meanwhile, IMHO,
lack of 4 byte addressing support is significantly hampering new
development (as evident from number of people trying to add 4 byte
addressing support.)

> [1] http://git.denx.de/?p=u-boot-spi.git;a=shortlog;h=refs/heads/next-working
> 

IIRC, last post of this branch was in January 2018. And looking at my
inbox, its seems that 4 byte addressing was broken in that series.
If you add 4 byte addressing + SFDP parsing logic + spi-mem support to
above branch, I am pretty sure you spi-nor.c would look almost the same
to whats there in this series.

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

Re: [U-Boot] [RESENT PATCH 1/2] rockchip: rk3128: use ROCKCHIP_BOOT_MODE_REG to update reboot flag

[Philipp Tomsich]

> On 06.12.2018, at 19:18, Simon Glass  wrote:
> 
> Hi Philipp,
> 
> On Thu, 6 Dec 2018 at 04:02, Philipp Tomsich
>  wrote:
>> 
>> Simon,
>> 
>>> On 06.12.2018, at 02:31, Simon Glass  wrote:
>>> 
>>> Hi Philipp,
>>> 
>>> On Thu, 29 Nov 2018 at 13:57, Philipp Tomsich
>>>  wrote:
 
 Simon,
 
 On 29.11.2018, at 19:43, Simon Glass  wrote:
 
 Hi Kever,
 
 On Wed, 28 Nov 2018 at 18:10, Kever Yang  wrote:
 
 
 Hi Philipp,
 
 
 On 11/28/2018 05:07 PM, Philipp Tomsich wrote:
 
 Kever,
 
 On 28.11.2018, at 03:04, Kever Yang  wrote:
 
 Use ROCKCHIP_BOOT_MODE_REG instead of grf structure so that
 we can re-use the source code later.
 
 Signed-off-by: Kever Yang 
 
 NAK, as there are still pending changes.
 
 Yes, I got that, and I send out my comments on your comments with no
 more response.
 
 See below for the reminder, in case this got lost.
 
 ---
 
 arch/arm/mach-rockchip/Kconfig| 1 +
 arch/arm/mach-rockchip/rk3128-board.c | 5 +
 2 files changed, 2 insertions(+), 4 deletions(-)
 
 diff --git a/arch/arm/mach-rockchip/Kconfig 
 b/arch/arm/mach-rockchip/Kconfig
 index 145d96b1f0..94a03e2a38 100644
 --- a/arch/arm/mach-rockchip/Kconfig
 +++ b/arch/arm/mach-rockchip/Kconfig
 @@ -179,6 +179,7 @@ config TPL_ROCKCHIP_BACK_TO_BROM
 config ROCKCHIP_BOOT_MODE_REG
   hex "Rockchip boot mode flag register address"
   default 0x200081c8 if ROCKCHIP_RK3036
 +default 0x100a0038 if ROCKCHIP_RK3128
   default 0x20004040 if ROCKCHIP_RK3188
   default 0x110005c8 if ROCKCHIP_RK322X
   default 0xff730094 if ROCKCHIP_RK3288
 
 As previously discussed: these should all go into header files, as they 
 are not user-configurable.
 This affects multiple patch series (as I requested the same for the STIMER 
 address).
 
 I believe you mention about this: http://patchwork.ozlabs.org/patch/891462/
 Now the model in u-boot rockchip channel is:
 - People send out patches to mailing list;
 - The patch get an ACK patch and review patch may request for change in
 1 week~4 months;
 - According to the maintainer's comment, people reply for why the patch
 like this,
 and maybe the patch do not need to change just like what the
 maintainer want.
 - BUT, there will never be more reply/comments.
 - Then, people have to resend the patches they think it may be
 reasonable, and maintainer
 then complain people doesn't address his comment.
 
 For this patch, I think:
 - This is not an first patch for this operation, this just make rk3128
 work like other SoCs, it's not a new feature;
 - This kind of default value setting is all over the U-Boot project, I'm
 not say it's correct,
 but it's a good solution and convenient for us to use the same object
 with different value in different SoCs,
 It's much better to separate them into more then 10 header files or
 lots of "#ifdef CONFIG_ROCKCHIIP_RK3128"
 in one header files.
 
 I hope I can get reply for this mail this time.
 
 Hi Simon,
  Could you help to comment on this?
 
 
 What happens if the user changes the value?
 
 Can this go in the device tree?
 
 It seems like this should be in a driver, to me. We have a SYSCON
 driver for GRF. Should we add an ioctl-type interface to it?
 
 
 This affects a number of settings by now, including the addresses for the
 debug UARTs, secure timer base addresses and the boot-mode register.
 
 What we’d really need would be a “read/write named-register” operation
 (which could either be an ioctl or a new read/write operation that takes a
 selector that can then internally be mapped onto an actual address).
 However, this would require a custom syscon for each chip (or at least a
 per-chip driver-data), which also doesn’t sound like a desirable design.
>>> 
>>> I assume it would come from the device tree.
>>> 
>>> To me this seems like a reasonable design. Yes it would need per-chip
>>> DT settings, or perhaps driver data.
>>> 
>>> But I believe we alreayd have a syscon_.c for each chip.
>> 
>> Yes, there are syscon_*.c files per chip, but these only contain the 
>> compatible
>> tables and reuse the generic syscon implementation.
>> 
>> I’ll take a stab at creating a RFC series to extend the generic syscon with 
>> an
>> ‘read/write named register’ mechanism.
> 
> OK, but I think it might be better to use something like ioctl(), if
> the operation is generally the same. E.g. if you have operations like:
> 
> - set boot mode
> - enable JTAG
> - ..

Good point. I still have my old prototype that tried something similar for
RGMII settings — should be a good-enough starting point.

Philipp.
___
U-Boot mailing

Re: [U-Boot] [RFC PATCH v2 00/11] SF: Migrate to Linux SPI NOR framework

[Tom Rini]

On Thu, Dec 06, 2018 at 10:44:00PM +0530, Jagan Teki wrote:
> On Tue, Dec 4, 2018 at 5:56 PM Vignesh R  wrote:
> >
> > U-Boot SPI NOR support (sf layer) is quite outdated as it does not
> > support 4 byte addressing opcodes, SFDP table parsing and different types of
> > quad mode enable sequences. Many newer flashes no longer support BANK
> > registers used by sf layer to a access >16MB space.
> > Also, many SPI controllers have special MMIO interfaces which provide
> > accelerated read/write access but require knowledge of flash parameters
> > to make use of it. Recent spi-mem layer provides a way to support such
> > flashes but sf layer isn't using that.
> > This patch series syncs SPI NOR framework from Linux v4.19. It also adds
> > spi-mem support on top.
> > So, we gain 4byte addressing support and SFDP support. This makes
> > migrating to U-Boot MTD framework easier.
> 
> We(someone) has proposed this sync before, but we(at-least I) rely on
> implementing via DM not direct sync to Linux. ofcourse other
> subsystems might have doing this but I literally don't propose to do
> that, since it may fire the u-boot implementation in future.
> 
> If you really get things up further, try to check this DM based
> spi-nor here[1] and lets discuss on u-boot point-of-view. I've paused
> this because of non-dm code, but I'm thinking we even re-change this
> to fit MTD driver-model (this is my TODO, once spi dm migration done).

We need to make sure things overall are a good fit and I know we've had
some back and forth on this, but, "sync with Linux subsystem and make it
work cleanly (as possible) in U-Boot" is the path I think we need to
take and I like what Vignesh has done and to repeat myself from earlier,
I want to see this series (or rather, it's overall evolution) come in
for v2019.04.  Progress over time on top of those changes is good but as
you note, your series is from a year ago and that was a pretty long
evolution in that direction too.  We need to get this solved and since
we have motivated developers right now, I want to see this resolved.
Thanks!

-- 
Tom


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

Re: [U-Boot] [RESENT PATCH 1/2] rockchip: rk3128: use ROCKCHIP_BOOT_MODE_REG to update reboot flag

[Simon Glass]

Hi Philipp,

On Thu, 6 Dec 2018 at 04:02, Philipp Tomsich
 wrote:
>
> Simon,
>
> > On 06.12.2018, at 02:31, Simon Glass  wrote:
> >
> > Hi Philipp,
> >
> > On Thu, 29 Nov 2018 at 13:57, Philipp Tomsich
> >  wrote:
> >>
> >> Simon,
> >>
> >> On 29.11.2018, at 19:43, Simon Glass  wrote:
> >>
> >> Hi Kever,
> >>
> >> On Wed, 28 Nov 2018 at 18:10, Kever Yang  wrote:
> >>
> >>
> >> Hi Philipp,
> >>
> >>
> >> On 11/28/2018 05:07 PM, Philipp Tomsich wrote:
> >>
> >> Kever,
> >>
> >> On 28.11.2018, at 03:04, Kever Yang  wrote:
> >>
> >> Use ROCKCHIP_BOOT_MODE_REG instead of grf structure so that
> >> we can re-use the source code later.
> >>
> >> Signed-off-by: Kever Yang 
> >>
> >> NAK, as there are still pending changes.
> >>
> >> Yes, I got that, and I send out my comments on your comments with no
> >> more response.
> >>
> >> See below for the reminder, in case this got lost.
> >>
> >> ---
> >>
> >> arch/arm/mach-rockchip/Kconfig| 1 +
> >> arch/arm/mach-rockchip/rk3128-board.c | 5 +
> >> 2 files changed, 2 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/arch/arm/mach-rockchip/Kconfig 
> >> b/arch/arm/mach-rockchip/Kconfig
> >> index 145d96b1f0..94a03e2a38 100644
> >> --- a/arch/arm/mach-rockchip/Kconfig
> >> +++ b/arch/arm/mach-rockchip/Kconfig
> >> @@ -179,6 +179,7 @@ config TPL_ROCKCHIP_BACK_TO_BROM
> >> config ROCKCHIP_BOOT_MODE_REG
> >>hex "Rockchip boot mode flag register address"
> >>default 0x200081c8 if ROCKCHIP_RK3036
> >> +default 0x100a0038 if ROCKCHIP_RK3128
> >>default 0x20004040 if ROCKCHIP_RK3188
> >>default 0x110005c8 if ROCKCHIP_RK322X
> >>default 0xff730094 if ROCKCHIP_RK3288
> >>
> >> As previously discussed: these should all go into header files, as they 
> >> are not user-configurable.
> >> This affects multiple patch series (as I requested the same for the STIMER 
> >> address).
> >>
> >> I believe you mention about this: http://patchwork.ozlabs.org/patch/891462/
> >> Now the model in u-boot rockchip channel is:
> >> - People send out patches to mailing list;
> >> - The patch get an ACK patch and review patch may request for change in
> >> 1 week~4 months;
> >> - According to the maintainer's comment, people reply for why the patch
> >> like this,
> >>  and maybe the patch do not need to change just like what the
> >> maintainer want.
> >> - BUT, there will never be more reply/comments.
> >> - Then, people have to resend the patches they think it may be
> >> reasonable, and maintainer
> >>  then complain people doesn't address his comment.
> >>
> >> For this patch, I think:
> >> - This is not an first patch for this operation, this just make rk3128
> >> work like other SoCs, it's not a new feature;
> >> - This kind of default value setting is all over the U-Boot project, I'm
> >> not say it's correct,
> >> but it's a good solution and convenient for us to use the same object
> >> with different value in different SoCs,
> >> It's much better to separate them into more then 10 header files or
> >> lots of "#ifdef CONFIG_ROCKCHIIP_RK3128"
> >> in one header files.
> >>
> >> I hope I can get reply for this mail this time.
> >>
> >> Hi Simon,
> >>   Could you help to comment on this?
> >>
> >>
> >> What happens if the user changes the value?
> >>
> >> Can this go in the device tree?
> >>
> >> It seems like this should be in a driver, to me. We have a SYSCON
> >> driver for GRF. Should we add an ioctl-type interface to it?
> >>
> >>
> >> This affects a number of settings by now, including the addresses for the
> >> debug UARTs, secure timer base addresses and the boot-mode register.
> >>
> >> What we’d really need would be a “read/write named-register” operation
> >> (which could either be an ioctl or a new read/write operation that takes a
> >> selector that can then internally be mapped onto an actual address).
> >> However, this would require a custom syscon for each chip (or at least a
> >> per-chip driver-data), which also doesn’t sound like a desirable design.
> >
> > I assume it would come from the device tree.
> >
> > To me this seems like a reasonable design. Yes it would need per-chip
> > DT settings, or perhaps driver data.
> >
> > But I believe we alreayd have a syscon_.c for each chip.
>
> Yes, there are syscon_*.c files per chip, but these only contain the 
> compatible
> tables and reuse the generic syscon implementation.
>
> I’ll take a stab at creating a RFC series to extend the generic syscon with an
> ‘read/write named register’ mechanism.

OK, but I think it might be better to use something like ioctl(), if
the operation is generally the same. E.g. if you have operations like:

- set boot mode
- enable JTAG
- ..

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

Re: [U-Boot] [RFC PATCH v2 00/11] SF: Migrate to Linux SPI NOR framework

[Vignesh R]

On 06/12/18 10:06 PM, Simon Goldschmidt wrote:
> Am 06.12.2018 um 14:54 schrieb Simon Goldschmidt:
>> On Thu, Dec 6, 2018 at 2:45 PM Vignesh R  wrote:
>>>
>>> Hi Simon,
>>>
>>> On 06/12/18 2:15 AM, Simon Goldschmidt wrote:
 Am 05.12.2018 um 07:55 schrieb Simon Goldschmidt:
> On Wed, Dec 5, 2018 at 7:51 AM Vignesh R  wrote:
>>> [...]
>>> I did some compilation tests first and I'm happy to say that with the
>>> SPL_SPI_FLASH_TINY option enabled, my SPL is about 1900 byte smaller
>>> than before :-)
>>>
>>> However, my socfpga socrates board does not boot. I'll have to
>>> investigate why. I just applied this series and compiled for
>>> socfpga_socrates_defconfig. Is there anything else I should have changed
>>> to make it work?
>>>
>>
>> Oops, that's unfortunate.
>> Just to be sure, does SPL fail to come up or SPL fails to load U-Boot
>> from flash? Is this with SPL_SPI_FLASH_TINY enabled?
>
> I tried both TINY and standard. Both are failing to load U-Boot (I get
> the standard error message that loading from SPI flash failed).
>
>> Could you enable debug prints at the end of spi_mem_exec_op() in
>> drivers/spi/spi-mem.c to see what commands are sent and their responses?
>
> OK, I'll do that.
>
>> I have TI EVM with Cadence QSPI(like SoCFPGA) but with a Spansion flash
>> and that seems to work fine with both full and tiny stack.

 OK, so I enabled some debugging and the first issue is that U-Boot has
 SNOR_MFR_MICRON and SNOR_MFR_ST while Linux only has SNOR_MFR_MICRON but
 defines it to CFI_MFR_ST (0x20, U-Boot ends up with 0x2c). While this
 might be correct, it leads to my n25q256a not being handled as
 "micron-like" and the code falls through to using Spansion-like opcode
 (0x17) that my chip does not understand.

>>>
>>> Oops, sorry, the micron chip I had has CFI MFR id of 0x2c, so I
>>> overlooked this. I have updated this now.
>>>
 However, after changing this (and using opcode 0xb7 to bring the chip
 into 4 byte mode, including 0x06 for write-enable), it still does not
 work as it uses the 'READ' opcode 0x03 instead of the 'FAST READ' opcode
 0x0b that U-Boot used until now. The problem here might be that 'READ'
 cannot do Quad-SPI (4-4-4) and I'm not sure the Cadence driver can
 handle Extended-SPI (1-1-1) that the 'READ' command is limited to...

>>>
>>> I had accidentally dropped Fast Read from SPI NOR layer and have sync'd
>>> it up now.  I see that in socfpga dts, flash does not contain:
>>> spi-rx-bus-width = <4>;
>>
>> We can add that if it helps. I'll try to update the upstream Linux dts
>> anyway to add "jeded,spi-nor" compatible once Neil's series is
>> applied.
>>
>>> Therefore SPI NOR layer falls back to READ (even though its a QSPI
>>> flash). But nevertheless with updated branch[1] you should see falling
>>> back to FAST READ with Cadence QSPI on your board (and 1-1-4, if rx bus
>>> width is 4).
>>>
 Using SFDP would probably help, but that doesn't compile (as I wrote in
 the other thread).

>>>
>>> Sorry for that. I have fixed that up and tested SFDP parsing logic with
>>> a Spansion flash. Note that Cadence QSPI wont support SFDP parsing as
>>> driver enables Quad mode for all reads and SFDP is only 1-1-1.
>>
>> Oh, I haven't really looked into that yet. That's sad.
>>

Yes, thats one of the motivation for this series. I wanted to use same driver
to support Cadence Octal SPI IP but this simply wasn't possible due disconnect 
b/w SF and SPI layer.
I plan to fix Cadence QSPI by moving to spi-mem layer once SF layer is in place

>>>
 On the other hand, enabling SFDP will increase the text/rodata size for
 SPL. We might need to remove the non-SFDP and write code as a counter
 measure to prevent increasing code size.

>>>
>>> That's not an option as Flash devices (even though have same JEDEC ID)
>>> manufactured before JESD216 std dont have SFDP populated. So, we will
>>> need to have both non-SFDP and SFDP support with option to disable SFDP
>>> (for size and boot time optimizations).
>>
>> Well, my idea was if you'd know that all the flash chips on your board
>> supported it, you'd be safe. It would only be a Kconfig option to
>> reduce binary size (get rid of the flash IDs table).
 But if SFDP doesn't work for QSPI anyway, that's not the best idea, I 
 guess...
>>

Yeah, current U-Boot SPI layer does not allow SPI Flash layer to communicate
bus width to SPI controller drivers. Either drivers capable of supporting 
Quad mode should move to spi-mem framework or spi_xfer() interface needs to be 
expanded.

>>> Thanks for all the debugging! It would be great if you could try below
>>> branch and let me know if it fixes all the issues.
>>> If yes, I will remove RFC and post new series.
>>
>> Sure, I'll try to find the time soon.
> 
> Had a quick test with both standard and tiny in SPL and both

Re: [U-Boot] [linux-sunxi] r40 enable loading from spi

[Jagan Teki]

On Sat, Dec 1, 2018 at 11:25 PM Ralph Spitzner  wrote:
>
> small patch to enable loading of u-boot from spi-flash  on allwinner r40 
> boards
> ( Bananapi_M2_Ultra/Berry)
>
> testet on my Berry, now loading linux from scsi :-)
>
> 

Please check [1] before sending, patch doesn't have proper information
about change and no s-o-b etc.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC PATCH v2 00/11] SF: Migrate to Linux SPI NOR framework

[Jagan Teki]

On Tue, Dec 4, 2018 at 5:56 PM Vignesh R  wrote:
>
> U-Boot SPI NOR support (sf layer) is quite outdated as it does not
> support 4 byte addressing opcodes, SFDP table parsing and different types of
> quad mode enable sequences. Many newer flashes no longer support BANK
> registers used by sf layer to a access >16MB space.
> Also, many SPI controllers have special MMIO interfaces which provide
> accelerated read/write access but require knowledge of flash parameters
> to make use of it. Recent spi-mem layer provides a way to support such
> flashes but sf layer isn't using that.
> This patch series syncs SPI NOR framework from Linux v4.19. It also adds
> spi-mem support on top.
> So, we gain 4byte addressing support and SFDP support. This makes
> migrating to U-Boot MTD framework easier.

We(someone) has proposed this sync before, but we(at-least I) rely on
implementing via DM not direct sync to Linux. ofcourse other
subsystems might have doing this but I literally don't propose to do
that, since it may fire the u-boot implementation in future.

If you really get things up further, try to check this DM based
spi-nor here[1] and lets discuss on u-boot point-of-view. I've paused
this because of non-dm code, but I'm thinking we even re-change this
to fit MTD driver-model (this is my TODO, once spi dm migration done).

[1] http://git.denx.de/?p=u-boot-spi.git;a=shortlog;h=refs/heads/next-working
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 4/4] rockchip: puma-rk3399: Enable vdd-log during bootup.

[Christoph Müllner]

> On 06.12.2018, at 14:40, Philipp Tomsich 
>  wrote:
> 
> 
> 
>> On 06.12.2018, at 12:25, Christoph Muellner 
>>  wrote:
>> 
>> On the RK3399-Q7 "Puma" module VDD_LOG is generated by an external
>> regulator, which sets the voltage level to 900 mV, which is within
>> the allowed range and which works quite fine.
>> 
>> However, in specific use-cases we need to adjust VDD_LOG to
>> maintain stable operation or to reduce power consumption.
>> This adjustment can be done via pwm2.
>> 
>> This patch allows to tune the VDD_LOG voltage level
>> via DTS. To do so the following things are done:
>> 
>> * Setup pin muxing for PWM2 (based on DTS settings)
>> * Turn on the vdd_log regulator (based on DTS settings)
>> 
>> Reported-by: Assaf Agmon 
>> Signed-off-by: Philipp Tomsich 
>> Signed-off-by: Christoph Muellner 
> 
> Reviewed-by: Philipp Tomsich 
> 
> See below for requested changes.
> 
>> ---
>> board/theobroma-systems/puma_rk3399/puma-rk3399.c | 43 
>> +++
>> 1 file changed, 43 insertions(+)
>> 
>> diff --git a/board/theobroma-systems/puma_rk3399/puma-rk3399.c 
>> b/board/theobroma-systems/puma_rk3399/puma-rk3399.c
>> index 573e691457f..e2915fcca50 100644
>> --- a/board/theobroma-systems/puma_rk3399/puma-rk3399.c
>> +++ b/board/theobroma-systems/puma_rk3399/puma-rk3399.c
>> @@ -23,10 +23,34 @@
>> #include 
>> #include 
>> 
>> +static int setup_pinctrl(void)
> 
> I’d prefer a forward-declaration and this further down, as I want to keep 
> board_init()
> up front.  Just a personal preference, but still ...
> 
>> +{
>> +int ret;
>> +struct udevice *pinctrl;
>> +
>> +ret = uclass_get_device(UCLASS_PINCTRL, 0, &pinctrl);
>> +if (ret) {
>> +debug("%s: Cannot find pinctrl device\n", __func__);
> 
> Please use pr_debug.
> 
>> +goto out;
>> +}
>> +
>> +/* Enable pwm2 for vdd_log regulator. */
>> +ret = pinctrl_request_noflags(pinctrl, PERIPH_ID_PWM2);
>> +if (ret) {
>> +printf("%s PWM2 pinctrl init fail!\n", __func__);
> 
> Don’t use printf here — either this is a pr_err or a pr_debug.
> 
>> +goto out;
>> +}
>> +
>> +out:
>> +return 0;
>> +}
>> +
>> int board_init(void)
>> {
>>  int ret;
>> 
>> +setup_pinctrl();
>> +
>>  /*
>>   * We need to call into regulators_enable_boot_on() again, as the call
>>   * during SPL may have not included all regulators.
>> @@ -35,6 +59,25 @@ int board_init(void)
>>  if (ret)
>>  debug("%s: Cannot enable boot on regulator\n", __func__);
>> 
>> +/*
>> + * vdd_log is ignored by regulators_enable_boot_on(), because
>> + * regulator-min-microvolt != regulator-max-microvolt.
>> + * Therefore we explicitly enable it here.
>> + */
>> +struct udevice *regulator;
>> +ret = regulator_get_by_platname("vdd_log", ®ulator);
>> +if (ret) {
>> +debug("%s Looking up regulator vdd-log failed!\n", __func__);
>> +goto out;
>> +}
>> +
>> +ret = regulator_set_enable(regulator, true);
>> +if (ret) {
>> +debug("%s Enabling vdd-log failed!\n", __func__);
>> +goto out;
>> +}
> 
> Generally speaking: I would prefer a
>   if (ret == 0)
>   ret = regulator_set_enable(regulator, true);
>   if (ret)
>   pr_debug(…) 
> 
> However, this should be irrelevant anyway: why doesn’t 
>   ret = regulators_enable_boot_on(false); 
> in board_init() suffice?

That's noted in the comment above.
In regulator_pre_probe() is a test if uc_pdata->min_uV == uc_pdata->max_uV.
Only if this is true, the regulator will be considered to get 
REGULATOR_FLAG_AUTOSET.
If that flag is not given, then the regulator will not be turned on by
regulators_enable_boot_on().

In other words: the regulator subsystem does not allow to enable
regulators by default, when regulator-min-microvolt and
regulator-max-microvolt is different in the DTS.
However these values are required for PWM regulators to specify
the possible range, they are covering (from 0 to 100 % duty-cycle).

Also note, that U-Boot's pwm_regulator driver currently evaluates
the non-documented regulator-init-microvolt entry in the DTS node.
It uses this value, if given, to setup the voltage during probe().
However, the pwm_regulator is not probed, because of the reasons above.


> 
>> +
>> +out:
>>  return 0;
>> }
>> 
>> -- 
>> 2.11.0

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

Re: [U-Boot] [RFC PATCH v2 00/11] SF: Migrate to Linux SPI NOR framework

[Simon Goldschmidt]

Am 06.12.2018 um 14:54 schrieb Simon Goldschmidt:

On Thu, Dec 6, 2018 at 2:45 PM Vignesh R  wrote:


Hi Simon,

On 06/12/18 2:15 AM, Simon Goldschmidt wrote:

Am 05.12.2018 um 07:55 schrieb Simon Goldschmidt:

On Wed, Dec 5, 2018 at 7:51 AM Vignesh R  wrote:

[...]

I did some compilation tests first and I'm happy to say that with the
SPL_SPI_FLASH_TINY option enabled, my SPL is about 1900 byte smaller
than before :-)

However, my socfpga socrates board does not boot. I'll have to
investigate why. I just applied this series and compiled for
socfpga_socrates_defconfig. Is there anything else I should have changed
to make it work?



Oops, that's unfortunate.
Just to be sure, does SPL fail to come up or SPL fails to load U-Boot
from flash? Is this with SPL_SPI_FLASH_TINY enabled?


I tried both TINY and standard. Both are failing to load U-Boot (I get
the standard error message that loading from SPI flash failed).


Could you enable debug prints at the end of spi_mem_exec_op() in
drivers/spi/spi-mem.c to see what commands are sent and their responses?


OK, I'll do that.


I have TI EVM with Cadence QSPI(like SoCFPGA) but with a Spansion flash
and that seems to work fine with both full and tiny stack.


OK, so I enabled some debugging and the first issue is that U-Boot has
SNOR_MFR_MICRON and SNOR_MFR_ST while Linux only has SNOR_MFR_MICRON but
defines it to CFI_MFR_ST (0x20, U-Boot ends up with 0x2c). While this
might be correct, it leads to my n25q256a not being handled as
"micron-like" and the code falls through to using Spansion-like opcode
(0x17) that my chip does not understand.



Oops, sorry, the micron chip I had has CFI MFR id of 0x2c, so I
overlooked this. I have updated this now.


However, after changing this (and using opcode 0xb7 to bring the chip
into 4 byte mode, including 0x06 for write-enable), it still does not
work as it uses the 'READ' opcode 0x03 instead of the 'FAST READ' opcode
0x0b that U-Boot used until now. The problem here might be that 'READ'
cannot do Quad-SPI (4-4-4) and I'm not sure the Cadence driver can
handle Extended-SPI (1-1-1) that the 'READ' command is limited to...



I had accidentally dropped Fast Read from SPI NOR layer and have sync'd
it up now.  I see that in socfpga dts, flash does not contain:
spi-rx-bus-width = <4>;


We can add that if it helps. I'll try to update the upstream Linux dts
anyway to add "jeded,spi-nor" compatible once Neil's series is
applied.


Therefore SPI NOR layer falls back to READ (even though its a QSPI
flash). But nevertheless with updated branch[1] you should see falling
back to FAST READ with Cadence QSPI on your board (and 1-1-4, if rx bus
width is 4).


Using SFDP would probably help, but that doesn't compile (as I wrote in
the other thread).



Sorry for that. I have fixed that up and tested SFDP parsing logic with
a Spansion flash. Note that Cadence QSPI wont support SFDP parsing as
driver enables Quad mode for all reads and SFDP is only 1-1-1.


Oh, I haven't really looked into that yet. That's sad.




On the other hand, enabling SFDP will increase the text/rodata size for
SPL. We might need to remove the non-SFDP and write code as a counter
measure to prevent increasing code size.



That's not an option as Flash devices (even though have same JEDEC ID)
manufactured before JESD216 std dont have SFDP populated. So, we will
need to have both non-SFDP and SFDP support with option to disable SFDP
(for size and boot time optimizations).


Well, my idea was if you'd know that all the flash chips on your board
supported it, you'd be safe. It would only be a Kconfig option to
reduce binary size (get rid of the flash IDs table).

But if SFDP doesn't work for QSPI anyway, that's not the best idea, I guess...


Thanks for all the debugging! It would be great if you could try below
branch and let me know if it fixes all the issues.
If yes, I will remove RFC and post new series.


Sure, I'll try to find the time soon.


Had a quick test with both standard and tiny in SPL and both configs now 
work on my board. I haven't tested SFDP as you said it does not works on 
Cadence QSPI. (I tested compiling it though, and that works now.)


Oh, and I think it's important to say that with your spi-nor-tiny code, 
SPL code size is reduced by 1980 bytes for my config 
(socfpga_socrates_defconfig)!


Regards,
Simon



Regards,
Simon



[1] https://github.com/r-vignesh/u-boot.git spi-nor-mig-patch-v1

--
Regards
Vignesh


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

Re: [U-Boot] [PATCH 1/2] AQUANTIA USXGMII autoneg enable

[York Sun]

On 10/30/18 2:54 AM, Valentin-catalin Neacsu wrote:
> If System interface protocol is USXGMII then enable USXGMII autoneg
> Signed-off-by: Valentin Catalin Neacsu 
> ---
>  drivers/net/phy/aquantia.c | 18 ++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/drivers/net/phy/aquantia.c b/drivers/net/phy/aquantia.c
> index 6678147545..603abb5a7f 100644
> --- a/drivers/net/phy/aquantia.c
> +++ b/drivers/net/phy/aquantia.c
> @@ -4,6 +4,7 @@
>   * SPDX-License-Identifier:  GPL-2.0+
>   *
>   * Copyright 2014 Freescale Semiconductor, Inc.
> + * Copyright 2018 NXP
>   */
>  #include 
>  #include 
> @@ -20,6 +21,13 @@
>  #define AQUNTIA_SPEED_LSB_MASK   0x2000
>  #define AQUNTIA_SPEED_MSB_MASK   0x40
>  
> +#define AQUANTIA_SYSTEM_INTERFACE_SR 0xe812
> +#define AQUANTIA_VENDOR_PROVISIONING_REG 0xC441
> +
> +#define AQUANTIA_USX_AUTONEG_CONTROL_ENA 0x0008
> +#define AQUANTIA_SI_IN_USE_MASK  0x0078
> +#define AQUANTIA_SI_USXGMII  0x0018
> +
>  int aquantia_config(struct phy_device *phydev)
>  {
>   u32 val = phy_read(phydev, MDIO_MMD_PMAPMD, MII_BMCR);
> @@ -41,6 +49,16 @@ int aquantia_config(struct phy_device *phydev)
>   phy_write(phydev, MDIO_MMD_PMAPMD, MII_BMCR,
> AQUNTIA_SPEED_LSB_MASK |
> AQUNTIA_SPEED_MSB_MASK);
> +
> + val = phy_read(phydev, MDIO_MMD_PHYXS,
> +AQUANTIA_SYSTEM_INTERFACE_SR);
> + /* If SI is USXGMII then start USXGMII autoneg*/
> + if ((val & AQUANTIA_SI_IN_USE_MASK) == AQUANTIA_SI_USXGMII) {
> + phy_write(phydev, MDIO_MMD_PHYXS,
> +   AQUANTIA_VENDOR_PROVISIONING_REG,
> +   AQUANTIA_USX_AUTONEG_CONTROL_ENA);
> + }
> +
>   } else if (phydev->interface == PHY_INTERFACE_MODE_SGMII_2500) {
>   /* 2.5GBASE-T mode */
>   phydev->advertising = SUPPORTED_1000baseT_Full;
> 

This should be sent to Joe.

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

[U-Boot] [PATCH] mpc85xx: Add support for -msingle-pic-base

[Joakim Tjernlund]

-msingle-pic-base is a new gcc(from 4.6) option for ppc and
it reduces the size of my u-boot with about 4-5 KB.
While at it, add -fno-jump-tables too to save a
few more bytes.

e5500 core:
size u-boot.bef
   textdata bss dec hex filename
 473043   23772  307104  803919   c444f u-boot.bef
size u-boot.aft
   textdata bss dec hex filename
 453195   23772  307104  784071   bf6c7 u-boot.aft

e500 core:
size u-boot.bef
   textdata bss dec hex filename
 292998   17868   24968  335834   51fda u-boot.bef
size u-boot.aft
   textdata bss dec hex filename
 288002   17868   24968  330838   50c56 u-boot.aft

Signed-off-by: Joakim Tjernlund 
---
 arch/powerpc/cpu/mpc85xx/config.mk | 1 +
 arch/powerpc/cpu/mpc85xx/start.S   | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/arch/powerpc/cpu/mpc85xx/config.mk 
b/arch/powerpc/cpu/mpc85xx/config.mk
index 44d69add68..7a1d81cf2d 100644
--- a/arch/powerpc/cpu/mpc85xx/config.mk
+++ b/arch/powerpc/cpu/mpc85xx/config.mk
@@ -4,6 +4,7 @@
 # Xianghua Xiao, x.x...@motorola.com
 
 PLATFORM_CPPFLAGS += -Wa,-me500 -msoft-float -mno-string
+PLATFORM_RELFLAGS += -msingle-pic-base -fno-jump-tables
 
 # -mspe=yes is needed to have -mno-spe accepted by a buggy GCC;
 # see "[PATCH,rs6000] make -mno-spe work as expected" on
diff --git a/arch/powerpc/cpu/mpc85xx/start.S b/arch/powerpc/cpu/mpc85xx/start.S
index 932aa08b27..dbc705388c 100644
--- a/arch/powerpc/cpu/mpc85xx/start.S
+++ b/arch/powerpc/cpu/mpc85xx/start.S
@@ -1216,6 +1216,9 @@ _start_cont:
mr  r1,r3   /* Transfer to SP(r1) */
 
GET_GOT
+   /* Needed for -msingle-pic-base */
+   bl  _GLOBAL_OFFSET_TABLE_@local-4
+   mflrr30
 
/* Pass our potential ePAPR device tree pointer to cpu_init_early_f */
mr  r3, r24
-- 
2.18.1

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

Re: [U-Boot] [PATCH v3 13/28] mtd: ensure MTD is compiled when ENV_IS_IN_FLASH is selected

[Simon Goldschmidt]

Am 06.12.2018 um 16:59 schrieb Tom Rini:

On Thu, Dec 06, 2018 at 04:23:00PM +0100, Miquel Raynal wrote:

Hi Wolfgang,

Wolfgang Denk  wrote on Thu, 06 Dec 2018 10:32:14 +0100:


Dear Boris,

In message <20181206100016.706330ba@bbrezillon> you wrote:
  

I took a rather small configuration: stm32f429-discovery_defconfig
which uses CONFIG_MTD_NOR_FLASH. Without CONFIG_MTD, u-boot.bin is
209416 bytes. With CONFIG_MTD, u-boot.bin is 214540 bytes. This is an
additional 5124 bytes which represent about 2% of the entire size.


So it's a 5 k code increase for zero benefit.


There's no short term benefit, but the long term benefit is ease better
maintainability.


For MTD, yes.  But a user of environment in NOR flash does not
necessarily want MTD,

Parallel NOR flash is a traditional memory device - you find it
frequently on older, resource-restricted systems.  It is not so
polular any more today - SPI NOR is much cheaper, comea with a
smaller footprint of thr PCB and is much easier to route.

And on these older systems a 5 k code increase is often critical.

Especially if this should also affect the SPL.


Please, stop repeating the SPL is a problem. I am not forcing MTD
to be compiled in the SPL. You overlooked that point in our last
three e-mails: MTD is *not* built in the SPL unless specifically
requested. CONFIG_MTD has absolutely no impact on the SPL.


Right, and this is the important part that you are indeed getting right.
We must be careful about the SPL case.  You are, so good, lets move on.


Now, let's talk about U-Boot size. I went through U-Boot MTD
implementation to see where this 5k overhead was coming from. The
explanation is short: nothing. My observation was wrong because of
commands being automatically compiled ("default y"). By the way this is
the kind of approach I want to get rid of because it is fundamentally
wrong.

Here is a brief summary, still with stm32f429-discovery_defconfig:
* before my series (MTD_NOR_FLASH + CMD_FLASH)
* after my series without MTD (CONFIG_MTD_NOR_FLASH + CMD_FLASH)
* after my series with MTD (MTD_NOR_FLASH + CMD_FLASH + MTD)

In all cases, u-boot.bin is 214540 bytes. I suppose if you don't use
anything from MTD, there is no additional symbol, the binary will not be
enlarged. And when you use it, it is hard to tell how much bytes were
added by MTD and how much bytes have been added by the feature using
MTD.


So when you aren't calling into the new code it gets discarded as
expected, good.  Thanks for digging.


I think you missed the *no*. There's no overhead at all for the SPL.
Either the platform was already enabling CONFIG_SPL_MTD_SUPPORT and the
MTD code was already compiled in before Miquel's patch, or this option
is disabled, and the SPL still does *not* embed the MTD layer.


So parallel NOR is still supported in the SPL _without_ MTD?
Then why cannot we have the same support in U-Boot, too?


Code duplication, maintainability, single interface, (hopefully) single
command, etc


Right.  And to be clear, in the main U-Boot case while we don't grow the
binary for fun, we do grow the overall binary (for some board or
another) with nearly every push because we're quite often doing "lets
fix $X" or "let's add $Y" and rarely "Drop $X as it's linked but
unused".  Just like DM is resulting in an overall larger binary that's a
more consistent and maintainable codebase, this too will result in some
things growing in binary size.  And we should review the framework with
an eye towards "can we do this in a more simple or size-courteous way?"
size growth in and of itself isn't a fatal problem.


Please understand that there is a fundamental difference between
parallel NOR flash and things like NAND, SPI NOR etc. - the latter
are storage devices, which are usually handled as block device or
similar, i. e. you always need a driver to read data.  Parallel NOR
is not storage, it is _memory_, which is directly mapped int o
memory. You can execute code from it.


That's only partially true. Yes, you can read from a parallel NORs like
if it was memory because memory controllers embedded in SoCs provide
your a direct mmio mapping. That's not true for write accesses,


Right, but especially in the SPL read access is sufficient.


100% agreed, the SPL just needs read access. But we are talking about
U-Boot itself here.


So, new but related question.  Are we dropping the write path in the
case of SPL?  The only case I can think of where SPL might be doing an
MTD write would be bootcount stored in env, so we should be able to drop
those paths in the normal case.


Based on my tests with Vignesh's series to port SF to MTD, I don't think 
we drop the write part in SPL. I also brought that up in that thread.


However, my (preliminary) test results of his work showed that SPL size 
is actually reduced when using his new 'spi-nor-tiny' code. And that's 
without trying to reduce MTD code size.


Regards,
Simon




[...]


Please do not understand me wrong: I fully agree with the MT

Re: [U-Boot] [PATCH v3 0/4] Add Rock960 and Ficus 96Board support

[Tom Rini]

On Thu, Dec 06, 2018 at 09:07:39PM +0530, Manivannan Sadhasivam wrote:
> On Thu, Dec 06, 2018 at 10:20:30AM -0500, Tom Rini wrote:
> > On Thu, Dec 06, 2018 at 08:53:33AM +0100, Alexander Graf wrote:
> > > 
> > > 
> > > On 26.10.18 20:00, Philipp Tomsich wrote:
> > > > 
> > > > 
> > > >> On 26.10.2018, at 19:17, Manivannan Sadhasivam 
> > > >>  wrote:
> > > >>
> > > >> On Fri, Sep 28, 2018 at 12:32:57AM +0530, Manivannan Sadhasivam wrote:
> > > >>> This patchset adds support for Rock960 and Ficus 96Boards from Vamrs.
> > > >>> Since both boards share most of the configurations, a common Rock960
> > > >>> family support is added with common support and the actual boards are
> > > >>> based on this.
> > > >>>
> > > >>> The previous version of the patchseries were adding Rock960 [1] and
> > > >>> Ficus [2] board support individually, but this series fuses them
> > > >>> together based on the common board support as per Linux kernel.
> > > >>>
> > > >>> [1] https://patchwork.ozlabs.org/cover/963239/
> > > >>> [2] https://lists.denx.de/pipermail/u-boot/2018-August/339059.html
> > > >>>
> > > >>> This patchseries has been tested on Rock960 v1.2 board and expecting
> > > >>> Ezequiel to do the testing for Ficus.
> > > >>>
> > > >>> PS: I have explicitly removed the previous Ack's for the Ficus board
> > > >>> since there has been a heavy modification done on these patches.
> > > >>>
> > > >>> Thanks,
> > > >>> Mani
> > > >>>
> > > >>
> > > >> Hi,
> > > >>
> > > >> Is there any update on this patchset? AFAIK everyone is happy to get
> > > >> this merged!
> > > > 
> > > > It’s on pretty high up my list for the next merge window, but I didn’t 
> > > > get it into
> > > > the current version.
> > > 
> > > So there goes another merge window. Any progress here?
> > 
> > So, I'm going to call out here that this new board is entirely missing a
> > MAINTAINERS file.  Causing ./tools/genboardscfg.py to complain about new
> > defconfigs without a MAINTAINER.  I'm gonna fix it now, but, grumble.  I
> > know checkpatch.pl does complain "Hey, new file, do you need to update
> > MAINTAINERS" from Linux.
> >
> 
> Hi Tom,
> 
> Sorry for that! It was my bad to left MAINTAINERS entry for Ficus board.
> Since there are two boards (Rock960 and Ficus) sharing common board
> support, I forgot to update the later one.

Not a huge problem, really.  I've now become motivated enough to write a
.travis.yml test for this problem and thus pushing the problem visibly
up the chain like I should have months ago :)

-- 
Tom


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

Re: [U-Boot] [PATCH v1] fs: fat: dynamically allocate memory for temporary buffer

[Tom Rini]

On Thu, Dec 06, 2018 at 04:45:08PM +0100, Stefan Agner wrote:
> On 06.12.2018 16:13, Tom Rini wrote:
> > On Thu, Dec 06, 2018 at 02:58:52PM +0100, Stefan Agner wrote:
> > 
> >> From: Stefan Agner 
> >>
> >> Drop the statically allocated get_contents_vfatname_block and
> >> dynamically allocate a buffer only if required. This saves
> >> 64KiB of memory.
> >>
> >> Signed-off-by: Stefan Agner 
> > 
> > Is there a particular issue you're running into here, or just that what
> > we're doing is just generally not a great idea?  I ask since I need to
> > poke git history to make sure that the thing at the back of my mind
> > about us needing to do this for some annoying boot case is intentional.
> 
> I was in the process checking large global variables since I had issues
> on a target with limited SRAM (used pre-relocation). I only after
> writing this patch I realized that the space for the .bss section is not
> required pre-relocation, so the patch did not help in my particular
> case.
> 
> That said, in git history I saw that get_contents_vfatname_block has
> been used more broadly in earlier FAT implementations. Now it is only
> used to handle a corner case: when loading from a file with an offset...
> I guess the .bss section is cleared, so we probably safe 64KiB of
> zeroing out... I feel it is still worth doing the change, but I don't
> have a really strong feeling.

Thanks for checking.  Yes, this is probably a good thing to do overall
and whatever historical reason we needed it like this isn't applicable
now if we're doing offset loading only in this case which isn't an SPL
thing anyhow.

-- 
Tom


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

Re: [U-Boot] [PATCH v3 13/28] mtd: ensure MTD is compiled when ENV_IS_IN_FLASH is selected

[Tom Rini]

On Thu, Dec 06, 2018 at 04:23:00PM +0100, Miquel Raynal wrote:
> Hi Wolfgang,
> 
> Wolfgang Denk  wrote on Thu, 06 Dec 2018 10:32:14 +0100:
> 
> > Dear Boris,
> > 
> > In message <20181206100016.706330ba@bbrezillon> you wrote:
> > >  
> > > > > I took a rather small configuration: stm32f429-discovery_defconfig
> > > > > which uses CONFIG_MTD_NOR_FLASH. Without CONFIG_MTD, u-boot.bin is
> > > > > 209416 bytes. With CONFIG_MTD, u-boot.bin is 214540 bytes. This is an
> > > > > additional 5124 bytes which represent about 2% of the entire size.
> > > > 
> > > > So it's a 5 k code increase for zero benefit.  
> > >
> > > There's no short term benefit, but the long term benefit is ease better
> > > maintainability.  
> > 
> > For MTD, yes.  But a user of environment in NOR flash does not
> > necessarily want MTD,
> > 
> > Parallel NOR flash is a traditional memory device - you find it
> > frequently on older, resource-restricted systems.  It is not so
> > polular any more today - SPI NOR is much cheaper, comea with a
> > smaller footprint of thr PCB and is much easier to route.
> > 
> > And on these older systems a 5 k code increase is often critical.
> > 
> > Especially if this should also affect the SPL.
> 
> Please, stop repeating the SPL is a problem. I am not forcing MTD
> to be compiled in the SPL. You overlooked that point in our last
> three e-mails: MTD is *not* built in the SPL unless specifically
> requested. CONFIG_MTD has absolutely no impact on the SPL.

Right, and this is the important part that you are indeed getting right.
We must be careful about the SPL case.  You are, so good, lets move on.

> Now, let's talk about U-Boot size. I went through U-Boot MTD
> implementation to see where this 5k overhead was coming from. The
> explanation is short: nothing. My observation was wrong because of
> commands being automatically compiled ("default y"). By the way this is
> the kind of approach I want to get rid of because it is fundamentally
> wrong.
> 
> Here is a brief summary, still with stm32f429-discovery_defconfig:
> * before my series (MTD_NOR_FLASH + CMD_FLASH)
> * after my series without MTD (CONFIG_MTD_NOR_FLASH + CMD_FLASH)
> * after my series with MTD (MTD_NOR_FLASH + CMD_FLASH + MTD)
> 
> In all cases, u-boot.bin is 214540 bytes. I suppose if you don't use
> anything from MTD, there is no additional symbol, the binary will not be
> enlarged. And when you use it, it is hard to tell how much bytes were
> added by MTD and how much bytes have been added by the feature using
> MTD.

So when you aren't calling into the new code it gets discarded as
expected, good.  Thanks for digging.

> > > I think you missed the *no*. There's no overhead at all for the SPL.
> > > Either the platform was already enabling CONFIG_SPL_MTD_SUPPORT and the
> > > MTD code was already compiled in before Miquel's patch, or this option
> > > is disabled, and the SPL still does *not* embed the MTD layer.  
> > 
> > So parallel NOR is still supported in the SPL _without_ MTD?
> > Then why cannot we have the same support in U-Boot, too?
> 
> Code duplication, maintainability, single interface, (hopefully) single
> command, etc

Right.  And to be clear, in the main U-Boot case while we don't grow the
binary for fun, we do grow the overall binary (for some board or
another) with nearly every push because we're quite often doing "lets
fix $X" or "let's add $Y" and rarely "Drop $X as it's linked but
unused".  Just like DM is resulting in an overall larger binary that's a
more consistent and maintainable codebase, this too will result in some
things growing in binary size.  And we should review the framework with
an eye towards "can we do this in a more simple or size-courteous way?"
size growth in and of itself isn't a fatal problem.

> > > > Please understand that there is a fundamental difference between
> > > > parallel NOR flash and things like NAND, SPI NOR etc. - the latter
> > > > are storage devices, which are usually handled as block device or
> > > > similar, i. e. you always need a driver to read data.  Parallel NOR
> > > > is not storage, it is _memory_, which is directly mapped int o
> > > > memory. You can execute code from it.  
> > >
> > > That's only partially true. Yes, you can read from a parallel NORs like
> > > if it was memory because memory controllers embedded in SoCs provide
> > > your a direct mmio mapping. That's not true for write accesses,  
> > 
> > Right, but especially in the SPL read access is sufficient.
> 
> 100% agreed, the SPL just needs read access. But we are talking about
> U-Boot itself here.

So, new but related question.  Are we dropping the write path in the
case of SPL?  The only case I can think of where SPL might be doing an
MTD write would be bootcount stored in env, so we should be able to drop
those paths in the normal case.

> [...]
> 
> > > > Please do not understand me wrong: I fully agree with the MTD rework
> > > > in general, and I'm happy to see it happen.  But please 

Re: [U-Boot] [PATCH v1] fs: fat: dynamically allocate memory for temporary buffer

[Stefan Agner]

On 06.12.2018 14:58, Stefan Agner wrote:
> From: Stefan Agner 
> 
> Drop the statically allocated get_contents_vfatname_block and
> dynamically allocate a buffer only if required. This saves
> 64KiB of memory.
> 
> Signed-off-by: Stefan Agner 
> ---
> 
>  fs/fat/fat.c | 20 ++--
>  1 file changed, 14 insertions(+), 6 deletions(-)
> 
> diff --git a/fs/fat/fat.c b/fs/fat/fat.c
> index 4bc3030ab8..06bcd02835 100644
> --- a/fs/fat/fat.c
> +++ b/fs/fat/fat.c
> @@ -305,9 +305,6 @@ get_cluster(fsdata *mydata, __u32 clustnum, __u8
> *buffer, unsigned long size)
>   * into 'buffer'.
>   * Update the number of bytes read in *gotsize or return -1 on fatal errors.
>   */
> -__u8 get_contents_vfatname_block[MAX_CLUSTSIZE]
> - __aligned(ARCH_DMA_MINALIGN);
> -
>  static int get_contents(fsdata *mydata, dir_entry *dentptr, loff_t pos,
>   __u8 *buffer, loff_t maxsize, loff_t *gotsize)
>  {
> @@ -318,7 +315,7 @@ static int get_contents(fsdata *mydata, dir_entry
> *dentptr, loff_t pos,
>   loff_t actsize;
>  
>   *gotsize = 0;
> - debug("Filesize: %llu bytes\n", filesize);
> + debug("Filesize: %llu bytes, starting at pos %llu\n", filesize, pos);
>  
>   if (pos >= filesize) {
>   debug("Read position past EOF: %llu\n", pos);
> @@ -350,15 +347,26 @@ static int get_contents(fsdata *mydata,
> dir_entry *dentptr, loff_t pos,
>  
>   /* align to beginning of next cluster if any */
>   if (pos) {
> + __u8 *tmp_buffer;
> +
> + tmp_buffer = malloc_cache_aligned(MAX_CLUSTSIZE);
> + if (tmp_buffer == NULL) {
> + debug("Error: allocating buffer\n");
> + return -1;
> + }
> +
>   actsize = min(filesize, (loff_t)bytesperclust);
> - if (get_cluster(mydata, curclust, get_contents_vfatname_block,
> + if (get_cluster(mydata, curclust, tmp_buffer,
>   (int)actsize) != 0) {
>   printf("Error reading cluster\n");
> + free(tmp_buffer);
>   return -1;
>   }
>   filesize -= actsize;
>   actsize -= pos;
> - memcpy(buffer, get_contents_vfatname_block + pos, actsize);
> + memcpy(tmp_buffer, buffer + pos, actsize);

I somehow managed to mix up copy direction here. Will send a v2.

--
Stefan

> + free(tmp_buffer);
> +
>   *gotsize += actsize;
>   if (!filesize)
>   return 0;
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v1] fs: fat: dynamically allocate memory for temporary buffer

[Stefan Agner]

On 06.12.2018 16:13, Tom Rini wrote:
> On Thu, Dec 06, 2018 at 02:58:52PM +0100, Stefan Agner wrote:
> 
>> From: Stefan Agner 
>>
>> Drop the statically allocated get_contents_vfatname_block and
>> dynamically allocate a buffer only if required. This saves
>> 64KiB of memory.
>>
>> Signed-off-by: Stefan Agner 
> 
> Is there a particular issue you're running into here, or just that what
> we're doing is just generally not a great idea?  I ask since I need to
> poke git history to make sure that the thing at the back of my mind
> about us needing to do this for some annoying boot case is intentional.

I was in the process checking large global variables since I had issues
on a target with limited SRAM (used pre-relocation). I only after
writing this patch I realized that the space for the .bss section is not
required pre-relocation, so the patch did not help in my particular
case.

That said, in git history I saw that get_contents_vfatname_block has
been used more broadly in earlier FAT implementations. Now it is only
used to handle a corner case: when loading from a file with an offset...
I guess the .bss section is cleared, so we probably safe 64KiB of
zeroing out... I feel it is still worth doing the change, but I don't
have a really strong feeling.

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

Re: [U-Boot] [PATCH v3 0/4] Add Rock960 and Ficus 96Board support

[Manivannan Sadhasivam]

On Thu, Dec 06, 2018 at 10:20:30AM -0500, Tom Rini wrote:
> On Thu, Dec 06, 2018 at 08:53:33AM +0100, Alexander Graf wrote:
> > 
> > 
> > On 26.10.18 20:00, Philipp Tomsich wrote:
> > > 
> > > 
> > >> On 26.10.2018, at 19:17, Manivannan Sadhasivam 
> > >>  wrote:
> > >>
> > >> On Fri, Sep 28, 2018 at 12:32:57AM +0530, Manivannan Sadhasivam wrote:
> > >>> This patchset adds support for Rock960 and Ficus 96Boards from Vamrs.
> > >>> Since both boards share most of the configurations, a common Rock960
> > >>> family support is added with common support and the actual boards are
> > >>> based on this.
> > >>>
> > >>> The previous version of the patchseries were adding Rock960 [1] and
> > >>> Ficus [2] board support individually, but this series fuses them
> > >>> together based on the common board support as per Linux kernel.
> > >>>
> > >>> [1] https://patchwork.ozlabs.org/cover/963239/
> > >>> [2] https://lists.denx.de/pipermail/u-boot/2018-August/339059.html
> > >>>
> > >>> This patchseries has been tested on Rock960 v1.2 board and expecting
> > >>> Ezequiel to do the testing for Ficus.
> > >>>
> > >>> PS: I have explicitly removed the previous Ack's for the Ficus board
> > >>> since there has been a heavy modification done on these patches.
> > >>>
> > >>> Thanks,
> > >>> Mani
> > >>>
> > >>
> > >> Hi,
> > >>
> > >> Is there any update on this patchset? AFAIK everyone is happy to get
> > >> this merged!
> > > 
> > > It’s on pretty high up my list for the next merge window, but I didn’t 
> > > get it into
> > > the current version.
> > 
> > So there goes another merge window. Any progress here?
> 
> So, I'm going to call out here that this new board is entirely missing a
> MAINTAINERS file.  Causing ./tools/genboardscfg.py to complain about new
> defconfigs without a MAINTAINER.  I'm gonna fix it now, but, grumble.  I
> know checkpatch.pl does complain "Hey, new file, do you need to update
> MAINTAINERS" from Linux.
>

Hi Tom,

Sorry for that! It was my bad to left MAINTAINERS entry for Ficus board.
Since there are two boards (Rock960 and Ficus) sharing common board
support, I forgot to update the later one.

Regards,
Mani

> -- 
> Tom


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

Re: [U-Boot] [PATCH v3 13/28] mtd: ensure MTD is compiled when ENV_IS_IN_FLASH is selected

[Miquel Raynal]

Hi Wolfgang,

Wolfgang Denk  wrote on Thu, 06 Dec 2018 10:32:14 +0100:

> Dear Boris,
> 
> In message <20181206100016.706330ba@bbrezillon> you wrote:
> >  
> > > > I took a rather small configuration: stm32f429-discovery_defconfig
> > > > which uses CONFIG_MTD_NOR_FLASH. Without CONFIG_MTD, u-boot.bin is
> > > > 209416 bytes. With CONFIG_MTD, u-boot.bin is 214540 bytes. This is an
> > > > additional 5124 bytes which represent about 2% of the entire size.
> > > 
> > > So it's a 5 k code increase for zero benefit.  
> >
> > There's no short term benefit, but the long term benefit is ease better
> > maintainability.  
> 
> For MTD, yes.  But a user of environment in NOR flash does not
> necessarily want MTD,
> 
> Parallel NOR flash is a traditional memory device - you find it
> frequently on older, resource-restricted systems.  It is not so
> polular any more today - SPI NOR is much cheaper, comea with a
> smaller footprint of thr PCB and is much easier to route.
> 
> And on these older systems a 5 k code increase is often critical.
> 
> Especially if this should also affect the SPL.

Please, stop repeating the SPL is a problem. I am not forcing MTD
to be compiled in the SPL. You overlooked that point in our last
three e-mails: MTD is *not* built in the SPL unless specifically
requested. CONFIG_MTD has absolutely no impact on the SPL.

Now, let's talk about U-Boot size. I went through U-Boot MTD
implementation to see where this 5k overhead was coming from. The
explanation is short: nothing. My observation was wrong because of
commands being automatically compiled ("default y"). By the way this is
the kind of approach I want to get rid of because it is fundamentally
wrong.

Here is a brief summary, still with stm32f429-discovery_defconfig:
* before my series (MTD_NOR_FLASH + CMD_FLASH)
* after my series without MTD (CONFIG_MTD_NOR_FLASH + CMD_FLASH)
* after my series with MTD (MTD_NOR_FLASH + CMD_FLASH + MTD)

In all cases, u-boot.bin is 214540 bytes. I suppose if you don't use
anything from MTD, there is no additional symbol, the binary will not be
enlarged. And when you use it, it is hard to tell how much bytes were
added by MTD and how much bytes have been added by the feature using
MTD.

> 
> > I think you missed the *no*. There's no overhead at all for the SPL.
> > Either the platform was already enabling CONFIG_SPL_MTD_SUPPORT and the
> > MTD code was already compiled in before Miquel's patch, or this option
> > is disabled, and the SPL still does *not* embed the MTD layer.  
> 
> So parallel NOR is still supported in the SPL _without_ MTD?
> Then why cannot we have the same support in U-Boot, too?

Code duplication, maintainability, single interface, (hopefully) single
command, etc

> 
> > > Please understand that there is a fundamental difference between
> > > parallel NOR flash and things like NAND, SPI NOR etc. - the latter
> > > are storage devices, which are usually handled as block device or
> > > similar, i. e. you always need a driver to read data.  Parallel NOR
> > > is not storage, it is _memory_, which is directly mapped int o
> > > memory. You can execute code from it.  
> >
> > That's only partially true. Yes, you can read from a parallel NORs like
> > if it was memory because memory controllers embedded in SoCs provide
> > your a direct mmio mapping. That's not true for write accesses,  
> 
> Right, but especially in the SPL read access is sufficient.

100% agreed, the SPL just needs read access. But we are talking about
U-Boot itself here.

[...]

> > > Please do not understand me wrong: I fully agree with the MTD rework
> > > in general, and I'm happy to see it happen.  But please do it in a
> > > way not to break existing basic use cases.  
> >
> > Okay, maybe we can put aside the parallel NOR case for now, but I do
> > think even parallel NOR accesses would benefit from the MTD layer.  
> 
> I agree that it benefits form an architectural and maintenance point
> of view.  But it adds a new dependency with more than insignificant
> impact to systems where this has not been before, and where
> resources are tight.

Do you see another significant impact that must prevent NOR flashes to
depend on MTD?


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

Re: [U-Boot] [PATCH v3 0/4] Add Rock960 and Ficus 96Board support

[Tom Rini]

On Thu, Dec 06, 2018 at 08:53:33AM +0100, Alexander Graf wrote:
> 
> 
> On 26.10.18 20:00, Philipp Tomsich wrote:
> > 
> > 
> >> On 26.10.2018, at 19:17, Manivannan Sadhasivam 
> >>  wrote:
> >>
> >> On Fri, Sep 28, 2018 at 12:32:57AM +0530, Manivannan Sadhasivam wrote:
> >>> This patchset adds support for Rock960 and Ficus 96Boards from Vamrs.
> >>> Since both boards share most of the configurations, a common Rock960
> >>> family support is added with common support and the actual boards are
> >>> based on this.
> >>>
> >>> The previous version of the patchseries were adding Rock960 [1] and
> >>> Ficus [2] board support individually, but this series fuses them
> >>> together based on the common board support as per Linux kernel.
> >>>
> >>> [1] https://patchwork.ozlabs.org/cover/963239/
> >>> [2] https://lists.denx.de/pipermail/u-boot/2018-August/339059.html
> >>>
> >>> This patchseries has been tested on Rock960 v1.2 board and expecting
> >>> Ezequiel to do the testing for Ficus.
> >>>
> >>> PS: I have explicitly removed the previous Ack's for the Ficus board
> >>> since there has been a heavy modification done on these patches.
> >>>
> >>> Thanks,
> >>> Mani
> >>>
> >>
> >> Hi,
> >>
> >> Is there any update on this patchset? AFAIK everyone is happy to get
> >> this merged!
> > 
> > It’s on pretty high up my list for the next merge window, but I didn’t get 
> > it into
> > the current version.
> 
> So there goes another merge window. Any progress here?

So, I'm going to call out here that this new board is entirely missing a
MAINTAINERS file.  Causing ./tools/genboardscfg.py to complain about new
defconfigs without a MAINTAINER.  I'm gonna fix it now, but, grumble.  I
know checkpatch.pl does complain "Hey, new file, do you need to update
MAINTAINERS" from Linux.

-- 
Tom


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

Re: [U-Boot] [PATCH v1] fs: fat: dynamically allocate memory for temporary buffer

[Tom Rini]

On Thu, Dec 06, 2018 at 02:58:52PM +0100, Stefan Agner wrote:

> From: Stefan Agner 
> 
> Drop the statically allocated get_contents_vfatname_block and
> dynamically allocate a buffer only if required. This saves
> 64KiB of memory.
> 
> Signed-off-by: Stefan Agner 

Is there a particular issue you're running into here, or just that what
we're doing is just generally not a great idea?  I ask since I need to
poke git history to make sure that the thing at the back of my mind
about us needing to do this for some annoying boot case is intentional.
Thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] Enable expression support for CONFIG_BOARD_SIZE_LIMIT

[Fabio Estevam]

Hi Wolfgang,

[Adding Andy]

On Thu, Dec 6, 2018 at 12:41 PM Fabio Estevam  wrote:

> I am running top of tree mainline U-Boot + your patch from this thread, plus:
>
> --- a/include/configs/pico-imx7d.h
> +++ b/include/configs/pico-imx7d.h
> @@ -134,7 +134,8 @@
>  /* FLASH and environment organization */
>  #define CONFIG_ENV_SIZESZ_8K
>
> -#define CONFIG_ENV_OFFSET  (8 * SZ_64K)
> +#define CONFIG_ENV_OFFSET  (768 * 1024)
> +#define CONFIG_BOARD_SIZE_LIMIT(1 * 1024)
>  #define CONFIG_SYS_FSL_USDHC_NUM   2
>
>  #define CONFIG_SYS_MMC_ENV_DEV 0
>
> It does build fine, but as I have intentionally forced a small
> CONFIG_BOARD_SIZE_LIMIT  I wanted it to fail, but it does not fail as
> shown below:
>
>   OBJCOPY u-boot-nodtb.bin
> /bin/sh: 1: arithmetic expression: expecting primary: ""(1 * 1024)""

I read the link suggested by Andy Pont: https://wiki.ubuntu.com/DashAsBinSh

where it says:

"In Makefiles, you can set the following variable at the top:

SHELL = /bin/bash"

And by forcing the SHELL variable to bash, then your patch works fine here:

--- a/Makefile
+++ b/Makefile
@@ -1,5 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0+

+SHELL = /bin/bash
 VERSION = 2019
 PATCHLEVEL = 01
 SUBLEVEL =
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] Please pull u-boot-rockchip

[Philipp Tomsich]

Tom,

the following changes have gone through Travis prior to the rebase and tagging
as https://travis-ci.org/ptomsich/u-boot-rockchip/builds/464122086

Thanks,
Philipp.


The following changes since commit 2a055ea53260ac8addeeb94eb671172844bc9106:

  Merge tag 'dm-pull-5dec18' of git://git.denx.de/u-boot-dm (2018-12-05 
20:32:25 -0500)

are available in the git repository at:

  git://git.denx.de/u-boot-rockchip.git for-master-20181206

for you to fetch changes up to 467877341a4169f1a8c50b7ebe4c0e6fd28da727:

  rockchip: rk3399: Add Ficus EE board support (2018-12-06 16:04:49 +0100)


- Changes the declaration of regs_phy in dwc2-otg to uintptr_t
  to ensure it can be cast to void* for use with writel().
- Add the Rock960 and Ficus boards.


Manivannan Sadhasivam (3):
  rockchip: rk3399: Add common Rock960 family from Vamrs
  rockchip: rk3399: Add Rock960 CE board support
  rockchip: rk3399: Add Ficus EE board support

Philipp Tomsich (1):
  usb: dwc2-otg: make regs_phy (in platdata) a uintptr_t

Randy Li (1):
  arm: dts: rockchip: add some common pin-settings to rk3399

 arch/arm/dts/Makefile  |2 +
 arch/arm/dts/rk3399-ficus.dts  |   78 +++
 arch/arm/dts/rk3399-rock960.dts|   45 
 arch/arm/dts/rk3399-rock960.dtsi   |  506 
+
 arch/arm/dts/rk3399-sdram-lpddr3-2GB-1600.dtsi | 1536 

 arch/arm/dts/rk3399.dtsi   |   55 -
 arch/arm/mach-rockchip/rk3399/Kconfig  |   26 +++
 board/vamrs/rock960_rk3399/Kconfig |   15 ++
 board/vamrs/rock960_rk3399/MAINTAINERS |6 +
 board/vamrs/rock960_rk3399/Makefile|6 +
 board/vamrs/rock960_rk3399/README  |  152 +
 board/vamrs/rock960_rk3399/rock960-rk3399.c|   50 +
 configs/ficus-rk3399_defconfig |   71 ++
 configs/rock960-rk3399_defconfig   |   69 ++
 include/configs/rock960_rk3399.h   |   15 ++
 include/usb/dwc2_udc.h |2 +-
 16 files changed, 2627 insertions(+), 7 deletions(-)
 create mode 100644 arch/arm/dts/rk3399-ficus.dts
 create mode 100644 arch/arm/dts/rk3399-rock960.dts
 create mode 100644 arch/arm/dts/rk3399-rock960.dtsi
 create mode 100644 arch/arm/dts/rk3399-sdram-lpddr3-2GB-1600.dtsi
 create mode 100644 board/vamrs/rock960_rk3399/Kconfig
 create mode 100644 board/vamrs/rock960_rk3399/MAINTAINERS
 create mode 100644 board/vamrs/rock960_rk3399/Makefile
 create mode 100644 board/vamrs/rock960_rk3399/README
 create mode 100644 board/vamrs/rock960_rk3399/rock960-rk3399.c
 create mode 100644 configs/ficus-rk3399_defconfig
 create mode 100644 configs/rock960-rk3399_defconfig
 create mode 100644 include/configs/rock960_rk3399.h


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

Re: [U-Boot] [U-Boot, v3, 1/4] arm: dts: rockchip: add some common pin-settings to rk3399

[Philipp Tomsich]

> From: Randy Li 
> 
> Those pins would be used by many boards.
> 
> Commit grabbed from Linux:
> 
> commit b41023282d07b61a53e2c9b9508912b1e7ce7b4f
> Author: Randy Li 
> Date:   Thu Jun 21 21:32:10 2018 +0800
> 
> arm64: dts: rockchip: add some common pin-settings to rk3399
> 
> Those pins would be used by many boards.
> 
> Signed-off-by: Randy Li 
> Signed-off-by: Heiko Stuebner 
> 
> Acked-by: Philipp Tomsich 
> Signed-off-by: Randy Li 
> Signed-off-by: Heiko Stuebner 
> Signed-off-by: Ezequiel Garcia 
> Tested-by: Peter Robinson 
> Reviewed-by: Philipp Tomsich 
> ---
> 
> Changes in v3: None
> 
> Changes in v2: None
> 
>  arch/arm/dts/rk3399.dtsi | 55 +++-
>  1 file changed, 49 insertions(+), 6 deletions(-)
> 

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

Re: [U-Boot] [U-Boot, v3, 4/4] rockchip: rk3399: Add Ficus EE board support

[Philipp Tomsich]

> Add board support for Ficus EE board from Vamrs. This board utilizes
> common Rock960 family support.
> 
> Following peripherals are tested and known to work:
> * Gigabit Ethernet
> * USB 2.0
> * MMC
> 
> Signed-off-by: Ezequiel Garcia 
> [Reworked based on common Rock960 family support]
> Signed-off-by: Manivannan Sadhasivam 
> Reviewed-by: Simon Glass 
> Reviewed-by: Philipp Tomsich 
> ---
> 
> Changes in v3: Modified the DRAM config header from LPDDR3 to DDR3
> 
> Changes in v2: None
> 
>  arch/arm/dts/Makefile  |  1 +
>  arch/arm/dts/rk3399-ficus.dts  | 78 ++
>  configs/ficus-rk3399_defconfig | 71 +++
>  3 files changed, 150 insertions(+)
>  create mode 100644 arch/arm/dts/rk3399-ficus.dts
>  create mode 100644 configs/ficus-rk3399_defconfig
> 

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

Re: [U-Boot] [U-Boot, v3, 2/4] rockchip: rk3399: Add common Rock960 family from Vamrs

[Philipp Tomsich]

> Rock960 is a family of boards based on Rockchip RK3399 SoC from Vamrs.
> It consists of Rock960 (Consumer Edition) and Ficus (Enterprise Edition)
> 96Boards.
> 
> Below are some of the key differences between both Rock960 and Ficus
> boards:
> 
> 1. Different host enable GPIO for USB
> 2. Different power and reset GPIO for PCI-E
> 3. No Ethernet port on Rock960
> 
> The common board support will be utilized by both boards. The device
> tree has been organized in such a way that only the properties which
> differ between both boards are placed in the board specific dts and
> the reset of the nodes are placed in common dtsi file.
> 
> Signed-off-by: Manivannan Sadhasivam 
> [Added instructions for SD card boot]
> Signed-off-by: Ezequiel Garcia 
> Reviewed-by: Simon Glass 
> Tested-by: Peter Robinson 
> ---
> 
> Changes in v3: Added instruction for copying prebuilt bl31.elf for SPL
> 
> Changes in v2: None
> 
>  arch/arm/dts/rk3399-rock960.dtsi| 506 
>  arch/arm/mach-rockchip/rk3399/Kconfig   |  26 +
>  board/vamrs/rock960_rk3399/Kconfig  |  15 +
>  board/vamrs/rock960_rk3399/MAINTAINERS  |   6 +
>  board/vamrs/rock960_rk3399/Makefile |   6 +
>  board/vamrs/rock960_rk3399/README   | 152 ++
>  board/vamrs/rock960_rk3399/rock960-rk3399.c |  50 ++
>  include/configs/rock960_rk3399.h|  15 +
>  8 files changed, 776 insertions(+)
>  create mode 100644 arch/arm/dts/rk3399-rock960.dtsi
>  create mode 100644 board/vamrs/rock960_rk3399/Kconfig
>  create mode 100644 board/vamrs/rock960_rk3399/MAINTAINERS
>  create mode 100644 board/vamrs/rock960_rk3399/Makefile
>  create mode 100644 board/vamrs/rock960_rk3399/README
>  create mode 100644 board/vamrs/rock960_rk3399/rock960-rk3399.c
>  create mode 100644 include/configs/rock960_rk3399.h
> 

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

Re: [U-Boot] [PATCH] Enable expression support for CONFIG_BOARD_SIZE_LIMIT

[Fabio Estevam]

Hi Philipp,

On Thu, Dec 6, 2018 at 12:50 PM Philipp Tomsich
 wrote:

> If you take a look at how CONFIG_BOARD_SIZE_LIMIT is used
> ifneq ($(CONFIG_BOARD_SIZE_LIMIT),)
> BOARD_SIZE_CHECK = \
> @actual=`wc -c $@ | awk '{print $$1}'`; \
> limit=`printf "%d" $(CONFIG_BOARD_SIZE_LIMIT)`; \
> if test $$actual -gt $$limit; then \
> echo "$@ exceeds file size limit:" >&2 ; \
> echo "  limit:  $$limit bytes" >&2 ; \
> echo "  actual: $$actual bytes" >&2 ; \
> echo "  excess: $$((actual - limit)) bytes" >&2; \
> exit 1; \
> fi
> else
> BOARD_SIZE_CHECK =
> endif
> you will notice that there’s no arithmetic expansion on it prior to it being
> passed int a 'if -gt’ compare.

Yes, this the current code. The patch Wolfgang submitted in this
thread changed the Makefile.

>
> 'git grep’ also shows that no other board is requesting an arithmetic
> expansion on this (i.e. everyone else just uses a constant).
>
> Note that the C-preprocessor will not do arithmetic for you...
> So you’ll either have to change the Makefile or define this as an actual
> constant number.

Yes, Wolfgang's patch changed the Makefile to allow arithmetic
operation, but it does not work on my system.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v3, 3/4] rockchip: rk3399: Add Rock960 CE board support

[Philipp Tomsich]

> Add board support for Rock960 CE board from Vamrs. This board utilizes
> common Rock960 family support.
> 
> Following peripherals are tested and known to work:
> * USB 2.0
> * MMC
> 
> This commit also adds DDR configuration for LPDDR3-2GiB-1600MHz which
> is being used on the board.
> 
> Signed-off-by: Manivannan Sadhasivam 
> Reviewed-by: Simon Glass 
> Tested-by: Peter Robinson 
> Reviewed-by: Philipp Tomsich 
> ---
> 
> Changes in v3:
> 
> * Add config options for USB to Ethernet and USB2 PHY
> 
> Changes in v2:
> 
> * Added missing config options for USB/uSD
> * Fixed the commit description for DDR speed
> 
>  arch/arm/dts/Makefile |1 +
>  arch/arm/dts/rk3399-rock960.dts   |   45 +
>  .../arm/dts/rk3399-sdram-lpddr3-2GB-1600.dtsi | 1536 +
>  configs/rock960-rk3399_defconfig  |   69 +
>  4 files changed, 1651 insertions(+)
>  create mode 100644 arch/arm/dts/rk3399-rock960.dts
>  create mode 100644 arch/arm/dts/rk3399-sdram-lpddr3-2GB-1600.dtsi
>  create mode 100644 configs/rock960-rk3399_defconfig
> 

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

Re: [U-Boot] [PATCH v3 0/4] Add Rock960 and Ficus 96Board support

[Philipp Tomsich]

> On 06.12.2018, at 15:57, Philipp Tomsich 
>  wrote:
> 
> 
> 
>> On 06.12.2018, at 08:53, Alexander Graf > > wrote:
>> 
>> 
>> 
>> On 26.10.18 20:00, Philipp Tomsich wrote:
>>> 
>>> 
 On 26.10.2018, at 19:17, Manivannan Sadhasivam 
 >>> > wrote:
 
 On Fri, Sep 28, 2018 at 12:32:57AM +0530, Manivannan Sadhasivam wrote:
> This patchset adds support for Rock960 and Ficus 96Boards from Vamrs.
> Since both boards share most of the configurations, a common Rock960
> family support is added with common support and the actual boards are
> based on this.
> 
> The previous version of the patchseries were adding Rock960 [1] and
> Ficus [2] board support individually, but this series fuses them
> together based on the common board support as per Linux kernel.
> 
> [1] https://patchwork.ozlabs.org/cover/963239/ 
> 
> [2] https://lists.denx.de/pipermail/u-boot/2018-August/339059.html 
> 
> 
> This patchseries has been tested on Rock960 v1.2 board and expecting
> Ezequiel to do the testing for Ficus.
> 
> PS: I have explicitly removed the previous Ack's for the Ficus board
> since there has been a heavy modification done on these patches.
> 
> Thanks,
> Mani
> 
 
 Hi,
 
 Is there any update on this patchset? AFAIK everyone is happy to get
 this merged!
>>> 
>>> It’s on pretty high up my list for the next merge window, but I didn’t get 
>>> it into
>>> the current version.
>> 
>> So there goes another merge window. Any progress here?
> 
> It’s on u-boot-rockchip/master, but waiting for a USB change to be merged for 
> the PR.
> Surprisingly it failed in Travis-CI for the Rock960 board…

And I just saw Marek’s mail in my backlog from last night, so I can indeed send
out the PR now.

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

Re: [U-Boot] [PATCH] usb: dwc2-otg: make regs_phy (in platdata) a uintptr_t

[Philipp Tomsich]

> On 06.12.2018, at 01:48, Marek Vasut  wrote:
> 
> On 12/06/2018 01:32 AM, Philipp Tomsich wrote:
>> The regs_phy field of the platform data structure for dwc2-otg is
>> today declared an unsigned int, but will eventually be cast into a
>> void* for a writel operation.  This triggers errors on modern GCC
>> versions.
>> 
>> E.g. we get the following error with GCC 6.3:
>>  drivers/usb/phy/rockchip_usb2_phy.c: In function 'property_enable':
>>  arch/arm/include/asm/io.h:49:29: error: cast to pointer from integer of 
>> different size [-Werror=int-to-pointer-cast]
>>   #define __arch_putl(v,a)  (*(volatile unsigned int *)(a) = (v))
>>   ^
>>  arch/arm/include/asm/io.h:117:48: note: in expansion of macro '__arch_putl'
>>   #define writel(v,c) ({ u32 __v = v; __iowmb(); __arch_putl(__v,c); __v; })
>>  ^~~
>>  drivers/usb/phy/rockchip_usb2_phy.c:61:2: note: in expansion of macro 
>> 'writel'
>>writel(val, pdata->regs_phy + reg->offset);
>>^~
>> 
>> This commit changes regs_phy to be a uintptr_t to ensure that it is
>> large enough to hold any valid pointer (and fix the associated
>> warning).
>> 
>> Signed-off-by: Philipp Tomsich 
> 
> Oh, ew. Good catch.
> 
> Acked-by: Marek Vasut 
> 
> Apply it alongside the 

Applied to u-boot-rockchip/master.

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

Re: [U-Boot] [PATCH v3 0/4] Add Rock960 and Ficus 96Board support

[Philipp Tomsich]

> On 06.12.2018, at 08:53, Alexander Graf  wrote:
> 
> 
> 
> On 26.10.18 20:00, Philipp Tomsich wrote:
>> 
>> 
>>> On 26.10.2018, at 19:17, Manivannan Sadhasivam 
>>>  wrote:
>>> 
>>> On Fri, Sep 28, 2018 at 12:32:57AM +0530, Manivannan Sadhasivam wrote:
 This patchset adds support for Rock960 and Ficus 96Boards from Vamrs.
 Since both boards share most of the configurations, a common Rock960
 family support is added with common support and the actual boards are
 based on this.
 
 The previous version of the patchseries were adding Rock960 [1] and
 Ficus [2] board support individually, but this series fuses them
 together based on the common board support as per Linux kernel.
 
 [1] https://patchwork.ozlabs.org/cover/963239/
 [2] https://lists.denx.de/pipermail/u-boot/2018-August/339059.html
 
 This patchseries has been tested on Rock960 v1.2 board and expecting
 Ezequiel to do the testing for Ficus.
 
 PS: I have explicitly removed the previous Ack's for the Ficus board
 since there has been a heavy modification done on these patches.
 
 Thanks,
 Mani
 
>>> 
>>> Hi,
>>> 
>>> Is there any update on this patchset? AFAIK everyone is happy to get
>>> this merged!
>> 
>> It’s on pretty high up my list for the next merge window, but I didn’t get 
>> it into
>> the current version.
> 
> So there goes another merge window. Any progress here?

It’s on u-boot-rockchip/master, but waiting for a USB change to be merged for 
the PR.
Surprisingly it failed in Travis-CI for the Rock960 board…

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

Re: [U-Boot] [PATCH] Enable expression support for CONFIG_BOARD_SIZE_LIMIT

[Fabio Estevam]

On Thu, Dec 6, 2018 at 12:58 PM Fabio Estevam  wrote:
>
> On Thu, Dec 6, 2018 at 12:44 PM Andy Pont  wrote:
> >
> > Fabio wrote...
> >
> > $ /bin/sh --version
> > /bin/sh: 0: Illegal option --
> >
> > In my system /bin/sh points to bash:
> > $ ls -al /bin/sh
> > lrwxrwxrwx 1 root root 4 mai  2  2018 /bin/sh -> dash
> >
> > Just to pick up on the obvious… /bin/sh is showing as linked to dash not 
> > bash!
>
> Yes, I meant bash.

I meant 'dash' :-)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] Enable expression support for CONFIG_BOARD_SIZE_LIMIT

[Fabio Estevam]

On Thu, Dec 6, 2018 at 12:44 PM Andy Pont  wrote:
>
> Fabio wrote...
>
> $ /bin/sh --version
> /bin/sh: 0: Illegal option --
>
> In my system /bin/sh points to bash:
> $ ls -al /bin/sh
> lrwxrwxrwx 1 root root 4 mai  2  2018 /bin/sh -> dash
>
> Just to pick up on the obvious… /bin/sh is showing as linked to dash not bash!

Yes, I meant bash.

>
> Using (( … )) for arithmetic expansion is a bashism [1]

Correct:
$ cat random.sh
#!/bin/sh
echo $(($RANDOM % 10))
$ checkbashisms random.sh
possible bashism in random.sh line 2 ($RANDOM):
echo $(($RANDOM % 10))
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] Enable expression support for CONFIG_BOARD_SIZE_LIMIT

[Philipp Tomsich]

Fabio,

let me chime in (I had to do a quick ‘git grep’ on this, as I couldn’t ignore
the mail traffic any longer)...

> On 06.12.2018, at 15:41, Fabio Estevam  wrote:
> 
> Hi Wolfgang,
> 
> On Thu, Dec 6, 2018 at 12:23 PM Wolfgang Denk  wrote:
> 
>> This makes really no sense to me.  Can you please send me (off list)
>> a git diff of the tree that is not building for you against the
>> nearest mainline commit?
> 
> I am running top of tree mainline U-Boot + your patch from this thread, plus:
> 
> --- a/include/configs/pico-imx7d.h
> +++ b/include/configs/pico-imx7d.h
> @@ -134,7 +134,8 @@
> /* FLASH and environment organization */
> #define CONFIG_ENV_SIZESZ_8K
> 
> -#define CONFIG_ENV_OFFSET  (8 * SZ_64K)
> +#define CONFIG_ENV_OFFSET  (768 * 1024)
> +#define CONFIG_BOARD_SIZE_LIMIT(1 * 1024)

If you take a look at how CONFIG_BOARD_SIZE_LIMIT is used
ifneq ($(CONFIG_BOARD_SIZE_LIMIT),)
BOARD_SIZE_CHECK = \
@actual=`wc -c $@ | awk '{print $$1}'`; \
limit=`printf "%d" $(CONFIG_BOARD_SIZE_LIMIT)`; \
if test $$actual -gt $$limit; then \
echo "$@ exceeds file size limit:" >&2 ; \
echo "  limit:  $$limit bytes" >&2 ; \
echo "  actual: $$actual bytes" >&2 ; \
echo "  excess: $$((actual - limit)) bytes" >&2; \
exit 1; \
fi
else
BOARD_SIZE_CHECK =
endif
you will notice that there’s no arithmetic expansion on it prior to it being
passed int a 'if -gt’ compare.

'git grep’ also shows that no other board is requesting an arithmetic
expansion on this (i.e. everyone else just uses a constant).

Note that the C-preprocessor will not do arithmetic for you...
So you’ll either have to change the Makefile or define this as an actual
constant number.

> #define CONFIG_SYS_FSL_USDHC_NUM   2
> 
> #define CONFIG_SYS_MMC_ENV_DEV 0
> 
> It does build fine, but as I have intentionally forced a small
> CONFIG_BOARD_SIZE_LIMIT  I wanted it to fail, but it does not fail as
> shown below:
> 
>  OBJCOPY u-boot-nodtb.bin
> /bin/sh: 1: arithmetic expression: expecting primary: ""(1 * 1024)""
>  SYM u-boot.sym
>  COPYu-boot.bin
>  MKIMAGE u-boot.img
> = WARNING ==
> This board does not use CONFIG_DM_MMC. Please update
> the board to use CONFIG_DM_MMC before the v2019.04 release.
> Failure to update by the deadline may result in board removal.
> See doc/driver-model/MIGRATION.txt for more info.
> 
> = WARNING ==
> This board does not use CONFIG_DM_USB. Please update
> the board to use CONFIG_DM_USB before the v2019.07 release.
> Failure to update by the deadline may result in board removal.
> See doc/driver-model/MIGRATION.txt for more info.
> 
>  CFGCHK  u-boot.cfg
> 
> As you can see there are two issues:
> 
> 1. The warnin: /bin/sh: 1: arithmetic expression: expecting primary:
> ""(1 * 1024)""
> 
> 2. It should have not built in this case. It should have detected the
> overlap and signalized the error
> 
>> And please also the output of /"bin/sh --version".
> 
> $ /bin/sh --version
> /bin/sh: 0: Illegal option --
> 
> In my system /bin/sh points to bash:
> $ ls -al /bin/sh
> lrwxrwxrwx 1 root root 4 mai  2  2018 /bin/sh -> dash
> 
> /bin/bash --version
> GNU bash, version 4.4.19(1)-release (x86_64-pc-linux-gnu)
> Copyright (C) 2016 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> 
> This is free software; you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> 
> I am able to reproduce this problem with a standalone script:
> 
> $ cat random.sh
> #!/bin/bash
> echo $(($RANDOM % 10))
> $ ./random.sh
> 3
> 
> Worked fine with bash.
> 
> Now if I force it to dash:
> 
> $ cat random.sh
> #!/bin/dash
> echo $(($RANDOM % 10))
> $ ./random.sh
> ./random.sh: 2: ./random.sh: arithmetic expression: expecting primary: " % 10"
> 
> Which is the same warning I get in U-Boot.
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot

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

Re: [U-Boot] [PATCH] Enable expression support for CONFIG_BOARD_SIZE_LIMIT

[Andy Pont]

Fabio wrote...


$ /bin/sh --version
/bin/sh: 0: Illegal option --

In my system /bin/sh points to bash:
$ ls -al /bin/sh
lrwxrwxrwx 1 root root 4 mai  2  2018 /bin/sh -> dash
Just to pick up on the obvious… /bin/sh is showing as linked to dash not 
bash!


Using (( … )) for arithmetic expansion is a bashism [1]

[1] https://wiki.ubuntu.com/DashAsBinSh

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

Re: [U-Boot] [PATCH v1] fs: fat: dynamically allocate memory for temporary buffer

[Lukasz Majewski]

On Thu,  6 Dec 2018 14:58:52 +0100
Stefan Agner  wrote:

> From: Stefan Agner 
> 
> Drop the statically allocated get_contents_vfatname_block and
> dynamically allocate a buffer only if required. This saves
> 64KiB of memory.
> 
> Signed-off-by: Stefan Agner 
> ---
> 
>  fs/fat/fat.c | 20 ++--
>  1 file changed, 14 insertions(+), 6 deletions(-)
> 
> diff --git a/fs/fat/fat.c b/fs/fat/fat.c
> index 4bc3030ab8..06bcd02835 100644
> --- a/fs/fat/fat.c
> +++ b/fs/fat/fat.c
> @@ -305,9 +305,6 @@ get_cluster(fsdata *mydata, __u32 clustnum, __u8
> *buffer, unsigned long size)
>   * into 'buffer'.
>   * Update the number of bytes read in *gotsize or return -1 on fatal
> errors. */
> -__u8 get_contents_vfatname_block[MAX_CLUSTSIZE]
> - __aligned(ARCH_DMA_MINALIGN);
> -
>  static int get_contents(fsdata *mydata, dir_entry *dentptr, loff_t
> pos, __u8 *buffer, loff_t maxsize, loff_t *gotsize)
>  {
> @@ -318,7 +315,7 @@ static int get_contents(fsdata *mydata, dir_entry
> *dentptr, loff_t pos, loff_t actsize;
>  
>   *gotsize = 0;
> - debug("Filesize: %llu bytes\n", filesize);
> + debug("Filesize: %llu bytes, starting at pos %llu\n",
> filesize, pos); 
>   if (pos >= filesize) {
>   debug("Read position past EOF: %llu\n", pos);
> @@ -350,15 +347,26 @@ static int get_contents(fsdata *mydata,
> dir_entry *dentptr, loff_t pos, 
>   /* align to beginning of next cluster if any */
>   if (pos) {
> + __u8 *tmp_buffer;
> +
> + tmp_buffer = malloc_cache_aligned(MAX_CLUSTSIZE);
> + if (tmp_buffer == NULL) {
> + debug("Error: allocating buffer\n");
> + return -1;
> + }
> +
>   actsize = min(filesize, (loff_t)bytesperclust);
> - if (get_cluster(mydata, curclust,
> get_contents_vfatname_block,
> + if (get_cluster(mydata, curclust, tmp_buffer,
>   (int)actsize) != 0) {
>   printf("Error reading cluster\n");
> + free(tmp_buffer);
>   return -1;
>   }
>   filesize -= actsize;
>   actsize -= pos;
> - memcpy(buffer, get_contents_vfatname_block + pos,
> actsize);
> + memcpy(tmp_buffer, buffer + pos, actsize);
> + free(tmp_buffer);
> +
>   *gotsize += actsize;
>   if (!filesize)
>   return 0;

Reviewed-by: Lukasz Majewski 


Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de


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

Re: [U-Boot] [PATCH v1] mtd: nand: raw: allow to disable unneeded ECC layouts

[Lukasz Majewski]

On Thu,  6 Dec 2018 14:57:09 +0100
Stefan Agner  wrote:

> From: Stefan Agner 
> 
> Each ECC layout consumes about 2984 bytes in the .data section. Allow
> to disable the default ECC layouts if a driver is known to provide its
> own ECC layout.
> 
> Signed-off-by: Stefan Agner 
> ---
> 
>  drivers/mtd/nand/raw/Kconfig | 7 +++
>  drivers/mtd/nand/raw/nand_base.c | 4 
>  2 files changed, 11 insertions(+)
> 
> diff --git a/drivers/mtd/nand/raw/Kconfig
> b/drivers/mtd/nand/raw/Kconfig index 008f7b4b4b..b06c45788a 100644
> --- a/drivers/mtd/nand/raw/Kconfig
> +++ b/drivers/mtd/nand/raw/Kconfig
> @@ -9,6 +9,12 @@ config SYS_NAND_SELF_INIT
> This option, if enabled, provides more flexible and
> linux-like NAND initialization process.
>  
> +config SYS_NAND_DRIVER_ECC_LAYOUT
> + bool
> + help
> +   Omit standard ECC layouts to safe space. Select this if
> your driver
> +   is known to provide its own ECC layout.
> +
>  config NAND_ATMEL
>   bool "Support Atmel NAND controller"
>   imply SYS_NAND_USE_FLASH_BBT
> @@ -81,6 +87,7 @@ config NAND_OMAP_ELM
>  config NAND_VF610_NFC
>   bool "Support for Freescale NFC for VF610"
>   select SYS_NAND_SELF_INIT
> + select SYS_NAND_DRIVER_ECC_LAYOUT
>   imply CMD_NAND
>   help
> Enables support for NAND Flash Controller on some Freescale
> diff --git a/drivers/mtd/nand/raw/nand_base.c
> b/drivers/mtd/nand/raw/nand_base.c index 92daebe120..6d2ff58d86 100644
> --- a/drivers/mtd/nand/raw/nand_base.c
> +++ b/drivers/mtd/nand/raw/nand_base.c
> @@ -47,6 +47,7 @@
>  #include 
>  
>  /* Define default oob placement schemes for large and small page
> devices */ +#ifdef CONFIG_SYS_NAND_DRIVER_ECC_LAYOUT
>  static struct nand_ecclayout nand_oob_8 = {
>   .eccbytes = 3,
>   .eccpos = {0, 1, 2},
> @@ -89,6 +90,7 @@ static struct nand_ecclayout nand_oob_128 = {
>   {.offset = 2,
>.length = 78} }
>  };
> +#endif
>  
>  static int nand_get_device(struct mtd_info *mtd, int new_state);
>  
> @@ -4339,6 +4341,7 @@ int nand_scan_tail(struct mtd_info *mtd)
>*/
>   if (!ecc->layout && (ecc->mode != NAND_ECC_SOFT_BCH)) {
>   switch (mtd->oobsize) {
> +#ifdef CONFIG_SYS_NAND_DRIVER_ECC_LAYOUT
>   case 8:
>   ecc->layout = &nand_oob_8;
>   break;
> @@ -4351,6 +4354,7 @@ int nand_scan_tail(struct mtd_info *mtd)
>   case 128:
>   ecc->layout = &nand_oob_128;
>   break;
> +#endif
>   default:
>   pr_warn("No oob scheme defined for oobsize
> %d\n", mtd->oobsize);

Reviewed-by: Lukasz Majewski 


Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de


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

Re: [U-Boot] [PATCH v1] board: toradex: colibri_vf: unset NFS and LOADS/B

[Lukasz Majewski]

On Thu,  6 Dec 2018 14:55:03 +0100
Stefan Agner  wrote:

> From: Stefan Agner 
> 
> Safe some space by not selecting CMD_NFS and CMD_LOADS/B.
> 
> Signed-off-by: Stefan Agner 
> ---
> 
>  configs/colibri_vf_defconfig | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/configs/colibri_vf_defconfig
> b/configs/colibri_vf_defconfig index fb0578868d..4192501257 100644
> --- a/configs/colibri_vf_defconfig
> +++ b/configs/colibri_vf_defconfig
> @@ -23,11 +23,14 @@ CONFIG_CMD_MEMTEST=y
>  CONFIG_CMD_DFU=y
>  CONFIG_CMD_FUSE=y
>  CONFIG_CMD_GPIO=y
> +# CONFIG_CMD_LOADB is not set
> +# CONFIG_CMD_LOADS is not set
>  CONFIG_CMD_MMC=y
>  CONFIG_CMD_USB=y
>  CONFIG_CMD_USB_MASS_STORAGE=y
>  # CONFIG_CMD_SETEXPR is not set
>  CONFIG_CMD_DHCP=y
> +# CONFIG_CMD_NFS is not set
>  CONFIG_CMD_MII=y
>  CONFIG_CMD_PING=y
>  CONFIG_CMD_BMP=y

Reviewed-by: Lukasz Majewski 


Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de


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

Re: [U-Boot] [PATCH v1] tools: logos: crop Toradex logo slightly

[Lukasz Majewski]

On Thu,  6 Dec 2018 14:53:02 +0100
Stefan Agner  wrote:

> From: Stefan Agner 
> 
> The current bitmap is a bit larger than necessary, it has a black
> border around the Toradex logo. Crop the logo slightly which safes
> some space, useful especially on Colibri VFxx.
> 
> Signed-off-by: Stefan Agner 
> ---
> 
>  tools/logos/toradex.bmp | Bin 24982 -> 23298 bytes
>  1 file changed, 0 insertions(+), 0 deletions(-)
> 
> diff --git a/tools/logos/toradex.bmp b/tools/logos/toradex.bmp
> index
> 3e2dcf23358dd46fc7b1bb0dae70d3ba985606ee..8b5cb18e8475b3eda72c9f0e821b2aad17bc1bae
> 100644 GIT binary patch delta 505
> zcmYLEO-oxr6rCd>(HDKjZ>@>Jpis10rD|SMpO}a~;ztZ>#n#YvXDMP^LN{G@Ros~Y
> z7ZzGv2rXT;2fM2V{0-tp-MG+&1*NzVD!qwH2j zqA&|eIdVc37wR8om8$e!Zz<*l6?djGE9YG(S~;)!9=&quRG=vfFLUm4-15@m|9r0G
> zmizeCFm60Pec_#Ey3_){ltsV`(*{R;a?MtR!GlVHyVU}jnm+JXtq3Lc0*@L5*6#@X
> zZWM?FBG5Uvi_1-;;7M@9V643tT)ro*yB*RRyf5r!m%wIs7(X6Z&}P4>2dpwK^!TCA
> z#vApR)u#7*|L~|!Y@L=^>|}#ZB|Th=)POrtDVzOa=q< zTCNWr4?o94(4CgaqoH;%G%TNcHS!SLa%5g3A@fQ&UylZ%jYNRCF+X@VE-pJ+(CWB8
> zDGB)@pZ0ionrZ=CrbK@;9R;^%B+8u4K>wYo&*H6Kdi+g)O1ODE*9`if$Qv)_#k`r8  
> Tu-(CC?xpL%4;b52`
> 
> delta 656
> zcmXw!ODIHP6vw|?uE!njFhgTzOi3nYyasb;yv8sxo^!iK9tlwv3RzGrG(|QZDZa9j
> zB?~JZ+1My$i;az@WKD$CWZ~X(xb^k>&j0++`QLBjQaHR3{E^tlYa7
> z)+w+|)TbsGvzX}UqTV=PO%wUG_^qEgSQ8tBeJ!7_i5^I%n~giXW{@^6RYN>W!v46l  
> zZnTmTwxA%p5v^)Y2)QGZeq#<|oysNFT8OjO0P4s2 zf{70}efyfocU>k(xMn2%=P%%;Ou?--52dJHO4+QS`l^!nSw-~J;C6l%lwr~5F=qKz  
> zmy?(Jy*yd_Wjye{4y`=ZDsxrI1-IXU5n+X*mIJivEJ(i7hzuVMUi3JcX#IAJ8&;aF
> zsBO3WN1EXwgprVHrN`B`5$D^R(R&&puNHN|Pe+lV@v!3JlZpi4&OG#JQJUH6Lh5}x
> zJarfUd2L|nEy26~M84?DfS$fmoLlIpxszBE*3T+sI<+ON_XaQ WVdOzbgrkvqwA_u-FJz9T1ojITOUl0h
> 

Reviewed-by: Lukasz Majewski 


Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de


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

Re: [U-Boot] [U-Boot, v3, 4/4] rockchip: rk3399: Add Ficus EE board support

[Philipp Tomsich]

Ezequiel,

> On 04.12.2018, at 23:02, Ezequiel Garcia  wrote:
> 
> On Tue, 2018-12-04 at 22:21 +0100, Philipp Tomsich wrote:
>> Peter (Robinson) already asked: I had lost this series one during a rebase 
>> screw-up
>> and will send out the PR as soon as it’s through Travis-CI.
>> 
> 
> Thanks for the quick reply.
> 
> Should you need anything from me or Mani, please let us know.

After sorting my git tree out, this is now waiting for a USB fix to be either 
waved
through by Marek (so I can apply it) or being applied by Marek.
The series does not pass Travis without this (and I darkly remember that I ran 
into
the same issue about 5 weeks back)…

It’s on u-boot-rockchip/master (together with the USB change), but I can’t send 
out 
the PR until the USB side is sorted.

Cheers,
Philipp.

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

Re: [U-Boot] [PATCH] Enable expression support for CONFIG_BOARD_SIZE_LIMIT

[Fabio Estevam]

Hi Wolfgang,

On Thu, Dec 6, 2018 at 12:23 PM Wolfgang Denk  wrote:

> This makes really no sense to me.  Can you please send me (off list)
> a git diff of the tree that is not building for you against the
> nearest mainline commit?

I am running top of tree mainline U-Boot + your patch from this thread, plus:

--- a/include/configs/pico-imx7d.h
+++ b/include/configs/pico-imx7d.h
@@ -134,7 +134,8 @@
 /* FLASH and environment organization */
 #define CONFIG_ENV_SIZESZ_8K

-#define CONFIG_ENV_OFFSET  (8 * SZ_64K)
+#define CONFIG_ENV_OFFSET  (768 * 1024)
+#define CONFIG_BOARD_SIZE_LIMIT(1 * 1024)
 #define CONFIG_SYS_FSL_USDHC_NUM   2

 #define CONFIG_SYS_MMC_ENV_DEV 0

It does build fine, but as I have intentionally forced a small
CONFIG_BOARD_SIZE_LIMIT  I wanted it to fail, but it does not fail as
shown below:

  OBJCOPY u-boot-nodtb.bin
/bin/sh: 1: arithmetic expression: expecting primary: ""(1 * 1024)""
  SYM u-boot.sym
  COPYu-boot.bin
  MKIMAGE u-boot.img
= WARNING ==
This board does not use CONFIG_DM_MMC. Please update
the board to use CONFIG_DM_MMC before the v2019.04 release.
Failure to update by the deadline may result in board removal.
See doc/driver-model/MIGRATION.txt for more info.

= WARNING ==
This board does not use CONFIG_DM_USB. Please update
the board to use CONFIG_DM_USB before the v2019.07 release.
Failure to update by the deadline may result in board removal.
See doc/driver-model/MIGRATION.txt for more info.

  CFGCHK  u-boot.cfg

As you can see there are two issues:

1. The warnin: /bin/sh: 1: arithmetic expression: expecting primary:
""(1 * 1024)""

2. It should have not built in this case. It should have detected the
overlap and signalized the error

> And please also the output of /"bin/sh --version".

$ /bin/sh --version
/bin/sh: 0: Illegal option --

In my system /bin/sh points to bash:
$ ls -al /bin/sh
lrwxrwxrwx 1 root root 4 mai  2  2018 /bin/sh -> dash

/bin/bash --version
GNU bash, version 4.4.19(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

I am able to reproduce this problem with a standalone script:

$ cat random.sh
#!/bin/bash
echo $(($RANDOM % 10))
$ ./random.sh
3

Worked fine with bash.

Now if I force it to dash:

$ cat random.sh
#!/bin/dash
echo $(($RANDOM % 10))
$ ./random.sh
./random.sh: 2: ./random.sh: arithmetic expression: expecting primary: " % 10"

Which is the same warning I get in U-Boot.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 05/19] riscv: Add a SYSCON driver for Core Local Interruptor

[Philipp Tomsich]

> On 13.11.2018, at 09:21, Bin Meng  wrote:
> 
> This adds U-Boot syscon driver for RISC-V Core Local Interruptor
> (CLINT). The CLINT block holds memory-mapped control and status
> registers associated with software and timer interrupts.
> 
> 3 APIs are provided for U-Boot to implement Supervisor Binary
> Interface (SBI) as defined by the RISC-V privileged architecture
> spec v1.10.
> 
> Signed-off-by: Bin Meng 
> ---
> 
> arch/riscv/Kconfig |  8 +
> arch/riscv/include/asm/clint.h | 24 +++
> arch/riscv/lib/Makefile|  1 +
> arch/riscv/lib/clint.c | 69 ++
> 4 files changed, 102 insertions(+)
> create mode 100644 arch/riscv/include/asm/clint.h
> create mode 100644 arch/riscv/lib/clint.c
> 
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index a37e895..abfc083 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -73,4 +73,12 @@ config 32BIT
> config 64BIT
>   bool
> 
> +config RISCV_CLINT
> + bool "Support Core Local Interruptor (CLINT)"
> + select REGMAP
> + select SYSCON
> + help
> +   The CLINT block holds memory-mapped control and status registers
> +   associated with software and timer interrupts.
> +
> endmenu
> diff --git a/arch/riscv/include/asm/clint.h b/arch/riscv/include/asm/clint.h
> new file mode 100644
> index 000..1c6024f
> --- /dev/null
> +++ b/arch/riscv/include/asm/clint.h
> @@ -0,0 +1,24 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright (C) 2018, Bin Meng 
> + */
> +
> +#ifndef _ASM_RISCV_CLINT_H
> +#define _ASM_RISCV_CLINT_H
> +
> +/*
> + * System controllers in a RISC-V system
> + *
> + * So far only Core Local Interruptor (CLINT) is defined. If new system
> + * controller is added, we may need move the defines to somewhere else.
> + */
> +enum {
> + RISCV_NONE,
> + RISCV_SYSCON_CLINT, /* Core Local Interruptor (CLINT) */
> +};
> +
> +void riscv_send_ipi(int hart);
> +void riscv_set_timecmp(int hart, u64 cmp);
> +u64 riscv_get_time(void);
> +
> +#endif /* _ASM_RISCV_CLINT_H */
> diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile
> index b58db89..b5a77c2 100644
> --- a/arch/riscv/lib/Makefile
> +++ b/arch/riscv/lib/Makefile
> @@ -9,6 +9,7 @@
> obj-$(CONFIG_CMD_BOOTM) += bootm.o
> obj-$(CONFIG_CMD_GO) += boot.o
> obj-y += cache.o
> +obj-$(CONFIG_RISCV_CLINT) += clint.o
> obj-y += interrupts.o
> obj-y += reset.o
> obj-y   += setjmp.o
> diff --git a/arch/riscv/lib/clint.c b/arch/riscv/lib/clint.c
> new file mode 100644
> index 000..369aa1d
> --- /dev/null
> +++ b/arch/riscv/lib/clint.c
> @@ -0,0 +1,69 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2018, Bin Meng 
> + *
> + * U-Boot syscon driver for RISC-V Core Local Interruptor (CLINT)
> + * The CLINT block holds memory-mapped control and status registers
> + * associated with software and timer interrupts.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* MSIP registers */
> +#define MSIP_REG(base, hart) ((ulong)(base) + (hart) * 4)
> +/* Timer compare register */
> +#define MTIMECMP_REG(base, hart) ((ulong)(base) + 0x4000 + (hart) * 8)
> +/* Timer register */
> +#define MTIME_REG(base)  ((ulong)(base) + 0xbff8)
> +
> +static void __iomem *clint_base;
> +
> +/*
> + * The following 3 APIs are used to implement Supervisor Binary Interface 
> (SBI)
> + * as defined by the RISC-V privileged architecture spec v1.10.
> + *
> + * For performance reasons we don't want to get the CLINT register base via
> + * syscon_get_first_range() each time we enter in those functions, instead
> + * the base address was saved to a global variable during the clint driver
> + * probe phase, so that we can use it directly.
> + */
> +
> +void riscv_send_ipi(int hart)
> +{
> + writel(1, (void __iomem *)MSIP_REG(clint_base, hart));
> +}
> +
> +void riscv_set_timecmp(int hart, u64 cmp)
> +{
> + writeq(cmp, (void __iomem *)MTIMECMP_REG(clint_base, hart));
> +}
> +
> +u64 riscv_get_time(void)
> +{
> + return readq((void __iomem *)MTIME_REG(clint_base));
> +}
> +
> +static int clint_probe(struct udevice *dev)
> +{
> + clint_base = syscon_get_first_range(RISCV_SYSCON_CLINT);
> +
> + return 0;
> +}
> +
> +static const struct udevice_id clint_ids[] = {
> + { .compatible = "riscv,clint0", .data = RISCV_SYSCON_CLINT },
> + { }
> +};
> +
> +U_BOOT_DRIVER(riscv_clint) = {
> + .name   = "riscv_clint",
> + .id = UCLASS_SYSCON,

Wouldn’t a separate UCLASS be more appropriate?

> + .of_match   = clint_ids,
> + .probe  = clint_probe,
> + .flags  = DM_FLAG_PRE_RELOC,
> +};
> -- 
> 2.7.4
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot

___
U-Boot mailing list
U-Boot@lists.denx.de
http

Re: [U-Boot] [PATCH] Enable expression support for CONFIG_BOARD_SIZE_LIMIT

[Wolfgang Denk]

Dear Fabio,

In message  
you wrote:
>
> Previously I tested on a machine running Ubuntu 16.04 and today I also
> tested on another machine running Ubuntu 18.04.
>
> The results are the same on both machines:
>
> 1.  I get a "expecting primary" warning:
>
>  OBJCOPY u-boot-nodtb.bin
> /bin/sh: 1: arithmetic expression: expecting primary: ""(1 * 1024)""

This makes really no sense to me.  Can you please send me (off list)
a git diff of the tree that is not building for you against the
nearest mainline commit?

And please also the output of /"bin/sh --version".

I have:

-> /bin/sh --version
GNU bash, version 4.4.23(1)-release (x86_64-redhat-linux-gnu)
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.


[Sorry, can't test build under Ubuntu ATM; our container gives
strange errors, and I have to wait until tomorrow as I don't want to
mess with the setup.]

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
When some people discover the truth, they just can't  understand  why
everybody isn't eager to hear it.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Please pull u-boot-dm

[Tom Rini]

On Wed, Dec 05, 2018 at 06:30:48PM -0700, Simon Glass wrote:

> Hi Tom,
> 
> The following changes since commit 2e2a2a5d4f0c2e2642326d9000ce1f1553632e6a:
> 
>   Merge branch 'master' of git://git.denx.de/u-boot-sh (2018-12-04
> 19:22:31 -0500)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-dm.git tags/dm-pull-5dec18
> 
> for you to fetch changes up to b288cd9600724ad3a0e55c8786e70741dd13deae:
> 
>   x86: acpi: Generate SPCR table (2018-12-05 07:23:16 -0700)
> 
> 
> Travis here
> 
> https://travis-ci.org/sglass68/u-boot/builds/463866708
> 
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

[U-Boot] [PATCH v1] fs: fat: dynamically allocate memory for temporary buffer

[Stefan Agner]

From: Stefan Agner 

Drop the statically allocated get_contents_vfatname_block and
dynamically allocate a buffer only if required. This saves
64KiB of memory.

Signed-off-by: Stefan Agner 
---

 fs/fat/fat.c | 20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index 4bc3030ab8..06bcd02835 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -305,9 +305,6 @@ get_cluster(fsdata *mydata, __u32 clustnum, __u8 *buffer, 
unsigned long size)
  * into 'buffer'.
  * Update the number of bytes read in *gotsize or return -1 on fatal errors.
  */
-__u8 get_contents_vfatname_block[MAX_CLUSTSIZE]
-   __aligned(ARCH_DMA_MINALIGN);
-
 static int get_contents(fsdata *mydata, dir_entry *dentptr, loff_t pos,
__u8 *buffer, loff_t maxsize, loff_t *gotsize)
 {
@@ -318,7 +315,7 @@ static int get_contents(fsdata *mydata, dir_entry *dentptr, 
loff_t pos,
loff_t actsize;
 
*gotsize = 0;
-   debug("Filesize: %llu bytes\n", filesize);
+   debug("Filesize: %llu bytes, starting at pos %llu\n", filesize, pos);
 
if (pos >= filesize) {
debug("Read position past EOF: %llu\n", pos);
@@ -350,15 +347,26 @@ static int get_contents(fsdata *mydata, dir_entry 
*dentptr, loff_t pos,
 
/* align to beginning of next cluster if any */
if (pos) {
+   __u8 *tmp_buffer;
+
+   tmp_buffer = malloc_cache_aligned(MAX_CLUSTSIZE);
+   if (tmp_buffer == NULL) {
+   debug("Error: allocating buffer\n");
+   return -1;
+   }
+
actsize = min(filesize, (loff_t)bytesperclust);
-   if (get_cluster(mydata, curclust, get_contents_vfatname_block,
+   if (get_cluster(mydata, curclust, tmp_buffer,
(int)actsize) != 0) {
printf("Error reading cluster\n");
+   free(tmp_buffer);
return -1;
}
filesize -= actsize;
actsize -= pos;
-   memcpy(buffer, get_contents_vfatname_block + pos, actsize);
+   memcpy(tmp_buffer, buffer + pos, actsize);
+   free(tmp_buffer);
+
*gotsize += actsize;
if (!filesize)
return 0;
-- 
2.19.2

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

[U-Boot] [PATCH v1] mtd: nand: raw: allow to disable unneeded ECC layouts

[Stefan Agner]

From: Stefan Agner 

Each ECC layout consumes about 2984 bytes in the .data section. Allow
to disable the default ECC layouts if a driver is known to provide its
own ECC layout.

Signed-off-by: Stefan Agner 
---

 drivers/mtd/nand/raw/Kconfig | 7 +++
 drivers/mtd/nand/raw/nand_base.c | 4 
 2 files changed, 11 insertions(+)

diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
index 008f7b4b4b..b06c45788a 100644
--- a/drivers/mtd/nand/raw/Kconfig
+++ b/drivers/mtd/nand/raw/Kconfig
@@ -9,6 +9,12 @@ config SYS_NAND_SELF_INIT
  This option, if enabled, provides more flexible and linux-like
  NAND initialization process.
 
+config SYS_NAND_DRIVER_ECC_LAYOUT
+   bool
+   help
+ Omit standard ECC layouts to safe space. Select this if your driver
+ is known to provide its own ECC layout.
+
 config NAND_ATMEL
bool "Support Atmel NAND controller"
imply SYS_NAND_USE_FLASH_BBT
@@ -81,6 +87,7 @@ config NAND_OMAP_ELM
 config NAND_VF610_NFC
bool "Support for Freescale NFC for VF610"
select SYS_NAND_SELF_INIT
+   select SYS_NAND_DRIVER_ECC_LAYOUT
imply CMD_NAND
help
  Enables support for NAND Flash Controller on some Freescale
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 92daebe120..6d2ff58d86 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -47,6 +47,7 @@
 #include 
 
 /* Define default oob placement schemes for large and small page devices */
+#ifdef CONFIG_SYS_NAND_DRIVER_ECC_LAYOUT
 static struct nand_ecclayout nand_oob_8 = {
.eccbytes = 3,
.eccpos = {0, 1, 2},
@@ -89,6 +90,7 @@ static struct nand_ecclayout nand_oob_128 = {
{.offset = 2,
 .length = 78} }
 };
+#endif
 
 static int nand_get_device(struct mtd_info *mtd, int new_state);
 
@@ -4339,6 +4341,7 @@ int nand_scan_tail(struct mtd_info *mtd)
 */
if (!ecc->layout && (ecc->mode != NAND_ECC_SOFT_BCH)) {
switch (mtd->oobsize) {
+#ifdef CONFIG_SYS_NAND_DRIVER_ECC_LAYOUT
case 8:
ecc->layout = &nand_oob_8;
break;
@@ -4351,6 +4354,7 @@ int nand_scan_tail(struct mtd_info *mtd)
case 128:
ecc->layout = &nand_oob_128;
break;
+#endif
default:
pr_warn("No oob scheme defined for oobsize %d\n",
   mtd->oobsize);
-- 
2.19.2

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

[U-Boot] [PATCH v1] board: toradex: colibri_vf: unset NFS and LOADS/B

[Stefan Agner]

From: Stefan Agner 

Safe some space by not selecting CMD_NFS and CMD_LOADS/B.

Signed-off-by: Stefan Agner 
---

 configs/colibri_vf_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/configs/colibri_vf_defconfig b/configs/colibri_vf_defconfig
index fb0578868d..4192501257 100644
--- a/configs/colibri_vf_defconfig
+++ b/configs/colibri_vf_defconfig
@@ -23,11 +23,14 @@ CONFIG_CMD_MEMTEST=y
 CONFIG_CMD_DFU=y
 CONFIG_CMD_FUSE=y
 CONFIG_CMD_GPIO=y
+# CONFIG_CMD_LOADB is not set
+# CONFIG_CMD_LOADS is not set
 CONFIG_CMD_MMC=y
 CONFIG_CMD_USB=y
 CONFIG_CMD_USB_MASS_STORAGE=y
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_CMD_DHCP=y
+# CONFIG_CMD_NFS is not set
 CONFIG_CMD_MII=y
 CONFIG_CMD_PING=y
 CONFIG_CMD_BMP=y
-- 
2.19.2

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

Re: [U-Boot] [RFC PATCH v2 00/11] SF: Migrate to Linux SPI NOR framework

[Simon Goldschmidt]

On Thu, Dec 6, 2018 at 2:45 PM Vignesh R  wrote:
>
> Hi Simon,
>
> On 06/12/18 2:15 AM, Simon Goldschmidt wrote:
> > Am 05.12.2018 um 07:55 schrieb Simon Goldschmidt:
> >> On Wed, Dec 5, 2018 at 7:51 AM Vignesh R  wrote:
> [...]
>  I did some compilation tests first and I'm happy to say that with the
>  SPL_SPI_FLASH_TINY option enabled, my SPL is about 1900 byte smaller
>  than before :-)
> 
>  However, my socfpga socrates board does not boot. I'll have to
>  investigate why. I just applied this series and compiled for
>  socfpga_socrates_defconfig. Is there anything else I should have changed
>  to make it work?
> 
> >>>
> >>> Oops, that's unfortunate.
> >>> Just to be sure, does SPL fail to come up or SPL fails to load U-Boot
> >>> from flash? Is this with SPL_SPI_FLASH_TINY enabled?
> >>
> >> I tried both TINY and standard. Both are failing to load U-Boot (I get
> >> the standard error message that loading from SPI flash failed).
> >>
> >>> Could you enable debug prints at the end of spi_mem_exec_op() in
> >>> drivers/spi/spi-mem.c to see what commands are sent and their responses?
> >>
> >> OK, I'll do that.
> >>
> >>> I have TI EVM with Cadence QSPI(like SoCFPGA) but with a Spansion flash
> >>> and that seems to work fine with both full and tiny stack.
> >
> > OK, so I enabled some debugging and the first issue is that U-Boot has
> > SNOR_MFR_MICRON and SNOR_MFR_ST while Linux only has SNOR_MFR_MICRON but
> > defines it to CFI_MFR_ST (0x20, U-Boot ends up with 0x2c). While this
> > might be correct, it leads to my n25q256a not being handled as
> > "micron-like" and the code falls through to using Spansion-like opcode
> > (0x17) that my chip does not understand.
> >
>
> Oops, sorry, the micron chip I had has CFI MFR id of 0x2c, so I
> overlooked this. I have updated this now.
>
> > However, after changing this (and using opcode 0xb7 to bring the chip
> > into 4 byte mode, including 0x06 for write-enable), it still does not
> > work as it uses the 'READ' opcode 0x03 instead of the 'FAST READ' opcode
> > 0x0b that U-Boot used until now. The problem here might be that 'READ'
> > cannot do Quad-SPI (4-4-4) and I'm not sure the Cadence driver can
> > handle Extended-SPI (1-1-1) that the 'READ' command is limited to...
> >
>
> I had accidentally dropped Fast Read from SPI NOR layer and have sync'd
> it up now.  I see that in socfpga dts, flash does not contain:
> spi-rx-bus-width = <4>;

We can add that if it helps. I'll try to update the upstream Linux dts
anyway to add "jeded,spi-nor" compatible once Neil's series is
applied.

> Therefore SPI NOR layer falls back to READ (even though its a QSPI
> flash). But nevertheless with updated branch[1] you should see falling
> back to FAST READ with Cadence QSPI on your board (and 1-1-4, if rx bus
> width is 4).
>
> > Using SFDP would probably help, but that doesn't compile (as I wrote in
> > the other thread).
> >
>
> Sorry for that. I have fixed that up and tested SFDP parsing logic with
> a Spansion flash. Note that Cadence QSPI wont support SFDP parsing as
> driver enables Quad mode for all reads and SFDP is only 1-1-1.

Oh, I haven't really looked into that yet. That's sad.

>
> > On the other hand, enabling SFDP will increase the text/rodata size for
> > SPL. We might need to remove the non-SFDP and write code as a counter
> > measure to prevent increasing code size.
> >
>
> That's not an option as Flash devices (even though have same JEDEC ID)
> manufactured before JESD216 std dont have SFDP populated. So, we will
> need to have both non-SFDP and SFDP support with option to disable SFDP
> (for size and boot time optimizations).

Well, my idea was if you'd know that all the flash chips on your board
supported it, you'd be safe. It would only be a Kconfig option to
reduce binary size (get rid of the flash IDs table).

But if SFDP doesn't work for QSPI anyway, that's not the best idea, I guess...

> Thanks for all the debugging! It would be great if you could try below
> branch and let me know if it fixes all the issues.
> If yes, I will remove RFC and post new series.

Sure, I'll try to find the time soon.

Regards,
Simon

>
> [1] https://github.com/r-vignesh/u-boot.git spi-nor-mig-patch-v1
>
> --
> Regards
> Vignesh
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v1] tools: logos: crop Toradex logo slightly

[Stefan Agner]

From: Stefan Agner 

The current bitmap is a bit larger than necessary, it has a black
border around the Toradex logo. Crop the logo slightly which safes
some space, useful especially on Colibri VFxx.

Signed-off-by: Stefan Agner 
---

 tools/logos/toradex.bmp | Bin 24982 -> 23298 bytes
 1 file changed, 0 insertions(+), 0 deletions(-)

diff --git a/tools/logos/toradex.bmp b/tools/logos/toradex.bmp
index 
3e2dcf23358dd46fc7b1bb0dae70d3ba985606ee..8b5cb18e8475b3eda72c9f0e821b2aad17bc1bae
 100644
GIT binary patch
delta 505
zcmYLEO-oxr6rCd>(HDKjZ>@>Jpis10rD|SMpO}a~;ztZ>#n#YvXDMP^LN{G@Ros~Y
z7ZzGv2rXT;2fM2V{0-tp-MG+&1*NzVD!qwH2j2dpwK^!TCA
z#vApR)u#7*|L~|!Y@L=^>|}#ZB|Th=)POrtDVzOa=q&j0++`QLBjQaHR3{E^tlYa7
z)+w+|)TbsGvzX}UqTV=PO%wUG_^qEgSQ8tBeJ!7_i5^I%n~giXW{@^6RYN>W!v46l
zZnTmTwxA%p5v^)Y2)QGZeq#<|oysNFT8OjO0P4s2k(xMn2%=P%%;Ou?--52dJHO4+QS`l^!nSw-~J;C6l%lwr~5F=qKz
zmy?(Jy*yd_Wjye{4y`=ZDsxrI1-IXU5n+X*mIJivEJ(i7hzuVMUi3JcX#IAJ8&;aF
zsBO3WN1EXwgprVHrN`B`5$D^R(R&&puNHN|Pe+lV@v!3JlZpi4&OG#JQJUH6Lh5}x
zJarfUd2L|nEy26~M84?DfS$fmoLlIpxszBE*3T+sI<+ON_XaQhttps://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2] rockchip: rk3288-evb: dts: remove 'vmmc' from emmc node

[Philipp Tomsich]

+Tom

> On 05.12.2018, at 03:25, Kever Yang  wrote:
> 
> The U-Boot eMMC does not need to care about the power for Rockchip
> SoC, because if the board is using eMMC, the power will default on
> (for bootrom), and we do not do power management for it like kernel,
> so the 'vmmc', 'vqmmc' is only useful for SD in U-Boot.
> 
> This make U-Boot can boot into kernel even if the pmic driver is
> broken.

If the PMIC driver is broken, we should fix the PMIC driver.
I would feel more comfortable w/o this statement.

> The rk3288-evb dts may be used in many boards using rockchip reference
> schematic but with little change, so we hope it can be more robust to
> boot into next stage.

Again, this is not how the DTS should be used.  I believe that Heiko, Fabio and
I had already highlighted this in comments to the earlier thread.

I am willing to move ahead with these and simply merge them, if either Tom or
Simon agree that they are fine with a DTS that describes one board and is then
used for incompatible (if they were compatible, this change wasn’t needed)
boards...

> Signed-off-by: Kever Yang 

Reviewed-by: Philipp Tomsich 

> ---
> 
> Changes in v2:
> - only update for rk3288-evb, remove change for other boards.
> 
> arch/arm/dts/rk3288-evb.dtsi | 2 --
> 1 file changed, 2 deletions(-)
> 
> diff --git a/arch/arm/dts/rk3288-evb.dtsi b/arch/arm/dts/rk3288-evb.dtsi
> index ce75bd5d28..04902c0bd3 100644
> --- a/arch/arm/dts/rk3288-evb.dtsi
> +++ b/arch/arm/dts/rk3288-evb.dtsi
> @@ -150,8 +150,6 @@
>   num-slots = <1>;
>   pinctrl-names = "default";
>   pinctrl-0 = <&emmc_clk>, <&emmc_cmd>, <&emmc_pwr>, <&emmc_bus8>;
> - vmmc-supply = <&vcc_io>;
> - vqmmc-supply = <&vcc_flash>;
>   status = "okay";
> };
> 
> -- 
> 2.18.0
> 

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

Re: [U-Boot] [PATCH] ARM: rockchip: rv1108: Fix booting with initramfs

[Philipp Tomsich]

> On 04.12.2018, at 14:49, Otavio Salvador  wrote:
> 
> We move the ramdisk_addr_r to 0x6800 and disable the initrd and
> fdt relocation, so the initramfs works out of box.
> 
> Signed-off-by: Otavio Salvador 

Reviewed-by: Philipp Tomsich 

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

Re: [U-Boot] [RFC PATCH v2 00/11] SF: Migrate to Linux SPI NOR framework

[Vignesh R]

Hi Simon,

On 06/12/18 2:15 AM, Simon Goldschmidt wrote:
> Am 05.12.2018 um 07:55 schrieb Simon Goldschmidt:
>> On Wed, Dec 5, 2018 at 7:51 AM Vignesh R  wrote:
[...]
 I did some compilation tests first and I'm happy to say that with the
 SPL_SPI_FLASH_TINY option enabled, my SPL is about 1900 byte smaller
 than before :-)

 However, my socfpga socrates board does not boot. I'll have to
 investigate why. I just applied this series and compiled for
 socfpga_socrates_defconfig. Is there anything else I should have changed
 to make it work?

>>>
>>> Oops, that's unfortunate.
>>> Just to be sure, does SPL fail to come up or SPL fails to load U-Boot
>>> from flash? Is this with SPL_SPI_FLASH_TINY enabled?
>>
>> I tried both TINY and standard. Both are failing to load U-Boot (I get
>> the standard error message that loading from SPI flash failed).
>>
>>> Could you enable debug prints at the end of spi_mem_exec_op() in
>>> drivers/spi/spi-mem.c to see what commands are sent and their responses?
>>
>> OK, I'll do that.
>>
>>> I have TI EVM with Cadence QSPI(like SoCFPGA) but with a Spansion flash
>>> and that seems to work fine with both full and tiny stack.
> 
> OK, so I enabled some debugging and the first issue is that U-Boot has 
> SNOR_MFR_MICRON and SNOR_MFR_ST while Linux only has SNOR_MFR_MICRON but 
> defines it to CFI_MFR_ST (0x20, U-Boot ends up with 0x2c). While this 
> might be correct, it leads to my n25q256a not being handled as 
> "micron-like" and the code falls through to using Spansion-like opcode 
> (0x17) that my chip does not understand.
> 

Oops, sorry, the micron chip I had has CFI MFR id of 0x2c, so I
overlooked this. I have updated this now.

> However, after changing this (and using opcode 0xb7 to bring the chip 
> into 4 byte mode, including 0x06 for write-enable), it still does not 
> work as it uses the 'READ' opcode 0x03 instead of the 'FAST READ' opcode 
> 0x0b that U-Boot used until now. The problem here might be that 'READ' 
> cannot do Quad-SPI (4-4-4) and I'm not sure the Cadence driver can 
> handle Extended-SPI (1-1-1) that the 'READ' command is limited to...
> 

I had accidentally dropped Fast Read from SPI NOR layer and have sync'd
it up now.  I see that in socfpga dts, flash does not contain:
spi-rx-bus-width = <4>;
Therefore SPI NOR layer falls back to READ (even though its a QSPI
flash). But nevertheless with updated branch[1] you should see falling
back to FAST READ with Cadence QSPI on your board (and 1-1-4, if rx bus
width is 4).

> Using SFDP would probably help, but that doesn't compile (as I wrote in 
> the other thread).
> 

Sorry for that. I have fixed that up and tested SFDP parsing logic with
a Spansion flash. Note that Cadence QSPI wont support SFDP parsing as
driver enables Quad mode for all reads and SFDP is only 1-1-1.

> On the other hand, enabling SFDP will increase the text/rodata size for 
> SPL. We might need to remove the non-SFDP and write code as a counter 
> measure to prevent increasing code size.
> 

That's not an option as Flash devices (even though have same JEDEC ID)
manufactured before JESD216 std dont have SFDP populated. So, we will
need to have both non-SFDP and SFDP support with option to disable SFDP
(for size and boot time optimizations).

Thanks for all the debugging! It would be great if you could try below
branch and let me know if it fixes all the issues.
If yes, I will remove RFC and post new series.

[1] https://github.com/r-vignesh/u-boot.git spi-nor-mig-patch-v1

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

Re: [U-Boot] [PATCH 3/4] rockchip: defconfig: puma-rk3399: enable PWM regulator

[Philipp Tomsich]

> On 06.12.2018, at 12:25, Christoph Muellner 
>  wrote:
> 
> Signed-off-by: Christoph Muellner 

You are missing a commit message.
Please revise.

> ---
> configs/puma-rk3399_defconfig | 1 +
> 1 file changed, 1 insertion(+)
> 
> diff --git a/configs/puma-rk3399_defconfig b/configs/puma-rk3399_defconfig
> index 8e33e09cee8..d23cf4bc523 100644
> --- a/configs/puma-rk3399_defconfig
> +++ b/configs/puma-rk3399_defconfig
> @@ -78,6 +78,7 @@ CONFIG_PINCTRL_ROCKCHIP_RK3399=y
> CONFIG_DM_PMIC=y
> CONFIG_PMIC_RK8XX=y
> CONFIG_SPL_DM_REGULATOR=y
> +CONFIG_REGULATOR_PWM=y
> CONFIG_DM_REGULATOR_FIXED=y
> CONFIG_SPL_DM_REGULATOR_FIXED=y
> CONFIG_DM_REGULATOR_GPIO=y
> -- 
> 2.11.0
> 

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

Re: [U-Boot] [PATCH 4/4] rockchip: puma-rk3399: Enable vdd-log during bootup.

[Philipp Tomsich]

> On 06.12.2018, at 12:25, Christoph Muellner 
>  wrote:
> 
> On the RK3399-Q7 "Puma" module VDD_LOG is generated by an external
> regulator, which sets the voltage level to 900 mV, which is within
> the allowed range and which works quite fine.
> 
> However, in specific use-cases we need to adjust VDD_LOG to
> maintain stable operation or to reduce power consumption.
> This adjustment can be done via pwm2.
> 
> This patch allows to tune the VDD_LOG voltage level
> via DTS. To do so the following things are done:
> 
> * Setup pin muxing for PWM2 (based on DTS settings)
> * Turn on the vdd_log regulator (based on DTS settings)
> 
> Reported-by: Assaf Agmon 
> Signed-off-by: Philipp Tomsich 
> Signed-off-by: Christoph Muellner 

Reviewed-by: Philipp Tomsich 

See below for requested changes.

> ---
> board/theobroma-systems/puma_rk3399/puma-rk3399.c | 43 +++
> 1 file changed, 43 insertions(+)
> 
> diff --git a/board/theobroma-systems/puma_rk3399/puma-rk3399.c 
> b/board/theobroma-systems/puma_rk3399/puma-rk3399.c
> index 573e691457f..e2915fcca50 100644
> --- a/board/theobroma-systems/puma_rk3399/puma-rk3399.c
> +++ b/board/theobroma-systems/puma_rk3399/puma-rk3399.c
> @@ -23,10 +23,34 @@
> #include 
> #include 
> 
> +static int setup_pinctrl(void)

I’d prefer a forward-declaration and this further down, as I want to keep 
board_init()
up front.  Just a personal preference, but still ...

> +{
> + int ret;
> + struct udevice *pinctrl;
> +
> + ret = uclass_get_device(UCLASS_PINCTRL, 0, &pinctrl);
> + if (ret) {
> + debug("%s: Cannot find pinctrl device\n", __func__);

Please use pr_debug.

> + goto out;
> + }
> +
> + /* Enable pwm2 for vdd_log regulator. */
> + ret = pinctrl_request_noflags(pinctrl, PERIPH_ID_PWM2);
> + if (ret) {
> + printf("%s PWM2 pinctrl init fail!\n", __func__);

Don’t use printf here — either this is a pr_err or a pr_debug.

> + goto out;
> + }
> +
> +out:
> + return 0;
> +}
> +
> int board_init(void)
> {
>   int ret;
> 
> + setup_pinctrl();
> +
>   /*
>* We need to call into regulators_enable_boot_on() again, as the call
>* during SPL may have not included all regulators.
> @@ -35,6 +59,25 @@ int board_init(void)
>   if (ret)
>   debug("%s: Cannot enable boot on regulator\n", __func__);
> 
> + /*
> +  * vdd_log is ignored by regulators_enable_boot_on(), because
> +  * regulator-min-microvolt != regulator-max-microvolt.
> +  * Therefore we explicitly enable it here.
> +  */
> + struct udevice *regulator;
> + ret = regulator_get_by_platname("vdd_log", ®ulator);
> + if (ret) {
> + debug("%s Looking up regulator vdd-log failed!\n", __func__);
> + goto out;
> + }
> +
> + ret = regulator_set_enable(regulator, true);
>  +if (ret) {
> + debug("%s Enabling vdd-log failed!\n", __func__);
> + goto out;
> + }

Generally speaking: I would prefer a
if (ret == 0)
ret = regulator_set_enable(regulator, true);
if (ret)
pr_debug(…) 

However, this should be irrelevant anyway: why doesn’t 
ret = regulators_enable_boot_on(false); 
in board_init() suffice?

> +
> +out:
>   return 0;
> }
> 
> -- 
> 2.11.0
> 

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

Re: [U-Boot] [PATCH 2/4] power: regulator: Allow PWM regulator to be omitted from SPL.

[Philipp Tomsich]

On 06.12.2018, at 12:25, Christoph Muellner 
 wrote:
> 
> This patch allows to enable the PWM regulator driver
> independent for U-Boot and SPL.
> 
> Signed-off-by: Christoph Muellner 

Reviewed-by: Philipp Tomsich 

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

Re: [U-Boot] [PATCH 1/4] rockchip: rk3399-puma: Cleanup vdd_log node in puma DTSI.

[Philipp Tomsich]

Christoph,

> On 06.12.2018, at 12:25, Christoph Muellner 
>  wrote:
> 
> * Eliminate non-standard entries (rockchip,pwm_id and
>   rockchip,pwm_voltage).
> * Define target voltage level for vdd-log to 950 mV.

Could  you provide the necessary background in the commit message to
assert that the non-standard entries are indeed not needed and why you
want to set the voltage to 950mV?

In other words: a bit of motivation for this change would be appreciated.

> Signed-off-by: Christoph Muellner 
> ---
> arch/arm/dts/rk3399-puma.dtsi | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/arch/arm/dts/rk3399-puma.dtsi b/arch/arm/dts/rk3399-puma.dtsi
> index 11ffcb71778..2cac16e2ce7 100644
> --- a/arch/arm/dts/rk3399-puma.dtsi
> +++ b/arch/arm/dts/rk3399-puma.dtsi
> @@ -180,10 +180,7 @@
>   regulator-max-microvolt = <140>;
>   regulator-always-on;
>   regulator-boot-on;
> -
> - /* for rockchip boot on */
> - rockchip,pwm_id= <2>;
> - rockchip,pwm_voltage = <100>;
> + regulator-init-microvolt = <95>;
>   };
> };
> 
> -- 
> 2.11.0
> 

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

Re: [U-Boot] [PATCH] Enable expression support for CONFIG_BOARD_SIZE_LIMIT

[Fabio Estevam]

Hi Wolfgang,

On Wed, Dec 5, 2018 at 7:52 AM Wolfgang Denk  wrote:

> Please try it on the shell:
>
> -> echo $(( ((768 - 69) * 1024) ))
> 715776
> -> echo $(( (1 * 1024) ))
> 1024

This works fine.

> It does for me, if I set the limit low:
>
>   OBJCOPY spl/u-boot-spl-nodtb.bin
>   COPYspl/u-boot-spl.bin
>   CFGSspl/u-boot-spl.cfgout
>   MKIMAGE SPL
>   OBJCOPY u-boot.srec
>   OBJCOPY u-boot-nodtb.bin
> u-boot-nodtb.bin exceeds file size limit:
>   limit:  1024 bytes
>   actual: 480172 bytes
>   excess: 479148 bytes
> make: *** [Makefile:1071: u-boot-nodtb.bin] Error 1

Previously I tested on a machine running Ubuntu 16.04 and today I also
tested on another machine running Ubuntu 18.04.

The results are the same on both machines:

1.  I get a "expecting primary" warning:

 OBJCOPY u-boot-nodtb.bin
/bin/sh: 1: arithmetic expression: expecting primary: ""(1 * 1024)""
  SYM u-boot.sym
  COPYu-boot.bin
  MKIMAGE u-boot.img
  LD  spl/drivers/usb/host/built-in.o
  LD  spl/drivers/built-in.o
  LD  spl/u-boot-spl
  OBJCOPY spl/u-boot-spl-nodtb.bin
  COPYspl/u-boot-spl.bin
  CFGSspl/u-boot-spl.cfgout
  MKIMAGE SPL

2. The overlap is not detected anymore. In the example below I forced
#define CONFIG_BOARD_SIZE_LIMIT(1 * 1024)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 05/19] riscv: Add a SYSCON driver for Core Local Interruptor

[Auer, Lukas]

Hi Bin,

On Thu, 2018-12-06 at 18:07 +0800, Bin Meng wrote:
> Hi Lukas,
> 
> On Thu, Dec 6, 2018 at 7:11 AM Auer, Lukas
>  wrote:
> > 
> > Hi Bin,
> > 
> > On Wed, 2018-12-05 at 17:59 +0800, Bin Meng wrote:
> > > Hi Lukas,
> > > 
> > > On Wed, Nov 14, 2018 at 6:33 PM Auer, Lukas
> > >  wrote:
> > > > 
> > > > Hi Bin,
> > > > 
> > > > On Wed, 2018-11-14 at 09:48 +0800, Bin Meng wrote:
> > > > > Hi Lukas,
> > > > > 
> > > > > On Tue, Nov 13, 2018 at 10:45 PM Auer, Lukas
> > > > >  wrote:
> > > > > > 
> > > > > > Hi Bin,
> > > > > > 
> > > > > > On Tue, 2018-11-13 at 00:21 -0800, Bin Meng wrote:
> > > > > > > This adds U-Boot syscon driver for RISC-V Core Local
> > > > > > > Interruptor
> > > > > > > (CLINT). The CLINT block holds memory-mapped control and
> > > > > > > status
> > > > > > > registers associated with software and timer interrupts.
> > > > > > > 
> > > > > > > 3 APIs are provided for U-Boot to implement Supervisor
> > > > > > > Binary
> > > > > > > Interface (SBI) as defined by the RISC-V privileged
> > > > > > > architecture
> > > > > > > spec v1.10.
> > > > > > > 
> > > > > > > Signed-off-by: Bin Meng 
> > > > > > > ---
> > > > > > 
> > > > > > Would it make sense to also abstract the functions provided
> > > > > > by
> > > > > > the
> > > > > > CLINT more? The reason why I am asking is because the CLINT
> > > > > > is
> > > > > > (unfortunately) not specified as part of RISC-V. It is
> > > > > > developing
> > > > > > into
> > > > > > a de facto standard since other platforms are following
> > > > > > SiFive's
> > > > > > implementation, but there is nothing that would prevent
> > > > > > them
> > > > > > from
> > > > > > implementing something else.
> > > > > > 
> > > > > 
> > > > > I think your observation is correct about CLINT. Rick, does
> > > > > Andes's
> > > > > RISC-V processor also follow SiFive's CLINT model?
> > > > > 
> > > > > > Two immediate examples I can think of would be mtime and
> > > > > > the
> > > > > > IPI
> > > > > > implementation. Many SoC vendors will likely already have a
> > > > > > suitable
> > > > > > timer IP block for mtime. I can imagine that they would
> > > > > > choose
> > > > > > to
> > > > > > re-
> > > > > > use their memory map instead of following that of the
> > > > > > CLINT.
> > > > > > For the IPI implementation there is already an alternative,
> > > > > > the
> > > > > > SBI. If
> > > > > > U-Boot should be able to run in supervisor mode, it would
> > > > > > be
> > > > > > helpful to
> > > > > > support both the SBI and the CLINT interface.
> > > > > > 
> > > > > 
> > > > > I am not sure I followed you here. This driver provides 3
> > > > > APIs:
> > > > > riscv_send_ipi() is for IPI, and the other 2 are for
> > > > > mtime/mtimecmp.
> > > > > 
> > > > 
> > > > It does, but I am not sure how easy it is to support different
> > > > devices.
> > > > Supporting the SBI is not going to be an issue, more
> > > > problematic
> > > > would
> > > > be if we have two different devices and device tree nodes to
> > > > implement
> > > > the functionality of the APIs. Now we have to bind this driver
> > > > to
> > > > two
> > > > devices and call the APIs from the correct instantiation, which
> > > > would
> > > > not work.
> > > > 
> > > > Thinking about this a little more, I think the only issue is
> > > > that
> > > > we
> > > > have both IPI- and mtime-related APIs in one driver. How about
> > > > something like this? Instead of binding this driver to
> > > > riscv,clint0, we
> > > > add a new misc driver for the clint0. The only thing the driver
> > > > does,
> > > > is to bind the syscon driver and the timer driver (see for
> > > > example
> > > > tegra-car.c). Other architectures with separate device tree
> > > > nodes
> > > > for
> > > > the API functionality won't need the misc driver and can just
> > > > bind
> > > > the
> > > > devices to the syscon driver and a timer driver.
> > > > 
> > > 
> > > Sorry it took a long time before replying this. I did have a look
> > > at
> > > the tegra-car.c driver, and also tried various experiments. As
> > > Rick
> > > pointed out we have to handle mixed IP blocks like Andes chip for
> > > mtimer and IPIs. So it looks we need be able to flexibly handle
> > > the
> > > following cases (sigh):
> > > 
> > > - SiFive's clint model which implements mtimer and IPI
> > > - mtimer following SiFive's clint model, but IPI does not (Andes
> > > chip)
> > > - IPI following SiFive's clint model, but mtimer follows
> > > (hypothetical
> > > model which does not exist today)
> > > - completely different mtimer and IPI models from SiFive's clint
> > > model
> > > 
> > 
> > This really is not ideal. I don't think there is a nice way of
> > handling
> > this since there is no way to detect which version we have. A
> > cleaner
> > solution would be to get everyone to use separate compatible
> > strings so
> > that we can load the correct driver or use the correct register
> > offsets.
> > I can't actually find a device node fo

Re: [U-Boot] [PATCH] nand: vybrid: Use calloc() instead of malloc() to allocate struct nfc

[Stefan Agner]

On 03.12.2018 10:20, Lukasz Majewski wrote:
> Without this change it is possible that Vybrid's NFC driver malloc() call
> will obtain some memory used (and correctly free'd) by some previous
> driver (in this case pinctrl for Vybrid).
> 
> As a result some fields of struct nfc - in out case mtd->_get_device - are
> "pre initialized" with some random values.
> 
> On the latter stage of booting, when e.g. somebody calls 'mtdparts default'
> the "data abort" is observed when __get_mtd_device() function is called.
> 
> The mtd->_get_device pointer is not NULL and wrong value is referenced.
> 
> Signed-off-by: Lukasz Majewski 

Looks good:

Reviewed-by: Stefan Agner 

--
Stefan

> 
> ---
> 
>  drivers/mtd/nand/raw/vf610_nfc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/nand/raw/vf610_nfc.c 
> b/drivers/mtd/nand/raw/vf610_nfc.c
> index fce7e5f299..3326c2b096 100644
> --- a/drivers/mtd/nand/raw/vf610_nfc.c
> +++ b/drivers/mtd/nand/raw/vf610_nfc.c
> @@ -646,7 +646,7 @@ static int vf610_nfc_nand_init(int devnum, void
> __iomem *addr)
>   .flash_bbt = 1,
>   };
>  
> - nfc = malloc(sizeof(*nfc));
> + nfc = calloc(1, sizeof(*nfc));
>   if (!nfc) {
>   printf(KERN_ERR "%s: Memory exhausted!\n", __func__);
>   return -ENOMEM;
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 2/5] dts: switch spi-flash to jedec, spi-nor compatible

[Stefan Roese]

On 06.12.18 10:51, Neil Armstrong wrote:

There is no reason not to use the Linux "jedec,spi-nor" binding in U-Boot
dts files. This compatible has been added in sf_probe, let use it.

This patch switches to jedec,spi-nor when spi-flash is used in the DTS
and DTSI files, and removed spi-flash when jedec,spi-nor is already
present.

Signed-off-by: Neil Armstrong 
---
  arch/arc/dts/axs10x_mb.dtsi   |  2 +-
  arch/arc/dts/hsdk.dts |  2 +-
  arch/arm/dts/am335x-brppt1-spi.dts|  2 +-
  arch/arm/dts/am437x-idk-evm.dts   |  2 +-
  arch/arm/dts/am437x-sk-evm.dts|  2 +-
  arch/arm/dts/armada-3720-db.dts   |  2 +-
  arch/arm/dts/armada-3720-espressobin.dts  |  2 +-
  arch/arm/dts/armada-3720-turris-mox.dts   |  2 +-
  arch/arm/dts/armada-385-amc.dts   |  2 +-
  arch/arm/dts/armada-385-turris-omnia-u-boot.dtsi  |  2 +-
  arch/arm/dts/armada-38x-controlcenterdc.dts   |  4 ++--
  arch/arm/dts/armada-38x-solidrun-microsom.dtsi|  2 +-
  arch/arm/dts/armada-8040-clearfog-gt-8k.dts   |  2 +-
  arch/arm/dts/armada-xp-theadorable.dts|  2 +-


For all the MVEBU / Armada based boards:

Acked-by: Stefan Roese 

Thanks for working on this,
Stefan


  arch/arm/dts/at91-sama5d2_xplained.dts|  2 +-
  arch/arm/dts/at91-sama5d4_xplained.dts|  2 +-
  arch/arm/dts/at91-sama5d4ek.dts   |  2 +-
  arch/arm/dts/at91sam9n12ek.dts|  2 +-
  arch/arm/dts/at91sam9x5ek.dtsi|  2 +-
  arch/arm/dts/bk4r1.dts|  4 ++--
  arch/arm/dts/da850-evm-u-boot.dtsi|  2 +-
  arch/arm/dts/exynos5250-snow.dts  |  2 +-
  arch/arm/dts/exynos5250-spring.dts|  2 +-
  arch/arm/dts/exynos5420-peach-pit.dts |  2 +-
  arch/arm/dts/fsl-ls1012a-2g5rdb.dts   |  2 +-
  arch/arm/dts/fsl-ls1012a-frdm.dtsi|  2 +-
  arch/arm/dts/fsl-ls1012a-frwy.dts |  2 +-
  arch/arm/dts/fsl-ls1012a-qds.dtsi |  8 
  arch/arm/dts/fsl-ls1012a-rdb.dtsi |  2 +-
  arch/arm/dts/fsl-ls1043a-qds.dtsi |  8 
  arch/arm/dts/fsl-ls1043a-rdb.dts  |  2 +-
  arch/arm/dts/fsl-ls1046a-qds.dtsi |  8 
  arch/arm/dts/fsl-ls1046a-rdb.dts  |  4 ++--
  arch/arm/dts/fsl-ls1088a-qds.dts  | 10 +-
  arch/arm/dts/fsl-ls1088a-rdb.dts  |  4 ++--
  arch/arm/dts/fsl-ls2080a-qds.dts  |  8 
  arch/arm/dts/fsl-ls2080a-rdb.dts  |  2 +-
  arch/arm/dts/fsl-ls2081a-rdb.dts  |  6 +++---
  arch/arm/dts/fsl-ls2088a-rdb-qspi.dts |  6 +++---
  arch/arm/dts/imx6sx-sabreauto-u-boot.dtsi |  4 ++--
  arch/arm/dts/imx6sx-sdb-u-boot.dtsi   |  4 ++--
  arch/arm/dts/imx6ul-14x14-evk-u-boot.dtsi |  2 +-
  arch/arm/dts/imx6ul-9x9-evk-u-boot.dtsi   |  2 +-
  arch/arm/dts/imx6ull-14x14-evk.dts|  2 +-
  arch/arm/dts/imx7d-sdb-qspi-u-boot.dtsi   |  2 +-
  arch/arm/dts/keystone-k2e-evm.dts |  2 +-
  arch/arm/dts/keystone-k2g-evm.dts |  4 ++--
  arch/arm/dts/keystone-k2g-ice.dts |  2 +-
  arch/arm/dts/keystone-k2hk-evm.dts|  2 +-
  arch/arm/dts/keystone-k2l-evm.dts |  2 +-
  arch/arm/dts/kirkwood-atl-sbx81lifkw.dts  |  2 +-
  arch/arm/dts/kirkwood-atl-sbx81lifxcat.dts|  2 +-
  arch/arm/dts/kirkwood-dreamplug.dts   |  2 +-
  arch/arm/dts/kirkwood-lsxl.dtsi   |  2 +-
  arch/arm/dts/kirkwood-netxbig.dtsi|  2 +-
  arch/arm/dts/kirkwood-ns2-common.dtsi |  2 +-
  arch/arm/dts/kirkwood-synology.dtsi   |  2 +-
  arch/arm/dts/ls1021a-iot.dtsi |  4 ++--
  arch/arm/dts/ls1021a-qds.dtsi |  2 +-
  arch/arm/dts/ls1021a-twr.dtsi |  4 ++--
  arch/arm/dts/mt7629-rfb.dts   |  2 +-
  arch/arm/dts/omap5-u-boot.dtsi|  2 +-
  arch/arm/dts/r8a77970-eagle-u-boot.dts|  2 +-
  arch/arm/dts/rk3288-veyron.dtsi   |  2 +-
  arch/arm/dts/rk3368-lion.dts  |  2 +-
  arch/arm/dts/rk3399-puma.dtsi |  2 +-
  arch/arm/dts/rv1108-evb.dts   |  2 +-
  arch/arm/dts/sama5d27_som1.dtsi   |  2 +-
  arch/arm/dts/sama5d3xmb.dtsi  |  2 +-
  arch/arm/dts/sama5d3xmb_cmp.dtsi

Re: [U-Boot] network not work with u-boot

[cleanc...@163.com]

Hi Wolfgang,

Highly appraciated for your help, I'll try them.



Best wishes.

Zhangguofu (Gary)
 
From: Wolfgang Denk
Date: 2018-12-06 16:13
To: cleanc...@163.com
CC: u-boot
Subject: Re: [U-Boot] network not work with u-boot
Dear "cleanc...@163.com",
 
In message <2018120610134234682...@163.com> you wrote:
>
> Thank you so much, I managed to upload the kernel image by using a tftp 
> server in my desktop. 
 
Fine.
 
> I thought the tftp was a kind of ftp with a naming difference...
 
These are totally different protocols.
 
> As for the configuration item ipaddr1, I still cannot delete it, I am not 
> happy about that.
> Do you or anyone else know how to delete this kind of ill-spelled items?
 
You can run "md" on the memory region which holds the environment,
to find out which special characters sneaked in.  They you can try
to delete the variable by carefully typing the same characters.
 
Alternatively, you can reset your environment to default and re-add
all wanted settings.
 
Best regards,
 
Wolfgang Denk
 
-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
COBOL is for morons. -- E.W. Dijkstra
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] pinctrl: meson: axg: Fix GPIO pin offsets

[Carlo Caione]

The pin number (first and last) in the bank definition is missing the
pin base offset shifting. This is causing a miscalculation when
retrieving the register and pin offsets in the GPIO driver causing the
'gpio' command to drive the wrong pins / GPIOs in the second GPIO chip
(the AO bank is driven correctly because the shifting is already 0).

Signed-off-by: Carlo Caione 
---
 drivers/pinctrl/meson/pinctrl-meson-axg.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/pinctrl/meson/pinctrl-meson-axg.c 
b/drivers/pinctrl/meson/pinctrl-meson-axg.c
index a54fbce910..3bbbe817b4 100644
--- a/drivers/pinctrl/meson/pinctrl-meson-axg.c
+++ b/drivers/pinctrl/meson/pinctrl-meson-axg.c
@@ -14,7 +14,7 @@
 
 #include "pinctrl-meson-axg.h"
 
-#define EE_OFF 14
+#define EE_OFF 15
 
 /* emmc */
 static const unsigned int emmc_nand_d0_pins[] = {BOOT_0};
@@ -893,17 +893,17 @@ static struct meson_pmx_func meson_axg_aobus_functions[] 
= {
 };
 
 static struct meson_bank meson_axg_periphs_banks[] = {
-   /*   namefirst  last  pullen  pulldir out in  */
-   BANK("Z",GPIOZ_0,   GPIOZ_10, 3,  0,  3,  0,  9,  0,  10, 0,  11, 
0),
-   BANK("BOOT", BOOT_0,BOOT_14,  4,  0,  4,  0,  12, 0,  13, 0,  14, 
0),
-   BANK("A",GPIOA_0,   GPIOA_20, 0,  0,  0,  0,  0,  0,  1,  0,  2,  
0),
-   BANK("X",GPIOX_0,   GPIOX_22, 2,  0,  2,  0,  6,  0,  7,  0,  8,  
0),
-   BANK("Y",GPIOY_0,   GPIOY_15, 1,  0,  1,  0,  3,  0,  4,  0,  5,  
0),
+   /*   namefirst  lastpullen  
pulldir out in  */
+   BANK("Z",PIN(GPIOZ_0, EE_OFF),  PIN(GPIOZ_10, EE_OFF), 3,  0,  
3,  0,  9,  0,  10, 0,  11, 0),
+   BANK("BOOT", PIN(BOOT_0, EE_OFF),   PIN(BOOT_14, EE_OFF),  4,  0,  
4,  0,  12, 0,  13, 0,  14, 0),
+   BANK("A",PIN(GPIOA_0, EE_OFF),  PIN(GPIOA_20, EE_OFF), 0,  0,  
0,  0,  0,  0,  1,  0,  2,  0),
+   BANK("X",PIN(GPIOX_0, EE_OFF),  PIN(GPIOX_22, EE_OFF), 2,  0,  
2,  0,  6,  0,  7,  0,  8,  0),
+   BANK("Y",PIN(GPIOY_0, EE_OFF),  PIN(GPIOY_15, EE_OFF), 1,  0,  
1,  0,  3,  0,  4,  0,  5,  0),
 };
 
 static struct meson_bank meson_axg_aobus_banks[] = {
-   /*   namefirst  last   pullen  pulldir out in  
*/
-   BANK("AO",   GPIOAO_0,  GPIOAO_13, 0,  16,  0, 0,  0,  0,  0, 16,  1,  
0),
+   /*   namefirst  last  pullen  pulldir   
  out in  */
+   BANK("AO",   PIN(GPIOAO_0, 0),  PIN(GPIOAO_13, 0), 0,  16,  0, 0,  0,  
0,  0, 16,  1,  0),
 };
 
 static struct meson_pmx_bank meson_axg_periphs_pmx_banks[] = {
@@ -931,11 +931,11 @@ static struct meson_axg_pmx_data 
meson_axg_aobus_pmx_banks_data = {
 
 struct meson_pinctrl_data meson_axg_periphs_pinctrl_data = {
.name   = "periphs-banks",
-   .pin_base   = 11,
+   .pin_base   = 15,
.groups = meson_axg_periphs_groups,
.funcs  = meson_axg_periphs_functions,
.banks  = meson_axg_periphs_banks,
-   .num_pins   = 100,
+   .num_pins   = 86,
.num_groups = ARRAY_SIZE(meson_axg_periphs_groups),
.num_funcs  = ARRAY_SIZE(meson_axg_periphs_functions),
.num_banks  = ARRAY_SIZE(meson_axg_periphs_banks),
-- 
2.19.1

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

Re: [U-Boot] [PATCH 1/1] arm: sunxi: Add NULL pointer check

[Stefan Mavrodiev]

On 12/5/18 5:46 PM, Maxime Ripard wrote:

On Wed, Dec 05, 2018 at 02:27:57PM +0200, Stefan Mavrodiev wrote:

Current driver doesn't check if the destination pointer is NULL.
This cause the data from the FIFO to be stored inside the internal
SDRAM ( address 0 ).

The patch add simple check if the destination pointer is NULL.

Signed-off-by: Stefan Mavrodiev 
---
  drivers/spi/sun4i_spi.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/sun4i_spi.c b/drivers/spi/sun4i_spi.c
index b86b5a00ad..38cc743c61 100644
--- a/drivers/spi/sun4i_spi.c
+++ b/drivers/spi/sun4i_spi.c
@@ -129,7 +129,8 @@ static inline void sun4i_spi_drain_fifo(struct 
sun4i_spi_priv *priv, int len)
  
  	while (len--) {

byte = readb(&priv->regs->rxdata);
-   *priv->rx_buf++ = byte;
+   if (priv->rx_buf)
+   *priv->rx_buf++ = byte;

It seems pretty inefficient to test the pointer at each access, it
would be better to check it once before starting the transfer.

I'm not sure if that can even happen?


I've tried to check that before draining the receive fifo, but then the 
controller doesn't

work. I'm thinking that the fifo must be drained in any case.



Maxime


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

[U-Boot] [PATCH 0/4] rk3399: puma: Enable PWM regulator for Puma.

[Christoph Muellner]

This patch series allows to tune VDD_LOG on RK3399-Q7 Puma boards
using a PWM adjustable regulator.

The effect of the series is, that VDD_LOG will be set to about 950 mV
on Puma. This is required to address stability issues on Puma.

Christoph Muellner (4):
  rockchip: rk3399-puma: Cleanup vdd_log node in puma DTSI.
  power: regulator: Allow PWM regulator to be omitted from SPL.
  rockchip: defconfig: puma-rk3399: enable PWM regulator
  rockchip: puma-rk3399: Enable vdd-log during bootup.

 arch/arm/dts/rk3399-puma.dtsi |  5 +--
 board/theobroma-systems/puma_rk3399/puma-rk3399.c | 43 +++
 configs/puma-rk3399_defconfig |  1 +
 drivers/power/regulator/Kconfig   |  7 
 drivers/power/regulator/Makefile  |  2 +-
 5 files changed, 53 insertions(+), 5 deletions(-)

-- 
2.11.0

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

[U-Boot] [PATCH 1/4] rockchip: rk3399-puma: Cleanup vdd_log node in puma DTSI.

[Christoph Muellner]

 * Eliminate non-standard entries (rockchip,pwm_id and
   rockchip,pwm_voltage).
 * Define target voltage level for vdd-log to 950 mV.

Signed-off-by: Christoph Muellner 
---
 arch/arm/dts/rk3399-puma.dtsi | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/arch/arm/dts/rk3399-puma.dtsi b/arch/arm/dts/rk3399-puma.dtsi
index 11ffcb71778..2cac16e2ce7 100644
--- a/arch/arm/dts/rk3399-puma.dtsi
+++ b/arch/arm/dts/rk3399-puma.dtsi
@@ -180,10 +180,7 @@
regulator-max-microvolt = <140>;
regulator-always-on;
regulator-boot-on;
-
-   /* for rockchip boot on */
-   rockchip,pwm_id= <2>;
-   rockchip,pwm_voltage = <100>;
+   regulator-init-microvolt = <95>;
};
 };
 
-- 
2.11.0

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