Re: [U-Boot] [PATCH 06/14] net: core: Using an ethernet address from ROM is not bad

[Michal Simek]

On 25.11.2016 16:30, Olliver Schinagl wrote:
> Currently we print a warning if the MAC address is read from
> ROM/Hardware. This should not be concidered a bad or erronous thing. A
> MAC address should come either from the hardware (ROM) or may be
> set/overriden in the environment. Neither is a warning or error case.
> 
> Worthy of a warning is the case where both are set, so the user is
> atleast aware something special is happening.
> 
> Signed-off-by: Olliver Schinagl 
> ---
>  net/eth-uclass.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/net/eth-uclass.c b/net/eth-uclass.c
> index 9703bea..aca3f6d 100644
> --- a/net/eth-uclass.c
> +++ b/net/eth-uclass.c
> @@ -510,8 +510,6 @@ static int eth_post_probe(struct udevice *dev)
>   memcpy(pdata->enetaddr, env_enetaddr, ARP_HLEN);
>   } else if (is_valid_ethaddr(pdata->enetaddr)) {
>   eth_setenv_enetaddr_by_index("eth", dev->seq, pdata->enetaddr);
> - printf("\nWarning: %s using MAC address from ROM\n",
> -dev->name);
>   } else if (is_zero_ethaddr(pdata->enetaddr)) {
>  #ifdef CONFIG_NET_RANDOM_ETHADDR
>   net_random_ethaddr(pdata->enetaddr);
> 

User should be aware if mac is read from ROM or something else.
Is there a way how to read it without this message to be generated?

Thanks,
Michal

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

Re: [U-Boot] [PATCH] sun8i_emac: Fix mdio read sequence

[Jagan Teki]

On Fri, Nov 25, 2016 at 9:50 PM, Dr. Philipp Tomsich
 wrote:
> Jagan,
>
>> On 25 Nov 2016, at 17:18, Jagan Teki  wrote:
>>
>> On Wed, Nov 16, 2016 at 7:10 AM, Andre Przywara  
>> wrote:
>>> From: Philipp Tomsich 
>>>
>>> To send a parametrized command to the PHY over MDIO, we should write
>>> the data first, the trigger the execution by the command register
>>> write. Fix the access pattern in our MDIO write routine.
>>> Apparently this doesn't really matter with the Realtek PHY on the
>>> Pine64, but other PHYs (which require more setup) will choke on
>>> the wrong order.
>>
>> Any tested-by this on non-realtek, because I always remember to have
>> CMD with DATA sequence for mdio write for most of the PHY's and ie
>> default sequence though.
>
> We have a KSZ9031 on all our boards… so it was tested against the KSZ9031.

Applied to u-boot-spi/sunxi

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

Re: [U-Boot] [PATCH] sunxi: add support for Nintendo NES Classic Edition

[Jagan Teki]

On Fri, Nov 18, 2016 at 5:01 AM, FUKAUMI Naoki  wrote:
> Signed-off-by: FUKAUMI Naoki 

Added commit message body and

Applied to u-boot-spi/sunxi

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

Re: [U-Boot] [PATCH v2 0/8] SF: Cadence QSPI driver fixes and clean up

[Jagan Teki]

On Fri, Nov 25, 2016 at 8:08 PM, Phil Edworthy
 wrote:
> This series has fixes, patches to clean the code up, and add support for
> specifying the sampling edge.
>
> Changed in v2:
>   spi: cadence_qspi: Fix baud rate calculation
>   spi: cadence_qspi: Fix CS timings (was "Fix CQSPI_CAL_DELAY calculation")
>   spi: cadence_qspi: Support specifying the sample edge used
>
> Added in v2:
>   spi: cadence_qspi: Better debug information on the SPI clock rate
>
> Phil Edworthy (8):
>   spi: cadence_qspi: Fix clearing of pol/pha bits
>   spi: cadence_qspi: Fix baud rate calculation

Please fix the comment for this patch.

>   spi: cadence_qspi: Better debug information on the SPI clock rate
>   spi: cadence_qspi: Use #define for bits instead of bit shifts

And this one,

>   spi: cadence_qspi: Clean up the #define names
>   spi: cadence_qspi: Remove returns from end of void functions
>   spi: cadence_qspi: Fix CS timings
>   spi: cadence_qspi: Support specifying the sample edge used

All look OK, expect above two.

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

Re: [U-Boot] [PATCH] cmd: usb: run 'usb start' when USB is stopped

[Hans de Goede]

Hi,

On 28-11-16 07:54, Minkyu Kang wrote:

Hi Jaehoon,

On 28/11/16 14:08, Jaehoon Chung wrote:

Hi Marek,

On 09/23/2016 01:15 PM, Simon Glass wrote:

+Marek

On 9 September 2016 at 04:20, Jaehoon Chung  wrote:

If USB is stopped, just run 'usb start' instead of printing message.
Then user didn't consider whether usb is started or stopped.


Do you have any other opinion for this? :)

Best Regards,
Jaehoon Chung



Signed-off-by: Jaehoon Chung 
---
 cmd/usb.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/cmd/usb.c b/cmd/usb.c
index 455127c..4970851 100644
--- a/cmd/usb.c
+++ b/cmd/usb.c
@@ -651,8 +651,8 @@ static int do_usb(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
return 0;
}
if (!usb_started) {
-   printf("USB is stopped. Please issue 'usb start' first.\n");
-   return 1;
+   printf("USB is stopped. Running 'usb start' first.\n");
+   do_usb_start();
}


It seems to ambiguous whether initialization was succeed or not.


Right at a minimum it should detect that do_usb_start succeeds. E.g.
on an otg port without an otg -> usb-host cable plugged in it will not
succeed.

Regards,

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

[U-Boot] Pull request v3: u-boot-spi/sunxi

[Jagan Teki]

Hi Tom,

Please pull this sunxi PR.

Changes for v3:
- Dropped patches from 'Chen-Yu Tsai'
- Added two new patches.
Changes for v2:
- Dropped 3 patches, which are still in review.

thanks!
Jagan.

The following changes since commit 136179bec19f4bc84227cba138214ea392a723ea:

  colibri_pxa270: transition to driver model for serial (2016-11-23 13:53:20 
+0100)

are available in the git repository at:

  git://git.denx.de/u-boot-spi.git sunxi

for you to fetch changes up to 707932b3e6507e47bb6b08be669fd39f140933b8:

  sun8i_emac: Fix mdio read sequence (2016-11-28 13:27:47 +0530)


Boris Brezillon (1):
  mtd: nand: add support for the TC58NVG2S0H chip

Emmanuel Vadot (1):
  sunxi: mmc: Set CONFIG_SYS_MMC_MAX_DEVICE

FUKAUMI Naoki (1):
  sunxi: add support for Nintendo NES Classic Edition

Hans de Goede (1):
  sunxi: Mele_M5_defconfig: Drop non existing STATUSLED setting

Jelle van der Waa (1):
  sunxi: Use the available Kconfig option for AHCI

Philipp Tomsich (1):
  sun8i_emac: Fix mdio read sequence

Yann E. MORIN (1):
  arm: sunxi: do not force USB for arch-sunxi

 arch/arm/Kconfig   | 10 ++--
 arch/arm/dts/Makefile  |  1 +
 .../dts/sun8i-r16-nintendo-nes-classic-edition.dts | 63 ++
 board/sunxi/MAINTAINERS|  5 ++
 configs/A10-OLinuXino-Lime_defconfig   |  3 +-
 configs/A20-OLinuXino-Lime2_defconfig  |  3 +-
 configs/A20-OLinuXino-Lime_defconfig   |  3 +-
 configs/A20-OLinuXino_MICRO_defconfig  |  3 +-
 configs/A20-Olimex-SOM-EVB_defconfig   |  3 +-
 configs/Bananapi_defconfig |  3 +-
 configs/Bananapro_defconfig|  3 +-
 configs/Cubieboard2_defconfig  |  3 +-
 configs/Cubieboard_defconfig   |  3 +-
 configs/Cubietruck_defconfig   |  3 +-
 configs/Itead_Ibox_A20_defconfig   |  3 +-
 configs/Lamobo_R1_defconfig|  3 +-
 configs/Linksprite_pcDuino3_Nano_defconfig |  3 +-
 configs/Linksprite_pcDuino3_defconfig  |  3 +-
 configs/Marsboard_A10_defconfig|  3 +-
 configs/Mele_A1000_defconfig   |  3 +-
 configs/Mele_M5_defconfig  |  3 +-
 configs/Nintendo_NES_Classic_Edition_defconfig | 24 +
 configs/Orangepi_defconfig |  3 +-
 configs/Orangepi_mini_defconfig|  3 +-
 configs/Wits_Pro_A20_DKT_defconfig |  3 +-
 drivers/mtd/nand/nand_ids.c|  3 ++
 drivers/net/sun8i_emac.c   |  2 +-
 include/configs/sunxi-common.h |  1 +
 scripts/config_whitelist.txt   |  1 -
 29 files changed, 143 insertions(+), 27 deletions(-)
 create mode 100644 arch/arm/dts/sun8i-r16-nintendo-nes-classic-edition.dts
 create mode 100644 configs/Nintendo_NES_Classic_Edition_defconfig
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 09/14] net: Add ability to set MAC address via EEPROM

[Michal Simek]

On 25.11.2016 16:30, Olliver Schinagl wrote:
> This patch allows Kconfig to enable and set parameters to make it
> possible to read the MAC address from an EEPROM. The net core layer then
> uses this information to read MAC addresses from this EEPROM.
> 
> Besides the various tuneables as to how to access the eeprom (bus,
> address, addressing mode/length, 2 configurable that are EEPROM generic
> (e.g. SPI or some other form of access) which are:
> 
> NET_ETHADDR_EEPROM_OFFSET, indicating where in the EEPROM the start of
> the MAC address is. The default is 8 allowing for 8 bytes before the MAC
> for other purposes (header MAGIC for example).
> 
> NET_ETHADDR_EEPROM_CRC8, indicating the MAC is appended with a CRC8-CCIT
> checksum that should be verified.
> 
> Currently only I2C eeproms have been tested and thus only those options
> are available, but shouldn't be a limit. NET_ETHADDR_EEPROM_SPI can be
> just as created and added.
> 
> The code currently first checks if there is a non-zero MAC address in
> the eeprom. If that fails to be the case, the read_rom_hwaddr can be
> used by a board to supply the MAC in other ways.
> 
> If both these fails, the other code is still in place to query the
> environent, which then can be used to override the hardware supplied
> data.
> 
> Signed-off-by: Olliver Schinagl 
> ---
>  doc/README.enetaddr | 99 
> +
>  include/net.h   | 14 
>  net/Kconfig | 59 +++
>  net/eth-uclass.c|  9 +++--
>  net/eth_common.c| 34 ++
>  net/eth_legacy.c|  2 ++
>  6 files changed, 214 insertions(+), 3 deletions(-)
> 
> diff --git a/doc/README.enetaddr b/doc/README.enetaddr
> index 50e4899..89c1f7d 100644
> --- a/doc/README.enetaddr
> +++ b/doc/README.enetaddr
> @@ -47,6 +47,105 @@ Correct flow of setting up the MAC address (summarized):
>  Previous behavior had the MAC address always being programmed into hardware
>  in the device's init() function.
>  
> +
> + EEPROM
> +
> +
> +Boards may come with an EEPROM specifically to store configuration bits, such
> +as a MAC address. Using CONFIG_NET_ETHADDR_EEPROM enables this feature.
> +Depending on the board, the EEPROM may be connected on various methods, but
> +currently, only the I2C bus can be used via CONFIG_NET_ETHADDR_EEPROM_I2C.
> +
> +The following config options are available,
> +CONFIG_NET_ETHADDR_EEPROM_I2C_BUS is the I2C bus on which the eeprom is 
> present.
> +CONFIG_NET_ETHADDR_EEPROM_I2C_ADDR sets the address of the EEPROM, which
> +defaults to the very common 0x50. Small size EEPROM's generally use single 
> byte
> +addressing but larger EEPROM's may use double byte addressing, which can be
> +configured using CONFIG_NET_ETHADDR_EEPROM_ADDRLEN.
> +
> +Within the EEPROM, the MAC address can be stored on any arbitrary offset,
> +CONFIG_NET_ETHADDR_EEPROM_OFFSET sets this to 8 as a default however, 
> allowing
> +the first 8 bytes to be used for an optional data, for example a 
> configuration
> +struct where the mac address is part of.
> +
> +Appending the 6 (ARP_HLEN) bytes is a CRC8 byte over the previous ARP_HLEN
> +bytes. Whether to check this CRC8 or not is dependent on
> +CONFIG_NET_ETHADDR_EEPROM_CRC8.
> +
> +To keep things nicely aligned, a final 'reserved' byte is added to the mac
> +address + crc8 combo.
> +
> +A board may want to store more information in its eeprom, using the following
> +example layout, this can be achieved.
> +
> +struct mac_addr {
> + uint8_t mac[ARP_HLEN];
> + uint8_t crc8;
> + uint8_t reserved;
> +};
> +
> +struct config_eeprom {
> + uint32_t magic;
> + uint8_t version;
> + uint8_t reserved[2];
> + uint8_t mac_cnt;
> + struct mac_addr[mac_cnt];
> +};
> +
> +Filling this in:
> +struct config_eeprom eeprom = {
> + .magic = { 'M', 'g', 'i', 'c' },
> + .reserved = { 0x00, 0x00 },
> + .mac_cnt = 2,
> + .mac_addr = {
> + {
> + .mac = {
> + 0x01, 0x23, 0x45,
> + 0x67, 0x89, 0xab,
> + },
> + .crc8 = 0xbe,
> + .reserved = 0x00,
> + }, {
> + .mac = {
> + 0xba, 0x98, 0x76,
> + 0x54, 0x32, 0x10,
> + },
> + .crc8 = 0x82,
> + .reserved = 0x00,
> + },
> + },
> +};
> +
> +The eeprom content would look like this.
> +
> +  4d 67 69 63 01 00 00 02  01 23 45 67 89 ab be 00 |Mgic.#Eg|
> +0010  ba 98 76 54 32 10 82 00  |..vT2...|
> +
> +This can be done from linux using the i2c-tools:
> +
> +i2cset I2CBUS 0x50 0x08 0x01
> +i2cset I2CBUS 0x50 0x09 0x23
> +i2cset I2CBUS 0x50 0x0a 0x45
> +i2cset I2CBUS 0x50 0x0b 0x67
> +i2cset I2CBUS 0x50 0x0c 0x89
> +i2cset I2CBUS 0x50 0x0d 0xab
> 

Re: [U-Boot] [PATCH 00/14] [PATCHv4] Retrieve MAC address from EEPROM

[Michal Simek]

Hi,

On 25.11.2016 16:43, Olliver Schinagl wrote:
> This patch-series introduces methods to retrieve the MAC address from an
> onboard EEPROM. The series does a few small cleanups at the start, as
> either
> I ran into them while doing this series and fixed them along the way or
> actually depended on them. If you want to split the smaller ones off into a
> smaller series I understand, but again, I do somewhat depend on them.
> 
> A manufacturer wants to produce boards and may even have MAC addresses for
> boards. Maintaining unique environments on a per-board basis however is
> horrible. Also this data should be very persistent, and not easily
> deletable
> by simply wiping the environment or device tree. Finally there are
> chips available on the market with a pre-programmed MAC address chips
> (proms)
> that a board manufacturer wants to use. Because of this, the MAC needs
> to be
> stored be able to read from such an 'external' source.
> 
> The current idea of the eeprom layout, is to skip the first 8 bytes, so
> that
> other information can be stored there if needed, for example a header
> with some
> magic to identify the EEPROM. Or equivalent purposes.
> 
> After those 8 bytes the MAC address follows the first macaddress. The
> macaddress
> is appended by a CRC8 byte and then padded to make for nice 8 bytes.
> Following
> the first macaddress one can store a second, or a third etc etc mac
> address.
> 
> The CRC8 is optional (via a define) but is strongly recommended to have. It
> helps preventing user error and more importantly, checks if the bytes
> read are
> actually a user inserted address. E.g. only writing 1 macaddress into
> the eeprom
> but trying to consume 2.
> 
> For the added tools, I explicitly did not use the wiser
> eth_validate_ethaddr_str(), eth_parse_enetaddr() and the ARP_HLEN define
> as it
> was quite painful (dependancies) to get these functions into the tools.
> I would
> suggest to merge as is, and if someone wants to improve these simple
> tools to
> use these functions to happily do so.
> 
> These patches where tested on Olimex OLinuXino Lime1 (A10/A20), Lime2 (NAND
> and eMMC) and A20-OLinuXino-MICRO-4G variants and have been in use
> internally on our production systems since v2 of this patch set. To be
> able to
> replicate these tests the second series (which will be separate from
> this set)
> are needed.
> 
> Left TODO:
> If U-Boot configures eth0 and eth1 it inserts these values into the
> environment.
> If the fdt then has an ethernet alias for ethernet0, with a MAC address
> for a
> different device, lets say eth2) things will not work at so well.
> I guess that leaves some discussion with a separated improvement patch as a
> reliable way is needed to match actual u-boot detected devices, with fdt
> described devices. E.g. is dev->name the same name to the fdt? Can we
> blindly
> match here?
> 
> ===
> Changes since v3:
> * Split off board specific stuff and only modify the generic functions
> * Make reading of an eeprom available to every board. By default this is
>   unconfigure and thus should just fall through
> * Clean some minor bits up (ARP_HLEN) and use it more generically
> * Update the gen_ethaddr_crc as suggested by simon
> * Let the fixup_ethernet from fdt_common insert mac addresses to the
> environment
>   for unconfigured devices. There is a small caveat here however as
> described
>   in the TODO above.
> * Print the mac address that u-boot assigned to each device.
> 
> Changes since v2:
> * Drop the id byte altogether and just mark it as reserved. The 'index'
> can be
> used to indicate the interface instead
> * Addopt the read_rom_hwaddr hooks
> * Renamed crc8 tool to gen_ethaddr_crc
> * Improved the layout EEPROM example
> * Made a function out of the hwaddress writing function in sunxi_emac so it
> can be re-used as the write_hwaddr net_ops hook.
> * No longer handle fdt parameters in board.c
> 
> Changes since v1:
> * Do not CRC the id byte, move it just after the crc byte.
> One of the reasons I decided to move it after the crc8 was mostly due to
> mass
> generation of MAC + CRC combo's where the ID is still unknown. Also not
> crc-ing
> the ID means that it is much easier for a user to change it (via the
> u-boot i2c
> cmd line or from within linux) without having to worry about the crc.
> * Add a generator to convert a MAC address from the input to a MAC +
> CRC8 on
> the output.

I have tested this on zcu102 with mac in eeprom and it is working fine
with one mac. I expect you have tested it with more and code looks good
in this sense.
I would personally prefer to know where that mac address is coming from
in output.

Thanks,
Michal

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

Re: [U-Boot] [PATCH v2] tools/env: fix environment alignment tests for block devices

[Max Krummenacher]

Hi

Any news on this?
The env utility is currently broken for block devices.
Alternatively we could also revert commit
183923d3e412500bdc597d1745e2fb6f7f679ec7.

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

Re: [U-Boot] [PATCH] ARM: dts: am437x-idk: Fix QSPI compatible string

[Vignesh R]

On Tuesday 22 November 2016 01:35 PM, Vignesh R wrote:
> 
> 
> On Monday 21 November 2016 11:33 PM, Jagan Teki wrote:
>> On Mon, Nov 21, 2016 at 10:07 AM, Vignesh R  wrote:
>>> Hi Jagan,
>>>
>>> On Thursday 13 October 2016 06:24 PM, Tom Rini wrote:
 On Thu, Oct 13, 2016 at 05:45:52PM +0530, Jagan Teki wrote:
> On Thu, Oct 13, 2016 at 3:53 PM, Vignesh R  wrote:
>> Unlike Linux kernel, U-Boot depends on "spi-flash" compatible to probe
>> m25p80 spi-nor devices. Hence, add "spi-flash" compatible string to
>> m25p80 node. Without this patch, flash device DT data is not parsed and
>> QSPI operates in unsupported mode leading to data corruption.
>>
>> Signed-off-by: Vignesh R 
>
> Applied to u-boot-spi/master

 ... I don't like that we need a non u-boot prefixed string here for the
 binding to work as that will lead to harder re-syncs later on the dt
 files.  Why aren't we matching on the existing part?  Thanks!

>>>
>>> I don't see this patch in u-boot master yet. If this patch was dropped
>>> due to Tom's comment above, then could you suggest how to address the issue?
>>
>> Some how missed this, but do you still unable to probe the flash w/o
>> "spi-flash"? I think there is a device_probe when !device_active(dev)
>> that will detect the flash chip. Please try once.
>>
> 
> Yes, the flash is detected. But the device is not bound due to missing
> "spi-flash" compatible and hence DT properties of flash node are not
> available to the driver. So, the QSPI controller tries to operate in
> mode 0 instead of mode 3 and default frequency instead of 48MHz as
> specified by spi-max-frequency property leading to failure of flashing
> operations.
> 

In case its not clear from above explanation, this patch is still
_needed_ in order for DT properties to be picked up. Without this QSPI
write operations fail on am437x. Can this patch be picked up for this rc?



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

[U-Boot] [RFC PATCH 0/3] spl: Add D-cache support

[Lokesh Vutla]

This series tries to add D-cache support in spl in order to reduce boot time
either in 2stage boot or Falcon Boot.

Lokesh Vutla (3):
  arch: arm: omap: Declare size of ddr very early
  spl: reorder the assignment of board info to global data
  spl: Add support for enabling dcache

 arch/arm/include/asm/cache.h|  1 +
 arch/arm/lib/cache-cp15.c   | 46 +
 arch/arm/mach-omap2/am33xx/board.c  |  4 
 arch/arm/mach-omap2/hwinit-common.c |  1 +
 arch/arm/mach-omap2/omap-cache.c| 15 
 common/spl/spl.c| 42 -
 6 files changed, 98 insertions(+), 11 deletions(-)

-- 
2.10.1

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

[U-Boot] [RFC PATCH 1/3] arch: arm: omap: Declare size of ddr very early

[Lokesh Vutla]

Declare the size of ddr very early in spl, so that this can be
used to enable cache.

Signed-off-by: Lokesh Vutla 
---
 arch/arm/mach-omap2/am33xx/board.c  | 4 
 arch/arm/mach-omap2/hwinit-common.c | 1 +
 2 files changed, 5 insertions(+)

diff --git a/arch/arm/mach-omap2/am33xx/board.c 
b/arch/arm/mach-omap2/am33xx/board.c
index 5ebeac0..7f445ae 100644
--- a/arch/arm/mach-omap2/am33xx/board.c
+++ b/arch/arm/mach-omap2/am33xx/board.c
@@ -303,6 +303,10 @@ void board_init_f(ulong dummy)
early_system_init();
board_early_init_f();
sdram_init();
+   /* dram_init must store complete ramsize in gd->ram_size */
+   gd->ram_size = get_ram_size(
+   (void *)CONFIG_SYS_SDRAM_BASE,
+   CONFIG_MAX_RAM_BANK_SIZE);
 }
 #endif
 
diff --git a/arch/arm/mach-omap2/hwinit-common.c 
b/arch/arm/mach-omap2/hwinit-common.c
index f317293..cac3274 100644
--- a/arch/arm/mach-omap2/hwinit-common.c
+++ b/arch/arm/mach-omap2/hwinit-common.c
@@ -171,6 +171,7 @@ void board_init_f(ulong dummy)
 #endif
/* For regular u-boot sdram_init() is called from dram_init() */
sdram_init();
+   gd->ram_size = omap_sdram_size();
 }
 #endif
 
-- 
2.10.1

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

[U-Boot] [RFC PATCH 3/3] spl: Add support for enabling dcache

[Lokesh Vutla]

Add support for enabling d-cache in SPL. The sequence in SPL tries to
replicate the sequence done in U-Boot except that MMU entries were added
for SRAM.

Signed-off-by: Lokesh Vutla 
---
 arch/arm/include/asm/cache.h |  1 +
 arch/arm/lib/cache-cp15.c| 46 +++-
 arch/arm/mach-omap2/omap-cache.c | 15 +
 common/spl/spl.c | 40 ++
 4 files changed, 92 insertions(+), 10 deletions(-)

diff --git a/arch/arm/include/asm/cache.h b/arch/arm/include/asm/cache.h
index 5400cbe..20f6aca 100644
--- a/arch/arm/include/asm/cache.h
+++ b/arch/arm/include/asm/cache.h
@@ -39,6 +39,7 @@ void arm_init_before_mmu(void);
 void arm_init_domains(void);
 void cpu_cache_initialization(void);
 void dram_bank_mmu_setup(int bank);
+void sram_bank_mmu_setup(phys_addr_t start, phys_addr_t size);
 
 #endif
 
diff --git a/arch/arm/lib/cache-cp15.c b/arch/arm/lib/cache-cp15.c
index e9bbcf5..76f95d6 100644
--- a/arch/arm/lib/cache-cp15.c
+++ b/arch/arm/lib/cache-cp15.c
@@ -94,16 +94,8 @@ void mmu_set_region_dcache_behaviour(phys_addr_t start, 
size_t size,
mmu_page_table_flush(startpt, stoppt);
 }
 
