Re: [U-Boot] [PATCH] Add SPI Flash STMicro's N25Q512A & add flag status check during SPI Flash write

[Insop Song]

Hi Jagan,

Thank you for your feedback,

> -Original Message-
> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
> Sent: Wednesday, June 05, 2013 11:34 PM
> To: Insop Song
> Cc: u-boot@lists.denx.de; york...@freescale.com
> Subject: Re: [U-Boot] [PATCH] Add SPI Flash STMicro's N25Q512A & add flag
> status check during SPI Flash write
> 
> Thank you very much for your interest on this.
> 
> >> > What do you think?
> >> >
> >> > Thank you,
> >>
> >> Can u just send pseudo code about your logic, i couldn't get u exactly
> sorry.
> >>
> >
> > Here is what I think, it is similar with your patch in the sense that "do 
> > the
> different status" check for different device.
> > However, the difference is that your patch checks based on device type at
> the status checking function.
> > Mine is proposing to add the information to the devices' struct
> > (spi_flash) instead, so each device can have a flexibility to call
> > flag status check. In this way if new device use this flag_status
> > check, you can just hide the setting in devices' probe function, and
> > not worrying about updating generic function call
> > (spi_flash_cmd_poll_bit() as in your patch)
> 
> Your idea seems to be clean and reasonable, but
> 
> >
> > I am not so happy to add "flag_status" in struct spi_flash; so I am open to
> your idea.
> > Please see below and let me know what you think?
> >
> >
> >
> >
> > // 1. adding flag status
> > struct spi_flash {
> > struct spi_slave *spi;
> >
> > const char  *name;
> >
> > /* Total flash size */
> > u32 size;
> > /* Write (page) size */
> > u32 page_size;
> > /* Erase (sector) size */
> > u32 sector_size;
> >
> > /* if flag_status is use or not */
> > u8  flag_status;
> >
> > int (*read)(struct spi_flash *flash, u32 offset,
> > size_t len, void *buf);
> > int (*write)(struct spi_flash *flash, u32 offset,
> > size_t len, const void *buf);
> > int (*erase)(struct spi_flash *flash, u32 offset,
> > size_t len); };
> >
> > // 2. in probe function, set the flag_status per vendor
> >
> >
> > struct spi_flash *spi_flash_probe_stmicro(struct spi_slave *spi, u8 *
> > idcode) {
> >
> > flash->spi = spi;
> > flash->name = params->name;
> >
> > flash->write = spi_flash_cmd_write_multi;
> > flash->erase = spi_flash_cmd_erase;
> > flash->read = spi_flash_cmd_read_fast;
> > flash->page_size = 256;
> > flash->sector_size = 256 * params->pages_per_sector;
> > flash->size = flash->sector_size * params->nr_sectors;
> >
> > // we do this for Micron, and will do the same if any other device 
> > needs
> this
> > flash->flag_status = 1;
> >
> > return flash;
> > }
> >
> >
> > // 3. call flag status check if flash->flag_status is set
> >
> >
> > int spi_flash_cmd_wait_ready(struct spi_flash *flash, unsigned long
> > timeout) {
> > if (flash->flag_status)
> > return spi_flash_cmd_poll_bit(flash, timeout,
> > CMD_READ_FLAG_STATUS, STATUS_PEC, STATUS_PEC);
> > else
> > return spi_flash_cmd_poll_bit(flash, timeout,
> > CMD_READ_STATUS, STATUS_WIP, 0); }
> 
> APAIK. flag status required only for stmicro flashes which has >= 512MB
> flashes.
> And as this is specific to a particular flash with particular size, i don't 
> see any
> reason to add extra variable in spi_flash and then initialized at probe.

Agree with you, that's why I also was not so happy to put flag_status to a 
generic struct.

> Your idea seems to be reasonable if we have more numbers of flash vendors
> require this with respective sizes.
> 
> ie, the reason I have gave a condition for the particular state like
> + if ((flash->idcode0 == 0x20) &&
> + (flash->size >= SPI_FLASH_512MB_STMIC))
> 
> And  I have removed spi_flash_cmd_poll_bit as these is no separate caller for
> this except the spi_flash_cmd_wait_ready() and did everything on
> spi_flash_cmd_wait_ready().
> 

Sounds good. I think your updated patch is coming on line now, so I will take a 
look at your v2 patch and I will comment on that thread directly.

I think we could close this discussion here.

Thank you.

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

Re: [U-Boot] [PATCH v2 00/16] sf: Update sf framework to support all sizes of flashes

[Jagan Teki]

Request for comments.

--
Thanks,
Jagan.

On Fri, May 31, 2013 at 6:22 PM, Jagannadha Sutradharudu Teki
 wrote:
> This series is v2 for the patch series sent few weeks back with a head
> "sf: Accessing > 16MBytes flashes in existing 3-byte addr mode."
>
> The current implementation in sf supports 3-byte address mode due
> to this up to 16MB amount of flash is able to access for those
> flashes which has an actual size of > 16MB.
>
> This series of patches is more detailed/meatured changes w.r.t the current
> sf framework in addition to changes related to support all sizes using
> bank/exnt register addr accessing support.
>
> With these new updates on sf framework, the flashes which has < 16MB
> are not effected as per as performance is concern and but the
> u-boot.bin size incrased ~600 bytes.
>
> sf update(for first 16MBytes), Changes before:
> U-Boot> sf update 0x100 0x0 0x100
> - N25Q256
>   16777216 bytes written, 0 bytes skipped in 199.72s, speed 86480 B/s
> - W25Q128BV
>   16777216 bytes written, 0 bytes skipped in 351.739s, speed 48913 B/s
> - S25FL256S_64K
>   16777216 bytes written, 0 bytes skipped in 65.659s, speed 262144 B/s
>
> sf update(for first 16MBytes), Changes after:
> U-Boot> sf update 0x100 0x0 0x100
> - N25Q256
>   16777216 bytes written, 0 bytes skipped in 198.953s, speed 86480 B/s
> - W25Q128BV
>   16777216 bytes written, 0 bytes skipped in 350.90s, speed 49200 B/s
> - S25FL256S_64K
>   16777216 bytes written, 0 bytes skipped in 66.521s, speed 262144 B/s
>
> The main aim of these changes is to not effect the current framework
> and at the same time to support the > 16Mbyte flashes, becuase of this
> I involved few flash vendor people in CC [thought that they may/mayn't
> be a mailing list members] to know their views.
>
> REQUEST FOR ALL SPI CODE CONTRIBUTORS/USERS, PLEASE TEST
> THESE CHANGES W.R.T YOUR HW IF POSSIBLE.
>
> Please let me know for any issues/concerns/questions.
>
> Thanks,
> Jagan.
>
> Jagannadha Sutradharudu Teki (16):
>   sf: Add bank address register writing support
>   sf: Add bank address register reading support
>   sf: Add extended addr write support for winbond|stmicro
>   sf: Add extended addr read support for winbond|stmicro
>   sf: read flash bank addr register at probe time
>   sf: Update sf to support all sizes of flashes
>   sf: Update sf read to support all sizes of flashes
>   sf: Use spi_flash_addr() in write call
>   sf: stmicro: Add support for N25Q512
>   sf: stmicro: Add support for N25Q512A
>   sf: stmicro: Add support for N25Q1024
>   sf: stmicro: Add support for N25Q1024A
>   sf: spansion: Add support for S25FL512S_256K
>   sf: Use spi_flash_read_common() in write status poll
>   sf: Remove spi_flash_cmd_poll_bit()
>   sf: Add Flag status register polling support
>
>  drivers/mtd/spi/spansion.c   |   7 ++
>  drivers/mtd/spi/spi_flash.c  | 192 
> +++
>  drivers/mtd/spi/spi_flash_internal.h |  21 +++-
>  drivers/mtd/spi/stmicro.c|  24 +
>  include/spi_flash.h  |   4 +
>  5 files changed, 203 insertions(+), 45 deletions(-)
>
> --
> 1.8.3
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Add SPI Flash STMicro's N25Q512A & add flag status check during SPI Flash write

[Jagan Teki]

Thank you very much for your interest on this.

>> > What do you think?
>> >
>> > Thank you,
>>
>> Can u just send pseudo code about your logic, i couldn't get u exactly sorry.
>>
>
> Here is what I think, it is similar with your patch in the sense that "do the 
> different status" check for different device.
> However, the difference is that your patch checks based on device type at the 
> status checking function.
> Mine is proposing to add the information to the devices' struct (spi_flash) 
> instead, so each device can have a flexibility to call flag status check. In 
> this way if new device use this flag_status check, you can just hide the 
> setting in devices' probe function, and not worrying about updating generic 
> function call (spi_flash_cmd_poll_bit() as in your patch)

Your idea seems to be clean and reasonable, but

>
> I am not so happy to add "flag_status" in struct spi_flash; so I am open to 
> your idea.
> Please see below and let me know what you think?
>
>
>
>
> // 1. adding flag status
> struct spi_flash {
> struct spi_slave *spi;
>
> const char  *name;
>
> /* Total flash size */
> u32 size;
> /* Write (page) size */
> u32 page_size;
> /* Erase (sector) size */
> u32 sector_size;
>
> /* if flag_status is use or not */
> u8  flag_status;
>
> int (*read)(struct spi_flash *flash, u32 offset,
> size_t len, void *buf);
> int (*write)(struct spi_flash *flash, u32 offset,
> size_t len, const void *buf);
> int (*erase)(struct spi_flash *flash, u32 offset,
> size_t len);
> };
>
> // 2. in probe function, set the flag_status per vendor
>
>
> struct spi_flash *spi_flash_probe_stmicro(struct spi_slave *spi, u8 * idcode)
> {
>
> flash->spi = spi;
> flash->name = params->name;
>
> flash->write = spi_flash_cmd_write_multi;
> flash->erase = spi_flash_cmd_erase;
> flash->read = spi_flash_cmd_read_fast;
> flash->page_size = 256;
> flash->sector_size = 256 * params->pages_per_sector;
> flash->size = flash->sector_size * params->nr_sectors;
>
> // we do this for Micron, and will do the same if any other device 
> needs this
> flash->flag_status = 1;
>
> return flash;
> }
>
>
> // 3. call flag status check if flash->flag_status is set
>
>
> int spi_flash_cmd_wait_ready(struct spi_flash *flash, unsigned long timeout)
> {
> if (flash->flag_status)
> return spi_flash_cmd_poll_bit(flash, timeout,
> CMD_READ_FLAG_STATUS, STATUS_PEC, STATUS_PEC);
> else
> return spi_flash_cmd_poll_bit(flash, timeout,
> CMD_READ_STATUS, STATUS_WIP, 0);
> }

APAIK. flag status required only for stmicro flashes which has >= 512MB flashes.
And as this is specific to a particular flash with particular size, i
don't see any reason to add extra variable in spi_flash
and then initialized at probe.
Your idea seems to be reasonable if we have more numbers of flash
vendors require this with respective sizes.

ie, the reason I have gave a condition for the particular state like
+   if ((flash->idcode0 == 0x20) &&
+   (flash->size >= SPI_FLASH_512MB_STMIC))

And  I have removed spi_flash_cmd_poll_bit as these is no separate
caller for this except the spi_flash_cmd_wait_ready()
and did everything on spi_flash_cmd_wait_ready().

Comments.

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

Re: [U-Boot] [PATCH] Add SPI Flash STMicro's N25Q512A & add flag status check during SPI Flash write

[Insop Song]

> -Original Message-
> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
> Sent: Wednesday, June 05, 2013 2:00 AM
> To: Insop Song
> Cc: u-boot@lists.denx.de; york...@freescale.com
> Subject: Re: [U-Boot] [PATCH] Add SPI Flash STMicro's N25Q512A & add flag
> status check during SPI Flash write
> > And how about this?  can we add "flag_status_check" flag somewhere, and
> if the device is needed then we set the flag during device discovery.
> > Then call the flag check function if the flag is set.
> > I think this way might be more generic then what you did in your patch.
> >
> > What do you think?
> >
> > Thank you,
> 
> Can u just send pseudo code about your logic, i couldn't get u exactly sorry.
> 

Here is what I think, it is similar with your patch in the sense that "do the 
different status" check for different device.
However, the difference is that your patch checks based on device type at the 
status checking function.
Mine is proposing to add the information to the devices' struct (spi_flash) 
instead, so each device can have a flexibility to call flag status check. In 
this way if new device use this flag_status check, you can just hide the 
setting in devices' probe function, and not worrying about updating generic 
function call (spi_flash_cmd_poll_bit() as in your patch)

I am not so happy to add "flag_status" in struct spi_flash; so I am open to 
your idea.
Please see below and let me know what you think?




// 1. adding flag status
struct spi_flash {
struct spi_slave *spi;

const char  *name;

/* Total flash size */
u32 size;
/* Write (page) size */
u32 page_size;
/* Erase (sector) size */
u32 sector_size;

/* if flag_status is use or not */
u8  flag_status;

int (*read)(struct spi_flash *flash, u32 offset,
size_t len, void *buf);
int (*write)(struct spi_flash *flash, u32 offset,
size_t len, const void *buf);
int (*erase)(struct spi_flash *flash, u32 offset,
size_t len);
};

// 2. in probe function, set the flag_status per vendor


struct spi_flash *spi_flash_probe_stmicro(struct spi_slave *spi, u8 * idcode)
{

flash->spi = spi;
flash->name = params->name;

flash->write = spi_flash_cmd_write_multi;
flash->erase = spi_flash_cmd_erase;
flash->read = spi_flash_cmd_read_fast;
flash->page_size = 256;
flash->sector_size = 256 * params->pages_per_sector;
flash->size = flash->sector_size * params->nr_sectors;

// we do this for Micron, and will do the same if any other device 
needs this
flash->flag_status = 1;

return flash;
}


// 3. call flag status check if flash->flag_status is set


int spi_flash_cmd_wait_ready(struct spi_flash *flash, unsigned long timeout)
{
if (flash->flag_status)
return spi_flash_cmd_poll_bit(flash, timeout,
CMD_READ_FLAG_STATUS, STATUS_PEC, STATUS_PEC);
else
return spi_flash_cmd_poll_bit(flash, timeout,
CMD_READ_STATUS, STATUS_WIP, 0);
}


Thank you,

IS



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

Re: [U-Boot] [PATCH v2 5/8] sf: winbond: Update the names for W25Q 0x40XX ID's flash parts

[Michal Simek]

move this discussion back to mailing list.

On 06/05/2013 05:56 PM, Jagan Teki wrote:
 And are your ok with below representation for common id's parts ?
 +   .name   = "W25Q80BL/W25Q80BV",
 +   .name   = "W25Q16CL/W25Q16DV",
 +   .name   = "W25Q32BV/W25Q32FV_SPI",
 +   .name   = "W25Q64CV/W25Q64FV_SPI",
 +   .name   = "W25Q128BV/W25Q128FV_SPI",
 +   .name   = "W25Q32DW/W25Q32FV_QPI",
 +   .name   = "W25Q64DW/W25Q64FV_QPI",
 +   .name   = "W25Q128FW/W25Q128FV_QPI",
>>>
>>> Any comments on above representation of part names, as the id's to
>>> these pairs are common.
>>> This will enhance u-boot sf to support all parts from winbond, but
>>> seems like different view of names.
>>>
>>
>> what's the difference between that parts?
> 
> parts were diff in terms of voltages and sone SPI and QPI configurations.
> but from the manufacture defeat, pair of parts were same ID's

ok.

>> Does software care if it is W25G80BL or BV?
>> Or software behaviour is the same and there is only difference in voltage
>> or so.
> 
> SW is same even if it 1.8 or 3.3 v.
> The only reason for giving the pair of names to support all different parts

You are supporting them but you are just not list them.

>> I don't care about it so much but it is increase u-boot size.
> Why does u-boot size increase, is it because of  below representation
> on name filed
>   = "W25Q80BL/W25Q80BV"

Just because of longer names which go probably to rodata section.

It is not a problem for me at all.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform




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

Re: [U-Boot] [PATCH V2] exynos: spl: Add a custom spi copy function

[Rajeshwari Birje]

Hi Jagan,

Simon had sent a V2 by rebasing the patch on MMC series submitted by
Amar, but there are no comments on those MMC patches and are not yet
merged. I incorporated the review comments given by Wolfgang Denk on
top of V1 and sent a V2 patch.

Regards,
Rajeshwari Shinde.

