date:20131011

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

2013-10-11 Thread Albert ARIBAUD

Hi Tom,

On Thu, 10 Oct 2013 18:52:57 -0400, Tom Rini  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 10/10/2013 06:10 PM, Scott Wood wrote:
> > On Thu, 2013-10-10 at 15:18 -0400, Tom Rini wrote:
> >> On 10/10/2013 03:00 PM, Albert ARIBAUD wrote:
> >>> On Thu, 10 Oct 2013 17:52:14 +0200, Albert ARIBAUD
> >>>  wrote:
> >>>
>  Hi Tom,
> 
>  On Thu, 10 Oct 2013 07:45:17 -0400, Tom Rini  wrote:
> 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On 10/10/2013 04:12 AM, Albert ARIBAUD wrote:
> >> Hi Tom,
> >>
> >> On Wed, 9 Oct 2013 21:45:25 -0400, Tom Rini  wrote:
> >>
> >>> 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?
> >>
> >> Builds OK on my side, both nand-flash/master and a merge of nf/master
> >> and u-boot/master, with gcc version 4.7.3 (Ubuntu/Linaro 
> >> 4.7.3-1ubuntu1)
> >>
> >> Tom, can you specify which toolchain shows the issue?
> >
> > Both ELDK 5.3 and Linaro 2013.03 (one TI has picked for some things) do
> > the above.  ELDK 5.2 is OK
> 
>  I'll test with ELDK5.3 in about an hour.
> >>>
> >>> I've installed eldk-eglibc-i686-arm-toolchain-gmae-5.3.sh and can build
> >>> am3517_crane on both nand-flash/master as well as on a merge of
> >>> u-boot/master and nand-flash/master
> >>
> >> Here we go, armhf toolchains trigger this problem because, I suspect, we
> >> aren't enforcing a flag to say "no, really, no hfp here" or similar.
> > 
> > Any idea why this patchset triggers it?  Does the 64-bit stuff cause
> > something from libgcc to be used that previously wasn't?  There is some
> > open-coded 64-bit division, but it's by a power of two so GCC should
> > convert it to a shift (and the ability to do 64-bit shifts was already
> > required by print_size()).
> 
> I'm not sure what parts of this math exactly cause things to go all
> nutty, but I suspect the answer is that we should be enforcing
> - -msomething or another than hf defaults to using (un)setting.

Ok, trying with the ARMhf toolchain.

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

Re: [U-Boot] [Patch v3] cmd/gpt: Support gpt command for all devices

2013-10-11 Thread Piotr Wilczek

Dear Egbert Eich,

