Re: [U-Boot] [PATCH 1/2][v2] armv8: LS2080A: Rename LS2085A to reflect LS2080A

[York Sun]

On 11/09/2015 03:12 AM, Prabhakar Kushwaha wrote:
> LS2080A is a prime personality of Freescale’s LS2085A. It is a non-AIOP
> personality without support of DP-DDR, L2 switch, 1588, PCIe endpoint etc.
> So renaming existing LS2085A code base to reflect LS2080A (Prime personality)
> 
> Signed-off-by: Pratiyush Mohan Srivastava 
> Signed-off-by: Prabhakar Kushwaha 
> ---
> Changes for v2: Rebased on LS1043 patch set



> diff --git a/arch/arm/include/asm/arch-fsl-layerscape/cpu.h 
> b/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
> index 2903996..5a91dcb 100644
> --- a/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
> +++ b/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
> @@ -8,8 +8,10 @@
>  #define _FSL_LAYERSCAPE_CPU_H
>  
>  static struct cpu_type cpu_type_list[] = {
> - CPU_TYPE_ENTRY(LS2085, LS2085, 8),
> +#ifdef CONFIG_LS2080A
>   CPU_TYPE_ENTRY(LS2080, LS2080, 8),
> +#endif
> + CPU_TYPE_ENTRY(LS2085, LS2085, 8),
>   CPU_TYPE_ENTRY(LS2045, LS2045, 4),
>   CPU_TYPE_ENTRY(LS1043, LS1043, 4),
>  };

Why using ifdef here?

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

Re: [U-Boot] [PATCH V2] ARM: tegra: refactor common Kconfig options

[Tom Warren]

Simon,

> -Original Message-
> From: Tom Rini [mailto:tr...@konsulko.com]
> Sent: Monday, November 23, 2015 12:08 PM
> To: Simon Glass 
> Cc: Stephen Warren ; U-Boot Mailing List  b...@lists.denx.de>; Tom Warren ; Stephen Warren
> 
> Subject: Re: [PATCH V2] ARM: tegra: refactor common Kconfig options
> 
> * PGP Signed by an unknown key
> 
> On Mon, Nov 23, 2015 at 11:38:30AM -0700, Simon Glass wrote:
> > Hi,
> >
> > On 23 November 2015 at 10:32, Stephen Warren 
> wrote:
> > > From: Stephen Warren 
> > >
> > > This makes it easier to select common options in a single place,
> > > rather than having to add them separately for different SoCs or
> architectures.
> > >
> > > The lists of select statements are now also sorted for easy searching.
> > >
> > > Signed-off-by: Stephen Warren 
> > > Reviewed-by: Simon Glass 
> > > ---
> > > v2: Rebase on latest Kconfig changes in u-boot/master.
> > > ---
> > >  arch/arm/mach-tegra/Kconfig | 38
> > > --
> > >  1 file changed, 20 insertions(+), 18 deletions(-)
> >
> > Acked-by: Simon Glass 
> >
> > I plan to pick this up along with the driver model PCI series for
> > Tegra. Tom please let me know if you would rather grab this.
> 
> Works for me, thanks.
If you (perhaps) meant me (for Tegra), it also works for me to have this go in 
via DM. ;)

Thanks

Tom
--
nvpublic
> 
> --
> Tom
> 
> * Unknown Key
> * 0x56D6FECD
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2] ARM: tegra: refactor common Kconfig options

[Tom Rini]

On Mon, Nov 23, 2015 at 07:40:25PM +, Tom Warren wrote:
> Simon,
> 
> > -Original Message-
> > From: Tom Rini [mailto:tr...@konsulko.com]
> > Sent: Monday, November 23, 2015 12:08 PM
> > To: Simon Glass 
> > Cc: Stephen Warren ; U-Boot Mailing List  > b...@lists.denx.de>; Tom Warren ; Stephen Warren
> > 
> > Subject: Re: [PATCH V2] ARM: tegra: refactor common Kconfig options
> > 
> > * PGP Signed by an unknown key
> > 
> > On Mon, Nov 23, 2015 at 11:38:30AM -0700, Simon Glass wrote:
> > > Hi,
> > >
> > > On 23 November 2015 at 10:32, Stephen Warren 
> > wrote:
> > > > From: Stephen Warren 
> > > >
> > > > This makes it easier to select common options in a single place,
> > > > rather than having to add them separately for different SoCs or
> > architectures.
> > > >
> > > > The lists of select statements are now also sorted for easy searching.
> > > >
> > > > Signed-off-by: Stephen Warren 
> > > > Reviewed-by: Simon Glass 
> > > > ---
> > > > v2: Rebase on latest Kconfig changes in u-boot/master.
> > > > ---
> > > >  arch/arm/mach-tegra/Kconfig | 38
> > > > --
> > > >  1 file changed, 20 insertions(+), 18 deletions(-)
> > >
> > > Acked-by: Simon Glass 
> > >
> > > I plan to pick this up along with the driver model PCI series for
> > > Tegra. Tom please let me know if you would rather grab this.
> > 
> > Works for me, thanks.
> If you (perhaps) meant me (for Tegra), it also works for me to have this go 
> in via DM. ;)

oops, 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] mx6sxsabresd: Fix Ethernet PHY reset sequence

[Fabio Estevam]

From: Fabio Estevam 

Since commit 59370f3fcd1350 ("net: phy: delay only if reset handler is
registered") Ethernet is no longer functional.

This commit does not have an issue in itself, but it revelead a problem
with the Ethernet initialization.

Fix this by calling enable_fec_anatop_clock() earlier and also
by adding a 10ms reset delay as recommended in the AR8031 datasheet.

Suggested-by: Jörg Krause 
Signed-off-by: Fabio Estevam 
---
 board/freescale/mx6sxsabresd/mx6sxsabresd.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/board/freescale/mx6sxsabresd/mx6sxsabresd.c 
b/board/freescale/mx6sxsabresd/mx6sxsabresd.c
index 3ee4662..56dc020 100644
--- a/board/freescale/mx6sxsabresd/mx6sxsabresd.c
+++ b/board/freescale/mx6sxsabresd/mx6sxsabresd.c
@@ -150,11 +150,15 @@ static int setup_fec(void)
 {
struct iomuxc *iomuxc_regs = (struct iomuxc *)IOMUXC_BASE_ADDR;
struct anatop_regs *anatop = (struct anatop_regs *)ANATOP_BASE_ADDR;
-   int reg;
+   int reg, ret;
 
/* Use 125MHz anatop loopback REF_CLK1 for ENET1 */
clrsetbits_le32(_regs->gpr[1], IOMUX_GPR1_FEC1_MASK, 0);
 
+   ret = enable_fec_anatop_clock(0, ENET_125MHZ);
+   if (ret)
+   return ret;
+
imx_iomux_v3_setup_multiple_pads(phy_control_pads,
 ARRAY_SIZE(phy_control_pads));
 
@@ -163,14 +167,14 @@ static int setup_fec(void)
 
/* Reset AR8031 PHY */
gpio_direction_output(IMX_GPIO_NR(2, 7) , 0);
-   udelay(500);
+   mdelay(10);
gpio_set_value(IMX_GPIO_NR(2, 7), 1);
 
reg = readl(>pll_enet);
reg |= BM_ANADIG_PLL_ENET_REF_25M_ENABLE;
writel(reg, >pll_enet);
 
-   return enable_fec_anatop_clock(0, ENET_125MHZ);
+   return 0;
 }
 
 int board_eth_init(bd_t *bis)
-- 
1.9.1

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

Re: [U-Boot] [PATCH V2] ARM: tegra: refactor common Kconfig options

[Simon Glass]

Hi,

On 23 November 2015 at 10:32, Stephen Warren  wrote:
> From: Stephen Warren 
>
> This makes it easier to select common options in a single place, rather
> than having to add them separately for different SoCs or architectures.
>
> The lists of select statements are now also sorted for easy searching.
>
> Signed-off-by: Stephen Warren 
> Reviewed-by: Simon Glass 
> ---
> v2: Rebase on latest Kconfig changes in u-boot/master.
> ---
>  arch/arm/mach-tegra/Kconfig | 38 --
>  1 file changed, 20 insertions(+), 18 deletions(-)

Acked-by: Simon Glass 

I plan to pick this up along with the driver model PCI series for
Tegra. Tom please let me know if you would rather grab this.

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

Re: [U-Boot] [PATCH] Revert "net: phy: delay only if reset handler is registered"

[Fabio Estevam]

Hi Jörg ,

On Fri, Nov 20, 2015 at 6:37 PM, Fabio Estevam  wrote:

> Ok, I will test your proposal below on Monday when I get access to my
> mx6sxsabresd, thanks.

Your proposal worked fine, thanks. Will send it as a formal patch.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2] mx6sxsabresd: Fix Ethernet PHY reset sequence

[Fabio Estevam]

From: Fabio Estevam 

Since commit 59370f3fcd1350 ("net: phy: delay only if reset handler is
registered") Ethernet is no longer functional.

This commit does not have an issue in itself, but it revelead a problem
with the Ethernet initialization.

Fix this by calling enable_fec_anatop_clock() earlier and also
by adding a 10ms reset delay as recommended in the AR8031 datasheet.

Suggested-by: Jörg Krause 
Signed-off-by: Fabio Estevam 
---
Changes since v1:
- Fix Jörg's email address

 board/freescale/mx6sxsabresd/mx6sxsabresd.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/board/freescale/mx6sxsabresd/mx6sxsabresd.c 
b/board/freescale/mx6sxsabresd/mx6sxsabresd.c
index 3ee4662..56dc020 100644
--- a/board/freescale/mx6sxsabresd/mx6sxsabresd.c
+++ b/board/freescale/mx6sxsabresd/mx6sxsabresd.c
@@ -150,11 +150,15 @@ static int setup_fec(void)
 {
struct iomuxc *iomuxc_regs = (struct iomuxc *)IOMUXC_BASE_ADDR;
struct anatop_regs *anatop = (struct anatop_regs *)ANATOP_BASE_ADDR;
-   int reg;
+   int reg, ret;
 
/* Use 125MHz anatop loopback REF_CLK1 for ENET1 */
clrsetbits_le32(_regs->gpr[1], IOMUX_GPR1_FEC1_MASK, 0);
 
+   ret = enable_fec_anatop_clock(0, ENET_125MHZ);
+   if (ret)
+   return ret;
+
imx_iomux_v3_setup_multiple_pads(phy_control_pads,
 ARRAY_SIZE(phy_control_pads));
 
@@ -163,14 +167,14 @@ static int setup_fec(void)
 
/* Reset AR8031 PHY */
gpio_direction_output(IMX_GPIO_NR(2, 7) , 0);
-   udelay(500);
+   mdelay(10);
gpio_set_value(IMX_GPIO_NR(2, 7), 1);
 
reg = readl(>pll_enet);
reg |= BM_ANADIG_PLL_ENET_REF_25M_ENABLE;
writel(reg, >pll_enet);
 
-   return enable_fec_anatop_clock(0, ENET_125MHZ);
+   return 0;
 }
 
 int board_eth_init(bd_t *bis)
-- 
1.9.1

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

Re: [U-Boot] Riotboard FEC broken

[Fabio Estevam]

Hi Catalin,

On Thu, Nov 5, 2015 at 9:10 AM, Catalin Crenguta
 wrote:
> Hello,
>
> I have ran git bisect commit and found out that commit
> 59370f3fcd135089c402c93720a87c688abe600c breaks FEC on Riotboard.
> Reverting this change makes it working again.

Does this changes fix the problem?

--- a/board/embest/mx6boards/mx6boards.c
+++ b/board/embest/mx6boards/mx6boards.c
@@ -118,7 +118,7 @@ static void setup_iomux_enet(void)

/* Reset AR8035 PHY */
gpio_direction_output(IMX_GPIO_NR(3, 31) , 0);
-   mdelay(2);
+   mdelay(10);
gpio_set_value(IMX_GPIO_NR(3, 31), 1);
 }

Regards,

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

Re: [U-Boot] PCIE_MEM_BUS for Freescale SoC

[York Sun]

On 11/23/2015 09:07 AM, Scott Wood wrote:
> On Mon, 2015-11-23 at 09:00 -0800, York Sun wrote:
>>
>> On 11/23/2015 08:24 AM, Scott Wood wrote:
>>> On Sat, 2015-11-21 at 15:29 -0800, York Sun wrote:

 On 11/21/2015 02:55 PM, York Sun wrote:
> Roy,
>
> Do you remember the reason why we use different virtual memory address
> from pci
> bus address with 36-bit? For example
>
> include/configs/P1022DS.h-496-#define CONFIG_SYS_PCIE1_MEM_VIRT
> 0xc000
> include/configs/P1022DS.h-497-#ifdef CONFIG_PHYS_64BIT
> include/configs/P1022DS.h:498:#define CONFIG_SYS_PCIE1_MEM_BUS 
>  0xe000
> include/configs/P1022DS.h-499-#define CONFIG_SYS_PCIE1_MEM_PHYS
> 0xc4000ull
> include/configs/P1022DS.h-500-#else
> include/configs/P1022DS.h:501:#define CONFIG_SYS_PCIE1_MEM_BUS 
>  0xc000
> include/configs/P1022DS.h-502-#define CONFIG_SYS_PCIE1_MEM_PHYS
> 0xc000
> include/configs/P1022DS.h-503-#endif
>
> As far as I can tell, the following is the mapping
>
> TLB: MEM_VIRT=>MEM_PHYS
> PCI: MEM_BUS=>MEM_PHYS
> LAW: MEM_PHYS=>pcie interface
>
> Being different for MEM_VIRT and MEM_BUS cause confusion. When I run
> "pci
> header" command to show the BARs, I expect I can use "md" to access
> the
> BAR
> address. That's not the case if MEM_BUS is different from MEM_VIRT.
>
> I forget why we did this for 36-bit addressing. The MEM_VIRT is the
> same
> as
> MEM_BUS for 32-bit addressing. And why do we use the same MEM_BUS
> address
> for
> all PCIe hose? I know they are not conflicting, but is it necessary?

 (I hope Becky and Kumar still follow this mailing list)

 I dug out an old commit 4c78d4a6c01621721b732418e1c6da684a56bbb1 by
 Becky
 Bruce.
 She believed overlapping the bus address for PCI controllers leaves more
 space.
 That's true. But we haven't use more than 512MB in u-boot. If we do need
 more
 space, we can easily move things around if we have PHYS_64BIT. If no
 objection,
 I'd like to change this back.
>>>
>>> I object.  It's not about how much RAM is used in U-Boot; it's about how
>>> much
>>> memory the OS needs to bounce-buffer for DMA.  The addresses set up by U
>>> -Boot
>>> should match what's in the device tree.  Yes, on 85xx Linux reprograms the
>>> ATMU based on the device tree rather than trusting U-Boot, but that
>>> doesn't
>>> mean every OS does.
>>
>> Isn't this backward? I mean the device tree should match u-boot,
> 
> Yes, and I don't want to deal with the churn of these device trees changing.
> 
>>  or u-boot should fix up the device tree, right?
> 
> In theory yes, but then you really are affecting Linux's usage.
> 
>> I checked several device tree files in kernel. We are not using more than
>> 512MB
>> for each PCI. What's the benefit of using the same address 0xe000?
> 
> Reducing the amount of RAM whose address matches a PCI bus address and thus
> can't be used for PCI DMA.
> 

Another thought, Linux scans and enumerates PCIe regardless U-boot. The BARs are
setup according to device tree. So setting done u-boot is overwritten.

And, reusing 0xe000 for all PCI(e) controllers only applies to PHYS_64BIT in
current code. Isn't address space more crowed for 32-bit?

Regarding the ATMU, if OS relies on u-boot to setup correct ATMU, it should have
correct device tree as well.

Those being said, I can leave the code as is. It is not broken badly, but
confusing if one tries to access BAR space manually.

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

Re: [U-Boot] [PATCH V2] arm: novena: Switch novena to config_distro_bootcmd

[Vagrant Cascadian]

On 2015-11-10, Marek Vasut wrote:
> Switch Novena to distro bootcmd, so it can be used with debian easily.

> diff --git a/include/configs/novena.h b/include/configs/novena.h
> index 718989f..3bb406d 100644
> --- a/include/configs/novena.h
> +++ b/include/configs/novena.h
> @@ -58,7 +59,7 @@
>  /* Booting Linux */
>  #define CONFIG_BOOTFILE  "fitImage"
>  #define CONFIG_BOOTARGS  "console=ttymxc1,115200 "
> -#define CONFIG_BOOTCOMMAND   "run net_nfs"
> +#define CONFIG_BOOTCOMMAND   "run distro_bootcmd ; run net_nfs"
>  #define CONFIG_HOSTNAME  novena
>  
>  /* Physical Memory Map */
...
> @@ -199,6 +201,10 @@
>   "rootdev=/dev/mmcblk0p2\0"  \
>   "netdev=eth0\0" \
>   "kernel_addr_r="__stringify(CONFIG_LOADADDR)"\0"\
> + "pxefile_addr_r="__stringify(CONFIG_LOADADDR)"\0"   \
> + "scriptaddr="__stringify(CONFIG_LOADADDR)"\0"   \
> + "ramdisk_addr_r=0x2800\0"   \
> + "fdt_addr_r=0x1000\0"   \
>   "addcons="  \
>   "setenv bootargs ${bootargs} "  \
>   "console=${consdev},${baudrate}\0"  \

"fdtfile=imx6q-novena.dtb" should be added above, maybe after fdt_addr_r.

The use of CONFIG_BOOTARGS and "run addcons" appear to be redundant, or
at least overlapping. Other boards simply set "console=ttymxc0,115200"
or appropriate, which would be a bit simpler.


live well,
  vagrant


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

Re: [U-Boot] Zynq: Unable to boot from MMC

[Jagan Teki]

Hi Moritz,

On 23 November 2015 at 01:15, Moritz Fischer  wrote:
> Hi Jagan,
>
>
>
> On Sun, Nov 22, 2015 at 6:25 AM, Jagan Teki  wrote:
>> Hi Michal,
>>
>> I'm unable to boot the zynq board from MMC, here is my trails:
>> 1. zynq-boot-bin.py -o boot.bin -u spl/u-boot-spl-dtb.bin
>> copied boot.bin and u-boot-dtb.img on to sd card
>>
>
> try reverting 9ac4fc82071ce346e3885118242ff45d22f69b82. I ran into
> this friday and was pointed to that
> by a colleague.

Still the same issue, here is the reverted commit

Revert "board_init: Change the logic to setup malloc_base"

This reverts commit 9ac4fc82071ce346e3885118242ff45d22f69b82.


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

Re: [U-Boot] [PATCH v3 10/16] drivers: mtd: spi: sf_probe: add compatible for spansion spi flash

[Mugunthan V N]

On Friday 20 November 2015 05:57 PM, Jagan Teki wrote:
> On 20 November 2015 at 11:31, Mugunthan V N  wrote:
>> Jagan
>>
>> On Thursday 19 November 2015 03:40 PM, Jagan Teki wrote:
>>> On 19 November 2015 at 12:35, Mugunthan V N  wrote:
 Add compatible for spansion 32MiB spi flash s25fl256s1.

 Signed-off-by: Mugunthan V N 
 ---
  drivers/mtd/spi/sf_probe.c | 1 +
  1 file changed, 1 insertion(+)

 diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c
 index bc05d30..ffbce59 100644
 --- a/drivers/mtd/spi/sf_probe.c
 +++ b/drivers/mtd/spi/sf_probe.c
 @@ -515,6 +515,7 @@ static const struct dm_spi_flash_ops spi_flash_std_ops 
 = {

  static const struct udevice_id spi_flash_std_ids[] = {
 { .compatible = "spi-flash" },
 +   { .compatible = "s25fl256s1" },
 { }
>>>
>>> Never compare with spi-flash vs s25fl256s1 here former is driver
>>> compatible string and later one is probed flash string name. we don't
>>> need to add them in compatible list, better to add it on dts node
>>> otherwise no issue the connected flash will detect while 'sf probe'
>>>
>>
>> I agree that spi flash will be probed even without addition of compatibles.
>>
>> If there is no matching compatible between the dtb and driver,  the dt
>> properties like spi-max-frequency, spi clock phase/polarity and spi
>> bus-width are not parsed from DT as the of_offset of the spi device will
>> be '-1'. This check and dt parse is done in spi_child_post_bind() in
>> spi-uclass driver.
>>
>> Since spi bus-width is not read from DT, by default spi transfers are
>> done in one wire mode and read throughput drops to 5.3Mbps. With Quad
>> mode read throughput is 16.6Mbps in DRA74x EVM.
>>
> 
> Why can't we try something like this [1] [2] I do agree with
> documentation missing, may be we add add that well.
> 
> [1] arch/arm/dts/socfpga_cyclone5_sockit.dts

This dts file is not in sync with kernel dts. There is no qspi support
in kernel. It is going to be really tough time to sync this dts between
kernel and u-boot ;)

> [2] arch/arm/dts/zynqmp-ep108.dts

I don't see compatible string "spi-flash" in zynqmp-ep108.dts

Adding spi-flash compatible will be tough as spi-flash works with the
existing compatibles and convincing spi maintainer (Mark Brown) for
adding a generic compatible will be difficult.

If you still insist to add spi-flash compatible to the dts file and *Tom
Rini* is also fine, I will re-spin the series with compatible changes to
the dts files.

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

Re: [U-Boot] [PATCH v3 1/3] cmd_sf: add 'release' command

[Valentin Longchamp]

Hi Simon,

On 20/11/2015 18:19, Simon Glass wrote:
> Hi,
> 
> On 20 November 2015 at 03:13, Valentin Longchamp
>  wrote:
>> On 19/11/2015 17:57, Jagan Teki wrote:
>>> On 13 November 2015 at 18:55, Valentin Longchamp
>>>  wrote:
 The release command is the pendant of the probe command. This command
 allows to call spi_flash_free from the command line. This may be
 necessary for some boards where sf probe does change the state of the
 hardware (like with some pin multiplexing changes for instance).
>>>
>>> So you want to change the state of pin multiplexing on your board with
>>> connected slave devices example: spi nor flash is it? what exactly the
>>> need of releasing? why can't we use pin multiplexing changes like
>>> selecting or deselecting particular lines through driver or from board
>>> files itself.
>>
>> That's our use case yes. Let me explain you it again in detail. Some of the
>> signals used to access the NAND Flash and the SPI NOR are shared. At reset, 
>> they
>> are available for the SPI NOR, since u-boot is in there and the CPU then
>> accesses it.
>>
>> In an usual boot sequence, the SPI NOR is accessed first (copying u-boot to 
>> the
>> RAM, reading out the environment) and so the pins are configured in hardware 
>> at
>> boot time for accessing the SPI NOR. After that, they are configured to 
>> access
>> the NAND where the kernel and filesystem are stored to boot Linux thanks to
>> env_relocate_spec() calling spi_flash_free() on exit in conjunction with [1]
>>
>> Now in the case where the boot sequence is interrupted and some accesses are
>> done to the SPI NOR, the pins are changed again to SPI NOR to perform these
>> accesses. But we have to make sure that the pins are configured back to NAND 
>> by
>> calling spi_flash_free() after these accesses and that's why I introduced the
>> release() function.
>>
>> In our case, there are 2 types of such accesses:
>> - environment variables write: this is the first patch of the series. It 
>> simply
>> adds calls to spi_flash_free() at function exit no only in 
>> env_relocate_spec()
>> but also in saveenv() so that the behavior here is coherent for the whole 
>> env_sf
>> file (spi_flash_probe() at function start, spi_flash_free() at function 
>> exit).
>> - updating u-boot: this is solved for us with the last 2 patches of the 
>> series.
>> The first one just adds a sf release command that does the opposite/cleanup 
>> to
>> sf probe and the second patch just calls this command in our scripts where
>> u-boot is updated/the SPI NOR is written.
>>
>> We are *indeed* using pin multiplexing changes, in our case, they are
>> implemented in the spi controller driver: drivers/spi/kirkwood_spi.c. To be 
>> very
>> specific, in our case this sf release command allows to explicitely call
>> spi_flash_free() which calls spi_free_slave(), which in our case
>> (kirkwood_spi.c) sets the pins back to their previous configuration.
> 
> Does your board use driver model from SPI and SPI flash? If not I
> think that should be the first step.
> 

No we don't. Could you please elaborate on how this would cover this use case
and should be the first step ?

I am open to other ways to cover this use case of ours, especially since this
was done more than 2 years ago and u-boot has changed since then. However I
don't see the direct link between the driver model and how it would allow to
make sure spi_flash_free() is called in our u-boot env scripts.

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

Re: [U-Boot] [PATCH 07/10] ARM: socfpga: arria10: add board files for the Arria10 SoCDK

[Pavel Machek]

Hi!

> index 000..86f9b78
> --- /dev/null
> +++ b/board/altera/arria10-socdk/Makefile
> @@ -0,0 +1,9 @@
> +#
> +# (C) Copyright 2001-2006
> +# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
> +# (C) Copyright 2010, Thomas Chou 
> +#

You can delete these. There's nothing left of the old Makefile here.

> +# SPDX-License-Identifier:   GPL-2.0+
> +#
> +
> +obj-y:= socfpga.o


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 10/10] ARM: socfpga: arria10: add support for building Arria10

