date:20130622

Re: [U-Boot] Modifying the Device tree fields

2013-06-22 Thread Kamaraj P

Thanks for the suggestions..
Is there any code pointers(using fdt_appendprop()) to modify/add the
interrupt numbers to the existing protected-sources property under pic
controller ?

mpic: pic@4 {
interrupt-controller;
#address-cells = 0;
#interrupt-cells = 2;
reg = 0x4 0x4;
compatible = chrp,open-pic;
device_type = open-pic;
protected-sources = 
16 , *0 , 28*
 

Any help would be greatly appreciated

Thanks,
Kamaraj


On Sat, Jun 22, 2013 at 12:37 AM, Scott Wood scottw...@freescale.comwrote:

 On 06/21/2013 12:26:33 PM, Kamaraj P wrote:

 Hello All,

 In my device tree blob, i would like to add some interrupt to the
 protected-source list dynamically in the u-boot before launching the linux
 kernel.

  mpic: pic@4 {
 interrupt-controller;
 #address-cells = 0;
 #interrupt-cells = 2;
 reg = 0x4 0x4;
 compatible = chrp,open-pic;
 device_type = open-pic;
 protected-sources = 
 16
  

 In the above DTS file,  i would like to add the other interrupts to the
  protected-sources dynamically.


 If you use the pic-no-reset property, you don't need protected-sources at
 all, unless you specifically want the error checking aspect of it.


  I hope we need to use the device fdt APIs.  Could you please any pointers
 or  reference for how to use those APIs in the u-boot ?


 fdt_appendprop looks like a good choice if you still want to do this.

 -Scott

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

Re: [U-Boot] uboot ERROR nfs: Cannot umount error

2013-06-22 Thread jinghui shi

Dear Joe,Wolfgang, and anyone reading this mail,

 2013/6/7 Wolfgang Denk w...@denx.de:
 Dear jinghui shi,
...
 Why we do not call ethernet driver's halt function if there was a
 Cannot umount error?

 It appears you have discovered a bug.  As this happens only in the
 error handling branch of the code, it is no big surprise that this has
 not been detected before.  But yes, this should be fixed.

  Is there a plan to fix this?

  Now I am planning to fix it myself(If you have a plan, that's a
better choice, I think),
but something still puzzles me. There is a very simple(but maybe not a
solution) method
to avoid this, that is call eth_halt() after puts(*** ERR: Cannot
umount\n) and
net_set_state(NET_LOOPFAIL), but the problem is if we really receive
a umount call
 reply but with a previous rpc id, should we treat it as a error, and
puts(*** ERR: Cannot umount\n)?

  Another method that leads the calling of eth_halt() is to treat the
[umount call
reply but with a previous rpc id] as a right reply, that means do
not care about the
rpc id, but what I worry about is that may cause some other
problems, I not clear about
NFS, so it maybe not a good idea to do so.

Can anyone give any idea/advice about this?

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

Re: [U-Boot] [PATCH] OpenRD: relocate environment to 640kB

2013-06-22 Thread Albert ARIBAUD

On Tue, 11 Jun 2013 12:00:19 +0200, Albert ARIBAUD
albert.u.b...@aribaud.net wrote:

 Hi Sascha,
 
 On Mon, 27 May 2013 11:42:26 +0200, Sascha Silbe
 t-ub...@infra-silbe.de wrote:
 
  U-Boot has become slightly larger than where the environment sector
  was previously located. Saving the environment would brick the device.
  
  Relocate the environment to where it is with the stock (i.e. Marvell
  USP) U-Boot version. That should give plenty of room for U-Boot to
  grow, including local customisations.
  
  This obviously breaks compatibility with previous mainline versions of
  U-Boot. Users will need to back up the environment before an update
  and restore it afterwards, or manually copy it to the new address
  before the update.
  
  Signed-off-by: Sascha Silbe t-ub...@infra-silbe.de
  ---
   include/configs/openrd.h | 4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)
  
  diff --git a/include/configs/openrd.h b/include/configs/openrd.h
  index 53bafe1..ea7f9aa 100644
  --- a/include/configs/openrd.h
  +++ b/include/configs/openrd.h
  @@ -90,8 +90,8 @@
* it has to be rounded to sector size
*/
   #define CONFIG_ENV_SIZE0x2 /* 128k */
  -#define CONFIG_ENV_ADDR0x6
  -#define CONFIG_ENV_OFFSET  0x6 /* env starts here */
  +#define CONFIG_ENV_ADDR0xa
  +#define CONFIG_ENV_OFFSET  0xa /* env starts here */
   
   /*
* Default environment variables
 
 CC:ing Tom.
 
 This patch is for 2013.10, not 2013.07, but I prefer raising the issue
 as early as possible.
 
 If there is no way to make things smoother, then I think the 2013.10
 release notes should contain a red, blinking, paragraph about this. I
 would *hate* it if people were not warned and given a method to port
 their current environment setting over.
 
 Possibly even, the 2013.07 could have a warning about the change to
 come, so that people have a better chance yet to prepare for the change.
 
 Amicalement,

Ping.

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

Re: [U-Boot] [PATCH] arm: omap5_uevm: Correct the console sys prompt for 5432

2013-06-22 Thread Albert ARIBAUD

Hi Tom,

On Tue, 11 Jun 2013 11:53:42 -0400, Tom Rini tr...@ti.com wrote:

 On Thu, Jun 06, 2013 at 04:30:38PM -0500, Dan Murphy wrote:
 
  Correct the console sys prompt to display the correct processor
  and the corrent board
  
  Signed-off-by: Dan Murphy dmur...@ti.com
  Reported-by: Lubomir Popov lpo...@mm-sol.com
 
 Reviewed-by: Tom Rini tr...@ti.com
 
 But personally, this is why I'm a fan of 'U-Boot # ' as the prompt :)

I'd like it too if we could simply have all boards using the same
prompt, but there might be some scripts out there which rely on the
prompt being something else than U-Boot # ' or worse yet, using the
prompt to determine which variant of the HW the scripts are dealing
with.

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

[U-Boot] [RFC] interrupt handling

2013-06-22 Thread Albert ARIBAUD

Hello all,

From time to time there is discussion about the need for proper
interrupt support in U-Boot.

Right now, the only thing left in the source code which remotely looks
like interrupt support is a few code sections compiled conditionally
under CONFIG_USE_IRQ, and it does not constitute a good approach to
interrupt support, if only for the following reasons:

- CONFIG_USE_IRQ is very general and imprecise as far as overall
  meaning goes. It does not say allow drivers to use IRQs, or IRQs
  are provided by supporting this specific interrupt controller, or
  this driver requires IRQs to work. It does not help us either that
  the option was never documented...

- CONFIG_USE_IRQ is, OTOH, very specific as far as interrupt types go.
  IRQ is an acronym known in ARM for a specific type of interrupt, but
  ARM also knows FIQ. IRQ may have a different meaning for another
  architecture, and each platform has its own classification and
  attributes for interrupts.

- no API is defined for registering interrupt controller or interrupt
  client drivers.

But the worst part is, CONFIG_USE_IRQ is never *ever* defined. :)

So I am tempted to start this RFC with a first question: do we *need*
interrupts in the first place, and if we do, do we need an organized
interrupts subsystem or do we keep an ad hoc approach?

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

Re: [U-Boot] [PATCH] Fix block device accesses beyond 2TiB

2013-06-22 Thread Albert ARIBAUD

On Mon, 17 Jun 2013 22:26:00 +0200, Marek Vasut ma...@denx.de wrote:

 Hello Sascha,
 
  With CONFIG_SYS_64BIT_LBA, lbaint_t gets defined as a 64-bit type,
  which is required to represent block numbers for storage devices that
  exceed 2TiB (the block size usually is 512B), e.g. recent hard drives.
  
  For some obscure reason, the current U-Boot code uses lbaint_t for the
  number of blocks to read (a rather optimistic estimation of how RAM
  sizes will evolve), but not for the starting address. Trying to access
  blocks beyond the 2TiB boundary will simply wrap around and read a
  block within the 0..2TiB range.
  
  We now use lbaint_t for block start addresses, too. This required
  changes to all block drivers as the signature of block_read(),
  block_write() and block_erase() in block_dev_desc_t changed.
  
  Signed-off-by: Sascha Silbe t-ub...@infra-silbe.de
  ---
  Functionality tested on CuBox Pro with a Western Digital WD30EFRX hard
  disk (3TB). Build tested for all arm boards and sandbox.
  
  Testing on other boards and architectures would be appreciated.
  
  Fixes for typos, style errors etc. are explicitly out of scope for
  this patch, even those checkpatch complains about because they appear
  on or near lines touched by the patch. They are unrelated to the issue
  at hand and can be fixed up later. Mixing in unrelated changes would
  just make harder to revert any problematic change.
 
 Quick review looks OK.
 
 Best regards,
 Marek Vasut

Anyone could test Sascha's patch? Especially Frédédic, can you test it
and see how this works with your enabling 64-bit LBA on LaCie kirkwood
products?

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

[U-Boot] [PATCH] gpio: pca953x: Use ARRAY_SIZE instead of reinventing it

2013-06-22 Thread Axel Lin

Signed-off-by: Axel Lin axel@ingics.com
---
 drivers/gpio/pca953x.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpio/pca953x.c b/drivers/gpio/pca953x.c
index be13745..7371cd4 100644
--- a/drivers/gpio/pca953x.c
+++ b/drivers/gpio/pca953x.c
@@ -47,9 +47,6 @@ struct pca953x_chip_ngpio {
 static struct pca953x_chip_ngpio pca953x_chip_ngpios[] =
 CONFIG_SYS_I2C_PCA953X_WIDTH;
 
-#define NUM_CHIP_GPIOS (sizeof(pca953x_chip_ngpios) / \
-   sizeof(struct pca953x_chip_ngpio))
-
 /*
  * Determine the number of GPIO pins supported. If we don't know we assume
  * 8 pins.
@@ -58,7 +55,7 @@ static int pca953x_ngpio(uint8_t chip)
 {
int i;
 
-   for (i = 0; i  NUM_CHIP_GPIOS; i++)
+   for (i = 0; i  ARRAY_SIZE(pca953x_chip_ngpios); i++)
if (pca953x_chip_ngpios[i].chip == chip)
return pca953x_chip_ngpios[i].ngpio;
 
-- 
1.8.1.2



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

Re: [U-Boot] [PATCH] gpio: pca953x: Use ARRAY_SIZE instead of reinventing it

2013-06-22 Thread Thierry Reding

On Sat, Jun 22, 2013 at 06:22:48PM +0800, Axel Lin wrote:
 Signed-off-by: Axel Lin axel@ingics.com
 ---
  drivers/gpio/pca953x.c | 5 +
  1 file changed, 1 insertion(+), 4 deletions(-)

Reviewed-by: Thierry Reding thierry.red...@gmail.com


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

Re: [U-Boot] [RFC] interrupt handling

2013-06-22 Thread Stefan Roese

Hi Albert,

On 22.06.2013 11:58, Albert ARIBAUD wrote:
 From time to time there is discussion about the need for proper
 interrupt support in U-Boot.
 
 Right now, the only thing left in the source code which remotely looks
 like interrupt support is a few code sections compiled conditionally
 under CONFIG_USE_IRQ, and it does not constitute a good approach to
 interrupt support, if only for the following reasons:
 
 - CONFIG_USE_IRQ is very general and imprecise as far as overall
   meaning goes. It does not say allow drivers to use IRQs, or IRQs
   are provided by supporting this specific interrupt controller, or
   this driver requires IRQs to work. It does not help us either that
   the option was never documented...
 
 - CONFIG_USE_IRQ is, OTOH, very specific as far as interrupt types go.
   IRQ is an acronym known in ARM for a specific type of interrupt, but
   ARM also knows FIQ. IRQ may have a different meaning for another
   architecture, and each platform has its own classification and
   attributes for interrupts.
 
 - no API is defined for registering interrupt controller or interrupt
   client drivers.
 
 But the worst part is, CONFIG_USE_IRQ is never *ever* defined. :)
 
 So I am tempted to start this RFC with a first question: do we *need*
 interrupts in the first place, and if we do, do we need an organized
 interrupts subsystem or do we keep an ad hoc approach?

I know that interrupts are currently used on PowerPC for the PPC4xx
ethernet driver (emac). This could be reworked to of cause, but I just
wanted to point this out.

I have no idea if interrupts are used on any ARM platform though.

Thanks,
Stefan

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

Re: [U-Boot] [[PATCH]] imx6: fix GPR2 wrong definition

2013-06-22 Thread Dirk Behme


Am 19.06.2013 11:16, schrieb Pierre Aubert:

Signed-off-by: Pierre Aubert p.aub...@staubli.com
CC: Stefano Babic sba...@denx.de


Acked-by: Dirk Behme dirk.be...@gmail.com

Thanks

Dirk


---
  arch/arm/include/asm/arch-mx6/imx-regs.h |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/include/asm/arch-mx6/imx-regs.h 
b/arch/arm/include/asm/arch-mx6/imx-regs.h
index 03abb2a..45824f9 100644
--- a/arch/arm/include/asm/arch-mx6/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx6/imx-regs.h
@@ -364,7 +364,7 @@ struct iomuxc {

  #define IOMUXC_GPR2_MODE_DISABLED 0
  #define IOMUXC_GPR2_MODE_ENABLED_DI0  1
-#define IOMUXC_GPR2_MODE_ENABLED_DI1   2
+#define IOMUXC_GPR2_MODE_ENABLED_DI1   3

  #define IOMUXC_GPR2_LVDS_CH1_MODE_OFFSET  2
  #define IOMUXC_GPR2_LVDS_CH1_MODE_MASK
(3IOMUXC_GPR2_LVDS_CH1_MODE_OFFSET)



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

Re: [U-Boot] [Patch v2] PHY: micrel.c: add support for KSZ9031

2013-06-22 Thread Joe Hershberger

On Tue, Jun 18, 2013 at 10:31 AM, Fabio Estevam feste...@gmail.com wrote:
 Hi Joe,

 On Wed, Feb 6, 2013 at 7:18 PM, David Andrey david.and...@netmodule.com 
 wrote:
 Add support for Micrel PHY KSZ9031 in phylib,
 including small rework for KSZ9021 to avoid
 code duplication

 Signed-off-by: David Andrey david.and...@netmodule.com
 Cc: Troy Kisky troy.ki...@boundarydevices.com
 Cc: Joe Herschberger joe.hershber...@gmail.com
 Cc: Andy Fleming aflem...@freescale.com

 Can we get this one applied for the upcoming 2013.04?

I have this in a branch, but I'm fixing problems with a few patches.
I'll send a PR soon that should include this.

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

Re: [U-Boot] [PATCH] gpio: pca953x: Use ARRAY_SIZE instead of reinventing it

2013-06-22 Thread Marek Vasut

Dear Axel Lin,

 Signed-off-by: Axel Lin axel@ingics.com
 ---
  drivers/gpio/pca953x.c | 5 +
  1 file changed, 1 insertion(+), 4 deletions(-)
 
 diff --git a/drivers/gpio/pca953x.c b/drivers/gpio/pca953x.c
 index be13745..7371cd4 100644
 --- a/drivers/gpio/pca953x.c
 +++ b/drivers/gpio/pca953x.c
 @@ -47,9 +47,6 @@ struct pca953x_chip_ngpio {
  static struct pca953x_chip_ngpio pca953x_chip_ngpios[] =
  CONFIG_SYS_I2C_PCA953X_WIDTH;
 
 -#define NUM_CHIP_GPIOS (sizeof(pca953x_chip_ngpios) / \
 - sizeof(struct pca953x_chip_ngpio))
 -
  /*
   * Determine the number of GPIO pins supported. If we don't know we assume
   * 8 pins.
 @@ -58,7 +55,7 @@ static int pca953x_ngpio(uint8_t chip)
  {
   int i;
 
 - for (i = 0; i  NUM_CHIP_GPIOS; i++)
 + for (i = 0; i  ARRAY_SIZE(pca953x_chip_ngpios); i++)
   if (pca953x_chip_ngpios[i].chip == chip)
   return pca953x_chip_ngpios[i].ngpio;

Absolutelly

Acked-by: Marek Vasut ma...@denx.de

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

[U-Boot] [PULL] u-boot-pxa/master

2013-06-22 Thread Marek Vasut

The following changes since commit fbf87b1823dd5ebc2a384711ea2c677543019ece:

  arm: optimize relocate_code routine (2013-06-21 23:05:50 +0200)

are available in the git repository at:

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

for you to fetch changes up to 9dc8fef2583f23ca6a99c6f5e709a8b80018364f:

  pxa: fix memory coherency problem after relocation (2013-06-22 15:25:28 +0200)


Mike Dunn (5):
  pxa: add support for palmtreo680 board
  pxa: palmtreo680 flash programming utility
  pxa: turn icache off in cpu_init_crit()
  pxa: use -mcpu=xscale compiler option
  pxa: fix memory coherency problem after relocation

 CREDITS  |4 +
 MAINTAINERS  |3 +
 arch/arm/cpu/pxa/config.mk   |2 +-
 arch/arm/cpu/pxa/start.S |3 +-
 arch/arm/lib/relocate.S  |9 +++
 board/palmtreo680/Makefile   |   34 +
 board/palmtreo680/README |  581 
++
 board/palmtreo680/palmtreo680.c  |  148 +++
 boards.cfg   |1 +
 include/configs/palmtreo680.h|  286 

 tools/palmtreo680/flash_u-boot.c |  177 
++
 11 files changed, 1245 insertions(+), 3 deletions(-)
 create mode 100644 board/palmtreo680/Makefile
 create mode 100644 board/palmtreo680/README
 create mode 100644 board/palmtreo680/palmtreo680.c
 create mode 100644 include/configs/palmtreo680.h
 create mode 100644 tools/palmtreo680/flash_u-boot.c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] cmd_i2c: Use ARRAY_SIZE instead of reinventing it

2013-06-22 Thread Axel Lin

Signed-off-by: Axel Lin axel@ingics.com
---
 common/cmd_i2c.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/common/cmd_i2c.c b/common/cmd_i2c.c
index 4380794..3215644 100644
--- a/common/cmd_i2c.c
+++ b/common/cmd_i2c.c
@@ -120,8 +120,6 @@ static uchar i2c_no_probes[] = CONFIG_SYS_I2C_NOPROBES;
 #define COMPARE_ADDR(a,i)  (i2c_no_probes[(i)] == (a))
 #define NO_PROBE_ADDR(i)   i2c_no_probes[(i)]
 #endif /* CONFIG_MULTI_BUS */
-
-#define NUM_ELEMENTS_NOPROBE (sizeof(i2c_no_probes)/sizeof(i2c_no_probes[0]))
 #endif
 
 #if defined(CONFIG_I2C_MUX)
@@ -713,7 +711,7 @@ static int do_i2c_probe (cmd_tbl_t *cmdtp, int flag, int 
argc, char * const argv
 
 #if defined(CONFIG_SYS_I2C_NOPROBES)
skip = 0;
-   for (k=0; k  NUM_ELEMENTS_NOPROBE; k++) {
+   for (k = 0; k  ARRAY_SIZE(i2c_no_probes); k++) {
if (COMPARE_BUS(bus, k)  COMPARE_ADDR(j, k)) {
skip = 1;
break;
@@ -731,7 +729,7 @@ static int do_i2c_probe (cmd_tbl_t *cmdtp, int flag, int 
argc, char * const argv
 
 #if defined(CONFIG_SYS_I2C_NOPROBES)
puts (Excluded chip addresses:);
-   for (k=0; k  NUM_ELEMENTS_NOPROBE; k++) {
+   for (k = 0; k  ARRAY_SIZE(i2c_no_probes); k++) {
if (COMPARE_BUS(bus,k))
printf( %02X, NO_PROBE_ADDR(k));
}
-- 
1.8.1.2



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

[U-Boot] [PATCH] mpc5200: Misc updates to a3m071 config header

2013-06-22 Thread Stefan Roese

This patch changes some features of the a3m071/a4m2k board support:

- Add bootcounter support
- Update MTD env default to correct values
- Add mtdparts to bootargs for mtd partitioning via kernel cmdline
- Added some default env variables for easy updating (kernel, dtb)
- Change README to the updated flash locations

Signed-off-by: Stefan Roese s...@denx.de
---
 board/a3m071/README  | 10 +-
 include/configs/a3m071.h | 31 +++
 2 files changed, 28 insertions(+), 13 deletions(-)

diff --git a/board/a3m071/README b/board/a3m071/README
index a0fe832..112c47b 100644
--- a/board/a3m071/README
+++ b/board/a3m071/README
@@ -57,13 +57,13 @@ the following command:
 = fdt print
 
 5. Save fdt to NOR flash:
-= erase fc06 fc07
-= cp.b 180 fc06 1
+= erase fc18 fc07
+= cp.b 180 fc18 1
 
 All this can be integrated into an environment command:
-= setenv upd_fdt 'tftp 180 a3m071/a3m071.dtb;run mtdargs addip2 addtty; \
-   fdt addr 180;fdt boardsetup;fdt chosen;erase fc06 fc07; \
-   cp.b 180 fc06 1'
+= setenv upd_fdt 'tftp 180 a3m071/a3m071.dtb;run mtdargs addip addtty; \
+   fdt addr 180;fdt boardsetup;fdt chosen;erase fc18 fc07; \
+   cp.b 180 fc18 1'
 = saveenv
 
 After this, only run upd_fdt needs to get called to load, patch
diff --git a/include/configs/a3m071.h b/include/configs/a3m071.h
index e9af825..905702d 100644
--- a/include/configs/a3m071.h
+++ b/include/configs/a3m071.h
@@ -42,6 +42,8 @@
 #define CONFIG_HOSTNAMEa3m071
 #endif
 
+#define CONFIG_BOOTCOUNT_LIMIT
+
 /*
  * Serial console configuration
  */
@@ -76,7 +78,8 @@
 #define CONFIG_FLASH_CFI_MTD
 #define MTDIDS_DEFAULT  nor0=fc00.flash
 #define MTDPARTS_DEFAULT   mtdparts=fc00.flash:512k(u-boot), \
-   256k(env),\
+   128k(env1),   \
+   128k(env2),   \
128k(hwinfo), \
1M(nvramsim), \
128k(dtb),\
@@ -84,7 +87,9 @@
128k(sysinfo),\
7552k(root),  \
4M(app),  \
-   13568k(data)
+   5376k(data),  \
+   8M(install)
+
 #define CONFIG_LZO /* needed for UBI */
 #define CONFIG_RBTREE  /* needed for UBI */
 #define CONFIG_CMD_MTDPARTS
@@ -378,7 +383,7 @@
nfsargs=setenv bootargs root=/dev/nfs rw  \
nfsroot=${serverip}:${rootpath}\0 \
ramargs=setenv bootargs root=/dev/ram rw\0\
-   mtdargs=setenv bootargs root=/dev/mtdblock7   \
+   mtdargs=setenv bootargs root=/dev/mtdblock8   \
rootfstype=squashfs,jffs2\0   \
addhost=setenv bootargs ${bootargs}   \
hostname=${hostname}\0\
@@ -387,22 +392,32 @@
:${hostname}:${netdev}:off panic=1\0  \
addtty=setenv bootargs ${bootargs}\
console=${consoledev},${baudrate}\0   \
-   flash_nfs=run nfsargs addip addtty addhost;   \
+   flash_nfs=run nfsargs addip addtty addmtd addhost;\
bootm ${kernel_addr} - ${fdt_addr}\0  \
-   flash_mtd=run mtdargs addip addtty addhost;   \
+   flash_mtd=run mtdargs addip addtty addmtd addhost;\
bootm ${kernel_addr} - ${fdt_addr}\0  \
-   flash_self=run ramargs addip addtty addhost;  \
+   flash_self=run ramargs addip addtty addmtd addhost;   \
bootm ${kernel_addr} ${ramdisk_addr} ${fdt_addr}\0\
net_nfs=tftp ${kernel_addr_r} ${bootfile};\
tftp ${fdt_addr_r} ${fdtfile};\
-   run nfsargs addip addtty addhost; \
+   run nfsargs addip addtty addmtd addhost;  \
bootm ${kernel_addr_r} - ${fdt_addr_r}\0  \
load=tftp ${loadaddr}  __stringify(CONFIG_HOSTNAME)   \
/u-boot-img.bin\0 \
-   update=protect off fc00 fc07; \
+   update=protect off fc00 fc07; \
era fc00 fc07;

Re: [U-Boot] [PATCH] Fix block device accesses beyond 2TiB

2013-06-22 Thread Albert ARIBAUD

Hi Frédéric,

On Sat, 22 Jun 2013 14:29:26 +0200, Frédéric Leroy fr...@starox.org
wrote:

 Hello Albert, Sascha, Marek
 
 Le 22/06/2013 12:07, Albert ARIBAUD a écrit :
   Quick review looks OK.
   
   Best regards,
   Marek Vasut
 
  Anyone could test Sascha's patch? Especially Frédédic, can you test it
  and see how this works with your enabling 64-bit LBA on LaCie kirkwood
  products?
 
  Amicalement,
 
 I applied Sascha patch with 64-bit LBA enabled.
 I verifyed it by using the ide read command.
 Logs are attached for u-boot tests, with and without the patch.
 I added the output of dd of the same block on a linux machine in order
 to verify the content.
 There is still issues to access file on a ext fs beyond the 2.1 limit
 (see end of logs).
 
 However, the patch issues no warning at compile time and fixes the ide
 block layer.

OK -- anyone has any idea why Sasha's patch fixes reading from far
blocks but does not fix ex2ls? Frankly, I'd prefer it if the patch
fixed it all. :)

 Best regards,

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

[U-Boot] [PATCH] serial: Use ARRAY_SIZE instead of reinventing it

2013-06-22 Thread Axel Lin

Signed-off-by: Axel Lin axel@ingics.com
---
 drivers/serial/serial.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/serial/serial.c b/drivers/serial/serial.c
index daa8003..a19cec5 100644
--- a/drivers/serial/serial.c
+++ b/drivers/serial/serial.c
@@ -37,7 +37,6 @@ static struct serial_device *serial_current;
  * Table with supported baudrates (defined in config_xyz.h)
  */
 static const unsigned long baudrate_table[] = CONFIG_SYS_BAUDRATE_TABLE;
-#defineN_BAUDRATES (sizeof(baudrate_table) / sizeof(baudrate_table[0]))
 
 /**
  * serial_null() - Void registration routine of a serial driver
@@ -74,11 +73,11 @@ static int on_baudrate(const char *name, const char *value, 
enum env_op op,
if (gd-baudrate == baudrate)
return 0;
 
-   for (i = 0; i  N_BAUDRATES; ++i) {
+   for (i = 0; i  ARRAY_SIZE(baudrate_table); ++i) {
if (baudrate == baudrate_table[i])
break;
}
-   if (i == N_BAUDRATES) {
+   if (i == ARRAY_SIZE(baudrate_table)) {
if ((flags  H_FORCE) == 0)
printf(## Baudrate %d bps not supported\n,
baudrate);
-- 
1.8.1.2



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

[U-Boot] [PATCH 1/3] hwmon: lm63: Use ARRAY_SIZE at appropriate place

2013-06-22 Thread Axel Lin

Signed-off-by: Axel Lin axel@ingics.com
---
 drivers/hwmon/lm63.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/hwmon/lm63.c b/drivers/hwmon/lm63.c
index f3adf64..bb8e644 100644
--- a/drivers/hwmon/lm63.c
+++ b/drivers/hwmon/lm63.c
@@ -133,8 +133,7 @@ int dtt_init_one(int sensor)
/*
 * Setup PWM Lookup-Table
 */
-   for (i = 0; i  sizeof(pwm_lookup) / sizeof(struct pwm_lookup_entry);
-i++) {
+   for (i = 0; i  ARRAY_SIZE(pwm_lookup); i++) {
int address = DTT_PWM_LOOKUP_BASE + 2 * i;
val = pwm_lookup[i].temp;
if (is_lm64(sensor))
-- 
1.8.1.2



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

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

2013-06-22 Thread Albert ARIBAUD

Hi Marek,

On Sat, 22 Jun 2013 15:26:21 +0200, Marek Vasut ma...@denx.de wrote:

 The following changes since commit fbf87b1823dd5ebc2a384711ea2c677543019ece:
 
   arm: optimize relocate_code routine (2013-06-21 23:05:50 +0200)
 
 are available in the git repository at:
 
   git://git.denx.de/u-boot-pxa.git master
 
 for you to fetch changes up to 9dc8fef2583f23ca6a99c6f5e709a8b80018364f:
 
   pxa: fix memory coherency problem after relocation (2013-06-22 15:25:28 
 +0200)
 
 
 Mike Dunn (5):
   pxa: add support for palmtreo680 board
   pxa: palmtreo680 flash programming utility
   pxa: turn icache off in cpu_init_crit()
   pxa: use -mcpu=xscale compiler option
   pxa: fix memory coherency problem after relocation
 
  CREDITS  |4 +
  MAINTAINERS  |3 +
  arch/arm/cpu/pxa/config.mk   |2 +-
  arch/arm/cpu/pxa/start.S |3 +-
  arch/arm/lib/relocate.S  |9 +++
  board/palmtreo680/Makefile   |   34 +
  board/palmtreo680/README |  581 
 ++
  board/palmtreo680/palmtreo680.c  |  148 +++
  boards.cfg   |1 +
  include/configs/palmtreo680.h|  286 
 
  tools/palmtreo680/flash_u-boot.c |  177 
 ++
  11 files changed, 1245 insertions(+), 3 deletions(-)
  create mode 100644 board/palmtreo680/Makefile
  create mode 100644 board/palmtreo680/README
  create mode 100644 board/palmtreo680/palmtreo680.c
  create mode 100644 include/configs/palmtreo680.h
  create mode 100644 tools/palmtreo680/flash_u-boot.c

gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1)

fails with warnings for palmtreo680:

pxa27x_udc.c: In function 'udc_read_urb':
pxa27x_udc.c:154:21: warning: variable 'is_short' set but not used
[-Wunused-but-set-variable] pxa27x_udc.c: In function
'udc_state_changed': pxa27x_udc.c:405:25: warning: variable 'alternate'
set but not used [-Wunused-but-set-variable] pxa27x_udc.c:405:14:
warning: variable 'interface' set but not used
[-Wunused-but-set-variable] pxa27x_udc.c:405:6: warning: variable
'config' set but not used [-Wunused-but-set-variable] docg4_spl.c: In
function 'docg4_load_block_reliable': docg4_spl.c:116:32: warning:
variable 'magic_low' set but not used [-Wunused-but-set-variable]
docg4_spl.c:116:20: warning: variable 'magic_high' set but not used
[-Wunused-but-set-variable] docg4_spl.c:116:11: warning: variable
'discard' set but not used [-Wunused-but-set-variable]

Mike, please fix the warnings; Marek, please update u-boot-pxa/master
and submit a new PR.

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

[U-Boot] [PATCH 2/3] mtd: cfi_flash: Use ARRAY_SIZE at appropriate places

2013-06-22 Thread Axel Lin

Signed-off-by: Axel Lin axel@ingics.com
---
 drivers/mtd/cfi_flash.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index 25f8752..a13b0b8 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -1797,7 +1797,7 @@ static int flash_detect_legacy(phys_addr_t base, int 
banknum)
};
int i;
 
-   for (i = 0; i  sizeof(modes) / sizeof(modes[0]); i++) {
+   for (i = 0; i  ARRAY_SIZE(modes); i++) {
info-vendor = modes[i];
info-start[0] =
(ulong)map_physmem(base,
@@ -1883,8 +1883,7 @@ static int __flash_detect_cfi (flash_info_t * info, 
struct cfi_qry *qry)
/* Issue FLASH reset command */
flash_cmd_reset(info);
 
-   for (cfi_offset=0;
-cfi_offset  sizeof(flash_offset_cfi) / sizeof(uint);
+   for (cfi_offset = 0; cfi_offset  ARRAY_SIZE(flash_offset_cfi);
 cfi_offset++) {
flash_write_cmd (info, 0, flash_offset_cfi[cfi_offset],
 FLASH_CMD_CFI);
@@ -2336,7 +2335,7 @@ void flash_protect_default(void)
 #endif
 
 #if defined(CONFIG_SYS_FLASH_AUTOPROTECT_LIST)
-   for (i = 0; i  (sizeof(apl) / sizeof(struct apl_s)); i++) {
+   for (i = 0; i  ARRAY_SIZE(apl); i++) {
debug(autoprotecting from %08lx to %08lx\n,
  apl[i].start, apl[i].start + apl[i].size - 1);
flash_protect(FLAG_PROTECT_SET,
-- 
1.8.1.2



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

[U-Boot] [PATCH 3/3] usb: musb: Use ARRAY_SIZE at appropriate places

2013-06-22 Thread Axel Lin

Signed-off-by: Axel Lin axel@ingics.com
---
 drivers/usb/musb/musb_hcd.c | 3 +--
 drivers/usb/musb/musb_udc.c | 3 +--
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/musb/musb_hcd.c b/drivers/usb/musb/musb_hcd.c
index 60e03a4..7bb91e5 100644
--- a/drivers/usb/musb/musb_hcd.c
+++ b/drivers/usb/musb/musb_hcd.c
@@ -1105,8 +1105,7 @@ int usb_lowlevel_init(int index, void **controller)
 
/* Configure all the endpoint FIFO's and start usb controller */
musbr = musb_cfg.regs;
-   musb_configure_ep(epinfo[0],
-   sizeof(epinfo) / sizeof(struct musb_epinfo));
+   musb_configure_ep(epinfo[0], ARRAY_SIZE(epinfo));
musb_start();
 
/*
diff --git a/drivers/usb/musb/musb_udc.c b/drivers/usb/musb/musb_udc.c
index e0b4217..e8a2ce0 100644
--- a/drivers/usb/musb/musb_udc.c
+++ b/drivers/usb/musb/musb_udc.c
@@ -894,8 +894,7 @@ void udc_setup_ep(struct usb_device_instance *device, 
unsigned int id,
epinfo[id * 2].epsize = endpoint-rcv_packetSize;
}
 
-   musb_configure_ep(epinfo[0],
- sizeof(epinfo) / sizeof(struct musb_epinfo));
+   musb_configure_ep(epinfo[0], ARRAY_SIZE(epinfo));
} else {
if (debug_level  0)
serial_printf(ERROR : %s endpoint request %d 
-- 
1.8.1.2



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

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

2013-06-22 Thread Mike Dunn

On 06/22/2013 09:57 AM, Albert ARIBAUD wrote:
 Hi Marek,
 
 On Sat, 22 Jun 2013 15:26:21 +0200, Marek Vasut ma...@denx.de wrote:
 
 The following changes since commit fbf87b1823dd5ebc2a384711ea2c677543019ece:

   arm: optimize relocate_code routine (2013-06-21 23:05:50 +0200)

 are available in the git repository at:

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

 for you to fetch changes up to 9dc8fef2583f23ca6a99c6f5e709a8b80018364f:

   pxa: fix memory coherency problem after relocation (2013-06-22 15:25:28 
 +0200)

 
 Mike Dunn (5):
   pxa: add support for palmtreo680 board
   pxa: palmtreo680 flash programming utility
   pxa: turn icache off in cpu_init_crit()
   pxa: use -mcpu=xscale compiler option
   pxa: fix memory coherency problem after relocation

  CREDITS  |4 +
  MAINTAINERS  |3 +
  arch/arm/cpu/pxa/config.mk   |2 +-
  arch/arm/cpu/pxa/start.S |3 +-
  arch/arm/lib/relocate.S  |9 +++
  board/palmtreo680/Makefile   |   34 +
  board/palmtreo680/README |  581 
 ++
  board/palmtreo680/palmtreo680.c  |  148 +++
  boards.cfg   |1 +
  include/configs/palmtreo680.h|  286 
 
  tools/palmtreo680/flash_u-boot.c |  177 
 ++
  11 files changed, 1245 insertions(+), 3 deletions(-)
  create mode 100644 board/palmtreo680/Makefile
  create mode 100644 board/palmtreo680/README
  create mode 100644 board/palmtreo680/palmtreo680.c
  create mode 100644 include/configs/palmtreo680.h
  create mode 100644 tools/palmtreo680/flash_u-boot.c
 
 gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1)
 
 fails with warnings for palmtreo680:


I don't get these warnings, despite the u-boot makefiles passing -Wall to gcc.
I'm using gcc version 4.5.4...  I guess maybe I need to update gcc because later
versions are stricter?  I'll go ahead and do that, and if this produces the
warnings, I'll submit patches that eliminates them.  Sorry.

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

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

2013-06-22 Thread Albert ARIBAUD

Hi Mike,

On Sat, 22 Jun 2013 10:42:27 -0700, Mike Dunn miked...@newsguy.com
wrote:

 On 06/22/2013 09:57 AM, Albert ARIBAUD wrote:
  Hi Marek,
  
  On Sat, 22 Jun 2013 15:26:21 +0200, Marek Vasut ma...@denx.de wrote:
  
  The following changes since commit 
  fbf87b1823dd5ebc2a384711ea2c677543019ece:
 
arm: optimize relocate_code routine (2013-06-21 23:05:50 +0200)
 
  are available in the git repository at:
 
git://git.denx.de/u-boot-pxa.git master
 
  for you to fetch changes up to 9dc8fef2583f23ca6a99c6f5e709a8b80018364f:
 
pxa: fix memory coherency problem after relocation (2013-06-22 15:25:28 
  +0200)
 
  
  Mike Dunn (5):
pxa: add support for palmtreo680 board
pxa: palmtreo680 flash programming utility
pxa: turn icache off in cpu_init_crit()
pxa: use -mcpu=xscale compiler option
pxa: fix memory coherency problem after relocation
 
   CREDITS  |4 +
   MAINTAINERS  |3 +
   arch/arm/cpu/pxa/config.mk   |2 +-
   arch/arm/cpu/pxa/start.S |3 +-
   arch/arm/lib/relocate.S  |9 +++
   board/palmtreo680/Makefile   |   34 +
   board/palmtreo680/README |  581 
  ++
   board/palmtreo680/palmtreo680.c  |  148 
  +++
   boards.cfg   |1 +
   include/configs/palmtreo680.h|  286 
  
   tools/palmtreo680/flash_u-boot.c |  177 
  ++
   11 files changed, 1245 insertions(+), 3 deletions(-)
   create mode 100644 board/palmtreo680/Makefile
   create mode 100644 board/palmtreo680/README
   create mode 100644 board/palmtreo680/palmtreo680.c
   create mode 100644 include/configs/palmtreo680.h
   create mode 100644 tools/palmtreo680/flash_u-boot.c
  
  gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1)
  
  fails with warnings for palmtreo680:
 
 
 I don't get these warnings, despite the u-boot makefiles passing -Wall to gcc.
 I'm using gcc version 4.5.4...  I guess maybe I need to update gcc because 
 later
 versions are stricter?  I'll go ahead and do that, and if this produces the
 warnings, I'll submit patches that eliminates them.  Sorry.

No need to be sorry -- you were using a toolchain that does not emit
these warnings, so you could not be expected to see them.

FYI, I am using the ARM cross-toolchain available in my Ubuntu 13.04.

 Thanks,
 Mike

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

Re: [U-Boot] [PATCH] OpenRD: relocate environment to 640kB

2013-06-22 Thread Tom Rini

On Sat, Jun 22, 2013 at 11:29:59AM +0200, Albert ARIBAUD wrote:

 On Tue, 11 Jun 2013 12:00:19 +0200, Albert ARIBAUD
 albert.u.b...@aribaud.net wrote:
 
  Hi Sascha,
  
  On Mon, 27 May 2013 11:42:26 +0200, Sascha Silbe
  t-ub...@infra-silbe.de wrote:
  
   U-Boot has become slightly larger than where the environment sector
   was previously located. Saving the environment would brick the device.
   
   Relocate the environment to where it is with the stock (i.e. Marvell
   USP) U-Boot version. That should give plenty of room for U-Boot to
   grow, including local customisations.
   
   This obviously breaks compatibility with previous mainline versions of
   U-Boot. Users will need to back up the environment before an update
   and restore it afterwards, or manually copy it to the new address
   before the update.
   
   Signed-off-by: Sascha Silbe t-ub...@infra-silbe.de
   ---
include/configs/openrd.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
   
   diff --git a/include/configs/openrd.h b/include/configs/openrd.h
   index 53bafe1..ea7f9aa 100644
   --- a/include/configs/openrd.h
   +++ b/include/configs/openrd.h
   @@ -90,8 +90,8 @@
 * it has to be rounded to sector size
 */
#define CONFIG_ENV_SIZE  0x2 /* 128k */
   -#define CONFIG_ENV_ADDR  0x6
   -#define CONFIG_ENV_OFFSET0x6 /* env starts here */
   +#define CONFIG_ENV_ADDR  0xa
   +#define CONFIG_ENV_OFFSET0xa /* env starts here */

/*
 * Default environment variables
  
  CC:ing Tom.
  
  This patch is for 2013.10, not 2013.07, but I prefer raising the issue
  as early as possible.
  
  If there is no way to make things smoother, then I think the 2013.10
  release notes should contain a red, blinking, paragraph about this. I
  would *hate* it if people were not warned and given a method to port
  their current environment setting over.
  
  Possibly even, the 2013.07 could have a warning about the change to
  come, so that people have a better chance yet to prepare for the change.
  
  Amicalement,
 
 Ping.

Oh right, agree your idea here.

-- 
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] Modifying the Device tree fields

Re: [U-Boot] uboot ERROR nfs: Cannot umount error

Re: [U-Boot] [PATCH] OpenRD: relocate environment to 640kB

Re: [U-Boot] [PATCH] arm: omap5_uevm: Correct the console sys prompt for 5432

[U-Boot] [RFC] interrupt handling

Re: [U-Boot] [PATCH] Fix block device accesses beyond 2TiB

[U-Boot] [PATCH] gpio: pca953x: Use ARRAY_SIZE instead of reinventing it

Re: [U-Boot] [PATCH] gpio: pca953x: Use ARRAY_SIZE instead of reinventing it

Re: [U-Boot] [RFC] interrupt handling

Re: [U-Boot] [[PATCH]] imx6: fix GPR2 wrong definition

Re: [U-Boot] [Patch v2] PHY: micrel.c: add support for KSZ9031

Re: [U-Boot] [PATCH] gpio: pca953x: Use ARRAY_SIZE instead of reinventing it

[U-Boot] [PULL] u-boot-pxa/master

[U-Boot] [PATCH] cmd_i2c: Use ARRAY_SIZE instead of reinventing it

[U-Boot] [PATCH] mpc5200: Misc updates to a3m071 config header

Re: [U-Boot] [PATCH] Fix block device accesses beyond 2TiB

[U-Boot] [PATCH] serial: Use ARRAY_SIZE instead of reinventing it

[U-Boot] [PATCH 1/3] hwmon: lm63: Use ARRAY_SIZE at appropriate place

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

[U-Boot] [PATCH 2/3] mtd: cfi_flash: Use ARRAY_SIZE at appropriate places

[U-Boot] [PATCH 3/3] usb: musb: Use ARRAY_SIZE at appropriate places

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

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

Re: [U-Boot] [PATCH] OpenRD: relocate environment to 640kB

24 matches

Site Navigation

Mail list logo

Footer information