> -Original Message-
> From: Egbert Eich [mailto:egbert.e...@gmail.com]
> Sent: Friday, October 04, 2013 6:53 PM
> To: u-boot@lists.denx.de
> Cc: Piotr Wilczek; Tom Rini; Egbert Eich; Egbert Eich
> Subject: [Patch v3] cmd/gpt: Support gpt command for all devices
> 
> From: Egbert Eich 
> 
> The gpt command was only implemented for mmc devices. There is no
> reason why this command should not be generalized and be applied all
> other storage device classes.
> This change both simplifies the implementation and eliminates a build
> failure for systems that don't support mmcs.
> 
> Signed-off-by: Egbert Eich 
> ---
> Changes for v2:
>- Coding style cleanup.
> Changes for v3:
>- Removed wrong '&'
>- Removed unused variable
>- Fixed argument checking
>Spotted by Piotr Wilczek 
> 
>  common/cmd_gpt.c | 45 +++--
>  1 file changed, 19 insertions(+), 26 deletions(-)
> 
> diff --git a/common/cmd_gpt.c b/common/cmd_gpt.c index a46f5cc..17b1180
> 100644
> --- a/common/cmd_gpt.c
> +++ b/common/cmd_gpt.c
> @@ -11,7 +11,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -122,7 +121,7 @@ static int set_gpt_info(block_dev_desc_t *dev_desc,
>   int errno = 0;
>   uint64_t size_ll, start_ll;
> 
> - debug("%s: MMC lba num: 0x%x %d\n", __func__,
> + debug("%s:  lba num: 0x%x %d\n", __func__,
> (unsigned int)dev_desc->lba, (unsigned int)dev_desc->lba);
> 
>   if (str_part == NULL)
> @@ -235,25 +234,18 @@ err:
>   return errno;
>  }
> 
> -static int gpt_mmc_default(int dev, const char *str_part)
> +static int gpt_default(block_dev_desc_t *blk_dev_desc, const char
> +*str_part)
>  {
>   int ret;
>   char *str_disk_guid;
>   u8 part_count = 0;
>   disk_partition_t *partitions = NULL;
> 
> - struct mmc *mmc = find_mmc_device(dev);
> -
> - if (mmc == NULL) {
> - printf("%s: mmc dev %d NOT available\n", __func__, dev);
> - return CMD_RET_FAILURE;
> - }
> -
>   if (!str_part)
>   return -1;
> 
>   /* fill partitions */
> - ret = set_gpt_info(&mmc->block_dev, str_part,
> + ret = set_gpt_info(blk_dev_desc, str_part,
>   &str_disk_guid, &partitions, &part_count);
>   if (ret) {
>   if (ret == -1)
> @@ -266,7 +258,7 @@ static int gpt_mmc_default(int dev, const char
> *str_part)
>   }
> 
>   /* save partitions layout to disk */
> - gpt_restore(&mmc->block_dev, str_disk_guid, partitions,
> part_count);
> + gpt_restore(blk_dev_desc, str_disk_guid, partitions, part_count);
>   free(str_disk_guid);
>   free(partitions);
> 
> @@ -287,27 +279,28 @@ static int do_gpt(cmd_tbl_t *cmdtp, int flag, int
> argc, char * const argv[])  {
>   int ret = CMD_RET_SUCCESS;
>   int dev = 0;
> - char *pstr;
> 
>   if (argc < 5)
>   return CMD_RET_USAGE;
> 
>   /* command: 'write' */
>   if ((strcmp(argv[1], "write") == 0) && (argc == 5)) {
> - /* device: 'mmc' */
> - if (strcmp(argv[2], "mmc") == 0) {
> - /* check if 'dev' is a number */
> - for (pstr = argv[3]; *pstr != '\0'; pstr++)
> - if (!isdigit(*pstr)) {
> - printf("'%s' is not a number\n",
> - argv[3]);
> - return CMD_RET_USAGE;
> - }
> - dev = (int)simple_strtoul(argv[3], NULL, 10);
> - /* write to mmc */
> - if (gpt_mmc_default(dev, argv[4]))
> - return CMD_RET_FAILURE;
> + char *ep;
> + block_dev_desc_t *blk_dev_desc;
This probably should be at the beginning of the function

> + dev = (int)simple_strtoul(argv[3], &ep, 10);
> + if (!ep || ep[0] != '\0') {
> + printf("'%s' is not a number\n", argv[3]);
> + return CMD_RET_USAGE;
>   }
> + blk_dev_desc = get_dev(argv[2], dev);
> + if (!blk_dev_desc) {
> + printf("%s: %s dev %d NOT available\n",
> +__func__, argv[2], dev);
I think it is not necessary since the mmc subsystem prints 'MMC Device not
found'.

> + return CMD_RET_FAILURE;
> + }
> +
> + if (gpt_default(blk_dev_desc, argv[4]))
> + return CMD_RET_FAILURE;
>   } else {
>   return CMD_RET_USAGE;
>   }
> --
> 1.8.1.4

Except minor comments this patch looks good to me.
I tested it on mmc device (Trats2) and works well.

Tested-by: Piotr Wilczek 

Best regards,
Piotr Wilczek


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

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

2013-10-11 Thread Zhao Qiang

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
Changes for v4:
-rebase on u-boot master branch

 arch/powerpc/include/asm/fsl_pci.h | 18 ---
 drivers/pci/fsl_pci_init.c | 44 +++---
 drivers/pci/pci.c  | 65 ++
 include/pci.h  | 10 ++
 4 files changed, 107 insertions(+), 30 deletions(-)

diff --git a/arch/powerpc/include/asm/fsl_pci.h 
b/arch/powerpc/include/asm/fsl_pci.h
index 749411c..5be718b 100644
--- a/arch/powerpc/include/asm/fsl_pci.h
+++ b/arch/powerpc/include/asm/fsl_pci.h
@@ -18,24 +18,6 @@
 /* Freescale-specific PCI config registers */
 #define FSL_PCI_PBFR   0x44
 
-#ifdef 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 */
-#endif
-
 #define FSL_PCIE_CFG_RDY   0x4b0
 #define FSL_PROG_IF_AGENT  0x1
 
diff --git a/drivers/pci/fsl_pci_init.c b/drivers/pci/fsl_pci_init.c
index d55db1a..1c202ca 100644
--- a/drivers/pci/fsl_pci_init.c
+++ b/drivers/pci/fsl_pci_init.c
@@ -295,6 +295,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);
@@ -367,7 +376,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 */
@@ -406,15 +420,16 @@ void fsl_pci_init(struct pci_controller *hose, struct 
fsl_pci_info *pci_info)
 * - Master PERR (pci)
 * - ICCA (PCIe)
 */
-   pci_hose_read_config_dword(hose, dev, PCI_DCR, &temp32);
+   pci_hose_read_config_dword(hose, dev, pci_dcr, &temp32);
temp32 |= 0xf000e;  /* set URR, FER, NFER (but not CER) */
-   pci_hose_write_config_dword(hose, dev, PCI_DCR, temp32);
+   pci_hose_write_config_dword(hose, dev, pci_dcr, temp32);
 
 #if defined(CONFIG_FSL_PCIE_DISABLE_ASPM)
+   pci_lcr = pcie_cap_pos + 0x10;
temp32 = 0;
-   pci_hose_read_config_dword(hose, dev, PCI_LCR, &temp32);
+   pci_hose_read_config_dword(hose, dev, pci_lcr, &temp32);
temp32 &= ~0x03;/* Disable ASPM  */
-   pci_hose_write_config_dword(hose, dev, PCI_LCR, temp32);
+   pci_hose_write_config_dword(hose, dev, pci_lcr, temp32);
udelay(1);
 #endif
if (pcie_cap == PCI_CAP_ID_EXP) {
@@ -494,7 +509,7 @@ void fsl_pci_init(struct pci_controller *hose, struct 
fsl_pci_info *pci_info)
out_be32(&pci->pme_msg_int_en, 0x);

[U-Boot] [PATCH 1/2] README: I2C: Fix indent

2013-10-11 Thread Nobuhiro Iwamatsu

Signed-off-by: Nobuhiro Iwamatsu 
---
 README | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/README b/README
index cee8e2f..77d2e80 100644
--- a/README
+++ b/README
@@ -1987,16 +1987,16 @@ CBFS (Coreboot Filesystem) support
offset CONFIG_SYS_FSL_I2C_SPEED for the i2c speed and
CONFIG_SYS_FSL_I2C_SLAVE for the slave addr of the first
bus.
-  - If your board supports a second fsl i2c bus, define
+ - If your board supports a second fsl i2c bus, define
CONFIG_SYS_FSL_I2C2_OFFSET for the register offset
CONFIG_SYS_FSL_I2C2_SPEED for the speed and
CONFIG_SYS_FSL_I2C2_SLAVE for the slave address of the
second bus.
 
- drivers/i2c/tegra_i2c.c:
-- activate this driver with CONFIG_SYS_I2C_TEGRA
-- This driver adds 4 i2c buses with a fix speed from
-  10 and the slave addr 0!
+ - activate this driver with CONFIG_SYS_I2C_TEGRA
+ - This driver adds 4 i2c buses with a fix speed from
+   10 and the slave addr 0!
 
- drivers/i2c/ppc4xx_i2c.c
  - activate this driver with CONFIG_SYS_I2C_PPC4XX
-- 
1.8.4.rc3

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

[U-Boot] [PATCH 2/2] i2c: sh_i2c: Avoid using I2C prior to relocation

2013-10-11 Thread Nobuhiro Iwamatsu

If user uses the I2C in before the relocation, board of sh and rmobile
will not start. This will solve this problem.

Signed-off-by: Nobuhiro Iwamatsu 
---
 drivers/i2c/sh_i2c.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/sh_i2c.c b/drivers/i2c/sh_i2c.c
index 58f8bf1..808202c 100644
--- a/drivers/i2c/sh_i2c.c
+++ b/drivers/i2c/sh_i2c.c
@@ -1,6 +1,6 @@
 /*
- * Copyright (C) 2011 Renesas Solutions Corp.
- * Copyright (C) 2011 Nobuhiro Iwamatsu 
+ * Copyright (C) 2011, 2013 Renesas Solutions Corp.
+ * Copyright (C) 2011, 2013 Nobuhiro Iwamatsu 

  *
  * SPDX-License-Identifier:GPL-2.0+
  */
@@ -8,6 +8,8 @@
 #include 
 #include 
 
+DECLARE_GLOBAL_DATA_PTR;
+
 /* Every register is 32bit aligned, but only 8bits in size */
 #define ureg(name) u8 name; u8 __pad_##name##0; u16 __pad_##name##1;
 struct sh_i2c {
@@ -240,6 +242,10 @@ void i2c_init(int speed, int slaveaddr)
 {
int num, denom, tmp;
 
+   /* No i2c support prior to relocation */
+   if (!(gd->flags & GD_FLG_RELOC))
+   return;
+
 #ifdef CONFIG_I2C_MULTI_BUS
current_bus = 0;
 #endif
-- 
1.8.4.rc3

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

Re: [U-Boot] U-Boot Regression Testing

2013-10-11 Thread Lukasz Majewski

Hi Curt,

Sorry for late reply.

> 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 can only present my approach - I test the board (TRATS) often before
the official u-boot release.

I don't have any list of commands to test -> I just test the ones often
used (mm) or the one to which I contribute (pmic, dfu, ums).

> 
> 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?

As with DFU or UMS - I have got an automated test script for HOST PC to
test if data (including corner cases data size) is written and read
correctly from the eMMC medium. However those tests require typing "dfu
mmc 0" or "ums 0" commands on the target.

This posts reminds me that I shall post them

> 
> 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 :)

I think that such scripts shall be added to ./test directory.

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

Unfortunately I don't use serial console. I even thought of writing a
special USB gadget (or extent DFU) to provide a convenient way to test
if e.g. eMMC write works:

- Read file from FS via e.g. ext4load
- Calculate CRC (crc)
- Store the file with other name
- Read it 
- Calculate CRC and compare

I'm also curious how other perform their tests. Since I _really_ want
to avoid over-engineered solution. Maybe someone do it better, simpler?

> 
> 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.

As I have written above. The best approach would be to use only board
under test and host PC. 
However it might be necessary to use the uC based "interface" board [1]
connected to HOST PC to perform power cycle (when we cannot use
u-boot's "reset" command).

> 
> If an existing framework exists that folks are happy with I would love
> to hear about it. 

+1 here

> Equally, I am interested to hear about what did
> *not* work for people. 

I would like to avoid using the [1]. And night run tests would be also
very welcome.

> Whatever method our project uses the scripts
> will be publicly available.
> 
> Cheers,
> Curt



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] omap3 usb boot

2013-10-11 Thread Michael Trimarchi

Hi Tom

I have managed to boot dm3730 on usb (first stage), but looking at the code
I have some comment

in arch/arm/cpu/armv7/omap3/clock.c

#ifdef CONFIG_SYS_NS16550
/* Enable UART1 clocks */
sr32(&prcm_base->fclken1_core, 13, 1, 0x1);
sr32(&prcm_base->iclken1_core, 13, 1, 0x1);

/* UART 3 Clocks */
sr32(&prcm_base->fclken_per, 11, 1, 0x1);
sr32(&prcm_base->iclken_per, 11, 1, 0x1);

You enable clock for two uarts without take in account the real console uart
of the device. Then some lines after

sr32(&prcm_base->fclken_per, 0, 32, FCK_PER_ON);
sr32(&prcm_base->iclken_per, 0, 32, ICK_PER_ON);

That just reset all the clock using the PER_ON mask so what is done before
doesn't make sense anymore.

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

[U-Boot] sandbox is broken

2013-10-11 Thread Masahiro Yamada

Hello Wolfgang, Simon


I cannot build sandbox for the current u-boot/master.
Could you check please?


The error is like this:

cmd_sandbox.c: In function 'do_sandbox_load':
cmd_sandbox.c:13:2: error: too many arguments to function 'do_load'
In file included from cmd_sandbox.c:8:0:
/home/yamada/workspace/eclipse/u-boot/include/fs.h:61:5: note: declared here
cmd_sandbox.c: In function 'do_sandbox_save':
cmd_sandbox.c:25:2: error: too many arguments to function 'do_save'
In file included from cmd_sandbox.c:8:0:
/home/yamada/workspace/eclipse/u-boot/include/fs.h:65:5: note: declared here
make[2]: *** [cmd_sandbox.o] Error 1
make[2]: Leaving directory `/home/yamada/workspace/eclipse/u-boot/common'
make[1]: *** [common/libcommon.o] Error 2
make[1]: Leaving directory `/home/yamada/workspace/eclipse/u-boot'
make: *** [sandbox] Error 2



It looks like this error was caused by the following commit.



commit b770e88a6c2548727f0d57a3e9e8bb0830f977b5
Author: Wolfgang Denk 
Date:   Sat Oct 5 21:07:25 2013 +0200

Fix number base handling of "load" command






Best Regards
Masahiro Yamada

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

[U-Boot] Suggestion for building all boards

2013-10-11 Thread Masahiro Yamada

Hello experts, custodians.


U-Boot Wiki page (http://www.denx.de/wiki/U-Boot/Patches)
says like follows:

> Before sending the patch, you must run the MAKEALL script on your patched 
> source tree
> and make sure that no errors or warnings are reported for any of the boards.
> Well, at least not any more warnings than without your patch.


For sending a patch that changes across all architectures,
we need to build all target boards.
(I am really eager to do this, for example, Kbuild-related patches,
a new warning option, etc.)


In stead of ./MAKEALL, we can also use  tools/buildman/buildman
for the same purpose.

But getting suitable toolchains is beyond the scope of them.

I want to focus on this issue.



My question is:
Where can I get suitable toolchains for all architectures
supported by U-Boot?


Gerhard Sittig told me this site:
ftp://ftp.kernel.org/pub/tools/crosstool/

But I could not get the crosstool for some architectures
(nds32, nios2) in this site.

I tried to compile as much boards as possible with crosstools
I could download from the site.

arm, avr32, sandbox, x86 are perfect!
I successfully compiled all board without any warnings.

For the other architectures, I can't compile at least some boards.

This means the toolchain I chose was not appropriate
or a bug in the source code.


So, I'd like to suggest:
We collect pre-built toolchains for all architectures on U-Boot ftp site.
They become RECOMMENDED toolchans, which means it is garanteed
all boards should be successfully compiled with such toolchains.

At least custodians must have a suitable toolchain
because they routinely build boards of their assigned architecture.
If it is impossible to upload it to U-Boot ftp site,
the link should be prepared to another download site.

If there are some variations (for ex. soft/hard float)
for supported cross tools, all of them should be collected.


My basic idea is:
Building all boards should be easy enough for everyone.
Of course basic skills of U-boot is required,
but arch-specific skills should not be required
just for compile.

If everyone can do this compiling check,
it should be done automatically.
The crontab daemon can do it and
send the result to this mailing list.
(everyday? once a week? every time u-boot/master is updated?)

We will soon notice a broken board
before someone raise the flag.
When a board is found to be broken,
notification e-mail should also be sent to
the architecture custodian and
board maintainer (if the board is not orphan).

The board maintainer (written in boards.cfg)
is responsible to fix the broken board.
The custodian should guide this.

Now we have the Active/Orphan status in the first
column of boards.cfg.

I'd like to suggest new status:

Active: can be compiled without any warnings
Warn:   still can be compiled, but with warnings
Broken: cannot be compiled

Suggestion for better terms is welcome :-)

(BTW, I'd like to abolish Orphan status.
We can refer the last column for the board maintainer.
If it is blank, it means unknown maintainer.)

If we notice a newly broken board, we should
change the status in boards.cfg
from Active to Warn or Broken.

If nobody fix the board for a long time (3 month or so?),
it should go to the scrap yard.


To sum up my suggestion,

 - Collect pre-built suitable crosstools for all architectures
   on U-boot ftp site.

 - Check all boards automatically using those recommended
   crosstools and post the result to the mailing list.

 - Add new status to boards.cfg to mark boards with a problem.


Best Regards
Masahiro

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

Re: [U-Boot] Suggestion for building all boards

2013-10-11 Thread Stefan Roese

Hi Masahiro,

On 11.10.2013 13:29, Masahiro Yamada wrote:
> My question is:
> Where can I get suitable toolchains for all architectures
> supported by U-Boot?
> 
> 
> Gerhard Sittig told me this site:
> ftp://ftp.kernel.org/pub/tools/crosstool/
> 
> But I could not get the crosstool for some architectures
> (nds32, nios2) in this site.
> 
> I tried to compile as much boards as possible with crosstools
> I could download from the site.
> 
> arm, avr32, sandbox, x86 are perfect!
> I successfully compiled all board without any warnings.
> 
> For the other architectures, I can't compile at least some boards.

Mike Frysinger (unfortunately not active with U-Boot development any
more) did some work on cross-toolchain builds. With nice and small
packages. Please take a look at this thread:

http://marc.info/?l=u-boot&m=132164771013203&w=1

Here a link to the binaries:

http://dev.gentoo.org/~vapier/u-boot/

Its a bit outdated, but better than nothing. Perhaps its possible to
generate more current toolchain versions easily? Mike?

> This means the toolchain I chose was not appropriate
> or a bug in the source code.
> 
> 
> So, I'd like to suggest:
> We collect pre-built toolchains for all architectures on U-Boot ftp site.
> They become RECOMMENDED toolchans, which means it is garanteed
> all boards should be successfully compiled with such toolchains.

Its usually recommended to use the ELDK toolchains. But yes, not all
architectures are supported right now.

> At least custodians must have a suitable toolchain
> because they routinely build boards of their assigned architecture.
> If it is impossible to upload it to U-Boot ftp site,
> the link should be prepared to another download site.
> 
> If there are some variations (for ex. soft/hard float)
> for supported cross tools, all of them should be collected.
> 
> 
> My basic idea is:
> Building all boards should be easy enough for everyone.
> Of course basic skills of U-boot is required,
> but arch-specific skills should not be required
> just for compile.
> 
> If everyone can do this compiling check,
> it should be done automatically.
> The crontab daemon can do it and
> send the result to this mailing list.
> (everyday? once a week? every time u-boot/master is updated?)
> 
> We will soon notice a broken board
> before someone raise the flag.
> When a board is found to be broken,
> notification e-mail should also be sent to
> the architecture custodian and
> board maintainer (if the board is not orphan).
> 
> The board maintainer (written in boards.cfg)
> is responsible to fix the broken board.
> The custodian should guide this.
> 
> Now we have the Active/Orphan status in the first
> column of boards.cfg.
> 
> I'd like to suggest new status:
> 
> Active: can be compiled without any warnings
> Warn:   still can be compiled, but with warnings
> Broken: cannot be compiled
> 
> Suggestion for better terms is welcome :-)
> 
> (BTW, I'd like to abolish Orphan status.
> We can refer the last column for the board maintainer.
> If it is blank, it means unknown maintainer.)
> 
> If we notice a newly broken board, we should
> change the status in boards.cfg
> from Active to Warn or Broken.
> 
> If nobody fix the board for a long time (3 month or so?),
> it should go to the scrap yard.

I like this idea.

> To sum up my suggestion,
> 
>  - Collect pre-built suitable crosstools for all architectures
>on U-boot ftp site.

Perhaps Mike's work can be used as a starting point for this?

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

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

2013-10-11 Thread Albert ARIBAUD

On Fri, 11 Oct 2013 09:11:52 +0200, Albert ARIBAUD
 wrote:

> Hi Tom,
> 
> On Thu, 10 Oct 2013 18:52:57 -0400, Tom Rini  wrote:
> 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> > 
> > On 10/10/2013 06:10 PM, Scott Wood wrote:
> > > On Thu, 2013-10-10 at 15:18 -0400, Tom Rini wrote:
> > >> On 10/10/2013 03:00 PM, Albert ARIBAUD wrote:
> > >>> On Thu, 10 Oct 2013 17:52:14 +0200, Albert ARIBAUD
> > >>>  wrote:
> > >>>
> >  Hi Tom,
> > 
> >  On Thu, 10 Oct 2013 07:45:17 -0400, Tom Rini  wrote:
> > 
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA1
> > >
> > > On 10/10/2013 04:12 AM, Albert ARIBAUD wrote:
> > >> Hi Tom,
> > >>
> > >> On Wed, 9 Oct 2013 21:45:25 -0400, Tom Rini  wrote:
> > >>
> > >>> 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?
> > >>
> > >> Builds OK on my side, both nand-flash/master and a merge of nf/master
> > >> and u-boot/master, with gcc version 4.7.3 (Ubuntu/Linaro 
> > >> 4.7.3-1ubuntu1)
> > >>
> > >> Tom, can you specify which toolchain shows the issue?
> > >
> > > Both ELDK 5.3 and Linaro 2013.03 (one TI has picked for some things) 
> > > do
> > > the above.  ELDK 5.2 is OK
> > 
> >  I'll test with ELDK5.3 in about an hour.
> > >>>
> > >>> I've installed eldk-eglibc-i686-arm-toolchain-gmae-5.3.sh and can build
> > >>> am3517_crane on both nand-flash/master as well as on a merge of
> > >>> u-boot/master and nand-flash/master
> > >>
> > >> Here we go, armhf toolchains trigger this problem because, I suspect, we
> > >> aren't enforcing a flag to say "no, really, no hfp here" or similar.
> > > 
> > > Any idea why this patchset triggers it?  Does the 64-bit stuff cause
> > > something from libgcc to be used that previously wasn't?  There is some
> > > open-coded 64-bit division, but it's by a power of two so GCC should
> > > convert it to a shift (and the ability to do 64-bit shifts was already
> > > required by print_size()).
> > 
> > I'm not sure what parts of this math exactly cause things to go all
> > nutty, but I suspect the answer is that we should be enforcing
> > - -msomething or another than hf defaults to using (un)setting.
> 
> Ok, trying with the ARMhf toolchain.

Even using the gnueabihf ELDK 5.3 toolchain, I still can build
am3517_crane with no problem.

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

Re: [U-Boot] sandbox is broken

2013-10-11 Thread Tom Rini

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/11/2013 06:51 AM, Masahiro Yamada wrote:
> Hello Wolfgang, Simon
> 
> 
> I cannot build sandbox for the current u-boot/master.
> Could you check please?
> 
> 
> The error is like this:
> 
> cmd_sandbox.c: In function 'do_sandbox_load':
> cmd_sandbox.c:13:2: error: too many arguments to function 'do_load'
> In file included from cmd_sandbox.c:8:0:
> /home/yamada/workspace/eclipse/u-boot/include/fs.h:61:5: note: declared here
> cmd_sandbox.c: In function 'do_sandbox_save':
> cmd_sandbox.c:25:2: error: too many arguments to function 'do_save'
> In file included from cmd_sandbox.c:8:0:
> /home/yamada/workspace/eclipse/u-boot/include/fs.h:65:5: note: declared here
> make[2]: *** [cmd_sandbox.o] Error 1
> make[2]: Leaving directory `/home/yamada/workspace/eclipse/u-boot/common'
> make[1]: *** [common/libcommon.o] Error 2
> make[1]: Leaving directory `/home/yamada/workspace/eclipse/u-boot'
> make: *** [sandbox] Error 2
> 
> 
> 
> It looks like this error was caused by the following commit.

Yes, I posted a patch for this just yesterday, I think.  I know I fixed
it locally yesterday and intended to post it..

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

iQIcBAEBAgAGBQJSV/OvAAoJENk4IS6UOR1WhHMP/1oIojozpISKBh5ruD7Aj4ot
K5yJylCjHhQHyjPFuj3praw34BWj+yUTgxmLstaP+Uyfbc54B1fDYm39tR6Cv7nM
nH91Azw3n18XZHvle94LbAcV2oo7suwPVWLbhWVsIhduKi16B4oMeTb3no7Vs/gQ
/h69Yjz5zbiLB3NlRHCnngvp9qUqRU4cUjFhiGVEAjOr+EFAVbg6jlKo8/50UMdr
oT1ahKTXLcf7bIyJ3dBVAuTGfYUPEVdji9bTQA+sp7gA/hY0gzdqtI1LNA9w3p1E
YAbJt0wTzxqtCLTDlebpwHcbnG5KIy4Vx9MJce4aljwZe+CJATLmXIVKdRGWOKt8
0CJ1PC975owLk33cjnsGVtbN+2E5fVt8mZMkzRjK5/AK/HQVzBjT5bJBMngSarXO
qdX3J5R2tAHPdeBvQluqN0egJVjgRGiokKVNakh5SehpoX2bGv3i8U3zypzLNfcO
ij2QU3mzO8RpZjrR2fHsVOjOqlG8VFb1bIDJlXv3lO2kTSlG2FBSqynkCug2eMda
qWi/vOnPG/MsTXEFqIppQ6A8jt+UDKQCPLaMruMX69zpxxlUbbncaaim5iIgQhSQ
Q+84BqWD0JMMxsYInay8JSnAiCNUK4JTAx3mYdabXMvuDeoYW7BAhrRgY+dr3drb
YAGEAXyr6vYZZEpRjfeO
=Ut4f
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] disk:efi: avoid unaligned access on efi partition

2013-10-11 Thread Piotr Wilczek

In this patch static variable and memcpy instead of an assignment
are used to avoid unaligned access exception on some ARM platforms.

Signed-off-by: Piotr Wilczek 
Signed-off-by: Kyungmin Park 
CC: Tom Rini 
---
 disk/part_efi.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/disk/part_efi.c b/disk/part_efi.c
index b7524d6..303b8af 100644
--- a/disk/part_efi.c
+++ b/disk/part_efi.c
@@ -224,7 +224,8 @@ static int set_protective_mbr(block_dev_desc_t *dev_desc)
p_mbr->signature = MSDOS_MBR_SIGNATURE;
p_mbr->partition_record[0].sys_ind = EFI_PMBR_OSTYPE_EFI_GPT;
p_mbr->partition_record[0].start_sect = 1;
-   p_mbr->partition_record[0].nr_sects = (u32) dev_desc->lba;
+   memcpy(&p_mbr->partition_record[0].nr_sects, &dev_desc->lba,
+  sizeof(dev_desc->lba));
 
/* Write MBR sector to the MMC device */
if (dev_desc->block_write(dev_desc->dev, 0, 1, p_mbr) != 1) {
@@ -387,8 +388,9 @@ int gpt_fill_pte(gpt_header *gpt_h, gpt_entry *gpt_e,
gpt_e[i].ending_lba = cpu_to_le64(offset - 1);
 
/* partition type GUID */
+   static efi_guid_t basic_guid = PARTITION_BASIC_DATA_GUID;
memcpy(gpt_e[i].partition_type_guid.b,
-   &PARTITION_BASIC_DATA_GUID, 16);
+   &basic_guid, 16);
 
 #ifdef CONFIG_PARTITION_UUIDS
str_uuid = partitions[i].uuid;
-- 
1.7.9.5

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

[U-Boot] [PATCH] fs:fat: fix set file name function

2013-10-11 Thread Piotr Wilczek

Curently memcpy copies string without null terminating char because
function strlen returns only number of characters excluding
null terminating character. Replace memcpy with strcpy.

Signed-off-by: Piotr Wilczek 
Signed-off-by: Kyungmin Park 
CC: Tom Rini 
---
 fs/fat/fat_write.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c
index b7a21e0..9f5e911 100644
--- a/fs/fat/fat_write.c
+++ b/fs/fat/fat_write.c
@@ -57,7 +57,7 @@ static void set_name(dir_entry *dirent, const char *filename)
if (len == 0)
return;
 
-   memcpy(s_name, filename, len);
+   strcpy(s_name, filename);
uppercase(s_name, len);
 
period = strchr(s_name, '.');
-- 
1.7.9.5

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

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

2013-10-11 Thread Albert ARIBAUD

Hi Minkyu,

On Thu, 10 Oct 2013 10:46:19 +0900, Minkyu Kang 
wrote:

> 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

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

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

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

2013-10-11 Thread Albert ARIBAUD

Hello Tom,

The following changes since commit
572886af5984febafa6f083e6b8af0465f4f5764:

  socfpga: Adding pin mux handoff files (2013-10-07 19:32:30 +0200)

are available in the git repository at:

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

for you to fetch changes up to 5a9120439416a9101dec7c7dc65bb75a5ff09c4e:

  Merge branch 'u-boot-samsung/master' into
  'u-boot-arm/master' (2013-10-11 14:47:25 +0200)



Albert ARIBAUD (1):
  Merge branch 'u-boot-samsung/master' into 'u-boot-arm/master'

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

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

[U-Boot] [RFC] [PATCH] [NEXT] arm: keep all sections in ELF file

2013-10-11 Thread Albert ARIBAUD

(foreword: this is an RFC, and in any case, not intended for
the upcoming 2013.10 release :) therefore I put notes here in the
commit message whereas the first actual patch will have notes below
the comment ('---') line of course.)

Current LDS files /DISCARD/ a lot of sections when linking ELF
files, causing diagnostic tools such as readelf or objdump to
produce partial output. Keep all section at link stage, filter
only at objcopy time so that .bin remains minimal.

NOTES:

*Please test*! :)

While the build reports show slightly text/data/bss/size
increases, .bin sizes are actually slightly reduced. Go figure.

I have not modified the x86 and MIPS lds files, which still /DISCARD/
unwanted sections. If the maintainers (Cc:ed) wish that I include their
lds files in the patch, just let me know (and please test, too).

The added line in Makefile is there only to help testing: it generates
an ELF version of u-boot.bin called u-boot.bin.elf in which you can see
which sections were kept and where they are supposed to map. This will
not be present in the actual patch.

Signed-off-by: Albert ARIBAUD 
Cc: Simon Glass  
Cc: Daniel Schwierzeck 
---
 Makefile|  1 +
 arch/arm/config.mk  |  3 +++
 arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds   | 16 +---
 arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds | 16 +---
 arch/arm/cpu/ixp/u-boot.lds | 15 +--
 arch/arm/cpu/u-boot-spl.lds | 15 +--
 arch/arm/cpu/u-boot.lds | 19 +++
 board/actux1/u-boot.lds | 15 +--
 board/actux2/u-boot.lds | 15 +--
 board/actux3/u-boot.lds | 15 +--
 board/dvlhost/u-boot.lds| 15 +--
 board/freescale/mx31ads/u-boot.lds  | 18 +-
 board/ti/am335x/u-boot.lds  | 15 +--
 board/vpac270/u-boot-spl.lds| 18 +-
 14 files changed, 114 insertions(+), 82 deletions(-)

diff --git a/Makefile b/Makefile
index 7d62f38..aa60f1a 100644
--- a/Makefile
+++ b/Makefile
@@ -432,6 +432,7 @@ $(obj)u-boot.srec:  $(obj)u-boot
 
 $(obj)u-boot.bin:  $(obj)u-boot
$(OBJCOPY) ${OBJCFLAGS} -O binary $< $@
+   $(OBJCOPY) ${OBJCFLAGS} $< $@.elf
$(BOARD_SIZE_CHECK)
 
 $(obj)u-boot.ldr:  $(obj)u-boot
diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index d0cf43f..7d1b049 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -103,3 +103,6 @@ ALL-y += checkarmreloc
 # such usage by requiring word relocations.
 PLATFORM_CPPFLAGS += $(call cc-option, -mword-relocations)
 endif
+
+# limit ourselves to the sections we want in the .bin.
+OBJCFLAGS += -j .text -j .rodata -j .data -j .u_boot_list -j .rel.dyn
diff --git a/arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds 
b/arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds
index 40bcc31..80fb9bd 100644
--- a/arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds
+++ b/arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds
@@ -51,11 +51,13 @@ SECTIONS
 
_end = .;
 
-   /DISCARD/ : { *(.dynstr*) }
-   /DISCARD/ : { *(.dynsym*) }
-   /DISCARD/ : { *(.dynamic*) }
-   /DISCARD/ : { *(.hash*) }
-   /DISCARD/ : { *(.plt*) }
-   /DISCARD/ : { *(.interp*) }
-   /DISCARD/ : { *(.gnu*) }
+   .dynsym _end : { *(.dynsym) }
+   .dynbss : { *(.dynbss) }
+   .dynstr : { *(.dynstr*) }
+   .dynamic : { *(.dynamic*) }
+   .hash : { *(.hash*) }
+   .plt : { *(.plt*) }
+   .interp : { *(.interp*) }
+   .gnu : { *(.gnu*) }
+   .ARM.exidx : { *(.ARM.exidx*) }
 }
diff --git a/arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds 
b/arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds
index 4927736..76b499d 100644
--- a/arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds
+++ b/arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds
@@ -51,11 +51,13 @@ SECTIONS
 
_end = .;
 
-   /DISCARD/ : { *(.dynstr*) }
-   /DISCARD/ : { *(.dynsym*) }
-   /DISCARD/ : { *(.dynamic*) }
-   /DISCARD/ : { *(.hash*) }
-   /DISCARD/ : { *(.plt*) }
-   /DISCARD/ : { *(.interp*) }
-   /DISCARD/ : { *(.gnu*) }
+   .dynsym _end : { *(.dynsym) }
+   .dynbss : { *(.dynbss) }
+   .dynstr : { *(.dynstr*) }
+   .dynamic : { *(.dynamic*) }
+   .hash : { *(.hash*) }
+   .plt : { *(.plt*) }
+   .interp : { *(.interp*) }
+   .gnu : { *(.gnu*) }
+   .ARM.exidx : { *(.ARM.exidx*) }
 }
diff --git a/arch/arm/cpu/ixp/u-boot.lds b/arch/arm/cpu/ixp/u-boot.lds
index c8d2e12..676ae2c 100644
--- a/arch/arm/cpu/ixp/u-boot.lds
+++ b/arch/arm/cpu/ixp/u-boot.lds
@@ -79,10 +79,13 @@ SECTIONS
KEEP(*(.__bss_end));
}
 
