[U-Boot] [PATCH 2/3] sf: change indentation in

[Bo Shen]

Signed-off-by: Bo Shen 
---
 drivers/mtd/spi/sf_probe.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c
index 6e19d79..9646914 100644
--- a/drivers/mtd/spi/sf_probe.c
+++ b/drivers/mtd/spi/sf_probe.c
@@ -25,7 +25,7 @@ DECLARE_GLOBAL_DATA_PTR;
  * @jedec: Device jedec ID (0x[1byte_manuf_id][2byte_dev_id])
  * @ext_jedec: Device ext_jedec ID
  * @sector_size:   Sector size of this device
- * @nr_sectors:No.of sectors on this device
+ * @nr_sectors:No.of sectors on this device
  * @flags: Importent param, for flash specific behaviour
  */
 struct spi_flash_params {
-- 
1.7.9.5

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

[U-Boot] [PATCH 3/3] sf: using the same license header format

[Bo Shen]

Signed-off-by: Bo Shen 

---
 drivers/mtd/spi/sf_probe.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c
index 9646914..2086022 100644
--- a/drivers/mtd/spi/sf_probe.c
+++ b/drivers/mtd/spi/sf_probe.c
@@ -5,7 +5,7 @@
  * Copyright (C) 2010 Reinhard Meyer, EMK Elektronik
  * Copyright (C) 2013 Jagannadha Sutradharudu Teki, Xilinx Inc.
  *
- * Licensed under the GPL-2 or later.
+ * SPDX-License-Identifier:GPL-2.0+
  */
 
 #include 
-- 
1.7.9.5

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

[U-Boot] [PATCH 1/3] sf: add missing Atmel at25df321 spi flash support

[Bo Shen]

As the spi flash transfer to multiple parts, it is forgot to add
Atmel AT25DF321 spi flash support, which broken several Atmel EK
boards which this chip. So, add it

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

diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c
index 4251b1b..6e19d79 100644
--- a/drivers/mtd/spi/sf_probe.c
+++ b/drivers/mtd/spi/sf_probe.c
@@ -46,6 +46,7 @@ static const struct spi_flash_params spi_flash_params_table[] 
= {
{"AT45DB161D", 0x1f2600, 0x0,   64 * 1024,32,  
SECT_4K},
{"AT45DB321D", 0x1f2700, 0x0,   64 * 1024,64,  
SECT_4K},
{"AT45DB641D", 0x1f2800, 0x0,   64 * 1024,   128,  
SECT_4K},
+   {"AT25DF321",  0x1f4701, 0x0,   64 * 1024,64,  
SECT_4K},
 #endif
 #ifdef CONFIG_SPI_FLASH_EON/* EON */
{"EN25Q32B",   0x1c3016, 0x0,   64 * 1024,64,   
 0},
-- 
1.7.9.5

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

Re: [U-Boot] problems porting to 2013.x

[Chris Ruehl]

Hi Chris,

On Wed, Oct 9, 2013 at 2:34 AM, Chris Ruehl  wrote:

Hi.

I hope someone can open my eyes on this. We try to port our MX27 board to
the new u-boot loader using the SPL code rather then the self hacked
NAND->SDRAM.

I'm not able to get anything run. The console stays dead.


I would suggest you to look to an existing mx27 supported in mainline,
like Armadeus' ap27 for example:

http://git.denx.de/?p=u-boot.git;a=commitdiff;h=bcc05c7aeb5507125b463fca3c98679d9c483919;hp=a8f2d0e6757c8f5391113582d8fecad29dc8cedc

Regards,

Fabio Estevam


Hi,

I had a quick look and many things match.. I think I have to spend a couple of 
days for study more details.


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

Re: [U-Boot] problems porting to 2013.x

[Fabio Estevam]

Hi Chris,

On Wed, Oct 9, 2013 at 2:34 AM, Chris Ruehl  wrote:
> Hi.
>
> I hope someone can open my eyes on this. We try to port our MX27 board to
> the new u-boot loader using the SPL code rather then the self hacked
> NAND->SDRAM.
>
> I'm not able to get anything run. The console stays dead.

I would suggest you to look to an existing mx27 supported in mainline,
like Armadeus' ap27 for example:

http://git.denx.de/?p=u-boot.git;a=commitdiff;h=bcc05c7aeb5507125b463fca3c98679d9c483919;hp=a8f2d0e6757c8f5391113582d8fecad29dc8cedc

Regards,

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

Re: [U-Boot] problems porting to 2013.x

[Chris Ruehl]

On Wednesday, October 09, 2013 02:29 PM, Chris Ruehl wrote:

On Wednesday, October 09, 2013 01:34 PM, Chris Ruehl wrote:

Hi.

I hope someone can open my eyes on this. We try to port our MX27 board
to the new u-boot loader using the SPL code rather then the self hacked
NAND->SDRAM.

I'm not able to get anything run. The console stays dead.

Let start here:
To see if the second image is booting I tried to load the image using
TFTP and memcpy/memcmp it to the TEXT_BASE (0xa780) and go. The
u-boot-v2 is loaded at 0xa7f0.

U-Boot 2.0.0-rc9-00188-geb5172d-dirty (Mar 24 2011 - 12:59:07)
Board: MX27
NAND device: Manufacturer ID: 0xec, Chip ID: 0xf1 (Samsung NAND 128MiB
3,3V 8-bit)
Scanning device for bad blocks
Bad eraseblock 592 at 0x04a0
dm9000 i/o: 0xd400, id: 0x9a46
got MAC address from EEPROM: 00:00:00:00:00:00
Using environment in NAND Flash
chip id: [2,882,1,01d]
mpll: 398999390 Hz
spll: 23725 Hz
arm: 265999593 Hz
perclk1: 66499898 Hz
perclk2: 66499898 Hz
perclk3: 66499898 Hz
perclk4: 66499898 Hz
clkin26: 2600 Hz
ahb: 132999796 Hz
ipg: 66499898 Hz
Malloc space: 0xa6f0 -> 0xa7f0 (size 16 MB)
Stack space : 0xa6ef8000 -> 0xa6f0 (size 32 kB)
running /env/bin/init...

uboot:/ tftp u-boot.bin /dev/ram0
phy0: Link is up - 100/Full
TFTP from server 10.128.2.105; our IP address is 10.128.2.10
Filename 'u-boot.bin'.
Loading: ##
done
Bytes transferred = 211308 (3396c hex)
uboot:/ memcpy -s /dev/ram0 0 0xa780 211308
uboot:/ memcmp -s /dev/ram0 0 0xa780 211308
OK
uboot:/ go 0xa780
## Starting application at 0xA780 ...

System.map
a780 T __image_copy_start
a780 T _start
a7800020 t _undefined_instruction
a7800024 t _software_interrupt
a7800028 t _prefetch_abort
a780002c t _data_abort
a7800030 t _not_used
a7800034 t _irq
a7800038 t _fiq
...


Any Idea?

Chris



More info:
I'd compiled the hello_world
make[1]: Entering directory
`/opt/cross_build/uboot.d/u-boot-git/examples/standalone'
arm-linux-gnueabihf-gcc -g -Os -ffunction-sections -fdata-sections
-fno-common -ffixed-r8 -msoft-float -D__KERNEL__
-DCONFIG_SYS_TEXT_BASE=0xa780 -DCONFIG_SPL_TEXT_BASE=0xa740
-DCONFIG_SPL_PAD_TO=5632 -I/opt/cross_build/uboot.d/u-boot-git/include
-fno-builtin -ffreestanding -nostdinc -isystem
/opt/armhf/gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/bin/../lib/gcc/arm-linux-gnueabihf/4.8.2/include
-pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork
-mabi=aapcs-linux -march=armv5te -Wall -Wstrict-prototypes
-fno-stack-protector -Wno-format-nonliteral -Wno-format-security
-fstack-usage -fno-toplevel-reorder -o hello_world.o hello_world.c -c
arm-linux-gnueabihf-gcc -g -Os -ffunction-sections -fdata-sections
-fno-common -ffixed-r8 -msoft-float -D__KERNEL__
-DCONFIG_SYS_TEXT_BASE=0xa780 -DCONFIG_SPL_TEXT_BASE=0xa740
-DCONFIG_SPL_PAD_TO=5632 -I/opt/cross_build/uboot.d/u-boot-git/include
-fno-builtin -ffreestanding -nostdinc -isystem
/opt/armhf/gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/bin/../lib/gcc/arm-linux-gnueabihf/4.8.2/include
-pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork
-mabi=aapcs-linux -march=armv5te -Wall -Wstrict-prototypes
-fno-stack-protector -Wno-format-nonliteral -Wno-format-security
-fstack-usage -fno-toplevel-reorder -o stubs.o stubs.c -c
arm-linux-gnueabihf-ld.bfd -r -o libstubs.o stubs.o
arm-linux-gnueabihf-ld.bfd -g -Ttext 0xa000 \
-o hello_world -e hello_world hello_world.o libstubs.o \
-L/opt/armhf/gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/bin/../lib/gcc/arm-linux-gnueabihf/4.8.2
-lgcc
arm-linux-gnueabihf-objcopy -O srec hello_world hello_world.srec
2>/dev/null
arm-linux-gnueabihf-objcopy -O binary hello_world hello_world.bin
2>/dev/null


same, its not working

uboot:/ tftp hello_world.bin
phy0: Link is up - 100/Full
TFTP from server 10.128.2.105; our IP address is 10.128.2.10
Filename 'hello_world.bin'.
Loading: #
done
Bytes transferred = 590 (24e hex)
uboot:/ go hello_world.bin
memmap: Invalid argument
uboot:/ cp hello_world.bin /dev/ram0
uboot:/ go /dev/ram0
## Starting application at 0xA000 ...


Thanks for any hint.
Chris


Hi,

while I study the nand_spl.c jump to the mxc_nand_spl.c the page count is 
calculated ( page = from / CONFIG_SYS_NAND_PAGE_SIZE ) where from is the

CONFIG_SYS_NAND_U_BOOT_OFFS

that means:
#define CONFIG_SPL_PAD_TO 6144  /* must match CONFIG_SYS_NAND_PAGE_SIZE 
boundery */
#define CONFIG_SYS_NAND_U_BOOT_OFFS CONFIG_SPL_PAD_TO

or some funny things happen to the u-boot.bin image in ram ..

comments welcome.

Chris

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

[U-Boot] FW: [PATCH v3] PCIe:change the method to get the address of a requested capability in configuration space.

[Zhao Qiang-B45475]

Hi Tom,

Please keep an eye on this patch 
http://patchwork.ozlabs.org/patch/275173/

Regards
Zhao Qiang

> -Original Message-
> From: Zhao Qiang-B45475
> Sent: Monday, September 30, 2013 11:10 AM
> To: 'tr...@ti.com'
> Cc: u-boot@lists.denx.de
> Subject: RE: [PATCH v3] PCIe:change the method to get the address of a
> requested capability in configuration space.
> 
> Hi Tom,
> 
> I'd like you to pay attention on this patch
> http://patchwork.ozlabs.org/patch/275173/
> 
> Regards
> Zhao Qiang
> 
> > -Original Message-
> > From: Zhao Qiang-B45475
> > Sent: Monday, September 16, 2013 5:28 PM
> > To: u-boot@lists.denx.de
> > Cc: Zhao Qiang-B45475
> > Subject: [PATCH v3] PCIe:change the method to get the address of a
> > requested capability in configuration space.
> >
> > Previously, the address of a requested capability is define like that
> > "#define PCI_DCR0x78"
> > But, the addresses of capabilities is different with regard to PCIe
> revs.
> > So this method is not flexible.
> >
> > Now a function to get the address of a requested capability is added
> > and used.
> > It can get the address dynamically by capability ID.
> > The step of this function:
> > 1. Read Status register in PCIe configuration space to confirm that
> >Capabilities List is valid.
> > 2. Find the address of Capabilities Pointer Register.
> > 3. Find the address of requested capability from the first
> > capability.
> >
> > Signed-off-by: Zhao Qiang 
> > ---
> > Changes for v2:
> > -Put an variable into "#ifdef" and "#endif"
> > Changes for v3:
> > -Modify the patch description
> >
> >
> >  arch/powerpc/include/asm/fsl_pci.h | 13 +---
> >  drivers/pci/fsl_pci_init.c | 44 +++---
> >  drivers/pci/pci.c  | 65
> > ++
> >  include/pci.h  | 10 ++
> >  4 files changed, 108 insertions(+), 24 deletions(-)
> >
> > diff --git a/arch/powerpc/include/asm/fsl_pci.h
> > b/arch/powerpc/include/asm/fsl_pci.h
> > index 90b0a2f..6b12afa 100644
> > --- a/arch/powerpc/include/asm/fsl_pci.h
> > +++ b/arch/powerpc/include/asm/fsl_pci.h
> > @@ -32,22 +32,11 @@
> >  /* Freescale-specific PCI config registers */
> >  #define FSL_PCI_PBFR   0x44
> >
> > -#ifdef CONFIG_SYS_FSL_PCI_VER_3_X
> > +#ifndef CONFIG_SYS_FSL_PCI_VER_3_X
> >  /* Currently only the PCIe capability is used, so hardcode the offset.
> >   * if more capabilities need to be justified, the capability link
> method
> >   * should be applied here
> >   */
> > -#define FSL_PCIE_CAP_ID0x70
> > -#define PCI_DCR0x78/* PCIe Device Control Register */
> > -#define PCI_DSR0x7a/* PCIe Device Status Register */
> > -#define PCI_LSR0x82/* PCIe Link Status Register */
> > -#define PCI_LCR0x80/* PCIe Link Control Register */
> > -#else
> > -#define FSL_PCIE_CAP_ID0x4c
> > -#define PCI_DCR0x54/* PCIe Device Control Register */
> > -#define PCI_DSR0x56/* PCIe Device Status Register */
> > -#define PCI_LSR0x5e/* PCIe Link Status Register */
> > -#define PCI_LCR0x5c/* PCIe Link Control Register */
> >  #define FSL_PCIE_CFG_RDY   0x4b0
> >  #endif
> >  #define FSL_PCI_CFG_READY  1 /* Endpoint: allow inbound configuration
> > */
> > diff --git a/drivers/pci/fsl_pci_init.c b/drivers/pci/fsl_pci_init.c
> > index 76337fe..492efcf 100644
> > --- a/drivers/pci/fsl_pci_init.c
> > +++ b/drivers/pci/fsl_pci_init.c
> > @@ -308,6 +308,15 @@ void fsl_pci_init(struct pci_controller *hose,
> > struct fsl_pci_info *pci_info)
> > int enabled, r, inbound = 0;
> > u16 ltssm;
> > u8 temp8, pcie_cap;
> > +   int pcie_cap_pos;
> > +   int pci_dcr;
> > +   int pci_dsr;
> > +   int pci_lsr;
> > +
> > +#if defined(CONFIG_FSL_PCIE_DISABLE_ASPM)
> > +   int pci_lcr;
> > +#endif
> > +
> > volatile ccsr_fsl_pci_t *pci = (ccsr_fsl_pci_t *)cfg_addr;
> > struct pci_region *reg = hose->regions + hose->region_count;
> > pci_dev_t dev = PCI_BDF(hose->first_busno, 0, 0); @@ -380,7 +389,12
> > @@ void fsl_pci_init(struct pci_controller *hose, struct fsl_pci_info
> > *pci_info)
> > hose->region_count++;
> >
> > /* see if we are a PCIe or PCI controller */
> > -   pci_hose_read_config_byte(hose, dev, FSL_PCIE_CAP_ID, &pcie_cap);
> > +   pcie_cap_pos = pci_hose_find_capability(hose, dev, PCI_CAP_ID_EXP);
> > +   pci_dcr = pcie_cap_pos + 0x08;
> > +   pci_dsr = pcie_cap_pos + 0x0a;
> > +   pci_lsr = pcie_cap_pos + 0x12;
> > +
> > +   pci_hose_read_config_byte(hose, dev, pcie_cap_pos, &pcie_cap);
> >
> >  #ifdef CONFIG_SRIO_PCIE_BOOT_MASTER
> > /* boot from PCIE --master */
> > @@ -419,15 +433,16 @@ void fsl_pci_init(struct pci_controller *hose,
> > struct fsl_pci_info *pci_info)
> >  * - Master PERR (pci)
> >  * - ICCA

Re: [U-Boot] FW: [PATCH v3] PCIe:change the method to get the address of a requested capability in configuration space.

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/09/2013 09:39 PM, Zhao Qiang-B45475 wrote:
> Hi Tom,
> 
>   Please keep an eye on this patch 
> http://patchwork.ozlabs.org/patch/275173/
> 
> Regards
> Zhao Qiang
> 
>> -Original Message-
>> From: Zhao Qiang-B45475
>> Sent: Monday, September 30, 2013 11:10 AM
>> To: 'tr...@ti.com'
>> Cc: u-boot@lists.denx.de
>> Subject: RE: [PATCH v3] PCIe:change the method to get the address of a
>> requested capability in configuration space.
>>
>> Hi Tom,
>>
>> I'd like you to pay attention on this patch
>> http://patchwork.ozlabs.org/patch/275173/
[snip]

York?  I'd like this to come via your tree, thanks!

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

iQIcBAEBAgAGBQJSVgeNAAoJENk4IS6UOR1WyxcQALGTZ8XBpVETKf19YVx8Fy6h
IuWj7xqr3PkvVZ678egLGVXe+PYL6ODXolNZ8xvV0aqGFrshh7RRXNp2U4cTv0nx
xZOIssFXNTdJBqX3lznHCh9D3ygG36rqy5E0lZhbvsUtPh2bpD3+mt0SC8I+srzF
aAeG1mIi4Lq4VbG19G1eVujltC4BuLTQGd5zGYdjIwY4ipvxEudmYF6cojiRmFPU
oFkL6VEf/9NPXlgH0wXYgR6YBaUIlsJH4EYEku5L102XNy9tRloQvzYaTYMM5MLT
GrlyAzyRn1WoU6+NyBXZrmCUGHo7yS24OPq20NpCpCuJ0BBnNanoTspiPFI4yuBr
Q0Dabx+bTqiLRYJcNtgnlIqZR1o38kSazzzI5FRSY5TVCOV9cxQEs4QHa0jTw3re
+/NGwnx1s4mAfDmorQkfytwgqxSaNKmml4wq/loWnfHT7LhhmvgSqGopHE2Yp1y3
aNp+GqQTSdZDOhZ4ZMyTtMn0tpO0wDDenHUESr005hBnpQGFdDkCDg6WxmqlJf3C
CaJAYFJ4gWIZhabgGU7CwCp1qFNzHHEInwijDSqsG4AiH83BuYZI4DTMF8Qtdlwz
cCB+lb56pOXd4BCRJ9t1HgGS9ah9GUR4uCs7KuCaMEfYbIQV/l8GjK5FkM7kQ3PZ
6EKpH3McO0Jb3okWez3h
=W2Hw
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] please pull u-boot-samsung master

[Minkyu Kang]

Dear Albert,

The following changes since commit 12eba1b49380988fd87cc0b3af44014cca8b71c4:

  README: update ARM register usage (2013-09-23 18:00:36 +0200)

are available in the git repository at:

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

for you to fetch changes up to 4d6c96711bd550ae292df566c2b36ff3e3dac24c:

  samsung: trats2: add support for new board Trats2 (2013-09-25 10:52:33 +0900)


Piotr Wilczek (4):
  drivers:power:max77693: add support for new multi function pmic max77693
  power:battery: add battery support for Trats2 board
  samsung:common:i2c: add definions for third soft I2C adapter for Trats2 
board
  samsung: trats2: add support for new board Trats2

 Makefile   |1 +
 board/samsung/common/multi_i2c.c   |   12 +
 board/samsung/trats2/Makefile  |   34 +++
 board/samsung/trats2/trats2.c  |  513 
 boards.cfg |1 +
 drivers/power/battery/Makefile |1 +
 drivers/power/battery/bat_trats2.c |   65 +
 drivers/power/mfd/Makefile |   33 +++
 drivers/power/mfd/fg_max77693.c|  139 ++
 drivers/power/mfd/muic_max77693.c  |   77 ++
 drivers/power/mfd/pmic_max77693.c  |   96 +++
 include/configs/trats2.h   |  311 ++
 include/power/max77693_fg.h|   49 
 include/power/max77693_muic.h  |   74 ++
 include/power/max77693_pmic.h  |   43 +++
 15 files changed, 1449 insertions(+)
 create mode 100644 board/samsung/trats2/Makefile
 create mode 100644 board/samsung/trats2/trats2.c
 create mode 100644 drivers/power/battery/bat_trats2.c
 create mode 100644 drivers/power/mfd/Makefile
 create mode 100644 drivers/power/mfd/fg_max77693.c
 create mode 100644 drivers/power/mfd/muic_max77693.c
 create mode 100644 drivers/power/mfd/pmic_max77693.c
 create mode 100644 include/configs/trats2.h
 create mode 100644 include/power/max77693_fg.h
 create mode 100644 include/power/max77693_muic.h
 create mode 100644 include/power/max77693_pmic.h
-- 
Thanks,
Minkyu Kang.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Pull request: nand flash

[Tom Rini]

On Wed, Oct 09, 2013 at 01:29:55PM -0500, Scott Wood wrote:

> Sorry for the lateness, but here are some MTD/UBI bugfixes.  They've
> been acked by Stefan Roese.
> 
> The following changes since commit b770e88a6c2548727f0d57a3e9e8bb0830f977b5:
> 
>   Fix number base handling of "load" command (2013-10-07 15:54:18 -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-nand-flash.git master
> 
> for you to fetch changes up to cc734f5ab26134e5e8d57c34edc257c89ac5b1d2:
> 
>   cmd_ubi: add write.part command, to write a volume in multiple parts 
> (2013-10-09 12:52:22 -0500)
> 
> 
> Paul Burton (4):
>   mtd: driver _read() returns max_bitflips; mtd_read() returns -EUCLEAN
>   cmd_mtdparts: use 64 bits for flash size, partition size & offset
>   cmd_ubi: use int64_t volume size for 'ubi create'
>   cmd_ubi: add write.part command, to write a volume in multiple parts

OK, problem:
Author: Paul Burton 
Date:   Wed Sep 4 15:16:57 2013 +0100

cmd_mtdparts: use 64 bits for flash size, partition size & offset

Causes a number of platform such as am3517_crane to fail to build with
recent toolchains with errors such as:
/opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.7-2013.03-20130313_linux/bin/arm-linux-gnueabihf-ld.bfd:
error:
/opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.7-2013.03-20130313_linux/bin/../lib/gcc/arm-linux-gnueabihf/4.7.3/libgcc.a(bpabi.o)
uses VFP register arguments, u-boot does not

Which we need to sort out, one way or another.  Albert, any quick ideas?

-- 
Tom


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

[U-Boot] [Patch v1 1/1] jffs2: change U_BOOT_CMD ls to fsls

[Suriyan Ramasami]

multiple definitions of `_u_boot_list_2_cmd_2_ls' if CONFIG_CMD_JFFS2
and CONFIG_CMD_FS_GENERIC are defined.

Signed-off-by: Suriyan Ramasami 
---
 common/cmd_jffs2.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/common/cmd_jffs2.c b/common/cmd_jffs2.c
index bce0983..f38455f 100644
--- a/common/cmd_jffs2.c
+++ b/common/cmd_jffs2.c
@@ -606,7 +606,7 @@ U_BOOT_CMD(
"  with offset 'off'"
 );
 U_BOOT_CMD(
-   ls, 2,  1,  do_jffs2_ls,
+   fsls,   2,  1,  do_jffs2_ls,
"list files in a directory (default /)",
"[ directory ]"
 );
-- 
1.7.1

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

Re: [U-Boot] [Patch v1 1/1] usb:smsx95xx LED activity for USB net driver

[Joe Hershberger]

On Oct 9, 2013, at 6:39 PM, Marek Vasut  wrote:

> Dear Simon Glass,
> 
>> +Joe (net maintainer)
>> +Marek (USB)
>> 
>> Hi Suriyan,
>> 
>> On Mon, Oct 7, 2013 at 9:30 PM, Suriyan Ramasami wrote:
>>> Add LED activity for SMSX95XX USB Ether driver.
>>> 
>>> Signed-off-by: “Suriyan Ramasami" 
>>> ---
>>> 
>>> drivers/usb/eth/smsc95xx.c |   14 ++
>>> 1 files changed, 14 insertions(+), 0 deletions(-)
>>> 
>>> diff --git a/drivers/usb/eth/smsc95xx.c b/drivers/usb/eth/smsc95xx.c
>>> index 15fd9a9..7bf0a34 100644
>>> --- a/drivers/usb/eth/smsc95xx.c
>>> +++ b/drivers/usb/eth/smsc95xx.c
>>> @@ -14,6 +14,12 @@
>>> 
>>> /* SMSC LAN95xx based USB 2.0 Ethernet Devices */
>>> 
>>> +/* LED defines */
>>> +#define LED_GPIO_CFG   (0x24)
>>> +#define LED_GPIO_CFG_SPD_LED   (0x0100)
>>> +#define LED_GPIO_CFG_LNK_LED   (0x0010)
>>> +#define LED_GPIO_CFG_FDX_LED   (0x0001)
>>> +
>>> 
>>> /* Tx command words */
>>> #define TX_CMD_A_FIRST_SEG_0x2000
>>> #define TX_CMD_A_LAST_SEG_ 0x1000
>>> 
>>> @@ -591,6 +597,14 @@ static int smsc95xx_init(struct eth_device *eth,
>>> bd_t *bd)
>>> 
>>>return ret;
>>> 
>>>debug("ID_REV = 0x%08x\n", read_buf);
>>> 
>>> +   /* Configure GPIO pins as LED outputs */
>>> +   write_buf = LED_GPIO_CFG_SPD_LED | LED_GPIO_CFG_LNK_LED |
>>> +   LED_GPIO_CFG_FDX_LED;
>>> +   ret = smsc95xx_write_reg(dev, LED_GPIO_CFG, write_buf);
>>> +   if (ret < 0)
>>> +   return ret;
>>> +   debug("LED_GPIO_CFG set\n");
>>> +
>> 
>> Seems good.
>> 
>> Acked-by: Simon Glass 
> 
> Applied to usb/next
> 
> I kinda wonder if Joe shouldn't pick this one. Is Joe still active ?

Sure... When I need to be. 

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

Re: [U-Boot] [PATCH v2 00/10] usb: Support for TIZEN's THOR download protocol

[Marek Vasut]

Dear Lukasz Majewski,

> This patch series provide support for TIZEN's THOR download protocol.
> 
> Dedicated program for flashing TIZEN developer devices (TRATS, TRATS2)
> is called lthor (or thor for Windows) and can be found at:
> 
> git clone git://review.tizen.org/tools/lthor
> 
> or for git web:
> 
> https://review.tizen.org/git/?p=tools/lthor.git;a=summary
> 
> 
> Presented composite USB function acts as a front end to perform
> correct USB communication with HOST PC.
> To store the received data on the target, the DFU (Device Firmware
> Update) code for flashing has been reused.
> 
> This means, that the "dfu_alt_info" environment variable is used
> to provide information where a received file is stored.
> 
> This also means that dfu and thor can co-exists together.
> Thor protocol and its implementation has one advantage - it is much
> faster than DFU for large files transfers (especially rootfs images).
> 
> It applies on: u-boot-denx-usb/next
> SHA1: 6928d26b84a5aa4a44706362234ab435bb15a6fb
> 
> Test HW: Exynos4210 (TRATS)

Applied all, thanks

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

Re: [U-Boot] [Patch v1 1/1] usb:smsx95xx LED activity for USB net driver

[Marek Vasut]

Dear Joe Hershberger,

> On Oct 9, 2013, at 6:39 PM, Marek Vasut  wrote:
> > Dear Simon Glass,
> > 
> >> +Joe (net maintainer)
> >> +Marek (USB)
> >> 
> >> Hi Suriyan,
> >> 
> >> On Mon, Oct 7, 2013 at 9:30 PM, Suriyan Ramasami 
wrote:
> >>> Add LED activity for SMSX95XX USB Ether driver.
> >>> 
> >>> Signed-off-by: “Suriyan Ramasami" 
> >>> ---
> >>> 
> >>> drivers/usb/eth/smsc95xx.c |   14 ++
> >>> 1 files changed, 14 insertions(+), 0 deletions(-)
> >>> 
> >>> diff --git a/drivers/usb/eth/smsc95xx.c b/drivers/usb/eth/smsc95xx.c
> >>> index 15fd9a9..7bf0a34 100644
> >>> --- a/drivers/usb/eth/smsc95xx.c
> >>> +++ b/drivers/usb/eth/smsc95xx.c
> >>> @@ -14,6 +14,12 @@
> >>> 
> >>> /* SMSC LAN95xx based USB 2.0 Ethernet Devices */
> >>> 
> >>> +/* LED defines */
> >>> +#define LED_GPIO_CFG   (0x24)
> >>> +#define LED_GPIO_CFG_SPD_LED   (0x0100)
> >>> +#define LED_GPIO_CFG_LNK_LED   (0x0010)
> >>> +#define LED_GPIO_CFG_FDX_LED   (0x0001)
> >>> +
> >>> 
> >>> /* Tx command words */
> >>> #define TX_CMD_A_FIRST_SEG_0x2000
> >>> #define TX_CMD_A_LAST_SEG_ 0x1000
> >>> 
> >>> @@ -591,6 +597,14 @@ static int smsc95xx_init(struct eth_device *eth,
> >>> bd_t *bd)
> >>> 
> >>>return ret;
> >>>
> >>>debug("ID_REV = 0x%08x\n", read_buf);
> >>> 
> >>> +   /* Configure GPIO pins as LED outputs */
> >>> +   write_buf = LED_GPIO_CFG_SPD_LED | LED_GPIO_CFG_LNK_LED |
> >>> +   LED_GPIO_CFG_FDX_LED;
> >>> +   ret = smsc95xx_write_reg(dev, LED_GPIO_CFG, write_buf);
> >>> +   if (ret < 0)
> >>> +   return ret;
> >>> +   debug("LED_GPIO_CFG set\n");
> >>> +
> >> 
> >> Seems good.
> >> 
> >> Acked-by: Simon Glass 
> > 
> > Applied to usb/next
> > 
> > I kinda wonder if Joe shouldn't pick this one. Is Joe still active ?
> 
> Sure... When I need to be.

Heh :) Haven't seen you on IRC for a while (and you surely missed a lot, 
applied 
for sjg too). I picked this patch, so no problem here.

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

