[U-Boot] [PATCH] Add board_mmc_init(...) function for init mmc1 only

[Hannes Petermaier]

Since B&R boards uses only MMC-Controller #1, it only
wastes time if we initialize #0 first to see that there is nothing.

Cc: 
Signed-off-by: Hannes Petermaier 
---
 board/BuR/common/common.c |7 +++
 include/configs/kwb.h |2 +-
 include/configs/tseries.h |2 +-
 3 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/board/BuR/common/common.c b/board/BuR/common/common.c
index 4c926ce..25cbe62 100644
--- a/board/BuR/common/common.c
+++ b/board/BuR/common/common.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -214,3 +215,9 @@ int board_eth_init(bd_t *bis)
return rv;
 }
 #endif /* CONFIG_DRIVER_TI_CPSW */
+#if defined(CONFIG_GENERIC_MMC) && !defined(CONFIG_SPL_BUILD)
+int board_mmc_init(bd_t *bis)
+{
+   return omap_mmc_init(1, 0, 0, -1, -1);
+}
+#endif
diff --git a/include/configs/kwb.h b/include/configs/kwb.h
index 0f631c0..0860434 100644
--- a/include/configs/kwb.h
+++ b/include/configs/kwb.h
@@ -109,7 +109,7 @@
 
 #undef CONFIG_ENV_IS_NOWHERE
 #define CONFIG_ENV_IS_IN_MMC
-#define CONFIG_SYS_MMC_ENV_DEV 1
+#define CONFIG_SYS_MMC_ENV_DEV 0
 #define CONFIG_SYS_MMC_ENV_PART2
 #define CONFIG_ENV_OFFSET  0x4 /* TODO: Adresse definieren */
 #define CONFIG_ENV_OFFSET_REDUND   (CONFIG_ENV_OFFSET + CONFIG_ENV_SIZE)
diff --git a/include/configs/tseries.h b/include/configs/tseries.h
index 8fb87ac..e550afa 100644
--- a/include/configs/tseries.h
+++ b/include/configs/tseries.h
@@ -237,7 +237,7 @@
 #elif defined(CONFIG_EMMC_BOOT)
 #undef CONFIG_ENV_IS_NOWHERE
 #define CONFIG_ENV_IS_IN_MMC
-#define CONFIG_SYS_MMC_ENV_DEV 1
+#define CONFIG_SYS_MMC_ENV_DEV 0
 #define CONFIG_SYS_MMC_ENV_PART2
 #define CONFIG_ENV_OFFSET  0x4 /* TODO: Adresse definieren */
 #define CONFIG_ENV_OFFSET_REDUND   (CONFIG_ENV_OFFSET + CONFIG_ENV_SIZE)
-- 
1.7.9.5

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

Re: [U-Boot] How to disable MAC address for usb_ether

[Albert ARIBAUD]

Hi Xuebing,

On Tue, 08 Apr 2014 11:13:04 +0800, Xuebing Wang 
wrote:

> Hi,
> 
> My board has one Ethernet, one USB Host and one USB Slave.
> 
> Command bdinfo shows below:
> 
> eth0name= cpsw
> ethaddr = 90:59:af:54:1a:28
> eth1name= usb_ether
> eth1addr= 90:59:af:54:1a:2a
> current eth = cpsw
> 
> Would you please teach me how to disable usb_ether MAC address, thus 
> bdinfo will show "eth1addr= (not set)"?
> 
> Thanks a lot.

Why do you want to unset the MAC address? Either you are using USB
Ethernet, and you need it to have a valid MAC, or you are not using it,
and eth1addr does not matter and can be safely ignored.

Still, you might want to try and check whether eth1addr is defined
in the environment (see env commands) and try to unset it -- but that
depends on which board exactly you are using and whether it is
supported by mainline U-Boot.

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

[U-Boot] [PATCH][v2] driver/net/fm/memac_phy: Initialize mdio_clock for SoCs wih FMANv3

[Priyanka Jain]

MDIO clock needs to be initialized in u-boot code for SoCs
having FMAN-v3(v3H or v3L) controller due to below reasons

-On SoCs that have FMAN-v3H  like B4860, default value of
MDIO_CLK_DIV bits in mdio_stat(mdio_cfg) register generates
mdio clock too high (much higher than 2.5MHz), violating the
IEEE specs.
-On SOCs that have FMAN-v3L like T1040, default value of
MDIO_CLK_DIV bits is zero, so MDIO clock is disabled.

So, for proper functioninig of MDIO, MDIO_CLK_DIV bits needs to
be properly initialized.
Also this type of initialization is generally done in
PBI(pre-bootloader) phase using rcw.But for chips like T1040
which support deep-sleep, such type of initialization cannot be
done in PBI phase due to the limitation that during deep-sleep
resume, FMAN (MDIO) registers are not accessible in PBI phase.
So, mdio clock initailization must be done as part of u-boot.

This initialization code is implemented in memac_phy.c which
gets compiled only for SoCs having FMANv3, so no extra compilation
flag is required.

Signed-off-by: Priyanka Jain 
---
 Changes for v2: Corrected Signed-off footer

 drivers/net/fm/memac_phy.c |   12 
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/drivers/net/fm/memac_phy.c b/drivers/net/fm/memac_phy.c
index 140e59b..2f4bc11 100644
--- a/drivers/net/fm/memac_phy.c
+++ b/drivers/net/fm/memac_phy.c
@@ -133,5 +133,17 @@ int fm_memac_mdio_init(bd_t *bis, struct memac_mdio_info 
*info)
 
bus->priv = info->regs;
 
+   /*
+* On some platforms like B4860, default value of MDIO_CLK_DIV bits
+* in mdio_stat(mdio_cfg) register generates MDIO clock too high
+* (much higher than 2.5MHz), violating the IEEE specs.
+* On other platforms like T1040, default value of MDIO_CLK_DIV bits
+* is zero, so MDIO clock is disabled.
+* So, for proper functioning of MDIO, MDIO_CLK_DIV bits needs to
+* be properly initialized.
+*/
+   setbits_be32(&((struct memac_mdio_controller *)info->regs)->mdio_stat,
+MDIO_STAT_CLKDIV(258));
+
return mdio_register(bus);
 }
-- 
1.7.4.1



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

Re: [U-Boot] [PATCH v2 3/5] spi: ti_qspi: Add delay for successful bulk erase.

[Sourav Poddar]

On Monday 07 April 2014 10:51 PM, Tom Rini wrote:

On Thu, Apr 03, 2014 at 08:45:42PM +0530, Jagan Teki wrote:

On Thu, Apr 3, 2014 at 5:22 PM, Tom Rini  wrote:

From: "Poddar, Sourav"

Bulk erase is not happening properly on dra7 due to erase timing constraints,
add a delay so that erase timing constraints are properly met.

Signed-off-by: Sourav Poddar
Tested-by: Yebio Mesfin
---
  drivers/spi/ti_qspi.c |3 +++
  1 file changed, 3 insertions(+)

diff --git a/drivers/spi/ti_qspi.c b/drivers/spi/ti_qspi.c
index dfa5d0c..c5d2245 100644
--- a/drivers/spi/ti_qspi.c
+++ b/drivers/spi/ti_qspi.c
@@ -314,6 +314,9 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen, 
const void *dout,
 qslave->cmd |= QSPI_RD_SNGL;
 debug("rx cmd %08x dc %08x\n",
   qslave->cmd, qslave->dc);
+   #ifdef CONFIG_DRA7XX
+   udelay(500);
+   #endif
 writel(qslave->cmd,&qslave->base->cmd);
 status = readl(&qslave->base->status);
 timeout = QSPI_TIMEOUT;

Can't we fix this? discussed the same in previous version thread as well.

Sorry, I kicked out v2 before checking my mbox again.  Sourav, do you
have some time to look at this again?

I can look at this sometime this week, but I am not sure if there is 
anything which
can be done. I had tried few stuffs to get rid of this in the past, but 
those attempts failed.
Still, I will check if there is anything more that can be done to get 
rid of this.

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

Re: [U-Boot] [PATCH v3 1/4]drivers: mmc: dwmmc: enable support for DT

[Beomho Seo]

Thank you for your advice.

On 04/08/2014 11:53 AM, Minkyu Kang wrote:
> Dear Beonho Seo,
> 
> On 20/03/14 13:14, Beomho Seo wrote:
>> This patch enables for device tree for dw-mmc driver.
>> Driver have been fixed because it is used exynos5 and exynos4.
>> Add, fdt compat id of exynos4 dwmmc.
>>
>> Signed-off-by: Beomho Seo 
>> Signed-off-by: Jaehoon Chung 
>> Tested-by: Piotr Wilczek 
>> Cc: Lukasz Majewski 
>> Cc: Piotr Wilczek 
>> Cc: Minkyu Kang 
>> ---
>> Changes for v3:
>> - None.
>>
>>  drivers/mmc/exynos_dw_mmc.c |   21 +
>>  include/fdtdec.h|1 +
>>  lib/fdtdec.c|1 +
>>  3 files changed, 19 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/mmc/exynos_dw_mmc.c b/drivers/mmc/exynos_dw_mmc.c
>> index de8cdcc..b9d41d4 100644
>> --- a/drivers/mmc/exynos_dw_mmc.c
>> +++ b/drivers/mmc/exynos_dw_mmc.c
>> @@ -13,6 +13,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>
>>  #define DWMMC_MAX_CH_NUM4
>>  #define DWMMC_MAX_FREQ  5200
>> @@ -82,6 +83,7 @@ int exynos_dwmci_add_port(int index, u32 regbase, int 
>> bus_width, u32 clksel)
>>  freq = 5200;
>>  sclk = get_mmc_clk(index);
>>  div = DIV_ROUND_UP(sclk, freq);
>> +div -= 1;
> 
> why?
> 

It need for set accurately required frequency.
Above code prevent to set below the required frequency.
For example above case,
If sclk is 100 MHz and required frequency 50 MHz, Where div = 2.
and then mmc clock set 33 MHz calculating.
So It need div minus one.