On Mon, Jun 3, 2013 at 12:36 AM, Jagan Teki  wrote:
> Hi,
>
> I think this needs to send as v3, as Simon sent v2 for this.
> http://patchwork.ozlabs.org/patch/243139/
>
> --
> Thanks,
> Jagan.
>
> On Thu, May 30, 2013 at 12:01 PM, Rajeshwari Shinde
>  wrote:
>> This patch implements a custom spi_copy funtion to copy u-boot from SF
>> to RAM. This is faster then iROM spi_copy funtion as this runs spi at
>> 50Mhz and also in WORD mode of operation.
>>
>> Changed a printf in pinmux.c to debug just to avoid the compilation
>> error in SPL.
>> Removed enum for boot mode from spl_boot.c as it was already define
>> in spl.h
>>
>> Based on "[PATCH V2] spi: exynos: Support word transfers"
>>
>> Signed-off-by: Alim Akhtar 
>> Signed-off-by: Tom Wai-Hong Tam 
>> Signed-off-by: Rajeshwari Shinde 
>> ---
>> Changes in V2:
>> - Corrected the commit message.
>> - Added a SPI timeout check.
>> - Corrected the comments.
>>  arch/arm/cpu/armv7/exynos/pinmux.c |2 +-
>>  arch/arm/include/asm/arch-exynos/spi.h |2 +
>>  board/samsung/smdk5250/spl_boot.c  |  136 
>> ---
>>  include/configs/exynos5250-dt.h|3 +
>>  spl/Makefile   |4 +
>>  5 files changed, 132 insertions(+), 15 deletions(-)
>>
>> diff --git a/arch/arm/cpu/armv7/exynos/pinmux.c 
>> b/arch/arm/cpu/armv7/exynos/pinmux.c
>> index bd499b4..c484a86 100644
>> --- a/arch/arm/cpu/armv7/exynos/pinmux.c
>> +++ b/arch/arm/cpu/armv7/exynos/pinmux.c
>> @@ -427,7 +427,7 @@ static int exynos4_pinmux_config(int peripheral, int 
>> flags)
>> case PERIPH_ID_SDMMC1:
>> case PERIPH_ID_SDMMC3:
>> case PERIPH_ID_SDMMC4:
>> -   printf("SDMMC device %d not implemented\n", peripheral);
>> +   debug("SDMMC device %d not implemented\n", peripheral);
>> return -1;
>> default:
>> debug("%s: invalid peripheral %d", __func__, peripheral);
>> diff --git a/arch/arm/include/asm/arch-exynos/spi.h 
>> b/arch/arm/include/asm/arch-exynos/spi.h
>> index e67ad27..3430ac1 100644
>> --- a/arch/arm/include/asm/arch-exynos/spi.h
>> +++ b/arch/arm/include/asm/arch-exynos/spi.h
>> @@ -43,6 +43,8 @@ struct exynos_spi {
>>
>>  #define SPI_TIMEOUT_MS 10
>>
>> +#define SF_READ_DATA_CMD   0x3
>> +
>>  /* SPI_CHCFG */
>>  #define SPI_CH_HS_EN   (1 << 6)
>>  #define SPI_CH_RST (1 << 5)
>> diff --git a/board/samsung/smdk5250/spl_boot.c 
>> b/board/samsung/smdk5250/spl_boot.c
>> index c0bcf46..85a5d68 100644
>> --- a/board/samsung/smdk5250/spl_boot.c
>> +++ b/board/samsung/smdk5250/spl_boot.c
>> @@ -22,17 +22,13 @@
>>
>>  #include
>>  #include
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>>
>> -enum boot_mode {
>> -   BOOT_MODE_MMC = 4,
>> -   BOOT_MODE_SERIAL = 20,
>> -   /* Boot based on Operating Mode pin settings */
>> -   BOOT_MODE_OM = 32,
>> -   BOOT_MODE_USB,  /* Boot using USB download */
>> -};
>> -
>> -   typedef u32 (*spi_copy_func_t)(u32 offset, u32 nblock, u32 dst);
>> -   typedef u32 (*usb_copy_func_t)(void);
>> +typedef u32 (*usb_copy_func_t)(void);
>>
>>  /*
>>   * Set/clear program flow prediction and return the previous state.
>> @@ -48,6 +44,119 @@ static int config_branch_prediction(int set_cr_z)
>> return cr & CR_Z;
>>  }
>>
>> +static void spi_rx_tx(struct exynos_spi *regs, int todo,
>> +   void *dinp, void const *doutp, int i)
>> +{
>> +   uint *rxp = (uint *)(dinp + (i * (32 * 1024)));
>> +   int rx_lvl, tx_lvl;
>> +   uint out_bytes, in_bytes;
>> +
>> +   out_bytes = todo;
>> +   in_bytes = todo;
>> +   setbits_le32(®s->ch_cfg, SPI_CH_RST);
>> +   clrbits_le32(®s->ch_cfg, SPI_CH_RST);
>> +   writel(((todo * 8) / 32) | SPI_PACKET_CNT_EN, ®s->pkt_cnt);
>> +
>> +   while (in_bytes) {
>> +   uint32_t spi_sts;
>> +   int temp;
>> +
>> +   spi_sts = readl(®s->spi_sts);
>> +   rx_lvl = ((spi_sts >> 15) & 0x7f);
>> +   tx_lvl = ((spi_sts >> 6) & 0x7f);
>> +   while (tx_lvl < 32 && out_bytes) {
>> +   temp = 0x;
>> +   writel(temp, ®s->tx_data);
>> +   out_bytes -= 4;
>> +   tx_lvl += 4;
>> +   }
>> +   while (rx_lvl >= 4 && in_bytes) {
>> +   temp = readl(®s->rx_data);
>> +   if (rxp)
>> +   *rxp++ = temp;
>> +   in_bytes -= 4;
>> +   rx_lvl -= 4;
>> +   }
>> +   }
>> +}
>> +
>> +/*
>> +*

[U-Boot] [PATCH] powerpc/mpc85xx:Disable Debug TLB entry before init_tlbs

[Prabhakar Kushwaha]

init_tlbs() initialize all the TLB entries required for the system.

So disable DEBUG TLB entry before TLB entries initialization.

Signed-off-by: Prabhakar Kushwaha 
---
 arch/powerpc/cpu/mpc85xx/cpu_init_early.c |4 
 1 file changed, 4 insertions(+)

diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init_early.c 
b/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
index f4403c2..3ab7748 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
@@ -180,5 +180,9 @@ void cpu_init_early_f(void)
 
invalidate_tlb(1);
 
+#if defined(CONFIG_SYS_PPC_E500_DEBUG_TLB) && !defined(CONFIG_SPL_BUILD)
+   disable_tlb(CONFIG_SYS_PPC_E500_DEBUG_TLB);
+#endif
+
init_tlbs();
 }
-- 
1.7.9.5



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

Re: [U-Boot] imx: Vybrid VF610 mac address issue

[Wang Huan-B18965]

Hi, Benoit,

> -Original Message-
> From: Benoît Thébaudeau [mailto:benoit.thebaud...@advansee.com]
> Sent: Thursday, June 06, 2013 5:46 AM
> To: Fabio Estevam
> Cc: Andy Voltz; u-boot@lists.denx.de; Stefano Babic; Wang Huan-B18965
> Subject: Re: [U-Boot] imx: Vybrid VF610 mac address issue
> 
> On Wednesday, June 5, 2013 11:16:17 PM, Benoît Thébaudeau wrote:
> > Hi Andy, Fabio,
> >
> > On Wednesday, June 5, 2013 11:13:52 PM, Fabio Estevam wrote:
> > > Hi Andy,
> > >
> > > On Wed, Jun 5, 2013 at 5:54 PM, Andy Voltz 
> wrote:
> > > > I recently tried booting the VF610 support on the Tower board,
> but
> > > > the mac address is reversed in Linux userspace. DHCP/BOOTP seems
> > > > to work properly in u-boot.
> > > >
> > > > I'm booting this kernel:
> > > > https://github.com/Timesys/linux-timesys/
> > > > ref: 2c4ead2dd6da019f5052a69b12c8f5b6b71f8dca
> > > >
> > > > I haven't yet seen how the address is passed to the kernel, but
> > > > our previous u-boot support does not have this issue with the
> same
> > > > kernel. That u-boot branch is also on our github.
> > >
> > > The MAC address is read in the imx_get_mac_from_fuse() function in
> > > arch/arm/cpu/armv7/vf610/generic.c
> > >
> > > Try printing all the elements of mac[] array in this function and
> > > check if the logic is correct there.
> >
> > You probably had programmed the fuses with a MAC address on your
> > board, and then replaced the existing U-Boot with the mainline
> > version. These 2 U-Boot-s may interpret the MAC fuses in a different
> > way. Especially, note that VF610 interprets the MAC fuses with
> > reversed endianness compared to i.MX6 in mainline U-Boot. This is
> > documented in doc/README.. There may be the same difference
> > between VF610 in mainline U-Boot and the other version of U-Boot that
> > you used first.
> 
> But if there is such a difference between U-Boot editions, it might be
> worth considering to make mainline U-Boot more consistent with
> Freescale's or others'
> before it is too much widespread. It is especially important if people
> change the U-Boot edition on their board.
> 
> Stefano, Alison, what do you think?
> 
> Alison, have you checked if your implementation in mainline is
> consistent with Freescale's? There may be a difference both for which
> fuse word is used for high/low parts of the MAC address (i.e. word-
> level endianness that I was talking about above), and for the byte-
> level endianness inside each fuse word.
[Alison Wang] Thanks for your comments. In Vybrid's RM, there is no specific 
descriptions about
how to program the mac address in the OTP Bank4 Word2(OCOTP_MAC0) and OTP Bank4 
Word3(OCOTP_MAC1).
So I think it is not formulary which fuse word is used for high/low parts of 
the MAC address
(i.e. word-level endianness), and for the byte-level endianness inside each 
fuse word.
Through reading the doc/README.vf610, I think the user could program the fuses 
correctly.


Best Regards,
Alison Wang

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

Re: [U-Boot] Vybrid VF610 mac address issue

[Wang Huan-B18965]

Hi, Andy, Fabio, Benoît,

> -Original Message-
> From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de]
> On Behalf Of Beno?t Thébaudeau
> Sent: Thursday, June 06, 2013 5:16 AM
> To: Fabio Estevam
> Cc: u-boot@lists.denx.de
> Subject: Re: [U-Boot] imx: Vybrid VF610 mac address issue
> 
> Hi Andy, Fabio,
> 
> On Wednesday, June 5, 2013 11:13:52 PM, Fabio Estevam wrote:
> > Hi Andy,
> >
> > On Wed, Jun 5, 2013 at 5:54 PM, Andy Voltz 
> wrote:
> > > I recently tried booting the VF610 support on the Tower board, but
> > > the mac address is reversed in Linux userspace. DHCP/BOOTP seems to
> > > work properly in u-boot.
> > >
> > > I'm booting this kernel:
> > > https://github.com/Timesys/linux-timesys/
> > > ref: 2c4ead2dd6da019f5052a69b12c8f5b6b71f8dca
> > >
> > > I haven't yet seen how the address is passed to the kernel, but our
> > > previous u-boot support does not have this issue with the same
> > > kernel. That u-boot branch is also on our github.
> >
> > The MAC address is read in the imx_get_mac_from_fuse() function in
> > arch/arm/cpu/armv7/vf610/generic.c
> >
> > Try printing all the elements of mac[] array in this function and
> > check if the logic is correct there.
> 
> You probably had programmed the fuses with a MAC address on your board,
> and then replaced the existing U-Boot with the mainline version. These
> 2 U-Boot-s may interpret the MAC fuses in a different way. Especially,
> note that VF610 interprets the MAC fuses with reversed endianness
> compared to i.MX6 in mainline U-Boot. This is documented in
> doc/README.. There may be the same difference between VF610 in
> mainline U-Boot and the other version of U-Boot that you used first.
> 
[Alison Wang] First of all, the mac address is set in include/configs/vybrid.h 
as below in Andy's previous u-boot version.
#define CONFIG_ETHADDR  00:e0:0c:bc:e5:60
#define CONFIG_IPADDR   10.81.67.175
Because no hardcoded IP addresses/MAC addresses should be set there, I change 
the codes. As Fabio said, the mac address is read in the 
imx_get_mac_from_fuse() function in arch/arm/cpu/armv7/vf610/generic.c now.

I think Andy may not program the mac address correctly in fuses on his board 
with the mainline version. On my board, the fuses are programmed like this,
The value of OTP fuse Bank4 Word2 is 0x00e0
The value of OTP fuse Bank4 Word3 is 0x0cbce560

So the mac address can be read from imx_get_mac_from_fuse() function in u-boot. 
Then we can get "ethaddr=00:e0:0c:bc:e5:60" in u-boot environment variables as 
below.
Vybrid U-Boot > pri
baudrate=115200
bootdelay=3
ethact=FEC
ethaddr=00:e0:0c:bc:e5:60
stderr=serial
stdin=serial
stdout=serial

Environment size: 121/8188 bytes

Andy, did you program the fuses as above? How about the result after 
programming the fuses as above?

Best Regards,
Alison Wang

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

[U-Boot] Pull request: u-boot-video/master

[Anatolij Gustschin]

Hey Tom,

The following changes since commit 5ed6f447af60aabd2669d913f673793c1ce48f47:

  P1022DS: Set CONFIG_SPL_MAX_SIZE directly (2013-05-03 09:19:43 -0400)

are available in the git repository at:

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

for you to fetch changes up to ea697ae7eb059d7467c6854ce562c31df510eb59:

  ARM: bcm2835: add simplefb DT node during bootz/m (2013-06-05 22:40:38 +0200)


Eric Nelson (1):
  cfb_console: flush FB cache at end of public functions

Stephen Warren (2):
  lcd: add functions to set up simplefb device tree
  ARM: bcm2835: add simplefb DT node during bootz/m

 board/raspberrypi/rpi_b/rpi_b.c|   14 +++-
 common/lcd.c   |   87 
 .../video/simple-framebuffer.txt   |   25 ++
 drivers/video/cfb_console.c|   15 ++--
 include/configs/rpi_b.h|2 +
 include/lcd.h  |3 +
 6 files changed, 139 insertions(+), 7 deletions(-)
 create mode 100644 doc/device-tree-bindings/video/simple-framebuffer.txt

Please pull. Thanks!

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

Re: [U-Boot] Maintain U-Boot splash until application is loaded

[Anatolij Gustschin]

Hi Otavio,

On Tue, 4 Jun 2013 23:13:43 -0300
Otavio Salvador  wrote:
...
> I am working in a product and we'd like to keep the U-Boot splash until the
> application has been loaded so we have a graceful initialization. This
> project uses MX23 (so mxs SoC family).
> 
> I tried to check the U-Boot mailing list archive for it but I couldn't find
> anything useful. I also did look at kernel source and it seems
> CONFIG_FB_PRE_INIT_FB is available for only *one* board.
> 
> Could someone advice me how to do that?

the mxs frame buffer driver in mainline linux tree looks in platform
data structure "struct mxsfb_platform_data" for fb_phys and fb_size
fields and uses this memory range for the frame buffer (if these are
initialized by platform code). But the platform code in
arch/arm/mach-mxs/mach-mxs.c doesn't initialize them. The platform
code could be extended to check if the display controller is
initialized by the boot loader and in this case it should read out
the frame buffer base address from the display controller registers
and calculate the frame buffer size using the resolution and depth
values from the controller registers. Then this frame buffer range
could be reserved (by reserve_bootmem()) so that the kernel doesn't
use it for other purposes, and the reserved range should be passed
in mxsfb_platform_data to the frame buffer driver.

When booting, the frame buffer could be used by frame buffer console
fbcon and in this case your splash will be overwritten. To prevent
this you could pass fbcon=map:1 on the kernel command line and if
the console on frame buffer is needed later, then map the console
to the frame buffer by appropriate ioctl (see con2fbmap utility).

Thanks,

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

[U-Boot] [PATCH 2/4] imx: nitrogen6x: Enable bootz

[Robert Winkler]

Signed-off-by: Robert Winkler 
---
 include/configs/nitrogen6x.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h
index 07f39e9..b126940 100644
--- a/include/configs/nitrogen6x.h
+++ b/include/configs/nitrogen6x.h
@@ -287,4 +287,6 @@
 #define CONFIG_CMD_TIME
 #define CONFIG_SYS_ALT_MEMTEST
 
+#define CONFIG_CMD_BOOTZ
+
 #endif/* __CONFIG_H */
-- 
1.8.3

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

[U-Boot] [PATCH 0/4] imx: nitrogen6x: Config changes

[Robert Winkler]

These are just some config changes for nitrogen6x.


RAW_INITRD, BOOTZ, FS_GENERIC are being used by this project
http://www.eewiki.net/display/linuxonarm/i.MX6x+SABRE+Lite

DCACHE can finally be enabled because some related bugs have
been fixed.

Robert Winkler (4):
  imx: nitrogen6x: Enabled data cache
  imx: nitrogen6x: Enable bootz
  imx: nitrogen6x: Enable raw initrd
  imx: nitrogen6x: Enable filesystem generic commands

 include/configs/nitrogen6x.h | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

-- 
1.8.3

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

[U-Boot] [PATCH 3/4] imx: nitrogen6x: Enable raw initrd

[Robert Winkler]

Signed-off-by: Robert Winkler 
---
 include/configs/nitrogen6x.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h
index b126940..5936e88 100644
--- a/include/configs/nitrogen6x.h
+++ b/include/configs/nitrogen6x.h
@@ -288,5 +288,6 @@
 #define CONFIG_SYS_ALT_MEMTEST
 
 #define CONFIG_CMD_BOOTZ
+#define CONFIG_SUPPORT_RAW_INITRD
 
 #endif/* __CONFIG_H */
-- 
1.8.3

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

[U-Boot] [PATCH 1/4] imx: nitrogen6x: Enabled data cache

[Robert Winkler]

Signed-off-by: Robert Winkler 
---
 include/configs/nitrogen6x.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h
index aea91bc..07f39e9 100644
--- a/include/configs/nitrogen6x.h
+++ b/include/configs/nitrogen6x.h
@@ -276,7 +276,7 @@
 #define CONFIG_OF_LIBFDT
 #define CONFIG_CMD_BOOTZ
 
-#define CONFIG_SYS_DCACHE_OFF
+/* #define CONFIG_SYS_DCACHE_OFF */
 
 #ifndef CONFIG_SYS_DCACHE_OFF
 #define CONFIG_CMD_CACHE
-- 
1.8.3

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

[U-Boot] [PATCH 4/4] imx: nitrogen6x: Enable filesystem generic commands

[Robert Winkler]

Signed-off-by: Robert Winkler 
---
 include/configs/nitrogen6x.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h
index 5936e88..1d8d7e5 100644
--- a/include/configs/nitrogen6x.h
+++ b/include/configs/nitrogen6x.h
@@ -289,5 +289,6 @@
 
 #define CONFIG_CMD_BOOTZ
 #define CONFIG_SUPPORT_RAW_INITRD
+#define CONFIG_CMD_FS_GENERIC
 
 #endif/* __CONFIG_H */
-- 
1.8.3

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

Re: [U-Boot] imx: Vybrid VF610 mac address issue

[Benoît Thébaudeau]

On Wednesday, June 5, 2013 11:16:17 PM, Benoît Thébaudeau wrote:
> Hi Andy, Fabio,
> 
> On Wednesday, June 5, 2013 11:13:52 PM, Fabio Estevam wrote:
> > Hi Andy,
> > 
> > On Wed, Jun 5, 2013 at 5:54 PM, Andy Voltz  wrote:
> > > I recently tried booting the VF610 support on the Tower board, but the
> > > mac
> > > address is reversed in Linux userspace. DHCP/BOOTP seems to work properly
> > > in u-boot.
> > >
> > > I'm booting this kernel:
> > > https://github.com/Timesys/linux-timesys/
> > > ref: 2c4ead2dd6da019f5052a69b12c8f5b6b71f8dca
> > >
> > > I haven't yet seen how the address is passed to the kernel, but our
> > > previous
> > > u-boot support does not have this issue with the same kernel. That u-boot
> > > branch is also on our github.
> > 
> > The MAC address is read in the imx_get_mac_from_fuse() function in
> > arch/arm/cpu/armv7/vf610/generic.c
> > 
> > Try printing all the elements of mac[] array in this function and
> > check if the logic is correct there.
> 
> You probably had programmed the fuses with a MAC address on your board, and
> then
> replaced the existing U-Boot with the mainline version. These 2 U-Boot-s may
> interpret the MAC fuses in a different way. Especially, note that VF610
> interprets the MAC fuses with reversed endianness compared to i.MX6 in
> mainline
> U-Boot. This is documented in doc/README.. There may be the same
> difference
> between VF610 in mainline U-Boot and the other version of U-Boot that you
> used
> first.

But if there is such a difference between U-Boot editions, it might be worth
considering to make mainline U-Boot more consistent with Freescale's or others'
before it is too much widespread. It is especially important if people change
the U-Boot edition on their board.

Stefano, Alison, what do you think?

Alison, have you checked if your implementation in mainline is consistent with
Freescale's? There may be a difference both for which fuse word is used for
high/low parts of the MAC address (i.e. word-level endianness that I was talking
about above), and for the byte-level endianness inside each fuse word.

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

Re: [U-Boot] [PATCH v2] vf610twr: Drop unneeded 'status' variable

[Otavio Salvador]

On Wed, Jun 5, 2013 at 6:34 PM, Fabio Estevam  wrote:

> From: Fabio Estevam 
>
> No need to use the 'status' variable, so just remove it.
>
> Signed-off-by: Fabio Estevam 
>

Reviewed-by: Otavio Salvador 

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] vf610twr: Drop unneeded 'or' operator

[Otavio Salvador]

On Wed, Jun 5, 2013 at 6:24 PM, Benoît Thébaudeau <
benoit.thebaud...@advansee.com> wrote:

> Hi Fabio,
>
> On Wednesday, June 5, 2013 11:17:45 PM, Fabio Estevam wrote:
> > From: Fabio Estevam 
> >
> > No need to use the or operator, so just remove it.
> >
> > Signed-off-by: Fabio Estevam 
> > ---
> >  board/freescale/vf610twr/vf610twr.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/board/freescale/vf610twr/vf610twr.c
> > b/board/freescale/vf610twr/vf610twr.c
> > index 04fa882..1156194 100644
> > --- a/board/freescale/vf610twr/vf610twr.c
> > +++ b/board/freescale/vf610twr/vf610twr.c
> > @@ -308,7 +308,7 @@ int board_mmc_init(bd_t *bis)
> >   imx_iomux_v3_setup_multiple_pads(
> >   esdhc1_pads, ARRAY_SIZE(esdhc1_pads));
> >
> > - status |= fsl_esdhc_initialize(bis, &esdhc_cfg[0]);
> > + status = fsl_esdhc_initialize(bis, &esdhc_cfg[0]);
> >
> >   return status;
> >  }
> > --
> > 1.8.1.2
>
> Or even better, completely drop status and use
> "return fsl_esdhc_initialize(bis, &esdhc_cfg[0]);".
>