-   /DISCARD/ : { *(.dynsym) }
-   /DISCARD/ : { *(.dynstr*) }
-   /DISCARD/ : { *(.dynamic*) }
-   /DISCARD/ : { *(.plt*) }
-   /DISCARD/ : { *(.interp*) }
-   /

Re: [U-Boot] [PATCH] disk:efi: avoid unaligned access on efi partition

2013-10-11 Thread Albert ARIBAUD

Hi Piotr,

On Fri, 11 Oct 2013 15:31:10 +0200, Piotr Wilczek
 wrote:

> In this patch static variable and memcpy instead of an assignment
> are used to avoid unaligned access exception on some ARM platforms.
> 
> Signed-off-by: Piotr Wilczek 
> Signed-off-by: Kyungmin Park 
> CC: Tom Rini 
> ---
>  disk/part_efi.c |6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/disk/part_efi.c b/disk/part_efi.c
> index b7524d6..303b8af 100644
> --- a/disk/part_efi.c
> +++ b/disk/part_efi.c
> @@ -224,7 +224,8 @@ static int set_protective_mbr(block_dev_desc_t *dev_desc)
>   p_mbr->signature = MSDOS_MBR_SIGNATURE;
>   p_mbr->partition_record[0].sys_ind = EFI_PMBR_OSTYPE_EFI_GPT;
>   p_mbr->partition_record[0].start_sect = 1;
> - p_mbr->partition_record[0].nr_sects = (u32) dev_desc->lba;
> + memcpy(&p_mbr->partition_record[0].nr_sects, &dev_desc->lba,
> +sizeof(dev_desc->lba));
>  
>   /* Write MBR sector to the MMC device */
>   if (dev_desc->block_write(dev_desc->dev, 0, 1, p_mbr) != 1) {
> @@ -387,8 +388,9 @@ int gpt_fill_pte(gpt_header *gpt_h, gpt_entry *gpt_e,
>   gpt_e[i].ending_lba = cpu_to_le64(offset - 1);
>  
>   /* partition type GUID */
> + static efi_guid_t basic_guid = PARTITION_BASIC_DATA_GUID;
>   memcpy(gpt_e[i].partition_type_guid.b,
> - &PARTITION_BASIC_DATA_GUID, 16);
> + &basic_guid, 16);

Usually, an all-caps symbol is a macro, which makes taking its address
a no-no.

Besides, doing a memcpy() for 32-bit quantities seems like overkill
for me. Any reason you cannot simply use asm/unaligned.h and either
get_unaligned or put_unaligned depending on where the alignment issue
lies?
 
>  #ifdef CONFIG_PARTITION_UUIDS
>   str_uuid = partitions[i].uuid;

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

[U-Boot] [PATCH v4] powerpc/p1010rdb: update readme for p1010rdb-pa and p1010rdb-pb

2013-10-11 Thread Shengzhou Liu

- Remove duplicate doc/README.p1010rdb
- Rename README to README.P1010RDB-PA
- Add new README.P1010RDB-PB

P1010RDB-PB is a variation of previous P1010RDB-PA board.

Signed-off-by: Shengzhou Liu 
---
v4: keep readme support for p1010rdb-pa
v3: add frequency combination support
v2: removed duplicate doc/README.p1010rdb

 board/freescale/p1010rdb/README |  208 ---
 board/freescale/p1010rdb/README.P1010RDB-PA |  208 +++
 board/freescale/p1010rdb/README.P1010RDB-PB |  188 
 doc/README.p1010rdb |  199 -
 4 files changed, 396 insertions(+), 407 deletions(-)
 delete mode 100644 board/freescale/p1010rdb/README
 create mode 100644 board/freescale/p1010rdb/README.P1010RDB-PA
 create mode 100644 board/freescale/p1010rdb/README.P1010RDB-PB
 delete mode 100644 doc/README.p1010rdb

diff --git a/board/freescale/p1010rdb/README b/board/freescale/p1010rdb/README
deleted file mode 100644
index 7f18aaa..000
--- a/board/freescale/p1010rdb/README
+++ /dev/null
@@ -1,208 +0,0 @@
-Overview
-=
-The P1010RDB is a Freescale reference design board that hosts the P1010 SoC.
-
-The P1010 is a cost-effective, low-power, highly integrated host processor
-based on a Power Architecture e500v2 core (maximum core frequency 800/1000 
MHz),
-that addresses the requirements of several routing, gateways, storage, 
consumer,
-and industrial applications. Applications of interest include the main CPUs and
-I/O processors in network attached storage (NAS), the voice over IP (VoIP)
-router/gateway, and wireless LAN (WLAN) and industrial controllers.
-
-The P1010RDB board features are as follows:
-Memory subsystem:
-   - 1Gbyte unbuffered DDR3 SDRAM discrete devices (32-bit bus)
-   - 32 Mbyte NOR flash single-chip memory
-   - 32 Mbyte NAND flash memory
-   - 256 Kbit M24256 I2C EEPROM
-   - 16 Mbyte SPI memory
-   - I2C Board EEPROM 128x8 bit memory
-   - SD/MMC connector to interface with the SD memory card
-Interfaces:
-   - PCIe:
-   - Lane0: x1 mini-PCIe slot
-   - Lane1: x1 PCIe standard slot
-   - SATA:
-   - 1 internal SATA connector to 2.5â 160G SATA2 HDD
-   - 1 eSATA connector to rear panel
-   - 10/100/1000 BaseT Ethernet ports:
-   - eTSEC1, RGMII: one 10/100/1000 port using Vitesse VSC8641XKO
-   - eTSEC2, SGMII: one 10/100/1000 port using Vitesse VSC8221
-   - eTSEC3, SGMII: one 10/100/1000 port using Vitesse VSC8221
-   - USB 2.0 port:
-   - x1 USB2.0 port via an external ULPI PHY to micro-AB connector
-   - x1 USB2.0 port via an internal UTMI PHY to micro-AB connector
-   - FlexCAN ports:
-   - 2 DB-9 female connectors for FlexCAN bus(revision 2.0B)
- interface;
-   - DUART interface:
-   - DUART interface: supports two UARTs up to 115200 bps for
-  console display
-   - RJ45 connectors are used for these 2 UART ports.
-   - TDM
-   - 2 FXS ports connected via an external SLIC to the TDM 
interface.
- SLIC is controllled via SPI.
-   - 1 FXO port connected via a relay to FXS for switchover to POTS
-Board connectors:
-   - Mini-ITX power supply connector
-   - JTAG/COP for debugging
-IEEE Std. 1588 signals for test and measurement
-Real-time clock on I2C bus
-POR
-   - support critical POR setting changed via switch on board
-PCB
-   - 6-layer routing (4-layer signals, 2-layer power and ground)
-
-
-Physical Memory Map on P1010RDB
-===
-Address Start   Address End   Memory type  Attributes
-0x_0x3fff_   DDR   1G Cacheable
-0xa000_0xdfff_   PCI Express Mem   1G non-cacheable
-0xee00_0xefff_   NOR Flash 32M non-cacheable
-0xffc2_0xffc5_   PCI IO range  256K non-cacheable
-0xffa0_0xffaf_   NAND Flash1M cacheable
-0xffb0_0xffbf_   Board CPLD1M non-cacheable
-0xffd0_0xffd0_3fff   L1 for Stack  16K Cacheable TLB0
-0xffe0_0xffef_   CCSR  1M non-cacheable
-
-
-Serial Port Configuration on P1010RDB
-=
-Configure the serial port of the attached computer with the following values:
-   -Data rate: 115200 bps
-   -Number of data bits: 8
-   -Parity: None
-   -Number of Stop bits: 1
-   -Flow Control: Hardware/None
-
-
-Settings of DIP-switch
-==
-  SW4[1:4]=  and SW6[4]=0 for boot from 16bit NOR flash
-  SW4[1:4]= 1000 and SW6[4]=1 for boot from 8bit NAND flash
-  SW4[1:4]= 0110 and SW6[4]=0 for boot from SPI flash
-Note: 1 stands for 'on', 0 stands for 'off'
-
-
-Setting of hwconfig
-===
-If FlexCAN or TDM is needed, please set "fsl_p1010mux:td

Re: [U-Boot] [RFC] [PATCH] [NEXT] arm: keep all sections in ELF file

2013-10-11 Thread Daniel Schwierzeck

2013/10/11 Albert ARIBAUD :
> (foreword: this is an RFC, and in any case, not intended for
> the upcoming 2013.10 release :) therefore I put notes here in the
> commit message whereas the first actual patch will have notes below
> the comment ('---') line of course.)
>
> Current LDS files /DISCARD/ a lot of sections when linking ELF
> files, causing diagnostic tools such as readelf or objdump to
> produce partial output. Keep all section at link stage, filter
> only at objcopy time so that .bin remains minimal.
>
> NOTES:
>
> *Please test*! :)
>
> While the build reports show slightly text/data/bss/size
> increases, .bin sizes are actually slightly reduced. Go figure.
>
> I have not modified the x86 and MIPS lds files, which still /DISCARD/
> unwanted sections. If the maintainers (Cc:ed) wish that I include their
> lds files in the patch, just let me know (and please test, too).