[Pavel Machek]

On Thu 2015-11-19 17:28:47, Dinh Nguyen wrote:
> On 11/19/2015 04:45 PM, Marek Vasut wrote:
> > On Thursday, November 19, 2015 at 10:35:47 PM, 
> > dingu...@opensource.altera.com 
> > wrote:
> >> From: Dinh Nguyen 
> >>
> >> Update Makefile to build Arria 10.
> >>
> >> Signed-off-by: Dinh Nguyen 
> >> ---
> >>  arch/arm/mach-socfpga/Makefile | 7 +--
> >>  arch/arm/mach-socfpga/arria10/Makefile | 7 +++
> >>  2 files changed, 12 insertions(+), 2 deletions(-)
> >>  create mode 100644 arch/arm/mach-socfpga/arria10/Makefile
> >>
> >> diff --git a/arch/arm/mach-socfpga/Makefile
> >> b/arch/arm/mach-socfpga/Makefile index 316b326..0dbe9bb 100644
> >> --- a/arch/arm/mach-socfpga/Makefile
> >> +++ b/arch/arm/mach-socfpga/Makefile
> >> @@ -6,15 +6,18 @@
> >>  #
> >>  # SPDX-License-Identifier:GPL-2.0+
> >>  #
> >> -
> >> +ifneq ($(CONFIG_TARGET_SOCFPGA_ARRIA10),y)
> >>  obj-y += misc.o timer.o reset_manager.o system_manager.o 
> > clock_manager.o \
> >>   fpga_manager.o scan_manager.o
> >>  obj-$(CONFIG_SPL_BUILD) += spl.o freeze_controller.o
> >> -
> >>  # QTS-generated config file wrappers
> >>  obj-y += wrap_pll_config.o
> >>  obj-$(CONFIG_SPL_BUILD) += wrap_iocsr_config.o wrap_pinmux_config.o   
> >> \
> >>   wrap_sdram_config.o
> >> +else
> >> +obj-y += arria10/
> > 
> > So why exactly does A10 have it's own dedicated dir if most of the code
> > is probably shared between A10 and AV/CV ?
> > 
> 
> Yes, there are some sharing. But I think that there will be enough
> differences that will ultimately warrant it's own directory. I think
> with it's own directory, the Makefile changes stay a bit cleaner. I
> 
> One of the biggest differences is that the A10's SDRAM support is going
> to be a bit ugly. The main point is that we need to program the FPGA
> during U-Boot booting up with a ~>10 MB rbf file while being limited to
> the OCRAM's size. I would like to contain this ugliness in it's own
> directory.

Well.. so you'll have to optimize memory consuption of the fpga
programming. It may be ugly, but once you are done, you'll want to use
the optimized version for everyone -- not to keep two versions.

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 04/10] ARM: socfpga: arria10: add stub sdram init for Arria10

[Marek Vasut]

On Monday, November 23, 2015 at 01:25:39 PM, Pavel Machek wrote:
> Hi!
> 
> > +union dramaddrw_reg {
> > +   struct {
> > +   u32 cfg_col_addr_width:5;
> > +   u32 cfg_row_addr_width:5;
> > +   u32 cfg_bank_addr_width:4;
> > +   u32 cfg_bank_group_addr_width:2;
> > +   u32 cfg_cs_addr_width:3;
> > +   u32 reserved:13;
> > +   };
> > +   u32 word;
> > +};
> 
> Umm. Are you sure this is good idea? Is gcc allowed  to do something
> funny and reorder bitfields in unexpected way?

GCC won't do anything, but I cannot say I'm a big fan of those bitfields.
Let's just drop them and use the BIT() macro.

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

Re: [U-Boot] U-boot broken on e500v2 soc

[Valentin Longchamp]

Hi York,

On 21/11/2015 07:33, York Sun wrote:
> Valentin,
> 
> Can you refresh my memory why you needed this
> commitac337168ad81a18e768e5e3cfff8d229adeb2b25 (patch
> http://patchwork.ozlabs.org/patch/455439)?
> Today I bisect an issue back to this commit.

In the patch description, there is a link to another patch that introduced some
problems with the bootcounter driver
(http://patchwork.ozlabs.org/patch/448849/). On the Keymile boards, we use this
bootcounter functionality that must call dcache_flush after the above change.
Tom suggested that powerpc required the kernel's corresponding cache function
from arch/powerpc/kernel/misc_32.S ported over to u-boot. That's what I did and
it allowed to solve the bootcounter problem.

Unfortunately, we don't have e500v2 CPUs at Keymile, only e300 and e500mc so
this patch was not tested from my side on e500v2 either.

Valentin

> 
> Scott,
> 
> Can you help to examine this u-boot commit? Before this commit,
> 512x/5xxx/83xx/85xx do nothing on function invalidate_dcache_range() and
> flush_dcache_range(). With this patch, I found e500v2 is broken on Intel e1000
> card when testing v2016-rc1. I didn't catch this issue when testing this 
> patch.
> 
> I wonder if this code is not safe for e500v2, or because the cache line size
> should be determined by reading L1CFG0. Why didn't we see any issue with Linux
> with the same code.
> 
> Log for testing on e500v2
> 
> P1023RDB
> 
> U-Boot 2016.01-rc1-00115-g2b24e09 (Nov 20 2015 - 22:01:56 -0800)
> 
> CPU0:  P1023E, Version: 1.1, (0x80fe0011)
> Core:  e500, Version: 5.1, (0x80212151)
> Clock Configuration:
>CPU0:500  MHz, CPU1:500  MHz,
>CCB:333.333 MHz,
>DDR:333.333 MHz (666.667 MT/s data rate) (Asynchronous), LBC:41.667 MHz
>FMAN1: 333.333 MHz
>QMAN:  0 MHz
> L1:D-cache 32 KiB enabled
>I-cache 32 KiB enabled
> Board: P1023 RDB
> I2C:   ready
> DRAM:  DIMM 0: is not a DDR3 SPD.
> SPD error on controller 0! Trying fallback to raw timing calculation
> Detected UDIMM Fixed DDR on board
> 512 MiB (DDR3, 32-bit, CL=5, ECC off)
> Flash: 64 MiB
> L2:256 KiB enabled
> NAND:  128 MiB
> EEPROM: CRC mismatch (a7fdad5b != )
> PCIe1: Root Complex of Slot 1, no link, regs @ 0xff60a000
> PCIe1: Bus 00 - 00
> PCIe2: Root Complex of Slot 2, x1 gen1, regs @ 0xff609000
>   02:00.0 - 8086:107d - Network controller
> PCIe2: Bus 01 - 02
> PCIe3: Root Complex of Slot 3, x1 gen1, regs @ 0xff60b000
>   04:00.0 - 168c:0030 - Network controller
> PCIe3: Bus 03 - 04
> In:serial
> Out:   serial
> Err:   serial
> Net:   Fman1: Uploading microcode version 160.0.18
> e1000: 00:15:17:8e:7b:8d
>FM1@DTSEC1, FM1@DTSEC2, e1000#0 [PRIME]
> Warning: e1000#0 MAC addresses don't match:
> Address in SROM is 00:15:17:8e:7b:8d
> Address in environment is  00:e0:0c:00:06:02
> 
> => ping $serverip
> Using e1000#0 device
> Bad trap at PC: 1ffc6f10, SR: 6049434, vector=e00
> NIP: 1FFC6F10 XER:  LR: 1FEF0B6C REGS: 1f8eda70 TRAP: 0e00 DAR: 
> 2000
> MSR: 06049434 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
> 
> GPR00: 1FF457D4 1F8EDB60 1F8EDF14 2000 0002 001F  1F8EDAB8
> GPR08: A0003818 4000 0003 1F8EDB80 1FF457D4 EC662032 1FFC8D50 1FFC6F24
> GPR16: 1FFB0074 1FFB005C 1FF59701 1FF5971F 1FF49C37 1FFB0068  1FFC6F10
> GPR24: 1FFB00CC 1FF48D60  1F8F3D70 1FFC5600 0040 1FF5C610 0040
> Call backtrace:
> 1FF2F350 1FF457D4 1FF06888 1FF13AF8 1FEFA180 1FEFA7FC 1FEF9A90
> 1FEFA124 1FEFA7FC 1FEFAA1C 1FF12B54 1FEFB140 1FF3AA7C 1FEFB454
> 1FEF0F4C
> Exception in kernel pc 1ffc6f10 signal 0
> ### ERROR ### Please RESET the board ###
> 
> 
> P1022DS log
> 
> U-Boot 2016.01-rc1-00115-g2b24e09 (Nov 20 2015 - 22:17:10 -0800)
> 
> CPU0:  P1022E, Version: 1.0, (0x80ee0010)
> Core:  e500, Version: 5.0, (0x80211050)
> Clock Configuration:
>CPU0:999.990 MHz, CPU1:999.990 MHz,
>CCB:499.995 MHz,
>DDR:333.330 MHz (666.660 MT/s data rate) (Asynchronous), LBC:31.250 MHz
> L1:D-cache 32 KiB enabled
>I-cache 32 KiB enabled
> Board: P1022DS Sys ID: 0x19, Sys Ver: 0x03, FPGA Ver: 0x09, vBank: 0
> I2C:   ready
> SPI:   ready
> DRAM:  Detected RDIMM 18JSF51272PDZ1G4D1
> Detected 4 GiB of memory
>This U-Boot only supports < 4G of DDR
>You could rebuild it with CONFIG_PHYS_64BIT
>2 GiB (DDR3, 64-bit, CL=5, ECC off)
> Flash: 128 MiB
> L2:256 KiB enabled
> NAND:  1024 MiB
> MMC:   FSL_SDHC: 0
> EEPROM: NXID v0
> PCIe1: Root Complex of Slot 1, no link, regs @ 0xffe0a000
> PCIe1: Bus 00 - 00
> PCIe2: Root Complex of Slot 3, x1 gen1, regs @ 0xffe09000
>   02:00.0 - 8086:10b9 - Network controller
> PCIe2: Bus 01 - 02
> PCIe3: Root Complex of Slot 2, no link, regs @ 0xffe0b000
> PCIe3: Bus 03 - 03
> In:serial
> Out:   serial
> Err:   serial
> Net:   e1000: 00:15:17:0b:8c:74
>eTSEC1, eTSEC2, e1000#0 [PRIME]
> Hit any key to stop autoboot:  0
> => ping $serverip
> Using e1000#0 device
> 

[U-Boot] [PATCH] spi: ti_qspi: Use 4-byte opcode for mmap read

[Vignesh R]

ti-qspi driver currently uses 3-byte addressing mode(and opcodes) for
memory-mapped read. This restricts maximum addressable flash size to
16MB.
Enable the 4-byte addressing(and use 4-byte opcode) for memory-mapped
read to allow access to addresses above 16MB.

Signed-off-by: Ravi Babu 
[vigne...@ti.com: Re-word commit description]
Signed-off-by: Vignesh R 

---

Tested on DRA74 EVM with Spansion flash and AM437X IDK EVM with Macronix
flash.

 drivers/spi/ti_qspi.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/spi/ti_qspi.c b/drivers/spi/ti_qspi.c
index 646dd899d3ec..0a032845866d 100644
--- a/drivers/spi/ti_qspi.c
+++ b/drivers/spi/ti_qspi.c
@@ -48,14 +48,14 @@
 #define CORE_CTRL_IO0x4a002558
 
 #define QSPI_CMD_READ   (0x3 << 0)
-#define QSPI_CMD_READ_QUAD  (0x6b << 0)
+#define QSPI_CMD_READ_QUAD  (0x6c << 0)
 #define QSPI_CMD_READ_FAST  (0x0b << 0)
-#define QSPI_SETUP0_NUM_A_BYTES (0x2 << 8)
+#define QSPI_SETUP0_NUM_A_BYTES (0x3 << 8)
 #define QSPI_SETUP0_NUM_D_BYTES_NO_BITS (0x0 << 10)
 #define QSPI_SETUP0_NUM_D_BYTES_8_BITS  (0x1 << 10)
 #define QSPI_SETUP0_READ_NORMAL (0x0 << 12)
 #define QSPI_SETUP0_READ_QUAD   (0x3 << 12)
-#define QSPI_CMD_WRITE  (0x2 << 16)
+#define QSPI_CMD_WRITE  (0x12 << 16)
 #define QSPI_NUM_DUMMY_BITS (0x0 << 24)
 
 /* ti qspi register set */
-- 
2.6.3

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

Re: [U-Boot] [PATCH 04/10] ARM: socfpga: arria10: add stub sdram init for Arria10

[Pavel Machek]

Hi!

> +union dramaddrw_reg {
> + struct {
> + u32 cfg_col_addr_width:5;
> + u32 cfg_row_addr_width:5;
> + u32 cfg_bank_addr_width:4;
> + u32 cfg_bank_group_addr_width:2;
> + u32 cfg_cs_addr_width:3;
> + u32 reserved:13;
> + };
> + u32 word;
> +};

Umm. Are you sure this is good idea? Is gcc allowed  to do something
funny and reorder bitfields in unexpected way?
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 10/16] drivers: mtd: spi: sf_probe: add compatible for spansion spi flash

[Jagan Teki]

On 23 November 2015 at 16:59, Mugunthan V N  wrote:
> On Friday 20 November 2015 05:57 PM, Jagan Teki wrote:
>> On 20 November 2015 at 11:31, Mugunthan V N  wrote:
>>> Jagan
>>>
>>> On Thursday 19 November 2015 03:40 PM, Jagan Teki wrote:
 On 19 November 2015 at 12:35, Mugunthan V N  wrote:
> Add compatible for spansion 32MiB spi flash s25fl256s1.
>
> Signed-off-by: Mugunthan V N 
> ---
>  drivers/mtd/spi/sf_probe.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c
> index bc05d30..ffbce59 100644
> --- a/drivers/mtd/spi/sf_probe.c
> +++ b/drivers/mtd/spi/sf_probe.c
> @@ -515,6 +515,7 @@ static const struct dm_spi_flash_ops 
> spi_flash_std_ops = {
>
>  static const struct udevice_id spi_flash_std_ids[] = {
> { .compatible = "spi-flash" },
> +   { .compatible = "s25fl256s1" },
> { }

 Never compare with spi-flash vs s25fl256s1 here former is driver
 compatible string and later one is probed flash string name. we don't
 need to add them in compatible list, better to add it on dts node
 otherwise no issue the connected flash will detect while 'sf probe'

>>>
>>> I agree that spi flash will be probed even without addition of compatibles.
>>>
>>> If there is no matching compatible between the dtb and driver,  the dt
>>> properties like spi-max-frequency, spi clock phase/polarity and spi
>>> bus-width are not parsed from DT as the of_offset of the spi device will
>>> be '-1'. This check and dt parse is done in spi_child_post_bind() in
>>> spi-uclass driver.
>>>
>>> Since spi bus-width is not read from DT, by default spi transfers are
>>> done in one wire mode and read throughput drops to 5.3Mbps. With Quad
>>> mode read throughput is 16.6Mbps in DRA74x EVM.
>>>
>>
>> Why can't we try something like this [1] [2] I do agree with
>> documentation missing, may be we add add that well.
>>
>> [1] arch/arm/dts/socfpga_cyclone5_sockit.dts
>
> This dts file is not in sync with kernel dts. There is no qspi support
> in kernel. It is going to be really tough time to sync this dts between
> kernel and u-boot ;)

Since we are in starting point of adding dts files (unlike Linux)
these dts files may not sync with Linux, we started adding these to
make dm or related drivers need to work. Yes I agreed with your point
and we really need to work on that as well.

>
>> [2] arch/arm/dts/zynqmp-ep108.dts
>
> I don't see compatible string "spi-flash" in zynqmp-ep108.dts

Yes, cant you add "s25fl256s1" like n25q512a11 added in this dts.

>
> Adding spi-flash compatible will be tough as spi-flash works with the
> existing compatibles and convincing spi maintainer (Mark Brown) for
> adding a generic compatible will be difficult.

This is what you pointed out - id_table.

static struct spi_driver m25p80_driver = {
.driver = {
.name   = "m25p80",
.of_match_table = m25p_of_table,
},
.id_table   = m25p_ids,


>
> If you still insist to add spi-flash compatible to the dts file and *Tom
> Rini* is also fine, I will re-spin the series with compatible changes to
> the dts files.

I'm saying like s25fl256s1 few of compatible strings were added
already on existing dts files, probably we may proceed with the same
for now. will trimming up later.

thanks!
-- 
Jagan | openedev.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: socfpga: Repair SoCrates board

[Marek Vasut]

On Monday, November 23, 2015 at 07:59:16 AM, Stefan Roese wrote:
> Hi Marek,

Hi!

> On 21.11.2015 13:40, Marek Vasut wrote:
> >>> +/*
> >>> + * PHY configuration
> >>> + */
> >>> +#ifdef CONFIG_PHY_MICREL_KSZ9021
> >>> +int board_phy_config(struct phy_device *phydev)
> >>> +{
> >>> + int ret;
> >>> + /*
> >>> +  * These skew settings for the KSZ9021 ethernet phy is required for
> >>> ethernet + * to work reliably on most flavors of cyclone5 boards.
> >>> +  */
> >>> + ret = ksz9021_phy_extended_write(phydev,
> >>> +  MII_KSZ9021_EXT_RGMII_RX_DATA_SKEW,
> >>> +  0x0);
> >>> + if (ret)
> >>> + return ret;
> >>> +
> >>> + ret = ksz9021_phy_extended_write(phydev,
> >>> +  MII_KSZ9021_EXT_RGMII_TX_DATA_SKEW,
> >>> +  0x0);
> >>> + if (ret)
> >>> + return ret;
> >>> +
> >>> + ret = ksz9021_phy_extended_write(phydev,
> >>> +  MII_KSZ9021_EXT_RGMII_CLOCK_SKEW,
> >>> +  0xf0f0);
> >>> + if (ret)
> >>> + return ret;
> >>> +
> >>> + if (phydev->drv->config)
> >>> + return phydev->drv->config(phydev);
> >>> +
> >>> + return 0;
> >>> +}
> >>> +#endif
> > 
> > Hi!
> > 
> >> v2 of the SoCrates comes with a different PHY, IIRC. So we might
> >> want to add some checking on the PHY model here at some time.
> > 
> > I don't have a socratesV2 and U-Boot does not support it either. Please
> > either mail me a socratesV2 or send a subsequent patch to add support
> > for socratesV2, I am open to either method.
> 
> I'll send a follow-up patch for this.

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] sunxi: Set AHB1 clock to PLL6/3 on all clock_sun6i.h using SoCs

[Ian Campbell]

On Mon, 2015-11-23 at 14:47 +0800, Chen-Yu Tsai wrote:
> Hi,
> 
> On Sun, Nov 22, 2015 at 11:40 PM, Hans de Goede 
> wrote:
> > Hi,
> >
> > On 22-11-15 15:14, Chen-Yu Tsai wrote:
> >>
> >> On Sat, Nov 21, 2015 at 11:48 PM, Ian Campbell <
> ijc+ub...@hellion.org.uk>
> >> wrote:
> >>>
> >>> On Fri, 2015-11-20 at 19:32 +0100, Hans de Goede wrote:
> 
>  According to the datasheets the max speed of AHB1 is 276 MHz, so
>  setting it to PLL6 / 3 which gives us 200MHz everywhere is fine,
>  and gives us a nice speed-up in certain workloads.
> 
>  Suggested-by: Chen-Yu Tsai 
>  Signed-off-by: Hans de Goede 
> >>>
> >>>
> >>> I suppose you've tested this on at least one such board? In that
> case:
> >>> Acked-by: Ian Campbell 
> >>
> >>
> >> I've tested this on some of my boards. It works fine on my
> Hummingbird A31
> >> and A23 Q8 tablet. However my Sinlinx SinA33 is giving me kernel
> Oops
> >> which
> >> I haven't looked into yet.
> >
> >
> > Works for me on a q8 A33 tablet. But lets investigate your oops
> before
> > including
> > this in the next pull-req. Thanks for the testing!
> 
> I retested it with a proper clean build, and it works now. No idea
> what
> the oops was about.
> 
> Also tested on my Sinlinx SinA31s. So it now works on all my sun6i
> generation
> boards.
> 
> Tested-by: Chen-Yu Tsai 

Good enough for me, my original Ack stands...

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

Re: [U-Boot] [PATCH 2/2] rockchip: Explicitely set CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN

[Sjoerd Simons]

On Sun, 2015-11-22 at 09:11 -0700, Simon Glass wrote:
> On 22 November 2015 at 00:21, Sjoerd Simons
>  wrote:
> > Now that u-boot relocates the malloc area in SPL to SDRAM, with the
> > malloc area sitting below the SPL_STACK_R_ADDR the
> > SPL_STACK_R_MALLOC_SIMPLE_LEN needs to be set explicitely for
> > rockchip as its SPL_STACK_R_ADDR (512kb) is smaller then
> > STACK_R_MALLOC_SIMPLE_LEN (1Mb).
> > 
> > Using the same value as SYS_MALLOC_F_LEN (8kb) is enough to load u-
> > boot
> > from SD card.
> > 
> > Signed-off-by: Sjoerd Simons 
> > 
> > ---
> > 
> >  configs/chromebook_jerry_defconfig | 1 +
> >  configs/firefly-rk3288_defconfig   | 1 +
> >  2 files changed, 2 insertions(+)
> 
> Explicitly (I can fix when applying if you like)
> 
> Acked-by: Simon Glass 

Yes please, saves doing another round :) Thanks!

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

Re: [U-Boot] arm: socfpga: Repair SoCrates board

[Jan Viktorin]

Hi Marek,

On Fri, 20 Nov 2015 17:17:33 +0100
Marek Vasut  wrote:

> This board was constantly parasiting on the CV SoCDK, so split it
> into it's own separate directory. Moreover, the board config was
> missing important bits, like simple-bus support in SPL, the DRAM
> configuration was incorrect and the DTS was also missing the pre
> reloc bits.
> 
> Signed-off-by: Marek Vasut 
> Cc: Stefan Roese 
> Cc: Dinh Nguyen 
> Cc: Dinh Nguyen 
> Reviewed-by: Stefan Roese 
> ---
>  arch/arm/dts/socfpga_cyclone5_socrates.dts |   5 +
>  arch/arm/mach-socfpga/Kconfig  |   7 +
>  board/ebv/socrates/MAINTAINERS |   6 +
>  board/ebv/socrates/Makefile|   9 +
>  board/ebv/socrates/qts/iocsr_config.h  | 660 
> +
>  board/ebv/socrates/qts/pinmux_config.h | 219 ++
>  board/ebv/socrates/qts/pll_config.h|  85 
>  board/ebv/socrates/qts/sdram_config.h  | 341 +++
>  board/ebv/socrates/socfpga.c   |  85 
>  configs/socfpga_socrates_defconfig |   3 +-
>  include/configs/socfpga_socrates.h |  97 +
>  11 files changed, 1516 insertions(+), 1 deletion(-)
>  create mode 100644 board/ebv/socrates/MAINTAINERS
>  create mode 100644 board/ebv/socrates/Makefile
>  create mode 100644 board/ebv/socrates/qts/iocsr_config.h
>  create mode 100644 board/ebv/socrates/qts/pinmux_config.h
>  create mode 100644 board/ebv/socrates/qts/pll_config.h
>  create mode 100644 board/ebv/socrates/qts/sdram_config.h
>  create mode 100644 board/ebv/socrates/socfpga.c
>  create mode 100644 include/configs/socfpga_socrates.h
> [snip]

SoCrates (1.2) boots now properly:

U-Boot SPL 2016.01-rc1 (Nov 23 2015 - 14:34:13)
drivers/ddr/altera/sequencer.c: Preparing to start memory calibration
drivers/ddr/altera/sequencer.c: CALIBRATION PASSED
drivers/ddr/altera/sequencer.c: Calibration complete
Trying to boot from MMC


U-Boot 2016.01-rc1 (Nov 23 2015 - 14:34:13 +0100)

CPU:   Altera SoCFPGA Platform
FPGA:  Altera Cyclone V, SE/A6 or SX/C6 or ST/D6, version 0x0
BOOT:  SD/MMC Internal Transceiver (3.0V)
   Watchdog enabled
I2C:   ready
DRAM:  1 GiB
MMC:   SOCFPGA DWMMC: 0
*** Warning - bad CRC, using default environment

In:serial
Out:   serial
Err:   serial
Model: EBV SOCrates
Net:
Error: ethernet@ff702000 address not set.
No ethernet found.
Hit any key to stop autoboot:  0
=>


Applied after manual fix of this:

default "socfpga_sockit" if TARGET_SOCFPGA_TERASIC_SOCKIT
 +  default "socfpga_sockit" if TARGET_SOCFPGA_EBV_SOCRATES


I don't understand the issue with Ethernet:

 "Error: ethernet@ff702000 address not set."

Otherwise

Tested-By: Jan Viktorin 

-- 
   Jan Viktorin  E-mail: vikto...@rehivetech.com
   System Architect  Web:www.RehiveTech.com
   RehiveTech
   Brno, Czech Republic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] i2c, avr32: fix compiler warning "input is not relaxable"