>>  /* set the clock divisor for mmc */
>>  set_mmc_clk(index, div);
>>
>> @@ -118,15 +120,21 @@ int exynos_dwmmc_init(const void *blob)
>>  {
>>  int index, bus_width;
>>  int node_list[DWMMC_MAX_CH_NUM];
>> -int err = 0, dev_id, flag, count, i;
>> +int err = 0, dev_id, flag, count, i, compat_id;
>>  u32 clksel_val, base, timing[3];
>>
>> +#ifdef CONFIG_EXYNOS4
>> +compat_id = COMPAT_SAMSUNG_EXYNOS4_DWMMC;
>> +#else
>> +compat_id = COMPAT_SAMSUNG_EXYNOS5_DWMMC;
>> +#endif
> 
> NAK.
> please don't use ifdef.
> 

OK. I will change it.

>> +
>>  count = fdtdec_find_aliases_for_id(blob, "mmc",
>> -COMPAT_SAMSUNG_EXYNOS5_DWMMC, node_list,
>> -DWMMC_MAX_CH_NUM);
>> +compat_id, node_list, DWMMC_MAX_CH_NUM);
>>
>>  for (i = 0; i < count; i++) {
>>  int node = node_list[i];
>> +struct fdt_gpio_state pwr_gpio;
>>
>>  if (node <= 0)
>>  continue;
>> @@ -145,6 +153,9 @@ int exynos_dwmmc_init(const void *blob)
>>  else
>>  flag = PINMUX_FLAG_NONE;
>>
>> +fdtdec_decode_gpio(blob, node, "pwr-gpios", &pwr_gpio);
>> +if (fdt_gpio_isvalid(&pwr_gpio))
>> +gpio_direction_output(pwr_gpio.gpio, 1);
> 
> please add blank line.
> 

OK. I will add blank line.

>>  /* config pinmux for each mmc channel */
>>  err = exynos_pinmux_config(dev_id, flag);
>>  if (err) {
>> @@ -152,7 +163,9 @@ int exynos_dwmmc_init(const void *blob)
>>  return err;
>>  }
>>
>> -index = dev_id - PERIPH_ID_SDMMC0;
>> +index = fdtdec_get_int(blob, node, "index", dev_id);
>> +if (index == dev_id)
>> +index = dev_id - PERIPH_ID_SDMMC0;
> 
> I can't understand why this routine is needed.
> Could you please explain?
> 

SDMMC index(0, 1 ... 4) is need to get/set mmc clk.
It is decided the difference between dev_id and PERIPH_ID_SDMMC0(=75).
But If dev_id is PERIPH_ID_SDMMC4(=131), index is set inaccurately.
So I add index property at device tree. and then parse it.
If index property not exist, index is decided the difference between dev_id and 
PERIPH_ID_SDMMC0.

>>
>>  /* Get the base address from the device node */
>>  base = fdtdec_get_addr(blob, node, "reg");
>> diff --git a/include/fdtdec.h b/include/fdtdec.h
>> index 63027bd..15f50fe 100644
>> --- a/include/fdtdec.h
>> +++ b/include/fdtdec.h
>> @@ -83,6 +83,7 @@ enum fdt_compat_id {
>>  COMPAT_SAMSUNG_EXYNOS5_DP,  /* Exynos Display port controller */
>>  COMPAT_SAMSUNG_EXYNOS5_DWMMC,   /* Exynos5 DWMMC controller */
>>  COMPAT_SAMSUNG_EXYNOS_MMC,  /* Exynos MMC controller */
>> +COMPAT_SAMSUNG_EXYNOS4_DWMMC,   /* Exynos4 DWMMC controller */
> 
> Do we need to separate exynos4 dwmmc and exynos5 dwmmc?
> 

OK, I will change and test it.

> Jaehoon,
> how you think?
> 
>>  COMPAT_SAMSUNG_EXYNOS_SERIAL,   /* Exynos UART */
>>  COMPAT_MAXIM_MAX77686_PMIC, /* MAX77686 PMIC */
>>  COMPAT_GENERIC_SPI_FLASH,   /* Generic SPI Flash chip */
>> diff --git a/lib/fdtdec.c b/lib/fdtdec.c
>> index be04598..79179cf 100644
>> --- a/lib/fdtdec.c
>> +++ b/lib/fdtdec.c
>> @@ -56,6 +56,7 @@ static const char * const compat_names[COMPAT_COUNT] = {
>>

Re: [U-Boot] [PATCH v3 1/4]drivers: mmc: dwmmc: enable support for DT

[Jaehoon Chung]

On 04/08/2014 11:53 AM, Minkyu Kang wrote:
> Dear Beonho Seo,
> 
> On 20/03/14 13:14, Beomho Seo wrote:
>> This patch enables for device tree for dw-mmc driver.
>> Driver have been fixed because it is used exynos5 and exynos4.
>> Add, fdt compat id of exynos4 dwmmc.
>>
>> Signed-off-by: Beomho Seo 
>> Signed-off-by: Jaehoon Chung 
>> Tested-by: Piotr Wilczek 
>> Cc: Lukasz Majewski 
>> Cc: Piotr Wilczek 
>> Cc: Minkyu Kang 
>> ---
>> Changes for v3:
>> - None.
>>
>>  drivers/mmc/exynos_dw_mmc.c |   21 +
>>  include/fdtdec.h|1 +
>>  lib/fdtdec.c|1 +
>>  3 files changed, 19 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/mmc/exynos_dw_mmc.c b/drivers/mmc/exynos_dw_mmc.c
>> index de8cdcc..b9d41d4 100644
>> --- a/drivers/mmc/exynos_dw_mmc.c
>> +++ b/drivers/mmc/exynos_dw_mmc.c
>> @@ -13,6 +13,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>
>>  #define DWMMC_MAX_CH_NUM4
>>  #define DWMMC_MAX_FREQ  5200
>> @@ -82,6 +83,7 @@ int exynos_dwmci_add_port(int index, u32 regbase, int 
>> bus_width, u32 clksel)
>>  freq = 5200;
>>  sclk = get_mmc_clk(index);
>>  div = DIV_ROUND_UP(sclk, freq);
>> +div -= 1;
> 
> why?
> 
>>  /* set the clock divisor for mmc */
>>  set_mmc_clk(index, div);
>>
>> @@ -118,15 +120,21 @@ int exynos_dwmmc_init(const void *blob)
>>  {
>>  int index, bus_width;
>>  int node_list[DWMMC_MAX_CH_NUM];
>> -int err = 0, dev_id, flag, count, i;
>> +int err = 0, dev_id, flag, count, i, compat_id;
>>  u32 clksel_val, base, timing[3];
>>
>> +#ifdef CONFIG_EXYNOS4
>> +compat_id = COMPAT_SAMSUNG_EXYNOS4_DWMMC;
>> +#else
>> +compat_id = COMPAT_SAMSUNG_EXYNOS5_DWMMC;
>> +#endif
> 
> NAK.
> please don't use ifdef.
In my patch, this is used  the below.
+
+   if (cpu_is_exynos4())
+   compat_id = COMPAT_SAMSUNG_EXYNOS4_DWMMC;
+   else if (cpu_is_exynos5())
+   compat_id = COMPAT_SAMSUNG_EXYNOS5_DWMMC;
+   else
+   compat_id = COMPAT_UNKNOWN;
+
> 
>> +
>>  count = fdtdec_find_aliases_for_id(blob, "mmc",
>> -COMPAT_SAMSUNG_EXYNOS5_DWMMC, node_list,
>> -DWMMC_MAX_CH_NUM);
>> +compat_id, node_list, DWMMC_MAX_CH_NUM);
>>
>>  for (i = 0; i < count; i++) {
>>  int node = node_list[i];
>> +struct fdt_gpio_state pwr_gpio;
>>
>>  if (node <= 0)
>>  continue;
>> @@ -145,6 +153,9 @@ int exynos_dwmmc_init(const void *blob)
>>  else
>>  flag = PINMUX_FLAG_NONE;
>>
>> +fdtdec_decode_gpio(blob, node, "pwr-gpios", &pwr_gpio);
>> +if (fdt_gpio_isvalid(&pwr_gpio))
>> +gpio_direction_output(pwr_gpio.gpio, 1);
> 
> please add blank line.
> 
>>  /* config pinmux for each mmc channel */
>>  err = exynos_pinmux_config(dev_id, flag);
>>  if (err) {
>> @@ -152,7 +163,9 @@ int exynos_dwmmc_init(const void *blob)
>>  return err;
>>  }
>>
>> -index = dev_id - PERIPH_ID_SDMMC0;
>> +index = fdtdec_get_int(blob, node, "index", dev_id);
>> +if (index == dev_id)
>> +index = dev_id - PERIPH_ID_SDMMC0;
> 
> I can't understand why this routine is needed.
> Could you please explain?
> 
>>
>>  /* Get the base address from the device node */
>>  base = fdtdec_get_addr(blob, node, "reg");
>> diff --git a/include/fdtdec.h b/include/fdtdec.h
>> index 63027bd..15f50fe 100644
>> --- a/include/fdtdec.h
>> +++ b/include/fdtdec.h
>> @@ -83,6 +83,7 @@ enum fdt_compat_id {
>>  COMPAT_SAMSUNG_EXYNOS5_DP,  /* Exynos Display port controller */
>>  COMPAT_SAMSUNG_EXYNOS5_DWMMC,   /* Exynos5 DWMMC controller */
>>  COMPAT_SAMSUNG_EXYNOS_MMC,  /* Exynos MMC controller */
>> +COMPAT_SAMSUNG_EXYNOS4_DWMMC,   /* Exynos4 DWMMC controller */
> 
> Do we need to separate exynos4 dwmmc and exynos5 dwmmc?
It didn't need to separate.

Best Regards,
Jaehoon Chung

> 
> Jaehoon,
> how you think?
> 
>>  COMPAT_SAMSUNG_EXYNOS_SERIAL,   /* Exynos UART */
>>  COMPAT_MAXIM_MAX77686_PMIC, /* MAX77686 PMIC */
>>  COMPAT_GENERIC_SPI_FLASH,   /* Generic SPI Flash chip */
>> diff --git a/lib/fdtdec.c b/lib/fdtdec.c
>> index be04598..79179cf 100644
>> --- a/lib/fdtdec.c
>> +++ b/lib/fdtdec.c
>> @@ -56,6 +56,7 @@ static const char * const compat_names[COMPAT_COUNT] = {
>>  COMPAT(SAMSUNG_EXYNOS5_DP, "samsung,exynos5-dp"),
>>  COMPAT(SAMSUNG_EXYNOS5_DWMMC, "samsung,exynos5250-dwmmc"),
>>  COMPAT(SAMSUNG_EXYNOS_MMC, "samsung,exynos-mmc"),
>> +COMPAT(SAMSUNG_EXYNOS4_DWMMC, "samsung,exynos4412-dwmmc"),
>>  COMPAT(SAMSUNG_EXYNOS_SERIAL, "samsung,exynos4210-uart"),
>>  COMPAT(MAXIM_MAX77686_PMIC, "maxim,max77686_pmic"),
>>  COMPAT(GENER

[U-Boot] How to disable MAC address for usb_ether

[Xuebing Wang]

Hi,

My board has one Ethernet, one USB Host and one USB Slave.

Command bdinfo shows below:

eth0name= cpsw
ethaddr = 90:59:af:54:1a:28
eth1name= usb_ether
eth1addr= 90:59:af:54:1a:2a
current eth = cpsw

Would you please teach me how to disable usb_ether MAC address, thus 
bdinfo will show "eth1addr= (not set)"?


Thanks a lot.

--
Thanks,
Xuebing Wang

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

[U-Boot] mx28: U-Boot fails to boot with VDD5V only power configuration

[Ankur Patel]

Dear Friends,

I'm bringing up a custom i.MX28 based board.  I'm having trouble bringing up 
the u-boot (version v2013.04) loader.  The Powersupply has been design as 
detailed in section 4.1.2.1 (VDD5V source only) of application note AN4199:

http://www.freescale.com/files/32bit/doc/app_note/AN4199.pdf

I am referring Patch 
L2.6.35_10.12_SDK_5V_SUPPLY_PATCH.tar.gz
 at freescale website which is for bootlets with VDD5V only support. I have 
even applied the patch to bootlet code imx-bootlets-src-10.12.01.tar.gz which 
is working fine.

Based on the bootlet patch, I have modified the u-boot code but I couldn't able 
to boot. Please find the u-boot patch at http://pastebin.com/VudxqTHQ

Can anyone please review it and share what is missing in the patch?

Regards,

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

Re: [U-Boot] {PATCH v3 3/4] arm: exynos: clock: Remove exynos4x12_set_mmc_clk function

[Beomho Seo]

On 04/08/2014 11:53 AM, Minkyu Kang wrote:
> Dear Beomho Seo,
> 
> On 20/03/14 13:14, Beomho Seo wrote:
>> exynos4x12_set_mmc_clk function have been removed.
>> Because, exynos4x12_clock and exynos4_clock return smae div_fsys* value.
> 
> typo, smae -> same?
> 

Thank you. I will fix this mistake.

>>
>> Signed-off-by: Beomho Seo 
>> Signed-off-by: Jaehoon Chung 
>> Tested-by: Piotr Wilczek 
>> Cc: Lukasz Majewski 
>> Cc: Piotr Wilczek 
>> Cc: Minkyu Kang 
>> ---
>> Changes for v3:
>> - None.
>>
>> Changes for v2:
>> - None.
>>
>>  arch/arm/cpu/armv7/exynos/clock.c |   29 +
>>  1 file changed, 1 insertion(+), 28 deletions(-)
>>
>> diff --git a/arch/arm/cpu/armv7/exynos/clock.c 
>> b/arch/arm/cpu/armv7/exynos/clock.c
>> index 1fea4d6..2c2029a 100644
>> --- a/arch/arm/cpu/armv7/exynos/clock.c
>> +++ b/arch/arm/cpu/armv7/exynos/clock.c
>> @@ -893,30 +893,6 @@ static void exynos4_set_mmc_clk(int dev_index, unsigned 
>> int div)
>>  (div & 0xff) << ((dev_index << 4) + 8));
>>  }
>>
>> -/* exynos4x12: set the mmc clock */
>> -static void exynos4x12_set_mmc_clk(int dev_index, unsigned int div)
>> -{
>> -struct exynos4x12_clock *clk =
>> -(struct exynos4x12_clock *)samsung_get_base_clock();
>> -unsigned int addr;
>> -
>> -/*
>> - * CLK_DIV_FSYS1
>> - * MMC0_PRE_RATIO [15:8], MMC1_PRE_RATIO [31:24]
>> - * CLK_DIV_FSYS2
>> - * MMC2_PRE_RATIO [15:8], MMC3_PRE_RATIO [31:24]
>> - */
>> -if (dev_index < 2) {
>> -addr = (unsigned int)&clk->div_fsys1;
>> -} else {
>> -addr = (unsigned int)&clk->div_fsys2;
>> -dev_index -= 2;
>> -}
>> -
>> -clrsetbits_le32(addr, 0xff << ((dev_index << 4) + 8),
>> -(div & 0xff) << ((dev_index << 4) + 8));
>> -}
>> -
>>  /* exynos5: set the mmc clock */
>>  static void exynos5_set_mmc_clk(int dev_index, unsigned int div)
>>  {
>> @@ -1612,10 +1588,7 @@ void set_mmc_clk(int dev_index, unsigned int div)
>>  else
>>  exynos5_set_mmc_clk(dev_index, div);
>>  } else {
>> -if (proid_is_exynos4412())
>> -exynos4x12_set_mmc_clk(dev_index, div);
>> -else
>> -exynos4_set_mmc_clk(dev_index, div);
>> +exynos4_set_mmc_clk(dev_index, div);
>>  }
>>  }
>>
> 
> Thanks,
> Minkyu Kang.
> 

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

Re: [U-Boot] {PATCH v3 3/4] arm: exynos: clock: Remove exynos4x12_set_mmc_clk function

[Minkyu Kang]

Dear Beomho Seo,

On 20/03/14 13:14, Beomho Seo wrote:
> exynos4x12_set_mmc_clk function have been removed.
> Because, exynos4x12_clock and exynos4_clock return smae div_fsys* value.

typo, smae -> same?

> 
> Signed-off-by: Beomho Seo 
> Signed-off-by: Jaehoon Chung 
> Tested-by: Piotr Wilczek 
> Cc: Lukasz Majewski 
> Cc: Piotr Wilczek 
> Cc: Minkyu Kang 
> ---
> Changes for v3:
> - None.
> 
> Changes for v2:
> - None.
> 
>  arch/arm/cpu/armv7/exynos/clock.c |   29 +
>  1 file changed, 1 insertion(+), 28 deletions(-)
> 
> diff --git a/arch/arm/cpu/armv7/exynos/clock.c 
> b/arch/arm/cpu/armv7/exynos/clock.c
> index 1fea4d6..2c2029a 100644
> --- a/arch/arm/cpu/armv7/exynos/clock.c
> +++ b/arch/arm/cpu/armv7/exynos/clock.c
> @@ -893,30 +893,6 @@ static void exynos4_set_mmc_clk(int dev_index, unsigned 
> int div)
>   (div & 0xff) << ((dev_index << 4) + 8));
>  }
> 
> -/* exynos4x12: set the mmc clock */
> -static void exynos4x12_set_mmc_clk(int dev_index, unsigned int div)
> -{
> - struct exynos4x12_clock *clk =
> - (struct exynos4x12_clock *)samsung_get_base_clock();
> - unsigned int addr;
> -
> - /*
> -  * CLK_DIV_FSYS1
> -  * MMC0_PRE_RATIO [15:8], MMC1_PRE_RATIO [31:24]
> -  * CLK_DIV_FSYS2
> -  * MMC2_PRE_RATIO [15:8], MMC3_PRE_RATIO [31:24]
> -  */
> - if (dev_index < 2) {
> - addr = (unsigned int)&clk->div_fsys1;
> - } else {
> - addr = (unsigned int)&clk->div_fsys2;
> - dev_index -= 2;
> - }
> -
> - clrsetbits_le32(addr, 0xff << ((dev_index << 4) + 8),
> - (div & 0xff) << ((dev_index << 4) + 8));
> -}
> -
>  /* exynos5: set the mmc clock */
>  static void exynos5_set_mmc_clk(int dev_index, unsigned int div)
>  {
> @@ -1612,10 +1588,7 @@ void set_mmc_clk(int dev_index, unsigned int div)
>   else
>   exynos5_set_mmc_clk(dev_index, div);
>   } else {
> - if (proid_is_exynos4412())
> - exynos4x12_set_mmc_clk(dev_index, div);
> - else
> - exynos4_set_mmc_clk(dev_index, div);
> + exynos4_set_mmc_clk(dev_index, div);
>   }
>  }
> 

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

Re: [U-Boot] [PATCH v3 1/4]drivers: mmc: dwmmc: enable support for DT

[Minkyu Kang]

Dear Beonho Seo,

On 20/03/14 13:14, Beomho Seo wrote:
> This patch enables for device tree for dw-mmc driver.
> Driver have been fixed because it is used exynos5 and exynos4.
> Add, fdt compat id of exynos4 dwmmc.
> 
> Signed-off-by: Beomho Seo 
> Signed-off-by: Jaehoon Chung 
> Tested-by: Piotr Wilczek 
> Cc: Lukasz Majewski 
> Cc: Piotr Wilczek 
> Cc: Minkyu Kang 
> ---
> Changes for v3:
> - None.
> 
>  drivers/mmc/exynos_dw_mmc.c |   21 +
>  include/fdtdec.h|1 +
>  lib/fdtdec.c|1 +
>  3 files changed, 19 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/mmc/exynos_dw_mmc.c b/drivers/mmc/exynos_dw_mmc.c
> index de8cdcc..b9d41d4 100644
> --- a/drivers/mmc/exynos_dw_mmc.c
> +++ b/drivers/mmc/exynos_dw_mmc.c
> @@ -13,6 +13,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #define  DWMMC_MAX_CH_NUM4
>  #define  DWMMC_MAX_FREQ  5200
> @@ -82,6 +83,7 @@ int exynos_dwmci_add_port(int index, u32 regbase, int 
> bus_width, u32 clksel)
>   freq = 5200;
>   sclk = get_mmc_clk(index);
>   div = DIV_ROUND_UP(sclk, freq);
> + div -= 1;

why?

>   /* set the clock divisor for mmc */
>   set_mmc_clk(index, div);
> 
> @@ -118,15 +120,21 @@ int exynos_dwmmc_init(const void *blob)
>  {
>   int index, bus_width;
>   int node_list[DWMMC_MAX_CH_NUM];
> - int err = 0, dev_id, flag, count, i;
> + int err = 0, dev_id, flag, count, i, compat_id;
>   u32 clksel_val, base, timing[3];
> 
> +#ifdef CONFIG_EXYNOS4
> + compat_id = COMPAT_SAMSUNG_EXYNOS4_DWMMC;
> +#else
> + compat_id = COMPAT_SAMSUNG_EXYNOS5_DWMMC;
> +#endif

NAK.
please don't use ifdef.

> +
>   count = fdtdec_find_aliases_for_id(blob, "mmc",
> - COMPAT_SAMSUNG_EXYNOS5_DWMMC, node_list,
> - DWMMC_MAX_CH_NUM);
> + compat_id, node_list, DWMMC_MAX_CH_NUM);
> 
>   for (i = 0; i < count; i++) {
>   int node = node_list[i];
> + struct fdt_gpio_state pwr_gpio;
> 
>   if (node <= 0)
>   continue;
> @@ -145,6 +153,9 @@ int exynos_dwmmc_init(const void *blob)
>   else
>   flag = PINMUX_FLAG_NONE;
> 
> + fdtdec_decode_gpio(blob, node, "pwr-gpios", &pwr_gpio);
> + if (fdt_gpio_isvalid(&pwr_gpio))
> + gpio_direction_output(pwr_gpio.gpio, 1);

please add blank line.

>   /* config pinmux for each mmc channel */
>   err = exynos_pinmux_config(dev_id, flag);
>   if (err) {
> @@ -152,7 +163,9 @@ int exynos_dwmmc_init(const void *blob)
>   return err;
>   }
> 
> - index = dev_id - PERIPH_ID_SDMMC0;
> + index = fdtdec_get_int(blob, node, "index", dev_id);
> + if (index == dev_id)
> + index = dev_id - PERIPH_ID_SDMMC0;

I can't understand why this routine is needed.
Could you please explain?

> 
>   /* Get the base address from the device node */
>   base = fdtdec_get_addr(blob, node, "reg");
> diff --git a/include/fdtdec.h b/include/fdtdec.h
> index 63027bd..15f50fe 100644
> --- a/include/fdtdec.h
> +++ b/include/fdtdec.h
> @@ -83,6 +83,7 @@ enum fdt_compat_id {
>   COMPAT_SAMSUNG_EXYNOS5_DP,  /* Exynos Display port controller */
>   COMPAT_SAMSUNG_EXYNOS5_DWMMC,   /* Exynos5 DWMMC controller */
>   COMPAT_SAMSUNG_EXYNOS_MMC,  /* Exynos MMC controller */
> + COMPAT_SAMSUNG_EXYNOS4_DWMMC,   /* Exynos4 DWMMC controller */

Do we need to separate exynos4 dwmmc and exynos5 dwmmc?

Jaehoon,
how you think?

>   COMPAT_SAMSUNG_EXYNOS_SERIAL,   /* Exynos UART */
>   COMPAT_MAXIM_MAX77686_PMIC, /* MAX77686 PMIC */
>   COMPAT_GENERIC_SPI_FLASH,   /* Generic SPI Flash chip */
> diff --git a/lib/fdtdec.c b/lib/fdtdec.c
> index be04598..79179cf 100644
> --- a/lib/fdtdec.c
> +++ b/lib/fdtdec.c
> @@ -56,6 +56,7 @@ static const char * const compat_names[COMPAT_COUNT] = {
>   COMPAT(SAMSUNG_EXYNOS5_DP, "samsung,exynos5-dp"),
>   COMPAT(SAMSUNG_EXYNOS5_DWMMC, "samsung,exynos5250-dwmmc"),
>   COMPAT(SAMSUNG_EXYNOS_MMC, "samsung,exynos-mmc"),
> + COMPAT(SAMSUNG_EXYNOS4_DWMMC, "samsung,exynos4412-dwmmc"),
>   COMPAT(SAMSUNG_EXYNOS_SERIAL, "samsung,exynos4210-uart"),
>   COMPAT(MAXIM_MAX77686_PMIC, "maxim,max77686_pmic"),
>   COMPAT(GENERIC_SPI_FLASH, "spi-flash"),
> 

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

[U-Boot] [PATCH 8/8] arm: rmobile: lager: Remove MACH_TYPE_LAGER and CONFIG_MACH_TYPE

[Nobuhiro Iwamatsu]

MACH_TYPE_LAGER and CONFIG_MACH_TYPE are not already available on Lager board.
This removes them.

Signed-off-by: Nobuhiro Iwamatsu 
---
 board/renesas/lager/lager.c | 2 --
 include/configs/lager.h | 2 --
 2 files changed, 4 deletions(-)

diff --git a/board/renesas/lager/lager.c b/board/renesas/lager/lager.c
index 898fb57..a5a0474 100644
--- a/board/renesas/lager/lager.c
+++ b/board/renesas/lager/lager.c
@@ -85,8 +85,6 @@ void arch_preboot_os(void)
 DECLARE_GLOBAL_DATA_PTR;
 int board_init(void)
 {
-   /* board id for linux */
-   gd->bd->bi_arch_number = MACH_TYPE_LAGER;
/* adress of boot parameters */
gd->bd->bi_boot_params = LAGER_SDRAM_BASE + 0x100;
 
diff --git a/include/configs/lager.h b/include/configs/lager.h
index 269cfec..ac31128 100644
--- a/include/configs/lager.h
+++ b/include/configs/lager.h
@@ -16,8 +16,6 @@
 #define CONFIG_RMOBILE
 #define CONFIG_RMOBILE_BOARD_STRING "Lager"
 #define CONFIG_SH_GPIO_PFC
-#define MACH_TYPE_LAGER4538
-#define CONFIG_MACH_TYPE   MACH_TYPE_LAGER
 
 #include 
 
-- 
1.8.5

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

[U-Boot] [PATCH 7/8] arm: rmobile: lager: Change to maximum CPU frequency

[Nobuhiro Iwamatsu]

Maximum CPU clock of R8A7790 that are used in lager board is 1.4GHz.
This change to use the maximum clock in this board.

Signed-off-by: Nobuhiro Iwamatsu 
---
 board/renesas/lager/lager.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/board/renesas/lager/lager.c b/board/renesas/lager/lager.c
index 959f46a..898fb57 100644
--- a/board/renesas/lager/lager.c
+++ b/board/renesas/lager/lager.c
@@ -24,15 +24,21 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
+#define CLK2MHZ(clk)   (clk / 1000 / 1000)
 void s_init(void)
 {
struct rcar_rwdt *rwdt = (struct rcar_rwdt *)RWDT_BASE;
struct rcar_swdt *swdt = (struct rcar_swdt *)SWDT_BASE;
+   u32 stc;
 
/* Watchdog init */
writel(0xA5A5A500, &rwdt->rwtcsra);
writel(0xA5A5A500, &swdt->swtcsra);
 
+   /* CPU frequency setting. Set to 1.4GHz */
+   stc = ((1500 / CLK2MHZ(CONFIG_SYS_CLK_FREQ)) - 1) << PLL0_STC_BIT;
+   clrsetbits_le32(PLL0CR, PLL0_STC_MASK, stc);
+
/* QoS(Quality-of-Service) Init */
qos_init();
 }
-- 
1.8.5

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

[U-Boot] [PATCH 6/8] arm: rmobile: lager: Update calculation of CONFIG_SH_TMU_CLK_FREQ

[Nobuhiro Iwamatsu]

CONFIG_SH_TMU_CLK_FREQ of lager is calculated from the external clock.
This defines RMOBILE_XTAL_CLK, this updates the calculation of
CONFIG_SH_TMU_CLK_FREQ.

Signed-off-by: Nobuhiro Iwamatsu 
---
 include/configs/lager.h | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/include/configs/lager.h b/include/configs/lager.h
index 5ddefef..269cfec 100644
--- a/include/configs/lager.h
+++ b/include/configs/lager.h
@@ -155,9 +155,10 @@
 #define CONFIG_SYS_I2C_POWERIC_ADDR 0x58 /* da9063 */
 
 /* Board Clock */
-#define CONFIG_BASE_CLK_FREQ   2000u
-#define CONFIG_SH_TMU_CLK_FREQ (CONFIG_BASE_CLK_FREQ / 2) /* EXT / 2 */
-#define CONFIG_PLL1_CLK_FREQ   (CONFIG_BASE_CLK_FREQ * 156 / 2)
+#define RMOBILE_XTAL_CLK   2000u
+#define CONFIG_SYS_CLK_FREQRMOBILE_XTAL_CLK
+#define CONFIG_SH_TMU_CLK_FREQ (CONFIG_SYS_CLK_FREQ / 2) /* EXT / 2 */
+#define CONFIG_PLL1_CLK_FREQ   (CONFIG_SYS_CLK_FREQ * 156 / 2)
 #define CONFIG_PLL1_DIV2_CLK_FREQ  (CONFIG_PLL1_CLK_FREQ / 2)
 #define CONFIG_MP_CLK_FREQ (CONFIG_PLL1_DIV2_CLK_FREQ / 15)
 #define CONFIG_HP_CLK_FREQ (CONFIG_PLL1_CLK_FREQ / 12)
-- 
1.8.5

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

[U-Boot] [PATCH 1/8] arm: rmobile: lager: Update QoS initialization to version 0.955

[Nobuhiro Iwamatsu]

Signed-off-by: Nobuhiro Iwamatsu 
---
 board/renesas/lager/qos.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/board/renesas/lager/qos.c b/board/renesas/lager/qos.c
index f1ac060..3742757 100644
--- a/board/renesas/lager/qos.c
+++ b/board/renesas/lager/qos.c
@@ -12,7 +12,7 @@
 #include 
 #include 
 
-/* QoS version 0.954 */
+/* QoS version 0.955 */
 
 enum {
DBSC3_R00, DBSC3_R01, DBSC3_R02, DBSC3_R03, DBSC3_R04,
@@ -475,7 +475,7 @@ void qos_init(void)
axi_qos = (struct rcar_axi_qos *)MP_AXI_ASDS0_BASE;
writel(0x0001, &axi_qos->qosconf);
writel(0x2014, &axi_qos->qosctset0);
-   writel(0x0001, &axi_qos->qosreqctr);
+   writel(0x0040, &axi_qos->qosreqctr);
writel(0x2006, &axi_qos->qosthres0);
writel(0x2001, &axi_qos->qosthres1);
writel(0x, &axi_qos->qosthres2);
@@ -484,19 +484,19 @@ void qos_init(void)
axi_qos = (struct rcar_axi_qos *)MP_AXI_ASDS1_BASE;
writel(0x0001, &axi_qos->qosconf);
writel(0x2014, &axi_qos->qosctset0);
-   writel(0x0001, &axi_qos->qosreqctr);
+   writel(0x0040, &axi_qos->qosreqctr);
writel(0x2006, &axi_qos->qosthres0);
writel(0x2001, &axi_qos->qosthres1);
writel(0x, &axi_qos->qosthres2);
writel(0x0001, &axi_qos->qosqon);
 
axi_qos = (struct rcar_axi_qos *)MP_AXI_MLP_BASE;
-   writel(0x, &axi_qos->qosconf);
-   writel(0x2002, &axi_qos->qosctset0);
-   writel(0x0001, &axi_qos->qosreqctr);
+   writel(0x0001, &axi_qos->qosconf);
+   writel(0x1FF0, &axi_qos->qosctset0);
+   writel(0x0020, &axi_qos->qosreqctr);
writel(0x2006, &axi_qos->qosthres0);
writel(0x2001, &axi_qos->qosthres1);
-   writel(0x, &axi_qos->qosthres2);
+   writel(0x2001, &axi_qos->qosthres2);
writel(0x0001, &axi_qos->qosqon);
 
axi_qos = (struct rcar_axi_qos *)MP_AXI_MMUMP_BASE;
-- 
1.8.5

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

[U-Boot] [PATCH 3/8] arm: rmobile: koelsch: Update calculation of CONFIG_SH_TMU_CLK_FREQ

[Nobuhiro Iwamatsu]

CONFIG_SH_TMU_CLK_FREQ of koelsch is calculated from the external clock.
This defines RMOBILE_XTAL_CLK, this updates the calculation of
CONFIG_SH_TMU_CLK_FREQ.

Signed-off-by: Nobuhiro Iwamatsu 
---
 include/configs/koelsch.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/include/configs/koelsch.h b/include/configs/koelsch.h
index 7db6086..1a93d17 100644
--- a/include/configs/koelsch.h
+++ b/include/configs/koelsch.h
@@ -135,8 +135,9 @@
 #define CONFIG_SH_ETHER_ALIGNE_SIZE 64
 
 /* Board Clock */
-#defineCONFIG_SYS_CLK_FREQ 1000
-#define CONFIG_SH_TMU_CLK_FREQ CONFIG_SYS_CLK_FREQ
+#define RMOBILE_XTAL_CLK   2000u
+#define CONFIG_SYS_CLK_FREQRMOBILE_XTAL_CLK
+#define CONFIG_SH_TMU_CLK_FREQ (CONFIG_SYS_CLK_FREQ / 2)
 #define CONFIG_SH_SCIF_CLK_FREQ14745600
 #define CONFIG_SYS_TMU_CLK_DIV 4
 
-- 
1.8.5

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

[U-Boot] [PATCH 4/8] arm: rmobile: Add register infomation of PLL regsiter

[Nobuhiro Iwamatsu]

Signed-off-by: Nobuhiro Iwamatsu 
---
 arch/arm/include/asm/arch-rmobile/rcar-base.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/include/asm/arch-rmobile/rcar-base.h 
b/arch/arm/include/asm/arch-rmobile/rcar-base.h
index 371f0ed..4331d31 100644
--- a/arch/arm/include/asm/arch-rmobile/rcar-base.h
+++ b/arch/arm/include/asm/arch-rmobile/rcar-base.h
@@ -374,6 +374,10 @@
 #define CCI_AXI_IPMMUDSDVMCR   0xFF880414
 #define CCI_AXI_AX2ADDRMASK0xFF88041C
 
+#define PLL0CR 0xE61500D8
+#define PLL0_STC_MASK  0x7F00
+#define PLL0_STC_BIT   24
+
 #ifndef __ASSEMBLY__
 #include 
 
-- 
1.8.5

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

[U-Boot] [PATCH 5/8] arm: rmobile: koelsch: Change to maximum CPU frequency

[Nobuhiro Iwamatsu]

Maximum CPU clock of R8A7791 that are used in koelsch board is 1.5GHz.
This change to use the maximum clock in this board.

Signed-off-by: Nobuhiro Iwamatsu 
---
 board/renesas/koelsch/koelsch.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/board/renesas/koelsch/koelsch.c b/board/renesas/koelsch/koelsch.c
index d4f6372..bfd0cc6 100644
--- a/board/renesas/koelsch/koelsch.c
+++ b/board/renesas/koelsch/koelsch.c
@@ -19,19 +19,26 @@
 #include 
 #include 
 #include 
+#include 
 #include "qos.h"
 
 DECLARE_GLOBAL_DATA_PTR;
 
+#define CLK2MHZ(clk)   (clk / 1000 / 1000)
 void s_init(void)
 {
struct rcar_rwdt *rwdt = (struct rcar_rwdt *)RWDT_BASE;
struct rcar_swdt *swdt = (struct rcar_swdt *)SWDT_BASE;
+   u32 stc;
 
/* Watchdog init */
writel(0xA5A5A500, &rwdt->rwtcsra);
writel(0xA5A5A500, &swdt->swtcsra);
 
+   /* CPU frequency setting. Set to 1.5GHz */
+   stc = ((1500 / CLK2MHZ(CONFIG_SYS_CLK_FREQ)) - 1) << PLL0_STC_BIT;
+   clrsetbits_le32(PLL0CR, PLL0_STC_MASK, stc);
+
/* QoS */
qos_init();
 }
-- 
1.8.5

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

[U-Boot] [PATCH 2/8] arm: rmobile: koelsch: Update QoS initialization

[Nobuhiro Iwamatsu]

This update QoS version 0.240 for ES1 and version 0.310 for ES2.

Signed-off-by: Nobuhiro Iwamatsu 
---
 board/renesas/koelsch/qos.c | 29 -
 1 file changed, 12 insertions(+), 17 deletions(-)

diff --git a/board/renesas/koelsch/qos.c b/board/renesas/koelsch/qos.c
index d82bf8b..e6c5e48 100644
--- a/board/renesas/koelsch/qos.c
+++ b/board/renesas/koelsch/qos.c
@@ -13,7 +13,7 @@
 #include 
 #include 
 
-/* QoS version 0.23 for ES1 and version 0.303 for ES2 */
+/* QoS version 0.240 for ES1 and version 0.310 for ES2 */
 
 enum {
DBSC3_00, DBSC3_01, DBSC3_02, DBSC3_03, DBSC3_04,
@@ -233,13 +233,11 @@ void qos_init(void)
writel(0x0001, &qos_addr->dblgqon);
}
 
-   if (!IS_R8A7791_ES2()) {
-   /* CCI-400 -QoS */
-   writel(0x20001000, CCI_400_MAXOT_1);
-   writel(0x20001000, CCI_400_MAXOT_2);
-   writel(0x000C, CCI_400_QOSCNTL_1);
-   writel(0x000C, CCI_400_QOSCNTL_2);
-   }
+   /* CCI-400 -QoS */
+   writel(0x20001000, CCI_400_MAXOT_1);
+   writel(0x20001000, CCI_400_MAXOT_2);
+   writel(0x000C, CCI_400_QOSCNTL_1);
+   writel(0x000C, CCI_400_QOSCNTL_2);
 
/* MXI -QoS */
/* Transaction Control (MXI) */
@@ -700,9 +698,6 @@ void qos_init(void)
axi_qos = (struct rcar_axi_qos *)RT_AXI_SY2RT_BASE;
writel(0x0002, &axi_qos->qosconf);
writel(0x2245, &axi_qos->qosctset0);
-   writel(0x2096, &axi_qos->qosctset1);
-   writel(0x2030, &axi_qos->qosctset2);
-   writel(0x2030, &axi_qos->qosctset3);
writel(0x0001, &axi_qos->qosreqctr);
writel(0x2064, &axi_qos->qosthres0);
writel(0x2004, &axi_qos->qosthres1);
@@ -722,7 +717,7 @@ void qos_init(void)
axi_qos = (struct rcar_axi_qos *)MP_AXI_ASDS0_BASE;
writel(0x0001, &axi_qos->qosconf);
writel(0x2014, &axi_qos->qosctset0);
-   writel(0x0001, &axi_qos->qosreqctr);
+   writel(0x0040, &axi_qos->qosreqctr);
writel(0x2064, &axi_qos->qosthres0);
writel(0x2004, &axi_qos->qosthres1);
writel(0x, &axi_qos->qosthres2);
@@ -731,19 +726,19 @@ void qos_init(void)
axi_qos = (struct rcar_axi_qos *)MP_AXI_ASDS1_BASE;
writel(0x0001, &axi_qos->qosconf);
writel(0x2014, &axi_qos->qosctset0);
-   writel(0x0001, &axi_qos->qosreqctr);
+   writel(0x0040, &axi_qos->qosreqctr);
writel(0x2064, &axi_qos->qosthres0);
writel(0x2004, &axi_qos->qosthres1);
writel(0x, &axi_qos->qosthres2);
writel(0x0001, &axi_qos->qosqon);
 
axi_qos = (struct rcar_axi_qos *)MP_AXI_MLP_BASE;
-   writel(0x, &axi_qos->qosconf);
-   writel(0x2014, &axi_qos->qosctset0);
-   writel(0x0001, &axi_qos->qosreqctr);
+   writel(0x0001, &axi_qos->qosconf);
+   writel(0x1FF0, &axi_qos->qosctset0);
+   writel(0x0020, &axi_qos->qosreqctr);
writel(0x2064, &axi_qos->qosthres0);
writel(0x2004, &axi_qos->qosthres1);
-   writel(0x, &axi_qos->qosthres2);
+   writel(0x2001, &axi_qos->qosthres2);
writel(0x0001, &axi_qos->qosqon);
 
axi_qos = (struct rcar_axi_qos *)MP_AXI_MMUMP_BASE;
-- 
1.8.5

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

Re: [U-Boot] Modify go to allow chain loading a second u-boot

[Simon Glass]

Hi,

On 3 April 2014 03:40, Helmut Raiger  wrote:

> Hi,
>
>   for all the wrong reasons I have to load a second u-boot from a first
> one.
>
> I'm finally able to start it, but it only works if I do a
> cleanup_before_linux(),
> i.e. turn off interrupts and caches before the actual 'go'.
>
> For testing I patched the go command, but obviously this can't be
> contributed as such.
>
> Anyone having a suggestion on how to do this?
>
> 1) add option to 'go' command, which is hard as it has variable arguments
>

This seems best to me if you don't want to add a new command. Maybe you
could add a '-c' argument to cleanup?


> 2) add another go command
> 3) use an environment variable to set the option for 'go'


> Theoretically I could use an u-boot image to encapsulate the second u-boot
> and use 'bootm', but I think I'll stumble over the same kind of questions.
>
> Helmut
> PS: this is a re-post (the original one hung on-to the thread where I
> asked for help in the first place).
>
>
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2] fs: fat: Fix cache align error message in fatwrite

[Nobuhiro Iwamatsu]

Use of malloc of do_fat_write() causes cache error on ARM v7 platforms.
Perhaps, the same problem will occur at any other CPUs.
This replaces malloc with memalign to fix cache buffer alignment.

Signed-off-by: Nobuhiro Iwamatsu 
Signed-off-by: Yoshiyuki Ito 
Tested-by: Hector Palacios 
---
 v2: Fix commit message.

 fs/fat/fat_write.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c
index 9f5e911..cef138e 100644
--- a/fs/fat/fat_write.c
+++ b/fs/fat/fat_write.c
@@ -952,7 +952,7 @@ static int do_fat_write(const char *filename, void *buffer,
}
 
mydata->fatbufnum = -1;
-   mydata->fatbuf = malloc(FATBUFSIZE);
+   mydata->fatbuf = memalign(ARCH_DMA_MINALIGN, FATBUFSIZE);
if (mydata->fatbuf == NULL) {
debug("Error: allocating memory\n");
return -1;
-- 
1.8.5

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

Re: [U-Boot] [PATCH] fs: fat: Fix cache align error message in fatwrite to use USB media

[Nobuhiro Iwamatsu]

Hi!

2014-04-07 23:19 GMT+09:00 Hector Palacios :
> Hello,
>
>
> On 04/03/2014 06:44 AM, Nobuhiro Iwamatsu wrote:
>>
>> Use of malloc of do_fat_write() from USB media causes cache error on
>
>
> I would remove 'from USB media' from the commit log as it doesn't really
> matter where you read from.

I see. I will remove and re-send.

>
>
>> ARM v7 platforms. Perhaps, the same problem will occur at any other CPUs.
>> This replaces malloc with memalign to fix cache buffer alignment.
>>
>> Signed-off-by: Nobuhiro Iwamatsu 
>> Signed-off-by: Yoshiyuki Ito 
>> ---
>>   fs/fat/fat_write.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c
>> index 9f5e911..cef138e 100644
>> --- a/fs/fat/fat_write.c
>> +++ b/fs/fat/fat_write.c
>> @@ -952,7 +952,7 @@ static int do_fat_write(const char *filename, void
>> *buffer,
>> }
>>
>> mydata->fatbufnum = -1;
>> -   mydata->fatbuf = malloc(FATBUFSIZE);
>> +   mydata->fatbuf = memalign(ARCH_DMA_MINALIGN, FATBUFSIZE);
>> if (mydata->fatbuf == NULL) {
>> debug("Error: allocating memory\n");
>> return -1;
>>
>
> Tested on an i.MX6 custom platform.
>
> Tested-by: Hector Palacios 
>

Thanks for your test!

> Thanks,

Best regards,
  Nobuhiro

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

Re: [U-Boot] [PATCH] lib: Add CONFIG_FDT_IGNORE_FIXUP_MEMORY_NODE

[Nobuhiro Iwamatsu]

Hi,

2014-04-08 2:41 GMT+09:00 Tom Rini :
> On Mon, Apr 07, 2014 at 08:53:39AM +0200, Wolfgang Denk wrote:
>> Dear Nobuhiro Iwamatsu,
>>
>> In message 
>> <1396846600-15386-1-git-send-email-nobuhiro.iwamatsu...@renesas.com> you 
>> wrote:
>> > Usually, when CONFIG_OF_LIBFDT is enabled, U-Boot is set to
>> > the FDT memory information that is set in the U-Boot. This patch
>> > disables this behavior.
>> >
>> > Signed-off-by: Nobuhiro Iwamatsu 
>> > ---
>> >  README   | 8 
>> >  arch/arm/lib/bootm-fdt.c | 2 ++
>> >  2 files changed, 10 insertions(+)
>>
>> Please explain why you would want to do this.  To me it makes no
>> sense.  Either U-Boot knows the correct memory size, then it should
>> pass it to Linux.  Or it does not, then U-Boot should be fixed.
>>
>> Also, I object that your implementation is ARM specific.  If such a
>> feature gets added, it should be architecture independent.
>
> This has shown up before in the context of platforms with >4GB memory
> and we "correct" the node by reducing the system memory, which is
> incorrect.  I agree this needs to be done for more than just ARM
> however.

It is one of the reasons of this patch that you wrote.

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



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

Re: [U-Boot] [PATCH] lib: Add CONFIG_FDT_IGNORE_FIXUP_MEMORY_NODE

[Nobuhiro Iwamatsu]

Hi,

Thanks for your comment.

2014-04-07 15:53 GMT+09:00 Wolfgang Denk :
> Dear Nobuhiro Iwamatsu,
>
> In message 
> <1396846600-15386-1-git-send-email-nobuhiro.iwamatsu...@renesas.com> you 
> wrote:
>> Usually, when CONFIG_OF_LIBFDT is enabled, U-Boot is set to
>> the FDT memory information that is set in the U-Boot. This patch
>> disables this behavior.
>>
>> Signed-off-by: Nobuhiro Iwamatsu 
>> ---
>>  README   | 8 
>>  arch/arm/lib/bootm-fdt.c | 2 ++
>>  2 files changed, 10 insertions(+)
>
> Please explain why you would want to do this.  To me it makes no
> sense.  Either U-Boot knows the correct memory size, then it should
> pass it to Linux.  Or it does not, then U-Boot should be fixed.

For example, I can access the memory of all in the U-Boot, but I may
want to control
the highmem on Linux,I do not want to show a specific area from kernel
and userland.

>
> Also, I object that your implementation is ARM specific.  If such a
> feature gets added, it should be architecture independent.

I see. But arch_fixup_memory_node() is used by ARM only.
So, we see to be dependent on the ARM is only this.

>
> Thanks.
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
> To be a winner, all you need to give is all you have.
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot



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

Re: [U-Boot] [U-boot] how to compile vexpress_aemv8a with latest u-boot code

[Albert ARIBAUD]

Hi tiger...@via-alliance.com,

On Mon, 31 Mar 2014 15:30:45 +0800,  wrote:

> Hi, experts:
> 
> I usually compiled u-boot for ARMv8 FVP model with below command:
> 
> export ARCH=aarch64
> 
> export
> CROSS_COMPILE=/home/tiger/tiger-linux-share/CBP5860/ARMv8/gcc-linaro-aar
> ch64/bin/aarch64-linux-gnu-
> 
> make vexpress_aemv8a
> 
>  
> 
> but when I tried to compile it with u-boot-2014.04-rc2.tar.bz2, it
> tiped:
> 
> Makefile:485: *** "System not configured - see README". Stop.
> 
>  
> 
> Best wishes,
> 
That should be

make vexpress_aemv8a_config
make

(note the _config) And with the upcoming Kconfig:

make vexpress_aemv8a_defconfig)
make

I personally use

./MAKEALL vexpress_aemv8a

(without the _[def]config)

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

Re: [U-Boot] [PATCH] board_r: return 0 from show_model_r

[Simon Glass]

On 4 April 2014 05:23, Paul Burton  wrote:

> The show_model_r function should return an int but didn't. Return 0 to
> indicate inevitable success and avoid the following if it is used:
>
> common/board_r.c: In function 'show_model_r':
> common/board_r.c:531:1: warning: no return statement in function returning
> non-void [-Wreturn-type]
>  }
>  ^
>
> Cc: Simon Glass 
> Signed-off-by: Paul Burton 
>

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

Re: [U-Boot] [PATCH v2] arm64 patch: gicv3 support

[Albert ARIBAUD]

Hi feng...@phytium.com.cn,

On Fri, 14 Mar 2014 14:26:27 +0800, feng...@phytium.com.cn wrote:

> From: David Feng 
> 
> This patch add gicv3 support to uboot armv8 platform.
> 
> Changes for v2:
>   - rename arm/cpu/armv8/gic.S with arm/lib/gic_64.S
>   - move smp_kick_all_cpus() from gic.S to start.S, it would be
> implementation dependent.
>   - Each core initialize it's own ReDistributor instead of master
> initializeing all ReDistributors. This is advised by arnab.basu
> .
> 
> Signed-off-by: David Feng 
> ---
>  arch/arm/cpu/armv8/Makefile   |1 -
>  arch/arm/cpu/armv8/gic.S  |  106 
>  arch/arm/cpu/armv8/start.S|   46 +++--
>  arch/arm/include/asm/gic.h|   56 +++
>  arch/arm/lib/Makefile |1 +
>  arch/arm/lib/gic_64.S |  194 
> +
>  include/configs/vexpress_aemv8a.h |7 ++
>  7 files changed, 297 insertions(+), 114 deletions(-)
>  delete mode 100644 arch/arm/cpu/armv8/gic.S
>  create mode 100644 arch/arm/lib/gic_64.S
> 
> diff --git a/arch/arm/cpu/armv8/Makefile b/arch/arm/cpu/armv8/Makefile
> index b6eb6de..7d93f59 100644
> --- a/arch/arm/cpu/armv8/Makefile
> +++ b/arch/arm/cpu/armv8/Makefile
> @@ -13,5 +13,4 @@ obj-y   += cache_v8.o
>  obj-y+= exceptions.o
>  obj-y+= cache.o
>  obj-y+= tlb.o
> -obj-y+= gic.o
>  obj-y+= transition.o
> diff --git a/arch/arm/cpu/armv8/gic.S b/arch/arm/cpu/armv8/gic.S
> deleted file mode 100644
> index 599aa8f..000
> --- a/arch/arm/cpu/armv8/gic.S
> +++ /dev/null
> @@ -1,106 +0,0 @@
> -/*
> - * GIC Initialization Routines.
> - *
> - * (C) Copyright 2013
> - * David Feng 
> - *
> - * SPDX-License-Identifier:  GPL-2.0+
> - */
> -
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -
> -
> -/*
> - *
> - * void gic_init(void) __attribute__((weak));
> - *
> - * Currently, this routine only initialize secure copy of GIC
> - * with Security Extensions at EL3.
> - *
> - */
> -WEAK(gic_init)
> - branch_if_slave x0, 2f
> -
> - /* Initialize Distributor and SPIs */
> - ldr x1, =GICD_BASE
> - mov w0, #0x3/* EnableGrp0 | EnableGrp1 */
> - str w0, [x1, GICD_CTLR] /* Secure GICD_CTLR */
> - ldr w0, [x1, GICD_TYPER]
> - and w2, w0, #0x1f   /* ITLinesNumber */
> - cbz w2, 2f  /* No SPIs */
> - add x1, x1, (GICD_IGROUPRn + 4)
> - mov w0, #~0 /* Config SPIs as Grp1 */
> -1:   str w0, [x1], #0x4
> - sub w2, w2, #0x1
> - cbnzw2, 1b
> -
> - /* Initialize SGIs and PPIs */
> -2:   ldr x1, =GICD_BASE
> - mov w0, #~0 /* Config SGIs and PPIs as Grp1 */
> - str w0, [x1, GICD_IGROUPRn] /* GICD_IGROUPR0 */
> - mov w0, #0x1/* Enable SGI 0 */
> - str w0, [x1, GICD_ISENABLERn]
> -
> - /* Initialize Cpu Interface */
> - ldr x1, =GICC_BASE
> - mov w0, #0x1e7  /* Disable IRQ/FIQ Bypass & */
> - /* Enable Ack Group1 Interrupt & */
> - /* EnableGrp0 & EnableGrp1 */
> - str w0, [x1, GICC_CTLR] /* Secure GICC_CTLR */
> -
> - mov w0, #0x1 << 7   /* Non-Secure access to GICC_PMR */
> - str w0, [x1, GICC_PMR]
> -
> - ret
> -ENDPROC(gic_init)
> -
> -
> -/*
> - *
> - * void gic_send_sgi(u64 sgi) __attribute__((weak));
> - *
> - */
> -WEAK(gic_send_sgi)
> - ldr x1, =GICD_BASE
> - mov w2, #0x8000
> - movkw2, #0x100, lsl #16
> - orr w2, w2, w0
> - str w2, [x1, GICD_SGIR]
> - ret
> -ENDPROC(gic_send_sgi)
> -
> -
> -/*
> - *
> - * void wait_for_wakeup(void) __attribute__((weak));
> - *
> - * Wait for SGI 0 from master.
> - *
> - */
> -WEAK(wait_for_wakeup)
> - ldr x1, =GICC_BASE
> -0:   wfi
> - ldr w0, [x1, GICC_AIAR]
> - str w0, [x1, GICC_AEOIR]
> - cbnzw0, 0b
> - ret
> -ENDPROC(wait_for_wakeup)
> -
> -
> -/*
> - *
> - * void smp_kick_all_cpus(void) __attribute__((weak));
> - *
> - */
> -WEAK(smp_kick_all_cpus)
> - /* Kick secondary cpus up by SGI 0 interrupt */
> - mov x0, xzr /* SGI 0 */
> - mov x29, lr /* Save LR */
> - bl  gic_send_sgi
> - mov   

Re: [U-Boot] CONFIG_ARMV7_NONSEC on altera soc (alignment issues ?)

[Tim Sander]

Hi Albert
> > I am currently trying to configure either Altera Soc and Xilinx Zynq to
> > boot Linux in nonsecure-mode. This mail focusses on the Altera SOC.
> > 
> > As soon as the u-boot switched to normal mode it seems there is a problem
> > with code alignment handling? At least it seems the code which is running
> > beforehand stops working in normal mode and stops in either data_abort or
> > prefetch handler. It stopps working when it hits the call to
> > stdio_devices[file]->puts(s); in console_puts (console.c:255).
> > 
> > print *stdio_devices[file]
> > $2 = {flags = 16978471, ext = 16978464,
> > name = "$\022\003\001\202\022\003\001\360\031\003\001\020\060\220",
> > ,> 
> >   start = 0xe92d4070, stop = 0xe2806010, putc = 0xe1530006, puts =
> >   0xe1a04000, tstc = 0xe1a05001, getc = 0xe5810024, priv = 0x1a07,
> >   list = { next = 0xe5831004, prev = 0xe5813000}}> 
> > As there are unaligned addresses (putc?) in these function calls i have
> > the impression that this is not working in normal mode but in secure
> > mode.
> > 
> > Unfortunatly i was not able to get the mainline u-boot to boot on the
> > altera soc so i patched the altera release:
> > git://git.rocketboards.org/u-boot-socfpga.git
> > with the 1740999a39ea4217bf926002d10869c0d925a5dc aka
> > socfpga_v2013.01.01-rel branch.
> > 
> > As the altera u-boot release socfpga_v2013.01.01-rel is to old to have the
> > CONFIG_ARMV7_NONSEC patches i cherry-picked the following patches:
> > d4296887544ddf95808bfb62f312008f519efb7bextend non-secure switch to also
> > go into HYP mode ba6a1698116da272f14c53a3ae41467cb7fc4372   add SMP
> > support for non-secure switch bb975455650b1f36681de31a93ffe54952ed3a6b
> > trigger non-secure state switch during bootm execution
> > 1ef923851ab8ffcc4265fd991815b88d9c1f12d7add C function to switch to
> > non-secure state 16212b594f385bd594d5d316bf11b13c1186e3d7   add assembly
> > routine to switch to non-secure state
> > 45b940d6f9a9d4989452ea67480e299bfa51ee19add secure monitor handler to
> > switch to non-secure state d75ba503a972df09784f1a332ba356ef8b42a0a6 
ARM:
> > prepare armv7.h to be included from assembly source
> > 
> > I also applied the attached hacked together patches to get the system
> > running and fix up the stack pointer in normal mode as it pointed to 0.
> > 
> > Best regards
> > Tim
> 
> So this is not a patch for mainline U-Boot, right?
Unfortunatly not. The altera branch is from an older version and i had 
problems booting mainline. So i went the other way round and used the altera 
git release and cherry picked the patches of which i thought that would be 
needed for switching to normal world. This works but as soon as i print out 
something in u-boot ("Booting linux") or if thats commented out, booting linux
i get a access violation. So i either get in the prefetch or abort handler. As 
i don't know where the TrustZone registers are nor what they do, i have a hard 
time moving on with this. So these patches are just very experimental and got 
me as far as booting into early linux. I have the suscpicion that the serial 
port, and probably other hw is only writable from secure world so one would 
need a monitor running to have access to this hw (If it can not be switched to 
be accessible from normal world). Further with the stack pointer not set up in 
normal world i have no idea how the versatile express should work without 
setting the stack. 

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

Re: [U-Boot] [PATCH] ARMv8: fix bug for flush data cache by set/way

[Scott Wood]

On Mon, 2014-03-31 at 09:50 +0800, Leo Yan wrote:
> When flush the d$ with set/way instruction, it need calculate the way's
> offset = log2(Associativity); but in current uboot's code, it use below
> formula to calculate the offset: log2(Associativity * 2 - 1), so finally
> it cannot flush data cache properly.

More specifically, the "Associativity" above is actually "Associativity
- 1", and clz isn't quite log2().

> Signed-off-by: Leo Yan 
> ---
>  arch/arm/cpu/armv8/cache.S |4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/arch/arm/cpu/armv8/cache.S b/arch/arm/cpu/armv8/cache.S
> index 546a83e..256d2e2 100644
> --- a/arch/arm/cpu/armv8/cache.S
> +++ b/arch/arm/cpu/armv8/cache.S
> @@ -30,9 +30,7 @@ ENTRY(__asm_flush_dcache_level)
>   add x2, x2, #4  /* x2 <- log2(cache line size) */
>   mov x3, #0x3ff
>   and x3, x3, x6, lsr #3  /* x3 <- max number of #ways */
> - add w4, w3, w3
> - sub w4, w4, 1   /* round up log2(#ways + 1) */
> - clz w5, w4  /* bit position of #ways */
> + clz w5, w3  /* bit position of #ways */
>   mov x4, #0x7fff
>   and x4, x4, x6, lsr #13 /* x4 <- max number of #sets */
>   /* x1 <- cache level << 1 */

I believe the new code will fail on a cache with associativity 1.  x3
would be 0, since it's actually associativity minus one, and thus w5
would be 32.  w5 is later interpreted as x5, so it would actually do a
32-bit shift rather than whatever behavior ARM specifies for shift
counts larger than the word size.

-Scott


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

[U-Boot] [RFC PATCH] MIPS: incaip: move board specific code out of generic code

[Daniel Schwierzeck]

This is required to switch MIPS platform to generic board.

Cc: Wolfgang Denk 
Signed-off-by: Daniel Schwierzeck 
---
Wolfgang, I would rather remove this board. It is obviously dead and no one ever
cared about it since you have added it. The code does not conform to current
coding style. Also it needs a lot of cleanup if we switch to driver model 
eventually.
---
 arch/mips/include/asm/inca-ip.h | 3 +++
 arch/mips/include/asm/u-boot-mips.h | 2 --
 arch/mips/lib/board.c   | 3 ---
 board/incaip/incaip.c   | 7 +--
 include/common.h| 3 ---
 include/configs/incaip.h| 2 +-
 6 files changed, 9 insertions(+), 11 deletions(-)

diff --git a/arch/mips/include/asm/inca-ip.h b/arch/mips/include/asm/inca-ip.h
index 5f03e2a..dcaa3e7 100644
--- a/arch/mips/include/asm/inca-ip.h
+++ b/arch/mips/include/asm/inca-ip.h
@@ -2428,3 +2428,6 @@ If set and clear bit are written concurrently with 1, the 
associated bit is not
 #define INCA_IP_ICU_ICU_EICR_EII2 (value)    1 << 3) - 1) & 
(value)) << 8)
 #define INCA_IP_ICU_ICU_EICR_EII1 (value)    1 << 3) - 1) & 
