[U-Boot] [PATCH] buildman: Fix building based on 'options' field

[Tom Rini]

The README for buildman says that we can use any field in boards.cfg to
decide what to build.  However, we were not saving the options field
correctly.

Cc: Simon Glass 
Signed-off-by: Tom Rini 
---
 tools/buildman/board.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/buildman/board.py b/tools/buildman/board.py
index 5d536d5f2004..ae0e0b8e1719 100644
--- a/tools/buildman/board.py
+++ b/tools/buildman/board.py
@@ -92,9 +92,9 @@ class Board:
 self.board_name = board_name
 self.vendor = vendor
 self.soc = soc
-self.props = [self.target, self.arch, self.cpu, self.board_name,
-  self.vendor, self.soc]
 self.options = options
+self.props = [self.target, self.arch, self.cpu, self.board_name,
+  self.vendor, self.soc, self.options]
 self.build_it = False
 
 
-- 
1.9.1

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

Re: [U-Boot] [PATCH 3/4] sunxi: sina33: Enable the eMMC

[Chen-Yu Tsai]

On Fri, Nov 4, 2016 at 11:18 PM, Maxime Ripard
 wrote:
> The SinA33 has an 4GB Toshiba eMMC connected to the MMC2 controller.
> Enable it.
>
> Signed-off-by: Maxime Ripard 

Reviewed-by: Chen-Yu Tsai 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/4] mmc: sunxi: Enable 8bits bus width for sun8i

[Chen-Yu Tsai]

On Fri, Nov 4, 2016 at 11:18 PM, Maxime Ripard
 wrote:
> The sun8i SoCs also have a 8 bits capable MMC2 controller. Enable the
> support for those too.
>
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/mmc/sunxi_mmc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
> index 6953accce123..b8716c93cb06 100644
> --- a/drivers/mmc/sunxi_mmc.c
> +++ b/drivers/mmc/sunxi_mmc.c
> @@ -463,7 +463,7 @@ struct mmc *sunxi_mmc_init(int sdc_no)
>
> cfg->voltages = MMC_VDD_32_33 | MMC_VDD_33_34;
> cfg->host_caps = MMC_MODE_4BIT;
> -#ifdef CONFIG_MACH_SUN50I
> +#if defined(CONFIG_MACH_SUN50I) || defined(CONFIG_MACH_SUN8I)

8 come before 50. :)

Otherwise,

Reviewed-by: Chen-Yu Tsai 

> if (sdc_no == 2)
> cfg->host_caps = MMC_MODE_8BIT;
>  #endif
> --
> git-series 0.8.11
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3] gpio: dwapb: Add support for port B

[Marek Vasut]

On 11/03/2016 12:05 PM, Phil Edworthy wrote:
> The IP supports two ports, A and B, each providing up to 32 gpios.
> The driver already creates a 2nd gpio bank by reading the 2nd node
> from DT, so this is quite a simple change to support the 2nd bank.
> 
> Signed-off-by: Phil Edworthy 
> ---
> v3:
>  Pass the bank nr to the register offset macro, to cope with
>  irregular register locations.
> v2:
>  Use an offset element in the platform data instead of if-elses.

Acked-by: Marek Vasut 


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

Re: [U-Boot] [PATCH v2 2/7] spi: cadence_qspi: Fix baud rate calculation

[Marek Vasut]

On 11/03/2016 01:19 PM, Phil Edworthy wrote:
> With the existing code, when the requested SPI clock rate is near
> to the lowest that can be achieved by the hardware (max divider
> of the ref clock is 32), the generated clock rate is wrong.
> For example, with a 50MHz ref clock, when asked for anything less
> than a 1.5MHz SPI clock, the code sets up the divider to generate
> 25MHz.
> 
> This change fixes the calculation.
> 
> Signed-off-by: Phil Edworthy 
> ---
> v2:
>  - Use the DIV_ROUND_UP macro

Acked-by: Marek Vasut 


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

Re: [U-Boot] [RFC] 0/4] Add Pl330 DMA support

[Marek Vasut]

On 11/03/2016 03:21 PM, Dinh Nguyen wrote:
> 
> 
> On 11/02/2016 03:47 PM, Marek Vasut wrote:
>> On 11/02/2016 05:30 PM, Dinh Nguyen wrote:
>>> On Tue, Nov 1, 2016 at 3:43 PM, Dinh Nguyen  wrote:


 On 11/01/2016 03:42 PM, Marek Vasut wrote:
> On 11/01/2016 09:39 PM, Dinh Nguyen wrote:
>>
>>
>> On 11/01/2016 03:09 PM, Marek Vasut wrote:
>>> On 11/01/2016 04:43 PM, Dinh Nguyen wrote:


 On 10/29/2016 02:59 PM, Marek Vasut wrote:
> On 10/18/2016 05:50 PM, Dinh Nguyen wrote:
>> On Sun, Oct 16, 2016 at 10:59 AM, Marek Vasut  wrote:
>>> On 10/15/2016 12:10 AM, Dinh Nguyen wrote:


 On 10/10/2016 10:52 AM, Dinh Nguyen wrote:
> Hi,
>
> This patchset adds the PL330 DMA driver to U-Boot. The SoCFPGA 
> platform makes
> use of the PL330 to transfer zereos to the SDRAM which enables 
> the ECC bit.
>
> This is only an RFC because after rebasing to v2016.11-rc1, I had 
> to revert
> the following patch "a78cd8613204 ARM: Rework and correct barrier 
> definitions"
> in order for this patch set to work correctly. With the above 
> patch applied,
> after the SDRAM scrubbing is complete, the SPL is failing to find 
> the MMC
> device.
>

 I kinda figured out why patch "a78cd8613204 ARM: Rework and correct
 barrier definitions" is causing SPL to fail after the SDRAM scrub
 operation. It appears that before the above mentioned patch, the 
 dmb()
 operation is defined as this:

 #define dmb()  __asm__ __volatile__ ("" : : : "memory")

 after the patch, the dmb is now:

 #define DMBasm volatile ("dmb sy" : : : "memory")

 So the "dmb sy" as described in the ARM documentation is a "Full 
 system
 DMB operation". For whatever reason, this change is causing the SPL
 error after the SDRAM scrub operation.
>>>
>>> Thanks for looking into this, can you poke into it some more ?
>>>
>>
>> Of course..
>
> The patch is causing a failure even in normal operation -- if you boot
> the socfpga board and type "reset", it won't reset with the patch.
>

 Can I ask what board are you seeing this on? I'm seeing that on my 
 Atlas
 board, it does not reset properly(even with the patch reverted). But
 "reset" is working fine on my devkit, with and without the patch.
>>>
>>> SoCKit and MCVEVK.
>>>
>>> I tried bisecting it, it worked on 2016.07 and doesn't on 2016.09 , and
>>> I arrived at this patch. Maybe you can double-check this ?
>>>
>>
>> Okay, I can check it on the SoCKit.
>
> It also happens on MCVEVK, but that's probably moot for your test ;-)
>

 I don't have an MCVEVK.

>>>
>>> The "reset" functionality is working fine on the SoCKit with 2016.11-rc3.
>>
>> Does it work on 2016.09.01 too ?
>>
> 
> Yes...reset works fine on 2016.09.01 and 2016.09 on my SoCKit.
> 
> Dinh
> 
Well it doesn't work on mine ... compiler problem ?

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

Re: [U-Boot] [bug report] sunxi: booting from eMMC

[Alexandr Bochkarev]

I have found problem place, this patch with hotfix allows to boot Allwinner A20 
from eMMC.
Dont know how to full fix it.

commit 9fa5bf30e95ead17eb0c50375b305fb8615427a9
Author: root 
Date:   Sat Nov 5 04:41:30 2016 +0600

allow to boot A20 from eMMC, fix

diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index 6953acc..87cf964 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -293,11 +293,17 @@ static int mmc_trans_data_by_cpu(struct mmc *mmc, struct 
mmc_data *data)
 }
 
 static int mmc_rint_wait(struct mmc *mmc, unsigned int timeout_msecs,
-unsigned int done_bit, const char *what)
+unsigned int done_bit, const char *what, struct 
mmc_cmd *cmd)
 {
struct sunxi_mmc_host *mmchost = mmc->priv;
unsigned int status;
 
+   if (cmd->cmdidx == MMC_CMD_SWITCH)
+   {
+   printf("mmc_rint_wait: fix me\n");
+   return 0;
+   }
+
do {
status = readl(>reg->rint);
if (!timeout_msecs-- ||
@@ -380,7 +386,7 @@ static int sunxi_mmc_send_cmd(struct mmc *mmc, struct 
mmc_cmd *cmd,
}
}
 
-   error = mmc_rint_wait(mmc, 1000, SUNXI_MMC_RINT_COMMAND_DONE, "cmd");
+   error = mmc_rint_wait(mmc, 1000, SUNXI_MMC_RINT_COMMAND_DONE, "cmd", 
cmd);
if (error)
goto out;
 
@@ -391,7 +397,7 @@ static int sunxi_mmc_send_cmd(struct mmc *mmc, struct 
mmc_cmd *cmd,
  data->blocks > 1 ?
  SUNXI_MMC_RINT_AUTO_COMMAND_DONE :
  SUNXI_MMC_RINT_DATA_OVER,
- "data");
+ "data", cmd);
if (error)
goto out;
}

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

Re: [U-Boot] [PATCH 1/2] rpi: save firmware provided boot param for later use

[Tom Rini]

On Fri, Nov 04, 2016 at 08:18:29PM +0100, Cédric Schieli wrote:
> 2016-11-04 19:04 GMT+01:00 Tom Rini :
> 
> > > At U-Boot entry point, the r2 register holds the address of the
> > > firmware provided boot param. Let's save it for further processing.
> > >
> > > Signed-off-by: Cédric Schieli 
> > [snip]
> > > diff --git a/include/configs/rpi.h b/include/configs/rpi.h
> > > index 8d4ad5d..2d1e619 100644
> > > --- a/include/configs/rpi.h
> > > +++ b/include/configs/rpi.h
> > > @@ -208,5 +208,9 @@
> > >   ENV_MEM_LAYOUT_SETTINGS \
> > >   BOOTENV
> > >
> > > +#ifndef __ASSEMBLY__
> > > +/* Firmware provided boot param */
> > > +extern const void *fw_boot_param;
> > > +#endif
> >
> > This is not a good place to hold this.  Looking at 2/2, just put this
> > into the board file and comment above it that it's declared in
> > lowlevel_init.S.
> 
> That's where I've put it in the first place, but patmat complained about
> externs in .c file...
> I'll adress that in the next version.

OK.  Yes, in this case it's better to ignore that warning than to throw
it into config.h.  If there was already an rpi.h, it should go in there.
I suppose that it's probably best overall to create an rpi.h and put it
in there.

-- 
Tom


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

Re: [U-Boot] [PATCH 1/1] ARM: ts4600: add basic board support

[Fabio Estevam]

On Thu, Nov 3, 2016 at 5:20 PM, Sebastien Bourdelin
 wrote:
> This commit adds basic support including:
> MMC, Serial console
>
> Signed-off-by: Sebastien Bourdelin 

Looks good:

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

Re: [U-Boot] [PATCHv2 3/3] igep00x0: add Hynix timings

[Javier Martinez Canillas]

Hello Ladis,

On Fri, Nov 4, 2016 at 8:59 AM, Ladislav Michl  wrote:
> Tested on IGEPv2 with Micron MT29F4G16ABBDA3W and
> Hynix H27S4G6F2DKA-BM
>
> Signed-off-by: Ladislav Michl 
> ---

Reviewed-by: Javier Martinez Canillas 

I don't have an IGEPv2 with Hynix to test, but everything is working
correctly on my IGEPv2 board with a Micron NAND.

Tested-by: Javier Martinez Canillas 

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

Re: [U-Boot] [PATCHv2 2/3] igep00x0: consolidate defconfigs

[Javier Martinez Canillas]

Hello Ladis,

On Fri, Nov 4, 2016 at 8:57 AM, Ladislav Michl  wrote:
> Defconfigs should remain the same except CONFIG_SYS_EXTRA_OPTIONS.
> Drop NAND specific defconfig as flash type is runtime detected.
>
> Signed-off-by: Ladislav Michl 
> ---

Reviewed-by: Javier Martinez Canillas 

I don't have an IGEP COM Module to test but the patch looks good to me.

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

Re: [U-Boot] [PATCHv2 1/3] igep00x0: disable CONFIG_DISPLAY_BOARDINFO

[Javier Martinez Canillas]

Hello Ladis,

On Fri, Nov 4, 2016 at 8:55 AM, Ladislav Michl  wrote:
> As a single U-Boot binary can now run on various board modifications,
> drop CONFIG_DISPLAY_BOARDINFO as it prints flash memory information
> too early to give us chance to easily detect it. Also saves few bytes
> as a bonus.
>
> Signed-off-by: Ladislav Michl 
> ---

Patch looks good to me.

Reviewed-by: Javier Martinez Canillas 

I've also tested on an IGEPv2 board:

Tested-by: Javier Martinez Canillas 

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

Re: [U-Boot] [PATCHv2 1/3] igep00x0: disable CONFIG_DISPLAY_BOARDINFO

[Javier Martinez Canillas]

Hello Ladis,

On Fri, Nov 4, 2016 at 2:21 PM, Ladislav Michl  wrote:
> On Fri, Nov 04, 2016 at 12:42:57PM -0300, Javier Martinez Canillas wrote:
>> Hello Ladis,
>>
>> On 11/04/2016 08:55 AM, Ladislav Michl wrote:
>> > As a single U-Boot binary can now run on various board modifications,
>> > drop CONFIG_DISPLAY_BOARDINFO as it prints flash memory information
>> > too early to give us chance to easily detect it. Also saves few bytes
>> > as a bonus.
>> >
>> > Signed-off-by: Ladislav Michl 
>> > ---
>>
>> I tried to test your patches on latest u-boot master (sha-1 dd93a8e9e688)
>> but my IGEPv2 board fails to boot and prints in an infinite loop following:
>>
>> "ecc unrecoverable error"
>
> This comes from SPL, right? That would imply you boot from NAND...
>
>> This is not related to your patches though, since I've the same issue
>> without your patches applied.
>>
>> Did you see this issue? u-boot works with previous v2016.09 release so
>> this is a newly introduced regression.
>
> No, otherwise I would fix that. Care to send complete boot log if there is
> any?
>

As talked on irc, this is because I don't have an UBI partition on my
NAND. I've just commented the error messages for now to be able to
boot since this is an unrelated issue.

>> Unfortunately I don't have time to dig deeper on this but I may give a
>> try next week.
>
> Thank you,
> ladis

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

[U-Boot] [PATCH v2 7/7] SPI: add missing flag to micron/stm N25Q128 flash chips

[Michael Kurz]

This patch adds the missing 4K erase flag to struct spi_flash_params

Signed-off-by: Michael Kurz 

---

Changes in v2: None

 drivers/mtd/spi/sf_params.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