[Andreas Bießmann]

Dear Heiko Schocher,

Heiko Schocher  writes:
>compiling U-Boot for avr32 boards shows since
>commit 3d1957f0ea01 "dm: i2c: Add support for multiplexed I2C buses"
>this warning:
>
>Building current source for 4 boards (4 threads, 8 jobs per thread)
> avr32:  +   atstk1002
>+(atstk1002) drivers/i2c/built-in.o: warning: input is not relaxable
> avr32:  +   grasshopper
>+(grasshopper) drivers/i2c/built-in.o: warning: input is not relaxable
> avr32:  +   atngw100
>+(atngw100) drivers/i2c/built-in.o: warning: input is not relaxable
> avr32:  +   atngw100mkii
>+(atngw100mkii) drivers/i2c/built-in.o: warning: input is not relaxable
>040 /4  0:00:16  : atngw100mkii
>
>Fix it.
>
>Signed-off-by: Heiko Schocher 
>Reviewed-by: Roger Meier 
>Reviewed-by: Simon Glass 
>Reviewed-by: Andreas Bießmann 
>---
>
> drivers/i2c/Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)

applied to u-boot-avr32/master, thanks!

Best regards,
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PULL] u-boot-avr32/master -> u-boot/master

[Andreas Bießmann]

Hi Tom,

please pull from u-boot-avr32/master

Andreas

The following changes since commit d018cd20b3d70e9deba8dbf2643853edfc977dff:

  sunxi: Update new defconfigs (2015-11-22 10:46:25 -0500)

are available in the git repository at:

  git://git.denx.de/u-boot-avr32.git master

for you to fetch changes up to f300dccde433bf9e0223e1be489822fdc1cc83e2:

  i2c, avr32: fix compiler warning "input is not relaxable" (2015-11-23 
14:47:48 +0100)


Heiko Schocher (1):
  i2c, avr32: fix compiler warning "input is not relaxable"

 drivers/i2c/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] arm: socfpga: Repair SoCrates board

[Jan Viktorin]

Hello Marek, Stefan, Dinh, all,

On Fri, 20 Nov 2015 17:17:33 +0100
Marek Vasut  wrote:

> This board was constantly parasiting on the CV SoCDK, so split it
> into it's own separate directory. Moreover, the board config was
> missing important bits, like simple-bus support in SPL, the DRAM
> configuration was incorrect and the DTS was also missing the pre
> reloc bits.
> 
> Signed-off-by: Marek Vasut 
> Cc: Stefan Roese 
> Cc: Dinh Nguyen 
> Cc: Dinh Nguyen 
> Reviewed-by: Stefan Roese 
> ---
> [snip]

I can see a lot of warnings like

include/configs/socfpga_socrates.h:26:0: warning: "CONFIG_CMD_GPIO"
redefined #define CONFIG_CMD_GPIO
 ^
In file included from ././include/linux/kconfig.h:4:0,
 from :0:
include/generated/autoconf.h:77:0: note: this is the location of the
previous definition #define CONFIG_CMD_GPIO 1
 ^
In file included from include/config.h:5:0,
 from include/common.h:18,
 from arch/arm/cpu/armv7/cache_v7.c:9:
include/configs/socfpga_socrates.h:26:0: warning: "CONFIG_CMD_GPIO"
redefined #define CONFIG_CMD_GPIO

I believe, it's a consequence of the migration to the kconfig system,
isn't?

Regards
Jan Viktorin

-- 
   Jan Viktorin  E-mail: vikto...@rehivetech.com
   System Architect  Web:www.RehiveTech.com
   RehiveTech
   Brno, Czech Republic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] arm: socfpga: Repair SoCrates board

[Jan Viktorin]

Hello Marek, Stefan, Dinh, all,

(I'm sorry If you've received this mail twice, I used a second e-mail
by mistake. This one should go to the mailing-list.)

I have a couple of short questions bellow...

On Fri, 20 Nov 2015 17:17:33 +0100
Marek Vasut  wrote:

> [snip]
> +/* Booting Linux */
> +#define CONFIG_BOOTDELAY 3
> +#define CONFIG_BOOTFILE  "zImage"

This is quite a general question. Why would one prefer zImage over
uImage (or vice-versa)? Is there some mainstream idea with this? Or is
it selected at random?

> +#define CONFIG_BOOTARGS  "console=ttyS0," 
> __stringify(CONFIG_BAUDRATE)
> +#define CONFIG_BOOTCOMMAND   "run mmcload; run mmcboot"
> [snip]
> +
> +#define CONFIG_EXTRA_ENV_SETTINGS \
> + "verify=n\0" \
> + "loadaddr= " __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \
> + "ramboot=setenv bootargs " CONFIG_BOOTARGS ";" \
> + "bootm ${loadaddr} - ${fdt_addr}\0" \
> + "bootimage=zImage\0" \
> + "fdt_addr=100\0" \
> + "fdtimage=socfpga.dtb\0" \
> + "fsloadcmd=ext2load\0" \
> + "bootm ${loadaddr} - ${fdt_addr}\0" \
> + "mmcroot=/dev/mmcblk0p2\0" \
> [snip]
> + "mmcload=mmc rescan;" \
> + "load mmc 0:1 ${loadaddr} ${bootimage};" \
> + "load mmc 0:1 ${fdt_addr} ${fdtimage}\0" \

The FAT partition is supposed to be the first and the Linux one as the
second. So the boot partition is to be placed at the end of the SD card.

I find it quite weird as it makes the fdisk call more complex then
necessary. I have to compute the position of the boot partition based
on the size of the SD card. If I just create the paritions in the (say)
natural order a2, b, 83 everything is pretty straight-forward.

So, what is the reason of this? Why anybody likes to use such layout?

Thanks
Jan Viktorin


-- 
   Jan Viktorin  E-mail: vikto...@rehivetech.com
   System Architect  Web:www.RehiveTech.com
   RehiveTech
   Brno, Czech Republic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] mmc: atmel: Properly fix clock configuration

[Andreas Bießmann]

Hi Gregory,

On 05.11.15 20:58, Gregory CLEMENT wrote:
> Timing issue occurs on eMMC not only when modifying the frequency but
> also for all the switch command(CMD6). According to the MMC spec waiting
> 8 clocks after a switch command would be the thing to do.
> 
> This patch allows fixing CPU hang observed when trying to changing the
> bus width on a eMMC on SAMA5D4.
> 
> Signed-off-by: Gregory CLEMENT 
> Tested-by: Marek Vasut  # on DENX MA5D4EV

this patch seams to break avr32 ... I'm on it to investigate the root cause.

Andreas

> ---
>  drivers/mmc/gen_atmel_mci.c | 15 ---
>  1 file changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/mmc/gen_atmel_mci.c b/drivers/mmc/gen_atmel_mci.c
> index da870c6..f090b27 100644
> --- a/drivers/mmc/gen_atmel_mci.c
> +++ b/drivers/mmc/gen_atmel_mci.c
> @@ -36,6 +36,7 @@ struct atmel_mci_priv {
>   struct mmc_config   cfg;
>   struct atmel_mci*mci;
>   unsigned intinitialized:1;
> + unsigned intcurr_clk;
>  };
>  
>  /* Read Atmel MCI IP version */
> @@ -91,7 +92,10 @@ static void mci_set_mode(struct mmc *mmc, u32 hz, u32 
> blklen)
>  
>   }
>   }
> -
> + if (version >= 0x500)
> + priv->curr_clk = bus_hz / (clkdiv * 2 + clkodd + 2);
> + else
> + priv->curr_clk = (bus_hz / (clkdiv + 1)) / 2;
>   blklen &= 0xfffc;
>  
>   mr = MMCI_BF(CLKDIV, clkdiv);
> @@ -118,8 +122,6 @@ static void mci_set_mode(struct mmc *mmc, u32 hz, u32 
> blklen)
>   if (mmc->card_caps & mmc->cfg->host_caps & MMC_MODE_HS)
>   writel(MMCI_BIT(HSMODE), >cfg);
>  
> - udelay(50);
> -
>   priv->initialized = 1;
>  }
>  
> @@ -323,6 +325,13 @@ mci_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd, 
> struct mmc_data *data)
>   }
>   }
>  
> + /*
> +  * After the switch command, wait for 8 clocks before the next
> +  * command
> +  */
> + if (cmd->cmdidx == MMC_CMD_SWITCH)
> + udelay(8*100/ priv->curr_clk); /* 8 clk in us */
> +
>   return 0;
>  }
>  
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 10/10] ARM: socfpga: arria10: add support for building Arria10

[Dinh Nguyen]

On 11/20/2015 06:49 AM, Marek Vasut wrote:
> On Friday, November 20, 2015 at 12:28:47 AM, Dinh Nguyen wrote:
>> On 11/19/2015 04:45 PM, Marek Vasut wrote:
>>> On Thursday, November 19, 2015 at 10:35:47 PM,
>>> dingu...@opensource.altera.com
>>>
>>> wrote:
 From: Dinh Nguyen 

 Update Makefile to build Arria 10.

 Signed-off-by: Dinh Nguyen 
 ---

  arch/arm/mach-socfpga/Makefile | 7 +--
  arch/arm/mach-socfpga/arria10/Makefile | 7 +++
  2 files changed, 12 insertions(+), 2 deletions(-)
  create mode 100644 arch/arm/mach-socfpga/arria10/Makefile

 diff --git a/arch/arm/mach-socfpga/Makefile
 b/arch/arm/mach-socfpga/Makefile index 316b326..0dbe9bb 100644
 --- a/arch/arm/mach-socfpga/Makefile
 +++ b/arch/arm/mach-socfpga/Makefile
 @@ -6,15 +6,18 @@

  #
  # SPDX-License-Identifier:GPL-2.0+
  #

 -
 +ifneq ($(CONFIG_TARGET_SOCFPGA_ARRIA10),y)

  obj-y += misc.o timer.o reset_manager.o system_manager.o
>>>
>>> clock_manager.o \
>>>
   fpga_manager.o scan_manager.o
  
  obj-$(CONFIG_SPL_BUILD) += spl.o freeze_controller.o

 -

  # QTS-generated config file wrappers
  obj-y += wrap_pll_config.o
  obj-$(CONFIG_SPL_BUILD) += wrap_iocsr_config.o wrap_pinmux_config.o   
 \
  
   wrap_sdram_config.o

 +else
 +obj-y += arria10/
>>>
>>> So why exactly does A10 have it's own dedicated dir if most of the code
>>> is probably shared between A10 and AV/CV ?
>>
>> Yes, there are some sharing. But I think that there will be enough
>> differences that will ultimately warrant it's own directory. I think
>> with it's own directory, the Makefile changes stay a bit cleaner. I
> 
> Linux doesn't seem to require a separate directory though, does it ?
> I'm not convinced we need one either.
> 
>> One of the biggest differences is that the A10's SDRAM support is going
>> to be a bit ugly.
> 
> The SDRAM code goes into drivers/ddr/ , no problem.
> 
>> The main point is that we need to program the FPGA
>> during U-Boot booting up with a ~>10 MB rbf file while being limited to
>> the OCRAM's size. I would like to contain this ugliness in it's own
>> directory.
> 
> What's the problem with this ? We already support loading files from storage
> in SPL, so just compile the FPGA manager into SPL as well and use it.
> 

Ok, let me re-work it all under the c5/a5 directory. Thanks for reviewing.

Dinh

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

Re: [U-Boot] [PATCH] ARM: zynq: Fix location of stack and malloc areas

[Moritz Fischer]

On Mon, Nov 23, 2015 at 7:41 AM, Michal Simek  wrote:
> The patch
> "board_init: Change the logic to setup malloc_base"
> (sha1: 9ac4fc82071ce346e3885118242ff45d22f69b82)
> breaks SPL for Zynq because it puts early alloc area on the stack which
> caused that stack was decreased by CONFIG_SYS_MALLOC_F_LEN (0x400)
> and there was not enough space for regular stack.
>
> This patch changes memory layout to better utilize the last 64k OCM
> block.
> 0x - 0xfff1000 - Full malloc space
> 0x1000 - 0x300 - Stack location
> 0xf300 - CONFIG_SYS_MALLOC_F_LEN - Early malloc space
> 0xfd00 - sizeof(GD) - GD
> 0xfe00 - 0x - SoC specific boot code
>
> Signed-off-by: Michal Simek 

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

Re: [U-Boot] [PATCH 10/10] ARM: socfpga: arria10: add support for building Arria10

[Dinh Nguyen]

On 11/23/2015 09:38 AM, Marek Vasut wrote:
> On Monday, November 23, 2015 at 03:36:14 PM, Dinh Nguyen wrote:
>> On 11/20/2015 06:49 AM, Marek Vasut wrote:
>>> On Friday, November 20, 2015 at 12:28:47 AM, Dinh Nguyen wrote:
 On 11/19/2015 04:45 PM, Marek Vasut wrote:
> On Thursday, November 19, 2015 at 10:35:47 PM,
> dingu...@opensource.altera.com
>
> wrote:
>> From: Dinh Nguyen 
>>
>> Update Makefile to build Arria 10.
>>
>> Signed-off-by: Dinh Nguyen 
>> ---
>>
>>  arch/arm/mach-socfpga/Makefile | 7 +--
>>  arch/arm/mach-socfpga/arria10/Makefile | 7 +++
>>  2 files changed, 12 insertions(+), 2 deletions(-)
>>  create mode 100644 arch/arm/mach-socfpga/arria10/Makefile
>>
>> diff --git a/arch/arm/mach-socfpga/Makefile
>> b/arch/arm/mach-socfpga/Makefile index 316b326..0dbe9bb 100644
>> --- a/arch/arm/mach-socfpga/Makefile
>> +++ b/arch/arm/mach-socfpga/Makefile
>> @@ -6,15 +6,18 @@
>>
>>  #
>>  # SPDX-License-Identifier:  GPL-2.0+
>>  #
>>
>> -
>> +ifneq ($(CONFIG_TARGET_SOCFPGA_ARRIA10),y)
>>
>>  obj-y   += misc.o timer.o reset_manager.o system_manager.o
>
> clock_manager.o \
>
>> fpga_manager.o scan_manager.o
>>  
>>  obj-$(CONFIG_SPL_BUILD) += spl.o freeze_controller.o
>>
>> -
>>
>>  # QTS-generated config file wrappers
>>  obj-y   += wrap_pll_config.o
>>  obj-$(CONFIG_SPL_BUILD) += wrap_iocsr_config.o wrap_pinmux_config.o 
>> \
>>  
>> wrap_sdram_config.o
>>
>> +else
>> +obj-y   += arria10/
>
> So why exactly does A10 have it's own dedicated dir if most of the code
> is probably shared between A10 and AV/CV ?

 Yes, there are some sharing. But I think that there will be enough
 differences that will ultimately warrant it's own directory. I think
 with it's own directory, the Makefile changes stay a bit cleaner. I
>>>
>>> Linux doesn't seem to require a separate directory though, does it ?
>>> I'm not convinced we need one either.
>>>
 One of the biggest differences is that the A10's SDRAM support is going
 to be a bit ugly.
>>>
>>> The SDRAM code goes into drivers/ddr/ , no problem.
>>>
 The main point is that we need to program the FPGA
 during U-Boot booting up with a ~>10 MB rbf file while being limited to
 the OCRAM's size. I would like to contain this ugliness in it's own
 directory.
>>>
>>> What's the problem with this ? We already support loading files from
>>> storage in SPL, so just compile the FPGA manager into SPL as well and
>>> use it.
>>
>> Ok, let me re-work it all under the c5/a5 directory. Thanks for reviewing.
> 
> But you didn't really answer my question -- what is the problem with the FPGA
> loader in SPL ?
> 

I thought you've already answered your own question. For whatever
reason, the downstream A10 is re-doing the FPGA manager just for this
purpose.

Dinh

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

Re: [U-Boot] [PATCH 25/25] dm: net: usb: Convert mcs7830 driver to support driver model

[Joe Hershberger]

On Mon, Nov 16, 2015 at 9:54 PM, Simon Glass  wrote:
> Adjust this driver to support driver model for Ethernet.
>
> Signed-off-by: Simon Glass 

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

Re: [U-Boot] [PATCH 24/25] dm: net: usb: Refactor mcs7830 driver ready for DM conversion

[Joe Hershberger]

Hi Simon,

On Mon, Nov 16, 2015 at 9:54 PM, Simon Glass  wrote:
> Remove stamp data and create common functions for the main Ethernet
> operations. This will make it easier to convert this driver to support
> driver model.
>
> Signed-off-by: Simon Glass 

LGTM.

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

Re: [U-Boot] [PATCH] Revert "net: phy: delay only if reset handler is registered"

[Jörg Krause]

On Mo, 2015-11-23 at 16:16 -0200, Fabio Estevam wrote:
> Hi Jörg ,
> 
> On Fri, Nov 20, 2015 at 6:37 PM, Fabio Estevam 
> wrote:
> 
> > Ok, I will test your proposal below on Monday when I get access to
> > my
> > mx6sxsabresd, thanks.
> 
> Your proposal worked fine, thanks. Will send it as a formal patch.

This is good news!

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

Re: [U-Boot] pci: fix address range check in __pci_hose_phys_to_bus()

[Tom Rini]

On Wed, Nov 18, 2015 at 03:05:06PM +0100, Marcel Ziswiler wrote:

> The address range check may overflow if the memory region is located at
> the top of the 32-bit address space. This can e.g. be seen on TK1 if
> using the E1000 gigabit Ethernet driver where start and size are both
> 0x8000 leading to the following messages:
> 
> Apalis TK1 # tftpboot $loadaddr test_file
> Using e1000#0 device
> TFTP from server 192.168.10.1; our IP address is 192.168.10.2
> Filename 'test_file'.
> Load address: 0x80408000
> Loading: pci_hose_phys_to_bus: invalid physical address
> 
> This patch fixes this by changing the order of the addition vs.
> subtraction in the range check just like already done in
> __pci_hose_bus_to_phys().
> 
> Reported-by: Ivan Mercier 
> Signed-off-by: Marcel Ziswiler 
> Reviewed-by: Bin Meng 
> Reviewed-by: Stephen Warren 
> Acked-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, 2/5] gpt: doc: README: Update README entry for gpt verify extension

[Tom Rini]

On Fri, Nov 20, 2015 at 08:06:14AM +0100, Lukasz Majewski wrote:

> ./doc/README.gpt entry has been updated to explain usage of "gpt verify"
> command.
> 
> Signed-off-by: Lukasz Majewski 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v2, 1/5] gpt: command: Remove duplicated check for empty partition description

[Tom Rini]

On Fri, Nov 20, 2015 at 08:06:13AM +0100, Lukasz Majewski wrote:

> Exactly the same check is performed in set_gpt_info() function executed
> just after this check.
> 
> Signed-off-by: Lukasz Majewski 
> 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] fs: ext4: Prevent infinite loop in ext4fs_iterate_dir

[Tom Rini]

On Wed, Nov 18, 2015 at 12:42:53PM -0500, Thomas Fitzsimmons wrote:

> If the ext3 journal gets out of sync with what is written on disk, for
> example because of an unexpected power cut, ext4fs_read_file can
> return an all-zero directory entry.  In that case, ext4fs_iterate_dir
> would infinite loop.
> 
> This patch detects when a directory entry's direntlen member is 0 and
> returns a failure status, which breaks out of the infinite loop.  As a
> result, U-Boot will not find files that may subsequently be recovered
> when the journal is replayed.
> 
> This is better behaviour than hanging in an infinite loop, but as a
> further improvement maybe U-Boot could interpret the ext3 journal and
> actually find the unsynced entries.
> 
> Signed-off-by: Thomas Fitzsimmons 
> Reviewed-by: Stefan Roese 

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, 5/5] gpt: command: Extend gpt command to support GPT table verification

[Tom Rini]

On Fri, Nov 20, 2015 at 08:06:17AM +0100, Lukasz Majewski wrote:

> This commit adds support for "gpt verify" command, which verifies
> correctness of on-board stored GPT partition table.
> As the optional parameter one can provide '$partitons' environment variable
> to check if partition data (size, offset, name) is correct.
> 
> This command should be regarded as complementary one to "gpt restore".
> 
> Signed-off-by: Lukasz Majewski 
> Reviewed-by: Tom Rini 
> Reviewed-by: Przemyslaw Marczak 

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] am33xx: Remove serial_init in s_init for QSPI/NOR XIP boot

[Tom Rini]

On Fri, Nov 20, 2015 at 04:07:41PM +0530, Vignesh R wrote:

> serial_init() reads global_data, since global_data is not yet
> initialized, this can cause unwanted behaviour leading to QSPI XIP boot
> hang. Also, since serial_init() is anyways called later from
> boar_init_f(), it does not make sense to do the same in s_init().
> 
> Tested on AM437x IDK EVM with QSPI XIP boot.
> 
> Signed-off-by: Vignesh R 
> 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] [PATCH 10/10] ARM: socfpga: arria10: add support for building Arria10

[Marek Vasut]