(value)) << 4)
 #define INCA_IP_ICU_ICU_EICR_EII0 (value)    1 << 3) - 1) & 
(value)) << 0)
+
+unsigned int incaip_get_cpuclk(void);
+int incaip_set_cpuclk(void);
diff --git a/arch/mips/include/asm/u-boot-mips.h 
b/arch/mips/include/asm/u-boot-mips.h
index 9f3cce9..a5b2fc0 100644
--- a/arch/mips/include/asm/u-boot-mips.h
+++ b/arch/mips/include/asm/u-boot-mips.h
@@ -21,5 +21,3 @@ static inline unsigned long image_copy_end(void)
extern char __image_copy_end[];
return (unsigned long) &__image_copy_end;
 }
-
-extern int incaip_set_cpuclk(void);
diff --git a/arch/mips/lib/board.c b/arch/mips/lib/board.c
index 317c825..3200d87 100644
--- a/arch/mips/lib/board.c
+++ b/arch/mips/lib/board.c
@@ -103,9 +103,6 @@ init_fnc_t *init_sequence[] = {
board_early_init_f,
timer_init,
env_init,   /* initialize environment */
-#ifdef CONFIG_INCA_IP
-   incaip_set_cpuclk,  /* set cpu clock according to env. variable */
-#endif
init_baudrate,  /* initialize baudrate settings */
serial_init,/* serial communications setup */
console_init_f,
diff --git a/board/incaip/incaip.c b/board/incaip/incaip.c
index 217b8af..5abd2b8 100644
--- a/board/incaip/incaip.c
+++ b/board/incaip/incaip.c
@@ -13,8 +13,6 @@
 #include 
 #include 
 
-extern uint incaip_get_cpuclk(void);
-
 void _machine_restart(void)
 {
*INCA_IP_WDT_RST_REQ = 0x3f;
@@ -74,6 +72,11 @@ phys_size_t initdram(int board_type)
return max_size;
 }
 
+int board_early_init_f(void)
+{
+   return incaip_set_cpuclk();
+}
+
 int checkboard (void)
 {
unsigned long chipid = *INCA_IP_WDT_CHIPID;
diff --git a/include/common.h b/include/common.h
index cbd3c9e..f77273e 100644
--- a/include/common.h
+++ b/include/common.h
@@ -692,9 +692,6 @@ ulong   get_UCLK (void);
 #if defined(CONFIG_LH7A40X)
 ulong  get_PLLCLK (void);
 #endif
-#if defined CONFIG_INCA_IP
-uint   incaip_get_cpuclk (void);
-#endif
 #if defined(CONFIG_IMX)
 ulong get_systemPLLCLK(void);
 ulong get_FCLK(void);
diff --git a/include/configs/incaip.h b/include/configs/incaip.h
index e11d184..2c4893d 100644
--- a/include/configs/incaip.h
+++ b/include/configs/incaip.h
@@ -103,7 +103,7 @@
 
 #define CONFIG_SYS_BOOTPARAMS_LEN  128*1024
 
-#define CONFIG_SYS_MIPS_TIMER_FREQ (incaip_get_cpuclk() / 2)
+#define CONFIG_SYS_MIPS_TIMER_FREQ (CONFIG_CPU_CLOCK_RATE / 2)
 
 #define CONFIG_SYS_SDRAM_BASE  0x8000
 
-- 
1.8.3.2

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

Re: [U-Boot] [PATCH V2 1/2] bootstage: arm: fix fdt stashing code

[Albert ARIBAUD]

Hi Rommel,

On Thu, 20 Feb 2014 00:16:56 +0900, Rommel G Custodio
 wrote:

> The conditional is using a variable that is not defined.
> 
> Signed-off-by: Rommel G Custodio 
> ---
>  arch/arm/lib/bootm.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
> index a8295bf..7f1b2e0 100644
> --- a/arch/arm/lib/bootm.c
> +++ b/arch/arm/lib/bootm.c
> @@ -71,8 +71,7 @@ static void announce_and_cleanup(int fake)
>   "(fake run for tracing)" : "");
>   bootstage_mark_name(BOOTSTAGE_ID_BOOTM_HANDOFF, "start_kernel");
>  #ifdef CONFIG_BOOTSTAGE_FDT
> - if (flag == BOOTM_STATE_OS_FAKE_GO)
> - bootstage_fdt_add_report();
> + bootstage_fdt_add_report();
>  #endif
>  #ifdef CONFIG_BOOTSTAGE_REPORT
>   bootstage_report();

Applied to u-boot-arm/master, thanks!

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

Re: [U-Boot] [PATCH v2 0/7] MIPS: Malta generic board conversion

[Daniel Schwierzeck]

2014-04-07 11:11 GMT+02:00 Paul Burton :
> This series adds generic board support for the MIPS architecture, and
> then converts the MIPS Malta development board to use it.
>
> Changes since v1:
>   - Call init_func_ram/initdram to preserve the existing behaviour for
> boards, as requested by Daniel.
>
>   - Call timer_init, which I'd missed as pointed out by Daniel.
>
> Note that I've only submitted the whole series again because patch
> numbers changed; the content of patches 1-3,6 is unchanged from v1.
>

applied to u-boot-mips/next, thanks

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

Re: [U-Boot] CONFIG_ARMV7_NONSEC on altera soc (alignment issues ?)

[Albert ARIBAUD]

Hi Tim,

On Wed, 26 Mar 2014 15:25:33 +0100, Tim Sander 
wrote:

> Hi
> 
> I am currently trying to configure either Altera Soc and Xilinx Zynq to boot 
> Linux in nonsecure-mode.
> This mail focusses on the Altera SOC.
> 
> As soon as the u-boot switched to normal mode it seems there is a problem 
> with code alignment handling? 
> At least it seems the code which is running beforehand stops working in 
> normal mode and stops in either
> data_abort or prefetch handler. It stopps working when it hits the call to
> stdio_devices[file]->puts(s); in console_puts (console.c:255).
> 
> print *stdio_devices[file]
> $2 = {flags = 16978471, ext = 16978464, 
> name = "$\022\003\001\202\022\003\001\360\031\003\001\020\060\220", 
> , 
>   start = 0xe92d4070, stop = 0xe2806010, putc = 0xe1530006, puts = 
> 0xe1a04000, tstc = 0xe1a05001, 
>   getc = 0xe5810024, priv = 0x1a07, list = { next = 0xe5831004, prev = 
> 0xe5813000}}
> 
> As there are unaligned addresses (putc?) in these function calls i have the 
> impression that this is not working in
> normal mode but in secure mode.
> 
> Unfortunatly i was not able to get the mainline u-boot to boot on the altera 
> soc so i patched the altera release:
> git://git.rocketboards.org/u-boot-socfpga.git
> with the 1740999a39ea4217bf926002d10869c0d925a5dc aka socfpga_v2013.01.01-rel 
> branch.
> 
> As the altera u-boot release socfpga_v2013.01.01-rel is to old to have the 
> CONFIG_ARMV7_NONSEC patches
> i cherry-picked the following patches:
> d4296887544ddf95808bfb62f312008f519efb7b  extend non-secure switch to 
> also go into HYP mode
> ba6a1698116da272f14c53a3ae41467cb7fc4372  add SMP support for non-secure 
> switch
> bb975455650b1f36681de31a93ffe54952ed3a6b  trigger non-secure state switch 
> during bootm execution
> 1ef923851ab8ffcc4265fd991815b88d9c1f12d7  add C function to switch to 
> non-secure state
> 16212b594f385bd594d5d316bf11b13c1186e3d7  add assembly routine to switch 
> to non-secure state
> 45b940d6f9a9d4989452ea67480e299bfa51ee19  add secure monitor handler to 
> switch to non-secure state
> d75ba503a972df09784f1a332ba356ef8b42a0a6  ARM: prepare armv7.h to be 
> included from assembly source
> 
> I also applied the attached hacked together patches to get the system running 
> and fix up the stack pointer in 
> normal mode as it pointed to 0. 
> 
> Best regards
> Tim

So this is not a patch for mainline U-Boot, right?

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

Re: [U-Boot] [PATCH] ARMv8: fix bug for flush data cache by set/way

[Albert ARIBAUD]

Hi Leo,

On Mon, 31 Mar 2014 09:50:35 +0800, Leo Yan  wrote:

> When flush the d$ with set/way instruction, it need calculate the way's
> offset = log2(Associativity); but in current uboot's code, it use below
> formula to calculate the offset: log2(Associativity * 2 - 1), so finally
> it cannot flush data cache properly.
> 
> Signed-off-by: Leo Yan 
> ---
>  arch/arm/cpu/armv8/cache.S |4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/arch/arm/cpu/armv8/cache.S b/arch/arm/cpu/armv8/cache.S
> index 546a83e..256d2e2 100644
> --- a/arch/arm/cpu/armv8/cache.S
> +++ b/arch/arm/cpu/armv8/cache.S
> @@ -30,9 +30,7 @@ ENTRY(__asm_flush_dcache_level)
>   add x2, x2, #4  /* x2 <- log2(cache line size) */
>   mov x3, #0x3ff
>   and x3, x3, x6, lsr #3  /* x3 <- max number of #ways */
> - add w4, w3, w3
> - sub w4, w4, 1   /* round up log2(#ways + 1) */
> - clz w5, w4  /* bit position of #ways */
> + clz w5, w3  /* bit position of #ways */
>   mov x4, #0x7fff
>   and x4, x4, x6, lsr #13 /* x4 <- max number of #sets */
>   /* x1 <- cache level << 1 */

Applied to u-boot-arm/master, thanks!

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

Re: [U-Boot] Socfpga preloader signing patch

[Gerhard Sittig]

On Tue, 2014-04-08 at 07:51 +1200, Charles Manning wrote:
> 
> On Saturday 05 April 2014 09:47:02 Pavel Machek wrote:
> > Hi!
> >
> > > I'm trying to get custom preloader to work (on EBV Socrates)... I
> > > tried applying old patch from mail archives, but a) applying patch
> > > from mail archives is not fun and b) it did not seem to do the trick.
> >
> > Just to make sure... right way to use the
> > socfpga-signed-preloader.bin is
> >
> > dd if=socfpga-signed-preloader.bin of=/dev/mmcblk0p1 bs=64k seek=0
> > dd if=u-boot.img of=/dev/mmcblk0p1 bs=64K seek=4
> 
> Almost right.
> 
> It must be partition 3, which must be of type A2.
> 
> dd .of=/dev/mmcblk0p3 ...