index 5b50114..accf95e 100644
--- a/drivers/mtd/spi/sf_params.c
+++ b/drivers/mtd/spi/sf_params.c
@@ -90,8 +90,8 @@ const struct spi_flash_params spi_flash_params_table[] = {
{"N25Q32A",0x20bb16, 0x0,   64 * 1024,64, RD_FULL | 
WR_QPP | SECT_4K},
{"N25Q64", 0x20ba17, 0x0,   64 * 1024,   128, RD_FULL | 
WR_QPP | SECT_4K},
{"N25Q64A",0x20bb17, 0x0,   64 * 1024,   128, RD_FULL | 
WR_QPP | SECT_4K},
-   {"N25Q128",0x20ba18, 0x0,   64 * 1024,   256, RD_FULL | 
WR_QPP},
-   {"N25Q128A",   0x20bb18, 0x0,   64 * 1024,   256, RD_FULL | 
WR_QPP},
+   {"N25Q128",0x20ba18, 0x0,   64 * 1024,   256, RD_FULL | 
WR_QPP | SECT_4K},
+   {"N25Q128A",   0x20bb18, 0x0,   64 * 1024,   256, RD_FULL | 
WR_QPP | SECT_4K},
{"N25Q256",0x20ba19, 0x0,   64 * 1024,   512, RD_FULL | 
WR_QPP | SECT_4K},
{"N25Q256A",   0x20bb19, 0x0,   64 * 1024,   512, RD_FULL | 
WR_QPP | SECT_4K},
{"N25Q512",0x20ba20, 0x0,   64 * 1024,  1024, RD_FULL | 
WR_QPP | E_FSR | SECT_4K},
-- 
2.1.4

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

[U-Boot] [PATCH v2 5/7] ARM: stm32: enable support for smsc phy on stm32f746-disco board

[Michael Kurz]

This patch enables support for the smsc phy on the
stm32f746-disco board.

Signed-off-by: Michael Kurz 
---

Changes in v2: None

 include/configs/stm32f746-disco.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/stm32f746-disco.h 
b/include/configs/stm32f746-disco.h
index 4088064..246cc2e 100644
--- a/include/configs/stm32f746-disco.h
+++ b/include/configs/stm32f746-disco.h
@@ -46,6 +46,7 @@
 #define CONFIG_DW_GMAC_DEFAULT_DMA_PBL (8)
 #define CONFIG_DW_ALTDESCRIPTOR
 #define CONFIG_MII
+#define CONFIG_PHY_SMSC
 
 #define CONFIG_STM32_HSE_HZ2500
 #define CONFIG_SYS_CLK_FREQ2 /* 200 MHz */
-- 
2.1.4

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

[U-Boot] [PATCH v2 6/7] ARM: SPI: stm32: add stm32f746 qspi driver

[Michael Kurz]

This patch adds support for the QSPI IP found in stm32f7 devices.

Signed-off-by: Michael Kurz 

---
This currently hard disables any multi i/o in the device tree, as it is
impossible to get this working without interpreting the commands of the
spi-flash framework in the xfer function and setting the used i/o lines
accordingly.
As i understand a spi-nor framework is currently in the making which
addresses these problems. Should i base this driver on the new
framework or is it ok in the current form and should later be ported to
the new one?

Changes in v2:
- Replaced bit shifts and masks with BIT() and GENMASK() macro

 arch/arm/dts/stm32f746-disco.dts |   4 +-
 arch/arm/include/asm/arch-stm32f7/stm32_periph.h |   6 +-
 arch/arm/mach-stm32/stm32f7/clock.c  |   4 +
 board/st/stm32f746-disco/stm32f746-disco.c   |  60 +++
 configs/stm32f746-disco_defconfig|   7 +
 drivers/spi/Kconfig  |   8 +
 drivers/spi/Makefile |   1 +
 drivers/spi/stm32_qspi.c | 628 +++
 8 files changed, 714 insertions(+), 4 deletions(-)
 create mode 100644 drivers/spi/stm32_qspi.c

diff --git a/arch/arm/dts/stm32f746-disco.dts b/arch/arm/dts/stm32f746-disco.dts
index 7b652f0..b58889a 100644
--- a/arch/arm/dts/stm32f746-disco.dts
+++ b/arch/arm/dts/stm32f746-disco.dts
@@ -146,8 +146,8 @@
#size-cells = <1>;
compatible = "micron,n25q128a13", "spi-flash";
spi-max-frequency = <10800>;
-   spi-tx-bus-width = <4>;
-   spi-rx-bus-width = <4>;
+   spi-tx-bus-width = <1>;
+   spi-rx-bus-width = <1>;
memory-map = <0x9000 0x100>;
reg = <0>;
};
diff --git a/arch/arm/include/asm/arch-stm32f7/stm32_periph.h 
b/arch/arm/include/asm/arch-stm32f7/stm32_periph.h
index 508b5f2..3c5604a 100644
--- a/arch/arm/include/asm/arch-stm32f7/stm32_periph.h
+++ b/arch/arm/include/asm/arch-stm32f7/stm32_periph.h
@@ -15,8 +15,9 @@
  *
  */
 enum periph_id {
-   UART1_GPIOA_9_10 = 0,
-   UART2_GPIOD_5_6,
+   PERIPH_ID_USART1 = 37,
+
+   PERIPH_ID_QUADSPI = 92,
 };
 
 enum periph_clock {
@@ -37,6 +38,7 @@ enum periph_clock {
TIMER2_CLOCK_CFG,
FMC_CLOCK_CFG,
STMMAC_CLOCK_CFG,
+   QSPI_CLOCK_CFG,
 };
 
 #endif /* __ASM_ARM_ARCH_PERIPH_H */
diff --git a/arch/arm/mach-stm32/stm32f7/clock.c 
b/arch/arm/mach-stm32/stm32f7/clock.c
index b068828..818401e 100644
--- a/arch/arm/mach-stm32/stm32f7/clock.c
+++ b/arch/arm/mach-stm32/stm32f7/clock.c
@@ -71,6 +71,7 @@ struct stm32_rcc_regs {
  * RCC AHB3ENR specific definitions
  */
 #define RCC_AHB3ENR_FMC_EN BIT(0)
+#define RCC_AHB3ENR_QSPI_ENBIT(1)
 
 /*
  * RCC APB1ENR specific definitions
@@ -342,6 +343,9 @@ void clock_setup(int peripheral)
setbits_le32(_RCC->ahb1enr, RCC_AHB1ENR_ETHMAC_RX_EN);
setbits_le32(_RCC->ahb1enr, RCC_AHB1ENR_ETHMAC_TX_EN);
break;
+   case QSPI_CLOCK_CFG:
+   setbits_le32(_RCC->ahb3enr, RCC_AHB3ENR_QSPI_EN);
+   break;
default:
break;
}
diff --git a/board/st/stm32f746-disco/stm32f746-disco.c 
b/board/st/stm32f746-disco/stm32f746-disco.c
index 970eabe..dcf3a4e 100644
--- a/board/st/stm32f746-disco/stm32f746-disco.c
+++ b/board/st/stm32f746-disco/stm32f746-disco.c
@@ -326,6 +326,60 @@ static int stmmac_setup(void)
 }
 #endif
 
+#ifdef CONFIG_STM32_QSPI
+const struct stm32_gpio_ctl gpio_ctl_qspi_9 = {
+   .mode = STM32_GPIO_MODE_AF,
+   .otype = STM32_GPIO_OTYPE_PP,
+   .speed = STM32_GPIO_SPEED_100M,
+   .pupd = STM32_GPIO_PUPD_NO,
+   .af = STM32_GPIO_AF9
+};
+
+const struct stm32_gpio_ctl gpio_ctl_qspi_10 = {
+   .mode = STM32_GPIO_MODE_AF,
+   .otype = STM32_GPIO_OTYPE_PP,
+   .speed = STM32_GPIO_SPEED_100M,
+   .pupd = STM32_GPIO_PUPD_NO,
+   .af = STM32_GPIO_AF10
+};
+
+static const struct stm32_gpio_dsc qspi_af9_gpio[] = {
+   {STM32_GPIO_PORT_B, STM32_GPIO_PIN_2},  /* QUADSPI_CLK */
+   {STM32_GPIO_PORT_D, STM32_GPIO_PIN_11}, /* QUADSPI_BK1_IO0 */
+   {STM32_GPIO_PORT_D, STM32_GPIO_PIN_12}, /* QUADSPI_BK1_IO1 */
+   {STM32_GPIO_PORT_D, STM32_GPIO_PIN_13}, /* QUADSPI_BK1_IO3 */
+   {STM32_GPIO_PORT_E, STM32_GPIO_PIN_2},  /* QUADSPI_BK1_IO2 */
+};
+
+static const struct stm32_gpio_dsc qspi_af10_gpio[] = {
+   {STM32_GPIO_PORT_B, STM32_GPIO_PIN_6},  /* QUADSPI_BK1_NCS */
+};
+
+static int qspi_setup(void)
+{
+   int res = 0;
+   int i;
+
+   clock_setup(GPIO_B_CLOCK_CFG);
+   clock_setup(GPIO_D_CLOCK_CFG);
+   clock_setup(GPIO_E_CLOCK_CFG);
+
+   for (i = 0; i < ARRAY_SIZE(qspi_af9_gpio); i++) {
+   res = stm32_gpio_config(_af9_gpio[i], _ctl_qspi_9);

[U-Boot] [PATCH v2 4/7] net: phy: add SMSC LAN8742 phy

[Michael Kurz]

This patch adds support for SMSC LAN8742 in phylib

Signed-off-by: Michael Kurz 
Acked-by: Joe Hershberger 

---

Changes in v2:
- Add Acked-by tag to 'net: phy: add SMSC LAN8742 phy'

 drivers/net/phy/smsc.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/net/phy/smsc.c b/drivers/net/phy/smsc.c
index 313fcdf..41ffbe9 100644
--- a/drivers/net/phy/smsc.c
+++ b/drivers/net/phy/smsc.c
@@ -82,12 +82,24 @@ static struct phy_driver lan8740_driver = {
.startup = _startup,
.shutdown = _shutdown,
 };
+
+static struct phy_driver lan8742_driver = {
+   .name = "SMSC LAN8742",
+   .uid = 0x0007c130,
+   .mask = 0x0,
+   .features = PHY_BASIC_FEATURES,
+   .config = _config_aneg,
+   .startup = _startup,
+   .shutdown = _shutdown,
+};
+
 int phy_smsc_init(void)
 {
phy_register(_driver);
phy_register(_driver);
phy_register(_driver);
phy_register(_driver);
+   phy_register(_driver);
 
return 0;
 }
-- 
2.1.4

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

[U-Boot] [PATCH v2 3/7] net: stm32: add designware mac glue code for stm32

[Michael Kurz]

This patch adds glue code required for enabling the designware
mac on stm32f7 devices.

Signed-off-by: Michael Kurz 

---

Changes in v2:
- Replaced bit shifts and masks with BIT() and GENMASK() macro
- Moved STM32_SYSCFG_BASE into stm32.h header

 arch/arm/include/asm/arch-stm32f7/stm32_periph.h |  1 +
 arch/arm/include/asm/arch-stm32f7/syscfg.h   | 38 
 arch/arm/mach-stm32/stm32f7/clock.c  |  5 +++
 board/st/stm32f746-disco/stm32f746-disco.c   | 56 
 configs/stm32f746-disco_defconfig| 15 ++-
 drivers/net/designware.c |  1 +
 include/configs/stm32f746-disco.h|  9 +++-
 7 files changed, 122 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/include/asm/arch-stm32f7/syscfg.h

diff --git a/arch/arm/include/asm/arch-stm32f7/stm32_periph.h 
b/arch/arm/include/asm/arch-stm32f7/stm32_periph.h
index 9b315a8..508b5f2 100644
--- a/arch/arm/include/asm/arch-stm32f7/stm32_periph.h
+++ b/arch/arm/include/asm/arch-stm32f7/stm32_periph.h
@@ -36,6 +36,7 @@ enum periph_clock {
SYSCFG_CLOCK_CFG,
TIMER2_CLOCK_CFG,
FMC_CLOCK_CFG,
+   STMMAC_CLOCK_CFG,
 };
 
 #endif /* __ASM_ARM_ARCH_PERIPH_H */
diff --git a/arch/arm/include/asm/arch-stm32f7/syscfg.h 
b/arch/arm/include/asm/arch-stm32f7/syscfg.h
new file mode 100644
index 000..49e78f2
--- /dev/null
+++ b/arch/arm/include/asm/arch-stm32f7/syscfg.h
@@ -0,0 +1,38 @@
+/*
+ * (C) Copyright 2016
+ * Michael Kurz, michi.k...@gmail.com.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _STM32_SYSCFG_H
+#define _STM32_SYSCFG_H
+
+struct stm32_syscfg_regs {
+   u32 memrmp;
+   u32 pmc;
+   u32 exticr1;
+   u32 exticr2;
+   u32 exticr3;
+   u32 exticr4;
+   u32 cmpcr;
+};
+
+/*
+ * SYSCFG registers base
+ */
+#define STM32_SYSCFG   ((struct stm32_syscfg_regs *)STM32_SYSCFG_BASE)
+
+/* SYSCFG memory remap register */
+#define SYSCFG_MEMRMP_MEM_BOOT BIT(0)
+#define SYSCFG_MEMRMP_SWP_FMC  BIT(10)
+
+/* SYSCFG peripheral mode configuration register */
+#define SYSCFG_PMC_ADCXDC2 BIT(16)
+#define SYSCFG_PMC_MII_RMII_SELBIT(23)
+
+/* Compensation cell control register */
+#define SYSCFG_CMPCR_CMP_PDBIT(0)
+#define SYSCFG_CMPCR_READY BIT(8)
+
+#endif
diff --git a/arch/arm/mach-stm32/stm32f7/clock.c 
b/arch/arm/mach-stm32/stm32f7/clock.c
index 839d928..b068828 100644
--- a/arch/arm/mach-stm32/stm32f7/clock.c
+++ b/arch/arm/mach-stm32/stm32f7/clock.c
@@ -337,6 +337,11 @@ void clock_setup(int peripheral)
case FMC_CLOCK_CFG:
setbits_le32(_RCC->ahb3enr, RCC_AHB3ENR_FMC_EN);
break;
+   case STMMAC_CLOCK_CFG:
+   setbits_le32(_RCC->ahb1enr, RCC_AHB1ENR_ETHMAC_EN);
+   setbits_le32(_RCC->ahb1enr, RCC_AHB1ENR_ETHMAC_RX_EN);
+   setbits_le32(_RCC->ahb1enr, RCC_AHB1ENR_ETHMAC_TX_EN);
+   break;
default:
break;
}
diff --git a/board/st/stm32f746-disco/stm32f746-disco.c 
b/board/st/stm32f746-disco/stm32f746-disco.c
index db5510e..970eabe 100644
--- a/board/st/stm32f746-disco/stm32f746-disco.c
+++ b/board/st/stm32f746-disco/stm32f746-disco.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -276,6 +277,55 @@ U_BOOT_DEVICE(stm32x7_serials) = {
.platdata = _platdata,
 };
 
+#ifdef CONFIG_ETH_DESIGNWARE
+const struct stm32_gpio_ctl gpio_ctl_eth = {
+   .mode = STM32_GPIO_MODE_AF,
+   .otype = STM32_GPIO_OTYPE_PP,
+   .speed = STM32_GPIO_SPEED_100M,
+   .pupd = STM32_GPIO_PUPD_NO,
+   .af = STM32_GPIO_AF11
+};
+
+static const struct stm32_gpio_dsc eth_gpio[] = {
+   {STM32_GPIO_PORT_A, STM32_GPIO_PIN_1},  /* ETH_RMII_REF_CLK */
+   {STM32_GPIO_PORT_A, STM32_GPIO_PIN_2},  /* ETH_MDIO */
+   {STM32_GPIO_PORT_A, STM32_GPIO_PIN_7},  /* ETH_RMII_CRS_DV */
+
+   {STM32_GPIO_PORT_C, STM32_GPIO_PIN_1},  /* ETH_MDC */
+   {STM32_GPIO_PORT_C, STM32_GPIO_PIN_4},  /* ETH_RMII_RXD0 */
+   {STM32_GPIO_PORT_C, STM32_GPIO_PIN_5},  /* ETH_RMII_RXD1 */
+
+   {STM32_GPIO_PORT_G, STM32_GPIO_PIN_11}, /* ETH_RMII_TX_EN */
+   {STM32_GPIO_PORT_G, STM32_GPIO_PIN_13}, /* ETH_RMII_TXD0 */
+   {STM32_GPIO_PORT_G, STM32_GPIO_PIN_14}, /* ETH_RMII_TXD1 */
+};
+
+static int stmmac_setup(void)
+{
+   int res = 0;
+   int i;
+
+   clock_setup(SYSCFG_CLOCK_CFG);
+
+   /* Set >RMII mode */
+   STM32_SYSCFG->pmc |= SYSCFG_PMC_MII_RMII_SEL;
+
+   clock_setup(GPIO_A_CLOCK_CFG);
+   clock_setup(GPIO_C_CLOCK_CFG);
+   clock_setup(GPIO_G_CLOCK_CFG);
+
+   for (i = 0; i < ARRAY_SIZE(eth_gpio); i++) {
+   res = stm32_gpio_config(_gpio[i], _ctl_eth);
+   if (res)
+   return res;
+   }
+
+   clock_setup(STMMAC_CLOCK_CFG);
+
+   return 0;
+}
+#endif
+
 u32 get_board_rev(void)
 {
return 

[U-Boot] [PATCH v2 2/7] ARM: stm32: cleanup stm32f7 files

[Michael Kurz]

Cleanup stm32f7 files:
- use BIT macro
- use GENMASK macro
- prefix all constants with STM32_
- remove double constants

Signed-off-by: Michael Kurz 

---

Changes in v2:
- add cleanup patch

 arch/arm/include/asm/arch-stm32f4/stm32.h|   2 +-
 arch/arm/include/asm/arch-stm32f7/fmc.h  |   7 +-
 arch/arm/include/asm/arch-stm32f7/gpt.h  |   9 +-
 arch/arm/include/asm/arch-stm32f7/rcc.h  |  64 ---
 arch/arm/include/asm/arch-stm32f7/stm32.h| 119 +---
 arch/arm/include/asm/arch-stm32f7/stm32_periph.h |   3 +
 arch/arm/mach-stm32/stm32f7/clock.c  | 227 ++-
 arch/arm/mach-stm32/stm32f7/timer.c  |   4 +-
 board/st/stm32f746-disco/stm32f746-disco.c   |  10 +-
 drivers/mtd/stm32_flash.c|   2 +-
 drivers/serial/serial_stm32x7.c  |   4 +-
 11 files changed, 203 insertions(+), 248 deletions(-)
 delete mode 100644 arch/arm/include/asm/arch-stm32f7/rcc.h

diff --git a/arch/arm/include/asm/arch-stm32f4/stm32.h 
b/arch/arm/include/asm/arch-stm32f4/stm32.h
index 6cc1966..b77345a 100644
--- a/arch/arm/include/asm/arch-stm32f4/stm32.h
+++ b/arch/arm/include/asm/arch-stm32f4/stm32.h
@@ -102,7 +102,7 @@ struct stm32_pwr_regs {
 #define STM32_USART3_BASE  (STM32_APB1PERIPH_BASE + 0x4800)
 #define STM32_USART6_BASE  (STM32_APB2PERIPH_BASE + 0x1400)
 
-#define FLASH_CNTL_BASE(STM32_AHB1PERIPH_BASE + 0x3C00)
+#define STM32_FLASH_CNTL_BASE  (STM32_AHB1PERIPH_BASE + 0x3C00)
 
 static const u32 sect_sz_kb[CONFIG_SYS_MAX_FLASH_SECT] = {
[0 ... 3] = 16 * 1024,
diff --git a/arch/arm/include/asm/arch-stm32f7/fmc.h 
b/arch/arm/include/asm/arch-stm32f7/fmc.h
index 7dd5077..24e6f1e 100644
--- a/arch/arm/include/asm/arch-stm32f7/fmc.h
+++ b/arch/arm/include/asm/arch-stm32f7/fmc.h
@@ -24,7 +24,6 @@ struct stm32_fmc_regs {
 /*
  * FMC registers base
  */
-#define STM32_SDRAM_FMC_BASE   0xA140
 #define STM32_SDRAM_FMC((struct stm32_fmc_regs 
*)STM32_SDRAM_FMC_BASE)
 
 /* Control register SDCR */
@@ -58,12 +57,12 @@ struct stm32_fmc_regs {
 #define FMC_SDCMR_MODE_SELFREFRESH 5
 #define FMC_SDCMR_MODE_POWERDOWN   6
 
-#define FMC_SDCMR_BANK_1   (1 << 4)
-#define FMC_SDCMR_BANK_2   (1 << 3)
+#define FMC_SDCMR_BANK_1   BIT(4)
+#define FMC_SDCMR_BANK_2   BIT(3)
 
 #define FMC_SDCMR_MODE_REGISTER_SHIFT  9
 
-#define FMC_SDSR_BUSY  (1 << 5)
+#define FMC_SDSR_BUSY  BIT(5)
 
 #define FMC_BUSY_WAIT()do { \
__asm__ __volatile__ ("dsb" : : : "memory"); \
diff --git a/arch/arm/include/asm/arch-stm32f7/gpt.h 
b/arch/arm/include/asm/arch-stm32f7/gpt.h
index 903bdf6..7591519 100644
--- a/arch/arm/include/asm/arch-stm32f7/gpt.h
+++ b/arch/arm/include/asm/arch-stm32f7/gpt.h
@@ -34,12 +34,11 @@ struct gpt_regs {
u32 tim2_5_or;
 };
 
-struct gpt_regs *const gpt1_regs_ptr =
-   (struct gpt_regs *)TIM2_BASE;
+struct gpt_regs *const gpt1_regs_ptr = (struct gpt_regs *)STM32_TIM2_BASE;
 
 /* Timer control1 register  */
-#define GPT_CR1_CEN0x0001
-#define GPT_MODE_AUTO_RELOAD   (1 << 7)
+#define GPT_CR1_CENBIT(0)
+#define GPT_MODE_AUTO_RELOAD   BIT(7)
 
 /* Auto reload register for free running config */
 #define GPT_FREE_RUNNING   0x
@@ -48,6 +47,6 @@ struct gpt_regs *const gpt1_regs_ptr =
 #define CONFIG_STM32_HZ1000
 
 /* Timer Event Generation registers */
-#define TIM_EGR_UG (1 << 0)
+#define TIM_EGR_UG BIT(0)
 
 #endif
diff --git a/arch/arm/include/asm/arch-stm32f7/rcc.h 
b/arch/arm/include/asm/arch-stm32f7/rcc.h
deleted file mode 100644
index 8bfb7b6..000
--- a/arch/arm/include/asm/arch-stm32f7/rcc.h
+++ /dev/null
@@ -1,64 +0,0 @@
-/*
- * (C) Copyright 2016
- * Vikas Manocha, ST Micoelectronics, vikas.mano...@st.com.
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#ifndef _STM32_RCC_H
-#define _STM32_RCC_H
-
-#define RCC_CR 0x00/* clock control */
-#define RCC_PLLCFGR0x04/* PLL configuration */
-#define RCC_CFGR   0x08/* clock configuration */
-#define RCC_CIR0x0C/* clock interrupt */
-#define RCC_AHB1RSTR   0x10/* AHB1 peripheral reset */
-#define RCC_AHB2RSTR   0x14/* AHB2 peripheral reset */
-#define RCC_AHB3RSTR   0x18/* AHB3 peripheral reset */
-#define RCC_APB1RSTR   0x20/* APB1 peripheral reset */
-#define RCC_APB2RSTR   0x24/* APB2 peripheral reset */
-#define RCC_AHB1ENR0x30/* AHB1 peripheral clock enable */
-#define RCC_AHB2ENR0x34/* AHB2 peripheral clock enable */
-#define RCC_AHB3ENR0x38/* AHB3 peripheral clock enable */
-#define RCC_APB1ENR0x40/* APB1 peripheral clock enable */
-#define RCC_APB2ENR0x44/* APB2 peripheral clock enable */
-#define 

[U-Boot] [PATCH v2 1/7] ARM: DTS: stm32: add stm32f746-disco device tree files

[Michael Kurz]

This patch adds the DTS source files needed for stm32f746-disco board
based on the stm32f429/469 files from current linux kernel.

Signed-off-by: Michael Kurz 
---

Changes in v2: None

 arch/arm/dts/Makefile   |2 +
 arch/arm/dts/armv7-m.dtsi   |   24 +
 arch/arm/dts/stm32f746-disco.dts|  154 +++
 arch/arm/dts/stm32f746.dtsi |  397 +++
 configs/stm32f746-disco_defconfig   |1 +
 include/dt-bindings/pinctrl/stm32f746-pinfunc.h | 1324 +++
 6 files changed, 1902 insertions(+)
 create mode 100644 arch/arm/dts/armv7-m.dtsi
 create mode 100644 arch/arm/dts/stm32f746-disco.dts
 create mode 100644 arch/arm/dts/stm32f746.dtsi
 create mode 100644 include/dt-bindings/pinctrl/stm32f746-pinfunc.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 836a8c4..0cb0d07 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -155,6 +155,8 @@ dtb-$(CONFIG_FSL_LSCH2) += fsl-ls1043a-qds-duart.dtb \
 
 dtb-$(CONFIG_ARCH_SNAPDRAGON) += dragonboard410c.dtb
 
+dtb-$(CONFIG_STM32F7) += stm32f746-disco.dtb
+
 dtb-$(CONFIG_MACH_SUN4I) += \
sun4i-a10-a1000.dtb \
sun4i-a10-ba10-tvbox.dtb \
diff --git a/arch/arm/dts/armv7-m.dtsi b/arch/arm/dts/armv7-m.dtsi
new file mode 100644
index 000..e0a6bf2
--- /dev/null
+++ b/arch/arm/dts/armv7-m.dtsi
@@ -0,0 +1,24 @@
+#include "skeleton.dtsi"
+
+/ {
+   nvic: interrupt-controller@e000e100  {
+   compatible = "arm,armv7m-nvic";
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   reg = <0xe000e100 0xc00>;
+   };
+
+   systick: timer@e000e010 {
+   compatible = "arm,armv7m-systick";
+   reg = <0xe000e010 0x10>;
+   status = "disabled";
+   };
+
+   soc {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "simple-bus";
+   interrupt-parent = <>;
+   ranges;
+   };
+};
\ No newline at end of file
diff --git a/arch/arm/dts/stm32f746-disco.dts b/arch/arm/dts/stm32f746-disco.dts
new file mode 100644
index 000..7b652f0
--- /dev/null
+++ b/arch/arm/dts/stm32f746-disco.dts
@@ -0,0 +1,154 @@
+/*
+ * Copyright 2016 - Michael Kurz 
+ *
+ * Based on:
+ * stm32f469-disco.dts from Linux
+ * Copyright 2016 - Lee Jones 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "stm32f746.dtsi"
+
+/ {
+   model = "STMicroelectronics STM32F746-DISCO board";
+   compatible = "st,stm32f746-disco", "st,stm32f746";
+
+   chosen {
+   bootargs = "root=/dev/ram rdinit=/linuxrc";
+   stdout-path = "serial0:115200n8";
+   };
+
+   memory {
+   reg = <0xC000 0x80>;
+   };
+
+   aliases {
+   serial0 = 
+   spi0 = 
+   };
+
+   soc {
+   pin-controller {
+   usart1_pins_disco: 

[U-Boot] [PATCH v2 0/7] ARM: stm32: add network and qspi driver support to stm32f746-disco board

[Michael Kurz]

This series adds support for the network and the qspi devices found on
the stm32f746 controller and enables those devices on the
stm32f746-disco board.

Changes in v2:
- add cleanup patch
- Replaced bit shifts and masks with BIT() and GENMASK() macro
- Moved STM32_SYSCFG_BASE into stm32.h header
- Add Acked-by tag to 'net: phy: add SMSC LAN8742 phy'
- Replaced bit shifts and masks with BIT() and GENMASK() macro

Michael Kurz (7):
  ARM: DTS: stm32: add stm32f746-disco device tree files
  ARM: stm32: cleanup stm32f7 files
  net: stm32: add designware mac glue code for stm32
  net: phy: add SMSC LAN8742 phy
  ARM: stm32: enable support for smsc phy on stm32f746-disco board
  ARM: SPI: stm32: add stm32f746 qspi driver
  SPI: add missing flag to micron/stm N25Q128 flash chips

 arch/arm/dts/Makefile|2 +
 arch/arm/dts/armv7-m.dtsi|   24 +
 arch/arm/dts/stm32f746-disco.dts |  154 +++
 arch/arm/dts/stm32f746.dtsi  |  397 +++
 arch/arm/include/asm/arch-stm32f4/stm32.h|2 +-
 arch/arm/include/asm/arch-stm32f7/fmc.h  |7 +-
 arch/arm/include/asm/arch-stm32f7/gpt.h  |9 +-
 arch/arm/include/asm/arch-stm32f7/rcc.h  |   64 --
 arch/arm/include/asm/arch-stm32f7/stm32.h|  119 +-
 arch/arm/include/asm/arch-stm32f7/stm32_periph.h |   10 +-
 arch/arm/include/asm/arch-stm32f7/syscfg.h   |   38 +
 arch/arm/mach-stm32/stm32f7/clock.c  |  236 ++--
 arch/arm/mach-stm32/stm32f7/timer.c  |4 +-
 board/st/stm32f746-disco/stm32f746-disco.c   |  126 +-
 configs/stm32f746-disco_defconfig|   23 +-
 drivers/mtd/spi/sf_params.c  |4 +-
 drivers/mtd/stm32_flash.c|2 +-
 drivers/net/designware.c |1 +
 drivers/net/phy/smsc.c   |   12 +
 drivers/serial/serial_stm32x7.c  |4 +-
 drivers/spi/Kconfig  |8 +
 drivers/spi/Makefile |1 +
 drivers/spi/stm32_qspi.c |  628 ++
 include/configs/stm32f746-disco.h|   10 +-
 include/dt-bindings/pinctrl/stm32f746-pinfunc.h  | 1324 ++
 25 files changed, 2954 insertions(+), 255 deletions(-)
 create mode 100644 arch/arm/dts/armv7-m.dtsi
 create mode 100644 arch/arm/dts/stm32f746-disco.dts
 create mode 100644 arch/arm/dts/stm32f746.dtsi
 delete mode 100644 arch/arm/include/asm/arch-stm32f7/rcc.h
 create mode 100644 arch/arm/include/asm/arch-stm32f7/syscfg.h
 create mode 100644 drivers/spi/stm32_qspi.c
 create mode 100644 include/dt-bindings/pinctrl/stm32f746-pinfunc.h

-- 
2.1.4

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

Re: [U-Boot] [PATCH 1/2] rpi: save firmware provided boot param for later use

[Cédric Schieli]

2016-11-04 19:04 GMT+01:00 Tom Rini :

> > At U-Boot entry point, the r2 register holds the address of the
> > firmware provided boot param. Let's save it for further processing.
> >
> > Signed-off-by: Cédric Schieli 
> [snip]
> > diff --git a/include/configs/rpi.h b/include/configs/rpi.h
> > index 8d4ad5d..2d1e619 100644
> > --- a/include/configs/rpi.h
> > +++ b/include/configs/rpi.h
> > @@ -208,5 +208,9 @@
> >   ENV_MEM_LAYOUT_SETTINGS \
> >   BOOTENV
> >
> > +#ifndef __ASSEMBLY__
> > +/* Firmware provided boot param */
> > +extern const void *fw_boot_param;
> > +#endif
>
> This is not a good place to hold this.  Looking at 2/2, just put this
> into the board file and comment above it that it's declared in
> lowlevel_init.S.


That's where I've put it in the first place, but patmat complained about
externs in .c file...
I'll adress that in the next version.

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

Re: [U-Boot] [PATCH 2/2] rpi: expose the firmware provided FDT blob in ${fw_fdt_addr}

[Tom Rini]

On Wed, Nov 02, 2016 at 07:06:13PM +0100, Cédric Schieli wrote:

> If the fw_boot_param saved at an early stage points to a valid FDT
> blob, let's expose it in ${fw_fdt_addr}.
> 
> Signed-off-by: Cédric Schieli 

OK, but how is fw_fdt_addr actually used?  I think we need to include
that in this patch too, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH 1/2] rpi: save firmware provided boot param for later use

[Tom Rini]

On Wed, Nov 02, 2016 at 07:06:12PM +0100, Cédric Schieli wrote:

> At U-Boot entry point, the r2 register holds the address of the
> firmware provided boot param. Let's save it for further processing.
> 
> Signed-off-by: Cédric Schieli 
[snip]
> diff --git a/include/configs/rpi.h b/include/configs/rpi.h
> index 8d4ad5d..2d1e619 100644
> --- a/include/configs/rpi.h
> +++ b/include/configs/rpi.h
> @@ -208,5 +208,9 @@
>   ENV_MEM_LAYOUT_SETTINGS \
>   BOOTENV
>  
> +#ifndef __ASSEMBLY__
> +/* Firmware provided boot param */
> +extern const void *fw_boot_param;
> +#endif

This is not a good place to hold this.  Looking at 2/2, just put this
into the board file and comment above it that it's declared in
lowlevel_init.S.

-- 
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 Support for SIL3531

[Tom Rini]

On Tue, Nov 01, 2016 at 02:07:43PM -0700, Rudolf J Streif wrote:

> Does anyone know if u-boot supports the SIL3531 PCIE SATA controller?
> 
> drivers/block/sata_sil.c explicitly lists SIL3131, SIL3132, and SIL3124. I am 
> not that familiar with the history of the SIL SATA chips and maybe somebody 
> knows if the SIL3531 is backwards compatible to those chips.

The best answer, without being able to test the HW in question, would be
to poke the relevant Linux driver and see if it distinguishes the 3531
from 3131 or just calls them 3x31.

-- 
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] [PATCHv2 1/3] igep00x0: disable CONFIG_DISPLAY_BOARDINFO

[Ladislav Michl]

On Fri, Nov 04, 2016 at 12:42:57PM -0300, Javier Martinez Canillas wrote:
> Hello Ladis,
> 
> On 11/04/2016 08:55 AM, Ladislav Michl wrote:
> > As a single U-Boot binary can now run on various board modifications,
> > drop CONFIG_DISPLAY_BOARDINFO as it prints flash memory information
> > too early to give us chance to easily detect it. Also saves few bytes
> > as a bonus.
> > 
> > Signed-off-by: Ladislav Michl 
> > ---
> 
> I tried to test your patches on latest u-boot master (sha-1 dd93a8e9e688)
> but my IGEPv2 board fails to boot and prints in an infinite loop following:
> 
> "ecc unrecoverable error"

This comes from SPL, right? That would imply you boot from NAND...

> This is not related to your patches though, since I've the same issue
> without your patches applied.
> 
> Did you see this issue? u-boot works with previous v2016.09 release so
> this is a newly introduced regression.

No, otherwise I would fix that. Care to send complete boot log if there is
any?

> Unfortunately I don't have time to dig deeper on this but I may give a
> try next week.

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

Re: [U-Boot] cubieboard sunxi u-boot help me

[Jagan Teki]

On Fri, Nov 4, 2016 at 6:03 PM, 崔超 <13671369...@163.com> wrote:
> Hi ,
> I' from China. I am studying u-boot on Cubieboard and I have a problem.
> https://github.com/OSer916/u-boot.git .
> My code is on the "cubieboard" branch.
>
>
> When I do "make sunny_defconfig && make CROSS_COMPILE=arm-linux-gnueabihf-", 
> the trouble comes out last:
>
>
> arm-linux-gnueabihf-ld.bfd: BFD (GNU Binutils) 2.25.0 Linaro 2015_10 
> assertion fail 
> /home/tcwg-buildslave/workspace/tcwg-make-release/label/tcwg-x86_64-ex40/target/arm-linux-gnueabihf/snapshots/binutils-gdb.git~linaro_binutils-2_25-branch/bfd/elf32-arm.c:7827
> arm-linux-gnueabihf-ld.bfd: error: required section '.rel.plt' not found in 
> the linker script
> arm-linux-gnueabihf-ld.bfd: final link failed: Invalid operation
> Makefile:1207: recipe for target 'u-boot' failed
> make: *** [u-boot] Error 1
>
>
> I used the compiler version is 
> "gcc-linaro-5.3-2016.02-x86_64_arm-linux-gnueabihf"

U-boot has very feasible way to build the source, try buildman.

Set-up:
tools/buildman/README

For build:
./tools/buildman/buildman -k 

for your case:
./tools/buildman/buildman -k Cubieboard

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

[U-Boot] [PATCH] SPI: fixup typo in omap2_spi.c

[郑 祎]

  regs->channel[] is an array of registers in SoC. It is indexed by CS#
  Fixup the typo which will cause the index error when accessing the hardware.

  In the all other code, regs->channel[] is indexed by 'priv->cs', so I think
  it is reasonable to fix that wrongly register accessing.
  
---
 drivers/spi/omap3_spi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/omap3_spi.c b/drivers/spi/omap3_spi.c
index 60e9d6e..2380a0e 100644
--- a/drivers/spi/omap3_spi.c
+++ b/drivers/spi/omap3_spi.c
@@ -416,7 +416,7 @@ static void _omap3_spi_set_wordlen(struct omap3_spi_priv 
*priv)
unsigned int confr;
 
/* McSPI individual channel configuration */
-   confr = readl(>regs->channel[priv->wordlen].chconf);
+   confr = readl(>regs->channel[priv->cs].chconf);
 
/* wordlength */
confr &= ~OMAP3_MCSPI_CHCONF_WL_MASK;
-- 
2.10.2

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

[U-Boot] cubieboard sunxi u-boot help me

[崔超]

Hi ,
I' from China. I am studying u-boot on Cubieboard and I have a problem.
https://github.com/OSer916/u-boot.git .
My code is on the "cubieboard" branch.


When I do "make sunny_defconfig && make CROSS_COMPILE=arm-linux-gnueabihf-", 
the trouble comes out last:


arm-linux-gnueabihf-ld.bfd: BFD (GNU Binutils) 2.25.0 Linaro 2015_10 assertion 
fail 
/home/tcwg-buildslave/workspace/tcwg-make-release/label/tcwg-x86_64-ex40/target/arm-linux-gnueabihf/snapshots/binutils-gdb.git~linaro_binutils-2_25-branch/bfd/elf32-arm.c:7827
arm-linux-gnueabihf-ld.bfd: error: required section '.rel.plt' not found in the 
linker script
arm-linux-gnueabihf-ld.bfd: final link failed: Invalid operation
Makefile:1207: recipe for target 'u-boot' failed
make: *** [u-boot] Error 1


I used the compiler version is 
"gcc-linaro-5.3-2016.02-x86_64_arm-linux-gnueabihf"




Thanks!









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

[U-Boot] [PATCH v4] arm: imx: add i.MX53 Beckhoff CX9020 Embedded PC

[linux-kernel-dev]

From: Patrick Bruenn 

Add CX9020 board based on mx53loco.
Add simplified imx53 base device tree from kernel v4.8-rc8, to reuse
serial_mxc with DTE and prepare for device tree migration of other
functions and imx53 devices.

The CX9020 differs from i.MX53 Quick Start Board by:
- use uart2 instead of uart1
- DVI-D connector instead of VGA
- no audio
- CCAT FPGA connected to emi
- enable rtc

Signed-off-by: Patrick Bruenn 

---
Version 4 should address most of the issues Stefan, Jagan and Simon pointed out.
Missing:
- moving CONFIG_FSL_ESDHC from mx53cx9020.h to defconfig, which would require 
DM_GPIO.
  But as soon as I enable that my imx53 device does not boot up and shows 
nothing on
  uart anymore.
- and because of that DM_GPIO issue I am unable to use DM_LED_GPIO
- I couldn't get DM_VIDEO working, too.
If you have any hint or reference on how to get that running on imx53, please 
let
me know and I will improve that.

Changes in v4:
- move TARGET_MX53CX9020 from arch/arm/Kconfig to arch/arm/cpu/armv7/mx5/Kconfig
- move CONFIG_MX53 to arch/arm/cpu/armv7/mx5/Kconfig
- move CONFIG_MXC_UART to mx53cx9020_defconfig
- move CONFIG_FEC_MXC to mx53cx9020_defconfig
- remove redundant SYS_SOC from board/beckhoff/mx53cx9020/Kconfig
- enable MXC_UART for MX5 devices
- enable FEC_MXC for MX5 devices
- group ethernet related configs in mx53cx9020.h
- make clear mx53cx9020 was derived from the u-boot version of mx53loco not 
from kernel code
- replace 'loadccat' with 'fpga load'
- add pinctrl-imx5 driver and use device tree for pinmux configuration on cx9020

Changes in v3:
- replace CONFIG_TARGET_MX53CX9020 with CONFIG_MX53 in dts/Makefile
- remove redundant CONFIG_DISPLAY_BOARDINFO from mx53cx9020.h

Changes in v2:
- remove #include  from mx53cx9020.c
- remove obsolete CONFIG_CMD_CCAT from mx53cx9020.h

 arch/arm/cpu/armv7/mx5/Kconfig   |8 +
 arch/arm/dts/Makefile|2 +
 arch/arm/dts/imx53-cx9020.dts|  190 
 arch/arm/dts/imx53-pinfunc.h | 1189 ++
 arch/arm/dts/imx53.dtsi  |  110 +++
 board/beckhoff/mx53cx9020/Kconfig|   12 +
 board/beckhoff/mx53cx9020/MAINTAINERS|6 +
 board/beckhoff/mx53cx9020/Makefile   |9 +
 board/beckhoff/mx53cx9020/imximage.cfg   |   82 ++
 board/beckhoff/mx53cx9020/mx53cx9020.c   |  367 
 board/beckhoff/mx53cx9020/mx53cx9020_video.c |   49 ++
 configs/mx53cx9020_defconfig |   29 +
 drivers/fpga/Kconfig |   20 +
 drivers/net/Kconfig  |2 +-
 drivers/pinctrl/nxp/Kconfig  |   14 +
 drivers/pinctrl/nxp/Makefile |1 +
 drivers/pinctrl/nxp/pinctrl-imx5.c   |   44 +
 drivers/serial/Kconfig   |2 +-
 include/configs/mx53cx9020.h |  202 +
 include/dt-bindings/clock/imx5-clock.h   |  219 +
 20 files changed, 2555 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/dts/imx53-cx9020.dts
 create mode 100644 arch/arm/dts/imx53-pinfunc.h
 create mode 100644 arch/arm/dts/imx53.dtsi
 create mode 100644 board/beckhoff/mx53cx9020/Kconfig
 create mode 100644 board/beckhoff/mx53cx9020/MAINTAINERS
 create mode 100644 board/beckhoff/mx53cx9020/Makefile
 create mode 100644 board/beckhoff/mx53cx9020/imximage.cfg
 create mode 100644 board/beckhoff/mx53cx9020/mx53cx9020.c
 create mode 100644 board/beckhoff/mx53cx9020/mx53cx9020_video.c
 create mode 100644 configs/mx53cx9020_defconfig
 create mode 100644 drivers/pinctrl/nxp/pinctrl-imx5.c
 create mode 100644 include/configs/mx53cx9020.h
 create mode 100644 include/dt-bindings/clock/imx5-clock.h

diff --git a/arch/arm/cpu/armv7/mx5/Kconfig b/arch/arm/cpu/armv7/mx5/Kconfig
index 9f250c6..5fb5513 100644
--- a/arch/arm/cpu/armv7/mx5/Kconfig
+++ b/arch/arm/cpu/armv7/mx5/Kconfig
@@ -18,11 +18,19 @@ config TARGET_USBARMORY
bool "Support USB armory"
select CPU_V7
 
+config TARGET_MX53CX9020
+   bool "Support CX9020"
+   select CPU_V7
+   select MX53
+   select DM
+   select DM_SERIAL
+
 endchoice
 
 config SYS_SOC
default "mx5"
 
+source "board/beckhoff/mx53cx9020/Kconfig"
 source "board/inversepath/usbarmory/Kconfig"
 
 endif
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 61eb852..cd00d53 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -282,6 +282,8 @@ dtb-$(CONFIG_VF610) += vf500-colibri.dtb \
pcm052.dtb \
bk4r1.dtb
 
+dtb-$(CONFIG_MX53) += imx53-cx9020.dtb
+
 dtb-$(CONFIG_MX6) += imx6ull-14x14-evk.dtb \
imx6dl-icore.dtb \
imx6q-icore.dtb
diff --git a/arch/arm/dts/imx53-cx9020.dts b/arch/arm/dts/imx53-cx9020.dts
new file mode 100644
index 000..9610301
--- /dev/null
+++ b/arch/arm/dts/imx53-cx9020.dts
@@ -0,0 +1,190 @@
+/*
+ * Copyright 2016 Beckhoff Automation
+ * Copyright 2011 

[U-Boot] [PATCH 1/2] SECURE_BOOT: Enable chain of trust on LS1012A platform

[Vinitha Pillai]

Define bootscript and its header addresses for QSPI target

Reviewed-by: Ruchika Gupta 
Signed-off-by: Sumit Garg 
Signed-off-by: Vinitha Pillai 
---
This patch depends on the following patch-set:

1. https://patchwork.ozlabs.org/patch/687002/
2. https://patchwork.ozlabs.org/patch/687000/
3. https://patchwork.ozlabs.org/patch/687001/

 arch/arm/include/asm/arch-fsl-layerscape/config.h | 7 +++
 arch/arm/include/asm/fsl_secure_boot.h| 5 +
 2 files changed, 12 insertions(+)

diff --git a/arch/arm/include/asm/arch-fsl-layerscape/config.h 
b/arch/arm/include/asm/arch-fsl-layerscape/config.h
index 11a62e8..34b3d25 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/config.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/config.h
@@ -186,6 +186,13 @@
 
 #define GICD_BASE  0x01401000
 #define GICC_BASE  0x01402000
+#define CONFIG_SYS_FSL_SFP_VER_3_2
+#define CONFIG_SYS_FSL_SEC_MON_BE
+#define CONFIG_SYS_FSL_SEC_BE
+#define CONFIG_SYS_FSL_SFP_BE
+#define CONFIG_SYS_FSL_SRK_LE
+#define CONFIG_KEY_REVOCATION
+#define CONFIG_SYS_FSL_MAX_NUM_OF_SEC   1
 #elif defined(CONFIG_ARCH_LS1046A)
 #define CONFIG_SYS_FMAN_V3
 #define CONFIG_SYS_NUM_FMAN1
diff --git a/arch/arm/include/asm/fsl_secure_boot.h 
b/arch/arm/include/asm/fsl_secure_boot.h
index 08ba589..5ffde4e 100644
--- a/arch/arm/include/asm/fsl_secure_boot.h
+++ b/arch/arm/include/asm/fsl_secure_boot.h
@@ -114,6 +114,9 @@
 #ifdef CONFIG_ARCH_LS1046A
 #define CONFIG_BS_HDR_ADDR_DEVICE  0x4078
 #define CONFIG_BS_ADDR_DEVICE  0x4080
+#elif defined(CONFIG_ARCH_LS1012A)
+#define CONFIG_BS_HDR_ADDR_DEVICE  0x400c
+#define CONFIG_BS_ADDR_DEVICE  0x4006
 #endif
 #define CONFIG_BS_HDR_SIZE 0x2000
 #define CONFIG_BS_SIZE 0x1000
@@ -141,6 +144,8 @@
 #define CONFIG_SYS_LS_PPA_ESBC_ADDR0x600c
 #elif defined(CONFIG_ARCH_LS1046A)
 #define CONFIG_SYS_LS_PPA_ESBC_ADDR 0x4074
+#elif defined(CONFIG_ARCH_LS1012A)
+#define CONFIG_SYS_LS_PPA_ESBC_ADDR0x4048
 #endif
 #else
 #error "No CONFIG_SYS_LS_PPA_FW_IN_xxx defined"
-- 
1.9.1

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

[U-Boot] [PATCH 2/2] LS1012ARDB: Add QSPI Secure Boot target

[Vinitha Pillai]

Add QSPI Secure Boot target to enable chain of trust

Reviewed-by: Ruchika Gupta 
Signed-off-by: Sumit Garg 
Signed-off-by: Vinitha Pillai 
---
This patch depends on the following patch-set:

1. https://patchwork.ozlabs.org/patch/687002/
2. https://patchwork.ozlabs.org/patch/687000/
3. https://patchwork.ozlabs.org/patch/687001/

 board/freescale/ls1012ardb/ls1012ardb.c   |  5 
 configs/ls1012ardb_qspi_SECURE_BOOT_defconfig | 40 +++
 include/configs/ls1012a_common.h  |  2 --
 include/configs/ls1012ardb.h  |  4 +++
 4 files changed, 49 insertions(+), 2 deletions(-)
 create mode 100644 configs/ls1012ardb_qspi_SECURE_BOOT_defconfig

diff --git a/board/freescale/ls1012ardb/ls1012ardb.c 
b/board/freescale/ls1012ardb/ls1012ardb.c
index 778434d..3966152 100644
--- a/board/freescale/ls1012ardb/ls1012ardb.c
+++ b/board/freescale/ls1012ardb/ls1012ardb.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -110,6 +111,10 @@ int board_init(void)
gd->env_addr = (ulong)_environment[0];
 #endif
 
+#ifdef CONFIG_FSL_CAAM
+   sec_init();
+#endif
+
return 0;
 }
 
diff --git a/configs/ls1012ardb_qspi_SECURE_BOOT_defconfig 
b/configs/ls1012ardb_qspi_SECURE_BOOT_defconfig
new file mode 100644
index 000..ebf8838
--- /dev/null
+++ b/configs/ls1012ardb_qspi_SECURE_BOOT_defconfig
@@ -0,0 +1,40 @@
+CONFIG_ARM=y
+CONFIG_TARGET_LS1012ARDB=y
+CONFIG_SYS_EXTRA_OPTIONS="QSPI_BOOT, SECURE_BOOT"
+# CONFIG_CMD_IMLS is not set
+CONFIG_SYS_NS16550=y
+CONFIG_DEFAULT_DEVICE_TREE="fsl-ls1012a-rdb"
+CONFIG_OF_CONTROL=y
+CONFIG_DM=y
+CONFIG_SPI_FLASH=y
+CONFIG_DM_SPI=y
+# CONFIG_SYS_MALLOC_F is not set
+CONFIG_FIT=y
+CONFIG_FIT_VERBOSE=y
+CONFIG_OF_BOARD_SETUP=y
+CONFIG_OF_STDOUT_VIA_ALIAS=y
+CONFIG_QSPI_BOOT=y
+CONFIG_BOOTDELAY=10
+CONFIG_HUSH_PARSER=y
+CONFIG_CMD_GREPENV=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_USB=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_CACHE=y
+CONFIG_CMD_EXT2=y
+CONFIG_CMD_FAT=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_NETDEVICES=y
+CONFIG_E1000=y
+CONFIG_FSL_DSPI=y
+CONFIG_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_USB_STORAGE=y
+CONFIG_RSA=y
diff --git a/include/configs/ls1012a_common.h b/include/configs/ls1012a_common.h
index 80603c9..ef28480 100644
--- a/include/configs/ls1012a_common.h
+++ b/include/configs/ls1012a_common.h
@@ -128,6 +128,4 @@
 #define CONFIG_PANIC_HANG
 #define CONFIG_SYS_BOOTM_LEN   (64 << 20)  /* Increase max gunzip size */
 
-#include 
-
 #endif /* __LS1012A_COMMON_H */
diff --git a/include/configs/ls1012ardb.h b/include/configs/ls1012ardb.h
index 15410dd..909c26b 100644
--- a/include/configs/ls1012ardb.h
+++ b/include/configs/ls1012ardb.h
@@ -95,4 +95,8 @@
 #define CONFIG_SYS_MEMTEST_START   0x8000
 #define CONFIG_SYS_MEMTEST_END 0x9fff
 
+#define CONFIG_FSL_CAAM/* Enable CAAM */
+
+#include 
+
 #endif /* __LS1012ARDB_H__ */
-- 
1.9.1

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

Re: [U-Boot] With u-boot vertion u-boot-d8bdfc8 compile error

[李东升]

Dear  sir :
before make , I have do something as below :
1.   export CROSS_COMPILE=arm-xilinx-linux-gnueabi-
  export PATH=/opt/zynq_gcc/arm-xilinx-linux-gnueabi/bin:$PATH
2.   export ARCH=arm
  export CROSS_COMPILE=arm-xilinx-Linux-gnueabi-

3.   make zynq_zc702_defconfig





At 2016-11-03 18:44:42, "Michal Simek"  wrote:

Hi,



2016-11-02 10:07 GMT+01:00 李东升 <000lidongsh...@163.com>:
Dear  sir or madam :
when i want to generate u-boot file for zynq device , i found it can not be 
compiled ;

the error code are as below :
root@lolo-pc:~/zynq_study/u-boot_file/u-boot-d8bdfc8# make zynq_zc702_defconfig
  HOSTCC  scripts/basic/fixdep
as: unrecognized option '--32'
scripts/Makefile.host:99: recipe for target 'scripts/basic/fixdep' failed
make[1]: *** [scripts/basic/fixdep] Error 1
Makefile:398: recipe for target 'scripts_basic' failed
make: *** [scripts_basic] Error 2


Could you please help me to find out the problem ~


You have to add arm32 toolchain to your patch. If you have vivado you should 
get it.


Then just

export CROSS_COMPILE=arm-xilinx-linux-gnueabi-


and build.


Thanks,

Michal


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

[U-Boot] EHCI timed out on TD - token

[Michael Kasprowicz]

Hi Uboot team,
Is this problem of EHCI timed out on TD - token=0x80008d80 already resolved
?

Following the thread
http://lists.denx.de/pipermail/u-boot/2016-February/246267.html I reduced
the USB_MAX_XFER_BLK even to 64, but still the issue persists.

If its solved can soneone please point me to the solution.
I am seeing this read timeout failure with 2 n 4 GB Usb drives.
Its a no go for our project, please help or advise.

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

Re: [U-Boot] [PATCH v7 1/2] armv8: Support loading 32-bit OS in AArch32 execution state

[york sun]

On 11/04/2016 09:53 AM, Alexander Graf wrote:
>
>
> On 04/11/2016 16:43, york sun wrote:
>> On 11/04/2016 09:32 AM, Ryan Harkin wrote:
>
> Yes, with the attached patch on top of your original 2 patches,
> everything works again.  I tested on FVP Foundation and AEMv8 models
> and Juno R0, R1 and R2.
>
> I don't think it would be good to stack these three patches the way
> they are presented in the upstream tree because it would not be
> bisect-able.  Some re-work or re-ordering would be needed.
>
> Note: I haven't attempted to understand what any of this code is
> doing, I'm just testing it with my standard boot flow to make sure
> nothing is broken for me.

 Ryan,

 I support Alison's patch order for her 32-bit patch sets. This feature
 doesn't exist before her first set. It is functional if you run U-Boot
 at EL3 after the first patch.
>>>
>>> Which I don't do.  I follow the boot flow recommended by ARM and it
>>> doesn't work for that setup, which I don't think is the right thing to
>>> do.
>>>
>>>
 It gets EL2 working after the 2nd set. If
 there is room to clarify in the commit message, please kindly suggest.

>>>
>>> Well, I'm not the maintainer of the tree, but I wouldn't want to have
>>> a tree that wasn't bootable at any point in the patch sequence.
>>> That's generally unacceptable on most projects I work on.  Keeping the
>>> tree bisect-able to prove which commit caused a problem is considered
>>> to be a valuable tool.
>>>
>>
>> Ryan,
>>
>> Thanks for sharing your concern. I support git-bisect. It is valuable,
>> no doubt. Let me try to understand the issue here. Without Alison's
>> patches, everything boots OK. With her first set, does something break?
>
> Yes, with the patches booting 64bit Linux with U-Boot running in EL2
> breaks according to Ryan.
>
>> My understanding is 32-bit OS can boot. If existing 64-bit OS fails,
>> then she needs to fix it.
>
> That's his point :). And I concur.

Thanks for the confirmation.

>
> (btw, you guys really should start thinking about following the ARM
> recommended boot model. It's pretty cumbersome to do everything
> different just for NXP)

If you are referring the trusted firmware, we are following that 
direction. Just not fully up yet on some platform.

It is definitely not our intention to be cumbersome. Please point out 
where it went sideway beside the trusted firmware.

York


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

Re: [U-Boot] [PATCH v7 1/2] armv8: Support loading 32-bit OS in AArch32 execution state

[york sun]

On 11/04/2016 10:12 AM, Alexander Graf wrote:
>
>
> On 04/11/2016 17:08, york sun wrote:
>> On 11/04/2016 09:53 AM, Alexander Graf wrote:
>>>
>>>
>>> On 04/11/2016 16:43, york sun wrote:
 On 11/04/2016 09:32 AM, Ryan Harkin wrote:
>>>
>>> Yes, with the attached patch on top of your original 2 patches,
>>> everything works again.  I tested on FVP Foundation and AEMv8 models
>>> and Juno R0, R1 and R2.
>>>
>>> I don't think it would be good to stack these three patches the way
>>> they are presented in the upstream tree because it would not be
>>> bisect-able.  Some re-work or re-ordering would be needed.
>>>
>>> Note: I haven't attempted to understand what any of this code is
>>> doing, I'm just testing it with my standard boot flow to make sure
>>> nothing is broken for me.
>>
>> Ryan,
>>
>> I support Alison's patch order for her 32-bit patch sets. This feature
>> doesn't exist before her first set. It is functional if you run U-Boot
>> at EL3 after the first patch.
>
> Which I don't do.  I follow the boot flow recommended by ARM and it
> doesn't work for that setup, which I don't think is the right thing to
> do.
>
>
>> It gets EL2 working after the 2nd set. If
>> there is room to clarify in the commit message, please kindly suggest.
>>
>
> Well, I'm not the maintainer of the tree, but I wouldn't want to have
> a tree that wasn't bootable at any point in the patch sequence.
> That's generally unacceptable on most projects I work on.  Keeping the
> tree bisect-able to prove which commit caused a problem is considered
> to be a valuable tool.
>

 Ryan,

 Thanks for sharing your concern. I support git-bisect. It is valuable,
 no doubt. Let me try to understand the issue here. Without Alison's
 patches, everything boots OK. With her first set, does something break?
>>>
>>> Yes, with the patches booting 64bit Linux with U-Boot running in EL2
>>> breaks according to Ryan.
>>>
 My understanding is 32-bit OS can boot. If existing 64-bit OS fails,
 then she needs to fix it.
>>>
>>> That's his point :). And I concur.
>>
>> Thanks for the confirmation.
>>
>>>
>>> (btw, you guys really should start thinking about following the ARM
>>> recommended boot model. It's pretty cumbersome to do everything
>>> different just for NXP)
>>
>> If you are referring the trusted firmware, we are following that
>> direction. Just not fully up yet on some platform.
>>
>> It is definitely not our intention to be cumbersome. Please point out
>> where it went sideway beside the trusted firmware.
>
> Basically it boils down to the fact that you are the only platform that
> runs U-Boot in EL3 :).
>
> If you want to keep the memory initialization inside of U-Boot, I think
> that's great. But you could either split that into SPL/EL2 or degrade
> yourself into EL2 as soon as possible by calling into an EL3 firmware.
> Whether you build that firmware as part of U-Boot (the stock one could
> be very trivial) or externally is not really too much of a problem.
>
> Things like Alison's patches could then do a simple PSCI call into said
> EL3 firmware to call into 32bit code in EL2 for example.
>

Basically I agree with you. U-Boot will run at EL2 as soon as we have 
the trusted firmware in place.

York

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

Re: [U-Boot] [PATCH v7 1/2] armv8: Support loading 32-bit OS in AArch32 execution state

[york sun]

On 11/04/2016 09:32 AM, Ryan Harkin wrote:
>>>
>>> Yes, with the attached patch on top of your original 2 patches,
>>> everything works again.  I tested on FVP Foundation and AEMv8 models
>>> and Juno R0, R1 and R2.
>>>
>>> I don't think it would be good to stack these three patches the way
>>> they are presented in the upstream tree because it would not be
>>> bisect-able.  Some re-work or re-ordering would be needed.
>>>
>>> Note: I haven't attempted to understand what any of this code is
>>> doing, I'm just testing it with my standard boot flow to make sure
>>> nothing is broken for me.
>>
>> Ryan,
>>
>> I support Alison's patch order for her 32-bit patch sets. This feature
>> doesn't exist before her first set. It is functional if you run U-Boot
>> at EL3 after the first patch.
>
> Which I don't do.  I follow the boot flow recommended by ARM and it
> doesn't work for that setup, which I don't think is the right thing to
> do.
>
>
>> It gets EL2 working after the 2nd set. If
>> there is room to clarify in the commit message, please kindly suggest.
>>
>
> Well, I'm not the maintainer of the tree, but I wouldn't want to have
> a tree that wasn't bootable at any point in the patch sequence.
> That's generally unacceptable on most projects I work on.  Keeping the
> tree bisect-able to prove which commit caused a problem is considered
> to be a valuable tool.
>

Ryan,

Thanks for sharing your concern. I support git-bisect. It is valuable, 
no doubt. Let me try to understand the issue here. Without Alison's 
patches, everything boots OK. With her first set, does something break? 
My understanding is 32-bit OS can boot. If existing 64-bit OS fails, 
then she needs to fix it.

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

Re: [U-Boot] [PATCH v7 1/2] armv8: Support loading 32-bit OS in AArch32 execution state

[Alexander Graf]

On 04/11/2016 17:08, york sun wrote:

On 11/04/2016 09:53 AM, Alexander Graf wrote:



On 04/11/2016 16:43, york sun wrote:

On 11/04/2016 09:32 AM, Ryan Harkin wrote:


Yes, with the attached patch on top of your original 2 patches,
everything works again.  I tested on FVP Foundation and AEMv8 models
and Juno R0, R1 and R2.

I don't think it would be good to stack these three patches the way
they are presented in the upstream tree because it would not be
bisect-able.  Some re-work or re-ordering would be needed.

Note: I haven't attempted to understand what any of this code is
doing, I'm just testing it with my standard boot flow to make sure
nothing is broken for me.


Ryan,

I support Alison's patch order for her 32-bit patch sets. This feature
doesn't exist before her first set. It is functional if you run U-Boot
at EL3 after the first patch.


Which I don't do.  I follow the boot flow recommended by ARM and it
doesn't work for that setup, which I don't think is the right thing to
do.



It gets EL2 working after the 2nd set. If
there is room to clarify in the commit message, please kindly suggest.



Well, I'm not the maintainer of the tree, but I wouldn't want to have
a tree that wasn't bootable at any point in the patch sequence.
That's generally unacceptable on most projects I work on.  Keeping the
tree bisect-able to prove which commit caused a problem is considered
to be a valuable tool.



Ryan,

Thanks for sharing your concern. I support git-bisect. It is valuable,
no doubt. Let me try to understand the issue here. Without Alison's
patches, everything boots OK. With her first set, does something break?


Yes, with the patches booting 64bit Linux with U-Boot running in EL2
breaks according to Ryan.


My understanding is 32-bit OS can boot. If existing 64-bit OS fails,
then she needs to fix it.


That's his point :). And I concur.


Thanks for the confirmation.



(btw, you guys really should start thinking about following the ARM
recommended boot model. It's pretty cumbersome to do everything
different just for NXP)


If you are referring the trusted firmware, we are following that
direction. Just not fully up yet on some platform.

It is definitely not our intention to be cumbersome. Please point out
where it went sideway beside the trusted firmware.


Basically it boils down to the fact that you are the only platform that 
runs U-Boot in EL3 :).


If you want to keep the memory initialization inside of U-Boot, I think 
that's great. But you could either split that into SPL/EL2 or degrade 
yourself into EL2 as soon as possible by calling into an EL3 firmware. 
Whether you build that firmware as part of U-Boot (the stock one could 
be very trivial) or externally is not really too much of a problem.


Things like Alison's patches could then do a simple PSCI call into said 
EL3 firmware to call into 32bit code in EL2 for example.



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

Re: [U-Boot] [PATCH v7 1/2] armv8: Support loading 32-bit OS in AArch32 execution state

[Ryan Harkin]

On 4 November 2016 at 15:53, Alexander Graf  wrote:
>
>
> On 04/11/2016 16:43, york sun wrote:
>>
>> On 11/04/2016 09:32 AM, Ryan Harkin wrote:
>
>
> Yes, with the attached patch on top of your original 2 patches,
> everything works again.  I tested on FVP Foundation and AEMv8 models
> and Juno R0, R1 and R2.
>
> I don't think it would be good to stack these three patches the way
> they are presented in the upstream tree because it would not be
> bisect-able.  Some re-work or re-ordering would be needed.
>
> Note: I haven't attempted to understand what any of this code is
> doing, I'm just testing it with my standard boot flow to make sure
> nothing is broken for me.


 Ryan,

 I support Alison's patch order for her 32-bit patch sets. This feature
 doesn't exist before her first set. It is functional if you run U-Boot
 at EL3 after the first patch.
>>>
>>>
>>> Which I don't do.  I follow the boot flow recommended by ARM and it
>>> doesn't work for that setup, which I don't think is the right thing to
>>> do.
>>>
>>>
 It gets EL2 working after the 2nd set. If
 there is room to clarify in the commit message, please kindly suggest.

>>>
>>> Well, I'm not the maintainer of the tree, but I wouldn't want to have
>>> a tree that wasn't bootable at any point in the patch sequence.
>>> That's generally unacceptable on most projects I work on.  Keeping the
>>> tree bisect-able to prove which commit caused a problem is considered
>>> to be a valuable tool.
>>>
>>
>> Ryan,
>>
>> Thanks for sharing your concern. I support git-bisect. It is valuable,
>> no doubt. Let me try to understand the issue here. Without Alison's
>> patches, everything boots OK. With her first set, does something break?
>
>
> Yes, with the patches booting 64bit Linux with U-Boot running in EL2 breaks
> according to Ryan.
>
>> My understanding is 32-bit OS can boot. If existing 64-bit OS fails,
>> then she needs to fix it.
>
>
> That's his point :). And I concur.
>

Correct.  Thanks Alex for clarifying what I'm trying to say :)


> (btw, you guys really should start thinking about following the ARM
> recommended boot model. It's pretty cumbersome to do everything different
> just for NXP)
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v7 1/2] armv8: Support loading 32-bit OS in AArch32 execution state