On Monday, November 23, 2015 at 11:50:15 PM, Dinh Nguyen wrote:
> On 11/23/2015 04:46 PM, Marek Vasut wrote:
> > On Monday, November 23, 2015 at 11:32:27 PM, Dinh Nguyen wrote:
> > [...]
> > 
> >> The main point is that we need to program the FPGA
> >> during U-Boot booting up with a ~>10 MB rbf file while being limited
> >> to the OCRAM's size. I would like to contain this ugliness in it's
> >> own directory.
> > 
> > What's the problem with this ? We already support loading files from
> > storage in SPL, so just compile the FPGA manager into SPL as well and
> > use it.
>  
>  Ok, let me re-work it all under the c5/a5 directory. Thanks for
>  reviewing.
> >>> 
> >>> But you didn't really answer my question -- what is the problem with
> >>> the FPGA loader in SPL ?
> >> 
> >> I thought you've already answered your own question. For whatever
> >> reason, the downstream A10 is re-doing the FPGA manager just for this
> >> purpose.
> > 
> > Could the reason be that the FPGA manager in it's current state expects
> > one big buffer with the entire FPGA bitstream ? When you're in SPL and
> > you still don't have DRAM running, you cannot create such buffer
> > anywhere. Thus, what you need to do is to have some sort of code which
> > loads a bit of the bitstream file at time and feeds it into the FPGA
> > manager, piece by piece. This should be doable pretty easily, what do
> > you think ?
> 
> That's exactly what is being in the mach-socfpga directory.

Um, am I missing it in this patchset ?

> Yes, but should that code go into mach-socfpga or drivers?

The FPGA manager bits are already in drivers/fpga/ , so that's where the 
improvements should go. If you need some special handling in the SPL,
that should be in mach-socfpga . In case it's too much change to the current 
SPL, moving the spl.c to spl-gen5.c and creating new spl-gen10.c might make 
sense ... or something like that, possibly even with some spl-common.c .

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

Re: [U-Boot] U-boot broken on e500v2 soc

[Scott Wood]

On Fri, 2015-11-20 at 22:33 -0800, York Sun wrote:
> Valentin,
> 
> Can you refresh my memory why you needed this
> commitac337168ad81a18e768e5e3cfff8d229adeb2b25 (patch
> http://patchwork.ozlabs.org/patch/455439)?
> Today I bisect an issue back to this commit.
> 
> Scott,
> 
> Can you help to examine this u-boot commit? Before this commit,
> 512x/5xxx/83xx/85xx do nothing on function invalidate_dcache_range() and
> flush_dcache_range(). With this patch, I found e500v2 is broken on Intel
> e1000
> card when testing v2016-rc1. I didn't catch this issue when testing this
> patch.
>
> I wonder if this code is not safe for e500v2, or because the cache line size
> should be determined by reading L1CFG0. Why didn't we see any issue with
> Linux
> with the same code.

L1_CACHE_SIZE should be 5 as long as CONFIG_E500MC is not defined.  I'm not
sure what Linux has to do with this since it isn't the same code (in
particular, Linux knows that the I/O is coherent and doesn't flush on e500).

What happens if you comment out invalidate_cache_range() but leave
flush_cache_range()?  We should never need to do the former on e500.

> Log for testing on e500v2
> 
> P1023RDB
> 
> U-Boot 2016.01-rc1-00115-g2b24e09 (Nov 20 2015 - 22:01:56 -0800)
> 
> CPU0:  P1023E, Version: 1.1, (0x80fe0011)
> Core:  e500, Version: 5.1, (0x80212151)
> Clock Configuration:
>CPU0:500  MHz, CPU1:500  MHz,
>CCB:333.333 MHz,
>DDR:333.333 MHz (666.667 MT/s data rate) (Asynchronous), LBC:41.667 MHz
>FMAN1: 333.333 MHz
>QMAN:  0 MHz
> L1:D-cache 32 KiB enabled
>I-cache 32 KiB enabled
> Board: P1023 RDB
> I2C:   ready
> DRAM:  DIMM 0: is not a DDR3 SPD.
> SPD error on controller 0! Trying fallback to raw timing calculation
> Detected UDIMM Fixed DDR on board
> 512 MiB (DDR3, 32-bit, CL=5, ECC off)
> Flash: 64 MiB
> L2:256 KiB enabled
> NAND:  128 MiB
> EEPROM: CRC mismatch (a7fdad5b != )
> PCIe1: Root Complex of Slot 1, no link, regs @ 0xff60a000
> PCIe1: Bus 00 - 00
> PCIe2: Root Complex of Slot 2, x1 gen1, regs @ 0xff609000
>   02:00.0 - 8086:107d - Network controller
> PCIe2: Bus 01 - 02
> PCIe3: Root Complex of Slot 3, x1 gen1, regs @ 0xff60b000
>   04:00.0 - 168c:0030 - Network controller
> PCIe3: Bus 03 - 04
> In:serial
> Out:   serial
> Err:   serial
> Net:   Fman1: Uploading microcode version 160.0.18
> e1000: 00:15:17:8e:7b:8d
>FM1@DTSEC1, FM1@DTSEC2, e1000#0 [PRIME]
> Warning: e1000#0 MAC addresses don't match:
> Address in SROM is 00:15:17:8e:7b:8d
> Address in environment is  00:e0:0c:00:06:02
> 
> => ping $serverip
> Using e1000#0 device
> Bad trap at PC: 1ffc6f10, SR: 6049434, vector=e00
> NIP: 1FFC6F10 XER:  LR: 1FEF0B6C REGS: 1f8eda70 TRAP: 0e00 DAR: 
> 2000
> MSR: 06049434 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
> 
> GPR00: 1FF457D4 1F8EDB60 1F8EDF14 2000 0002 001F  1F8EDAB8
> GPR08: A0003818 4000 0003 1F8EDB80 1FF457D4 EC662032 1FFC8D50 1FFC6F24
> GPR16: 1FFB0074 1FFB005C 1FF59701 1FF5971F 1FF49C37 1FFB0068  1FFC6F10
> GPR24: 1FFB00CC 1FF48D60  1F8F3D70 1FFC5600 0040 1FF5C610 0040
> Call backtrace:
> 1FF2F350 1FF457D4 1FF06888 1FF13AF8 1FEFA180 1FEFA7FC 1FEF9A90
> 1FEFA124 1FEFA7FC 1FEFAA1C 1FF12B54 1FEFB140 1FF3AA7C 1FEFB454
> 1FEF0F4C
> Exception in kernel pc 1ffc6f10 signal 0
> ### ERROR ### Please RESET the board ###

0xe00 is an instruction TLB error.  Could you dump the TLB when this happens?

DAR of 0x2000 looks like something that would actually cause a problem,
but that's only relevant to data exceptions, not instruction.

What is the instruction at 0x1ffc6f10?

-Scott

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

Re: [U-Boot] part:efi: add bootable parameter in gpt command

[Tom Rini]

On Tue, Nov 17, 2015 at 11:36:52AM +0100, Patrick Delaunay wrote:

> The optional parameter bootable is added in gpt command to set the
> partition attribute flag "Legacy BIOS bootable"
> 
> This flag is used in extlinux and so in with distro to select
> the boot partition where is located the configuration file
> (please check out doc/README.distro for details).
> 
> With this parameter, U-Boot can be used to create the boot partition
> needed for device using distro.
> 
> example of use:
> 
> setenv partitions "name=u-boot,size=60MiB;name=boot,size=60Mib,bootable;\
>name=rootfs,size=0"
> 
> > gpt write mmc 0 $partitions
> 
> > part list mmc 0
> 
> Partition Map for MMC device 0  --   Partition Type: EFI
> 
> Part  Start LBA   End LBA Name
>   Attributes
>   Type GUID
>   Partition GUID
>   1   0x0022  0x0001e021  "u-boot"
>   attrs:  0x
>   type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
>   guid:   cceb0b18-39cb-d547-9db7-03b405fa77d4
>   2   0x0001e022  0x0003c021  "boot"
>   attrs:  0x0004
>   type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
>   guid:   d4981a2b-0478-544e-9607-7fd3c651068d
>   3   0x0003c022  0x003a9fde  "rootfs"
>   attrs:  0x
>   type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
>   guid:   6d6c9a36-e919-264d-a9ee-bd00379686c7
> 
> > part list mmc 0 -bootable devplist
> 
> > printenv devplist
> 
> devplist=2
> 
> Then the distro scripts will search extlinux in partition 2
> and not in the first partition.
> 
> Signed-off-by: Patrick Delaunay 

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 v2 0/5] gpt: command: Add support for "gpt verify" command

[Tom Rini]

On Fri, Nov 20, 2015 at 08:06:12AM +0100, Lukasz Majewski wrote:

> Up till now "gpt" command was only able to write (i.e. restore) GPT
> partition on specified medium with information provided at "$partitions"
> env variable.
> 
> This patch series adds complementary feature - namely "gpt verify", which
> allows checking (at e.g. boot time) if previously created GPT layout is
> still correct.
> 
> This patch series clearly applies on top of u-boot/master:
> SHA1: 736d1746fb7b8f7cd70657a4a72db2b6bd8de40e
> 
> It has been tested on Beaglebone Black development board (Sitara AM335x
> CPU).
> 
> 
> Lukasz Majewski (5):
>   gpt: command: Remove duplicated check for empty partition description
>   gpt: doc: README: Update README entry for gpt verify extension
>   gpt: doc: Update gpt command's help description
>   gpt: part: Definition and declaration of GPT verification functions
>   gpt: command: Extend gpt command to support GPT table verification

So, I was going to say one thing here, but it turns out I guessed wrong
about which part of the previous series still applied (it was 4/6, not
3/6, even 'tho #3 was not included in the v2 posts).  In the future,
unless you're just changing one patch in the series, please repost the
whole thing, it makes applying easier (and you can just say Changes in
vX: None in the changelog for the unchanged patch).  Thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, 4/4, v2] lib/tiny-printf.c: Support numbers bigger than 0xffff and misc updates

[Tom Rini]

On Mon, Nov 16, 2015 at 03:26:34PM +0100, Stefan Roese wrote:

> With this patch now, the tiny printf() function also supports numbers
> bigger than 0x. Additionally the code is simplified a bit and
> some static variables are moved to function parameters. Also the
> upper case hex variable output support is removed, as its not really
> needed in this simple printf version. And removing it reduces the
> complexity and the code size again a bit.
> 
> Here the new numbers, again on the db-mv784mp-gp (Armada XP):
> 
> Without this patch:
>   56542   185361956   77034   12cea ./spl/u-boot-spl
> 
> With this patch:
>   56446   185361936   76918   12c76 ./spl/u-boot-spl
> 
> Signed-off-by: Stefan Roese 
> Cc: Simon Glass 
> Cc: Hans de Goede 
> Cc: Tom Rini 
> Cc: Albert Aribaud 

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] u-boot-avr32/master -> u-boot/master

[Tom Rini]

On Mon, Nov 23, 2015 at 02:53:22PM +0100, Andreas Bießmann wrote:

> Hi Tom,
> 
> please pull from u-boot-avr32/master
> 
> Andreas
> 
> The following changes since commit d018cd20b3d70e9deba8dbf2643853edfc977dff:
> 
>   sunxi: Update new defconfigs (2015-11-22 10:46:25 -0500)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-avr32.git master
> 
> for you to fetch changes up to f300dccde433bf9e0223e1be489822fdc1cc83e2:
> 
>   i2c, avr32: fix compiler warning "input is not relaxable" (2015-11-23 
> 14:47:48 +0100)
> 

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, 2/4, v2] common/console.c: Small coding style cleanup

[Tom Rini]

On Mon, Nov 16, 2015 at 03:26:32PM +0100, Stefan Roese wrote:

> Change some comments to match the U-Boot coding style rules.
> 
> Signed-off-by: Stefan Roese 
> Cc: Simon Glass 
> Acked-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, 4/6] gpt: doc: Update gpt command's help description

[Tom Rini]

On Fri, Nov 13, 2015 at 07:42:10AM +0100, Lukasz Majewski wrote:

> Signed-off-by: Lukasz Majewski 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, 1/4, v2] common/console.c: Drop sandbox special-case console code

[Tom Rini]

On Mon, Nov 16, 2015 at 03:26:31PM +0100, Stefan Roese wrote:

> As done in commit da229e4e [sandbox: Drop special-case sandbox console code],
> this patch drops the sandbox special-case code in vprintf() that was
> missed by Simon at that time.
> 
> Signed-off-by: Stefan Roese 
> Cc: Simon Glass 
> Acked-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] [PATCH 10/10] ARM: socfpga: arria10: add support for building Arria10

[Marek Vasut]

On Monday, November 23, 2015 at 11:32:27 PM, Dinh Nguyen wrote:
[...]
>  The main point is that we need to program the FPGA
>  during U-Boot booting up with a ~>10 MB rbf file while being limited
>  to the OCRAM's size. I would like to contain this ugliness in it's
>  own directory.
> >>> 
> >>> What's the problem with this ? We already support loading files from
> >>> storage in SPL, so just compile the FPGA manager into SPL as well and
> >>> use it.
> >> 
> >> Ok, let me re-work it all under the c5/a5 directory. Thanks for
> >> reviewing.
> > 
> > But you didn't really answer my question -- what is the problem with the
> > FPGA loader in SPL ?
> 
> I thought you've already answered your own question. For whatever
> reason, the downstream A10 is re-doing the FPGA manager just for this
> purpose.

Could the reason be that the FPGA manager in it's current state expects one big 
buffer with the entire FPGA bitstream ? When you're in SPL and you still don't 
have DRAM running, you cannot create such buffer anywhere. Thus, what you need
to do is to have some sort of code which loads a bit of the bitstream file at 
time and feeds it into the FPGA manager, piece by piece. This should be doable
pretty easily, what do you think ?

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

Re: [U-Boot] [U-Boot, v2, 4/5] gpt: part: Definition and declaration of GPT verification functions

[Tom Rini]

On Fri, Nov 20, 2015 at 08:06:16AM +0100, Lukasz Majewski wrote:

> This commit provides definition and declaration of GPT verification
> functions - namely gpt_verify_headers() and gpt_verify_partitions().
> The former is used to only check CRC32 of GPT's header and PTEs.
> The latter examines each partition entry and compare attributes such as:
> name, start offset and size with ones provided at '$partitions' env
> variable.
> 
> Signed-off-by: Lukasz Majewski 
> Reviewed-by: Tom Rini 
> Reviewed-by: Przemyslaw Marczak 

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, 3/4, v3] lib/tiny-printf.c: Add tiny printf function for space limited environments

[Tom Rini]

On Mon, Nov 23, 2015 at 07:00:22AM +0100, Stefan Roese wrote:

> This patch adds a small printf() version that supports all basic formats.
> Its intented to be used in U-Boot SPL versions on platforms with very
> limited internal RAM sizes.
> 
> To enable it, just define CONFIG_USE_TINY_PRINTF in your defconfig. This
> will result in the SPL using this tiny function and the main U-Boot
> still using the full-blown printf() function.
> 
> This code was copied from:
> http://www.sparetimelabs.com/printfrevisited
> With mostly only coding style related changes so that its checkpatch
> clean.
> 
> The size reduction is about 2.5KiB. Here a comparison for the db-mv784mp-gp
> (Marvell AXP) SPL:
> 
> Without this patch:
>   58963   185361928   79427   13643 ./spl/u-boot-spl
> 
> With this patch:
>   56542   185361956   77034   12cea ./spl/u-boot-spl
> 
> Note:
> To make it possible to compile tiny-printf.c instead of vsprintf.c when
> CONFIG_USE_TINY_PRINTF is defined, the functions printf() and vprintf() are
> moved from common/console.c into vsprintf.c in this patch.
> 
> Signed-off-by: Stefan Roese 
> Cc: Simon Glass 
> Cc: Hans de Goede 
> Cc: Tom Rini 
> Cc: Albert Aribaud 

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 10/10] ARM: socfpga: arria10: add support for building Arria10

[Dinh Nguyen]

On 11/23/2015 05:03 PM, Marek Vasut wrote:
> On Monday, November 23, 2015 at 11:50:15 PM, Dinh Nguyen wrote:
>> On 11/23/2015 04:46 PM, Marek Vasut wrote:
>>> On Monday, November 23, 2015 at 11:32:27 PM, Dinh Nguyen wrote:
>>> [...]
>>>
 The main point is that we need to program the FPGA
 during U-Boot booting up with a ~>10 MB rbf file while being limited
 to the OCRAM's size. I would like to contain this ugliness in it's
 own directory.
>>>
>>> What's the problem with this ? We already support loading files from
>>> storage in SPL, so just compile the FPGA manager into SPL as well and
>>> use it.
>>
>> Ok, let me re-work it all under the c5/a5 directory. Thanks for
>> reviewing.
>
> But you didn't really answer my question -- what is the problem with
> the FPGA loader in SPL ?

 I thought you've already answered your own question. For whatever
 reason, the downstream A10 is re-doing the FPGA manager just for this
 purpose.
>>>
>>> Could the reason be that the FPGA manager in it's current state expects
>>> one big buffer with the entire FPGA bitstream ? When you're in SPL and
>>> you still don't have DRAM running, you cannot create such buffer
>>> anywhere. Thus, what you need to do is to have some sort of code which
>>> loads a bit of the bitstream file at time and feeds it into the FPGA
>>> manager, piece by piece. This should be doable pretty easily, what do
>>> you think ?
>>
>> That's exactly what is being in the mach-socfpga directory.
> 
> Um, am I missing it in this patchset ?
> 

No, you're not missing it, I have not sent it up yet. That support is in
the downstream, but also with the fpga-manager driver re-written. I need
to clean this up before I can send it.

>> Yes, but should that code go into mach-socfpga or drivers?
> 
> The FPGA manager bits are already in drivers/fpga/ , so that's where the 
> improvements should go. If you need some special handling in the SPL,
> that should be in mach-socfpga . In case it's too much change to the current 
> SPL, moving the spl.c to spl-gen5.c and creating new spl-gen10.c might make 
> sense ... or something like that, possibly even with some spl-common.c .
> 

Ok. BTW, Arria10 is not using SPL. It has 256K of OCRAM that U-Boot can
use to setup the SDRAM.

Dinh

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

Re: [U-Boot] [PATCH 10/10] ARM: socfpga: arria10: add support for building Arria10

[Marek Vasut]

On Tuesday, November 24, 2015 at 12:04:10 AM, Dinh Nguyen wrote:
> On 11/23/2015 05:03 PM, Marek Vasut wrote:
> > On Monday, November 23, 2015 at 11:50:15 PM, Dinh Nguyen wrote:
> >> On 11/23/2015 04:46 PM, Marek Vasut wrote:
> >>> On Monday, November 23, 2015 at 11:32:27 PM, Dinh Nguyen wrote:
> >>> [...]
> >>> 
>  The main point is that we need to program the FPGA
>  during U-Boot booting up with a ~>10 MB rbf file while being
>  limited to the OCRAM's size. I would like to contain this
>  ugliness in it's own directory.
> >>> 
> >>> What's the problem with this ? We already support loading files
> >>> from storage in SPL, so just compile the FPGA manager into SPL as
> >>> well and use it.
> >> 
> >> Ok, let me re-work it all under the c5/a5 directory. Thanks for
> >> reviewing.
> > 
> > But you didn't really answer my question -- what is the problem with
> > the FPGA loader in SPL ?
>  
>  I thought you've already answered your own question. For whatever
>  reason, the downstream A10 is re-doing the FPGA manager just for this
>  purpose.
> >>> 
> >>> Could the reason be that the FPGA manager in it's current state expects
> >>> one big buffer with the entire FPGA bitstream ? When you're in SPL and
> >>> you still don't have DRAM running, you cannot create such buffer
> >>> anywhere. Thus, what you need to do is to have some sort of code which
> >>> loads a bit of the bitstream file at time and feeds it into the FPGA
> >>> manager, piece by piece. This should be doable pretty easily, what do
> >>> you think ?
> >> 
> >> That's exactly what is being in the mach-socfpga directory.
> > 
> > Um, am I missing it in this patchset ?
> 
> No, you're not missing it, I have not sent it up yet. That support is in
> the downstream, but also with the fpga-manager driver re-written. I need
> to clean this up before I can send it.

OK, thanks :)

> >> Yes, but should that code go into mach-socfpga or drivers?
> > 
> > The FPGA manager bits are already in drivers/fpga/ , so that's where the
> > improvements should go. If you need some special handling in the SPL,
> > that should be in mach-socfpga . In case it's too much change to the
> > current SPL, moving the spl.c to spl-gen5.c and creating new spl-gen10.c
> > might make sense ... or something like that, possibly even with some
> > spl-common.c .
> 
> Ok. BTW, Arria10 is not using SPL. It has 256K of OCRAM that U-Boot can
> use to setup the SDRAM.

So what do I do if I want to boot arria10 from NAND ? UBI and UBIFS won't
fit into 256kiB, so I think using SPL might be the sensible thing afterall,
since you would be able to use arbitrarily-sized U-Boot.

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 10/10] ARM: socfpga: arria10: add support for building Arria10

[Dinh Nguyen]

On 11/23/2015 04:46 PM, Marek Vasut wrote:
> On Monday, November 23, 2015 at 11:32:27 PM, Dinh Nguyen wrote:
> [...]
>> The main point is that we need to program the FPGA
>> during U-Boot booting up with a ~>10 MB rbf file while being limited
>> to the OCRAM's size. I would like to contain this ugliness in it's
>> own directory.
>
> What's the problem with this ? We already support loading files from
> storage in SPL, so just compile the FPGA manager into SPL as well and
> use it.

 Ok, let me re-work it all under the c5/a5 directory. Thanks for
 reviewing.
>>>
>>> But you didn't really answer my question -- what is the problem with the
>>> FPGA loader in SPL ?
>>
>> I thought you've already answered your own question. For whatever
>> reason, the downstream A10 is re-doing the FPGA manager just for this
>> purpose.
> 
> Could the reason be that the FPGA manager in it's current state expects one 
> big 
> buffer with the entire FPGA bitstream ? When you're in SPL and you still 
> don't 
> have DRAM running, you cannot create such buffer anywhere. Thus, what you need
> to do is to have some sort of code which loads a bit of the bitstream file at 
> time and feeds it into the FPGA manager, piece by piece. This should be doable
> pretty easily, what do you think ?
> 

That's exactly what is being in the mach-socfpga directory. Yes, but
should that code go into mach-socfpga or drivers?

Dinh

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

Re: [U-Boot] [PATCH 01/10] ARM: socfpga: arria10: add base address map for Arria10

[Dinh Nguyen]

On 11/19/2015 04:26 PM, Marek Vasut wrote:
> On Thursday, November 19, 2015 at 10:35:38 PM, dingu...@opensource.altera.com 
> wrote:
>> From: Dinh Nguyen 
>>
>> Add the base address map for Arria10.
>>
>> Signed-off-by: Dinh Nguyen 
>> ---
>>  .../include/mach/socfpga_a10_base_addrs.h  | 45
> 
> Reviewed-by: Marek Vasut 
> 
> btw. it'd be nice if we could rename the socfpga_base_addrs.h to just plain
> base_addr_ca5.h
> 
> and then call this file
> base_addr_a10.h
> 
> This might be more systematic, don't you think ?
> 

Yes, I agree. I'll send a patch to rename the socfpga_base_addr.h for
ac5 along with v2 of this.

Dinh

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

Re: [U-Boot] [PATCH 1/2][v2] armv8: LS2080A: Rename LS2085A to reflect LS2080A

[Kushwaha Prabhakar]