+1 :)

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2 REPOST 2/2] ARM: bcm2835: add simplefb DT node during bootz/m

[Anatolij Gustschin]

On Mon, 27 May 2013 22:31:18 -0600
Stephen Warren  wrote:

> Add a DT simple-framebuffer node to DT when booting the Linux kernel.
> This will allow the kernel to inherit the framebuffer configuration from
> U-Boot, and display a graphical boot console, and even run a full SW-
> rendered X server.
> 
> Signed-off-by: Stephen Warren 
> Acked-by: Simon Glass 
> ---
>  board/raspberrypi/rpi_b/rpi_b.c |   14 +-
>  include/configs/rpi_b.h |2 ++
>  2 files changed, 15 insertions(+), 1 deletion(-)

Applied to u-boot-video/master. Thanks!

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

Re: [U-Boot] [PATCH V2 REPOST 1/2] lcd: add functions to set up simplefb device tree

[Anatolij Gustschin]

On Mon, 27 May 2013 22:31:17 -0600
Stephen Warren  wrote:

> simple-framebuffer is a new device tree binding that describes a pre-
> configured frame-buffer memory region and its format. The Linux kernel
> contains a driver that supports this binding. Implement functions to
> create a DT node (or fill in an existing node) with parameters that
> describe the framebuffer format that U-Boot is using.
> 
> This will be immediately used by the Raspberry Pi board in U-Boot, and
> likely will be used by the Samsung ARM ChromeBook support soon too. It
> could well be used by many other boards (e.g. Tegra boards with built-in
> LCD panels, which aren't yet supported by the Linux kernel).
> 
> Signed-off-by: Stephen Warren 
> Acked-by: Simon Glass 
> ---
> v2: Add binding doc, remove ifdefs from lcd.h
> ---
>  common/lcd.c   |   87 
> 
>  .../video/simple-framebuffer.txt   |   25 ++
>  include/lcd.h  |3 +
>  3 files changed, 115 insertions(+)
>  create mode 100644 doc/device-tree-bindings/video/simple-framebuffer.txt

Applied to u-boot-video/master. Thanks!

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

[U-Boot] [PATCH v2] vf610twr: Drop unneeded 'status' variable

[Fabio Estevam]

From: Fabio Estevam 

No need to use the 'status' variable, so just remove it.

Signed-off-by: Fabio Estevam 
---
Changes since v1:
- Drop status variable

 board/freescale/vf610twr/vf610twr.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/board/freescale/vf610twr/vf610twr.c 
b/board/freescale/vf610twr/vf610twr.c
index 04fa882..f14df8b 100644
--- a/board/freescale/vf610twr/vf610twr.c
+++ b/board/freescale/vf610twr/vf610twr.c
@@ -301,16 +301,13 @@ int board_mmc_init(bd_t *bis)
NEW_PAD_CTRL(VF610_PAD_PTA28__ESDHC1_DAT2, ESDHC_PAD_CTRL),
NEW_PAD_CTRL(VF610_PAD_PTA29__ESDHC1_DAT3, ESDHC_PAD_CTRL),
};
-   s32 status = 0;
 
esdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC_CLK);
 
imx_iomux_v3_setup_multiple_pads(
esdhc1_pads, ARRAY_SIZE(esdhc1_pads));
 
-   status |= fsl_esdhc_initialize(bis, &esdhc_cfg[0]);
-
-   return status;
+   return fsl_esdhc_initialize(bis, &esdhc_cfg[0]);
 }
 #endif
 
-- 
1.8.1.2

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

Re: [U-Boot] [PATCH V2 REPOST 1/2] lcd: add functions to set up simplefb device tree

[Anatolij Gustschin]

On Tue, 04 Jun 2013 21:38:19 -0600
Stephen Warren  wrote:
...
> Anatolij, do these patches look good? Are you waiting for Albert to ack
> patch 2 in order to take it through the LCD tree? Thanks.

these patches look good, I'll queue them. Sorry for delay.

Thanks,

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

Re: [U-Boot] [PATCH] vf610twr: Drop unneeded 'or' operator

[Benoît Thébaudeau]

Hi Fabio,

On Wednesday, June 5, 2013 11:17:45 PM, Fabio Estevam wrote:
> From: Fabio Estevam 
> 
> No need to use the or operator, so just remove it.
> 
> Signed-off-by: Fabio Estevam 
> ---
>  board/freescale/vf610twr/vf610twr.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/board/freescale/vf610twr/vf610twr.c
> b/board/freescale/vf610twr/vf610twr.c
> index 04fa882..1156194 100644
> --- a/board/freescale/vf610twr/vf610twr.c
> +++ b/board/freescale/vf610twr/vf610twr.c
> @@ -308,7 +308,7 @@ int board_mmc_init(bd_t *bis)
>   imx_iomux_v3_setup_multiple_pads(
>   esdhc1_pads, ARRAY_SIZE(esdhc1_pads));
>  
> - status |= fsl_esdhc_initialize(bis, &esdhc_cfg[0]);
> + status = fsl_esdhc_initialize(bis, &esdhc_cfg[0]);
>  
>   return status;
>  }
> --
> 1.8.1.2

Or even better, completely drop status and use
"return fsl_esdhc_initialize(bis, &esdhc_cfg[0]);".

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

Re: [U-Boot] imx: Vybrid VF610 mac address issue

[Benoît Thébaudeau]

Hi Andy, Fabio,

On Wednesday, June 5, 2013 11:13:52 PM, Fabio Estevam wrote:
> Hi Andy,
> 
> On Wed, Jun 5, 2013 at 5:54 PM, Andy Voltz  wrote:
> > I recently tried booting the VF610 support on the Tower board, but the mac
> > address is reversed in Linux userspace. DHCP/BOOTP seems to work properly
> > in u-boot.
> >
> > I'm booting this kernel:
> > https://github.com/Timesys/linux-timesys/
> > ref: 2c4ead2dd6da019f5052a69b12c8f5b6b71f8dca
> >
> > I haven't yet seen how the address is passed to the kernel, but our
> > previous
> > u-boot support does not have this issue with the same kernel. That u-boot
> > branch is also on our github.
> 
> The MAC address is read in the imx_get_mac_from_fuse() function in
> arch/arm/cpu/armv7/vf610/generic.c
> 
> Try printing all the elements of mac[] array in this function and
> check if the logic is correct there.

You probably had programmed the fuses with a MAC address on your board, and then
replaced the existing U-Boot with the mainline version. These 2 U-Boot-s may
interpret the MAC fuses in a different way. Especially, note that VF610
interprets the MAC fuses with reversed endianness compared to i.MX6 in mainline
U-Boot. This is documented in doc/README.. There may be the same difference
between VF610 in mainline U-Boot and the other version of U-Boot that you used
first.

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

[U-Boot] [PATCH] vf610twr: Drop unneeded 'or' operator

[Fabio Estevam]

From: Fabio Estevam 

No need to use the or operator, so just remove it.

Signed-off-by: Fabio Estevam 
---
 board/freescale/vf610twr/vf610twr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/freescale/vf610twr/vf610twr.c 
b/board/freescale/vf610twr/vf610twr.c
index 04fa882..1156194 100644
--- a/board/freescale/vf610twr/vf610twr.c
+++ b/board/freescale/vf610twr/vf610twr.c
@@ -308,7 +308,7 @@ int board_mmc_init(bd_t *bis)
imx_iomux_v3_setup_multiple_pads(
esdhc1_pads, ARRAY_SIZE(esdhc1_pads));
 
-   status |= fsl_esdhc_initialize(bis, &esdhc_cfg[0]);
+   status = fsl_esdhc_initialize(bis, &esdhc_cfg[0]);
 
return status;
 }
-- 
1.8.1.2

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

Re: [U-Boot] imx: Vybrid VF610 mac address issue

[Fabio Estevam]

Hi Andy,

On Wed, Jun 5, 2013 at 5:54 PM, Andy Voltz  wrote:
> I recently tried booting the VF610 support on the Tower board, but the mac
> address is reversed in Linux userspace. DHCP/BOOTP seems to work properly
> in u-boot.
>
> I'm booting this kernel:
> https://github.com/Timesys/linux-timesys/
> ref: 2c4ead2dd6da019f5052a69b12c8f5b6b71f8dca
>
> I haven't yet seen how the address is passed to the kernel, but our previous
> u-boot support does not have this issue with the same kernel. That u-boot
> branch is also on our github.

The MAC address is read in the imx_get_mac_from_fuse() function in
arch/arm/cpu/armv7/vf610/generic.c

Try printing all the elements of mac[] array in this function and
check if the logic is correct there.

Regards,

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

[U-Boot] imx: Vybrid VF610 mac address issue

[Andy Voltz]

I recently tried booting the VF610 support on the Tower board, but the mac
address is reversed in Linux userspace. DHCP/BOOTP seems to work properly
in u-boot.

I'm booting this kernel:
https://github.com/Timesys/linux-timesys/
ref: 2c4ead2dd6da019f5052a69b12c8f5b6b71f8dca

I haven't yet seen how the address is passed to the kernel, but our previous
u-boot support does not have this issue with the same kernel. That u-boot
branch is also on our github.

Any ideas?

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

Re: [U-Boot] arm, arm335x: add watchdog support

[Michael Trimarchi]

Hi

On Jun 5, 2013 4:27 PM, "Heiko Schocher"  wrote:
>
> Hello Michael,
>
> Am 05.06.2013 16:21, schrieb Michael Trimarchi:
> > Hi
> >
> > On Jun 5, 2013 4:17 PM, "Heiko Schocher"  > >
wrote:
> >>
> >> Hello Michael,
> >>
> >> Am 05.06.2013 15:31, schrieb Michael Trimarchi:
> >> > Hi
> >> >
> >> > On Jun 4, 2013 10:55 AM, "Heiko Schocher"  >> wrote:
> >> >>
> >> >> Add TI OMAP 16xx & 24xx/34xx 32KHz (non-secure) watchdog support.
> >> >>
> >> >> Signed-off-by: Heiko Schocher mailto:h...@denx.de>
>>
> >> >> Cc: Albert Aribaud   > >>
> >> >> Cc: Tom Rini mailto:tr...@ti.com> mailto:tr...@ti.com>>>
> >> >> ---
> >> >>  arch/arm/include/asm/arch-am33xx/cpu.h |  20 ++
> >> >>  drivers/watchdog/Makefile  |   1 +
> >> >>  drivers/watchdog/omap_wdt.c| 115
+
> >> >>  3 Dateien geändert, 136 Zeilen hinzugefügt(+)
> >> >>  create mode 100644 drivers/watchdog/omap_wdt.c
> >> [...]
> >> >> diff --git a/drivers/watchdog/omap_wdt.c
b/drivers/watchdog/omap_wdt.c
> >> >> new file mode 100644
> >> >> index 000..dc4df98
> >> >> --- /dev/null
> >> >> +++ b/drivers/watchdog/omap_wdt.c
> >> >> @@ -0,0 +1,115 @@
> >> [...]
> >> >> +   /* wait for posted write to complete */
> >> >> +   while ((readl(&wdt->wdtwwps) & WDT_WWPS_PEND_WTGR))
> >> >> +   ;
> >> >> +}
> >> >> +
> >> >
> >> > I think that this patch has some problem because watchdog reset is
in getc code. Did you try to paste very long string when it is enabled? You
need to
> >> > avoid reset when it is not needed
> >>
> >> I think, I do not understand you ... this is for all watchdogs
> >> the case ...
> >>
> >> I currently pasted a 500 bytes long string, seeing no problems
> >> with the watchdog...
> >>
> >
> > OK, maybe was a problem of my version. I have done the same driver 2
month ago and tested on omap3. I optimize the watchdog reset using time
delaying.
> > BTW if it works I have no other comments. Sorry for the noise
>
> Maybe you have a chance to try this patch on your hw?
>

Yes I can or I can ask.

Michael

> bye,
> Heiko
> --
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2 09/12] mmc: omap_hsmmc: add mmc1 pbias, ldo1

[Lubomir Popov]

Hi Nishanth,

> On Wed, Jun 5, 2013 at 11:35 AM, Lubomir Popov  wrote:
>> Hi Nishanth,
>>
>> On 05/06/13 17:01, Nishanth Menon wrote:
>>> On Wed, Jun 5, 2013 at 3:03 AM, Lubomir Popov  wrote:
 Hi Tom,

 On 05/06/13 00:06, Tom Rini wrote:
> On Mon, Jun 03, 2013 at 10:58:27PM +0300, Lubomir Popov wrote:
>> Hi Lokesh,
>>
>>> Hi Lubomir,
>>> On Thursday 30 May 2013 07:56 PM, Lubomir Popov wrote:
 Hi Lokesh,

 On 30/05/13 16:19, Lokesh Vutla wrote:
> From: Balaji T K 
>
> add dra mmc pbias support and ldo1 power on
>
> Signed-off-by: Balaji T K 
> Signed-off-by: Lokesh Vutla 
> ---
>   arch/arm/include/asm/arch-omap5/omap.h |3 ++-
>   drivers/mmc/omap_hsmmc.c   |   26 
> ++
>   drivers/power/palmas.c |   25 
> -
>   include/configs/omap5_common.h |4 
>   include/configs/omap5_uevm.h   |5 -
>   include/palmas.h   |6 +-
>   6 files changed, 49 insertions(+), 20 deletions(-)
>
>> [snip]
> + /* set LDO9 TWL6035 to 3V */
 LDO9? TWL6035? If this function is used on the DRA7xx boards only (with
 TPS659038), you should add some comment above.
>>> Ok ll add the comment.

> + val = 0x2b; /* (3 - 0.9) * 20 + 1 */
 Why not use definitions for the voltage? You could take them from
 http://patchwork.ozlabs.org/patch/244103/ where some values are
 defined.
>>> Yes, Ill rebase this patch on top of your patch and use those defines.
>> Please be aware that my above mentioned patch has not been reviewed/
>> tested/acked/nacked/whatever by nobody (except possibly a quick look by
>> Nishanth Menon, who had some objections). I wrote it when bringing up a
>> custom OMAP5 board, and most probably it shall not go into mainline in
>> its current form, if ever. I gave it only as an example of how things
>> could be done cleaner. Feel free to use the code as you wish, but I'm
>> afraid that applying it as a patch to your tree and basing upon it might
>> run you into problems when you later sync with mainline.
>>
>> Tom, your opinion?
>
> OK, so at the time it was "nothing will really use this code except test
> functions".  Looks like we have a use for mmc1_ldo9 code at least, so
> lets rework the first patch for adding that + cleanups wrt constants.
 Well, I'm not quite sure that this LDO9 function would be the only one
 used (or LDO1 on the DRA7xx board). Judging from omapboot for the OMAP5
 boards for example, SMPS7 (it delivers the common 1.8 V I/O supply) is
 set to 'Forced PWM' mode in order to reduce board noise - there sure has
 been a reason to do so and sacrifice converter efficiency. Therefore I
 added similar functionality in my patch to the Palmas driver (and am
 explicitly calling it in my board init).
 The option to bypass LDO9 on OMAP5+TWL603x boards seems quite mandatory
 as well, if hardware is designed such that the SD card socket has a
 separate fixed 3.3 V supply which also powers the LDO9 input (the
 uEVM for example). On the DRA7xx+TPS659038 board the power scheme is
 different and this does not apply.

>>>
>>> I hate this code for many reasons -
>>> a) hsmmc is used on many OMAP and DM platforms to my knowledge.
>>> b) what is being done here is to power on the LDO supplying MMC.
>> Sorry, but I can't get if hsmmc is discussed here, or power.
>>
>> For OMAP5+TWL603x the LDO powering MMC (actually the removable card
>> interface only; eMMC is another story) is turned on automatically at
>> power-on by the PMIC sequencer, with a default voltage and mode --
>> otherwise we would not be able to boot from a card (ROM code does not
>> touch the PMIC at all). We are talking here about the possibility to
>> have additional control over this LDO, which should be board-specific,
>> I agree. On the OMAP5 boards, for example, the call to
>> palmas_mmc1_poweron_ldo() from within omap_hsmmc actually does not
>> turn on LDO9 - it is on at this moment anyway. The call just makes
>> it switch from the default bypass mode (with Vout = Vin = 3.3 V) to
>> regulation mode and Vout = 3.0 V. Why is this done is yet another
>> question; to me it seems useless (and possibly wrong) when the card
>> is powered with a fixed voltage of 3.3 V.
>> Therefore it seems reasonable to count on the PMIC defaults and
>> remove this call from omap_hsmmc altogether, thus disengaging the
>> PMIC driver from hsmmc, at least for OMAP5.
>>
>> For OMAP4 things are somewhat different. Here the TWL6030 PMIC powers
>> both the OMAP interface and the card socket, and in addition can
>> automatically power off the MMC LDO upon detecting card removal.
>> ROM 

Re: [U-Boot] [PATCH] powerpc/mpc85xx:Add iprot input arg in create_TLB0/1_entry

[Scott Wood]

On 06/04/2013 10:20:38 PM, Prabhakar Kushwaha wrote:

On 06/04/2013 10:07 PM, Scott Wood wrote:

On 06/04/2013 11:36:17 AM, Scott Wood wrote:

On 06/04/2013 05:24:41 AM, Prabhakar Kushwaha wrote:
create_tlb1_entry and create_tlb0_entry creates TLB entries with  
IPROT
bit set by default. Any TLB entries with IPROT = 1 can not be  
invalidated.


Add IPROT as input argument for TLB entry creation APIs.

Signed-off-by: Prabhakar Kushwaha 
---
 Based upon git://git.denx.de/u-boot.git branch master


NACK as discussed in the thread where you suggested this.


Sigh, didn't notice this was the external list, so I'll elaborate.   
We never want to create a non-IPROT entry, as we don't have a TLB  
miss handler that will replace entries that have been invalidated.   
This will be especially important if we ever run U-Boot inside a  
virtual machine.  And yes, this means that the current TLB0 usage  
should go away as well.


oh..

this means function like invalidate_tlb(1) should not be used u-boot?


Pretty much, yes.

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

Re: [U-Boot] [PATCH V2 09/12] mmc: omap_hsmmc: add mmc1 pbias, ldo1

[Nishanth Menon]

On Wed, Jun 5, 2013 at 11:35 AM, Lubomir Popov  wrote:
> Hi Nishanth,
>
> On 05/06/13 17:01, Nishanth Menon wrote:
>> On Wed, Jun 5, 2013 at 3:03 AM, Lubomir Popov  wrote:
>>> Hi Tom,
>>>
>>> On 05/06/13 00:06, Tom Rini wrote:
 On Mon, Jun 03, 2013 at 10:58:27PM +0300, Lubomir Popov wrote:
> Hi Lokesh,
>
>> Hi Lubomir,
>> On Thursday 30 May 2013 07:56 PM, Lubomir Popov wrote:
>>> Hi Lokesh,
>>>
>>> On 30/05/13 16:19, Lokesh Vutla wrote:
 From: Balaji T K 

 add dra mmc pbias support and ldo1 power on

 Signed-off-by: Balaji T K 
 Signed-off-by: Lokesh Vutla 
 ---
   arch/arm/include/asm/arch-omap5/omap.h |3 ++-
   drivers/mmc/omap_hsmmc.c   |   26 
 ++
   drivers/power/palmas.c |   25 
 -
   include/configs/omap5_common.h |4 
   include/configs/omap5_uevm.h   |5 -
   include/palmas.h   |6 +-
   6 files changed, 49 insertions(+), 20 deletions(-)

> [snip]
 + /* set LDO9 TWL6035 to 3V */
>>> LDO9? TWL6035? If this function is used on the DRA7xx boards only (with
>>> TPS659038), you should add some comment above.
>> Ok ll add the comment.
>>>
 + val = 0x2b; /* (3 - 0.9) * 20 + 1 */
>>> Why not use definitions for the voltage? You could take them from
>>> http://patchwork.ozlabs.org/patch/244103/ where some values are
>>> defined.
>> Yes, Ill rebase this patch on top of your patch and use those defines.
> Please be aware that my above mentioned patch has not been reviewed/
> tested/acked/nacked/whatever by nobody (except possibly a quick look by
> Nishanth Menon, who had some objections). I wrote it when bringing up a
> custom OMAP5 board, and most probably it shall not go into mainline in
> its current form, if ever. I gave it only as an example of how things
> could be done cleaner. Feel free to use the code as you wish, but I'm
> afraid that applying it as a patch to your tree and basing upon it might
> run you into problems when you later sync with mainline.
>
> Tom, your opinion?

 OK, so at the time it was "nothing will really use this code except test
 functions".  Looks like we have a use for mmc1_ldo9 code at least, so
 lets rework the first patch for adding that + cleanups wrt constants.
>>> Well, I'm not quite sure that this LDO9 function would be the only one
>>> used (or LDO1 on the DRA7xx board). Judging from omapboot for the OMAP5
>>> boards for example, SMPS7 (it delivers the common 1.8 V I/O supply) is
>>> set to 'Forced PWM' mode in order to reduce board noise - there sure has
>>> been a reason to do so and sacrifice converter efficiency. Therefore I
>>> added similar functionality in my patch to the Palmas driver (and am
>>> explicitly calling it in my board init).
>>> The option to bypass LDO9 on OMAP5+TWL603x boards seems quite mandatory
>>> as well, if hardware is designed such that the SD card socket has a
>>> separate fixed 3.3 V supply which also powers the LDO9 input (the
>>> uEVM for example). On the DRA7xx+TPS659038 board the power scheme is
>>> different and this does not apply.
>>>
>>
>> I hate this code for many reasons -
>> a) hsmmc is used on many OMAP and DM platforms to my knowledge.
>> b) what is being done here is to power on the LDO supplying MMC.
> Sorry, but I can't get if hsmmc is discussed here, or power.
>
> For OMAP5+TWL603x the LDO powering MMC (actually the removable card
> interface only; eMMC is another story) is turned on automatically at
> power-on by the PMIC sequencer, with a default voltage and mode --
> otherwise we would not be able to boot from a card (ROM code does not
> touch the PMIC at all). We are talking here about the possibility to
> have additional control over this LDO, which should be board-specific,
> I agree. On the OMAP5 boards, for example, the call to
> palmas_mmc1_poweron_ldo() from within omap_hsmmc actually does not
> turn on LDO9 - it is on at this moment anyway. The call just makes
> it switch from the default bypass mode (with Vout = Vin = 3.3 V) to
> regulation mode and Vout = 3.0 V. Why is this done is yet another
> question; to me it seems useless (and possibly wrong) when the card
> is powered with a fixed voltage of 3.3 V.
> Therefore it seems reasonable to count on the PMIC defaults and
> remove this call from omap_hsmmc altogether, thus disengaging the
> PMIC driver from hsmmc, at least for OMAP5.
>
> For OMAP4 things are somewhat different. Here the TWL6030 PMIC powers
> both the OMAP interface and the card socket, and in addition can
> automatically power off the MMC LDO upon detecting card removal.
> ROM code *does* access the MMC LDO to turn it on and set it to 3.0 V
> (it starts by default at 1.8 V), but only if b

Re: [U-Boot] TPM patches to pull if you wish

[Tom Rini]

On Mon, Jun 03, 2013 at 06:08:23PM -0700, Simon Glass wrote:

> Hi Tom,
> 
> I pushed the TPM patches to a branch for you if you want to pick them up.
> 
> I ended up squashing the config patch into the others - since otherwise
> snow will not build for one commit. Does that seem acceptable or should I
> resend the whole series again?
> 
> Here are the original patches:
> 
> http://patchwork.ozlabs.org/bundle/sjg/tpm/
> 
> 
> The following changes since commit d6639d10dbfa42dc888f8917012550b632a88959:
> 
>   Merge branch 'master' of git://git.denx.de/u-boot-nand-flash (2013-05-31
> 18:28:47 -0400)
> 
> are available in the git repository at:
> 
> 
>   git://git.denx.de/u-boot-x86.git tpm
> 
> for you to fetch changes up to 1b393db5870927d68c42a46e6c5877c8d0d83910:
> 
>   tpm: Reorganize the I2C TPM driver (2013-06-03 01:31:23 -0700)
> 
> 
> Che-liang Chiou (1):
>   tpm: Rename generic_lpc_tpm to tpm_tis_lpc
> 
> Tom Wai-Hong Tam (2):
>   x86: config: Reflect the name changes of LPC TPM configs
>   tpm: Reorganize the I2C TPM driver
> 
> Vincent Palatin (1):
>   tpm: Add support for new Infineon I2C TPM (SLB 9645 TT 1.2 I2C)
> 
>  README   |  18 +++-
>  drivers/tpm/Makefile |   7 +-
>  drivers/tpm/slb9635_i2c/compatibility.h  |  51 -
>  drivers/tpm/tis_i2c.c|   4 +
>  drivers/tpm/{slb9635_i2c => }/tpm.c  | 280
> ++-
>  drivers/tpm/{slb9635_i2c/tpm.h => tpm_private.h} |  46 ++--
>  drivers/tpm/{slb9635_i2c => }/tpm_tis_i2c.c  | 354
> 
>  drivers/tpm/{generic_lpc_tpm.c => tpm_tis_lpc.c} |   0
>  include/configs/coreboot.h   |   3 +-
>  include/configs/exynos5250-dt.h  |   6 +-
>  include/fdtdec.h |   1 +
>  lib/fdtdec.c |   1 +
>  12 files changed, 486 insertions(+), 285 deletions(-)
>  delete mode 100644 drivers/tpm/slb9635_i2c/compatibility.h
>  rename drivers/tpm/{slb9635_i2c => }/tpm.c (63%)
>  rename drivers/tpm/{slb9635_i2c/tpm.h => tpm_private.h} (71%)
>  rename drivers/tpm/{slb9635_i2c => }/tpm_tis_i2c.c (59%)
>  rename drivers/tpm/{generic_lpc_tpm.c => tpm_tis_lpc.c} (100%)

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH V2 09/12] mmc: omap_hsmmc: add mmc1 pbias, ldo1

[Lubomir Popov]

Hi Nishanth,

On 05/06/13 17:01, Nishanth Menon wrote:
> On Wed, Jun 5, 2013 at 3:03 AM, Lubomir Popov  wrote:
>> Hi Tom,
>>
>> On 05/06/13 00:06, Tom Rini wrote:
>>> On Mon, Jun 03, 2013 at 10:58:27PM +0300, Lubomir Popov wrote:
 Hi Lokesh,

> Hi Lubomir,
> On Thursday 30 May 2013 07:56 PM, Lubomir Popov wrote:
>> Hi Lokesh,
>>
>> On 30/05/13 16:19, Lokesh Vutla wrote:
>>> From: Balaji T K 
>>>
>>> add dra mmc pbias support and ldo1 power on
>>>
>>> Signed-off-by: Balaji T K 
>>> Signed-off-by: Lokesh Vutla 
>>> ---
>>>   arch/arm/include/asm/arch-omap5/omap.h |3 ++-
>>>   drivers/mmc/omap_hsmmc.c   |   26 
>>> ++
>>>   drivers/power/palmas.c |   25 
>>> -
>>>   include/configs/omap5_common.h |4 
>>>   include/configs/omap5_uevm.h   |5 -
>>>   include/palmas.h   |6 +-
>>>   6 files changed, 49 insertions(+), 20 deletions(-)
>>>
 [snip]
>>> + /* set LDO9 TWL6035 to 3V */
>> LDO9? TWL6035? If this function is used on the DRA7xx boards only (with
>> TPS659038), you should add some comment above.
> Ok ll add the comment.
>>
>>> + val = 0x2b; /* (3 - 0.9) * 20 + 1 */
>> Why not use definitions for the voltage? You could take them from
>> http://patchwork.ozlabs.org/patch/244103/ where some values are
>> defined.
> Yes, Ill rebase this patch on top of your patch and use those defines.
 Please be aware that my above mentioned patch has not been reviewed/
 tested/acked/nacked/whatever by nobody (except possibly a quick look by
 Nishanth Menon, who had some objections). I wrote it when bringing up a
 custom OMAP5 board, and most probably it shall not go into mainline in
 its current form, if ever. I gave it only as an example of how things
 could be done cleaner. Feel free to use the code as you wish, but I'm
 afraid that applying it as a patch to your tree and basing upon it might
 run you into problems when you later sync with mainline.

 Tom, your opinion?
>>>
>>> OK, so at the time it was "nothing will really use this code except test
>>> functions".  Looks like we have a use for mmc1_ldo9 code at least, so
>>> lets rework the first patch for adding that + cleanups wrt constants.
>> Well, I'm not quite sure that this LDO9 function would be the only one
>> used (or LDO1 on the DRA7xx board). Judging from omapboot for the OMAP5
>> boards for example, SMPS7 (it delivers the common 1.8 V I/O supply) is
>> set to 'Forced PWM' mode in order to reduce board noise - there sure has
>> been a reason to do so and sacrifice converter efficiency. Therefore I
>> added similar functionality in my patch to the Palmas driver (and am
>> explicitly calling it in my board init).
>> The option to bypass LDO9 on OMAP5+TWL603x boards seems quite mandatory
>> as well, if hardware is designed such that the SD card socket has a
>> separate fixed 3.3 V supply which also powers the LDO9 input (the
>> uEVM for example). On the DRA7xx+TPS659038 board the power scheme is
>> different and this does not apply.
>>
> 
> I hate this code for many reasons -
> a) hsmmc is used on many OMAP and DM platforms to my knowledge.
> b) what is being done here is to power on the LDO supplying MMC.
Sorry, but I can't get if hsmmc is discussed here, or power.

For OMAP5+TWL603x the LDO powering MMC (actually the removable card
interface only; eMMC is another story) is turned on automatically at
power-on by the PMIC sequencer, with a default voltage and mode --
otherwise we would not be able to boot from a card (ROM code does not
touch the PMIC at all). We are talking here about the possibility to
have additional control over this LDO, which should be board-specific,
I agree. On the OMAP5 boards, for example, the call to
palmas_mmc1_poweron_ldo() from within omap_hsmmc actually does not
turn on LDO9 - it is on at this moment anyway. The call just makes
it switch from the default bypass mode (with Vout = Vin = 3.3 V) to
regulation mode and Vout = 3.0 V. Why is this done is yet another
question; to me it seems useless (and possibly wrong) when the card
is powered with a fixed voltage of 3.3 V.
Therefore it seems reasonable to count on the PMIC defaults and
remove this call from omap_hsmmc altogether, thus disengaging the
PMIC driver from hsmmc, at least for OMAP5.

For OMAP4 things are somewhat different. Here the TWL6030 PMIC powers
both the OMAP interface and the card socket, and in addition can
automatically power off the MMC LDO upon detecting card removal.
ROM code *does* access the MMC LDO to turn it on and set it to 3.0 V
(it starts by default at 1.8 V), but only if booting from a card.
So here the call to PMIC driver should stay.

Other OMAPs and derivatives - other scenarios.

Anyway, omap_hsmmc.c is built for TI platforms only. If you me

Re: [U-Boot] [PATCH V2 09/12] mmc: omap_hsmmc: add mmc1 pbias, ldo1

[Nishanth Menon]

On Wed, Jun 5, 2013 at 3:03 AM, Lubomir Popov  wrote:
> Hi Tom,
>
> On 05/06/13 00:06, Tom Rini wrote:
>> On Mon, Jun 03, 2013 at 10:58:27PM +0300, Lubomir Popov wrote:
>>> Hi Lokesh,
>>>
 Hi Lubomir,
 On Thursday 30 May 2013 07:56 PM, Lubomir Popov wrote:
> Hi Lokesh,
>
> On 30/05/13 16:19, Lokesh Vutla wrote:
>> From: Balaji T K 
>>
>> add dra mmc pbias support and ldo1 power on
>>
>> Signed-off-by: Balaji T K 
>> Signed-off-by: Lokesh Vutla 
>> ---
>>   arch/arm/include/asm/arch-omap5/omap.h |3 ++-
>>   drivers/mmc/omap_hsmmc.c   |   26 
>> ++
>>   drivers/power/palmas.c |   25 -
>>   include/configs/omap5_common.h |4 
>>   include/configs/omap5_uevm.h   |5 -
>>   include/palmas.h   |6 +-
>>   6 files changed, 49 insertions(+), 20 deletions(-)
>>
>>> [snip]
>> + /* set LDO9 TWL6035 to 3V */
> LDO9? TWL6035? If this function is used on the DRA7xx boards only (with
> TPS659038), you should add some comment above.
 Ok ll add the comment.
>
>> + val = 0x2b; /* (3 - 0.9) * 20 + 1 */
> Why not use definitions for the voltage? You could take them from
> http://patchwork.ozlabs.org/patch/244103/ where some values are
> defined.
 Yes, Ill rebase this patch on top of your patch and use those defines.
>>> Please be aware that my above mentioned patch has not been reviewed/
>>> tested/acked/nacked/whatever by nobody (except possibly a quick look by
>>> Nishanth Menon, who had some objections). I wrote it when bringing up a
>>> custom OMAP5 board, and most probably it shall not go into mainline in
>>> its current form, if ever. I gave it only as an example of how things
>>> could be done cleaner. Feel free to use the code as you wish, but I'm
>>> afraid that applying it as a patch to your tree and basing upon it might
>>> run you into problems when you later sync with mainline.
>>>
>>> Tom, your opinion?
>>
>> OK, so at the time it was "nothing will really use this code except test
>> functions".  Looks like we have a use for mmc1_ldo9 code at least, so
>> lets rework the first patch for adding that + cleanups wrt constants.
> Well, I'm not quite sure that this LDO9 function would be the only one
> used (or LDO1 on the DRA7xx board). Judging from omapboot for the OMAP5
> boards for example, SMPS7 (it delivers the common 1.8 V I/O supply) is
> set to 'Forced PWM' mode in order to reduce board noise - there sure has
> been a reason to do so and sacrifice converter efficiency. Therefore I
> added similar functionality in my patch to the Palmas driver (and am
> explicitly calling it in my board init).
> The option to bypass LDO9 on OMAP5+TWL603x boards seems quite mandatory
> as well, if hardware is designed such that the SD card socket has a
> separate fixed 3.3 V supply which also powers the LDO9 input (the
> uEVM for example). On the DRA7xx+TPS659038 board the power scheme is
> different and this does not apply.
>

I hate this code for many reasons -
a) hsmmc is used on many OMAP and DM platforms to my knowledge.
b) what is being done here is to power on the LDO supplying MMC.

The implementation *should* be board specific! not an #ifdef madness
which works only on TI platforms.

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

[U-Boot] pull request: u-boot-arm/master

[Albert ARIBAUD]

Hello Tom,

The following changes since commit
3da0e5750b24a9491058df6126c7be577a276c09:

  arm: factorize relocate_code routine (2013-05-30 20:24:38 +0200)

are available in the git repository at:

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

for you to fetch changes up to 4596dcc1d4ea5763e0f92cf5becd9fc7d4c6e674:

  am33xx/omap: Move save_omap_boot_params to omap-common/boot-common.c
  (2013-06-05 08:46:49 -0400)


Tom Rini (3):
  omap-common/hwinit-common.c: Mark omap_rev_string as static
  am33xx: Correct NON_SECURE_SRAM_START/END
  am33xx/omap: Move save_omap_boot_params to
omap-common/boot-common.c

 arch/arm/cpu/armv7/omap-common/boot-common.c   |   39
 
 arch/arm/cpu/armv7/omap-common/hwinit-common.c |   38
 +-- arch/arm/include/asm/arch-am33xx/omap.h
 |4 +-- arch/arm/include/asm/arch-am33xx/sys_proto.h   |1 +
 arch/arm/include/asm/arch-omap4/sys_proto.h|1 +
 arch/arm/include/asm/arch-omap5/sys_proto.h|1 +
 board/isee/igep0033/board.c|9 ++
 board/phytec/pcm051/board.c|9 ++
 board/ti/am335x/board.c|9 ++
 board/ti/ti814x/evm.c  |9 ++
 include/configs/am335x_evm.h   |   10 --
 include/configs/igep0033.h |   10 --
 include/configs/pcm051.h   |   10 -- 13 files
 changed, 105 insertions(+), 45 deletions(-)

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

Re: [U-Boot] Please pull u-boot-ti/master

[Albert ARIBAUD]

Hi Tom,

On Wed, 5 Jun 2013 08:54:18 -0400, Tom Rini  wrote:

> Hello,
> 
> The following changes since commit 3da0e5750b24a9491058df6126c7be577a276c09:
> 
>   arm: factorize relocate_code routine (2013-05-30 20:24:38 +0200)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-ti.git master
> 
> for you to fetch changes up to 4596dcc1d4ea5763e0f92cf5becd9fc7d4c6e674:
> 
>   am33xx/omap: Move save_omap_boot_params to omap-common/boot-common.c 
> (2013-06-05 08:46:49 -0400)
> 
> 
> Tom Rini (3):
>   omap-common/hwinit-common.c: Mark omap_rev_string as static
>   am33xx: Correct NON_SECURE_SRAM_START/END
>   am33xx/omap: Move save_omap_boot_params to omap-common/boot-common.c
> 
>  arch/arm/cpu/armv7/omap-common/boot-common.c   |   39 
> 
>  arch/arm/cpu/armv7/omap-common/hwinit-common.c |   38 +--
>  arch/arm/include/asm/arch-am33xx/omap.h|4 +--
>  arch/arm/include/asm/arch-am33xx/sys_proto.h   |1 +
>  arch/arm/include/asm/arch-omap4/sys_proto.h|1 +
>  arch/arm/include/asm/arch-omap5/sys_proto.h|1 +
>  board/isee/igep0033/board.c|9 ++
>  board/phytec/pcm051/board.c|9 ++
>  board/ti/am335x/board.c|9 ++
>  board/ti/ti814x/evm.c  |9 ++
>  include/configs/am335x_evm.h   |   10 --
>  include/configs/igep0033.h |   10 --
>  include/configs/pcm051.h   |   10 --
>  13 files changed, 105 insertions(+), 45 deletions(-)
> 

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 1/1 RESEND] NET: Fix system hanging if NET device is not installed

[Stephen Warren]