Re: [U-Boot] [Patch v1 1/1] usb:smsx95xx LED activity for USB net driver

[Marek Vasut]

Dear Simon Glass,

> +Joe (net maintainer)
> +Marek (USB)
> 
> Hi Suriyan,
> 
> On Mon, Oct 7, 2013 at 9:30 PM, Suriyan Ramasami wrote:
> > Add LED activity for SMSX95XX USB Ether driver.
> > 
> > Signed-off-by: “Suriyan Ramasami" 
> > ---
> > 
> >  drivers/usb/eth/smsc95xx.c |   14 ++
> >  1 files changed, 14 insertions(+), 0 deletions(-)
> > 
> > diff --git a/drivers/usb/eth/smsc95xx.c b/drivers/usb/eth/smsc95xx.c
> > index 15fd9a9..7bf0a34 100644
> > --- a/drivers/usb/eth/smsc95xx.c
> > +++ b/drivers/usb/eth/smsc95xx.c
> > @@ -14,6 +14,12 @@
> > 
> >  /* SMSC LAN95xx based USB 2.0 Ethernet Devices */
> > 
> > +/* LED defines */
> > +#define LED_GPIO_CFG   (0x24)
> > +#define LED_GPIO_CFG_SPD_LED   (0x0100)
> > +#define LED_GPIO_CFG_LNK_LED   (0x0010)
> > +#define LED_GPIO_CFG_FDX_LED   (0x0001)
> > +
> > 
> >  /* Tx command words */
> >  #define TX_CMD_A_FIRST_SEG_0x2000
> >  #define TX_CMD_A_LAST_SEG_ 0x1000
> > 
> > @@ -591,6 +597,14 @@ static int smsc95xx_init(struct eth_device *eth,
> > bd_t *bd)
> > 
> > return ret;
> > 
> > debug("ID_REV = 0x%08x\n", read_buf);
> > 
> > +   /* Configure GPIO pins as LED outputs */
> > +   write_buf = LED_GPIO_CFG_SPD_LED | LED_GPIO_CFG_LNK_LED |
> > +   LED_GPIO_CFG_FDX_LED;
> > +   ret = smsc95xx_write_reg(dev, LED_GPIO_CFG, write_buf);
> > +   if (ret < 0)
> > +   return ret;
> > +   debug("LED_GPIO_CFG set\n");
> > +
> 
> Seems good.
> 
> Acked-by: Simon Glass 

Applied to usb/next

I kinda wonder if Joe shouldn't pick this one. Is Joe still active ?

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

Re: [U-Boot] [PATCH 3/6] usb: omap: Move the usb phy code to the usb/phy directory

[Dan Murphy]

Marek

On 10/09/2013 07:35 PM, Marek Vasut wrote:
> Dear Dan Murphy,
>
>> Marek
>>
>> On 10/09/2013 06:38 PM, Marek Vasut wrote:
>>> Dear Dan Murphy,
>>>
 Moving the usb/phy code from xhci-omap to the usb/phy directory
 and moving the associated phy code over to the new file.

 Newer TI processors adding xHCI support will have different PHY
 configurations so therefore abstracting this code away will prevent
 messing around with the xhci-omap file itself.

 Signed-off-by: Dan Murphy 
>>> git format-patch -M would help here greatly too.
>>>
>>> Best regards,
>>> Marek Vasut
>> -M gives no love here.  It shows the same diff that I posted.
>>
>> Even with an 80% delta.
> Aargh ... what about splitting it into two patches then ?
>
> Best regards,
> Marek Vasut

I will see what I can do to get an easier diff.

Dan

-- 
--
Dan Murphy

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

Re: [U-Boot] [PATCH 3/6] usb: omap: Move the usb phy code to the usb/phy directory

[Marek Vasut]

Dear Dan Murphy,

> Marek
> 
> On 10/09/2013 06:38 PM, Marek Vasut wrote:
> > Dear Dan Murphy,
> > 
> >> Moving the usb/phy code from xhci-omap to the usb/phy directory
> >> and moving the associated phy code over to the new file.
> >> 
> >> Newer TI processors adding xHCI support will have different PHY
> >> configurations so therefore abstracting this code away will prevent
> >> messing around with the xhci-omap file itself.
> >> 
> >> Signed-off-by: Dan Murphy 
> > 
> > git format-patch -M would help here greatly too.
> > 
> > Best regards,
> > Marek Vasut
> 
> -M gives no love here.  It shows the same diff that I posted.
> 
> Even with an 80% delta.

Aargh ... what about splitting it into two patches then ?

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

Re: [U-Boot] TI xHCI updates

[Marek Vasut]

Dear Jagan Teki,

> Hi,
> 
> What is this are you manually created this.
> please use --cover-letter on git format-patch
> 
> Will list down the patches on the cover letter and this will be PATCH 0/6
[..]

Just a nitpick, but please do not top-post in the MLs. Thanks!

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

Re: [U-Boot] [PATCH 1/6] usb: omap: Move the xhci-omap header file to common location

[Marek Vasut]

Dear Dan Murphy,

> Marek
> 
> On 10/09/2013 06:37 PM, Marek Vasut wrote:
> > Dear Dan Murphy,
> > 
> >> Moving the xhci-omap header to a more global location so that
> >> other code can reference this code.
> >> 
> >> Signed-off-by: Dan Murphy 
> > 
> > Is this just a simple move? Can you please repost with git format-patch
> > -M ?
> > 
> > Best regards,
> > Marek Vasut
> 
> OK SGTM I think I like that switch on the format-patch command.  Will post
> V2 with that switch enabled.
> 
> Can you look at the other patches in case V2 needs other changes?

Sure, done.

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

Re: [U-Boot] [PATCH 5/6] usb: am437x: Add support for am437x xhci USB host

[Marek Vasut]

Dear Dan Murphy,