good idea. I've pushed an initial patch for MIPS to u-boot-mips/testing.
I'll do some testing on weekend.

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

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

2013-10-11 Thread 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 
---

v2 - Reformatted patch with -M - http://patchwork.ozlabs.org/patch/281933/

 drivers/usb/host/xhci-omap.c   |2 +-
 .../arch-omap5 => include/linux/usb}/xhci-omap.h   |0
 2 files changed, 1 insertion(+), 1 deletion(-)
 rename {arch/arm/include/asm/arch-omap5 => include/linux/usb}/xhci-omap.h 
(100%)

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/arch/arm/include/asm/arch-omap5/xhci-omap.h 
b/include/linux/usb/xhci-omap.h
similarity index 100%
rename from arch/arm/include/asm/arch-omap5/xhci-omap.h
rename to include/linux/usb/xhci-omap.h
-- 
1.7.9.5

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

[U-Boot] [PATCH v2 2/6] usb: omap5: Update the board_usb_init api

2013-10-11 Thread 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 update the board_usb_init to the latest prototype.

Signed-off-by: Dan Murphy 
---

v2 - Adopted to board_usb_init and not create a new API - 
http://patchwork.ozlabs.org/patch/281931/

 board/ti/omap5_uevm/evm.c|2 +-
 drivers/usb/host/xhci-omap.c |7 ---
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/board/ti/omap5_uevm/evm.c b/board/ti/omap5_uevm/evm.c
index 228df29..6a01200 100644
--- a/board/ti/omap5_uevm/evm.c
+++ b/board/ti/omap5_uevm/evm.c
@@ -219,7 +219,7 @@ void usb_hub_reset_devices(int port)
  *
  * @return 0
  */