On 06/05/2013 01:07 AM, Jim Lin wrote:
> If we try to boot from NET device, NetInitLoop in net.c will be invoked.
> If NET device is not installed, eth_get_dev() function will return
> eth_current value, which is NULL.
> When NetInitLoop is called, "eth_get_dev->enetaddr" will access
> restricted memory area and therefore cause hanging.
> This issue is found on Tegra30 Cardhu platform after adding
> CONFIG_CMD_NET and CONFIG_CMD_DHCP in config header file.

Oh, you didn't send this patch to anyone, just the mailing list. I added
the net maintainer to Cc so he'll see this patch.

BTW, this is a critical bugfix, to avoid hangs without any USB Ethernet
device attached.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v3] arm: dra7xx: Update the EXTRA_ENV_SETTINGS

[Dan Murphy]

Update the EXTRA_ENV_SETTING for the dra7xx.
The console needs to be set to ttyO0 and the
findfdt needs to be updated to load the
dra7xx-evm.dtb file.

Signed-off-by: Dan Murphy 
---
v3 - Updated based on comments - http://patchwork.ozlabs.org/patch/248687/
v2 - Updated with side bar maintainer comments.
 include/configs/dra7xx_evm.h   |2 ++
 include/configs/omap5_common.h |8 ++--
 include/configs/omap5_uevm.h   |1 +
 3 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h
index 28a306b..2db0fbd 100644
--- a/include/configs/dra7xx_evm.h
+++ b/include/configs/dra7xx_evm.h
@@ -35,4 +35,6 @@
 #define CONFIG_DRA7XX  /* in a TI DRA7XX core */
 #define CONFIG_SYS_PROMPT  "DRA752 EVM # "
 
+#define CONSOLEDEV "ttyO0"
+
 #endif /* __CONFIG_DRA7XX_EVM_H */
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index deb5e9f..b261176 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -144,7 +144,7 @@
 
 #define CONFIG_EXTRA_ENV_SETTINGS \
"loadaddr=0x8200\0" \
-   "console=ttyO2,115200n8\0" \
+   "console=" CONSOLEDEV ",115200n8\0" \
"fdt_high=0x\0" \
"fdtaddr=0x80f8\0" \
"bootpart=0:2\0" \
@@ -174,7 +174,11 @@
"bootz ${loadaddr} - ${fdtaddr}\0" \
"findfdt="\
"if test $board_name = omap5_uevm; then " \
-   "setenv fdtfile omap5-uevm.dtb; fi;\0 " \
+   "setenv fdtfile omap5-uevm.dtb; fi; " \
+   "if test $board_name = dra7xx; then " \
+   "setenv fdtfile dra7-evm.dtb; fi; " \
+   "if test -z ${fdtfile}; then " \
+   "echo WARNING: Could not determine device tree to use; 
fi; \0" \
"loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile};\0" \
 
 #define CONFIG_BOOTCOMMAND \
diff --git a/include/configs/omap5_uevm.h b/include/configs/omap5_uevm.h
index 9e0339b..f2cbb02 100644
--- a/include/configs/omap5_uevm.h
+++ b/include/configs/omap5_uevm.h
@@ -55,6 +55,7 @@
 #define CONFIG_CMD_PART
 
 #define CONFIG_SYS_PROMPT  "OMAP5430 EVM # "
+#define CONSOLEDEV "ttyO2"
 
 #define CONFIG_OMAP_PLATFORM_RESET_TIME_MAX_USEC   16296
 #endif /* __CONFIG_OMAP5_EVM_H */
-- 
1.7.5.4

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

Re: [U-Boot] arm, arm335x: add watchdog support

[Heiko Schocher]

Hello Michael,

Am 05.06.2013 16:21, schrieb Michael Trimarchi:
> Hi
> 
> On Jun 5, 2013 4:17 PM, "Heiko Schocher" mailto:h...@denx.de>> 
> wrote:
>>
>> Hello Michael,
>>
>> Am 05.06.2013 15:31, schrieb Michael Trimarchi:
>> > Hi
>> >
>> > On Jun 4, 2013 10:55 AM, "Heiko Schocher" > >  >> wrote:
>> >>
>> >> Add TI OMAP 16xx & 24xx/34xx 32KHz (non-secure) watchdog support.
>> >>
>> >> Signed-off-by: Heiko Schocher mailto:h...@denx.de> 
>> >> >>
>> >> Cc: Albert Aribaud > >>   >>
>> >> Cc: Tom Rini mailto:tr...@ti.com> > >> >>
>> >> ---
>> >>  arch/arm/include/asm/arch-am33xx/cpu.h |  20 ++
>> >>  drivers/watchdog/Makefile  |   1 +
>> >>  drivers/watchdog/omap_wdt.c| 115 
>> >> +
>> >>  3 Dateien geändert, 136 Zeilen hinzugefügt(+)
>> >>  create mode 100644 drivers/watchdog/omap_wdt.c
>> [...]
>> >> diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
>> >> new file mode 100644
>> >> index 000..dc4df98
>> >> --- /dev/null
>> >> +++ b/drivers/watchdog/omap_wdt.c
>> >> @@ -0,0 +1,115 @@
>> [...]
>> >> +   /* wait for posted write to complete */
>> >> +   while ((readl(&wdt->wdtwwps) & WDT_WWPS_PEND_WTGR))
>> >> +   ;
>> >> +}
>> >> +
>> >
>> > I think that this patch has some problem because watchdog reset is in getc 
>> > code. Did you try to paste very long string when it is enabled? You need to
>> > avoid reset when it is not needed
>>
>> I think, I do not understand you ... this is for all watchdogs
>> the case ...
>>
>> I currently pasted a 500 bytes long string, seeing no problems
>> with the watchdog...
>>
> 
> OK, maybe was a problem of my version. I have done the same driver 2 month 
> ago and tested on omap3. I optimize the watchdog reset using time delaying.
> BTW if it works I have no other comments. Sorry for the noise

Maybe you have a chance to try this patch on your hw?

bye,
Heiko
-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] arm, arm335x: add watchdog support

[Michael Trimarchi]

Hi

On Jun 5, 2013 4:17 PM, "Heiko Schocher"  wrote:
>
> Hello Michael,
>
> Am 05.06.2013 15:31, schrieb Michael Trimarchi:
> > Hi
> >
> > On Jun 4, 2013 10:55 AM, "Heiko Schocher"  > >
wrote:
> >>
> >> Add TI OMAP 16xx & 24xx/34xx 32KHz (non-secure) watchdog support.
> >>
> >> Signed-off-by: Heiko Schocher mailto:h...@denx.de>>
> >> Cc: Albert Aribaud >
> >> Cc: Tom Rini mailto:tr...@ti.com>>
> >> ---
> >>  arch/arm/include/asm/arch-am33xx/cpu.h |  20 ++
> >>  drivers/watchdog/Makefile  |   1 +
> >>  drivers/watchdog/omap_wdt.c| 115
+
> >>  3 Dateien geändert, 136 Zeilen hinzugefügt(+)
> >>  create mode 100644 drivers/watchdog/omap_wdt.c
> [...]
> >> diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
> >> new file mode 100644
> >> index 000..dc4df98
> >> --- /dev/null
> >> +++ b/drivers/watchdog/omap_wdt.c
> >> @@ -0,0 +1,115 @@
> [...]
> >> +   /* wait for posted write to complete */
> >> +   while ((readl(&wdt->wdtwwps) & WDT_WWPS_PEND_WTGR))
> >> +   ;
> >> +}
> >> +
> >
> > I think that this patch has some problem because watchdog reset is in
getc code. Did you try to paste very long string when it is enabled? You
need to
> > avoid reset when it is not needed
>
> I think, I do not understand you ... this is for all watchdogs
> the case ...
>
> I currently pasted a 500 bytes long string, seeing no problems
> with the watchdog...
>

OK, maybe was a problem of my version. I have done the same driver 2 month
ago and tested on omap3. I optimize the watchdog reset using time delaying.
BTW if it works I have no other comments. Sorry for the noise

Michael

> bye,
> Heiko
> --
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-BOOT] [PATCH] arm: da830: moved pinmux configurations to the arch tree

[Christian Riesch]

On 2013-05-30 09:55, Vishwanathrao Badarkhe, Manish wrote:

Move pinmux configurations for the DA830 SoCs from board file
to the arch tree so that it can be used for all da830 based devices.
Also, avoids duplicate pinmuxing in case of NAND.

Signed-off-by: Vishwanathrao Badarkhe, Manish 


Acked-by: Christian Riesch 

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

Re: [U-Boot] arm, arm335x: add watchdog support

[Heiko Schocher]

Hello Michael,

Am 05.06.2013 15:31, schrieb Michael Trimarchi:
> Hi
> 
> On Jun 4, 2013 10:55 AM, "Heiko Schocher"  > wrote:
>>
>> Add TI OMAP 16xx & 24xx/34xx 32KHz (non-secure) watchdog support.
>>
>> Signed-off-by: Heiko Schocher mailto:h...@denx.de>>
>> Cc: Albert Aribaud > >
>> Cc: Tom Rini mailto:tr...@ti.com>>
>> ---
>>  arch/arm/include/asm/arch-am33xx/cpu.h |  20 ++
>>  drivers/watchdog/Makefile  |   1 +
>>  drivers/watchdog/omap_wdt.c| 115 
>> +
>>  3 Dateien geändert, 136 Zeilen hinzugefügt(+)
>>  create mode 100644 drivers/watchdog/omap_wdt.c
[...]
>> diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
>> new file mode 100644
>> index 000..dc4df98
>> --- /dev/null
>> +++ b/drivers/watchdog/omap_wdt.c
>> @@ -0,0 +1,115 @@
[...]
>> +   /* wait for posted write to complete */
>> +   while ((readl(&wdt->wdtwwps) & WDT_WWPS_PEND_WTGR))
>> +   ;
>> +}
>> +
> 
> I think that this patch has some problem because watchdog reset is in getc 
> code. Did you try to paste very long string when it is enabled? You need to
> avoid reset when it is not needed

I think, I do not understand you ... this is for all watchdogs
the case ...

I currently pasted a 500 bytes long string, seeing no problems
with the watchdog...

bye,
Heiko
-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] dfu: make data buffer size configurable

[Heiko Schocher]

Hello Tom,

Am 05.06.2013 14:43, schrieb Tom Rini:
> On Wed, Jun 05, 2013 at 06:53:53AM +0200, Heiko Schocher wrote:
>> Hello Tom,
>>
>> Am 04.06.2013 22:04, schrieb Tom Rini:
>>> On Tue, Jun 04, 2013 at 11:22:54AM +0200, Heiko Schocher wrote:
[...]
 +  CONFIG_SYS_DFU_DATA_BUF_SIZE
 +  Dfu transfer uses a buffer before writing data to the
 +  raw storage device. Make the size (in bytes) of this buffer
 +  configurable.
 +
CONFIG_SYS_DFU_MAX_FILE_SIZE
When updating files rather than the raw storage device,
we use a static buffer to copy the file into and then write
>>>
>>> The point of the buffer being configurable is to allow for larger files,
>>> right?  We need to fix CONFIG_SYS_DFU_MAX_FILE_SIZE so that..
>>
>> In current code CONFIG_SYS_DFU_MAX_FILE_SIZE is not used in dfu_nand.c,
> 
> Nor anywhere else.  As I said in the DFU + UBI thread, there's a bug
> here :)

CONFIG_SYS_DFU_MAX_FILE_SIZE is used in ./drivers/dfu/dfu_mmc.c ...

>> as if buffer is full, it is immediately flushed to nand.
>> Also default value from CONFIG_SYS_DFU_MAX_FILE_SIZE is smaller (4MiB)
>> as default value of CONFIG_SYS_DFU_DATA_BUF_SIZE (8MiB) ...
> 
> Right, and the commit that did it was about increasing the size of the
> kernel that could be sent over.

Hmm.. the CONFIG_SYS_DFU_DATA_BUF_SIZE limits not the size of
a file that could be loaded into a partition. It specifies
only the size of one chunk, that get burned into the raw nand ...

And this should be a configurable size ...

>> I used on my upcoming board port a CONFIG_SYS_DFU_DATA_BUF_SIZE from
>> 1MiB and that worked perfectly, when transferring a file > 200MB.
>> The default value from 8MiB sometimes caused an error on the host:
>>
>> []# date;dfu-util -a rootfs -D 
>> dxr2-org/dxr2.xx-release-image-UNKNOWN-dxr2.ubi;date
>> Di 28. Mai 14:20:44 CEST 2013
>> dfu-util 0.5
>> [...]
>> Copying data from PC to DFU device
>> Starting download: 
>> [#dfu_download: 
>> libusb_control_transfer returned -7
>> Error during download
>>
>> Why we have a buffersize from 8MiB for raw writes, but a max file size
>> from 4MiB only?
> 
> Then we need to poke around the code here a bit more and see what's
> going on, and fix things so that we can both do larger (say, 8MiB)
> filesystem transfers and not have dfu-util get mad sometimes.

Timeout in libusb_control_transfer while the target writes
the 8MiB into the nand ... ?

I try to find out something ...

 -#define DFU_DATA_BUF_SIZE (1024*1024*8)   /* 8 MiB */
 +#ifndef CONFIG_SYS_DFU_DATA_BUF_SIZE
 +#define CONFIG_SYS_DFU_DATA_BUF_SIZE  (1024*1024*8)   /* 8 
 MiB */
 +#endif
  #ifndef CONFIG_SYS_DFU_MAX_FILE_SIZE
  #define CONFIG_SYS_DFU_MAX_FILE_SIZE  (4 << 20)   /* 4 MiB */
  #endif
>>>
>>> We use one variable for both spots.  Or is there some case I'm missing
>>> where we need to buffer 8MiB at a time for raw writes?  In which case we
>>> still need to make CONFIG_SYS_DFU_MAX_FILE_SIZE be used :)
>>
>> I do not really know, why we have 2 defines here!
> 
> File size vs buffer size?  I'm not quite certain it was the right way to
> go either.

Yeah, but why is the file size < buffer size as default?

In dfu_mmc:
If raw partition, if dfu_buf (size of CONFIG_SYS_DFU_DATA_BUF_SIZE)
full -> write it to the mmc. Same for nand.

If FAT or EXT4 partition (mmc only), write the dfu_buffer through
mmc_file_buffer() to dfu_file_buf[CONFIG_SYS_DFU_MAX_FILE_SIZE] ...
this seems buggy to me, but maybe I oversee something, I could not
try it ... and if the hole file is transfered, the dfu_file_buf
gets flushed to the partition ...

The CONFIG_SYS_DFU_MAX_FILE_SIZE is only needed as we can only
write a complete image to FAT, EXT4 (also UBI) partitions, I think.

So we have in the dfu subsystem following problems:

a) we have no common API to add image types. Currently
   all dfu_{device_type} has to program it.
b) we have no possibility to write image types (FAT, EXT4 or
   UBI) in chunks -> CONFIG_SYS_DFU_MAX_FILE_SIZE introduced
c) CONFIG_SYS_DFU_DATA_BUF_SIZE > CONFIG_SYS_DFU_MAX_FILE_SIZE
   which is in my eyes buggy ...
d) sporadic problems with CONFIG_SYS_DFU_DATA_BUF_SIZE = 8MiB
   Currently i get always an error ... try to find out why ...

bye,
Heiko
-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2 09/12] mmc: omap_hsmmc: add mmc1 pbias, ldo1

[Tom Rini]

On Wed, Jun 05, 2013 at 11:03:26AM +0300, Lubomir Popov wrote:

> Hi Tom,
> 
> On 05/06/13 00:06, Tom Rini wrote:
> > On Mon, Jun 03, 2013 at 10:58:27PM +0300, Lubomir Popov wrote:
> >> Hi Lokesh,
> >>
> >>> Hi Lubomir,
> >>> On Thursday 30 May 2013 07:56 PM, Lubomir Popov wrote:
>  Hi Lokesh,
> 
>  On 30/05/13 16:19, Lokesh Vutla wrote:
> > From: Balaji T K 
> >
> > add dra mmc pbias support and ldo1 power on
> >
> > Signed-off-by: Balaji T K 
> > Signed-off-by: Lokesh Vutla 
> > ---
> >   arch/arm/include/asm/arch-omap5/omap.h |3 ++-
> >   drivers/mmc/omap_hsmmc.c   |   26 
> > ++
> >   drivers/power/palmas.c |   25 
> > -
> >   include/configs/omap5_common.h |4 
> >   include/configs/omap5_uevm.h   |5 -
> >   include/palmas.h   |6 +-
> >   6 files changed, 49 insertions(+), 20 deletions(-)
> >
> >> [snip]
> > +   /* set LDO9 TWL6035 to 3V */
>  LDO9? TWL6035? If this function is used on the DRA7xx boards only (with
>  TPS659038), you should add some comment above.
> >>> Ok ll add the comment.
> 
> > +   val = 0x2b; /* (3 - 0.9) * 20 + 1 */
>  Why not use definitions for the voltage? You could take them from
>  http://patchwork.ozlabs.org/patch/244103/ where some values are
>  defined.
> >>> Yes, Ill rebase this patch on top of your patch and use those defines.
> >> Please be aware that my above mentioned patch has not been reviewed/
> >> tested/acked/nacked/whatever by nobody (except possibly a quick look by
> >> Nishanth Menon, who had some objections). I wrote it when bringing up a
> >> custom OMAP5 board, and most probably it shall not go into mainline in
> >> its current form, if ever. I gave it only as an example of how things
> >> could be done cleaner. Feel free to use the code as you wish, but I'm
> >> afraid that applying it as a patch to your tree and basing upon it might
> >> run you into problems when you later sync with mainline.
> >>
> >> Tom, your opinion?
> > 
> > OK, so at the time it was "nothing will really use this code except test
> > functions".  Looks like we have a use for mmc1_ldo9 code at least, so
> > lets rework the first patch for adding that + cleanups wrt constants.
> Well, I'm not quite sure that this LDO9 function would be the only one
> used (or LDO1 on the DRA7xx board). Judging from omapboot for the OMAP5
> boards for example, SMPS7 (it delivers the common 1.8 V I/O supply) is
> set to 'Forced PWM' mode in order to reduce board noise - there sure has
> been a reason to do so and sacrifice converter efficiency. Therefore I
> added similar functionality in my patch to the Palmas driver (and am
> explicitly calling it in my board init).
> The option to bypass LDO9 on OMAP5+TWL603x boards seems quite mandatory
> as well, if hardware is designed such that the SD card socket has a
> separate fixed 3.3 V supply which also powers the LDO9 input (the
> uEVM for example). On the DRA7xx+TPS659038 board the power scheme is
> different and this does not apply.

OK, lets see.  That so lets keep your patch as-is, since we've now got
-ffunction-sections/-fdata-sections/--gc-sections on ARM for main
U-Boot, these small things won't hurt like they used to.

-- 
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] arm, arm335x: add watchdog support

[Michael Trimarchi]

Hi