> Add the support for the am437x xhci usb host.
> 
> The xHCI host on AM437 is connected to a usb2 phy so need to
> add support to enable those clocks.
> 
> Signed-off-by: Dan Murphy 
> ---
>  arch/arm/include/asm/arch-am33xx/hardware_am43xx.h |   10 +
>  drivers/usb/phy/omap_usb_phy.c |   23
>  include/configs/am43xx_evm.h   | 
>  11 ++ include/linux/usb/xhci-omap.h  |4
> 
>  4 files changed, 48 insertions(+)
> 
> diff --git a/arch/arm/include/asm/arch-am33xx/hardware_am43xx.h
> b/arch/arm/include/asm/arch-am33xx/hardware_am43xx.h index
> 303c594..3b665e6 100644
> --- a/arch/arm/include/asm/arch-am33xx/hardware_am43xx.h
> +++ b/arch/arm/include/asm/arch-am33xx/hardware_am43xx.h
> @@ -51,4 +51,14 @@
>  /* RTC base address */
>  #define RTC_BASE 0x44E3E000
> 
> +/* USB Clock Control */
> +#define PRM_PER_USB_OTG_SS0_CLKCTRL (CM_PER + 0x260)
> +#define PRM_PER_USB_OTG_SS1_CLKCTRL (CM_PER + 0x268)
> +#define USBOTGSSX_CLKCTRL_MODULE_EN  (1 << 2)
> +#define USBOTGSSX_CLKCTRL_OPTFCLKEN_REFCLK960 (1 << 8)
> +
> +#define PRM_PER_USBPHYOCP2SCP0_CLKCTRL (CM_PER + 0x5b8)
> +#define PRM_PER_USBPHYOCP2SCP1_CLKCTRL (CM_PER + 0x5c0)
> +#define USBPHYOCPSCP_MODULE_EN   (1 << 2)
> +
>  #endif /* __AM43XX_HARDWARE_AM43XX_H */
> diff --git a/drivers/usb/phy/omap_usb_phy.c
> b/drivers/usb/phy/omap_usb_phy.c index f1da73d..20c4805 100644
> --- a/drivers/usb/phy/omap_usb_phy.c
> +++ b/drivers/usb/phy/omap_usb_phy.c
> @@ -207,6 +207,25 @@ void usb_phy_power(int on)
>  }
>  #endif /* CONFIG_OMAP_USB2PHY2_HOST */
> 
> +#ifdef CONFIG_AM437X_USB2PHY2_HOST
> +static void am437x_enable_usb2_phy2(struct omap_xhci *omap)
> +{
> + int usb_otg_ss_clk_val = (USBOTGSSX_CLKCTRL_MODULE_EN |
> + USBOTGSSX_CLKCTRL_OPTFCLKEN_REFCLK960);

Other than that it should be "const", it should also be at least unsigned. And 
prefferably u32 .

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

Re: [U-Boot] TI xHCI updates

[Dan Murphy]

Jagan
On 10/09/2013 12:26 PM, Jagan Teki wrote:
> Hi,
>
> What is this are you manually created this.
> please use --cover-letter on git format-patch
>
> Will list down the patches on the cover letter and this will be PATCH 0/6
>
> On Wed, Oct 9, 2013 at 10:51 PM, Dan Murphy  wrote:
>> On 10/09/2013 12:19 PM, Dan Murphy wrote:
>>> This patch series contains the following changes
>>>
>>> - Moves the xhci-omap.h to a common location
>>> - Fixes a compilation issue on OMAP5 when xHCI is defined when patch
>>> "usb: new board-specific USB init interface" is applied
>>> - Moves the TI USB PHY code out of the xhci-omap.c file and into
>>> a new file called drivers/usb/phy/omap_usb_phy.c
>>> - Enables the dra7xx xHCI controller
>>> - Enables the AM437x xHCI controller
>>> - Move OMAP5 MAC creation out of USB and into misc_init so that usbethaddr 
>>> is
>>> set on each boot or else the kernel sets a random MAC.
>>>
>>>
>>> ___
>>> U-Boot mailing list
>>> U-Boot@lists.denx.de
>>> http://lists.denx.de/mailman/listinfo/u-boot
>> Forgot to mention this patchset is based on top of the uBoot USB next branch.
>>
>> Dan
>>
>> --
>> --
>> Dan Murphy
>>
>> ___
>> U-Boot mailing list
>> U-Boot@lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
>

Yes I manually created this

And please bottom post on replies as well.

Dan

-- 
--
Dan Murphy

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

Re: [U-Boot] [PATCH 2/6] usb: omap5: Change the board_usb_init api to board_xhci_usb_init

[Dan Murphy]

Marek

On 10/09/2013 06:38 PM, Marek Vasut wrote:
> Dear Dan Murphy,
>
>> Recent patches declares board_usb_init function prototype for a new
>> usb architecture.
>>
>> Turning on the OMAP_XHCI defines cause a redefinition compiler failure.
>> So rename the API from board_usb_init to board_xhci_usb_init.
>>
>> Signed-off-by: Dan Murphy 
> Can you not use board_usb_init() ? I believe the whole point of the usb 
> rework 
> was to avoid having various names for the same function.
>
> Best regards,
> Marek Vasut

I will post the change in V2.

Dan

-- 
--
Dan Murphy

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

Re: [U-Boot] [PATCH 1/6] usb: omap: Move the xhci-omap header file to common location

[Dan Murphy]

Marek

On 10/09/2013 06:37 PM, Marek Vasut wrote:
> Dear Dan Murphy,
>
>> Moving the xhci-omap header to a more global location so that
>> other code can reference this code.
>>
>> Signed-off-by: Dan Murphy 
> Is this just a simple move? Can you please repost with git format-patch -M ?
>
> Best regards,
> Marek Vasut

OK SGTM I think I like that switch on the format-patch command.  Will post V2 
with that switch enabled.

Can you look at the other patches in case V2 needs other changes?

Dan

-- 
--
Dan Murphy

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

Re: [U-Boot] [PATCH 3/6] usb: omap: Move the usb phy code to the usb/phy directory

[Dan Murphy]

Marek

On 10/09/2013 06:38 PM, Marek Vasut wrote:
> Dear Dan Murphy,
>
>> Moving the usb/phy code from xhci-omap to the usb/phy directory
>> and moving the associated phy code over to the new file.
>>
>> Newer TI processors adding xHCI support will have different PHY
>> configurations so therefore abstracting this code away will prevent
>> messing around with the xhci-omap file itself.
>>
>> Signed-off-by: Dan Murphy 
> git format-patch -M would help here greatly too.
>
> Best regards,
> Marek Vasut

-M gives no love here.  It shows the same diff that I posted.

Even with an 80% delta.

Dan

-- 
--
Dan Murphy

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

[U-Boot] [PATCH 1/3] cmd_ubifs: normalize 'file not found' errors

[Luka Perkov]

From: Tim Harvey 

Signed-off-by: Tim Harvey 
---
 common/cmd_ubifs.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/common/cmd_ubifs.c b/common/cmd_ubifs.c
index eba54fd..d9af023 100644
--- a/common/cmd_ubifs.c
+++ b/common/cmd_ubifs.c
@@ -104,8 +104,10 @@ int do_ubifs_ls(cmd_tbl_t *cmdtp, int flag, int argc, char 
* const argv[])
debug("Using filename %s\n", filename);
 
ret = ubifs_ls(filename);
-   if (ret)
-   printf("%s not found!\n", filename);
+   if (ret) {
+   printf("** File not found %s **\n", filename);
+   ret = CMD_RET_FAILURE;
+   }
 
return ret;
 }
@@ -140,8 +142,10 @@ int do_ubifs_load(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
debug("Loading file '%s' to address 0x%08x (size %d)\n", filename, 
addr, size);
 
ret = ubifs_load(filename, addr, size);
-   if (ret)
-   printf("%s not found!\n", filename);
+   if (ret) {
+   printf("** File not found %s **\n", filename);
+   ret = CMD_RET_FAILURE;
+   }
 
return ret;
 }
-- 
1.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 3/3] cmd_zfs: normalize 'file not found' errors

[Luka Perkov]

Signed-off-by: Luka Perkov 
---
 common/cmd_zfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/cmd_zfs.c b/common/cmd_zfs.c
index 9110868..0aed29e 100644
--- a/common/cmd_zfs.c
+++ b/common/cmd_zfs.c
@@ -95,7 +95,7 @@ static int do_zfs_load(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[]
memset(&zfile, 0, sizeof(zfile));
zfile.device = &vdev;
if (zfs_open(&zfile, filename)) {
-   printf("** File not found %s\n", filename);
+   printf("** File not found %s **\n", filename);
return 1;
}
 
-- 
1.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 2/3] cmd_reiser: normalize 'file not found' errors

[Luka Perkov]

Signed-off-by: Luka Perkov 
---
 common/cmd_reiser.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/cmd_reiser.c b/common/cmd_reiser.c
index b9d2449..8871564 100644
--- a/common/cmd_reiser.c
+++ b/common/cmd_reiser.c
@@ -141,7 +141,7 @@ int do_reiserload (cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
 
filelen = reiserfs_open(filename);
if (filelen < 0) {
-   printf("** File not found %s\n", filename);
+   printf("** File not found %s **\n", filename);
return 1;
}
if ((count < filelen) && (count != 0)) {
-- 
1.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/6] usb: omap: Move the usb phy code to the usb/phy directory

[Marek Vasut]

Dear Dan Murphy,

> Moving the usb/phy code from xhci-omap to the usb/phy directory
> and moving the associated phy code over to the new file.
> 
> Newer TI processors adding xHCI support will have different PHY
> configurations so therefore abstracting this code away will prevent
> messing around with the xhci-omap file itself.
> 
> Signed-off-by: Dan Murphy 

git format-patch -M would help here greatly too.

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

Re: [U-Boot] [PATCH 2/6] usb: omap5: Change the board_usb_init api to board_xhci_usb_init

[Marek Vasut]

Dear Dan Murphy,

> Recent patches declares board_usb_init function prototype for a new
> usb architecture.
> 
> Turning on the OMAP_XHCI defines cause a redefinition compiler failure.
> So rename the API from board_usb_init to board_xhci_usb_init.
> 
> Signed-off-by: Dan Murphy 

Can you not use board_usb_init() ? I believe the whole point of the usb rework 
was to avoid having various names for the same function.

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

Re: [U-Boot] [PATCH 1/6] usb: omap: Move the xhci-omap header file to common location

[Marek Vasut]

Dear Dan Murphy,

> Moving the xhci-omap header to a more global location so that
> other code can reference this code.
> 
> Signed-off-by: Dan Murphy 

Is this just a simple move? Can you please repost with git format-patch -M ?

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

Re: [U-Boot] How/Where does "_start" get assigned a value ?

[Djoker]

On Wed, Oct 9, 2013 at 12:54 PM, Arvid Brodin  wrote:
> On 2013-10-09 18:07, djoker wrote:
>> Hi Everyone,
>>
>> I have a armv7 board and am looking at the "_start" symbol address, using
>> the following command:
>> *nm u-boot | grep -w _start*
>>
>> It returned the following:
>> *6720 T _start*
>>
>> I couldn't help notice that the the _start value is very "close" in vlaue to
>> the value of CONFIG_SYS_TEXT_BASE defined in my board file:
>> *#define CONFIG_SYS_TEXT_BASE 0x6704*
>>
>> But, I have searched through the source code, but not found where _start
>> gets assigned a value.. Could someone please help me understand this ?
>
> This symbol is declared in arch/<...>/start.S, as the entry point for the
> u-boot code, if I understand things correctly.
>

Arvid, I know that the symbol is declared under that file.
But, how is it getting assigned a value equal to or greater than
CONFIG_SYS_TEXT_BASE ?
Basically, I am seeing a similar issue as below:

u-boot.10912.n7.nabble.com/U-Boot-ARM-gap-between-start-and-CONFIG-SYS-TEXT-BASE-td4134.html#none

There really was no conclusion as to why the padding of 0's happened ?



>
>>
>> Thanks,
>> ~vj
>>
>>
>>
>> --
>> View this message in context: 
>> http://u-boot.10912.n7.nabble.com/How-Where-does-start-get-assigned-a-value-tp165089.html
>> Sent from the U-Boot mailing list archive at Nabble.com.
>> ___
>> U-Boot mailing list
>> U-Boot@lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
>>
>
>
> --
> Arvid Brodin | Consultant (Linux)
> XDIN AB | Knarrarnäsgatan 7 | SE-164 40 Kista | Sweden | xdin.com
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] How/Where does "_start" get assigned a value ?

[djoker]

I am running into the issue as described below:

http://u-boot.10912.n7.nabble.com/U-Boot-ARM-gap-between-start-and-CONFIG-SYS-TEXT-BASE-td4134.html#none

But am unable to figure out what the reason could be



--
View this message in context: 
http://u-boot.10912.n7.nabble.com/How-Where-does-start-get-assigned-a-value-tp165089p165110.html
Sent from the U-Boot mailing list archive at Nabble.com.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] buildman: make board selector argument a regex

[Simon Glass]

Hi Stephen,

On Wed, Oct 9, 2013 at 2:28 PM, Stephen Warren  wrote:
> From: Stephen Warren 
>
> A common use-case is to build all boards for a particular SoC. This can
> be achieved by:
>
> ./tools/buildman/buildman -b mainline_dev -n tegra20
>
> However, when the SoC is a member of a family of SoCs, and each SoC has
> a different name, it would be even more useful to build all boards for
> every SoC in that family. This currently isn't possible since buildman's
> board selection command-line arguments are compared to board definitions
> using pure string equality.
>
> To enable this, compare using a regex match instead. This matches
> MAKEALL's handling of command-line arguments. This enables:
>
> (all Tegra)
> ./tools/buildman/buildman -b mainline_dev -n tegra

Do you want the -n here?

>
> (all Tegra)
> ./tools/buildman/buildman -b mainline_dev -n '^tegra.*$'
>
> (all Tegra114, Tegra30 boards, but not Tegra20)
> ./tools/buildman/buildman -b mainline_dev -n 'tegra[13]'
>
> Signed-off-by: Stephen Warren 
> ---
>  tools/buildman/board.py | 12 +++-

Great addition, will be useful. Would you mind also updating the README please?

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

Re: [U-Boot] [PATCH 1/2] buildman: don't fail --list-toolchains when toolchains fail

[Simon Glass]

On Wed, Oct 9, 2013 at 2:28 PM, Stephen Warren  wrote:
> From: Stephen Warren 
>
> When a toolchain invocation fails, an exception is thrown but not caught
> which then aborts the entire toolchain detection process. To solve this,
> request that exceptions not be thrown, since the toolchain init code
> already error-checks the command result. This solves e.g.:
>
>  - found '/usr/bin/winegcc'
> Traceback (most recent call last):
> ...
> Exception: Error running '/usr/bin/winegcc --version'
>
> Signed-off-by: Stephen Warren 

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

[U-Boot] [PATCH 2/2] buildman: make board selector argument a regex

[Stephen Warren]

From: Stephen Warren 

A common use-case is to build all boards for a particular SoC. This can
be achieved by:

./tools/buildman/buildman -b mainline_dev -n tegra20

However, when the SoC is a member of a family of SoCs, and each SoC has
a different name, it would be even more useful to build all boards for
every SoC in that family. This currently isn't possible since buildman's
board selection command-line arguments are compared to board definitions
using pure string equality.

To enable this, compare using a regex match instead. This matches
MAKEALL's handling of command-line arguments. This enables:

(all Tegra)
./tools/buildman/buildman -b mainline_dev -n tegra

(all Tegra)
./tools/buildman/buildman -b mainline_dev -n '^tegra.*$'

(all Tegra114, Tegra30 boards, but not Tegra20)
./tools/buildman/buildman -b mainline_dev -n 'tegra[13]'

Signed-off-by: Stephen Warren 
---
 tools/buildman/board.py | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/tools/buildman/board.py b/tools/buildman/board.py
index 1d3db20..5172a47 100644
--- a/tools/buildman/board.py
+++ b/tools/buildman/board.py
@@ -3,6 +3,8 @@
 # SPDX-License-Identifier: GPL-2.0+
 #
 