> -Original Message-
> From: York Sun [mailto:york...@freescale.com]
> Sent: Tuesday, November 24, 2015 12:49 AM
> To: Kushwaha Prabhakar-B32579 ; u-
> b...@lists.denx.de
> Cc: Srivastava Pratiyush-B46174 
> Subject: Re: [PATCH 1/2][v2] armv8: LS2080A: Rename LS2085A to reflect
> LS2080A
> 
> 
> 
> On 11/09/2015 03:12 AM, Prabhakar Kushwaha wrote:
> > LS2080A is a prime personality of Freescale’s LS2085A. It is a
> > non-AIOP personality without support of DP-DDR, L2 switch, 1588, PCIe
> endpoint etc.
> > So renaming existing LS2085A code base to reflect LS2080A (Prime
> > personality)
> >
> > Signed-off-by: Pratiyush Mohan Srivastava
> > 
> > Signed-off-by: Prabhakar Kushwaha 
> > ---
> > Changes for v2: Rebased on LS1043 patch set
> 
> 
> 
> > diff --git a/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
> > b/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
> > index 2903996..5a91dcb 100644
> > --- a/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
> > +++ b/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
> > @@ -8,8 +8,10 @@
> >  #define _FSL_LAYERSCAPE_CPU_H
> >
> >  static struct cpu_type cpu_type_list[] = {
> > -   CPU_TYPE_ENTRY(LS2085, LS2085, 8),
> > +#ifdef CONFIG_LS2080A
> > CPU_TYPE_ENTRY(LS2080, LS2080, 8),
> > +#endif
> > +   CPU_TYPE_ENTRY(LS2085, LS2085, 8),
> > CPU_TYPE_ENTRY(LS2045, LS2045, 4),
> > CPU_TYPE_ENTRY(LS1043, LS1043, 4),
> >  };
> 
> Why using ifdef here?

I am trying to reduce size of table.
Instead of adding all SoC in table only defined the required one at a time. 

--prabhakar




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

Re: [U-Boot] [PATCH] Implement pytest-based test infrastructure

[Stephen Warren]

On 11/23/2015 07:18 PM, Simon Glass wrote:
> Hi Stephen,
> 
> On 23 November 2015 at 18:45, Simon Glass  wrote:
>> Hi Stephen,
>>
>> On 22 November 2015 at 10:30, Stephen Warren  wrote:
>>> On 11/21/2015 09:49 AM, Simon Glass wrote:
 Hi Stephen,

 On 19 November 2015 at 12:09, Stephen Warren  wrote:
>
> On 11/19/2015 10:00 AM, Stephen Warren wrote:
>>
>> On 11/19/2015 07:45 AM, Simon Glass wrote:
>>>
>>> Hi Stephen,
>>>
>>> On 14 November 2015 at 23:53, Stephen Warren 
>>> wrote:

 This tool aims to test U-Boot by executing U-Boot shell commands
 using the
 console interface. A single top-level script exists to execute or 
 attach
 to the U-Boot console, run the entire script of tests against it, and
 summarize the results. Advantages of this approach are:

 - Testing is performed in the same way a user or script would interact
with U-Boot; there can be no disconnect.
 - There is no need to write or embed test-related code into U-Boot
 itself.
It is asserted that writing test-related code in Python is simpler
 and
more flexible that writing it all in C.
 - It is reasonably simple to interact with U-Boot in this way.

 A few simple tests are provided as examples. Soon, we should convert as
 many as possible of the other tests in test/* and test/cmd_ut.c too.
>>>
>>>
>>> It's great to see this and thank you for putting in the effort!
>>>
>>> It looks like a good way of doing functional tests. I still see a role
>>> for unit tests and things like test/dm. But if we can arrange to call
>>> all U-Boot tests (unit and functional) from one 'test.py' command that
>>> would be a win.
>>>
>>> I'll look more when I can get it to work - see below.
>
> ...
>>
>> made it print a message about checking the docs for missing
>> requirements. I can probably patch the top-level test.py to do the same.
>
>
> I've pushed such a patch to:
>
> git://github.com/swarren/u-boot.git tegra_dev
> (the separate pytests branch has now been deleted)
>
> There are also a variety of other patches there related to this testing 
> infra-structure. I guess I'll hold off sending them to the list until 
> there's been some general feedback on the patches I've already posted, 
> but feel free to pull the branch down and play with it. Note that it's 
> likely to get rebased as I work.

 OK I got it working thank you. It is horribly slow though - do you
 know what is holding it up? For me to takes 12 seconds to run the
 (very basic) tests.
>>>
>>> It looks like pexpect includes a default delay to simulate human
>>> interaction. If you edit test/py/uboot_console_base.py ensure_spawned()
>>> and add the following somewhere soon after the assignment to self.p:
>>>
>>> self.p.delaybeforesend = 0
>>>
>>> ... that will more than halve the execution time. (8.3 -> 3.5s on my
>>> 5-year-old laptop).
>>>
>>> That said, even your 12s or my 8.3s doesn't seem like a bad price to pay
>>> for some easy-to-use automated testing.
>>
>> Sure, but my reference is to the difference between a native C test
>> and this framework. As we add more and more tests the overhead will be
>> significant. If it takes 8 seconds to run the current (fairly trivial)
>> tests, it might take a minute to run a larger suite, and to me that is
>> too long (e.g. to bisect for a failing commit).
>>
>> I wonder what is causing the delay?
>>
>>>
 Also please see dm_test_usb_tree() which uses a console buffer to
 check command output.
>>>
>>> OK, I'll take a look.
>>>
 I wonder if we should use something like that
 for simple unit tests, and use python for the more complicated
 functional tests?
>>>
>>> I'm not sure that's a good idea; it'd be best to settle on a single way
>>> of executing tests so that (a) people don't have to run/implement
>>> different kinds of tests in different ways (b) we can leverage test code
>>> across as many tests as possible.
>>>
>>> (Well, doing unit tests and system level tests differently might be
>>> necessary since one calls functions and the other uses the shell "user
>>> interface", but having multiple ways of doing e.g. system tests doesn't
>>> seem like a good idea.)
>>
>> As you found with some of the tests, it is convenient/necessary to be
>> able to call U-Boot C functions in some tests. So I don't see this as
>> a one-size-fits-all solution.
>>
>> I think it is perfectly reasonable for the python framework to run the
>> existing C tests - there is no need to rewrite them in Python. Also
>> for the driver model tests - we can just run the tests from some sort
>> of python wrapper and get the best of 

Re: [U-Boot] [PATCH] Implement pytest-based test infrastructure

[Stephen Warren]

On 11/23/2015 06:45 PM, Simon Glass wrote:
> Hi Stephen,
> 
> On 22 November 2015 at 10:30, Stephen Warren  wrote:
>> On 11/21/2015 09:49 AM, Simon Glass wrote:
>>> Hi Stephen,
>>>
>>> On 19 November 2015 at 12:09, Stephen Warren  wrote:

 On 11/19/2015 10:00 AM, Stephen Warren wrote:
>
> On 11/19/2015 07:45 AM, Simon Glass wrote:
>>
>> Hi Stephen,
>>
>> On 14 November 2015 at 23:53, Stephen Warren 
>> wrote:
>>>
>>> This tool aims to test U-Boot by executing U-Boot shell commands
>>> using the
>>> console interface. A single top-level script exists to execute or attach
>>> to the U-Boot console, run the entire script of tests against it, and
>>> summarize the results. Advantages of this approach are:
>>>
>>> - Testing is performed in the same way a user or script would interact
>>>with U-Boot; there can be no disconnect.
>>> - There is no need to write or embed test-related code into U-Boot
>>> itself.
>>>It is asserted that writing test-related code in Python is simpler
>>> and
>>>more flexible that writing it all in C.
>>> - It is reasonably simple to interact with U-Boot in this way.
>>>
>>> A few simple tests are provided as examples. Soon, we should convert as
>>> many as possible of the other tests in test/* and test/cmd_ut.c too.
>>
>>
>> It's great to see this and thank you for putting in the effort!
>>
>> It looks like a good way of doing functional tests. I still see a role
>> for unit tests and things like test/dm. But if we can arrange to call
>> all U-Boot tests (unit and functional) from one 'test.py' command that
>> would be a win.
>>
>> I'll look more when I can get it to work - see below.

 ...
>
> made it print a message about checking the docs for missing
> requirements. I can probably patch the top-level test.py to do the same.


 I've pushed such a patch to:

 git://github.com/swarren/u-boot.git tegra_dev
 (the separate pytests branch has now been deleted)

 There are also a variety of other patches there related to this testing 
 infra-structure. I guess I'll hold off sending them to the list until 
 there's been some general feedback on the patches I've already posted, but 
 feel free to pull the branch down and play with it. Note that it's likely 
 to get rebased as I work.
>>>
>>> OK I got it working thank you. It is horribly slow though - do you
>>> know what is holding it up? For me to takes 12 seconds to run the
>>> (very basic) tests.
>>
>> It looks like pexpect includes a default delay to simulate human
>> interaction. If you edit test/py/uboot_console_base.py ensure_spawned()
>> and add the following somewhere soon after the assignment to self.p:
>>
>> self.p.delaybeforesend = 0
>>
>> ... that will more than halve the execution time. (8.3 -> 3.5s on my
>> 5-year-old laptop).
>>
>> That said, even your 12s or my 8.3s doesn't seem like a bad price to pay
>> for some easy-to-use automated testing.
> 
> Sure, but my reference is to the difference between a native C test
> and this framework. As we add more and more tests the overhead will be
> significant. If it takes 8 seconds to run the current (fairly trivial)
> tests, it might take a minute to run a larger suite, and to me that is
> too long (e.g. to bisect for a failing commit).
> 
> I wonder what is causing the delay?

I actually hope the opposite.

Most of the tests supported today are the most trivial possible tests,
i.e. they take very little CPU time on the target to implement. I would
naively expect that once we implement more interesting tests (USB Mass
Storage, USB enumeration, eMMC/SD/USB data reading, Ethernet DHCP/TFTP,
...) the command invocation overhead will rapidly become insignificant.
This certainly seems to be true for the UMS test I have locally, but who
knows whether this will be more generally true.

I put a bit of time measurement into run_command() and found that on my
system at work, for p.send("the shell command to execute") was actually
(marginally) slower on sandbox than on real HW, despite real HW being a
115200 baud serial port, and the code splitting the shell commands into
chunks that are sent and waited for synchronously to avoid overflowing
UART FIFOs. I'm not sure why this is. Looking at U-Boot's console, it
seems to be non-blocking, so I don't think termios VMIN/VTIME come into
play (setting them to 0 made no difference), and the two raw modes took
the same time. I meant to look into pexpect's termios settings to see if
there was anything to tweak there, but forgot today.

I did do one experiment to compare expect (the Tcl version) and pexpect.
If I do roughly the following in both:

spawn u-boot (sandbox)
wait for prompt
100 times:
send "echo $foo\n"
wait for "echo $foo"

Re: [U-Boot] [PATCH 1/2][v2] armv8: LS2080A: Rename LS2085A to reflect LS2080A

[York Sun]

On 11/23/2015 08:25 PM, Kushwaha Prabhakar-B32579 wrote:
> 
>> -Original Message-
>> From: York Sun [mailto:york...@freescale.com]
>> Sent: Tuesday, November 24, 2015 12:49 AM
>> To: Kushwaha Prabhakar-B32579 ; u-
>> b...@lists.denx.de
>> Cc: Srivastava Pratiyush-B46174 
>> Subject: Re: [PATCH 1/2][v2] armv8: LS2080A: Rename LS2085A to reflect
>> LS2080A
>>
>>
>>
>> On 11/09/2015 03:12 AM, Prabhakar Kushwaha wrote:
>>> LS2080A is a prime personality of Freescale’s LS2085A. It is a
>>> non-AIOP personality without support of DP-DDR, L2 switch, 1588, PCIe
>> endpoint etc.
>>> So renaming existing LS2085A code base to reflect LS2080A (Prime
>>> personality)
>>>
>>> Signed-off-by: Pratiyush Mohan Srivastava
>>> 
>>> Signed-off-by: Prabhakar Kushwaha 
>>> ---
>>> Changes for v2: Rebased on LS1043 patch set
>>
>> 
>>
>>> diff --git a/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
>>> b/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
>>> index 2903996..5a91dcb 100644
>>> --- a/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
>>> +++ b/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
>>> @@ -8,8 +8,10 @@
>>>  #define _FSL_LAYERSCAPE_CPU_H
>>>
>>>  static struct cpu_type cpu_type_list[] = {
>>> -   CPU_TYPE_ENTRY(LS2085, LS2085, 8),
>>> +#ifdef CONFIG_LS2080A
>>> CPU_TYPE_ENTRY(LS2080, LS2080, 8),
>>> +#endif
>>> +   CPU_TYPE_ENTRY(LS2085, LS2085, 8),
>>> CPU_TYPE_ENTRY(LS2045, LS2045, 4),
>>> CPU_TYPE_ENTRY(LS1043, LS1043, 4),
>>>  };
>>
>> Why using ifdef here?
> 
> I am trying to reduce size of table.
> Instead of adding all SoC in table only defined the required one at a time. 

I thought the plan was to support both LS2080 and LS2085 in one image built for
LS2080. We have always used a complete table for cpu list. If you are flexible,
I will drop the ifdef when merging this patch.

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

Re: [U-Boot] [PATCH 1/2][v2] armv8: LS2080A: Rename LS2085A to reflect LS2080A

[Kushwaha Prabhakar]

> -Original Message-
> From: York Sun [mailto:york...@freescale.com]
> Sent: Tuesday, November 24, 2015 11:14 AM
> To: Kushwaha Prabhakar-B32579 ; u-
> b...@lists.denx.de
> Cc: Srivastava Pratiyush-B46174 
> Subject: Re: [PATCH 1/2][v2] armv8: LS2080A: Rename LS2085A to reflect
> LS2080A
> 
> 
> 
> On 11/23/2015 08:25 PM, Kushwaha Prabhakar-B32579 wrote:
> >
> >> -Original Message-
> >> From: York Sun [mailto:york...@freescale.com]
> >> Sent: Tuesday, November 24, 2015 12:49 AM
> >> To: Kushwaha Prabhakar-B32579 ; u-
> >> b...@lists.denx.de
> >> Cc: Srivastava Pratiyush-B46174 
> >> Subject: Re: [PATCH 1/2][v2] armv8: LS2080A: Rename LS2085A to
> >> reflect LS2080A
> >>
> >>
> >>
> >> On 11/09/2015 03:12 AM, Prabhakar Kushwaha wrote:
> >>> LS2080A is a prime personality of Freescale’s LS2085A. It is a
> >>> non-AIOP personality without support of DP-DDR, L2 switch, 1588,
> >>> PCIe
> >> endpoint etc.
> >>> So renaming existing LS2085A code base to reflect LS2080A (Prime
> >>> personality)
> >>>
> >>> Signed-off-by: Pratiyush Mohan Srivastava
> >>> 
> >>> Signed-off-by: Prabhakar Kushwaha 
> >>> ---
> >>> Changes for v2: Rebased on LS1043 patch set
> >>
> >> 
> >>
> >>> diff --git a/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
> >>> b/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
> >>> index 2903996..5a91dcb 100644
> >>> --- a/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
> >>> +++ b/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
> >>> @@ -8,8 +8,10 @@
> >>>  #define _FSL_LAYERSCAPE_CPU_H
> >>>
> >>>  static struct cpu_type cpu_type_list[] = {
> >>> - CPU_TYPE_ENTRY(LS2085, LS2085, 8),
> >>> +#ifdef CONFIG_LS2080A
> >>>   CPU_TYPE_ENTRY(LS2080, LS2080, 8),
> >>> +#endif
> >>> + CPU_TYPE_ENTRY(LS2085, LS2085, 8),
> >>>   CPU_TYPE_ENTRY(LS2045, LS2045, 4),
> >>>   CPU_TYPE_ENTRY(LS1043, LS1043, 4),  };
> >>
> >> Why using ifdef here?
> >
> > I am trying to reduce size of table.
> > Instead of adding all SoC in table only defined the required one at a time.
> 
> I thought the plan was to support both LS2080 and LS2085 in one image built
> for LS2080. We have always used a complete table for cpu list. If you are
> flexible, I will drop the ifdef when merging this patch.
> 

Yes, we can drop the ifdef.

--prabhakar

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

Re: [U-Boot] [PATCH 10/10] ARM: socfpga: arria10: add support for building Arria10

[Dinh Nguyen]

On 11/23/2015 05:20 PM, Marek Vasut wrote:
> On Tuesday, November 24, 2015 at 12:04:10 AM, Dinh Nguyen wrote:
>> On 11/23/2015 05:03 PM, Marek Vasut wrote:
>>> On Monday, November 23, 2015 at 11:50:15 PM, Dinh Nguyen wrote:
 On 11/23/2015 04:46 PM, Marek Vasut wrote:
> On Monday, November 23, 2015 at 11:32:27 PM, Dinh Nguyen wrote:
> [...]
>
>> The main point is that we need to program the FPGA
>> during U-Boot booting up with a ~>10 MB rbf file while being
>> limited to the OCRAM's size. I would like to contain this
>> ugliness in it's own directory.
>
> What's the problem with this ? We already support loading files
> from storage in SPL, so just compile the FPGA manager into SPL as
> well and use it.

 Ok, let me re-work it all under the c5/a5 directory. Thanks for
 reviewing.
>>>
>>> But you didn't really answer my question -- what is the problem with
>>> the FPGA loader in SPL ?
>>
>> I thought you've already answered your own question. For whatever
>> reason, the downstream A10 is re-doing the FPGA manager just for this
>> purpose.
>
> Could the reason be that the FPGA manager in it's current state expects
> one big buffer with the entire FPGA bitstream ? When you're in SPL and
> you still don't have DRAM running, you cannot create such buffer
> anywhere. Thus, what you need to do is to have some sort of code which
> loads a bit of the bitstream file at time and feeds it into the FPGA
> manager, piece by piece. This should be doable pretty easily, what do
> you think ?

 That's exactly what is being in the mach-socfpga directory.
>>>
>>> Um, am I missing it in this patchset ?
>>
>> No, you're not missing it, I have not sent it up yet. That support is in
>> the downstream, but also with the fpga-manager driver re-written. I need
>> to clean this up before I can send it.
> 
> OK, thanks :)
> 
 Yes, but should that code go into mach-socfpga or drivers?
>>>
>>> The FPGA manager bits are already in drivers/fpga/ , so that's where the
>>> improvements should go. If you need some special handling in the SPL,
>>> that should be in mach-socfpga . In case it's too much change to the
>>> current SPL, moving the spl.c to spl-gen5.c and creating new spl-gen10.c
>>> might make sense ... or something like that, possibly even with some
>>> spl-common.c .
>>
>> Ok. BTW, Arria10 is not using SPL. It has 256K of OCRAM that U-Boot can
>> use to setup the SDRAM.
> 
> So what do I do if I want to boot arria10 from NAND ? UBI and UBIFS won't
> fit into 256kiB, so I think using SPL might be the sensible thing afterall,
> since you would be able to use arbitrarily-sized U-Boot.
> 

I hope Chin Liang can chime here, I know that we have support for NAND,
but I haven't been part of that task, so I don't know how it's being done.

Dinh


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

Re: [U-Boot] [RFC PATCH v2 07/11] net: IPv6 support

[Joe Hershberger]

On Mon, Nov 9, 2015 at 1:38 AM, Chris Packham  wrote:
> Adds basic support for IPv6. Neighbor discovery and ping6 are the only
> things supported at the moment.

ping6 is not supported at this moment... not until the next moment.

>
> Helped-by: Hanna Hawa  [endian & alignment fixes]
> Signed-off-by: Chris Packham 
>
> ---
> Now we have something functional. With this and the next patch you can
> do something like 'setenv ipaddr6 3ffe::1/64' and 'ping6 3ffe::2' should
> work.
>
> I seem to have a problem that when you send a ping6 for a non-existent
> address that ends up stuck and the next non-ipv6 net operation tries to
> resolve it. I suspect this is because the pending neighbor discovery
> information isn't cleaned up properly, I need to look into that.
>
> Changes in v2:
> - split ping6 support into separate patch
> - split environment variables into separate patch
> - change ip6_ndisc_* to ndisc_*, fix CamelCase
>
>  include/net.h  |   1 +
>  include/net6.h | 194 +
>  net/Makefile   |   2 +
>  net/ndisc.c| 266 ++
>  net/ndisc.h|  25 +
>  net/net.c  |  38 +++-
>  net/net6.c | 299 
> +
>  7 files changed, 823 insertions(+), 2 deletions(-)
>  create mode 100644 net/ndisc.c
>  create mode 100644 net/ndisc.h
>
> diff --git a/include/net.h b/include/net.h
> index e8bd2b7..8b7c878 100644
> --- a/include/net.h
> +++ b/include/net.h
> @@ -316,6 +316,7 @@ struct vlan_ethernet_hdr {
>  #define VLAN_ETHER_HDR_SIZE(sizeof(struct vlan_ethernet_hdr))
>
>  #define PROT_IP0x0800  /* IP protocol
>   */
> +#define PROT_IP60x86DD  /* IPv6 protocol   */
>  #define PROT_ARP   0x0806  /* IP ARP protocol  */
>  #define PROT_RARP  0x8035  /* IP ARP protocol  */
>  #define PROT_VLAN  0x8100  /* IEEE 802.1q protocol */
> diff --git a/include/net6.h b/include/net6.h
> index a41eb87..ff97c39 100644
> --- a/include/net6.h
> +++ b/include/net6.h
> @@ -22,6 +22,16 @@ struct in6_addr {
>  #define s6_addr32  in6_u.u6_addr32
>  };
>
> +#define IN6ADDRSZ  sizeof(struct in6_addr)
> +#define INETHADDRSZsizeof(net_ethaddr)
> +
> +#define IPV6_ADDRSCOPE_INTF0x01
> +#define IPV6_ADDRSCOPE_LINK0x02
> +#define IPV6_ADDRSCOPE_AMDIN   0x04
> +#define IPV6_ADDRSCOPE_SITE0x05
> +#define IPV6_ADDRSCOPE_ORG 0x08
> +#define IPV6_ADDRSCOPE_GLOBAL  0x0E
> +
>  /**
>   * struct ipv6hdr - Internet Protocol V6 (IPv6) header.
>   *
> @@ -45,6 +55,145 @@ struct ip6_hdr {
> struct in6_addr daddr;
>  };
>
> +#define IP6_HDR_SIZE (sizeof(struct ip6_hdr))
> +
> +/* Handy for static initialisations of struct in6_addr, atlhough the
> + * c99 '= { 0 }' idiom might work depending on you compiler. */

you -> your