On Jun 4, 2013 10:55 AM, "Heiko Schocher"  wrote:
>
> Add TI OMAP 16xx & 24xx/34xx 32KHz (non-secure) watchdog support.
>
> Signed-off-by: Heiko Schocher 
> Cc: Albert Aribaud 
> Cc: Tom Rini 
> ---
>  arch/arm/include/asm/arch-am33xx/cpu.h |  20 ++
>  drivers/watchdog/Makefile  |   1 +
>  drivers/watchdog/omap_wdt.c| 115
+
>  3 Dateien geändert, 136 Zeilen hinzugefügt(+)
>  create mode 100644 drivers/watchdog/omap_wdt.c
>
> diff --git a/arch/arm/include/asm/arch-am33xx/cpu.h
b/arch/arm/include/asm/arch-am33xx/cpu.h
> index 3d3a7c8..fb44654 100644
> --- a/arch/arm/include/asm/arch-am33xx/cpu.h
> +++ b/arch/arm/include/asm/arch-am33xx/cpu.h
> @@ -61,6 +61,26 @@
>  #define PRM_RSTCTRL_RESET  0x01
>  #define PRM_RSTST_WARM_RESET_MASK  0x232
>
> +/*
> + * Watchdog:
> + * Using the prescaler, the OMAP watchdog could go for many
> + * months before firing.  These limits work without scaling,
> + * with the 60 second default assumed by most tools and docs.
> + */
> +#define TIMER_MARGIN_MAX   (24 * 60 * 60)  /* 1 day */
> +#define TIMER_MARGIN_DEFAULT   60  /* 60 secs */
> +#define TIMER_MARGIN_MIN   1
> +
> +#define PTV0   /* prescale */
> +#define GET_WLDR_VAL(secs) (0x - ((secs) * (32768/(1< +#define WDT_WWPS_PEND_WCLR BIT(0)
> +#define WDT_WWPS_PEND_WLDR BIT(2)
> +#define WDT_WWPS_PEND_WTGR BIT(3)
> +#define WDT_WWPS_PEND_WSPR BIT(4)
> +
> +#define WDT_WCLR_PRE   BIT(5)
> +#define WDT_WCLR_PTV_OFF   2
> +
>  #ifndef __KERNEL_STRICT_NAMES
>  #ifndef __ASSEMBLY__
>  struct gpmc_cs {
> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> index d57578d..46adc42 100644
> --- a/drivers/watchdog/Makefile
> +++ b/drivers/watchdog/Makefile
> @@ -34,6 +34,7 @@ COBJS-$(CONFIG_TNETV107X_WATCHDOG) += tnetv107x_wdt.o
>  COBJS-$(CONFIG_S5P)   += s5p_wdt.o
>  COBJS-$(CONFIG_XILINX_TB_WATCHDOG) += xilinx_tb_wdt.o
>  COBJS-$(CONFIG_BFIN_WATCHDOG)  += bfin_wdt.o
> +COBJS-$(CONFIG_OMAP_WATCHDOG) += omap_wdt.o
>
>  COBJS  := $(COBJS-y)
>  SRCS   := $(COBJS:.o=.c)
> diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
> new file mode 100644
> index 000..dc4df98
> --- /dev/null
> +++ b/drivers/watchdog/omap_wdt.c
> @@ -0,0 +1,115 @@
> +/*
> + * omap_wdt.c
> + *
> + * (C) Copyright 2013
> + * Heiko Schocher, DENX Software Engineering, h...@denx.de.
> + *
> + * Based on:
> + *
> + * Watchdog driver for the TI OMAP 16xx & 24xx/34xx 32KHz (non-secure)
watchdog
> + *
> + * Author: MontaVista Software, Inc.
> + *   or 
> + *
> + * 2003 (c) MontaVista Software, Inc. This file is licensed under the
> + * terms of the GNU General Public License version 2. This program is
> + * licensed "as is" without any warranty of any kind, whether express
> + * or implied.
> + *
> + * History:
> + *
> + * 20030527: George G. Davis 
> + * Initially based on
linux-2.4.19-rmk7-pxa1/drivers/char/sa1100_wdt.c
> + * (c) Copyright 2000 Oleg Drokin 
> + * Based on SoftDog driver by Alan Cox 
> + *
> + * Copyright (c) 2004 Texas Instruments.
> + * 1. Modified to support OMAP1610 32-KHz watchdog timer
> + * 2. Ported to 2.6 kernel
> + *
> + * Copyright (c) 2005 David Brownell
> + * Use the driver model and standard identifiers; handle bigger
timeouts.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* Hardware timeout in seconds */
> +#define WDT_HW_TIMEOUT 60
> +
> +static unsigned int wdt_trgr_pattern = 0x1234;
> +
> +void hw_watchdog_reset(void)
> +{
> +   struct wd_timer *wdt = (struct wd_timer *)WDT_BASE;
> +
> +   /* wait for posted write to complete */
> +   while ((readl(&wdt->wdtwwps)) & WDT_WWPS_PEND_WTGR)
> +   ;
> +
> +   wdt_trgr_pattern = ~wdt_trgr_pattern;
> +   writel(wdt_trgr_pattern, &wdt->wdtwtgr);
> +
> +   /* wait for posted write to complete */
> +   while ((readl(&wdt->wdtwwps) & WDT_WWPS_PEND_WTGR))
> +   ;
> +}
> +

I think that this patch has some problem because watchdog reset is in getc
code. Did you try to paste very long string when it is enabled? You need to
avoid reset when it is not needed

Michael

> +static int omap_wdt_set_timeout(unsigned int timeout)
> +{
> +   struct wd_timer *wdt = (struct wd_timer *)WDT_BASE;
> +   u32 pre_margin = GET_WLDR_VAL(timeout);
> +
> +   /* just count up at 32 KHz */
> +   while (readl(&wdt->wdtwwps) & WDT_WWPS_PEND_WLDR)
> +   ;
> +
> +   writel(pre_margin, &wdt->wdtwldr);
> +   while (readl(&wdt->wdtwwps) & WDT_WWPS_PEND_WLDR)
> +   ;
> +
> +   return 0;
> +}
> +
> +void hw_watchdog_init(void)
> +{
> +   struct wd_timer *wdt = (struct wd_timer *)WDT_BASE;
> +
> +   /* initialize prescaler */
> +   while (readl(&wdt->wdtwwps) & WDT_WWPS_PEND_WCLR)
> +   ;
> +
> +   writel(WDT_WCLR_PRE | (P

Re: [U-Boot] [U-BOOT] [PATCH] arm: da830: moved pinmux configurations to the arch tree

[Tom Rini]

On Thu, May 30, 2013 at 01:25:11PM +0530, Vishwanathrao Badarkhe, Manish wrote:

> Move pinmux configurations for the DA830 SoCs from board file
> to the arch tree so that it can be used for all da830 based devices.
> Also, avoids duplicate pinmuxing in case of NAND.
> 
> Signed-off-by: Vishwanathrao Badarkhe, Manish 

Reviewed-by: Tom Rini 

-- 
Tom


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

[U-Boot] Please pull u-boot-ti/master

[Tom Rini]

Hello,

The following changes since commit 3da0e5750b24a9491058df6126c7be577a276c09:

  arm: factorize relocate_code routine (2013-05-30 20:24:38 +0200)

are available in the git repository at:

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

for you to fetch changes up to 4596dcc1d4ea5763e0f92cf5becd9fc7d4c6e674:

  am33xx/omap: Move save_omap_boot_params to omap-common/boot-common.c 
(2013-06-05 08:46:49 -0400)


Tom Rini (3):
  omap-common/hwinit-common.c: Mark omap_rev_string as static
  am33xx: Correct NON_SECURE_SRAM_START/END
  am33xx/omap: Move save_omap_boot_params to omap-common/boot-common.c

 arch/arm/cpu/armv7/omap-common/boot-common.c   |   39 
 arch/arm/cpu/armv7/omap-common/hwinit-common.c |   38 +--
 arch/arm/include/asm/arch-am33xx/omap.h|4 +--
 arch/arm/include/asm/arch-am33xx/sys_proto.h   |1 +
 arch/arm/include/asm/arch-omap4/sys_proto.h|1 +
 arch/arm/include/asm/arch-omap5/sys_proto.h|1 +
 board/isee/igep0033/board.c|9 ++
 board/phytec/pcm051/board.c|9 ++
 board/ti/am335x/board.c|9 ++
 board/ti/ti814x/evm.c  |9 ++
 include/configs/am335x_evm.h   |   10 --
 include/configs/igep0033.h |   10 --
 include/configs/pcm051.h   |   10 --
 13 files changed, 105 insertions(+), 45 deletions(-)

-- 
Tom


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

Re: [U-Boot] [u-boot] spi/arm-pl022: Add support for ARM PL022 spi controller

[Armando Visconti]

On 06/03/2013 12:10 PM, Jagan Teki wrote:

I completely lost the original thread... I will re-start from V3...

Pls discard this noisy thread,


Please check the below thread for earlier v3
http://patchwork.ozlabs.org/patch/205814/




Thx Jagan,

I have a v4 ready, where I just corrected the checkpatch errors.

Nevertheless, I failed to find your comments over the v3.
Can you possibly send to me the link to the discussion thread?

Thx,
Arm



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

[U-Boot] [PATCH v2 5/7] ac14xx: remove obsolete board config items

[Gerhard Sittig]

- use the default baudrate table for serial communication
- remove hostname/boofile/rootpath defines which were not referenced elsewhere

Signed-off-by: Gerhard Sittig 
---
 include/configs/ac14xx.h |6 --
 1 file changed, 6 deletions(-)

diff --git a/include/configs/ac14xx.h b/include/configs/ac14xx.h
index 5dbcba2..e06e9ea 100644
--- a/include/configs/ac14xx.h
+++ b/include/configs/ac14xx.h
@@ -330,8 +330,6 @@
 #endif
 
 #define CONFIG_BAUDRATE115200  /* ... at 115200 bps */
-#define CONFIG_SYS_BAUDRATE_TABLE  \
-   {300, 600, 1200, 2400, 4800, 9600, 19200, 38400, 115200}
 
 #define CONSOLE_FIFO_TX_SIZE   FIFOC_PSC3_TX_SIZE
 #define CONSOLE_FIFO_TX_ADDR   FIFOC_PSC3_TX_ADDR
@@ -496,10 +494,6 @@
 #define CONFIG_ENV_OVERWRITE
 #define CONFIG_TIMESTAMP
 
-#define CONFIG_HOSTNAMEac14xx
-#define CONFIG_BOOTFILE"ac14xx/uImage"
-#define CONFIG_ROOTPATH"/opt/eldk/ppc_6xx"
-
 /* default load addr for tftp and bootm */
 #define CONFIG_LOADADDR40
 
-- 
1.7.10.4

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

[U-Boot] [PATCH v2 7/7] ac14xx: rephrase network boot config for development

[Gerhard Sittig]

- remove the builtin 'rootpath' spec (according to U-Boot project
  policy) and require user provided environments to contain these
- rephrase the evaluation of the 'muster_nr' approach which allows to
  quickly switch among several network boot setups (make the setting
  transparent when empty, resulting in default DULG behaviour)
- reduce the ARP timeout for faster network boot

Signed-off-by: Gerhard Sittig 
---
 include/configs/ac14xx.h |   17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/include/configs/ac14xx.h b/include/configs/ac14xx.h
index fcb56f4..381bcdd 100644
--- a/include/configs/ac14xx.h
+++ b/include/configs/ac14xx.h
@@ -505,15 +505,15 @@
"echo"
 
 #define CONFIG_EXTRA_ENV_SETTINGS_DEVEL
\
-   "muster_nr=00\0"\
+   "muster_nr=-00\0"   \
"fromram=run ramargs addip addtty; "\
-   "tftp ${fdt_addr_r} ac14xx/ac14xx.dtb-${muster_nr}; "   \
-   "tftp ${kernel_addr_r} ac14xx/uImage-${muster_nr}; "\
-   "tftp ${ramdisk_addr_r} ac14xx/uFS-${muster_nr}; "  \
+   "tftp ${fdt_addr_r} ac14xx/ac14xx.dtb${muster_nr}; "\
+   "tftp ${kernel_addr_r} ac14xx/uImage${muster_nr}; " \
+   "tftp ${ramdisk_addr_r} ac14xx/uFS${muster_nr}; "   \
"bootm ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r}\0" \
"fromnfs=run nfsargs addip addtty; "\
-   "tftp ${fdt_addr_r} ac14xx/ac14xx.dtb-${muster_nr}; "   \
-   "tftp ${kernel_addr_r} ac14xx/uImage-${muster_nr}; "\
+   "tftp ${fdt_addr_r} ac14xx/ac14xx.dtb${muster_nr}; "\
+   "tftp ${kernel_addr_r} ac14xx/uImage${muster_nr}; " \
"bootm ${kernel_addr_r} - ${fdt_addr_r}\0"  \
"fromflash=run nfsargs addip addtty; "  \
"bootm fc02 - fc00\0"   \
@@ -541,12 +541,11 @@
"u-boot=ac14xx/u-boot.bin\0"\
"bootfile=ac14xx/uImage\0"  \
"fdtfile=ac14xx/ac14xx.dtb\0"   \
-   "rootpath=/opt/eldk/ppc_6xx\n"  \
"netdev=eth0\0" \
"consdev=ttyPSC0\0" \
"hostname=ac14xx\0" \
"nfsargs=setenv bootargs root=/dev/nfs rw " \
-   "nfsroot=${serverip}:${rootpath}-${muster_nr}\0"\
+   "nfsroot=${serverip}:${rootpath}${muster_nr}\0" \
"ramargs=setenv bootargs root=/dev/ram rw\0"\
"addip=setenv bootargs ${bootargs} "\
"ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}"  \
@@ -576,6 +575,8 @@
 
 #define CONFIG_BOOTCOMMAND "run production"
 
+#define CONFIG_ARP_TIMEOUT 200UL
+
 #define CONFIG_FIT 1
 #define CONFIG_OF_LIBFDT   1
 #define CONFIG_OF_BOARD_SETUP  1
-- 
1.7.10.4

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

[U-Boot] [PATCH v2 4/7] ac14xx: re-order the recovery condition checks

[Gerhard Sittig]

re-order the conditions which make the recovery system startup: combine
those conditions which were explicitly initiated (key press, software
request) and those which post-process error conditions (installer issues)

Signed-off-by: Gerhard Sittig 
---
 board/ifm/ac14xx/ac14xx.c |   12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/board/ifm/ac14xx/ac14xx.c b/board/ifm/ac14xx/ac14xx.c
index c8e88cc..dc2aff0 100644
--- a/board/ifm/ac14xx/ac14xx.c
+++ b/board/ifm/ac14xx/ac14xx.c
@@ -336,8 +336,8 @@ int misc_init_r(void)
/*
 * enforce the start of the recovery system when
 * - the appropriate keys were pressed
-* - a previous installation was aborted or has failed
 * - "some" external software told us to
+* - a previous installation was aborted or has failed
 */
want_recovery = 0;
keys = gpio_querykbd();
@@ -347,6 +347,11 @@ int misc_init_r(void)
printf("detected recovery request (keyboard)\n");
want_recovery = 1;
}
+   s = getenv("want_recovery");
+   if ((s != NULL) && (*s != '\0')) {
+   printf("detected recovery request (environment)\n");
+   want_recovery = 1;
+   }
s = getenv("install_in_progress");
if ((s != NULL) && (*s != '\0')) {
printf("previous installation has not completed\n");
@@ -357,11 +362,6 @@ int misc_init_r(void)
printf("previous installation has failed\n");
want_recovery = 1;
}
-   s = getenv("want_recovery");
-   if ((s != NULL) && (*s != '\0')) {
-   printf("detected recovery request (environment)\n");
-   want_recovery = 1;
-   }
if (want_recovery) {
printf("enforced start of the recovery system\n");
setenv("bootcmd", "run recovery");
-- 
1.7.10.4

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

[U-Boot] [PATCH v2 2/7] ac14xx: cleanup comments in the board support

[Gerhard Sittig]

fix typos, minor rephrasing, remove obsolete notes and TODO items

Signed-off-by: Gerhard Sittig 
---
 board/ifm/ac14xx/ac14xx.c |   10 ++
 include/configs/ac14xx.h  |5 ++---
 2 files changed, 4 insertions(+), 11 deletions(-)

diff --git a/board/ifm/ac14xx/ac14xx.c b/board/ifm/ac14xx/ac14xx.c
index f200b45..d45b7b2 100644
--- a/board/ifm/ac14xx/ac14xx.c
+++ b/board/ifm/ac14xx/ac14xx.c
@@ -37,7 +37,7 @@ static void gpio_configure(void)
 
/*
 * out_be32(&gpioregs->gpdir, 0xC2293020);
-* workaround for a hardware affect: configure direction in pieces,
+* workaround for a hardware effect: configure direction in pieces,
 * setting all outputs at once drops the reset line too low and
 * makes us lose the MII connection (breaks ethernet for us)
 */
@@ -330,8 +330,7 @@ int misc_init_r(void)
gpio_configure();
 
/*
-* check the GPIO keyboard,
-* enforced start of the recovery when
+* enforce the start of the recovery system when
 * - the appropriate keys were pressed
 * - a previous installation was aborted or has failed
 * - "some" external software told us to
@@ -339,13 +338,8 @@ int misc_init_r(void)
want_recovery = 0;
keys = gpio_querykbd();
printf("GPIO keyboard status [0x%08X]\n", keys);
-   /* XXX insist in the _exact_ combination? */
if ((keys & GPIOKEY_BITS_RECOVERY) == GPIOKEY_BITS_RECOVERY) {
printf("GPIO keyboard requested RECOVERY\n");
-   /* XXX TODO
-* refine the logic to detect the first keypress, and
-* wait to recheck IF it was the recovery combination?
-*/
want_recovery = 1;
}
s = getenv("install_in_progress");
diff --git a/include/configs/ac14xx.h b/include/configs/ac14xx.h
index 7cb10fb..5dbcba2 100644
--- a/include/configs/ac14xx.h
+++ b/include/configs/ac14xx.h
@@ -72,7 +72,7 @@
 #define CONFIG_SYS_MAX_RAM_SIZE0x2000
 
 /*
- * DDR Controller Configuration XXX TODO
+ * DDR Controller Configuration
  *
  * SYS_CFG:
  * [31:31] MDDRC Soft Reset:   Diabled
@@ -265,7 +265,6 @@
 
 /*
  * CS related parameters
- * TODO document these
  */
 /* CS0 Flash */
 #define CONFIG_SYS_CS0_CFG 0x00031110
@@ -506,7 +505,7 @@
 
 #define CONFIG_BOOTDELAY   2   /* -1 disables auto-boot */
 
-/* XXX TODO need to specify the builtin environment */
+/* the builtin environment and standard greeting */
 #define CONFIG_PREBOOT "echo;" \
"echo Type \\\"run flash_nfs\\\" to mount root filesystem over NFS;" \
"echo"
-- 
1.7.10.4

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

[U-Boot] [PATCH v2 6/7] ac14xx: use the official product name everywhere

[Gerhard Sittig]

remove remaining "k6" code names, switch to the official 'ac14xx' name

Signed-off-by: Gerhard Sittig 
---
 include/configs/ac14xx.h |   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/configs/ac14xx.h b/include/configs/ac14xx.h
index e06e9ea..fcb56f4 100644
--- a/include/configs/ac14xx.h
+++ b/include/configs/ac14xx.h
@@ -507,13 +507,13 @@
 #define CONFIG_EXTRA_ENV_SETTINGS_DEVEL
\
"muster_nr=00\0"\
"fromram=run ramargs addip addtty; "\
-   "tftp ${fdt_addr_r} k6m2/ac14xx.dtb-${muster_nr}; " \
-   "tftp ${kernel_addr_r} k6m2/uImage-${muster_nr}; "  \
-   "tftp ${ramdisk_addr_r} k6m2/uFS-${muster_nr}; "\
+   "tftp ${fdt_addr_r} ac14xx/ac14xx.dtb-${muster_nr}; "   \
+   "tftp ${kernel_addr_r} ac14xx/uImage-${muster_nr}; "\
+   "tftp ${ramdisk_addr_r} ac14xx/uFS-${muster_nr}; "  \
"bootm ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r}\0" \
"fromnfs=run nfsargs addip addtty; "\
-   "tftp ${fdt_addr_r} k6m2/ac14xx.dtb-${muster_nr}; " \
-   "tftp ${kernel_addr_r} k6m2/uImage-${muster_nr}; "  \
+   "tftp ${fdt_addr_r} ac14xx/ac14xx.dtb-${muster_nr}; "   \
+   "tftp ${kernel_addr_r} ac14xx/uImage-${muster_nr}; "\
"bootm ${kernel_addr_r} - ${fdt_addr_r}\0"  \
"fromflash=run nfsargs addip addtty; "  \
"bootm fc02 - fc00\0"   \
-- 
1.7.10.4

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

[U-Boot] [PATCH v2 3/7] ac14xx: minor improvement in diagnostics

[Gerhard Sittig]

- minor rewording of diagnostics output
- make diagnostics optional and off by default

Signed-off-by: Gerhard Sittig 
---
 board/ifm/ac14xx/ac14xx.c |   34 --
 1 file changed, 20 insertions(+), 14 deletions(-)

diff --git a/board/ifm/ac14xx/ac14xx.c b/board/ifm/ac14xx/ac14xx.c
index d45b7b2..c8e88cc 100644
--- a/board/ifm/ac14xx/ac14xx.c
+++ b/board/ifm/ac14xx/ac14xx.c
@@ -23,6 +23,10 @@
 #include 
 #endif
 
+static int eeprom_diag;
+static int mac_diag;
+static int gpio_diag;
+
 DECLARE_GLOBAL_DATA_PTR;
 
 static void gpio_configure(void)
@@ -126,8 +130,6 @@ static u32 gpio_querykbd(void)
 
 /* excerpt from the recovery's hw_info.h */
 
-static int eeprom_diag = 1;
-
 struct __attribute__ ((__packed__)) eeprom_layout {
charmagic[3];   /** 'ifm' */
u8  len[2]; /** content length without magic/len fields */
@@ -231,11 +233,13 @@ int mac_read_from_eeprom(void)
 
if (mac && is_valid_ether_addr(mac)) {
eth_setenv_enetaddr("ethaddr", mac);
-   mac_txt = getenv("ethaddr");
-   if (mac_txt)
-   printf("DIAG: MAC value [%s]\n", mac_txt);
-   else
-   printf("DIAG: failed to setup MAC env\n");
+   if (mac_diag) {
+   mac_txt = getenv("ethaddr");
+   if (mac_txt)
+   printf("DIAG: MAC value [%s]\n", mac_txt);
+   else
+   printf("DIAG: failed to setup MAC env\n");
+   }
}
 
return 0;
@@ -337,29 +341,31 @@ int misc_init_r(void)
 */
want_recovery = 0;
keys = gpio_querykbd();
-   printf("GPIO keyboard status [0x%08X]\n", keys);
+   if (gpio_diag)
+   printf("GPIO keyboard status [0x%02X]\n", keys);
if ((keys & GPIOKEY_BITS_RECOVERY) == GPIOKEY_BITS_RECOVERY) {
-   printf("GPIO keyboard requested RECOVERY\n");
+   printf("detected recovery request (keyboard)\n");
want_recovery = 1;
}
s = getenv("install_in_progress");
if ((s != NULL) && (*s != '\0')) {
-   printf("previous installation aborted, running RECOVERY\n");
+   printf("previous installation has not completed\n");
want_recovery = 1;
}
s = getenv("install_failed");
if ((s != NULL) && (*s != '\0')) {
-   printf("previous installation FAILED, running RECOVERY\n");
+   printf("previous installation has failed\n");
want_recovery = 1;
}
s = getenv("want_recovery");
if ((s != NULL) && (*s != '\0')) {
-   printf("running RECOVERY according to the request\n");
+   printf("detected recovery request (environment)\n");
want_recovery = 1;
}
-
-   if (want_recovery)
+   if (want_recovery) {
+   printf("enforced start of the recovery system\n");
setenv("bootcmd", "run recovery");
+   }
 
/*
 * boot the recovery system without waiting; boot the
-- 
1.7.10.4

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

[U-Boot] [PATCH v2 1/7] ac14xx: fix a potential NULL deref in diagnostics

[Gerhard Sittig]

getenv() immediately after setenv() may perfectly legally return NULL, so
make sure to not deference an invalid pointer when creating diagnostic output

Signed-off-by: Gerhard Sittig 
---
 board/ifm/ac14xx/ac14xx.c |8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/board/ifm/ac14xx/ac14xx.c b/board/ifm/ac14xx/ac14xx.c
index 7442591..f200b45 100644
--- a/board/ifm/ac14xx/ac14xx.c
+++ b/board/ifm/ac14xx/ac14xx.c
@@ -209,6 +209,7 @@ static int read_eeprom(void)
 int mac_read_from_eeprom(void)
 {
const u8 *mac;
+   const char *mac_txt;
 
if (read_eeprom()) {
printf("I2C EEPROM read failed.\n");
@@ -230,8 +231,11 @@ int mac_read_from_eeprom(void)
 
if (mac && is_valid_ether_addr(mac)) {
eth_setenv_enetaddr("ethaddr", mac);
-   printf("DIAG: %s() MAC value [%s]\n",
-   __func__, getenv("ethaddr"));
+   mac_txt = getenv("ethaddr");
+   if (mac_txt)
+   printf("DIAG: MAC value [%s]\n", mac_txt);
+   else
+   printf("DIAG: failed to setup MAC env\n");
}
 
return 0;
-- 
1.7.10.4

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

[U-Boot] [PATCH v2 0/7] cleanup in the 'ifm AC14xx' board support

[Gerhard Sittig]

this change set adjusts the configuration of the 'ifm AC14xx' board
to get closer to mainline philosophy and slightly improves builtin
diagnostics and robustness after setup failure


changes in v2:
- address a potential NULL pointer dereference in the diagnostics
  code path as well (previously unhandled in mainline)
- split the previous convoluted v1 patch into a series of
  individual patches, each addressing one specific issue,
  to aid in the review process


Gerhard Sittig (7):
  ac14xx: fix a potential NULL deref in diagnostics
  ac14xx: cleanup comments in the board support
  ac14xx: minor improvement in diagnostics
  ac14xx: re-order the recovery condition checks
  ac14xx: remove obsolete board config items
  ac14xx: use the official product name everywhere
  ac14xx: rephrase network boot config for development

 board/ifm/ac14xx/ac14xx.c |   50 -
 include/configs/ac14xx.h  |   28 ++---
 2 files changed, 38 insertions(+), 40 deletions(-)

-- 
1.7.10.4

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

Re: [U-Boot] dfu: make data buffer size configurable

[Tom Rini]

On Wed, Jun 05, 2013 at 06:53:53AM +0200, Heiko Schocher wrote:
> Hello Tom,
> 
> Am 04.06.2013 22:04, schrieb Tom Rini:
> > On Tue, Jun 04, 2013 at 11:22:54AM +0200, Heiko Schocher wrote:
> > 
> >> Dfu transfer uses a buffer before writing data to the
> >> raw storage device. Make the size (in bytes) of this buffer
> >> configurable.
> > 
> > NAK.
> 
> :-(
> 
> >> +  CONFIG_SYS_DFU_DATA_BUF_SIZE
> >> +  Dfu transfer uses a buffer before writing data to the
> >> +  raw storage device. Make the size (in bytes) of this buffer
> >> +  configurable.
> >> +
> >>CONFIG_SYS_DFU_MAX_FILE_SIZE
> >>When updating files rather than the raw storage device,
> >>we use a static buffer to copy the file into and then write
> > 
> > The point of the buffer being configurable is to allow for larger files,
> > right?  We need to fix CONFIG_SYS_DFU_MAX_FILE_SIZE so that..
> 
> In current code CONFIG_SYS_DFU_MAX_FILE_SIZE is not used in dfu_nand.c,

Nor anywhere else.  As I said in the DFU + UBI thread, there's a bug
here :)

> as if buffer is full, it is immediately flushed to nand.
> Also default value from CONFIG_SYS_DFU_MAX_FILE_SIZE is smaller (4MiB)
> as default value of CONFIG_SYS_DFU_DATA_BUF_SIZE (8MiB) ...

Right, and the commit that did it was about increasing the size of the
kernel that could be sent over.

> I used on my upcoming board port a CONFIG_SYS_DFU_DATA_BUF_SIZE from
> 1MiB and that worked perfectly, when transferring a file > 200MB.
> The default value from 8MiB sometimes caused an error on the host:
> 
> []# date;dfu-util -a rootfs -D 
> dxr2-org/dxr2.xx-release-image-UNKNOWN-dxr2.ubi;date
> Di 28. Mai 14:20:44 CEST 2013
> dfu-util 0.5
> [...]
> Copying data from PC to DFU device
> Starting download: 
> [#dfu_download: 
> libusb_control_transfer returned -7
> Error during download
> 
> Why we have a buffersize from 8MiB for raw writes, but a max file size
> from 4MiB only?

Then we need to poke around the code here a bit more and see what's
going on, and fix things so that we can both do larger (say, 8MiB)
filesystem transfers and not have dfu-util get mad sometimes.

> >> -#define DFU_DATA_BUF_SIZE (1024*1024*8)   /* 8 MiB */
> >> +#ifndef CONFIG_SYS_DFU_DATA_BUF_SIZE
> >> +#define CONFIG_SYS_DFU_DATA_BUF_SIZE  (1024*1024*8)   /* 8 
> >> MiB */
> >> +#endif
> >>  #ifndef CONFIG_SYS_DFU_MAX_FILE_SIZE
> >>  #define CONFIG_SYS_DFU_MAX_FILE_SIZE  (4 << 20)   /* 4 MiB */
> >>  #endif
> > 
> > We use one variable for both spots.  Or is there some case I'm missing
> > where we need to buffer 8MiB at a time for raw writes?  In which case we
> > still need to make CONFIG_SYS_DFU_MAX_FILE_SIZE be used :)
> 
> I do not really know, why we have 2 defines here!

File size vs buffer size?  I'm not quite certain it was the right way to
go either.

-- 
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] arm: dra7xx: Update the EXTRA_ENV_SETTINGS

[Tom Rini]

On Wed, Jun 05, 2013 at 07:27:05AM -0500, Dan Murphy wrote:
> On 06/04/2013 04:35 PM, Tom Rini wrote:
> > On Tue, Jun 04, 2013 at 10:26:06AM -0500, Dan Murphy wrote:
> >> Update the EXTRA_ENV_SETTING for the dra7xx.
> >> The console needs to be set to ttyO0 and the
> >> findfdt needs to be updated to load the
> >> dra7xx-evm.dtb file.
> >>
> >> Signed-off-by: Dan Murphy 
> >> ---
> >> v2 - Updated with side bar maintainer comments.
> >>  include/configs/omap5_common.h |   12 ++--
> >>  1 files changed, 10 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/include/configs/omap5_common.h 
> >> b/include/configs/omap5_common.h
> >> index deb5e9f..c5061dd 100644
> >> --- a/include/configs/omap5_common.h
> >> +++ b/include/configs/omap5_common.h
> >> @@ -142,9 +142,15 @@
> >>  #define PARTS_DEFAULT
> >>  #endif
> >>  
> >> +#ifdef CONFIG_DRA7XX
> >> +#define CONFIG_CONSOLE_DEV"ttyO0"
> >> +#else
> >> +#define CONFIG_CONSOLE_DEV"ttyO2"
> >> +#endif
> >> +
> >>  #define CONFIG_EXTRA_ENV_SETTINGS \
> >>"loadaddr=0x8200\0" \
> >> -  "console=ttyO2,115200n8\0" \
> >> +  "console=" CONFIG_CONSOLE_DEV ",115200n8\0" \
> > Sorry, when we chatted on IRC I was being a bit more literal than you
> > did.  I want dra7xx_evm.h to have '#define CONSOLEDEV "ttyO0"' and
> > omap5_uevm.h to have '#define CONSOLEDEV "ttyO2"' and omap5_common.h to
> > have:
> > "console=" CONSOLEDEV ",115200n8\0" \
> OK I got it.  Change a comin.
> >> @@ -174,7 +180,9 @@
> >>"bootz ${loadaddr} - ${fdtaddr}\0" \
> >>"findfdt="\
> >>"if test $board_name = omap5_uevm; then " \
> >> -  "setenv fdtfile omap5-uevm.dtb; fi;\0 " \
> >> +  "setenv fdtfile omap5-uevm.dtb; fi; " \
> >> +  "if test $board_name = dra7xx; then " \
> >> +  "setenv fdtfile dra7-evm.dtb; fi;\0 " \
> > This part is fine, thanks.  If you've got time, add something like:
> > if test -z $fdtfile; then
> >   echo "WARNING: Could not determine device tree to use"
> > fi
> >
> > After testing I got the syntax right, thanks!
> >
> 
> What does the -z do?  Could not find any info on that.

If it works, it's like regular shell scripts, and we test that the
contents are empty (so, I forgot quotes, after double checking fedora's
arm-boot-config, if test -z "$fdtfile" ...)

-- 
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] common: board_f: Do not call board_postclk_init twice

[Tom Rini]

On Tue, May 21, 2013 at 09:08:09PM -, Masahiro Yamada wrote:

> The generic-board board_init_f function called board_postclk_init twice.
> 
> The first one came from arch/arm/lib/board.c, while the second one
> from arch/powerpc/lib/board.c.
> 
> This commit deletes the first occurrence.
> In addition, the second get_clocks call is moved after
> board_postclk_init in order to keep the function call order
> both for ARM and PowerPC.
> ARM board calles get_clocks function after board_postclk_init.
> 
> Signed-off-by: Masahiro Yamada 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] input: simplify key_matrix_decode_fdt()

[Tom Rini]

On Thu, May 23, 2013 at 12:09:57PM -, Stephen Warren wrote:

> From: Stephen Warren 
> 
> We know the exact property names that the code wants to process. Look
> these up directly with fdt_get_property(), rather than iterating over
> all properties within the node, and checking each property's name, in
> a convoluted fashion, against the expected name.
> 
> Signed-off-by: Stephen Warren 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] disk: Fix possible out-of-bounds access in part_efi.c