-int board_usb_init(void)
+int board_usb_init(int index, enum board_usb_init_type init)
 {
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..4f98c77 100644
--- a/drivers/usb/host/xhci-omap.c
+++ b/drivers/usb/host/xhci-omap.c
@@ -182,11 +182,12 @@ static void omap_enable_phy_clocks(struct omap_xhci *omap)
 
 };
 
-inline int __board_usb_init(void)
+inline int __board_usb_init(int index, enum board_usb_init_type init)
 {
return 0;
 }
-int board_usb_init(void) __attribute__((weak, alias("__board_usb_init")));
+int board_usb_init(int index, enum board_usb_init_type init) \
+   __attribute__((weak, alias("__board_usb_init")));
 
 static void dwc3_set_mode(struct dwc3 *dwc3_reg, u32 mode)
 {
@@ -295,7 +296,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_usb_init(index, USB_INIT_HOST);
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] [PATCH v2 3/6] usb: omap: Move the usb phy code to the usb/phy directory

2013-10-11 Thread 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 
---

v2 - No code change just a patch format change for copied code - 
http://patchwork.ozlabs.org/patch/281934/

 drivers/usb/host/xhci-omap.c   |  171 +---
 drivers/usb/phy/Makefile   |1 +
 .../usb/{host/xhci-omap.c => phy/omap_usb_phy.c}   |  142 +---
 include/linux/usb/xhci-omap.h  |6 +
 4 files changed, 15 insertions(+), 305 deletions(-)
 copy drivers/usb/{host/xhci-omap.c => phy/omap_usb_phy.c} (58%)