> +#define ZERO_IPV6_ADDR { { { 0x00, 0x00, 0x00, 0x00, \
> + 0x00, 0x00, 0x00, 0x00, \
> + 0x00, 0x00, 0x00, 0x00, \
> + 0x00, 0x00, 0x00, 0x00 } } }
> +
> +#define IPV6_LINK_LOCAL_PREFIX 0xfe80
> +
> +enum {
> +   __ND_OPT_PREFIX_INFO_END= 0,
> +   ND_OPT_SOURCE_LL_ADDR   = 1,
> +   ND_OPT_TARGET_LL_ADDR   = 2,
> +   ND_OPT_PREFIX_INFO  = 3,
> +   ND_OPT_REDIRECT_HDR = 4,
> +   ND_OPT_MTU  = 5,
> +   __ND_OPT_MAX
> +};
> +
> +/* ICMPv6 */
> +#define IPPROTO_ICMPV6 58
> +/* hop limit for neighbour discovery packets */
> +#define IPV6_NDISC_HOPLIMIT 255
> +#define NDISC_TIMEOUT  5000UL
> +#define NDISC_TIMEOUT_COUNT 3
> +
> +struct icmp6hdr {
> +   __u8icmp6_type;
> +#define IPV6_ICMP_ECHO_REQUEST 128
> +#define IPV6_ICMP_ECHO_REPLY   129
> +#define IPV6_NDISC_ROUTER_SOLICITATION 133
> +#define IPV6_NDISC_ROUTER_ADVERTISEMENT134
> +#define IPV6_NDISC_NEIGHBOUR_SOLICITATION  135
> +#define IPV6_NDISC_NEIGHBOUR_ADVERTISEMENT 136
> +#define IPV6_NDISC_REDIRECT137
> +   __u8icmp6_code;
> +   __be16  icmp6_cksum;
> +
> +   union {
> +   __be32  un_data32[1];
> +   __be16  un_data16[2];
> +   __u8un_data8[4];
> +
> +   struct icmpv6_echo {
> +   __be16  identifier;
> +   __be16  sequence;
> +   } u_echo;
> +
> +   struct icmpv6_nd_advt {
> +#if defined(__LITTLE_ENDIAN_BITFIELD)
> +   __be32  reserved:5,
> +   override:1,
> +   solicited:1,
> +   router:1,
> +

Re: [U-Boot] [PATCH v6] arm: atmel: Add SAMA5D2 Xplained board

[Yang, Wenyou]

Hi Andreas,

> -Original Message-
> From: Andreas Bießmann [mailto:andreas.de...@googlemail.com]
> Sent: 2015年11月24日 0:29
> To: Yang, Wenyou; U-Boot Mailing List
> Cc: Bo Shen
> Subject: Re: [U-Boot] [PATCH v6] arm: atmel: Add SAMA5D2 Xplained board
> 
> Hi Wenyou,
> 
> On 30.10.15 02:55, Wenyou Yang wrote:
> > The board supports following features:
> >  - Boot media support: SD card/e.MMC/SPI flash,
> >  - Support LCD display (optional, disabled by default),
> >  - Support ethernet,
> >  - Support USB mass storage.
> >
> > Signed-off-by: Wenyou Yang 
> 
> I'll fix a few checkpatch warnings while applying

Thank you very much for your review and your help, 

> 
> Andreas
> 
> > ---
> > The patch is based on the following patches sent in mailing list.
> > [PATCH] gpio: atmel: Add the PIO4 driver support
> > [PATCH] arm: at91: Change the Chip ID registers' addresses
> > [PATCH v4] mmc: atmel: Add atmel sdhci support
> > [PATCH v3] arm: at91: clock: Add the generated clock support
> >
> > Changes in v6:
> >  1./ change function invocation due to its declaration change,
> > at91_enable_periph_generated_clk().
> >
> > Changes in v5:
> >  1./ remove wrong pin config for USB hw init.
> >
> > Changes in v4:
> >  1./ remove __weak attribute for has_lcdc() added in v3.
> >  2./ remove unused goto err_exit.
> >
> > Changes in v3:
> >  1./ change defines-->definitions for more clearly in asm/arch/sama5d2.h.
> >  2./ remove unused cpu_is_sama5d2x() macros.
> >  3./ fix spelling error "adress".
> >  4./ add __weak attribute for has_lcdc().
> >  5./ remove SPL configs.
> >
> > Changes in v2:
> >  1./ re-order SAMA5D2 statements alphabetically.
> >  2./ remove redundant "Unknown CPU type".
> >  3./ rework sama5d2's macros.
> >  4./ remove some #ifdef before functions.
> >  5./ move CONFIG_CMD_SF to Kconfig.
> >  6./ remove NAND macros from config file.
> >  7./ CONFIG_BOOTCOMMAND for sf uses defines in at91-sama5_common.h.
> >
> >  arch/arm/mach-at91/Kconfig   |5 +
> >  arch/arm/mach-at91/armv7/Makefile|1 +
> >  arch/arm/mach-at91/armv7/sama5d2_devices.c   |   59 +
> >  arch/arm/mach-at91/include/mach/at91_pmc.h   |9 +-
> >  arch/arm/mach-at91/include/mach/atmel_usba_udc.h |3 +-
> >  arch/arm/mach-at91/include/mach/hardware.h   |2 +
> >  arch/arm/mach-at91/include/mach/sama5d2.h|  203 
> >  board/atmel/sama5d2_xplained/Kconfig |   15 ++
> >  board/atmel/sama5d2_xplained/MAINTAINERS |7 +
> >  board/atmel/sama5d2_xplained/Makefile|8 +
> >  board/atmel/sama5d2_xplained/sama5d2_xplained.c  |  284
> ++
> >  configs/sama5d2_xplained_mmc_defconfig   |   11 +
> >  configs/sama5d2_xplained_spiflash_defconfig  |   11 +
> >  include/configs/sama5d2_xplained.h   |  122 ++
> >  14 files changed, 734 insertions(+), 6 deletions(-)  create mode
> > 100644 arch/arm/mach-at91/armv7/sama5d2_devices.c
> >  create mode 100644 arch/arm/mach-at91/include/mach/sama5d2.h
> >  create mode 100644 board/atmel/sama5d2_xplained/Kconfig
> >  create mode 100644 board/atmel/sama5d2_xplained/MAINTAINERS
> >  create mode 100644 board/atmel/sama5d2_xplained/Makefile
> >  create mode 100644 board/atmel/sama5d2_xplained/sama5d2_xplained.c
> >  create mode 100644 configs/sama5d2_xplained_mmc_defconfig
> >  create mode 100644 configs/sama5d2_xplained_spiflash_defconfig
> >  create mode 100644 include/configs/sama5d2_xplained.h


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

[U-Boot] [PATCHv2 2/2] ARM: socfpga: rename the cyclone5 and arria5 base address file

[dinguyen]

From: Dinh Nguyen 

When adding support for the Arria10 platform, we're going to name the file
base_addr_a10.h, so to be systematic about it, rename the socfpga_base_addr.h
to be base_addr_ac5.h for the Arria5 and Cyclone5 platform.

Suggested-by: Marek Vasut 
Signed-off-by: Dinh Nguyen 
---
 .../mach-socfpga/include/mach/{socfpga_base_addrs.h => base_addr_ac5.h} | 0
 include/configs/socfpga_arria5_socdk.h  | 2 +-
 include/configs/socfpga_cyclone5_socdk.h| 2 +-
 include/configs/socfpga_de0_nano_soc.h  | 2 +-
 include/configs/socfpga_mcvevk.h| 2 +-
 include/configs/socfpga_sockit.h| 2 +-
 6 files changed, 5 insertions(+), 5 deletions(-)
 rename arch/arm/mach-socfpga/include/mach/{socfpga_base_addrs.h => 
base_addr_ac5.h} (100%)

diff --git a/arch/arm/mach-socfpga/include/mach/socfpga_base_addrs.h 
b/arch/arm/mach-socfpga/include/mach/base_addr_ac5.h
similarity index 100%
rename from arch/arm/mach-socfpga/include/mach/socfpga_base_addrs.h
rename to arch/arm/mach-socfpga/include/mach/base_addr_ac5.h
diff --git a/include/configs/socfpga_arria5_socdk.h 
b/include/configs/socfpga_arria5_socdk.h
index 8364c66..91ecbf7 100644
--- a/include/configs/socfpga_arria5_socdk.h
+++ b/include/configs/socfpga_arria5_socdk.h
@@ -6,7 +6,7 @@
 #ifndef __CONFIG_SOCFPGA_ARRIA5_H__
 #define __CONFIG_SOCFPGA_ARRIA5_H__
 
-#include 
+#include 
 
 /* U-Boot Commands */
 #define CONFIG_SYS_NO_FLASH
diff --git a/include/configs/socfpga_cyclone5_socdk.h 
b/include/configs/socfpga_cyclone5_socdk.h
index 86b53e2..b5cf393 100644
--- a/include/configs/socfpga_cyclone5_socdk.h
+++ b/include/configs/socfpga_cyclone5_socdk.h
@@ -6,7 +6,7 @@
 #ifndef __CONFIG_SOCFPGA_CYCLONE5_H__
 #define __CONFIG_SOCFPGA_CYCLONE5_H__
 
-#include 
+#include 
 
 /* U-Boot Commands */
 #define CONFIG_SYS_NO_FLASH
diff --git a/include/configs/socfpga_de0_nano_soc.h 
b/include/configs/socfpga_de0_nano_soc.h
index 3ae9b3e..b371a9b 100644
--- a/include/configs/socfpga_de0_nano_soc.h
+++ b/include/configs/socfpga_de0_nano_soc.h
@@ -6,7 +6,7 @@
 #ifndef __CONFIG_TERASIC_DE0_H__
 #define __CONFIG_TERASIC_DE0_H__
 
-#include 
+#include 
 
 /* U-Boot Commands */
 #define CONFIG_SYS_NO_FLASH
diff --git a/include/configs/socfpga_mcvevk.h b/include/configs/socfpga_mcvevk.h
index 4b270ce..d051eec 100644
--- a/include/configs/socfpga_mcvevk.h
+++ b/include/configs/socfpga_mcvevk.h
@@ -6,7 +6,7 @@
 #ifndef __CONFIG_DENX_MCVEVK_H__
 #define __CONFIG_DENX_MCVEVK_H__
 
-#include 
+#include 
 
 /* U-Boot Commands */
 #define CONFIG_SYS_NO_FLASH
diff --git a/include/configs/socfpga_sockit.h b/include/configs/socfpga_sockit.h
index 742c5ae..d26f53d 100644
--- a/include/configs/socfpga_sockit.h
+++ b/include/configs/socfpga_sockit.h
@@ -6,7 +6,7 @@
 #ifndef __CONFIG_TERASIC_SOCKIT_H__
 #define __CONFIG_TERASIC_SOCKIT_H__
 
-#include 
+#include 
 
 /* U-Boot Commands */
 #define CONFIG_SYS_NO_FLASH
-- 
2.6.2

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

Re: [U-Boot] [PATCH v2 3/3] net: zynq: Disable secondary queues

[Joe Hershberger]

Hi Michal,

On Thu, Nov 12, 2015 at 7:43 AM, Michal Simek  wrote:
> From: "Edgar E. Iglesias" 
>
> Zynq has no priority queues.
> ZynqMP has one priority queue and this change is required
> to get ethernet working.
> This patch was not needed on ep108 for uknown reason even
> it should be used.
> Tested on Zynq and ZynqMP.
>
> Signed-off-by: Edgar E. Iglesias 
> Signed-off-by: Michal Simek 

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

Re: [U-Boot] [PATCH 1/6] test/py: require .config to exist

[Tom Rini]

On Tue, Nov 17, 2015 at 08:19:59PM -0700, Stephen Warren wrote:

> From: Stephen Warren 
> 
> If .config doesn't exist, the test will currently throw an exception
> because the shell prompt value can't be looked up. It's not obvious how
> to resolve this. Fix the code to require that the .config file exist in
> the build directory rather than ignoring the issue when it's missing.
> Make the error message reference the fact that U-Boot doesn't appear to
> be built, and mention how to solve that.
> 
> Signed-off-by: Stephen Warren 

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/6] test/py: parse include/autoconf.mk for config options

[Tom Rini]

On Tue, Nov 17, 2015 at 08:20:00PM -0700, Stephen Warren wrote:

> From: Stephen Warren 
> 
> Many config options aren't yet converted to Kconfig. Update the test
> scripts to parse include/autoconf.mk to pick up the non-converted
> options. This will allow tests to be marked as depending on those
> options.
> 
> Signed-off-by: Stephen Warren 

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 4/6] test/py: print implicit shell prompt later

[Tom Rini]

On Tue, Nov 17, 2015 at 08:20:02PM -0700, Stephen Warren wrote:

> Whenever a test is about to start, the test scripts log an "implicit"
> version of the shell prompt. This ensures that each test's log section
> includes the prompt, which makes it easier to read.
> 
> However, pytest apparently doesn't set up stdout capturing for skipped
> tests. If we print this implicit prompt before we've determined whether
> the test is skipped, then it may/will appear as stdout in ther terminal
> where the test script was run, which looks messy.
> 
> To avoid this, only print this prompt after we've evaluated whether the
> test is to be skipped. Note that internally, pytest.skip() raises an
> exception, which causes the moved code not to execute, now that it's
> later in the execution path.
> 
> Signed-off-by: Stephen Warren 

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 v2 04/11] lib: net_utils: add string_to_ip6

[Joe Hershberger]

On Mon, Nov 9, 2015 at 1:38 AM, Chris Packham  wrote:
> string_to_ip6 parses an IPv6 address from a string. Parsing v6 addresses
> is a bit more complicated than parsing v4 because there are a number of
> different formats that can be used.
>
> Signed-off-by: Chris Packham 

This looks fine for now.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH v2 01/11] Initial net6.h

[Joe Hershberger]

Hi Chris,

On Mon, Nov 9, 2015 at 1:38 AM, Chris Packham  wrote:
> The initial net6.h just has the definition of an IPv6 address and IPv6
> header. Subsequent changes will build on this.
>
> Signed-off-by: Chris Packham 
>
> ---
>
> Changes in v2: None

Still looks fine to me.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH v2 09/11] net: TFTP over IPv6

[Joe Hershberger]

On Mon, Nov 9, 2015 at 1:38 AM, Chris Packham  wrote:
> Add support for UDP/TFTP over IPv6. To support specifying an server IPv6
> address in the command square brackets must be used to separate the
> address from the filename. e.g
>   tftpboot6 [2001:db8::1]:zImage
>
> Signed-off-by: Chris Packham 
> ---
>
> Changes in v2: None

Aren't the square brackets new?

>  common/Kconfig   |  9 
>  common/cmd_net.c | 13 
>  include/net.h|  2 +-
>  include/net6.h   |  4 
>  net/net.c|  3 +++
>  net/net6.c   | 64 
> 
>  net/tftp.c   | 58 ++
>  7 files changed, 152 insertions(+), 1 deletion(-)
>
> diff --git a/common/Kconfig b/common/Kconfig
> index b1effc6..5914328 100644
> --- a/common/Kconfig
> +++ b/common/Kconfig
> @@ -400,6 +400,15 @@ config CMD_NET
>   bootp - boot image via network using BOOTP/TFTP protocol
>   tftpboot - boot image via network using TFTP protocol
>
> +config CMD_NET6
> +   bool "ipv6 commands"
> +   select NET
> +   select NET6
> +   default n
> +   help
> + IPv6 network commands
> + tftpboot6 - boot image via network using TFTP protocol
> +

Wouldn't ping6 be considered a command? Why is this not added in an
earlier patch to allow for ping6?

It seems like ping6 would depend on CMD_NET6. Also, it seems like
tftp6 should be behind its own CMD_TFTP6 token, since it surely must
be optional. Maybe we want it to be enabled by default, but it should
be possible to disable.

I think you'll need to update the documentation patch as a result.