[Tom Rini]

On Sun, May 19, 2013 at 12:53:34PM -, Marek Vasut wrote:

> Make sure to never access beyond bounds of either EFI partition name
> or DOS partition name. This situation is happening:
> 
> part.h: disk_partition_t->name is 32-byte long
> part_efi.h: gpt_entry->partition_name is 36-bytes long
> 
> The loop in part_efi.c copies over 36 bytes and thus accesses beyond
> the disk_partition_t->name .
> 
> Fix this by picking the shortest of source and destination arrays and
> make sure the destination array is cleared so the trailing bytes are
> zeroed-out and don't cause issues with string manipulation.
> 
> Signed-off-by: Marek Vasut 
> Cc: Tom Rini 
> Cc: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH v3 0/10] image: Reduce code duplication and refactor

[Tom Rini]

On Thu, May 16, 2013 at 04:53:18PM -0700, Simon Glass wrote:

> In creating a new feature[*] I found that the image code includes quite
> a bit of duplication in places. In particular the code to load a kernel,
> FDT and ramdisk is all fairly similar, but subtly different.
> 
> This series introduces a new function fit_image_load() which loads an image
> from a FIT and supports the various features. For the bootstage updates,
> these are standardised so that each file has its own range and the events
> within that range have corresponding numbers. This means that the boot
> progress numbers will change slightly with this series.
> 
> The image.c file is still very long. Rather than perpetuate the #ifdefs
> in the code I have split out the image.c code that is dependent on
> CONFIG_OF_LIBFDT into image-fdt.c.
> 
> Several architectures have their own way of setting up a ramdisk and FDT
> for booting. An attempt is made here to unify these by providing a function
> image_setup_linux() to handle the overall task, and image_setup_fdt() to set
> up the FDT.
> 
> For ARM, the bootm code is a maze of #ifdefs, which means that many boards
> compile the code differently and it takes longer to detect breakages. To get
> around this, some defines are added to ARM's bootm.h to permit the use of
> if() instead of #ifdef, making use of the compiler's dead code elimination.
> 
> Also this series introduces a very basic test of image loading using sandbox.
> Some patches add bootm support for sandbox, and also a 'sb save' command to
> save memory to a host file (used to check that the bootm actually worked).
> 
> A test program for sandbox is added as a basic sanity check of image loading
> as performed by bootm.
> 
> * The new feature is support for FIT booting on x86, available in patchwork
> starting here:
> 
> http://patchwork.ozlabs.org/patch/211526/
> 
> Changes in v3:
> - Rebase without verified boot patches
> 
> Changes in v2:
> - Add workaround for ELDK-4.2 to avoid cast warning
> - Put quotes around error when selected FIT config cannot be found
> - Correct definition of IMAGE_ENABLE_BEST_MATCH
> - Fix checkpatch checks about parenthesis alignment
> - Rebase on previous patches
> - Add workaround for ELDK-4.2 to avoid cast warning
> 
> Simon Glass (10):
>   bootstage: Introduce sub-IDs for use with image loading
>   mkimage: Add map_sysmem() and IH_ARCH_DEFAULT to simplfy building
>   image: Introduce fit_image_load() to load images from FITs
>   image: Use fit_image_load() to load ramdisk
>   image: Use fit_image_load() to load FDT
>   sandbox: Adjust bootm command to work with sandbox
>   image: Use fit_image_load() to load kernel
>   sandbox: image: Adjust FIT image printing to work with sandbox
>   bootstage: Remove unused entries related to kernel/ramdisk/fdt load
>   sandbox: image: Create a test for loading FIT images
> 
>  common/cmd_bootm.c | 170 +++-
>  common/image-fdt.c | 207 
>  common/image-fit.c | 310 +---
>  common/image.c | 122 ++
>  include/bootstage.h|  51 +++---
>  include/image.h| 105 +++-
>  test/image/test-fit.py | 422 
> +
>  tools/mkimage.h|  12 ++
>  8 files changed, 846 insertions(+), 553 deletions(-)
>  create mode 100755 test/image/test-fit.py

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] fdt: allow bootdelay to be specified via device tree

[Tom Rini]

On Tue, May 14, 2013 at 08:02:56AM -, Stephen Warren wrote:

> From: Stephen Warren 
> 
> This can be useful to force bootcmd to execute as soon as U-Boot has
> started.
> 
> My use-case is: An SoC-specific tool pushes U-Boot into RAM, along with
> an image to be written to device boot flash, with the DT config property
> "bootcmd" set to contain a command to write that image to flash. In this
> scenario, we don't want to allow any stale bootdelay value taken from
> the current flash content to affect how long it takes before the
> flashing process starts.
> 
> Signed-off-by: Stephen Warren 
> Acked-by: Simon Glass 
> Acked-by: Gerald Van Baren 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] input: fix unaligned access in key_matrix_decode_fdt()

[Tom Rini]

On Wed, May 22, 2013 at 08:48:18AM -, Stephen Warren wrote:

> From: Stephen Warren 
> 
> Initialized character arrays on the stack can cause gcc to emit code that
> performs unaligned accessess. Make the data static to avoid this.
> 
> Note that the unaligned accesses are made when copying data to prefix[] on
> the stack from .rodata. By making the data static, the copy is completely
> avoided. All explicitly written code treats the data as u8[], so will never
> cause any unaligned accesses.
> 
> Signed-off-by: Stephen Warren 
> Acked-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH v4 1/9] at91: Correct CONFIG_AUTOBOOT_PROMPT definition for pm9263