diff --git a/drivers/usb/host/xhci-omap.c b/drivers/usb/host/xhci-omap.c
index 4f98c77..7292ed8 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

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

2013-10-11 Thread 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 
---

v2 - No code changes - http://patchwork.ozlabs.org/patch/281930/

 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 6a01200..0044c22 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 v2 5/6] usb: am437x: Add support for am437x xhci USB host

2013-10-11 Thread 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 
---

v2 - Changed int->const u32 for usb_otg_ss_clk_val - 
http://patchwork.ozlabs.org/patch/281932/

 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 f074a88..af46db2 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)
+{
+   const u32 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 v2 4/6] usb: dra7xx: Add support for dra7xx xhci USB host

2013-10-11 Thread 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 
---

v2 - In omap_enable_usb2_phy2 changed int to u32 - 
http://patchwork.ozlabs.org/patch/281935/

 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 7292ed8..f6099ac 100644
--- a/drivers/usb/host/xhci-omap.c
+++ b/drivers/usb/host/xhci-omap.c
@@ -98,9 +98,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) {
@@ -116,7 +114,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..f074a88 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);

[U-Boot] [PATCH v2 0/6] TI xHCI Updated patchset

2013-10-11 Thread Dan Murphy

V2 patchset for TI SoC's that support xHCI controllers

Dan Murphy (6):
  usb: omap: Move the xhci-omap header file to common location
  usb: omap5: Update the board_usb_init api
  usb: omap: Move the usb phy code to the usb/phy directory
  usb: dra7xx: Add support for dra7xx xhci USB host
  usb: am437x: Add support for am437x xhci USB host
  ARM: omap5-evm: Move MAC creation to misc_init

 arch/arm/cpu/armv7/omap5/prcm-regs.c   |1 +
 arch/arm/include/asm/arch-am33xx/hardware_am43xx.h |   10 ++
 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 +
 board/ti/omap5_uevm/evm.c  |   41 ++---
 drivers/usb/host/xhci-omap.c   |  184 +--
 drivers/usb/phy/Makefile   |1 +
 .../usb/{host/xhci-omap.c => phy/omap_usb_phy.c}   |  187 +++-
 include/configs/am43xx_evm.h   |   11 ++
 include/configs/dra7xx_evm.h   |   11 ++
 .../arch-omap5 => include/linux/usb}/xhci-omap.h   |   16 ++
 13 files changed, 146 insertions(+), 328 deletions(-)
 copy drivers/usb/{host/xhci-omap.c => phy/omap_usb_phy.c} (58%)
 rename {arch/arm/include/asm/arch-omap5 => include/linux/usb}/xhci-omap.h (86%)

-- 
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 v8 1/5] mtd: nand: omap: enable BCH ECC scheme using ELM for generic platform

2013-10-11 Thread Scott Wood

On Fri, 2013-10-11 at 05:27 +, Gupta, Pekon wrote:
> > From: Scott Wood [mailto:scottw...@freescale.com]
> > On Thu, 2013-10-10 at 16:30 +0530, Pekon Gupta wrote:
> [snip]
> > > -#else
> > > + } else {
> > >   /*
> > >* This ecc_size_config setting is for BCH sw library.
> > >*
> > > @@ -333,7 +330,7 @@ static void omap_hwecc_init_bch(struct nand_chip
> > *chip, int32_t mode)
> > >*  size1 = 32 (skip 32 nibbles = 16 bytes per sector in spare area)
> > >*/
> > >   val = (32 << 22) | (0 << 12);
> > > -#endif
> > > + }
> > 
> > Either indentation or braces are wrong above.  If it's just the
> > indentation that's wrong, let me know and I can fix up when applying.
> > 
> Yes, thanks. I did run checkpatch.pl but may be because code here is
> not part of the changed lines, so it did not give the indentation warning.

It seems that checkpatch.pl only checks the indentation of the first
line of the if-body, and not the subsequent lines or anything in the
else-body.

> Do we have any checkpatch utility for u-boot ?

tools/checkpatch.pl

-Scott



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

Re: [U-Boot] omap3 usb boot

2013-10-11 Thread Tom Rini

On Fri, Oct 11, 2013 at 11:15:25AM +0200, Michael Trimarchi wrote:
> Hi Tom
> 
> I have managed to boot dm3730 on usb (first stage), but looking at the code
> I have some comment
> 
> in arch/arm/cpu/armv7/omap3/clock.c
> 
> #ifdef CONFIG_SYS_NS16550
> /* Enable UART1 clocks */
> sr32(&prcm_base->fclken1_core, 13, 1, 0x1);
> sr32(&prcm_base->iclken1_core, 13, 1, 0x1);
> 
> /* UART 3 Clocks */
> sr32(&prcm_base->fclken_per, 11, 1, 0x1);
> sr32(&prcm_base->iclken_per, 11, 1, 0x1);
> 
> You enable clock for two uarts without take in account the real console uart
> of the device. Then some lines after
> 
> sr32(&prcm_base->fclken_per, 0, 32, FCK_PER_ON);
> sr32(&prcm_base->iclken_per, 0, 32, ICK_PER_ON);
> 
> That just reset all the clock using the PER_ON mask so what is done before
> doesn't make sense anymore.

Yes, a lot of that code hasn't been heavily reviewed in a long while.
Patches to clean things up happily reviewed.

-- 
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] env_mmc: fix buffer allocation for armv7

2013-10-11 Thread Tom Rini

On Tue, Oct 08, 2013 at 08:17:01PM +0200, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20131008134456.GB15917@bill-the-cat> you wrote:
> > 
> > > Well, if we have DDR such that we can use it for the malloc arena, we
> > > also should use it for the stack.  Or is there a good reason for not
> > > doing this?  It would solve all these issues at the root...
> > 
> > Making SPL more complex for everyone?  We would need to do a fairly
> > good-sized re-jigger of SPL to setup and swap around stack pointers like
> > we do in full U-Boot.
> 
> Hm,  I'm not convinced.  As proposed, we make the code bigger, less
> efficient, more error prone and more ugly for everyone, not only for
> SPL users.  Aslo, this might not be the only place where buffers or
> such may be kept on the stack.  I hope you don't want to change all
> these?
> 
> Really, if we have the resources, we should use them.  If RAM is
> abailable, it should also be used for the stack.  Just using it for
> malloc() is neither fish nor fowl.

I'll ceed the point and re-work things on my series then.  Markus, your
patch is good as-is and I shall pick it up shortly.

-- 
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] powerpc/mpc85xx: Increase image size

2013-10-11 Thread York Sun

Scott, et al.