[Alexander Graf]

On 04/11/2016 16:43, york sun wrote:

On 11/04/2016 09:32 AM, Ryan Harkin wrote:


Yes, with the attached patch on top of your original 2 patches,
everything works again.  I tested on FVP Foundation and AEMv8 models
and Juno R0, R1 and R2.

I don't think it would be good to stack these three patches the way
they are presented in the upstream tree because it would not be
bisect-able.  Some re-work or re-ordering would be needed.

Note: I haven't attempted to understand what any of this code is
doing, I'm just testing it with my standard boot flow to make sure
nothing is broken for me.


Ryan,

I support Alison's patch order for her 32-bit patch sets. This feature
doesn't exist before her first set. It is functional if you run U-Boot
at EL3 after the first patch.


Which I don't do.  I follow the boot flow recommended by ARM and it
doesn't work for that setup, which I don't think is the right thing to
do.



It gets EL2 working after the 2nd set. If
there is room to clarify in the commit message, please kindly suggest.



Well, I'm not the maintainer of the tree, but I wouldn't want to have
a tree that wasn't bootable at any point in the patch sequence.
That's generally unacceptable on most projects I work on.  Keeping the
tree bisect-able to prove which commit caused a problem is considered
to be a valuable tool.



Ryan,

Thanks for sharing your concern. I support git-bisect. It is valuable,
no doubt. Let me try to understand the issue here. Without Alison's
patches, everything boots OK. With her first set, does something break?