[Tom Rini]

On Wed, May 15, 2013 at 09:23:53AM -0700, Simon Glass wrote:

> This is not currently used, since autoboot is not enabled for this
> board, but the string is missing a parameter. Add it.
> 
> 
> Signed-off-by: Simon Glass 

Along with the rest of the series, applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH v2] arm: dra7xx: Update the EXTRA_ENV_SETTINGS

[Dan Murphy]

On 06/04/2013 04:35 PM, Tom Rini wrote:
> On Tue, Jun 04, 2013 at 10:26:06AM -0500, Dan Murphy wrote:
>> Update the EXTRA_ENV_SETTING for the dra7xx.
>> The console needs to be set to ttyO0 and the
>> findfdt needs to be updated to load the
>> dra7xx-evm.dtb file.
>>
>> Signed-off-by: Dan Murphy 
>> ---
>> v2 - Updated with side bar maintainer comments.
>>  include/configs/omap5_common.h |   12 ++--
>>  1 files changed, 10 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
>> index deb5e9f..c5061dd 100644
>> --- a/include/configs/omap5_common.h
>> +++ b/include/configs/omap5_common.h
>> @@ -142,9 +142,15 @@
>>  #define PARTS_DEFAULT
>>  #endif
>>  
>> +#ifdef CONFIG_DRA7XX
>> +#define CONFIG_CONSOLE_DEV  "ttyO0"
>> +#else
>> +#define CONFIG_CONSOLE_DEV  "ttyO2"
>> +#endif
>> +
>>  #define CONFIG_EXTRA_ENV_SETTINGS \
>>  "loadaddr=0x8200\0" \
>> -"console=ttyO2,115200n8\0" \
>> +"console=" CONFIG_CONSOLE_DEV ",115200n8\0" \
> Sorry, when we chatted on IRC I was being a bit more literal than you
> did.  I want dra7xx_evm.h to have '#define CONSOLEDEV "ttyO0"' and
> omap5_uevm.h to have '#define CONSOLEDEV "ttyO2"' and omap5_common.h to
> have:
> "console=" CONSOLEDEV ",115200n8\0" \
OK I got it.  Change a comin.
>> @@ -174,7 +180,9 @@
>>  "bootz ${loadaddr} - ${fdtaddr}\0" \
>>  "findfdt="\
>>  "if test $board_name = omap5_uevm; then " \
>> -"setenv fdtfile omap5-uevm.dtb; fi;\0 " \
>> +"setenv fdtfile omap5-uevm.dtb; fi; " \
>> +"if test $board_name = dra7xx; then " \
>> +"setenv fdtfile dra7-evm.dtb; fi;\0 " \
> This part is fine, thanks.  If you've got time, add something like:
> if test -z $fdtfile; then
>   echo "WARNING: Could not determine device tree to use"
> fi
>
> After testing I got the syntax right, thanks!
>

What does the -z do?  Could not find any info on that.

-- 
--
Dan Murphy

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

Re: [U-Boot] arm, arm335x: add watchdog support

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/05/2013 01:22 AM, Heiko Schocher wrote:
> Hello Tom,
> 
> Am 04.06.2013 23:24, schrieb Tom Rini:
>> On Tue, Jun 04, 2013 at 10:55:36AM +0200, Heiko Schocher wrote:
>> 
>>> Add TI OMAP 16xx & 24xx/34xx 32KHz (non-secure) watchdog 
>>> support.
>>> 
>>> Signed-off-by: Heiko Schocher  Cc: Albert Aribaud 
>>>  Cc: Tom Rini 
>> 
>> Reviewed-by: Tom Rini 
>> 
>> But this is also unused code right now.  Enabling on the 
>> am335x_evm config is a good place-holder and easy for you to
>> test I assume platform until you can also post the custom board
>> you're working on.
> 
> I repost this patch with the board support, ok?

OK, thanks.

- -- 
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRryzkAAoJENk4IS6UOR1WX0UP/jxsDh51DNxGlUEtqg03LxhR
FV4bN1yMrcFogeBacW3YIDhq0kgZ+afvxSo3yigExZt0FnWpnAUN1AD4W3fwtB4D
UyNWfmI0KIGyY0/N83hNX1ABtmdILr6eDZEf9xoNfNGh4IQZDGXgaAcgincwZ10d
HioI1cYOHRvMG/VZ4LFj7b5QrhSax2fm5dm51bq0ioII1qdfE4vV+bNgX271mPdB
hfV2XCVsB1wm7MuC1v8NdRDXUly5g2ARIcHq9smdVOiwHl94nS8KOiaM6QAcwB0R
wN/x/h6hYcDVXIrxLvVn+ZRYk96RzurywylNws4xQco7WHKISKTrsWXXmj+ecodX
DWVC1Dk+Ch/V/sJyf+1+p7ctg/PfA/P9VYqdjwrhoTrVTj+4Ds34qOwqW+cx0I+J
Eb5SbeTtjBzMoMWl9f11eJiQ7HqhR6qSijJ2HQlJgVOqMeBbpv1PKAdzRoGWVz2a
QsXUcALr1IkHzn4lKJ2qFDf+erZhTCyWOpeL4BTsqp3hSOJs1BxkRtanpZJU8tzj
9shXkwyCyzXMIxT98WmNB3+p5HaCMoQFOvebVSxTTx9jziuz8+Y9b9+xe7AAcZoU
yAA1a+DmZufkc2sygrC2XENWkEukLro1ir1ivi2sInpA6+i2iWv+YmBgdUpXZIjC
Q6zC5K0jO13kA2wmrY8P
=e8Ph
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] net, cpsw: disable gigabit support through plattform data

[Heiko Schocher]

Hello Mugunthan, Tom,

Am 04.06.2013 17:29, schrieb Mugunthan V N:
> On 6/4/2013 8:45 PM, Heiko Schocher wrote:
>> Hello Wolfgang,
>>
>> Am 04.06.2013 17:00, schrieb Wolfgang Denk:
>>> Dear Heiko,
>>>
>>> In message <1370335914-14027-1-git-send-email...@denx.de> you wrote:
 add possibility to disable gigabit support through
 plattform data. Current boards should not be affected
 through this patch.
>>> ...
 +  if (phy->speed == 1000) {
 +  if (priv->data.gigabit_en) {
 +  mac_control |= GIGABITEN;
 +  } else {
 +  /* Disable gigabit as it's non-functional */
 +  mac_control &= ~GIGABITEN;
 +  phy->speed = 100;
>>> Is this reliable?  I mean, how do we know it's a 100 Mbps connection
>>> (and not for example a 10 Mbs one) ?
> Phy speed info will be read from phy status itself for configuring
> mac ctrl reg.
>> Indeed. Anyway, I have to check, if this patch is necessary, as Tom
>> noted ...
>>
>> bye,
>> Heiko
> As Tom mentioned this patch is applicable only for initial samples
> as there was a issue with Gig mode packet transfer.
> Now there is no issue with having Gig enabled by default.

Indeed, ethernet works fine without this patch :-)

Sorry for the noise. I delete this patch in patchwork.

Thanks!

bye,
Heiko
-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Add SPI Flash STMicro's N25Q512A & add flag status check during SPI Flash write

[Jagan Teki]

On Wed, Jun 5, 2013 at 10:10 AM, Insop Song  wrote:
> Hi Jagan,
>
> Thank you for your feedback.
>
>> -Original Message-
>> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
>> Sent: Monday, June 03, 2013 10:31 PM
>> To: Insop Song
>> Cc: u-boot@lists.denx.de; york...@freescale.com
>> Subject: Re: [U-Boot] [PATCH] Add SPI Flash STMicro's N25Q512A & add flag
>> status check during SPI Flash write
>> >
>> > I've made a change and add spi_flash_cmd_wait_program to align with
>> existing code structure.
>> > Please see the patch below.
>> > Erase is okay without checking, so I didn't add the check.
>>
>> No i see without the check in erase when i erase and read back i couldn't see
>> 0xff Please check.
>
> I've tested on the N25Q512A erase without the flag check went okay.
> However, adding the check to the erase would be safe, and I've tested erase 
> with flag status check.
> Here is the diff of this change. I will use the format-patch when we finalize 
> the change.
>
> diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
> index 4240e9d..9cf5aaf 100644
> --- a/drivers/mtd/spi/spi_flash.c
> +++ b/drivers/mtd/spi/spi_flash.c
> @@ -247,6 +247,10 @@ int spi_flash_cmd_erase(struct spi_flash *flash, u32 
> offset, size_t len)
> if (ret)
> goto out;
>
> + ret = spi_flash_cmd_wait_program(flash, SPI_FLASH_PROG_TIMEOUT);
> + if (ret)
> + break;
> +
> ret = spi_flash_cmd_wait_ready(flash, 
> SPI_FLASH_PAGE_ERASE_TIMEOUT);
> if (ret)
> goto out;
>
>
>> >
>> > I am not sure I'd agree with you on that you are putting the device check 
>> > in
>> spi_flash_cmd_poll_bit().
>> > I am more inclined to make the change at the level where we call
>> spi_flash_cmd_poll_bit() if we have to distinguish per devices.
>>
>> spi_flash_cmd_poll_bit() is common call for poll for read_status, as write 
>> call
>> is common to all making changes to
>> spi_flash_cmd_poll_bit() is valid i guess.
>> Write call is a global which is used by
>> so many user, i don't like to add the flag status there and make the 
>> confusion
>> user.
>>
>
> To your comment on "confusion to users", I agree on that.
> With that argument, your patch is better since it hides the flag status check.
>
> And how about this?  can we add "flag_status_check" flag somewhere, and if 
> the device is needed then we set the flag during device discovery.
> Then call the flag check function if the flag is set.
> I think this way might be more generic then what you did in your patch.
>
> What do you think?
>
> Thank you,

Can u just send pseudo code about your logic, i couldn't get u exactly sorry.

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

Re: [U-Boot] [PATCH] video:lcd:cfb_console: cm_t35: Add CONFIG_SPLASH_SCREEN_PREPARE support to CONFIG_VIDEO

[Igor Grinberg]

Hi Robert,

On 06/04/13 21:11, Robert Winkler wrote:
> Adding Anatolij to the CC list.
> 
> On Tue, Jun 4, 2013 at 8:10 AM, Robert Winkler
>  wrote:
>> Hi Igor,
>>
>> On Mon, Jun 3, 2013 at 11:10 PM, Igor Grinberg  
>> wrote:
>>> Hi Robert,
>>>
>>> On 06/03/13 20:20, Robert Winkler wrote:
 Also change splash_screen_prepare to a weak function.
>>>
>>> You should be able to make a commit message a bit better.
>>> Also, personally, I see here two functional changes and it would be better
>>> to separate them into two patches:
>>> 1) Make the splash_screen_prepare() weak (I don't like this approach,
>>>explanation below)
>>> 2) Add CONFIG_SPLASH_SCREEN_PREPARE support to CONFIG_VIDEO
>>>
>>> We have considered making the splash_screen_prepare() function weak
>>> in the past, but decided to make it a config option instead.
>>> This way it is documented in the README and is selectable in the
>>> board config.
>>> Once you change it to be weak, there is no point in the config option
>>> anymore... Personally, I don't like this approach.
>>>
>> Wolfgang said as long as I was fixing the bug of SPLASH_SCREEN_PREPARE
>> not working
>> for CONFIG_VIDEO I should change it to a weak function so that's what I did.
>>
>> See the email here:
>> http://lists.denx.de/pipermail/u-boot/2013-May/155478.html

Ok.
The major benefit of the construct (which Wolfgang wants to remove) is
clear code with no #ifdefs inside functions.
I don't have any special feelings for that construct, but I'd like to
keep #ifdefs out of any functions (the benefit).

>>
>> I agree with you about the pointlessness of the CONFIG option and I
>> too like having
>> it documented in the README.  That's the only reason I left the
>> #ifdefs in at all because
>> I didn't want to/didn't think I should remove the CONFIG altogether.
>>
>> I'm not sure what the solution is.

...
some thoughts below...

>>
>>

 Signed-off-by: Robert Winkler 
 ---
  board/compulab/cm_t35/cm_t35.c |  2 +-
  common/lcd.c   | 10 --
  drivers/video/cfb_console.c| 14 ++
  3 files changed, 19 insertions(+), 7 deletions(-)

 diff --git a/board/compulab/cm_t35/cm_t35.c 
 b/board/compulab/cm_t35/cm_t35.c
 index b0b80e5..95098af 100644
 --- a/board/compulab/cm_t35/cm_t35.c
 +++ b/board/compulab/cm_t35/cm_t35.c
 @@ -120,7 +120,7 @@ static inline int splash_load_from_nand(void)
  }
  #endif /* CONFIG_CMD_NAND */

 -int board_splash_screen_prepare(void)
 +int splash_screen_prepare(void)
  {
   char *env_splashimage_value;
   u32 bmp_load_addr;
 diff --git a/common/lcd.c b/common/lcd.c
 index edae835..90f1143 100644
 --- a/common/lcd.c
 +++ b/common/lcd.c
 @@ -1069,15 +1069,13 @@ int lcd_display_bitmap(ulong bmp_image, int x, int 
 y)
  #endif

  #ifdef CONFIG_SPLASH_SCREEN_PREPARE
 -static inline int splash_screen_prepare(void)
 -{
 - return board_splash_screen_prepare();
 -}
 -#else
 -static inline int splash_screen_prepare(void)
 +int __splash_screen_prepare(void)
  {
   return 0;
  }
 +
 +int splash_screen_prepare(void)
 + __attribute__ ((weak, alias("__splash_screen_prepare")));
  #endif
>>>
>>> You remove the #else statement, apparently you break the compilation for
>>> !CONFIG_SPLASH_SCREEN_PREPARE, as the below lcd_logo() function references
>>> the splash_screen_prepare() function.
>>> Also, this means you force the code to have the ugly #ifdefs inside
>>> functions - that is not really nice.
>>>

  static void *lcd_logo(void)
 diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c
 index 0793f07..9180998 100644
 --- a/drivers/video/cfb_console.c
 +++ b/drivers/video/cfb_console.c
 @@ -1966,6 +1966,16 @@ static void plot_logo_or_black(void *screen, int 
 width, int x, int y, int black)
  #endif
  }

 +#ifdef CONFIG_SPLASH_SCREEN_PREPARE
 +int __splash_screen_prepare(void)
 +{
 + return 0;
 +}
 +
 +int splash_screen_prepare(void)
 + __attribute__ ((weak, alias("__splash_screen_prepare")));
 +#endif
>>>
>>> Why duplicate the above?
>>> Probably, just place it in a common location?
>> I asked Wolfgang about this in the original thread but haven't heard
>> back so I just submitted it
>> like this with the thought that CONFIG_VIDEO and CONFIG_LCD are never
>> used simultaneously and are
>> designed not to be (I could easily be wrong about that).
>>
>>>
 +
  static void *video_logo(void)
  {
   char info[128];
 @@ -1996,6 +2006,10 @@ static void *video_logo(void)
   s = getenv("splashimage");
   if (s != NULL) {

 +#ifdef CONFIG_SPLASH_SCREEN_PREPARE
 + splash_screen_prepare();
 +#endif
>>>
>>> These are the ugly #ifdefs, I was talking about...
>> Agreed
>>>
>>> I would recommend

Re: [U-Boot] [PATCH V2 09/12] mmc: omap_hsmmc: add mmc1 pbias, ldo1

[Lubomir Popov]

Hi Tom,

On 05/06/13 00:06, Tom Rini wrote:
> On Mon, Jun 03, 2013 at 10:58:27PM +0300, Lubomir Popov wrote:
>> Hi Lokesh,
>>
>>> Hi Lubomir,
>>> On Thursday 30 May 2013 07:56 PM, Lubomir Popov wrote:
 Hi Lokesh,

 On 30/05/13 16:19, Lokesh Vutla wrote:
> From: Balaji T K 
>
> add dra mmc pbias support and ldo1 power on
>
> Signed-off-by: Balaji T K 
> Signed-off-by: Lokesh Vutla 
> ---
>   arch/arm/include/asm/arch-omap5/omap.h |3 ++-
>   drivers/mmc/omap_hsmmc.c   |   26 ++
>   drivers/power/palmas.c |   25 -
>   include/configs/omap5_common.h |4 
>   include/configs/omap5_uevm.h   |5 -
>   include/palmas.h   |6 +-
>   6 files changed, 49 insertions(+), 20 deletions(-)
>
>> [snip]
> + /* set LDO9 TWL6035 to 3V */
 LDO9? TWL6035? If this function is used on the DRA7xx boards only (with
 TPS659038), you should add some comment above.
>>> Ok ll add the comment.

> + val = 0x2b; /* (3 - 0.9) * 20 + 1 */
 Why not use definitions for the voltage? You could take them from
 http://patchwork.ozlabs.org/patch/244103/ where some values are
 defined.
>>> Yes, Ill rebase this patch on top of your patch and use those defines.
>> Please be aware that my above mentioned patch has not been reviewed/
>> tested/acked/nacked/whatever by nobody (except possibly a quick look by
>> Nishanth Menon, who had some objections). I wrote it when bringing up a
>> custom OMAP5 board, and most probably it shall not go into mainline in
>> its current form, if ever. I gave it only as an example of how things
>> could be done cleaner. Feel free to use the code as you wish, but I'm
>> afraid that applying it as a patch to your tree and basing upon it might
>> run you into problems when you later sync with mainline.
>>
>> Tom, your opinion?
> 
> OK, so at the time it was "nothing will really use this code except test
> functions".  Looks like we have a use for mmc1_ldo9 code at least, so
> lets rework the first patch for adding that + cleanups wrt constants.
Well, I'm not quite sure that this LDO9 function would be the only one
used (or LDO1 on the DRA7xx board). Judging from omapboot for the OMAP5
boards for example, SMPS7 (it delivers the common 1.8 V I/O supply) is
set to 'Forced PWM' mode in order to reduce board noise - there sure has
been a reason to do so and sacrifice converter efficiency. Therefore I
added similar functionality in my patch to the Palmas driver (and am
explicitly calling it in my board init).
The option to bypass LDO9 on OMAP5+TWL603x boards seems quite mandatory
as well, if hardware is designed such that the SD card socket has a
separate fixed 3.3 V supply which also powers the LDO9 input (the
uEVM for example). On the DRA7xx+TPS659038 board the power scheme is
different and this does not apply.

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

[U-Boot] [PATCH 1/1 RESEND] NET: Fix system hanging if NET device is not installed

[Jim Lin]

If we try to boot from NET device, NetInitLoop in net.c will be invoked.
If NET device is not installed, eth_get_dev() function will return
eth_current value, which is NULL.
When NetInitLoop is called, "eth_get_dev->enetaddr" will access
restricted memory area and therefore cause hanging.
This issue is found on Tegra30 Cardhu platform after adding
CONFIG_CMD_NET and CONFIG_CMD_DHCP in config header file.

Signed-off-by: Jim Lin 
---
 net/net.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/net/net.c b/net/net.c
index df94789..7663b9c 100644
--- a/net/net.c
+++ b/net/net.c
@@ -271,7 +271,8 @@ static void NetInitLoop(void)
 #endif
env_changed_id = env_id;
}
-   memcpy(NetOurEther, eth_get_dev()->enetaddr, 6);
+   if (eth_get_dev())
+   memcpy(NetOurEther, eth_get_dev()->enetaddr, 6);
 
return;
 }
-- 
1.7.7

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