FYI:  It's not strictly necessary that partition 3 is the raw
partition of type A2.  That's just a common practice or a
previous default, but not the only valid setup.  I'm aware of
setups where the FAT partition was omitted, p1 is raw and p2 is
Linux.  These work equally fine.


virtually yours
Gerhard Sittig
-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: off...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] armv8: Flush dcache before switching to EL2

[Albert ARIBAUD]

Hi York,

On Mon, 31 Mar 2014 14:40:32 -0700, York Sun 
wrote:

> For ARMv8, U-boot has been running at EL3 with cache and MMU enabled.
> Without proper setup for EL2, cache and MMU are both disabled (out of
> reset). Before switching, we need to flush the dcache to make sure the
> data is in the main memory.
> 
> Signed-off-by: York Sun 
> ---
>  arch/arm/lib/bootm.c |1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
> index a8295bf..9782ddb 100644
> --- a/arch/arm/lib/bootm.c
> +++ b/arch/arm/lib/bootm.c
> @@ -199,6 +199,7 @@ static void do_nonsec_virt_switch(void)
>  
>  #ifdef CONFIG_ARM64
>   smp_kick_all_cpus();
> + flush_dcache_all(); /* flush cache before swtiching to EL2 */
>   armv8_switch_to_el2();
>  #ifdef CONFIG_ARMV8_SWITCH_TO_EL1
>   armv8_switch_to_el1();

Applied as a bugfix to u-boot-arm/master, thanks!

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

Re: [U-Boot] [PATCH 0/4] vybrid/tower fixes and enhancements

[Albert ARIBAUD]

Hi ste...@agner.ch,

On Tue, 11 Mar 2014 18:43:56 +0100, ste...@agner.ch wrote:

> From: Stefan Agner 
> 
> This patch series addresses several fixes and enhancements for the
> vybrid tower.
> 
> The patches are originally by Marcel Ziswiler which should remain
> the Author of the patches, I picked them up since some changes
> I'm going to submit are building upon them.
> 
> Changes v3:
> - Merged patches to reflect one logical change on a pheripherial
>   device level.
> 
> Changes v2:
> - Memory offset based reserved ANADIG field naming scheme.
> - Fixed mux_ctrl_ofs in secondary RMII1 iomux definitions.
> 
> Marcel Ziswiler (4):
>   arm: vf610: fix anadig register struct
>   arm: vf610: add uart0 clock/iomux definitions
>   arm: vf610: add enet1 support
>   arm: vf610: fix double iomux configuration for vf610twr board
> 
>  arch/arm/include/asm/arch-vf610/crm_regs.h| 57 
> +++
>  arch/arm/include/asm/arch-vf610/imx-regs.h|  1 +
>  arch/arm/include/asm/arch-vf610/iomux-vf610.h | 12 ++
>  board/freescale/vf610twr/vf610twr.c   |  1 -
>  4 files changed, 45 insertions(+), 26 deletions(-)
> 

Applied as a bugfix (although it is not only a bugfix) to
u-boot-arm/master, thanks!

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

Re: [U-Boot] CONFIG_SYS_XIP_BOOT for when it's a choice?

[Tom Rini]

On Mon, Apr 07, 2014 at 09:19:09PM +0200, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20140407190210.GK23803@bill-the-cat> you wrote:
> > 
> > > I think CONFIG_ENV_IS_IN.. is an independent thing. Even when booting
> > > from NOR you can have the environment anywhere else.
> > 
> > Well, maybe.  I'm not sure (and too lazy to dig through the board doc
> > atm) on if you can have both NOR and QSPI available on the reference
> > design, but I think not.  But also, for ..._qspiboot I want to show
> > everything from QSPI, and ..._norboot I want everything on NOR.
> 
> OK, but this is a design decision for this specific board, then.  It
> is not a fundamental property of the U-Boot design.  For us, boot
> device and environment storage are independent.  And so it should be
> implemented.

Maybe, maybe not.  But it's beside the point.  The point is we have SoC
init code that needs to be run once.  Sometimes this is true when
CONFIG_SPL_BUILD=y, sometimes this is true when other options are set
instead.  What should we call the option to denote one-time init?
Should we extend CONFIG_SKIP_LOWLEVEL_INIT to cover this case?

> > > As for the differences between NOR and QSPI...  IIRC we cannot execute
> > > any code directly on QSPI, we have to load it to some memory first,
> > > right?  So QSPI is not much different from loading the code from any
> > > other storage device - or am I missing something?  How is XIP from
> > > QSPI working?
> > 
> > Nope, this board has memory mapped QSPI and on reading something other
> > than all 0s or all 1s ROM jumps to it.
> 
> If you use the memory mapped mode, then it looks just like any
> other ROM, and we should not need special code either.

Well, for CONFIG_NOR_BOOT we must have it on am335x (haven't checked
am43xx) to finish doing pinmux as only 12KiB is mapped, in addition to
env related options.  On am43xx and QSPI it's just used to denote when
we are doing one-time init in U-Boot proper rather than SPL.

This is, I guess, yet another extension of "we need to treat SPL as a
U-Boot with x/y/z set, not a special magic build target like we do
today" and Kconfig will help.

-- 
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] Socfpga preloader signing patch

[Charles Manning]

On Saturday 05 April 2014 09:47:02 Pavel Machek wrote:
> Hi!
>
> > I'm trying to get custom preloader to work (on EBV Socrates)... I
> > tried applying old patch from mail archives, but a) applying patch
> > from mail archives is not fun and b) it did not seem to do the trick.
>
> Just to make sure... right way to use the
> socfpga-signed-preloader.bin is
>
> dd if=socfpga-signed-preloader.bin of=/dev/mmcblk0p1 bs=64k seek=0
> dd if=u-boot.img of=/dev/mmcblk0p1 bs=64K seek=4

Almost right.

It must be partition 3, which must be of type A2.

dd .of=/dev/mmcblk0p3 ...

I use the following script to set up an sd card with some useful partitions:


#!/bin/bash
# Script to partition an SDCard for the SoCFPGA
# /dev/sdx3 MUST be type A2. It is used for the bootloaders.
#
# We also make /dev/sdx1 -  FAT, then the rest is ext2
#


#set -e -x

DEVICE=$1
THIS_DIR="$( cd "$( dirname "$0" )" && pwd )"
BASE_DIR="${THIS_DIR}/.."

errmsg() {
echo "Error: $@" 2>&1
}

errdie() {
errmsg "$@"
exit 1
}

log() {
echo ''
echo "$@"
echo ''
}

usage() {
echo "Usage: $1 "
}

if [ $# -ne 1 ]; then
errmsg "incorrect usage"
usage $0
exit 1
fi

DEVICE=$1

# precondition checks

if [ ! -b ${DEVICE} ]; then
errdie "${DEVICE} is not an accessable block device"
fi

# confirm

read -p "The ${DEVICE} device will be formatted. Continue? [y/n] " answer
if [ "$answer" != "y" ]; then
exit 0;
fi

# umount if device partitions are mounted

for partition in `mount | grep ${DEVICE} | cut -d ' ' -f 1`; do
echo "Umounting ${partition} ..."
umount $partition
if [ $? -ne 0 ]; then
errdie "failed to umount ${partition}"
fi
done

# go

log 'Repartitioning...'


#
# Set up 3 partitions, then set their type.
#  /dev/sdx3 is the bootloader partition and must be type A2
#  We add a small FAT partition, as /dev/sdx1 then the rest is
# an ext2 partition.
#
fdisk $DEVICE << EOF
o
n
p
3
2048
+8M
n
p
1

+20M
n
p
2


t
1
4
t
2
83
t
3
a2
p
w
EOF

if [ $? -ne 0 ]; then
errdie "repartitioning failed"
fi

log 'Formatting...'

echo "Formatting FAT aprtition..."

mkfs.vfat ${DEVICE}1
if [ $? -ne 0 ]; then
errdie "formatting failed"
fi

echo "Formatting Linux partition ..."

mkfs.ext2 ${DEVICE}2
if [ $? -ne 0 ]; then
errdie "formatting failed"
fi


log 'Done'

exit 0
#end of script

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

Re: [U-Boot] CONFIG_SYS_XIP_BOOT for when it's a choice?

[Wolfgang Denk]

Dear Tom,

In message <20140407190210.GK23803@bill-the-cat> you wrote:
> 
> > I think CONFIG_ENV_IS_IN.. is an independent thing. Even when booting
> > from NOR you can have the environment anywhere else.
> 
> Well, maybe.  I'm not sure (and too lazy to dig through the board doc
> atm) on if you can have both NOR and QSPI available on the reference
> design, but I think not.  But also, for ..._qspiboot I want to show
> everything from QSPI, and ..._norboot I want everything on NOR.

OK, but this is a design decision for this specific board, then.  It
is not a fundamental property of the U-Boot design.  For us, boot
device and environment storage are independent.  And so it should be
implemented.

> > As for the differences between NOR and QSPI...  IIRC we cannot execute
> > any code directly on QSPI, we have to load it to some memory first,
> > right?  So QSPI is not much different from loading the code from any
> > other storage device - or am I missing something?  How is XIP from
> > QSPI working?
> 
> Nope, this board has memory mapped QSPI and on reading something other
> than all 0s or all 1s ROM jumps to it.

If you use the memory mapped mode, then it looks just like any
other ROM, and we should not need special code either.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
I am not now, nor have I ever been, a member of the demigodic party.
   -- Dennis Ritchie
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] CONFIG_SYS_XIP_BOOT for when it's a choice?

[Tom Rini]

On Mon, Apr 07, 2014 at 08:45:42PM +0200, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20140407174936.GJ23803@bill-the-cat> you wrote:
> > 
> > > OK.  So if this basically the same what we do when booting XIP from
> > > parallel NOR, then maybe we should rename CONFIG_NOR_BOOT into a more
> > > generic name, like CONFIG_XIP_BOOT ?
> > 
> > Nope, not everything for NOR is required for QSPI nor correct, so we'll
> > still need NOR/QSPI boot options (CONFIG_ENV_IS_IN.. then
> > size/location).
> 
> I think CONFIG_ENV_IS_IN.. is an independent thing. Even when booting
> from NOR you can have the environment anywhere else.

Well, maybe.  I'm not sure (and too lazy to dig through the board doc
atm) on if you can have both NOR and QSPI available on the reference
design, but I think not.  But also, for ..._qspiboot I want to show
everything from QSPI, and ..._norboot I want everything on NOR.

> As for the differences between NOR and QSPI...  IIRC we cannot execute
> any code directly on QSPI, we have to load it to some memory first,
> right?  So QSPI is not much different from loading the code from any
> other storage device - or am I missing something?  How is XIP from
> QSPI working?

Nope, this board has memory mapped QSPI and on reading something other
than all 0s or all 1s ROM jumps to it.

-- 
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] CONFIG_SYS_XIP_BOOT for when it's a choice?

[Wolfgang Denk]

Dear Tom,

In message <20140407174936.GJ23803@bill-the-cat> you wrote:
> 
> > OK.  So if this basically the same what we do when booting XIP from
> > parallel NOR, then maybe we should rename CONFIG_NOR_BOOT into a more
> > generic name, like CONFIG_XIP_BOOT ?
> 
> Nope, not everything for NOR is required for QSPI nor correct, so we'll
> still need NOR/QSPI boot options (CONFIG_ENV_IS_IN.. then
> size/location).

I think CONFIG_ENV_IS_IN.. is an independent thing. Even when booting
from NOR you can have the environment anywhere else.

As for the differences between NOR and QSPI...  IIRC we cannot execute
any code directly on QSPI, we have to load it to some memory first,
right?  So QSPI is not much different from loading the code from any
other storage device - or am I missing something?  How is XIP from
QSPI working?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"No matter where you go, there you are..."  - Buckaroo Banzai
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Is it OK to use target code from host tools

[Scott Wood]

On Mon, 2014-04-07 at 18:22 +0200, Albert ARIBAUD wrote:
> Hi Charles,
> 
> On Wed, 5 Mar 2014 11:30:26 +1300, Charles Manning
>  wrote:
> 
> > Hello All
> > 
> > I am currently reworking a socfpga signer patch which is part of mkimage.
> > 
> > One thing I need to do is to stuff some bytes into a header ensuring the
> > endianism is correct.
> > 
> > This is a trivial thing to do in C, but I have been instructed to use the
> > existing functions put_unaligned_le32() etc.
> > 
> > These are part of Linux in linux/unaligned/access_ok.h. But this includes
> > 
> > 
> > It seems to me that this mixing of host space and target space is
> > potentially problematic.
> 
> Hmm... Where exactly is there a mixing of host and target?

arch//include/asm are target-specific headers.  I suppose the
headers in arch/sandbox would work, but is that currently what will be
used if a host tool references an asm/ header?  Plus, it's
Linux-specific.

Or if you mean to include the host's asm/ headers, that's also
Linux-specific.

> > Is this a safe thing to do?

In tools/relocate-rela.c I open-coded endian swapping because I didn't
see a better way to do so portably (outside of the networking functions
which didn't do what I needed).  Perhaps that could be factored out (and
extended to other sizes) to somewhere common.

-Scott


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

Re: [U-Boot] [PATCH] build:arm: Remove setting of CROSS_COMPILE environment variable

[Albert ARIBAUD]

Hi Lukasz,

On Tue, 18 Mar 2014 16:46:48 +0100, Lukasz Majewski
 wrote:

> After Kbuild introduction, the CROSS_COMPILE environment variable has been
> set to some default value (prefix arm-linux-).
> 
> This shall be removed since it breaks building u-boot for native arm target
> (like qemu ARM).
> Moreover not all compilers have arm-linux- prefix.
> 
> Additionally the u-boot cross compiles with CROSS_COMPILE= set explicitly-
> e.g.:
> CROSS_COMPILE=/  /arm-v7a-linux-gnueabi- make
> 
> Signed-off-by: Lukasz Majewski 
> Cc: Masahiro Yamada 
> ---
>  arch/arm/config.mk |4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/arch/arm/config.mk b/arch/arm/config.mk
> index f4c2d81..178a59a 100644
> --- a/arch/arm/config.mk
> +++ b/arch/arm/config.mk
> @@ -5,10 +5,6 @@
>  # SPDX-License-Identifier:   GPL-2.0+
>  #
>  
> -ifeq ($(CROSS_COMPILE),)
> -CROSS_COMPILE := arm-linux-
> -endif
> -
>  ifndef CONFIG_STANDALONE_LOAD_ADDR
>  ifneq ($(CONFIG_OMAP_COMMON),)
>  CONFIG_STANDALONE_LOAD_ADDR = 0x8030

Applied to u-boot-arm/master, thanks!

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

Re: [U-Boot] [PATCH] build:arm: Remove setting of CROSS_COMPILE environment variable

[Albert ARIBAUD]

Hi Lukasz,

On Mon, 07 Apr 2014 09:04:58 +0200, Lukasz Majewski
 wrote:


> Are you willing to add this patch to your u-boot-arm tree? 
> 
> I know that you were not available on the ML for some time and hence,
> I'm curious if you plan to send pull request for u-boot-arm tree to Tom
> before the v2014.04 release?

Yes and yes -- I am clean up my backlog and this patch will get in
before I send the PR.

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

Re: [U-Boot] [PULL] : Please pull u-boot-imx

[Albert ARIBAUD]

Hi Stefano,

On Mon, 07 Apr 2014 18:20:36 +0200, Stefano Babic 
wrote:

> Hi Albert,
> 
> this contains the fix for the i.MX6 errata. I do not foresee now to send
> another PR before release, maybe this is the last one for 2014.04.
> 
> The following changes since commit 1a9df13d5bc0b68c9dcae88d244c995c9351db67:
> 
>   arm: mxs: Add support for generating signed BootStream (2014-04-04
> 11:44:59 +0200)
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-imx.git master
> 
> for you to fetch changes up to 68659d649debc9fb3d8ce21ce4dcfe3a66b63e3a:
> 
>   MX6: Enable ARM errata workaround 794072 and 761320 (2014-04-07
> 18:11:01 +0200)
> 
> 
> Nitin Garg (3):
>   ARM: Add workaround for Cortex-A9 errata 794072
>   ARM: Add workaround for Cortex-A9 errata 761320
>   MX6: Enable ARM errata workaround 794072 and 761320
> 
>  README   |2 ++
>  arch/arm/cpu/armv7/start.S   |7 ++-
>  include/configs/mx6_common.h |2 ++
>  3 files changed, 10 insertions(+), 1 deletion(-)
> 
> Best regards,
> Stefano
> 

Applied to u-boot-arm/master, thanks!

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

Re: [U-Boot] CONFIG_SYS_XIP_BOOT for when it's a choice?

[Tom Rini]

On Mon, Apr 07, 2014 at 07:41:39PM +0200, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20140407171943.GG23803@bill-the-cat> you wrote:
> > 
> > > What exactly do you mean by "non-SPL XIP booting"?  Is this not the
> > > standard boot mode which has actually been the first (and only one)
> > > that U-Boot has ever been designed for, like booting from a ROM (like
> > > parallel NOR flash)?  Because the we do exactly that: we execute the
> > > code as is from the boot device...
> >
> > Exactly.  But most modern platforms are not XIP booting by default, if
> > ever.  When it is, it's a special case and needs the code we usually
> > only call in SPL (say memory controller init) linked in.  Today this is
> > done with say:
> > #if defined(CONFIG_SPL_BUILD) || defined(CONFIG_NOR_BOOT)
> > ...
> > #endif
> > on am335x.  Looking at am43xx we have both traditional NOR and QSPI NOR
> > as boot options, along with SD/NAND/various-peripheral-boots.
> 
> OK.  So if this basically the same what we do when booting XIP from
> parallel NOR, then maybe we should rename CONFIG_NOR_BOOT into a more
> generic name, like CONFIG_XIP_BOOT ?

Nope, not everything for NOR is required for QSPI nor correct, so we'll
still need NOR/QSPI boot options (CONFIG_ENV_IS_IN.. then
size/location).

-- 
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] lib: Add CONFIG_FDT_IGNORE_FIXUP_MEMORY_NODE

[Tom Rini]

On Mon, Apr 07, 2014 at 08:53:39AM +0200, Wolfgang Denk wrote:
> Dear Nobuhiro Iwamatsu,
> 
> In message 
> <1396846600-15386-1-git-send-email-nobuhiro.iwamatsu...@renesas.com> you 
> wrote:
> > Usually, when CONFIG_OF_LIBFDT is enabled, U-Boot is set to
> > the FDT memory information that is set in the U-Boot. This patch
> > disables this behavior.
> > 
> > Signed-off-by: Nobuhiro Iwamatsu 
> > ---
> >  README   | 8 
> >  arch/arm/lib/bootm-fdt.c | 2 ++
> >  2 files changed, 10 insertions(+)
> 
> Please explain why you would want to do this.  To me it makes no
> sense.  Either U-Boot knows the correct memory size, then it should
> pass it to Linux.  Or it does not, then U-Boot should be fixed.
> 
> Also, I object that your implementation is ARM specific.  If such a
> feature gets added, it should be architecture independent.

This has shown up before in the context of platforms with >4GB memory
and we "correct" the node by reducing the system memory, which is
incorrect.  I agree this needs to be done for more than just ARM
however.

-- 
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] CONFIG_SYS_XIP_BOOT for when it's a choice?

[Wolfgang Denk]

Dear Tom,

In message <20140407171943.GG23803@bill-the-cat> you wrote:
> 
> > What exactly do you mean by "non-SPL XIP booting"?  Is this not the
> > standard boot mode which has actually been the first (and only one)
> > that U-Boot has ever been designed for, like booting from a ROM (like
> > parallel NOR flash)?  Because the we do exactly that: we execute the
> > code as is from the boot device...
>
> Exactly.  But most modern platforms are not XIP booting by default, if
> ever.  When it is, it's a special case and needs the code we usually
> only call in SPL (say memory controller init) linked in.  Today this is
> done with say:
> #if defined(CONFIG_SPL_BUILD) || defined(CONFIG_NOR_BOOT)
> ...
> #endif
> on am335x.  Looking at am43xx we have both traditional NOR and QSPI NOR
> as boot options, along with SD/NAND/various-peripheral-boots.

OK.  So if this basically the same what we do when booting XIP from
parallel NOR, then maybe we should rename CONFIG_NOR_BOOT into a more
generic name, like CONFIG_XIP_BOOT ?

I would like to have only one name for one thing...

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Writing a book is like washing an elephant: there's no good place  to
begin  or  end,  and  it's  hard to keep track of what you've already
covered.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/5] spi: ti_qspi: Add delay for successful bulk erase.

[Tom Rini]

On Thu, Apr 03, 2014 at 08:45:42PM +0530, Jagan Teki wrote:
> On Thu, Apr 3, 2014 at 5:22 PM, Tom Rini  wrote:
> > From: "Poddar, Sourav" 
> >
> > Bulk erase is not happening properly on dra7 due to erase timing 
> > constraints,
> > add a delay so that erase timing constraints are properly met.
> >
> > Signed-off-by: Sourav Poddar 
> > Tested-by: Yebio Mesfin 
> > ---
> >  drivers/spi/ti_qspi.c |3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/spi/ti_qspi.c b/drivers/spi/ti_qspi.c
> > index dfa5d0c..c5d2245 100644
> > --- a/drivers/spi/ti_qspi.c
> > +++ b/drivers/spi/ti_qspi.c
> > @@ -314,6 +314,9 @@ int spi_xfer(struct spi_slave *slave, unsigned int 
> > bitlen, const void *dout,
> > qslave->cmd |= QSPI_RD_SNGL;
> > debug("rx cmd %08x dc %08x\n",
> >   qslave->cmd, qslave->dc);
> > +   #ifdef CONFIG_DRA7XX
> > +   udelay(500);
> > +   #endif
> > writel(qslave->cmd, &qslave->base->cmd);
> > status = readl(&qslave->base->status);
> > timeout = QSPI_TIMEOUT;
> 
> Can't we fix this? discussed the same in previous version thread as well.

Sorry, I kicked out v2 before checking my mbox again.  Sourav, do you
have some time to look at this again?

-- 
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] CONFIG_SYS_XIP_BOOT for when it's a choice?

[Tom Rini]

On Mon, Apr 07, 2014 at 07:05:36PM +0200, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20140305172806.GY16805@bill-the-cat> you wrote:
> > 
> > I'm looking over some patches for am43xx to enable the case of non-SPL
> > XIP booting and this means we start getting code that's shared with
> > am335x that looks like:
> 
> What exactly do you mean by "non-SPL XIP booting"?  Is this not the
> standard boot mode which has actually been the first (and only one)
> that U-Boot has ever been designed for, like booting from a ROM (like
> parallel NOR flash)?  Because the we do exactly that: we execute the
> code as is from the boot device...