Yes, with the patches booting 64bit Linux with U-Boot running in EL2 
breaks according to Ryan.



My understanding is 32-bit OS can boot. If existing 64-bit OS fails,
then she needs to fix it.


That's his point :). And I concur.

(btw, you guys really should start thinking about following the ARM 
recommended boot model. It's pretty cumbersome to do everything 
different just for NXP)


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

Re: [U-Boot] [PATCH v7 1/2] armv8: Support loading 32-bit OS in AArch32 execution state

[Alison Wang]

> On 4 November 2016 at 02:26, Alison Wang  wrote:
> > York,
> >
> >
> >
> > No, he don’t have my 32-bit kernel image. I am not
> > sure he is using 32-bit kernel or 64-bit kernel.
> >
> >
> >
> > Ryan,
> >
> >
> >
> > I am not familiar with the boards you tested,
> 
> The FVP Foundation model is free to use from ARM.  The entire software
> stack I'm using is available via ARM's portal:
> 
> https://community.arm.com/groups/arm-development-platforms
> 
> 
> > so I have some
> > questions, please help to work with me to find the root cause.
> >
> >
> >
> > 1.   Are you loading 32-bit kernel or 64-bit kernel?
> >
> 
> I'm loading the "standard" 64-bit kernel.  I was using a kernel based
> off 4.8:
> 
> https://git.linaro.org/landing-teams/working/arm/kernel-
> release.git/log/?h=latest-armlt-20161001
> 
> > 2.   Is CONFIG_ARMV8_SWITCH_TO_EL1 defined on these boards?
> >
> 
> I guess it is for the FVP models, if I grep for it, it's in my
> configs' .h file:
> 
> include/configs/vexpress_aemv8a.h:15:#define CONFIG_ARMV8_SWITCH_TO_EL1
> 
> ---
> #ifdef CONFIG_TARGET_VEXPRESS64_BASE_FVP #ifndef CONFIG_SEMIHOSTING
> #error CONFIG_TARGET_VEXPRESS64_BASE_FVP requires CONFIG_SEMIHOSTING
> #endif #define CONFIG_ARMV8_SWITCH_TO_EL1 #endif
> ---
> 
> But it isn't in my Juno config.
> 
> 
> > 3.   Are you using some secure firmware on these boards? In
> detail, I
> > want to know which EL is running on these boards when calling
> > armv8_switch_to_el2 in arch/arm/lib/bootm.c. If it is already running
> > in EL2 when calling armv8_swith_to_el2, the attached patch with PSCI
> > enabled is needed.
> >
> 
> I'm using what ARM consider the "standard" boot flow.  I'm using ARM
> Trusted Firmware to boot u-boot which in turn boots an arm64 kernel.
> 
> I'd expect my setup to still work after you've added patches to allow
> an aarch32 kernel to be booted, but I guess you're changing the boot
> path for non-aarch32 kernels also.
[Alison Wang] Of course, although I add these patches to support aarch32
kernel, I should make sure aarch64 kernel work too.

If you are using ARM Trusted Firmware to boot u-boot, I want to know what
EL is running for your U-Boot. If it is running in EL2 or EL1, please add
the attached patch to test again.