-__weak void dram_bank_mmu_setup(int bank)
+static void set_section_caches(int i)
 {
-   bd_t *bd = gd->bd;
-   int i;
-
-   debug("%s: bank: %d\n", __func__, bank);
-   for (i = bd->bi_dram[bank].start >> MMU_SECTION_SHIFT;
-i < (bd->bi_dram[bank].start >> MMU_SECTION_SHIFT) +
-(bd->bi_dram[bank].size >> MMU_SECTION_SHIFT);
-i++) {
 #if defined(CONFIG_SYS_ARM_CACHE_WRITETHROUGH)
set_section_dcache(i, DCACHE_WRITETHROUGH);
 #elif defined(CONFIG_SYS_ARM_CACHE_WRITEALLOC)
@@ -111,9 +103,33 @@ __weak void dram_bank_mmu_setup(int bank)
 #else
set_section_dcache(i, DCACHE_WRITEBACK);
 #endif
-   }
 }
 
+__weak void dram_bank_mmu_setup(int bank)
+{
+   bd_t *bd = gd->bd;
+   int i;
+
+   debug("%s: bank: %d\n", __func__, bank);
+   for (i = bd->bi_dram[bank].start >> MMU_SECTION_SHIFT;
+i < (bd->bi_dram[bank].start >> MMU_SECTION_SHIFT) +
+(bd->bi_dram[bank].size >> MMU_SECTION_SHIFT); i++)
+   set_section_caches(i);
+}
+
+#if defined(CONFIG_SPL_BUILD) && (defined(CONFIG_SPL_MAX_SIZE) || \
+ defined(CONFIG_SPL_MAX_FOOTPRINT))
+__weak void sram_bank_mmu_setup(phys_addr_t start, phys_addr_t size)
+{
+   int i;
+
+   for (i = start >> MMU_SECTION_SHIFT;
+i < (start >> MMU_SECTION_SHIFT) + (size >> MMU_SECTION_SHIFT);
+i++)
+   set_section_caches(i);
+}
+#endif
+
 /* to activate the MMU we need to set up virtual memory: use 1M areas */
 static inline void mmu_setup(void)
 {
@@ -129,6 +145,16 @@ static inline void mmu_setup(void)
dram_bank_mmu_setup(i);
}
 
+#if defined(CONFIG_SPL_BUILD)
+#if defined(CONFIG_SPL_MAX_SIZE)
+   sram_bank_mmu_setup(CONFIG_SPL_TEXT_BASE,
+   ALIGN(CONFIG_SPL_MAX_SIZE, MMU_SECTION_SIZE));
+#elif defined(CONFIG_SPL_MAX_FOOTPRINT)
+   sram_bank_mmu_setup(CONFIG_SPL_TEXT_BASE,
+   ALIGN(CONFIG_SPL_MAX_FOOTPRINT, MMU_SECTION_SIZE));
+#endif
+#endif
+
 #ifdef CONFIG_ARMV7_LPAE
/* Set up 4 PTE entries pointing to our 4 1GB page tables */
for (i = 0; i < 4; i++) {
diff --git a/arch/arm/mach-omap2/omap-cache.c b/arch/arm/mach-omap2/omap-cache.c
index b37163a..6019e0c 100644
--- a/arch/arm/mach-omap2/omap-cache.c
+++ b/arch/arm/mach-omap2/omap-cache.c
@@ -62,6 +62,21 @@ void dram_bank_mmu_setup(int bank)
set_section_dcache(i, ARMV7_DCACHE_POLICY);
 }
 
+#ifdef CONFIG_SPL_BUILD
+void sram_bank_mmu_setup(phys_addr_t start, phys_addr_t size)
+{
+   int i;
+   phys_addr_t end;
+
+   start = start >> MMU_SECTION_SHIFT;
+   size = size >> MMU_SECTION_SHIFT;
+   end = start + size;
+
+   for (i = start; i <= end; i++)
+   set_section_dcache(i, ARMV7_DCACHE_POLICY);
+}
+#endif
+
 void arm_init_domains(void)
 {
u32 reg;
diff --git a/common/spl/spl.c b/common/spl/spl.c
index 990b700..cdd2917 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -381,6 +381,34 @@ static int spl_load_image(struct spl_image_info 
*spl_image, u32 boot_device)
return -ENODEV;
 }
 
+#if !(defined(CONFIG_SYS_ICACHE_OFF) && defined(CONFIG_SYS_DCACHE_OFF)) && \
+   defined(CONFIG_ARM)
+static int reserve_mmu(void)
+{
+   phys_addr_t ram_top = 0;
+   /* reserve TLB table */
+   gd->arch.tlb_size = PGTABLE_SIZE;
+
+#ifdef CONFIG_SYS_SDRAM_BASE
+   ram_top = CONFIG_SYS_SDRAM_BASE;
+#endif
+   ram_top += get_effective_memsize();
+   gd->arch.tlb_addr = ram_top - gd->arch.tlb_size;
+   debug("TLB table from %08lx to %08lx\n", gd->arch.tlb_addr,
+ gd->arch.tlb_addr + gd->arch.tlb_size);
+   return 0;
+}
+
+__weak void dram_

[U-Boot] [RFC PATCH 2/3] spl: reorder the assignment of board info to global data

[Lokesh Vutla]

Move the assignment of board info to global data a bit early which is safe,
so that ram details can be used to enable caches.

Signed-off-by: Lokesh Vutla 
---
 common/spl/spl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/spl/spl.c b/common/spl/spl.c
index bdb165a..990b700 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -394,6 +394,7 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
int i;
 
debug(">>spl:board_init_r()\n");
+   gd->bd = &bdata;
 
 #if defined(CONFIG_SYS_SPL_MALLOC_START)
mem_malloc_init(CONFIG_SYS_SPL_MALLOC_START,
@@ -461,7 +462,6 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
  */
 void preloader_console_init(void)
 {
-   gd->bd = &bdata;
gd->baudrate = CONFIG_BAUDRATE;
 
serial_init();  /* serial communications setup */
-- 
2.10.1

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

Re: [U-Boot] [PATCH v2] spi: cadence_qspi_apb: Use 32 bit indirect write transaction when possible

[Vignesh R]

On Friday 25 November 2016 10:21 PM, Marek Vasut wrote:
> On 11/24/2016 06:35 AM, Vignesh R wrote:
>> According to Section 11.15.4.9.2 Indirect Write Controller of K2G SoC
>> TRM SPRUHY8D[1], the external master is only permitted to issue 32-bit
>> data interface writes until the last word of an indirect transfer
>> otherwise indirect writes is known to fails sometimes. So, make sure
>> that QSPI indirect writes are 32 bit sized except for the last write. If
>> the txbuf is unaligned then use bounce buffer to avoid data aborts.
>>
>> So, now that the driver uses bounce_buffer, enable CONFIG_BOUNCE_BUFFER
>> for all boards that use Cadence QSPI driver.
>>
>> [1]www.ti.com/lit/ug/spruhy8d/spruhy8d.pdf
>>
>> Signed-off-by: Vignesh R 
>> ---
> 
> Reviewed-by: Marek Vasut 
> 
> I'd like to have at least Dinh's/Chin's ack on this.
> 
> btw don't you need BB for READ as well ?
> 

I don't see any issue with READ due to non word size accesses ATM,
anyways I am working on patch to use BB for READ. Will post that separately.

Thanks for the review!

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

[U-Boot] [PATCH] arch/arm/lib/Makefile: Allow CONFIG_USE_ARCH_MEMSET/MEMCPY with SPL

[Mike Looijmans]

CONFIG_USE_ARCH_MEMSET/MEMCPY are inside a "SPL" check, which makes it
impossible to use CONFIG_USE_ARCH_MEMSET combined with a SPL that calls
memset. This patch moves that outside of the "if spl" block, allowing
the code to be used inside SPL.

One use case is that when using ECC on the Zynq platform, all the DDR
RAM must be written to before it's read, otherwise the system will cause
a bus error and hang. Without CONFIG_USE_ARCH_MEMSET it takes over 5
seconds to clear 256MB, enabling CONFIG_USE_ARCH_MEMSET reduces that time
to less than 3 seconds.

Signed-off-by: Mike Looijmans 
---
 arch/arm/lib/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index 0051f76..eac6a5d 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -30,12 +30,12 @@ obj-$(CONFIG_CMD_BOOTI) += bootm.o
 obj-$(CONFIG_CMD_BOOTM) += bootm.o
 obj-$(CONFIG_CMD_BOOTZ) += bootm.o zimage.o
 obj-$(CONFIG_SYS_L2_PL310) += cache-pl310.o
-obj-$(CONFIG_USE_ARCH_MEMSET) += memset.o
-obj-$(CONFIG_USE_ARCH_MEMCPY) += memcpy.o
 else
 obj-$(CONFIG_SPL_FRAMEWORK) += spl.o
 obj-$(CONFIG_SPL_FRAMEWORK) += zimage.o
 endif
+obj-$(CONFIG_USE_ARCH_MEMSET) += memset.o
+obj-$(CONFIG_USE_ARCH_MEMCPY) += memcpy.o
 obj-$(CONFIG_SEMIHOSTING) += semihosting.o
 
 obj-y  += sections.o
-- 
1.9.1

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

Re: [U-Boot] [PATCH] cmd: usb: run 'usb start' when USB is stopped

[Jaehoon Chung]

On 11/28/2016 05:11 PM, Hans de Goede wrote:
> Hi,
> 
> On 28-11-16 07:54, Minkyu Kang wrote:
>> Hi Jaehoon,
>>
>> On 28/11/16 14:08, Jaehoon Chung wrote:
>>> Hi Marek,
>>>
>>> On 09/23/2016 01:15 PM, Simon Glass wrote:
 +Marek

 On 9 September 2016 at 04:20, Jaehoon Chung  wrote:
> If USB is stopped, just run 'usb start' instead of printing message.
> Then user didn't consider whether usb is started or stopped.
>>>
>>> Do you have any other opinion for this? :)
>>>
>>> Best Regards,
>>> Jaehoon Chung
>>>
>
> Signed-off-by: Jaehoon Chung 
> ---
>  cmd/usb.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/cmd/usb.c b/cmd/usb.c
> index 455127c..4970851 100644
> --- a/cmd/usb.c
> +++ b/cmd/usb.c
> @@ -651,8 +651,8 @@ static int do_usb(cmd_tbl_t *cmdtp, int flag, int 
> argc, char * const argv[])
> return 0;
> }
> if (!usb_started) {
> -   printf("USB is stopped. Please issue 'usb start' 
> first.\n");
> -   return 1;
> +   printf("USB is stopped. Running 'usb start' first.\n");
> +   do_usb_start();
> }
>>
>> It seems to ambiguous whether initialization was succeed or not.
> 
> Right at a minimum it should detect that do_usb_start succeeds. E.g.
> on an otg port without an otg -> usb-host cable plugged in it will not
> succeed.

Got it..Then discard this patch. Thanks for pointing out. 

Best Regards,
Jaehoon Chung

> 
> Regards,
> 
> Hans
> 
> 
> 

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

Re: [U-Boot] [PATCH v2] spi: cadence_qspi_apb: Use 32 bit indirect write transaction when possible

[Vignesh R]

On Friday 25 November 2016 11:18 PM, Jagan Teki wrote:
 >>> diff --git a/include/configs/k2g_evm.h b/include/configs/k2g_evm.h
 >>> index a14544526c71..1d603e0c002f 100644
 >>> --- a/include/configs/k2g_evm.h
 >>> +++ b/include/configs/k2g_evm.h
 >>> @@ -79,6 +79,7 @@
 >>>  #define CONFIG_CADENCE_QSPI
 >>>  #define CONFIG_CQSPI_REF_CLK 38400
 >>>  #define CONFIG_CQSPI_DECODER 0x0
 >>> +#define CONFIG_BOUNCE_BUFFER
>>> >>
>>> >> Better define this on Kconfig and add it on defconfig.
>> >
>> > Such change is unrelated to this patch and should be fixed in a
>> > separate/subsequent one.
> Agreed it should be a separate patch.

Yes, that should be separate series. There are a bunch of drivers and
couple of architectures using CONFIG_BOUNCE_BUFFER, hence the change is
not trivial.

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

[U-Boot] [PATCH 0/4] env_sf: minor cleanup

[Andreas Fenkart]

Andreas Fenkart (4):
  env_sf: factor out prepare_flash_device
  enf_sf: reuse setup_flash_device instead of open coding it
  env_sf: re-order error handling in single-buffer env_relocate_spec
  env_sf: use DIV_ROUND_UP to calculate number of sectors to erase

 common/env_sf.c | 91 ++---
 1 file changed, 35 insertions(+), 56 deletions(-)

-- 
2.10.1

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

[U-Boot] [PATCH 3/4] env_sf: re-order error handling in single-buffer env_relocate_spec

[Andreas Fenkart]

this makes it easier comparable to the double-buffered version

Signed-off-by: Andreas Fenkart 
---
 common/env_sf.c | 20 +++-
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/common/env_sf.c b/common/env_sf.c
index ba9ac8a..8a3de63 100644
--- a/common/env_sf.c
+++ b/common/env_sf.c
@@ -312,29 +312,31 @@ void env_relocate_spec(void)
char *buf = NULL;
 
buf = (char *)memalign(ARCH_DMA_MINALIGN, CONFIG_ENV_SIZE);
-
-   ret = setup_flash_device();
-   if (ret) {
-   if (buf)
-   free(buf);
+   if (!buf) {
+   set_default_env("!malloc() failed");
return;
}
 
+   ret = setup_flash_device();
+   if (ret)
+   goto out;
+
ret = spi_flash_read(env_flash,
CONFIG_ENV_OFFSET, CONFIG_ENV_SIZE, buf);
if (ret) {
set_default_env("!spi_flash_read() failed");
-   goto out;
+   goto err_read;
}
 
ret = env_import(buf, 1);
if (ret)
gd->env_valid = 1;
-out:
+
+err_read:
spi_flash_free(env_flash);
-   if (buf)
-   free(buf);
env_flash = NULL;
+out:
+   free(buf);
 }
 #endif
 
-- 
2.10.1

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

[U-Boot] [PATCH 2/4] enf_sf: reuse setup_flash_device instead of open coding it

[Andreas Fenkart]

setup_flash_device selects one of two code paths depending on the driver
model being used (=CONFIG_DM_SPI_FLASH). env_relocate_spec only used
the non driver-model code path. I'm unsure why, either none of the
platforms that need relocation use the driver model, or - worse - the
driver model is not yet usable when relocating.

Signed-off-by: Andreas Fenkart 
---
 common/env_sf.c | 14 +-
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/common/env_sf.c b/common/env_sf.c
index 5126762..ba9ac8a 100644
--- a/common/env_sf.c
+++ b/common/env_sf.c
@@ -175,12 +175,9 @@ void env_relocate_spec(void)
goto out;
}
 
-   env_flash = spi_flash_probe(CONFIG_ENV_SPI_BUS, CONFIG_ENV_SPI_CS,
-   CONFIG_ENV_SPI_MAX_HZ, CONFIG_ENV_SPI_MODE);
-   if (!env_flash) {
-   set_default_env("!spi_flash_probe() failed");
+   ret = setup_flash_device();
+   if (ret)
goto out;
-   }
 
ret = spi_flash_read(env_flash, CONFIG_ENV_OFFSET,
CONFIG_ENV_SIZE, tmp_env1);
@@ -315,10 +312,9 @@ void env_relocate_spec(void)
char *buf = NULL;
 