Exactly.  But most modern platforms are not XIP booting by default, if
ever.  When it is, it's a special case and needs the code we usually
only call in SPL (say memory controller init) linked in.  Today this is
done with say:
#if defined(CONFIG_SPL_BUILD) || defined(CONFIG_NOR_BOOT)
...
#endif
on am335x.  Looking at am43xx we have both traditional NOR and QSPI NOR
as boot options, along with SD/NAND/various-peripheral-boots.

-- 
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] CONFIG_SYS_XIP_BOOT for when it's a choice?

[Wolfgang Denk]

Dear Tom,

In message <20140305172806.GY16805@bill-the-cat> you wrote:
> 
> I'm looking over some patches for am43xx to enable the case of non-SPL
> XIP booting and this means we start getting code that's shared with
> am335x that looks like:


What exactly do you mean by "non-SPL XIP booting"?  Is this not the
standard boot mode which has actually been the first (and only one)
that U-Boot has ever been designed for, like booting from a ROM (like
parallel NOR flash)?  Because the we do exactly that: we execute the
code as is from the boot device...

> Because we need to do certain init either in SPL or early U-Boot.  While
> I don't see another XIP boot case being added anytime soon, it would be
> nice to instead write:

What you call "XIP boot" is the default for all systems booting from
NOR flash (or other boot ROM) - or am I missing something?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Voodoo Programming: Things programmers do that  they  know  shouldn't
work  but they try anyway, and which sometimes actually work, such as
recompiling everything. - Karl Lehenbauer
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v6 2/9] tools: mkimage: add support for gpimage format

[Wolfgang Denk]

Dear Tom & Gerhard,

In message <20140407135502.GB23803@bill-the-cat> you wrote:
> 
> > the above hunk just references the newly introduced enum, and
> > keeps the list of images sorted alphabetically -- so I think this
> > is OK
> 
> Yes, agreed.

You both are roght, of course.  Hm,  now where is this big brown paper
bag...  Ah, here...

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
God runs electromagnetics by wave theory on  Monday,  Wednesday,  and
Friday,  and the Devil runs them by quantum theory on Tuesday, Thurs-
day, and Saturday.   -- William Bragg
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Fix USB keyboard polling via control endpoint

[Wolfgang Denk]

Dear Adrian,

In message <3392231.3254.1396864604431.JavaMail.adrian@Gurnard> you wrote:
> 
> > From: "Wolfgang Denk" 
> 
> > I agree that the code is wrong and needs fixing.  data->new is an
> > uint8_t pointer, so taking the size of the pointer is obviously
> > wrong.  But what you fix here is not the only place where
> > sizeof(data->new) is used, so this patch fixes part of the problem at
> > best.
> 
> I can't find any other instances of sizeof in usb_kbd.c.

Yes, you are right.  I did not see that your patch fixes both
occurrences of sizeof(data->new).

> Is this a broader problem in the USB stack?

I haven't looked at the other code, so I cannot comment on that.

> > Can you please try out if the following extended version f the patch
> > works and fixes your problem?  You will note that I removed all
> > occurrences of this magic number 8 by replacing it with
> > USB_KBD_PDATA_SIZE  so the could should also be easier to read.
> 
> I've tested your extended patch, and it does fix the problem for me. I agree 
> that adding USB_KBD_PDATA_SIZE
> does improve readability.

Thanks for testing.

Marek, can you then please use my version of the patch instead of the
original one?

Thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
In accord with UNIX philosophy, Perl gives you enough  rope  to  hang
yourself.  - L. Wall & R. L. Schwartz, _Programming Perl_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Different Port for TFTP communication

[Wolfgang Denk]

Dear Mario,

In message  you 
wrote:
>
> I have a short question about TFTP usage in u-boot.
> Is it possible to change the Port for TFTP communication
> while u-boot is running. Standard path for TFTP is 69
> an let's say, we want to change port to 1500.

As is, this cannot be changed.  The TFTP port number is hard wired
in the code - see "net/tftp.c":

...
 18 /* Well known TFTP port # */
 19 #define WELL_KNOWN_PORT 69
...

Of course it should be trivial to add a config option for this, or
even make it changable at runtime.  But I have to admit that I don't
see many actual use cases for such a modification.

Could you please explain why you need to do this - is this just some
exotic environment, or is this needed for some more general use case?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
For those who like this sort of thing, this is the sort of thing they
like.   - Abraham Lincoln
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] CONFIG_SYS_XIP_BOOT for when it's a choice?

[Tom Rini]

On Mon, Apr 07, 2014 at 06:31:41PM +0200, Albert ARIBAUD wrote:
> Hi Tom,
> 
> On Wed, 5 Mar 2014 12:28:06 -0500, Tom Rini  wrote:
> 
> > Hey all,
> > 
> > I'm looking over some patches for am43xx to enable the case of non-SPL
> > XIP booting and this means we start getting code that's shared with
> > am335x that looks like:
> > #if defined(CONFIG_SPL_BUILD) || defined(CONFIG_NOR_BOOT) || \
> > defined(CONFIG_QSPI_BOOT)
> > ...
> > #endif
> > 
> > Because we need to do certain init either in SPL or early U-Boot.  While
> > I don't see another XIP boot case being added anytime soon, it would be
> > nice to instead write:
> > #if defined(CONFIG_SPL_BUILD) || defined(CONFIG_SYS_XIP_BOOT)
> > or whatever makes the most sense for a name.  Thoughts on the name?
> > Thanks!
> 
> Or maybe name the config option not after the boot mode but after what
> it actually does, and then in the board config, enable this option if
> the boot mode wants it?

Right.  But what to call the option?

-- 
Tom


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

Re: [U-Boot] [PATCH v2 8/8] embest/mx6boards: use common detect_hdmi

[Stefano Babic]

On 04/04/2014 19:05, Eric Bénard wrote:
> Signed-off-by: Eric Bénard 
> ---


Applied to u-boot-imx, -next branch, thanks !

Best regards,
Stefano Babic



-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 7/8] mx6sabresd: use common detect_hdmi

[Stefano Babic]

On 04/04/2014 19:05, Eric Bénard wrote:
> Signed-off-by: Eric Bénard 
> ---

Applied to u-boot-imx, -next branch, thanks !

Best regards,
Stefano Babic


-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 6/8] nitrogen6x: use common detect_hdmi

[Stefano Babic]

On 04/04/2014 19:05, Eric Bénard wrote:
> Signed-off-by: Eric Bénard 
> ---


Applied to u-boot-imx, -next branch, thanks !

Best regards,
Stefano Babic



-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 5/8] imx-common/video: add detect_hdmi

[Stefano Babic]

On 04/04/2014 19:05, Eric Bénard wrote:
> this function is used by several board together with board_video_skip
> to detect if hdmi is plugged is order to select the display to use.
> So move it in imx-common to share it.
> 
> Signed-off-by: Eric Bénard 
> ---

Applied to u-boot-imx, -next branch, thanks !

Best regards,
Stefano Babic



-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 4/8] RiOTboard and MarSBoard: add new boards support

[Stefano Babic]

On 04/04/2014 19:05, Eric Bénard wrote:
> RiOTboard is produced by Embest/Element 14 and is based on i.MX6 Solo
> The following features are tested :
> - UART2 (console)
> - eMMC
> - SDCard
> - uSDCard
> - Ethernet
> - USB Host (through 4 ports hub)
> - HDMI output
> - I2C 1/2/3
> - LVDS TFT with LCD8000-97C from Embest/Element 14
> 
> Boot on eMMC and through USB loader are tested.
> 
> For more informations on this board : http://www.riotboard.org/
> 
> MarSBoard is produced by Embest/Element 14 and is based on i.MX6 Dual
> The following features are tested :
> - UART2 (console)
> - eMMC
> - uSDCard
> - Ethernet
> - USB Host (through 2 ports hub)
> - HDMI output
> - I2C 1/2
> - SPI NOR Flash
> - LVDS TFT with LCD8000-97C from Embest/Element 14
> 
> Boot on SPI NOR and through USB loader are tested.
> 
> For more informations on this board :
> http://www.embest-tech.com/shop/star/marsboard.html
> 
> Both boards are supported by the same code base as they are based on a
> common trunk of schematics.
> 
> Signed-off-by: Eric Bénard 
> Acked-by: Stefano Babic 
> ---

Applied to u-boot-imx, -next branch, thanks !

Best regards,
Stefano Babic



-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/8] imx-common: add board_video_skip

[Stefano Babic]

On 04/04/2014 19:05, Eric Bénard wrote:
> this function is shared by several boards and thus can be factorized
> 
> Signed-off-by: Eric Bénard 
> Acked-by: Eric Nelson 
> Acked-by: Stefano Babic 
> ---

Applied to u-boot-imx, -next branch, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/8] mx6sabresd: use common board_video_skip

[Stefano Babic]

On 04/04/2014 19:05, Eric Bénard wrote:
> Signed-off-by: Eric Bénard 
> ---


Applied to u-boot-imx, -next branch, thanks !

Best regards,
Stefano Babic



-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 2/8] nitrogen6x: use common board_video_skip

[Stefano Babic]

On 04/04/2014 19:05, Eric Bénard wrote:
> Signed-off-by: Eric Bénard 
> Acked-by: Eric Nelson 
> ---


Applied to u-boot-imx, -next branch, thanks !

Best regards,
Stefano Babic


-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH/RFC] Reintegration of ns9750

[Albert ARIBAUD]

Hi Marek,

Sorry, I am slowly catching up.

On Sat, 22 Mar 2014 19:27:48 +0100, Marek Vasut  wrote:

> On Saturday, March 22, 2014 at 11:18:05 AM, Rikard Söderström wrote:
> > Hi Marex,
> > 
> > Are you referring to the code or the linkage issue as "nasty"?
> 
> Actually, both. But more the linker issue this time ;-)

Phew. I though /I/ was the nasty one. :)

Will look at the patch ASAP.
 
> Best regards,
> Marek Vasut

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

Re: [U-Boot] CONFIG_SYS_XIP_BOOT for when it's a choice?

[Albert ARIBAUD]

Hi Tom,

On Wed, 5 Mar 2014 12:28:06 -0500, Tom Rini  wrote:

> Hey all,
> 
> I'm looking over some patches for am43xx to enable the case of non-SPL
> XIP booting and this means we start getting code that's shared with
> am335x that looks like:
> #if defined(CONFIG_SPL_BUILD) || defined(CONFIG_NOR_BOOT) || \
>   defined(CONFIG_QSPI_BOOT)
> ...
> #endif
> 
> Because we need to do certain init either in SPL or early U-Boot.  While
> I don't see another XIP boot case being added anytime soon, it would be
> nice to instead write:
> #if defined(CONFIG_SPL_BUILD) || defined(CONFIG_SYS_XIP_BOOT)
> or whatever makes the most sense for a name.  Thoughts on the name?
> Thanks!

Or maybe name the config option not after the boot mode but after what
it actually does, and then in the board config, enable this option if
the boot mode wants it?

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

Re: [U-Boot] [PATCH v4 1/2] watchdog/denali: Adding DesignWare watchdog driver support

[Albert ARIBAUD]

Hi Chin,

On Tue, 4 Mar 2014 20:51:53 -0600, Chin Liang See 
wrote:

> To add the DesignWare watchdog driver support. It required
> information such as register base address and clock info from
> configuration header file  within include/configs folder.
> 
> Signed-off-by: Chin Liang See 
> Cc: Anatolij Gustschin 
> Cc: Albert Aribaud 
> Cc: Heiko Schocher 
> Cc: Tom Rini 
> ---
> Changes for v4
> - Added static for local function
> Changes for v3
> - Split to 2 series patch
> Changes for v2
> - Enable this driver at socfpga_cyclone5 board
> ---

IIUC, there are now two V4 of this series, with different histories:

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

and

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

The latter (to which I am answering) should have been V5 as it answers
change requests done on the "first V4", and should have history
including the V4 entries of the "first V4" and V5 entries too.

Please re-send as proper V5 (making sure it still builds on current ARM
ToT, just in case).

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

[U-Boot] FEC_MXC leftovers

[Nikolay Dimitrov]

Gents,

In "drivers/net/fec_mxc.c" there are 2 functions:

int fec_phy_read(struct mii_dev *bus, int phyAddr, int dev_addr, int 
regAddr);
int fec_phy_write(struct mii_dev *bus, int phyAddr, int dev_addr, int 
regAddr, u16 data);


Looks like parameter "dev_addr" is not used. Does anyone remember what 
was the purpose of this parameter? It looks like this interface is 
replicated all over the mdio- and mii- functions.


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

Re: [U-Boot] Is it OK to use target code from host tools

[Albert ARIBAUD]

Hi Charles,

On Wed, 5 Mar 2014 11:30:26 +1300, Charles Manning
 wrote:

> Hello All
> 
> I am currently reworking a socfpga signer patch which is part of mkimage.
> 
> One thing I need to do is to stuff some bytes into a header ensuring the
> endianism is correct.
> 
> This is a trivial thing to do in C, but I have been instructed to use the
> existing functions put_unaligned_le32() etc.
> 
> These are part of Linux in linux/unaligned/access_ok.h. But this includes
> 
> 
> It seems to me that this mixing of host space and target space is
> potentially problematic.

Hmm... Where exactly is there a mixing of host and target?

> Is this a safe thing to do?
> 
> Thanks
> 
> Charles


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

[U-Boot] [PULL] : Please pull u-boot-imx

[Stefano Babic]

Hi Albert,

this contains the fix for the i.MX6 errata. I do not foresee now to send
another PR before release, maybe this is the last one for 2014.04.

The following changes since commit 1a9df13d5bc0b68c9dcae88d244c995c9351db67:

  arm: mxs: Add support for generating signed BootStream (2014-04-04
11:44:59 +0200)

are available in the git repository at:

  git://www.denx.de/git/u-boot-imx.git master

for you to fetch changes up to 68659d649debc9fb3d8ce21ce4dcfe3a66b63e3a:

  MX6: Enable ARM errata workaround 794072 and 761320 (2014-04-07
18:11:01 +0200)


Nitin Garg (3):
  ARM: Add workaround for Cortex-A9 errata 794072
  ARM: Add workaround for Cortex-A9 errata 761320
  MX6: Enable ARM errata workaround 794072 and 761320

 README   |2 ++
 arch/arm/cpu/armv7/start.S   |7 ++-
 include/configs/mx6_common.h |2 ++
 3 files changed, 10 insertions(+), 1 deletion(-)

Best regards,
Stefano

-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 2/3] ARM: Add workaround for Cortex-A9 errata 761320

[Stefano Babic]

On 02/04/2014 15:55, nitin.g...@freescale.com wrote:
> From: Nitin Garg 
> 
> Full cache line writes to the same memory region from at least two
> processors might deadlock the processor. Exists on r1, r2, r3
> revisions.
> 
> Signed-off-by: Nitin Garg 
> ---

Applied to u-boot-imx, thanks !

Best regards,
Stefano Babic


-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 1/3] ARM: Add workaround for Cortex-A9 errata 794072

[Stefano Babic]

On 02/04/2014 15:55, nitin.g...@freescale.com wrote:
> From: Nitin Garg 
> 
> A short loop including a DMB instruction might cause a denial of
> service on another processor which executes a CP15 broadcast operation.
> Exists on r1, r2, r3, r4 revisions.
> 
> Signed-off-by: Nitin Garg 
> Acked-by: Dirk Behme 
> ---

Applied to u-boot-imx, thanks !

Best regards,
Stefano Babic


-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 3/3] MX6: Enable ARM errata workaround 794072 and 761320

[Stefano Babic]

On 02/04/2014 15:55, nitin.g...@freescale.com wrote:
> From: Nitin Garg 
> 
> Since MX6 is Cortex-A9 r2p10, enable software workaround
> for errata 794072 and 761320.
> 
> Signed-off-by: Nitin Garg 
> ---

Applied to u-boot-imx, thanks !

Best regards,
Stefano Babic



-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [Patch v2 1/3] armv8/cache: Consolidate setting for MAIR and TCR

[Albert ARIBAUD]

Hi York,

On Wed, 26 Feb 2014 13:26:02 -0800, York Sun 
wrote:

> Move setting for MAIR and TCR to cache_v8.c, to avoid conflict with
> sub-architecture.
> 
> Signed-off-by: York Sun 
> CC: David Feng 
> ---

Whole series applied to u-boot-arm/master, thanks!

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

Re: [U-Boot] [PATCH] doc:power:pmic: Add doc entry for PMIC(v2) framework

[Simon Glass]

Hi Lukasz,

On 7 April 2014 06:34, Lukasz Majewski  wrote:

> Well written documentation for PMIC framework was missing and hence
> it has been probably difficult and time consuming for other developers
> to understand rationale for key design decisions and overall design
> structure.
> This commit provides proper documentation entry.
>
> Signed-off-by: Lukasz Majewski 
>

Acked-by: Simon Glass 

But it would be good to say "U-Boot"

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

Re: [U-Boot] [Question] How is the Falcon mode working

[Stefano Babic]

Hi Frank,