Thanks.
> 
> Regards,
> Ryan.
> 
> >
> >
> >
> >
> > Best Regards,
> >
> > Alison Wang
> >
> >
> >
> > From: york sun
> > Sent: Friday, November 04, 2016 10:04 AM
> > To: ryan.har...@linaro.org
> > Cc: Wang Huan ; ag...@suse.de; Scott Wood
> > ; Stuart Yoder ; Leo Li
> > ; feng...@phytium.com.cn; mon...@monstr.eu;
> > thomas...@samsung.com; mk7.k...@samsung.com; u-boot@lists.denx.de;
> > Jason Jin ; Alison Wang 
> >
> >
> > Subject: Re: [PATCH v7 1/2] armv8: Support loading 32-bit OS in
> > AArch32 execution state
> >
> >
> >
> > Alison,
> >
> > Does Ryan have your 32-bit kernel image? I think kernel 32-bit
> doesn't
> > support spin table. Please work with Ryan if your PSCI patch is
> > required for the test.
> >
> > York
> >
> >
> >
> >  Original Message 
> > From: Ryan Harkin 
> > Sent: Thursday, November 3, 2016 12:17 PM
> > To: york sun 
> > Subject: Re: [PATCH v7 1/2] armv8: Support loading 32-bit OS in
> > AArch32 execution state
> > CC: Alison Wang ,ag...@suse.de,Scott Wood
> > ,Stuart Yoder ,Leo Li
> >
> ,feng...@phytium.com.cn,mon...@monstr.eu,thomas.ab
> > @samsung.com,mk7.k...@samsung.com,u-boot@lists.denx.de,Jason
> > Jin ,Alison Wang 
> >
> > Hi York/Alison,
> >
> > Sorry for not having had time to look at this earlier.
> >
> >
> > On 26 October 2016 at 17:54, york sun  wrote:
> >> On 10/07/2016 11:56 PM, Alison Wang wrote:
> >>> To support loading a 32-bit OS, the execution state will change
> from
> >>> AArch64 to AArch32 when jumping to kernel.
> >>>
> >>> The architecture information will be got through checking FIT image,
> >>> then U-Boot will load 32-bit OS or 64-bit OS automatically.
> >>>
> >>> Signed-off-by: Ebony Zhu 
> >>> Signed-off-by: Alison Wang 
> >>> Signed-off-by: Chenhui Zhao 
> >>> ---
> >>> Changes in v7:
> >>> - Move the call for armv8_switch_to_el2_m into this patch.
> >>>
> >>
> >> Reviewers,
> >>
> >> May I have your comment please? I intend to merge this set when the
> >> merge window opens.
> >>
> >
> > I've just tested these two patches on ARM's FVP Foundation and AEMv8
> > models and ARM's Juno board.
> >
> > In all cases, with this patchset, the kernel fails to start.  I see a
> > continuous reboot, where the 

Re: [U-Boot] [PATCH v7 1/2] armv8: Support loading 32-bit OS in AArch32 execution state

[york sun]

On 11/04/2016 05:34 AM, Ryan Harkin wrote:
> On 4 November 2016 at 09:20, Alison Wang  wrote:
>>> On 4 November 2016 at 02:26, Alison Wang  wrote:
 York,



 No, he don’t have my 32-bit kernel image. I am not
 sure he is using 32-bit kernel or 64-bit kernel.



 Ryan,



 I am not familiar with the boards you tested,
>>>
>>> The FVP Foundation model is free to use from ARM.  The entire software
>>> stack I'm using is available via ARM's portal:
>>>
>>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcommunity.arm.com%2Fgroups%2Farm-development-platforms=01%7C01%7Cyork.sun%40nxp.com%7C2327a62e481a449f1e7608d404a6794c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0=sr1vyQ38lglMJPIGE1i2HaNTxJqsiPgqJtlZJpOvfHc%3D=0
>>>
>>>
 so I have some
 questions, please help to work with me to find the root cause.



 1.   Are you loading 32-bit kernel or 64-bit kernel?

>>>
>>> I'm loading the "standard" 64-bit kernel.  I was using a kernel based
>>> off 4.8:
>>>
>>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.linaro.org%2Flanding-teams%2Fworking%2Farm%2Fkernel-=01%7C01%7Cyork.sun%40nxp.com%7C2327a62e481a449f1e7608d404a6794c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0=N9sN8rBtRtib8gBCICvuH2EmwOswW203ERcRtA3FiFU%3D=0
>>> release.git/log/?h=latest-armlt-20161001
>>>
 2.   Is CONFIG_ARMV8_SWITCH_TO_EL1 defined on these boards?

>>>
>>> I guess it is for the FVP models, if I grep for it, it's in my
>>> configs' .h file:
>>>
>>> include/configs/vexpress_aemv8a.h:15:#define CONFIG_ARMV8_SWITCH_TO_EL1
>>>
>>> ---
>>> #ifdef CONFIG_TARGET_VEXPRESS64_BASE_FVP #ifndef CONFIG_SEMIHOSTING
>>> #error CONFIG_TARGET_VEXPRESS64_BASE_FVP requires CONFIG_SEMIHOSTING
>>> #endif #define CONFIG_ARMV8_SWITCH_TO_EL1 #endif
>>> ---
>>>
>>> But it isn't in my Juno config.
>>>
>>>
 3.   Are you using some secure firmware on these boards? In
>>> detail, I
 want to know which EL is running on these boards when calling
 armv8_switch_to_el2 in arch/arm/lib/bootm.c. If it is already running
 in EL2 when calling armv8_swith_to_el2, the attached patch with PSCI
 enabled is needed.

>>>
>>> I'm using what ARM consider the "standard" boot flow.  I'm using ARM
>>> Trusted Firmware to boot u-boot which in turn boots an arm64 kernel.
>>>
>>> I'd expect my setup to still work after you've added patches to allow
>>> an aarch32 kernel to be booted, but I guess you're changing the boot
>>> path for non-aarch32 kernels also.
>> [Alison Wang] Of course, although I add these patches to support aarch32
>> kernel, I should make sure aarch64 kernel work too.
>>
>> If you are using ARM Trusted Firmware to boot u-boot, I want to know what
>> EL is running for your U-Boot.
>
> I guess I'm running U-Boot at EL2.  U-Boot is BL33 and the ARM-TF docs say:
>
> -
> BL33 (Non-trusted Firmware) execution
>
> EL3 Runtime Software initializes the EL2 or EL1 processor context for
> normal- world cold boot, ensuring that no secure state information
> finds its way into the non-secure execution state. EL3 Runtime
> Software uses the entrypoint information provided by BL2 to jump to
> the Non-trusted firmware image (BL33) at the highest available
> Exception Level (EL2 if available, otherwise EL1).
> -
>
>
>> If it is running in EL2 or EL1, please add
>> the attached patch to test again.
>
> Yes, with the attached patch on top of your original 2 patches,
> everything works again.  I tested on FVP Foundation and AEMv8 models
> and Juno R0, R1 and R2.
>
> I don't think it would be good to stack these three patches the way
> they are presented in the upstream tree because it would not be
> bisect-able.  Some re-work or re-ordering would be needed.
>
> Note: I haven't attempted to understand what any of this code is
> doing, I'm just testing it with my standard boot flow to make sure
> nothing is broken for me.

Ryan,

I support Alison's patch order for her 32-bit patch sets. This feature 
doesn't exist before her first set. It is functional if you run U-Boot 
at EL3 after the first patch. It gets EL2 working after the 2nd set. If 
there is room to clarify in the commit message, please kindly suggest.

York


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

Re: [U-Boot] [PATCH v7 1/2] armv8: Support loading 32-bit OS in AArch32 execution state

[Ryan Harkin]

On 4 November 2016 at 15:08, york sun  wrote:
> On 11/04/2016 05:34 AM, Ryan Harkin wrote:
>> On 4 November 2016 at 09:20, Alison Wang  wrote:
 On 4 November 2016 at 02:26, Alison Wang  wrote:
> York,
>
>
>
> No, he don’t have my 32-bit kernel image. I am not
> sure he is using 32-bit kernel or 64-bit kernel.
>
>
>
> Ryan,
>
>
>
> I am not familiar with the boards you tested,

 The FVP Foundation model is free to use from ARM.  The entire software
 stack I'm using is available via ARM's portal:

 https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcommunity.arm.com%2Fgroups%2Farm-development-platforms=01%7C01%7Cyork.sun%40nxp.com%7C2327a62e481a449f1e7608d404a6794c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0=sr1vyQ38lglMJPIGE1i2HaNTxJqsiPgqJtlZJpOvfHc%3D=0


> so I have some
> questions, please help to work with me to find the root cause.
>
>
>
> 1.   Are you loading 32-bit kernel or 64-bit kernel?
>

 I'm loading the "standard" 64-bit kernel.  I was using a kernel based
 off 4.8:

 https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.linaro.org%2Flanding-teams%2Fworking%2Farm%2Fkernel-=01%7C01%7Cyork.sun%40nxp.com%7C2327a62e481a449f1e7608d404a6794c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0=N9sN8rBtRtib8gBCICvuH2EmwOswW203ERcRtA3FiFU%3D=0
 release.git/log/?h=latest-armlt-20161001

> 2.   Is CONFIG_ARMV8_SWITCH_TO_EL1 defined on these boards?
>

 I guess it is for the FVP models, if I grep for it, it's in my
 configs' .h file:

 include/configs/vexpress_aemv8a.h:15:#define CONFIG_ARMV8_SWITCH_TO_EL1

 ---
 #ifdef CONFIG_TARGET_VEXPRESS64_BASE_FVP #ifndef CONFIG_SEMIHOSTING
 #error CONFIG_TARGET_VEXPRESS64_BASE_FVP requires CONFIG_SEMIHOSTING
 #endif #define CONFIG_ARMV8_SWITCH_TO_EL1 #endif
 ---

 But it isn't in my Juno config.


> 3.   Are you using some secure firmware on these boards? In
 detail, I
> want to know which EL is running on these boards when calling
> armv8_switch_to_el2 in arch/arm/lib/bootm.c. If it is already running
> in EL2 when calling armv8_swith_to_el2, the attached patch with PSCI
> enabled is needed.
>

 I'm using what ARM consider the "standard" boot flow.  I'm using ARM
 Trusted Firmware to boot u-boot which in turn boots an arm64 kernel.

 I'd expect my setup to still work after you've added patches to allow
 an aarch32 kernel to be booted, but I guess you're changing the boot
 path for non-aarch32 kernels also.
>>> [Alison Wang] Of course, although I add these patches to support aarch32
>>> kernel, I should make sure aarch64 kernel work too.
>>>
>>> If you are using ARM Trusted Firmware to boot u-boot, I want to know what
>>> EL is running for your U-Boot.
>>
>> I guess I'm running U-Boot at EL2.  U-Boot is BL33 and the ARM-TF docs say:
>>
>> -
>> BL33 (Non-trusted Firmware) execution
>>
>> EL3 Runtime Software initializes the EL2 or EL1 processor context for
>> normal- world cold boot, ensuring that no secure state information
>> finds its way into the non-secure execution state. EL3 Runtime
>> Software uses the entrypoint information provided by BL2 to jump to
>> the Non-trusted firmware image (BL33) at the highest available
>> Exception Level (EL2 if available, otherwise EL1).
>> -
>>
>>
>>> If it is running in EL2 or EL1, please add
>>> the attached patch to test again.
>>
>> Yes, with the attached patch on top of your original 2 patches,
>> everything works again.  I tested on FVP Foundation and AEMv8 models
>> and Juno R0, R1 and R2.
>>
>> I don't think it would be good to stack these three patches the way
>> they are presented in the upstream tree because it would not be
>> bisect-able.  Some re-work or re-ordering would be needed.
>>
>> Note: I haven't attempted to understand what any of this code is
>> doing, I'm just testing it with my standard boot flow to make sure
>> nothing is broken for me.
>
> Ryan,
>
> I support Alison's patch order for her 32-bit patch sets. This feature
> doesn't exist before her first set. It is functional if you run U-Boot
> at EL3 after the first patch.

Which I don't do.  I follow the boot flow recommended by ARM and it
doesn't work for that setup, which I don't think is the right thing to
do.


> It gets EL2 working after the 2nd set. If
> there is room to clarify in the commit message, please kindly suggest.
>

Well, I'm not the maintainer of the tree, but I wouldn't want to have
a tree that wasn't bootable at any point in the patch 

Re: [U-Boot] [PATCH 1/3] fsl/ddr: Revise erratum a009942 and clean related erratum

[york sun]

On 11/04/2016 04:18 AM, Shengzhou Liu wrote:
> - add additional function erratum_a009942_check_cpo to check if the
>   board needs tuning CPO calibration for optimal setting.
> - move ERRATUM_A009942(with revision to check cpo_sample option) from
>   fsl_ddr_gen4.c to ctrl_regs.c for reuse on all DDR4/DDR3 parts.
> - move ERRATUM_A008378 from fsl_ddr_gen4.c to ctrl_regs.c
> - remove obsolete ERRATUM_A004934 which is replaced with ERRATUM_A009942.

Shengzhou,

There is an issue for moving the erratum 9942 workaround to ctrl_regs.c. 
This workaround requires setting debug register in a read-modify-write 
fashion. You won't be able to read the debug register in ctrl_regs.c file.

York

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

[U-Boot] [PATCH 1/4] mmc: Retry the switch command

[Maxime Ripard]

Some eMMC will fail at the first switch, but would succeed in a subsequent
one.

Make sure we try several times to cover those cases. The number of retries
(and the behaviour) is currently what is being used in Linux.

Signed-off-by: Maxime Ripard 
---
 drivers/mmc/mmc.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 4380c7c195a6..d6b7e4f510c9 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -494,6 +494,7 @@ int mmc_switch(struct mmc *mmc, u8 set, u8 index, u8 value)
 {
struct mmc_cmd cmd;
int timeout = 1000;
+   int retries = 3;
int ret;
 
cmd.cmdidx = MMC_CMD_SWITCH;
@@ -502,11 +503,17 @@ int mmc_switch(struct mmc *mmc, u8 set, u8 index, u8 
value)
 (index << 16) |
 (value << 8);
 
-   ret = mmc_send_cmd(mmc, , NULL);
+   while (retries > 0) {
+   ret = mmc_send_cmd(mmc, , NULL);
 
-   /* Waiting for the ready status */
-   if (!ret)
-   ret = mmc_send_status(mmc, timeout);
+   /* Waiting for the ready status */
+   if (!ret) {
+   ret = mmc_send_status(mmc, timeout);
+   return ret;
+   }
+
+   retries--;
+   }
 
return ret;
 
-- 
git-series 0.8.11
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 2/4] mmc: sunxi: Enable 8bits bus width for sun8i

[Maxime Ripard]

The sun8i SoCs also have a 8 bits capable MMC2 controller. Enable the
support for those too.

Signed-off-by: Maxime Ripard 
---
 drivers/mmc/sunxi_mmc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index 6953accce123..b8716c93cb06 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -463,7 +463,7 @@ struct mmc *sunxi_mmc_init(int sdc_no)
 
cfg->voltages = MMC_VDD_32_33 | MMC_VDD_33_34;
cfg->host_caps = MMC_MODE_4BIT;
-#ifdef CONFIG_MACH_SUN50I
+#if defined(CONFIG_MACH_SUN50I) || defined(CONFIG_MACH_SUN8I)
if (sdc_no == 2)
cfg->host_caps = MMC_MODE_8BIT;
 #endif
-- 
git-series 0.8.11
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 4/4] sunxi: sina33: Enable the LCD

[Maxime Ripard]

The SinA33 comes with an optional 7" display. Enable it in the
configuration.

Signed-off-by: Maxime Ripard 
---
 configs/Sinlinx_SinA33_defconfig | 4 
 1 file changed, 4 insertions(+), 0 deletions(-)

diff --git a/configs/Sinlinx_SinA33_defconfig b/configs/Sinlinx_SinA33_defconfig
index f4719db2d501..26b119a9b92f 100644
--- a/configs/Sinlinx_SinA33_defconfig
+++ b/configs/Sinlinx_SinA33_defconfig
@@ -6,6 +6,10 @@ CONFIG_DRAM_ZQ=15291
 CONFIG_MMC0_CD_PIN="PB4"
 CONFIG_MMC_SUNXI_SLOT_EXTRA=2
 CONFIG_USB0_ID_DET="PH8"
+CONFIG_VIDEO_LCD_MODE="x:1024,y:600,depth:18,pclk_khz:66000,le:90,ri:160,up:3,lo:127,hs:70,vs:20,sync:3,vmode:0"
+CONFIG_VIDEO_LCD_DCLK_PHASE=0
+CONFIG_VIDEO_LCD_BL_EN="PH6"
+CONFIG_VIDEO_LCD_BL_PWM="PH0"
 CONFIG_DEFAULT_DEVICE_TREE="sun8i-a33-sinlinx-sina33"
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
 CONFIG_SPL=y
-- 
git-series 0.8.11
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 3/4] sunxi: sina33: Enable the eMMC

[Maxime Ripard]

The SinA33 has an 4GB Toshiba eMMC connected to the MMC2 controller.
Enable it.

Signed-off-by: Maxime Ripard 
---
 configs/Sinlinx_SinA33_defconfig | 1 +
 1 file changed, 1 insertion(+), 0 deletions(-)

diff --git a/configs/Sinlinx_SinA33_defconfig b/configs/Sinlinx_SinA33_defconfig
index 2a5f985dd303..f4719db2d501 100644
--- a/configs/Sinlinx_SinA33_defconfig
+++ b/configs/Sinlinx_SinA33_defconfig
@@ -4,6 +4,7 @@ CONFIG_MACH_SUN8I_A33=y
 CONFIG_DRAM_CLK=552
 CONFIG_DRAM_ZQ=15291
 CONFIG_MMC0_CD_PIN="PB4"
+CONFIG_MMC_SUNXI_SLOT_EXTRA=2
 CONFIG_USB0_ID_DET="PH8"
 CONFIG_DEFAULT_DEVICE_TREE="sun8i-a33-sinlinx-sina33"
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
-- 
git-series 0.8.11
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 0/4] sunxi: Improve the SinA33 support

[Maxime Ripard]

Hi all,

The SinA33 board is based on an Allwinner A33 SoC and features an external
(and optional) LCD display and a 4GB Toshida eMMC.

This eMMC wasn't recognized by default in U-boot because it was failing to
switch in high speed mode at the first attempt.

The first three patches are to enable the eMMC, the last one to enable the
LCD.

Let me know what you think,
Maxime

Maxime Ripard (4):
  mmc: Retry the switch command
  mmc: sunxi: Enable 8bits bus width for sun8i
  sunxi: sina33: Enable the eMMC
  sunxi: sina33: Enable the LCD

 configs/Sinlinx_SinA33_defconfig |  5 +
 drivers/mmc/mmc.c| 15 +++
 drivers/mmc/sunxi_mmc.c  |  2 +-
 3 files changed, 17 insertions(+), 5 deletions(-)

base-commit: d8bdfc80da39211d95f10d24e79f2e867305f71b
-- 
git-series 0.8.11
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Phil Edworthy]

Whilst at it, move the code to read the "sram-size" property
into the other code that reads properties from the node, rather
than the SF subnode.

Also change the code to use a bool for the bypass arg.

Signed-off-by: Phil Edworthy 

---
v2:
 Change name of DT prop and provide details of what it does.
 Whilst at it, move the code to read the "sram-size" property
 into the other code that reads properties from the node, rather
 than the SF subnode.

 Also changed the code to use a bool for the bypass arg.

 Note: I didn't explicitly state that the prop is optional as all of the props
 listed in that section are optional.
---
 doc/device-tree-bindings/spi/spi-cadence.txt |  2 ++
 drivers/spi/cadence_qspi.c   | 13 +
 drivers/spi/cadence_qspi.h   |  3 ++-
 drivers/spi/cadence_qspi_apb.c   |  8 +++-
 4 files changed, 20 insertions(+), 6 deletions(-)

diff --git a/doc/device-tree-bindings/spi/spi-cadence.txt 
b/doc/device-tree-bindings/spi/spi-cadence.txt
index c1e2233..94c800b 100644
--- a/doc/device-tree-bindings/spi/spi-cadence.txt
+++ b/doc/device-tree-bindings/spi/spi-cadence.txt
@@ -26,3 +26,5 @@ connected flash properties
  select (n_ss_out).
 - tslch-ns : Delay in master reference clocks between setting
  n_ss_out low and first bit transfer
