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

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] 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] 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 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

[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

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] 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 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] 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] [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 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

[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(, (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();
> > 
> >   /* 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();
> >   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 

[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(_ccm->CCGR6);
+   if (enable)
+   reg |= MXC_CCM_CCGR6_EMI_SLOW_MASK;
+   else
+   reg &= ~MXC_CCM_CCGR6_EMI_SLOW_MASK;
+   __raw_writel(reg, _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

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] [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

[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] 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] [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] [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

[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, _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 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] 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] [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] [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 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] [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) */
>> 

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 = <>;
>
>
> 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] 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

[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] 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] xyz-modem: Change getc timeout loop waiting

[Tom Rini]

On Mon, Nov 21, 2016 at 10:18:51AM +0200, tomas.me...@vaisala.com wrote:

> This fixes the loop delay when using a hw watchdog.
> 
> In case a watchdog is used that accesses CPU registers,
> the defined delay of 20us in a tight loop will cause a
> huge delay in the actual timeout seen. This is caused
> by the fact that udelay will inheritantly call WATCHDOG_RESET.
> Together with the omap wdt implementation, the seen timeout increases up to
> around 30s. This makes the loop very slow and causes long
> delays when using the modem.
> 
> Instead, implement the 2 sec loop by using the timer interface to know
> when to break out of the timeout loop. Watchdog kicking is taken care of
> by getc().
> 
> Signed-off-by: Tomas Melin 

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, v4, 2/3] spl: dfu: move DFU Kconfig to SPL Kconfig

[Tom Rini]

On Mon, Nov 21, 2016 at 10:58:52AM -0800, Stefan Agner wrote:

> From: Stefan Agner 
> 
> The DFU Kconfig menu entries should be part of the SPL
> Kconfig file. Also avoid using the top level Makefile by
> moving the config dependent build artifacts to the driver/
> and driver/usb/gadget/ Makfiles.
> 
> With that, DFU can be built again in SPL if
> CONFIG_SPL_DFU_SUPPORT is enabled.
> 
> Fixes: 6ad6102246d8 ("usb:gadget: Disallow DFU in SPL for now")
> 
> Signed-off-by: Stefan Agner 
> Reviewed-by: Simon Glass 
> Acked-by: Lukasz Majewski 

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, v4, 1/3] spl: add RAM boot device only if it is actually defined

[Tom Rini]

On Mon, Nov 21, 2016 at 10:58:51AM -0800, Stefan Agner wrote:

> From: Stefan Agner 
> 
> Some devices (e.g. dra7xx) support loading to RAM using DFU without
> having direct boot from RAM support. Make sure the linker list
> does not contain BOOT_DEVICE_RAM if CONFIG_SPL_RAM_DEVICE is not
> enabled.
> 
> Fixes: 98136b2f26fa ("spl: Convert spl_ram_load_image() to use linker list")
> 
> Signed-off-by: Stefan Agner 
> Acked-by: Lukasz Majewski 

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] README: fix typo FAT_ENV_DEV_AND_PART

[Tom Rini]

On Mon, Nov 21, 2016 at 05:33:58PM +0200, Nicolae Rosia wrote:

> From: Nicolae Rosia 
> 
> The actual define symbol is FAT_ENV_DEVICE_AND_PART
> 
> Signed-off-by: Nicolae Rosia 

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, 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, 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] tools/Makefile: suppress "which swig" error output

[Tom Rini]

On Sat, Nov 19, 2016 at 12:04:59PM +, Andre Przywara wrote:

> The Makefile in tools/ tries to find the "swig" utility by calling "which".
> If nothing is found in the path, some versions of which will print an error
> message:
> $ make clean
> which: no swig in (/usr/local/bin:/usr/bin:/bin)
> 
> This does not apply to all version of "which", though:
> $ echo $0
> bash
> $ type which
> which is aliased to `type -path'
> $ which foo   <== this version is OK
> $ /usr/bin/which foo  <== this one is chatty
> /usr/bin/which: no foo in (/usr/local/bin:/usr/bin:/bin)
> $ sh  <== make uses /bin/sh
> sh-4.3$ which foo <== no alias here
> which: no foo in (/usr/local/bin:/usr/bin:/bin)
> 
> This error message is rather pointless in our case, since we just have
> this very check to care for this. So add stderr redirection to suppress
> the message.
> 
> Signed-off-by: Andre Przywara 
> 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, v2] tools/env: fix environment alignment tests for block devices

[Tom Rini]

On Sat, Nov 19, 2016 at 01:58:56PM +0100, 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 

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] [PATCH v4 0/6] Add ARMv8 PSCI framework

[Hongbo Zhang]

Hi York,
This generic PSCI is controlled by CONFIG_ARMV8_PSCI, if enabled, any
platform can implement their own PSCI functions under this framework,
this is all similar with ARMv7's.

While PPA is controlled by CONFIG_FSL_LS_PPA, and the private PSCI
inside the PPA is controlled by FSL_PPA_ARMV8_PSCI,  this macro
depends on and selected by CONFIG_FSL_LS_PPA.

That is to say, they are using separate configs, and only one of them
can be enabled at one time.

On Tue, Nov 29, 2016 at 1:16 AM, york sun  wrote:
> 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] [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] [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] [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, 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

Re: [U-Boot] [U-Boot, v2, 1/2] keystone2: Move target selection to Kconfig

[Tom Rini]

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

> The config option TARGET_K2x_EVM is set by the k2x defconfigs to pick
> a board target, but the header configs also set K2x_EVM. This config
> is redundant, remove it and use TARGET_K2x_EVM everywhere in its place.
> 
> 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

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] sata: fix sata command can not being executed bug

[Tom Rini]

On Mon, Nov 21, 2016 at 10:24:20AM +0800, tang yuantian wrote:

> From: Tang Yuantian 
> 
> Commit d97dc8a0 separated the non-command code into its own file
> which caused variable sata_curr_device can not be set to a correct
> value.
> 
> Before commit d97dc8a0, variable sata_curr_device can be set
> correctly in sata_initialize().
> After commit d97dc8a0, sata_initialize() is moved out to its own file.
> Accordingly, variable sata_curr_device is removed from sata_initialize()
> too. This caused sata_curr_device never gets a chance to be set properly
> which prevent other commands from being executed.
> 
> This patch sets variable sata_curr_device properly.
> 
> Fixes: d97dc8a0 (dm: sata: Separate the non-command code into its
>  own file)
> 
> Signed-off-by: Tang Yuantian 
> 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,v4,3/3] spl: add USB Gadget config option

[Tom Rini]

On Mon, Nov 21, 2016 at 10:58:53AM -0800, Stefan Agner wrote:

> From: Stefan Agner 
> 
> Introduce USB Gadget config option. This allows to combine Makefile
> entries for SPL_USBETH_SUPPORT and SPL_DFU_SUPPORT.
> 
> Signed-off-by: Stefan Agner 
> Acked-by: Lukasz Majewski 
> Tested-by: Ravi Babu 

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] 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] [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] [PATCH 05/24] SPL: tiny-printf: add "l" modifier

[André Przywara]

On 28/11/16 00:22, André Przywara wrote:
> On 27/11/16 17:02, Simon Glass wrote:
> 
> Hi,
> 
>> On 23 November 2016 at 20:19, Siarhei Siamashka
>>  wrote:
>>> On Sun, 20 Nov 2016 14:56:59 +
>>> Andre Przywara  wrote:
>>>
 tiny-printf does not know about the "l" modifier so far, which breaks
 the crash dump on AArch64, because it uses %lx to print the registers.
 Add an easy way of handling longs correctly.
>>>
>>> I can't help but notice that the changes of this kind are in a way
>>> defeating the original purpose of tiny-printf. And it is surely not
>>> the first patch adding features to tiny-printf. I guess, in the end
>>> we may end up with a large and bloated printf implementation again :-)
>>>
>>> A possible solution might be just a strict check when parsing format
>>> modifiers and abort with an error message (yeah, this will introduce
>>> some size increase, but hopefully the last one). This way we
>>> acknowledge the fact that tiny-printf is a reduced incomplete
>>> implementation, and that the callers need to take this into account.
>>>
>>> As for the "l" modifier. How much does it add to the code size? IMHO
>>> this information should be mentioned in the commit message. Can the
>>> AArch64 crash dump code be modified to avoid using it? Or can we have
>>> the "l" modifier supported on 64-bit platforms only?
>>>
 Signed-off-by: Andre Przywara 
 ---
  lib/tiny-printf.c | 43 +--
  1 file changed, 33 insertions(+), 10 deletions(-)
>>
>> I think I tested this patch as adding 36 bytes on Thumb2 so not too
>> terrible. But I do agree with the sentiment.

Simon, what is your compiler?
Both with GCC 5.3.0 and GCC 6.2.0 I get exactly 6/4 bytes more of .text,
which is not too bad for parsing (but ignoring) two new modifiers.
It turns out that (at least these two versions of) GCCs are quite clever
here and optimize away almost everything.
Looking closer one can see that the if and else branches become
identical if sizeof(long) == sizeof(int) == 4, so the compiler happily
merges the code, removes the "if (long)" check and in turn the whole
long-handling code on 32-bit.
This is the patch as sent, without any further hints in the code.

If anyone really wants to save code space, I suggest to switch to a
later compiler:

GCC 5.3.0:
 textdata bss dec hex filename
origin/master   orangepi_plus_defconfig GCC 5.3.0
18881 488 232   196014c91 spl/u-boot-spl
  758   0   0 758 2f6 spl/lib/tiny-printf.o

master+tiny_printf %l,%- orangepi_plus_defconfig GCC 5.3.0
18887 488 232   196074c97 spl/u-boot-spl
  758   0   0 758 2f6 spl/lib/tiny-printf.o

GCC 6.2.0:
origin/master   orangepi_plus_defconfig GCC 6.2.0
16871 488 232   1759144b7 spl/u-boot-spl
  698   0   0 698 2ba spl/lib/tiny-printf.o

master+tiny_printf %l,%- orangepi_plus_defconfig GCC 6.2.0
16875 488 232   1759544bb spl/u-boot-spl
  702   0   0 702 2be spl/lib/tiny-printf.o

On 64-bit (only GCC 6.2.0) this results in more code, as expected:
HEAD of patch set w/o tiny-printf %l, pine64_plus_defconfig
25824 392 360   2657667d0 spl/u-boot-spl
 1542   0   01542 606 spl/lib/tiny-printf.o
HEAD of patch set, pine64_plus_defconfig
25972 392 360   267246864 spl/u-boot-spl
 1690   0   01690 69a spl/lib/tiny-printf.o

So this is 148 Bytes more in .text. I can trade three simple patches
that cut off 80 Bytes in sunxi/armv8 to at least offset this a bit,
though this isn't really a regression, as there was no SPL64 for sunxi
before.
So apart from Alex' bug fix I won't change the patch, if people can live
with that.

Cheers,
Andre.

___
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

[Tom Rini]

On Tue, Nov 29, 2016 at 02:58:41AM +0200, Vladimir Zapolskiy wrote:
> 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.

I'm interesting in having J-Core work and be maintained in U-Boot, so
lets make this work.  With regards to legacy platforms, I'm happy to
drop things which are unavailable / non-functional and just note in
doc/README.scrapyard when things were removed.  We did this a lot around
a year ago and probably should again.

And then yes, the R-Car patches should come in via another repository
rather than u-boot.sh as was previously convenient.

> > 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.

Ah, OK.

> > 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):
> 
> % 

[U-Boot] [PATCH] 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.
>

(re-sent because I flubbed the subject line and got bounced for Ccing
all arch mainatiners, sorry for the spam)

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.

If it helps this is also consistent with the Linux documentation for
this binding[1] which states that the compatible property should have
both "-l2-cache-controller" and "cache" as values

[1] - Documentation/devicetree/bindings/powerpc/fsl/l2cache.txt


 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

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] [PATCH v2] spi: cadence_qspi_apb: Use 32 bit indirect write transaction when possible

[Vignesh R]

On Monday 28 November 2016 06:11 PM, Marek Vasut wrote:
> 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?

No issues with that either. The above limitation seems to be only wrt sf
write (indirect write).


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

Re: [U-Boot] Query on qspi driver

[Siva Durga Prasad Paladugu]

Hi Jagan,

> -Original Message-
> From: Jagan Teki [mailto:ja...@openedev.com]
> Sent: Thursday, November 24, 2016 11:48 PM
> To: Siva Durga Prasad Paladugu 
> Cc: u-boot@lists.denx.de; Michal Simek (michal.si...@xilinx.com)
> 
> Subject: Re: [U-Boot] Query on qspi driver
> 
> On Wed, Nov 23, 2016 at 11:21 AM, Siva Durga Prasad Paladugu
>  wrote:
> > Hi Jagan,
> >
> > I am planning to send ZynqMP qspi driver to mainline. As per your recent
> patches, I can see that, you are moving qspi flash stuff to spi-nor and these
> are not in main tree yet.
> > As you said earlier, I have seen u-boot-spi.git and there are few branches
> on which you have spi-nor related changes. Could you please let me know
> branch to work for sending my ZynqMP qspi driver patches.
> > Also, could you let me know your plan or target release for spi-nor
> changes, so that I will work on it accordingly.
> 
> Please note that, if this controller is specially designed for spi-nor flash's
> with exact functionalities which are more likely a flash related I can
> recommend you to add the driver on mtd side, if not it should be a pure spi
> driver.
> 
> If you want to write the driver on mtd side, use the master tree itself and
> once SPI-NOR ML will make the changes accordingly.
Yes, I want to write driver on mtd side. 
Which master you are referring, is it u-boot-spi.git Or u-boot.git master?
If it is u-boot.git, then I didn’t find any spi-nor related changes there. Do 
you want me to add driver on mtd side with current spi on master?
Also, could you let me know your plan or target release for spi-nor changes, so 
that I will work on it accordingly.

Regards,
Siva
> 
> 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] spi: cadence_qspi_apb: Use 32 bit indirect write transaction when possible

[Vignesh R]

On Monday 28 November 2016 07:45 PM, See, Chin Liang wrote:
> 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.
> 

Data slave port does accept byte, half-word and word access, there are
no data aborts. But indirect write controller seems to have
limitation(as documented in section 11.15.4.9.2) couping with non 32-bit
data writes on TI platform. For example with current driver if I try:

fatload mmc 0 0x8200 zImage
sf erase 0x0 0x50
sf write 0x8200 0x0 0x35
sf read 0xA000 0x0 0x35


md.b 0xA000
a000: 00 00 a0 00 00 00 a0 00 00 00 a0 00 00 00 a0 00
a010: 00 00 a0 00 00 00 a0 00 00 00 a0 00 00 00 a0 00
a020: 03 00 00 00 18 28 6f 00 00 00 00 00 d8 5b 35 00
a030: 01 02 03 00 00 00 00 00 00 00 00 00 00 00 00 00
md.b 0x8200
8200: 00 00 a0 e1 00 00 a0 e1 00 00 a0 e1 00 00 a0 e1
8210: 00 00 a0 e1 00 00 a0 e1 00 00 a0 e1 00 00 a0 e1
8220: 03 00 00 ea 18 28 6f 01 00 00 00 00 d8 5b 35 00
8230: 01 02 03 04 00 90 0f e1 88 07 00 eb 01 70 a0 e1


As you can see, every fourth byte turn out to be 0x00. Therefore this
patch is required.


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

[U-Boot] [PATCH] configs: am43x: hs: Modify SPL load address to fix UART boot issue

[Lokesh Vutla]

From: Madan Srinivas 

An issue in the TI secure image generation tool causes the ROM to
load the SPL at a different load address than what is specified by
CONFIG_ISW_ENTRY_ADDR while doing a peripheral boot.

This causes the SPL to fail on secure devices during peripheral
boot.

The TI secure image generation tool has been fixed so that the SPL
will always be loaded at 0x403018E0 by the ROM code for both
peripheral and memory boot modes. am43x hs defconfig file have been
updated to reflect this change.

Signed-off-by: Madan Srinivas 
Signed-off-by: Lokesh Vutla 
---
 configs/am43xx_hs_evm_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configs/am43xx_hs_evm_defconfig b/configs/am43xx_hs_evm_defconfig
index 1c53877..7d791fe 100644
--- a/configs/am43xx_hs_evm_defconfig
+++ b/configs/am43xx_hs_evm_defconfig
@@ -2,7 +2,7 @@ CONFIG_ARM=y
 CONFIG_AM43XX=y
 CONFIG_TI_SECURE_DEVICE=y
 CONFIG_TARGET_AM43XX_EVM=y
-CONFIG_ISW_ENTRY_ADDR=0x40302ae0
+CONFIG_ISW_ENTRY_ADDR=0x403018e0
 CONFIG_SPL_STACK_R_ADDR=0x8200
 CONFIG_SPL_YMODEM_SUPPORT=y
 CONFIG_DEFAULT_DEVICE_TREE="am437x-gp-evm"
-- 
2.10.1

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

[U-Boot] [PATCH 5/5] ARM: AMx3xx: Make FIT boot as default boot on HS devices

[Lokesh Vutla]

Verification has to be done before booting any images on HS devices. So
default the boot to FIT on HS devices.

Signed-off-by: Lokesh Vutla 
---
 board/ti/am335x/board.c | 7 +++
 board/ti/am43xx/board.c | 7 +++
 2 files changed, 14 insertions(+)

diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c
index da9eab4..111ed35 100644
--- a/board/ti/am335x/board.c
+++ b/board/ti/am335x/board.c
@@ -639,6 +639,13 @@ int board_late_init(void)
if (board_is_bbg1())
name = "BBG1";
set_board_info_env(name);
+
+   /*
+* Default FIT boot on HS devices. Non FIT images are not allowed
+* on HS devices.
+*/
+   if (get_device_type() == HS_DEVICE)
+   setenv("boot_fit", "1");
 #endif
 
 #if !defined(CONFIG_SPL_BUILD)
diff --git a/board/ti/am43xx/board.c b/board/ti/am43xx/board.c
index ba6f88f..390cc16 100644
--- a/board/ti/am43xx/board.c
+++ b/board/ti/am43xx/board.c
@@ -632,6 +632,13 @@ int board_late_init(void)
 {
 #ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
set_board_info_env(NULL);
+
+   /*
+* Default FIT boot on HS devices. Non FIT images are not allowed
+* on HS devices.
+*/
+   if (get_device_type() == HS_DEVICE)
+   setenv("boot_fit", "1");
 #endif
return 0;
 }
-- 
2.10.1

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

[U-Boot] [PATCH 4/5] ARM: AM57xx: Make FIT boot as default boot on HS devices

[Lokesh Vutla]

Verification has to be done before booting any images on HS devices. So
default the boot to FIT on HS devices.

Signed-off-by: Lokesh Vutla 
---
 board/ti/am57xx/board.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/board/ti/am57xx/board.c b/board/ti/am57xx/board.c
index 226752e..c63c693 100644
--- a/board/ti/am57xx/board.c
+++ b/board/ti/am57xx/board.c
@@ -463,6 +463,14 @@ int board_late_init(void)
 * This is the POWERHOLD-in-Low behavior.
 */
palmas_i2c_write_u8(TPS65903X_CHIP_P1, 0xA0, 0x1);
+
+   /*
+* Default FIT boot on HS devices. Non FIT images are not allowed
+* on HS devices.
+*/
+   if (get_device_type() == HS_DEVICE)
+   setenv("boot_fit", "1");
+
return 0;
 }
 
-- 
2.10.1

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

[U-Boot] [PATCH 3/5] ARM: DRA7: Make FIT boot as default boot on HS devices

[Lokesh Vutla]

Verification has to be done before booting any images on HS devices. So
default the boot to FIT on HS devices.

Signed-off-by: Lokesh Vutla 
---
 board/ti/dra7xx/evm.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
index 6d352e6..f932ae9 100644
--- a/board/ti/dra7xx/evm.c
+++ b/board/ti/dra7xx/evm.c
@@ -530,6 +530,13 @@ int board_late_init(void)
 
set_board_info_env(name);
 
+   /*
+* Default FIT boot on HS devices. Non FIT images are not allowed
+* on HS devices.
+*/
+   if (get_device_type() == HS_DEVICE)
+   setenv("boot_fit", "1");
+
omap_die_id_serial();
 #endif
return 0;
-- 
2.10.1

___
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

[Lokesh Vutla]

On Monday 28 November 2016 10:10 PM, Tom Rini wrote:
> 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..

Yes. I have verified it on all TI platforms.
On DRA7-evm with MMCSD boot:
without this series SPL took 607 ms to complete
with this series SPL took 318 ms to complete.

> 
>>
>> 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!
> 

I am mainly worried about platforms other than TI(Just want to be sure
that this series did not break other platforms)

Thanks and regards,
Lokesh

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

[U-Boot] [PATCH 0/5] ti_armv7_common: env: Add support for loading FIT images

[Lokesh Vutla]

This series adds env support for loading FIT images on TI platforms and
making it as default on HS platforms.

Lokesh Vutla (5):
  ti_armv7_common: env: Consolidate support for loading images from mmc
  ti_armv7_common: env: Add support for loading FIT images
  ARM: DRA7: Make FIT boot as default boot on HS devices
  ARM: AM57xx: Make FIT boot as default boot on HS devices
  ARM: AMx3xx: Make FIT boot as default boot on HS devices

 board/ti/am335x/board.c   |  7 +++
 board/ti/am43xx/board.c   |  7 +++
 board/ti/am57xx/board.c   |  8 
 board/ti/dra7xx/evm.c |  7 +++
 include/configs/am335x_evm.h  | 29 ---
 include/configs/am43xx_evm.h  | 18 -
 include/configs/ti_armv7_common.h | 41 ++-
 include/configs/ti_omap4_common.h | 12 
 include/configs/ti_omap5_common.h | 19 --
 9 files changed, 85 insertions(+), 63 deletions(-)

-- 
2.10.1

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

[U-Boot] [PATCH 1/5] ti_armv7_common: env: Consolidate support for loading images from mmc

[Lokesh Vutla]

Support for loading images from mmc is duplicated in all TI platforms.
Add this information to DEFAULT_MMC_TI_ARGS so that it can be reused
in all TI platforms.

Reviewed-by: Andrew F. Davis 
Signed-off-by: Lokesh Vutla 
---
 include/configs/am335x_evm.h  | 25 -
 include/configs/am43xx_evm.h  | 14 --
 include/configs/ti_armv7_common.h | 28 +++-
 include/configs/ti_omap4_common.h |  8 
 include/configs/ti_omap5_common.h | 15 ---
 5 files changed, 27 insertions(+), 63 deletions(-)

diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index 8fa8e39..7f5bee9 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -101,7 +101,6 @@
 #define CONFIG_EXTRA_ENV_SETTINGS \
DEFAULT_LINUX_BOOT_ENV \
DEFAULT_MMC_TI_ARGS \
-   "boot_fdt=try\0" \
"bootpart=0:2\0" \
"bootdir=/boot\0" \
"bootfile=zImage\0" \
@@ -127,30 +126,6 @@
"root=${ramroot} " \
"rootfstype=${ramrootfstype}\0" \
"loadramdisk=load mmc ${mmcdev} ${rdaddr} ramdisk.gz\0" \
-   "loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0" \
-   "loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}\0" \
-   "mmcloados=run args_mmc; " \
-   "if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \
-   "if run loadfdt; then " \
-   "bootz ${loadaddr} - ${fdtaddr}; " \
-   "else " \
-   "if test ${boot_fdt} = try; then " \
-   "bootz; " \
-   "else " \
-   "echo WARN: Cannot load the DT; " \
-   "fi; " \
-   "fi; " \
-   "else " \
-   "bootz; " \
-   "fi;\0" \
-   "mmcboot=mmc dev ${mmcdev}; " \
-   "if mmc rescan; then " \
-   "echo SD/MMC found on device ${mmcdev};" \
-   "run envboot; " \
-   "if run loadimage; then " \
-   "run mmcloados;" \
-   "fi;" \
-   "fi;\0" \
"spiboot=echo Booting from spi ...; " \
"run spiargs; " \
"sf probe ${spibusno}:0; " \
diff --git a/include/configs/am43xx_evm.h b/include/configs/am43xx_evm.h
index 0a6c06a..abfa852 100644
--- a/include/configs/am43xx_evm.h
+++ b/include/configs/am43xx_evm.h
@@ -229,20 +229,6 @@
"root=${ramroot} " \
"rootfstype=${ramrootfstype}\0" \
"loadramdisk=load ${devtype} ${devnum} ${rdaddr} ramdisk.gz\0" \
-   "loadimage=load ${devtype} ${bootpart} ${loadaddr} 
${bootdir}/${bootfile}\0" \
-   "loadfdt=load ${devtype} ${bootpart} ${fdtaddr} 
${bootdir}/${fdtfile}\0" \
-   "mmcboot=mmc dev ${mmcdev}; " \
-   "setenv devnum ${mmcdev}; " \
-   "setenv devtype mmc; " \
-   "if mmc rescan; then " \
-   "echo SD/MMC found on device ${devnum};" \
-   "if run loadimage; then " \
-   "run loadfdt; " \
-   "echo Booting from mmc${mmcdev} ...; " \
-   "run args_mmc; " \
-   "bootz ${loadaddr} - ${fdtaddr}; " \
-   "fi;" \
-   "fi;\0" \
"usbboot=" \
"setenv devnum ${usbdev}; " \
"setenv devtype usb; " \
diff --git a/include/configs/ti_armv7_common.h 
b/include/configs/ti_armv7_common.h
index 3e4d3fa..d720b2b 100644
--- a/include/configs/ti_armv7_common.h
+++ b/include/configs/ti_armv7_common.h
@@ -54,7 +54,8 @@
"ramdisk_addr_r=0x8808\0" \
"scriptaddr=0x8000\0" \
"pxefile_addr_r=0x8010\0" \
-   "bootm_size=0x1000\0"
+   "bootm_size=0x1000\0" \
+   "boot_fdt=try\0"
 
 #define DEFAULT_MMC_TI_ARGS \
"mmcdev=0\0" \
@@ -71,6 +72,8 @@
"importbootenv=echo Importing environment from mmc${mmcdev} ...; " \
"env import -t ${loadaddr} ${filesize}\0" \
"loadbootenv=fatload mmc ${mmcdev} ${loadaddr} ${bootenvfile}\0" \
+   "loadimage=load ${devtype} ${bootpart} ${loadaddr} 
${bootdir}/${bootfile}\0" \
+   "loadfdt=load ${devtype} ${bootpart} ${fdtaddr} 
${bootdir}/${fdtfile}\0" \
"envboot=mmc dev ${mmcdev}; " \
"if mmc rescan; then " \
"echo SD/MMC found on device ${mmcdev};" \
@@ -87,6 +90,29 @@
"fi;" \
"fi;" \
"fi;\0" \
+   "mmcloados=run args_mmc; " \
+   "if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \
+   

[U-Boot] [PATCH 2/5] ti_armv7_common: env: Add support for loading FIT images

[Lokesh Vutla]

FIT is a new image format which is a Tree like structure and gives more
flexibility in handling of various images. Mainly used for unification of
multiple images in a single blob and provide security information for each
image.

U-Boot already has support for loading such images, so adding the environment
support to load FIT image on all TI platforms.

Reviewed-by: Andrew F. Davis 
Signed-off-by: Lokesh Vutla 
---
 include/configs/am335x_evm.h  |  4 
 include/configs/am43xx_evm.h  |  4 
 include/configs/ti_armv7_common.h | 15 ++-
 include/configs/ti_omap4_common.h |  4 
 include/configs/ti_omap5_common.h |  4 
 5 files changed, 30 insertions(+), 1 deletion(-)

diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index 7f5bee9..59f838a 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -90,6 +90,9 @@
func(DHCP, dhcp, na)
 
 #define CONFIG_BOOTCOMMAND \
+   "if test ${boot_fit} -eq 1; then "  \
+   "run update_to_fit;"\
+   "fi;"   \
"run findfdt; " \
"run init_console; " \
"run envboot; " \
@@ -101,6 +104,7 @@
 #define CONFIG_EXTRA_ENV_SETTINGS \
DEFAULT_LINUX_BOOT_ENV \
DEFAULT_MMC_TI_ARGS \
+   DEFAULT_FIT_TI_ARGS \
"bootpart=0:2\0" \
"bootdir=/boot\0" \
"bootfile=zImage\0" \
diff --git a/include/configs/am43xx_evm.h b/include/configs/am43xx_evm.h
index abfa852..a04cc76 100644
--- a/include/configs/am43xx_evm.h
+++ b/include/configs/am43xx_evm.h
@@ -206,6 +206,7 @@
 #define CONFIG_EXTRA_ENV_SETTINGS \
DEFAULT_LINUX_BOOT_ENV \
DEFAULT_MMC_TI_ARGS \
+   DEFAULT_FIT_TI_ARGS \
"fdtfile=undefined\0" \
"bootpart=0:2\0" \
"bootdir=/boot\0" \
@@ -269,6 +270,9 @@
DFUARGS \
 
 #define CONFIG_BOOTCOMMAND \
+   "if test ${boot_fit} -eq 1; then "  \
+   "run update_to_fit;"\
+   "fi;"   \
"run findfdt; " \
"run envboot;" \
"run mmcboot;" \
diff --git a/include/configs/ti_armv7_common.h 
b/include/configs/ti_armv7_common.h
index d720b2b..d13fc94 100644
--- a/include/configs/ti_armv7_common.h
+++ b/include/configs/ti_armv7_common.h
@@ -110,10 +110,23 @@
"if mmc rescan; then " \
"echo SD/MMC found on device ${mmcdev};" \
"if run loadimage; then " \
-   "run mmcloados;" \
+   "if test ${boot_fit} -eq 1; then " \
+   "run loadfit; " \
+   "else " \
+   "run mmcloados;" \
+   "fi;" \
"fi;" \
"fi;\0" \
 
+#define DEFAULT_FIT_TI_ARGS \
+   "boot_fit=0\0" \
+   "fit_loadaddr=0x8800\0" \
+   "fit_bootfile=fitImage.itb\0" \
+   "update_to_fit=setenv loadaddr ${fit_loadaddr}; setenv bootfile 
${fit_bootfile}\0" \
+   "args_fit=setenv bootargs console=${console} \0" \
+   "loadfit=run args_fit; bootm ${loadaddr}:kernel@1 " \
+   "${loadaddr}:ramdisk@1 ${loadaddr}:${fdtfile};\0" \
+
 /*
  * DDR information.  If the CONFIG_NR_DRAM_BANKS is not defined,
  * we say (for simplicity) that we have 1 bank, always, even when
diff --git a/include/configs/ti_omap4_common.h 
b/include/configs/ti_omap4_common.h
index ce9d3e8..8e0f9eb 100644
--- a/include/configs/ti_omap4_common.h
+++ b/include/configs/ti_omap4_common.h
@@ -98,6 +98,9 @@
func(DHCP, dhcp, na)
 
 #define CONFIG_BOOTCOMMAND \
+   "if test ${boot_fit} -eq 1; then "  \
+   "run update_to_fit;"\
+   "fi;"   \
"run findfdt; " \
"run envboot; " \
"run distro_bootcmd"
@@ -107,6 +110,7 @@
 #define CONFIG_EXTRA_ENV_SETTINGS \
DEFAULT_LINUX_BOOT_ENV \
DEFAULT_MMC_TI_ARGS \
+   DEFAULT_FIT_TI_ARGS \
"console=ttyO2,115200n8\0" \
"fdtfile=undefined\0" \
"bootpart=0:2\0" \
diff --git a/include/configs/ti_omap5_common.h 
b/include/configs/ti_omap5_common.h
index 90ead56..37d6565 100644
--- a/include/configs/ti_omap5_common.h
+++ b/include/configs/ti_omap5_common.h
@@ -65,6 +65,7 @@
 #define CONFIG_EXTRA_ENV_SETTINGS \
DEFAULT_LINUX_BOOT_ENV \
DEFAULT_MMC_TI_ARGS \
+   DEFAULT_FIT_TI_ARGS \
"console=" CONSOLEDEV ",115200n8\0" \
"fdtfile=undefined\0" \
"bootpart=0:2\0" \
@@ -110,6 +111,9 @@
"echo Booting into fastboot ...; " \
"fastboot " __stringify(CONFIG_FASTBOOT_USB_DEV) "; " \
"fi;" \
+   "if test ${boot_fit} -eq 1; then "  \
+   "run update_to_fit;"\
+   "fi;"   \
"run findfdt; " \
"run envboot; " \
"run mmcboot;" \
-- 
2.10.1

___
U-Boot mailing list

[U-Boot] [PATCH] ARM: K2G: DDR3: Fix up priv ID for MPU

[Lokesh Vutla]

From: Nishanth Menon 

For ECC enabled DDR, we use EDMA to reset all memory values to 0. For
K2E/L/H/K the priv ID of 8 was indicative of ARM, but that is not the
case for K2G, where it is 1.

Unfortunately, ddr3 code had hard coded the privID and had missed
identification previously. Fix the same, else unforeseen behavior can
be expected in our reset of DDR contents to 0 for ECC enablement.

Signed-off-by: Nishanth Menon 
Signed-off-by: Lokesh Vutla 
---
 arch/arm/mach-keystone/ddr3.c | 23 +++
 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-keystone/ddr3.c b/arch/arm/mach-keystone/ddr3.c
index 6b92530..ee8e12e 100644
--- a/arch/arm/mach-keystone/ddr3.c
+++ b/arch/arm/mach-keystone/ddr3.c
@@ -138,7 +138,10 @@ static void ddr3_reset_data(u32 base, u32 ddr3_size)
puts("\nClear entire DDR3 memory to enable ECC\n");
 
/* save the SES MPAX regs */
-   msmc_get_ses_mpax(8, 0, mpax);
+   if (cpu_is_k2g())
+   msmc_get_ses_mpax(K2G_MSMC_SEGMENT_ARM, 0, mpax);
+   else
+   msmc_get_ses_mpax(K2HKLE_MSMC_SEGMENT_ARM, 0, mpax);
 
/* setup edma slot 1 configuration */
slot.opt = EDMA3_SLOPT_TRANS_COMP_INT_ENB |
@@ -169,8 +172,17 @@ static void ddr3_reset_data(u32 base, u32 ddr3_size)
for (seg = 0; seg < seg_num; seg += KS2_MSMC_MAP_SEG_NUM) {
/* map 2GB 36-bit DDR address to 32-bit DDR address in EMIF
   access slave interface so that edma driver can access */
-   msmc_map_ses_segment(8, 0, base >> KS2_MSMC_SEG_SIZE_SHIFT,
-KS2_MSMC_DST_SEG_BASE + seg, MPAX_SEG_2G);
+   if (cpu_is_k2g()) {
+   msmc_map_ses_segment(K2G_MSMC_SEGMENT_ARM, 0,
+base >> KS2_MSMC_SEG_SIZE_SHIFT,
+KS2_MSMC_DST_SEG_BASE + seg,
+MPAX_SEG_2G);
+   } else {
+   msmc_map_ses_segment(K2HKLE_MSMC_SEGMENT_ARM, 0,
+base >> KS2_MSMC_SEG_SIZE_SHIFT,
+KS2_MSMC_DST_SEG_BASE + seg,
+MPAX_SEG_2G);
+   }
 
if ((seg_num - seg) > KS2_MSMC_MAP_SEG_NUM)
edma_blks = KS2_MSMC_MAP_SEG_NUM <<
@@ -197,7 +209,10 @@ static void ddr3_reset_data(u32 base, u32 ddr3_size)
qedma3_stop(KS2_EDMA0_BASE, _channel);
 
/* restore the SES MPAX regs */
-   msmc_set_ses_mpax(8, 0, mpax);
+   if (cpu_is_k2g())
+   msmc_set_ses_mpax(K2G_MSMC_SEGMENT_ARM, 0, mpax);
+   else
+   msmc_set_ses_mpax(K2HKLE_MSMC_SEGMENT_ARM, 0, mpax);
 }
 
 static void ddr3_ecc_init_range(u32 base)
-- 
2.10.1

___
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 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 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

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 

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

[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 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

[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";
 };
 
+ {
+   clock-frequency = <10>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_i2c2_1>;
+   status = "okay";
+};
+
+ {
+clock-frequency = <10>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_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>;
+   };
+};
+
  {
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