+import re
+
 class Board:
 """A particular board that we can build"""
 def __init__(self, status, arch, cpu, soc, vendor, board_name, target, 
options):
@@ -135,14 +137,22 @@ class Boards:
 due to each argument, arranged by argument.
 """
 result = {}
+argres = {}
 for arg in args:
 result[arg] = 0
+argres[arg] = re.compile(arg)
 result['all'] = 0
 
 for board in self._boards:
 if args:
 for arg in args:
-if arg in board.props:
+argre = argres[arg]
+match = False
+for prop in board.props:
+match = argre.match(prop)
+if match:
+break
+if match:
 if not board.build_it:
 board.build_it = True
 result[arg] += 1
-- 
1.8.1.5

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

[U-Boot] [PATCH 1/2] buildman: don't fail --list-toolchains when toolchains fail

[Stephen Warren]

From: Stephen Warren 

When a toolchain invocation fails, an exception is thrown but not caught
which then aborts the entire toolchain detection process. To solve this,
request that exceptions not be thrown, since the toolchain init code
already error-checks the command result. This solves e.g.:

 - found '/usr/bin/winegcc'
Traceback (most recent call last):
...
Exception: Error running '/usr/bin/winegcc --version'

Signed-off-by: Stephen Warren 
---
 tools/buildman/toolchain.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/buildman/toolchain.py b/tools/buildman/toolchain.py
index a292338..7effb88 100644
--- a/tools/buildman/toolchain.py
+++ b/tools/buildman/toolchain.py
@@ -39,7 +39,7 @@ class Toolchain:
 # As a basic sanity check, run the C compiler with --version
 cmd = [fname, '--version']
 if test:
-result = command.RunPipe([cmd], capture=True, env=env)
+result = command.RunPipe([cmd], capture=True, env=env, 
raise_on_error=False)
 self.ok = result.return_code == 0
 if verbose:
 print 'Tool chain test: ',
-- 
1.8.1.5

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

Re: [U-Boot] How/Where does "_start" get assigned a value ?

[Arvid Brodin]

On 2013-10-09 18:07, djoker wrote:
> Hi Everyone,
> 
> I have a armv7 board and am looking at the "_start" symbol address, using
> the following command:
> *nm u-boot | grep -w _start*
> 
> It returned the following:
> *6720 T _start*
> 
> I couldn't help notice that the the _start value is very "close" in vlaue to
> the value of CONFIG_SYS_TEXT_BASE defined in my board file:
> *#define CONFIG_SYS_TEXT_BASE 0x6704*
> 
> But, I have searched through the source code, but not found where _start
> gets assigned a value.. Could someone please help me understand this ?

This symbol is declared in arch/<...>/start.S, as the entry point for the
u-boot code, if I understand things correctly.


> 
> Thanks,
> ~vj
> 
> 
> 
> --
> View this message in context: 
> http://u-boot.10912.n7.nabble.com/How-Where-does-start-get-assigned-a-value-tp165089.html
> Sent from the U-Boot mailing list archive at Nabble.com.
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
> 


-- 
Arvid Brodin | Consultant (Linux)
XDIN AB | Knarrarnäsgatan 7 | SE-164 40 Kista | Sweden | xdin.com

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

Re: [U-Boot] [PATCH] ARM: omap4-panda: Add MAC address creation for panda

[Dan Murphy]

Tom

On 10/09/2013 02:27 PM, Tom Rini wrote:
> On Wed, Oct 09, 2013 at 01:53:46PM -0500, Dan Murphy wrote:
>
>> Add a MAC address create based on the OMAP die ID registers.
>> Then poplulate the ethaddr enviroment variable so that the device
>> tree alias can be updated prior to boot.
>>
>> Signed-off-by: Dan Murphy 
> What are we creating a MAC address for here?  The 10/100 port that's
> hooked up via USB is covered already, and we just need your other patch
> to make usbethaddr be updated in the aliases node applied to fix that.
> We shouldn't be dealing with other ethernet devices that we don't use in
> U-Boot.
>

We need to create the MAC for the panda as no MAC address is being set at all 
for the
USB->Ethernet LAN.

I will change this to set the usbethaddr instead since the lan device is 
connected via usb on the panda boards

Dan

-- 
--
Dan Murphy

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

[U-Boot] Got u-boot-2012.10 running on at91sam9200 - but why does it work?

[Arvid Brodin]

Hi,

I managed to get u-boot-2012.10 to boot from NOR flash on a custom 
at91rm9200 board by doing this:


Signed-off-by: Arvid Brodin 
---
 arch/arm/cpu/arm920t/start.S   | 8 +++-
 2 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/arch/arm/cpu/arm920t/start.S b/arch/arm/cpu/arm920t/start.S
index 14c9156..efc4ea3 100644
--- a/arch/arm/cpu/arm920t/start.S
+++ b/arch/arm/cpu/arm920t/start.S
@@ -294,9 +294,7 @@ clbss_e:
 _nand_boot_ofs:
.word nand_boot
 #else
-   ldr r0, _board_init_r_ofs
-   adr r1, _start
-   add lr, r0, r1
+   ldr lr, _board_init_r
add lr, lr, r9
/* setup parameters for board_init_r */
mov r0, r5  /* gd_t */
@@ -304,8 +302,8 @@ _nand_boot_ofs:
/* jump to it ... */
mov pc, lr
 
-_board_init_r_ofs:
-   .word board_init_r - _start
+_board_init_r:
+   .word board_init_r
 #endif
 
 _rel_dyn_start_ofs:
-- 
1.8.1.5

(I also had to comment out the CONFIG_AT91RM9200EK define in my custom board
config file.)

Any idea why this is needed? I simply used a LED to see where the un-touched 
code failed, and noticed it reached the board_init_r call but never entered the
function. I thought it a bit strange to first subtract _start in the variable
definition and the add it again in the code, so I tried without it, and -- lo
and behold! -- it worked.



-- 
Arvid Brodin | Consultant (Linux)
XDIN AB | Knarrarnäsgatan 7 | SE-164 40 Kista | Sweden | xdin.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] How/Where does "_start" get assigned a value ?

[djoker]

Hi Everyone,

I have a armv7 board and am looking at the "_start" symbol address, using
the following command:
*nm u-boot | grep -w _start*

It returned the following:
*6720 T _start*

I couldn't help notice that the the _start value is very "close" in vlaue to
the value of CONFIG_SYS_TEXT_BASE defined in my board file:
*#define CONFIG_SYS_TEXT_BASE 0x6704*

But, I have searched through the source code, but not found where _start
gets assigned a value.. Could someone please help me understand this ?

Thanks,
~vj



--
View this message in context: 
http://u-boot.10912.n7.nabble.com/How-Where-does-start-get-assigned-a-value-tp165089.html
Sent from the U-Boot mailing list archive at Nabble.com.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: omap4-panda: Add MAC address creation for panda

[Tom Rini]

On Wed, Oct 09, 2013 at 01:53:46PM -0500, Dan Murphy wrote:

> Add a MAC address create based on the OMAP die ID registers.
> Then poplulate the ethaddr enviroment variable so that the device
> tree alias can be updated prior to boot.
> 
> Signed-off-by: Dan Murphy 

What are we creating a MAC address for here?  The 10/100 port that's
hooked up via USB is covered already, and we just need your other patch
to make usbethaddr be updated in the aliases node applied to fix that.
We shouldn't be dealing with other ethernet devices that we don't use in
U-Boot.

-- 
Tom


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

[U-Boot] [PATCH] i.MX6: nitrogen6x: fix erase size in 6x_upgrade.txt

[Eric Nelson]

The 6x_upgrade script is used to upgrade U-Boot in SPI-NOR
on Nitrogen6x/SABRE Lite boards using U-Boot's 'sf' command.

U-Boot is placed at offset 0x400 in flash, and the script
currently only erases 0x5 bytes. Since the current
head is 319k, any additional features enabled in the
configuration will exceed the space erased and cause errors
re-programming the device.

This patch increases the erase size to the full size of
the region allocated for the U-Boot binary.

Signed-off-by: Eric Nelson 
---
 board/boundary/nitrogen6x/6x_upgrade.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/boundary/nitrogen6x/6x_upgrade.txt 
b/board/boundary/nitrogen6x/6x_upgrade.txt
index 0d8e8e5..ad3d0b6 100644
--- a/board/boundary/nitrogen6x/6x_upgrade.txt
+++ b/board/boundary/nitrogen6x/6x_upgrade.txt
@@ -17,7 +17,7 @@ if ${fs}load ${dtype} ${disk}:1 1200 u-boot.imx || 
${fs}load ${dtype} ${disk
 sleep 1 ;
done
   echo "erasing" ;
-   sf erase 0 0x5 ;
+   sf erase 0 0xC ;
   # two steps to prevent bricking
   echo "programming" ;
sf write 0x1200 $offset $filesize ;
-- 
1.8.1.2

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

[U-Boot] [PATCH] ARM: omap4: Update sdram setting for panda rev A6

[Dan Murphy]

OMAP4 panda rev A6 is a 4430 es2.3 IC with an updated memory
part.

The panda rev A6 uses Elpida 2x4Gb memory and no longer uses Micron
so the timings needs to be updated

Signed-off-by: Dan Murphy 
---
 arch/arm/cpu/armv7/omap4/sdram_elpida.c |4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/cpu/armv7/omap4/sdram_elpida.c 
b/arch/arm/cpu/armv7/omap4/sdram_elpida.c
index 67a7926..e4c8316 100644
--- a/arch/arm/cpu/armv7/omap4/sdram_elpida.c
+++ b/arch/arm/cpu/armv7/omap4/sdram_elpida.c
@@ -121,6 +121,8 @@ static void emif_get_reg_dump_sdp(u32 emif_nr, const struct 
emif_regs **regs)
*regs = &emif_regs_elpida_380_mhz_1cs;
else if (omap4_rev == OMAP4430_ES2_0)
*regs = &emif_regs_elpida_200_mhz_2cs;
+   else if (omap4_rev == OMAP4430_ES2_3)
+   *regs = &emif_regs_elpida_400_mhz_1cs;
else if (omap4_rev < OMAP4470_ES1_0)
*regs = &emif_regs_elpida_400_mhz_2cs;
else
@@ -136,6 +138,8 @@ static void emif_get_dmm_regs_sdp(const struct 
dmm_lisa_map_regs
 
if (omap_rev == OMAP4430_ES1_0)
*dmm_lisa_regs = &lisa_map_2G_x_1_x_2;
+   else if (omap_rev == OMAP4430_ES2_3)
+   *dmm_lisa_regs = &lisa_map_2G_x_2_x_2;
else if (omap_rev < OMAP4460_ES1_0)
*dmm_lisa_regs = &lisa_map_2G_x_2_x_2;
else
-- 
1.7.9.5

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

[U-Boot] [PATCH] ARM: omap4-panda: Add MAC address creation for panda

[Dan Murphy]

Add a MAC address create based on the OMAP die ID registers.
Then poplulate the ethaddr enviroment variable so that the device
tree alias can be updated prior to boot.

Signed-off-by: Dan Murphy 
---
 arch/arm/include/asm/arch-omap4/omap.h |4 
 board/ti/panda/panda.c |   16 
 2 files changed, 20 insertions(+)

diff --git a/arch/arm/include/asm/arch-omap4/omap.h 
b/arch/arm/include/asm/arch-omap4/omap.h
index 9129c0d..e35f51c 100644
--- a/arch/arm/include/asm/arch-omap4/omap.h
+++ b/arch/arm/include/asm/arch-omap4/omap.h
@@ -33,6 +33,10 @@
 
 /* CONTROL_ID_CODE */
 #define CONTROL_ID_CODE0x4A002204
+#define STD_FUSE_DIE_ID_0  0x4A002200
+#define STD_FUSE_DIE_ID_1  0x4A002208
+#define STD_FUSE_DIE_ID_2  0x4A00220c
+#define STD_FUSE_DIE_ID_3  0x4A002210
 
 #define OMAP4_CONTROL_ID_CODE_ES1_00x0B85202F
 #define OMAP4_CONTROL_ID_CODE_ES2_00x1B85202F
diff --git a/board/ti/panda/panda.c b/board/ti/panda/panda.c
index e838ffd..53f4c24 100644
--- a/board/ti/panda/panda.c
+++ b/board/ti/panda/panda.c
@@ -133,6 +133,7 @@ int misc_init_r(void)
 {
int phy_type;
u32 auxclk, altclksrc;
+   uint8_t device_mac[6];
 
/* EHCI is not supported on ES1.0 */
if (omap_revision() == OMAP4430_ES1_0)
@@ -186,6 +187,21 @@ int misc_init_r(void)
 
writel(altclksrc, &scrm->altclksrc);
 
+   if (!getenv("ethaddr")) {
+   /*
+* create a fake MAC address from the processor ID code.
+* first byte is 0x02 to signify locally administered.
+*/
+   device_mac[0] = 0x02;
+   device_mac[1] = readl(STD_FUSE_DIE_ID_3) & 0xff;
+   device_mac[2] = readl(STD_FUSE_DIE_ID_2) & 0xff;
+   device_mac[3] = readl(STD_FUSE_DIE_ID_1) & 0xff;
+   device_mac[4] = readl(STD_FUSE_DIE_ID_0) & 0xff;
+   device_mac[5] = (readl(STD_FUSE_DIE_ID_0) >> 8) & 0xff;
+
+   eth_setenv_enetaddr("ethaddr", device_mac);
+   }
+
return 0;
 }
 
-- 
1.7.9.5

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

[U-Boot] Pull request: nand flash

[Scott Wood]

Sorry for the lateness, but here are some MTD/UBI bugfixes.  They've
been acked by Stefan Roese.

The following changes since commit b770e88a6c2548727f0d57a3e9e8bb0830f977b5:

  Fix number base handling of "load" command (2013-10-07 15:54:18 -0400)

are available in the git repository at:

  git://git.denx.de/u-boot-nand-flash.git master

for you to fetch changes up to cc734f5ab26134e5e8d57c34edc257c89ac5b1d2:

  cmd_ubi: add write.part command, to write a volume in multiple parts 
(2013-10-09 12:52:22 -0500)


Paul Burton (4):
  mtd: driver _read() returns max_bitflips; mtd_read() returns -EUCLEAN
  cmd_mtdparts: use 64 bits for flash size, partition size & offset
  cmd_ubi: use int64_t volume size for 'ubi create'
  cmd_ubi: add write.part command, to write a volume in multiple parts

 common/cmd_mtdparts.c  | 54 ++
 common/cmd_ubi.c   | 79 +++---
 doc/README.ubi |  3 ++
 drivers/mtd/mtdcore.c  | 14 ++-
 drivers/mtd/mtdpart.c  | 12 +++---
 drivers/mtd/nand/nand_base.c   | 18 +++--
 drivers/mtd/onenand/onenand_base.c |  3 +-
 include/jffs2/load_kernel.h|  6 +--
 include/linux/mtd/nand.h   |  3 ++
 9 files changed, 129 insertions(+), 63 deletions(-)

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

[U-Boot] [PATCH] omap5_common: Re-work mmc boot to try SD and eMMC, correct root device

[Tom Rini]

OMAP5 boards may have both eMMC (on MMC2) and an SD slot (on MMC1).  We
Update the default bootcmd to match what happens on AM335x where we try
SD first, and then eMMC.  In this case however, the hardware layout used
for powering both of these means that in the kernel eMMC shall be found
first as it is powered by a fixed regulator and SD found second as SD is
powered via the palmas which will result in deferred probing.

Tested-by: Aparna Balasubramanian 
Signed-off-by: Tom Rini 
---
 include/configs/omap5_common.h |   45 +---
 1 file changed, 24 insertions(+), 21 deletions(-)

diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index 98ba559..eade637 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -83,7 +83,7 @@
"partitions=" PARTS_DEFAULT "\0" \
"optargs=\0" \
"mmcdev=0\0" \
-   "mmcroot=/dev/mmcblk0p2 rw\0" \
+   "mmcroot=/dev/mmcblk1p2 rw\0" \
"mmcrootfstype=ext4 rootwait\0" \
"mmcargs=setenv bootargs console=${console} " \
"${optargs} " \
@@ -97,9 +97,24 @@
"importbootenv=echo Importing environment from mmc${mmcdev} ...; " \
"env import -t ${loadaddr} ${filesize}\0" \
"loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0" \
-   "mmcboot=echo Booting from mmc${mmcdev} ...; " \
-   "run mmcargs; " \
-   "bootz ${loadaddr} - ${fdtaddr}\0" \
+   "mmcboot=mmc dev ${mmcdev}; " \
+   "if mmc rescan; then " \
+   "echo SD/MMC found on device ${mmcdev};" \
+   "if run loadbootenv; then " \
+   "echo Loaded environment from ${bootenv};" \
+   "run importbootenv;" \
+   "fi;" \
+   "if test -n $uenvcmd; then " \
+   "echo Running uenvcmd ...;" \
+   "run uenvcmd;" \
+   "fi;" \
+   "if run loadimage; then " \
+   "run loadfdt; " \
+   "echo Booting from mmc${mmcdev} ...; " \
+   "run mmcargs; " \
+   "bootz ${loadaddr} - ${fdtaddr}; " \
+   "fi;" \
+   "fi;\0" \
"findfdt="\
"if test $board_name = omap5_uevm; then " \
"setenv fdtfile omap5-uevm.dtb; fi; " \
@@ -111,23 +126,11 @@
 
 #define CONFIG_BOOTCOMMAND \
"run findfdt; " \
-   "mmc dev ${mmcdev}; if mmc rescan; then " \
-   "if run loadbootscript; then " \
-   "run bootscript; " \
-   "else " \
-   "if run loadbootenv; then " \
-   "run importbootenv; " \
-   "fi;" \
-   "if test -n ${uenvcmd}; then " \
-   "echo Running uenvcmd ...;" \
-   "run uenvcmd;" \
-   "fi;" \
-   "fi;" \
-   "if run loadimage; then " \
-   "run loadfdt; " \
-   "run mmcboot; " \
-   "fi; " \
-   "fi"
+   "run mmcboot;" \
+   "setenv mmcdev 1; " \
+   "setenv bootpart 1:2; " \
+   "setenv mmcroot /dev/mmcblk0p2 rw; " \
+   "run mmcboot;" \
 
 
 /*
-- 
1.7.9.5

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

Re: [U-Boot] [PATCH v2] usb: Prevent using reserved registers on DM36x usb

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/09/2013 01:16 PM, Andrew Murray wrote:
> On 30 September 2013 00:26, Marek Vasut  wrote:
>> Dear Andrew Murray,
>>
>>> The musb driver defines and uses MUSB_CSR0_H_DIS_PING, however this
>>> bit is reserved on the DM36x. Thus this patch ensures that the
>>> reserved bit is not accesssed.
>>>
>>> It has been observed that some USB devices will fail to enumerate
>>> with errors such as 'error in inquiry' without this patch.
>>>
>>> See http://www.ti.com/litv/pdf/sprufh9a for details.
>>>
>>> Cc: Marek Vasut 
>>> Cc: Tom Rini 
>>> Signed-off-by: Andrew Murray 
>>
>> Tom, can you check this and if it's OK with you, pick this by hand?
>>
>> For my part, I'm fine here,
>>
>> Acked-by: Marek Vasut 
> 
> Tom, was this version OK?

Yes, this is now in master, sorry I've been slacking in sending my
replies to all patches.

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

iQIcBAEBAgAGBQJSVZYHAAoJENk4IS6UOR1WJzIP/3mWVIYFD041O91GjbyNymW3
5Tjh7zXQ0MjrHHD86diZk4EsdhS3ucfQ1YP9yiDM4DhruGiO0MGRheQoND6MxqAK
Ab7q3QBDp5qdIvoepUb8UZVe15IK5PyZ86q3xraJYZ4uN6lS+FfnP//3UwdgD/Sr
bw+9vfHWFjmZvPVOXQoMebmnClWaHY5MCjkMwi4K4/DYjWcWyQLA9tAotvMa/Xhc
yBx1jwnTtqBAMWJnJD+ZTKkssPLZTF+B/IV+waZIX5upviV5fg1JKtdwRw0BAQUz
SATsWiKAEczztYttQfz39lzyOS+VFvtYKDEJb8B24BlFRn11udgZk4RNKWixxDCT
j7+q74e4mVzD529Qb5aqhf5PyyaKcmxlkHDHk3xRRGsaUOHLLv/j/pXUGG7CAc7d
v9oGIpa9J4fIN8y8im1tMfJjXuq/gspqTmJo0F0tfUtzUHIJIXy7zptmhANoVLu2
nmL+owCesTlLQc0y6gQMUXAqiBdBSzSgMkGmcSkD+J+C6XfdSZBTu9zX3dUDmX7y
tuwx01l9k6iP8oqC7TQGycLgWNzenJH2YuvFS3yctTtwmQd0RtqbSHgCzW7FjAzX
WFRUzTLz20OtR0O+sXCKtxnv/BvwkE3i4Ohe+LRJxCuorIa8KMRad+88sMaya927
2LgEI3U1cQrpT2zgZ6QN
=zGv4
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] TI xHCI updates

[Jagan Teki]

Hi,

What is this are you manually created this.
please use --cover-letter on git format-patch

Will list down the patches on the cover letter and this will be PATCH 0/6

On Wed, Oct 9, 2013 at 10:51 PM, Dan Murphy  wrote:
> On 10/09/2013 12:19 PM, Dan Murphy wrote:
>> This patch series contains the following changes
>>
>> - Moves the xhci-omap.h to a common location
>> - Fixes a compilation issue on OMAP5 when xHCI is defined when patch
>> "usb: new board-specific USB init interface" is applied
>> - Moves the TI USB PHY code out of the xhci-omap.c file and into
>> a new file called drivers/usb/phy/omap_usb_phy.c
>> - Enables the dra7xx xHCI controller
>> - Enables the AM437x xHCI controller
>> - Move OMAP5 MAC creation out of USB and into misc_init so that usbethaddr is
>> set on each boot or else the kernel sets a random MAC.
>>
>>
>> ___
>> U-Boot mailing list
>> U-Boot@lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
> Forgot to mention this patchset is based on top of the uBoot USB next branch.
>
> Dan
>
> --
> --
> Dan Murphy
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot



-- 
Thanks,
Jagan.

Jagannadha Sutradharudu Teki,
E: jagannadh.t...@gmail.com, P: +91-9676773388
Engineer - System Software Hacker
U-boot - SPI Custodian and Zynq APSOC
Ln: http://www.linkedin.com/in/jaganteki
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] usb: Prevent using reserved registers on DM36x usb

[Andrew Murray]

On 30 September 2013 00:26, Marek Vasut  wrote:
> Dear Andrew Murray,
>
>> The musb driver defines and uses MUSB_CSR0_H_DIS_PING, however this
>> bit is reserved on the DM36x. Thus this patch ensures that the
>> reserved bit is not accesssed.
>>
>> It has been observed that some USB devices will fail to enumerate
>> with errors such as 'error in inquiry' without this patch.
>>
>> See http://www.ti.com/litv/pdf/sprufh9a for details.
>>
>> Cc: Marek Vasut 
>> Cc: Tom Rini 
>> Signed-off-by: Andrew Murray 
>
> Tom, can you check this and if it's OK with you, pick this by hand?
>
> For my part, I'm fine here,
>
> Acked-by: Marek Vasut 

Tom, was this version OK?

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

Re: [U-Boot] TI xHCI updates

[Dan Murphy]

On 10/09/2013 12:19 PM, Dan Murphy wrote:
> This patch series contains the following changes
>
> - Moves the xhci-omap.h to a common location
> - Fixes a compilation issue on OMAP5 when xHCI is defined when patch
> "usb: new board-specific USB init interface" is applied
> - Moves the TI USB PHY code out of the xhci-omap.c file and into
> a new file called drivers/usb/phy/omap_usb_phy.c
> - Enables the dra7xx xHCI controller
> - Enables the AM437x xHCI controller
> - Move OMAP5 MAC creation out of USB and into misc_init so that usbethaddr is
> set on each boot or else the kernel sets a random MAC.
>
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
Forgot to mention this patchset is based on top of the uBoot USB next branch.

Dan

-- 
--
Dan Murphy

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

[U-Boot] [PATCH 4/6] usb: dra7xx: Add support for dra7xx xhci USB host

[Dan Murphy]

Add the support for the dra7xx xhci usb host.
dra7xx does not contain an EHCI controller so the headers
can be removed from the board file.

The xHCI host on dra7xx is connected to a usb2 phy so need to
add support to enable those clocks.

Signed-off-by: Dan Murphy 
---
 arch/arm/cpu/armv7/omap5/prcm-regs.c|1 +
 arch/arm/include/asm/arch-omap5/clock.h |4 +++
 arch/arm/include/asm/omap_common.h  |1 +
 board/ti/dra7xx/evm.c   |6 -
 board/ti/dra7xx/mux_data.h  |1 +
 drivers/usb/host/xhci-omap.c|6 ++---
 drivers/usb/phy/omap_usb_phy.c  |   45 +--
 include/configs/dra7xx_evm.h|   11 
 include/linux/usb/xhci-omap.h   |   12 ++---
 9 files changed, 72 insertions(+), 15 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap5/prcm-regs.c 
b/arch/arm/cpu/armv7/omap5/prcm-regs.c
index b48c65c..85a65be 100644
--- a/arch/arm/cpu/armv7/omap5/prcm-regs.c
+++ b/arch/arm/cpu/armv7/omap5/prcm-regs.c
@@ -795,6 +795,7 @@ struct prcm_regs const dra7xx_prcm = {
.cm_clkmode_dpll_dsp= 0x4a005234,
.cm_shadow_freq_config1 = 0x4a005260,
.cm_clkmode_dpll_gmac   = 0x4a0052a8,
+   .cm_coreaon_usb_phy2_core_clkctrl = 0x4a008688,
 
/* cm1.mpu */
.cm_mpu_mpu_clkctrl = 0x4a005320,
diff --git a/arch/arm/include/asm/arch-omap5/clock.h 
b/arch/arm/include/asm/arch-omap5/clock.h
index 5cbbc44..8869b50 100644
--- a/arch/arm/include/asm/arch-omap5/clock.h
+++ b/arch/arm/include/asm/arch-omap5/clock.h
@@ -202,6 +202,10 @@
 /* PRM_VC_VAL_BYPASS */
 #define PRM_VC_I2C_CHANNEL_FREQ_KHZ400
 
+/* CTRL_CORE_SRCOMP_NORTH_SIDE */
+#define USB2PHY_DISCHGDET  (1 << 29)
+#define USB2PHY_AUTORESUME_EN (1 << 30)
+
 /* SMPS */
 #define SMPS_I2C_SLAVE_ADDR0x12
 #define SMPS_REG_ADDR_12_MPU   0x23
diff --git a/arch/arm/include/asm/omap_common.h 
b/arch/arm/include/asm/omap_common.h
index bea1835..8a395e8 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -144,6 +144,7 @@ struct prcm_regs {
u32 cm_ssc_deltamstep_dpll_unipro;
u32 cm_ssc_modfreqdiv_dpll_unipro;
u32 cm_coreaon_usb_phy_core_clkctrl;
+   u32 cm_coreaon_usb_phy2_core_clkctrl;
 
/* cm2.core */
u32 cm_coreaon_bandgap_clkctrl;
diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
index 9a114e2..9657c75 100644
--- a/board/ti/dra7xx/evm.c
+++ b/board/ti/dra7xx/evm.c
@@ -17,12 +17,6 @@
 
 #include "mux_data.h"
 
-#ifdef CONFIG_USB_EHCI
-#include 
-#include 
-#include 
-#endif
-
 #ifdef CONFIG_DRIVER_TI_CPSW
 #include 
 #endif
diff --git a/board/ti/dra7xx/mux_data.h b/board/ti/dra7xx/mux_data.h
index 6965cc5..38de9d5 100644
--- a/board/ti/dra7xx/mux_data.h
+++ b/board/ti/dra7xx/mux_data.h
@@ -61,5 +61,6 @@ const struct pad_conf_entry core_padconf_array_essential[] = {
{GPMC_A4, (IEN | PDIS | M1)},   /* QSPI1_CS3 */
{GPMC_CS2, (IEN | PTU | PDIS | M1)},/* QSPI1_CS0 */
{GPMC_CS3, (IEN | PTU | PDIS | M1)},/* QSPI1_CS1*/
+   {USB2_DRVVBUS, (M0 | IEN | FSC) },
 };
 #endif /* _MUX_DATA_DRA7XX_H_ */
diff --git a/drivers/usb/host/xhci-omap.c b/drivers/usb/host/xhci-omap.c
index 513b9d8..5c85885 100644
--- a/drivers/usb/host/xhci-omap.c
+++ b/drivers/usb/host/xhci-omap.c
@@ -97,9 +97,7 @@ static int omap_xhci_core_init(struct omap_xhci *omap)
 {
int ret = 0;
 
-   omap_enable_phy_clocks(omap);
-
-   omap_usb3_phy_init(omap->usb3_phy);
+   omap_enable_phy(omap);
 
ret = dwc3_core_init(omap->dwc3_reg);
if (ret) {
@@ -115,7 +113,7 @@ static int omap_xhci_core_init(struct omap_xhci *omap)
 
 static void omap_xhci_core_exit(struct omap_xhci *omap)
 {
-   usb3_phy_power(0);
+   usb_phy_power(0);
 }
 
 int xhci_hcd_init(int index, struct xhci_hccr **hccr, struct xhci_hcor **hcor)
diff --git a/drivers/usb/phy/omap_usb_phy.c b/drivers/usb/phy/omap_usb_phy.c
index ed727bf..f1da73d 100644
--- a/drivers/usb/phy/omap_usb_phy.c
+++ b/drivers/usb/phy/omap_usb_phy.c
@@ -22,6 +22,7 @@
 
 #include "../host/xhci.h"
 
+#ifdef CONFIG_OMAP_USB3PHY1_HOST
 struct usb_dpll_params {
u16 m;
u8  n;
@@ -99,7 +100,7 @@ static void usb3_phy_partial_powerup(struct omap_usb3_phy 
*phy_regs)
writel(val, (*ctrl)->control_phy_power_usb);
 }
 
-void usb3_phy_power(int on)
+void usb_phy_power(int on)
 {
u32 val;
 
@@ -128,7 +129,7 @@ void omap_usb3_phy_init(struct omap_usb3_phy *phy_regs)
usb3_phy_power(1);
 }
 
-void omap_enable_phy_clocks(struct omap_xhci *omap)
+static void omap_enable_usb3_phy(struct omap_xhci *omap)
 {
u32 val;
 
@@ -176,6 +177,35 @@ void omap_enable_phy_clocks(struct omap_xhci *omap)
setbits_le32((*prcm)->cm_l3init_usb_otg_ss_clkctrl, val);
 
 };
+#endif /* CONFIG_OMAP_USB3PHY1_HOST */
+
+#ifdef CONFIG_OMAP_USB2PHY2_HOST
+static void oma

[U-Boot] [PATCH 5/6] usb: am437x: Add support for am437x xhci USB host

[Dan Murphy]

Add the support for the am437x xhci usb host.

The xHCI host on AM437 is connected to a usb2 phy so need to
add support to enable those clocks.

Signed-off-by: Dan Murphy 
---
 arch/arm/include/asm/arch-am33xx/hardware_am43xx.h |   10 +
 drivers/usb/phy/omap_usb_phy.c |   23 
 include/configs/am43xx_evm.h   |   11 ++
 include/linux/usb/xhci-omap.h  |4 
 4 files changed, 48 insertions(+)

diff --git a/arch/arm/include/asm/arch-am33xx/hardware_am43xx.h 
b/arch/arm/include/asm/arch-am33xx/hardware_am43xx.h
index 303c594..3b665e6 100644
--- a/arch/arm/include/asm/arch-am33xx/hardware_am43xx.h
+++ b/arch/arm/include/asm/arch-am33xx/hardware_am43xx.h
@@ -51,4 +51,14 @@
 /* RTC base address */
 #define RTC_BASE   0x44E3E000
 
+/* USB Clock Control */
+#define PRM_PER_USB_OTG_SS0_CLKCTRL (CM_PER + 0x260)
+#define PRM_PER_USB_OTG_SS1_CLKCTRL (CM_PER + 0x268)
+#define USBOTGSSX_CLKCTRL_MODULE_EN(1 << 2)
+#define USBOTGSSX_CLKCTRL_OPTFCLKEN_REFCLK960 (1 << 8)
+
+#define PRM_PER_USBPHYOCP2SCP0_CLKCTRL (CM_PER + 0x5b8)
+#define PRM_PER_USBPHYOCP2SCP1_CLKCTRL (CM_PER + 0x5c0)
+#define USBPHYOCPSCP_MODULE_EN (1 << 2)
+
 #endif /* __AM43XX_HARDWARE_AM43XX_H */
diff --git a/drivers/usb/phy/omap_usb_phy.c b/drivers/usb/phy/omap_usb_phy.c
index f1da73d..20c4805 100644
--- a/drivers/usb/phy/omap_usb_phy.c
+++ b/drivers/usb/phy/omap_usb_phy.c
@@ -207,6 +207,25 @@ void usb_phy_power(int on)
 }
 #endif /* CONFIG_OMAP_USB2PHY2_HOST */
 
+#ifdef CONFIG_AM437X_USB2PHY2_HOST
+static void am437x_enable_usb2_phy2(struct omap_xhci *omap)
+{
+   int usb_otg_ss_clk_val = (USBOTGSSX_CLKCTRL_MODULE_EN |
+   USBOTGSSX_CLKCTRL_OPTFCLKEN_REFCLK960);
+
+   writel(usb_otg_ss_clk_val, PRM_PER_USB_OTG_SS0_CLKCTRL);
+   writel(usb_otg_ss_clk_val, PRM_PER_USB_OTG_SS1_CLKCTRL);
+
+   writel(USBPHYOCPSCP_MODULE_EN, PRM_PER_USBPHYOCP2SCP0_CLKCTRL);
+   writel(USBPHYOCPSCP_MODULE_EN, PRM_PER_USBPHYOCP2SCP1_CLKCTRL);
+}
+
+void usb_phy_power(int on)
+{
+   return;
+}
+#endif /* CONFIG_AM437X_USB2PHY2_HOST */
+
 void omap_reset_usb_phy(struct dwc3 *dwc3_reg)
 {
/* Assert USB3 PHY reset */
@@ -231,6 +250,10 @@ void omap_enable_phy(struct omap_xhci *omap)
omap_enable_usb2_phy2(omap);
 #endif
 
+#ifdef CONFIG_AM437X_USB2PHY2_HOST
+   am437x_enable_usb2_phy2(omap);
+#endif
+
 #ifdef CONFIG_OMAP_USB3PHY1_HOST
omap_enable_usb3_phy(omap);
omap_usb3_phy_init(omap->usb3_phy);
diff --git a/include/configs/am43xx_evm.h b/include/configs/am43xx_evm.h
index 5c802a1..64c4811 100644
--- a/include/configs/am43xx_evm.h
+++ b/include/configs/am43xx_evm.h
@@ -24,6 +24,7 @@
 #define CONFIG_SYS_HUSH_PARSER /* use "hush" command parser */
 #define CONFIG_SYS_PROMPT  "U-Boot# "
 #define CONFIG_SYS_NO_FLASH
+#define CONFIG_SYS_CACHELINE_SIZE 32
 
 #define CONFIG_OF_LIBFDT
 #define CONFIG_CMD_BOOTZ
@@ -132,4 +133,14 @@
 /* Unsupported features */
 #undef CONFIG_USE_IRQ
 
+#define CONFIG_CMD_USB
+#define CONFIG_USB_HOST
+#define CONFIG_USB_XHCI
+#define CONFIG_USB_XHCI_OMAP
+#define CONFIG_USB_STORAGE
+#define CONFIG_SYS_USB_XHCI_MAX_ROOT_PORTS 2
+
+#define CONFIG_OMAP_USB_PHY
+#define CONFIG_AM437X_USB2PHY2_HOST
+
 #endif /* __CONFIG_AM43XX_EVM_H */
diff --git a/include/linux/usb/xhci-omap.h b/include/linux/usb/xhci-omap.h
index c3fcc03..82630ad 100644
--- a/include/linux/usb/xhci-omap.h
+++ b/include/linux/usb/xhci-omap.h
@@ -14,6 +14,10 @@
 #define OMAP_XHCI_BASE 0x488d
 #define OMAP_OCP1_SCP_BASE 0x4A081000
 #define OMAP_OTG_WRAPPER_BASE 0x488c
+#elif defined CONFIG_AM43XX
+#define OMAP_XHCI_BASE 0x483d
+#define OMAP_OCP1_SCP_BASE 0x483E8000
+#define OMAP_OTG_WRAPPER_BASE 0x483dc100
 #else
 /* Default to the OMAP5 XHCI defines */
 #define OMAP_XHCI_BASE 0x4a03
-- 
1.7.9.5

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

[U-Boot] [PATCH 1/6] usb: omap: Move the xhci-omap header file to common location

[Dan Murphy]

Moving the xhci-omap header to a more global location so that
other code can reference this code.

Signed-off-by: Dan Murphy 
---
 arch/arm/include/asm/arch-omap5/xhci-omap.h |  124 ---
 drivers/usb/host/xhci-omap.c|2 +-
 include/linux/usb/xhci-omap.h   |  124 +++
 3 files changed, 125 insertions(+), 125 deletions(-)
 delete mode 100644 arch/arm/include/asm/arch-omap5/xhci-omap.h
 create mode 100644 include/linux/usb/xhci-omap.h

diff --git a/arch/arm/include/asm/arch-omap5/xhci-omap.h 
b/arch/arm/include/asm/arch-omap5/xhci-omap.h
deleted file mode 100644
index b557a43..000
--- a/arch/arm/include/asm/arch-omap5/xhci-omap.h
+++ /dev/null
@@ -1,124 +0,0 @@
-/*
- * (C) Copyright 2013
- * Texas Instruments Inc, 
- *
- * Author: Dan Murphy 
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#ifndef _ASM_ARCH_XHCI_OMAP_H_
-#define _ASM_ARCH_XHCI_OMAP_H_
-
-#define OMAP_XHCI_BASE 0x4a03
-#define OMAP_OCP1_SCP_BASE 0x4a084c00
-#define OMAP_OTG_WRAPPER_BASE 0x4A02
-
-/* Phy register MACRO definitions */
-#definePLL_REGM_MASK   0x001FFE00
-#definePLL_REGM_SHIFT  0x9
-#definePLL_REGM_F_MASK 0x0003
-#definePLL_REGM_F_SHIFT0x0
-#definePLL_REGN_MASK   0x01FE
-#definePLL_REGN_SHIFT  0x1
-#definePLL_SELFREQDCO_MASK 0x000E
-#definePLL_SELFREQDCO_SHIFT0x1
-#definePLL_SD_MASK 0x0003FC00
-#definePLL_SD_SHIFT0x9
-#defineSET_PLL_GO  0x1
-#definePLL_TICOPWDN0x1
-#definePLL_LOCK0x2
-#definePLL_IDLE0x1
-
-#define USB3_PWRCTL_CLK_CMD_MASK   0x3FE000
-#define USB3_PWRCTL_CLK_FREQ_MASK  0xFFC
-#define USB3_PHY_PARTIAL_RX_POWERON (1 << 6)
-#define USB3_PHY_RX_POWERON(1 << 14)
-#define USB3_PHY_TX_POWERON(1 << 15)
-#define USB3_PHY_TX_RX_POWERON (USB3_PHY_RX_POWERON | USB3_PHY_TX_POWERON)
-#define USB3_PWRCTL_CLK_CMD_SHIFT   14
-#define USB3_PWRCTL_CLK_FREQ_SHIFT 22
-
-/* USBOTGSS_WRAPPER definitions */
-#define USBOTGSS_WRAPRESET (1 << 17)
-#define USBOTGSS_DMADISABLE (1 << 16)
-#define USBOTGSS_STANDBYMODE_NO_STANDBY (1 << 4)
-#define USBOTGSS_STANDBYMODE_SMRT  (1 << 5)
-#define USBOTGSS_STANDBYMODE_SMRT_WKUP (0x3 << 4)
-#define USBOTGSS_IDLEMODE_NOIDLE (1 << 2)
-#define USBOTGSS_IDLEMODE_SMRT (1 << 3)
-#define USBOTGSS_IDLEMODE_SMRT_WKUP (0x3 << 2)
-
-/* USBOTGSS_IRQENABLE_SET_0 bit */
-#define USBOTGSS_COREIRQ_EN(1 << 0)
-
-/* USBOTGSS_IRQENABLE_SET_1 bits */
-#define USBOTGSS_IRQ_SET_1_IDPULLUP_FALL_EN(1 << 0)
-#define USBOTGSS_IRQ_SET_1_DISCHRGVBUS_FALL_EN (1 << 3)
-#define USBOTGSS_IRQ_SET_1_CHRGVBUS_FALL_EN(1 << 4)
-#define USBOTGSS_IRQ_SET_1_DRVVBUS_FALL_EN (1 << 5)
-#define USBOTGSS_IRQ_SET_1_IDPULLUP_RISE_EN(1 << 8)
-#define USBOTGSS_IRQ_SET_1_DISCHRGVBUS_RISE_EN (1 << 11)
-#define USBOTGSS_IRQ_SET_1_CHRGVBUS_RISE_EN(1 << 12)
-#define USBOTGSS_IRQ_SET_1_DRVVBUS_RISE_EN (1 << 13)
-#define USBOTGSS_IRQ_SET_1_OEVT_EN (1 << 16)
-#define USBOTGSS_IRQ_SET_1_DMADISABLECLR_EN(1 << 17)
-
-/*
- * USBOTGSS_WRAPPER registers
- */
-struct omap_dwc_wrapper {
-   u32 revision;
-
-   u32 reserve_1[3];
-
-   u32 sysconfig; /* offset of 0x10 */
-
-   u32 reserve_2[3];
-   u16 reserve_3;
-
-   u32 irqstatus_raw_0; /* offset of 0x24 */
-   u32 irqstatus_0;
-   u32 irqenable_set_0;
-   u32 irqenable_clr_0;
-
-   u32 irqstatus_raw_1; /* offset of 0x34 */
-   u32 irqstatus_1;
-   u32 irqenable_set_1;
-   u32 irqenable_clr_1;
-
-   u32 reserve_4[15];
-
-   u32 utmi_otg_ctrl; /* offset of 0x80 */
-   u32 utmi_otg_status;
-
-   u32 reserve_5[30];
-
-   u32 mram_offset; /* offset of 0x100 */
-   u32 fladj;
-   u32 dbg_config;
-   u32 dbg_data;
-   u32 dev_ebc_en;
-};
-
-/* XHCI PHY register structure */
-struct omap_usb3_phy {
-   u32 reserve1;
-   u32 pll_status;
-   u32 pll_go;
-   u32 pll_config_1;
-   u32 pll_config_2;
-   u32 pll_config_3;
-   u32 pll_ssc_config_1;
-   u32 pll_ssc_config_2;
-   u32 pll_config_4;
-};
-
-struct omap_xhci {
-   struct omap_dwc_wrapper *otg_wrapper;
-   struct omap_usb3_phy *usb3_phy;
-   struct xhci_hccr *hcd;
-   struct dwc3 *dwc3_reg;
-};
-
-#endif /* _ASM_ARCH_XHCI_OMAP_H_ */
diff --git a/drivers/usb/host/xhci-omap.c b/drivers/usb/host/xhci-omap.c
index f4e41fd..a8702da 100644
--- a/drivers/usb/host/xhci-omap.c
+++ b/drivers/usb/host/xhci-omap.c
@@ -15,10 +15,10 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 #include 
+#include 
 
 #include "xhci.h"
 
diff --git a/include/linux/usb/xhci-omap.h b/include/linux/usb/xhci-omap.h
new file mode 100644
index 000..b557a43
--- /dev/null
+++ b/include/linux/usb/xhci-omap.h
@@

[U-Boot] [PATCH 3/6] usb: omap: Move the usb phy code to the usb/phy directory

[Dan Murphy]

Moving the usb/phy code from xhci-omap to the usb/phy directory
and moving the associated phy code over to the new file.

Newer TI processors adding xHCI support will have different PHY configurations
so therefore abstracting this code away will prevent messing around with the
xhci-omap file itself.

Signed-off-by: Dan Murphy 
---
 drivers/usb/host/xhci-omap.c   |  171 +-
 drivers/usb/phy/Makefile   |1 +
 drivers/usb/phy/omap_usb_phy.c |  197 
 include/linux/usb/xhci-omap.h  |6 ++
 4 files changed, 206 insertions(+), 169 deletions(-)
 create mode 100644 drivers/usb/phy/omap_usb_phy.c

diff --git a/drivers/usb/host/xhci-omap.c b/drivers/usb/host/xhci-omap.c
index 0093e63..513b9d8 100644
--- a/drivers/usb/host/xhci-omap.c
+++ b/drivers/usb/host/xhci-omap.c
@@ -27,161 +27,6 @@ DECLARE_GLOBAL_DATA_PTR;
 
 static struct omap_xhci omap;
 
-struct usb_dpll_params {
-   u16 m;
-   u8  n;
-   u8  freq:3;
-   u8  sd;
-   u32 mf;
-};
-
-#defineNUM_USB_CLKS6
-
-static struct usb_dpll_params omap_usb3_dpll_params[NUM_USB_CLKS] = {
-   {1250, 5, 4, 20, 0},/* 12 MHz */
-   {3125, 20, 4, 20, 0},   /* 16.8 MHz */
-   {1172, 8, 4, 20, 65537},/* 19.2 MHz */
-   {1250, 12, 4, 20, 0},   /* 26 MHz */
-   {3125, 47, 4, 20, 92843},   /* 38.4 MHz */
-   {1000, 7, 4, 10, 0},/* 20 MHz */
-};
-
-static void omap_usb_dpll_relock(struct omap_usb3_phy *phy_regs)
-{
-   u32 val;
-
-   writel(SET_PLL_GO, &phy_regs->pll_go);
-   do {
-   val = readl(&phy_regs->pll_status);
-   if (val & PLL_LOCK)
-   break;
-   } while (1);
-}
-
-static void omap_usb_dpll_lock(struct omap_usb3_phy *phy_regs)
-{
-   u32 clk_index = get_sys_clk_index();
-   u32 val;
-
-   val = readl(&phy_regs->pll_config_1);
-   val &= ~PLL_REGN_MASK;
-   val |= omap_usb3_dpll_params[clk_index].n << PLL_REGN_SHIFT;
-   writel(val, &phy_regs->pll_config_1);
-
-   val = readl(&phy_regs->pll_config_2);
-   val &= ~PLL_SELFREQDCO_MASK;
-   val |= omap_usb3_dpll_params[clk_index].freq << PLL_SELFREQDCO_SHIFT;
-   writel(val, &phy_regs->pll_config_2);
-
-   val = readl(&phy_regs->pll_config_1);
-   val &= ~PLL_REGM_MASK;
-   val |= omap_usb3_dpll_params[clk_index].m << PLL_REGM_SHIFT;
-   writel(val, &phy_regs->pll_config_1);
-
-   val = readl(&phy_regs->pll_config_4);
-   val &= ~PLL_REGM_F_MASK;
-   val |= omap_usb3_dpll_params[clk_index].mf << PLL_REGM_F_SHIFT;
-   writel(val, &phy_regs->pll_config_4);
-
-   val = readl(&phy_regs->pll_config_3);
-   val &= ~PLL_SD_MASK;
-   val |= omap_usb3_dpll_params[clk_index].sd << PLL_SD_SHIFT;
-   writel(val, &phy_regs->pll_config_3);
-
-   omap_usb_dpll_relock(phy_regs);
-}
-
-static void usb3_phy_partial_powerup(struct omap_usb3_phy *phy_regs)
-{
-   u32 rate = get_sys_clk_freq()/100;
-   u32 val;
-
-   val = readl((*ctrl)->control_phy_power_usb);
-   val &= ~(USB3_PWRCTL_CLK_CMD_MASK | USB3_PWRCTL_CLK_FREQ_MASK);
-   val |= (USB3_PHY_PARTIAL_RX_POWERON | USB3_PHY_TX_RX_POWERON);
-   val |= rate << USB3_PWRCTL_CLK_FREQ_SHIFT;
-
-   writel(val, (*ctrl)->control_phy_power_usb);
-}
-
-static void usb3_phy_power(int on)
-{
-   u32 val;
-
-   val = readl((*ctrl)->control_phy_power_usb);
-   if (on) {
-   val &= ~USB3_PWRCTL_CLK_CMD_MASK;
-   val |= USB3_PHY_TX_RX_POWERON;
-   } else {
-   val &= (~USB3_PWRCTL_CLK_CMD_MASK & ~USB3_PHY_TX_RX_POWERON);
-   }
-
-   writel(val, (*ctrl)->control_phy_power_usb);
-}
-
-static void dwc_usb3_phy_init(struct omap_usb3_phy *phy_regs)
-{
-   omap_usb_dpll_lock(phy_regs);
-
-   usb3_phy_partial_powerup(phy_regs);
-   /*
-* Give enough time for the PHY to partially power-up before
-* powering it up completely. delay value suggested by the HW
-* team.
-*/
-   mdelay(100);
-   usb3_phy_power(1);
-}
-
-static void omap_enable_phy_clocks(struct omap_xhci *omap)
-{
-   u32 val;
-
-   /* Setting OCP2SCP1 register */
-   setbits_le32((*prcm)->cm_l3init_ocp2scp1_clkctrl,
-OCP2SCP1_CLKCTRL_MODULEMODE_HW);
-
-   /* Turn on 32K AON clk */
-   setbits_le32((*prcm)->cm_coreaon_usb_phy_core_clkctrl,
-USBPHY_CORE_CLKCTRL_OPTFCLKEN_CLK32K);
-
-   /* Setting CM_L3INIT_CLKSTCTRL to 0x0 i.e NO sleep */
-   writel(0x0, (*prcm)->cm_l3init_clkstctrl);
-
-   val = (USBOTGSS_DMADISABLE |
-   USBOTGSS_STANDBYMODE_SMRT_WKUP |
-   USBOTGSS_IDLEMODE_NOIDLE);
-   writel(val, &omap->otg_wrapper->sysconfig);
-
-   /* Clear the utmi OTG status */
-   val = readl(&omap->otg_wrapper->utmi_otg_st

[U-Boot] TI xHCI updates

[Dan Murphy]

This patch series contains the following changes

- Moves the xhci-omap.h to a common location
- Fixes a compilation issue on OMAP5 when xHCI is defined when patch
"usb: new board-specific USB init interface" is applied
- Moves the TI USB PHY code out of the xhci-omap.c file and into
a new file called drivers/usb/phy/omap_usb_phy.c
- Enables the dra7xx xHCI controller
- Enables the AM437x xHCI controller
- Move OMAP5 MAC creation out of USB and into misc_init so that usbethaddr is
set on each boot or else the kernel sets a random MAC.


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

[U-Boot] [PATCH 6/6] ARM: omap5-evm: Move MAC creation to misc_init

[Dan Murphy]

Move the MAC creation from the USB init to an function
that is called on every boot.  This will then populate the
usbethaddr mac that kernel driver can pick up from the
device tree blob.

Signed-off-by: Dan Murphy 
---
 board/ti/omap5_uevm/evm.c |   39 ---
 1 file changed, 20 insertions(+), 19 deletions(-)

diff --git a/board/ti/omap5_uevm/evm.c b/board/ti/omap5_uevm/evm.c
index e85afdc..9d983ac 100644
--- a/board/ti/omap5_uevm/evm.c
+++ b/board/ti/omap5_uevm/evm.c
@@ -110,10 +110,30 @@ static void enable_host_clocks(void)
  */
 int misc_init_r(void)
 {
+   int reg;
+   uint8_t device_mac[6];
+
 #ifdef CONFIG_PALMAS_POWER
palmas_init_settings();
 #endif
 
+   if (!getenv("usbethaddr")) {
+   reg = DIE_ID_REG_BASE + DIE_ID_REG_OFFSET;
+
+   /*
+* create a fake MAC address from the processor ID code.
+* first byte is 0x02 to signify locally administered.
+*/
+   device_mac[0] = 0x02;
+   device_mac[1] = readl(reg + 0x10) & 0xff;
+   device_mac[2] = readl(reg + 0xC) & 0xff;
+   device_mac[3] = readl(reg + 0x8) & 0xff;
+   device_mac[4] = readl(reg) & 0xff;
+   device_mac[5] = (readl(reg) >> 8) & 0xff;
+
+   eth_setenv_enetaddr("usbethaddr", device_mac);
+   }
+
return 0;
 }
 
@@ -162,28 +182,9 @@ static struct omap_usbhs_board_data usbhs_bdata = {
 int ehci_hcd_init(int index, struct ehci_hccr **hccr, struct ehci_hcor **hcor)
 {
int ret;
-   int reg;
-   uint8_t device_mac[6];
 
enable_host_clocks();
 
-   if (!getenv("usbethaddr")) {
-   reg = DIE_ID_REG_BASE + DIE_ID_REG_OFFSET;
-
-   /*
-* create a fake MAC address from the processor ID code.
-* first byte is 0x02 to signify locally administered.
-*/
-   device_mac[0] = 0x02;
-   device_mac[1] = readl(reg + 0x10) & 0xff;
-   device_mac[2] = readl(reg + 0xC) & 0xff;
-   device_mac[3] = readl(reg + 0x8) & 0xff;
-   device_mac[4] = readl(reg) & 0xff;
-   device_mac[5] = (readl(reg) >> 8) & 0xff;
-
-   eth_setenv_enetaddr("usbethaddr", device_mac);
-   }
-
ret = omap_ehci_hcd_init(index, &usbhs_bdata, hccr, hcor);
if (ret < 0) {
puts("Failed to initialize ehci\n");
-- 
1.7.9.5

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

[U-Boot] [PATCH 2/6] usb: omap5: Change the board_usb_init api to board_xhci_usb_init

[Dan Murphy]

Recent patches declares board_usb_init function prototype for a new
usb architecture.

Turning on the OMAP_XHCI defines cause a redefinition compiler failure.
So rename the API from board_usb_init to board_xhci_usb_init.

Signed-off-by: Dan Murphy 
---
 board/ti/omap5_uevm/evm.c|4 ++--
 drivers/usb/host/xhci-omap.c |6 +++---
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/board/ti/omap5_uevm/evm.c b/board/ti/omap5_uevm/evm.c
index 228df29..e85afdc 100644
--- a/board/ti/omap5_uevm/evm.c
+++ b/board/ti/omap5_uevm/evm.c
@@ -214,12 +214,12 @@ void usb_hub_reset_devices(int port)
 
 #ifdef CONFIG_USB_XHCI_OMAP
 /**
- * @brief board_usb_init - Configure EVM board specific configurations
+ * @brief board_xhci_host_init - Configure EVM board specific configurations
  * for the LDO's and clocks for the USB blocks.
  *
  * @return 0
  */
-int board_usb_init(void)
+int board_xhci_host_init(void)
 {
int ret;
 #ifdef CONFIG_PALMAS_USB_SS_PWR
diff --git a/drivers/usb/host/xhci-omap.c b/drivers/usb/host/xhci-omap.c
index a8702da..0093e63 100644
--- a/drivers/usb/host/xhci-omap.c
+++ b/drivers/usb/host/xhci-omap.c
@@ -182,11 +182,11 @@ static void omap_enable_phy_clocks(struct omap_xhci *omap)
 
 };
 
-inline int __board_usb_init(void)
+inline int __board_xhci_host_init(void)
 {
return 0;
 }
-int board_usb_init(void) __attribute__((weak, alias("__board_usb_init")));
+int board_xhci_host_init(void) __attribute__((weak, 
alias("__board_xhci_host_init")));
 
 static void dwc3_set_mode(struct dwc3 *dwc3_reg, u32 mode)
 {
@@ -295,7 +295,7 @@ int xhci_hcd_init(int index, struct xhci_hccr **hccr, 
struct xhci_hcor **hcor)
ctx->usb3_phy = (struct omap_usb3_phy *)OMAP_OCP1_SCP_BASE;
ctx->otg_wrapper = (struct omap_dwc_wrapper *)OMAP_OTG_WRAPPER_BASE;
 
-   ret = board_usb_init();
+   ret = board_xhci_host_init();
if (ret != 0) {
puts("Failed to initialize board for USB\n");
return ret;
-- 
1.7.9.5

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

[U-Boot] U-Boot Regression Testing

[Curt Brune]

Hello,

I have some questions about how U-Boot regression testing works.  I am
assuming some regression testing happens during the release period
across some representative sample of boards and architectures.

I know people check for compilation failures with MAKEALL, but I am
wondering about runtime testing.  I also understand that testing
platform specific boot code is rather difficult (or easy depending on
your perspective) - it boots or it does not boot.

To be concrete -- how are core U-Boot commands and features tested?
For example how do you test that FIT image support is not broken or
that the 'env' command and all its options work properly?

Googling did not turn up much on how this is done.

On the social side -- is that something the community helps out with
or something DENX does, or a mix?

Are you using a test framework of some kind, either home grown or open
source?  These things tend to become home grown over time :)

This kind of testing usually takes the form of 'chat' scripts
communicating over serial consoles.  Perhaps you are using expect,
pexpect, python nose?

We have a project, of which U-Boot is a part, that is starting to span
multiple boards and architectures.  We make a few modifications to
U-Boot and I want to start automated regression testing as the number
of boards increases.

If an existing framework exists that folks are happy with I would love
to hear about it.  Equally, I am interested to hear about what did
*not* work for people.  Whatever method our project uses the scripts
will be publicly available.

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

Re: [U-Boot] [PATCH] SPDX: document dual license notation

[Stephen Warren]

On 10/08/2013 10:23 PM, Wolfgang Denk wrote:
> Dear Stephen,
> 
> In message <52546f78.40...@wwwdotorg.org> you wrote:
>>
>>> +Ideally, the license terms of all files in the source tree should be
>>> +defined by such License Identifiers; in no case a file can contain
>>> +more than one such License Identifier.
>>
>> I assume "one such License Identifier" here is intended to mean: a
>> source line prefixed with the words "SPDX-License-Identifier:". However,
>> to me "one such License Identifier" would actually refer to the
>> "GPL-2.0+" part of the line, since that's what actually identifies the
>> license. The other text simply introduces a list of license identifiers.
>> That would then conflict with the rest of the patch that goes on to
>> explicitly state that multiple licenses are allowed.
>>
>> In other words, I think that text can be confusing. I think you need to
>> add "line", "list" or "set" to the end of the sentence to make it
>> unambiguous.
> 
> Could you please suggest such a phrase?  Thanks.

Sigh. As I said: In other words, I think that text can be confusing. I
think you need to add "line", "list" or "set" to the end of the sentence
to make it unambiguous.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/4] Coding Style cleanup: replace leading SPACEs by TABs

[Tom Rini]

On Wed, Oct 09, 2013 at 09:33:53AM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Wed, Oct 9, 2013 at 9:29 AM, Tom Rini  wrote:
> 
> > On Wed, Oct 09, 2013 at 08:02:10PM +0900, Masahiro Yamada wrote:
> > > Hello, Wolfgang, Simon.
> > >
> > > (I added Cc Simon)
> > >
> > >
> > > >  tools/buildman/README  |  268 +--
> > > >  tools/buildman/board.py|  236 +-
> > > >  tools/buildman/bsettings.py|   18 +-
> > > >  tools/buildman/builder.py  | 2374
> > ++--
> > > >  tools/buildman/buildman.py |   16 +-
> > > >  tools/buildman/control.py  |  136 +-
> > > >  tools/buildman/test.py |  162 +-
> > > >  tools/buildman/toolchain.py|  392 ++--
> > >
> > > I might be too worried, but so many lines are going to be changed.
> > > Just in case, I hope Simon checks this.
> >
> > I'm not sure whacking the whitespace in quasi-external (I know patman is
> > used outside U-Boot, I forget about buildman) python tools is the right
> > way to go here.  Today the tools are consistent and space-only.  This
> > makes it mix-and-match.
> 
> patman also. The coding style I tried to follow for Python is PEP 8 - with
> spaces. At least it is consistent.

OK, yeah.  Wolfgang, please drop patman/buildman and
test/image/test-fit.py changes out of this.  reformat.py is consistently
using tabs, except for what you fixed, so that's fine.

If that's still a problem, we need to reformat the whole of the tool to
something tab-consistent instead, entirely.  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 2/4] Coding Style cleanup: replace leading SPACEs by TABs

[Simon Glass]

Hi Tom,

On Wed, Oct 9, 2013 at 9:29 AM, Tom Rini  wrote:

> On Wed, Oct 09, 2013 at 08:02:10PM +0900, Masahiro Yamada wrote:
> > Hello, Wolfgang, Simon.
> >
> > (I added Cc Simon)
> >
> >
> > >  tools/buildman/README  |  268 +--
> > >  tools/buildman/board.py|  236 +-
> > >  tools/buildman/bsettings.py|   18 +-
> > >  tools/buildman/builder.py  | 2374
> ++--
> > >  tools/buildman/buildman.py |   16 +-
> > >  tools/buildman/control.py  |  136 +-
> > >  tools/buildman/test.py |  162 +-
> > >  tools/buildman/toolchain.py|  392 ++--
> >
> > I might be too worried, but so many lines are going to be changed.
> > Just in case, I hope Simon checks this.
>
> I'm not sure whacking the whitespace in quasi-external (I know patman is
> used outside U-Boot, I forget about buildman) python tools is the right
> way to go here.  Today the tools are consistent and space-only.  This
> makes it mix-and-match.
>

patman also. The coding style I tried to follow for Python is PEP 8 - with
spaces. At least it is consistent.

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

Re: [U-Boot] [PATCH 2/4] Coding Style cleanup: replace leading SPACEs by TABs

[Tom Rini]

On Wed, Oct 09, 2013 at 08:02:10PM +0900, Masahiro Yamada wrote:
> Hello, Wolfgang, Simon.
> 
> (I added Cc Simon)
> 
> 
> >  tools/buildman/README  |  268 +--
> >  tools/buildman/board.py|  236 +-
> >  tools/buildman/bsettings.py|   18 +-
> >  tools/buildman/builder.py  | 2374 
> > ++--
> >  tools/buildman/buildman.py |   16 +-
> >  tools/buildman/control.py  |  136 +-
> >  tools/buildman/test.py |  162 +-
> >  tools/buildman/toolchain.py|  392 ++--
> 
> I might be too worried, but so many lines are going to be changed.
> Just in case, I hope Simon checks this.

I'm not sure whacking the whitespace in quasi-external (I know patman is
used outside U-Boot, I forget about buildman) python tools is the right
way to go here.  Today the tools are consistent and space-only.  This
makes it mix-and-match.

-- 
Tom


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

Re: [U-Boot] [PATCH] ARM: fdt support: Add usbethaddr as an acceptable MAC

[Dan Murphy]

All

On 10/02/2013 03:21 PM, Dan Murphy wrote:
> Tom
>
> On 10/02/2013 03:19 PM, Tom Rini wrote:
>> On Wed, Oct 02, 2013 at 03:14:26PM -0500, Dan Murphy wrote:
>>> Tom
>>>
>>> On 10/02/2013 02:19 PM, Tom Rini wrote:
 On Wed, Oct 02, 2013 at 02:00:15PM -0500, Dan Murphy wrote:

> A board that has a USB ethernet device only may set the usbetheraddr
> and not the ethaddr.
> ethaddr will be the default MAC address that is chosen and if that
> is not populated then the usbethaddr is looked at.  If neither are set
> then then device tree blob is not modified.
>
> Signed-off-by: Dan Murphy 
> ---
>  common/fdt_support.c |   12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/common/fdt_support.c b/common/fdt_support.c
> index b034c98..fef7e60 100644
> --- a/common/fdt_support.c
> +++ b/common/fdt_support.c
> @@ -450,8 +450,18 @@ void fdt_fixup_ethernet(void *fdt)
>   if (node < 0)
>   return;
>  
> + if (!getenv("ethaddr")) {
> + if (getenv("usbethaddr")) {
> + strcpy(mac, "usbethaddr");
> + } else {
> + debug("No ethernet MAC Address defined\n");
> + return;
> + }
> + } else {
> + strcpy(mac, "ethaddr");
> + }
> +
>   i = 0;
> - strcpy(mac, "ethaddr");
>   while ((tmp = getenv(mac)) != NULL) {
>   sprintf(enet, "ethernet%d", i);
>   path = fdt_getprop(fdt, node, enet, NULL);
 The problem is we may well have both.  I think we need to re-work the
 function slightly to be:
 while ((tmp = getenv(mac)) != NULL) {
   do_fdt_fixup_ethernet_x(tmp, fdt, node, enet, i)
 }
 if (getenv("usbethaddr"))
   do_fdt_fixup_ethernet_x("usbethaddr", fdt, ...)

 Where the name of the new function, and parameter order also makes sense
 and is complete of course.  Thanks!

>>> One issue with this approach is that we don't know which inteface in
>>> the dt is usb ethernet and which is not.  So correctly assigning the
>>> MAC to the correct inteface will be tricky.
>> Oh, that's true...  Maybe I should withdraw my objection, since we're
>> unlikely to really see both in production cases.
>>
>>> But the patch is flawed in the affect is that it does not take into
>>> account multiple usbethaddr either.  I will rework it for this but I
>>> am not sure about the other.
>> But we don't support that either, did a quick grep before posting.
>>
> Actually we do.  If you setenv eth1addr in the enviroment it will try to set 
> it in the dtb for the next ethernet instance.
>
> The other option is to set the ethaddr and then have usbethaddr reference 
> ethaddr and leave this code alone.
>
> Dan
>

Are there additional comments?
I currently do not have a V2 so I am assuming I have addressed all comments.

Please let me know.

Dan

-- 
--
Dan Murphy

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

[U-Boot] [PATCH 2/3] lcd: add DataImage SCF0403x LCD panel support

[Nikita Kiryanov]

Add SPI-based driver for DataImage SCF0403852GGU04 and SCF0403526GGU20
LCD panels.

Cc: Tom Rini 
Cc: Anatolij Gustschin 
Cc: Igor Grinberg 
Signed-off-by: Nikita Kiryanov 
---
 drivers/video/Makefile  |   1 +
 drivers/video/scf0403_lcd.c | 298 
 include/scf0403_lcd.h   |  22 
 include/spi.h   |   1 +
 4 files changed, 322 insertions(+)
 create mode 100644 drivers/video/scf0403_lcd.c
 create mode 100644 include/scf0403_lcd.h

diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 6c208c5..e7324d1 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -22,6 +22,7 @@ COBJS-$(CONFIG_FSL_DIU_FB) += fsl_diu_fb.o videomodes.o
 COBJS-$(CONFIG_L5F31188) += l5f31188.o
 COBJS-$(CONFIG_MPC8XX_LCD) += mpc8xx_lcd.o
 COBJS-$(CONFIG_PXA_LCD) += pxa_lcd.o
+COBJS-$(CONFIG_SCF0403_LCD) += scf0403_lcd.o
 COBJS-$(CONFIG_S6E8AX0) += s6e8ax0.o
 COBJS-$(CONFIG_S6E63D6) += s6e63d6.o
 COBJS-$(CONFIG_LD9040) += ld9040.o
diff --git a/drivers/video/scf0403_lcd.c b/drivers/video/scf0403_lcd.c
new file mode 100644
index 000..1d1c3ff
--- /dev/null
+++ b/drivers/video/scf0403_lcd.c
@@ -0,0 +1,298 @@
+/*
+ * scf0403.c -- support for DataImage SCF0403 LCD
+ *
+ * Copyright (c) 2013 Adapted from Linux driver:
+ * Copyright (c) 2012 Anders Electronics plc. All Rights Reserved.
+ * Copyright (c) 2012 CompuLab, Ltd
+ *   Dmitry Lifshitz 
+ *   Ilya Ledvich 
+ * Inspired by Alberto Panizzo  &
+ * Marek Vasut work in l4f00242t03.c
+ *
+ * U-Boot port: Nikita Kiryanov 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+
+struct scf0403_cmd {
+   u16 cmd;
+   u16 *params;
+   int count;
+};
+
+struct scf0403_initseq_entry {
+   struct scf0403_cmd cmd;
+   int delay_ms;
+};
+
+struct scf0403_priv {
+   struct spi_slave *spi;
+   unsigned int reset_gpio;
+   u32 rddid;
+   struct scf0403_initseq_entry *init_seq;
+   int seq_size;
+};
+
+struct scf0403_priv priv;
+
+#define SCF0403852GGU04_ID 0x80
+
+/* SCF0403526GGU20 model commands parameters */
+static u16 extcmd_params_sn20[]= {0xff, 0x98, 0x06};
+static u16 spiinttype_params_sn20[]= {0x60};
+static u16 bc_params_sn20[]= {
+   0x01, 0x10, 0x61, 0x74, 0x01, 0x01, 0x1B,
+   0x12, 0x71, 0x00, 0x00, 0x00, 0x01, 0x01,
+   0x05, 0x00, 0xFF, 0xF2, 0x01, 0x00, 0x40,
+};
+static u16 bd_params_sn20[] = {0x01, 0x23, 0x45, 0x67, 0x01, 0x23, 0x45, 0x67};
+static u16 be_params_sn20[] = {
+   0x01, 0x22, 0x22, 0xBA, 0xDC, 0x26, 0x28, 0x22, 0x22,
+};
+static u16 vcom_params_sn20[]  = {0x74};
+static u16 vmesur_params_sn20[]= {0x7F, 0x0F, 0x00};
+static u16 powerctl_params_sn20[]  = {0x03, 0x0b, 0x00};
+static u16 lvglvolt_params_sn20[]  = {0x08};
+static u16 engsetting_params_sn20[]= {0x00, 0x00, 0x00, 0x00, 0x00, 0x20};
+static u16 dispfunc_params_sn20[]  = {0xa0};
+static u16 dvddvolt_params_sn20[]  = {0x74};
+static u16 dispinv_params_sn20[]   = {0x00, 0x00, 0x00};
+static u16 panelres_params_sn20[]  = {0x82};
+static u16 framerate_params_sn20[] = {0x00, 0x13, 0x13};
+static u16 timing_params_sn20[]= {0x80, 0x05, 0x40, 0x28};
+static u16 powerctl2_params_sn20[] = {0x17, 0x75, 0x79, 0x20};
+static u16 memaccess_params_sn20[] = {0x00};
+static u16 pixfmt_params_sn20[]= {0x66};
+static u16 pgamma_params_sn20[]= {
+   0x00, 0x03, 0x0b, 0x0c, 0x0e, 0x08, 0xc5, 0x04,
+   0x08, 0x0c, 0x13, 0x11, 0x11, 0x14, 0x0c, 0x10,
+};
+static u16 ngamma_params_sn20[] = {
+   0x00, 0x0d, 0x11, 0x0c, 0x0c, 0x04, 0x76, 0x03,
+   0x08, 0x0b, 0x16, 0x10, 0x0d, 0x16, 0x0a, 0x00,
+};
+static u16 tearing_params_sn20[] = {0x00};
+
+/* SCF0403852GGU04 model commands parameters */
+static u16 memaccess_params_sn04[] = {0x08};
+static u16 pixfmt_params_sn04[]= {0x66};
+static u16 modectl_params_sn04[]   = {0x01};
+static u16 dispfunc_params_sn04[]  = {0x22, 0xe2, 0xFF, 0x04};
+static u16 vcom_params_sn04[]  = {0x00, 0x6A};
+static u16 pgamma_params_sn04[]= {
+   0x00, 0x07, 0x0d, 0x10, 0x13, 0x19, 0x0f, 0x0c,
+   0x05, 0x08, 0x06, 0x13, 0x0f, 0x30, 0x20, 0x1f,
+};
+static u16 ngamma_params_sn04[]= {
+   0x1F, 0x20, 0x30, 0x0F, 0x13, 0x06, 0x08, 0x05,
+   0x0C, 0x0F, 0x19, 0x13, 0x10, 0x0D, 0x07, 0x00,
+};
+static u16 dispinv_params_sn04[]   = {0x02};
+
+/* Common commands */
+static struct scf0403_cmd scf0403_cmd_slpout   = {0x11, NULL, 0};
+static struct scf0403_cmd scf0403_cmd_dison= {0x29, NULL, 0};
+
+/* SCF0403852GGU04 init sequence */
+st

[U-Boot] [PATCH 3/3] cm_t35: use scf0403 driver

[Nikita Kiryanov]

Use scf0403 driver to add scf0403x LCD support for cm-t35 and cm-t3730
boards.

Cc: Tom Rini 
Cc: Anatolij Gustschin 
Cc: Igor Grinberg 
Signed-off-by: Nikita Kiryanov 
---
NOTE: This patch depends on http://patchwork.ozlabs.org/patch/275283/

 arch/arm/include/asm/arch-omap3/dss.h |  9 ---
 board/compulab/cm_t35/cm_t35.c| 12 +
 board/compulab/common/omap3_display.c | 46 +--
 include/configs/cm_t35.h  |  3 +++
 4 files changed, 64 insertions(+), 6 deletions(-)

diff --git a/arch/arm/include/asm/arch-omap3/dss.h 
b/arch/arm/include/asm/arch-omap3/dss.h
index ae0babf..8bf6b48 100644
--- a/arch/arm/include/asm/arch-omap3/dss.h
+++ b/arch/arm/include/asm/arch-omap3/dss.h
@@ -178,10 +178,11 @@ struct venc_regs {
 #define LCD_INTERFACE_24_BIT   3
 
 /* Polarity */
-#define DSS_IVS(1 << 12)
-#define DSS_IHS(1 << 13)
-#define DSS_IPC(1 << 14)
-#define DSS_IEO(1 << 15)
+#define DSS_IVS(1 << 12)
+#define DSS_IHS(1 << 13)
+#define DSS_IPC(1 << 14)
+#define DSS_IEO(1 << 15)
+#define DSS_ONOFF  (1 << 17)
 
 /* GFX format */
 #define GFXFORMAT_BITMAP1  (0x0 << 1)
diff --git a/board/compulab/cm_t35/cm_t35.c b/board/compulab/cm_t35/cm_t35.c
index a6d4aba..51dd4a4 100644
--- a/board/compulab/cm_t35/cm_t35.c
+++ b/board/compulab/cm_t35/cm_t35.c
@@ -268,6 +268,9 @@ static void cm_t3x_set_common_muxconf(void)
/* DVI enable */
MUX_VAL(CP(GPMC_NCS3),  (IDIS  | PTU | DIS  | M4));/*GPMC_nCS3*/
 
+   /* DataImage backlight */
+   MUX_VAL(CP(GPMC_NCS7),  (IDIS  | PTU | DIS  | M4));/*GPIO_58*/
+
/* CM-T3x Ethernet */
MUX_VAL(CP(GPMC_NCS5),  (IDIS | PTU | DIS | M0)); /*GPMC_nCS5*/
MUX_VAL(CP(GPMC_CLK),   (IEN  | PTD | DIS | M4)); /*GPIO_59*/
@@ -374,6 +377,15 @@ static void cm_t3x_set_common_muxconf(void)
MUX_VAL(CP(MMC1_DAT1),  (IEN  | PTU | EN  | M0)); /*MMC1_DAT1*/
MUX_VAL(CP(MMC1_DAT2),  (IEN  | PTU | EN  | M0)); /*MMC1_DAT2*/
MUX_VAL(CP(MMC1_DAT3),  (IEN  | PTU | EN  | M0)); /*MMC1_DAT3*/
+
+   /* SPI */
+   MUX_VAL(CP(MCBSP1_CLKR),(IEN | PTD | DIS | M1)); /*MCSPI4_CLK*/
+   MUX_VAL(CP(MCBSP1_DX),  (IEN | PTD | DIS | M1)); /*MCSPI4_SIMO*/
+   MUX_VAL(CP(MCBSP1_DR),  (IEN | PTD | DIS | M1)); /*MCSPI4_SOMI*/
+   MUX_VAL(CP(MCBSP1_FSX), (IEN | PTU | EN  | M1)); /*MCSPI4_CS0*/
+
+   /* display controls */
+   MUX_VAL(CP(MCBSP1_FSR), (IDIS | PTU | DIS | M4)); /*GPIO_157*/
 }
 
 static void cm_t35_set_muxconf(void)
diff --git a/board/compulab/common/omap3_display.c 
b/board/compulab/common/omap3_display.c
index ead821e..61707f5 100644
--- a/board/compulab/common/omap3_display.c
+++ b/board/compulab/common/omap3_display.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 DECLARE_GLOBAL_DATA_PTR;
@@ -22,6 +23,7 @@ enum display_type {
NONE,
DVI,
DVI_CUSTOM,
+   DATA_IMAGE, /* #define CONFIG_SCF0403_LCD to use */
 };
 
 #define CMAP_ADDR  0x8010
@@ -119,6 +121,18 @@ static const struct panel_config preset_dvi_1280X1024 = {
.gfx_format = GFXFORMAT_RGB16,
 };
 
+static const struct panel_config preset_dataimage_480X800 = {
+   .lcd_size   = PANEL_LCD_SIZE(480, 800),
+   .timing_h   = DSS_HBP(2) | DSS_HFP(2) | DSS_HSW(2),
+   .timing_v   = DSS_VBP(17) | DSS_VFP(20) | DSS_VSW(3),
+   .pol_freq   = DSS_IVS | DSS_IHS | DSS_IPC | DSS_ONOFF,
+   .divisor= 10 | (1 << 10),
+   .data_lines = LCD_INTERFACE_18_BIT,
+   .panel_type = ACTIVE_DISPLAY,
+   .load_mode  = 2,
+   .gfx_format = GFXFORMAT_RGB16,
+};
+
 /*
  * set_resolution_params()
  *
@@ -146,6 +160,13 @@ static enum display_type set_dvi_preset(const struct 
panel_config preset,
return DVI;
 }
 
+static enum display_type set_dataimage_preset(const struct panel_config preset,
+   int x_res, int y_res)
+{
+   set_preset(preset, x_res, y_res);
+   return DATA_IMAGE;
+}
+
 /*
  * parse_mode() - parse the mode parameter of custom lcd settings
  *
@@ -369,6 +390,8 @@ static enum display_type env_parse_displaytype(char 
*displaytype)
return set_dvi_preset(preset_dvi_1280X960, 1280, 960);
else if (!strncmp(displaytype, "dvi1280x1024", 12))
return set_dvi_preset(preset_dvi_1280X1024, 1280, 1024);
+   else if (!strncmp(displaytype, "dataimage480x800", 16))
+   return set_dataimage_preset(preset_dataimage_480X800, 480, 800);
 
return NONE;
 }
@@ -401,12 +424,31 @@ void lcd_ctrl_init(void *lcdbase)
clrsetbits_le32(&prcm->clksel_dss, 0xF, 3);
 }
 
+#ifdef CONFIG_SCF0403_LCD
+static void scf0403_enable(void)
+{
+   gpio_direction_output(58, 1);
+   scf0403_init(157);
+}
+#else
+static in

[U-Boot] [PATCH 0/3] Add support for SPI based DataImage LCD panel

[Nikita Kiryanov]

This patch ports the Linux driver for DataImage SCF0403852GGU04 and
SCF0403526GGU20 LCD panels into U-Boot. As a preparation step, variable SPI word
length support is added to omap3_spi and the generic SPI interface.
Finally, the driver is used in cm_t35 board.

The SPI changes were tested with a Beagle I2C/SPI/MDIO Protocol Analyzer, and
also with a DataImage SCF0403 lcd as part of the DataImage driver test.

Patch number 3 depends on http://patchwork.ozlabs.org/patch/275283/

Cc: Tom Rini 
Cc: Anatolij Gustschin 
Cc: Igor Grinberg 
Cc: Jagannadha Sutradharudu Teki 

Nikita Kiryanov (3):
  spi: omap3: add support for more word lengths
  lcd: add DataImage SCF0403x LCD panel support
  cm_t35: use scf0403 driver

 arch/arm/include/asm/arch-omap3/dss.h |   9 +-
 board/compulab/cm_t35/cm_t35.c|  12 ++
 board/compulab/common/omap3_display.c |  46 +-
 drivers/spi/omap3_spi.c   |  78 +++--
 drivers/spi/omap3_spi.h   |  11 +-
 drivers/video/Makefile|   1 +
 drivers/video/scf0403_lcd.c   | 298 ++
 include/configs/cm_t35.h  |   3 +
 include/scf0403_lcd.h |  22 +++
 include/spi.h |  14 ++
 10 files changed, 467 insertions(+), 27 deletions(-)
 create mode 100644 drivers/video/scf0403_lcd.c
 create mode 100644 include/scf0403_lcd.h

-- 
1.8.1.2

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

[U-Boot] [PATCH 1/3] spi: omap3: add support for more word lengths

[Nikita Kiryanov]

Current implementation only supports 8 bit word lengths, even though
omap3 can handle anything between 4 and 32.

Update the spi interface to support changing the SPI word length,
and implement it in omap3_spi driver to support the full range of
possible word lengths.
This implementation is backwards compatible by defaulting to the old
behavior of 8 bit word lengths.
Also, it required a change to the omap3_spi non static I/O functions,
but since they are not used anywhere else, no collateral changes are required.

Cc: Tom Rini 
Cc: Igor Grinberg 
Cc: Jagannadha Sutradharudu Teki 
Signed-off-by: Nikita Kiryanov 
---
 drivers/spi/omap3_spi.c | 78 ++---
 drivers/spi/omap3_spi.h | 11 ---
 include/spi.h   | 13 +
 3 files changed, 81 insertions(+), 21 deletions(-)

diff --git a/drivers/spi/omap3_spi.c b/drivers/spi/omap3_spi.c
index 6bac245..add98e1 100644
--- a/drivers/spi/omap3_spi.c
+++ b/drivers/spi/omap3_spi.c
@@ -20,7 +20,7 @@
 #include 
 #include "omap3_spi.h"
 
-#define WORD_LEN   8
+#define SPI_DEFAULT_WORDLEN 8;
 #define SPI_WAIT_TIMEOUT 300;
 
 static void spi_reset(struct omap3_spi_slave *ds)
@@ -128,10 +128,32 @@ struct spi_slave *spi_setup_slave(unsigned int bus, 
unsigned int cs,
ds->regs = regs;
ds->freq = max_hz;
ds->mode = mode;
+   ds->wordlen = SPI_DEFAULT_WORDLEN;
 
return &ds->slave;
 }
 
+int spi_set_wordlen(struct spi_slave *slave, unsigned int wordlen)
+{
+   struct omap3_spi_slave *ds;
+   int chconf;
+
+   if (wordlen < 4 || wordlen > 32) {
+   printf("SPI error: unsupported wordlen %d\n", wordlen);
+   return -1;
+   }
+
+   ds = to_omap3_spi(slave);
+   ds->wordlen = wordlen;
+
+   chconf = readl(&ds->regs->channel[ds->slave.cs].chconf);
+   chconf &= ~OMAP3_MCSPI_CHCONF_WL_MASK;
+   chconf |= (wordlen - 1) << 7;
+   omap3_spi_write_chconf(ds, chconf);
+
+   return 0;
+}
+
 void spi_free_slave(struct spi_slave *slave)
 {
struct omap3_spi_slave *ds = to_omap3_spi(slave);
@@ -185,7 +207,7 @@ int spi_claim_bus(struct spi_slave *slave)
 
/* wordlength */
conf &= ~OMAP3_MCSPI_CHCONF_WL_MASK;
-   conf |= (WORD_LEN - 1) << 7;
+   conf |= (ds->wordlen - 1) << 7;
 
/* set chipselect polarity; manage with FORCE */
if (!(ds->mode & SPI_CS_HIGH))
@@ -223,7 +245,7 @@ void spi_release_bus(struct spi_slave *slave)
spi_reset(ds);
 }
 
-int omap3_spi_write(struct spi_slave *slave, unsigned int len, const u8 *txp,
+int omap3_spi_write(struct spi_slave *slave, unsigned int len, const void *txp,
unsigned long flags)
 {
struct omap3_spi_slave *ds = to_omap3_spi(slave);
@@ -250,7 +272,13 @@ int omap3_spi_write(struct spi_slave *slave, unsigned int 
len, const u8 *txp,
}
}
/* Write the data */
-   writel(txp[i], &ds->regs->channel[ds->slave.cs].tx);
+   unsigned int *tx = &ds->regs->channel[ds->slave.cs].tx;
+   if (ds->wordlen > 16)
+   writel(((u32 *)txp)[i], tx);
+   else if (ds->wordlen > 8)
+   writel(((u16 *)txp)[i], tx);
+   else
+   writel(((u8 *)txp)[i], tx);
}
 
 /* wait to finish of transfer */
@@ -268,7 +296,7 @@ int omap3_spi_write(struct spi_slave *slave, unsigned int 
len, const u8 *txp,
return 0;
 }
 
-int omap3_spi_read(struct spi_slave *slave, unsigned int len, u8 *rxp,
+int omap3_spi_read(struct spi_slave *slave, unsigned int len, void *rxp,
   unsigned long flags)
 {
struct omap3_spi_slave *ds = to_omap3_spi(slave);
@@ -302,7 +330,13 @@ int omap3_spi_read(struct spi_slave *slave, unsigned int 
len, u8 *rxp,
omap3_spi_set_enable(ds,OMAP3_MCSPI_CHCTRL_DIS);
 
/* Read the data */
-   rxp[i] = readl(&ds->regs->channel[ds->slave.cs].rx);
+   unsigned int *rx = &ds->regs->channel[ds->slave.cs].rx;
+   if (ds->wordlen > 16)
+   ((u32 *)rxp)[i] = readl(rx);
+   else if (ds->wordlen > 8)
+   ((u16 *)rxp)[i] = (u16)readl(rx);
+   else
+   ((u8 *)rxp)[i] = (u8)readl(rx);
}
 
if (flags & SPI_XFER_END) {
@@ -314,8 +348,8 @@ int omap3_spi_read(struct spi_slave *slave, unsigned int 
len, u8 *rxp,
 }
 
 /*McSPI Transmit Receive Mode*/
-int omap3_spi_txrx(struct spi_slave *slave,
-   unsigned int len, const u8 *txp, u8 *rxp, unsigned long flags)
+int omap3_spi_txrx(struct spi_slave *slave, unsigned int len,
+  const void *txp, void *rxp, unsigned long flags)
 {
struct omap3_spi_slave *ds = to_omap3_spi(slave);
int timeout = SPI_WAIT_TIMEOUT;
@@ -344,7 +378,13 @@ int omap3_spi_txrx(struct spi_slave *slave,
   

Re: [U-Boot] [ANN] v2013.10-rc4

[Tom Rini]

On Wed, Oct 09, 2013 at 10:12:19AM +0200, Holger Brunck wrote:
> Hi Tom,
> 
> On 10/02/2013 09:14 PM, Tom Rini wrote:
> > 
> > I've put v2013.10-rc4 out, only a little later than I had hoped, but I
> > wanted to get those PRs in for this.
> > uploaded soon.
> > 
> > At this point, we're just about ready to release so:
> > 1) If you have a bugfix outstand please let me know (I know about the
> > igep and pcm cpsw fixes, those are on my list)
> > 2) If something is broken, please shout!
> 
> there are some km83xx patches outstanding for this and for the last merge
> window. I guess that Kim is currently so busy that he don't find the time to
> pull them.
> 
> Can you pull them directly?  Unfortunately it is a little complicated.
> 
> Patches Part one which were planned to go in for v2013.07 are already
> sitting in Kims ppc83xx tree, see the lates two commits in this
> branch:
> 
> http://git.denx.de/?p=u-boot/u-boot-mpc83xx.git;a=shortlog;h=refs/heads/next
> 
> Patches part two are these commits:
> http://patchwork.ozlabs.org/patch/256906/
> http://patchwork.ozlabs.org/patch/256905/
> http://patchwork.ozlabs.org/patch/256903/
> http://patchwork.ozlabs.org/patch/256904/
> 
> Please note that all patches are only km board related and therefore
> there is no risk at all for other boards that they get in so late.

OK, I've grabbed these and done some local testing as well real quick,
it's all applied to u-boot/master now, 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] Tegra: T1x4: SPI: Use a common name (t1x4) for SPI driver

[Jagan Teki]

On Wed, Oct 9, 2013 at 2:49 AM, Stephen Warren  wrote:
> On 10/08/2013 12:23 AM, Jagan Teki wrote:
>> On Tue, Oct 8, 2013 at 2:50 AM, Tom Warren  wrote:
>>> Tegra124 is compatible w/T114 SPI, so try to commonize as
>>> much as possible.
> ... [ large patch quoted]
>>
>> Is it part of tegra.git?
>
> Please don't quote an entire patch just to ask a one-line question. It
> makes people waste their time reading through the entire patch trying to
> find out what you said.

OK, understand sorry for the consistence.
Will try to fix this for next time on-wards.

-- 
Thanks,
Jagan.

Jagannadha Sutradharudu Teki,
E: jagannadh.t...@gmail.com, P: +91-9676773388
Engineer - System Software Hacker
U-boot - SPI Custodian and Zynq APSOC
Ln: http://www.linkedin.com/in/jaganteki
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 06/10 V4] Exynos5420: Add base patch for SMDK5420

[Rajeshwari Birje]

Hi Simon,

I guess you meant decode_sromc and board_eth_init functions.
Will add them in board.c and send next version.

Regards,
Rajeshwari Shinde

On Tue, Oct 8, 2013 at 11:07 PM, Simon Glass  wrote:
> Hi Rajeshwari,
>
> On Fri, Sep 27, 2013 at 6:10 AM, Rajeshwari S Shinde <
> rajeshwar...@samsung.com> wrote:
>
>> Adding the base patch for Exynos based SMDK5420.
>> This shall enable compilation and basic boot support for
>> SMDK5420.
>>
>> Signed-off-by: Rajeshwari S Shinde 
>> Signed-off-by: Akshay Saraswat 
>> ---
>> Changes in V2:
>> - None
>> Changes in V3:
>> - None
>> Changes in V4:
>> - Rebased on latest u-boot-samsung tree.
>>  board/samsung/common/board.c  |   2 +
>>  board/samsung/smdk5420/Makefile   |  34 +
>>  board/samsung/smdk5420/smdk5420.c | 253
>> ++
>>  board/samsung/smdk5420/smdk5420_spl.c |  52 +++
>>  boards.cfg|   1 +
>>  tools/Makefile|   2 +
>>  6 files changed, 344 insertions(+)
>>  create mode 100644 board/samsung/smdk5420/Makefile
>>  create mode 100644 board/samsung/smdk5420/smdk5420.c
>>  create mode 100644 board/samsung/smdk5420/smdk5420_spl.c
>>
>> diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
>> index 7193c90..ce85ddb 100644
>> --- a/board/samsung/common/board.c
>> +++ b/board/samsung/common/board.c
>> @@ -139,6 +139,7 @@ struct cros_ec_dev *board_get_cros_ec_dev(void)
>> return local.cros_ec_dev;
>>  }
>>
>> +#ifdef CONFIG_CROS_EC
>>  static int board_init_cros_ec_devices(const void *blob)
>>  {
>> local.cros_ec_err = cros_ec_init(blob, &local.cros_ec_dev);
>> @@ -147,6 +148,7 @@ static int board_init_cros_ec_devices(const void *blob)
>>
>> return 0;
>>  }
>> +#endif
>>
>>  #if defined(CONFIG_POWER)
>>  #ifdef CONFIG_POWER_MAX77686
>> diff --git a/board/samsung/smdk5420/Makefile
>> b/board/samsung/smdk5420/Makefile
>> new file mode 100644
>> index 000..be538ec
>> --- /dev/null
>> +++ b/board/samsung/smdk5420/Makefile
>> @@ -0,0 +1,34 @@
>> +#
>> +# Copyright (C) 2013 Samsung Electronics
>> +#
>> +# SPDX-License-Identifier: GPL-2.0+
>> +#
>> +
>> +include $(TOPDIR)/config.mk
>> +
>> +LIB= $(obj)lib$(BOARD).o
>> +
>> +COBJS  += smdk5420_spl.o
>> +
>> +ifndef CONFIG_SPL_BUILD
>> +COBJS  += smdk5420.o
>> +endif
>> +
>> +SRCS   := $(SOBJS:.o=.S) $(COBJS:.o=.c)
>> +OBJS   := $(addprefix $(obj),$(COBJS) $(SOBJS))
>> +
>> +ALL:=   $(obj).depend $(LIB)
>> +
>> +all:   $(ALL)
>> +
>> +$(LIB):$(OBJS)
>> +   $(call cmd_link_o_target, $(OBJS))
>> +
>> +#
>> +
>> +# defines $(obj).depend target
>> +include $(SRCTREE)/rules.mk
>> +
>> +sinclude $(obj).depend
>> +
>> +#
>> diff --git a/board/samsung/smdk5420/smdk5420.c
>> b/board/samsung/smdk5420/smdk5420.c
>> new file mode 100644
>> index 000..cf76455
>> --- /dev/null
>> +++ b/board/samsung/smdk5420/smdk5420.c
>> @@ -0,0 +1,253 @@
>> +/*
>> + * Copyright (C) 2013 Samsung Electronics
>> + *
>> + * SPDX-License-Identifier:GPL-2.0+
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +DECLARE_GLOBAL_DATA_PTR;
>> +
>> +#ifdef CONFIG_USB_EHCI_EXYNOS
>> +static int board_usb_vbus_init(void)
>> +{
>> +   struct exynos5_gpio_part1 *gpio1 = (struct exynos5_gpio_part1 *)
>> +
>> samsung_get_base_gpio_part1();
>> +
>> +   /* Enable VBUS power switch */
>> +   s5p_gpio_direction_output(&gpio1->x2, 6, 1);
>> +
>> +   /* VBUS turn ON time */
>> +   mdelay(3);
>> +
>> +   return 0;
>> +}
>> +#endif
>> +
>> +int exynos_init(void)
>> +{
>> +#ifdef CONFIG_USB_EHCI_EXYNOS
>> +   board_usb_vbus_init();
>> +#endif
>> +   return 0;
>> +}
>> +
>> +static int decode_sromc(const void *blob, struct fdt_sromc *config)
>> +{
>> +   int err;
>> +   int node;
>> +
>> +   node = fdtdec_next_compatible(blob, 0,
>> COMPAT_SAMSUNG_EXYNOS5_SROMC);
>> +   if (node < 0) {
>> +   debug("Could not find SROMC node\n");
>> +   return node;
>> +   }
>> +
>> +   config->bank = fdtdec_get_int(blob, node, "bank", 0);
>> +   config->width = fdtdec_get_int(blob, node, "width", 2);
>> +
>> +   err = fdtdec_get_int_array(blob, node, "srom-timing",
>> config->timing,
>> +   FDT_SROM_TIMING_COUNT);
>> +   if (err < 0) {
>> +   debug("Could not decode SROMC configuration Error: %s\n",
>> + fdt_strerror(err));
>> +   return -FDT_ERR_NOTFOUND;
>> +   }
>> +   return 0;
>> +}
>> +
>> +int board_eth_init(bd_t *bis)
>> +{
>> +#ifdef CONFIG_SMC911X
>> +   u32 smc_bw_conf, smc_bc_c

Re: [U-Boot] [PATCH 09/10 V4] SPL: EXYNOS: Prepare for variable size SPL support

[Rajeshwari Birje]

Hi Simon,

We just have the binaries for BL1 which we receive with the product.

Regards,
Rajeshwari Shinde

On Tue, Oct 8, 2013 at 11:13 PM, Simon Glass  wrote:
> On Fri, Sep 27, 2013 at 6:10 AM, Rajeshwari S Shinde <
> rajeshwar...@samsung.com> wrote:
>
>> When variable size SPL is used, the BL1 expects the SPL to be
>> encapsulated differently: instead of putting the checksum at a fixed
>> offset in the SPL blob, prepend the blob with a header including the
>> size and the checksum.
>>
>> The enhancements include
>> - adding a command line option, '--vs' to indicate the need for the
>> variable size encapsulation
>> - padding the fixed size encapsulated blob with 0xff instead of
>> random
>> memory contents
>> - do not silently truncate the input file, report error instead
>> - no need to explicitly closing files/freeing memory, this all
>> happens
>> on exit; removing cleanups it makes code clearer
>> - profuse commenting
>> - modify Makefile to allow enabling the new feature per board
>>
>> Signed-off-by: Vadim Bendebury 
>> Signed-off-by: Rajeshwari S Shinde 
>>
>
> Acked-by: Simon Glass 
>
> Where is the new BL1 published, please?
>
> Regards,
> Simon
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>



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

Re: [U-Boot] [PATCH 2/4] Coding Style cleanup: replace leading SPACEs by TABs

[Masahiro Yamada]

Hello, Wolfgang, Simon.

(I added Cc Simon)


>  tools/buildman/README  |  268 +--
>  tools/buildman/board.py|  236 +-
>  tools/buildman/bsettings.py|   18 +-
>  tools/buildman/builder.py  | 2374 
> ++--
>  tools/buildman/buildman.py |   16 +-
>  tools/buildman/control.py  |  136 +-
>  tools/buildman/test.py |  162 +-
>  tools/buildman/toolchain.py|  392 ++--

I might be too worried, but so many lines are going to be changed.
Just in case, I hope Simon checks this.


Best Regards
Masahiro Yamada

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

Re: [U-Boot] [PATCH 1/4] arm64: Add tool to statically apply RELA relocations

[Albert ARIBAUD]

Hi Scott,

On Tue, 8 Oct 2013 11:22:15 -0500, Scott Wood 
wrote:

> On Tue, 2013-10-08 at 10:10 +0200, Albert ARIBAUD wrote:
> > Thanks Scott fot the heads-up. I have found the arm64 ABI and traced it
> > back to this URL:
> > 
> > 
> > 
> > (Somehow the document can be read in Firefox but evince chokes on it)
> 
> It works for me in evince 3.6.1.

Thanks. Mine is 3.10.0. Could be a regression.

> -Scott

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

Re: [U-Boot] [ANN] v2013.10-rc4

[Holger Brunck]

Hi Tom,

On 10/02/2013 09:14 PM, Tom Rini wrote:
> 
> I've put v2013.10-rc4 out, only a little later than I had hoped, but I
> wanted to get those PRs in for this.
> uploaded soon.
> 
> At this point, we're just about ready to release so:
> 1) If you have a bugfix outstand please let me know (I know about the
> igep and pcm cpsw fixes, those are on my list)
> 2) If something is broken, please shout!
> 

there are some km83xx patches outstanding for this and for the last merge
window. I guess that Kim is currently so busy that he don't find the time to
pull them.

Can you pull them directly?  Unfortunately it is a little complicated.

Patches Part one which were planned to go in for v2013.07 are already sitting in
Kims ppc83xx tree, see the lates two commits in this branch:

http://git.denx.de/?p=u-boot/u-boot-mpc83xx.git;a=shortlog;h=refs/heads/next

Patches part two are these commits:
http://patchwork.ozlabs.org/patch/256906/
http://patchwork.ozlabs.org/patch/256905/
http://patchwork.ozlabs.org/patch/256903/
http://patchwork.ozlabs.org/patch/256904/

Please note that all patches are only km board related and therefore there is no
risk at all for other boards that they get in so late.

Regards
Holger

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

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

[Rajeshwari Birje]

Hi Minkyu Kang,

Since this patch is related to arch/arm spi booting, I had a doubt
where would it get merged in u-boot-samsung.git or u-boot-spi.git.

This patch is based on "[U-Boot] [PATCH 4/4] spi: exynos: Support word
transfers" which is already merged in u-boot-spi.git.

Regards,
Rajeshwari Shinde.

On Tue, Oct 8, 2013 at 6:42 PM, Rajeshwari S 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.
>
> Signed-off-by: Alim Akhtar 
> Signed-off-by: Tom Wai-Hong Tam 
> Signed-off-by: Rajeshwari S Shinde 
> ---
> Based on following patch yet to be merged:
> "[U-Boot] [PATCH 4/4] spi: exynos: Support word transfers"
> Changes in V2:
> - Corrected the commit message.
> - Added a SPI timeout check.
> - Corrected the comments.
> Changes in V3:
> - Rebased on the latest u-boot-spi tree.
>  arch/arm/cpu/armv7/exynos/pinmux.c |   2 +-
>  arch/arm/cpu/armv7/exynos/spl_boot.c   | 122 
> -
>  arch/arm/include/asm/arch-exynos/spi.h |   1 +
>  include/configs/exynos5250-dt.h|   2 +
>  4 files changed, 123 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/cpu/armv7/exynos/pinmux.c 
> b/arch/arm/cpu/armv7/exynos/pinmux.c
> index 8002bce..74cc700 100644
> --- a/arch/arm/cpu/armv7/exynos/pinmux.c
> +++ b/arch/arm/cpu/armv7/exynos/pinmux.c
> @@ -462,7 +462,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/cpu/armv7/exynos/spl_boot.c 
> b/arch/arm/cpu/armv7/exynos/spl_boot.c
> index 3651c00..6faf13f 100644
> --- a/arch/arm/cpu/armv7/exynos/spl_boot.c
> +++ b/arch/arm/cpu/armv7/exynos/spl_boot.c
> @@ -10,8 +10,11 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
> +#include 
>
>  #include "common_setup.h"
>  #include "clock_init.h"
> @@ -59,6 +62,119 @@ static int config_branch_prediction(int set_cr_z)
>  }
>  #endif
>
> +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;
> +   }
> +   }
> +}
> +
> +/*
> + * Copy uboot from spi flash to RAM
> + *
> + * @parma uboot_size   size of u-boot to copy
> + * @param uboot_addr   address in u-boot to copy
> + */
> +static void exynos_spi_copy(unsigned int uboot_size, unsigned int uboot_addr)
> +{
> +   int upto, todo;
> +   int i, timeout = 100;
> +   struct exynos_spi *regs = (struct exynos_spi *)CONFIG_ENV_SPI_BASE;
> +
> +   set_spi_clk(PERIPH_ID_SPI1, 5000); /* set spi clock to 50Mhz */
> +   /* set the spi1 GPIO */
> +   exynos_pinmux_config(PERIPH_ID_SPI1, PINMUX_FLAG_NONE);
> +
> +   /* set pktcnt and enable it */
> +   writel(4 | SPI_PACKET_CNT_EN, ®s->pkt_cnt);
> +   /* set FB_CLK_SEL */
> +   writel(SPI_FB_DELAY_180, ®s->fb_clk);
> +   /* set CH_WIDTH and BUS_WIDTH as word */
> +   setbits_le32(®s->mode_cfg, SPI_MODE_CH_WIDTH_WORD |
> +   SPI_MODE_BUS_WIDTH_WORD);
> +   clrbits_le32(®s->ch_cfg, SPI_CH_CPOL_L); /* CPOL: active high */
> +
> +   /* clear rx and tx channel if set priveously */
> +   clrbits_le32(®s->ch_cfg, SPI_RX_CH_ON | SPI_TX_CH_ON);
> +
> +   setbits_le32(®s->swap_cfg, SPI_RX_SWAP_EN |
> +