>  config CMD_TFTPPUT
> bool "tftp put"
> help
> diff --git a/common/cmd_net.c b/common/cmd_net.c
> index 271f91d..47b56ee 100644
> --- a/common/cmd_net.c
> +++ b/common/cmd_net.c
> @@ -42,6 +42,19 @@ U_BOOT_CMD(
> "[loadAddress] [[hostIPaddr:]bootfilename]"
>  );
>
> +#ifdef CONFIG_CMD_NET6
> +int do_tftpb6(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
> +{
> +   return netboot_common(TFTP6, cmdtp, argc, argv);
> +}
> +
> +U_BOOT_CMD(
> +   tftpboot6,  3,  1,  do_tftpb6,
> +   "boot image via network using TFTP protocol",
> +   "[loadAddress] [[hostIP6Addr]:][bootfilename]"
> +);
> +#endif
> +
>  #ifdef CONFIG_CMD_TFTPPUT
>  int do_tftpput(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
>  {
> diff --git a/include/net.h b/include/net.h
> index 6a9832c..69e6a17 100644
> --- a/include/net.h
> +++ b/include/net.h
> @@ -525,7 +525,7 @@ extern int  net_restart_wrap;   /* Tried all 
> network devices */
>
>  enum proto_t {
> BOOTP, RARP, ARP, TFTPGET, DHCP, PING, PING6, DNS, NFS, CDP, NETCONS,
> -   SNTP, TFTPSRV, TFTPPUT, LINKLOCAL
> +   SNTP, TFTPSRV, TFTPPUT, TFTP6, LINKLOCAL
>  };
>
>  extern charnet_boot_file_name[1024];/* Boot File name */
> diff --git a/include/net6.h b/include/net6.h
> index ff97c39..7ae1777 100644
> --- a/include/net6.h
> +++ b/include/net6.h
> @@ -246,6 +246,10 @@ void ping6_start(void);
>  void ping6_receive(struct ethernet_hdr *et, struct ip6_hdr *ip6,
>   int len);
>
> +/* Transmit UDP packet using IPv6, performing neighbour discovery if needed 
> */
> +int net_send_udp_packet6(uchar *ether, struct in6_addr *dest,
> +   int dport, int sport, int len);
> +
>  /* handler for incoming IPv6 echo packet */
>  void net_ip6_handler(struct ethernet_hdr *et, struct ip6_hdr *ip6,
> int len);
> diff --git a/net/net.c b/net/net.c
> index ca24673..2b0d17e 100644
> --- a/net/net.c
> +++ b/net/net.c
> @@ -453,6 +453,9 @@ restart:
>  #ifdef CONFIG_CMD_TFTPPUT
> case TFTPPUT:
>  #endif
> +#ifdef CONFIG_CMD_NET6
> +   case TFTP6:
> +#endif
> /* always use ARP to get server ethernet address */
> tftp_start(protocol);
> break;
> diff --git a/net/net6.c b/net/net6.c
> index 8f0c721..5b8a003 100644
> --- a/net/net6.c
> +++ b/net/net6.c
> @@ -342,6 +342,50 @@ ip6_add_hdr(uchar *xip, struct in6_addr *src, struct 
> in6_addr *dest,
> return sizeof(struct ip6_hdr);
>  }
>
> +int
> +net_send_udp_packet6(uchar *ether, struct in6_addr *dest, int dport, int 
> sport, int len)
> +{
> +   uchar *pkt;
> +   struct udp_hdr *udp;
> +
> +   udp = (struct udp_hdr *)((uchar *)net_tx_packet + net_eth_hdr_size() 
> + IP6_HDR_SIZE);
> +
> +   udp->udp_dst = htons(dport);
> +   udp->udp_src = htons(sport);
> +   udp->udp_len = htons(len + UDP_HDR_SIZE);
> +   /* checksum */
> +   udp->udp_xsum = 0;
> +   udp->udp_xsum = csum_ipv6_magic(_ip6, dest, len + UDP_HDR_SIZE,
> +   IPPROTO_UDP, csum_partial((__u8 *)udp, len + UDP_HDR_SIZE, 
> 0));
> +
> +   /* if MAC address was not discovered yet, 

Re: [U-Boot] [RFC PATCH v2 08/11] net: Add ping6 command and implementation

[Joe Hershberger]

On Mon, Nov 9, 2015 at 1:38 AM, Chris Packham  wrote:
> Signed-off-by: Chris Packham 
>
> ---
>
> Changes in v2:
> - split ping6 support into it's own patch
>
>  common/Kconfig   |   6 +++
>  common/cmd_net.c |  28 ++
>  include/net.h|   4 +-
>  net/net6.c   |   7 
>  net/ping6.c  | 111 
> +++
>  5 files changed, 154 insertions(+), 2 deletions(-)
>  create mode 100644 net/ping6.c
>
> diff --git a/common/Kconfig b/common/Kconfig
> index 0388a6c..b1effc6 100644
> --- a/common/Kconfig
> +++ b/common/Kconfig
> @@ -431,6 +431,12 @@ config CMD_PING
> help
>   Send ICMP ECHO_REQUEST to network host
>
> +config CMD_PING6
> +   bool "ping6"
> +   depends on CMD_NET6
> +   help
> + Send ICMPv6 ECHO_REQUEST to network host
> +
>  config CMD_CDP
> bool "cdp"
> help
> diff --git a/common/cmd_net.c b/common/cmd_net.c
> index b2f3c7b..271f91d 100644
> --- a/common/cmd_net.c
> +++ b/common/cmd_net.c
> @@ -11,6 +11,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  static int netboot_common(enum proto_t, cmd_tbl_t *, int, char * const []);
>
> @@ -284,6 +285,33 @@ U_BOOT_CMD(
>  );
>  #endif
>
> +#ifdef CONFIG_CMD_PING6
> +int do_ping6(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
> +{
> +   if (argc < 2)
> +   return -1;
> +
> +   if (string_to_ip6(argv[1], _ping_ip6) != 0)
> +   return CMD_RET_USAGE;
> +
> +   if (net_loop(PING6) < 0) {
> +   printf("ping6 failed; host %pI6c is not alive\n",
> +  _ping_ip6);
> +   return 1;
> +   }
> +
> +   printf("host %pI6c is alive\n", _ping_ip6);
> +
> +   return 0;
> +}
> +
> +U_BOOT_CMD(
> +   ping6,  2,  1,  do_ping6,
> +   "send ICMPv6 ECHO_REQUEST to network host",
> +   "pingAddress"
> +);
> +#endif /* CONFIG_CMD_PING6 */
> +
>  #if defined(CONFIG_CMD_CDP)
>
>  static void cdp_update_env(void)
> diff --git a/include/net.h b/include/net.h
> index 8b7c878..6a9832c 100644
> --- a/include/net.h
> +++ b/include/net.h
> @@ -524,8 +524,8 @@ extern ushort   net_native_vlan;/* 
> Our Native VLAN */
>  extern int net_restart_wrap;   /* Tried all network devices 
> */
>
>  enum proto_t {
> -   BOOTP, RARP, ARP, TFTPGET, DHCP, PING, DNS, NFS, CDP, NETCONS, SNTP,
> -   TFTPSRV, TFTPPUT, LINKLOCAL
> +   BOOTP, RARP, ARP, TFTPGET, DHCP, PING, PING6, DNS, NFS, CDP, NETCONS,
> +   SNTP, TFTPSRV, TFTPPUT, LINKLOCAL
>  };
>
>  extern charnet_boot_file_name[1024];/* Boot File name */
> diff --git a/net/net6.c b/net/net6.c
> index 955a089..8f0c721 100644
> --- a/net/net6.c
> +++ b/net/net6.c
> @@ -370,6 +370,13 @@ void net_ip6_handler(struct ethernet_hdr *et, struct 
> ip6_hdr *ip6, int len)
> return;
>
> switch (icmp->icmp6_type) {
> +#ifdef CONFIG_CMD_PING6
> +   case IPV6_ICMP_ECHO_REQUEST:
> +   case IPV6_ICMP_ECHO_REPLY:
> +   ping6_receive(et, ip6, len);
> +   break;
> +#endif /* CONFIG_CMD_PING6 */
> +
> case IPV6_NDISC_NEIGHBOUR_SOLICITATION:
> case IPV6_NDISC_NEIGHBOUR_ADVERTISEMENT:
> ndisc_receive(et, ip6, len);
> diff --git a/net/ping6.c b/net/ping6.c
> new file mode 100644
> index 000..34796c6
> --- /dev/null
> +++ b/net/ping6.c
> @@ -0,0 +1,111 @@
> +/*
> + * net/ping6.c
> + *
> + * (C) Copyright 2013 Allied Telesis Labs NZ
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +#define DEBUG
> +#include 
> +#include 
> +#include 
> +#include "ndisc.h"
> +
> +static ushort seq_no;
> +
> +/* the ipv6 address to ping */
> +struct in6_addr net_ping_ip6;
> +
> +int

+ static int

> +ip6_make_ping(uchar *eth_dst_addr, struct in6_addr *neigh_addr, uchar *pkt)
> +{
> +   struct echo_msg *msg;
> +   __u16 len;
> +   uchar *pkt_old = pkt;
> +
> +   len = sizeof(struct echo_msg);
> +
> +   pkt += net_set_ether(pkt, eth_dst_addr, PROT_IP6);
> +   pkt += ip6_add_hdr(pkt, _ip6, neigh_addr, IPPROTO_ICMPV6,
> +  IPV6_NDISC_HOPLIMIT, len);
> +
> +   /* ICMPv6 - Echo */
> +   msg = (struct echo_msg *)pkt;
> +   msg->icmph.icmp6_type = IPV6_ICMP_ECHO_REQUEST;
> +   msg->icmph.icmp6_code = 0;
> +   msg->icmph.icmp6_cksum = 0;
> +   msg->icmph.icmp6_identifier = 0;
> +   msg->icmph.icmp6_sequence = htons(seq_no++);
> +   msg->id = msg->icmph.icmp6_identifier;  /* these seem redundant */
> +   msg->sequence = msg->icmph.icmp6_sequence;
> +
> +   /* checksum */
> +   msg->icmph.icmp6_cksum = csum_ipv6_magic(_ip6, neigh_addr, len,
> +IPPROTO_ICMPV6,
> +csum_partial((__u8 *)msg, 
> len, 0));

Re: [U-Boot] [RFC PATCH v2 05/11] net: add definition of udp_hdr

[Joe Hershberger]

On Mon, Nov 9, 2015 at 1:38 AM, Chris Packham  wrote:
> UDP is the same over IPv4 as it is over other protocols (i.e. IPv6) add
> a definition of just the UDP header independent of the IPv4 header that
> it may or may not be combined with.
>
> Signed-off-by: Chris Packham 
> ---
> Ideally struct ip_udp_hdr would be defined as
>
>   struct ip_udp_hdr {
>   struct ip_hdr  ip;
>   struct udp_hdr udp;
>   };
>
> Implementing this touches more code that I really want to at this
> point. Some of the code that currently uses struct ip_udp_hdr could
> probably just use struct ip_hdr instead but some care would need to be
> taken to much such a change.

Sounds reasonable.

> Changes in v2: None
>
>  include/net.h | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/include/net.h b/include/net.h
> index ebed29a..e8bd2b7 100644
> --- a/include/net.h
> +++ b/include/net.h
> @@ -348,6 +348,18 @@ struct ip_hdr {
>  #define IP_HDR_SIZE(sizeof(struct ip_hdr))
>
>  /*
> + * UDP header.
> + */
> +struct udp_hdr {
> +   __be16  udp_src;/* UDP source port  */
> +   __be16  udp_dst;/* UDP destination port */
> +   __be16  udp_len;/* Length of UDP packet */
> +   __be16  udp_xsum;   /* Checksum */
> +};
> +
> +#define UDP_HDR_SIZE   (sizeof(struct udp_hdr))
> +
> +/*
>   * Internet Protocol (IP) + UDP header.
>   */
>  struct ip_udp_hdr {
> @@ -368,7 +380,6 @@ struct ip_udp_hdr {
>  };
>
>  #define IP_UDP_HDR_SIZE(sizeof(struct ip_udp_hdr))
> -#define UDP_HDR_SIZE   (IP_UDP_HDR_SIZE - IP_HDR_SIZE)
>
>  /*
>   * Address Resolution Protocol (ARP) header.
> --
> 2.5.3
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2] arm: novena: Switch novena to config_distro_bootcmd

[Vagrant Cascadian]

On 2015-11-10, Marek Vasut wrote:
> Switch Novena to distro bootcmd, so it can be used with debian easily.
...
> diff --git a/include/configs/novena.h b/include/configs/novena.h
> index 718989f..3bb406d 100644
> --- a/include/configs/novena.h
> +++ b/include/configs/novena.h
> @@ -199,6 +201,10 @@
>   "rootdev=/dev/mmcblk0p2\0"  \
>   "netdev=eth0\0" \
>   "kernel_addr_r="__stringify(CONFIG_LOADADDR)"\0"\
> + "pxefile_addr_r="__stringify(CONFIG_LOADADDR)"\0"   \
> + "scriptaddr="__stringify(CONFIG_LOADADDR)"\0"   \
> + "ramdisk_addr_r=0x2800\0"   \
> + "fdt_addr_r=0x1000\0"   \
>   "addcons="  \
>   "setenv bootargs ${bootargs} "  \
>   "console=${consdev},${baudrate}\0"  \

Apparently, 0x1000 doesn't work for fdt_addr_r, changing it to:

"fdt_addr_r=0x1120"

Worked for me.


live well,
  vagrant


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

Re: [U-Boot] [PATCH 18/25] dm: net: Convert rtl8169 to use DM PCI API

[Joe Hershberger]

Hi Simon,

On Mon, Nov 16, 2015 at 9:53 PM, Simon Glass  wrote:
> Update this driver to use the proper driver-model PCI API functions.
>
> Signed-off-by: Simon Glass 
> ---
>
>  drivers/net/rtl8169.c | 88 
> ---
>  1 file changed, 70 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/net/rtl8169.c b/drivers/net/rtl8169.c
> index 19422c4..0a93668 100644
> --- a/drivers/net/rtl8169.c
> +++ b/drivers/net/rtl8169.c
> @@ -513,8 +513,13 @@ static void rtl_flush_buffer(void *buf, size_t size)
>  /**
>  RECV - Receive a frame
>  ***/
> -static int rtl_recv_common(pci_dev_t bdf, unsigned long dev_iobase,
> +#ifdef CONFIG_DM_ETH
> +static int rtl_recv_common(struct udevice *dev, unsigned long dev_iobase,
> +  uchar **packetp)
> +#else
> +static int rtl_recv_common(pci_dev_t dev, unsigned long dev_iobase,
>uchar **packetp)
> +#endif
>  {
> /* return true if there's an ethernet packet ready to read */
> /* nic->packet should contain data on return */
> @@ -545,9 +550,16 @@ static int rtl_recv_common(pci_dev_t bdf, unsigned long 
> dev_iobase,
> else
> tpc->RxDescArray[cur_rx].status =
> cpu_to_le32(OWNbit + RX_BUF_SIZE);
> +#ifdef CONFIG_DM_ETH
> tpc->RxDescArray[cur_rx].buf_addr = cpu_to_le32(
> -   pci_mem_to_phys(bdf, (pci_addr_t)(unsigned 
> long)
> +   dm_pci_mem_to_phys(dev,
> +   (pci_addr_t)(unsigned long)
> +   tpc->RxBufferRing[cur_rx]));
> +#else
> +   tpc->RxDescArray[cur_rx].buf_addr = cpu_to_le32(
> +   pci_mem_to_phys(dev, (pci_addr_t)(unsigned 
> long)
> tpc->RxBufferRing[cur_rx]));
> +#endif
> rtl_flush_rx_desc(>RxDescArray[cur_rx]);
>  #ifdef CONFIG_DM_ETH
> *packetp = rxdata;
> @@ -576,7 +588,7 @@ int rtl8169_eth_recv(struct udevice *dev, int flags, 
> uchar **packetp)
>  {
> struct rtl8169_private *priv = dev_get_priv(dev);
>
> -   return rtl_recv_common(pci_get_bdf(dev), priv->iobase, packetp);
> +   return rtl_recv_common(dev, priv->iobase, packetp);
>  }
>  #else
>  static int rtl_recv(struct eth_device *dev)
> @@ -590,8 +602,13 @@ static int rtl_recv(struct eth_device *dev)
>  /**
>  SEND - Transmit a frame
>  ***/
> -static int rtl_send_common(pci_dev_t bdf, unsigned long dev_iobase,
> +#ifdef CONFIG_DM_ETH
> +static int rtl_send_common(struct udevice *dev, unsigned long dev_iobase,
>void *packet, int length)
> +#else
> +static int rtl_send_common(pci_dev_t dev, unsigned long dev_iobase,
> +  void *packet, int length)
> +#endif
>  {
> /* send the packet to destination */
>
> @@ -618,8 +635,13 @@ static int rtl_send_common(pci_dev_t bdf, unsigned long 
> dev_iobase,
> ptxb[len++] = '\0';
>
> tpc->TxDescArray[entry].buf_Haddr = 0;
> +#ifdef CONFIG_DM_ETH
> +   tpc->TxDescArray[entry].buf_addr = cpu_to_le32(
> +   dm_pci_mem_to_phys(dev, (pci_addr_t)(unsigned long)ptxb));
> +#else
> tpc->TxDescArray[entry].buf_addr = cpu_to_le32(
> -   pci_mem_to_phys(bdf, (pci_addr_t)(unsigned long)ptxb));
> +   pci_mem_to_phys(dev, (pci_addr_t)(unsigned long)ptxb));
> +#endif
> if (entry != (NUM_TX_DESC - 1)) {
> tpc->TxDescArray[entry].status =
> cpu_to_le32((OWNbit | FSbit | LSbit) |
> @@ -661,7 +683,7 @@ int rtl8169_eth_send(struct udevice *dev, void *packet, 
> int length)
>  {
> struct rtl8169_private *priv = dev_get_priv(dev);
>
> -   return rtl_send_common(pci_get_bdf(dev), priv->iobase, packet, 
> length);
> +   return rtl_send_common(dev, priv->iobase, packet, length);
>  }
>
>  #else
> @@ -695,7 +717,11 @@ static void rtl8169_set_rx_mode(void)
> RTL_W32(MAR0 + 4, mc_filter[1]);
>  }
>
> -static void rtl8169_hw_start(pci_dev_t bdf)
> +#ifdef CONFIG_DM_ETH
> +static void rtl8169_hw_start(struct udevice *dev)
> +#else
> +static void rtl8169_hw_start(pci_dev_t dev)
> +#endif
>  {
> u32 i;
>
> @@ -740,11 +766,21 @@ static void rtl8169_hw_start(pci_dev_t bdf)
>
> tpc->cur_rx = 0;
>
> -   RTL_W32(TxDescStartAddrLow, pci_mem_to_phys(bdf,
> +#ifdef CONFIG_DM_ETH
> +   RTL_W32(TxDescStartAddrLow, dm_pci_mem_to_phys(dev,
> +   

Re: [U-Boot] [PATCH 1/2] checkpatch: ignore request to use ether_addr_copy()

[Joe Hershberger]

On Fri, Nov 13, 2015 at 10:03 AM, Stephen Warren  wrote:
> From: Stephen Warren 
>
> The Linux kernel, from which checkpatch originates, contains function
> ether_addr_copy() to copy Ethernet MAC addresses, and checkpatch warns
> that it should be used in preference to memcpy() where appropriate.
> U-Boot doesn't contain ether_addr_copy(), so tell checkpatch not to issue
> this warning.
>
> Signed-off-by: Stephen Warren 

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

Re: [U-Boot] [PATCH] include: net: Simplify the usage of __always_inline

[Joe Hershberger]

Hi Fabio,

On Sun, Nov 8, 2015 at 6:25 PM, Fabio Estevam  wrote:
> From: Fabio Estevam 
>
> Since commit de4d2e9e7ce0f9 (" bitops: Add fls_long and __ffs64")
>  is included in include/linux/bitops.h,
> which allows us to marking a function as 'always_inline' in a simpler
> format.
>
> Signed-off-by: Fabio Estevam 

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

Re: [U-Boot] [RFC PATCH v2 06/11] net: IPv6 skeleton and environment variables

[Joe Hershberger]

Hi Chris,

On Mon, Nov 9, 2015 at 1:38 AM, Chris Packham  wrote:
> Create net6.c and add CONFIG_NET6 to Kconfig/Makefile. Also add
> support for the following environment variables:
>  - ip6addr
>  - gateway6
>  - serverip6
>
> Signed-off-by: Chris Packham 
> ---
>
> Changes in v2:
> - Split environment variables from main implementation
> - remove "prefixlength6" environment variable. The prefix length is now
>   set when specifying the address i.e. setenv ip6addr 2001:db8::1/64.
>
>  include/env_callback.h |  8 +
>  include/env_flags.h|  9 +
>  net/Kconfig|  5 +++
>  net/Makefile   |  1 +
>  net/net6.c | 89 
> ++
>  5 files changed, 112 insertions(+)
>  create mode 100644 net/net6.c
>
> diff --git a/include/env_callback.h b/include/env_callback.h
> index 90b95b5..97e245b 100644
> --- a/include/env_callback.h
> +++ b/include/env_callback.h
> @@ -60,6 +60,13 @@
>  #define NET_CALLBACKS
>  #endif
>
> +#ifdef CONFIG_NET6
> +#define NET6_CALLBACKS \
> +   "ip6addr:ip6addr," \
> +   "serverip6:serverip6,"

Any reason why gateway6 is not in this list? Seems like an oversight
since you define a handler for it below.

> +#else
> +#define NET6_CALLBACKS
> +#endif
>  /*
>   * This list of callback bindings is static, but may be overridden by 
> defining
>   * a new association in the ".callbacks" environment variable.
> @@ -68,6 +75,7 @@
> ENV_DOT_ESCAPE ENV_FLAGS_VAR ":flags," \
> "baudrate:baudrate," \
> NET_CALLBACKS \
> +   NET6_CALLBACKS \
> "loadaddr:loadaddr," \
> SILENT_CALLBACK \
> SPLASHIMAGE_CALLBACK \
> diff --git a/include/env_flags.h b/include/env_flags.h
> index 8823fb9..bf93f15 100644
> --- a/include/env_flags.h
> +++ b/include/env_flags.h
> @@ -65,6 +65,14 @@ enum env_flags_varaccess {
>  #define NET_FLAGS
>  #endif
>
> +#ifdef CONFIG_NET6
> +#define NET6_FLAGS \
> +   "ip6addr:s," \
> +   "serverip6:s,"
> +#else
> +#define NET6_FLAGS
> +#endif
> +
>  #ifndef CONFIG_ENV_OVERWRITE
>  #define SERIAL_FLAGS "serial#:so,"
>  #else
> @@ -74,6 +82,7 @@ enum env_flags_varaccess {
>  #define ENV_FLAGS_LIST_STATIC \
> ETHADDR_FLAGS \
> NET_FLAGS \
> +   NET6_FLAGS \
> SERIAL_FLAGS \
> CONFIG_ENV_FLAGS_LIST_STATIC
>
> diff --git a/net/Kconfig b/net/Kconfig
> index a44a783..bacd914 100644
> --- a/net/Kconfig
> +++ b/net/Kconfig
> @@ -32,4 +32,9 @@ config NET_TFTP_VARS
>   If unset, timeout and maximum are hard-defined as 1 second
>   and 10 timouts per TFTP transfer.
>
> +config NET6
> +   bool "IPv6 support"
> +   help
> + Support for IPv6
> +
>  endif   # if NET
> diff --git a/net/Makefile b/net/Makefile
> index e9cc8ad..6da8019 100644
> --- a/net/Makefile
> +++ b/net/Makefile
> @@ -20,3 +20,4 @@ obj-$(CONFIG_CMD_PING) += ping.o
>  obj-$(CONFIG_CMD_RARP) += rarp.o
>  obj-$(CONFIG_CMD_SNTP) += sntp.o
>  obj-$(CONFIG_CMD_NET)  += tftp.o
> +obj-$(CONFIG_NET6) += net6.o
> diff --git a/net/net6.c b/net/net6.c
> new file mode 100644
> index 000..f778cef
> --- /dev/null
> +++ b/net/net6.c
> @@ -0,0 +1,89 @@
> +/*
> + * Simple IPv6 network layer implementation.
> + *
> + * Based and/or adapted from the IPv4 network layer in net.[hc]
> + *
> + * (C) Copyright 2013 Allied Telesis Labs NZ
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "ndisc.h"
> +
> +/* Our gateway's IPv6 address */
> +struct in6_addr net_gateway6 = ZERO_IPV6_ADDR;
> +/* Our IPv6 addr (0 = unknown) */
> +struct in6_addr net_ip6 = ZERO_IPV6_ADDR;
> +/* set server IPv6 addr (0 = unknown) */
> +struct in6_addr net_server_ip6 = ZERO_IPV6_ADDR;
> +/* The prefix length of our network */
> +u_int32_t net_prefix_length;
> +
> +static int on_ip6addr(const char *name, const char *value, enum env_op op,
> + int flags)
> +{
> +   char *v, *s, *strcopy;
> +   int i;
> +
> +   if (flags & H_PROGRAMMATIC)
> +   return 0;
> +
> +   if (op == env_op_delete) {
> +   net_prefix_length = 0;
> +   net_copy_ip6(_ip6, _null_addr_ip6);
> +   return 0;
> +   }
> +
> +   strcopy = strdup(value);
> +   if (strcopy == NULL)
> +   return -1;

+   return -ENOMEM;

> +
> +   net_prefix_length = 128;

Does this imply that you are allowed to omit this part of the address
now? I assume you are not allowed to omit it, hence the proposed code
below.

> +   i = 0;
> +   s = strcopy;


> +   while (s) {
> +   v = strsep(, "/");
> +   if (!v)
> +   break;
> +
> +   switch (i++) {
> +   case 0:
> +   string_to_ip6(v, _ip6);
> +   break;
> +   case 1:

Re: [U-Boot] [RFC PATCH v2 02/11] lib: vsprintf: add IPv6 compressed format %pI6c

[Joe Hershberger]

On Mon, Nov 9, 2015 at 1:38 AM, Chris Packham  wrote:
> Add support for "human friendly" IPv6 address representations as
> specified in
> http://tools.ietf.org/html/draft-ietf-6man-text-addr-representation-00
>
> This code has been adapted from Linux kernel with minimal modification.
>
> Signed-off-by: Chris Packham 
> ---
>
> Changes in v2: None

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

Re: [U-Boot] [RFC PATCH v2 11/11] net: e1000 enable multicast reception

[Joe Hershberger]

On Mon, Nov 9, 2015 at 1:38 AM, Chris Packham  wrote:
> IPv6 neighbor discovery uses various multicast addresses to send the
> request and receive the response. For neighbor discovery to work
> properly in U-boot the Ethernet device needs to support joining/leaving
> various L2 multicast groups or it needs to support multicast/promiscuous
> mode. For the sake of simplicity the latter approach has been taken. The
> e1000 hardware has slightly finer grained control in that it is possible
> to enable support for multicast-promiscuous mode separately from unicast
> so the extra traffic received is less.
>
> Signed-off-by: Chris Packham 
>
> ---
> Drivers that support multicast reception have it enabled/disabled with
> CONFIG_MCAST_TFTP. It wouldn't be too hard to create a separate
> CONFIG_MCAST that is selected by enabling CONFIG_MCAST_TFTP or
> CONFIG_NET6.

I agree that a new token CONFIG_MCAST should be created.

> Changes in v2: None
>
>  drivers/net/e1000.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c
> index 2ba03ed..d19a9de 100644
> --- a/drivers/net/e1000.c
> +++ b/drivers/net/e1000.c
> @@ -5090,6 +5090,11 @@ e1000_setup_rctl(struct e1000_hw *hw)
> rctl &= ~(E1000_RCTL_SZ_4096);
> rctl |= E1000_RCTL_SZ_2048;
> rctl &= ~(E1000_RCTL_BSEX | E1000_RCTL_LPE);
> +
> +#ifdef CONFIG_NET6
> +   rctl |= E1000_RCTL_MPE;
> +#endif
> +
> E1000_WRITE_REG(hw, RCTL, rctl);
>  }
>
> --
> 2.5.3
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCHv2 1/2] ARM: socfpga: arria10: add base address map for Arria10

[dinguyen]

From: Dinh Nguyen 

Add the base address map for Arria10.

Signed-off-by: Dinh Nguyen 
Reviewed-by: Marek Vasut 
---
v2: renamed to base_addr_a10.h
---
 arch/arm/mach-socfpga/include/mach/base_addr_a10.h | 45 ++
 1 file changed, 45 insertions(+)
 create mode 100644 arch/arm/mach-socfpga/include/mach/base_addr_a10.h

diff --git a/arch/arm/mach-socfpga/include/mach/base_addr_a10.h 
b/arch/arm/mach-socfpga/include/mach/base_addr_a10.h
new file mode 100644
index 000..a7056d4
--- /dev/null
+++ b/arch/arm/mach-socfpga/include/mach/base_addr_a10.h
@@ -0,0 +1,45 @@
+/*
+ * Copyright (C) 2014 Altera Corporation 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _SOCFPGA_A10_BASE_HARDWARE_H_
+#define _SOCFPGA_A10_BASE_HARDWARE_H_
+
+#define SOCFPGA_EMAC0_ADDRESS  0xff80
+#define SOCFPGA_EMAC1_ADDRESS  0xff802000
+#define SOCFPGA_EMAC2_ADDRESS  0xff804000
+#define SOCFPGA_SDMMC_ADDRESS  0xff808000
+#define SOCFPGA_QSPIREGS_ADDRESS   0xff809000
+#define SOCFPGA_QSPIDATA_ADDRESS   0xffa0
+#define SOCFPGA_UART1_ADDRESS  0xffc02100
+#define SOCFPGA_HMC_MMR_IO48_ADDRESS   0xffcfa000
+#define SOCFPGA_FPGAMGRDATA_ADDRESS0xffcfe400
+#define SOCFPGA_FPGAMGRREGS_ADDRESS0xffd03000
+#define SOCFPGA_L4WD0_ADDRESS  0xffd00200
+#define SOCFPGA_SYSMGR_ADDRESS 0xffd06000
+#define SOCFPGA_PINMUX_SHARED_3V_IO_ADDRESS0xffd07000
+#define SOCFPGA_PINMUX_DEDICATED_IO_ADDRESS0xffd07200
+#define SOCFPGA_PINMUX_DEDICATED_IO_CFG_ADDRESS0xffd07300
+#define SOCFPGA_PINMUX_FPGA_INTERFACE_ADDRESS  0xffd07400
+#define SOCFPGA_DMANONSECURE_ADDRESS   0xffda
+#define SOCFPGA_DMASECURE_ADDRESS  0xffda1000
+#define SOCFPGA_MPUSCU_ADDRESS 0xc000
+#define SOCFPGA_MPUL2_ADDRESS  0xf000
+#define SOCFPGA_I2C0_ADDRESS   0xffc02200
+#define SOCFPGA_I2C1_ADDRESS   0xffc02300
+
+#define SOCFPGA_ECC_OCRAM_ADDRESS  0xff8c3000
+#define SOCFPGA_UART0_ADDRESS  0xffc02000
+#define SOCFPGA_OSC1TIMER0_ADDRESS 0xffd0
+#define SOCFPGA_CLKMGR_ADDRESS 0xffd04000
+#define SOCFPGA_RSTMGR_ADDRESS 0xffd05000
+
+#define SOCFPGA_SDR_ADDRESS0xffcfb000
+#define SOCFPGA_SDR_SCHEDULER_ADDRESS  0xffd12400
+#define SOCFPGA_SDR_FIREWALL_OCRAM_ADDRESS 0xffd13200
+#define SOCFPGA_SDR_FIREWALL_MPU_FPGA_ADDRESS  0xffd13300
+#define SOCFPGA_SDR_FIREWALL_L3_ADDRESS0xffd13400
+
+#endif /* _SOCFPGA_A10_BASE_HARDWARE_H_ */
-- 
2.6.2

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

Re: [U-Boot] [PATCH 5/6] test/py: replace cmd_repeat.sh with Python

[Tom Rini]

On Tue, Nov 17, 2015 at 08:20:03PM -0700, Stephen Warren wrote:

> From: Stephen Warren 
> 
> This moves this test into the new infra-structure, and also allows it to
> work on real hardware, not just sandbox.
> 
> Signed-off-by: Stephen Warren 

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] Implement pytest-based test infrastructure

[Tom Rini]

On Thu, Nov 19, 2015 at 10:00:32AM -0700, Stephen Warren wrote:
> On 11/19/2015 07:45 AM, Simon Glass wrote:
> >Hi Stephen,
> >
> >On 14 November 2015 at 23:53, Stephen Warren  wrote:
> >>This tool aims to test U-Boot by executing U-Boot shell commands using the
> >>console interface. A single top-level script exists to execute or attach
> >>to the U-Boot console, run the entire script of tests against it, and
> >>summarize the results. Advantages of this approach are:
> >>
> >>- Testing is performed in the same way a user or script would interact
> >>   with U-Boot; there can be no disconnect.
> >>- There is no need to write or embed test-related code into U-Boot itself.
> >>   It is asserted that writing test-related code in Python is simpler and
> >>   more flexible that writing it all in C.
> >>- It is reasonably simple to interact with U-Boot in this way.
> >>
> >>A few simple tests are provided as examples. Soon, we should convert as
> >>many as possible of the other tests in test/* and test/cmd_ut.c too.
> >
> >It's great to see this and thank you for putting in the effort!
> >
> >It looks like a good way of doing functional tests. I still see a role
> >for unit tests and things like test/dm. But if we can arrange to call
> >all U-Boot tests (unit and functional) from one 'test.py' command that
> >would be a win.
> >
> >I'll look more when I can get it to work - see below.
> ...
> >I get this on my Ubuntu 64-bit machine (14.04.3)
> >
> >$ ./test/py/test.py --bd sandbox --buildTraceback (most recent call last):
> >   File "./test/py/test.py", line 12, in 
> > os.execvp("py.test", args)
> >   File "/usr/lib/python2.7/os.py", line 344, in execvp
> > _execvpe(file, args)
> >   File "/usr/lib/python2.7/os.py", line 380, in _execvpe
> > func(fullname, *argrest)
> >OSError: [Errno 2] No such file or directory
> 
> "py.test" isn't in your $PATH. Did you install it? See the following
> in test/py/README.md:
> 
> >## Requirements
> >
> >The test suite is implemented using pytest. Interaction with the U-Boot
> >console uses pexpect. Interaction with real hardware uses the tools of your
> >choice; you get to implement various "hook" scripts that are called by the
> >test suite at the appropriate time.
> >
> >On Debian or Debian-like distributions, the following packages are required.
> >Similar package names should exist in other distributions.
> >
> >| Package| Version tested (Ubuntu 14.04) |
> >| -- | - |
> >| python | 2.7.5-5ubuntu3|
> >| python-pytest  | 2.5.1-1   |
> >| python-pexpect | 3.1-1ubuntu0.1|
> 
> In the main Python code, I trapped at least one exception location
> and made it print a message about checking the docs for missing
> requirements. I can probably patch the top-level test.py to do the
> same.

Isn't there some way to inject the local to U-Boot copy of the libraries
in?  I swear I've done something like that before in python..


-- 
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] Implement pytest-based test infrastructure

[Stephen Warren]

On 11/23/2015 04:44 PM, Tom Rini wrote:

On Thu, Nov 19, 2015 at 10:00:32AM -0700, Stephen Warren wrote:

...

See the following in test/py/README.md:


## Requirements

The test suite is implemented using pytest. Interaction with the U-Boot
console uses pexpect. Interaction with real hardware uses the tools of your
choice; you get to implement various "hook" scripts that are called by the
test suite at the appropriate time.

On Debian or Debian-like distributions, the following packages are required.
Similar package names should exist in other distributions.

| Package| Version tested (Ubuntu 14.04) |
| -- | - |
| python | 2.7.5-5ubuntu3|
| python-pytest  | 2.5.1-1   |
| python-pexpect | 3.1-1ubuntu0.1|


In the main Python code, I trapped at least one exception location
and made it print a message about checking the docs for missing
requirements. I can probably patch the top-level test.py to do the
same.


Isn't there some way to inject the local to U-Boot copy of the libraries
in?  I swear I've done something like that before in python..


It would certainly be possible to either check in the required Python 
libraries in the U-Boot source tree, or include instructions for people 
to manually create a "virtualenv" (or perhaps even automatically do this 
from test.py). However, I was hoping to avoid the need to for that since 
those options are a bit more complex than "just install these 3 packages 
and run the script". (And in fact I've already mentioned 
virtualenv-based setup instructions in the README for people which 
archaic distros).


Still, if we find that varying versions of pytest/pexpect don't work 
well, we could certainly choose one of those options.


BTW, I've created a ton of patches on top of all these that I haven't 
posted yet. See:


git://github.com/swarren/u-boot.git tegra_dev

I'm not sure if I should squash all that into a V2 of this patch, or 
just post them all as incremental fixes/enhancements?

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

Re: [U-Boot] [RFC PATCH v2 03/11] lib: net_utils: make string_to_ip stricter

[Joe Hershberger]

On Mon, Nov 9, 2015 at 1:38 AM, Chris Packham  wrote:
> Previously values greater than 255 were implicitly truncated. Add some
> stricter checking to reject addresses with components >255.
>
> With the input "1234192.168.1.1" the old behaviour would truncate the
> address to 192.168.1.1. New behaviour rejects the string outright and
> returns 0.0.0.0, which for the purposes of IP addresses can be
> considered an error.
>
> Signed-off-by: Chris Packham 
> ---
>
> Changes in v2:
> - restore some lazy parsing behavior that the tftpboot command relied on.

It would be good to explicitly describe (in the change log) what you
had to change about your stricter parsing that tftpboot required. It
seems your commit log didn't change.

>  lib/net_utils.c | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/lib/net_utils.c b/lib/net_utils.c
> index cfae842..f148b8a 100644
> --- a/lib/net_utils.c
> +++ b/lib/net_utils.c
> @@ -24,11 +24,16 @@ struct in_addr string_to_ip(const char *s)
>
> for (addr.s_addr = 0, i = 0; i < 4; ++i) {
> ulong val = s ? simple_strtoul(s, , 10) : 0;
> +   if (val > 255) {
> +   addr.s_addr = 0;
> +   return addr;
> +   }
> addr.s_addr <<= 8;
> addr.s_addr |= (val & 0xFF);
> -   if (s) {
> -   s = (*e) ? e+1 : e;
> -   }
> +   if (*e == '.')
> +   s = e + 1;
> +   else
> +   break;
> }
>
> addr.s_addr = htonl(addr.s_addr);
> --
> 2.5.3
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Implement pytest-based test infrastructure

[Simon Glass]

Hi Stephen,

On 22 November 2015 at 10:30, Stephen Warren  wrote:
> On 11/21/2015 09:49 AM, Simon Glass wrote:
>> Hi Stephen,
>>
>> On 19 November 2015 at 12:09, Stephen Warren  wrote:
>>>
>>> On 11/19/2015 10:00 AM, Stephen Warren wrote:

 On 11/19/2015 07:45 AM, Simon Glass wrote:
>
> Hi Stephen,
>
> On 14 November 2015 at 23:53, Stephen Warren 
> wrote:
>>
>> This tool aims to test U-Boot by executing U-Boot shell commands
>> using the
>> console interface. A single top-level script exists to execute or attach
>> to the U-Boot console, run the entire script of tests against it, and
>> summarize the results. Advantages of this approach are:
>>
>> - Testing is performed in the same way a user or script would interact
>>with U-Boot; there can be no disconnect.
>> - There is no need to write or embed test-related code into U-Boot
>> itself.
>>It is asserted that writing test-related code in Python is simpler
>> and
>>more flexible that writing it all in C.
>> - It is reasonably simple to interact with U-Boot in this way.
>>
>> A few simple tests are provided as examples. Soon, we should convert as
>> many as possible of the other tests in test/* and test/cmd_ut.c too.
>
>
> It's great to see this and thank you for putting in the effort!
>
> It looks like a good way of doing functional tests. I still see a role
> for unit tests and things like test/dm. But if we can arrange to call
> all U-Boot tests (unit and functional) from one 'test.py' command that
> would be a win.
>
> I'll look more when I can get it to work - see below.
>>>
>>> ...

 made it print a message about checking the docs for missing
 requirements. I can probably patch the top-level test.py to do the same.
>>>
>>>
>>> I've pushed such a patch to:
>>>
>>> git://github.com/swarren/u-boot.git tegra_dev
>>> (the separate pytests branch has now been deleted)
>>>
>>> There are also a variety of other patches there related to this testing 
>>> infra-structure. I guess I'll hold off sending them to the list until 
>>> there's been some general feedback on the patches I've already posted, but 
>>> feel free to pull the branch down and play with it. Note that it's likely 
>>> to get rebased as I work.
>>
>> OK I got it working thank you. It is horribly slow though - do you
>> know what is holding it up? For me to takes 12 seconds to run the
>> (very basic) tests.
>
> It looks like pexpect includes a default delay to simulate human
> interaction. If you edit test/py/uboot_console_base.py ensure_spawned()
> and add the following somewhere soon after the assignment to self.p:
>
> self.p.delaybeforesend = 0
>
> ... that will more than halve the execution time. (8.3 -> 3.5s on my
> 5-year-old laptop).
>
> That said, even your 12s or my 8.3s doesn't seem like a bad price to pay
> for some easy-to-use automated testing.

Sure, but my reference is to the difference between a native C test
and this framework. As we add more and more tests the overhead will be
significant. If it takes 8 seconds to run the current (fairly trivial)
tests, it might take a minute to run a larger suite, and to me that is
too long (e.g. to bisect for a failing commit).

I wonder what is causing the delay?

>
>> Also please see dm_test_usb_tree() which uses a console buffer to
>> check command output.
>
> OK, I'll take a look.
>
>> I wonder if we should use something like that
>> for simple unit tests, and use python for the more complicated
>> functional tests?
>
> I'm not sure that's a good idea; it'd be best to settle on a single way
> of executing tests so that (a) people don't have to run/implement
> different kinds of tests in different ways (b) we can leverage test code
> across as many tests as possible.
>
> (Well, doing unit tests and system level tests differently might be
> necessary since one calls functions and the other uses the shell "user
> interface", but having multiple ways of doing e.g. system tests doesn't
> seem like a good idea.)

As you found with some of the tests, it is convenient/necessary to be
able to call U-Boot C functions in some tests. So I don't see this as
a one-size-fits-all solution.

I think it is perfectly reasonable for the python framework to run the
existing C tests - there is no need to rewrite them in Python. Also
for the driver model tests - we can just run the tests from some sort
of python wrapper and get the best of both worlds, right?

Please don't take this to indicate any lack of enthusiasm for what you
are doing - it's a great development and I'm sure it will help a lot!
We really need to unify all the tests so we can run them all in one
step.

I just think we should aim to have the automated tests run in a few
seconds (let's say 5-10 at the outside). We need to make sure that the
python 

Re: [U-Boot] [PATCH v5 0/8] dm: pci: tegra: Convert Tegra PCI to driver model

[Simon Glass]

Hi Stephen,

On 23 November 2015 at 10:45, Stephen Warren  wrote:
> On 11/19/2015 08:26 PM, Simon Glass wrote:
>>
>> This series converts all Tegra boards to use driver model for PCI. The net
>> effect should be no change in functionality.
>
>
> The series,
>
> Tested-by: Stephen Warren 
>
> (On both Jetson TK1 and p2371-2180/Jetson TX1, tested PCIe Ethernet)

Thanks for helping with this. I'll pull this series into dm/master.

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

Re: [U-Boot] [PATCH v3 07/11] x86: tsc: Use notrace from

[Simon Glass]

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

Re: [U-Boot] [PATCH 10/10] ARM: socfpga: arria10: add support for building Arria10

[Chin Liang See]

On Mon, 2015-11-23 at 17:25 -0600, Dinh Nguyen wrote:
> On 11/23/2015 05:20 PM, Marek Vasut wrote:
> > On Tuesday, November 24, 2015 at 12:04:10 AM, Dinh Nguyen wrote:
> > > On 11/23/2015 05:03 PM, Marek Vasut wrote:
> > > > On Monday, November 23, 2015 at 11:50:15 PM, Dinh Nguyen wrote:
> > > > > On 11/23/2015 04:46 PM, Marek Vasut wrote:
> > > > > > On Monday, November 23, 2015 at 11:32:27 PM, Dinh Nguyen
> > > > > > wrote:
> > > > > > [...]
> > > > > > 
> > > > > > > > > > > The main point is that we need to program the
> > > > > > > > > > > FPGA
> > > > > > > > > > > during U-Boot booting up with a ~>10 MB rbf file
> > > > > > > > > > > while being
> > > > > > > > > > > limited to the OCRAM's size. I would like to
> > > > > > > > > > > contain this
> > > > > > > > > > > ugliness in it's own directory.
> > > > > > > > > > 
> > > > > > > > > > What's the problem with this ? We already support
> > > > > > > > > > loading files
> > > > > > > > > > from storage in SPL, so just compile the FPGA
> > > > > > > > > > manager into SPL as
> > > > > > > > > > well and use it.
> > > > > > > > > 
> > > > > > > > > Ok, let me re-work it all under the c5/a5 directory.
> > > > > > > > > Thanks for
> > > > > > > > > reviewing.
> > > > > > > > 
> > > > > > > > But you didn't really answer my question -- what is the
> > > > > > > > problem with
> > > > > > > > the FPGA loader in SPL ?
> > > > > > > 
> > > > > > > I thought you've already answered your own question. For
> > > > > > > whatever
> > > > > > > reason, the downstream A10 is re-doing the FPGA manager
> > > > > > > just for this
> > > > > > > purpose.
> > > > > > 
> > > > > > Could the reason be that the FPGA manager in it's current
> > > > > > state expects
> > > > > > one big buffer with the entire FPGA bitstream ? When you're
> > > > > > in SPL and
> > > > > > you still don't have DRAM running, you cannot create such
> > > > > > buffer
> > > > > > anywhere. Thus, what you need to do is to have some sort of
> > > > > > code which
> > > > > > loads a bit of the bitstream file at time and feeds it into
> > > > > > the FPGA
> > > > > > manager, piece by piece. This should be doable pretty
> > > > > > easily, what do
> > > > > > you think ?
> > > > > 
> > > > > That's exactly what is being in the mach-socfpga directory.
> > > > 
> > > > Um, am I missing it in this patchset ?
> > > 
> > > No, you're not missing it, I have not sent it up yet. That
> > > support is in
> > > the downstream, but also with the fpga-manager driver re-written.
> > > I need
> > > to clean this up before I can send it.
> > 
> > OK, thanks :)
> > 
> > > > > Yes, but should that code go into mach-socfpga or drivers?
> > > > 
> > > > The FPGA manager bits are already in drivers/fpga/ , so that's
> > > > where the
> > > > improvements should go. If you need some special handling in
> > > > the SPL,
> > > > that should be in mach-socfpga . In case it's too much change
> > > > to the
> > > > current SPL, moving the spl.c to spl-gen5.c and creating new
> > > > spl-gen10.c
> > > > might make sense ... or something like that, possibly even with
> > > > some
> > > > spl-common.c .
> > > 
> > > Ok. BTW, Arria10 is not using SPL. It has 256K of OCRAM that U
> > > -Boot can
> > > use to setup the SDRAM.
> > 
> > So what do I do if I want to boot arria10 from NAND ? UBI and UBIFS
> > won't
> > fit into 256kiB, so I think using SPL might be the sensible thing
> > afterall,
> > since you would be able to use arbitrarily-sized U-Boot.
> > 
> 
> I hope Chin Liang can chime here, I know that we have support for
> NAND,
> but I haven't been part of that task, so I don't know how it's being
> done.

Finally my email is back online :)

We do have NAND support but not with UBI and UBIFS.
For this support, user can use U-Boot to load arbitrarily-sized U-Boot
that run on SDRAM.

One of the nice thing of U-Boot over SPL is the console support and
ability to troubleshoot.
This is possible with Arria 10 SoC as we have larger OCRAM (256kB vs CV
SoC 64kB).

Thanks
Chin Liang

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

Re: [U-Boot] [PATCH] Implement pytest-based test infrastructure

[Simon Glass]

Hi Stephen,

On 23 November 2015 at 18:45, Simon Glass  wrote:
> Hi Stephen,
>
> On 22 November 2015 at 10:30, Stephen Warren  wrote:
>> On 11/21/2015 09:49 AM, Simon Glass wrote:
>>> Hi Stephen,
>>>
>>> On 19 November 2015 at 12:09, Stephen Warren  wrote:

 On 11/19/2015 10:00 AM, Stephen Warren wrote:
>
> On 11/19/2015 07:45 AM, Simon Glass wrote:
>>
>> Hi Stephen,
>>
>> On 14 November 2015 at 23:53, Stephen Warren 
>> wrote:
>>>
>>> This tool aims to test U-Boot by executing U-Boot shell commands
>>> using the
>>> console interface. A single top-level script exists to execute or attach
>>> to the U-Boot console, run the entire script of tests against it, and
>>> summarize the results. Advantages of this approach are:
>>>
>>> - Testing is performed in the same way a user or script would interact
>>>with U-Boot; there can be no disconnect.
>>> - There is no need to write or embed test-related code into U-Boot
>>> itself.
>>>It is asserted that writing test-related code in Python is simpler
>>> and
>>>more flexible that writing it all in C.
>>> - It is reasonably simple to interact with U-Boot in this way.
>>>
>>> A few simple tests are provided as examples. Soon, we should convert as
>>> many as possible of the other tests in test/* and test/cmd_ut.c too.
>>
>>
>> It's great to see this and thank you for putting in the effort!
>>
>> It looks like a good way of doing functional tests. I still see a role
>> for unit tests and things like test/dm. But if we can arrange to call
>> all U-Boot tests (unit and functional) from one 'test.py' command that
>> would be a win.
>>
>> I'll look more when I can get it to work - see below.

 ...
>
> made it print a message about checking the docs for missing
> requirements. I can probably patch the top-level test.py to do the same.


 I've pushed such a patch to:

 git://github.com/swarren/u-boot.git tegra_dev
 (the separate pytests branch has now been deleted)

 There are also a variety of other patches there related to this testing 
 infra-structure. I guess I'll hold off sending them to the list until 
 there's been some general feedback on the patches I've already posted, but 
 feel free to pull the branch down and play with it. Note that it's likely 
 to get rebased as I work.
>>>
>>> OK I got it working thank you. It is horribly slow though - do you
>>> know what is holding it up? For me to takes 12 seconds to run the
>>> (very basic) tests.
>>
>> It looks like pexpect includes a default delay to simulate human
>> interaction. If you edit test/py/uboot_console_base.py ensure_spawned()
>> and add the following somewhere soon after the assignment to self.p:
>>
>> self.p.delaybeforesend = 0
>>
>> ... that will more than halve the execution time. (8.3 -> 3.5s on my
>> 5-year-old laptop).
>>
>> That said, even your 12s or my 8.3s doesn't seem like a bad price to pay
>> for some easy-to-use automated testing.
>
> Sure, but my reference is to the difference between a native C test
> and this framework. As we add more and more tests the overhead will be
> significant. If it takes 8 seconds to run the current (fairly trivial)
> tests, it might take a minute to run a larger suite, and to me that is
> too long (e.g. to bisect for a failing commit).
>
> I wonder what is causing the delay?
>
>>
>>> Also please see dm_test_usb_tree() which uses a console buffer to
>>> check command output.
>>
>> OK, I'll take a look.
>>
>>> I wonder if we should use something like that
>>> for simple unit tests, and use python for the more complicated
>>> functional tests?
>>
>> I'm not sure that's a good idea; it'd be best to settle on a single way
>> of executing tests so that (a) people don't have to run/implement
>> different kinds of tests in different ways (b) we can leverage test code
>> across as many tests as possible.
>>
>> (Well, doing unit tests and system level tests differently might be
>> necessary since one calls functions and the other uses the shell "user
>> interface", but having multiple ways of doing e.g. system tests doesn't
>> seem like a good idea.)
>
> As you found with some of the tests, it is convenient/necessary to be
> able to call U-Boot C functions in some tests. So I don't see this as
> a one-size-fits-all solution.
>
> I think it is perfectly reasonable for the python framework to run the
> existing C tests - there is no need to rewrite them in Python. Also
> for the driver model tests - we can just run the tests from some sort
> of python wrapper and get the best of both worlds, right?
>
> Please don't take this to indicate any lack of enthusiasm for what you
> are doing - it's a great development and I'm sure it will help a lot!
> We 

Re: [U-Boot] [PATCH v3 11/11] x86: tsc: Move tsc_timer.c to drivers/timer

[Simon Glass]

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

Re: [U-Boot] [PATCH v3 09/11] x86: Convert to use driver model timer

[Simon Glass]

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

Re: [U-Boot] [PATCH v3 06/11] x86: Reomve MIN_PORT80_KCLOCKS_DELAY

[Simon Glass]

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

Re: [U-Boot] [PATCH v3 1/3] cmd_sf: add 'release' command

[Simon Glass]

Hi Valentine,

On 23 November 2015 at 02:19, Valentin Longchamp
 wrote:
> Hi Simon,
>
> On 20/11/2015 18:19, Simon Glass wrote:
>> Hi,
>>
>> On 20 November 2015 at 03:13, Valentin Longchamp
>>  wrote:
>>> On 19/11/2015 17:57, Jagan Teki wrote:
 On 13 November 2015 at 18:55, Valentin Longchamp
  wrote:
> The release command is the pendant of the probe command. This command
> allows to call spi_flash_free from the command line. This may be
> necessary for some boards where sf probe does change the state of the
> hardware (like with some pin multiplexing changes for instance).

 So you want to change the state of pin multiplexing on your board with
 connected slave devices example: spi nor flash is it? what exactly the
 need of releasing? why can't we use pin multiplexing changes like
 selecting or deselecting particular lines through driver or from board
 files itself.
>>>
>>> That's our use case yes. Let me explain you it again in detail. Some of the
>>> signals used to access the NAND Flash and the SPI NOR are shared. At reset, 
>>> they
>>> are available for the SPI NOR, since u-boot is in there and the CPU then
>>> accesses it.
>>>
>>> In an usual boot sequence, the SPI NOR is accessed first (copying u-boot to 
>>> the
>>> RAM, reading out the environment) and so the pins are configured in 
>>> hardware at
>>> boot time for accessing the SPI NOR. After that, they are configured to 
>>> access
>>> the NAND where the kernel and filesystem are stored to boot Linux thanks to
>>> env_relocate_spec() calling spi_flash_free() on exit in conjunction with [1]
>>>
>>> Now in the case where the boot sequence is interrupted and some accesses are
>>> done to the SPI NOR, the pins are changed again to SPI NOR to perform these
>>> accesses. But we have to make sure that the pins are configured back to 
>>> NAND by
>>> calling spi_flash_free() after these accesses and that's why I introduced 
>>> the
>>> release() function.
>>>
>>> In our case, there are 2 types of such accesses:
>>> - environment variables write: this is the first patch of the series. It 
>>> simply
>>> adds calls to spi_flash_free() at function exit no only in 
>>> env_relocate_spec()
>>> but also in saveenv() so that the behavior here is coherent for the whole 
>>> env_sf
>>> file (spi_flash_probe() at function start, spi_flash_free() at function 
>>> exit).
>>> - updating u-boot: this is solved for us with the last 2 patches of the 
>>> series.
>>> The first one just adds a sf release command that does the opposite/cleanup 
>>> to
>>> sf probe and the second patch just calls this command in our scripts where
>>> u-boot is updated/the SPI NOR is written.
>>>
>>> We are *indeed* using pin multiplexing changes, in our case, they are
>>> implemented in the spi controller driver: drivers/spi/kirkwood_spi.c. To be 
>>> very
>>> specific, in our case this sf release command allows to explicitely call
>>> spi_flash_free() which calls spi_free_slave(), which in our case
>>> (kirkwood_spi.c) sets the pins back to their previous configuration.
>>
>> Does your board use driver model from SPI and SPI flash? If not I
>> think that should be the first step.
>>
>
> No we don't. Could you please elaborate on how this would cover this use case
> and should be the first step ?
>
> I am open to other ways to cover this use case of ours, especially since this
> was done more than 2 years ago and u-boot has changed since then. However I
> don't see the direct link between the driver model and how it would allow to
> make sure spi_flash_free() is called in our u-boot env scripts.

In driver model you would have a remove() method for your SPI driver
which does the required pinmux changing.

There is a detailed howto in doc/driver-model showing how to port your
driver over. Please let me know if you need any help/ideas.

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

Re: [U-Boot] [PATCH v3 01/11] dm: timer: Fix several nits

[Simon Glass]

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

Re: [U-Boot] [PATCH v2 04/11] timer: sandbox: Use device tree to pass the clock frequency

[Simon Glass]

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

Re: [U-Boot] [PATCH v3 10/11] x86: tsc: Remove legacy timer codes

[Simon Glass]

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

Re: [U-Boot] [PATCH v3 03/11] timer: altera: Remove the codes to get clock frequency

[Simon Glass]

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