I'd like to start the discussion to increase u-boot image size for some
mpc85xx targets. As we all know the reset vector is at the very end and
linking process start from the top. This gives us no good choice but to
use fixed image size. While we have more and more features, the size
increases inevitably. It's time to adjust the arbitrary size. We are now
using 512KB. Shall we go with 768KB, or even 1MB?

For the first step, I think we don't have to increase size for all
targets. We can adjust those with CONFIG_SYS_TEXT_BASE=0xeff8. Those
are the most recent used. There are other targets which don't use NOR
flash boot method. They should be considered as well.

It is per board configuration. But it may be better if we keep them
consistent.

Please comment.

Regards,

York



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

[U-Boot] SPDX-License-Identifier on new files

2013-10-11 Thread D Rambo

Is there a policy that new source files upstreamed to u-boot contain
registered SPDX license identifiers? I see that there are still about 1900
source files that have no SPDX identifier, and about 6000 that do. The
reason I'm asking is that our company has a dual license (for GPL2.0 or
Proprietary), and would like to know if it is possible to submit code that
has the legacy dual license first (and register/clean up SPDX later), or if
we need to do the internal legal and register the appropriate licenses with
spdx.org first before submission upstream?

Another question is related to http://spdx.org/about-spdx/faqs

   *How does one represent a file or package that is dual licensed
(i.e., a license choice)?*

   SPDX license information can be represented using conjunctive or
disjunctive regular expressions.  For example, a file that is dual licensed
under either the GPL-2.0 or MIT would be represented using the following
disjunctive expression: (GPL-2.0 *or* MIT).

So my question is whether a dual license can be registered with spdx or is
it necessary to split the dual license and show the "or" condition above.
In other words, is the "or" parsing critical to license clearing reports?

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

Re: [U-Boot] powerpc/mpc85xx: Increase image size

2013-10-11 Thread Scott Wood

On Fri, 2013-10-11 at 11:29 -0700, York Sun wrote:
> Scott, et al.
> 
> I'd like to start the discussion to increase u-boot image size for some
> mpc85xx targets. As we all know the reset vector is at the very end and
> linking process start from the top. This gives us no good choice but to
> use fixed image size. While we have more and more features, the size
> increases inevitably. It's time to adjust the arbitrary size. We are now
> using 512KB. Shall we go with 768KB, or even 1MB?

768K would affect fewer existing partition maps (many of which leave 1M
for U-Boot and environment combined), but 1M might be better for new
boards.  And of course it would be nice if someone could spare some time
to try to slim things down (finer-grained compile-time config,
speed/size tradeoffs, etc).

> For the first step, I think we don't have to increase size for all
> targets. We can adjust those with CONFIG_SYS_TEXT_BASE=0xeff8. Those
> are the most recent used. There are other targets which don't use NOR
> flash boot method. They should be considered as well.
> 
> It is per board configuration. But it may be better if we keep them
> consistent.

I don't think it's worth trying to keep them consistent.  Leave alone
old boards that are not pushing the limit, and where testing and user
education would be a hassle, and let newer boards where more features
are wanted not be constrained by the past.

-Scott

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

Re: [U-Boot] SPDX-License-Identifier on new files

2013-10-11 Thread Tom Rini

On Fri, Oct 11, 2013 at 11:07:58AM -0700, D Rambo wrote:

> Is there a policy that new source files upstreamed to u-boot contain
> registered SPDX license identifiers? I see that there are still about 1900
> source files that have no SPDX identifier, and about 6000 that do. The
> reason I'm asking is that our company has a dual license (for GPL2.0 or
> Proprietary), and would like to know if it is possible to submit code that
> has the legacy dual license first (and register/clean up SPDX later), or if
> we need to do the internal legal and register the appropriate licenses with
> spdx.org first before submission upstream?

New code needs to use SPDX tags.

Next, I'm not a lawyer but you should ask the legal folks in your
company if you can't just license a copy of the code in question you
want to use as reference as GPL-2.0

-- 
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] powerpc/mpc85xx: Increase image size

2013-10-11 Thread York Sun

On 10/11/2013 11:39 AM, Scott Wood wrote:
> On Fri, 2013-10-11 at 11:29 -0700, York Sun wrote:
>> Scott, et al.
>>
>> I'd like to start the discussion to increase u-boot image size for some
>> mpc85xx targets. As we all know the reset vector is at the very end and
>> linking process start from the top. This gives us no good choice but to
>> use fixed image size. While we have more and more features, the size
>> increases inevitably. It's time to adjust the arbitrary size. We are now
>> using 512KB. Shall we go with 768KB, or even 1MB?
> 
> 768K would affect fewer existing partition maps (many of which leave 1M
> for U-Boot and environment combined), but 1M might be better for new
> boards.  And of course it would be nice if someone could spare some time
> to try to slim things down (finer-grained compile-time config,
> speed/size tradeoffs, etc).
> 
>> For the first step, I think we don't have to increase size for all
>> targets. We can adjust those with CONFIG_SYS_TEXT_BASE=0xeff8. Those
>> are the most recent used. There are other targets which don't use NOR
>> flash boot method. They should be considered as well.
>>
>> It is per board configuration. But it may be better if we keep them
>> consistent.
> 
> I don't think it's worth trying to keep them consistent.  Leave alone
> old boards that are not pushing the limit, and where testing and user
> education would be a hassle, and let newer boards where more features
> are wanted not be constrained by the past.
> 

I did a quick search for eff8. Only these boards have it

include/configs/B4860QDS.h
include/configs/C29XPCIE.h
include/configs/corenet_ds.h
include/configs/HWW1U1A.h
include/configs/MPC8536DS.h
include/configs/MPC8572DS.h
include/configs/P1010RDB.h
include/configs/P1022DS.h
include/configs/P1023RDB.h
include/configs/P1023RDS.h
include/configs/P1_P2_RDB.h
include/configs/p1_p2_rdb_pc.h
include/configs/p1_twr.h
include/configs/P2020DS.h
include/configs/P2041RDB.h
include/configs/T1040QDS.h
include/configs/t4qds.h

York

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

[U-Boot] [PATCH] Makefile: Introduce ARCH_PLATFORM_LIBGCC variable

2013-10-11 Thread Tom Rini

In some cases, such as arm multi-lib hardfloat (hf) toolchains, we will
have multiple libgcc.a's available, and the arch needs to provide
additional logic to determine the right file to use
(-print-libgcc-file-name contains no CFLAG parsing logic).

Cc: Albert Aribaud 
Signed-off-by: Tom Rini 
---
 Makefile   |4 
 arch/arm/config.mk |   11 +++
 2 files changed, 15 insertions(+)

diff --git a/Makefile b/Makefile
index b09bfcc..13b396f 100644
--- a/Makefile
+++ b/Makefile
@@ -357,8 +357,12 @@ else
 PLATFORM_LIBGCC = -L $(USE_PRIVATE_LIBGCC) -lgcc
 endif
 else
+ifneq ("$(ARCH_PLATFORM_LIBGCC)","")
+PLATFORM_LIBGCC := -L $(shell dirname $(ARCH_PLATFORM_LIBGCC)) -lgcc
+else
 PLATFORM_LIBGCC := -L $(shell dirname `$(CC) $(CFLAGS) 
-print-libgcc-file-name`) -lgcc
 endif
+endif
 PLATFORM_LIBS += $(PLATFORM_LIBGCC)
 export PLATFORM_LIBS
 
diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index d0cf43f..e1d0dec 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -19,6 +19,17 @@ LDFLAGS_FINAL += --gc-sections
 PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections \
  -fno-common -ffixed-r9 -msoft-float
 
+#
+# When we use a hardfp toolchain if there are both 'libgcc.a' (hardfp) and
+# 'arm-linux-gnueabi/libgcc.a' (softfp) we need to use the latter.  We
+# cannot always build with a hardfp-only toolchain.
+#
+ARCH_PLATFORM_LIBGCC := $(shell \
+   X=`$(CC) -print-file-name=arm-linux-gnueabi/libgcc.a`; \
+   if [ -f $$X ]; then echo $$X ; \
+   else $(CC) -print-file-name=libgcc.a ; \
+   fi)
+
 # Support generic board on ARM
 __HAVE_ARCH_GENERIC_BOARD := y
 
-- 
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] Makefile: Introduce ARCH_PLATFORM_LIBGCC variable

2013-10-11 Thread Tom Rini

On Fri, Oct 11, 2013 at 04:13:03PM -0400, Tom Rini wrote:

> In some cases, such as arm multi-lib hardfloat (hf) toolchains, we will
> have multiple libgcc.a's available, and the arch needs to provide
> additional logic to determine the right file to use
> (-print-libgcc-file-name contains no CFLAG parsing logic).
> 
> Cc: Albert Aribaud 
> Signed-off-by: Tom Rini 

For the record, build-tested with ELDKs for arm, powerpc and mips,
and other toolchains for nds32 m68k x86 and sandbox.

-- 
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] SPDX-License-Identifier on new files

2013-10-11 Thread Wolfgang Denk

Dear D Rambo,

In message  
you wrote:
>
> Is there a policy that new source files upstreamed to u-boot contain
> registered SPDX license identifiers? I see that there are still about 1900
> source files that have no SPDX identifier, and about 6000 that do. The

This is still work in progress...

> reason I'm asking is that our company has a dual license (for GPL2.0 or
> Proprietary), and would like to know if it is possible to submit code that

Please note that new code added to U-Boot shall have GPL2.0+, i. e.
GPL2.0 only is only accepted if the code is borrowed from other,
already existing projects (like the linux kernel).

>*How does one represent a file or package that is dual licensed
> (i.e., a license choice)?*

See [1]

[1] http://article.gmane.org/gmane.comp.boot-loaders.u-boot/171426