On 07/04/2014 15:49, Frank Ihle wrote:
> Hi U-Boot,
> 
> you recently gave me the hint about the Falcon Mode for my Fast
> Booting investigations. But I think might got it wrong, could
> somebody correct me if so?:
> 
> - According to the "Falcon Mode" Pdf of October 2013
> (http://www.denx.de/wiki/pub/U-Boot/MiniSummitELCE2013/2013-ELCE-U-Boot-Falcon-Boot.pdf)
> The Falcon mode is just about to chose 2 different execution modes
> during startup - one that starts Linux directly (and skips u-boot)
> and the other for instance to make updates, or failsafe mode (and
> starts u-boot). Or does it even contain more functionality ?

The second starts U-Boot as you are used to.

> - According to the "Minimizing boot times using U-Boot Falcon Mode"
> Pdf of July 2012 
> (http://schedule2012.rmll.info/IMG/pdf/LSM2012_UbootFalconMode_Babic.pdf)
> it's mentioned that this can only run with boards, which are able to
> work with SPL. I guess here SPL means Second Programm Bootloader. I'm
> not an expert in this area, but wouldn't it be possible to run every
> board with an SPL, since it's just Software like a Bootloader?

Of course, but not all boards supported in mainline were converted to
use SPL, and for this reason not all boards support out of the box
Falcon Mode.

> And if
> not what is the "real" eye of the needle here ? I'm just asking
> because I didn't get the problem here.

It is simply a snapshot of the current U-Boot mainline. The switch
between Linux/U-Boot is implemented in SPL, and this makes sense because
SPL is much smaller that the whole U-Boot, dropping also the time that a
SOC needs to load an image from the storage media.

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 0/3] pcnet driver fixes

[Paul Burton]

This series fixes issues with the pcnet driver & its memory accesses.

Previously the network interface on the MIPS Malta board was unreliable
& would often time out whilst transferring files via TFTP, but with this
series applied it is now stable.

Paul Burton (3):
  pcnet: access descriptor rings & init block uncached
  pcnet: align rx buffers for cache invalidation
  pcnet: force ordering of descriptor accesses

 drivers/net/pcnet.c | 122 
 1 file changed, 65 insertions(+), 57 deletions(-)

-- 
1.8.5.3

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

[U-Boot] [PATCH 3/3] pcnet: force ordering of descriptor accesses

[Paul Burton]

The ordering of accesses to the rx & tx descriptors is important, yet
the send & recv functions accessed them via regular structure accesses.
This leaves the compiler with the opportunity to reorder those accesses
or to hoist them outside of loops. Prevent that from happening by using
readl & writel to access the descriptors. As a nice bonus, this removes
the need for the driver to care about endianness.

Signed-off-by: Paul Burton 
---
 drivers/net/pcnet.c | 37 +++--
 1 file changed, 19 insertions(+), 18 deletions(-)

diff --git a/drivers/net/pcnet.c b/drivers/net/pcnet.c
index 2802411..237fbba 100644
--- a/drivers/net/pcnet.c
+++ b/drivers/net/pcnet.c
@@ -434,7 +434,7 @@ static int pcnet_send(struct eth_device *dev, void *packet, 
int pkt_len)
 
/* Wait for completion by testing the OWN bit */
for (i = 1000; i > 0; i--) {
-   status = le16_to_cpu(entry->status);
+   status = readw(&entry->status);
if ((status & 0x8000) == 0)
break;
udelay(100);
@@ -451,11 +451,10 @@ static int pcnet_send(struct eth_device *dev, void 
*packet, int pkt_len)
 * Setup Tx ring. Caution: the write order is important here,
 * set the status with the "ownership" bits last.
 */
-   status = 0x8300;
-   entry->length = cpu_to_le16(-pkt_len);
-   entry->misc = 0x;
-   entry->base = PCI_TO_MEM_LE(dev, packet);
-   entry->status = cpu_to_le16(status);
+   writew(-pkt_len, &entry->length);
+   writel(0, &entry->misc);
+   writel(PCI_TO_MEM(dev, packet), &entry->base);
+   writew(0x8300, &entry->status);
 
/* Trigger an immediate send poll. */
pcnet_write_csr(dev, 0, 0x0008);
@@ -473,34 +472,34 @@ static int pcnet_recv (struct eth_device *dev)
struct pcnet_rx_head *entry;
unsigned char *buf;
int pkt_len = 0;
-   u16 status;
+   u16 status, err_status;
 
while (1) {
entry = &lp->uc->rx_ring[lp->cur_rx];
/*
 * If we own the next entry, it's a new packet. Send it up.
 */
-   status = le16_to_cpu(entry->status);
+   status = readw(&entry->status);
if ((status & 0x8000) != 0)
break;
-   status >>= 8;
+   err_status = status >> 8;
 
-   if (status != 0x03) {   /* There was an error. */
+   if (err_status != 0x03) {   /* There was an error. */
printf("%s: Rx%d", dev->name, lp->cur_rx);
-   PCNET_DEBUG1(" (status=0x%x)", status);
-   if (status & 0x20)
+   PCNET_DEBUG1(" (status=0x%x)", err_status);
+   if (err_status & 0x20)
printf(" Frame");
-   if (status & 0x10)
+   if (err_status & 0x10)
printf(" Overflow");
-   if (status & 0x08)
+   if (err_status & 0x08)
printf(" CRC");
-   if (status & 0x04)
+   if (err_status & 0x04)
printf(" Fifo");
printf(" Error\n");
-   entry->status &= le16_to_cpu(0x03ff);
+   status &= 0x03ff;
 
} else {
-   pkt_len = (le32_to_cpu(entry->msg_length) & 0xfff) - 4;
+   pkt_len = (readl(&entry->msg_length) & 0xfff) - 4;
if (pkt_len < 60) {
printf("%s: Rx%d: invalid packet length %d\n",
   dev->name, lp->cur_rx, pkt_len);
@@ -513,7 +512,9 @@ static int pcnet_recv (struct eth_device *dev)
 lp->cur_rx, pkt_len, buf);
}
}
-   entry->status |= cpu_to_le16(0x8000);
+
+   status |= 0x8000;
+   writew(status, &entry->status);
 
if (++lp->cur_rx >= RX_RING_SIZE)
lp->cur_rx = 0;
-- 
1.8.5.3

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

[U-Boot] [PATCH 1/3] pcnet: access descriptor rings & init block uncached

[Paul Burton]

The prior accesses to the descriptor rings & init block via cached
memory had a few issues:

  - The memory needs cache flushes or invalidation at the appropriate
times, but was not necessarily aligned on cache line boundaries.
This could lead to data being incorrectly lost or written back to
RAM at the wrong time.

  - There are points where ordering of writes to the memory is
important, but because it's cached memory the pcnet controller
would see cache lines written back ordered by address. This could
occasionally lead to hardware seeing descriptors in an incorrect
state.

  - Flushing the cache constantly is inefficient.

So, to avoid all of those issues simply access the descriptors & init
block via uncached memory. The MIPS-specific UNCACHED_SDRAM macro is
used to do this (retrieving an address in kseg1) as I could see no
existing generic solution. Since the MIPS Malta board is the only user
of the pcnet driver, hopefully this doesn't matter.

Signed-off-by: Paul Burton 
---
 drivers/net/pcnet.c | 66 -
 1 file changed, 35 insertions(+), 31 deletions(-)

diff --git a/drivers/net/pcnet.c b/drivers/net/pcnet.c
index 71a3110..8c334c7 100644
--- a/drivers/net/pcnet.c
+++ b/drivers/net/pcnet.c
@@ -71,10 +71,14 @@ struct pcnet_init_block {
u32 reserved2;
 };
 
-typedef struct pcnet_priv {
+struct pcnet_uncached_priv {
struct pcnet_rx_head rx_ring[RX_RING_SIZE];
struct pcnet_tx_head tx_ring[TX_RING_SIZE];
struct pcnet_init_block init_block;
+};
+
+typedef struct pcnet_priv {
+   struct pcnet_uncached_priv *uc;
/* Receive Buffer space */
unsigned char rx_buf[RX_RING_SIZE][PKT_BUF_SZ + 4];
int cur_rx;
@@ -283,6 +287,7 @@ static int pcnet_probe(struct eth_device *dev, bd_t *bis, 
int dev_nr)
 
 static int pcnet_init(struct eth_device *dev, bd_t *bis)
 {
+   struct pcnet_uncached_priv *uc;
int i, val;
u32 addr;
 
@@ -325,24 +330,31 @@ static int pcnet_init(struct eth_device *dev, bd_t *bis)
addr = (u32)malloc(sizeof(pcnet_priv_t) + 0x10);
addr = (addr + 0xf) & ~0xf;
lp = (pcnet_priv_t *)addr;
+
+   addr = (u32)memalign(ARCH_DMA_MINALIGN, sizeof(*lp->uc));
+   flush_dcache_range(addr, addr + sizeof(*lp->uc));
+   addr = UNCACHED_SDRAM(addr);
+   lp->uc = (struct pcnet_uncached_priv *)addr;
}
 
-   lp->init_block.mode = cpu_to_le16(0x);
-   lp->init_block.filter[0] = 0x;
-   lp->init_block.filter[1] = 0x;
+   uc = lp->uc;
+
+   uc->init_block.mode = cpu_to_le16(0x);
+   uc->init_block.filter[0] = 0x;
+   uc->init_block.filter[1] = 0x;
 
/*
 * Initialize the Rx ring.
 */
lp->cur_rx = 0;
for (i = 0; i < RX_RING_SIZE; i++) {
-   lp->rx_ring[i].base = PCI_TO_MEM_LE(dev, lp->rx_buf[i]);
-   lp->rx_ring[i].buf_length = cpu_to_le16(-PKT_BUF_SZ);
-   lp->rx_ring[i].status = cpu_to_le16(0x8000);
+   uc->rx_ring[i].base = PCI_TO_MEM_LE(dev, lp->rx_buf[i]);
+   uc->rx_ring[i].buf_length = cpu_to_le16(-PKT_BUF_SZ);
+   uc->rx_ring[i].status = cpu_to_le16(0x8000);
PCNET_DEBUG1
("Rx%d: base=0x%x buf_length=0x%hx status=0x%hx\n", i,
-lp->rx_ring[i].base, lp->rx_ring[i].buf_length,
-lp->rx_ring[i].status);
+uc->rx_ring[i].base, uc->rx_ring[i].buf_length,
+uc->rx_ring[i].status);
}
 
/*
@@ -351,34 +363,34 @@ static int pcnet_init(struct eth_device *dev, bd_t *bis)
 */
lp->cur_tx = 0;
for (i = 0; i < TX_RING_SIZE; i++) {
-   lp->tx_ring[i].base = 0;
-   lp->tx_ring[i].status = 0;
+   uc->tx_ring[i].base = 0;
+   uc->tx_ring[i].status = 0;
}
 
/*
 * Setup Init Block.
 */
-   PCNET_DEBUG1("Init block at 0x%p: MAC", &lp->init_block);
+   PCNET_DEBUG1("Init block at 0x%p: MAC", &lp->uc->init_block);
 
for (i = 0; i < 6; i++) {
-   lp->init_block.phys_addr[i] = dev->enetaddr[i];
-   PCNET_DEBUG1(" %02x", lp->init_block.phys_addr[i]);
+   lp->uc->init_block.phys_addr[i] = dev->enetaddr[i];
+   PCNET_DEBUG1(" %02x", lp->uc->init_block.phys_addr[i]);
}
 
-   lp->init_block.tlen_rlen = cpu_to_le16(TX_RING_LEN_BITS |
+   uc->init_block.tlen_rlen = cpu_to_le16(TX_RING_LEN_BITS |
   RX_RING_LEN_BITS);
-   lp->init_block.rx_ring = PCI_TO_MEM_LE(dev, lp->rx_ring);
-   lp->init_block.tx_ring = PCI_TO_MEM_LE(dev, lp->tx_ring);
-   flush_dcache_range((unsigned long)lp, (unsigned long)&lp->rx_buf);
+   uc->init_block.rx_ring 

[U-Boot] [PATCH 2/3] pcnet: align rx buffers for cache invalidation

[Paul Burton]

The RX buffers are invalidated when a packet is received, however they
were not suitably cache-line aligned. Allocate them seperately to the
pcnet_priv structure and align to ARCH_DMA_MINALIGN in order to ensure
suitable alignment for the cache invalidation, preventing anything else
being placed in the same lines & lost.

Signed-off-by: Paul Burton 
---
 drivers/net/pcnet.c | 21 -
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/drivers/net/pcnet.c b/drivers/net/pcnet.c
index 8c334c7..2802411 100644
--- a/drivers/net/pcnet.c
+++ b/drivers/net/pcnet.c
@@ -80,7 +80,7 @@ struct pcnet_uncached_priv {
 typedef struct pcnet_priv {
struct pcnet_uncached_priv *uc;
/* Receive Buffer space */
-   unsigned char rx_buf[RX_RING_SIZE][PKT_BUF_SZ + 4];
+   unsigned char (*rx_buf)[RX_RING_SIZE][PKT_BUF_SZ + 4];
int cur_rx;
int cur_tx;
 } pcnet_priv_t;
@@ -335,6 +335,10 @@ static int pcnet_init(struct eth_device *dev, bd_t *bis)
flush_dcache_range(addr, addr + sizeof(*lp->uc));
addr = UNCACHED_SDRAM(addr);
lp->uc = (struct pcnet_uncached_priv *)addr;
+
+   addr = (u32)memalign(ARCH_DMA_MINALIGN, sizeof(*lp->rx_buf));
+   flush_dcache_range(addr, addr + sizeof(*lp->rx_buf));
+   lp->rx_buf = (void *)addr;
}
 
uc = lp->uc;
@@ -348,7 +352,7 @@ static int pcnet_init(struct eth_device *dev, bd_t *bis)
 */
lp->cur_rx = 0;
for (i = 0; i < RX_RING_SIZE; i++) {
-   uc->rx_ring[i].base = PCI_TO_MEM_LE(dev, lp->rx_buf[i]);
+   uc->rx_ring[i].base = PCI_TO_MEM_LE(dev, (*lp->rx_buf)[i]);
uc->rx_ring[i].buf_length = cpu_to_le16(-PKT_BUF_SZ);
uc->rx_ring[i].status = cpu_to_le16(0x8000);
PCNET_DEBUG1
@@ -467,6 +471,7 @@ static int pcnet_send(struct eth_device *dev, void *packet, 
int pkt_len)
 static int pcnet_recv (struct eth_device *dev)
 {
struct pcnet_rx_head *entry;
+   unsigned char *buf;
int pkt_len = 0;
u16 status;
 
@@ -500,14 +505,12 @@ static int pcnet_recv (struct eth_device *dev)
printf("%s: Rx%d: invalid packet length %d\n",
   dev->name, lp->cur_rx, pkt_len);
} else {
-   invalidate_dcache_range(
-   (unsigned long)lp->rx_buf[lp->cur_rx],
-   (unsigned long)lp->rx_buf[lp->cur_rx] +
-   pkt_len);
-   NetReceive(lp->rx_buf[lp->cur_rx], pkt_len);
+   buf = (*lp->rx_buf)[lp->cur_rx];
+   invalidate_dcache_range((unsigned long)buf,
+   (unsigned long)buf + pkt_len);
+   NetReceive(buf, pkt_len);
PCNET_DEBUG2("Rx%d: %d bytes from 0x%p\n",
-lp->cur_rx, pkt_len,
-lp->rx_buf[lp->cur_rx]);
+lp->cur_rx, pkt_len, buf);
}
}
entry->status |= cpu_to_le16(0x8000);
-- 
1.8.5.3

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

Re: [U-Boot] [PATCH 6/7] omap3: zoom1: enable bootz

[Tom Rini]

On Thu, Apr 03, 2014 at 06:19:25PM -0500, Nishanth Menon wrote:

> Boot from zImage and fdt_file if uImage is not available to maintain
> the legacy behavior.
[snip]
>  #define CONFIG_EXTRA_ENV_SETTINGS \
>   "loadaddr=0x8200\0" \
> + "fdt_high=0x\0" \
> + "fdtaddr=0x80f8\0" \

OK, how much memory does this board ever have?  If less than 512MB,
don't do fdt_high.  If 256MB or more, please put fdtaddr at base+128MB.
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 5/7] omap3: zoom1: disable JFFS2 and enable FS_GENERIC

[Tom Rini]

On Thu, Apr 03, 2014 at 06:19:24PM -0500, Nishanth Menon wrote:

> This is more in line with commits
> 664979a2a9f764b63b8094458b87247d254b0cc1(omap3_beagle: remove JFFS2
> support.) and 102ce9ea7afdda80fe25aa786975e1722196bdb9 (omap3_beagle:
> enable CMD_FS_GENERIC and simplify load of image/ramdisk)
> 
> SigMD_FS_GENERIC allows us to simplify where we load up our image from

Regex gone awry, otherwise looks fine.

-- 
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] fs: fat: Fix cache align error message in fatwrite to use USB media

[Hector Palacios]

Hello,

On 04/03/2014 06:44 AM, Nobuhiro Iwamatsu wrote:

Use of malloc of do_fat_write() from USB media causes cache error on


I would remove 'from USB media' from the commit log as it doesn't really matter where 
you read from.



ARM v7 platforms. Perhaps, the same problem will occur at any other CPUs.
This replaces malloc with memalign to fix cache buffer alignment.

Signed-off-by: Nobuhiro Iwamatsu 
Signed-off-by: Yoshiyuki Ito 
---
  fs/fat/fat_write.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c
index 9f5e911..cef138e 100644
--- a/fs/fat/fat_write.c
+++ b/fs/fat/fat_write.c
@@ -952,7 +952,7 @@ static int do_fat_write(const char *filename, void *buffer,
}

mydata->fatbufnum = -1;
-   mydata->fatbuf = malloc(FATBUFSIZE);
+   mydata->fatbuf = memalign(ARCH_DMA_MINALIGN, FATBUFSIZE);
if (mydata->fatbuf == NULL) {
debug("Error: allocating memory\n");
return -1;



Tested on an i.MX6 custom platform.

Tested-by: Hector Palacios 

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

Re: [U-Boot] [PATCH 0/7] omap3: zoom1: long pending cleanups :(

[Tom Rini]

On Thu, Apr 03, 2014 at 06:19:19PM -0500, Nishanth Menon wrote:

> A series of patches to add in ethernet and bootz support.
> 
> baseline: v2014.04-rc3
> 
> 
> Nishanth Menon (7):
>   omap3: zoom1: enable CONFIG_SYS_GENERIC_BOARD
>   OMAP3: zoom1: Configure GPMC for Ethernet
>   OMAP3: zoom1: enable LAN9211
>   omap3: zoom1: enable common network commands
>   omap3: zoom1: disable JFFS2 and enable FS_GENERIC
>   omap3: zoom1: enable bootz
>   omap3: zoom1: fix default console
> 
>  board/logicpd/zoom1/zoom1.c   |   38 --
>  board/logicpd/zoom1/zoom1.h   |   19 ++-
>  include/configs/omap3_zoom1.h |   52 
> ++---

Can you switch over to include/configs/ti_omap3_common.h as well?  I
suspect you'll need some of the patches I posted for omap3_evm to do so
tho.  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 v6 2/9] tools: mkimage: add support for gpimage format

[Tom Rini]

On Mon, Apr 07, 2014 at 03:21:35PM +0200, Gerhard Sittig wrote:
> On Fri, 2014-04-04 at 22:45 +0200, Wolfgang Denk wrote:
> > 
> > Dear Murali Karicheri,
> > 
> > In message <1396631815-5735-3-git-send-email-m-kariche...@ti.com> you wrote:
> > > This patch add support for gpimage format as a preparatory
> > > patch for porting u-boot for keystone2 devices and is
> > > based on omapimage format. It re-uses gph header to store the
> > > size and loadaddr as done in omapimage.c
> > ...
> > > @@ -125,6 +125,7 @@ static const table_entry_t uimage_type[] = {
> > >   {   IH_TYPE_FILESYSTEM, "filesystem", "Filesystem Image",   },
> > >   {   IH_TYPE_FIRMWARE,   "firmware",   "Firmware",   },
> > >   {   IH_TYPE_FLATDT, "flat_dt","Flat Device Tree",   },
> > > + {   IH_TYPE_GPIMAGE,"gpimage","TI Keystone SPL Image",},
> > >   {   IH_TYPE_KERNEL, "kernel", "Kernel Image",   },
> > >   {   IH_TYPE_KERNEL_NOLOAD, "kernel_noload",  "Kernel Image (no 
> > > loading done)", },
> > >   {   IH_TYPE_KWBIMAGE,   "kwbimage",   "Kirkwood Boot Image",},
> > 
> > For binary compatibility with existing images you can only appen, but
> > never insert into uimage_type[].
> 
> the next hunk (declaration of the IH_TYPE_GPIMAGE enum value) did
> the append, using a number past all previously used numbers,
> keeping compatibility with existing binaries
> 
> the above hunk just references the newly introduced enum, and
> keeps the list of images sorted alphabetically -- so I think this
> is OK

Yes, agreed.

-- 
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] [Question] How is the Falcon mode working

[Frank Ihle]

Hi U-Boot,

you recently gave me the hint about the Falcon Mode for my Fast Booting 
investigations. But I think might got it wrong, could somebody correct me if 
so?:

- According to the "Falcon Mode" Pdf of October 2013 
(http://www.denx.de/wiki/pub/U-Boot/MiniSummitELCE2013/2013-ELCE-U-Boot-Falcon-Boot.pdf)
 The Falcon mode is just about to chose 2 different execution modes during 
startup - one that starts Linux directly (and skips u-boot) and the other for 
instance to make updates, or failsafe mode (and starts u-boot). Or does it even 
contain more functionality ?

- According to the "Minimizing boot times using U-Boot Falcon Mode" Pdf of July 
2012 
(http://schedule2012.rmll.info/IMG/pdf/LSM2012_UbootFalconMode_Babic.pdf) it's 
mentioned that this can only run with boards, which are able to work with SPL. 
I guess here SPL means Second Programm Bootloader. I'm not an expert in this 
area, but wouldn't it be possible to run every board with an SPL, since it's 
just Software like a Bootloader? And if not what is the "real" eye of the 
needle here ? I'm just asking because I didn't get the problem here.

Thanks for your time

Kind Regards

Frank

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

[U-Boot] Different Port for TFTP communication

[Mario Albrecht]

Hi,

I have a short question about TFTP usage in u-boot.
Is it possible to change the Port for TFTP communication
while u-boot is running. Standard path for TFTP is 69
an let's say, we want to change port to 1500.

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

Re: [U-Boot] [PATCH v6 2/9] tools: mkimage: add support for gpimage format

[Gerhard Sittig]

On Fri, 2014-04-04 at 22:45 +0200, Wolfgang Denk wrote:
> 
> Dear Murali Karicheri,
> 
> In message <1396631815-5735-3-git-send-email-m-kariche...@ti.com> you wrote:
> > This patch add support for gpimage format as a preparatory
> > patch for porting u-boot for keystone2 devices and is
> > based on omapimage format. It re-uses gph header to store the
> > size and loadaddr as done in omapimage.c
> ...
> > @@ -125,6 +125,7 @@ static const table_entry_t uimage_type[] = {
> > {   IH_TYPE_FILESYSTEM, "filesystem", "Filesystem Image",   },
> > {   IH_TYPE_FIRMWARE,   "firmware",   "Firmware",   },
> > {   IH_TYPE_FLATDT, "flat_dt","Flat Device Tree",   },
> > +   {   IH_TYPE_GPIMAGE,"gpimage","TI Keystone SPL Image",},
> > {   IH_TYPE_KERNEL, "kernel", "Kernel Image",   },
> > {   IH_TYPE_KERNEL_NOLOAD, "kernel_noload",  "Kernel Image (no 
> > loading done)", },
> > {   IH_TYPE_KWBIMAGE,   "kwbimage",   "Kirkwood Boot Image",},
> 
> For binary compatibility with existing images you can only appen, but
> never insert into uimage_type[].

the next hunk (declaration of the IH_TYPE_GPIMAGE enum value) did
the append, using a number past all previously used numbers,
keeping compatibility with existing binaries

the above hunk just references the newly introduced enum, and
keeps the list of images sorted alphabetically -- so I think this
is OK


virtually yours
Gerhard Sittig
-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: off...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Socfpga preloader signing patch

[Gerhard Sittig]

On Fri, 2014-04-04 at 22:47 +0200, Pavel Machek wrote:
> 
> Hi!
> 
> > I'm trying to get custom preloader to work (on EBV Socrates)... I
> > tried applying old patch from mail archives, but a) applying patch
> > from mail archives is not fun and b) it did not seem to do the trick.
> 
> Just to make sure... right way to use the
> socfpga-signed-preloader.bin is
> 
> dd if=socfpga-signed-preloader.bin of=/dev/mmcblk0p1 bs=64k seek=0
> dd if=u-boot.img of=/dev/mmcblk0p1 bs=64K seek=4

Assuming that mmcblk0p1 is the raw partition (type A2) on your
disk, then yes these are the correct instructions.  You only
update one of the four preloader copies, but this is fine as
well.  Cannot spot a problem here.


virtually yours
Gerhard Sittig
-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: off...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] doc:power:pmic: Add doc entry for PMIC(v2) framework

[Lukasz Majewski]

Well written documentation for PMIC framework was missing and hence
it has been probably difficult and time consuming for other developers
to understand rationale for key design decisions and overall design
structure.
This commit provides proper documentation entry.

Signed-off-by: Lukasz Majewski 
---
 doc/README.power-framework |  166 
 1 file changed, 166 insertions(+)
 create mode 100644 doc/README.power-framework

diff --git a/doc/README.power-framework b/doc/README.power-framework
new file mode 100644
index 000..1f6fd43
--- /dev/null
+++ b/doc/README.power-framework
@@ -0,0 +1,166 @@
+#
+# (C) Copyright 2014 Samsung Electronics
+# Lukasz Majewski 
+#
+# SPDX-License-Identifier:  GPL-2.0+
+#
+
+Introduction
+
+
+This document describes the second version of the u-boot's PMIC (Power
+Management IC) framework. As a reference boards please consider Samsungs' Trats
+and Trats2.
+
+Background
+--
+
+Boards supported by u-boot are getting increasingly complex. Developers and
+designers strive to cut down power consumption. Hence several different types 
of
+devices are now available on the board - namely power managers (PMIC), fuel
+gauges (FG), micro USB interface controllers (MUIC), batteries, multi-function
+devices (MFD).
+
+Explanation of key design decisions
+---
+
+One package can integrate PMIC and MUIC with different addresses on the I2C 
bus.
+The same device - e.g. MAX8997 uses two different I2C busses and addresses.
+
+Power devices use not only I2C for communication, but SPI as well. Additionally
+different ICs use different endianess. For this reason struct pmic holds
+information about I2C/SPI transmission, which is used with generic
+pmic_req_write() function.
+
+The "flat" hierarchy for power devices works well when each device performs 
only
+one operation - e.g. PMIC enables LDO.
+
+The problem emerges when we have a device (battery) which conceptually shall be
+the master and uses methods exported by other devices. We need to control MUIC
+to start charging the battery, use PMIC to reduce board's overall power
+consumption (by disabling not needed LDOs, BUCKs) and get current state of
+energy on the battery from FG.
+Up till now u-boot doesn't support device model, so a simple one had to be
+added.
+
+The directory hierarchy has following structure:
+./include/power/_.h
+e.g. ./include/power/max8997_pmic.h
+
+./drivers/power/pmic/power_{core files}.c
+e.g. ./drivers/power/pmic/power_core.c
+
+./drivers/power/pmic//_.c
+e.g. ./drivers/power/pmic/pmic_max8997.c
+e.g. ./drivers/power/battery/trats/bat_trats.c
+e.g. ./drivers/power/fuel_gauge/fg_max17042.c
+
+The framework classifies devices by their function - separate directories 
should
+be maintained for different classes of devices.
+
+Current design
+--
+
+Everything is a power device described by struct pmic. Even battery is
+considered as a valid power device. This helps for better management of those
+devices.
+
+- Block diagram of the hierarchy:
+   -
+   | BAT   |
+   |   |   |   |
+   |   -   |
+   |   |   |
+  \|/ \|/ \|/
+   --- -   -
+   |FG   | |MUIC   |   |CHRG   |
+   | | |   |   |   |
+   --- -   -
+
+
+1. When hierarchy is not needed (no complex battery charge):
+
+Definition of the struct pmic is only required with proper name and parameters
+for communication. This is enough to use the "pmic" command in the u-boot
+prompt to change values of device's register (enable/disable LDO, BUCK).
+
+The PG, MUIC and CHRG above are regarded to be in the same level in the
+hierarchy.
+
+2. Complex battery charging.
+
+To charge a battery, information from several "abstract" power devices is
+needed (defined at ./include/power/pmic.h):
+- FG device (struct power_fg):
+-- *fg_battery_check - check if battery is not above its limits
+-- *fg_battery_update - update the pmic framework with current
+battery state(voltage and current capacity)
+
+- Charger device (struct power_chrq):
+-- *chrg_type - type/capacity of the charger (including information
+about USB cable disconnection)
+-- *chrg_bat_present - detection if battery to be charged is
+   present
+-- *chrg_state - status of the charger - if it is enabled or
+ disabled
+
+- Battery device (struct power_battery):
+-- *battery_init - assign proper callbacks to be used by top
+

Re: [U-Boot] [PATCH] Fix USB keyboard polling via control endpoint

[Adrian Cox]

> From: "Wolfgang Denk" 

> I agree that the code is wrong and needs fixing.  data->new is an
> uint8_t pointer, so taking the size of the pointer is obviously
> wrong.  But what you fix here is not the only place where
> sizeof(data->new) is used, so this patch fixes part of the problem at
> best.

I can't find any other instances of sizeof in usb_kbd.c. Is this a broader 
problem in the USB stack?

> Can you please try out if the following extended version f the patch
> works and fixes your problem?  You will note that I removed all
> occurrences of this magic number 8 by replacing it with
> USB_KBD_PDATA_SIZE  so the could should also be easier to read.

I've tested your extended patch, and it does fix the problem for me. I agree 
that adding USB_KBD_PDATA_SIZE
does improve readability.

Thanks and regards,
Adrian Cox

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

Re: [U-Boot] [PATCH] arm: Handle .gnu.hash section in ldscripts

[Albert ARIBAUD]

Hi Andreas,

On Mon, 27 Jan 2014 05:48:11 +0100, Andreas Färber 
wrote:

> Avoids "could not find output section .gnu.hash" ld.bfd errors on openSUSE.
> 
> Cc: Albert Aribaud 
> Cc: Tom Rini 
> Signed-off-by: Andreas Färber 
> ---
>  More changes like this may be needed, but these I compile-tested with
>  v2014.01 (regression from v2013.10). colibri_t20_iris was runtime-tested.
>  GCC 4.8.2 r206511, binutils 2.24
> 
>  arch/arm/cpu/u-boot.lds| 1 +
>  board/ti/am335x/u-boot.lds | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds
> index 4da5d24..fb8bfaf 100644
> --- a/arch/arm/cpu/u-boot.lds
> +++ b/arch/arm/cpu/u-boot.lds
> @@ -97,6 +97,7 @@ SECTIONS
>   .dynamic : { *(.dynamic*) }
>   .plt : { *(.plt*) }
>   .interp : { *(.interp*) }
> + .gnu.hash : { *(.gnu.hash) }
>   .gnu : { *(.gnu*) }
>   .ARM.exidx : { *(.ARM.exidx*) }
>   .gnu.linkonce.armexidx : { *(.gnu.linkonce.armexidx.*) }
> diff --git a/board/ti/am335x/u-boot.lds b/board/ti/am335x/u-boot.lds
> index 6a734b3..fec4ccf 100644
> --- a/board/ti/am335x/u-boot.lds
> +++ b/board/ti/am335x/u-boot.lds
> @@ -113,6 +113,7 @@ SECTIONS
>   .dynstr : { *(.dynstr*) }
>   .dynamic : { *(.dynamic*) }
>   .hash : { *(.hash*) }
> + .gnu.hash : { *(.gnu.hash) }
>   .plt : { *(.plt*) }
>   .interp : { *(.interp*) }
>   .gnu : { *(.gnu*) }

Applied to u-boot-arm/master, thanks!

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

Re: [U-Boot] Bug in buildsystem for SPL LDSCRIPT

[Andreas Bießmann]

and also to the list ... sorry for the noise

On 04/07/2014 11:27 AM, Andreas Bießmann wrote:
> Hi Masahiro,
> 
> a late bug report ;) changing my board config file will not regenerate
> the spl/u-boot-spl.lds for the board though it depends on it. The
> LDSCRIPT is patched with some size information for range checking which
> is not updated in my case. However regenerating the file by deleting it
> first works. Cold you please provide a fix for that in 2014.04?
> 
> Best regards
> 
> Andreas Bießmann
> 

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

Re: [U-Boot] [PATCH 5/5] MIPS: Malta: convert to generic board

[Paul Burton]

On Sun, Apr 06, 2014 at 08:58:16PM +0200, Daniel Schwierzeck wrote:
> 2014-04-04 13:20 GMT+02:00 Paul Burton :
> > This patch converts the MIPS Malta development board to make use of the
> > generic board code now that it is supported on MIPS.
> >
> > Signed-off-by: Paul Burton 
> > ---
> >  board/imgtec/malta/malta.c | 9 -
> >  include/configs/malta.h| 3 +++
> >  2 files changed, 7 insertions(+), 5 deletions(-)
> >
> > diff --git a/board/imgtec/malta/malta.c b/board/imgtec/malta/malta.c
> > index d363e49..0f16b74 100644
> > --- a/board/imgtec/malta/malta.c
> > +++ b/board/imgtec/malta/malta.c
> > @@ -19,6 +19,8 @@
> >
> >  #include "superio.h"
> >
> > +DECLARE_GLOBAL_DATA_PTR;
> > +
> >  enum core_card {
> > CORE_UNKNOWN,
> > CORE_LV,
> > @@ -82,11 +84,6 @@ static enum sys_con malta_sys_con(void)
> > }
> >  }
> >
> > -phys_size_t initdram(int board_type)
> > -{
> > -   return CONFIG_SYS_MEM_SIZE;
> > -}
> > -
> >  int checkboard(void)
> >  {
> > enum core_card core;
> > @@ -129,6 +126,8 @@ int board_early_init_f(void)
> >  {
> > void *io_base;
> >
> > +   gd->ram_size = CONFIG_SYS_MEM_SIZE;
> > +
> > /* choose correct PCI I/O base */
> > switch (malta_sys_con()) {
> > case SYSCON_GT64120:
> 
> I would prefer to enable the according init funtions in board_f,c for
> MIPS, so that all MIPS boards can be converted without changing such
> code.

Sure, v2 coming shortly.

> 
> --- a/common/board_f.c
> +++ b/common/board_f.c
> @@ -173,7 +173,7 @@ static int announce_dram_init(void)
> return 0;
>  }
> 
> -#ifdef CONFIG_PPC
> +#if defined(CONFIG_PPC) || defined(CONFIG_MIPS)
>  static int init_func_ram(void)
>  {
>  #ifdef CONFIG_BOARD_TYPES
> @@ -889,7 +889,7 @@ static init_fnc_t init_sequence_f[] = {
>  #ifdef CONFIG_ARM
> dram_init,  /* configure available RAM banks */
>  #endif
> -#ifdef CONFIG_PPC
> +#if defined(CONFIG_PPC) || defined(CONFIG_MIPS)
> init_func_ram,
>  #endif
>  #ifdef CONFIG_POST
> 
> BTW: there are other canditates too, which are implemented in the same
> way as PowerPC or ARM and which should be also enabled for MIPS, e.g.
> init_timer
> 
> -- 
> - Daniel

Thanks for pointing that out! I can't spot anything besides init_timer,
except for the board-specific incapi_set_cpuclk call which I guess will
probably just need to be added to common/board_f.c if & when that board
is converted.

Paul


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 v2 6/7] MIPS: allow use of generic board

[Paul Burton]

This patch allows MIPS boards to make use of generic board, replacing
arch/mips/lib/board.c with common/board_{f,r}.c and struct bd_info with
the asm-generic version.

Signed-off-by: Paul Burton 
---
Changes since v1:
  - None
---
 arch/mips/config.mk| 2 ++
 arch/mips/include/asm/u-boot.h | 9 +
 arch/mips/lib/Makefile | 2 ++
 doc/README.generic-board   | 1 +
 4 files changed, 14 insertions(+)

diff --git a/arch/mips/config.mk b/arch/mips/config.mk
index 1899f51..ac95a63 100644
--- a/arch/mips/config.mk
+++ b/arch/mips/config.mk
@@ -27,6 +27,8 @@ ENDIANNESS ?= -EB
 
 PLATFORM_CPPFLAGS += -DCONFIG_MIPS -D__MIPS__
 
+__HAVE_ARCH_GENERIC_BOARD := y
+
 #
 # From Linux arch/mips/Makefile
 #
diff --git a/arch/mips/include/asm/u-boot.h b/arch/mips/include/asm/u-boot.h
index 985d7d8..0eb170d 100644
--- a/arch/mips/include/asm/u-boot.h
+++ b/arch/mips/include/asm/u-boot.h
@@ -15,6 +15,13 @@
 #ifndef _U_BOOT_H_
 #define _U_BOOT_H_ 1
 
+#ifdef CONFIG_SYS_GENERIC_BOARD
+
+/* Use the generic board which requires a unified bd_info */
+#include 
+
+#else /* !CONFIG_SYS_GENERIC_BOARD */
+
 typedef struct bd_info {
unsigned intbi_baudrate;/* serial console baudrate */
unsigned long   bi_arch_number; /* unique id for this board */
@@ -26,6 +33,8 @@ typedef struct bd_info {
unsigned long   bi_flashoffset; /* reserved area for startup monitor */
 } bd_t;
 
+#endif /* !CONFIG_SYS_GENERIC_BOARD */
+
 /* For image.h:image_check_target_arch() */
 #define IH_ARCH_DEFAULT IH_ARCH_MIPS
 
diff --git a/arch/mips/lib/Makefile b/arch/mips/lib/Makefile
index 88ef1c5..e483e86 100644
--- a/arch/mips/lib/Makefile
+++ b/arch/mips/lib/Makefile
@@ -5,7 +5,9 @@
 # SPDX-License-Identifier: GPL-2.0+
 #
 
+ifndef CONFIG_SYS_GENERIC_BOARD
 obj-y  += board.o
+endif
 obj-y  += io.o
 
 obj-$(CONFIG_CMD_BOOTM) += bootm.o
diff --git a/doc/README.generic-board b/doc/README.generic-board
index 50d3a26..fdec30e 100644
--- a/doc/README.generic-board
+++ b/doc/README.generic-board
@@ -44,6 +44,7 @@ The following architectures are supported at the time of 
writing:
 
arc
arm
+   mips
powerpc
sandbox
x86
-- 
1.8.5.3

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

[U-Boot] [PATCH v2 7/7] MIPS: Malta: convert to generic board

[Paul Burton]

This patch converts the MIPS Malta development board to make use of the
generic board code now that it is supported on MIPS.

Signed-off-by: Paul Burton 
---
Changes since v1:
  - Drop the now unnecessary initdram/ram_size changes.
---
 include/configs/malta.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/configs/malta.h b/include/configs/malta.h
index cc574ed..a29b86b 100644
--- a/include/configs/malta.h
+++ b/include/configs/malta.h
@@ -14,6 +14,9 @@
  * System configuration
  */
 #define CONFIG_MALTA
+#define CONFIG_SYS_GENERIC_BOARD
+#define CONFIG_BOARD_EARLY_INIT_F
+#define CONFIG_DISPLAY_BOARDINFO
 
 #define CONFIG_MEMSIZE_IN_BYTES
 
-- 
1.8.5.3

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

[U-Boot] [PATCH v2 5/7] board_f: call timer_init on MIPS

[Paul Burton]

MIPS needs a call to timer_init to preserve its current behaviour
ensuring that the cop0 compare register is initialised appropriately.

Reported-by: Daniel Schwierzeck 
Signed-off-by: Paul Burton 
---
Changes since v1:
  - New patch
---
 common/board_f.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/board_f.c b/common/board_f.c
index 2ece9e2..cbdf06f 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -819,7 +819,7 @@ static init_fnc_t init_sequence_f[] = {
/* TODO: can we rename this to timer_init()? */
init_timebase,
 #endif
-#ifdef CONFIG_ARM
+#if defined(CONFIG_ARM) || defined(CONFIG_MIPS)
timer_init, /* initialize timer */
 #endif
 #ifdef CONFIG_SYS_ALLOC_DPRAM
-- 
1.8.5.3

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

[U-Boot] [PATCH v2 2/7] MIPS: move mips_io_port_base out of board.c

[Paul Burton]

Move the definition of this variable out of arch/mips/lib/board.c in
preparation for allowing use of generic board on MIPS, which will lead
to this file not being compiled.

Signed-off-by: Paul Burton 
---
Changes since v1:
  - None
---
 arch/mips/lib/Makefile |  2 ++
 arch/mips/lib/board.c  |  6 --
 arch/mips/lib/io.c | 12 
 3 files changed, 14 insertions(+), 6 deletions(-)
 create mode 100644 arch/mips/lib/io.c

diff --git a/arch/mips/lib/Makefile b/arch/mips/lib/Makefile
index fabeb83..88ef1c5 100644
--- a/arch/mips/lib/Makefile
+++ b/arch/mips/lib/Makefile
@@ -6,6 +6,8 @@
 #
 
 obj-y  += board.o
+obj-y  += io.o
+
 obj-$(CONFIG_CMD_BOOTM) += bootm.o
 
 lib-$(CONFIG_USE_PRIVATE_LIBGCC) += ashldi3.o ashrdi3.o lshrdi3.o
diff --git a/arch/mips/lib/board.c b/arch/mips/lib/board.c
index 9e6ba15..317c825 100644
--- a/arch/mips/lib/board.c
+++ b/arch/mips/lib/board.c
@@ -27,12 +27,6 @@ ulong monitor_flash_len;
 
 static char *failed = "*** failed ***\n";
 
-/*
- * mips_io_port_base is the begin of the address space to which x86 style
- * I/O ports are mapped.
- */
-const unsigned long mips_io_port_base = -1;
-
 int __board_early_init_f(void)
 {
/*
diff --git a/arch/mips/lib/io.c b/arch/mips/lib/io.c
new file mode 100644
index 000..b2d4a09
--- /dev/null
+++ b/arch/mips/lib/io.c
@@ -0,0 +1,12 @@
+/*
+ * (C) Copyright 2003
+ * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/*
+ * mips_io_port_base is the begin of the address space to which x86 style
+ * I/O ports are mapped.
+ */
+const unsigned long mips_io_port_base = -1;
-- 
1.8.5.3

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

[U-Boot] [PATCH v2 1/7] MIPS: stub interrupt_init function

[Paul Burton]

interrupt_init is called unconditionally by the generic board code.
Define a stub for it on MIPS like the enable & disable functions.

Signed-off-by: Paul Burton 
---
Changes since v1:
  - None
---
 arch/mips/cpu/mips32/interrupts.c | 5 +
 arch/mips/cpu/mips64/interrupts.c | 5 +
 2 files changed, 10 insertions(+)

diff --git a/arch/mips/cpu/mips32/interrupts.c 
b/arch/mips/cpu/mips32/interrupts.c
index a7e2ed0..275fcf5 100644
--- a/arch/mips/cpu/mips32/interrupts.c
+++ b/arch/mips/cpu/mips32/interrupts.c
@@ -7,6 +7,11 @@
 
 #include 
 
+int interrupt_init(void)
+{
+   return 0;
+}
+
 void enable_interrupts(void)
 {
 }
diff --git a/arch/mips/cpu/mips64/interrupts.c 
b/arch/mips/cpu/mips64/interrupts.c
index a7e2ed0..275fcf5 100644
--- a/arch/mips/cpu/mips64/interrupts.c
+++ b/arch/mips/cpu/mips64/interrupts.c
@@ -7,6 +7,11 @@
 
 #include 
 
+int interrupt_init(void)
+{
+   return 0;
+}
+
 void enable_interrupts(void)
 {
 }
-- 
1.8.5.3

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

[U-Boot] [PATCH v2 4/7] board_f: call init_func_ram on MIPS

[Paul Burton]

Assigning gd->ram_size the return value of initdram matches the existing
MIPS board behaviour.

Suggested-by: Daniel Schwierzeck 
Signed-off-by: Paul Burton 
---
Changes since v1:
  - New patch
---
 common/board_f.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/common/board_f.c b/common/board_f.c
index f285bad..2ece9e2 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -173,7 +173,7 @@ static int announce_dram_init(void)
return 0;
 }
 
-#ifdef CONFIG_PPC
+#if defined(CONFIG_MIPS) || defined(CONFIG_PPC)
 static int init_func_ram(void)
 {
 #ifdef CONFIG_BOARD_TYPES
@@ -889,7 +889,7 @@ static init_fnc_t init_sequence_f[] = {
 #ifdef CONFIG_ARM
dram_init,  /* configure available RAM banks */
 #endif
-#ifdef CONFIG_PPC
+#if defined(CONFIG_MIPS) || defined(CONFIG_PPC)
init_func_ram,
 #endif
 #ifdef CONFIG_POST
-- 
1.8.5.3

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