+- sample-edge-rising   : Data outputs from flash memory will be sampled on the
+ rising edge. Default is falling edge.
diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
index 1051afb..16fb18e 100644
--- a/drivers/spi/cadence_qspi.c
+++ b/drivers/spi/cadence_qspi.c
@@ -39,8 +39,10 @@ static int cadence_spi_write_speed(struct udevice *bus, uint 
hz)
 /* Calibration sequence to determine the read data capture delay register */
 static int spi_calibration(struct udevice *bus, uint hz)
 {
+   struct cadence_spi_platdata *plat = bus->platdata;
struct cadence_spi_priv *priv = dev_get_priv(bus);
void *base = priv->regbase;
+   bool edge = plat->sample_edge_rising;
u8 opcode_rdid = 0x9F;
unsigned int idcode = 0, temp = 0;
int err = 0, i, range_lo = -1, range_hi = -1;
@@ -49,7 +51,7 @@ static int spi_calibration(struct udevice *bus, uint hz)
cadence_spi_write_speed(bus, 100);
 
/* configure the read data capture delay register to 0 */
-   cadence_qspi_apb_readdata_capture(base, 1, 0);
+   cadence_qspi_apb_readdata_capture(base, true, edge, 0);
 
/* Enable QSPI */
cadence_qspi_apb_controller_enable(base);
@@ -69,7 +71,7 @@ static int spi_calibration(struct udevice *bus, uint hz)
cadence_qspi_apb_controller_disable(base);
 
/* reconfigure the read data capture delay register */
-   cadence_qspi_apb_readdata_capture(base, 1, i);
+   cadence_qspi_apb_readdata_capture(base, true, edge, i);
 
/* Enable back QSPI */
cadence_qspi_apb_controller_enable(base);
@@ -105,7 +107,8 @@ static int spi_calibration(struct udevice *bus, uint hz)
cadence_qspi_apb_controller_disable(base);
 
/* configure the final value for read data capture delay register */
-   cadence_qspi_apb_readdata_capture(base, 1, (range_hi + range_lo) / 2);
+   cadence_qspi_apb_readdata_capture(base, true, edge,
+   (range_hi + range_lo) / 2);
debug("SF: Read data capture delay calibrated to %i (%i - %i)\n",
  (range_hi + range_lo) / 2, range_lo, range_hi);
 
@@ -298,6 +301,7 @@ static int cadence_spi_ofdata_to_platdata(struct udevice 
*bus)
 
plat->regbase = (void *)data[0];
plat->ahbbase = (void *)data[2];
+   plat->sram_size = fdtdec_get_int(blob, node, "sram-size", 128);
 
/* All other paramters are embedded in the child node */
subnode = fdt_first_subnode(blob, node);
@@ -317,7 +321,8 @@ static int cadence_spi_ofdata_to_platdata(struct udevice 
*bus)
plat->tsd2d_ns = fdtdec_get_int(blob, subnode, "tsd2d-ns", 255);
plat->tchsh_ns = fdtdec_get_int(blob, subnode, "tchsh-ns", 20);
plat->tslch_ns = fdtdec_get_int(blob, subnode, "tslch-ns", 20);
-   plat->sram_size = fdtdec_get_int(blob, node, "sram-size", 128);
+   plat->sample_edge_rising = fdtdec_get_bool(blob, subnode,
+   "sample-edge-rising");
 
debug("%s: regbase=%p ahbbase=%p max-frequency=%d page-size=%d\n",
  __func__, plat->regbase, plat->ahbbase, plat->max_hz,
diff --git a/drivers/spi/cadence_qspi.h b/drivers/spi/cadence_qspi.h
index a849f7b..ad1dbae 100644
--- a/drivers/spi/cadence_qspi.h
+++ b/drivers/spi/cadence_qspi.h
@@ -26,6 +26,7 @@ struct cadence_spi_platdata {
u32 tchsh_ns;
u32 tslch_ns;
u32 sram_size;
+   boolsample_edge_rising;
 };
 
 struct cadence_spi_priv {

[U-Boot] [PATCH] mkimage: Allow including a ramdisk in FIT auto mode

[Tomeu Vizoso]

Adds -i option that allows specifying a ramdisk file to be added to the
FIT image when we are using the automatic FIT mode (no ITS file).

This makes adding Depthcharge support to LAVA much more convenient, as
no additional configuration files need to be kept around in the machine
that dispatches jobs to the boards.

Signed-off-by: Tomeu Vizoso 
Cc: Simon Glass 
Cc: Matt Hart 
Cc: Neil Williams 
---
 doc/mkimage.1 |  4 
 tools/fit_image.c | 33 -
 tools/imagetool.h |  1 +
 tools/mkimage.c   | 10 +++---
 4 files changed, 44 insertions(+), 4 deletions(-)

diff --git a/doc/mkimage.1 b/doc/mkimage.1
index e883f07849a6..3dcdcedcefaf 100644
--- a/doc/mkimage.1
+++ b/doc/mkimage.1
@@ -138,6 +138,10 @@ This can be used to sign images with additional keys after 
initial image
 creation.
 
 .TP
+.BI "\-i [" "ramdisk_file" "]"
+Appends the ramdisk file to the FIT.
+
+.TP
 .BI "\-k [" "key_directory" "]"
 Specifies the directory containing keys to use for signing. This directory
 should contain a private key file .key for use with signing and a
diff --git a/tools/fit_image.c b/tools/fit_image.c
index 10fd6d492937..efd8a97a0b92 100644
--- a/tools/fit_image.c
+++ b/tools/fit_image.c
@@ -85,8 +85,15 @@ static int fit_calc_size(struct image_tool_params *params)
size = imagetool_get_filesize(params, params->datafile);
if (size < 0)
return -1;
-
total_size = size;
+
+   if (params->fit_ramdisk) {
+   size = imagetool_get_filesize(params, params->fit_ramdisk);
+   if (size < 0)
+   return -1;
+   total_size += size;
+   }
+
for (cont = params->content_head; cont; cont = cont->next) {
size = imagetool_get_filesize(params, cont->fname);
if (size < 0)
@@ -233,6 +240,20 @@ static int fit_write_images(struct image_tool_params 
*params, char *fdt)
fdt_end_node(fdt);
}
 
+   /* And a ramdisk file if available */
+   if (params->fit_ramdisk) {
+   fdt_begin_node(fdt, FIT_RAMDISK_PROP "@1");
+
+   fdt_property_string(fdt, "type", FIT_RAMDISK_PROP);
+   fdt_property_string(fdt, "os", 
genimg_get_os_short_name(params->os));
+
+   ret = fdt_property_file(params, fdt, "data", 
params->fit_ramdisk);
+   if (ret)
+   return ret;
+
+   fdt_end_node(fdt);
+   }
+
fdt_end_node(fdt);
 
return 0;
@@ -272,15 +293,25 @@ static void fit_write_configs(struct image_tool_params 
*params, char *fdt)
snprintf(str, sizeof(str), "%s@1", typename);
fdt_property_string(fdt, typename, str);
 
+   if (params->fit_ramdisk)
+   fdt_property_string(fdt, FIT_RAMDISK_PROP,
+   FIT_RAMDISK_PROP "@1");
+
snprintf(str, sizeof(str), FIT_FDT_PROP "@%d", upto);
fdt_property_string(fdt, FIT_FDT_PROP, str);
fdt_end_node(fdt);
}
+
if (!upto) {
fdt_begin_node(fdt, "conf@1");
typename = genimg_get_type_short_name(params->fit_image_type);
snprintf(str, sizeof(str), "%s@1", typename);
fdt_property_string(fdt, typename, str);
+
+   if (params->fit_ramdisk)
+   fdt_property_string(fdt, FIT_RAMDISK_PROP,
+   FIT_RAMDISK_PROP "@1");
+
fdt_end_node(fdt);
}
 
diff --git a/tools/imagetool.h b/tools/imagetool.h
index 6c1a9d376058..15c2a0c0e1c1 100644
--- a/tools/imagetool.h
+++ b/tools/imagetool.h
@@ -70,6 +70,7 @@ struct image_tool_params {
int orig_file_size; /* Original size for file before padding */
bool auto_its;  /* Automatically create the .its file */
int fit_image_type; /* Image type to put into the FIT */
+   char *fit_ramdisk;  /* Ramdisk file to include */
struct content_info *content_head;  /* List of files to include */
struct content_info *content_tail;
bool external_data; /* Store data outside the FIT */
diff --git a/tools/mkimage.c b/tools/mkimage.c
index 0c6dba89a099..49d5d1ed70a7 100644
--- a/tools/mkimage.c
+++ b/tools/mkimage.c
@@ -88,12 +88,13 @@ static void usage(const char *msg)
"  -x ==> set XIP (execute in place)\n",
params.cmdname);
fprintf(stderr,
-   "   %s [-D dtc_options] [-f fit-image.its|-f auto|-F] [-b 
 [-b ]] fit-image\n"
+   "   %s [-D dtc_options] [-f fit-image.its|-f auto|-F] [-b 
 [-b ]] [-i ] fit-image\n"
"file is used with -f auto, it may occur 
multiple times.\n",
params.cmdname);

Re: [U-Boot] [RFC PATCH 01/10] sun6i: Restrict some register initialization to Allwinner A31 SoC

[Chen-Yu Tsai]

On Thu, Nov 3, 2016 at 4:52 PM, Alexander Graf  wrote:
> On 11/03/2016 02:36 AM, Andre Przywara wrote:
>>
>> These days many Allwinner SoCs use clock_sun6i.c, although out of them
>> only the (original sun6i) A31 has a second MBUS clock register.
>> Also setting up the PRCM PLL_CTLR1 register to provide the proper voltage
>> seems to be an A31-only feature as well.
>> So restrict the initialization to this SoC only to avoid writing bogus
>> values to (undefined) registers in other chips.
>>
>> Signed-off-by: Andre Przywara 
>
>
> Reviewed-by: Alexander Graf 
>
> (However I haven't counter-checked with specs)

Reviewed-by: Chen-Yu Tsai 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCHv2 3/3] igep00x0: add Hynix timings

[Ladislav Michl]

Tested on IGEPv2 with Micron MT29F4G16ABBDA3W and
Hynix H27S4G6F2DKA-BM

Signed-off-by: Ladislav Michl 
---
Changes in v2:
 - None

diff --git a/board/isee/igep00x0/igep00x0.c b/board/isee/igep00x0/igep00x0.c
index 71688cc..669f3dd 100644
--- a/board/isee/igep00x0/igep00x0.c
+++ b/board/isee/igep00x0/igep00x0.c
@@ -84,10 +84,22 @@ void get_board_mem_timings(struct board_sdrc_timings 
*timings)
int mfr, id, err = identify_nand_chip(, );
 