> So my question is whether a dual license can be registered with spdx or is
> it necessary to split the dual license and show the "or" condition above.
> In other words, is the "or" parsing critical to license clearing reports?

There are two parts here;  first, you must define the exact license
terms.  GPL is already defined in SPDX, so that is no isse.  But you
have to add your proprietary license to the Licenses/ directory, and
define a Unique License Identifier for it (which you should also
submit to the SPDX project for official registration).  Second, in the
SPDX-License-Identifier: line, both license IDs get listed, separated
by white space.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Real computer scientists despise the idea of actual  hardware.  Hard-
ware has limitations, software doesn't. It's a real shame that Turing
machines are so poor at I/O.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Suggestion for building all boards

2013-10-11 Thread Simon Glass

Hi Masahiro,

On Fri, Oct 11, 2013 at 5:29 AM, Masahiro Yamada
 wrote:
> Hello experts, custodians.
>

> To sum up my suggestion,
>
>  - Collect pre-built suitable crosstools for all architectures
>on U-boot ftp site.

Great idea. If you can organize a tarball (or more than one) and a
place to put it then we could make buildman fetch and setup
automatically.

>
>  - Check all boards automatically using those recommended
>crosstools and post the result to the mailing list.

Would be very helpful.

>
>  - Add new status to boards.cfg to mark boards with a problem.

This is for boards that are already broken I think.

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

Re: [U-Boot] [PATCH] disk:efi: avoid unaligned access on efi partition

2013-10-11 Thread Måns Rullgård

Piotr Wilczek  writes:

> In this patch static variable and memcpy instead of an assignment
> are used to avoid unaligned access exception on some ARM platforms.
>
> Signed-off-by: Piotr Wilczek 
> Signed-off-by: Kyungmin Park 
> CC: Tom Rini 
> ---
>  disk/part_efi.c |6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/disk/part_efi.c b/disk/part_efi.c
> index b7524d6..303b8af 100644
> --- a/disk/part_efi.c
> +++ b/disk/part_efi.c
> @@ -224,7 +224,8 @@ static int set_protective_mbr(block_dev_desc_t *dev_desc)
>   p_mbr->signature = MSDOS_MBR_SIGNATURE;
>   p_mbr->partition_record[0].sys_ind = EFI_PMBR_OSTYPE_EFI_GPT;
>   p_mbr->partition_record[0].start_sect = 1;
> - p_mbr->partition_record[0].nr_sects = (u32) dev_desc->lba;
> + memcpy(&p_mbr->partition_record[0].nr_sects, &dev_desc->lba,
> +sizeof(dev_desc->lba));

Why is this assignment problematic?  Note that the compiler may optimise
the memcpy() call into a plain assignment including any alignment
assumptions it was making in the original code.

The correct fix is either to ensure that pointers are properly aligned
or that things are annotated as potentially unaligned, whichever is more
appropriate.

-- 
Måns Rullgård
m...@mansr.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 ?

2013-10-11 Thread Djoker

I am sorry Gerhard, I am newbie to the list.
I will keep in mind the etiquette of the list.
Thanks for the help.

On Thu, Oct 10, 2013 at 8:37 AM, Gerhard Sittig  wrote:
> On Wed, Oct 09, 2013 at 09:07 -0700, djoker wrote:
>>
>> Hi Everyone,
>
> Why do you "re-send" your request without giving readers time to
> respond (first message at 17:00 and second on 09:00 the very next
> morning)?
>
> This unnecessarily splits the same subject across several
> threads, hinders discussion and prevents easy lookup in archives
> (and reduces your score and thus the willingness to help such a
> "demanding" person) ...
>
>> 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*
>
> As with any ARM based CPU, I'd expect the "executable" to start
> with a vector table, before the actual body of the start()
> routine follows.
>
> The "reset vector" only has a few bytes in the vector table, and
> should consist of a branch to the actual initialization code.
>
> So I'd rather be baffled if the _start symbol would reside at the
> very start of the binary, since it then would clobber all the
> vectors.
>
>> But, I have searched through the source code, but not found where _start
>> gets assigned a value.. Could someone please help me understand this ?
>
> The linker (sometimes referred to as the loader) is the entity to
> assign addresses to symbols.  So check the linker command line
> and control files when in doubt.
>
> Optionally tell the compiler to "save temp files", and/or check
> whether the resulting *.o files or executables match what you'd
> expect from looking at the C/assembly source.
>
>
> virtually yours
> Gerhard Sittig
> --
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: off...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

2013-10-11 Thread Marek Vasut

Dear Dan Murphy,

[...]

> +
> + /* This is an undocumented Reserved register */
> + reg = 0x4a0086c0;
> + val = readl(reg);
> + val |= 0x100;
> + setbits_le32(reg, val);
> +}

Do you know what it's doing at least?

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 0/6] TI xHCI Updated patchset

2013-10-11 Thread Marek Vasut

Dear Dan Murphy,

> V2 patchset for TI SoC's that support xHCI controllers
> 
> Dan Murphy (6):
>   usb: omap: Move the xhci-omap header file to common location
>   usb: omap5: Update the board_usb_init api
>   usb: omap: Move the usb phy code to the usb/phy directory
>   usb: dra7xx: Add support for dra7xx xhci USB host
>   usb: am437x: Add support for am437x xhci USB host
>   ARM: omap5-evm: Move MAC creation to misc_init
> 
>  arch/arm/cpu/armv7/omap5/prcm-regs.c   |1 +
>  arch/arm/include/asm/arch-am33xx/hardware_am43xx.h |   10 ++
>  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 +
>  board/ti/omap5_uevm/evm.c  |   41 ++---
>  drivers/usb/host/xhci-omap.c   |  184
> +-- drivers/usb/phy/Makefile   |  
>  1 +
>  .../usb/{host/xhci-omap.c => phy/omap_usb_phy.c}   |  187
> +++- include/configs/am43xx_evm.h   | 
>  11 ++
>  include/configs/dra7xx_evm.h   |   11 ++
>  .../arch-omap5 => include/linux/usb}/xhci-omap.h   |   16 ++
>  13 files changed, 146 insertions(+), 328 deletions(-)
>  copy drivers/usb/{host/xhci-omap.c => phy/omap_usb_phy.c} (58%)
>  rename {arch/arm/include/asm/arch-omap5 => include/linux/usb}/xhci-omap.h
> (86%)

Applied all and pushed to -next.

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/3] sf: add missing Atmel at25df321 spi flash support

2013-10-11 Thread Bo Shen


Hi Jagan,
  Cc Tom.

On 10/11/2013 09:24, Bo Shen wrote:

Hi Jagan,

On 10/10/2013 22:14, Jagan Teki wrote:

Thanks for this.

On Thu, Oct 10, 2013 at 10:37 AM, Bo Shen  wrote:

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(+)


If this patch not applied before release at Oct 14, it will make a 
regression for several Atmel EK boards boot from spi flash.


Would you please pick it before release?

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

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

2013-10-11 Thread Zhao Qiang

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
Changes for v4:
-Rebase on u-boot master branch
Changes for v5:
-Remove a blank

 arch/powerpc/include/asm/fsl_pci.h | 18 ---
 drivers/pci/fsl_pci_init.c | 44 +++---
 drivers/pci/pci.c  | 65 ++
 include/pci.h  | 10 ++
 4 files changed, 107 insertions(+), 30 deletions(-)

diff --git a/arch/powerpc/include/asm/fsl_pci.h 
b/arch/powerpc/include/asm/fsl_pci.h
index 749411c..5be718b 100644
--- a/arch/powerpc/include/asm/fsl_pci.h
+++ b/arch/powerpc/include/asm/fsl_pci.h
@@ -18,24 +18,6 @@
 /* Freescale-specific PCI config registers */
 #define FSL_PCI_PBFR   0x44
 
-#ifdef 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 */
-#endif
-
 #define FSL_PCIE_CFG_RDY   0x4b0
 #define FSL_PROG_IF_AGENT  0x1
 
diff --git a/drivers/pci/fsl_pci_init.c b/drivers/pci/fsl_pci_init.c
index d55db1a..2085cd6 100644
--- a/drivers/pci/fsl_pci_init.c
+++ b/drivers/pci/fsl_pci_init.c
@@ -295,6 +295,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);
@@ -367,7 +376,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 */
@@ -406,15 +420,16 @@ void fsl_pci_init(struct pci_controller *hose, struct 
fsl_pci_info *pci_info)
 * - Master PERR (pci)
 * - ICCA (PCIe)
 */
-   pci_hose_read_config_dword(hose, dev, PCI_DCR, &temp32);
+   pci_hose_read_config_dword(hose, dev, pci_dcr, &temp32);
temp32 |= 0xf000e;  /* set URR, FER, NFER (but not CER) */
-   pci_hose_write_config_dword(hose, dev, PCI_DCR, temp32);
+   pci_hose_write_config_dword(hose, dev, pci_dcr, temp32);
 
 #if defined(CONFIG_FSL_PCIE_DISABLE_ASPM)
+   pci_lcr = pcie_cap_pos + 0x10;
temp32 = 0;
-   pci_hose_read_config_dword(hose, dev, PCI_LCR, &temp32);
+   pci_hose_read_config_dword(hose, dev, pci_lcr, &temp32);
temp32 &= ~0x03;/* Disable ASPM  */
-   pci_hose_write_config_dword(hose, dev, PCI_LCR, temp32);
+   pci_hose_write_config_dword(hose, dev, pci_lcr, temp32);
udelay(1);
 #endif
if (pcie_cap == PCI_CAP_ID_EXP) {
@@ -494,7 +509,7 @@ void fsl_pci_init(struct pci_controller *hose, struct 
fsl_pci_info *pci_info)
out_be

45 matches

Mail list logo