buf = (char *)memalign(ARCH_DMA_MINALIGN, CONFIG_ENV_SIZE);
-   env_flash = spi_flash_probe(CONFIG_ENV_SPI_BUS, CONFIG_ENV_SPI_CS,
-   CONFIG_ENV_SPI_MAX_HZ, CONFIG_ENV_SPI_MODE);
-   if (!env_flash) {
-   set_default_env("!spi_flash_probe() failed");
+
+   ret = setup_flash_device();
+   if (ret) {
if (buf)
free(buf);
return;
-- 
2.10.1

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

[U-Boot] [PATCH 1/4] env_sf: factor out prepare_flash_device

[Andreas Fenkart]

copy&paste code found in single/double buffered code path

Signed-off-by: Andreas Fenkart 
---
 common/env_sf.c | 47 ++-
 1 file changed, 18 insertions(+), 29 deletions(-)

diff --git a/common/env_sf.c b/common/env_sf.c
index c53200f..5126762 100644
--- a/common/env_sf.c
+++ b/common/env_sf.c
@@ -45,13 +45,8 @@ char *env_name_spec = "SPI Flash";
 
 static struct spi_flash *env_flash;
 
-#if defined(CONFIG_ENV_OFFSET_REDUND)
-int saveenv(void)
+static int setup_flash_device(void)
 {
-   env_t   env_new;
-   char*saved_buffer = NULL, flag = OBSOLETE_FLAG;
-   u32 saved_size, saved_offset, sector = 1;
-   int ret;
 #ifdef CONFIG_DM_SPI_FLASH
struct udevice *new;
 
@@ -76,6 +71,20 @@ int saveenv(void)
}
}
 #endif
+   return 0;
+}
+
+#if defined(CONFIG_ENV_OFFSET_REDUND)
+int saveenv(void)
+{
+   env_t   env_new;
+   char*saved_buffer = NULL, flag = OBSOLETE_FLAG;
+   u32 saved_size, saved_offset, sector = 1;
+   int ret;
+
+   ret = setup_flash_device();
+   if (ret)
+   return ret;
 
ret = env_export(&env_new);
if (ret)
@@ -242,30 +251,10 @@ int saveenv(void)
char*saved_buffer = NULL;
int ret = 1;
env_t   env_new;
-#ifdef CONFIG_DM_SPI_FLASH
-   struct udevice *new;
-
-   /* speed and mode will be read from DT */
-   ret = spi_flash_probe_bus_cs(CONFIG_ENV_SPI_BUS, CONFIG_ENV_SPI_CS,
-0, 0, &new);
-   if (ret) {
-   set_default_env("!spi_flash_probe_bus_cs() failed");
-   return 1;
-   }
 
-   env_flash = dev_get_uclass_priv(new);
-#else
-
-   if (!env_flash) {
-   env_flash = spi_flash_probe(CONFIG_ENV_SPI_BUS,
-   CONFIG_ENV_SPI_CS,
-   CONFIG_ENV_SPI_MAX_HZ, CONFIG_ENV_SPI_MODE);
-   if (!env_flash) {
-   set_default_env("!spi_flash_probe() failed");
-   return 1;
-   }
-   }
-#endif
+   ret = setup_flash_device();
+   if (ret)
+   return ret;
 
/* Is the sector larger than the env (i.e. embedded) */
if (CONFIG_ENV_SECT_SIZE > CONFIG_ENV_SIZE) {
-- 
2.10.1

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

[U-Boot] [PATCH 4/4] env_sf: use DIV_ROUND_UP to calculate number of sectors to erase

[Andreas Fenkart]

simpler, needs less thinking when reading the code

Signed-off-by: Andreas Fenkart 
---
 common/env_sf.c | 18 +-
 1 file changed, 5 insertions(+), 13 deletions(-)

diff --git a/common/env_sf.c b/common/env_sf.c
index 8a3de63..0434bb8 100644
--- a/common/env_sf.c
+++ b/common/env_sf.c
@@ -79,7 +79,7 @@ int saveenv(void)
 {
env_t   env_new;
char*saved_buffer = NULL, flag = OBSOLETE_FLAG;
-   u32 saved_size, saved_offset, sector = 1;
+   u32 saved_size, saved_offset, sector;
int ret;
 
ret = setup_flash_device();
@@ -114,11 +114,7 @@ int saveenv(void)
goto done;
}
 
-   if (CONFIG_ENV_SIZE > CONFIG_ENV_SECT_SIZE) {
-   sector = CONFIG_ENV_SIZE / CONFIG_ENV_SECT_SIZE;
-   if (CONFIG_ENV_SIZE % CONFIG_ENV_SECT_SIZE)
-   sector++;
-   }
+   sector = DIV_ROUND_UP(CONFIG_ENV_SIZE, CONFIG_ENV_SECT_SIZE);
 
puts("Erasing SPI flash...");
ret = spi_flash_erase(env_flash, env_new_offset,
@@ -244,7 +240,7 @@ out:
 #else
 int saveenv(void)
 {
-   u32 saved_size, saved_offset, sector = 1;
+   u32 saved_size, saved_offset, sector;
char*saved_buffer = NULL;
int ret = 1;
env_t   env_new;
@@ -267,16 +263,12 @@ int saveenv(void)
goto done;
}
 
-   if (CONFIG_ENV_SIZE > CONFIG_ENV_SECT_SIZE) {
-   sector = CONFIG_ENV_SIZE / CONFIG_ENV_SECT_SIZE;
-   if (CONFIG_ENV_SIZE % CONFIG_ENV_SECT_SIZE)
-   sector++;
-   }
-
ret = env_export(&env_new);
if (ret)
goto done;
 
+   sector = DIV_ROUND_UP(CONFIG_ENV_SIZE, CONFIG_ENV_SECT_SIZE);
+
puts("Erasing SPI flash...");
ret = spi_flash_erase(env_flash, CONFIG_ENV_OFFSET,
sector * CONFIG_ENV_SECT_SIZE);
-- 
2.10.1

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

Re: [U-Boot] [PATCH v2] tools/env: fix environment alignment tests for block devices

[Andreas Fenkart]

Hi Max,

LGTM, see one nit below, can fixed later

On 11/19/2016 01:58 PM, Max Krummenacher wrote:

commit 183923d3e412500bdc597d1745e2fb6f7f679ec7 enforces that the
environment must start at an erase block boundary.

For block devices the sample fw_env.config does not mandate a erase block size
for block devices. A missing setting defaults to the full env size.

Depending on the environment location the alignment check now errors out for
perfectly legal settings.

Fix this by defaulting to the standard blocksize of 0x200 for environments
stored in a block device.
That keeps the fw_env.config files for block devices working even with that
new check.

Signed-off-by: Max Krummenacher 

---

Changes in v2:
- move default value handling from parse_config(), get_config() to
   check_device_config(), so that !defined(CONFIG_FILE) is covered also.
- use DIV_ROUND_UP instead of doing this manually
- move the check after the setting of default values in check_device_config().
- use 0 as the marker for default values to be used.

  tools/env/fw_env.c | 60 ++
  1 file changed, 33 insertions(+), 27 deletions(-)

diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c
index 3dc0d53..862a0b1 100644
--- a/tools/env/fw_env.c
+++ b/tools/env/fw_env.c
@@ -1291,18 +1291,6 @@ static int check_device_config(int dev)
struct stat st;
int fd, rc = 0;
  
-	if (DEVOFFSET(dev) % DEVESIZE(dev) != 0) {

-   fprintf(stderr, "Environment does not start on (erase) block 
boundary\n");
-   errno = EINVAL;
-   return -1;
-   }
-
-   if (ENVSIZE(dev) > ENVSECTORS(dev) * DEVESIZE(dev)) {
-   fprintf(stderr, "Environment does not fit into available 
sectors\n");
-   errno = EINVAL;
-   return -1;
-   }
-
fd = open(DEVNAME(dev), O_RDONLY);
if (fd < 0) {
fprintf(stderr,
@@ -1335,9 +1323,15 @@ static int check_device_config(int dev)
goto err;
}
DEVTYPE(dev) = mtdinfo.type;
+   if (DEVESIZE(dev) == 0)
+   /* Assume the erase size is the same as the env-size */
+   DEVESIZE(dev) = ENVSIZE(dev);
Since we already checked for character devices, we could use the 
mtdinfo.erasesize. I guess we can relay on mtdinfo on new kernels, and 
if not there is still the fallback to specify it in fw_env.config.



} else {
uint64_t size;
DEVTYPE(dev) = MTD_ABSENT;
+   if (DEVESIZE(dev) == 0)
+   /* Assume the erase size to be 512 bytes */
+   DEVESIZE(dev) = 0x200;
It doesn't even matter. In case of MTD_ABSENT, erasize is never used 
itself, only the tuple (DEVESIZE * ENVSECTORS) matters.


  
  		/*

 * Check for negative offsets, treat it as backwards offset
@@ -1359,6 +1353,22 @@ static int check_device_config(int dev)
}
}
  
+	if (ENVSECTORS(dev) == 0)

+   /* Assume enough sectors to cover the environment */
+   ENVSECTORS(dev) = DIV_ROUND_UP(ENVSIZE(dev), DEVESIZE(dev));
+
+   if (DEVOFFSET(dev) % DEVESIZE(dev) != 0) {
+   fprintf(stderr, "Environment does not start on (erase) block 
boundary\n");
+   errno = EINVAL;
+   return -1;
+   }
+
+   if (ENVSIZE(dev) > ENVSECTORS(dev) * DEVESIZE(dev)) {
+   fprintf(stderr, "Environment does not fit into available 
sectors\n");
+   errno = EINVAL;
+   return -1;
+   }
+
  err:
close(fd);
return rc;
@@ -1382,10 +1392,10 @@ static int parse_config(struct env_opts *opts)
DEVNAME (0) = DEVICE1_NAME;
DEVOFFSET (0) = DEVICE1_OFFSET;
ENVSIZE (0) = ENV1_SIZE;
-   /* Default values are: erase-size=env-size */
-   DEVESIZE (0) = ENVSIZE (0);
-   /* #sectors=env-size/erase-size (rounded up) */
-   ENVSECTORS (0) = (ENVSIZE(0) + DEVESIZE(0) - 1) / DEVESIZE(0);
+
+   /* Set defaults for DEVESIZE, ENVSECTORS later once we
+* know DEVTYPE
+*/
  #ifdef DEVICE1_ESIZE
DEVESIZE (0) = DEVICE1_ESIZE;
  #endif
@@ -1397,10 +1407,10 @@ static int parse_config(struct env_opts *opts)
DEVNAME (1) = DEVICE2_NAME;
DEVOFFSET (1) = DEVICE2_OFFSET;
ENVSIZE (1) = ENV2_SIZE;
-   /* Default values are: erase-size=env-size */
-   DEVESIZE (1) = ENVSIZE (1);
-   /* #sectors=env-size/erase-size (rounded up) */
-   ENVSECTORS (1) = (ENVSIZE(1) + DEVESIZE(1) - 1) / DEVESIZE(1);
+
+   /* Set defaults for DEVESIZE, ENVSECTORS later once we
+* know DEVTYPE
+*/
  #ifdef DEVICE2_ESIZE
DEVESIZE (1) = DEVICE2_ESIZE;
  #endif
@@ -1466,13 +1476,9 @@ static int get_config (char *fname)
  
  		DEVNAME(i) = devname;
  
-		if (rc < 4)

-   /* Assume the erase size is the sam

Re: [U-Boot] [PATCH] ARM: dts: am437x-idk: Fix QSPI compatible string

[Jagan Teki]

On Mon, Nov 28, 2016 at 3:04 PM, Vignesh R  wrote:
>
>
> On Tuesday 22 November 2016 01:35 PM, Vignesh R wrote:
>>
>>
>> On Monday 21 November 2016 11:33 PM, Jagan Teki wrote:
>>> On Mon, Nov 21, 2016 at 10:07 AM, Vignesh R  wrote:
 Hi Jagan,

 On Thursday 13 October 2016 06:24 PM, Tom Rini wrote:
> On Thu, Oct 13, 2016 at 05:45:52PM +0530, Jagan Teki wrote:
>> On Thu, Oct 13, 2016 at 3:53 PM, Vignesh R  wrote:
>>> Unlike Linux kernel, U-Boot depends on "spi-flash" compatible to probe
>>> m25p80 spi-nor devices. Hence, add "spi-flash" compatible string to
>>> m25p80 node. Without this patch, flash device DT data is not parsed and
>>> QSPI operates in unsupported mode leading to data corruption.
>>>
>>> Signed-off-by: Vignesh R 
>>
>> Applied to u-boot-spi/master
>
> ... I don't like that we need a non u-boot prefixed string here for the
> binding to work as that will lead to harder re-syncs later on the dt
> files.  Why aren't we matching on the existing part?  Thanks!
>

 I don't see this patch in u-boot master yet. If this patch was dropped
 due to Tom's comment above, then could you suggest how to address the 
 issue?
>>>
>>> Some how missed this, but do you still unable to probe the flash w/o
>>> "spi-flash"? I think there is a device_probe when !device_active(dev)
>>> that will detect the flash chip. Please try once.
>>>
>>
>> Yes, the flash is detected. But the device is not bound due to missing
>> "spi-flash" compatible and hence DT properties of flash node are not
>> available to the driver. So, the QSPI controller tries to operate in
>> mode 0 instead of mode 3 and default frequency instead of 48MHz as
>> specified by spi-max-frequency property leading to failure of flashing
>> operations.
>>
>
> In case its not clear from above explanation, this patch is still
> _needed_ in order for DT properties to be picked up. Without this QSPI
> write operations fail on am437x. Can this patch be picked up for this rc?

Will pick.

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

[U-Boot] [PATCH 4/4] imx: mx6sxsabreauto: enable more dm drivers

[Peng Fan]

Enable MMC/I2C/GPIO/PMIC/REGULATOR/PCA953X DM drivers
for mx6sxsabreauto board. Drop non-DM code.

Note:
The i.MX DM drivers has such dependency.
  MXC GPIO -> MXC I2C -> PFUZE/REGULATOR
  MXC GPIO -> PCA953X
  MXC GPIO -> FSL_USDHC

So the drivers needs to be enabled all to avoid
compiling error.

The uboot dm tree log:
=> dm tree
 Class   Probed   Name
 
  root[ + ]root_driver
  thermal [   ]|-- imx_thermal
  simple_bus  [ + ]|-- soc
  simple_bus  [ + ]|   |-- aips-bus@0200
  simple_bus  [   ]|   |   |-- spba-bus@0200
  gpio[ + ]|   |   |-- gpio@0209c000
  gpio[ + ]|   |   |-- gpio@020a
  gpio[ + ]|   |   |-- gpio@020a4000
  gpio[ + ]|   |   |-- gpio@020a8000
  gpio[ + ]|   |   |-- gpio@020ac000
  gpio[ + ]|   |   |-- gpio@020b
  gpio[ + ]|   |   |-- gpio@020b4000
  simple_bus  [   ]|   |   |-- anatop@020c8000
  simple_bus  [   ]|   |   |-- snvs@020cc000
  pinctrl [ + ]|   |   `-- iomuxc@020e
  pinconfig   [ + ]|   |   `-- imx6x-sabreauto
  pinconfig   [ + ]|   |   |-- i2c2grp-1
  pinconfig   [ + ]|   |   |-- i2c3grp-2
  pinconfig   [   ]|   |   |-- uart1grp
  pinconfig   [ + ]|   |   |-- usdhc3grp
  pinconfig   [   ]|   |   |-- usdhc3grp-100mhz
  pinconfig   [   ]|   |   |-- usdhc3grp-200mhz
  pinconfig   [ + ]|   |   |-- usdhc4grp
  pinconfig   [ + ]|   |   `-- vccsd3grp
  simple_bus  [ + ]|   |-- aips-bus@0210
  mmc [ + ]|   |   |-- usdhc@02198000
  mmc [ + ]|   |   |-- usdhc@0219c000
  i2c [ + ]|   |   |-- i2c@021a4000
  i2c_generic [ + ]|   |   |   |-- generic_8
  i2c_generic [ + ]|   |   |   `-- generic_4e
  i2c [ + ]|   |   `-- i2c@021a8000
  gpio[ + ]|   |   |-- gpio@30
  gpio[ + ]|   |   `-- gpio@32
  simple_bus  [   ]|   `-- aips-bus@0220
  simple_bus  [   ]|   `-- spba-bus@0220
  simple_bus  [ + ]`-- regulators
  regulator   [ + ]`-- regulator@0

Signed-off-by: Peng Fan 
Cc: Stefano Babic 
---
 board/freescale/mx6sxsabreauto/mx6sxsabreauto.c | 258 +---
 configs/mx6sxsabreauto_defconfig|  13 ++
 include/configs/mx6sxsabreauto.h|   7 -
 3 files changed, 69 insertions(+), 209 deletions(-)

diff --git a/board/freescale/mx6sxsabreauto/mx6sxsabreauto.c 
b/board/freescale/mx6sxsabreauto/mx6sxsabreauto.c
index 44e6a7d..e7ab810 100644
--- a/board/freescale/mx6sxsabreauto/mx6sxsabreauto.c
+++ b/board/freescale/mx6sxsabreauto/mx6sxsabreauto.c
@@ -16,12 +16,9 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
 #include 
@@ -37,15 +34,6 @@ DECLARE_GLOBAL_DATA_PTR;
PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED |   \
PAD_CTL_DSE_40ohm   | PAD_CTL_SRE_FAST  | PAD_CTL_HYS)
 
-#define USDHC_PAD_CTRL (PAD_CTL_PKE | PAD_CTL_PUE |\
-   PAD_CTL_PUS_22K_UP  | PAD_CTL_SPEED_LOW |   \
-   PAD_CTL_DSE_80ohm   | PAD_CTL_SRE_FAST  | PAD_CTL_HYS)
-
-#define I2C_PAD_CTRL(PAD_CTL_PKE | PAD_CTL_PUE |\
-   PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED |   \
-   PAD_CTL_DSE_40ohm | PAD_CTL_HYS |   \
-   PAD_CTL_ODE)
-
 #define ENET_PAD_CTRL  (PAD_CTL_PUS_100K_UP | PAD_CTL_PUE | \
PAD_CTL_SPEED_HIGH   |   \
PAD_CTL_DSE_48ohm   | PAD_CTL_SRE_FAST)
@@ -56,54 +44,11 @@ DECLARE_GLOBAL_DATA_PTR;
 #define ENET_RX_PAD_CTRL  (PAD_CTL_PKE | PAD_CTL_PUE |  \
PAD_CTL_SPEED_HIGH   | PAD_CTL_SRE_FAST)
 
-#define I2C_PMIC   1
-
 #define GPMI_PAD_CTRL0 (PAD_CTL_PKE | PAD_CTL_PUE | PAD_CTL_PUS_100K_UP)
 #define GPMI_PAD_CTRL1 (PAD_CTL_DSE_40ohm | PAD_CTL_SPEED_MED | \
PAD_CTL_SRE_FAST)
 #define GPMI_PAD_CTRL2 (GPMI_PAD_CTRL0 | GPMI_PAD_CTRL1)
 
-/*Define for building port exp gpio, pin starts from 0*/
-#define PORTEXP_IO_NR(chip, pin) \
-   ((chip << 5) + pin)
-
-/*Get the chip addr from a ioexp gpio*/
-#define PORTEXP_IO_TO_CHIP(gpio_nr) \
-   (gpio_nr >> 5)
-
-/*Get the pin number from a ioexp gpio*/
-#define PORTEXP_IO_TO_PIN(gpio_nr) \
-   (gpio_nr & 0x1f)
-
-#define CPU_PER_RST_B  PORTEXP_IO_NR(0x30, 4)
-#define STEER_ENET PORTEXP_IO_NR(0x32, 2)
-
-static int port_exp_direction_output(unsigned gpio, int value)
-{
-   int ret;
-
-   i2c_set_bus_num(2);
-   ret = i2c_probe(PORTEXP_IO_TO_CHIP(gpio));
-   if (ret)
-   return ret;
-
-   ret = pca953x_set_dir(PORTEXP_IO_TO_CHIP(gpio),
-   (1 << PORTEXP_IO_TO_PIN(gpio)),
-   (PCA953X_DIR_OUT << PORTEXP_IO_TO_PIN(gpio)));
-
-   if (ret)
-   return ret;
-
-

[U-Boot] [PATCH 3/4] imx: dts: mx6sxsabreauto: enable i2c2/3

[Peng Fan]

Enable i2c2/3, add pinctrl settings.
Add max7310 for i2c3.

Signed-off-by: Peng Fan 
Cc: Stefano Babic 
---
 arch/arm/dts/imx6sx-sabreauto.dts | 42 +++
 1 file changed, 42 insertions(+)

diff --git a/arch/arm/dts/imx6sx-sabreauto.dts 
b/arch/arm/dts/imx6sx-sabreauto.dts
index 240a286..a4c2627 100644
--- a/arch/arm/dts/imx6sx-sabreauto.dts
+++ b/arch/arm/dts/imx6sx-sabreauto.dts
@@ -68,8 +68,50 @@
status = "okay";
 };
 
+&i2c2 {
+   clock-frequency = <10>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_i2c2_1>;
+   status = "okay";
+};
+
+&i2c3 {
+clock-frequency = <10>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_i2c3_2>;
+   status = "okay";
+
+   max7310_a: gpio@30 {
+   compatible = "maxim,max7310";
+   reg = <0x30>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
+
+   max7310_b: gpio@32 {
+   compatible = "maxim,max7310";
+   reg = <0x32>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
+};
+
 &iomuxc {
imx6x-sabreauto {
+   pinctrl_i2c2_1: i2c2grp-1 {
+   fsl,pins = <
+   MX6SX_PAD_GPIO1_IO03__I2C2_SDA  
0x4001b8b1
+   MX6SX_PAD_GPIO1_IO02__I2C2_SCL  
0x4001b8b1
+   >;
+   };
+
+   pinctrl_i2c3_2: i2c3grp-2 {
+   fsl,pins = <
+   MX6SX_PAD_KEY_ROW4__I2C3_SDA
0x4001b8b1
+   MX6SX_PAD_KEY_COL4__I2C3_SCL
0x4001b8b1
+   >;
+   };
+
pinctrl_uart1: uart1grp {
fsl,pins = <
MX6SX_PAD_GPIO1_IO04__UART1_TX  0x1b0b1
-- 
2.6.2

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

[U-Boot] [PATCH 2/4] imx: mx6sxsabreauto: enable pinctrl driver

[Peng Fan]

Enable pinctrl driver for mx6sxsabreauto board.

Signed-off-by: Peng Fan 
Cc: Stefano Babic 
---
 configs/mx6sxsabreauto_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/mx6sxsabreauto_defconfig b/configs/mx6sxsabreauto_defconfig
index 49c0583..3e3feab 100644
--- a/configs/mx6sxsabreauto_defconfig
+++ b/configs/mx6sxsabreauto_defconfig
@@ -28,6 +28,8 @@ CONFIG_OF_CONTROL=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_PINCTRL=y
+CONFIG_PINCTRL_IMX6=y
 CONFIG_FSL_QSPI=y
 CONFIG_USB=y
 CONFIG_USB_STORAGE=y
-- 
2.6.2

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

Re: [U-Boot] [PATCHv4] Retrieve MAC address from EEPROM

[Igor Grinberg]

Hi Olliver,

On 11/25/16 17:30, Olliver Schinagl wrote:

[...]

> 
> The current idea of the eeprom layout, is to skip the first 8 bytes, so that
> other information can be stored there if needed, for example a header with 
> some
> magic to identify the EEPROM. Or equivalent purposes.
> 
> After those 8 bytes the MAC address follows the first macaddress. The 
> macaddress
> is appended by a CRC8 byte and then padded to make for nice 8 bytes. Following
> the first macaddress one can store a second, or a third etc etc mac address.
> 
> The CRC8 is optional (via a define) but is strongly recommended to have. It
> helps preventing user error and more importantly, checks if the bytes read are
> actually a user inserted address. E.g. only writing 1 macaddress into the 
> eeprom
> but trying to consume 2.

While reading the above, I'm wondering, have you considered the eeprom layout
feature that we have in: common/eeprom/... ?

The layout feature was actually designed for these tasks, but in a more generic
way then just Ethernet MAC address.

What do you think?


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

[U-Boot] [PATCH] dm: core: Add dev_get_addr_size_index() to retrieve addr and size

[Stefan Roese]

The currently available functions accessing the 'reg' property of a
device only retrieve the address. Sometimes its also necessary to
retrieve the size described by the 'reg' property. This patch adds
the new function dev_get_addr_size_index() which retrieves both,
the address and the size described by the 'reg' property.

Signed-off-by: Stefan Roese 
Cc: Simon Glass 
---
 drivers/core/device.c | 22 ++
 include/dm/device.h   | 16 
 2 files changed, 38 insertions(+)

diff --git a/drivers/core/device.c b/drivers/core/device.c
index dcf5d9d..ec43654 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -693,6 +693,28 @@ fdt_addr_t dev_get_addr_index(struct udevice *dev, int 
index)
 #endif
 }
 
+fdt_addr_t dev_get_addr_size_index(struct udevice *dev, int index,
+  fdt_size_t *size)
+{
+#if CONFIG_IS_ENABLED(OF_CONTROL)
+   /*
+* Only get the size in this first call. We'll get the addr in the
+* next call to the exisiting dev_get_xxx function which handles
+* all config options.
+*/
+   fdtdec_get_addr_size_auto_noparent(gd->fdt_blob, dev->of_offset,
+  "reg", 1, size, false);
+
+   /*
+* Get the base address via the existing function which handles
+* all Kconfig cases
+*/
+   return dev_get_addr_index(dev, index);
+#else
+   return FDT_ADDR_T_NONE;
+#endif
+}
+
 fdt_addr_t dev_get_addr_name(struct udevice *dev, const char *name)
 {
 #if CONFIG_IS_ENABLED(OF_CONTROL)
diff --git a/include/dm/device.h b/include/dm/device.h
index babf8ac..9948bd4 100644
--- a/include/dm/device.h
+++ b/include/dm/device.h
@@ -497,6 +497,22 @@ void *dev_map_physmem(struct udevice *dev, unsigned long 
size);
 fdt_addr_t dev_get_addr_index(struct udevice *dev, int index);
 
 /**
+ * dev_get_addr_size_index() - Get the indexed reg property of a device
+ *
+ * Returns the address and size specified in the 'reg' property of a device.
+ *
+ * @dev: Pointer to a device
+ * @index: the 'reg' property can hold a list of  pairs
+ *and @index is used to select which one is required
+ * @size: Pointer to size varible - this function returns the size
+ *specified in the 'reg' property here
+ *
+ * @return addr
+ */
+fdt_addr_t dev_get_addr_size_index(struct udevice *dev, int index,
+  fdt_size_t *size);
+
+/**
  * dev_get_addr_name() - Get the reg property of a device, indexed by name
  *
  * @dev: Pointer to a device
-- 
2.10.2

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

Re: [U-Boot] [PATCH v3] mmc: add bkops-enable command

[Tomas Melin]

Hi Jaehoon,

On 11/28/2016 06:58 AM, Jaehoon Chung wrote:

> 
> Applied on u-boot-mmc.
> Before applied this patch from patchwork, i changed Author from your email to 
> your name, is it ok?
> 
Thanks! Yes that is perfectly ok.

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

Re: [U-Boot] [PATCH 1/6] net: dw: Add read_rom_hwaddr net_op hook

[Olliver Schinagl]

On 27-11-16 18:02, Simon Glass wrote:

Hi,

On 25 November 2016 at 08:38, Olliver Schinagl  wrote:

Add the read_rom_hwaddr net_op hook so that it can be called from boards
to read the mac from a ROM chip.

Signed-off-by: Olliver Schinagl 
---
  drivers/net/designware.c | 16 
  1 file changed, 16 insertions(+)

diff --git a/drivers/net/designware.c b/drivers/net/designware.c
index 9e6d726..3f2f67c 100644
--- a/drivers/net/designware.c
+++ b/drivers/net/designware.c
@@ -230,6 +230,21 @@ static int _dw_write_hwaddr(struct dw_eth_dev *priv, u8 
*mac_id)
 return 0;
  }

+__weak int dw_board_read_rom_hwaddr(unsigned char *enetaddr, int id)
+{
+   return -ENOSYS;
+}
+
+static int designware_eth_read_rom_hwaddr(struct udevice *dev)
+{
+   struct eth_pdata *pdata = dev_get_platdata(dev);
+
+   if (!dev)
+   return -ENOSYS;
+
+   return dw_board_read_rom_hwaddr(pdata->enetaddr, dev->seq);
+}
+
  static void dw_adjust_link(struct eth_mac_regs *mac_p,
struct phy_device *phydev)
  {
@@ -685,6 +700,7 @@ static const struct eth_ops designware_eth_ops = {
 .free_pkt   = designware_eth_free_pkt,
 .stop   = designware_eth_stop,
 .write_hwaddr   = designware_eth_write_hwaddr,
+   .read_rom_hwaddr= designware_eth_read_rom_hwaddr,
  };

  static int designware_eth_ofdata_to_platdata(struct udevice *dev)

You should not call board code from a driver. But since this is a
sunxi driver, why not move all the code that reads the serial number
into this file?

Hey Simon,

unless I missunderstand, this is how Joe suggested in a while ago, and 
how it has been implemented in a few other drivers. Can you elaborate a 
bit more?


Olliver


Regards,
Simon



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

Re: [U-Boot] [PATCH] net: zynq_gem: Return 0 on success, not -ENOSYS

[Olliver Schinagl]

On 28-11-16 08:22, Michal Simek wrote:

On 25.11.2016 16:41, Olliver Schinagl wrote:

The .read_rom_hwaddr net_ops hook does not check the return value, which
is why it was never caught that we are currently returning 0 if the
read_rom_hwaddr function return -ENOSYS and -ENOSYS otherwise.

In this case we can simplify this by just returning the result of the
function.

Signed-off-by: Olliver Schinagl 
---
  drivers/net/zynq_gem.c | 8 +++-
  1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
index 8b7c1be..04a3fd4 100644
--- a/drivers/net/zynq_gem.c
+++ b/drivers/net/zynq_gem.c
@@ -593,14 +593,12 @@ __weak int zynq_board_read_rom_ethaddr(unsigned char 
*ethaddr)
  
  static int zynq_gem_read_rom_mac(struct udevice *dev)

  {
-   int retval;
struct eth_pdata *pdata = dev_get_platdata(dev);
  
-	retval = zynq_board_read_rom_ethaddr(pdata->enetaddr);

-   if (retval == -ENOSYS)
-   retval = 0;
+   if (!dev)
+   return -ENOSYS;
  
-	return retval;

+   return zynq_board_read_rom_ethaddr(pdata->enetaddr);
  }
  
  static int zynq_gem_miiphy_read(struct mii_dev *bus, int addr,



Not a problem with the patch above but I hope to get rid of this whole
function by using MAC reading from eeprom.
Yeah I agree, once the eeprom bit has matured, this could (in your case 
for your board) be dropped.


Also board specific functions should return error value when read is not
possible.
As an unwritten rule you mean? I think the intention is that 
*_board_read_rom_hwaddr returns 0 on success < 0 on error.


Acked-by: Michal Simek 

Thanks,
Michal



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

Re: [U-Boot] [PATCHv4] Retrieve MAC address from EEPROM

[Olliver Schinagl]

On 28-11-16 10:13, Igor Grinberg wrote:

Hi Olliver,

On 11/25/16 17:30, Olliver Schinagl wrote:

[...]


The current idea of the eeprom layout, is to skip the first 8 bytes, so that
other information can be stored there if needed, for example a header with some
magic to identify the EEPROM. Or equivalent purposes.

After those 8 bytes the MAC address follows the first macaddress. The macaddress
is appended by a CRC8 byte and then padded to make for nice 8 bytes. Following
the first macaddress one can store a second, or a third etc etc mac address.

The CRC8 is optional (via a define) but is strongly recommended to have. It
helps preventing user error and more importantly, checks if the bytes read are
actually a user inserted address. E.g. only writing 1 macaddress into the eeprom
but trying to consume 2.

While reading the above, I'm wondering, have you considered the eeprom layout
feature that we have in: common/eeprom/... ?
Last year, when starting this patch series, this did not really exist in 
so far (iirc).


The layout feature was actually designed for these tasks, but in a more generic
way then just Ethernet MAC address.
I did see it and I was quite excited. I think a follow up patch should 
switch over. I did not yet use the new eeprom layout thing as I am 
hoping for Maxime's patches to land first, where he makes the whole 
eeprom interfacing more generic.


What do you think?
I'll have to look at the eeprom layout feature a little more in depth, 
the one thing that was a little 'annoying' (from a short quick glance) 
was that the layout was jumping around a bit (eth0, eth1, something 
else, eth2, eth3). But yes, I was quite intrigued herein.


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

Re: [U-Boot] [PATCH 06/14] net: core: Using an ethernet address from ROM is not bad

[Olliver Schinagl]

On 28-11-16 08:59, Michal Simek wrote:

On 25.11.2016 16:30, Olliver Schinagl wrote:

Currently we print a warning if the MAC address is read from
ROM/Hardware. This should not be concidered a bad or erronous thing. A
MAC address should come either from the hardware (ROM) or may be
set/overriden in the environment. Neither is a warning or error case.

Worthy of a warning is the case where both are set, so the user is
atleast aware something special is happening.

Signed-off-by: Olliver Schinagl 
---
  net/eth-uclass.c | 2 --
  1 file changed, 2 deletions(-)

diff --git a/net/eth-uclass.c b/net/eth-uclass.c
index 9703bea..aca3f6d 100644
--- a/net/eth-uclass.c
+++ b/net/eth-uclass.c
@@ -510,8 +510,6 @@ static int eth_post_probe(struct udevice *dev)
memcpy(pdata->enetaddr, env_enetaddr, ARP_HLEN);
} else if (is_valid_ethaddr(pdata->enetaddr)) {
eth_setenv_enetaddr_by_index("eth", dev->seq, pdata->enetaddr);
-   printf("\nWarning: %s using MAC address from ROM\n",
-  dev->name);
} else if (is_zero_ethaddr(pdata->enetaddr)) {
  #ifdef CONFIG_NET_RANDOM_ETHADDR
net_random_ethaddr(pdata->enetaddr);


User should be aware if mac is read from ROM or something else.
Is there a way how to read it without this message to be generated?
I think what we need is a 'source' field here to be printed at the end. 
I do agree the user will want to know WHERE the address came from (and 
what it is). I do think the warning is misplaced here however. There's 
nothing to be warned against.


I'll look into adding the feature that prints the source at the end (as 
detailed as we can).


Thanks,
Michal



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

Re: [U-Boot] [PATCH 06/14] net: core: Using an ethernet address from ROM is not bad

[Olliver Schinagl]

On November 28, 2016 12:06:37 PM CET, Michal Simek  
wrote:
>On 28.11.2016 11:48, Olliver Schinagl wrote:
>> On 28-11-16 08:59, Michal Simek wrote:
>>> On 25.11.2016 16:30, Olliver Schinagl wrote:
 Currently we print a warning if the MAC address is read from
 ROM/Hardware. This should not be concidered a bad or erronous
>thing. A
 MAC address should come either from the hardware (ROM) or may be
 set/overriden in the environment. Neither is a warning or error
>case.

 Worthy of a warning is the case where both are set, so the user is
 atleast aware something special is happening.

 Signed-off-by: Olliver Schinagl 
 ---
   net/eth-uclass.c | 2 --
   1 file changed, 2 deletions(-)

 diff --git a/net/eth-uclass.c b/net/eth-uclass.c
 index 9703bea..aca3f6d 100644
 --- a/net/eth-uclass.c
 +++ b/net/eth-uclass.c
 @@ -510,8 +510,6 @@ static int eth_post_probe(struct udevice *dev)
   memcpy(pdata->enetaddr, env_enetaddr, ARP_HLEN);
   } else if (is_valid_ethaddr(pdata->enetaddr)) {
   eth_setenv_enetaddr_by_index("eth", dev->seq,
 pdata->enetaddr);
 -printf("\nWarning: %s using MAC address from ROM\n",
 -   dev->name);
   } else if (is_zero_ethaddr(pdata->enetaddr)) {
   #ifdef CONFIG_NET_RANDOM_ETHADDR
   net_random_ethaddr(pdata->enetaddr);

>>> User should be aware if mac is read from ROM or something else.
>>> Is there a way how to read it without this message to be generated?
>> I think what we need is a 'source' field here to be printed at the
>end.
>> I do agree the user will want to know WHERE the address came from
>(and
>> what it is). I do think the warning is misplaced here however.
>There's
>> nothing to be warned against.
>> 
>> I'll look into adding the feature that prints the source at the end
>(as
>> detailed as we can).
>
>Maybe enough here to remove that Warning from print message.
Well a later patch in this series does print it per interface.

Hence why my suggestion to add the source/from.

Olliver

>
>Thanks,
>Michal

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 06/14] net: core: Using an ethernet address from ROM is not bad

[Michal Simek]

On 28.11.2016 12:08, Olliver Schinagl wrote:
> 
> 
> On November 28, 2016 12:06:37 PM CET, Michal Simek  
> wrote:
>> On 28.11.2016 11:48, Olliver Schinagl wrote:
>>> On 28-11-16 08:59, Michal Simek wrote:
 On 25.11.2016 16:30, Olliver Schinagl wrote:
> Currently we print a warning if the MAC address is read from
> ROM/Hardware. This should not be concidered a bad or erronous
>> thing. A
> MAC address should come either from the hardware (ROM) or may be
> set/overriden in the environment. Neither is a warning or error
>> case.
>
> Worthy of a warning is the case where both are set, so the user is
> atleast aware something special is happening.
>
> Signed-off-by: Olliver Schinagl 
> ---
>   net/eth-uclass.c | 2 --
>   1 file changed, 2 deletions(-)
>
> diff --git a/net/eth-uclass.c b/net/eth-uclass.c
> index 9703bea..aca3f6d 100644
> --- a/net/eth-uclass.c
> +++ b/net/eth-uclass.c
> @@ -510,8 +510,6 @@ static int eth_post_probe(struct udevice *dev)
>   memcpy(pdata->enetaddr, env_enetaddr, ARP_HLEN);
>   } else if (is_valid_ethaddr(pdata->enetaddr)) {
>   eth_setenv_enetaddr_by_index("eth", dev->seq,
> pdata->enetaddr);
> -printf("\nWarning: %s using MAC address from ROM\n",
> -   dev->name);
>   } else if (is_zero_ethaddr(pdata->enetaddr)) {
>   #ifdef CONFIG_NET_RANDOM_ETHADDR
>   net_random_ethaddr(pdata->enetaddr);
>
 User should be aware if mac is read from ROM or something else.
 Is there a way how to read it without this message to be generated?
>>> I think what we need is a 'source' field here to be printed at the
>> end.
>>> I do agree the user will want to know WHERE the address came from
>> (and
>>> what it is). I do think the warning is misplaced here however.
>> There's
>>> nothing to be warned against.
>>>
>>> I'll look into adding the feature that prints the source at the end
>> (as
>>> detailed as we can).
>>
>> Maybe enough here to remove that Warning from print message.
> Well a later patch in this series does print it per interface.
> 
> Hence why my suggestion to add the source/from.

Definitely nice prints and if you add source/from part I will be happy
with it.

Thanks,
Michal


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

Re: [U-Boot] [PATCH 06/14] net: core: Using an ethernet address from ROM is not bad

[Michal Simek]

On 28.11.2016 11:48, Olliver Schinagl wrote:
> On 28-11-16 08:59, Michal Simek wrote:
>> On 25.11.2016 16:30, Olliver Schinagl wrote:
>>> Currently we print a warning if the MAC address is read from
>>> ROM/Hardware. This should not be concidered a bad or erronous thing. A
>>> MAC address should come either from the hardware (ROM) or may be
>>> set/overriden in the environment. Neither is a warning or error case.
>>>
>>> Worthy of a warning is the case where both are set, so the user is
>>> atleast aware something special is happening.
>>>
>>> Signed-off-by: Olliver Schinagl 
>>> ---
>>>   net/eth-uclass.c | 2 --
>>>   1 file changed, 2 deletions(-)
>>>
>>> diff --git a/net/eth-uclass.c b/net/eth-uclass.c
>>> index 9703bea..aca3f6d 100644
>>> --- a/net/eth-uclass.c
>>> +++ b/net/eth-uclass.c
>>> @@ -510,8 +510,6 @@ static int eth_post_probe(struct udevice *dev)
>>>   memcpy(pdata->enetaddr, env_enetaddr, ARP_HLEN);
>>>   } else if (is_valid_ethaddr(pdata->enetaddr)) {
>>>   eth_setenv_enetaddr_by_index("eth", dev->seq,
>>> pdata->enetaddr);
>>> -printf("\nWarning: %s using MAC address from ROM\n",
>>> -   dev->name);
>>>   } else if (is_zero_ethaddr(pdata->enetaddr)) {
>>>   #ifdef CONFIG_NET_RANDOM_ETHADDR
>>>   net_random_ethaddr(pdata->enetaddr);
>>>
>> User should be aware if mac is read from ROM or something else.
>> Is there a way how to read it without this message to be generated?
> I think what we need is a 'source' field here to be printed at the end.
> I do agree the user will want to know WHERE the address came from (and
> what it is). I do think the warning is misplaced here however. There's
> nothing to be warned against.
> 
> I'll look into adding the feature that prints the source at the end (as
> detailed as we can).

Maybe enough here to remove that Warning from print message.

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

Re: [U-Boot] [PATCHv4] Retrieve MAC address from EEPROM

[Igor Grinberg]

Added Nikita to Cc.

On 11/28/16 12:45, Olliver Schinagl wrote:
> On 28-11-16 10:13, Igor Grinberg wrote:
>> Hi Olliver,
>>
>> On 11/25/16 17:30, Olliver Schinagl wrote:
>>
>> [...]
>>
>>> The current idea of the eeprom layout, is to skip the first 8 bytes, so that
>>> other information can be stored there if needed, for example a header with 
>>> some
>>> magic to identify the EEPROM. Or equivalent purposes.
>>>
>>> After those 8 bytes the MAC address follows the first macaddress. The 
>>> macaddress
>>> is appended by a CRC8 byte and then padded to make for nice 8 bytes. 
>>> Following
>>> the first macaddress one can store a second, or a third etc etc mac address.
>>>
>>> The CRC8 is optional (via a define) but is strongly recommended to have. It
>>> helps preventing user error and more importantly, checks if the bytes read 
>>> are
>>> actually a user inserted address. E.g. only writing 1 macaddress into the 
>>> eeprom
>>> but trying to consume 2.
>> While reading the above, I'm wondering, have you considered the eeprom layout
>> feature that we have in: common/eeprom/... ?
> Last year, when starting this patch series, this did not really exist in so 
> far (iirc).
>>
>> The layout feature was actually designed for these tasks, but in a more 
>> generic
>> way then just Ethernet MAC address.
> I did see it and I was quite excited. I think a follow up patch should switch 
> over.

Sounds great!

> I did not yet use the new eeprom layout thing as I am hoping for Maxime's 
> patches to
> land first, where he makes the whole eeprom interfacing more generic.

That's interesting. I haven't been around for some time, are there any public 
patches
already? If so, can you please point where should I look at?

>>
>> What do you think?
> I'll have to look at the eeprom layout feature a little more in depth, the 
> one thing
> that was a little 'annoying' (from a short quick glance) was that the layout 
> was
> jumping around a bit (eth0, eth1, something else, eth2, eth3). But yes,
> I was quite intrigued herein.

Ohh.. you mean compulab layout? I see.
Compulab layout is already out there for 6 years in various devices.
It has gone through several versions, so to be backward compatible (and 
currently it is,
besides the legacy version), it had to do the "jumping" thing.
It is only last year Nikita has started to facilitate it a bit in upstream.
Anyway, the point is that eeprom layout in u-boot/common/eeprom/... should be 
generic
as a framework and any vendor/board can define their own layout in vendor/board 
location.
We are also going to extend the layout framework to provide more in-U-Boot APIs.

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

Re: [U-Boot] [PATCH RESEND] imx-common: hab: fix return value from hab_auth_img

[Eric Nelson]

Hi all,

On 11/27/2016 08:27 AM, Eric Nelson wrote:
> The authenticate_image routine returns a boolean to indicate
> a valid (1) or invalid (0) image.
> 

An off-list discussion highlighted that the expected return value
from the authenticate_image() routine isn't obvious since there
isn't any user in main-line except the "hab_auth_img" command.

My understanding was gleaned from this use in the NXP tree:

http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/tree/drivers/usb/gadget/f_fastboot.c?id=m6.0.1_2.1.0-ga#n1727

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

Re: [U-Boot] [PATCH v5 0/7] toradex: config block handling

[Marcel Ziswiler]

Hi Tom

Could you please apply that series or let me know what else would be
needed/missing to having that done?

http://patchwork.ozlabs.org/patch/695699/

http://patchwork.ozlabs.org/patch/695695/

http://patchwork.ozlabs.org/patch/695697/

http://patchwork.ozlabs.org/patch/695693/

http://patchwork.ozlabs.org/patch/695694/

http://patchwork.ozlabs.org/patch/695696/

http://patchwork.ozlabs.org/patch/695698/

Cheers

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

[U-Boot] [PATCH 12/15 v2] pci: mvebu: Add PCIe driver for Armada-8K

[Stefan Roese]

From: Shadi Ammouri 

This patch adds a driver for the PCIe controller integrated in the
Marvell Armada-8K SoC. This controller is based on the DesignWare
IP core.

The original version was written by Shadi and Yehuda. I ported this
driver to the latest mainline U-Boot version with DM support.

Tested on the Marvell DB-88F8040 Armada-8K eval board.

Signed-off-by: Shadi Ammouri 
Signed-off-by: Yehuda Yitschak 
Signed-off-by: Stefan Roese 
Cc: Simon Glass 
Cc: Nadav Haklai 
Cc: Neta Zur Hershkovits 
Cc: Kostya Porotchkin 
Cc: Omri Itach 
Cc: Igal Liberman 
Cc: Haim Boot 
Cc: Hanna Hawa 
---
v2:
- Removed host struct from private data struct
- Added comments to structs and functions
- Moved shift into the macro for PCIE_LINK_STATUS_SPEED_MASK
  and PCIE_LINK_STATUS_WIDTH_MASK
- Added Email addresses to ToDo statement
- Used clrsetbits_le32(9 where applicable
- Added const to register base pointer
- Used new core function dev_get_addr_size_index() to retrieve
  addr and size
- Added code to configure the PCIe root complex device as PCI
  bridge device

 drivers/pci/Kconfig |  10 +
 drivers/pci/Makefile|   1 +
 drivers/pci/pcie_dw_mvebu.c | 535 
 3 files changed, 546 insertions(+)
 create mode 100644 drivers/pci/pcie_dw_mvebu.c

diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index b8376b4..ff2c370 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -33,6 +33,16 @@ config PCI_PNP
help
  Enable PCI memory and I/O space resource allocation and assignment.
 
+config PCIE_DW_MVEBU
+   bool "Enable Armada-8K PCIe driver (DesignWare core)"
+   default n
+   depends on DM_PCI
+   depends on ARMADA_8K
+   help
+ Say Y here if you want to enable PCIe controller support on
+ Armada-8K SoCs. The PCIe controller on Armada-8K is based on
+ DesignWare hardware.
+
 config PCI_SANDBOX
bool "Sandbox PCI support"
depends on SANDBOX && DM_PCI
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index 9583e91..86717a4 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -30,5 +30,6 @@ obj-$(CONFIG_SH7780_PCI) +=pci_sh7780.o
 obj-$(CONFIG_PCI_TEGRA) += pci_tegra.o
 obj-$(CONFIG_TSI108_PCI) += tsi108_pci.o
 obj-$(CONFIG_WINBOND_83C553) += w83c553f.o
+obj-$(CONFIG_PCIE_DW_MVEBU) += pcie_dw_mvebu.o
 obj-$(CONFIG_PCIE_LAYERSCAPE) += pcie_layerscape.o
 obj-$(CONFIG_PCI_XILINX) += pcie_xilinx.o
diff --git a/drivers/pci/pcie_dw_mvebu.c b/drivers/pci/pcie_dw_mvebu.c
new file mode 100644
index 000..890a265
--- /dev/null
+++ b/drivers/pci/pcie_dw_mvebu.c
@@ -0,0 +1,535 @@
+/*
+ * Copyright (C) 2015 Marvell International Ltd.
+ *
+ * Copyright (C) 2016 Stefan Roese 
+ *
+ * Based on:
+ *   - drivers/pci/pcie_imx.c
+ *   - drivers/pci/pci_mvebu.c
+ *   - drivers/pci/pcie_xilinx.c
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* PCI Config space registers */
+#define PCIE_CONFIG_BAR0   0x10
+#define PCIE_LINK_STATUS_REG   0x80
+#define PCIE_LINK_STATUS_SPEED_OFF 16
+#define PCIE_LINK_STATUS_SPEED_MASK(0xf << PCIE_LINK_STATUS_SPEED_OFF)
+#define PCIE_LINK_STATUS_WIDTH_OFF 20
+#define PCIE_LINK_STATUS_WIDTH_MASK(0xf << PCIE_LINK_STATUS_WIDTH_OFF)
+
+/* Resizable bar capability registers */
+#define RESIZABLE_BAR_CAP  0x250
+#define RESIZABLE_BAR_CTL0 0x254
+#define RESIZABLE_BAR_CTL1 0x258
+
+/* iATU registers */
+#define PCIE_ATU_VIEWPORT  0x900
+#define PCIE_ATU_REGION_INBOUND(0x1 << 31)
+#define PCIE_ATU_REGION_OUTBOUND   (0x0 << 31)
+#define PCIE_ATU_REGION_INDEX1 (0x1 << 0)
+#define PCIE_ATU_REGION_INDEX0 (0x0 << 0)
+#define PCIE_ATU_CR1   0x904
+#define PCIE_ATU_TYPE_MEM  (0x0 << 0)
+#define PCIE_ATU_TYPE_IO   (0x2 << 0)
+#define PCIE_ATU_TYPE_CFG0 (0x4 << 0)
+#define PCIE_ATU_TYPE_CFG1 (0x5 << 0)
+#define PCIE_ATU_CR2   0x908
+#define PCIE_ATU_ENABLE(0x1 << 31)
+#define PCIE_ATU_BAR_MODE_ENABLE   (0x1 << 30)
+#define PCIE_ATU_LOWER_BASE0x90C
+#define PCIE_ATU_UPPER_BASE0x910
+#define PCIE_ATU_LIMIT 0x914
+#define PCIE_ATU_LOWER_TARGET  0x918
+#define PCIE_ATU_BUS(x)(((x) & 0xff) << 24)
+#define PCIE_ATU_DEV(x)(((x) & 0x1f) << 19)
+#define PCIE_ATU_FUNC(x)   (((x) & 0x7) << 16)
+#define PCIE_ATU_UPPER_TARGET  0x91C
+
+#define PCIE_LINK_CAPABILITY   0x7C
+#define PCIE_LINK_CTL_20xA0
+#define TARGET_LINK_SPEED_MASK 0xF
+#define LINK_SPEED_GEN_1   0x1
+#define LINK_SPEED_GEN_2   0x2
+#define LINK_SPEED_GEN_3   0x3
+
+#define PCIE_GEN3_RELATED  0x890
+#define GEN3_EQU_DIS

Re: [U-Boot] [PATCH] sunxi: move CONFIG_SATAPWR to Kconfig option

[Maxime Ripard]

Hi Hans,

On Fri, Nov 25, 2016 at 09:12:30AM +0100, Hans de Goede wrote:
> Hi,
> 
> On 24-11-16 22:22, Maxime Ripard wrote:
> > On Wed, Nov 23, 2016 at 07:28:16PM +0100, Jelle van der Waa wrote:
> > > Introduce a new CONFIG_SATAPWR Kconfig option to replace the
> > > option in CONFIG_SYS_EXTRA_OPTIONS.
> > > 
> > > Signed-off-by: Jelle van der Waa 
> > > ---
> > >  board/sunxi/Kconfig|  7 +++
> > >  board/sunxi/board.c| 11 ++-
> > >  configs/A10-OLinuXino-Lime_defconfig   |  3 ++-
> > >  configs/A20-OLinuXino-Lime2_defconfig  |  3 ++-
> > >  configs/A20-OLinuXino-Lime_defconfig   |  3 ++-
> > >  configs/A20-OLinuXino_MICRO_defconfig  |  3 ++-
> > >  configs/A20-Olimex-SOM-EVB_defconfig   |  3 ++-
> > >  configs/Cubieboard2_defconfig  |  3 ++-
> > >  configs/Cubieboard_defconfig   |  3 ++-
> > >  configs/Cubietruck_defconfig   |  3 ++-
> > >  configs/Itead_Ibox_A20_defconfig   |  3 ++-
> > >  configs/Lamobo_R1_defconfig|  3 ++-
> > >  configs/Linksprite_pcDuino3_Nano_defconfig |  3 ++-
> > >  configs/Linksprite_pcDuino3_defconfig  |  3 ++-
> > >  configs/Sinovoip_BPI_M3_defconfig  |  2 +-
> > >  configs/orangepi_plus_defconfig|  3 ++-
> > >  16 files changed, 40 insertions(+), 19 deletions(-)
> > > 
> > > diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
> > > index ae2fba1..fe2f7b4 100644
> > > --- a/board/sunxi/Kconfig
> > > +++ b/board/sunxi/Kconfig
> > > @@ -667,6 +667,13 @@ config GMAC_TX_DELAY
> > >   ---help---
> > >   Set the GMAC Transmit Clock Delay Chain value.
> > > 
> > > +config SATAPWR
> > > + string "power pin for SATA"
> > > + default ""
> > > + ---help---
> > > + Set the power pin for SATA. This takes a string in the format
> > > + understood by sunxi_name_to_gpio, e.g. PH1 for pin 1 of port H.
> > > +
> > 
> > This looks like a rather generic option. Can't this be in
> > drivers/block instead?
> 
> The proper solution would be to get the info from devicetree,
> which requires regulator support, which we don't have yet
> for sunxi. In the mean time getting rid of the need for
> CONFIG_SYS_EXTRA_OPTIONS is a worthwhile goal in itself
> IMHO.

Yes, but a GPIO to enable the SATA 5V rail seems like a rather common
thing, and definitely not Allwinner specific.

Moving that option to drivers/block would make more sense I guess.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [U-Boot] [PATCH v2 7/8] spi: cadence_qspi: Fix CS timings

[See, Chin Liang]

Hi Phil,

On Jum, 2016-11-25 at 14:38 +, Phil Edworthy wrote:
> 
> The Cadence QSPI controller has specified overheads for the various
> CS
> times that are in addition to those programmed in to the Device Delay
> register. The overheads are different for the delays.
> 
> In addition, the existing code does not handle the case when the
> delay
> is less than a SCLK period.
> 
> This change accurately calculates the additional delays in Ref
> clocks.
> 
> Signed-off-by: Phil Edworthy 
> ---
> v2:
>  Was "spi: cadence_qspi: Fix CQSPI_CAL_DELAY calculation"
>  Note only did the existing code not cope with the delay less than
>  an SCLK period, but the calculation didn't round properly, and
>  didn't take into account the delays that the QSPI Controller adds
>  to those programmed into the Device Delay reg.
> ---
>  drivers/spi/cadence_qspi_apb.c | 23 ---
>  1 file changed, 12 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/spi/cadence_qspi_apb.c
> b/drivers/spi/cadence_qspi_apb.c
> index 1cd636a..56ad952 100644
> --- a/drivers/spi/cadence_qspi_apb.c
> +++ b/drivers/spi/cadence_qspi_apb.c
> @@ -169,9 +169,6 @@
> ((readl(base + CQSPI_REG_CONFIG) >> \
> CQSPI_REG_CONFIG_IDLE_LSB) & 0x1)
> 
> -#define CQSPI_CAL_DELAY(tdelay_ns, tref_ns, tsclk_ns)  \
> -   tdelay_ns) - (tsclk_ns)) / (tref_ns)))
> -
>  #define CQSPI_GET_RD_SRAM_LEVEL(reg_base)  \
> (((readl(reg_base + CQSPI_REG_SDRAMLEVEL)) >>   \
> CQSPI_REG_SDRAMLEVEL_RD_LSB) & CQSPI_REG_SDRAMLEVEL_RD_MASK)
> @@ -357,16 +354,20 @@ void cadence_qspi_apb_delay(void *reg_base,
> cadence_qspi_apb_controller_disable(reg_base);
> 
> /* Convert to ns. */
> -   ref_clk_ns = (10) / ref_clk;
> +   ref_clk_ns = DIV_ROUND_UP(10, ref_clk);
> 
> /* Convert to ns. */
> -   sclk_ns = (10) / sclk_hz;
> -
> -   /* Plus 1 to round up 1 clock cycle. */
> -   tshsl = CQSPI_CAL_DELAY(tshsl_ns, ref_clk_ns, sclk_ns) + 1;
> -   tchsh = CQSPI_CAL_DELAY(tchsh_ns, ref_clk_ns, sclk_ns) + 1;
> -   tslch = CQSPI_CAL_DELAY(tslch_ns, ref_clk_ns, sclk_ns) + 1;
> -   tsd2d = CQSPI_CAL_DELAY(tsd2d_ns, ref_clk_ns, sclk_ns) + 1;
> +   sclk_ns = DIV_ROUND_UP(10, sclk_hz);
> +
> +   /* The controller adds additional delay to that programmed in
> the reg */
> +   if (tshsl_ns >= sclk_ns + ref_clk_ns)
> +   tshsl_ns -= sclk_ns + ref_clk_ns;
> +   if (tchsh_ns >= sclk_ns + 3 * ref_clk_ns)
> +   tchsh_ns -= sclk_ns + 3 * ref_clk_ns;
Any reason we need this?
The DIV_ROUND_UP or previous + 1 in algo will ensure its more than a
SCLK period.

Thanks
Chin Liang

> 
> +   tshsl = DIV_ROUND_UP(tshsl_ns, ref_clk_ns);
> +   tchsh = DIV_ROUND_UP(tchsh_ns, ref_clk_ns);
> +   tslch = DIV_ROUND_UP(tslch_ns, ref_clk_ns);
> +   tsd2d = DIV_ROUND_UP(tsd2d_ns, ref_clk_ns);
> 
> reg = ((tshsl & CQSPI_REG_DELAY_TSHSL_MASK)
> << CQSPI_REG_DELAY_TSHSL_LSB);
> --
> 2.7.4
> 
> 
> 
> 
> Confidentiality Notice.
> This message may contain information that is confidential or
> otherwise protected from disclosure. If you are not the intended
> recipient, you are hereby notified that any use, disclosure,
> dissemination, distribution, or copying of this message, or any
> attachments, is strictly prohibited. If you have received this
> message in error, please advise the sender by reply e-mail, and
> delete the message and any attachments. Thank you.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 0/8] SF: Cadence QSPI driver fixes and clean up

[Marek Vasut]

On 11/28/2016 09:07 AM, Jagan Teki wrote:
> On Fri, Nov 25, 2016 at 8:08 PM, Phil Edworthy
>  wrote:
>> This series has fixes, patches to clean the code up, and add support for
>> specifying the sampling edge.
>>
>> Changed in v2:
>>   spi: cadence_qspi: Fix baud rate calculation
>>   spi: cadence_qspi: Fix CS timings (was "Fix CQSPI_CAL_DELAY calculation")
>>   spi: cadence_qspi: Support specifying the sample edge used
>>
>> Added in v2:
>>   spi: cadence_qspi: Better debug information on the SPI clock rate
>>
>> Phil Edworthy (8):
>>   spi: cadence_qspi: Fix clearing of pol/pha bits
>>   spi: cadence_qspi: Fix baud rate calculation
> 
> Please fix the comment for this patch.

Fix how ? It seems perfectly fine to me, so explain.

>>   spi: cadence_qspi: Better debug information on the SPI clock rate
>>   spi: cadence_qspi: Use #define for bits instead of bit shifts
> 
> And this one,

DTTO, seems perfectly fine.

>>   spi: cadence_qspi: Clean up the #define names
>>   spi: cadence_qspi: Remove returns from end of void functions
>>   spi: cadence_qspi: Fix CS timings
>>   spi: cadence_qspi: Support specifying the sample edge used
> 
> All look OK, expect above two.
> 
> thanks!
> 


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

Re: [U-Boot] [PATCH v2] tools/env: fix environment alignment tests for block devices

[Max Krummenacher]

Hi Andreas

2016-11-28 10:47 GMT+01:00 Andreas Fenkart :
> Hi Max,
>
> LGTM, see one nit below, can fixed later
>
>
> On 11/19/2016 01:58 PM, Max Krummenacher wrote:
>>
>> commit 183923d3e412500bdc597d1745e2fb6f7f679ec7 enforces that the
>> environment must start at an erase block boundary.
>>
>> For block devices the sample fw_env.config does not mandate a erase block
>> size
>> for block devices. A missing setting defaults to the full env size.
>>
>>   tools/env/fw_env.c | 60
...
>> }
>> DEVTYPE(dev) = mtdinfo.type;
>> +   if (DEVESIZE(dev) == 0)
>> +   /* Assume the erase size is the same as the
>> env-size */
>> +   DEVESIZE(dev) = ENVSIZE(dev);
>
> Since we already checked for character devices, we could use the
> mtdinfo.erasesize. I guess we can relay on mtdinfo on new kernels, and if
> not there is still the fallback to specify it in fw_env.config.

Agreed, however since that changes functionallity I think this must go
into a follow up patch.
Also, since the config file skeleton mandates a erase size I don't see
a pressing need.

>
>> } else {
>> uint64_t size;
>> DEVTYPE(dev) = MTD_ABSENT;
>> +   if (DEVESIZE(dev) == 0)
>> +   /* Assume the erase size to be 512 bytes */
>> +   DEVESIZE(dev) = 0x200;
>
> It doesn't even matter. In case of MTD_ABSENT, erasize is never used itself,
> only the tuple (DEVESIZE * ENVSECTORS) matters.

That is not true. with the test for DEVOFFSET being aligned to
DEVESIZE the previous used default broke env with certain legal config
files.
Other than this new test I agree.

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

Re: [U-Boot] [PATCH v2] spi: cadence_qspi_apb: Use 32 bit indirect write transaction when possible

[Marek Vasut]

On 11/28/2016 10:37 AM, Vignesh R wrote:
> 
> 
> On Friday 25 November 2016 10:21 PM, Marek Vasut wrote:
>> On 11/24/2016 06:35 AM, Vignesh R wrote:
>>> According to Section 11.15.4.9.2 Indirect Write Controller of K2G SoC
>>> TRM SPRUHY8D[1], the external master is only permitted to issue 32-bit
>>> data interface writes until the last word of an indirect transfer
>>> otherwise indirect writes is known to fails sometimes. So, make sure
>>> that QSPI indirect writes are 32 bit sized except for the last write. If
>>> the txbuf is unaligned then use bounce buffer to avoid data aborts.
>>>
>>> So, now that the driver uses bounce_buffer, enable CONFIG_BOUNCE_BUFFER
>>> for all boards that use Cadence QSPI driver.
>>>
>>> [1]www.ti.com/lit/ug/spruhy8d/spruhy8d.pdf
>>>
>>> Signed-off-by: Vignesh R 
>>> ---
>>
>> Reviewed-by: Marek Vasut 
>>
>> I'd like to have at least Dinh's/Chin's ack on this.
>>
>> btw don't you need BB for READ as well ?
>>
> 
> I don't see any issue with READ due to non word size accesses ATM,

Like user does sf read ... 0x1003 0x100 , you'll likely have a problem, no?

> anyways I am working on patch to use BB for READ. Will post that separately.
> 
> Thanks for the review!
> 


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

Re: [U-Boot] [PATCH] usb: xhci: Limit transfer length in a single TD

[Marek Vasut]

On 11/28/2016 07:15 AM, Dongwoo Lee wrote:
> On 11/26/2016 03:25 AM, Marek Vasut wrote:
>> On 11/22/2016 03:42 AM, Dongwoo Lee wrote:
>>> On 2016년 11월 18일 23:01, Marek Vasut wrote:
 On 11/18/2016 08:24 AM, Jaehoon Chung wrote:
> Hi,
>
> Added Marek as USB maintainer.
>
> On 11/17/2016 01:21 PM, Dongwoo Lee wrote:
>> The transfer request exceeding 4032KB (the maximum number of TRBs per
>> TD * the maximum size of transfer buffer on TRB) fails on xhci host
>> with timed out error or babble error state. This failure occurs when
>> accessing large files on USB mass-storage. Currently with xhci as well
>> as ehci host, the driver requests maximum 30MB (65536 blks * 512 byte)
>> to storage at once. However, xhci cannot handle this request because
>> of the reason mentioned above, even though ehci can handle this. Thus,
>> transfer request larger than this size should be splitted in order to
>> limit the length of data in a single TD.
>>
>> Even though the single request is splitted into multiple requests,
>> the transfer speed has affected insignificantly in comparison with
>> ehci host: 22.6 MB/s on ehci and 22.3 MB/s on xhci for 100MB tranfer.
>
> I don't have USB knowledge..So i wonder that this is correct way.
> Have other guys ever seen the similar issue?

 Is this a controller limitation ?

 btw can you fix your mailer to NOT send HTML email to the list?

>>>
>>> If my understanding for xhci spec.(rev. 1.1) 4.9.2 is right, the controller 
>>> has no limitation for transfer size because it can support a very large TRB 
>>> ring with multiple Ring Segments. 
>>>
>>> However, the xhci driver seems not to be implemented for supporting it; 
>>> the TRB ring is comprised of only a single segment. As a result, it cannot 
>>> handle the request exceeding 4032KB (TRB_MAX_BUFF_SIZE(64KB) * 
>>> (TRBS_PER_SEGMENT(64) - link TRB(1)), thus the request should be divided.  
>>
>> Can we update the driver ?
>>
> 
> Yes, I agree. 
> I think also updating driver is more reasonable.
> 
> Though I think it takes some time since I just started xhci, I will
> prepare a patch for enabling multiple ring segments for the driver.

Great, thanks!


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

Re: [U-Boot] [PATCH] SPL: NOR: Add CONFIG_SPL_NOR_COPY_ENTIRE_IMAGE define to enable whole image copy from NOR

[Marek Vasut]

On 11/28/2016 07:27 AM, Lukasz Majewski wrote:
> This define gives the possibility to copy entire image (including header)
> from NOR parallel memory to e.g. SDRAM.
> 
> The legacy behavior is preserved, since other board don't enabled this option.
> 
> Signed-off-by: Lukasz Majewski 

What is the usecase ?

> ---
>  common/spl/Kconfig   | 10 ++
>  common/spl/spl_nor.c | 12 +---
>  2 files changed, 19 insertions(+), 3 deletions(-)
> 
> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> index df9e0ce..d31b26d 100644
> --- a/common/spl/Kconfig
> +++ b/common/spl/Kconfig
> @@ -399,6 +399,16 @@ config SPL_NOR_SUPPORT
> a memory-mapped device makes it very easy to access. Loading from
> NOR is typically achieved with just a memcpy().
>  
> +config SPL_NOR_COPY_ENTIRE_IMAGE
> + bool
> + depends on SPL_NOR_SUPPORT
> + prompt "Copy entire image from NOR memory"
> + default n
> + help
> +   By default the SPL NOR driver supports copying only payload to
> +   destination address. Say Y if you want to copy entire image (including
> +   its image header).
> +
>  config SPL_ONENAND_SUPPORT
>   bool "Support OneNAND flash"
>   depends on SPL
> diff --git a/common/spl/spl_nor.c b/common/spl/spl_nor.c
> index 6bfa399..44f3e99 100644
> --- a/common/spl/spl_nor.c
> +++ b/common/spl/spl_nor.c
> @@ -10,13 +10,15 @@
>  static int spl_nor_load_image(struct spl_image_info *spl_image,
> struct spl_boot_device *bootdev)
>  {
> + void *img_src;
>   int ret;
> +#ifndef CONFIG_SPL_NOR_COPY_ENTIRE_IMAGE
>   /*
>* Loading of the payload to SDRAM is done with skipping of
>* the mkimage header in this SPL NOR driver
>*/
>   spl_image->flags |= SPL_COPY_PAYLOAD_ONLY;
> -
> +#endif
>  #ifdef CONFIG_SPL_OS_BOOT
>   if (!spl_start_uboot()) {
>   const struct image_header *header;
> @@ -65,9 +67,13 @@ static int spl_nor_load_image(struct spl_image_info 
> *spl_image,
>   if (ret)
>   return ret;
>  
> + img_src = (void *)CONFIG_SYS_UBOOT_BASE;
> +#ifndef CONFIG_SPL_NOR_COPY_ENTIRE_IMAGE
> + img_src += sizeof(struct image_header));
> +#endif
> +
>   memcpy((void *)(unsigned long)spl_image->load_addr,
> -(void *)(CONFIG_SYS_UBOOT_BASE + sizeof(struct image_header)),
> -spl_image->size);
> +img_src, spl_image->size);
>  
>   return 0;
>  }
> 


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

Re: [U-Boot] [PATCH] sunxi: move CONFIG_SATAPWR to Kconfig option

[Hans de Goede]

HI,

On 28-11-16 13:42, Maxime Ripard wrote:

Hi Hans,

On Fri, Nov 25, 2016 at 09:12:30AM +0100, Hans de Goede wrote:

Hi,

On 24-11-16 22:22, Maxime Ripard wrote:

On Wed, Nov 23, 2016 at 07:28:16PM +0100, Jelle van der Waa wrote:

Introduce a new CONFIG_SATAPWR Kconfig option to replace the
option in CONFIG_SYS_EXTRA_OPTIONS.

Signed-off-by: Jelle van der Waa 
---
 board/sunxi/Kconfig|  7 +++
 board/sunxi/board.c| 11 ++-
 configs/A10-OLinuXino-Lime_defconfig   |  3 ++-
 configs/A20-OLinuXino-Lime2_defconfig  |  3 ++-
 configs/A20-OLinuXino-Lime_defconfig   |  3 ++-
 configs/A20-OLinuXino_MICRO_defconfig  |  3 ++-
 configs/A20-Olimex-SOM-EVB_defconfig   |  3 ++-
 configs/Cubieboard2_defconfig  |  3 ++-
 configs/Cubieboard_defconfig   |  3 ++-
 configs/Cubietruck_defconfig   |  3 ++-
 configs/Itead_Ibox_A20_defconfig   |  3 ++-
 configs/Lamobo_R1_defconfig|  3 ++-
 configs/Linksprite_pcDuino3_Nano_defconfig |  3 ++-
 configs/Linksprite_pcDuino3_defconfig  |  3 ++-
 configs/Sinovoip_BPI_M3_defconfig  |  2 +-
 configs/orangepi_plus_defconfig|  3 ++-
 16 files changed, 40 insertions(+), 19 deletions(-)

diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index ae2fba1..fe2f7b4 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -667,6 +667,13 @@ config GMAC_TX_DELAY
---help---
Set the GMAC Transmit Clock Delay Chain value.

+config SATAPWR
+   string "power pin for SATA"
+   default ""
+   ---help---
+   Set the power pin for SATA. This takes a string in the format
+   understood by sunxi_name_to_gpio, e.g. PH1 for pin 1 of port H.
+


This looks like a rather generic option. Can't this be in
drivers/block instead?


The proper solution would be to get the info from devicetree,
which requires regulator support, which we don't have yet
for sunxi. In the mean time getting rid of the need for
CONFIG_SYS_EXTRA_OPTIONS is a worthwhile goal in itself
IMHO.


Yes, but a GPIO to enable the SATA 5V rail seems like a rather common
thing, and definitely not Allwinner specific.

Moving that option to drivers/block would make more sense I guess.


Hmm, but in the end this should be removed, as everything should'
be using devicetree, so I'm not convinced it is a good idea
to introduce a generic option for this.

Anyways either way is fine with me.

Regards,

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

Re: [U-Boot] [PATCH v2 0/8] SF: Cadence QSPI driver fixes and clean up

[Jagan Teki]

On Mon, Nov 28, 2016 at 6:20 PM, Marek Vasut  wrote:
> On 11/28/2016 09:07 AM, Jagan Teki wrote:
>> On Fri, Nov 25, 2016 at 8:08 PM, Phil Edworthy
>>  wrote:
>>> This series has fixes, patches to clean the code up, and add support for
>>> specifying the sampling edge.
>>>
>>> Changed in v2:
>>>   spi: cadence_qspi: Fix baud rate calculation
>>>   spi: cadence_qspi: Fix CS timings (was "Fix CQSPI_CAL_DELAY calculation")
>>>   spi: cadence_qspi: Support specifying the sample edge used
>>>
>>> Added in v2:
>>>   spi: cadence_qspi: Better debug information on the SPI clock rate
>>>
>>> Phil Edworthy (8):
>>>   spi: cadence_qspi: Fix clearing of pol/pha bits
>>>   spi: cadence_qspi: Fix baud rate calculation
>>
>> Please fix the comment for this patch.
>
> Fix how ? It seems perfectly fine to me, so explain.
>
>>>   spi: cadence_qspi: Better debug information on the SPI clock rate
>>>   spi: cadence_qspi: Use #define for bits instead of bit shifts
>>
>> And this one,
>
> DTTO, seems perfectly fine.

See my comments on these patch threads.

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

Re: [U-Boot] [PATCH v2 8/8] spi: cadence_qspi: Support specifying the sample edge used

[See, Chin Liang]

Hi Phil,

On Jum, 2016-11-25 at 14:38 +, Phil Edworthy wrote:
> Whilst at it, move the code to read the "sram-size" property
> into the other code that reads properties from the node, rather
> than the SF subnode.
> 
> Also change the code to use a bool for the bypass arg.
> 
> Signed-off-by: Phil Edworthy 
> 
> ---
> v2:
>  Change name of DT prop and provide details of what it does.
>  Whilst at it, move the code to read the "sram-size" property
>  into the other code that reads properties from the node, rather
>  than the SF subnode.
> 
>  Also change the code to use a bool for the bypass arg.
> ---
>  doc/device-tree-bindings/spi/spi-cadence.txt |  2 ++
>  drivers/spi/cadence_qspi.c   | 13 +
>  drivers/spi/cadence_qspi.h   |  3 ++-
>  drivers/spi/cadence_qspi_apb.c   |  8 +++-
>  4 files changed, 20 insertions(+), 6 deletions(-)
> 

[..]

> diff --git a/drivers/spi/cadence_qspi_apb.c
> b/drivers/spi/cadence_qspi_apb.c
> index 56ad952..e43973c 100644
> --- a/drivers/spi/cadence_qspi_apb.c
> +++ b/drivers/spi/cadence_qspi_apb.c
> @@ -98,6 +98,7 @@
>  #defineCQSPI_REG_RD_DATA_CAPTURE_BYPASSBIT(0)
>  #defineCQSPI_REG_RD_DATA_CAPTURE_DELAY_LSB 1
>  #defineCQSPI_REG_RD_DATA_CAPTURE_DELAY_MASK0xF
> +#defineCQSPI_REG_RD_DATA_CAPTURE_EDGE  BIT(5)


Actually we don't have this edge bit at SOCFPGA.
But no harm as its unused bit at SOCFPGA today

Thanks
Chin Liang

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

Re: [U-Boot] [PATCH v2 2/4] davinci: omapl138_lcdk: configure ddr2

[Fabien Parent]

On Tue, Nov 22, 2016 at 7:10 PM, Tom Rini  wrote:
> On Tue, Nov 22, 2016 at 06:13:31PM +0100, Fabien Parent wrote:
>
>> The SPL is unable to load u-boot because the DDR2 is not configured.
>> Configure the DDR2.
>>
>> Signed-off-by: Fabien Parent 
>> ---
>>
>> V1 -> V2
>>
>> * New patch
>>
>> ---
>>  include/configs/omapl138_lcdk.h | 42 
>> +
>>  1 file changed, 42 insertions(+)
>>
>> diff --git a/include/configs/omapl138_lcdk.h 
>> b/include/configs/omapl138_lcdk.h
>> index ce3a8f4..2cdf892 100644
>> --- a/include/configs/omapl138_lcdk.h
>> +++ b/include/configs/omapl138_lcdk.h
>> @@ -31,6 +31,7 @@
>>  #define CONFIG_SYS_HZ_CLOCK  clk_get(DAVINCI_AUXCLK_CLKID)
>>  #define CONFIG_SYS_HZ1000
>>  #define CONFIG_SYS_DA850_PLL_INIT
>> +#define CONFIG_SYS_DA850_DDR_INIT
>>  #define CONFIG_SKIP_LOWLEVEL_INIT
>>  #define CONFIG_SYS_TEXT_BASE 0xc108
>
> This would be "easy" to move to Kconfig, so please do.
>
>> @@ -80,6 +81,47 @@
>>  #define CONFIG_SYS_DA850_PLL1_PLLM 21
>>
>>  /*
>> + * DDR2 memory configuration
>> + */
>> +#define CONFIG_SYS_DA850_DDR2_DDRPHYCR (DV_DDR_PHY_PWRDNEN | \
>> + DV_DDR_PHY_EXT_STRBEN | \
>> + (0x5 << DV_DDR_PHY_RD_LATENCY_SHIFT))
>> +
>> +#define CONFIG_SYS_DA850_DDR2_SDBCR (  \
>> + (1 << DV_DDR_SDCR_DDR2EN_SHIFT) | \
>> + (1 << DV_DDR_SDCR_DDREN_SHIFT)  | \
>> + (1 << DV_DDR_SDCR_SDRAMEN_SHIFT)| \
>> + (1 << DV_DDR_SDCR_BUS_WIDTH_SHIFT)  | \
>> + (4 << DV_DDR_SDCR_CL_SHIFT) | \
>> + (3 << DV_DDR_SDCR_IBANK_SHIFT)  | \
>> + (2 << DV_DDR_SDCR_PAGESIZE_SHIFT))
>> +
>> +/* SDBCR2 is only used if IBANK_POS bit in SDBCR is set */
>> +#define CONFIG_SYS_DA850_DDR2_SDBCR2 0
>> +
>> +#define CONFIG_SYS_DA850_DDR2_SDTIMR ( \
>> + (19 << DV_DDR_SDTMR1_RFC_SHIFT) | \
>> + (1 << DV_DDR_SDTMR1_RP_SHIFT)   | \
>> + (1 << DV_DDR_SDTMR1_RCD_SHIFT)  | \
>> + (2 << DV_DDR_SDTMR1_WR_SHIFT)   | \
>> + (6 << DV_DDR_SDTMR1_RAS_SHIFT)  | \
>> + (8 << DV_DDR_SDTMR1_RC_SHIFT)   | \
>> + (1 << DV_DDR_SDTMR1_RRD_SHIFT)  | \
>> + (1 << DV_DDR_SDTMR1_WTR_SHIFT))
>> +
>> +#define CONFIG_SYS_DA850_DDR2_SDTIMR2 (\
>> + (7 << DV_DDR_SDTMR2_RASMAX_SHIFT)   | \
>> + (2 << DV_DDR_SDTMR2_XP_SHIFT)   | \
>> + (0 << DV_DDR_SDTMR2_ODT_SHIFT)  | \
>> + (10 << DV_DDR_SDTMR2_XSNR_SHIFT)| \
>> + (199 << DV_DDR_SDTMR2_XSRD_SHIFT)   | \
>> + (1 << DV_DDR_SDTMR2_RTP_SHIFT)  | \
>> + (2 << DV_DDR_SDTMR2_CKE_SHIFT))
>> +
>> +#define CONFIG_SYS_DA850_DDR2_SDRCR0x0492
>> +#define CONFIG_SYS_DA850_DDR2_PBBPR0x30
>
> This is a little harder.  I think this should be done more like
> arch/arm/include/asm/arch-omap3/mem.h:#define where we name-space the
> values that we construct based on the part (maker and size/speed).  Do
> you have time to look into this migration?  Thanks!

Given that I don't have a lot of time right now, in the v3 I will just
move CONFIG_SYS_DA850_DDR_INIT to Kconfig and keep all the config in
the header file and at a later time once my current work on
OMAPl138-LCDK is over I will sent a new patchset for all the
CONFIG_SYS_DA85_DDR* options.

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

Re: [U-Boot] [PATCH v2] spi: cadence_qspi_apb: Use 32 bit indirect write transaction when possible

[See, Chin Liang]

On Jum, 2016-11-25 at 17:51 +0100, Marek Vasut wrote:
> On 11/24/2016 06:35 AM, Vignesh R wrote:
> > 
> > According to Section 11.15.4.9.2 Indirect Write Controller of K2G
> > SoC
> > TRM SPRUHY8D[1], the external master is only permitted to issue 32-
> > bit
> > data interface writes until the last word of an indirect transfer
> > otherwise indirect writes is known to fails sometimes. So, make
> > sure
> > that QSPI indirect writes are 32 bit sized except for the last
> > write. If
> > the txbuf is unaligned then use bounce buffer to avoid data aborts.
> > 
> > So, now that the driver uses bounce_buffer, enable
> > CONFIG_BOUNCE_BUFFER
> > for all boards that use Cadence QSPI driver.
> > 
> > [1]www.ti.com/lit/ug/spruhy8d/spruhy8d.pdf
> > 
> > Signed-off-by: Vignesh R 
> > ---
> Reviewed-by: Marek Vasut 
> 
> I'd like to have at least Dinh's/Chin's ack on this.

THanks Marek

Hmmm... From 11.15.4.1.1, the data slave port should able to accept
only byte, half-word and word access. This should not create any data
abort but probably bad performance. But it should insignificant as
access time for the flash is longer than the data port access itself.

Thanks
Chin Liang

> 
> btw don't you need BB for READ as well ?
> 
> > 
> > v2:
> >  - Use bounce buffer
> >  - Link to v1: https://patchwork.ozlabs.org/patch/693069/
> > 
> >  drivers/spi/cadence_qspi_apb.c   | 26 --
> >  include/configs/k2g_evm.h|  1 +
> >  include/configs/socfpga_common.h |  1 +
> >  include/configs/stv0991.h|  1 +
> >  4 files changed, 23 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/spi/cadence_qspi_apb.c
> > b/drivers/spi/cadence_qspi_apb.c
> > index e285d3c1e761..6ce98acf747d 100644
> > --- a/drivers/spi/cadence_qspi_apb.c
> > +++ b/drivers/spi/cadence_qspi_apb.c
> > @@ -30,6 +30,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include "cadence_qspi.h"
> > 
> >  #define CQSPI_REG_POLL_US(1) /* 1us */
> > @@ -741,6 +742,17 @@ int
> > cadence_qspi_apb_indirect_write_execute(struct cadence_spi_platdata
> > *plat,
> >   unsigned int remaining = n_tx;
> >   unsigned int write_bytes;
> >   int ret;
> > + struct bounce_buffer bb;
> > + u8 *bb_txbuf;
> > +
> > + /*
> > +  * Handle non-4-byte aligned accesses via bounce buffer to
> > +  * avoid data abort.
> > +  */
> > + ret = bounce_buffer_start(&bb, (void *)txbuf, n_tx,
> > GEN_BB_READ);
> > + if (ret)
> > + return ret;
> > + bb_txbuf = bb.bounce_buffer;
> > 
> >   /* Configure the indirect read transfer bytes */
> >   writel(n_tx, plat->regbase + CQSPI_REG_INDIRECTWRBYTES);
> > @@ -751,11 +763,11 @@ int
> > cadence_qspi_apb_indirect_write_execute(struct cadence_spi_platdata
> > *plat,
> > 
> >   while (remaining > 0) {
> >   write_bytes = remaining > page_size ? page_size :
> > remaining;
> > - /* Handle non-4-byte aligned access to avoid data
> > abort. */
> > - if (((uintptr_t)txbuf % 4) || (write_bytes % 4))
> > - writesb(plat->ahbbase, txbuf, write_bytes);
> > - else
> > - writesl(plat->ahbbase, txbuf, write_bytes >>
> > 2);
> > + writesl(plat->ahbbase, bb_txbuf, write_bytes >> 2);
> > + if (write_bytes % 4)
> > + writesb(plat->ahbbase,
> > + bb_txbuf + rounddown(write_bytes, 4),
> > + write_bytes % 4);
> > 
> >   ret = wait_for_bit("QSPI", plat->regbase +
> > CQSPI_REG_SDRAMLEVEL,
> >  CQSPI_REG_SDRAMLEVEL_WR_MASK <<
> > @@ -765,7 +777,7 @@ int
> > cadence_qspi_apb_indirect_write_execute(struct cadence_spi_platdata
> > *plat,
> >   goto failwr;
> >   }
> > 
> > - txbuf += write_bytes;
> > + bb_txbuf += write_bytes;
> >   remaining -= write_bytes;
> >   }
> > 
> > @@ -776,6 +788,7 @@ int
> > cadence_qspi_apb_indirect_write_execute(struct cadence_spi_platdata
> > *plat,
> >   printf("Indirect write completion error (%i)\n",
> > ret);
> >   goto failwr;
> >   }
> > + bounce_buffer_stop(&bb);
> > 
> >   /* Clear indirect completion status */
> >   writel(CQSPI_REG_INDIRECTWR_DONE_MASK,
> > @@ -786,6 +799,7 @@ failwr:
> >   /* Cancel the indirect write */
> >   writel(CQSPI_REG_INDIRECTWR_CANCEL_MASK,
> >  plat->regbase + CQSPI_REG_INDIRECTWR);
> > + bounce_buffer_stop(&bb);
> >   return ret;
> >  }
> > 
> > diff --git a/include/configs/k2g_evm.h b/include/configs/k2g_evm.h
> > index a14544526c71..1d603e0c002f 100644
> > --- a/include/configs/k2g_evm.h
> > +++ b/include/configs/k2g_evm.h
> > @@ -79,6 +79,7 @@
> >  #define CONFIG_CADENCE_QSPI
> >  #define CONFIG_CQSPI_REF_CLK 38400
> >  #define CONFIG_CQSPI_DECODER 0x0
> > +#define CONFIG_BOUNCE_BUFFER
> >  #en

[U-Boot] [PATCH] imx6: clock: Enable External Memory Interface [EIM] clock (eim_slow_clock)

[Lukasz Majewski]

This patch extends the imx6 clock code to enable or disable the EIM
slow clock, which in necessary when one wants to use EIM interface t
o read/write from external memory (e.g. NOR).

Signed-off-by: Lukasz Majewski 
---
 arch/arm/cpu/armv7/mx6/clock.c| 14 ++
 arch/arm/include/asm/arch-mx6/clock.h |  1 +
 2 files changed, 15 insertions(+)

diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c
index ae3143c..3227e3b 100644
--- a/arch/arm/cpu/armv7/mx6/clock.c
+++ b/arch/arm/cpu/armv7/mx6/clock.c
@@ -1379,6 +1379,20 @@ void select_ldb_di_clock_source(enum ldb_di_clock clk)
 }
 #endif
 
+#ifndef CONFIG_SYS_NO_FLASH
+void enable_eim_clk(unsigned char enable)
+{
+   u32 reg;
+
+   reg = __raw_readl(&imx_ccm->CCGR6);
+   if (enable)
+   reg |= MXC_CCM_CCGR6_EMI_SLOW_MASK;
+   else
+   reg &= ~MXC_CCM_CCGR6_EMI_SLOW_MASK;
+   __raw_writel(reg, &imx_ccm->CCGR6);
+}
+#endif
+
 /***/
 
 U_BOOT_CMD(
diff --git a/arch/arm/include/asm/arch-mx6/clock.h 
b/arch/arm/include/asm/arch-mx6/clock.h
index 82f9f92..ed1433e 100644
--- a/arch/arm/include/asm/arch-mx6/clock.h
+++ b/arch/arm/include/asm/arch-mx6/clock.h
@@ -79,4 +79,5 @@ void enable_qspi_clk(int qspi_num);
 void enable_thermal_clk(void);
 void mxs_set_lcdclk(u32 base_addr, u32 freq);
 void select_ldb_di_clock_source(enum ldb_di_clock clk);
+void enable_eim_clk(unsigned char enable);
 #endif /* __ASM_ARCH_CLOCK_H */
-- 
2.1.4

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

[U-Boot] [PATCH 1/1] rpi: set serial port clock to 48 MHz

[Mirza Krak]

From: Mirza Krak 

Recently the default UART clock rate has been changed to 48 MHz on all
pi`s in the firmware files, which broke UART support in u-boot.

Align configuration to boot firmware.

Signed-off-by: Mirza Krak 
---

It was changed here 
https://github.com/raspberrypi/firmware/commit/d0bc6ce8e2ae7850959fed4edb0695f3cddfb96a.

See also https://github.com/raspberrypi/linux/issues/1732.


 board/raspberrypi/rpi/rpi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index 1d3a4e0..a8996d7 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -37,7 +37,7 @@ static const struct pl01x_serial_platdata serial_platdata = {
.base = 0x20201000,
 #endif
.type = TYPE_PL011,
-   .clock = 300,
+   .clock = 4800,
 };

 U_BOOT_DEVICE(bcm2835_serials) = {
--
2.1.4

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

Re: [U-Boot] Macronix NOR_SPI and Quad I/O

[Champ, Andy]

I don't have anything that does Quad IO, so I can't test it either.

I think the best thing to do is to disable it for the Macronix parts, and put a 
comment in the table explaining why. With any luck one day somebody somewhere 
will have a device with a Macronix chip and quad I/O, and they can do it 
properly.

If this sounds good I'll put a patch together, run it past our open source 
lawyers (I'm not allowed to just push!) and send it through.

Alternatively I could put together a patch that sets a different flag bit for 
Macronix Quad I/O and push that. The only thing is of course that I have no way 
to test it, and as we all know untested code never works.

Which way should I go?

Regards
Andy Champ

From: Jagan Teki 
Sent: 26 November 2016 03:13
To: Champ, Andy
Cc: u-boot@lists.denx.de; jt...@openedev.com; radu.bac...@gmail.com; 
cl...@altera.com; dumitru.bac...@intel.com
Subject: Re: [U-Boot] Macronix NOR_SPI and Quad I/O

On Fri, Nov 25, 2016 at 10:07 PM, Champ, Andy  wrote:
> Hi all,
>
>
> in the table in drivers/mtd/spi/spi_flash_ids.c there is a flag WR_QPP set 
> against Macronix devices (including the ones Dumitru is just adding).
>
>
> This is used when programming the devices on a 4-bit bus to select the 
> command to use for programming - either CMD_QUAD_PAGE_PROGRAM (0x32) or 
> CMD_PAGE_PROGRAM (0x2).
>
>
> The Macronix devices that I have a spec for do not mention command 0x32. Each 
> of the devices that I have a spec for ( MX25L25635F MX25U51245G MX25V8035F 
> and MX25V1635F ) use command 0x38 instead.

We need to fix this, till now no Macronix has been tested with QUAD I
think, please send the suitable fix will review.

thanks!
--
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.

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

[U-Boot] [PATCH] SPL: NOR: Add CONFIG_SPL_NOR_COPY_ENTIRE_IMAGE define to enable whole image copy from NOR

[Lukasz Majewski]

This define gives the possibility to copy entire image (including header)
from NOR parallel memory to e.g. SDRAM.

The legacy behavior is preserved, since other board don't enabled this option.

Signed-off-by: Lukasz Majewski 
---
 common/spl/Kconfig   | 10 ++
 common/spl/spl_nor.c | 12 +---
 2 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index df9e0ce..d31b26d 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -399,6 +399,16 @@ config SPL_NOR_SUPPORT
  a memory-mapped device makes it very easy to access. Loading from
  NOR is typically achieved with just a memcpy().
 
+config SPL_NOR_COPY_ENTIRE_IMAGE
+   bool
+   depends on SPL_NOR_SUPPORT
+   prompt "Copy entire image from NOR memory"
+   default n
+   help
+ By default the SPL NOR driver supports copying only payload to
+ destination address. Say Y if you want to copy entire image (including
+ its image header).
+
 config SPL_ONENAND_SUPPORT
bool "Support OneNAND flash"
depends on SPL
diff --git a/common/spl/spl_nor.c b/common/spl/spl_nor.c
index 6bfa399..44f3e99 100644
--- a/common/spl/spl_nor.c
+++ b/common/spl/spl_nor.c
@@ -10,13 +10,15 @@
 static int spl_nor_load_image(struct spl_image_info *spl_image,
  struct spl_boot_device *bootdev)
 {
+   void *img_src;
int ret;
+#ifndef CONFIG_SPL_NOR_COPY_ENTIRE_IMAGE
/*
 * Loading of the payload to SDRAM is done with skipping of
 * the mkimage header in this SPL NOR driver
 */
spl_image->flags |= SPL_COPY_PAYLOAD_ONLY;
-
+#endif
 #ifdef CONFIG_SPL_OS_BOOT
if (!spl_start_uboot()) {
const struct image_header *header;
@@ -65,9 +67,13 @@ static int spl_nor_load_image(struct spl_image_info 
*spl_image,
if (ret)
return ret;
 
+   img_src = (void *)CONFIG_SYS_UBOOT_BASE;
+#ifndef CONFIG_SPL_NOR_COPY_ENTIRE_IMAGE
+   img_src += sizeof(struct image_header));
+#endif
+
memcpy((void *)(unsigned long)spl_image->load_addr,
-  (void *)(CONFIG_SYS_UBOOT_BASE + sizeof(struct image_header)),
-  spl_image->size);
+  img_src, spl_image->size);
 
return 0;
 }
-- 
2.1.4

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

Re: [U-Boot] [Resend RFC PATCH v1 0/3] GPT over MTD

[Patrick DELAUNAY]

Hi Ladislav,

> 
> Hi Patrick,
> 
> On Thu, Nov 24, 2016 at 02:14:22PM +, Patrick DELAUNAY wrote:
> > Hi Ladislav,
> >
> > >
> > > Hi,
> > >
> > > On Tue, Nov 22, 2016 at 02:24:39PM +0100, Patrick Delaunay wrote:
> > > >
> > > > I have a request to support GPT over MTD to be able to have
> > > > dynamic MTD informations without u-Boot
> > > environment(CONFIG_ENV_IS_NOWHERE is a
> > > > other requirement of my project).
> > >
> > > I'm just curious, could you provide some reasoning, why this is a
> > > requirement?
> >
> > One platform requirement is to boot from any supported device (NOR,
> NAND, eMMC, ...) with the same boot chain (including SPL and U-Boot)
> WITHOUT recompilation and only by changing the hardware boot
> configuration (OTP).
> 
> Ok, the very same requirement here...
> 
> > So I can't use environment (CONFIG_ENV_IS_NOWHERE), because I don't
> know which device is expected for tests (boot from NAND,  eMMC, NOR).
> > PS: I agree that in final client board, the u-boot will be optimized and u-
> boot env could be used.
> >
> > For  block device(eMMC), it is not an issue
> > -  first boot stage uses the GPT header in block device,  to found, load
> and execute SPL and U-Boot.
> > -  U-Boot Generic Distro feature is used in U-Boot to
> > load kernel (found extlinux.conf in bootable partition)
> >
> > For Flash Device, the offset for SPL and U-Boot can't be determined easily
> by first boot stage.
> 
> Offset of SPL? Isn't that determined by boot ROM code? So you actually
> cannot do much with that. What hardware are you planning to use your
> solution with?

Not necessarily, we may have a first stage boot loader (let's say ARM Trusted 
Firmware) loaded by the ROM code before SPL execution.
Then SPL is executed as plugin, without Flash driver only to initialize DDR (as 
FEL for sunxi platform or bootrom plugin for mvebu) 
The HW used is a board based on the STMicroelectronics 96Board with STiH410 soc 
(ARM core).

> > It is why GPT is re-used to save MTD partition offset without hardcoded
> part in first boot stage or in SPL (and without U-Boot env).
> > => partition offsets are determined dynamically
> 
> As SPL offset is given and only U-Boot offset can be changed (is that
> assumption right?), you can store U-Boot in UBI volume.
> 

With SPL executed as plugin, U-Boot is loaded by first boot loader, which 
support GPT but not UBI...

> > So it should be easier to have the same behavior, based on GPT, for every
> boot device, block or flash.
> > And the same tools (programmer) or command in U-Boot will use to
> update/read every device, based on GPT header.
> 
> I have to admit, that UBI solution would not let you use the same scenario for
> eMMC and NAND in terms of U-Boot commands used, but otherwise it is
> more robust.
> 
> > > > The idea is to use the GPT header to save partitioning information
> > > > directly in flash device (NOR or NAND), then the MTD variables are
> > > > rebuild from these GPT partitions and can be used by DISTRO to
> > > > search
> > > bootable binary.
> > >
> > > Ok, so you stored partitioning information on flash... That seems to
> > > be some kind of limited environment saved :-)
> >
> > Yes I use standard GPT to save partitioning information, to save offset of
> MTD partition in flash device.
> > So it is limited environment :-) but limited to partition offset and it can 
> > be
> discovered dynamically by first boot stage.
> 
> First boot stage is SPL here?

Not necessary, SPL is loaded and executed as plugin by first boot stage...

> 
> > > > I make a first prototyping for this request but I want ask you if
> > > > this feature is acceptable for u-boot and if this patches, after
> > > > some update and cleanups, would be merged in u-boot mainline.
> > > > Do you see already some blocking points ?
> > >
> > > Is there any reason why you cannot use UBI?
> >
> > UBIFS will be used in U-Boot not in previous boot stage
> 
> Just to make it completely clear: UBIFS is a filesystem used on the top of UBI
> volume...
> 
> > Kernel and device tree will be found in a UBIFS volume
> 
> ...so kernel and DTB are stored as a files inside UBIFS (filesystem)?
> 
> Both SPL and U-Boot can load images from UBI volumes. Also you'll get
> Falcon mode for free :-)

In our case, when SPL is loaded as plugin, without file system and flash driver 
support, the FALCON mode is not possible :-<

The expected Flash layout is 

MTD partition1 => First Boot stage (with Flash driver / GPT support)
MTD partition2 => U-Boot SPL (only DDR init)
MTD partition3 => U-Boot (UBI / UBIFS stage)
MTD partition4 => UBI (several volume : boot, kernel used by u-boot)

- First boot stage is loaded by ROM in internal RAM
- SPL is loaded as plugin to initialize DDR
- Uboot is loaded in DDR by First Boot Stage / found UBI volume 

=> my issue is : how to found MTD offset if they are not hardcoded in U-Boot 
and First Boot Stage ?

> Best regards,
> 

Re: [U-Boot] [PATCH v2 2/4] davinci: omapl138_lcdk: configure ddr2

[Tom Rini]

On Mon, Nov 28, 2016 at 02:38:34PM +0100, Fabien Parent wrote:
> On Tue, Nov 22, 2016 at 7:10 PM, Tom Rini  wrote:
> > On Tue, Nov 22, 2016 at 06:13:31PM +0100, Fabien Parent wrote:
> >
> >> The SPL is unable to load u-boot because the DDR2 is not configured.
> >> Configure the DDR2.
> >>
> >> Signed-off-by: Fabien Parent 
> >> ---
> >>
> >> V1 -> V2
> >>
> >> * New patch
> >>
> >> ---
> >>  include/configs/omapl138_lcdk.h | 42 
> >> +
> >>  1 file changed, 42 insertions(+)
> >>
> >> diff --git a/include/configs/omapl138_lcdk.h 
> >> b/include/configs/omapl138_lcdk.h
> >> index ce3a8f4..2cdf892 100644
> >> --- a/include/configs/omapl138_lcdk.h
> >> +++ b/include/configs/omapl138_lcdk.h
> >> @@ -31,6 +31,7 @@
> >>  #define CONFIG_SYS_HZ_CLOCK  clk_get(DAVINCI_AUXCLK_CLKID)
> >>  #define CONFIG_SYS_HZ1000
> >>  #define CONFIG_SYS_DA850_PLL_INIT
> >> +#define CONFIG_SYS_DA850_DDR_INIT
> >>  #define CONFIG_SKIP_LOWLEVEL_INIT
> >>  #define CONFIG_SYS_TEXT_BASE 0xc108
> >
> > This would be "easy" to move to Kconfig, so please do.
> >
> >> @@ -80,6 +81,47 @@
> >>  #define CONFIG_SYS_DA850_PLL1_PLLM 21
> >>
> >>  /*
> >> + * DDR2 memory configuration
> >> + */
> >> +#define CONFIG_SYS_DA850_DDR2_DDRPHYCR (DV_DDR_PHY_PWRDNEN | \
> >> + DV_DDR_PHY_EXT_STRBEN | \
> >> + (0x5 << DV_DDR_PHY_RD_LATENCY_SHIFT))
> >> +
> >> +#define CONFIG_SYS_DA850_DDR2_SDBCR (  \
> >> + (1 << DV_DDR_SDCR_DDR2EN_SHIFT) | \
> >> + (1 << DV_DDR_SDCR_DDREN_SHIFT)  | \
> >> + (1 << DV_DDR_SDCR_SDRAMEN_SHIFT)| \
> >> + (1 << DV_DDR_SDCR_BUS_WIDTH_SHIFT)  | \
> >> + (4 << DV_DDR_SDCR_CL_SHIFT) | \
> >> + (3 << DV_DDR_SDCR_IBANK_SHIFT)  | \
> >> + (2 << DV_DDR_SDCR_PAGESIZE_SHIFT))
> >> +
> >> +/* SDBCR2 is only used if IBANK_POS bit in SDBCR is set */
> >> +#define CONFIG_SYS_DA850_DDR2_SDBCR2 0
> >> +
> >> +#define CONFIG_SYS_DA850_DDR2_SDTIMR ( \
> >> + (19 << DV_DDR_SDTMR1_RFC_SHIFT) | \
> >> + (1 << DV_DDR_SDTMR1_RP_SHIFT)   | \
> >> + (1 << DV_DDR_SDTMR1_RCD_SHIFT)  | \
> >> + (2 << DV_DDR_SDTMR1_WR_SHIFT)   | \
> >> + (6 << DV_DDR_SDTMR1_RAS_SHIFT)  | \
> >> + (8 << DV_DDR_SDTMR1_RC_SHIFT)   | \
> >> + (1 << DV_DDR_SDTMR1_RRD_SHIFT)  | \
> >> + (1 << DV_DDR_SDTMR1_WTR_SHIFT))
> >> +
> >> +#define CONFIG_SYS_DA850_DDR2_SDTIMR2 (\
> >> + (7 << DV_DDR_SDTMR2_RASMAX_SHIFT)   | \
> >> + (2 << DV_DDR_SDTMR2_XP_SHIFT)   | \
> >> + (0 << DV_DDR_SDTMR2_ODT_SHIFT)  | \
> >> + (10 << DV_DDR_SDTMR2_XSNR_SHIFT)| \
> >> + (199 << DV_DDR_SDTMR2_XSRD_SHIFT)   | \
> >> + (1 << DV_DDR_SDTMR2_RTP_SHIFT)  | \
> >> + (2 << DV_DDR_SDTMR2_CKE_SHIFT))
> >> +
> >> +#define CONFIG_SYS_DA850_DDR2_SDRCR0x0492
> >> +#define CONFIG_SYS_DA850_DDR2_PBBPR0x30
> >
> > This is a little harder.  I think this should be done more like
> > arch/arm/include/asm/arch-omap3/mem.h:#define where we name-space the
> > values that we construct based on the part (maker and size/speed).  Do
> > you have time to look into this migration?  Thanks!
> 
> Given that I don't have a lot of time right now, in the v3 I will just
> move CONFIG_SYS_DA850_DDR_INIT to Kconfig and keep all the config in
> the header file and at a later time once my current work on
> OMAPl138-LCDK is over I will sent a new patchset for all the
> CONFIG_SYS_DA85_DDR* options.

OK, thanks!

-- 
Tom


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

Re: [U-Boot] [Resend RFC PATCH v1 1/3] add support of GPT partitioning over MTD

[Patrick DELAUNAY]

Hi Simon,

> 
> Hi Patrick,
> 
> On 24 November 2016 at 03:27, Patrick DELAUNAY
>  wrote:
> > Hi Simon,
> >
> >>
> >> Hi Patrick,
> >>
> >> On 22 November 2016 at 06:24, Patrick Delaunay
> >>  wrote:
> >> > From: Patrick Delaunay 
> >> >
> >> > Signed-off-by: Patrick Delaunay 
> >> > Signed-off-by: Patrick Delaunay 
> >> > ---
> >> >
> >> >  Kconfig|  12 ++
> >> >  cmd/gpt.c  |  98 --
> >> >  cmd/mtdparts.c | 103 ++-
> >> >  cmd/part.c |  48 -
> >> >  disk/part_efi.c| 526
> >> -
> >> >  doc/README.gpt.mtd | 189 +++
> >> >  include/part.h |  13 +-
> >> >  include/uuid.h |   1 +
> >> >  lib/uuid.c |  33 
> >> >  9 files changed, 944 insertions(+), 79 deletions(-)  create mode
> >> > 100644 doc/README.gpt.mtd
> >>
> >> General comments:
> >>
> >> - use 'U-Boot' consistently rather than variations
> >> - can you split your large function up a bit?
> >> - can you make a precursor patch to refactor things, so reducing the
> >> size of this one?
> >
> > Yes, I will do this split in v2 to reduce each patch size:
> > - one patch to uuid new function
> > - one precursor for efi part : refactor
> > - one patch for GPT over MTD in part_efi.c
> > & I will split large function
> > - one patch for each command update
> >
> >> - nice README!
> >>
> >> >
> >> > diff --git a/Kconfig b/Kconfig
> >> > index 1263d0b..c2388e1 100644
> >> > --- a/Kconfig
> >> > +++ b/Kconfig
> >> > @@ -335,6 +335,18 @@ config ARCH_FIXUP_FDT
> >> >
> >> >  endmenu# Boot images
> >> >
> >> > +config EFI_PARTITION_MTD
> >> > +   bool "Support GPT over MTD"
> >> > +   help
> >> > + The GPT partition is normally defined only for block device 
> >> > with
> >> > + built-in controller which manage flash translation layer
> >> > + This option activate the GPT partition support over RAW device
> >> > + using the MTD framework
> >> > + - manage partition over MTD devices (as flash: NOR and NAND)
> >> > + - extract MTD information
> >> > + - update command gpt, mtdparts and part
> >> > + NB: depends on EFI_PARTITION
> >>
> >> So do you want 'depends on EFI_PARTITION'?
> >
> > Yes I expect it, I try to add
> > depends on EFI_PARTITION
> > but is not working as it is not (yet ?)  one KCONFIG option.
> > I add this comment to add this line when part lib will integrate
> > KCONFIG
> 
> I see. Well if you have the energy you could use moveconfig.py to convert it.

I will try to propose something (first usage of moveconfig.py script...)
if I have no issue with cross-compilation

=>  Create "disk/Kconfig" with PARTITIONS all associated option
(MAC_PARTITION, DOS_PARTITION, ISO_PARTITION, AMIGA_PARTITION, EFI_PARTITION)


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

Re: [U-Boot] Macronix NOR_SPI and Quad I/O

[Bacrau, Dumitru]

Hi guys,

I do have Macronix parts and Quad capability. Unfortunately I am not using the 
latest U-Boot code (but looks similar) and also I do not have much time today 
and tomorrow.

Would it be OK if you waited until Wednesday so I can investigate and test 
this? If it is urgent go ahead and do what you need to, then we can add Quad 
later.

Thanks,
Radu

-Original Message-
From: Champ, Andy [mailto:andyc...@amazon.co.uk] 
Sent: Monday, November 28, 2016 4:00 AM
To: Jagan Teki 
Cc: u-boot@lists.denx.de; jt...@openedev.com; radu.bac...@gmail.com; 
cl...@altera.com; Bacrau, Dumitru 
Subject: Re: [U-Boot] Macronix NOR_SPI and Quad I/O

I don't have anything that does Quad IO, so I can't test it either.

I think the best thing to do is to disable it for the Macronix parts, and put a 
comment in the table explaining why. With any luck one day somebody somewhere 
will have a device with a Macronix chip and quad I/O, and they can do it 
properly.

If this sounds good I'll put a patch together, run it past our open source 
lawyers (I'm not allowed to just push!) and send it through.

Alternatively I could put together a patch that sets a different flag bit for 
Macronix Quad I/O and push that. The only thing is of course that I have no way 
to test it, and as we all know untested code never works.

Which way should I go?

Regards
Andy Champ

From: Jagan Teki 
Sent: 26 November 2016 03:13
To: Champ, Andy
Cc: u-boot@lists.denx.de; jt...@openedev.com; radu.bac...@gmail.com; 
cl...@altera.com; dumitru.bac...@intel.com
Subject: Re: [U-Boot] Macronix NOR_SPI and Quad I/O

On Fri, Nov 25, 2016 at 10:07 PM, Champ, Andy  wrote:
> Hi all,
>
>
> in the table in drivers/mtd/spi/spi_flash_ids.c there is a flag WR_QPP set 
> against Macronix devices (including the ones Dumitru is just adding).
>
>
> This is used when programming the devices on a 4-bit bus to select the 
> command to use for programming - either CMD_QUAD_PAGE_PROGRAM (0x32) or 
> CMD_PAGE_PROGRAM (0x2).
>
>
> The Macronix devices that I have a spec for do not mention command 0x32. Each 
> of the devices that I have a spec for ( MX25L25635F MX25U51245G MX25V8035F 
> and MX25V1635F ) use command 0x38 instead.

We need to fix this, till now no Macronix has been tested with QUAD I think, 
please send the suitable fix will review.

thanks!
--
Jagan Teki
Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream Maintainer 
Hyderabad, India.

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

Re: [U-Boot] Macronix NOR_SPI and Quad I/O

[Champ, Andy]

Hi Radu,
As far as I am concerned there is no urgency at all.
I just happened to notice as I was looking through the code that the command 
does not agree with the Macronix device spec, and I thought I should tell 
someone! Our device does not support Quad I/O.

Thanks
Andy Champ

-Original Message-
From: Bacrau, Dumitru [mailto:dumitru.bac...@intel.com] 
Sent: 28 November 2016 15:50
To: Champ, Andy ; Jagan Teki 
Cc: u-boot@lists.denx.de; jt...@openedev.com; radu.bac...@gmail.com; 
cl...@altera.com
Subject: RE: [U-Boot] Macronix NOR_SPI and Quad I/O

Hi guys,

I do have Macronix parts and Quad capability. Unfortunately I am not using the 
latest U-Boot code (but looks similar) and also I do not have much time today 
and tomorrow.

Would it be OK if you waited until Wednesday so I can investigate and test 
this? If it is urgent go ahead and do what you need to, then we can add Quad 
later.

Thanks,
Radu

-Original Message-
From: Champ, Andy [mailto:andyc...@amazon.co.uk] 
Sent: Monday, November 28, 2016 4:00 AM
To: Jagan Teki 
Cc: u-boot@lists.denx.de; jt...@openedev.com; radu.bac...@gmail.com; 
cl...@altera.com; Bacrau, Dumitru 
Subject: Re: [U-Boot] Macronix NOR_SPI and Quad I/O

I don't have anything that does Quad IO, so I can't test it either.

I think the best thing to do is to disable it for the Macronix parts, and put a 
comment in the table explaining why. With any luck one day somebody somewhere 
will have a device with a Macronix chip and quad I/O, and they can do it 
properly.

If this sounds good I'll put a patch together, run it past our open source 
lawyers (I'm not allowed to just push!) and send it through.

Alternatively I could put together a patch that sets a different flag bit for 
Macronix Quad I/O and push that. The only thing is of course that I have no way 
to test it, and as we all know untested code never works.

Which way should I go?

Regards
Andy Champ

From: Jagan Teki 
Sent: 26 November 2016 03:13
To: Champ, Andy
Cc: u-boot@lists.denx.de; jt...@openedev.com; radu.bac...@gmail.com; 
cl...@altera.com; dumitru.bac...@intel.com
Subject: Re: [U-Boot] Macronix NOR_SPI and Quad I/O

On Fri, Nov 25, 2016 at 10:07 PM, Champ, Andy  wrote:
> Hi all,
>
>
> in the table in drivers/mtd/spi/spi_flash_ids.c there is a flag WR_QPP set 
> against Macronix devices (including the ones Dumitru is just adding).
>
>
> This is used when programming the devices on a 4-bit bus to select the 
> command to use for programming - either CMD_QUAD_PAGE_PROGRAM (0x32) or 
> CMD_PAGE_PROGRAM (0x2).
>
>
> The Macronix devices that I have a spec for do not mention command 0x32. Each 
> of the devices that I have a spec for ( MX25L25635F MX25U51245G MX25V8035F 
> and MX25V1635F ) use command 0x38 instead.

We need to fix this, till now no Macronix has been tested with QUAD I think, 
please send the suitable fix will review.

thanks!
--
Jagan Teki
Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream Maintainer 
Hyderabad, India.


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

Re: [U-Boot] [RFC PATCH 0/3] spl: Add D-cache support

[Tom Rini]

On Mon, Nov 28, 2016 at 03:04:42PM +0530, Lokesh Vutla wrote:

> This series tries to add D-cache support in spl in order to reduce boot time
> either in 2stage boot or Falcon Boot.

I assume you've measured and confirmed that there is a speed increase?
I ask since I'd tried this ages ago but..

> 
> Lokesh Vutla (3):
>   arch: arm: omap: Declare size of ddr very early
>   spl: reorder the assignment of board info to global data

... I didn't have changes like this, which is perhaps why it ended up
not working right.  Thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] SPL: NOR: Add CONFIG_SPL_NOR_COPY_ENTIRE_IMAGE define to enable whole image copy from NOR

[Tom Rini]

On Mon, Nov 28, 2016 at 01:43:44PM +0100, Marek Vasut wrote:
> On 11/28/2016 07:27 AM, Lukasz Majewski wrote:
> > This define gives the possibility to copy entire image (including header)
> > from NOR parallel memory to e.g. SDRAM.
> > 
> > The legacy behavior is preserved, since other board don't enabled this 
> > option.
> > 
> > Signed-off-by: Lukasz Majewski 
> 
> What is the usecase ?

This is actually a v2, and the answer from v1 is at
http://lists.denx.de/pipermail/u-boot/2016-September/267019.html and
should be more prominent in the commit message / help text (so, v3
please!).  Without this option u-boot.img doesn't work from NOR, only
u-boot.bin

-- 
Tom


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

Re: [U-Boot] [PATCH 1/5] davinci: omapl138_lcdk: fixup mac address in dtb

[Tom Rini]

On Fri, Nov 25, 2016 at 11:11:23AM +0100, Fabien Parent wrote:
> In order to avoid having a random mac address assigned by Linux, let's
> fixup the dtb with the mac address that was programmed in the EEPROM.
> 
> Signed-off-by: Fabien Parent 
> ---
>  board/davinci/da8xxevm/omapl138_lcdk.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/board/davinci/da8xxevm/omapl138_lcdk.c 
> b/board/davinci/da8xxevm/omapl138_lcdk.c
> index 9c1a483..8a29748 100644
> --- a/board/davinci/da8xxevm/omapl138_lcdk.c
> +++ b/board/davinci/da8xxevm/omapl138_lcdk.c
> @@ -10,6 +10,7 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -371,3 +372,12 @@ int board_mmc_init(bd_t *bis)
>   return davinci_mmc_init(bis, &mmc_sd0);
>  }
>  #endif
> +
> +#if defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_SYSTEM_SETUP)
> +int ft_system_setup(void *blob, bd_t *bd)
> +{
> + fdt_fixup_ethernet(blob);
> +
> + return 0;
> +}
> +#endif

I don't understand why this is needed.  CONFIG_LMB should be set so
image_setup_linux will be called which will call image_setup_libfdt
which will call fdt_fixup_ethernet along with other stuff we'd want done
as well.  I suspect we have some bug somewhere along the line with
regards to pre ARMv7 platforms and FDT where some knob or another that
should be set, is not set.

-- 
Tom


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

Re: [U-Boot] [RFC PATCH 1/3] arch: arm: omap: Declare size of ddr very early

[Tom Rini]

On Mon, Nov 28, 2016 at 03:04:43PM +0530, Lokesh Vutla wrote:

> Declare the size of ddr very early in spl, so that this can be
> used to enable cache.
> 
> Signed-off-by: Lokesh Vutla 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [RFC PATCH 3/3] spl: Add support for enabling dcache

[Tom Rini]

On Mon, Nov 28, 2016 at 03:04:45PM +0530, Lokesh Vutla wrote:

> Add support for enabling d-cache in SPL. The sequence in SPL tries to
> replicate the sequence done in U-Boot except that MMU entries were added
> for SRAM.
> 
> Signed-off-by: Lokesh Vutla 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [RFC PATCH 2/3] spl: reorder the assignment of board info to global data

[Tom Rini]

On Mon, Nov 28, 2016 at 03:04:44PM +0530, Lokesh Vutla wrote:

> Move the assignment of board info to global data a bit early which is safe,
> so that ram details can be used to enable caches.
> 
> Signed-off-by: Lokesh Vutla 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 2/5] davinci: omapl138_lcdk: improve readability of boot command

[Tom Rini]

On Fri, Nov 25, 2016 at 11:11:24AM +0100, Fabien Parent wrote:

> Improve the readability of the boot command. This will help a later
> commit that adds support for dtb and system setup.
> 
> Signed-off-by: Fabien Parent 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 3/5] davinci: omapl138_lcdk: add DT support for EMMC boot

[Tom Rini]

On Fri, Nov 25, 2016 at 11:11:25AM +0100, Fabien Parent wrote:

> When booting from EMMC, load the DTB and pass it to the kernel.
> 
> Signed-off-by: Fabien Parent 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH] SPL: NOR: Add CONFIG_SPL_NOR_COPY_ENTIRE_IMAGE define to enable whole image copy from NOR

[Marek Vasut]

On 11/28/2016 05:50 PM, Tom Rini wrote:
> On Mon, Nov 28, 2016 at 01:43:44PM +0100, Marek Vasut wrote:
>> On 11/28/2016 07:27 AM, Lukasz Majewski wrote:
>>> This define gives the possibility to copy entire image (including header)
>>> from NOR parallel memory to e.g. SDRAM.
>>>
>>> The legacy behavior is preserved, since other board don't enabled this 
>>> option.
>>>
>>> Signed-off-by: Lukasz Majewski 
>>
>> What is the usecase ?
> 
> This is actually a v2, and the answer from v1 is at
> http://lists.denx.de/pipermail/u-boot/2016-September/267019.html and
> should be more prominent in the commit message / help text (so, v3
> please!).  Without this option u-boot.img doesn't work from NOR, only
> u-boot.bin

Ah, I recall this issue, thanks!

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

Re: [U-Boot] [PATCH v4 0/6] Add ARMv8 PSCI framework

[york sun]

On 11/25/2016 02:47 AM, Hongbo Zhang wrote:
> v3-v4 changes:
>  - Re-added the 1/6 from v2, and move the newly re-named macro into Kconfig
>  - Add "Reviewed-by: Tom Rini " for patch 4/6 ~ 6/6.
>
> v2-v3 changes:
>  - Drop the previous 1/6, since the previous CONFIG_ARMV8_PSCI in common parts
> of codes also work for generic PSCI framework, so there are 5 patches in this
> iteration.
>  - Add "Reviewed-by: Tom Rini " for patches 1/5 and 2/5,
> which were 2/6 and 3/6.
>  - Move config values for ls1043 from armv8/Kconfig to s1043ardb_defconfig.
>
> v1-v2 changes:
>  - The new config options are introduced in Kconfig when used for first time
>  - Introduce new config options in armv8/Kconfig instead of LS1043 platform
>  - Move previous patch 5/6 to current 2/6 place
>
> v1 notes:
>
> This patch set introduces ARMv8 PSCI framework, all the PSCI functions are
> implemented a default dummy one, it is up to each platform to implement their
> own specific ones.
>
> The first 1/6 patch is a prepare clean up for adding ARMv8 PSCI.
> Patches 2/6 to 5/6 introduce new ARMv8 framework and set it up.
> The last 6/6 adds a most simple implementation on NXP LS1043 platform, to
> verify this framework.
>
> This patch set mainly introduces ARMv8 PSCI framework, for easier review and
> merge, further PSCI implementation on LS1043 is coming later.
>

Hongbo,

Can you educate me how this generic PSCI framework co-exist with PPA or 
other secure firmware?

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

Re: [U-Boot] Macronix NOR_SPI and Quad I/O

[Bacrau, Dumitru]

Hi Andy,

I have double-checked the datasheets and indeed the Quad Page Program opcode 
for Macronix is 0x38 and not 0x32 like the U-Boot code has defined in 
CMD_QUAD_PAGE_PROGRAM.

My version of the code is similar to the current u-boot mainline, and it also 
has the WR_QPP flag. But its usage depends on another flag that never gets set, 
so basically I have never used Quad mode for writing in my testing.

In the latest U-Boot code from u-boot-spi the situation is similar, except the 
above parameter is retrieved from the U-Boot device tree parameter  
"spi-tx-bus-width". But none of the device trees set that parameter to '4' so 
again the Quad mode is never used for writing anyway.

Note that Quad mode is very useful for reading, where it effectively quadruples 
the speed. But in case of writing, it only speeds up data transmission to the 
flash device, which then starts writing, and the host keeps polling it for 
completion. Because of this, there is not a lot to gain from using quad mode 
for writing.

Ideally we would need a way to convey that the Macronix devices use a different 
instruction opcode for quad writing. This could be in spi_flash_info structure 
or somewhere in the device tree.

Regards,
Radu

-Original Message-
From: Champ, Andy [mailto:andyc...@amazon.co.uk] 
Sent: Monday, November 28, 2016 9:59 AM
To: Bacrau, Dumitru ; Jagan Teki 
Cc: u-boot@lists.denx.de; jt...@openedev.com; radu.bac...@gmail.com; 
cl...@altera.com
Subject: RE: [U-Boot] Macronix NOR_SPI and Quad I/O

Hi Radu,
As far as I am concerned there is no urgency at all.
I just happened to notice as I was looking through the code that the command 
does not agree with the Macronix device spec, and I thought I should tell 
someone! Our device does not support Quad I/O.

Thanks
Andy Champ

-Original Message-
From: Bacrau, Dumitru [mailto:dumitru.bac...@intel.com] 
Sent: 28 November 2016 15:50
To: Champ, Andy ; Jagan Teki 
Cc: u-boot@lists.denx.de; jt...@openedev.com; radu.bac...@gmail.com; 
cl...@altera.com
Subject: RE: [U-Boot] Macronix NOR_SPI and Quad I/O

Hi guys,

I do have Macronix parts and Quad capability. Unfortunately I am not using the 
latest U-Boot code (but looks similar) and also I do not have much time today 
and tomorrow.

Would it be OK if you waited until Wednesday so I can investigate and test 
this? If it is urgent go ahead and do what you need to, then we can add Quad 
later.

Thanks,
Radu

-Original Message-
From: Champ, Andy [mailto:andyc...@amazon.co.uk] 
Sent: Monday, November 28, 2016 4:00 AM
To: Jagan Teki 
Cc: u-boot@lists.denx.de; jt...@openedev.com; radu.bac...@gmail.com; 
cl...@altera.com; Bacrau, Dumitru 
Subject: Re: [U-Boot] Macronix NOR_SPI and Quad I/O

I don't have anything that does Quad IO, so I can't test it either.

I think the best thing to do is to disable it for the Macronix parts, and put a 
comment in the table explaining why. With any luck one day somebody somewhere 
will have a device with a Macronix chip and quad I/O, and they can do it 
properly.

If this sounds good I'll put a patch together, run it past our open source 
lawyers (I'm not allowed to just push!) and send it through.

Alternatively I could put together a patch that sets a different flag bit for 
Macronix Quad I/O and push that. The only thing is of course that I have no way 
to test it, and as we all know untested code never works.

Which way should I go?

Regards
Andy Champ

From: Jagan Teki 
Sent: 26 November 2016 03:13
To: Champ, Andy
Cc: u-boot@lists.denx.de; jt...@openedev.com; radu.bac...@gmail.com; 
cl...@altera.com; dumitru.bac...@intel.com
Subject: Re: [U-Boot] Macronix NOR_SPI and Quad I/O

On Fri, Nov 25, 2016 at 10:07 PM, Champ, Andy  wrote:
> Hi all,
>
>
> in the table in drivers/mtd/spi/spi_flash_ids.c there is a flag WR_QPP set 
> against Macronix devices (including the ones Dumitru is just adding).
>
>
> This is used when programming the devices on a 4-bit bus to select the 
> command to use for programming - either CMD_QUAD_PAGE_PROGRAM (0x32) or 
> CMD_PAGE_PROGRAM (0x2).
>
>
> The Macronix devices that I have a spec for do not mention command 0x32. Each 
> of the devices that I have a spec for ( MX25L25635F MX25U51245G MX25V8035F 
> and MX25V1635F ) use command 0x38 instead.

We need to fix this, till now no Macronix has been tested with QUAD I think, 
please send the suitable fix will review.

thanks!
--
Jagan Teki
Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream Maintainer 
Hyderabad, India.


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

Re: [U-Boot] [PATCH 4/5] davinci: omapl138_lcdk: do fdt systemsetup when loading DT

[Tom Rini]

On Fri, Nov 25, 2016 at 11:11:26AM +0100, Fabien Parent wrote:

> When loading the DTB, let's also do the systemsetup in order to patch
> the DT with the mac address.
> 
> Signed-off-by: Fabien Parent 

Like the first patch, we shouldn't need to do this, something deeper
must be wrong...

-- 
Tom


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

Re: [U-Boot] Macronix NOR_SPI and Quad I/O

[Champ, Andy]

Hi Radu,

It seems to me there are two approaches:
- Set a different flag for this different command
- Check the manufacturer ID before selecting the command.
Either way the data we'd need is in the params variable, nicely to hand.

The code I've been working on is for write protecting Macronix and WInbond 
NOR-SPI devices; I'll publish that at some point. The write protect code has 
callbacks, which probably makes sense when the handling is more complex - the 
commands, and the areas you can protect, are both different on a 
per-manufacturer basis.

A flag is nice and simple, which is good given that nobody needs this right 
now. I do wonder if quad writes are worth doing at all - in which case the fix 
is /really/ simple. Remove the code, and the flag!

As I said, I don't need this - it's just that I don't like to see broken code 
lying around.

Thanks
Andy Champ

-Original Message-
From: Bacrau, Dumitru [mailto:dumitru.bac...@intel.com] 
Sent: 28 November 2016 17:33
To: Champ, Andy ; Jagan Teki 
Cc: u-boot@lists.denx.de; jt...@openedev.com; radu.bac...@gmail.com; 
cl...@altera.com
Subject: RE: [U-Boot] Macronix NOR_SPI and Quad I/O

Hi Andy,

I have double-checked the datasheets and indeed the Quad Page Program opcode 
for Macronix is 0x38 and not 0x32 like the U-Boot code has defined in 
CMD_QUAD_PAGE_PROGRAM.

My version of the code is similar to the current u-boot mainline, and it also 
has the WR_QPP flag. But its usage depends on another flag that never gets set, 
so basically I have never used Quad mode for writing in my testing.

In the latest U-Boot code from u-boot-spi the situation is similar, except the 
above parameter is retrieved from the U-Boot device tree parameter  
"spi-tx-bus-width". But none of the device trees set that parameter to '4' so 
again the Quad mode is never used for writing anyway.

Note that Quad mode is very useful for reading, where it effectively quadruples 
the speed. But in case of writing, it only speeds up data transmission to the 
flash device, which then starts writing, and the host keeps polling it for 
completion. Because of this, there is not a lot to gain from using quad mode 
for writing.

Ideally we would need a way to convey that the Macronix devices use a different 
instruction opcode for quad writing. This could be in spi_flash_info structure 
or somewhere in the device tree.

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

Re: [U-Boot] [U-Boot, 3/8] spl: Move the loading code into its own function

[Tom Rini]

On Thu, Nov 17, 2016 at 10:29:30AM -0700, Simon Glass wrote:

> Create a boot_from_devices() function to handle trying each device. This
> helps to reduce the size of the already-large board_init_r() function.
> 
> Signed-off-by: Simon Glass 

So with gcc-5.x and later:
+In file included from include/common.h:27:0,   
+ from common/spl/spl.c:9:  
+ #define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
+  ^
+common/spl/spl.c:384:18: note: in expansion of macro 'ARRAY_SIZE'
+  for (i = 0; i < ARRAY_SIZE(spl_boot_list) &&
+  ^
+common/spl/spl.c:380:13: note: declared here
+ u32 spl_boot_list[])
+ ^
w+common/spl/spl.c: In function 'boot_from_devices':
w+include/linux/kernel.h:45:30: warning: 'sizeof' on array function parameter 
'spl_boot_list' will return size of 'u32 * {aka unsigned int *}' 
[-Wsizeof-array-argument]

Which I think is what Masahiro was pointing out :)  So the rest of the
series needs some re-work following that too, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, 3/8] spl: Move the loading code into its own function

[Simon Glass]

Hi Tom,

On 28 November 2016 at 13:09, Tom Rini  wrote:
> On Thu, Nov 17, 2016 at 10:29:30AM -0700, Simon Glass wrote:
>
>> Create a boot_from_devices() function to handle trying each device. This
>> helps to reduce the size of the already-large board_init_r() function.
>>
>> Signed-off-by: Simon Glass 
>
> So with gcc-5.x and later:
> +In file included from include/common.h:27:0, 
>   + from common/spl/spl.c:9:  
> + #define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
> +  ^
> +common/spl/spl.c:384:18: note: in expansion of macro 'ARRAY_SIZE'
> +  for (i = 0; i < ARRAY_SIZE(spl_boot_list) &&
> +  ^
> +common/spl/spl.c:380:13: note: declared here
> + u32 spl_boot_list[])
> + ^
> w+common/spl/spl.c: In function 'boot_from_devices':
> w+include/linux/kernel.h:45:30: warning: 'sizeof' on array function parameter 
> 'spl_boot_list' will return size of 'u32 * {aka unsigned int *}' 
> [-Wsizeof-array-argument]
>
> Which I think is what Masahiro was pointing out :)  So the rest of the
> series needs some re-work following that too, thanks!

Yes indeed, will get to it this week...need to test it properly with a
board with multiple loaders.

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

[U-Boot] static var mem alignment issue/question

[Tim Harvey]

Greetings,

In debugging an issue with a rather old branch of U-Boot (2015-04) I
found that the static assignment of a data buffer was not 32-bit
aligned which caused data aborts. However I find that current U-boot
master does not suffer this issue and no matter what I declare static
before the particular variable its always 32-bit aligned. I don't see
any code changes that would cause this and in both cases I'm building
with the same gcc5.2.0 toolchain.

The code in question is this this from cmd/fdt.c:

} else if (argv[1][0] == 's') {
char *pathp;/* path */
char *prop; /* property */
int  nodeoffset;/* node offset from libfdt */
static char data[SCRATCHPAD];   /* storage for the property */
int  len;   /* new length of the property */
int  ret;

What guarantee's that 'data' above is 32-bit aligned in master that is
missing from the older U-Boot branch I'm using? Perhaps there is some
arg in a Makefile that I'm missing?

Regards,

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

Re: [U-Boot] [PATCH] SPL: NOR: Add CONFIG_SPL_NOR_COPY_ENTIRE_IMAGE define to enable whole image copy from NOR

[Marek Vasut]

On 11/28/2016 10:09 PM, Lukasz Majewski wrote:
> This define gives the possibility to copy entire image (including header -
> e.g. u-boot.img) from NOR parallel memory to e.g. SDRAM. The current code
> only supports loading the raw binary image (the u-boot.bin).
> 
> The legacy behavior is preserved, since other board don't enabled this option.

So, what's the usecase again ? ;-) I still miss it being documented.

> Signed-off-by: Lukasz Majewski 
> ---
> Changes for v2:
> - Update to code to apply on v2016.11+
> Changes for v3:
> - Write better commit mesage to explain the problem
> 
> ---
>  common/spl/Kconfig   | 10 ++
>  common/spl/spl_nor.c | 12 +---
>  2 files changed, 19 insertions(+), 3 deletions(-)
> 
> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> index df9e0ce..d31b26d 100644
> --- a/common/spl/Kconfig
> +++ b/common/spl/Kconfig
> @@ -399,6 +399,16 @@ config SPL_NOR_SUPPORT
> a memory-mapped device makes it very easy to access. Loading from
> NOR is typically achieved with just a memcpy().
>  
> +config SPL_NOR_COPY_ENTIRE_IMAGE
> + bool
> + depends on SPL_NOR_SUPPORT
> + prompt "Copy entire image from NOR memory"
> + default n
> + help
> +   By default the SPL NOR driver supports copying only payload to
> +   destination address. Say Y if you want to copy entire image (including
> +   its image header).
> +
>  config SPL_ONENAND_SUPPORT
>   bool "Support OneNAND flash"
>   depends on SPL
> diff --git a/common/spl/spl_nor.c b/common/spl/spl_nor.c
> index 6bfa399..44f3e99 100644
> --- a/common/spl/spl_nor.c
> +++ b/common/spl/spl_nor.c
> @@ -10,13 +10,15 @@
>  static int spl_nor_load_image(struct spl_image_info *spl_image,
> struct spl_boot_device *bootdev)
>  {
> + void *img_src;
>   int ret;
> +#ifndef CONFIG_SPL_NOR_COPY_ENTIRE_IMAGE
>   /*
>* Loading of the payload to SDRAM is done with skipping of
>* the mkimage header in this SPL NOR driver
>*/
>   spl_image->flags |= SPL_COPY_PAYLOAD_ONLY;
> -
> +#endif
>  #ifdef CONFIG_SPL_OS_BOOT
>   if (!spl_start_uboot()) {
>   const struct image_header *header;
> @@ -65,9 +67,13 @@ static int spl_nor_load_image(struct spl_image_info 
> *spl_image,
>   if (ret)
>   return ret;
>  
> + img_src = (void *)CONFIG_SYS_UBOOT_BASE;
> +#ifndef CONFIG_SPL_NOR_COPY_ENTIRE_IMAGE
> + img_src += sizeof(struct image_header));
> +#endif
> +
>   memcpy((void *)(unsigned long)spl_image->load_addr,
> -(void *)(CONFIG_SYS_UBOOT_BASE + sizeof(struct image_header)),
> -spl_image->size);
> +img_src, spl_image->size);
>  
>   return 0;
>  }
> 


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

Re: [U-Boot] Rockchip RK3288 u-boot with mainline kernel

[Simon Glass]

+ A few rockchip people and linux-rockchip

Hi Rick,

On 25 November 2016 at 11:20, Rick Bronson  wrote:
> Hi All,
>
>   I've got unsupported RK3288 hardware running the latest git u-boot to
> SPL as explained in
> http://git.denx.de/?p=u-boot.git;a=blob;f=doc/README.rockchip.  My goal
> is to run the mainline (ie. not Android) Linux kernel on this hardware
> and wondered:
>
>  - Do I need to get the latest git u-boot to run before I can run the
> mainline kernel?  Or can I use
> github.com/linux-rockchip/u-boot-rockchip.git, which I have running
> u-boot fully.

It's up to you - obviously mainline is where the development should
be, but there is no requirement that I know of.

Does mainline run on your board?

>
>  - The device tree seems to be in two places, once via:
>
> resource_tool --image=resource2.img --pack linux/logo.bmp ${DTS}.dtb
>
>   that gets put into the resource file and then again at the end of the
> kernel via CONFIG_ARM_APPENDED_DTB.  Do I need both?  When I do both
> I get things like:
>
> 
> Unknow param: MACHINE_MODEL:rk30sdk!
> Unknow param: MACHINE_ID:007!

I don't know much about that. Hopefully someone on the linux-rockchip
list knows. But for mainline U-Boot I'm not sure why you would need
this?

> 
>
>   Thanks much for any help.
>
>   Rick Bronson
>
>

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

Re: [U-Boot] [PATCH v5 10/13] tegra: Use a U-Boot-specific .dtsi file

[Simon Glass]

Hi Stephen,

On 17 November 2016 at 12:45, Stephen Warren  wrote:
>
> On 11/16/2016 06:13 PM, Simon Glass wrote:
>>
>> With the new device-tree rules it is possible to put device-tree changes
>> needed by U-Boot into their own file. As an example of this approach, move
>> Tegra over to use it.
>
>
> Sounds like a good idea.
>
>> diff --git a/arch/arm/dts/tegra20-u-boot.dtsi 
>> b/arch/arm/dts/tegra20-u-boot.dtsi
>
>
>> +/ {
>> +   compatible = "nvidia,tegra20";
>> +   interrupt-parent = <&lic>;
>
>
> I don't think either of those lines is specific to U-Boot.

Yes they should not be there - fixed in v6.

>
> I'd expect to see more "U-Boot overlay" DTs than this; I recall there being 
> more differences between U-Boot and kernel DTS files when I last sync'd the 
> two.

Yes but most of those changes should be dropped. I did a partial sync
a few months back but if you recall there were still differences. Is
this something the Tegra maintainer might look at?

I don't want to immortalise those differences in a separate U-Boot
file when really we should just get rid of them.

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

Re: [U-Boot] [PATCH 08/14] mmc: Add JZ47xx SD/MMC controller driver

[Marek Vasut]

On 11/28/2016 03:58 AM, Jaehoon Chung wrote:
> Hi Marek,
> 
> On 11/26/2016 07:32 AM, Marek Vasut wrote:
>> From: Paul Burton 
>>
>> Add driver for the JZ47xx MSC controller.
> 
> There are some checkpatch error and warings. Could you fix them?

Yeah

> And i don't know what means MSC?

Me neither, probably MMC SD Controller .

>> Signed-off-by: Marek Vasut 
>> Cc: Daniel Schwierzeck 
>> Cc: Paul Burton 
>> ---
>>  drivers/mmc/Kconfig  |   6 +
>>  drivers/mmc/Makefile |   1 +
>>  drivers/mmc/jz_mmc.c | 443 
>> +++
>>  3 files changed, 450 insertions(+)
>>  create mode 100644 drivers/mmc/jz_mmc.c
>>
>> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
>> index aca438b8..761b886 100644
>> --- a/drivers/mmc/Kconfig
>> +++ b/drivers/mmc/Kconfig
>> @@ -102,6 +102,12 @@ config MMC_UNIPHIER
>>  help
>>This selects support for the SD/MMC Host Controller on UniPhier SoCs.
>>  
>> +config JZ47XX_MMC
>> +bool "Ingenic JZ47xx SD/MMC Host Controller support"
>> +depends on ARCH_JZ47XX
>> +help
>> +  This selects support for the SD Card Controller on Ingenic JZ47xx 
>> SoCs.
>> +
>>  config SANDBOX_MMC
>>  bool "Sandbox MMC support"
>>  depends on MMC && SANDBOX
>> diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
>> index d850758..5f7cca3 100644
>> --- a/drivers/mmc/Makefile
>> +++ b/drivers/mmc/Makefile
>> @@ -57,6 +57,7 @@ obj-$(CONFIG_TEGRA_MMC) += tegra_mmc.o
>>  obj-$(CONFIG_MMC_UNIPHIER) += uniphier-sd.o
>>  obj-$(CONFIG_ZYNQ_SDHCI) += zynq_sdhci.o
>>  obj-$(CONFIG_ROCKCHIP_SDHCI) += rockchip_sdhci.o
>> +obj-$(CONFIG_JZ47XX_MMC) += jz_mmc.o
>>  
>>  ifdef CONFIG_SPL_BUILD
>>  obj-$(CONFIG_SPL_MMC_BOOT) += fsl_esdhc_spl.o
>> diff --git a/drivers/mmc/jz_mmc.c b/drivers/mmc/jz_mmc.c
>> new file mode 100644
>> index 000..213fe63
>> --- /dev/null
>> +++ b/drivers/mmc/jz_mmc.c
>> @@ -0,0 +1,443 @@
>> +/*
>> + * Ingenic JZ MMC driver
>> + *
>> + * Copyright (c) 2013 Imagination Technologies
>> + * Author: Paul Burton 
>> + *
>> + * SPDX-License-Identifier: GPL-2.0+
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/* Registers */
>> +#define MSC_STRPCL  0x000
>> +#define MSC_STAT0x004
>> +#define MSC_CLKRT   0x008
>> +#define MSC_CMDAT   0x00c
>> +#define MSC_RESTO   0x010
>> +#define MSC_RDTO0x014
>> +#define MSC_BLKLEN  0x018
>> +#define MSC_NOB 0x01c
>> +#define MSC_SNOB0x020
>> +#define MSC_IMASK   0x024
>> +#define MSC_IREG0x028
>> +#define MSC_CMD 0x02c
>> +#define MSC_ARG 0x030
>> +#define MSC_RES 0x034
>> +#define MSC_RXFIFO  0x038
>> +#define MSC_TXFIFO  0x03c
>> +#define MSC_LPM 0x040
>> +#define MSC_DMAC0x044
>> +#define MSC_DMANDA  0x048
>> +#define MSC_DMADA   0x04c
>> +#define MSC_DMALEN  0x050
>> +#define MSC_DMACMD  0x054
>> +#define MSC_CTRL2   0x058
>> +#define MSC_RTCNT   0x05c
>> +#define MSC_DBG 0x0fc
>> +
>> +/* MSC Clock and Control Register (MSC_STRPCL) */
>> +
>> +#define MSC_STRPCL_EXIT_MULTIPLEBIT(7)
>> +#define MSC_STRPCL_EXIT_TRANSFERBIT(6)
>> +#define MSC_STRPCL_START_READWAIT   BIT(5)
>> +#define MSC_STRPCL_STOP_READWAITBIT(4)
>> +#define MSC_STRPCL_RESETBIT(3)
>> +#define MSC_STRPCL_START_OP BIT(2)
>> +#define MSC_STRPCL_CLOCK_CONTROL_STOP   BIT(0)
>> +#define MSC_STRPCL_CLOCK_CONTROL_START  BIT(1)
>> +
>> +/* MSC Status Register (MSC_STAT) */
>> +
>> +#define MSC_STAT_AUTO_CMD_DONE  BIT(31)
>> +#define MSC_STAT_IS_RESETTING   BIT(15)
>> +#define MSC_STAT_SDIO_INT_ACTIVEBIT(14)
>> +#define MSC_STAT_PRG_DONE   BIT(13)
>> +#define MSC_STAT_DATA_TRAN_DONE BIT(12)
>> +#define MSC_STAT_END_CMD_RESBIT(11)
>> +#define MSC_STAT_DATA_FIFO_AFULLBIT(10)
>> +#define MSC_STAT_IS_READWAITBIT(9)
>> +#define MSC_STAT_CLK_EN BIT(8)
>> +#define MSC_STAT_DATA_FIFO_FULL BIT(7)
>> +#define MSC_STAT_DATA_FIFO_EMPTYBIT(6)
>> +#define MSC_STAT_CRC_RES_ERRBIT(5)
>> +#define MSC_STAT_CRC_READ_ERROR BIT(4)
>> +#define MSC_STAT_CRC_WRITE_ERRORBIT(2)
>> +#define MSC_STAT_CRC_WRITE_ERROR_NOSTS  BIT(4)
>> +#define MSC_STAT_TIME_OUT_RES   BIT(1)
>> +#define MSC_STAT_TIME_OUT_READ  BIT(0)
>> +
>> +/* MSC Bus Clock Control Register (MSC_CLKRT) */
>> +#define MSC_CLKRT_CLK_RATE_MASK 0x7
>> +
>> +/* MSC Command Sequence Control Register (MSC_CMDAT) */
>> 

[U-Boot] [PATCH] arch: powerpc: Retain compatible property for L2 cache

[Chris Packham]

Instead of setting the compatible property to "cache", append the
desired value retaining what may already be set in the current property.

Signed-off-by: Chris Packham 
---
On Thu, Nov 24, 2016 at 6:41 AM, york sun  wrote:
> On 11/23/2016 01:43 AM, Chris Packham wrote:
>> Hi,
>>
>> I was just looking at what it would take to add the T2080 L2 cache to
>> the mpc85xx_edac driver in Linux. At a cursory glance all the
>> registers appear to be there so I figured I'd just add the
>> appropriate
>> entry to the of match table.
>>
>> To my surprise I found that the compatible string in my device tree
>> was overwritten with "cache". I've tracked this down to the
>> CONFIG_SYS_FSL_QORIQ_CHASSIS2 implementation of ft_fixup_l2cache in
>> u-boot.
>>
>> The CONFIG_L2_CACHE version seems to take care to update the device
>> tree node to
>>
>>   compatible = "fsl,t2080-l2-cache-controller", "cache";
>>
>> but the CONFIG_SYS_FSL_QORIQ_CHASSIS2 version just sets this to
>>
>>   compatible = "cache";
>>
>> Is this an over-site or is it intentional?
>>
>
> I don't have any record of this discussion. Kumar wrote and committed
> this change. I hope he remembers.
>

Here's a patch that retains the compatible property from the
original dtb and adds the "cache" value if required. This gets
the value I need through to the kernel.

 arch/powerpc/cpu/mpc85xx/fdt.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/cpu/mpc85xx/fdt.c b/arch/powerpc/cpu/mpc85xx/fdt.c
index 047c972ac78e..f31df41836d5 100644
--- a/arch/powerpc/cpu/mpc85xx/fdt.c
+++ b/arch/powerpc/cpu/mpc85xx/fdt.c
@@ -337,7 +337,8 @@ static inline void ft_fixup_l2cache(void *blob)
fdt_setprop_cell(blob, l2_off, "cache-size", size);
fdt_setprop_cell(blob, l2_off, "cache-sets", num_sets);
fdt_setprop_cell(blob, l2_off, "cache-level", 2);
-   fdt_setprop(blob, l2_off, "compatible", "cache", 6);
+   if (fdt_node_check_compatible(blob, l2_off, "cache") == 
1)
+   fdt_appendprop_string(blob, l2_off, 
"compatible", "cache");
}
 
if (l3_off < 0) {
-- 
2.10.2

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

[U-Boot] [PATCH] SPL: NOR: Add CONFIG_SPL_NOR_COPY_ENTIRE_IMAGE define to enable whole image copy from NOR

[Lukasz Majewski]

This define gives the possibility to copy entire image (including header -
e.g. u-boot.img) from NOR parallel memory to e.g. SDRAM. The current code
only supports loading the raw binary image (the u-boot.bin).

The legacy behavior is preserved, since other board don't enabled this option.

Signed-off-by: Lukasz Majewski 
---
Changes for v2:
- Update to code to apply on v2016.11+
Changes for v3:
- Write better commit mesage to explain the problem

---
 common/spl/Kconfig   | 10 ++
 common/spl/spl_nor.c | 12 +---
 2 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index df9e0ce..d31b26d 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -399,6 +399,16 @@ config SPL_NOR_SUPPORT
  a memory-mapped device makes it very easy to access. Loading from
  NOR is typically achieved with just a memcpy().
 
+config SPL_NOR_COPY_ENTIRE_IMAGE
+   bool
+   depends on SPL_NOR_SUPPORT
+   prompt "Copy entire image from NOR memory"
+   default n
+   help
+ By default the SPL NOR driver supports copying only payload to
+ destination address. Say Y if you want to copy entire image (including
+ its image header).
+
 config SPL_ONENAND_SUPPORT
bool "Support OneNAND flash"
depends on SPL
diff --git a/common/spl/spl_nor.c b/common/spl/spl_nor.c
index 6bfa399..44f3e99 100644
--- a/common/spl/spl_nor.c
+++ b/common/spl/spl_nor.c
@@ -10,13 +10,15 @@
 static int spl_nor_load_image(struct spl_image_info *spl_image,
  struct spl_boot_device *bootdev)
 {
+   void *img_src;
int ret;
+#ifndef CONFIG_SPL_NOR_COPY_ENTIRE_IMAGE
/*
 * Loading of the payload to SDRAM is done with skipping of
 * the mkimage header in this SPL NOR driver
 */
spl_image->flags |= SPL_COPY_PAYLOAD_ONLY;
-
+#endif
 #ifdef CONFIG_SPL_OS_BOOT
if (!spl_start_uboot()) {
const struct image_header *header;
@@ -65,9 +67,13 @@ static int spl_nor_load_image(struct spl_image_info 
*spl_image,
if (ret)
return ret;
 
+   img_src = (void *)CONFIG_SYS_UBOOT_BASE;
+#ifndef CONFIG_SPL_NOR_COPY_ENTIRE_IMAGE
+   img_src += sizeof(struct image_header));
+#endif
+
memcpy((void *)(unsigned long)spl_image->load_addr,
-  (void *)(CONFIG_SYS_UBOOT_BASE + sizeof(struct image_header)),
-  spl_image->size);
+  img_src, spl_image->size);
 
return 0;
 }
-- 
2.1.4

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

Re: [U-Boot] [U-Boot,v2] timer: Support clocks via phandle

[Tom Rini]

On Sat, Nov 19, 2016 at 07:57:27PM +0300, Zakharov Vlad wrote:

> Earlier timer driver needed a clock-frequency property in compatible
> device-tree nodes. Another way is to reference a clock via a phandle.
> 
> So now timer_pre_probe tries to get clock by reference through device
> tree. In case it is impossible to get clock device through the
> reference, clock-frequency property of the timer node is read to provide
> backward compatibility.
> 
> Signed-off-by: Vlad Zakharov 
> Reviewed-by: Simon Glass 

NAK:
   sandbox:  +   sandbox_spl x
+(sandbox_spl)   err = clk_get_by_index(dev, 0, timer_clk);
+(sandbox_spl)   ^
w+(sandbox_spl) drivers/timer/timer-uclass.c: In function ‘timer_pre_probe’:
w+(sandbox_spl) drivers/timer/timer-uclass.c:50:6: warning: ‘timer_clk’ is used 
uninitialized in this function [-Wuninitialized]

-- 
Tom


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

Re: [U-Boot] Pull request v3: u-boot-spi/sunxi

[Tom Rini]

On Mon, Nov 28, 2016 at 01:45:59PM +0530, Jagan Teki wrote:

> Hi Tom,
> 
> Please pull this sunxi PR.
> 
> Changes for v3:
> - Dropped patches from 'Chen-Yu Tsai'
> - Added two new patches.
> Changes for v2:
> - Dropped 3 patches, which are still in review.
> 
> thanks!
> Jagan.
> 
> The following changes since commit 136179bec19f4bc84227cba138214ea392a723ea:
> 
>   colibri_pxa270: transition to driver model for serial (2016-11-23 13:53:20 
> +0100)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-spi.git sunxi
> 
> for you to fetch changes up to 707932b3e6507e47bb6b08be669fd39f140933b8:
> 
>   sun8i_emac: Fix mdio read sequence (2016-11-28 13:27:47 +0530)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] spl: add check for FIT-header when loading image

[Tom Rini]

On Wed, Nov 16, 2016 at 12:54:39PM +0200, tomas.me...@vaisala.com wrote:

> Add check for FDT_MAGIC, otherwise also legacy images will be loaded as
> a FIT. With this check in place, the loader works correct both
> with legacy and FIT images.
> 
> Signed-off-by: Tomas Melin 
> Acked-by: Lokesh Vutla 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] spl: remove redundant call to parse_image_header()

[Tom Rini]

On Wed, Nov 16, 2016 at 01:15:05PM +0200, tomas.me...@vaisala.com wrote:

> Image header was checked twice.
> 
> Signed-off-by: Tomas Melin 
> Acked-by: Lokesh Vutla 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v5, 1/7] Revert "generic-board: allow showing custom board info"

[Tom Rini]

On Wed, Nov 16, 2016 at 05:49:19PM +0100, Marcel Ziswiler wrote:

> Drop CONFIG_CUSTOM_BOARDINFO as it is not Kconfig compliant and anyway
> not really used anywhere plus the upcoming weak show_board_info()
> approach seems much superior.
> 
> This reverts commit a9ad18c9d5fe2554753b0f9a52adfd5ebce61147.
> 
> Signed-off-by: Marcel Ziswiler 
> Reviewed-by: Tom Rini 
> Acked-by: Max Krummenacher 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v5, 2/7] generic-board: make show_board_info a weak function

[Tom Rini]

On Wed, Nov 16, 2016 at 05:49:20PM +0100, Marcel Ziswiler wrote:

> Make show_board_info() a weak function which allows for custom board
> specific implementations thereof.
> 
> Signed-off-by: Marcel Ziswiler 
> Reviewed-by: Tom Rini 
> Acked-by: Max Krummenacher 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v5, 3/7] apalis/colibri_t20/t30: deactivate displaying board info

[Tom Rini]

On Wed, Nov 16, 2016 at 05:49:21PM +0100, Marcel Ziswiler wrote:

> Deactivate CONFIG_DISPLAY_BOARDINFO in favour of
> CONFIG_DISPLAY_BOARDINFO_LATE which also displays on the LCD.
> 
> Signed-off-by: Marcel Ziswiler 
> Acked-by: Max Krummenacher 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [RESEND][PATCH 00/24] sh: add generic board support and fixes

[Vladimir Zapolskiy]

Hi Tom,

On 11/28/2016 05:43 PM, Tom Rini wrote:
> On Mon, Nov 28, 2016 at 12:15:12AM +0200, Vladimir Zapolskiy wrote:
> 
>> This is a combined series of the fixes to SH2/SH3/SH4/SH4A architecture port
>> of U-boot on top of the master branch, there is no functional difference
>> between this series and 3 my series sent in August 2016 for 2016.09, however
>> due to many positive generalization updates to U-boot sources the old
>> unreviewed series can not be cleanly applied anymore:
>>
>> * [PATCH 0/6] sh4: fix and simplify cache manipulation
>> * [PATCH 0/5] sh4: fixes to SH7751 PCI host controller
>> * [PATCH] common: sh: add necessary define bits to board_f
>> * [PATCH 00/12] sh: change arch and boards code to generic board
>>
>> I have to resend the changes, because apparently Nobuhiro Iwamatsu is
>> too busy to maintain SH port and I ask Tom/Simon/Marek and other active
>> U-boot developers to review and apply the changes, it is highly desirable
>> to have a possibility to run modern U-boot on boards powered by SH cores.
> 
> First, would you be interested in taking up the SH maintainership?

clearly Renesas abandoned SH architecture as a legacy one (and probably
as a competing with R-Car one), but until J4 core as a replacement for
Renesas SH4 is released by j-core.org project it is desirable to keep
U-Boot running on SH platforms.

I'm interested in maintainership of SH and thereafter J-Core cores, but
practically I have only one SH4 powered board on hand, unfortunately
begging for hardware donations was not so successful. At the moment
U-Boot contains SH2A/SH3/SH4/SH4A arch support and boards, I have to
figure out where to get more boards to cover more SoC flavours, and
getting legacy hardware is always a problem, because it is not on
a store's shelf.

To start from I would recommend to decouple u-boot-sh.git fork into
independent SH and ARM R-Car repositories, the latter one will be
maintained by Renesas associates.

> Second, I know before you told me how to get QEMU to run, but with this
> series and:
> qemu-system-sh4 -M r2d -kernel r2dplus/current/r2dplus/u-boot.bin
> -nographic -serial null -serial vc
> 
> I get:
> QEMU 2.5.91 monitor - type 'help' for more information
> (qemu) long write to SH7750_WCR1_A7 (0x1f88) ignored
> long write to SH7750_WCR2_A7 (0x1f8c) ignored
> long write to SH7750_WCR3_A7 (0x1f800010) ignored
> long write to SH7750_MCR_A7 (0x1f800014) ignored
> word write to SH7750_RTCNT_A7 (0x1f800020) ignored
> word write to SH7750_RTCOR_A7 (0x1f800024) ignored
> Write access to refresh count register
> word write to SH7750_RTCSR_A7 (0x1f80001c) ignored
> Read access to refresh count register, incrementing
> long write to SH7750_MCR_A7 (0x1f800014) ignored
> long read to SH7750_WCR1_A7 (0x1f88) ignored
> long read to SH7750_WCR2_A7 (0x1f8c) ignored
> long read to SH7750_WCR3_A7 (0x1f800010) ignored
> long read to SH7750_MCR_A7 (0x1f800014) ignored
> 
> and the qemu monitor/debug prompt.

The displayed qemu output is expected and can be ignored, currently SH
port in qemu is in "odd fixes" maintainership stage, hopefully I'll
find time to send a patch to silence this.

> Without -serial args I just get the
> hang.  Any ideas?  I ask since I'm keen to add r2dplus to test.py and
> travis-ci once it's working, thanks!
> 

I use this list of components to build and test U-Boot on r2dplus
qemu target and SH7751 powered board I have on hand (it is quite
similar to r2dplus devkit):

* SH4 toolchain from buildroot distro with musl (libc flavour most
  probably is unrelated to U-boot or kernel):
 - gcc-5.3.0
 - musl-1.1.12
 - linux-4.4 headers

* qemu-system-sh4 is from standard Debian qemu-system-misc package:
 - qemu-system-misc-1:2.6+dfsg-3
 - qemu-2.6.50 vanilla build also works for me fine

* U-Boot compilation:

% make ARCH=sh CROSS_COMPILE=sh4-buildroot-linux-musl-
CC='sh4-buildroot-linux-musl-gcc -Wall' r2dplus_defconfig

% make ARCH=sh CROSS_COMPILE=sh4-buildroot-linux-musl-
CC='sh4-buildroot-linux-musl-gcc -Wall' u-boot.bin

Command to run qemu with output directly to a console is similar to
the command you mentioned above (press Ctrl-C to terminate):

% qemu-system-sh4 -M r2d -kernel u-boot.bin -monitor null -serial null
-serial stdio -nographic

This is an example of testing on my end (omitting "long write ..
ignored" messages):

U-Boot 2016.11-00195-ge01f392eab43 (Nov 29 2016 - 02:55:25 +0200)

CPU: SH4
BOARD: Renesas Solutions R2D Plus
DRAM:  64 MiB
Flash: ERROR: too many flash sectors
8 MiB
*** Warning - bad CRC, using default environment

PCI: SH7751 PCI host bridge found.
long read to SH7750_WCR1_A7 (0x1f88) ignored
long read to SH7750_WCR2_A7 (0x1f8c) ignored
long read to SH7750_WCR3_A7 (0x1f800010) ignored
long read to SH7750_MCR_A7 (0x1f800014) ignored
PCI:   Bus Dev VenId DevId Class Int
PCI:
  00:00.0 - 1054:350e -

Re: [U-Boot] [U-Boot,v5,4/7] toradex: config block handling

[Tom Rini]

On Wed, Nov 16, 2016 at 05:49:22PM +0100, Marcel Ziswiler wrote:

> Add Toradex factory configuration block handling. The config block is a
> data structure which gets stored to flash during production testing. The
> structure holds such information as board resp. hardware revision,
> product ID and serial number which is used as the NIC part of the
> Ethernet MAC address as well. The config block will be read upon boot by
> the show_board_info() function, displayed as part of the board
> information and passed to Linux via device tree or ATAGs.
> 
> Signed-off-by: Marcel Ziswiler 
> Acked-by: Max Krummenacher 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v5, 5/7] apalis/colibri_imx7/pxa270/t20/t30/vf: integrate config block handling

[Tom Rini]

On Wed, Nov 16, 2016 at 05:49:23PM +0100, Marcel Ziswiler wrote:

> With our common code in place actually make use of it across all our
> modules.
> 
> Signed-off-by: Marcel Ziswiler 
> Acked-by: Max Krummenacher 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v5, 6/7] apalis/colibri_t30: move environment location

[Tom Rini]

On Wed, Nov 16, 2016 at 05:49:24PM +0100, Marcel Ziswiler wrote:

> Now with the config block handling in place move the U-Boot environment
> location before the config block at the end of 1st "boot sector" as
> deployed during production using our downstream BSP.
> 
> Signed-off-by: Marcel Ziswiler 
> Acked-by: Max Krummenacher 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v5, 7/7] colibri_vf: usb gadget: toradex pid is now set generically

[Tom Rini]

On Wed, Nov 16, 2016 at 05:49:25PM +0100, Marcel Ziswiler wrote:

> From: Max Krummenacher 
> 
> remove now unused CONFIG_TRDX_PID_XXX
> 
> Signed-off-by: Marcel Ziswiler 
> Acked-by: Stefan Agner 
> Acked-by: Max Krummenacher 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] linux/compat.h: Properly implement ndelay fallback

[Tom Rini]

On Fri, Nov 18, 2016 at 02:40:37PM +0100, mario@gdsys.cc wrote:

> Commit c68c62 ("i2c: mvtwsi: Make delay times frequency-dependent")
> extensively used the ndelay function with a calculated parameter
> which is dependant on the configured frequency of the I2C bus. If
> standard speed is employed, the parameter is usually 1 (1ns
> period length for 100kHz frequency).
> 
> But, since the arm architecture does not implement a proper version of
> ndelay, the fallback default from include/linux/compat.h is used,
> which defines every ndelay as udelay(1). This causes problems for
> slower speeds on arm, since the delay time is now 9us too short for
> the desired frequency, which leads to random failures of the I2C
> interface.
> 
> To remedy this, we implement a proper, parameter-aware ndelay fallback
> for architectures that don't implement a real ndelay function.
> 
> Reported-By: Jason Brown 
> To: Tom Rini 
> To: Heiko Schocher 
> Signed-off-by: Mario Six 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] bootcounter_ram: Fix misaligned cache warning

[Tom Rini]

On Fri, Nov 18, 2016 at 05:21:52PM +0100, Stefan Roese wrote:

> This patch fixes the warning about misaligned cache on Armada XP:
> 
> CACHE: Misaligned operation at range [7000, 7fac]
> 
> Signed-off-by: Stefan Roese 
> Cc: Valentin Longchamp 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v2, 2/2] ti_armv7_keystone2: env: Add NFS loading support for PMMC and MON

[Tom Rini]

On Fri, Nov 18, 2016 at 11:56:16AM -0600, Andrew F. Davis wrote:

> NFS loading support has been added to the default environment for
> most boot components, as PMMC and MON loading were added later they
> did not originally get the NFS commands added, add these now.
> 
> Signed-off-by: Andrew F. Davis 
> Reviewed-by: Lokesh Vutla 

Applied to u-boot/master, thanks!

-- 
Tom


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