timings->mr = MICRON_V_MR_165;
-   if (!err && mfr == NAND_MFR_MICRON) {
-   timings->mcfg = MICRON_V_MCFG_200(256 << 20);
-   timings->ctrla = MICRON_V_ACTIMA_200;
-   timings->ctrlb = MICRON_V_ACTIMB_200;
+   if (!err) {
+   switch (mfr) {
+   case NAND_MFR_HYNIX:
+   timings->mcfg = HYNIX_V_MCFG_200(256 << 20);
+   timings->ctrla = HYNIX_V_ACTIMA_200;
+   timings->ctrlb = HYNIX_V_ACTIMB_200;
+   break;
+   case NAND_MFR_MICRON:
+   timings->mcfg = MICRON_V_MCFG_200(256 << 20);
+   timings->ctrla = MICRON_V_ACTIMA_200;
+   timings->ctrlb = MICRON_V_ACTIMB_200;
+   break;
+   default:
+   /* Should not happen... */
+   break;
+   }
timings->rfr_ctrl = SDP_3430_SDRC_RFR_CTRL_200MHz;
gpmc_cs0_flash = MTD_DEV_TYPE_NAND;
} else {
-- 
2.1.4

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

[U-Boot] [PATCHv2 2/3] igep00x0: consolidate defconfigs

[Ladislav Michl]

Defconfigs should remain the same except CONFIG_SYS_EXTRA_OPTIONS.
Drop NAND specific defconfig as flash type is runtime detected.

Signed-off-by: Ladislav Michl 
---
Changes in v2:
 - fix screwup caused by mismerge
 - update to current git

diff --git a/configs/igep0030_defconfig b/configs/igep0030_defconfig
index 75f731d..edc7520 100644
--- a/configs/igep0030_defconfig
+++ b/configs/igep0030_defconfig
@@ -2,7 +2,8 @@ CONFIG_ARM=y
 CONFIG_OMAP34XX=y
 # CONFIG_SPL_EXT_SUPPORT is not set
 CONFIG_TARGET_OMAP3_IGEP00X0=y
-CONFIG_SYS_EXTRA_OPTIONS="MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND"
+CONFIG_SYS_EXTRA_OPTIONS="MACH_TYPE=MACH_TYPE_IGEP0030"
+CONFIG_BOOTDELAY=3
 CONFIG_SYS_CONSOLE_IS_IN_ENV=y
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 CONFIG_VERSION_VARIABLE=y
@@ -31,5 +32,6 @@ CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_CMD_UBI=y
+CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_SYS_NS16550=y
 CONFIG_OF_LIBFDT=y
diff --git a/configs/igep0030_nand_defconfig b/configs/igep0030_nand_defconfig
deleted file mode 100644
index dda1a7b..000
--- a/configs/igep0030_nand_defconfig
+++ /dev/null
@@ -1,34 +0,0 @@
-CONFIG_ARM=y
-CONFIG_OMAP34XX=y
-# CONFIG_SPL_EXT_SUPPORT is not set
-CONFIG_TARGET_OMAP3_IGEP00X0=y
-CONFIG_SYS_EXTRA_OPTIONS="MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_NAND"
-CONFIG_SYS_CONSOLE_IS_IN_ENV=y
-CONFIG_SYS_CONSOLE_INFO_QUIET=y
-CONFIG_VERSION_VARIABLE=y
-CONFIG_SPL=y
-CONFIG_SPL_MTD_SUPPORT=y
-CONFIG_SPL_ONENAND_SUPPORT=y
-CONFIG_SPL_OS_BOOT=y
-CONFIG_HUSH_PARSER=y
-CONFIG_CMD_BOOTZ=y
-# CONFIG_CMD_IMLS is not set
-CONFIG_CMD_ASKENV=y
-# CONFIG_CMD_FLASH is not set
-CONFIG_CMD_MMC=y
-CONFIG_CMD_SPI=y
-CONFIG_CMD_I2C=y
-CONFIG_CMD_GPIO=y
-# CONFIG_CMD_SETEXPR is not set
-CONFIG_CMD_DHCP=y
-CONFIG_CMD_MII=y
-CONFIG_CMD_PING=y
-CONFIG_CMD_CACHE=y
-CONFIG_CMD_EXT2=y
-CONFIG_CMD_EXT4=y
-CONFIG_CMD_EXT4_WRITE=y
-CONFIG_CMD_FAT=y
-CONFIG_CMD_FS_GENERIC=y
-CONFIG_CMD_UBI=y
-CONFIG_SYS_NS16550=y
-CONFIG_OF_LIBFDT=y
diff --git a/configs/igep0032_defconfig b/configs/igep0032_defconfig
index 1819995..81d05d4 100644
--- a/configs/igep0032_defconfig
+++ b/configs/igep0032_defconfig
@@ -2,7 +2,8 @@ CONFIG_ARM=y
 CONFIG_OMAP34XX=y
 # CONFIG_SPL_EXT_SUPPORT is not set
 CONFIG_TARGET_OMAP3_IGEP00X0=y
-CONFIG_SYS_EXTRA_OPTIONS="MACH_TYPE=MACH_TYPE_IGEP0032,BOOT_ONENAND"
+CONFIG_SYS_EXTRA_OPTIONS="MACH_TYPE=MACH_TYPE_IGEP0032"
+CONFIG_BOOTDELAY=3
 CONFIG_SYS_CONSOLE_IS_IN_ENV=y
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 CONFIG_VERSION_VARIABLE=y
-- 
2.1.4

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

[U-Boot] [PATCHv2 1/3] igep00x0: disable CONFIG_DISPLAY_BOARDINFO

[Ladislav Michl]

As a single U-Boot binary can now run on various board modifications,
drop CONFIG_DISPLAY_BOARDINFO as it prints flash memory information
too early to give us chance to easily detect it. Also saves few bytes
as a bonus.

Signed-off-by: Ladislav Michl 
---
Changes in v2:
  - update to current git (uses Kconfig)

diff --git a/board/isee/igep00x0/igep00x0.c b/board/isee/igep00x0/igep00x0.c
index 808955e..71688cc 100644
--- a/board/isee/igep00x0/igep00x0.c
+++ b/board/isee/igep00x0/igep00x0.c
@@ -27,24 +27,6 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-const omap3_sysinfo sysinfo = {
-   DDR_STACKED,
-#if (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0020)
-   "IGEPv2",
-#endif
-#if (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0030)
-   "IGEP COM MODULE/ELECTRON",
-#endif
-#if (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0032)
-   "IGEP COM PROTON",
-#endif
-#if defined(CONFIG_ENV_IS_IN_ONENAND)
-   "ONENAND",
-#else
-   "NAND",
-#endif
-};
-
 static const struct ns16550_platdata igep_serial = {
.base = OMAP34XX_UART3,
.reg_shift = 2,
diff --git a/configs/igep0020_defconfig b/configs/igep0020_defconfig
index 9c247d7..c25b6b8 100644
--- a/configs/igep0020_defconfig
+++ b/configs/igep0020_defconfig
@@ -7,6 +7,7 @@ CONFIG_BOOTDELAY=3
 CONFIG_SYS_CONSOLE_IS_IN_ENV=y
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 CONFIG_VERSION_VARIABLE=y
+# CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_SPL=y
 CONFIG_SPL_MTD_SUPPORT=y
 CONFIG_SPL_ONENAND_SUPPORT=y
diff --git a/configs/igep0030_defconfig b/configs/igep0030_defconfig
index 1312ddb..75f731d 100644
--- a/configs/igep0030_defconfig
+++ b/configs/igep0030_defconfig
@@ -6,6 +6,7 @@ 
CONFIG_SYS_EXTRA_OPTIONS="MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND"
 CONFIG_SYS_CONSOLE_IS_IN_ENV=y
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 CONFIG_VERSION_VARIABLE=y
+# CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_SPL=y
 CONFIG_SPL_MTD_SUPPORT=y
 CONFIG_SPL_ONENAND_SUPPORT=y
diff --git a/configs/igep0032_defconfig b/configs/igep0032_defconfig
index 37e46b0..1819995 100644
--- a/configs/igep0032_defconfig
+++ b/configs/igep0032_defconfig
@@ -6,6 +6,7 @@ 
CONFIG_SYS_EXTRA_OPTIONS="MACH_TYPE=MACH_TYPE_IGEP0032,BOOT_ONENAND"
 CONFIG_SYS_CONSOLE_IS_IN_ENV=y
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 CONFIG_VERSION_VARIABLE=y
+# CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_SPL=y
 CONFIG_SPL_MTD_SUPPORT=y
 CONFIG_SPL_ONENAND_SUPPORT=y
-- 
2.1.4

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

Re: [U-Boot] [PATCH 1/3] igep00x0: disable CONFIG_DISPLAY_BOARDINFO

[Ladislav Michl]

Hi Enric,

On Tue, Sep 20, 2016 at 05:41:02PM +0200, Enric Balletbo Serra wrote:
[snip]
> I must NACK for now these series, meanwhile I don't find time to look
> at this deeply. I think this will break lots of things. For example,
> will this u-boot boot a non-device tree based kernel without breaking
> things? I don't think so, It's right that non-device tree kernels are
> old but these are still used in lots of IGEP boards and I don't want
> to break this, for now.
> 
> Please give me some time to look at this and think in all the use cases.

Any chance you'll find time to look at this? I'm sending updated patch serie
as a reply to this email. I do not think it breaks anything and I'll provide
fix if you prove me wrong. Please note, that without "igep00x0: add Hynix
timings" patch some boards are unable to boot. My bad, of course, as I hadn't
all board variants on my table at the time writing runtime flash detection
support.

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

Re: [U-Boot] [PATCH v7 1/2] armv8: Support loading 32-bit OS in AArch32 execution state

[Ryan Harkin]

On 4 November 2016 at 09:20, Alison Wang  wrote:
>> On 4 November 2016 at 02:26, Alison Wang  wrote:
>> > York,
>> >
>> >
>> >
>> > No, he don’t have my 32-bit kernel image. I am not
>> > sure he is using 32-bit kernel or 64-bit kernel.
>> >
>> >
>> >
>> > Ryan,
>> >
>> >
>> >
>> > I am not familiar with the boards you tested,
>>
>> The FVP Foundation model is free to use from ARM.  The entire software
>> stack I'm using is available via ARM's portal:
>>
>> https://community.arm.com/groups/arm-development-platforms
>>
>>
>> > so I have some
>> > questions, please help to work with me to find the root cause.
>> >
>> >
>> >
>> > 1.   Are you loading 32-bit kernel or 64-bit kernel?
>> >
>>
>> I'm loading the "standard" 64-bit kernel.  I was using a kernel based
>> off 4.8:
>>
>> https://git.linaro.org/landing-teams/working/arm/kernel-
>> release.git/log/?h=latest-armlt-20161001
>>
>> > 2.   Is CONFIG_ARMV8_SWITCH_TO_EL1 defined on these boards?
>> >
>>
>> I guess it is for the FVP models, if I grep for it, it's in my
>> configs' .h file:
>>
>> include/configs/vexpress_aemv8a.h:15:#define CONFIG_ARMV8_SWITCH_TO_EL1
>>
>> ---
>> #ifdef CONFIG_TARGET_VEXPRESS64_BASE_FVP #ifndef CONFIG_SEMIHOSTING
>> #error CONFIG_TARGET_VEXPRESS64_BASE_FVP requires CONFIG_SEMIHOSTING
>> #endif #define CONFIG_ARMV8_SWITCH_TO_EL1 #endif
>> ---
>>
>> But it isn't in my Juno config.
>>
>>
>> > 3.   Are you using some secure firmware on these boards? In
>> detail, I
>> > want to know which EL is running on these boards when calling
>> > armv8_switch_to_el2 in arch/arm/lib/bootm.c. If it is already running
>> > in EL2 when calling armv8_swith_to_el2, the attached patch with PSCI
>> > enabled is needed.
>> >
>>
>> I'm using what ARM consider the "standard" boot flow.  I'm using ARM
>> Trusted Firmware to boot u-boot which in turn boots an arm64 kernel.
>>
>> I'd expect my setup to still work after you've added patches to allow
>> an aarch32 kernel to be booted, but I guess you're changing the boot
>> path for non-aarch32 kernels also.
> [Alison Wang] Of course, although I add these patches to support aarch32
> kernel, I should make sure aarch64 kernel work too.
>
> If you are using ARM Trusted Firmware to boot u-boot, I want to know what
> EL is running for your U-Boot.

I guess I'm running U-Boot at EL2.  U-Boot is BL33 and the ARM-TF docs say:

-
BL33 (Non-trusted Firmware) execution

EL3 Runtime Software initializes the EL2 or EL1 processor context for
normal- world cold boot, ensuring that no secure state information
finds its way into the non-secure execution state. EL3 Runtime
Software uses the entrypoint information provided by BL2 to jump to
the Non-trusted firmware image (BL33) at the highest available
Exception Level (EL2 if available, otherwise EL1).
-


> If it is running in EL2 or EL1, please add
> the attached patch to test again.

Yes, with the attached patch on top of your original 2 patches,
everything works again.  I tested on FVP Foundation and AEMv8 models
and Juno R0, R1 and R2.

I don't think it would be good to stack these three patches the way
they are presented in the upstream tree because it would not be
bisect-able.  Some re-work or re-ordering would be needed.

Note: I haven't attempted to understand what any of this code is
doing, I'm just testing it with my standard boot flow to make sure
nothing is broken for me.


> Thanks.
>>
>> Regards,
>> Ryan.
>>
>> >
>> >
>> >
>> >
>> > Best Regards,
>> >
>> > Alison Wang
>> >
>> >
>> >
>> > From: york sun
>> > Sent: Friday, November 04, 2016 10:04 AM
>> > To: ryan.har...@linaro.org
>> > Cc: Wang Huan ; ag...@suse.de; Scott Wood
>> > ; Stuart Yoder ; Leo Li
>> > ; feng...@phytium.com.cn; mon...@monstr.eu;
>> > thomas...@samsung.com; mk7.k...@samsung.com; u-boot@lists.denx.de;
>> > Jason Jin ; Alison Wang 
>> >
>> >
>> > Subject: Re: [PATCH v7 1/2] armv8: Support loading 32-bit OS in
>> > AArch32 execution state
>> >
>> >
>> >
>> > Alison,
>> >
>> > Does Ryan have your 32-bit kernel image? I think kernel 32-bit
>> doesn't
>> > support spin table. Please work with Ryan if your PSCI patch is
>> > required for the test.
>> >
>> > York
>> >
>> >
>> >
>> >  Original Message 
>> > From: Ryan Harkin 
>> > Sent: Thursday, November 3, 2016 12:17 PM
>> > To: york sun 
>> > Subject: Re: [PATCH v7 1/2] armv8: Support loading 32-bit OS in
>> > AArch32 execution state
>> > CC: Alison Wang ,ag...@suse.de,Scott Wood
>> > ,Stuart Yoder ,Leo Li

Re: [U-Boot] [PATCH] ARM: k2g: Update PLL Multiplier and divider values

[Tom Rini]

On Thu, Nov 03, 2016 at 03:35:02PM +0530, Lokesh Vutla wrote:

> Only a certain set of PLLM/D values are recommended to configure the DDR
> at the required speeds for a given clock input frequency. Updating these
> values as specified in Data Sheet[1] Table 5-18
> 
> [1] http://www.ti.com/lit/ds/symlink/66ak2g02.pdf
> 
> Signed-off-by: Lokesh Vutla 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH] ARM: keystone2: PLL: Enable glitch free initialization sequence

[Tom Rini]

On Thu, Nov 03, 2016 at 03:32:51PM +0530, Lokesh Vutla wrote:

> Update the PLL initialization sequence to avoid glitches while
> programming. User guide for the same is available at[1].
> 
> [1] http://www.ti.com/lit/ug/sprugv2h/sprugv2h.pdf
> 
> Signed-off-by: Lokesh Vutla 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PULL] u-boot-usb/master

[Tom Rini]

On Thu, Nov 03, 2016 at 11:57:12AM +0100, Marek Vasut wrote:

> The following changes since commit d8bdfc80da39211d95f10d24e79f2e867305f71b:
> 
>   Prepare v2016.11-rc3 (2016-10-31 16:36:10 -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-usb.git master
> 
> for you to fetch changes up to dd93a8e9e688f4c448092a275bf7db3e16d21c6f:
> 
>   dfu: align array in dfu_get_dev_type with enum dfu_device_type
> (2016-11-03 11:55:25 +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] Please pull u-boot-rockchip

[Tom Rini]

On Mon, Oct 31, 2016 at 11:40:10AM -0600, Simon Glass wrote:

> Hi Tom,
> 
> This includes various minor tweaks for rockchip.
> 
> 
> The following changes since commit 48d2fc47c9feac54fdc0e2e0462f13b1a8689ece:
> 
>   Merge branch 'sun9i-a80-spl' of http://git.denx.de/u-boot-sunxi
> (2016-10-30 08:12:00 -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-rockchip.git
> 
> for you to fetch changes up to 4594ac07847f5c7fe7294ce6c71849fea0a431e0:
> 
>   rk3288: kconfig: remove duplicate definition of SPL_MMC_SUPPORT
> (2016-10-30 13:29:06 -0600)
> 

Applied to u-boot/master (before v2016.11-rc3), 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] tools: imximage: check return value when open the plugin file

[Tom Rini]

On Fri, Nov 04, 2016 at 10:33:15AM +0800, Peng Fan wrote:

> Check return value when open the plugin file.
> 
> Coverity report:
> ** CID 153926:  Error handling issues  (NEGATIVE_RETURNS)
> /tools/imximage.c: 542 in copy_plugin_code()
> 
>ifd = open(plugin_file, O_RDONLY|O_BINARY);
> >>>  CID 153926:  Error handling issues  (NEGATIVE_RETURNS)
> >>> "ifd" is passed to a parameter that cannot be negative.
> 
> Signed-off-by: Peng Fan 
> Cc: Stefano Babic 
> Cc: Tom Rini 

Reported-by: Coverity (CID: 153926)
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

[U-Boot] [PATCH] sf: Fix S25FS512S id param table

[Jagan Teki]

S25FS512S and S25FL512S_256K have common id information
till 5 bytes and 6th byte have different family id
like FS and FL-S as 0x81 and 0x80.

Reported-by: Vignesh R 
Signed-off-by: Jagan Teki 
---
 drivers/mtd/spi/sf_params.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
index 344d9c9..3be3470 100644
--- a/drivers/mtd/spi/sf_params.c
+++ b/drivers/mtd/spi/sf_params.c
@@ -93,7 +93,7 @@ const struct spi_flash_info spi_flash_ids[] = {
{"S25FL128S_64K",  INFO(0x012018, 0x4d01,  64 * 1024,   256, RD_FULL | 
WR_QPP) },
{"S25FL256S_256K", INFO(0x010219, 0x4d00, 256 * 1024,   128, RD_FULL | 
WR_QPP) },
{"S25FL256S_64K",  INFO(0x010219, 0x4d01,  64 * 1024,   512, RD_FULL | 
WR_QPP) },
-   {"S25FS512S",  INFO(0x010220, 0x4D00, 128 * 1024,   512, RD_FULL | 
WR_QPP) },
+   {"S25FS512S",  INFO6(0x010220, 0x4D0081, 128 * 1024, 512, RD_FULL | 
WR_QPP) },
{"S25FL512S_256K", INFO(0x010220, 0x4d00, 256 * 1024,   256, RD_FULL | 
WR_QPP) },
{"S25FL512S_64K",  INFO(0x010220, 0x4d01,  64 * 1024,  1024, RD_FULL | 
WR_QPP) },
{"S25FL512S_512K", INFO(0x010220, 0x4f00, 256 * 1024,   256, RD_FULL | 
WR_QPP) },
-- 
1.9.1

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

Re: [U-Boot] [PATCH RESEND v2 2/2] spi: ti_qspi: Fix baudrate divider calculation

[Jagan Teki]

On Mon, Oct 31, 2016 at 2:54 PM, Jagan Teki  wrote:
> On Mon, Oct 31, 2016 at 9:40 AM, Vignesh R  wrote:
>> Fix the divider calculation logic to choose a value so that the
>> resulting baudrate is either equal to or closest possible baudrate less
>> than the requested value. While at that, cleanup ti_spi_set_speed().
>>
>> Signed-off-by: Vignesh R 
>> ---
>>
>> v2: cleanup ti_spi_set_speed() a bit.
>>
>>  drivers/spi/ti_qspi.c | 15 +++
>>  1 file changed, 7 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/spi/ti_qspi.c b/drivers/spi/ti_qspi.c
>> index 52520dff6325..b5de70bf40e3 100644
>> --- a/drivers/spi/ti_qspi.c
>> +++ b/drivers/spi/ti_qspi.c
>> @@ -16,6 +16,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>
>>  DECLARE_GLOBAL_DATA_PTR;
>>
>> @@ -118,21 +119,19 @@ static void ti_spi_set_speed(struct ti_qspi_priv 
>> *priv, uint hz)
>> if (!hz)
>> clk_div = 0;
>> else
>> -   clk_div = (priv->fclk / hz) - 1;
>> -
>> -   debug("ti_spi_set_speed: hz: %d, clock divider %d\n", hz, clk_div);
>> +   clk_div = DIV_ROUND_UP(priv->fclk, hz) - 1;
>>
>> /* disable SCLK */
>> writel(readl(>base->clk_ctrl) & ~QSPI_CLK_EN,
>>>base->clk_ctrl);
>
> Move this before enable SCLK.

Do send the updated v3 or discusses further, I need to send the release PR?

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

[U-Boot] [PATCH 1/3] fsl/ddr: Revise erratum a009942 and clean related erratum

[Shengzhou Liu]

- add additional function erratum_a009942_check_cpo to check if the
  board needs tuning CPO calibration for optimal setting.
- move ERRATUM_A009942(with revision to check cpo_sample option) from
  fsl_ddr_gen4.c to ctrl_regs.c for reuse on all DDR4/DDR3 parts.
- move ERRATUM_A008378 from fsl_ddr_gen4.c to ctrl_regs.c
- remove obsolete ERRATUM_A004934 which is replaced with ERRATUM_A009942.

Signed-off-by: Shengzhou Liu 
---
 arch/arm/cpu/armv8/fsl-layerscape/cpu.c   |   7 +-
 arch/powerpc/cpu/mpc85xx/cpu_init.c   |   6 +-
 arch/powerpc/include/asm/config_mpc85xx.h |   2 -
 board/freescale/ls1021aqds/ls1021aqds.c   |   6 +-
 drivers/ddr/fsl/ctrl_regs.c   | 104 +-
 drivers/ddr/fsl/fsl_ddr_gen4.c|  23 ---
 drivers/ddr/fsl/mpc85xx_ddr_gen3.c|   3 -
 include/fsl_ddr.h |   2 +
 include/fsl_ddr_sdram.h   |   3 +-
 9 files changed, 121 insertions(+), 35 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c 
b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
index b7a2e0c..19de15e 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
@@ -25,6 +25,9 @@
 #ifdef CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT
 #include 
 #endif
+#ifdef CONFIG_SYS_FSL_DDR
+#include 
+#endif
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -400,7 +403,9 @@ int arch_early_init_r(void)
 #ifdef CONFIG_SYS_FSL_ERRATUM_A009635
erratum_a009635();
 #endif
-
+#if defined(CONFIG_SYS_FSL_ERRATUM_A009942) && defined(CONFIG_SYS_FSL_DDR)
+   erratum_a009942_check_cpo();
+#endif
 #ifdef CONFIG_MP
 #if defined(CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT) && defined(CONFIG_ARMV8_PSCI)
/* Check the psci version to determine if the psci is supported */
diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c 
b/arch/powerpc/cpu/mpc85xx/cpu_init.c
index 53b3729..c1dbd9c 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
@@ -45,7 +45,7 @@
 #include 
 #include 
 #endif
-
+#include 
 #include "../../../../drivers/block/fsl_sata.h"
 #ifdef CONFIG_U_QE
 #include 
@@ -947,6 +947,10 @@ int cpu_init_r(void)
 
 #endif /* CONFIG_SYS_FSL_USB_DUAL_PHY_ENABLE */
 
+#ifdef CONFIG_SYS_FSL_ERRATUM_A009942
+   erratum_a009942_check_cpo();
+#endif
+
 #ifdef CONFIG_FMAN_ENET
fman_enet_init();
 #endif
diff --git a/arch/powerpc/include/asm/config_mpc85xx.h 
b/arch/powerpc/include/asm/config_mpc85xx.h
index 6d845e8..1e62a9c 100644
--- a/arch/powerpc/include/asm/config_mpc85xx.h
+++ b/arch/powerpc/include/asm/config_mpc85xx.h
@@ -681,7 +681,6 @@
 #define CONFIG_SYS_FSL_USB_DUAL_PHY_ENABLE
 #define CONFIG_SYS_FSL_USB_INTERNAL_UTMI_PHY
 #define CONFIG_SYS_FSL_ERRATUM_A004468
-#define CONFIG_SYS_FSL_ERRATUM_A_004934
 #define CONFIG_SYS_FSL_ERRATUM_A005871
 #define CONFIG_SYS_FSL_ERRATUM_A006379
 #define CONFIG_SYS_FSL_ERRATUM_A007186
@@ -720,7 +719,6 @@
 #define CONFIG_SYS_FSL_TBCLK_DIV   16
 #define CONFIG_SYS_FSL_PCIE_COMPAT "fsl,qoriq-pcie-v2.4"
 #define CONFIG_SYS_FSL_USB1_PHY_ENABLE
-#define CONFIG_SYS_FSL_ERRATUM_A_004934
 #define CONFIG_SYS_FSL_ERRATUM_A005871
 #define CONFIG_SYS_FSL_ERRATUM_A006379
 #define CONFIG_SYS_FSL_ERRATUM_A007186
diff --git a/board/freescale/ls1021aqds/ls1021aqds.c 
b/board/freescale/ls1021aqds/ls1021aqds.c
index 4eb38a7..79078d2 100644
--- a/board/freescale/ls1021aqds/ls1021aqds.c
+++ b/board/freescale/ls1021aqds/ls1021aqds.c
@@ -22,7 +22,7 @@
 #include 
 #include 
 #include 
-
+#include 
 #include "../common/sleep.h"
 #include "../common/qixis.h"
 #include "ls1021aqds_qixis.h"
@@ -433,7 +433,9 @@ int board_init(void)
 #ifdef CONFIG_SYS_FSL_ERRATUM_A010315
erratum_a010315();
 #endif
-
+#ifdef CONFIG_SYS_FSL_ERRATUM_A009942
+   erratum_a009942_check_cpo();
+#endif
major = get_soc_major_rev();
if (major == SOC_MAJOR_VER_1_0) {
/* Set CCI-400 control override register to
diff --git a/drivers/ddr/fsl/ctrl_regs.c b/drivers/ddr/fsl/ctrl_regs.c
index 24fd366..656de2c 100644
--- a/drivers/ddr/fsl/ctrl_regs.c
+++ b/drivers/ddr/fsl/ctrl_regs.c
@@ -5,14 +5,14 @@
  */
 
 /*
- * Generic driver for Freescale DDR/DDR2/DDR3 memory controller.
+ * Generic driver for Freescale DDR/DDR2/DDR3/DDR4 memory controller.
  * Based on code from spd_sdram.c
  * Author: James Yang [at freescale.com]
  */
 
 #include 
 #include 
-
+#include 
 #include 
 #include 
 #include 
@@ -2305,6 +2305,9 @@ compute_fsl_memctl_config_regs(const unsigned int 
ctrl_num,
unsigned int wrlvl_en;
unsigned int ip_rev = 0;
unsigned int unq_mrs_en = 0;
+#ifdef CONFIG_SYS_FSL_ERRATUM_A009942
+   unsigned int ddr_freq;
+#endif
int cs_en = 1;
 
memset(ddr, 0, sizeof(fsl_ddr_cfg_regs_t));
@@ -2526,5 +2529,102 @@ compute_fsl_memctl_config_regs(const unsigned int 
ctrl_num,
ddr->debug[2] |= 0x0200;/* set bit 22 */
 #endif
 
+#if defined(CONFIG_SYS_FSL_ERRATUM_A008378) && 

[U-Boot] [PATCH 3/3] fsl/ddr: Fix compiling warning

[Shengzhou Liu]

Fix following warning in case multiple erratum macro was not defined.
warning: unused variable 'tmp'
warning: unused variable 'ddr_freq'

Signed-off-by: Shengzhou Liu 
---
 drivers/ddr/fsl/fsl_ddr_gen4.c | 43 +-
 1 file changed, 17 insertions(+), 26 deletions(-)

diff --git a/drivers/ddr/fsl/fsl_ddr_gen4.c b/drivers/ddr/fsl/fsl_ddr_gen4.c
index 2a5066a..03ab844 100644
--- a/drivers/ddr/fsl/fsl_ddr_gen4.c
+++ b/drivers/ddr/fsl/fsl_ddr_gen4.c
@@ -47,13 +47,9 @@ void fsl_ddr_set_memctl_regs(const fsl_ddr_cfg_regs_t *regs,
 {
unsigned int i, bus_width;
struct ccsr_ddr __iomem *ddr;
-   u32 temp_sdram_cfg;
+   u32 temp32;
u32 total_gb_size_per_controller;
int timeout;
-#if defined(CONFIG_SYS_FSL_ERRATUM_A008511) || \
-   defined(CONFIG_SYS_FSL_ERRATUM_A009801)
-   u32 temp32;
-#endif
 
 #ifdef CONFIG_SYS_FSL_ERRATUM_A008511
u32 mr6;
@@ -61,11 +57,6 @@ void fsl_ddr_set_memctl_regs(const fsl_ddr_cfg_regs_t *regs,
u32 vref_seq2[3] = {0xc0, 0xf0, 0x70};  /* for range 2 */
u32 *vref_seq = vref_seq1;
 #endif
-#if defined(CONFIG_SYS_FSL_ERRATUM_A009942) | \
-   defined(CONFIG_SYS_FSL_ERRATUM_A010165)
-   ulong ddr_freq;
-   u32 tmp;
-#endif
 #ifdef CONFIG_FSL_DDR_BIST
u32 mtcr, err_detect, err_sbe;
u32 cs0_bnds, cs1_bnds, cs2_bnds, cs3_bnds, cs0_config;
@@ -268,10 +259,10 @@ void fsl_ddr_set_memctl_regs(const fsl_ddr_cfg_regs_t 
*regs,
 #endif
 
 #ifdef CONFIG_SYS_FSL_ERRATUM_A010165
-   ddr_freq = get_ddr_freq(ctrl_num) / 100;
-   if ((ddr_freq > 1900) && (ddr_freq < 2300)) {
-   tmp = ddr_in32(>debug[28]);
-   ddr_out32(>debug[28], tmp | 0x000a);
+   temp32 = get_ddr_freq(ctrl_num) / 100;
+   if ((temp32 > 1900) && (temp32 < 2300)) {
+   temp32 = ddr_in32(>debug[28]);
+   ddr_out32(>debug[28], temp32 | 0x000a);
}
 #endif
/*
@@ -289,9 +280,9 @@ void fsl_ddr_set_memctl_regs(const fsl_ddr_cfg_regs_t *regs,
 
 step2:
/* Set, but do not enable the memory */
-   temp_sdram_cfg = regs->ddr_sdram_cfg;
-   temp_sdram_cfg &= ~(SDRAM_CFG_MEM_EN);
-   ddr_out32(>sdram_cfg, temp_sdram_cfg);
+   temp32 = regs->ddr_sdram_cfg;
+   temp32 &= ~(SDRAM_CFG_MEM_EN);
+   ddr_out32(>sdram_cfg, temp32);
 
/*
 * 500 painful micro-seconds must elapse between
@@ -306,18 +297,18 @@ step2:
 #ifdef CONFIG_DEEP_SLEEP
if (is_warm_boot()) {
/* enter self-refresh */
-   temp_sdram_cfg = ddr_in32(>sdram_cfg_2);
-   temp_sdram_cfg |= SDRAM_CFG2_FRC_SR;
-   ddr_out32(>sdram_cfg_2, temp_sdram_cfg);
+   temp32 = ddr_in32(>sdram_cfg_2);
+   temp32 |= SDRAM_CFG2_FRC_SR;
+   ddr_out32(>sdram_cfg_2, temp32);
/* do board specific memory setup */
board_mem_sleep_setup();
 
-   temp_sdram_cfg = (ddr_in32(>sdram_cfg) | SDRAM_CFG_BI);
+   temp32 = (ddr_in32(>sdram_cfg) | SDRAM_CFG_BI);
} else
 #endif
-   temp_sdram_cfg = ddr_in32(>sdram_cfg) & ~SDRAM_CFG_BI;
+   temp32 = ddr_in32(>sdram_cfg) & ~SDRAM_CFG_BI;
/* Let the controller go */
-   ddr_out32(>sdram_cfg, temp_sdram_cfg | SDRAM_CFG_MEM_EN);
+   ddr_out32(>sdram_cfg, temp32 | SDRAM_CFG_MEM_EN);
mb();
isb();
 
@@ -460,9 +451,9 @@ step2:
 #ifdef CONFIG_DEEP_SLEEP
if (is_warm_boot()) {
/* exit self-refresh */
-   temp_sdram_cfg = ddr_in32(>sdram_cfg_2);
-   temp_sdram_cfg &= ~SDRAM_CFG2_FRC_SR;
-   ddr_out32(>sdram_cfg_2, temp_sdram_cfg);
+   temp32 = ddr_in32(>sdram_cfg_2);
+   temp32 &= ~SDRAM_CFG2_FRC_SR;
+   ddr_out32(>sdram_cfg_2, temp32);
}
 #endif
 
-- 
2.1.0.27.g96db324

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

Re: [U-Boot] [RFC PATCH] lib/timer: initialize timebase_l/timebase_h

[Andre Przywara]

Hi,

On 26/10/16 08:14, Alexander Graf wrote:
> On 10/26/2016 02:07 AM, André Przywara wrote:
>> On 25/10/16 08:52, Alexander Graf wrote:
>>
>> Hi Alex,
>>
>> thanks for looking at this!
>>
>>> On 25/10/2016 02:51, Andre Przywara wrote:
 On systems using the generic timer routines defined in lib/time.c we
 use timebase_l and timebase_h fields from the gd to detect wraparounds
 in our tick counter. The tick calculcation algorithm silently assumes
 that a long is only 32 bits, which leads to wrong results when
 timebase_h
 is not 0 on 64-bit systems.
 As one possible fix lets initialize timebase_h (and timebase_l) to
 0, so
 on 64-bit systems timebase_h will never(TM) be bigger than 0 and thus
 cannot spoil timebase_l by being ORed into it.

 This fixes occasional timeout issues on the Pine64 (and possibly other
 ARM64 systems).
>> Well, not really (this fix isn't sufficient), but read on ...
>>
 Signed-off-by: Andre Przywara 
 ---
 Hi,

 I am bit puzzled what the proper fix is, this one is the easiest I
 could
 come up with. Not sure if the gd should be zeroed normally (and it's
 just
 broken on sunxi/arm64 because of some linker issues) or whether we
 really
 forgot to initialize those fields and just got away with it.
>>> The gd clearing happens via crt0_64.S -> board_init_f_init_reserve().
>>> There we should have fully cleared all memory associated with global
>>> data.
>> Ah,thanks for pointing to that. I was a bit clueless where to start
>> looking for it - "git grep gd" is obviously not a good idea ;-)
>>
>>> I can't see anything obviously wrong in that code. Could you try to dump
>>> gd if the timer offsets are != 0 on init? Maybe we can conclude
>>> something from the data in it.
>> So I agree that this code looks sane and indeed in all my dumps it looks
>> like the initialization works fine.
>> I did some more debugging and learned that the increased timebase_h
>> comes from detected overflows: in fact some readings are really lower
>> than previous ones:
>> ...
>> MMC:   SUNXI SD/MMC: 0
>> get_ticks() overflow: now: 118046720, tbl: 118063103, tbh: 0
>> get_ticks() overflow: now: 118439936, tbl: 118456318, tbh: 1
>> get_ticks() overflow: now: 118571008, tbl: 118587391, tbh: 2
>> get_ticks() overflow: now: 118734848, tbl: 118751230, tbh: 3
>> get_ticks() overflow: now: 119422976, tbl: 119439358, tbh: 4
>> get_ticks() overflow: now: 119783424, tbl: 119799807, tbh: 5
>> get_ticks() overflow: now: 120045568, tbl: 120061950, tbh: 6
>> get_ticks() overflow: now: 120406016, tbl: 120422398, tbh: 7
>> *** Warning - bad CRC, using default environment
>> ..
>> Not sure how this actually happens - I am not aware of any such severe
>> hardware errata in the A53 r0p4 or the timer, also I think that would
>> have bitten us elsewhere already.
>> As ATF keeps the secondaries in WFI, U-Boot only runs on CPU0 (confirmed
>> by MPIDR reads).
>> Also U-Boot reads the physical counter, so a bogus CNTVOFF can also not
>> be the culprit.
>>
>> So I can fix this annoying issue by using one of the other proposed
>> fixes (handling timebase_h only if BITS_PER_LONG < 64 or defining
>> get_ticks in armv8/generic_timer.c), but it would still be interesting
>> to find the real root cause.
> 
> Can you try and ask around? If this bites us in U-Boot, there's a good
> chance Linux timers should be broken too, no?
> 
> I remember that NXP had similar problems with the timer:
> 
>   https://patchwork.kernel.org/patch/9344727/

So I did some more experiments, and indeed it looks very much like a
silicon bug in the A64. Philipp found this in the BSP kernel:
https://github.com/longsleep/linux-pine64/blob/pine64-hacks-1.2/drivers/clocksource/arm_arch_timer.c#L231

So I have a direct test that reads both the CNTVCNT register and
CLOCK_MONOTONIC_RAW back to back for a few million times and looks for
decreasing values. On the Freescale box it triggers on every boot, on
A64 only on certain boots.

But the error pattern looks similar (though not identical), on the A64
it is:
CNTVCNT before: 7fff, CNTVCNT after: 4000
CNTVCNT before: , CNTVCNT after: c000
On the Freescale box I see different lengths of bogus lower bits, on the
A64 it's always the lower 15 bits.

These are at least the cases that I could spot (because the later read
returns a smaller value), there may be more corruptions that are harder
to find.

Setting the new Freescale erratum DT property in the arch timer node
fixes at least the Linux interface on the A64, as expected.
But as stated above this doesn't happen on every boot, so there might be
the chance that it's a missing initialization somewhere.

Since clock_gettime() gets disabled in the VDSO with the workaround, I'd
like to do more research to get an idea why it sometimes works and
sometimes not.

But unless we find another fix, I'll send a patch to enable the FSL
workaround 

[U-Boot] [PATCH 2/3] fsl/ddr: Enable erratum-a009942 workaround for B/T-series

[Shengzhou Liu]

Enable ERRATUM_A009942 workaround for B-series and T-series platforms.

Signed-off-by: Shengzhou Liu 
---
 arch/powerpc/include/asm/config_mpc85xx.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/powerpc/include/asm/config_mpc85xx.h 
b/arch/powerpc/include/asm/config_mpc85xx.h
index 1e62a9c..95183da 100644
--- a/arch/powerpc/include/asm/config_mpc85xx.h
+++ b/arch/powerpc/include/asm/config_mpc85xx.h
@@ -686,6 +686,7 @@
 #define CONFIG_SYS_FSL_ERRATUM_A007186
 #define CONFIG_SYS_FSL_ERRATUM_A006593
 #define CONFIG_SYS_FSL_ERRATUM_A007798
+#define CONFIG_SYS_FSL_ERRATUM_A009942
 #define CONFIG_SYS_CCSRBAR_DEFAULT 0xfe00
 #define CONFIG_SYS_FSL_SFP_VER_3_0
 #define CONFIG_SYS_FSL_PCI_VER_3_X
@@ -728,6 +729,7 @@
 #define CONFIG_SYS_FSL_ERRATUM_A006384
 #define CONFIG_SYS_FSL_ERRATUM_A007212
 #define CONFIG_SYS_FSL_ERRATUM_A004477
+#define CONFIG_SYS_FSL_ERRATUM_A009942
 #define CONFIG_SYS_CCSRBAR_DEFAULT 0xfe00
 #define CONFIG_SYS_FSL_SFP_VER_3_0
 
@@ -807,6 +809,7 @@ defined(CONFIG_PPC_T1020) || defined(CONFIG_PPC_T1022)
 #define CONFIG_SYS_FSL_SFP_VER_3_0
 #define CONFIG_SYS_FSL_ERRATUM_A008378
 #define CONFIG_SYS_FSL_ERRATUM_A009663
+#define CONFIG_SYS_FSL_ERRATUM_A009942
 
 #elif defined(CONFIG_PPC_T1024) || defined(CONFIG_PPC_T1023) ||\
 defined(CONFIG_PPC_T1014) || defined(CONFIG_PPC_T1013)
@@ -856,6 +859,7 @@ defined(CONFIG_PPC_T1014) || defined(CONFIG_PPC_T1013)
 #define CONFIG_SYS_FSL_SFP_VER_3_0
 #define CONFIG_SYS_FSL_ERRATUM_A008378
 #define CONFIG_SYS_FSL_ERRATUM_A009663
+#define CONFIG_SYS_FSL_ERRATUM_A009942
 
 #elif defined(CONFIG_PPC_T2080) || defined(CONFIG_PPC_T2081)
 #define CONFIG_E6500
@@ -908,6 +912,7 @@ defined(CONFIG_PPC_T1014) || defined(CONFIG_PPC_T1013)
 #define CONFIG_SYS_FSL_ERRATUM_A006593
 #define CONFIG_SYS_FSL_ERRATUM_A007186
 #define CONFIG_SYS_FSL_ERRATUM_A006379
+#define CONFIG_SYS_FSL_ERRATUM_A009942
 #define ESDHCI_QUIRK_BROKEN_TIMEOUT_VALUE
 #define CONFIG_SYS_FSL_SFP_VER_3_0
 
-- 
2.1.0.27.g96db324

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

[U-Boot] [PATCH] tools: imximage: check return value when open the plugin file

[Peng Fan]

Check return value when open the plugin file.

Coverity report:
** CID 153926:  Error handling issues  (NEGATIVE_RETURNS)
/tools/imximage.c: 542 in copy_plugin_code()

   ifd = open(plugin_file, O_RDONLY|O_BINARY);
>>>  CID 153926:  Error handling issues  (NEGATIVE_RETURNS)
>>> "ifd" is passed to a parameter that cannot be negative.

Signed-off-by: Peng Fan 
Cc: Stefano Babic 
Cc: Tom Rini 
---
 tools/imximage.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/tools/imximage.c b/tools/imximage.c
index 615a64e..c9e42ec 100644
--- a/tools/imximage.c
+++ b/tools/imximage.c
@@ -533,12 +533,19 @@ static void print_hdr_v2(struct imx_header *imx_hdr)
 
 static void copy_plugin_code(struct imx_header *imxhdr, char *plugin_file)
 {
-   int ifd = -1;
+   int ifd;
struct stat sbuf;
char *plugin_buf = imxhdr->header.hdr_v2.data.plugin_code;
char *ptr;
 
ifd = open(plugin_file, O_RDONLY|O_BINARY);
+   if (ifd < 0) {
+   fprintf(stderr, "Can't open %s: %s\n",
+   plugin_file,
+   strerror(errno));
+   exit(EXIT_FAILURE);
+   }
+
if (fstat(ifd, ) < 0) {
fprintf(stderr, "Can't stat %s: %s\n",
plugin_file,
-- 
2.6.2

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

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

[Phil Edworthy]

Hi Vignesh,

On 04 November 2016 05:57, Vignesh R wrote:
> On Wednesday 02 November 2016 08:45 PM, Phil Edworthy wrote:
> > The HW manual does not give details about what the register
> > value for this bit actually does, other than "Choose edge on
> > which data outputs from flash memory will be sampled".
> >
> > Signed-off-by: Phil Edworthy 
> >
> > ---
> > Our HW engineers tell me that it needs to be set for our hardware.
> > ---
> >  doc/device-tree-bindings/spi/spi-cadence.txt |  2 ++
> >  drivers/spi/cadence_qspi.c   | 10 +++---
> >  drivers/spi/cadence_qspi.h   |  3 ++-
> >  drivers/spi/cadence_qspi_apb.c   |  8 +++-
> >  4 files changed, 18 insertions(+), 5 deletions(-)
> >
> > diff --git a/doc/device-tree-bindings/spi/spi-cadence.txt b/doc/device-tree-
> bindings/spi/spi-cadence.txt
> > index c1e2233..71aa06a 100644
> > --- a/doc/device-tree-bindings/spi/spi-cadence.txt
> > +++ b/doc/device-tree-bindings/spi/spi-cadence.txt
> > @@ -26,3 +26,5 @@ connected flash properties
> >   select (n_ss_out).
> >  - tslch-ns : Delay in master reference clocks between setting
> >   n_ss_out low and first bit transfer
> > +- sample-edge  : The edge on which data outputs from flash
> memory will
> > + be sampled.
> 
> Could this be changed to bool property say sample-edge-rising?
> 
> sample-edge-rising(optional): data outputs from flash memory will
> be sampled at the rising edge. Default is falling edge
Whilst this makes sense, the trouble I have is that I don't know if the
register setting  is making it use rising or falling edge sampling. I'll try to
find out again...
 
> --
> Regards
> Vignesh

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

Re: [U-Boot] [PATCH v7 1/2] armv8: Support loading 32-bit OS in AArch32 execution state

[Ryan Harkin]

On 4 November 2016 at 02:26, Alison Wang  wrote:
> York,
>
>
>
> No, he don’t have my 32-bit kernel image. I am not sure he
> is using 32-bit kernel or 64-bit kernel.
>
>
>
> Ryan,
>
>
>
> I am not familiar with the boards you tested,

The FVP Foundation model is free to use from ARM.  The entire software
stack I'm using is available via ARM's portal:

https://community.arm.com/groups/arm-development-platforms


> so I have some
> questions, please help to work with me to find the root cause.
>
>
>
> 1.   Are you loading 32-bit kernel or 64-bit kernel?
>

I'm loading the "standard" 64-bit kernel.  I was using a kernel based off 4.8:

https://git.linaro.org/landing-teams/working/arm/kernel-release.git/log/?h=latest-armlt-20161001

> 2.   Is CONFIG_ARMV8_SWITCH_TO_EL1 defined on these boards?
>

I guess it is for the FVP models, if I grep for it, it's in my configs' .h file:

include/configs/vexpress_aemv8a.h:15:#define CONFIG_ARMV8_SWITCH_TO_EL1

---
#ifdef CONFIG_TARGET_VEXPRESS64_BASE_FVP
#ifndef CONFIG_SEMIHOSTING
#error CONFIG_TARGET_VEXPRESS64_BASE_FVP requires CONFIG_SEMIHOSTING
#endif
#define CONFIG_ARMV8_SWITCH_TO_EL1
#endif
---

But it isn't in my Juno config.


> 3.   Are you using some secure firmware on these boards? In detail, I
> want to know which EL is running on these boards when calling
> armv8_switch_to_el2 in arch/arm/lib/bootm.c. If it is already running in EL2
> when calling armv8_swith_to_el2, the attached patch with PSCI enabled is
> needed.
>

I'm using what ARM consider the "standard" boot flow.  I'm using ARM
Trusted Firmware to boot u-boot which in turn boots an arm64 kernel.

I'd expect my setup to still work after you've added patches to allow
an aarch32 kernel to be booted, but I guess you're changing the boot
path for non-aarch32 kernels also.

Regards,
Ryan.

>
>
>
>
> Best Regards,
>
> Alison Wang
>
>
>
> From: york sun
> Sent: Friday, November 04, 2016 10:04 AM
> To: ryan.har...@linaro.org
> Cc: Wang Huan ; ag...@suse.de; Scott Wood
> ; Stuart Yoder ; Leo Li
> ; feng...@phytium.com.cn; mon...@monstr.eu;
> thomas...@samsung.com; mk7.k...@samsung.com; u-boot@lists.denx.de; Jason Jin
> ; Alison Wang 
>
>
> Subject: Re: [PATCH v7 1/2] armv8: Support loading 32-bit OS in AArch32
> execution state
>
>
>
> Alison,
>
> Does Ryan have your 32-bit kernel image? I think kernel 32-bit doesn't
> support spin table. Please work with Ryan if your PSCI patch is required for
> the test.
>
> York
>
>
>
>  Original Message 
> From: Ryan Harkin 
> Sent: Thursday, November 3, 2016 12:17 PM
> To: york sun 
> Subject: Re: [PATCH v7 1/2] armv8: Support loading 32-bit OS in AArch32
> execution state
> CC: Alison Wang ,ag...@suse.de,Scott Wood
> ,Stuart Yoder ,Leo Li
> ,feng...@phytium.com.cn,mon...@monstr.eu,thomas...@samsung.com,mk7.k...@samsung.com,u-boot@lists.denx.de,Jason
> Jin ,Alison Wang 
>
> Hi York/Alison,
>
> Sorry for not having had time to look at this earlier.
>
>
> On 26 October 2016 at 17:54, york sun  wrote:
>> On 10/07/2016 11:56 PM, Alison Wang wrote:
>>> To support loading a 32-bit OS, the execution state will change from
>>> AArch64 to AArch32 when jumping to kernel.
>>>
>>> The architecture information will be got through checking FIT image,
>>> then U-Boot will load 32-bit OS or 64-bit OS automatically.
>>>
>>> Signed-off-by: Ebony Zhu 
>>> Signed-off-by: Alison Wang 
>>> Signed-off-by: Chenhui Zhao 
>>> ---
>>> Changes in v7:
>>> - Move the call for armv8_switch_to_el2_m into this patch.
>>>
>>
>> Reviewers,
>>
>> May I have your comment please? I intend to merge this set when the
>> merge window opens.
>>
>
> I've just tested these two patches on ARM's FVP Foundation and AEMv8
> models and ARM's Juno board.
>
> In all cases, with this patchset, the kernel fails to start.  I see a
> continuous reboot, where the kernel starts then immediately resets:
>
> --
> Starting kernel ...
>
> resetting ...
> --
>
> So I wouldn't want to see these patches merged.
>
> Regards,
> Ryan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] gpio: dwapb: Add support for port B

[Marek Vasut]

On 11/04/2016 09:09 AM, Phil Edworthy wrote:
> Hi Marek,

Hi,

> On 03 November 2016 17:49, Marek Vasut wrote:
>> On 11/03/2016 02:56 PM, Simon Glass wrote:
>>> On 2 November 2016 at 13:38, Marek Vasut >> > wrote:
 On 11/02/2016 04:24 PM, Phil Edworthy wrote:
> 
>> Please no c-structure register definitions, this does not scale :(
> I think this is a long standing issue... For some IP blocks using a
> C-structure for register definitions is painful. On the other hand,
> for some others it may make the code more readable.
> 
> In this case, I would tend to agree with Simon. However, I'll happily
> use whatever you two agree to.

Since the code uses macros, let's not make it inconsistent.

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

Re: [U-Boot] [PATCH v2 1/6] ARMv8: LS1043A: change macro CONFIG_ARMV8_PSCI definition

[Hongbo Zhang]

Talked to the author Zhiqiang Hou who introduced the previous
CONFIG_ARMV8_PSCI, although this config was introduced due to FSL PPA,
codes covered by it in the armv8/cpu-dt.c, bootm-dt.c, psci-dt.c also
work for the coming generic ARMv8 PSCI framework, what's more,
Zhiqiang is sending patches to clean up PPA related configs to
Kconfig, so I don't need to send this 1/6 patch any more, I'll send
the other updated 5 patches in v3.

On Thu, Nov 3, 2016 at 5:56 PM, Hongbo Zhang  wrote:
> On Wed, Nov 2, 2016 at 10:27 PM, Tom Rini  wrote:
>> On Tue, Nov 01, 2016 at 06:04:27PM +0800, macro.wav...@gmail.com wrote:
>>
>>> From: Hongbo Zhang 
>>>
>>> NXP/Freescale uses macro CONFIG_ARMV8_PSCI to enable their private PSCI
>>> implementation in PPA firmware, but this macro naming too generic, so this
>>> patch replaces it with a specic one CONFIG_FSL_PPA_ARMV8_PSCI.
>>> And this macro CONFIG_ARMV8_PSCI will be used for a generic PSCI for ARMv8
>>> which will be added in following patchs.
>>>
>>> Signed-off-by: Hongbo Zhang 
>> [snip]
>>> diff --git a/include/configs/ls1043ardb.h b/include/configs/ls1043ardb.h
>>> index 1d0a1ac..d2f8fc0 100644
>>> --- a/include/configs/ls1043ardb.h
>>> +++ b/include/configs/ls1043ardb.h
>>> @@ -12,7 +12,7 @@
>>>  #if defined(CONFIG_FSL_LS_PPA)
>>>  #define CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT
>>>  #define SEC_FIRMWARE_ERET_ADDR_REVERT
>>> -#define CONFIG_ARMV8_PSCI
>>> +#define CONFIG_FSL_PPA_ARMV8_PSCI
>>>
>>>  #define CONFIG_SYS_LS_PPA_FW_IN_XIP
>>>  #ifdef CONFIG_SYS_LS_PPA_FW_IN_XIP
>>
>> This will trip-up the whitelist check, please move the new symbol to
>> Kconfig and select it from LS1043ARDB + FSL_LS_PPA.  Thanks!
>>
>
> Payed much attention to the config options I introduced in the common
> framework, but neglected this legacy one.
> Yes will update this.
>
>> --
>> Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] gpio: dwapb: Add support for port B

[Phil Edworthy]

Hi Marek,

On 03 November 2016 17:49, Marek Vasut wrote:
> On 11/03/2016 02:56 PM, Simon Glass wrote:
> > On 2 November 2016 at 13:38, Marek Vasut  > > wrote:
> >> On 11/02/2016 04:24 PM, Phil Edworthy wrote:

> Please no c-structure register definitions, this does not scale :(
I think this is a long standing issue... For some IP blocks using a
C-structure for register definitions is painful. On the other hand,
for some others it may make the code more readable.

In this case, I would tend to agree with Simon. However, I'll happily
use whatever you two agree to.

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

Re: [U-Boot] [PATCH v7 1/2] armv8: Support loading 32-bit OS in AArch32 execution state

[york sun]

Alison,

Does Ryan have your 32-bit kernel image? I think kernel 32-bit doesn't support 
spin table. Please work with Ryan if your PSCI patch is required for the test.

York


 Original Message 
From: Ryan Harkin 
Sent: Thursday, November 3, 2016 12:17 PM
To: york sun 
Subject: Re: [PATCH v7 1/2] armv8: Support loading 32-bit OS in AArch32 
execution state
CC: Alison Wang ,ag...@suse.de,Scott Wood 
,Stuart Yoder ,Leo Li 
,feng...@phytium.com.cn,mon...@monstr.eu,thomas...@samsung.com,mk7.k...@samsung.com,u-boot@lists.denx.de,Jason
 Jin ,Alison Wang 


Hi York/Alison,

Sorry for not having had time to look at this earlier.


On 26 October 2016 at 17:54, york sun  wrote:
> On 10/07/2016 11:56 PM, Alison Wang wrote:
>> To support loading a 32-bit OS, the execution state will change from
>> AArch64 to AArch32 when jumping to kernel.
>>
>> The architecture information will be got through checking FIT image,
>> then U-Boot will load 32-bit OS or 64-bit OS automatically.
>>
>> Signed-off-by: Ebony Zhu 
>> Signed-off-by: Alison Wang 
>> Signed-off-by: Chenhui Zhao 
>> ---
>> Changes in v7:
>> - Move the call for armv8_switch_to_el2_m into this patch.
>>
>
> Reviewers,
>
> May I have your comment please? I intend to merge this set when the
> merge window opens.
>

I've just tested these two patches on ARM's FVP Foundation and AEMv8
models and ARM's Juno board.

In all cases, with this patchset, the kernel fails to start.  I see a
continuous reboot, where the kernel starts then immediately resets:

--
Starting kernel ...

resetting ...
--

So I wouldn't want to see these patches merged.

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