Re: [U-Boot] [PATCH 2/4] net: round up before calling flush_cache

[Stefano Babic]

On 01/04/2012 21:23, Mike Frysinger wrote:
> On Sunday 01 April 2012 09:22:59 Stefano Babic wrote:
>> If the range passed to flush_cache is not multiple of
>> ARCH_DMA_MINALIGN, a warning due to mislaignment is printed. 
>> Detected with fec_mxc, mx35 boards:
>> 
>> CACHE: Misaligned operation at range [8080, 8083c310]
> 
> warning on flushing is broken.  the arch/arm/cpu/arm926ejs/cache.c
> code should probably be fixed instead.

mmhhh...I agree with you. Marek, really I am expecting that the same
message appears on MX28, not only on arm1136. Only if the size of the
downloaded file is a multiple of 32, the warning will not appear.

Anyway, the message is misleading. Do we need such kind of warning or
can we simply silently ignore it ?

Stefano

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

Re: [U-Boot] [PATCH] Prevent malloc with size 0

[Graeme Russ]

Hi Joakim,

On Apr 2, 2012 4:55 PM, "Joakim Tjernlund" 
wrote:
>
> >
> > Hi Marek,
> >
> > On Mon, Apr 2, 2012 at 1:36 PM, Marek Vasut 
wrote:
> > > Dear Mike Frysinger,
> > >
> > >> On Sunday 01 April 2012 20:25:44 Graeme Russ wrote:
> > >> > b) The code calling malloc(0) is making a perfectly legitimate
assumption
> > >> >
> > >> >based on how glibc handles malloc(0)
> > >>
> > >> not really.  POSIX says malloc(0) is implementation defined (so it
may
> > >> return a unique address, or it may return NULL).  no userspace code
> > >> assuming malloc(0) will return non-NULL is correct.
> > >
> > > Which is your implementation-defined ;-) But I have to agree with
this one. So
> > > my vote is for returning NULL.
> >
> > Also, no userspace code assuming malloc(0) will return NULL is correct
> >
> > Point being, no matter which implementation is chosen, it is up to the
> > caller to not assume that the choice that was made was, in fact, the
> > choice that was made.
> >
> > I.e. the behaviour of malloc(0) should be able to be changed on a whim
> > with no side-effects
> >
> > So I think I should change my vote to returning NULL for one reason and
> > one reason only - It is faster during run-time
>
> Then u-boot will be incompatible with both glibc and the linux kernel, it
seems

Forget aboug other implementations...

What matters is that the fact that the behaviour is undefined and it is up
to the caller to take that into account

> to me that any modern impl. of malloc(0) will return a non NULL ptr.
>
> It does need to be slower, just return ~0 instead, the kernel does
something similar:
>  if (!size)
> return ZERO_SIZE_PTR;

That could work, but technically I don't think it complies as it is not a
pointer to allocated memory...

Regards,

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

Re: [U-Boot] [PATCH v2 0/2] misc:pmic: Support for MAX8997 PMIC at Trats Samsung device

[Lukasz Majewski]

On Thu, 29 Mar 2012 13:29:16 +0200
Lukasz Majewski  wrote:

> This patch series adds support for MAX8997 PMIC device. This device
> has been used at Trats Samsung target board. 
> 
> ---
> Changes for v2:
> - function for converting voltage to register value has been removed
> 
> ---
> Lukasz Majewski (2):
>   misc:pmic:max8997 MAX8997 support for PMIC driver
>   misc:pmic:samsung Convert TRATS target to use MAX8997 instead of
> MAX8998
> 
>  board/samsung/trats/trats.c |   27 +++
>  drivers/misc/Makefile   |1 +
>  drivers/misc/pmic_max8997.c |   43 ++
>  include/configs/trats.h |2 +-
>  include/max8997_pmic.h  |  190
> +++ 5 files changed, 245
> insertions(+), 18 deletions(-) create mode 100644
> drivers/misc/pmic_max8997.c create mode 100644 include/max8997_pmic.h
> 

Hi Stefano,

Please look into those resend patches.
I've added changes, which only fix the Trats board. No new functionality
for the PMIC framework is included.

New functionality will be added after releasing 2012.04 u-boot.

-- 
Best regards,

Lukasz Majewski

Samsung Poland R&D Center
Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/2] misc:pmic:max8997 MAX8997 support for PMIC driver

[Stefano Babic]

On 29/03/2012 13:29, Lukasz Majewski wrote:
> This commit adds support for MAX8997 PMIC driver.
> 
> Signed-off-by: Lukasz Majewski 
> Signed-off-by: Kyungmin Park 
> Cc: Stefano Babic 
> ---
> Changes for v2:
> - Function for converting voltage to proper register value has been removed
> 
> ---
> 
>  drivers/misc/Makefile   |1 +
>  drivers/misc/pmic_max8997.c |   43 ++
>  include/max8997_pmic.h  |  190 
> +++
>  3 files changed, 234 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/misc/pmic_max8997.c
>  create mode 100644 include/max8997_pmic.h
> 
> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> index a709707..30c7f8d 100644
> --- a/drivers/misc/Makefile
> +++ b/drivers/misc/Makefile
> @@ -39,6 +39,7 @@ COBJS-$(CONFIG_PMIC_FSL) += pmic_fsl.o
>  COBJS-$(CONFIG_PMIC_I2C) += pmic_i2c.o
>  COBJS-$(CONFIG_PMIC_SPI) += pmic_spi.o
>  COBJS-$(CONFIG_PMIC_MAX8998) += pmic_max8998.o
> +COBJS-$(CONFIG_PMIC_MAX8997) += pmic_max8997.o
>  
>  COBJS:= $(COBJS-y)
>  SRCS := $(COBJS:.o=.c)
> diff --git a/drivers/misc/pmic_max8997.c b/drivers/misc/pmic_max8997.c
> new file mode 100644
> index 000..de7e9f6
> --- /dev/null
> +++ b/drivers/misc/pmic_max8997.c
> @@ -0,0 +1,43 @@
> +/*
> + *  Copyright (C) 2012 Samsung Electronics
> + *  Lukasz Majewski 
> + *
> + * See file CREDITS for list of people who contributed to this
> + * project.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> + * MA 02111-1307 USA
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +int pmic_init(void)
> +{
> + struct pmic *p = get_pmic();
> + static const char name[] = "MAX8997_PMIC";
> +
> + puts("Board PMIC init\n");
> +
> + p->name = name;
> + p->interface = PMIC_I2C;
> + p->number_of_regs = PMIC_NUM_OF_REGS;
> + p->hw.i2c.addr = MAX8997_I2C_ADDR;
> + p->hw.i2c.tx_num = 1;
> + p->bus = I2C_PMIC;
> +
> + return 0;
> +}
> diff --git a/include/max8997_pmic.h b/include/max8997_pmic.h
> new file mode 100644
> index 000..17ae24e
> --- /dev/null
> +++ b/include/max8997_pmic.h
> @@ -0,0 +1,190 @@
> +/*
> + *  Copyright (C) 2011 Samsung Electronics
> + *  Lukasz Majewski 
> + *
> + * See file CREDITS for list of people who contributed to this
> + * project.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> + * MA 02111-1307 USA
> + */
> +
> +#ifndef __MAX8997_PMIC_H_
> +#define __MAX8997_PMIC_H_
> +
> +/* MAX 8997 registers */
> +enum {
> + MAX8997_REG_PMIC_ID0= 0x00,
> + MAX8997_REG_PMIC_ID1= 0x01,
> + MAX8997_REG_INTSRC  = 0x02,
> + MAX8997_REG_INT1= 0x03,
> + MAX8997_REG_INT2= 0x04,
> + MAX8997_REG_INT3= 0x05,
> + MAX8997_REG_INT4= 0x06,
> +
> + MAX8997_REG_INT1MSK = 0x08,
> + MAX8997_REG_INT2MSK = 0x09,
> + MAX8997_REG_INT3MSK = 0x0a,
> + MAX8997_REG_INT4MSK = 0x0b,
> +
> + MAX8997_REG_STATUS1 = 0x0d,
> + MAX8997_REG_STATUS2 = 0x0e,
> + MAX8997_REG_STATUS3 = 0x0f,
> + MAX8997_REG_STATUS4 = 0x10,
> +
> + MAX8997_REG_MAINCON1= 0x13,
> + MAX8997_REG_MAINCON2= 0x14,
> + MAX8997_REG_BUCKRAMP= 0x15,
> +
> + MAX8997_REG_BUCK1CTRL   = 0x18,
> + MAX8997_REG_BUCK1DVS1   = 0x19,
> + MAX8997_REG_BUCK1DVS2   = 0x1a,
> + MAX8997_REG_BUCK1DVS3   = 0x1b,
> + MAX8997_REG_BUCK1DVS4   = 0x1c,
> + MAX8997_REG_BUCK1DVS5   = 0x1d,
> + MAX8997_REG_BUCK1DVS6   = 0x1e,
> + MAX8997_REG_BUCK1DVS7   = 0x1f,
> + MAX8997_REG_BUCK1DVS8   = 0x20,
> + MAX8997_REG_BUCK2CTRL   = 0x21,
> + M

Re: [U-Boot] [PATCH v2 0/2] misc:pmic: Support for MAX8997 PMIC at Trats Samsung device

[Stefano Babic]

On 02/04/2012 09:26, Lukasz Majewski wrote:
> Hi Stefano,
>

Hi Lukasz,

> Please look into those resend patches.
> I've added changes, which only fix the Trats board. No new functionality
> for the PMIC framework is included.
> 
> New functionality will be added after releasing 2012.04 u-boot.

no issue, I sent my Ack.

I could push Patch 1/2, as I did for previous pmic patches, but patch
2/2 is in Minkyu's competence and should be merged into Samsung's tree.
To avoid breakage, I have no problems if Minkyu pick up the whole
patchset in his tree (or I do the same in my tree).

Minkyu, what do you prefer ?

Best regards,
Stefano Babic

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

Re: [U-Boot] [PATCH] Prevent malloc with size 0

[Joakim Tjernlund]

Hi Grame

Graeme Russ  wrote on 2012/04/02 09:17:44:
>
> Hi Joakim,
> On Apr 2, 2012 4:55 PM, "Joakim Tjernlund"  
> wrote:
> >
> > >
> > > Hi Marek,
> > >
> > > On Mon, Apr 2, 2012 at 1:36 PM, Marek Vasut  wrote:
> > > > Dear Mike Frysinger,
> > > >
> > > >> On Sunday 01 April 2012 20:25:44 Graeme Russ wrote:
> > > >> > b) The code calling malloc(0) is making a perfectly legitimate 
> > > >> > assumption
> > > >> >
> > > >> >    based on how glibc handles malloc(0)
> > > >>
> > > >> not really.  POSIX says malloc(0) is implementation defined (so it may
> > > >> return a unique address, or it may return NULL).  no userspace code
> > > >> assuming malloc(0) will return non-NULL is correct.
> > > >
> > > > Which is your implementation-defined ;-) But I have to agree with this 
> > > > one. So
> > > > my vote is for returning NULL.
> > >
> > > Also, no userspace code assuming malloc(0) will return NULL is correct
> > >
> > > Point being, no matter which implementation is chosen, it is up to the
> > > caller to not assume that the choice that was made was, in fact, the
> > > choice that was made.
> > >
> > > I.e. the behaviour of malloc(0) should be able to be changed on a whim
> > > with no side-effects
> > >
> > > So I think I should change my vote to returning NULL for one reason and
> > > one reason only - It is faster during run-time
> >
> > Then u-boot will be incompatible with both glibc and the linux kernel, it 
> > seems
> Forget aboug other implementations...
> What matters is that the fact that the behaviour is undefined and it is up to 
> the caller to take that into account

Well, u-boot borrows code from both kernel and user space so it would make 
sense if
malloc(0) behaved the same. Especially for kernel code which tend to depend on 
the
kernels impl.(just look at Scotts example)

> > to me that any modern impl. of malloc(0) will return a non NULL ptr.
> >
> > It does need to be slower, just return ~0 instead, the kernel does 
> > something similar:
> >  if (!size)
> >     return ZERO_SIZE_PTR;
> That could work, but technically I don't think it complies as it is not a 
> pointer to allocated memory...

It doesn't not have to be allocated memory, just a ptr != NULL which you can do 
free() on.

 Jocke

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

Re: [U-Boot] [PATCH v2 1/2] misc:pmic:max8997 MAX8997 support for PMIC driver

[Lukasz Majewski]

Hi Stefano,

> 
> Acked-by: Stefano Babic 
> 
> Best regards,
> Stefano Babic
> 

Thanks for ACK,

Since it is PMIC related, I'd like to ask you to take it to your (IMX?)
tree.

BTW: I predict that PMIC subsytem will grow (since PMIC's are more and
more complicated - e.g. MAX8997).

Up to now the IMX tree is used to push it to mainline. 
Stefano if this situation is OK with you, then there is no topic :-).



-- 
Best regards,

Lukasz Majewski

Samsung Poland R&D Center
Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 0/2] misc:pmic: Support for MAX8997 PMIC at Trats Samsung device

[Minkyu Kang]

Dear Stefano Babic,

On 2 April 2012 16:37, Stefano Babic  wrote:
> On 02/04/2012 09:26, Lukasz Majewski wrote:
>> Hi Stefano,
>>
>
> Hi Lukasz,
>
>> Please look into those resend patches.
>> I've added changes, which only fix the Trats board. No new functionality
>> for the PMIC framework is included.
>>
>> New functionality will be added after releasing 2012.04 u-boot.
>
> no issue, I sent my Ack.
>
> I could push Patch 1/2, as I did for previous pmic patches, but patch
> 2/2 is in Minkyu's competence and should be merged into Samsung's tree.
> To avoid breakage, I have no problems if Minkyu pick up the whole
> patchset in his tree (or I do the same in my tree).
>

OK. I will push this patchset to samsung tree.

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

Re: [U-Boot] [PATCH v2 1/2] misc:pmic:max8997 MAX8997 support for PMIC driver

[Stefano Babic]

On 02/04/2012 09:54, Lukasz Majewski wrote:
> 
> Hi Stefano,
> 
>>
>> Acked-by: Stefano Babic 
>>
>> Best regards,
>> Stefano Babic
>>
> 
> Thanks for ACK,
> 
> Since it is PMIC related, I'd like to ask you to take it to your (IMX?)
> tree.
> 

I have also a u-boot-staging tree. I will use this, as changes have
nothing to do with IMX.

> BTW: I predict that PMIC subsytem will grow (since PMIC's are more and
> more complicated - e.g. MAX8997).

I think we will move all pmic stuff from drivers/misc to drivers/power,
because PMICs belong better to this category. At the beginning, PMIC was
related to only one Freescale's chip.

> 
> Up to now the IMX tree is used to push it to mainline. 
> Stefano if this situation is OK with you, then there is no topic :-).

Ok - I will go on.

Best regards,
Stefano Babic

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

[U-Boot] [PATCH v6] kirkwood: add NAS62x0 board support

[Luka Perkov]

Add support for new boards RaidSonic ICY BOX NAS6210 and NAS6220.

Only difference between boards is number of SATA ports.

More information about the boards can be found here:

http://www.raidsonic.de/en/products/nas-systems.php?we_objectID=7036
http://www.raidsonic.de/en/products/nas-systems.php?we_objectID=7515

Signed-off-by: Luka Perkov 
Signed-off-by: Gerald Kerma 
Signed-off-by: Simon Baatz 
---

Changes from version v1:

 * use tools/checkpatch.pl to locate patch errors and fix them
 * add two entries in boards.cfg, one for each board
 * fixed CONFIG_RESET_PHY_R
 * don't define values for macros that enable features only
 * remove static RAM configuration
 * fix comments
 * use only CONFIG_ENV_OFFSET and remove CONFIG_ENV_ADDR
 * clean coding style
 * add entry in MAINTAINERS file

Changes from version v2:

 * use defined() in macros for board selection for robustness

Changes from version v3:

 * don't use utf8 for Geralds name
 * don't mix upper/lower case in kwbimage.cfg
 * fix prompt

Changes from version v4:
 * fix board Makefile (clean and distclean)
 * use generic way to handle arch number of the board
 * fix MAINTAINERS file
 * move code from Marvell to raidsonic folder
 * use CONFIG_MACH_TYPE
 * set only necessary GPIOs
 * use link instead of address for license
 * add few links about board being supported for quick reference
 * add previous change logs
 * multiple updates to kwbimage.cfg, thank you Simon

Changes from version v5:
 * remove typo from kwbimage.cfg (duplicated lines), thank you David
 * clean up comments in kwbimage.cfg

 MAINTAINERS |5 +
 board/raidsonic/ib62x0/Makefile |   43 +
 board/raidsonic/ib62x0/ib62x0.c |   79 
 board/raidsonic/ib62x0/ib62x0.h |   40 
 board/raidsonic/ib62x0/kwbimage.cfg |  169 ++
 boards.cfg  |2 +
 include/configs/ib62x0.h|  172 +++
 7 files changed, 510 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 72f8b64..e6608ea 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -781,6 +781,11 @@ Linus Walleij 
integratorapvarious
integratorcpvarious
 
+Luka Perkov 
+
+   ib6210  ARM926EJS
+   ib6220  ARM926EJS
+
 Dave Peverley 
 
omap730p2   ARM926EJS
diff --git a/board/raidsonic/ib62x0/Makefile b/board/raidsonic/ib62x0/Makefile
new file mode 100644
index 000..d450f8d
--- /dev/null
+++ b/board/raidsonic/ib62x0/Makefile
@@ -0,0 +1,43 @@
+#
+# (C) Copyright 2009
+# Marvell Semiconductor 
+# Written-by: Prafulla Wadaskar 
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see .
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS  := ib62x0.o
+
+SRCS   := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS))
+SOBJS  := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+   $(call cmd_link_o_target, $(OBJS) $(SOBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/raidsonic/ib62x0/ib62x0.c b/board/raidsonic/ib62x0/ib62x0.c
new file mode 100644
index 000..65f2c2e
--- /dev/null
+++ b/board/raidsonic/ib62x0/ib62x0.c
@@ -0,0 +1,79 @@
+/*
+ * Copyright (C) 2011-2012
+ * Gerald Kerma 
+ * Luka Perkov 
+ * Simon Baatz 
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see .
+ */
+
+#include 
+#include 
+#include 
+#inc

Re: [U-Boot] [PATCH v6] kirkwood: add NAS62x0 board support

[Simon Baatz]

Hi Luka,

Am 01.04.2012 01:17, schrieb Luka Perkov:

Add support for new boards RaidSonic ICY BOX NAS6210 and NAS6220.

Only difference between boards is number of SATA ports.



just realizing that you make a difference in the number of SATA ports 
between 6210 and 6220 here. However, the 6210 has two SATA ports as 
well. The second one is just realized as an eSATA port, since there is 
only one drive bay.


- Simon

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

[U-Boot] please add me to email list

[wchfuestc]

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

Re: [U-Boot] [PATCH v2 0/2] misc:pmic: Support for MAX8997 PMIC at Trats Samsung device

[Stefano Babic]

On 02/04/2012 09:59, Minkyu Kang wrote:
> Dear Stefano Babic,
> 
> On 2 April 2012 16:37, Stefano Babic  wrote:
>> On 02/04/2012 09:26, Lukasz Majewski wrote:
>>> Hi Stefano,
>>>
>>
>> Hi Lukasz,
>>
>>> Please look into those resend patches.
>>> I've added changes, which only fix the Trats board. No new functionality
>>> for the PMIC framework is included.
>>>
>>> New functionality will be added after releasing 2012.04 u-boot.
>>
>> no issue, I sent my Ack.
>>
>> I could push Patch 1/2, as I did for previous pmic patches, but patch
>> 2/2 is in Minkyu's competence and should be merged into Samsung's tree.
>> To avoid breakage, I have no problems if Minkyu pick up the whole
>> patchset in his tree (or I do the same in my tree).
>>
> 
> OK. I will push this patchset to samsung tree.

Ok, thanks.

Stefano Babic


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

Re: [U-Boot] [PATCH v2 1/2] misc:pmic:max8997 MAX8997 support for PMIC driver

[Lukasz Majewski]

Hi Stefano,

> On 02/04/2012 09:54, Lukasz Majewski wrote:
> > 
> > Hi Stefano,
> > 
> >>
> >> Acked-by: Stefano Babic 
> >>
> >> Best regards,
> >> Stefano Babic
> >>
> > 
> > Thanks for ACK,
> > 
> > Since it is PMIC related, I'd like to ask you to take it to your
> > (IMX?) tree.
> > 
> 
> I have also a u-boot-staging tree. I will use this, as changes have
> nothing to do with IMX.

Ok, good.

> 
> > BTW: I predict that PMIC subsytem will grow (since PMIC's are more
> > and more complicated - e.g. MAX8997).
> 
> I think we will move all pmic stuff from drivers/misc to
> drivers/power, because PMICs belong better to this category. At the
> beginning, PMIC was related to only one Freescale's chip.

Yes, I also think, that this is a better place.
> 
> > 
> > Up to now the IMX tree is used to push it to mainline. 
> > Stefano if this situation is OK with you, then there is no
> > topic :-).
> 
> Ok - I will go on.

No topic then :-)


-- 
Best regards,

Lukasz Majewski

Samsung Poland R&D Center
Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/2] misc:pmic:max8997 MAX8997 support for PMIC driver

[Stefano Babic]

On 02/04/2012 10:13, Lukasz Majewski wrote:

>>
>> Ok - I will go on.
> 
> No topic then :-)

Minkyu has confirmed he will pick up both patches in Samsung's tree.

Best regards,
Stefano

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

[U-Boot] [PATCH v3 0/4] ARM: EXYNOS: add display driver for EXYNOS SoC

[Donghwa Lee]

This patch is for display driver version 3 of EXYNOS SoC.

[1/4]:  ARM: EXYNOS: definition of system registers
- to contorl FIMD of LBLK0 bypass selection, add missed 
definitions of system register
[2/4]:  ARM: EXYNOS:  add data structure for EXYNOS display driver
- It is needed to specific vidinfo_t data structure for 
EXYNOS display driver.
[3/4]:  ARM: EXYNOS: add exynos lcd clock interface
- Is is newly defined to interface to get lcd source clock.
[4/4]: ARM: EXYNOS: support EXYNOS display driver


change of v2: 
- define missing function declaration
- correct the wrong return value for some function
- etc

Thank you,
Donghwa Lee

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

[U-Boot] [PATCH v3 1/4] ARM: EXYNOS: definition of system registers

[Donghwa Lee]

This is definition of system registers for EXYNOS SoC.

Signed-off-by: Donghwa Lee 
Signed-off-by: Kyungmin Park 
---
 arch/arm/cpu/armv7/exynos/Makefile|2 +-
 arch/arm/cpu/armv7/exynos/system.c|   48 ++
 arch/arm/include/asm/arch-exynos/cpu.h|2 +
 arch/arm/include/asm/arch-exynos/system.h |   53 +
 4 files changed, 104 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/cpu/armv7/exynos/system.c
 create mode 100644 arch/arm/include/asm/arch-exynos/system.h

diff --git a/arch/arm/cpu/armv7/exynos/Makefile 
b/arch/arm/cpu/armv7/exynos/Makefile
index 124c380..75c31dc 100644
--- a/arch/arm/cpu/armv7/exynos/Makefile
+++ b/arch/arm/cpu/armv7/exynos/Makefile
@@ -22,7 +22,7 @@ include $(TOPDIR)/config.mk
 
 LIB= $(obj)lib$(SOC).o
 
-COBJS  += clock.o soc.o
+COBJS  += clock.o soc.o system.o
 
 SRCS   := $(SOBJS:.o=.S) $(COBJS:.o=.c)
 OBJS   := $(addprefix $(obj),$(COBJS) $(SOBJS))
diff --git a/arch/arm/cpu/armv7/exynos/system.c 
b/arch/arm/cpu/armv7/exynos/system.c
new file mode 100644
index 000..6c34730
--- /dev/null
+++ b/arch/arm/cpu/armv7/exynos/system.c
@@ -0,0 +1,48 @@
+/*
+ * Copyright (C) 2012 Samsung Electronics
+ * Donghwa Lee 
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include 
+#include 
+#include 
+
+static void exynos4_set_system_display(void)
+{
+   struct exynos4_sysreg *sysreg =
+   (struct exynos4_sysreg *)samsung_get_base_sysreg();
+   unsigned int cfg = 0;
+
+   /*
+* system register path set
+* 0: MIE/MDNIE
+* 1: FIMD Bypass
+*/
+   cfg = readl(&sysreg->display_ctrl);
+   cfg |= (1 << 1);
+   writel(cfg, &sysreg->display_ctrl);
+}
+
+void set_system_display_ctrl(void)
+{
+   if (cpu_is_exynos4())
+   exynos4_set_system_display();
+}
diff --git a/arch/arm/include/asm/arch-exynos/cpu.h 
b/arch/arm/include/asm/arch-exynos/cpu.h
index 89f2c2e..70048f0 100644
--- a/arch/arm/include/asm/arch-exynos/cpu.h
+++ b/arch/arm/include/asm/arch-exynos/cpu.h
@@ -29,6 +29,7 @@
 /* EXYNOS4 */
 #define EXYNOS4_GPIO_PART3_BASE0x0386
 #define EXYNOS4_PRO_ID 0x1000
+#define EXYNOS4_SYSREG_BASE0x1001
 #define EXYNOS4_POWER_BASE 0x1002
 #define EXYNOS4_SWRESET0x10020400
 #define EXYNOS4_CLOCK_BASE 0x1003
@@ -127,6 +128,7 @@ static inline unsigned int samsung_get_base_##device(void)  
\
 
 SAMSUNG_BASE(adc, ADC_BASE)
 SAMSUNG_BASE(clock, CLOCK_BASE)
+SAMSUNG_BASE(sysreg, SYSREG_BASE)
 SAMSUNG_BASE(fimd, FIMD_BASE)
 SAMSUNG_BASE(gpio_part1, GPIO_PART1_BASE)
 SAMSUNG_BASE(gpio_part2, GPIO_PART2_BASE)
diff --git a/arch/arm/include/asm/arch-exynos/system.h 
b/arch/arm/include/asm/arch-exynos/system.h
new file mode 100644
index 000..c85f949
--- /dev/null
+++ b/arch/arm/include/asm/arch-exynos/system.h
@@ -0,0 +1,53 @@
+/*
+ * (C) Copyright 2012 Samsung Electronics
+ * Donghwa Lee 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ *
+ */
+
+#ifndef __ASM_ARM_ARCH_SYSTEM_H_
+#define __ASM_ARM_ARCH_SYSTEM_H_
+
+#ifndef __ASSEMBLY__
+struct exynos4_sysreg {
+   unsigned char   res1[0x210];
+   unsigned intdisplay_ctrl;
+   unsigned intdisplay_ctrl2;
+   unsigned intcamera_control;
+   unsigned intaudio_endian;
+   unsigned intjtag_con;
+};
+
+struct exynos5_sysreg {
+   unsigned char   res1[0x214];
+   unsigned intdisp1blk_cfg;
+   unsigned int

[U-Boot] [PATCH v3 2/4] ARM: EXYNOS: add data structure for EXYNOS display driver

[Donghwa Lee]

add vidinfo data structure for EXYNOS display driver

Signed-off-by: Donghwa Lee 
Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 include/lcd.h |   63 +
 1 files changed, 63 insertions(+), 0 deletions(-)

diff --git a/include/lcd.h b/include/lcd.h
index d95feeb..651ff42 100644
--- a/include/lcd.h
+++ b/include/lcd.h
@@ -56,6 +56,11 @@ extern void lcd_initcolregs (void);
 /* gunzip_bmp used if CONFIG_VIDEO_BMP_GZIP */
 extern struct bmp_image *gunzip_bmp(unsigned long addr, unsigned long *lenp);
 
+enum {
+   FIMD_RGB_INTERFACE = 1,
+   FIMD_CPU_INTERFACE = 2,
+};
+
 #if defined CONFIG_MPC823
 /*
  * LCD controller stucture for MPC823 CPU
@@ -183,6 +188,63 @@ typedef struct vidinfo {
u_long  mmio;   /* Memory mapped registers */
 } vidinfo_t;
 
+#elif defined(CONFIG_EXYNOS_FB)
+
+typedef struct vidinfo {
+   ushort vl_col;  /* Number of columns (i.e. 640) */
+   ushort vl_row;  /* Number of rows (i.e. 480) */
+   ushort vl_width;/* Width of display area in millimeters */
+   ushort vl_height;   /* Height of display area in millimeters */
+
+   /* LCD configuration register */
+   u_char vl_freq; /* Frequency */
+   u_char vl_clkp; /* Clock polarity */
+   u_char vl_oep;  /* Output Enable polarity */
+   u_char vl_hsp;  /* Horizontal Sync polarity */
+   u_char vl_vsp;  /* Vertical Sync polarity */
+   u_char vl_dp;   /* Data polarity */
+   u_char vl_bpix; /* Bits per pixel, 0 = 1, 1 = 2, 2 = 4, 3 = 8, 
4 = 16 */
+
+   /* Horizontal control register. Timing from data sheet */
+   u_char vl_hspw; /* Horz sync pulse width */
+   u_char vl_hfpd; /* Wait before of line */
+   u_char vl_hbpd; /* Wait end of line */
+
+   /* Vertical control register. */
+   u_char  vl_vspw;/* Vertical sync pulse width */
+   u_char  vl_vfpd;/* Wait before of frame */
+   u_char  vl_vbpd;/* Wait end of frame */
+   u_char  vl_cmd_allow_len; /* Wait end of frame */
+
+   void (*cfg_gpio)(void);
+   void (*backlight_on)(unsigned int onoff);
+   void (*reset_lcd)(void);
+   void (*lcd_power_on)(void);
+   void (*cfg_ldo)(void);
+   void (*enable_ldo)(unsigned int onoff);
+   void (*mipi_power)(void);
+   void (*backlight_reset)(void);
+
+   unsigned int win_id;
+   unsigned int init_delay;
+   unsigned int power_on_delay;
+   unsigned int reset_delay;
+   unsigned int interface_mode;
+   unsigned int cs_setup;
+   unsigned int wr_setup;
+   unsigned int wr_act;
+   unsigned int wr_hold;
+
+   /* parent clock name(MPLL, EPLL or VPLL) */
+   unsigned int pclk_name;
+   /* ratio value for source clock from parent clock. */
+   unsigned int sclk_div;
+
+   unsigned int lcd_rotate;
+   unsigned int dual_lcd_enabled;
+
+} vidinfo_t;
+
 #else
 
 typedef struct vidinfo {
@@ -213,6 +275,7 @@ voidlcd_puts(const char *s);
 void   lcd_printf  (const char *fmt, ...);
 void   lcd_clear(void);
 intlcd_display_bitmap(ulong bmp_image, int x, int y);
+void   init_panel_info (vidinfo_t *vid);
 
 /* Allow boards to customize the information displayed */
 void lcd_show_board_info(void);
-- 
1.7.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v3 3/4] ARM: EXYNOS: add exynos lcd clock interface

[Donghwa Lee]

To get lcd clock in EXYNOS display driver, added get_lcd_clk() interface.

Signed-off-by: Donghwa Lee 
Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 arch/arm/cpu/armv7/exynos/clock.c  |   79 
 arch/arm/include/asm/arch-exynos/clk.h |2 +
 2 files changed, 81 insertions(+), 0 deletions(-)

diff --git a/arch/arm/cpu/armv7/exynos/clock.c 
b/arch/arm/cpu/armv7/exynos/clock.c
index 2f7048b..ecaa11e 100644
--- a/arch/arm/cpu/armv7/exynos/clock.c
+++ b/arch/arm/cpu/armv7/exynos/clock.c
@@ -414,6 +414,71 @@ static void exynos5_set_mmc_clk(int dev_index, unsigned 
int div)
writel(val, addr);
 }
 
+/* get_lcd_clk: return lcd clock frequency */
+static unsigned long exynos4_get_lcd_clk(void)
+{
+   struct exynos4_clock *clk =
+   (struct exynos4_clock *)samsung_get_base_clock();
+   unsigned long pclk, sclk;
+   unsigned int sel;
+   unsigned int ratio;
+
+   /*
+* CLK_SRC_LCD0
+* FIMD0_SEL [3:0]
+*/
+   sel = readl(&clk->src_lcd0);
+   sel = sel & 0xf;
+
+   /*
+* 0x6: SCLK_MPLL
+* 0x7: SCLK_EPLL
+* 0x8: SCLK_VPLL
+*/
+   if (sel == 0x6)
+   sclk = get_pll_clk(MPLL);
+   else if (sel == 0x7)
+   sclk = get_pll_clk(EPLL);
+   else if (sel == 0x8)
+   sclk = get_pll_clk(VPLL);
+   else
+   return 0;
+
+   /*
+* CLK_DIV_LCD0
+* FIMD0_RATIO [3:0]
+*/
+   ratio = readl(&clk->div_lcd0);
+   ratio = ratio & 0xf;
+
+   pclk = sclk / (ratio + 1);
+
+   return pclk;
+}
+
+void exynos4_set_lcd_clk(void)
+{
+   struct exynos4_clock *clk =
+   (struct exynos4_clock *)samsung_get_base_clock();
+   unsigned int cfg = 0;
+
+   /* set lcd src clock 0x6: SCLK_VPLL */
+   cfg = readl(&clk->src_lcd0);
+   cfg &= ~(0xf);
+   cfg |= 0x6;
+   writel(cfg, &clk->src_lcd0);
+
+   /* Gating all clocks for FIMD0 */
+   cfg = readl(&clk->gate_ip_lcd0);
+   cfg |= 1 << 0;
+   writel(cfg, &clk->gate_ip_lcd0);
+
+   /* set fimd ratio */
+   cfg &= ~(0xf);
+   cfg |= 0x1;
+   writel(cfg, &clk->div_lcd0);
+}
+
 unsigned long get_pll_clk(int pllreg)
 {
if (cpu_is_exynos5())
@@ -453,3 +518,17 @@ void set_mmc_clk(int dev_index, unsigned int div)
else
exynos4_set_mmc_clk(dev_index, div);
 }
+
+unsigned long get_lcd_clk(void)
+{
+   if (cpu_is_exynos4())
+   return exynos4_get_lcd_clk();
+   else
+   return 0;
+}
+
+void set_lcd_clk(void)
+{
+   if (cpu_is_exynos4())
+   exynos4_set_lcd_clk();
+}
diff --git a/arch/arm/include/asm/arch-exynos/clk.h 
b/arch/arm/include/asm/arch-exynos/clk.h
index ff0f641..cf00dea 100644
--- a/arch/arm/include/asm/arch-exynos/clk.h
+++ b/arch/arm/include/asm/arch-exynos/clk.h
@@ -33,5 +33,7 @@ unsigned long get_arm_clk(void);
 unsigned long get_pwm_clk(void);
 unsigned long get_uart_clk(int dev_index);
 void set_mmc_clk(int dev_index, unsigned int div);
+unsigned long get_lcd_clk(void);
+void set_lcd_clk(void);
 
 #endif
-- 
1.7.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v3 4/4] ARM: EXYNOS: support EXYNOS display driver

[Donghwa Lee]

This patch is for EXYNOS Display driver.

Signed-off-by: Donghwa Lee 
Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 arch/arm/include/asm/arch-exynos/fb.h |  446 +
 drivers/video/Makefile|1 +
 drivers/video/exynos_fb.c |  134 ++
 drivers/video/exynos_fb.h |   59 +
 drivers/video/exynos_fimd.c   |  354 ++
 5 files changed, 994 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/include/asm/arch-exynos/fb.h
 create mode 100644 drivers/video/exynos_fb.c
 create mode 100644 drivers/video/exynos_fb.h
 create mode 100644 drivers/video/exynos_fimd.c

diff --git a/arch/arm/include/asm/arch-exynos/fb.h 
b/arch/arm/include/asm/arch-exynos/fb.h
new file mode 100644
index 000..b10b0da
--- /dev/null
+++ b/arch/arm/include/asm/arch-exynos/fb.h
@@ -0,0 +1,446 @@
+/*
+ * (C) Copyright 2012 Samsung Electronics
+ * Donghwa Lee 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * aint with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ *
+ */
+
+#ifndef __ASM_ARM_ARCH_FB_H_
+#define __ASM_ARM_ARCH_FB_H_
+
+#ifndef __ASSEMBLY__
+struct exynos4_fb {
+   unsigned int vidcon0;
+   unsigned int vidcon1;
+   unsigned int vidcon2;
+   unsigned int vidcon3;
+   unsigned int vidtcon0;
+   unsigned int vidtcon1;
+   unsigned int vidtcon2;
+   unsigned int vidtcon3;
+   unsigned int wincon0;
+   unsigned int wincon1;
+   unsigned int wincon2;
+   unsigned int wincon3;
+   unsigned int wincon4;
+
+   unsigned int winshmap;
+   unsigned int res1;
+
+   unsigned int winchmap2;
+   unsigned int vidosd0a;
+   unsigned int vidosd0b;
+   unsigned int vidosd0c;
+   unsigned int res2;
+
+   unsigned int vidosd1a;
+   unsigned int vidosd1b;
+   unsigned int vidosd1c;
+   unsigned int vidosd1d;
+
+   unsigned int vidosd2a;
+   unsigned int vidosd2b;
+   unsigned int vidosd2c;
+   unsigned int vidosd2d;
+
+   unsigned int vidosd3a;
+   unsigned int vidosd3b;
+   unsigned int vidosd3c;
+   unsigned int res3;
+
+   unsigned int vidosd4a;
+   unsigned int vidosd4b;
+   unsigned int vidosd4c;
+   unsigned int res4[5];
+
+   unsigned int vidw00add0b0;
+   unsigned int vidw00add0b1;
+   unsigned int vidw01add0b0;
+   unsigned int vidw01add0b1;
+
+   unsigned int vidw02add0b0;
+   unsigned int vidw02add0b1;
+   unsigned int vidw03add0b0;
+   unsigned int vidw03add0b1;
+   unsigned int vidw04add0b0;
+   unsigned int vidw04add0b1;
+   unsigned int res5[2];
+
+   unsigned int vidw00add1b0;
+   unsigned int vidw00add1b1;
+   unsigned int vidw01add1b0;
+   unsigned int vidw01add1b1;
+
+   unsigned int vidw02add1b0;
+   unsigned int vidw02add1b1;
+   unsigned int vidw03add1b0;
+   unsigned int vidw03add1b1;
+
+   unsigned int vidw04add1b0;
+   unsigned int vidw04add1b1;
+   unsigned int res7[2];
+
+   unsigned int vidw00add2;
+   unsigned int vidw01add2;
+   unsigned int vidw02add2;
+   unsigned int vidw03add2;
+   unsigned int vidw04add2;
+   unsigned int res8[7];
+
+   unsigned int vidintcon0;
+   unsigned int vidintcon1;
+   unsigned int res9[1];
+
+   unsigned int w1keycon0;
+   unsigned int w1keycon1;
+   unsigned int w2keycon0;
+   unsigned int w2keycon1;
+   unsigned int w3keycon0;
+   unsigned int w3keycon1;
+   unsigned int w4keycon0;
+   unsigned int w4keycon1;
+
+   unsigned int w1keyalpha;
+   unsigned int w2keyalpha;
+   unsigned int w3keyalpha;
+   unsigned int w4keyalpha;
+
+   unsigned int dithmode;
+   unsigned int res10[2];
+
+   unsigned int win0map;
+   unsigned int win1map;
+   unsigned int win2map;
+   unsigned int win3map;
+   unsigned int win4map;
+   unsigned int res11[1];
+
+   unsigned int wpalcon_h;
+   unsigned int wpalcon_l;
+
+   unsigned int trigcon;
+   unsigned int res12[2];
+
+   unsigned int i80ifcona0;
+   unsigned int i80ifcona1;
+   unsigned int i80ifconb0;
+   unsigned int i80ifconb1;
+
+   unsigned int colorgaincon;
+   unsigned int res13[2];
+
+   unsigned int ldi_cmdcon0;
+   

Re: [U-Boot] [PATCH 00/11] MIPS: fixes and updates

[Daniel Schwierzeck]

Hi Marek,

Am 31.03.2012 22:49, schrieb Marek Vasut:

>
> My apologies for picking the rest of this series so late. Looks like the MIPS
> maintainer is n/a so I'll pull these through my staging tree once we'll fix 
> some
> issues.
>
> Best regards,
> Marek Vasut

thanks for looking into this but parts of this series are either obsolete or
already applied by Wolfgang.

I'll resend a new series with bugfixes only as soon as MAKEALL is working again.
Currently the MIPS tree is completely broken. All boards fail with:

cmd_bootm.c: In function 'do_bootm_subcommand':
cmd_bootm.c:518:23: error: 'bootm_headers_t' has no member named 'lmb'
cmd_bootm.c: In function 'do_bootm':
cmd_bootm.c:665:21: error: 'bootm_headers_t' has no member named 'lmb'


git bisect says:

44f074c771c4b70d250b0d7ed2f7513488c678bb is the first bad commit
commit 44f074c771c4b70d250b0d7ed2f7513488c678bb
Author: Marek Vasut 
Date:   Wed Mar 14 21:52:45 2012 +

BOOT: Add "bootz" command to boot Linux zImage on ARM

This command boots Linux zImage from where the zImage is loaded to. Passing
initrd and fdt is supported.

Tested on i.MX28 based DENX M28EVK
Tested on PXA270 based Voipac PXA270.

NOTE: This currently only supports ARM, but other architectures
can be easily
added by defining bootz_setup().

I'll try to find a suitable fix.

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

Re: [U-Boot] [PATCH 00/11] MIPS: fixes and updates

[Anatolij Gustschin]

Hi Daniel,

On Mon, 2 Apr 2012 13:54:18 +0200
Daniel Schwierzeck  wrote:

> Hi Marek,
> 
> Am 31.03.2012 22:49, schrieb Marek Vasut:
> 
> >
> > My apologies for picking the rest of this series so late. Looks like the 
> > MIPS
> > maintainer is n/a so I'll pull these through my staging tree once we'll fix 
> > some
> > issues.
> >
> > Best regards,
> > Marek Vasut
> 
> thanks for looking into this but parts of this series are either obsolete or
> already applied by Wolfgang.
> 
> I'll resend a new series with bugfixes only as soon as MAKEALL is working 
> again.
> Currently the MIPS tree is completely broken. All boards fail with:
> 
> cmd_bootm.c: In function 'do_bootm_subcommand':
> cmd_bootm.c:518:23: error: 'bootm_headers_t' has no member named 'lmb'
> cmd_bootm.c: In function 'do_bootm':
> cmd_bootm.c:665:21: error: 'bootm_headers_t' has no member named 'lmb'
...
> I'll try to find a suitable fix.

This is already fixed by http://patchwork.ozlabs.org/patch/149924/
I think.

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

[U-Boot] [PATCH] UBIFS: Improve error message when reading superblock failed

[Thomas Weber]

From: Bernhard Walle 

In addition to the error message also display the error code. I had the
problem that my malloc memory was not enough (ENOMEM), and if u-boot
had displayed the error code immediately that would have saved me some
debugging.

Signed-off-by: Bernhard Walle 

Use ubifs_err instead of printf.
Add "errno=%d" in output as suggested by Albert Aribaud.
Signed-off-by: Thomas Weber 
---
 fs/ubifs/super.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c
index 26b48f0..30ccd98 100644
--- a/fs/ubifs/super.c
+++ b/fs/ubifs/super.c
@@ -1191,7 +1191,7 @@ int ubifs_mount(char *vol_name)
mnt = NULL;
ret = ubifs_get_sb(&ubifs_fs_type, flags, name, data, mnt);
if (ret) {
-   printf("Error reading superblock on volume '%s'!\n", name);
+   ubifs_err("Error reading superblock on volume '%s' 
errno=%d!\n", name, ret);
return -1;
}
 
-- 
1.7.8.5

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

Re: [U-Boot] [PATCH 00/11] MIPS: fixes and updates

[Daniel Schwierzeck]

Hi Anatolij,

On Mon, Apr 2, 2012 at 2:01 PM, Anatolij Gustschin  wrote:
> Hi Daniel,
>
> On Mon, 2 Apr 2012 13:54:18 +0200
> Daniel Schwierzeck  wrote:
>
...
>> I'll resend a new series with bugfixes only as soon as MAKEALL is working 
>> again.
>> Currently the MIPS tree is completely broken. All boards fail with:
>>
>> cmd_bootm.c: In function 'do_bootm_subcommand':
>> cmd_bootm.c:518:23: error: 'bootm_headers_t' has no member named 'lmb'
>> cmd_bootm.c: In function 'do_bootm':
>> cmd_bootm.c:665:21: error: 'bootm_headers_t' has no member named 'lmb'
> ...
>> I'll try to find a suitable fix.
>
> This is already fixed by http://patchwork.ozlabs.org/patch/149924/
> I think.
>

yes this patch works

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

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

[Thomas Chou]

Dear Wolfgang,

On 04/02/2012 10:50 AM, Thomas Chou wrote:

I hit more build error after rc1. I will send new pull request after I
fix them.


The problem was solved with Marek's recent patch as Mike Frysinger said.
http://patchwork.ozlabs.org/patch/149924/

So please pull the u-boot-nios/master.

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

[U-Boot] [PATCH] cm-t35: add I2C multi-bus support

[Igor Grinberg]

From: Nikita Kiryanov 

Enable I2C multi-bus support and config I2C muxes for I2C2 and I2C3.

Signed-off-by: Nikita Kiryanov 
Signed-off-by: Igor Grinberg 
---
 board/cm_t35/cm_t35.c|6 ++
 include/configs/cm_t35.h |1 +
 2 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/board/cm_t35/cm_t35.c b/board/cm_t35/cm_t35.c
index 0a04994..bc991c4 100644
--- a/board/cm_t35/cm_t35.c
+++ b/board/cm_t35/cm_t35.c
@@ -241,6 +241,12 @@ static void cm_t3x_set_common_muxconf(void)
/* I2C1 */
MUX_VAL(CP(I2C1_SCL),   (IEN  | PTU | EN  | M0)); /*I2C1_SCL*/
MUX_VAL(CP(I2C1_SDA),   (IEN  | PTU | EN  | M0)); /*I2C1_SDA*/
+   /* I2C2 */
+   MUX_VAL(CP(I2C2_SCL),   (IEN  | PTU | EN  | M0)); /*I2C2_SCL*/
+   MUX_VAL(CP(I2C2_SDA),   (IEN  | PTU | EN  | M0)); /*I2C2_SDA*/
+   /* I2C3 */
+   MUX_VAL(CP(I2C3_SCL),   (IEN  | PTU | EN  | M0)); /*I2C3_SCL*/
+   MUX_VAL(CP(I2C3_SDA),   (IEN  | PTU | EN  | M0)); /*I2C3_SDA*/
 
/* control and debug */
MUX_VAL(CP(SYS_32K),(IEN  | PTD | DIS | M0)); /*SYS_32K*/
diff --git a/include/configs/cm_t35.h b/include/configs/cm_t35.h
index fe91c10..b28bd8e 100644
--- a/include/configs/cm_t35.h
+++ b/include/configs/cm_t35.h
@@ -156,6 +156,7 @@
 #define CONFIG_DRIVER_OMAP34XX_I2C
 #define CONFIG_SYS_I2C_EEPROM_ADDR 0x50
 #define CONFIG_SYS_I2C_EEPROM_ADDR_LEN 1
+#define CONFIG_I2C_MULTI_BUS
 
 /*
  * TWL4030
-- 
1.7.3.4

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

Re: [U-Boot] [PATCH v2] mvgbe: remove warning for unused methods

[Prafulla Wadaskar]

 

> -Original Message-
> From: Prafulla Wadaskar 
> Sent: 26 March 2012 15:54
> To: 'Valentin Longchamp'; u-boot@lists.denx.de
> Cc: Stefan Bigler; Gerlando Falauto; Holger Brunck
> Subject: RE: [PATCH v2] mvgbe: remove warning for unused methods
> 
> 
> 
> > -Original Message-
> > From: Valentin Longchamp [mailto:valentin.longch...@keymile.com]
> > Sent: 26 March 2012 15:32
> > To: u-boot@lists.denx.de
> > Cc: Stefan Bigler; Valentin Longchamp; Gerlando Falauto; Prafulla 
> > Wadaskar; Holger Brunck
> > Subject: [PATCH v2] mvgbe: remove warning for unused methods
> > 
> > From: Stefan Bigler 
> > 
> > Some baords may use the GBE interface but they have no phy 
> connected 
> > to the interface and a direct MAC/MAC interface.
> > For them we need to get rid of compiler warnings.
> > 
> > Signed-off-by: Stefan Bigler 
> > Signed-off-by: Valentin Longchamp 
> > cc: Gerlando Falauto 
> > cc: Prafulla Wadaskar 
> > cc: Holger Brunck 
> > ---
> >  drivers/net/mvgbe.c |2 ++
> >  1 files changed, 2 insertions(+), 0 deletions(-)
> > 
> > diff --git a/drivers/net/mvgbe.c b/drivers/net/mvgbe.c index 
> > 1dcb700..df258b9 100644
> > --- a/drivers/net/mvgbe.c
> > +++ b/drivers/net/mvgbe.c
> > @@ -52,6 +52,7 @@ DECLARE_GLOBAL_DATA_PTR;  #define 
> MV_PHY_ADR_REQUEST 
> > 0xee  #define MVGBE_SMI_REG (((struct mvgbe_registers 
> > *)MVGBE0_BASE)->smi)
> > 
> > +#if defined(CONFIG_MII) || defined(CONFIG_CMD_MII)
> >  /*
> >   * smi_reg_read - miiphy_read callback function.
> >   *
> > @@ -181,6 +182,7 @@ static int smi_reg_write(const char 
> *devname, u8 
> > phy_adr, u8 reg_ofs, u16 data)
> > 
> > return 0;
> >  }
> > +#endif
> > 
> >  /* Stop and checks all queues */
> >  static void stop_queue(u32 * qreg)
> > --
> > 1.7.1
> 
> Acked-by: Prafulla Wadaskar 

Hi Joe

May you please pull this patch in u-boot-net.git?

This does not have any further dependency, whereas it is a dependency for some 
other patchset

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

[U-Boot] [PATCH 0/3] MIPS: fixes for 2012.04-rc1

[Daniel Schwierzeck]

Hi Marek,

this series collects the bugfix patches from the open patches at patchwork
delegated to you. Only these patches should be merged for the release.
The other patches are superseeded for now.

The series is rebased against v2012.04-rc1 and needs your patch
http://patchwork.ozlabs.org/patch/149924/ to run MAKEALL -a mips.

Daniel Schwierzeck (3):
  MIPS: board.c: fix init of flash data in bd_info
  MIPS: fix inconsistency in config option for cache operation mode
  MIPS: fix endianess handling

 README |6 ++
 arch/mips/cpu/mips32/cache.S   |6 +-
 arch/mips/cpu/mips32/config.mk |   21 +++--
 arch/mips/lib/board.c  |8 ++--
 boards.cfg |2 +-
 include/configs/pb1x00.h   |2 ++
 6 files changed, 35 insertions(+), 10 deletions(-)

--
1.7.9.4

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

[U-Boot] [PATCH 1/3] MIPS: board.c: fix init of flash data in bd_info

[Daniel Schwierzeck]

Boards with CONFIG_SYS_NO_FLASH should not forced to define
CONFIG_SYS_FLASH_BASE. In this case the flash data in bd_info
should be initialized with 0 like the other archs do.

Signed-off-by: Daniel Schwierzeck 
---
 arch/mips/lib/board.c |8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/mips/lib/board.c b/arch/mips/lib/board.c
index d998f0e..38e6e77 100644
--- a/arch/mips/lib/board.c
+++ b/arch/mips/lib/board.c
@@ -294,15 +294,19 @@ void board_init_r(gd_t *id, ulong dest_addr)
/* configure available FLASH banks */
size = flash_init();
display_flash_config(size);
+   bd->bi_flashstart = CONFIG_SYS_FLASH_BASE;
bd->bi_flashsize = size;
-#endif
 
-   bd->bi_flashstart = CONFIG_SYS_FLASH_BASE;
 #if CONFIG_SYS_MONITOR_BASE == CONFIG_SYS_FLASH_BASE
bd->bi_flashoffset = monitor_flash_len; /* reserved area for U-Boot */
 #else
bd->bi_flashoffset = 0;
 #endif
+#else
+   bd->bi_flashstart = 0;
+   bd->bi_flashsize = 0;
+   bd->bi_flashoffset = 0;
+#endif
 
 #ifdef CONFIG_CMD_NAND
puts("NAND:  ");
-- 
1.7.9.4

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

[U-Boot] [PATCH 3/3] MIPS: fix endianess handling

[Daniel Schwierzeck]

Make endianess of target CPU configurable. Use the new config
option for dbau1550_el and pb1000 boards.

Adapt linking of standalone applications to pass through
endianess options to LD.

Build tested with:
 - ELDK 4 mips_4KC- and mips4KCle
 - Sourcery CodeBench Lite 2011.03-93

With this patch all 26 MIPS boards can be compiled now in one step by
running "MAKEALL -a mips".

Signed-off-by: Daniel Schwierzeck 
---
 README |6 ++
 arch/mips/cpu/mips32/config.mk |   21 +++--
 boards.cfg |2 +-
 include/configs/pb1x00.h   |2 ++
 4 files changed, 24 insertions(+), 7 deletions(-)

diff --git a/README b/README
index c98afa7..9702067 100644
--- a/README
+++ b/README
@@ -374,6 +374,12 @@ The following options need to be configured:
Defines the string to utilize when trying to match PCIe device
tree nodes for the given platform.
 
+- Generic CPU options:
+   CONFIG_SYS_BIG_ENDIAN, CONFIG_SYS_LITTLE_ENDIAN
+
+   Defines the endianess of the CPU. Implementation of those
+   values is arch specific.
+
 - Intel Monahans options:
CONFIG_SYS_MONAHANS_RUN_MODE_OSC_RATIO
 
diff --git a/arch/mips/cpu/mips32/config.mk b/arch/mips/cpu/mips32/config.mk
index 4d1b273..a1cd590 100644
--- a/arch/mips/cpu/mips32/config.mk
+++ b/arch/mips/cpu/mips32/config.mk
@@ -27,14 +27,23 @@
 # Note: Toolchains with binutils prior to v2.16
 # are no longer supported by U-Boot MIPS tree!
 #
-MIPSFLAGS = -march=mips32r2
+MIPSFLAGS := -march=mips32r2
 
+# Handle special prefix in ELDK 4.0 toolchain
 ifneq (,$(findstring 4KCle,$(CROSS_COMPILE)))
-ENDIANNESS = -EL
-else
-ENDIANNESS = -EB
+ENDIANNESS := -EL
 endif
 
-MIPSFLAGS += $(ENDIANNESS)
+ifdef CONFIG_SYS_LITTLE_ENDIAN
+ENDIANNESS := -EL
+endif
+
+ifdef CONFIG_SYS_BIG_ENDIAN
+ENDIANNESS := -EB
+endif
+
+# Default to EB if no endianess is configured
+ENDIANNESS ?= -EB
 
-PLATFORM_CPPFLAGS += $(MIPSFLAGS)
+PLATFORM_CPPFLAGS += $(MIPSFLAGS) $(ENDIANNESS)
+PLATFORM_LDFLAGS += $(ENDIANNESS)
diff --git a/boards.cfg b/boards.cfg
index c6090ba..3cf75c3 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -360,7 +360,7 @@ dbau1000 mipsmips32  
dbau1x00-
 dbau1100 mipsmips32  dbau1x00- 
 au1x00  dbau1x00:DBAU1100
 dbau1500 mipsmips32  dbau1x00- 
 au1x00  dbau1x00:DBAU1500
 dbau1550 mipsmips32  dbau1x00- 
 au1x00  dbau1x00:DBAU1550
-dbau1550_el  mipsmips32  dbau1x00- 
 au1x00  dbau1x00:DBAU1550
+dbau1550_el  mipsmips32  dbau1x00- 
 au1x00  dbau1x00:DBAU1550,SYS_LITTLE_ENDIAN
 gth2 mipsmips32  -   - 
 au1x00
 pb1000   mipsmips32  pb1x00  - 
 au1x00  pb1x00:PB1000
 incaip   mipsmips32  incaip  - 
 incaip
diff --git a/include/configs/pb1x00.h b/include/configs/pb1x00.h
index eea8ed3..d056884 100644
--- a/include/configs/pb1x00.h
+++ b/include/configs/pb1x00.h
@@ -46,6 +46,8 @@
 #endif
 #endif
 
+#define CONFIG_SYS_LITTLE_ENDIAN
+
 #define CONFIG_ETHADDR DE:AD:BE:EF:01:01/* Ethernet address */
 
 #define CONFIG_BOOTDELAY   2   /* autoboot after 2 seconds */
-- 
1.7.9.4

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

[U-Boot] [PATCH 2/3] MIPS: fix inconsistency in config option for cache operation mode

[Daniel Schwierzeck]

Commit ab2a98b11716364bc5a8c43cdfa7fee176cda1d8 missed to
use the new config option in dcache_enable().

Fix this to avoid inconsistencies if someone wants to disable
and enable D-caches.

Signed-off-by: Daniel Schwierzeck 
---
 arch/mips/cpu/mips32/cache.S |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/mips/cpu/mips32/cache.S b/arch/mips/cpu/mips32/cache.S
index 5ce0ec4..e683e8b 100644
--- a/arch/mips/cpu/mips32/cache.S
+++ b/arch/mips/cpu/mips32/cache.S
@@ -30,6 +30,10 @@
 #include 
 #include 
 
+#ifndef CONFIG_SYS_MIPS_CACHE_MODE
+#define CONFIG_SYS_MIPS_CACHE_MODE CONF_CM_CACHABLE_NONCOHERENT
+#endif
+
 #define RA t8
 
 /*
@@ -224,7 +228,7 @@ LEAF(dcache_enable)
mfc0t0, CP0_CONFIG
ori t0, CONF_CM_CMASK
xorit0, CONF_CM_CMASK
-   ori t0, CONF_CM_CACHABLE_NONCOHERENT
+   ori t0, CONFIG_SYS_MIPS_CACHE_MODE
mtc0t0, CP0_CONFIG
jr  ra
END(dcache_enable)
-- 
1.7.9.4

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

Re: [U-Boot] [PATCH 00/11] MIPS: fixes and updates

[Marek Vasut]

Dear Daniel Schwierzeck,

> Hi Marek,
> 
> Am 31.03.2012 22:49, schrieb Marek Vasut:
> 
> 
> > My apologies for picking the rest of this series so late. Looks like the
> > MIPS maintainer is n/a so I'll pull these through my staging tree once
> > we'll fix some issues.
> > 
> > Best regards,
> > Marek Vasut
> 
> thanks for looking into this but parts of this series are either obsolete
> or already applied by Wolfgang.
> 
> I'll resend a new series with bugfixes only as soon as MAKEALL is working
> again. Currently the MIPS tree is completely broken. All boards fail with:
> 
> cmd_bootm.c: In function 'do_bootm_subcommand':
> cmd_bootm.c:518:23: error: 'bootm_headers_t' has no member named 'lmb'
> cmd_bootm.c: In function 'do_bootm':
> cmd_bootm.c:665:21: error: 'bootm_headers_t' has no member named 'lmb'
> 
> 
> git bisect says:

Git bisect says I screwed up, sorry. Fix is already in the ML.

> 44f074c771c4b70d250b0d7ed2f7513488c678bb is the first bad commit
> commit 44f074c771c4b70d250b0d7ed2f7513488c678bb
> Author: Marek Vasut 
> Date:   Wed Mar 14 21:52:45 2012 +
> 
> BOOT: Add "bootz" command to boot Linux zImage on ARM
> 
> This command boots Linux zImage from where the zImage is loaded to.
> Passing initrd and fdt is supported.
> 
> Tested on i.MX28 based DENX M28EVK
> Tested on PXA270 based Voipac PXA270.
> 
> NOTE: This currently only supports ARM, but other architectures
> can be easily
> added by defining bootz_setup().
> 
> I'll try to find a suitable fix.

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] spi/kirkwood: add weak functions board_spi_bus_claim/release

[Valentin Longchamp]

Dear Prafulla,

On 03/30/2012 02:58 PM, Prafulla Wadaskar wrote:
>> -Original Message-
>> From: Valentin Longchamp [mailto:valentin.longch...@keymile.com]
>> Sent: 30 March 2012 17:45
>> To: Prafulla Wadaskar
>> Cc: u-boot@lists.denx.de; Gerlando Falauto; Holger Brunck
>> Subject: Re: [PATCH v2] spi/kirkwood: add weak functions
>> board_spi_bus_claim/release
>>
>> Hi Prafulla,
>>
>> For the simplicity of the discussion, I have removed everything in the
>> discussion that is not relevant for the current open point.
>>
>> On 03/30/2012 01:34 PM, Prafulla Wadaskar wrote:
>>> In Kirkwood specific claim_bus API, you will backup default
>> configuration (which is NF in your case) for these particular pins
>> (SPI_SI, SPI_SCK, SPI_CSn, MOSI, MISO).
>>
>> But which MPP are these particular pins ?
>>
>> Let's have a look at a single signal, SPI_SCK for instance. From the
>> 88F6281
>> Hardware Spec [1], page 53, SPI_SCK can be MPP[2], MPP[10]. How can
>> the generic
>> driver know which one actually is wired to the SPI device SCK pin on
>> the
>> currently running hardware (when none is configured as then, since by
>> default
>> for us MPP[2] is NF_IO[4] and MPP[10] is UA0_TXD ) ? This is a board
>> specific !
>>
>> If you tell me how I easily can find this out in the kirkwood driver,
> 
> Dear Valentin
> 
> Please make a use of CONFIG_SF_DEFAULT_CS for this.

Is this really the correct #define to use ? From the documentation, this is
supposed to set the Serial Flash CS. OK our SPI controller is used for serial
flash access, but this may be used for something else.

So I would not use this #define, nor any that is related to Serial Flash 
support.

> By default this is defined to 0, lets map it to our default use case i.e. 
> using MPP0-3 for default SPI signals
> 
> One may pre-define this in his board config as per specific need, and we can 
> use this effectively in Kirkwood_spi driver.
> i.e.
>  bit0 to be used to configure SPI_CSn
>  bit1 to be used to configure SPI_MOSI... and so on
> 
> so if my needs are to use
> 1. MPP7 as SPI_CSn I will define CONFIG_SF_DEFAULT_CS to 0x01
> 2. MPP6 as SPI_MOSI I will define CONFIG_SF_DEFAULT_CS to 0x02
> 2. MPP6 as SPI_MOSI and MPP7 as SPI_CSn, I will define CONFIG_SF_DEFAULT_CS 
> to 0x03
> .. and so on.
> 

Yeah I see what you mean and that's what I had figured out. But I don't think
this is a simple solution:

1) We would have to add another CONFIG_SYS_XY for this purpose (as explained 
above)

2) The two spi_claim_bus and spi_release_bus functions should implement some bit
masking on the new CONFIG_SYS_XY to determine 4 pins that have to be configured.
The number of code lines would not be huge, but that would still be a lot more
than the 10 lines that my board specific functions would require. 10 sequencial
c line codes/board are from my point of view acceptable (and it would be only
for our board, since I see no other board using this).

OK genericity is nice, but I guess we would be the only ones using this code,
and it would not be worth it in this case. Additionnaly, I like the fact that
anything that has to do with the mpp configurations stays in one single board
specific .c file.

Regards

-- 
Valentin Longchamp
Embedded Software Engineer
Hardware and Chip Integration
__
KEYMILE AG
Schwarzenburgstr. 73
CH-3097 Liebefeld
Phone +41 31 377 1318
Fax   +41 31 377 1212
valentin.longch...@keymile.com
www.keymile.com
__
KEYMILE: A Specialist as a Partner
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Correct corrupted NAND Flash access on KARO TX25 modules

[Marek Vasut]

Dear Gachet Daniel,

> Hi Marek,
> 
> Thanks for your answer. Have I to do more?

Did you submit the new patch into the ML? If so, did you CC sba...@denx.de? If 
so, the patch will be picked by him and applied :)

Thanks for your patch!

> 
> Have a good day.
> 
> Cordially,
> 
> Daniel
> 
> -Original Message-
> From: Marek Vasut [mailto:ma...@denx.de]
> Sent: dimanche 1 avril 2012 23:02
> To: u-boot@lists.denx.de
> Cc: Gachet Daniel
> Subject: Re: [U-Boot] [PATCH] Correct corrupted NAND Flash access on KARO
> TX25 modules
> 
> Dear Gachet Daniel,
> 
> > Hi Stefano and Marek,
> > 
> > -Original Message-
> > From: stefano babic [mailto:sba...@denx.de]
> > Sent: dimanche 1 avril 2012 12:33
> > To: Gachet Daniel
> > Cc: u-boot@lists.denx.de
> > Subject: Re: [U-Boot] [PATCH] Correct corrupted NAND Flash access on
> > KARO
> > TX25 modules
> > 
> > >Am 31/03/2012 09:31, schrieb Gachet Daniel:
> > >> This short patch correct corrupted data while reading NAND flash
> > >> modules on the KARO TX25 module.
> > >> 
> > >> The current version of the mxc_nand driver uses the symmetric mode
> > >> to access the NAND flash, but the devices
> > >>
> > >>populated on the KARO TX25 only support an asymmetric mode (i.MX25:
> > >>bit 8  within NAND_FLASH_CONFIG1 register cleared).
> > >>
> > >> Signed-off-by: Daniel Gachet 
> > >> Cc: Wolfgang Denk 
> > >> 
> > >> diff -upr drivers/mtd/nand/mxc_nand.c drivers/mtd/nand/mxc_nand.c
> > >> --- drivers/mtd/nand/mxc_nand.c  2011-12-23 20:25:35.0 +0100
> > >> +++ drivers/mtd/nand/mxc_nand.c  2012-03-30 08:10:13.0 +0200
> > >> @@ -1290,7 +1290,9 @@ static void mxc_setup_config1(void)
> > >> 
> > >>  uint16_t tmp;
> > >>  
> > >>  tmp = readw(&host->regs->nfc_config1);
> > >> 
> > >> +#ifndef MACH_TYPE_TX25
> > >> 
> > >>  tmp |= NFC_ONE_CYCLE;
> > >> 
> > >> +#endif
> > >
> > >NAK. We cleaned up all u-boot occurrencies of machine id, except the
> > >machid passed to the kernel. And when the device tree will be
> > >effective, also the machid will be obsolete.
> > >
> > >This change seems not strictly related to the Karo's SOM, but it it a
> > >configuration of the mxc_nand driver, such as CONFIG_NAND_MXC_V1_1.
> > >You can add a CONFIG_NAND_MXC_* value (please add documentation, too)
> > >and use it in the driver code.
> > >
> > >Can I also ask you if the same setup is used in the Linux driver
> > >(this SOM is not mainlined, I suppose you have a porting from the
> > >manufacturer) ? As far as I can see, this setup is not used for the
> > >Freescale's mx25pdk (the only MX25 board in mainline kernel).
> > >
> > >Best regards,
> > >Stefano Babic
> > >
> > >--
> > >=
> > >DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> > >HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> > >Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: off...@denx.de
> > >=
> > 
> > I found the proposition of Stefano very interesting. My proposition
> > will be to define a specific value for that bit, for instance
> > CONFIG_NAND_MXC_V1_1_NFC_ONE_CYCLE. If this value is defined, the
> > NFC_ONE_CYCLE bit will be set, otherwise not. This value could be
> > defined in the specific board configuration file (./include/configs/...).
> > 
> > The patch will be the following:
> > diff -upr drivers/mtd/nand/mxc_nand.c drivers/mtd/nand/mxc_nand.c
> > --- drivers/mtd/nand/mxc_nand.c 2011-12-23 20:25:35.0 +0100
> > +++ drivers/mtd/nand/mxc_nand.c 2012-04-01 21:07:13.0 +0200
> > @@ -1290,7 +1290,9 @@ static void mxc_setup_config1(void)
> > 
> > uint16_t tmp;
> > 
> > tmp = readw(&host->regs->nfc_config1);
> > 
> > +#ifdef CONFIG_NAND_MXC_V1_1_NFC_ONE_CYCLE
> > 
> > tmp |= NFC_ONE_CYCLE;
> > 
> > +#endif
> > 
> > tmp |= NFC_4_8N_ECC;
> > writew(tmp, &host->regs->nfc_config1);
> > if (host->pagesize_2k)
> > 
> > Is that a valuable solution for you?
> 
> Ain't that basically what I said? Though, I might have not been clear
> enough ;-) Yes, that's it. Thanks!
> 
> > Cordially,
> > 
> > Daniel

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 0/3] MIPS: fixes for 2012.04-rc1

[Marek Vasut]

Dear Daniel Schwierzeck,

> Hi Marek,
> 
> this series collects the bugfix patches from the open patches at patchwork
> delegated to you. Only these patches should be merged for the release.
> The other patches are superseeded for now.
> 
> The series is rebased against v2012.04-rc1 and needs your patch
> http://patchwork.ozlabs.org/patch/149924/ to run MAKEALL -a mips.

Shinya-san, you ok with these patches hitting .04?

I'll roll then through my -staging if it's fine.

> Daniel Schwierzeck (3):
>   MIPS: board.c: fix init of flash data in bd_info
>   MIPS: fix inconsistency in config option for cache operation mode
>   MIPS: fix endianess handling
> 
>  README |6 ++
>  arch/mips/cpu/mips32/cache.S   |6 +-
>  arch/mips/cpu/mips32/config.mk |   21 +++--
>  arch/mips/lib/board.c  |8 ++--
>  boards.cfg |2 +-
>  include/configs/pb1x00.h   |2 ++
>  6 files changed, 35 insertions(+), 10 deletions(-)
> 
> --
> 1.7.9.4
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

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][resubmit] eb_cpux9k2: add USB host support to board

[Marek Vasut]

Dear e...@bus-elektronik.de,

> Am 2012-04-01 18:14, schrieb Marek Vasut:
> > Dear Jens Scharsig,
> > 
> >> * add USB host support to eb_cpux9k2 board
> > 
> > Did you test this too?
> 
> Of course, I've test this with/against current RC1.

Ok, I can pick this up and push through my staging ... or does Albert want to 
pick it directly via -arm (which would be better)?

> > CCing Albert, Albert do you want me to push this through staging or
> > you'll pick this?
> > 
> >> Signed-off-by: Jens Scharsig 
> >> ---
> >> 
> >>  include/configs/eb_cpux9k2.h |   14 ++
> >>  1 files changed, 14 insertions(+), 0 deletions(-)
> >> 
> >> diff --git a/include/configs/eb_cpux9k2.h b/include/configs/eb_cpux9k2.h
> >> index 9046cf0..eb05e2a 100644
> >> --- a/include/configs/eb_cpux9k2.h
> >> +++ b/include/configs/eb_cpux9k2.h
> >> @@ -139,6 +139,8 @@
> >> 
> >>  #define CONFIG_CMD_PING
> >>  #define CONFIG_I2C_CMD_NO_FLAT
> >>  #define CONFIG_I2C_CMD_TREE
> >> 
> >> +#define CONFIG_CMD_USB
> >> +#define CONFIG_CMD_FAT
> >> 
> >>  #define CONFIG_SYS_LONGHELP
> >> 
> >> @@ -169,6 +171,18 @@
> >> 
> >>  /*
> >>  
> >>   * Hardware drivers
> >>   */
> >> 
> >> +#define CONFIG_USB_ATMEL
> >> +#define CONFIG_USB_OHCI_NEW
> >> +#define CONFIG_AT91C_PQFP_UHPBUG
> >> +#define CONFIG_USB_STORAGE
> >> +#define CONFIG_DOS_PARTITION
> >> +#define CONFIG_ISO_PARTITION
> >> +#define CONFIG_EFI_PARTITION
> >> +
> >> +#define CONFIG_SYS_USB_OHCI_MAX_ROOT_PORTS1
> >> +#define CONFIG_SYS_USB_OHCI_CPU_INIT
> >> +#define CONFIG_SYS_USB_OHCI_REGS_BASE 0x0030
> >> +#define CONFIG_SYS_USB_OHCI_SLOT_NAME "at91rm9200"
> >> 
> >>  /*
> >>  
> >>   * UART/CONSOLE
> > 
> > Best regards,
> > Marek Vasut
> 
> Tested-by: Jens Scharsig 
> 
> 
> Best regards
> 
> Jens Scharsig
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

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

[U-Boot] MMC0: DMA transfer failed

[Fabio Estevam]

Hi,

On a mx28evk board I am getting the following using top of tree U-boot:

U-Boot 2012.04-rc1-1-g037cbfd (Apr 02 2012 - 10:57:48)

Freescale i.MX28 family at 454 MHz
DRAM:  128 MiB
MMC:   MXS MMC: 0
MMC0: DMA transfer failed
MMC0: DMA transfer failed
MMC0: DMA transfer failed
MMC0: DMA transfer failed
MMC init failed
Using default environment

Is there any patch I am missing?

Thanks,

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

Re: [U-Boot] [PATCH 2/4] net: round up before calling flush_cache

[Marek Vasut]

Dear Stefano Babic,

> On 01/04/2012 21:23, Mike Frysinger wrote:
> > On Sunday 01 April 2012 09:22:59 Stefano Babic wrote:
> >> If the range passed to flush_cache is not multiple of
> >> ARCH_DMA_MINALIGN, a warning due to mislaignment is printed.
> >> Detected with fec_mxc, mx35 boards:
> >> 
> >> CACHE: Misaligned operation at range [8080, 8083c310]
> > 
> > warning on flushing is broken.  the arch/arm/cpu/arm926ejs/cache.c
> > code should probably be fixed instead.
> 
> mmhhh...I agree with you. Marek, really I am expecting that the same
> message appears on MX28, not only on arm1136. Only if the size of the
> downloaded file is a multiple of 32, the warning will not appear.
> 
> Anyway, the message is misleading. Do we need such kind of warning or
> can we simply silently ignore it ?

Well, it was there to catch bugs in drivers. We can probably turn it into 
debug() now ?

> Stefano

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] Prevent malloc with size 0

[Marek Vasut]

Dear Joakim Tjernlund,

> Hi Grame
> 
> Graeme Russ  wrote on 2012/04/02 09:17:44:
> > Hi Joakim,
> > 
> > On Apr 2, 2012 4:55 PM, "Joakim Tjernlund"  
wrote:
> > > > Hi Marek,
> > > > 
> > > > On Mon, Apr 2, 2012 at 1:36 PM, Marek Vasut  
wrote:
> > > > > Dear Mike Frysinger,
> > > > > 
> > > > >> On Sunday 01 April 2012 20:25:44 Graeme Russ wrote:
> > > > >> > b) The code calling malloc(0) is making a perfectly legitimate
> > > > >> > assumption
> > > > >> > 
> > > > >> >based on how glibc handles malloc(0)
> > > > >> 
> > > > >> not really.  POSIX says malloc(0) is implementation defined (so it
> > > > >> may return a unique address, or it may return NULL).  no
> > > > >> userspace code assuming malloc(0) will return non-NULL is
> > > > >> correct.
> > > > > 
> > > > > Which is your implementation-defined ;-) But I have to agree with
> > > > > this one. So my vote is for returning NULL.
> > > > 
> > > > Also, no userspace code assuming malloc(0) will return NULL is
> > > > correct
> > > > 
> > > > Point being, no matter which implementation is chosen, it is up to
> > > > the caller to not assume that the choice that was made was, in fact,
> > > > the choice that was made.
> > > > 
> > > > I.e. the behaviour of malloc(0) should be able to be changed on a
> > > > whim with no side-effects
> > > > 
> > > > So I think I should change my vote to returning NULL for one reason
> > > > and one reason only - It is faster during run-time
> > > 
> > > Then u-boot will be incompatible with both glibc and the linux kernel,
> > > it seems
> > 
> > Forget aboug other implementations...
> > What matters is that the fact that the behaviour is undefined and it is
> > up to the caller to take that into account
> 
> Well, u-boot borrows code from both kernel and user space so it would make
> sense if malloc(0) behaved the same. Especially for kernel code which tend
> to depend on the kernels impl.(just look at Scotts example)
> 
> > > to me that any modern impl. of malloc(0) will return a non NULL ptr.
> > > 
> > > It does need to be slower, just return ~0 instead, the kernel does
> > > something similar: if (!size)
> > > return ZERO_SIZE_PTR;
> > 
> > That could work, but technically I don't think it complies as it is not a
> > pointer to allocated memory...
> 
> It doesn't not have to be allocated memory, just a ptr != NULL which you
> can do free() on.

But kernel has something mapped there to trap these pointers I believe.

> 
>  Jocke

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] i.MX28: Fix initial stack pointer position

[Fabio Estevam]

On Mon, Apr 2, 2012 at 1:21 AM, Marek Vasut  wrote:
> The patch:
>
>  m28evk: Use GENERATED_GBL_DATA_SIZE
>  commit 1084606c972ea5f1d89f69bdbd978b867d0ee521
>
> introduced usage of GENERATED_GBL_DATA_SIZE and calculation of initial stack
> pointer position defived from that. Due to a small typo, the SP position moved
> to 0x21f80, which is past the SRAM area. This didn't manifest on the real
> hardware as the SRAM repeats there (address bits in the CPU being ignored).
>
> Though this was caught in QEMU, where it crashed the emulator.
>
> Signed-off-by: Marek Vasut 
> Cc: Stefano Babic 
> Cc: Fabio Estevam 

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

Re: [U-Boot] [PATCH V2 12/24] SPEAr: Enable usb device high speed support

[Tom Rini]

On 04/01/2012 11:50 PM, Amit Virdi wrote:

Dear Marek,

On 3/31/2012 11:58 PM, Marek Vasut wrote:

Dear Amit Virdi,


From: Vipin KUMAR


Cc me with usb related stuff please.



Ok, I'll take care in future.


Does USBTTY work for you? Tom complained about it.



Yes it works and we haven't found any issue till date. Infact, Vipin has
developed a tool for flashing using usbtty and we have been using it for
quite long.

What kind of problems did Tom faced?


On a beagleboard it's acting like the buffer isn't being flushed at 
first.  If I type 'help' after switching from UART I have to hit space a 
few times to see all the output.


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

Re: [U-Boot] [PATCH 0/6] add zip command support for uboot

[Lei Wen]

Dear Wolfgang,

On Wed, Mar 28, 2012 at 10:23 AM, Lei Wen  wrote:
> Hi Tom,
>
> On Wed, Mar 28, 2012 at 2:12 AM, Tom Rini  wrote:
>> On Tue, Mar 27, 2012 at 04:04:29PM +0800, Lei Wen wrote:
>>> Hi,
>>>
>>> On Sun, Mar 25, 2012 at 11:53 PM,   wrote:
>>> > From: Lei Wen 
>>> >
>>> > This patch set add zip command support for uboot.
>>> > The first two patches import deflate and trees functions from zlib 1.2.5
>>> > without any change. While the third patch did the necessary change to
>>> > make the import file could be built passed in uboot environment.
>>> >
>>> > The fourth patch make us could zip the memory from 0 in the address space.
>>> >
>>> > The latter fifth and sixth patch does the adding gzip lib function 
>>> > exporting
>>> > and zip command support.
>>> >
>>> > Patch set test with zip&unzip and compared with original memory content.
>>> >
>>> >
>>> > Lei Wen (6):
>>> > ?lib: zlib: import deflate source file from 1.2.5
>>> > ?lib: zlib: import trees file from 1.2.5
>>> > ?lib: zlib: include deflate into zlib build
>>> > ?lib: zlib: remove the limitation for cannot using 0 as start
>>> > ?lib: add gzip lib function callback
>>> > ?common: add zip command support
>>> >
>>> > ?common/Makefile ? ? ? | ? ?1 +
>>> > ?common/cmd_zip.c ? ? ?| ? 60 ++
>>> > ?include/common.h ? ? ?| ? ?7 +
>>> > ?include/u-boot/zlib.h | ? 40 +-
>>> > ?lib/Makefile ? ? ? ? ?| ? ?1 +
>>> > ?lib/gzip.c ? ? ? ? ? ?| ?143 
>>> > ?lib/zlib/deflate.c ? ?| 1831 
>>> > +
>>> > ?lib/zlib/deflate.h ? ?| ?342 +
>>> > ?lib/zlib/trees.c ? ? ?| 1244 +
>>> > ?lib/zlib/trees.h ? ? ?| ?128 
>>> > ?lib/zlib/zlib.c ? ? ? | ? ?8 +
>>> > ?lib/zlib/zutil.h ? ? ?| ? ?4 +
>>> > ?12 files changed, 3804 insertions(+), 5 deletions(-)
>>> > ?create mode 100644 common/cmd_zip.c
>>> > ?create mode 100644 lib/gzip.c
>>> > ?create mode 100644 lib/zlib/deflate.c
>>> > ?create mode 100644 lib/zlib/deflate.h
>>> > ?create mode 100644 lib/zlib/trees.c
>>> > ?create mode 100644 lib/zlib/trees.h
>>>
>>> Any comments to this series?
>>
>> What's the usecase for this code?  Did the U-Boot change in size for
>> targets that didn't opt for the new command?
>
> There is one usecase in our usage, that is compressing and upload the
> memory content
> through the usb, so that it would reduce the total upload time.
> Certainly, this also could be used to verify current unzip feature
> whether it works well.
> Or some other case, like testing the memory speed?
>
> No, the new gzip feature only shows up if its configuration is opened,
> or the uboot size would
> not be impacted.

Do you have any comment on this series?

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

Re: [U-Boot] [PATCH] cm-t35: add I2C multi-bus support

[Tom Rini]

On 04/02/2012 05:29 AM, Igor Grinberg wrote:

From: Nikita Kiryanov

Enable I2C multi-bus support and config I2C muxes for I2C2 and I2C3.

Signed-off-by: Nikita Kiryanov
Signed-off-by: Igor Grinberg


Have you confirmed this is sufficient and there's no changes required in 
omap24xx_i2c.c ?  Thanks!


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

Re: [U-Boot] [PATCH] Prevent malloc with size 0

[Joakim Tjernlund]

Marek Vasut  wrote on 2012/04/02 16:05:13:
>
> Dear Joakim Tjernlund,
>
> > Hi Grame
> >
> > Graeme Russ  wrote on 2012/04/02 09:17:44:
> > > Hi Joakim,
> > >
> > > On Apr 2, 2012 4:55 PM, "Joakim Tjernlund" 
> wrote:
> > > > > Hi Marek,
> > > > >
> > > > > On Mon, Apr 2, 2012 at 1:36 PM, Marek Vasut 
> wrote:
> > > > > > Dear Mike Frysinger,
> > > > > >
> > > > > >> On Sunday 01 April 2012 20:25:44 Graeme Russ wrote:
> > > > > >> > b) The code calling malloc(0) is making a perfectly legitimate
> > > > > >> > assumption
> > > > > >> >
> > > > > >> >based on how glibc handles malloc(0)
> > > > > >>
> > > > > >> not really.  POSIX says malloc(0) is implementation defined (so it
> > > > > >> may return a unique address, or it may return NULL).  no
> > > > > >> userspace code assuming malloc(0) will return non-NULL is
> > > > > >> correct.
> > > > > >
> > > > > > Which is your implementation-defined ;-) But I have to agree with
> > > > > > this one. So my vote is for returning NULL.
> > > > >
> > > > > Also, no userspace code assuming malloc(0) will return NULL is
> > > > > correct
> > > > >
> > > > > Point being, no matter which implementation is chosen, it is up to
> > > > > the caller to not assume that the choice that was made was, in fact,
> > > > > the choice that was made.
> > > > >
> > > > > I.e. the behaviour of malloc(0) should be able to be changed on a
> > > > > whim with no side-effects
> > > > >
> > > > > So I think I should change my vote to returning NULL for one reason
> > > > > and one reason only - It is faster during run-time
> > > >
> > > > Then u-boot will be incompatible with both glibc and the linux kernel,
> > > > it seems
> > >
> > > Forget aboug other implementations...
> > > What matters is that the fact that the behaviour is undefined and it is
> > > up to the caller to take that into account
> >
> > Well, u-boot borrows code from both kernel and user space so it would make
> > sense if malloc(0) behaved the same. Especially for kernel code which tend
> > to depend on the kernels impl.(just look at Scotts example)
> >
> > > > to me that any modern impl. of malloc(0) will return a non NULL ptr.
> > > >
> > > > It does need to be slower, just return ~0 instead, the kernel does
> > > > something similar: if (!size)
> > > > return ZERO_SIZE_PTR;
> > >
> > > That could work, but technically I don't think it complies as it is not a
> > > pointer to allocated memory...
> >
> > It doesn't not have to be allocated memory, just a ptr != NULL which you
> > can do free() on.
>
> But kernel has something mapped there to trap these pointers I believe.

So? That only means that the kernel has extra protection if someone tries to
deference such a ptr. You are not required to do that(nice to have though)
You don have any protection for deferencing NULL either I think?

 Jocke

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

Re: [U-Boot] [PATCH 2/4] net: round up before calling flush_cache

[Stefano Babic]

On 02/04/2012 16:03, Marek Vasut wrote:

> 
> Well, it was there to catch bugs in drivers. We can probably turn it into 
> debug() now ?

Agree, I set it into next version.

Best regards,
Stefano Babic


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

[U-Boot] MMC is broken on mx28evk

[Lauri Hintsala]

Hi Marek,

I built U-Boot 2012.04-rc1 and tried it with mx28evk. MMC seems to be 
broken. Reverting your commit 3687c4 (i.MX28: Do data transfers via DMA 
in MMC driver) fix the issue.


Also there is issue in setting MAC address. Console logs are at the end 
of this mail.


Best regards,
Lauri Hintsala


---

U-Boot 2012.04-rc1 (Apr 02 2012 - 17:19:53)

Freescale i.MX28 family at 454 MHz
DRAM:  128 MiB
MMC:   MXS MMC: 0
MMC0: DMA transfer failed
MMC0: DMA transfer failed
MMC0: DMA transfer failed
MMC0: DMA transfer failed
MMC init failed
Using default environment

In:serial
Out:   serial
Err:   serial
Net:   FEC0
Warning: failed to set MAC address
, FEC1
Warning: failed to set MAC address

Hit any key to stop autoboot:  0
MX28EVK U-Boot > mmc rescan
MMC0: DMA transfer failed
MMC0: DMA transfer failed
MMC0: DMA transfer failed
MMC0: DMA transfer failed
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] MMC is broken on mx28evk

[Marek Vasut]

Dear Lauri Hintsala,

> Hi Marek,
> 
> I built U-Boot 2012.04-rc1 and tried it with mx28evk. MMC seems to be
> broken. Reverting your commit 3687c4 (i.MX28: Do data transfers via DMA
> in MMC driver) fix the issue.

CCing Fabio, can you test? Also, CCing proper ML.

> Also there is issue in setting MAC address. Console logs are at the end
> of this mail.
> 
> Best regards,
> Lauri Hintsala
> 
> 
> ---
> 
> U-Boot 2012.04-rc1 (Apr 02 2012 - 17:19:53)
> 
> Freescale i.MX28 family at 454 MHz
> DRAM:  128 MiB
> MMC:   MXS MMC: 0
> MMC0: DMA transfer failed
> MMC0: DMA transfer failed
> MMC0: DMA transfer failed
> MMC0: DMA transfer failed
> MMC init failed
> Using default environment
> 
> In:serial
> Out:   serial
> Err:   serial
> Net:   FEC0
> Warning: failed to set MAC address
> , FEC1
> Warning: failed to set MAC address
> 
> Hit any key to stop autoboot:  0
> MX28EVK U-Boot > mmc rescan
> MMC0: DMA transfer failed
> MMC0: DMA transfer failed
> MMC0: DMA transfer failed
> MMC0: DMA transfer failed

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

Re: [U-Boot] MMC0: DMA transfer failed

[Marek Vasut]

Dear Fabio Estevam,

> Hi,
> 
> On a mx28evk board I am getting the following using top of tree U-boot:
> 
> U-Boot 2012.04-rc1-1-g037cbfd (Apr 02 2012 - 10:57:48)
> 
> Freescale i.MX28 family at 454 MHz
> DRAM:  128 MiB
> MMC:   MXS MMC: 0
> MMC0: DMA transfer failed
> MMC0: DMA transfer failed
> MMC0: DMA transfer failed
> MMC0: DMA transfer failed
> MMC init failed
> Using default environment

No, it means I might just have a good card and I didn't notice this. I really 
do 
need to get some crappy (new) cards to track down these issues. Fabio, can you 
please try debugging this?

> Is there any patch I am missing?
> 
> Thanks,
> 
> Fabio Estevam

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] Prevent malloc with size 0

[Marek Vasut]

Dear Joakim Tjernlund,

> Marek Vasut  wrote on 2012/04/02 16:05:13:
> > Dear Joakim Tjernlund,
> > 
> > > Hi Grame
> > > 
> > > Graeme Russ  wrote on 2012/04/02 09:17:44:
> > > > Hi Joakim,
> > > > 
> > > > On Apr 2, 2012 4:55 PM, "Joakim Tjernlund"
> > > > 
> > 
> > wrote:
> > > > > > Hi Marek,
> > > > > > 
> > > > > > On Mon, Apr 2, 2012 at 1:36 PM, Marek Vasut
> > > > > > 
> > 
> > wrote:
> > > > > > > Dear Mike Frysinger,
> > > > > > > 
> > > > > > >> On Sunday 01 April 2012 20:25:44 Graeme Russ wrote:
> > > > > > >> > b) The code calling malloc(0) is making a perfectly
> > > > > > >> > legitimate assumption
> > > > > > >> > 
> > > > > > >> >based on how glibc handles malloc(0)
> > > > > > >> 
> > > > > > >> not really.  POSIX says malloc(0) is implementation defined
> > > > > > >> (so it may return a unique address, or it may return NULL). 
> > > > > > >> no userspace code assuming malloc(0) will return non-NULL is
> > > > > > >> correct.
> > > > > > > 
> > > > > > > Which is your implementation-defined ;-) But I have to agree
> > > > > > > with this one. So my vote is for returning NULL.
> > > > > > 
> > > > > > Also, no userspace code assuming malloc(0) will return NULL is
> > > > > > correct
> > > > > > 
> > > > > > Point being, no matter which implementation is chosen, it is up
> > > > > > to the caller to not assume that the choice that was made was,
> > > > > > in fact, the choice that was made.
> > > > > > 
> > > > > > I.e. the behaviour of malloc(0) should be able to be changed on a
> > > > > > whim with no side-effects
> > > > > > 
> > > > > > So I think I should change my vote to returning NULL for one
> > > > > > reason and one reason only - It is faster during run-time
> > > > > 
> > > > > Then u-boot will be incompatible with both glibc and the linux
> > > > > kernel, it seems
> > > > 
> > > > Forget aboug other implementations...
> > > > What matters is that the fact that the behaviour is undefined and it
> > > > is up to the caller to take that into account
> > > 
> > > Well, u-boot borrows code from both kernel and user space so it would
> > > make sense if malloc(0) behaved the same. Especially for kernel code
> > > which tend to depend on the kernels impl.(just look at Scotts example)
> > > 
> > > > > to me that any modern impl. of malloc(0) will return a non NULL
> > > > > ptr.
> > > > > 
> > > > > It does need to be slower, just return ~0 instead, the kernel does
> > > > > something similar: if (!size)
> > > > > 
> > > > > return ZERO_SIZE_PTR;
> > > > 
> > > > That could work, but technically I don't think it complies as it is
> > > > not a pointer to allocated memory...
> > > 
> > > It doesn't not have to be allocated memory, just a ptr != NULL which
> > > you can do free() on.
> > 
> > But kernel has something mapped there to trap these pointers I believe.
> 
> So? That only means that the kernel has extra protection if someone tries
> to deference such a ptr. You are not required to do that(nice to have
> though) You don have any protection for deferencing NULL either I think?

Can't GCC track it?

>  Jocke

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

Re: [U-Boot] MMC0: DMA transfer failed

[Stefano Babic]

On 02/04/2012 16:01, Fabio Estevam wrote:
> Hi,
> 
> On a mx28evk board I am getting the following using top of tree U-boot:
> 
> U-Boot 2012.04-rc1-1-g037cbfd (Apr 02 2012 - 10:57:48)
> 
> Freescale i.MX28 family at 454 MHz
> DRAM:  128 MiB
> MMC:   MXS MMC: 0
> MMC0: DMA transfer failed
> MMC0: DMA transfer failed
> MMC0: DMA transfer failed
> MMC0: DMA transfer failed
> MMC init failed
> Using default environment
> 
> Is there any patch I am missing?

Hi Fabio,

maybe it is worth to check first if it depends on the data cache, that
is now turned on. Add CONFIG_CMD_CACHE to the configuartion file, and
try to start mmc with and without dcache.

Best regards,
Stefano

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

Re: [U-Boot] MMC0: DMA transfer failed

[Marek Vasut]

Dear Stefano Babic,

> On 02/04/2012 16:01, Fabio Estevam wrote:
> > Hi,
> > 
> > On a mx28evk board I am getting the following using top of tree U-boot:
> > 
> > U-Boot 2012.04-rc1-1-g037cbfd (Apr 02 2012 - 10:57:48)
> > 
> > Freescale i.MX28 family at 454 MHz
> > DRAM:  128 MiB
> > MMC:   MXS MMC: 0
> > MMC0: DMA transfer failed
> > MMC0: DMA transfer failed
> > MMC0: DMA transfer failed
> > MMC0: DMA transfer failed
> > MMC init failed
> > Using default environment
> > 
> > Is there any patch I am missing?
> 
> Hi Fabio,
> 
> maybe it is worth to check first if it depends on the data cache, that
> is now turned on. Add CONFIG_CMD_CACHE to the configuartion file, and
> try to start mmc with and without dcache.

The cache should be off on m28evk and so should be on mx28evk.

> Best regards,
> Stefano

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] Prevent malloc with size 0

[Joakim Tjernlund]

Marek Vasut  wrote on 2012/04/02 16:42:30:
>
> Dear Joakim Tjernlund,
>
> > Marek Vasut  wrote on 2012/04/02 16:05:13:
> > > Dear Joakim Tjernlund,
> > >
> > > > Hi Grame
> > > >
> > > > Graeme Russ  wrote on 2012/04/02 09:17:44:
> > > > > Hi Joakim,
> > > > >
> > > > > On Apr 2, 2012 4:55 PM, "Joakim Tjernlund"
> > > > > 
> > >
> > > wrote:
> > > > > > > Hi Marek,
> > > > > > >
> > > > > > > On Mon, Apr 2, 2012 at 1:36 PM, Marek Vasut
> > > > > > > 
> > >
> > > wrote:
> > > > > > > > Dear Mike Frysinger,
> > > > > > > >
> > > > > > > >> On Sunday 01 April 2012 20:25:44 Graeme Russ wrote:
> > > > > > > >> > b) The code calling malloc(0) is making a perfectly
> > > > > > > >> > legitimate assumption
> > > > > > > >> >
> > > > > > > >> >based on how glibc handles malloc(0)
> > > > > > > >>
> > > > > > > >> not really.  POSIX says malloc(0) is implementation defined
> > > > > > > >> (so it may return a unique address, or it may return NULL).
> > > > > > > >> no userspace code assuming malloc(0) will return non-NULL is
> > > > > > > >> correct.
> > > > > > > >
> > > > > > > > Which is your implementation-defined ;-) But I have to agree
> > > > > > > > with this one. So my vote is for returning NULL.
> > > > > > >
> > > > > > > Also, no userspace code assuming malloc(0) will return NULL is
> > > > > > > correct
> > > > > > >
> > > > > > > Point being, no matter which implementation is chosen, it is up
> > > > > > > to the caller to not assume that the choice that was made was,
> > > > > > > in fact, the choice that was made.
> > > > > > >
> > > > > > > I.e. the behaviour of malloc(0) should be able to be changed on a
> > > > > > > whim with no side-effects
> > > > > > >
> > > > > > > So I think I should change my vote to returning NULL for one
> > > > > > > reason and one reason only - It is faster during run-time
> > > > > >
> > > > > > Then u-boot will be incompatible with both glibc and the linux
> > > > > > kernel, it seems
> > > > >
> > > > > Forget aboug other implementations...
> > > > > What matters is that the fact that the behaviour is undefined and it
> > > > > is up to the caller to take that into account
> > > >
> > > > Well, u-boot borrows code from both kernel and user space so it would
> > > > make sense if malloc(0) behaved the same. Especially for kernel code
> > > > which tend to depend on the kernels impl.(just look at Scotts example)
> > > >
> > > > > > to me that any modern impl. of malloc(0) will return a non NULL
> > > > > > ptr.
> > > > > >
> > > > > > It does need to be slower, just return ~0 instead, the kernel does
> > > > > > something similar: if (!size)
> > > > > >
> > > > > > return ZERO_SIZE_PTR;
> > > > >
> > > > > That could work, but technically I don't think it complies as it is
> > > > > not a pointer to allocated memory...
> > > >
> > > > It doesn't not have to be allocated memory, just a ptr != NULL which
> > > > you can do free() on.
> > >
> > > But kernel has something mapped there to trap these pointers I believe.
> >
> > So? That only means that the kernel has extra protection if someone tries
> > to deference such a ptr. You are not required to do that(nice to have
> > though) You don have any protection for deferencing NULL either I think?
>
> Can't GCC track it?

Track what? NULL ptrs? I don't think so. Possibly when you have a static
NULL ptr but not in the general case.

I am getting tired of this discussion now. I am just trying to tell you that
no sane impl. of malloc() these days return NULL for malloc(0). Even though
standards allow it they don't consider malloc(0) an error, glibc will not
update errno in this case.

 Jocke

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

Re: [U-Boot] [PATCH] mmc:fix: Set mmc width according to MMC host capabilities

[Lukasz Majewski]

Hi Andy,

> Hi Andy,
> 
> > This patch sets the MMC width according to the MMC host
> > capabilities. It turned out, that there are some targets (e.g.
> > GONI), which are able to read data from SPI only at 4 bit mode.
> > This patch restricts the width number according to the MMC host.
> > 
> > Signed-off-by: Lukasz Majewski 
> > Signed-off-by: Kyungmin Park 
> > Cc: Andy Fleming 
> > ---
> >  drivers/mmc/mmc.c |4 +++-
> >  include/mmc.h |3 +++
> >  2 files changed, 6 insertions(+), 1 deletions(-)
> > 
> > diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> > index 49c3349..51c0106 100644
> > --- a/drivers/mmc/mmc.c
> > +++ b/drivers/mmc/mmc.c
> > @@ -1103,7 +1103,9 @@ int mmc_startup(struct mmc *mmc)
> > else
> > mmc_set_clock(mmc, 2500);
> > } else {
> > -   for (width = EXT_CSD_BUS_WIDTH_8; width >= 0;
> > width--) {
> > +   width = ((mmc->host_caps &
> > MMC_MODE_MASK_WIDTH_BITS)
> > >>
> > +MMC_MODE_WIDTH_BITS_SHIFT);
> > +   for (; width >= 0; width--) {
> > /* Set the card to use 4 bit*/
> > err = mmc_switch(mmc,
> > EXT_CSD_CMD_SET_NORMAL, EXT_CSD_BUS_WIDTH, width);
> > diff --git a/include/mmc.h b/include/mmc.h
> > index 30c2375..ff2f28e 100644
> > --- a/include/mmc.h
> > +++ b/include/mmc.h
> > @@ -47,6 +47,9 @@
> >  #define MMC_MODE_SPI   0x400
> >  #define MMC_MODE_HC0x800
> >  
> > +#define MMC_MODE_MASK_WIDTH_BITS (MMC_MODE_4BIT | MMC_MODE_8BIT)
> > +#define MMC_MODE_WIDTH_BITS_SHIFT 8
> > +
> >  #define SD_DATA_4BIT   0x0004
> >  
> >  #define IS_SD(x) (x->version & SD_VERSION_SD)
> 
> Do you have any opinions/comments about this patch?
> It has already spent some time on the mainling list and nobody
> complaint :-)
> 

Do you have any questions about this patch?


-- 
Best regards,

Lukasz Majewski

Samsung Poland R&D Center
Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Prevent malloc with size 0

[Marek Vasut]

Dear Joakim Tjernlund,

> Marek Vasut  wrote on 2012/04/02 16:42:30:
> > Dear Joakim Tjernlund,
> > 
> > > Marek Vasut  wrote on 2012/04/02 16:05:13:
> > > > Dear Joakim Tjernlund,
> > > > 
> > > > > Hi Grame
> > > > > 
> > > > > Graeme Russ  wrote on 2012/04/02 09:17:44:
> > > > > > Hi Joakim,
> > > > > > 
> > > > > > On Apr 2, 2012 4:55 PM, "Joakim Tjernlund"
> > > > > > 
> > > > 
> > > > wrote:
> > > > > > > > Hi Marek,
> > > > > > > > 
> > > > > > > > On Mon, Apr 2, 2012 at 1:36 PM, Marek Vasut
> > > > > > > > 
> > > > 
> > > > wrote:
> > > > > > > > > Dear Mike Frysinger,
> > > > > > > > > 
> > > > > > > > >> On Sunday 01 April 2012 20:25:44 Graeme Russ wrote:
> > > > > > > > >> > b) The code calling malloc(0) is making a perfectly
> > > > > > > > >> > legitimate assumption
> > > > > > > > >> > 
> > > > > > > > >> >based on how glibc handles malloc(0)
> > > > > > > > >> 
> > > > > > > > >> not really.  POSIX says malloc(0) is implementation
> > > > > > > > >> defined (so it may return a unique address, or it may
> > > > > > > > >> return NULL). no userspace code assuming malloc(0) will
> > > > > > > > >> return non-NULL is correct.
> > > > > > > > > 
> > > > > > > > > Which is your implementation-defined ;-) But I have to
> > > > > > > > > agree with this one. So my vote is for returning NULL.
> > > > > > > > 
> > > > > > > > Also, no userspace code assuming malloc(0) will return NULL
> > > > > > > > is correct
> > > > > > > > 
> > > > > > > > Point being, no matter which implementation is chosen, it is
> > > > > > > > up to the caller to not assume that the choice that was made
> > > > > > > > was, in fact, the choice that was made.
> > > > > > > > 
> > > > > > > > I.e. the behaviour of malloc(0) should be able to be changed
> > > > > > > > on a whim with no side-effects
> > > > > > > > 
> > > > > > > > So I think I should change my vote to returning NULL for one
> > > > > > > > reason and one reason only - It is faster during run-time
> > > > > > > 
> > > > > > > Then u-boot will be incompatible with both glibc and the linux
> > > > > > > kernel, it seems
> > > > > > 
> > > > > > Forget aboug other implementations...
> > > > > > What matters is that the fact that the behaviour is undefined and
> > > > > > it is up to the caller to take that into account
> > > > > 
> > > > > Well, u-boot borrows code from both kernel and user space so it
> > > > > would make sense if malloc(0) behaved the same. Especially for
> > > > > kernel code which tend to depend on the kernels impl.(just look at
> > > > > Scotts example)
> > > > > 
> > > > > > > to me that any modern impl. of malloc(0) will return a non NULL
> > > > > > > ptr.
> > > > > > > 
> > > > > > > It does need to be slower, just return ~0 instead, the kernel
> > > > > > > does something similar: if (!size)
> > > > > > > 
> > > > > > > return ZERO_SIZE_PTR;
> > > > > > 
> > > > > > That could work, but technically I don't think it complies as it
> > > > > > is not a pointer to allocated memory...
> > > > > 
> > > > > It doesn't not have to be allocated memory, just a ptr != NULL
> > > > > which you can do free() on.
> > > > 
> > > > But kernel has something mapped there to trap these pointers I
> > > > believe.
> > > 
> > > So? That only means that the kernel has extra protection if someone
> > > tries to deference such a ptr. You are not required to do that(nice to
> > > have though) You don have any protection for deferencing NULL either I
> > > think?
> > 
> > Can't GCC track it?
> 
> Track what? NULL ptrs? I don't think so. Possibly when you have a static
> NULL ptr but not in the general case.

Well of course.

> I am getting tired of this discussion now. I am just trying to tell you
> that no sane impl. of malloc() these days return NULL for malloc(0).

And I got your point. Though for u-boot, this would be the best solution 
actually. Anyone who uses memory allocated by malloc(0) is insane.

> Even
> though standards allow it they don't consider malloc(0) an error, glibc
> will not update errno in this case.

There's no errno in uboot I'm aware of ;-)

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

Re: [U-Boot] MMC0: DMA transfer failed

[Fabio Estevam]

On Mon, Apr 2, 2012 at 11:41 AM, Marek Vasut  wrote:

> No, it means I might just have a good card and I didn't notice this. I really 
> do
> need to get some crappy (new) cards to track down these issues. Fabio, can you
> please try debugging this?

Ok, I am debugging this.

What do you think about the change below?

--- a/drivers/mmc/mxsmmc.c
+++ b/drivers/mmc/mxsmmc.c
@@ -191,7 +191,7 @@ mxsmmc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd, struct
else
cache_data_count = data_count;

-   if (data->flags & MMC_DATA_READ) {
+   if (data->flags & MMC_DATA_WRITE) {
priv->desc->cmd.data = MXS_DMA_DESC_COMMAND_DMA_WRITE;
priv->desc->cmd.address = (dma_addr_t)data->dest;
} else {

It doesn't fix this issue, but it seems correct.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] U-Boot build report @ Sat Mar 31 05:30:15 CEST 2012

[Tom Rini]

On Sat, Mar 31, 2012 at 02:59:06PM +0200, Marek Vasut wrote:
> Hello guys,
> 
> we now have exactly these boards not building for -RC1, can you please look 
> into 
> it?:
[snip]
> arm/hawkboard   FAILED FOR: eldk4.2
> arm/hawkboard_uart  FAILED FOR: eldk4.2

SPL link failure.  Newer toolchains give us a built-in udelay, and we
provide __udelay but not udelay on these boards since we don't use
CONFIG_SPL_LIBGENERIC_SUPPORT and adding that in might be a fatal size
bloat.  Not sure what we want to do about this, and the last thread or
two about this was unresolved.

-- 
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 v8] usb: align buffers at cacheline

[Tom Warren]

Marek, Puneet, et al.,

> -Original Message-
> From: Marek Vasut [mailto:ma...@denx.de]
> Sent: Monday, March 19, 2012 8:47 AM
> To: Tom Warren
> Cc: Puneet Saxena; Mike Frysinger; u-boot@lists.denx.de; s...@chromium.org;
> li...@bohmer.net; tr...@ti.com; albert.u.b...@aribaud.net
> Subject: Re: [PATCH v8] usb: align buffers at cacheline
> 
> Dear Tom Warren,
> 
> > Marek,
> >
> > > -Original Message-
> > > From: Marek Vasut [mailto:marek.va...@gmail.com]
> > > Sent: Monday, March 19, 2012 7:43 AM
> > > To: Puneet Saxena
> > > Cc: Mike Frysinger; u-boot@lists.denx.de; s...@chromium.org;
> > > li...@bohmer.net; tr...@ti.com; Tom Warren
> > > Subject: Re: [PATCH v8] usb: align buffers at cacheline
> > >
> > > Dear Puneet Saxena,
> > >
> > > > Hi Marek,
> > > > I adapted my patch for git://git.denx.de/u-boot-usb.git master branch.
> > > > As the build for target "Seaboard" is broken once I enable USB in
> > > > Seaboard.h, I am unable to test my changes on "u-boot-usb".
> > >
> > > u-boot-usb is forked off the mainline u-boot.git ... tegra stuff
> > > likely isn't pulled there. Simon, can you tell me when this is gonna be
> there?
> >
> > Simon's USB/fdt patch set will be pulled into -arm first, then -main,
> > when he adapts the 'panic' putc patchset (implement pre-console putc
> > for fdt
> > warning) to meet with Wolfgang's approval. Once that's done (hopefully
> > early this week), I can submit another pull request to finally get
> > this series in.
> >
> > Simon - can we have an ETA?
> 
> I'd love to see some ETA on u-boot-arm push from Albert Aribaud :-( Albert,
> how're you doing ?
> 
> Thanks!
> 

u-boot-tegra/master has the fdt/USB patches, and has been pulled into ARM 
master.

We need the cacheline/buffer alignment patch now, to remove the volcanic spew 
whenever you do any USB commands.

Can you guys (Puneet & Marek, and Mike/Simon if necessary) work together to get 
this in soon?

Thanks,

Tom
> >
> > Tom
> >
> > > > I would have to merge lots of changes from "denx-uboot-tegra" to
> > > > make it working for "u-boot-usb.git" master branch.
> > > > I can send the adapted patch if it's needed.
> > >
> > > The problem I see is that there are important USB patches in
> > > mainline, though they are not in -tegra. So the approach I'd take if
> > > I were you would be to rebase -tegra atop of mainline for yourself
> > > and then apply your patch. Does that work for you?
> > >
> > > > Thanks,
> > > > Puneet
> > >
> > > Thanks!
> > >
> > > Best regards,
> > > Marek Vasut
> 
> Best regards,
> Marek Vasut
-- 
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Prevent malloc with size 0

[Joakim Tjernlund]

Marek Vasut  wrote on 2012/04/02 17:23:03:
>
> Dear Joakim Tjernlund,
>
> > Marek Vasut  wrote on 2012/04/02 16:42:30:
> > > Dear Joakim Tjernlund,
> > >
> > > > Marek Vasut  wrote on 2012/04/02 16:05:13:
> > > > > Dear Joakim Tjernlund,
> > > > >
> > > > > > Hi Grame
> > > > > >
> > > > > > Graeme Russ  wrote on 2012/04/02 09:17:44:
> > > > > > > Hi Joakim,
> > > > > > >
> > > > > > > On Apr 2, 2012 4:55 PM, "Joakim Tjernlund"
> > > > > > > 
> > > > >
> > > > > wrote:
> > > > > > > > > Hi Marek,
> > > > > > > > >
> > > > > > > > > On Mon, Apr 2, 2012 at 1:36 PM, Marek Vasut
> > > > > > > > > 
> > > > >
> > > > > wrote:
> > > > > > > > > > Dear Mike Frysinger,
> > > > > > > > > >
> > > > > > > > > >> On Sunday 01 April 2012 20:25:44 Graeme Russ wrote:
> > > > > > > > > >> > b) The code calling malloc(0) is making a perfectly
> > > > > > > > > >> > legitimate assumption
> > > > > > > > > >> >
> > > > > > > > > >> >based on how glibc handles malloc(0)
> > > > > > > > > >>
> > > > > > > > > >> not really.  POSIX says malloc(0) is implementation
> > > > > > > > > >> defined (so it may return a unique address, or it may
> > > > > > > > > >> return NULL). no userspace code assuming malloc(0) will
> > > > > > > > > >> return non-NULL is correct.
> > > > > > > > > >
> > > > > > > > > > Which is your implementation-defined ;-) But I have to
> > > > > > > > > > agree with this one. So my vote is for returning NULL.
> > > > > > > > >
> > > > > > > > > Also, no userspace code assuming malloc(0) will return NULL
> > > > > > > > > is correct
> > > > > > > > >
> > > > > > > > > Point being, no matter which implementation is chosen, it is
> > > > > > > > > up to the caller to not assume that the choice that was made
> > > > > > > > > was, in fact, the choice that was made.
> > > > > > > > >
> > > > > > > > > I.e. the behaviour of malloc(0) should be able to be changed
> > > > > > > > > on a whim with no side-effects
> > > > > > > > >
> > > > > > > > > So I think I should change my vote to returning NULL for one
> > > > > > > > > reason and one reason only - It is faster during run-time
> > > > > > > >
> > > > > > > > Then u-boot will be incompatible with both glibc and the linux
> > > > > > > > kernel, it seems
> > > > > > >
> > > > > > > Forget aboug other implementations...
> > > > > > > What matters is that the fact that the behaviour is undefined and
> > > > > > > it is up to the caller to take that into account
> > > > > >
> > > > > > Well, u-boot borrows code from both kernel and user space so it
> > > > > > would make sense if malloc(0) behaved the same. Especially for
> > > > > > kernel code which tend to depend on the kernels impl.(just look at
> > > > > > Scotts example)
> > > > > >
> > > > > > > > to me that any modern impl. of malloc(0) will return a non NULL
> > > > > > > > ptr.
> > > > > > > >
> > > > > > > > It does need to be slower, just return ~0 instead, the kernel
> > > > > > > > does something similar: if (!size)
> > > > > > > >
> > > > > > > > return ZERO_SIZE_PTR;
> > > > > > >
> > > > > > > That could work, but technically I don't think it complies as it
> > > > > > > is not a pointer to allocated memory...
> > > > > >
> > > > > > It doesn't not have to be allocated memory, just a ptr != NULL
> > > > > > which you can do free() on.
> > > > >
> > > > > But kernel has something mapped there to trap these pointers I
> > > > > believe.
> > > >
> > > > So? That only means that the kernel has extra protection if someone
> > > > tries to deference such a ptr. You are not required to do that(nice to
> > > > have though) You don have any protection for deferencing NULL either I
> > > > think?
> > >
> > > Can't GCC track it?
> >
> > Track what? NULL ptrs? I don't think so. Possibly when you have a static
> > NULL ptr but not in the general case.
>
> Well of course.

What did you mean then with "Can't GCC track it?" then? Just a bad joke?

>
> > I am getting tired of this discussion now. I am just trying to tell you
> > that no sane impl. of malloc() these days return NULL for malloc(0).
>
> And I got your point. Though for u-boot, this would be the best solution
> actually. Anyone who uses memory allocated by malloc(0) is insane.

No, you don't get the point. If you did you would not have have made the 
"insane" remark.

>
> > Even
> > though standards allow it they don't consider malloc(0) an error, glibc
> > will not update errno in this case.
>
> There's no errno in uboot I'm aware of ;-)

Just pointing out that malloc(0) is not an error even if malloc returns NULL in 
glibc/standards.
malloc(0) represents the empty set, just like 0 does in math and it is sometimes
useful.

 Jocke

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

Re: [U-Boot] U-Boot build report @ Sat Mar 31 05:30:15 CEST 2012

[Marek Vasut]

Dear Tom Rini,

> On Sat, Mar 31, 2012 at 02:59:06PM +0200, Marek Vasut wrote:
> > Hello guys,
> > 
> > we now have exactly these boards not building for -RC1, can you please
> > look into
> 
> > it?:
> [snip]
> 
> > arm/hawkboard   FAILED FOR: eldk4.2
> > arm/hawkboard_uart  FAILED FOR: eldk4.2
> 
> SPL link failure.  Newer toolchains give us a built-in udelay, and we
> provide __udelay but not udelay on these boards since we don't use
> CONFIG_SPL_LIBGENERIC_SUPPORT and adding that in might be a fatal size
> bloat.  Not sure what we want to do about this, and the last thread or
> two about this was unresolved.

But we have --gc-sections and stuff like that so unneeded bloat should be 
removed.

And it's not only this, I see also problem with lldiv.

Configuring for hawkboard board...
arch/arm/cpu/arm926ejs/davinci/libdavinci.o: In function `lldiv':
/workspace/compiler/eldk4.2/device/arm___hawkboard/include/div64.h:45: 
undefined 
reference to `__div64_32'
drivers/mtd/nand/libnand.o: In function `nand_command':
/workspace/compiler/eldk4.2/device/arm___hawkboard/drivers/mtd/nand/nand_base.c:591:
 
undefined reference to `udelay'
/workspace/compiler/eldk4.2/device/arm___hawkboard/drivers/mtd/nand/nand_base.c:607:
 
undefined reference to `udelay'
/workspace/compiler/eldk4.2/device/arm___hawkboard/drivers/mtd/nand/nand_base.c:613:
 
undefined reference to `udelay'
make[1]: *** 
[/workspace/compiler/eldk4.2/device/arm___hawkboard/spl/u-boot-spl] 
Error 1
make: *** [spl/u-boot-spl.bin] Error 2
   textdata bss dec hex filename
 1918206388   54764  252972   3dc2c ./u-boot

- SUMMARY 
Boards compiled: 1
Boards with warnings or errors: 1 ( hawkboard )
--

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 v8] usb: align buffers at cacheline

[Marek Vasut]

Dear Tom Warren,

> Marek, Puneet, et al.,
> 
> > -Original Message-
> > From: Marek Vasut [mailto:ma...@denx.de]
> > Sent: Monday, March 19, 2012 8:47 AM
> > To: Tom Warren
> > Cc: Puneet Saxena; Mike Frysinger; u-boot@lists.denx.de;
> > s...@chromium.org; li...@bohmer.net; tr...@ti.com;
> > albert.u.b...@aribaud.net
> > Subject: Re: [PATCH v8] usb: align buffers at cacheline
> > 
> > Dear Tom Warren,
> > 
> > > Marek,
> > > 
> > > > -Original Message-
> > > > From: Marek Vasut [mailto:marek.va...@gmail.com]
> > > > Sent: Monday, March 19, 2012 7:43 AM
> > > > To: Puneet Saxena
> > > > Cc: Mike Frysinger; u-boot@lists.denx.de; s...@chromium.org;
> > > > li...@bohmer.net; tr...@ti.com; Tom Warren
> > > > Subject: Re: [PATCH v8] usb: align buffers at cacheline
> > > > 
> > > > Dear Puneet Saxena,
> > > > 
> > > > > Hi Marek,
> > > > > I adapted my patch for git://git.denx.de/u-boot-usb.git master
> > > > > branch. As the build for target "Seaboard" is broken once I enable
> > > > > USB in Seaboard.h, I am unable to test my changes on "u-boot-usb".
> > > > 
> > > > u-boot-usb is forked off the mainline u-boot.git ... tegra stuff
> > > > likely isn't pulled there. Simon, can you tell me when this is gonna
> > > > be
> > 
> > there?
> > 
> > > Simon's USB/fdt patch set will be pulled into -arm first, then -main,
> > > when he adapts the 'panic' putc patchset (implement pre-console putc
> > > for fdt
> > > warning) to meet with Wolfgang's approval. Once that's done (hopefully
> > > early this week), I can submit another pull request to finally get
> > > this series in.
> > > 
> > > Simon - can we have an ETA?
> > 
> > I'd love to see some ETA on u-boot-arm push from Albert Aribaud :-(
> > Albert, how're you doing ?
> > 
> > Thanks!
> 
> u-boot-tegra/master has the fdt/USB patches, and has been pulled into ARM
> master.
> 
> We need the cacheline/buffer alignment patch now, to remove the volcanic
> spew whenever you do any USB commands.
> 
> Can you guys (Puneet & Marek, and Mike/Simon if necessary) work together to
> get this in soon?

Ain't you gonna help us? I believe the patch is really close to be usable, it 
just needs some easy debugging, won't you volunteer, it'd really help? :)

> Thanks,
> 
> Tom
> 
> > > Tom
> > > 
> > > > > I would have to merge lots of changes from "denx-uboot-tegra" to
> > > > > make it working for "u-boot-usb.git" master branch.
> > > > > I can send the adapted patch if it's needed.
> > > > 
> > > > The problem I see is that there are important USB patches in
> > > > mainline, though they are not in -tegra. So the approach I'd take if
> > > > I were you would be to rebase -tegra atop of mainline for yourself
> > > > and then apply your patch. Does that work for you?
> > > > 
> > > > > Thanks,
> > > > > Puneet
> > > > 
> > > > Thanks!
> > > > 
> > > > Best regards,
> > > > Marek Vasut
> > 
> > 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 v8] usb: align buffers at cacheline

[Tom Warren]

Marek,

> -Original Message-
> From: Marek Vasut [mailto:ma...@denx.de]
> Sent: Monday, April 02, 2012 9:12 AM
> To: Tom Warren
> Cc: Puneet Saxena; Mike Frysinger; u-boot@lists.denx.de; s...@chromium.org;
> li...@bohmer.net; tr...@ti.com; albert.u.b...@aribaud.net
> Subject: Re: [PATCH v8] usb: align buffers at cacheline
> 
> Dear Tom Warren,
> 
> > Marek, Puneet, et al.,
> >
> > > -Original Message-
> > > From: Marek Vasut [mailto:ma...@denx.de]
> > > Sent: Monday, March 19, 2012 8:47 AM
> > > To: Tom Warren
> > > Cc: Puneet Saxena; Mike Frysinger; u-boot@lists.denx.de;
> > > s...@chromium.org; li...@bohmer.net; tr...@ti.com;
> > > albert.u.b...@aribaud.net
> > > Subject: Re: [PATCH v8] usb: align buffers at cacheline
> > >
> > > Dear Tom Warren,
> > >
> > > > Marek,
> > > >
> > > > > -Original Message-
> > > > > From: Marek Vasut [mailto:marek.va...@gmail.com]
> > > > > Sent: Monday, March 19, 2012 7:43 AM
> > > > > To: Puneet Saxena
> > > > > Cc: Mike Frysinger; u-boot@lists.denx.de; s...@chromium.org;
> > > > > li...@bohmer.net; tr...@ti.com; Tom Warren
> > > > > Subject: Re: [PATCH v8] usb: align buffers at cacheline
> > > > >
> > > > > Dear Puneet Saxena,
> > > > >
> > > > > > Hi Marek,
> > > > > > I adapted my patch for git://git.denx.de/u-boot-usb.git master
> > > > > > branch. As the build for target "Seaboard" is broken once I
> > > > > > enable USB in Seaboard.h, I am unable to test my changes on "u-
> boot-usb".
> > > > >
> > > > > u-boot-usb is forked off the mainline u-boot.git ... tegra stuff
> > > > > likely isn't pulled there. Simon, can you tell me when this is
> > > > > gonna be
> > >
> > > there?
> > >
> > > > Simon's USB/fdt patch set will be pulled into -arm first, then
> > > > -main, when he adapts the 'panic' putc patchset (implement
> > > > pre-console putc for fdt
> > > > warning) to meet with Wolfgang's approval. Once that's done
> > > > (hopefully early this week), I can submit another pull request to
> > > > finally get this series in.
> > > >
> > > > Simon - can we have an ETA?
> > >
> > > I'd love to see some ETA on u-boot-arm push from Albert Aribaud :-(
> > > Albert, how're you doing ?
> > >
> > > Thanks!
> >
> > u-boot-tegra/master has the fdt/USB patches, and has been pulled into
> > ARM master.
> >
> > We need the cacheline/buffer alignment patch now, to remove the
> > volcanic spew whenever you do any USB commands.
> >
> > Can you guys (Puneet & Marek, and Mike/Simon if necessary) work
> > together to get this in soon?
> 
> Ain't you gonna help us? I believe the patch is really close to be usable,
> it just needs some easy debugging, won't you volunteer, it'd really help? :)
> 
I can apply the latest patch (v8?) and see how much spew is still present, but 
I (a) have no expertise in cache/USB issues and (b) have a ton of patches to 
apply/push for Tegra2 and (as soon as those are in) Tegra3, so my BW is 
limited, and finally (c) this is Puneet's work, and I'd like to see him 
complete it (with help from the list).

Tom
> > Thanks,
> >
> > Tom
> >
> > > > Tom
> > > >
> > > > > > I would have to merge lots of changes from "denx-uboot-tegra"
> > > > > > to make it working for "u-boot-usb.git" master branch.
> > > > > > I can send the adapted patch if it's needed.
> > > > >
> > > > > The problem I see is that there are important USB patches in
> > > > > mainline, though they are not in -tegra. So the approach I'd
> > > > > take if I were you would be to rebase -tegra atop of mainline
> > > > > for yourself and then apply your patch. Does that work for you?
> > > > >
> > > > > > Thanks,
> > > > > > Puneet
> > > > >
> > > > > Thanks!
> > > > >
> > > > > Best regards,
> > > > > Marek Vasut
> > >
> > > Best regards,
> > > Marek Vasut
-- 
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH V3 1/4] ARM1136: add cache flush and invalidate operations

[Stefano Babic]

From: Anatolij Gustschin 

Since commit 5c1ad3e6f8ae578bbe30e09652f1531e9bc22031
(net: fec_mxc: allow use with cache enabled) the FEC_MXC
driver uses flush_dcache_range() and invalidate_dcache_range()
functions. This driver is also configured for ARM1136 based
'flea3' and 'mx35pdk' boards which currently do not build
as there are no ARM1136 specific flush_dcache_range() and
invalidate_dcache_range() functions. Add various ARM1136
cache functions to fix building for 'flea3' and 'mx35pdk'.

Signed-off-by: Anatolij Gustschin 
Signed-off-by: Stefano Babic 
Cc: Fabio Estevam 
CC: Mike Frysinger 
CC: Marek Vasut 
---
 arch/arm/cpu/arm1136/cpu.c |   95 
 1 files changed, 95 insertions(+), 0 deletions(-)

Changes since V2:
- use debug instead of printf in case of misalignment (M. Frysinger, M. Vasut)

Changes since V1:

- use the same routine as in ARM926ejs to check range to easy detect 
misalignment (S. Babic)
- cache are still disable - add enable_caches (S. Babic)

diff --git a/arch/arm/cpu/arm1136/cpu.c b/arch/arm/cpu/arm1136/cpu.c
index 2b91631..f2e30b5 100644
--- a/arch/arm/cpu/arm1136/cpu.c
+++ b/arch/arm/cpu/arm1136/cpu.c
@@ -75,3 +75,98 @@ static void cache_flush(void)
asm ("mcr p15, 0, %0, c7, c7, 0": :"r" (i));  /* invalidate both caches 
and flush btb */
asm ("mcr p15, 0, %0, c7, c10, 4": :"r" (i)); /* mem barrier to sync 
things */
 }
+
+#ifndef CONFIG_SYS_DCACHE_OFF
+
+#ifndef CONFIG_SYS_CACHELINE_SIZE
+#define CONFIG_SYS_CACHELINE_SIZE  32
+#endif
+
+void invalidate_dcache_all(void)
+{
+   asm ("mcr p15, 0, %0, c7, c6, 0" : : "r" (0));
+}
+
+void flush_dcache_all(void)
+{
+   asm ("mcr p15, 0, %0, c7, c10, 0" : : "r" (0));
+   asm ("mcr p15, 0, %0, c7, c10, 4" : : "r" (0));
+}
+
+static inline int bad_cache_range(unsigned long start, unsigned long stop)
+{
+   int ok = 1;
+
+   if (start & (CONFIG_SYS_CACHELINE_SIZE - 1))
+   ok = 0;
+
+   if (stop & (CONFIG_SYS_CACHELINE_SIZE - 1))
+   ok = 0;
+
+   if (!ok)
+   debug("CACHE: Misaligned operation at range [%08lx, %08lx]\n",
+   start, stop);
+
+   return ok;
+}
+
+void invalidate_dcache_range(unsigned long start, unsigned long stop)
+{
+   if (bad_cache_range(start, stop))
+   return;
+
+   while (start < stop) {
+   asm ("mcr p15, 0, %0, c7, c6, 1" : : "r" (start));
+   start += CONFIG_SYS_CACHELINE_SIZE;
+   }
+}
+
+void flush_dcache_range(unsigned long start, unsigned long stop)
+{
+   if (bad_cache_range(start, stop))
+   return;
+
+   while (start < stop) {
+   asm ("mcr p15, 0, %0, c7, c14, 1" : : "r" (start));
+   start += CONFIG_SYS_CACHELINE_SIZE;
+   }
+
+   asm ("mcr p15, 0, %0, c7, c10, 4" : : "r" (0));
+}
+
+void flush_cache(unsigned long start, unsigned long size)
+{
+   flush_dcache_range(start, start + size);
+}
+
+void enable_caches(void)
+{
+#ifndef CONFIG_SYS_ICACHE_OFF
+   icache_enable();
+#endif
+#ifndef CONFIG_SYS_DCACHE_OFF
+   dcache_enable();
+#endif
+}
+
+#else /* #ifndef CONFIG_SYS_DCACHE_OFF */
+void invalidate_dcache_all(void)
+{
+}
+
+void flush_dcache_all(void)
+{
+}
+
+void invalidate_dcache_range(unsigned long start, unsigned long stop)
+{
+}
+
+void flush_dcache_range(unsigned long start, unsigned long stop)
+{
+}
+
+void flush_cache(unsigned long start, unsigned long size)
+{
+}
+#endif /* #ifndef CONFIG_SYS_DCACHE_OFF */
-- 
1.7.5.4

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

[U-Boot] [PATCH V2 2/4] ARM: 926ejs: use debug() for misaligned addresses

[Stefano Babic]

Misaligned warnings are useful to debug faulty drivers.
A misaligned warning is printed also when the driver
is correct - use debug() instead of printf().

Signed-off-by: Stefano Babic 
CC: Albert Aribaud 
CC: Mike Frysinger 
CC: Marek Vasut 
---

Changes since V1:

This substitutes [PATCH 2/4] net: round up before calling flush_cache
- change warning in cache.c instead of fixing cmd_net.c
(M. Frysinger, M. Vasut)

 arch/arm/cpu/arm926ejs/cache.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/cpu/arm926ejs/cache.c b/arch/arm/cpu/arm926ejs/cache.c
index 5b23e3a..4430578 100644
--- a/arch/arm/cpu/arm926ejs/cache.c
+++ b/arch/arm/cpu/arm926ejs/cache.c
@@ -55,7 +55,7 @@ static int check_cache_range(unsigned long start, unsigned 
long stop)
ok = 0;
 
if (!ok)
-   printf("CACHE: Misaligned operation at range [%08lx, %08lx]\n",
+   debug("CACHE: Misaligned operation at range [%08lx, %08lx]\n",
start, stop);
 
return ok;
-- 
1.7.5.4

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

Re: [U-Boot] U-Boot build report @ Sat Mar 31 05:30:15 CEST 2012

[Tom Rini]

On Mon, Apr 02, 2012 at 06:10:18PM +0200, Marek Vasut wrote:
> Dear Tom Rini,
> 
> > On Sat, Mar 31, 2012 at 02:59:06PM +0200, Marek Vasut wrote:
> > > Hello guys,
> > > 
> > > we now have exactly these boards not building for -RC1, can you please
> > > look into
> > 
> > > it?:
> > [snip]
> > 
> > > arm/hawkboard   FAILED FOR: eldk4.2
> > > arm/hawkboard_uart  FAILED FOR: eldk4.2
> > 
> > SPL link failure.  Newer toolchains give us a built-in udelay, and we
> > provide __udelay but not udelay on these boards since we don't use
> > CONFIG_SPL_LIBGENERIC_SUPPORT and adding that in might be a fatal size
> > bloat.  Not sure what we want to do about this, and the last thread or
> > two about this was unresolved.
> 
> But we have --gc-sections and stuff like that so unneeded bloat should be 
> removed.

OK, in this case --gc-sections and how our code is structured work
together and a quick for each symbol in spl/libgeneric.o check of
spl/u-boot-spl shows nothing unneeded added with ELDK4.2 and with newer
toolchains nothing at all added.

> And it's not only this, I see also problem with lldiv.

Same thing, built-in vs not.

-- 
Tom


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

Re: [U-Boot] [PATCH V3 1/4] ARM1136: add cache flush and invalidate operations

[Marek Vasut]

Dear Stefano Babic,

> From: Anatolij Gustschin 
> 
> Since commit 5c1ad3e6f8ae578bbe30e09652f1531e9bc22031
> (net: fec_mxc: allow use with cache enabled) the FEC_MXC
> driver uses flush_dcache_range() and invalidate_dcache_range()
> functions. This driver is also configured for ARM1136 based
> 'flea3' and 'mx35pdk' boards which currently do not build
> as there are no ARM1136 specific flush_dcache_range() and
> invalidate_dcache_range() functions. Add various ARM1136
> cache functions to fix building for 'flea3' and 'mx35pdk'.
> 
> Signed-off-by: Anatolij Gustschin 
> Signed-off-by: Stefano Babic 
> Cc: Fabio Estevam 
> CC: Mike Frysinger 
> CC: Marek Vasut 
> ---
>  arch/arm/cpu/arm1136/cpu.c |   95
>  1 files changed, 95
> insertions(+), 0 deletions(-)
> 
> Changes since V2:
> - use debug instead of printf in case of misalignment (M. Frysinger, M.
> Vasut)
> 
> Changes since V1:
> 
> - use the same routine as in ARM926ejs to check range to easy detect
> misalignment (S. Babic) - cache are still disable - add enable_caches (S.
> Babic)

Acked-by: Marek Vasut 

> 
> diff --git a/arch/arm/cpu/arm1136/cpu.c b/arch/arm/cpu/arm1136/cpu.c
> index 2b91631..f2e30b5 100644
> --- a/arch/arm/cpu/arm1136/cpu.c
> +++ b/arch/arm/cpu/arm1136/cpu.c
> @@ -75,3 +75,98 @@ static void cache_flush(void)
>   asm ("mcr p15, 0, %0, c7, c7, 0": :"r" (i));  /* invalidate both caches
> and flush btb */ asm ("mcr p15, 0, %0, c7, c10, 4": :"r" (i)); /* mem
> barrier to sync things */ }
> +
> +#ifndef CONFIG_SYS_DCACHE_OFF
> +
> +#ifndef CONFIG_SYS_CACHELINE_SIZE
> +#define CONFIG_SYS_CACHELINE_SIZE32
> +#endif
> +
> +void invalidate_dcache_all(void)
> +{
> + asm ("mcr p15, 0, %0, c7, c6, 0" : : "r" (0));
> +}
> +
> +void flush_dcache_all(void)
> +{
> + asm ("mcr p15, 0, %0, c7, c10, 0" : : "r" (0));
> + asm ("mcr p15, 0, %0, c7, c10, 4" : : "r" (0));
> +}
> +
> +static inline int bad_cache_range(unsigned long start, unsigned long stop)
> +{
> + int ok = 1;
> +
> + if (start & (CONFIG_SYS_CACHELINE_SIZE - 1))
> + ok = 0;
> +
> + if (stop & (CONFIG_SYS_CACHELINE_SIZE - 1))
> + ok = 0;
> +
> + if (!ok)
> + debug("CACHE: Misaligned operation at range [%08lx, %08lx]\n",
> + start, stop);
> +
> + return ok;
> +}
> +
> +void invalidate_dcache_range(unsigned long start, unsigned long stop)
> +{
> + if (bad_cache_range(start, stop))
> + return;
> +
> + while (start < stop) {
> + asm ("mcr p15, 0, %0, c7, c6, 1" : : "r" (start));
> + start += CONFIG_SYS_CACHELINE_SIZE;
> + }
> +}
> +
> +void flush_dcache_range(unsigned long start, unsigned long stop)
> +{
> + if (bad_cache_range(start, stop))
> + return;
> +
> + while (start < stop) {
> + asm ("mcr p15, 0, %0, c7, c14, 1" : : "r" (start));
> + start += CONFIG_SYS_CACHELINE_SIZE;
> + }
> +
> + asm ("mcr p15, 0, %0, c7, c10, 4" : : "r" (0));
> +}
> +
> +void flush_cache(unsigned long start, unsigned long size)
> +{
> + flush_dcache_range(start, start + size);
> +}
> +
> +void enable_caches(void)
> +{
> +#ifndef CONFIG_SYS_ICACHE_OFF
> + icache_enable();
> +#endif
> +#ifndef CONFIG_SYS_DCACHE_OFF
> + dcache_enable();
> +#endif
> +}
> +
> +#else /* #ifndef CONFIG_SYS_DCACHE_OFF */
> +void invalidate_dcache_all(void)
> +{
> +}
> +
> +void flush_dcache_all(void)
> +{
> +}
> +
> +void invalidate_dcache_range(unsigned long start, unsigned long stop)
> +{
> +}
> +
> +void flush_dcache_range(unsigned long start, unsigned long stop)
> +{
> +}
> +
> +void flush_cache(unsigned long start, unsigned long size)
> +{
> +}
> +#endif /* #ifndef CONFIG_SYS_DCACHE_OFF */
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2 2/4] ARM: 926ejs: use debug() for misaligned addresses

[Marek Vasut]

Dear Stefano Babic,

> Misaligned warnings are useful to debug faulty drivers.
> A misaligned warning is printed also when the driver
> is correct - use debug() instead of printf().
> 
> Signed-off-by: Stefano Babic 
> CC: Albert Aribaud 
> CC: Mike Frysinger 
> CC: Marek Vasut 

Acked-by: Marek Vasut 

> ---
> 
> Changes since V1:
> 
> This substitutes [PATCH 2/4] net: round up before calling flush_cache
> - change warning in cache.c instead of fixing cmd_net.c
>   (M. Frysinger, M. Vasut)
> 
>  arch/arm/cpu/arm926ejs/cache.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/cpu/arm926ejs/cache.c
> b/arch/arm/cpu/arm926ejs/cache.c index 5b23e3a..4430578 100644
> --- a/arch/arm/cpu/arm926ejs/cache.c
> +++ b/arch/arm/cpu/arm926ejs/cache.c
> @@ -55,7 +55,7 @@ static int check_cache_range(unsigned long start,
> unsigned long stop) ok = 0;
> 
>   if (!ok)
> - printf("CACHE: Misaligned operation at range [%08lx, %08lx]\n",
> + debug("CACHE: Misaligned operation at range [%08lx, %08lx]\n",
>   start, stop);
> 
>   return ok;

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

Re: [U-Boot] U-Boot build report @ Sat Mar 31 05:30:15 CEST 2012

[Marek Vasut]

Dear Tom Rini,

> On Mon, Apr 02, 2012 at 06:10:18PM +0200, Marek Vasut wrote:
> > Dear Tom Rini,
> > 
> > > On Sat, Mar 31, 2012 at 02:59:06PM +0200, Marek Vasut wrote:
> > > > Hello guys,
> > > > 
> > > > we now have exactly these boards not building for -RC1, can you
> > > > please look into
> > > 
> > > > it?:
> > > [snip]
> > > 
> > > > arm/hawkboard   FAILED FOR: eldk4.2
> > > > arm/hawkboard_uart  FAILED FOR: eldk4.2
> > > 
> > > SPL link failure.  Newer toolchains give us a built-in udelay, and we
> > > provide __udelay but not udelay on these boards since we don't use
> > > CONFIG_SPL_LIBGENERIC_SUPPORT and adding that in might be a fatal size
> > > bloat.  Not sure what we want to do about this, and the last thread or
> > > two about this was unresolved.
> > 
> > But we have --gc-sections and stuff like that so unneeded bloat should be
> > removed.
> 
> OK, in this case --gc-sections and how our code is structured work
> together and a quick for each symbol in spl/libgeneric.o check of
> spl/u-boot-spl shows nothing unneeded added with ELDK4.2 and with newer
> toolchains nothing at all added.
> 
> > And it's not only this, I see also problem with lldiv.
> 
> Same thing, built-in vs not.

So I can expect a patch?

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 v8] usb: align buffers at cacheline

[Marek Vasut]

Dear Tom Warren,

> Marek,
> 
> > -Original Message-
> > From: Marek Vasut [mailto:ma...@denx.de]
> > Sent: Monday, April 02, 2012 9:12 AM
> > To: Tom Warren
> > Cc: Puneet Saxena; Mike Frysinger; u-boot@lists.denx.de;
> > s...@chromium.org; li...@bohmer.net; tr...@ti.com;
> > albert.u.b...@aribaud.net
> > Subject: Re: [PATCH v8] usb: align buffers at cacheline
> > 
> > Dear Tom Warren,
> > 
> > > Marek, Puneet, et al.,
> > > 
> > > > -Original Message-
> > > > From: Marek Vasut [mailto:ma...@denx.de]
> > > > Sent: Monday, March 19, 2012 8:47 AM
> > > > To: Tom Warren
> > > > Cc: Puneet Saxena; Mike Frysinger; u-boot@lists.denx.de;
> > > > s...@chromium.org; li...@bohmer.net; tr...@ti.com;
> > > > albert.u.b...@aribaud.net
> > > > Subject: Re: [PATCH v8] usb: align buffers at cacheline
> > > > 
> > > > Dear Tom Warren,
> > > > 
> > > > > Marek,
> > > > > 
> > > > > > -Original Message-
> > > > > > From: Marek Vasut [mailto:marek.va...@gmail.com]
> > > > > > Sent: Monday, March 19, 2012 7:43 AM
> > > > > > To: Puneet Saxena
> > > > > > Cc: Mike Frysinger; u-boot@lists.denx.de; s...@chromium.org;
> > > > > > li...@bohmer.net; tr...@ti.com; Tom Warren
> > > > > > Subject: Re: [PATCH v8] usb: align buffers at cacheline
> > > > > > 
> > > > > > Dear Puneet Saxena,
> > > > > > 
> > > > > > > Hi Marek,
> > > > > > > I adapted my patch for git://git.denx.de/u-boot-usb.git master
> > > > > > > branch. As the build for target "Seaboard" is broken once I
> > > > > > > enable USB in Seaboard.h, I am unable to test my changes on "u-
> > 
> > boot-usb".
> > 
> > > > > > u-boot-usb is forked off the mainline u-boot.git ... tegra stuff
> > > > > > likely isn't pulled there. Simon, can you tell me when this is
> > > > > > gonna be
> > > > 
> > > > there?
> > > > 
> > > > > Simon's USB/fdt patch set will be pulled into -arm first, then
> > > > > -main, when he adapts the 'panic' putc patchset (implement
> > > > > pre-console putc for fdt
> > > > > warning) to meet with Wolfgang's approval. Once that's done
> > > > > (hopefully early this week), I can submit another pull request to
> > > > > finally get this series in.
> > > > > 
> > > > > Simon - can we have an ETA?
> > > > 
> > > > I'd love to see some ETA on u-boot-arm push from Albert Aribaud :-(
> > > > Albert, how're you doing ?
> > > > 
> > > > Thanks!
> > > 
> > > u-boot-tegra/master has the fdt/USB patches, and has been pulled into
> > > ARM master.
> > > 
> > > We need the cacheline/buffer alignment patch now, to remove the
> > > volcanic spew whenever you do any USB commands.
> > > 
> > > Can you guys (Puneet & Marek, and Mike/Simon if necessary) work
> > > together to get this in soon?
> > 
> > Ain't you gonna help us? I believe the patch is really close to be
> > usable, it just needs some easy debugging, won't you volunteer, it'd
> > really help? :)
> 
> I can apply the latest patch (v8?) and see how much spew is still present,
> but I (a) have no expertise in cache/USB issues and (b) have a ton of
> patches to apply/push for Tegra2 and (as soon as those are in) Tegra3, so
> my BW is limited, and finally (c) this is Puneet's work, and I'd like to
> see him complete it (with help from the list).

Well, everyone does. And that's how FOSS works -- you scratch your own itch by 
sending a patch, thus helping everyone else ;-)

And hey, my boards don't have caches enabled (yet) so this is low-prio for me. 
Sure, if someone has this as a high-prio thing, patch is very welcome :)

> 
> Tom
> 
> > > Thanks,
> > > 
> > > Tom
> > > 
> > > > > Tom
> > > > > 
> > > > > > > I would have to merge lots of changes from "denx-uboot-tegra"
> > > > > > > to make it working for "u-boot-usb.git" master branch.
> > > > > > > I can send the adapted patch if it's needed.
> > > > > > 
> > > > > > The problem I see is that there are important USB patches in
> > > > > > mainline, though they are not in -tegra. So the approach I'd
> > > > > > take if I were you would be to rebase -tegra atop of mainline
> > > > > > for yourself and then apply your patch. Does that work for you?
> > > > > > 
> > > > > > > Thanks,
> > > > > > > Puneet
> > > > > > 
> > > > > > Thanks!
> > > > > > 
> > > > > > Best regards,
> > > > > > Marek Vasut
> > > > 
> > > > Best regards,
> > > > Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] hawkboard: Add CONFIG_SPL_LIBGENERIC_SUPPORT

[Tom Rini]

With older toolchains we need CONFIG_SPL_LIBGENERIC_SUPPORT in order for
CONFIG_SPL_NAND_SUPPORT to link.

Signed-off-by: Tom Rini 
---
 include/configs/hawkboard.h |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/include/configs/hawkboard.h b/include/configs/hawkboard.h
index 50a1c17..0859371 100644
--- a/include/configs/hawkboard.h
+++ b/include/configs/hawkboard.h
@@ -62,6 +62,7 @@
 #define CONFIG_SPL_NAND_SUPPORT
 #define CONFIG_SPL_NAND_SIMPLE
 #define CONFIG_SPL_NAND_LOAD
+#define CONFIG_SPL_LIBGENERIC_SUPPORT  /* for udelay and __div64_32 for NAND */
 #define CONFIG_SPL_SERIAL_SUPPORT
 #define CONFIG_SPL_LDSCRIPT"board/$(BOARDDIR)/u-boot-spl-hawk.lds"
 #define CONFIG_SPL_TEXT_BASE   0xc108
-- 
1.7.0.4

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

Re: [U-Boot] MMC0: DMA transfer failed

[Marek Vasut]

Dear Fabio Estevam,

> On Mon, Apr 2, 2012 at 11:41 AM, Marek Vasut  wrote:
> > No, it means I might just have a good card and I didn't notice this. I
> > really do need to get some crappy (new) cards to track down these
> > issues. Fabio, can you please try debugging this?
> 
> Ok, I am debugging this.
> 
> What do you think about the change below?
> 
> --- a/drivers/mmc/mxsmmc.c
> +++ b/drivers/mmc/mxsmmc.c
> @@ -191,7 +191,7 @@ mxsmmc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd,
> struct else
> cache_data_count = data_count;
> 
> -   if (data->flags & MMC_DATA_READ) {
> +   if (data->flags & MMC_DATA_WRITE) {
> priv->desc->cmd.data = MXS_DMA_DESC_COMMAND_DMA_WRITE;
> priv->desc->cmd.address = (dma_addr_t)data->dest;
> } else {
> 
> It doesn't fix this issue, but it seems correct.

No it's not, when you do SD READ, you read the data into the dest buffer.

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] Adds driver for Xilinx' xps_spi SPI controller.

[Marek Vasut]

Dear Graeme Smecher,

> Hi Marek,
> 
> On 31/03/12 12:42 PM, Marek Vasut wrote:
> > Dear Graeme Smecher,
> > 
> >> Hi Wolfgang,
> >> 
> >> On 18/09/10 01:02 PM, Wolfgang Denk wrote:
> >>> Dear Graeme Smecher,
> >>> 
> >>> In
> >>> message<1280955847-2999-1-git-send-email-graeme.smec...@mail.mcgill.ca
> >>> >
> > 
> > you wrote:
>  This code differs in only trivial ways from the altera_spi driver. It
>  plays nice with Thomas Chou's mmc_spi driver, as well as with SPI
>  flash.
> >>> 
> >>> Hm... if the core really differs in only trivial ways from the
> >>> altera_spi driver, then why do we need a duplication of that code?
> >>> 
> >>> Can we plase have a single driver source that supports both instead?
> >> 
> >> Hm... It's possible to combine xilinx_spi.c and altera_spi.c. However, I
> >> suspect joining them will make maintenance more complicated rather than
> >> simpler. I can't, for example, test a combined driver on Altera hardware
> >> (and the Altera maintainer will likely have the same problem with Xilinx
> >> hardware.)
> >> 
> >> My guess is that most SPI interfaces are nearly identical at a register
> >> level, especially for drivers that don't support interrupts and other
> >> complications. (See mxc_spi.c for another example.) Xilinx and Altera's
> >> SPI interfaces are just two examples that happen to both be FPGA-based
> >> -- I could probably have adapted any of the other SPI drivers instead.
> >> 
> >> Are you sure combining drivers is the most logical approach? Let me
> >> know, and I'll have a crack at it.
> >> 
> >> thanks,
> >> Graeme
> > 
> > What was the conclusion here? Shall I drop the patch or will you submit a
> > rebased version?
> 
> Please drop the patch for now, since I'm not in a position to maintain
> it. The trail of bread-crumbs on the mailing list is a good compromise
> until someone (me, later on?) steps up.

Sorry to hear that, though thanks for updating me on the situation :)

> thanks,
> Graeme

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] Prevent malloc with size 0

[Marek Vasut]

Dear Joakim Tjernlund,

> Marek Vasut  wrote on 2012/04/02 17:23:03:
> > Dear Joakim Tjernlund,
> > 
> > > Marek Vasut  wrote on 2012/04/02 16:42:30:
> > > > Dear Joakim Tjernlund,
> > > > 
> > > > > Marek Vasut  wrote on 2012/04/02 16:05:13:
> > > > > > Dear Joakim Tjernlund,
> > > > > > 
> > > > > > > Hi Grame
> > > > > > > 
> > > > > > > Graeme Russ  wrote on 2012/04/02 09:17:44:
> > > > > > > > Hi Joakim,
> > > > > > > > 
> > > > > > > > On Apr 2, 2012 4:55 PM, "Joakim Tjernlund"
> > > > > > > > 
> > > > > > 
> > > > > > wrote:
> > > > > > > > > > Hi Marek,
> > > > > > > > > > 
> > > > > > > > > > On Mon, Apr 2, 2012 at 1:36 PM, Marek Vasut
> > > > > > > > > > 
> > > > > > 
> > > > > > wrote:
> > > > > > > > > > > Dear Mike Frysinger,
> > > > > > > > > > > 
> > > > > > > > > > >> On Sunday 01 April 2012 20:25:44 Graeme Russ wrote:
> > > > > > > > > > >> > b) The code calling malloc(0) is making a perfectly
> > > > > > > > > > >> > legitimate assumption
> > > > > > > > > > >> > 
> > > > > > > > > > >> >based on how glibc handles malloc(0)
> > > > > > > > > > >> 
> > > > > > > > > > >> not really.  POSIX says malloc(0) is implementation
> > > > > > > > > > >> defined (so it may return a unique address, or it may
> > > > > > > > > > >> return NULL). no userspace code assuming malloc(0)
> > > > > > > > > > >> will return non-NULL is correct.
> > > > > > > > > > > 
> > > > > > > > > > > Which is your implementation-defined ;-) But I have to
> > > > > > > > > > > agree with this one. So my vote is for returning NULL.
> > > > > > > > > > 
> > > > > > > > > > Also, no userspace code assuming malloc(0) will return
> > > > > > > > > > NULL is correct
> > > > > > > > > > 
> > > > > > > > > > Point being, no matter which implementation is chosen, it
> > > > > > > > > > is up to the caller to not assume that the choice that
> > > > > > > > > > was made was, in fact, the choice that was made.
> > > > > > > > > > 
> > > > > > > > > > I.e. the behaviour of malloc(0) should be able to be
> > > > > > > > > > changed on a whim with no side-effects
> > > > > > > > > > 
> > > > > > > > > > So I think I should change my vote to returning NULL for
> > > > > > > > > > one reason and one reason only - It is faster during
> > > > > > > > > > run-time
> > > > > > > > > 
> > > > > > > > > Then u-boot will be incompatible with both glibc and the
> > > > > > > > > linux kernel, it seems
> > > > > > > > 
> > > > > > > > Forget aboug other implementations...
> > > > > > > > What matters is that the fact that the behaviour is undefined
> > > > > > > > and it is up to the caller to take that into account
> > > > > > > 
> > > > > > > Well, u-boot borrows code from both kernel and user space so it
> > > > > > > would make sense if malloc(0) behaved the same. Especially for
> > > > > > > kernel code which tend to depend on the kernels impl.(just look
> > > > > > > at Scotts example)
> > > > > > > 
> > > > > > > > > to me that any modern impl. of malloc(0) will return a non
> > > > > > > > > NULL ptr.
> > > > > > > > > 
> > > > > > > > > It does need to be slower, just return ~0 instead, the
> > > > > > > > > kernel does something similar: if (!size)
> > > > > > > > > 
> > > > > > > > > return ZERO_SIZE_PTR;
> > > > > > > > 
> > > > > > > > That could work, but technically I don't think it complies as
> > > > > > > > it is not a pointer to allocated memory...
> > > > > > > 
> > > > > > > It doesn't not have to be allocated memory, just a ptr != NULL
> > > > > > > which you can do free() on.
> > > > > > 
> > > > > > But kernel has something mapped there to trap these pointers I
> > > > > > believe.
> > > > > 
> > > > > So? That only means that the kernel has extra protection if someone
> > > > > tries to deference such a ptr. You are not required to do that(nice
> > > > > to have though) You don have any protection for deferencing NULL
> > > > > either I think?
> > > > 
> > > > Can't GCC track it?
> > > 
> > > Track what? NULL ptrs? I don't think so. Possibly when you have a
> > > static NULL ptr but not in the general case.
> > 
> > Well of course.
> 
> What did you mean then with "Can't GCC track it?" then? Just a bad joke?

Never mind, didn't finish my train of thought.

> > > I am getting tired of this discussion now. I am just trying to tell you
> > > that no sane impl. of malloc() these days return NULL for malloc(0).
> > 
> > And I got your point. Though for u-boot, this would be the best solution
> > actually. Anyone who uses memory allocated by malloc(0) is insane.
> 
> No, you don't get the point. If you did you would not have have made the
> "insane" remark.

No, relying on malloc(0) returning something sane is messed up.

> > > Even
> > > though standards allow it they don't consider malloc(0) an error, glibc
> > > will not update errno in this case.
> > 
> > There's no errno in uboot I'm aware of ;-)
> 
> Just pointing out that malloc(0) is not an error even if malloc returns
> NULL in glibc/standards. malloc(0) represe

Re: [U-Boot] [PATCH] hawkboard: Add CONFIG_SPL_LIBGENERIC_SUPPORT

[Sughosh Ganu]

On Mon Apr 02, 2012 at 09:33:43AM -0700, Tom Rini wrote:
> With older toolchains we need CONFIG_SPL_LIBGENERIC_SUPPORT in order for
> CONFIG_SPL_NAND_SUPPORT to link.
> 
> Signed-off-by: Tom Rini 
> ---
>  include/configs/hawkboard.h |1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/include/configs/hawkboard.h b/include/configs/hawkboard.h
> index 50a1c17..0859371 100644
> --- a/include/configs/hawkboard.h
> +++ b/include/configs/hawkboard.h
> @@ -62,6 +62,7 @@
>  #define CONFIG_SPL_NAND_SUPPORT
>  #define CONFIG_SPL_NAND_SIMPLE
>  #define CONFIG_SPL_NAND_LOAD
> +#define CONFIG_SPL_LIBGENERIC_SUPPORT/* for udelay and __div64_32 
> for NAND */
>  #define CONFIG_SPL_SERIAL_SUPPORT
>  #define CONFIG_SPL_LDSCRIPT  "board/$(BOARDDIR)/u-boot-spl-hawk.lds"
>  #define CONFIG_SPL_TEXT_BASE 0xc108

 Simon is adding this as part of the common relocation support patch
 series. I think he was going to send an updated version.

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

Re: [U-Boot] [PATCH] hawkboard: Add CONFIG_SPL_LIBGENERIC_SUPPORT

[Tom Rini]

On Mon, Apr 02, 2012 at 10:10:57PM +0530, Sughosh Ganu wrote:
> On Mon Apr 02, 2012 at 09:33:43AM -0700, Tom Rini wrote:
> > With older toolchains we need CONFIG_SPL_LIBGENERIC_SUPPORT in order for
> > CONFIG_SPL_NAND_SUPPORT to link.
> > 
> > Signed-off-by: Tom Rini 
> > ---
> >  include/configs/hawkboard.h |1 +
> >  1 files changed, 1 insertions(+), 0 deletions(-)
> > 
> > diff --git a/include/configs/hawkboard.h b/include/configs/hawkboard.h
> > index 50a1c17..0859371 100644
> > --- a/include/configs/hawkboard.h
> > +++ b/include/configs/hawkboard.h
> > @@ -62,6 +62,7 @@
> >  #define CONFIG_SPL_NAND_SUPPORT
> >  #define CONFIG_SPL_NAND_SIMPLE
> >  #define CONFIG_SPL_NAND_LOAD
> > +#define CONFIG_SPL_LIBGENERIC_SUPPORT  /* for udelay and __div64_32 
> > for NAND */
> >  #define CONFIG_SPL_SERIAL_SUPPORT
> >  #define CONFIG_SPL_LDSCRIPT
> > "board/$(BOARDDIR)/u-boot-spl-hawk.lds"
> >  #define CONFIG_SPL_TEXT_BASE   0xc108
> 
>  Simon is adding this as part of the common relocation support patch
>  series. I think he was going to send an updated version.

Well, this is broken in mainline today so I don't want to wait.

-- 
Tom


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

Re: [U-Boot] [PATCH V2] Adds driver for Xilinx' xps_spi SPI controller.

[Graeme Smecher]

Hi Marek,

On 31/03/12 12:42 PM, Marek Vasut wrote:

Dear Graeme Smecher,


Hi Wolfgang,

On 18/09/10 01:02 PM, Wolfgang Denk wrote:

Dear Graeme Smecher,

In message<1280955847-2999-1-git-send-email-graeme.smec...@mail.mcgill.ca>

you wrote:

This code differs in only trivial ways from the altera_spi driver. It
plays nice with Thomas Chou's mmc_spi driver, as well as with SPI
flash.

Hm... if the core really differs in only trivial ways from the
altera_spi driver, then why do we need a duplication of that code?

Can we plase have a single driver source that supports both instead?

Hm... It's possible to combine xilinx_spi.c and altera_spi.c. However, I
suspect joining them will make maintenance more complicated rather than
simpler. I can't, for example, test a combined driver on Altera hardware
(and the Altera maintainer will likely have the same problem with Xilinx
hardware.)

My guess is that most SPI interfaces are nearly identical at a register
level, especially for drivers that don't support interrupts and other
complications. (See mxc_spi.c for another example.) Xilinx and Altera's
SPI interfaces are just two examples that happen to both be FPGA-based
-- I could probably have adapted any of the other SPI drivers instead.

Are you sure combining drivers is the most logical approach? Let me
know, and I'll have a crack at it.

thanks,
Graeme

What was the conclusion here? Shall I drop the patch or will you submit a
rebased version?


Please drop the patch for now, since I'm not in a position to maintain 
it. The trail of bread-crumbs on the mailing list is a good compromise 
until someone (me, later on?) steps up.


thanks,
Graeme

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

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

[Tom Rini]

Hello,

The following changes since commit 37ee186fde3c48f90121a76e5039efe534a273f3:
  Ian Campbell (1):
ARM: dreamplug: Enable FDT support

are available in the git repository at:

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

Aneesh V (6):
  arm: adapt asm/linkage.h from Linux
  armv7: add appropriate headers for assembly functions
  ARM: enable Thumb build
  armv7: Use -march=armv7-a and thereby enable Thumb-2
  omap4+: Avoid using __attribute__ ((__packed__))
  OMAP4: enable Thumb build

Balaji T K (3):
  arm: omap5: correct boot device mode7 for eMMC
  omap5: pbias ldo9 turn on
  mmc: omap5evm: Add eMMC saveenv support

Enric Balletb?? i Serra (1):
  OMAP3: igep00x0: Reduce lines of code for IGEP-based boards.

Grazvydas Ignotas (3):
  OMAP3: pandora: pin mux updates for DM3730 board variant
  OMAP3: pandora: revise GPIO configuration
  OMAP3: pandora: drop console kernel argument

Jonathan Solnit (1):
  ARM:OMAP+:MMC: Add parameters to MMC init

Nishanth Menon (3):
  OMAP3+: Introduce generic logic for OMAP voltage controller
  OMAP4460: TPS Ensure SET1 is selected after voltage configuration
  OMAP4: scale voltage of core before MPU scales

SRICHARAN R (16):
  OMAP5: clocks: Change clock settings as required for ES1.0 silicon.
  OMAP5: board: Add pinmux data for omap5_evm board.
  OMAP5: io: Configure the io settings for omap5430 sevm board.
  OMAP5: emif/ddr: Change emif settings as required for ES1.0 silicon.
  OMAP5: palmas: Configure nominal opp vdd values
  OMAP5: hwinit: Add the missing break statement
  OMAP4/5: Make the silicon revision variable common.
  OMAP5: SRAM: Change the SRAM base address.
  OMAP4/5: Make the sysctrl structure common
  OMAP4/5: device: Add support to get the device type.
  OMAP5: defconfig: Align the defconfig for 5430 ES1.0
  OMAP5: ddr: Change the ddr device name.
  OMAP4/5: emif: Correct the emif power mgt shadow register bit fields.
  power: twl6035: add palmas PMIC support
  OMAP3+: reset: Create a common reset layer.
  OMAP5: reset: Use cold reset in case of 5430ES1.0

Tom Rini (2):
  tools, config.mk: Add gcc-version.sh, cc-version test from Linux
  Makefile: Add a 'checkthumb' rule

 Makefile   |7 +
 README |8 +
 arch/arm/config.mk |   27 +-
 arch/arm/cpu/armv7/am33xx/board.c  |2 +-
 arch/arm/cpu/armv7/config.mk   |7 +-
 arch/arm/cpu/armv7/mx5/lowlevel_init.S |5 +-
 arch/arm/cpu/armv7/mx6/lowlevel_init.S |5 +-
 arch/arm/cpu/armv7/omap-common/Makefile|1 +
 arch/arm/cpu/armv7/omap-common/clocks-common.c |   99 ++---
 arch/arm/cpu/armv7/omap-common/emif-common.c   |   41 ++-
 arch/arm/cpu/armv7/omap-common/hwinit-common.c |6 +-
 arch/arm/cpu/armv7/omap-common/lowlevel_init.S |   14 +-
 .../arm/cpu/armv7/omap-common/{reset.S => reset.c} |   30 +-
 arch/arm/cpu/armv7/omap-common/spl.c   |1 +
 arch/arm/cpu/armv7/omap-common/spl_mmc.c   |5 +-
 arch/arm/cpu/armv7/omap-common/vc.c|  138 ++
 arch/arm/cpu/armv7/omap3/lowlevel_init.S   |   41 +-
 arch/arm/cpu/armv7/omap4/clocks.c  |   77 ++-
 arch/arm/cpu/armv7/omap4/hwinit.c  |   24 +-
 arch/arm/cpu/armv7/omap4/sdram_elpida.c|4 +
 arch/arm/cpu/armv7/omap5/Makefile  |2 +-
 arch/arm/cpu/armv7/omap5/clocks.c  |  143 --
 arch/arm/cpu/armv7/omap5/hwinit.c  |  104 -
 .../cpu/armv7/omap5/{sdram_elpida.c => sdram.c}|  101 +++--
 arch/arm/cpu/armv7/s5pc1xx/cache.S |   10 +-
 arch/arm/cpu/armv7/s5pc1xx/reset.S |5 +-
 arch/arm/cpu/armv7/start.S |   13 +-
 arch/arm/cpu/armv7/tegra2/lowlevel_init.S  |5 +-
 arch/arm/cpu/armv7/u8500/lowlevel.S|9 +-
 arch/arm/include/asm/arch-am33xx/mmc_host_def.h|2 +-
 arch/arm/include/asm/arch-omap3/cpu.h  |5 +-
 arch/arm/include/asm/arch-omap3/mmc_host_def.h |8 +-
 arch/arm/include/asm/arch-omap3/mux.h  |6 +
 arch/arm/include/asm/arch-omap4/clocks.h   |   18 +-
 arch/arm/include/asm/arch-omap4/cpu.h  |   11 +
 arch/arm/include/asm/arch-omap4/mmc_host_def.h |2 +-
 arch/arm/include/asm/arch-omap4/mux_omap4.h|2 +-
 arch/arm/include/asm/arch-omap4/omap.h |   25 +-
 arch/arm/include/asm/arch-omap4/sys_proto.h|8 +-
 arch/arm/include/asm/arch-omap5/clocks.h   |   52 ++-
 arch/arm/include/asm/arch-omap5/cpu.h  |   11 +
 arch/arm/include/asm/arch-omap5/mmc_host_def.h |2 +-
 arch/arm/include/asm/arch-omap5/mux_omap5.h|  504 ++

Re: [U-Boot] [PATCH V3 1/4] ARM1136: add cache flush and invalidate operations

[Stefano Babic]

On 02/04/2012 18:18, Stefano Babic wrote:
> From: Anatolij Gustschin 
> 
> Since commit 5c1ad3e6f8ae578bbe30e09652f1531e9bc22031
> (net: fec_mxc: allow use with cache enabled) the FEC_MXC
> driver uses flush_dcache_range() and invalidate_dcache_range()
> functions. This driver is also configured for ARM1136 based
> 'flea3' and 'mx35pdk' boards which currently do not build
> as there are no ARM1136 specific flush_dcache_range() and
> invalidate_dcache_range() functions. Add various ARM1136
> cache functions to fix building for 'flea3' and 'mx35pdk'.
> 
> Signed-off-by: Anatolij Gustschin 
> Signed-off-by: Stefano Babic 
> Cc: Fabio Estevam 
> CC: Mike Frysinger 
> CC: Marek Vasut 
> ---

Applied to u-boot-imx (fix), thanks.

Best regards,
Stefano Babic

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

Re: [U-Boot] [PATCH 1/2] Build u-boot.imx by default when board uses it

[Stefano Babic]

On 11/11/2011 14:26, Loïc Minier wrote:
> On Fri, Nov 11, 2011, Daniel Schwierzeck wrote:
>> ALL-$(CONFIG_UBOOT_IMG) += $(obj)u-boot.img
>> ALL-$(CONFIG_UBOOT_IMX) += $(obj)u-boot.imx
>> ALL-$(CONFIG_UBOOT_KWB) += $(obj)u-boot.kwb
>>
>> then you can define CONFIG_UBOOT_KWB or CONFIG_UBOOT_IMX in your
>> board config if needed
> 
>  That'd be a fine solution for me if others agree it's the right
>  approach; ideally, we would even set CONFIG_UBOOT_IMX when
>  CONFIG_IMX_CONFIG is set (not sure where though).

Sorry to bring a dead thread to new life...

The issue is not yet solved and I am asking if we can do something for
the incoming release 2012.04. I would prefer we do not add a new switch
CONFIG_UBOOT_IMX into the configuration file, because it is possible to
have the same u-boot image running on different storages, for example on
NAND or NOR, and they have different offsets. This means different
imximage (header), while u-boot itself (binary) remains the same. So
this information should be not interpreted by the compiler.

Rereading the thread a major point is that we must not change the main
Makefile. What about if the changes suggested in the patch are put into
arch/arm/cpu/armv7/config.mk ?

Best regards,
Stefano Babic

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

Re: [U-Boot] [PATCH] Prevent malloc with size 0

[Joakim Tjernlund]

Marek Vasut  wrote on 2012/04/02 18:39:33:
> From: Marek Vasut 
>
> Dear Joakim Tjernlund,
>
> > Marek Vasut  wrote on 2012/04/02 17:23:03:
> > > Dear Joakim Tjernlund,
> > >
> > > > Marek Vasut  wrote on 2012/04/02 16:42:30:
> > > > > Dear Joakim Tjernlund,
> > > > >
> > > > > > Marek Vasut  wrote on 2012/04/02 16:05:13:
> > > > > > > Dear Joakim Tjernlund,
> > > > > > >
> > > > > > > > Hi Grame
> > > > > > > >
> > > > > > > > Graeme Russ  wrote on 2012/04/02 
> > > > > > > > 09:17:44:
> > > > > > > > > Hi Joakim,
> > > > > > > > >
> > > > > > > > > On Apr 2, 2012 4:55 PM, "Joakim Tjernlund"
> > > > > > > > > 
> > > > > > >
> > > > > > > wrote:
> > > > > > > > > > > Hi Marek,
> > > > > > > > > > >
> > > > > > > > > > > On Mon, Apr 2, 2012 at 1:36 PM, Marek Vasut
> > > > > > > > > > > 
> > > > > > >
> > > > > > > wrote:
> > > > > > > > > > > > Dear Mike Frysinger,
> > > > > > > > > > > >
> > > > > > > > > > > >> On Sunday 01 April 2012 20:25:44 Graeme Russ wrote:
> > > > > > > > > > > >> > b) The code calling malloc(0) is making a perfectly
> > > > > > > > > > > >> > legitimate assumption
> > > > > > > > > > > >> >
> > > > > > > > > > > >> >based on how glibc handles malloc(0)
> > > > > > > > > > > >>
> > > > > > > > > > > >> not really.  POSIX says malloc(0) is implementation
> > > > > > > > > > > >> defined (so it may return a unique address, or it may
> > > > > > > > > > > >> return NULL). no userspace code assuming malloc(0)
> > > > > > > > > > > >> will return non-NULL is correct.
> > > > > > > > > > > >
> > > > > > > > > > > > Which is your implementation-defined ;-) But I have to
> > > > > > > > > > > > agree with this one. So my vote is for returning NULL.
> > > > > > > > > > >
> > > > > > > > > > > Also, no userspace code assuming malloc(0) will return
> > > > > > > > > > > NULL is correct
> > > > > > > > > > >
> > > > > > > > > > > Point being, no matter which implementation is chosen, it
> > > > > > > > > > > is up to the caller to not assume that the choice that
> > > > > > > > > > > was made was, in fact, the choice that was made.
> > > > > > > > > > >
> > > > > > > > > > > I.e. the behaviour of malloc(0) should be able to be
> > > > > > > > > > > changed on a whim with no side-effects
> > > > > > > > > > >
> > > > > > > > > > > So I think I should change my vote to returning NULL for
> > > > > > > > > > > one reason and one reason only - It is faster during
> > > > > > > > > > > run-time
> > > > > > > > > >
> > > > > > > > > > Then u-boot will be incompatible with both glibc and the
> > > > > > > > > > linux kernel, it seems
> > > > > > > > >
> > > > > > > > > Forget aboug other implementations...
> > > > > > > > > What matters is that the fact that the behaviour is undefined
> > > > > > > > > and it is up to the caller to take that into account
> > > > > > > >
> > > > > > > > Well, u-boot borrows code from both kernel and user space so it
> > > > > > > > would make sense if malloc(0) behaved the same. Especially for
> > > > > > > > kernel code which tend to depend on the kernels impl.(just look
> > > > > > > > at Scotts example)
> > > > > > > >
> > > > > > > > > > to me that any modern impl. of malloc(0) will return a non
> > > > > > > > > > NULL ptr.
> > > > > > > > > >
> > > > > > > > > > It does need to be slower, just return ~0 instead, the
> > > > > > > > > > kernel does something similar: if (!size)
> > > > > > > > > >
> > > > > > > > > > return ZERO_SIZE_PTR;
> > > > > > > > >
> > > > > > > > > That could work, but technically I don't think it complies as
> > > > > > > > > it is not a pointer to allocated memory...
> > > > > > > >
> > > > > > > > It doesn't not have to be allocated memory, just a ptr != NULL
> > > > > > > > which you can do free() on.
> > > > > > >
> > > > > > > But kernel has something mapped there to trap these pointers I
> > > > > > > believe.
> > > > > >
> > > > > > So? That only means that the kernel has extra protection if someone
> > > > > > tries to deference such a ptr. You are not required to do that(nice
> > > > > > to have though) You don have any protection for deferencing NULL
> > > > > > either I think?
> > > > >
> > > > > Can't GCC track it?
> > > >
> > > > Track what? NULL ptrs? I don't think so. Possibly when you have a
> > > > static NULL ptr but not in the general case.
> > >
> > > Well of course.
> >
> > What did you mean then with "Can't GCC track it?" then? Just a bad joke?
>
> Never mind, didn't finish my train of thought.

I almost figured that ...

>
> > > > I am getting tired of this discussion now. I am just trying to tell you
> > > > that no sane impl. of malloc() these days return NULL for malloc(0).
> > >
> > > And I got your point. Though for u-boot, this would be the best solution
> > > actually. Anyone who uses memory allocated by malloc(0) is insane.
> >
> > No, you don't get the point. If you did you would not have have made the
> > "insane" remark.
>
> No, relying on malloc(0) returning something sane is messed up.

Depend

Re: [U-Boot] [PATCH] usb: increase delay after port reset

[Marek Vasut]

Dear Ilya Yanok,

> In our setup (OMAP3 EHCI host, keyboard, mouse mass storage and BT
> dongle devices connected via several hubs) keyboard fails to initialize
> during the bus scan (stalled endpoint while get_descriptor/64) and after
> that keyboard is unusable (even in Linux) until power off/on.
> 
> Increasing the delay after port reset from 200ms to 260ms solves this
> problem.

Do we still have this problem?

> Signed-off-by: Ilya Yanok 
> ---
>  common/usb.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/common/usb.c b/common/usb.c
> index bed5116..5e282c6 100644
> --- a/common/usb.c
> +++ b/common/usb.c
> @@ -1147,7 +1147,7 @@ void usb_hub_port_connect_change(struct usb_device
> *dev, int port) return;
>   }
> 
> - wait_ms(200);
> + wait_ms(260);
> 
>   /* Allocate a new device struct for it */
>   usb = usb_alloc_new_device();

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

[U-Boot] [PATCH] mmc: mxsmmc: Fix operation with DMA

[Fabio Estevam]

Initialize the DMA controller so that the following errors are fixed:

U-Boot 2012.04-rc1-1-g037cbfd (Apr 02 2012 - 10:57:48)

Freescale i.MX28 family at 454 MHz
DRAM:  128 MiB
MMC:   MXS MMC: 0
MMC0: DMA transfer failed
MMC0: DMA transfer failed
MMC0: DMA transfer failed
MMC0: DMA transfer failed
MMC init failed

Signed-off-by: Fabio Estevam 
---
 drivers/mmc/mxsmmc.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/mmc/mxsmmc.c b/drivers/mmc/mxsmmc.c
index e8bad9d..57f9953 100644
--- a/drivers/mmc/mxsmmc.c
+++ b/drivers/mmc/mxsmmc.c
@@ -303,6 +303,9 @@ int mxsmmc_initialize(bd_t *bis, int id, int (*wp)(int))
return -ENOMEM;
}
 
+   /* Init the DMA controller. */
+   mxs_dma_init();
+
priv->desc = mxs_dma_desc_alloc();
if (!priv->desc) {
free(priv);
-- 
1.7.1


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

Re: [U-Boot] [PATCH] mmc: mxsmmc: Fix operation with DMA

[Marek Vasut]

Dear Fabio Estevam,

> Initialize the DMA controller so that the following errors are fixed:
> 
> U-Boot 2012.04-rc1-1-g037cbfd (Apr 02 2012 - 10:57:48)
> 
> Freescale i.MX28 family at 454 MHz
> DRAM:  128 MiB
> MMC:   MXS MMC: 0
> MMC0: DMA transfer failed
> MMC0: DMA transfer failed
> MMC0: DMA transfer failed
> MMC0: DMA transfer failed
> MMC init failed
> 
> Signed-off-by: Fabio Estevam 
> ---
>  drivers/mmc/mxsmmc.c |3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/mmc/mxsmmc.c b/drivers/mmc/mxsmmc.c
> index e8bad9d..57f9953 100644
> --- a/drivers/mmc/mxsmmc.c
> +++ b/drivers/mmc/mxsmmc.c
> @@ -303,6 +303,9 @@ int mxsmmc_initialize(bd_t *bis, int id, int
> (*wp)(int)) return -ENOMEM;
>   }
> 
> + /* Init the DMA controller. */
> + mxs_dma_init();
> +
>   priv->desc = mxs_dma_desc_alloc();
>   if (!priv->desc) {
>   free(priv);

AH!

You don't have NAND over there, that explains it :)

Now, this is a problem on m28evk, because this init happens twice there. Can 
you 
possibly pull this somewhere into arch_cpu_init() or similar call?


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] hawkboard: Add CONFIG_SPL_LIBGENERIC_SUPPORT

[Marek Vasut]

Dear Tom Rini,

> On Mon, Apr 02, 2012 at 10:10:57PM +0530, Sughosh Ganu wrote:
> > On Mon Apr 02, 2012 at 09:33:43AM -0700, Tom Rini wrote:
> > > With older toolchains we need CONFIG_SPL_LIBGENERIC_SUPPORT in order
> > > for CONFIG_SPL_NAND_SUPPORT to link.
> > > 
> > > Signed-off-by: Tom Rini 
> > > ---
> > > 
> > >  include/configs/hawkboard.h |1 +
> > >  1 files changed, 1 insertions(+), 0 deletions(-)
> > > 
> > > diff --git a/include/configs/hawkboard.h b/include/configs/hawkboard.h
> > > index 50a1c17..0859371 100644
> > > --- a/include/configs/hawkboard.h
> > > +++ b/include/configs/hawkboard.h
> > > @@ -62,6 +62,7 @@
> > > 
> > >  #define CONFIG_SPL_NAND_SUPPORT
> > >  #define CONFIG_SPL_NAND_SIMPLE
> > >  #define CONFIG_SPL_NAND_LOAD
> > > 
> > > +#define CONFIG_SPL_LIBGENERIC_SUPPORT/* for udelay and __div64_32 for
> > > NAND */
> > > 
> > >  #define CONFIG_SPL_SERIAL_SUPPORT
> > >  #define CONFIG_SPL_LDSCRIPT  "board/$(BOARDDIR)/u-boot-spl-
hawk.lds"
> > >  #define CONFIG_SPL_TEXT_BASE 0xc108
> >  
> >  Simon is adding this as part of the common relocation support patch
> >  series. I think he was going to send an updated version.
> 
> Well, this is broken in mainline today so I don't want to wait.

Agreed

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] Prevent malloc with size 0

[Marek Vasut]

Dear Joakim Tjernlund,

> Marek Vasut  wrote on 2012/04/02 18:39:33:
> > From: Marek Vasut 
> > 
> > Dear Joakim Tjernlund,
> > 
> > > Marek Vasut  wrote on 2012/04/02 17:23:03:
> > > > Dear Joakim Tjernlund,
> > > > 
> > > > > Marek Vasut  wrote on 2012/04/02 16:42:30:
> > > > > > Dear Joakim Tjernlund,
> > > > > > 
> > > > > > > Marek Vasut  wrote on 2012/04/02 16:05:13:
> > > > > > > > Dear Joakim Tjernlund,
> > > > > > > > 
> > > > > > > > > Hi Grame
> > > > > > > > > 
> > > > > > > > > Graeme Russ  wrote on 2012/04/02 
09:17:44:
> > > > > > > > > > Hi Joakim,
> > > > > > > > > > 
> > > > > > > > > > On Apr 2, 2012 4:55 PM, "Joakim Tjernlund"
> > > > > > > > > > 
> > > > > > > > 
> > > > > > > > wrote:
> > > > > > > > > > > > Hi Marek,
> > > > > > > > > > > > 
> > > > > > > > > > > > On Mon, Apr 2, 2012 at 1:36 PM, Marek Vasut
> > > > > > > > > > > > 
> > > > > > > > 
> > > > > > > > wrote:
> > > > > > > > > > > > > Dear Mike Frysinger,
> > > > > > > > > > > > > 
> > > > > > > > > > > > >> On Sunday 01 April 2012 20:25:44 Graeme Russ wrote:
> > > > > > > > > > > > >> > b) The code calling malloc(0) is making a
> > > > > > > > > > > > >> > perfectly legitimate assumption
> > > > > > > > > > > > >> > 
> > > > > > > > > > > > >> >based on how glibc handles malloc(0)
> > > > > > > > > > > > >> 
> > > > > > > > > > > > >> not really.  POSIX says malloc(0) is
> > > > > > > > > > > > >> implementation defined (so it may return a unique
> > > > > > > > > > > > >> address, or it may return NULL). no userspace
> > > > > > > > > > > > >> code assuming malloc(0) will return non-NULL is
> > > > > > > > > > > > >> correct.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Which is your implementation-defined ;-) But I have
> > > > > > > > > > > > > to agree with this one. So my vote is for
> > > > > > > > > > > > > returning NULL.
> > > > > > > > > > > > 
> > > > > > > > > > > > Also, no userspace code assuming malloc(0) will
> > > > > > > > > > > > return NULL is correct
> > > > > > > > > > > > 
> > > > > > > > > > > > Point being, no matter which implementation is
> > > > > > > > > > > > chosen, it is up to the caller to not assume that
> > > > > > > > > > > > the choice that was made was, in fact, the choice
> > > > > > > > > > > > that was made.
> > > > > > > > > > > > 
> > > > > > > > > > > > I.e. the behaviour of malloc(0) should be able to be
> > > > > > > > > > > > changed on a whim with no side-effects
> > > > > > > > > > > > 
> > > > > > > > > > > > So I think I should change my vote to returning NULL
> > > > > > > > > > > > for one reason and one reason only - It is faster
> > > > > > > > > > > > during run-time
> > > > > > > > > > > 
> > > > > > > > > > > Then u-boot will be incompatible with both glibc and
> > > > > > > > > > > the linux kernel, it seems
> > > > > > > > > > 
> > > > > > > > > > Forget aboug other implementations...
> > > > > > > > > > What matters is that the fact that the behaviour is
> > > > > > > > > > undefined and it is up to the caller to take that into
> > > > > > > > > > account
> > > > > > > > > 
> > > > > > > > > Well, u-boot borrows code from both kernel and user space
> > > > > > > > > so it would make sense if malloc(0) behaved the same.
> > > > > > > > > Especially for kernel code which tend to depend on the
> > > > > > > > > kernels impl.(just look at Scotts example)
> > > > > > > > > 
> > > > > > > > > > > to me that any modern impl. of malloc(0) will return a
> > > > > > > > > > > non NULL ptr.
> > > > > > > > > > > 
> > > > > > > > > > > It does need to be slower, just return ~0 instead, the
> > > > > > > > > > > kernel does something similar: if (!size)
> > > > > > > > > > > 
> > > > > > > > > > > return ZERO_SIZE_PTR;
> > > > > > > > > > 
> > > > > > > > > > That could work, but technically I don't think it
> > > > > > > > > > complies as it is not a pointer to allocated memory...
> > > > > > > > > 
> > > > > > > > > It doesn't not have to be allocated memory, just a ptr !=
> > > > > > > > > NULL which you can do free() on.
> > > > > > > > 
> > > > > > > > But kernel has something mapped there to trap these pointers
> > > > > > > > I believe.
> > > > > > > 
> > > > > > > So? That only means that the kernel has extra protection if
> > > > > > > someone tries to deference such a ptr. You are not required to
> > > > > > > do that(nice to have though) You don have any protection for
> > > > > > > deferencing NULL either I think?
> > > > > > 
> > > > > > Can't GCC track it?
> > > > > 
> > > > > Track what? NULL ptrs? I don't think so. Possibly when you have a
> > > > > static NULL ptr but not in the general case.
> > > > 
> > > > Well of course.
> > > 
> > > What did you mean then with "Can't GCC track it?" then? Just a bad
> > > joke?
> > 
> > Never mind, didn't finish my train of thought.
> 
> I almost figured that ...
> 
> > > > > I am getting tired of this discussion now. I am just trying to tell
> > > > > you that no sane impl. of malloc() these days retur

Re: [U-Boot] [PATCH] Correct corrupted NAND Flash access on KARO TX25 modules

[stefano babic]

Am 02/04/2012 19:47, schrieb Gachet Daniel:
> Hi Stefano,
> 
> Have I to do more for the patch? Are you ok with the proposal?
> 

That is ok. Please use a shorter name: the function you patch is already
surrounded by #ifdef MXC_NFC_V1_1, so it is not required to repeat it in
the name (we have a lot of long names, but
CONFIG_NAND_MXC_V1_1_NFC_ONE_CYCLE is really quite long). The name
suggest also that you want to set ONE_CYCLE, but really you want the
opposite. Something like CONFIG_NAND_MXC_NO_ONE_CYLE is still long, but
maybe more correct.

Best regards,
Stefano Babic

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

[U-Boot] [PATCH v2] mmc: mxsmmc: Fix operation with DMA

[Fabio Estevam]

Initialize the DMA controller so that the following errors are fixed:

U-Boot 2012.04-rc1-1-g037cbfd (Apr 02 2012 - 10:57:48)

Freescale i.MX28 family at 454 MHz
DRAM:  128 MiB
MMC:   MXS MMC: 0
MMC0: DMA transfer failed
MMC0: DMA transfer failed
MMC0: DMA transfer failed
MMC0: DMA transfer failed
MMC init failed

In order to not break the DMA NAND support, remove mxs_dma_init from the
NAND driver now that it is called from the core dma file.

Signed-off-by: Fabio Estevam 
--
Changes since v1:
- Call mxs_dma_init() from a common location and remove it
from the mxs_nand driver

 drivers/dma/apbh_dma.c  |2 ++
 drivers/mtd/nand/mxs_nand.c |3 ---
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/dma/apbh_dma.c b/drivers/dma/apbh_dma.c
index c086629..68c4be2 100644
--- a/drivers/dma/apbh_dma.c
+++ b/drivers/dma/apbh_dma.c
@@ -346,6 +346,8 @@ struct mxs_dma_desc *mxs_dma_desc_alloc(void)
struct mxs_dma_desc *pdesc;
uint32_t size;
 
+   /* Initialize the DMA controller. */
+   mxs_dma_init();
size = roundup(sizeof(struct mxs_dma_desc), MXS_DMA_ALIGNMENT);
pdesc = memalign(MXS_DMA_ALIGNMENT, size);
 
diff --git a/drivers/mtd/nand/mxs_nand.c b/drivers/mtd/nand/mxs_nand.c
index 4b1297a..95eac35 100644
--- a/drivers/mtd/nand/mxs_nand.c
+++ b/drivers/mtd/nand/mxs_nand.c
@@ -1072,9 +1072,6 @@ int mxs_nand_init(struct mxs_nand_info *info)
goto err2;
}
 
-   /* Init the DMA controller. */
-   mxs_dma_init();
-
/* Reset the GPMI block. */
mx28_reset_block(&gpmi_regs->hw_gpmi_ctrl0_reg);
 
-- 
1.7.1


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

Re: [U-Boot] [PATCH V2 2/4] ARM: 926ejs: use debug() for misaligned addresses

[Mike Frysinger]

On Mon, Apr 2, 2012 at 12:18, Stefano Babic wrote:
> Misaligned warnings are useful to debug faulty drivers.
> A misaligned warning is printed also when the driver
> is correct - use debug() instead of printf().

unfortunately, this turns the failure into a silent one.  if i read
the code correctly, you still return an error in this code path which
means things don't actually get flushed/invalidated.

to the original concept, i have no problem with cache funcs all
warning on misalignment via debug() so developers can quickly see if
things need to be reviewed.
-mike
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-BOOT][PATCH] mmc: remove the hard setting for tran_speed

[Jae hoon Chung]

Hi Andy.

How do you about this patch?
I want to know your thinking.
In my case, clock is set to 50MHz, but mmcinfo is produced the "25MHz".
Because tran_speed is 25MHz.
But mmc->card_caps is set to MMC_MODE_HS and MMC_MODE_HS_52MHZ.
So we should be see the wrong information with mmcinfo.

Best Regards,
Jaehoon Chung

2012/3/27 Jaehoon Chung :
> mmc_set_clock is set to the hard-coding.
> But i think good that use the tran_speed value.
>
> Signed-off-by: Jaehoon Chung 
> Signed-off-by: Kyungmin Park 
> ---
>  drivers/mmc/mmc.c |   13 +++--
>  1 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index e035012..cba96cf 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -1124,9 +1124,9 @@ int mmc_startup(struct mmc *mmc)
>                }
>
>                if (mmc->card_caps & MMC_MODE_HS)
> -                       mmc_set_clock(mmc, 5000);
> +                       mmc->tran_speed = 5000;
>                else
> -                       mmc_set_clock(mmc, 2500);
> +                       mmc->tran_speed = 2500;
>        } else {
>                for (width = EXT_CSD_BUS_WIDTH_8; width >= 0; width--) {
>                        /* Set the card to use 4 bit*/
> @@ -1161,13 +1161,14 @@ int mmc_startup(struct mmc *mmc)
>
>                if (mmc->card_caps & MMC_MODE_HS) {
>                        if (mmc->card_caps & MMC_MODE_HS_52MHz)
> -                               mmc_set_clock(mmc, 5200);
> +                               mmc->tran_speed = 5200;
>                        else
> -                               mmc_set_clock(mmc, 2600);
> -               } else
> -                       mmc_set_clock(mmc, 2000);
> +                               mmc->tran_speed = 2600;
> +               }
>        }
>
> +       mmc_set_clock(mmc, mmc->tran_speed);
> +
>        /* fill in device description */
>        mmc->block_dev.lun = 0;
>        mmc->block_dev.type = 0;
> --
> 1.7.4.1
> ___
> 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 1/2] Build u-boot.imx by default when board uses it

[Mike Frysinger]

On Mon, Apr 2, 2012 at 13:03, Stefano Babic wrote:
> On 11/11/2011 14:26, Loďc Minier wrote:
>> On Fri, Nov 11, 2011, Daniel Schwierzeck wrote:
>>> ALL-$(CONFIG_UBOOT_IMG) += $(obj)u-boot.img
>>> ALL-$(CONFIG_UBOOT_IMX) += $(obj)u-boot.imx
>>> ALL-$(CONFIG_UBOOT_KWB) += $(obj)u-boot.kwb
>>>
>>> then you can define CONFIG_UBOOT_KWB or CONFIG_UBOOT_IMX in your
>>> board config if needed
>>
>>  That'd be a fine solution for me if others agree it's the right
>>  approach; ideally, we would even set CONFIG_UBOOT_IMX when
>>  CONFIG_IMX_CONFIG is set (not sure where though).
>
> Sorry to bring a dead thread to new life...
>
> The issue is not yet solved and I am asking if we can do something for
> the incoming release 2012.04. I would prefer we do not add a new switch
> CONFIG_UBOOT_IMX into the configuration file, because it is possible to
> have the same u-boot image running on different storages, for example on
> NAND or NOR, and they have different offsets. This means different
> imximage (header), while u-boot itself (binary) remains the same. So
> this information should be not interpreted by the compiler.

i'm not sure i follow.  it's been a while since this thread came
through, but it seemed like you could handle this (defining the
various CONFIG_xxx stuff) in arch/soc asm/config.h files ?

> Rereading the thread a major point is that we must not change the main
> Makefile. What about if the changes suggested in the patch are put into
> arch/arm/cpu/armv7/config.mk ?

the suggested ALL-$(CONFIG_xxx) syntax should be usable in the
arch/soc config.mk files
-mike
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-BOOT][PATCH] mmc: support the revision check for eMMC4.5

[Jae hoon Chung]

Hi,

Anybody think about this patch?
mmcinfo is produce correctly?

if i miss something, let me know, plz.

Best Regards,
Jaehoon Chung

2012/3/27 Jaehoon Chung :
> eMMC card is introduced the eMMC4.5.
> But now eMMC card is checked up to eMMC4.0.
> This patch is supported until eMMC4.5
>
> Signed-off-by: Jaehoon Chung 
> Signed-off-by: Kyungmin Park 
> ---
>  common/cmd_mmc.c  |    5 -
>  drivers/mmc/mmc.c |   25 +
>  include/mmc.h     |    8 
>  3 files changed, 37 insertions(+), 1 deletions(-)
>
> diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c
> index 8f13c22..ff150ca 100644
> --- a/common/cmd_mmc.c
> +++ b/common/cmd_mmc.c
> @@ -106,7 +106,10 @@ static void print_mmcinfo(struct mmc *mmc)
>        printf("Rd Block Len: %d\n", mmc->read_bl_len);
>
>        printf("%s version %d.%d\n", IS_SD(mmc) ? "SD" : "MMC",
> -                       (mmc->version >> 4) & 0xf, mmc->version & 0xf);
> +                       (mmc->version >> 4) & 0xf,
> +                       (mmc->version & 0xf) == EXT_CSD_REV_1_5 ?
> +                       41 :((mmc->version & 0xf) > EXT_CSD_REV_1_5 ?
> +                       (mmc->version & 0xf) - 1 : (mmc->version & 0xf)));
>
>        printf("High Capacity: %s\n", mmc->high_capacity ? "Yes" : "No");
>        puts("Capacity: ");
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index 49c3349..e035012 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -651,6 +651,31 @@ int mmc_change_freq(struct mmc *mmc)
>        if (err)
>                return err;
>
> +       switch (ext_csd[EXT_CSD_REV]) {
> +       case EXT_CSD_REV_1_0:
> +               mmc->version |= EXT_CSD_REV_1_0;
> +               break;
> +       case EXT_CSD_REV_1_1:
> +               mmc->version |= EXT_CSD_REV_1_1;
> +               break;
> +       case EXT_CSD_REV_1_2:
> +               mmc->version |= EXT_CSD_REV_1_2;
> +               break;
> +       case EXT_CSD_REV_1_3:
> +               mmc->version |= EXT_CSD_REV_1_3;
> +               break;
> +       case EXT_CSD_REV_1_5:
> +               mmc->version |= EXT_CSD_REV_1_5;
> +               break;
> +       case EXT_CSD_REV_1_6:
> +               mmc->version |= EXT_CSD_REV_1_6;
> +               break;
> +       case EXT_CSD_REV_1_4:
> +       default:
> +               printf("Unknown revision - %x\n", ext_csd[EXT_CSD_REV]);
> +               return 0;
> +       }
> +
>        /* No high-speed support */
>        if (!ext_csd[EXT_CSD_HS_TIMING])
>                return 0;
> diff --git a/include/mmc.h b/include/mmc.h
> index 30c2375..726da99 100644
> --- a/include/mmc.h
> +++ b/include/mmc.h
> @@ -157,6 +157,14 @@
>  #define EXT_CSD_SEC_CNT                        212     /* RO, 4 bytes */
>  #define EXT_CSD_HC_ERASE_GRP_SIZE      224     /* RO */
>
> +#define EXT_CSD_REV_1_0                        0
> +#define EXT_CSD_REV_1_1                        1
> +#define EXT_CSD_REV_1_2                        2
> +#define EXT_CSD_REV_1_3                        3
> +#define EXT_CSD_REV_1_4                        4
> +#define EXT_CSD_REV_1_5                        5
> +#define EXT_CSD_REV_1_6                        6
> +
>  /*
>  * EXT_CSD field definitions
>  */
> --
> 1.7.4.1
> ___
> 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

[U-Boot] [PATCH v3 2/6] env: make himport_r() selective on variables

[Gerlando Falauto]

Add 2 new arguments to himport_r():

 o "nvars", "vars": number and list of variables to take into account
   (0 means ALL)

NOTE: This patch does not change the current behaviour.

Signed-off-by: Gerlando Falauto 
---
 common/cmd_nvedit.c |3 ++-
 common/env_common.c |6 --
 include/search.h|6 +-
 lib/hashtable.c |   27 ++-
 4 files changed, 37 insertions(+), 5 deletions(-)

diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
index e762e76..59668a6 100644
--- a/common/cmd_nvedit.c
+++ b/common/cmd_nvedit.c
@@ -930,7 +930,8 @@ static int do_env_import(cmd_tbl_t *cmdtp, int flag,
addr = (char *)ep->data;
}
 
-   if (himport_r(&env_htab, addr, size, sep, del ? 0 : H_NOCLEAR) == 0) {
+   if (himport_r(&env_htab, addr, size, sep, del ? 0 : H_NOCLEAR,
+   0, NULL) == 0) {
error("Environment import failed: errno = %d\n", errno);
return 1;
}
diff --git a/common/env_common.c b/common/env_common.c
index c33d22d..a93c062 100644
--- a/common/env_common.c
+++ b/common/env_common.c
@@ -182,7 +182,8 @@ void set_default_env(const char *s)
}
 
if (himport_r(&env_htab, (char *)default_environment,
-   sizeof(default_environment), '\0', 0) == 0)
+   sizeof(default_environment), '\0', 0,
+   0, NULL) == 0)
error("Environment import failed: errno = %d\n", errno);
 
gd->flags |= GD_FLG_ENV_READY;
@@ -207,7 +208,8 @@ int env_import(const char *buf, int check)
}
}
 
-   if (himport_r(&env_htab, (char *)ep->data, ENV_SIZE, '\0', 0)) {
+   if (himport_r(&env_htab, (char *)ep->data, ENV_SIZE, '\0', 0,
+   0, NULL)) {
gd->flags |= GD_FLG_ENV_READY;
return 1;
}
diff --git a/include/search.h b/include/search.h
index a4a5ef4..94d75fc 100644
--- a/include/search.h
+++ b/include/search.h
@@ -94,9 +94,13 @@ extern ssize_t hexport_r(struct hsearch_data *__htab,
 const char __sep, char **__resp, size_t __size,
 int argc, char * const argv[]);
 
+/*
+ * nvars: length of vars array
+ * vars: array of strings (variable names) to import (nvars == 0 means all)
+ */
 extern int himport_r(struct hsearch_data *__htab,
 const char *__env, size_t __size, const char __sep,
-int __flag);
+int __flag, int nvars, char * const vars[]);
 
 /* Flags for himport_r() */
 #defineH_NOCLEAR   (1 << 0) /* do not clear hash table before 
importing */
diff --git a/lib/hashtable.c b/lib/hashtable.c
index abd61c8..0610e86 100644
--- a/lib/hashtable.c
+++ b/lib/hashtable.c
@@ -603,6 +603,24 @@ ssize_t hexport_r(struct hsearch_data *htab, const char 
sep,
  * himport()
  */
 
+/* Check whether variable name is amongst vars[] */
+static int is_var_in_set(const char *name, int nvars, char * const vars[])
+{
+   int i = 0;
+
+   /* No variables specified means process all of them */
+   if (nvars == 0)
+   return 1;
+
+   for (i = 0; i < nvars; i++) {
+   if (!strcmp(name, vars[i]))
+   return 1;
+   }
+   debug("Skipping non-listed variable %s\n", name);
+
+   return 0;
+}
+
 /*
  * Import linearized data into hash table.
  *
@@ -639,7 +657,8 @@ ssize_t hexport_r(struct hsearch_data *htab, const char sep,
  */
 
 int himport_r(struct hsearch_data *htab,
- const char *env, size_t size, const char sep, int flag)
+   const char *env, size_t size, const char sep, int flag,
+   int nvars, char * const vars[])
 {
char *data, *sp, *dp, *name, *value;
 
@@ -726,6 +745,8 @@ int himport_r(struct hsearch_data *htab,
*dp++ = '\0';   /* terminate name */
 
debug("DELETE CANDIDATE: \"%s\"\n", name);
+   if (!is_var_in_set(name, nvars, vars))
+   continue;
 
if (hdelete_r(name, htab) == 0)
debug("DELETE ERROR 
##\n");
@@ -743,6 +764,10 @@ int himport_r(struct hsearch_data *htab,
*sp++ = '\0';   /* terminate value */
++dp;
 
+   /* Skip variables which are not supposed to be processed */
+   if (!is_var_in_set(name, nvars, vars))
+   continue;
+
/* enter into hash table */
e.key = name;
e.data = value;
-- 
1.7.1

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

[U-Boot] [PATCH v3 6/6] env: delete selected vars not present in imported env

[Gerlando Falauto]

When variables explicitly specified on the command line are not present
in the imported env, delete them from the running env.
If the variable is also missing from the running env, issue a warning.

Signed-off-by: Gerlando Falauto 
---
 lib/hashtable.c |   48 +---
 1 files changed, 41 insertions(+), 7 deletions(-)

diff --git a/lib/hashtable.c b/lib/hashtable.c
index f3f47de..b3d0b64 100644
--- a/lib/hashtable.c
+++ b/lib/hashtable.c
@@ -607,22 +607,32 @@ ssize_t hexport_r(struct hsearch_data *htab, const char 
sep,
  * himport()
  */
 
-/* Check whether variable name is amongst vars[] */
-static int is_var_in_set(const char *name, int nvars, char * const vars[])
+/*
+ * Check whether variable 'name' is amongst vars[],
+ * and remove all instances by setting the pointer to NULL
+ */
+static int is_var_in_set(const char *name, int nvars, char * vars[])
 {
int i = 0;
+   int res = 0;
 
/* No variables specified means process all of them */
if (nvars == 0)
return 1;
 
for (i = 0; i < nvars; i++) {
-   if (!strcmp(name, vars[i]))
-   return 1;
+   if (vars[i] == NULL)
+   continue;
+   /* If we found it, delete all of them */
+   if (!strcmp(name, vars[i])) {
+   vars[i] = NULL;
+   res = 1;
+   }
}
-   debug("Skipping non-listed variable %s\n", name);
+   if (!res)
+   debug("Skipping non-listed variable %s\n", name);
 
-   return 0;
+   return res;
 }
 
 /*
@@ -662,9 +672,11 @@ static int is_var_in_set(const char *name, int nvars, char 
* const vars[])
 
 int himport_r(struct hsearch_data *htab,
const char *env, size_t size, const char sep, int flag,
-   int nvars, char * const vars[], int do_apply)
+   int nvars, char * const __vars[], int do_apply)
 {
char *data, *sp, *dp, *name, *value;
+   char *vars[nvars];
+   int i;
 
/* Test for correct arguments.  */
if (htab == NULL) {
@@ -681,6 +693,10 @@ int himport_r(struct hsearch_data *htab,
memcpy(data, env, size);
dp = data;
 
+   /* make a local copy of the list of variables */
+   if (nvars)
+   memcpy(vars, __vars, sizeof(__vars[0]) * nvars);
+
if ((flag & H_NOCLEAR) == 0) {
/* Destroy old hash table if one exists */
debug("Destroy Hash Table: %p table = %p\n", htab,
@@ -809,6 +825,24 @@ int himport_r(struct hsearch_data *htab,
debug("INSERT: free(data = %p)\n", data);
free(data);
 
+   /* process variables which were not considered */
+   for (i = 0; i < nvars; i++) {
+   if (vars[i] == NULL)
+   continue;
+   /*
+* All variables which were not deleted from the variable list
+* were not present in the imported env
+* This could mean two things:
+* a) if the variable was present in current env, we delete it
+* b) if the variable was not present in current env, we notify
+*it might be a typo
+*/
+   if (hdelete_r(vars[i], htab, do_apply) == 0)
+   printf("WARNING: '%s' neither in running nor in 
imported env!\n", vars[i]);
+   else
+   printf("WARNING: '%s' not in imported env, deleting 
it!\n", vars[i]);
+   }
+
debug("INSERT: done\n");
return 1;   /* everything OK */
 }
-- 
1.7.1

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

[U-Boot] [PATCH v3 3/6] env: add check/apply logic to himport_r()

[Gerlando Falauto]

Change hashtable so that a callback function will decide whether a
variable can be overwritten, and possibly apply the changes.

So add a new field to struct hsearch_data:

 o "apply" callback function to check whether a variable can be
overwritten, and possibly immediately apply the changes;
when NULL, no check is performed.

And a new argument to himport_r():
 o "do_apply": whether to call the apply callback function

NOTE: This patch does not change the current behavior.

Signed-off-by: Gerlando Falauto 
---
 common/cmd_nvedit.c   |3 ++-
 common/env_common.c   |8 +---
 include/environment.h |9 +
 include/search.h  |   14 +-
 lib/hashtable.c   |   20 +++-
 5 files changed, 48 insertions(+), 6 deletions(-)

diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
index 59668a6..fc6165f 100644
--- a/common/cmd_nvedit.c
+++ b/common/cmd_nvedit.c
@@ -201,6 +201,7 @@ static int do_env_grep(cmd_tbl_t *cmdtp, int flag,
  * environment variable, then (if successful) apply the changes to internals so
  * to make them effective.  Code for this function was taken out of
  * _do_env_set(), which now calls it instead.
+ * Also called as a callback function by himport_r().
  * Returns 0 in case of success, 1 in case of failure.
  * When (flag & H_FORCE) is set, do not print out any error message and force
  * overwriting of write-once variables.
@@ -931,7 +932,7 @@ static int do_env_import(cmd_tbl_t *cmdtp, int flag,
}
 
if (himport_r(&env_htab, addr, size, sep, del ? 0 : H_NOCLEAR,
-   0, NULL) == 0) {
+   0, NULL, 0 /* do_apply */) == 0) {
error("Environment import failed: errno = %d\n", errno);
return 1;
}
diff --git a/common/env_common.c b/common/env_common.c
index a93c062..5558c1c 100644
--- a/common/env_common.c
+++ b/common/env_common.c
@@ -122,7 +122,9 @@ const uchar default_environment[] = {
"\0"
 };
 
-struct hsearch_data env_htab;
+struct hsearch_data env_htab = {
+   .apply = env_check_apply,
+};
 
 static uchar __env_get_char_spec(int index)
 {
@@ -183,7 +185,7 @@ void set_default_env(const char *s)
 
if (himport_r(&env_htab, (char *)default_environment,
sizeof(default_environment), '\0', 0,
-   0, NULL) == 0)
+   0, NULL, 0 /* do_apply */) == 0)
error("Environment import failed: errno = %d\n", errno);
 
gd->flags |= GD_FLG_ENV_READY;
@@ -209,7 +211,7 @@ int env_import(const char *buf, int check)
}
 
if (himport_r(&env_htab, (char *)ep->data, ENV_SIZE, '\0', 0,
-   0, NULL)) {
+   0, NULL, 0 /* do_apply */)) {
gd->flags |= GD_FLG_ENV_READY;
return 1;
}
diff --git a/include/environment.h b/include/environment.h
index 1ef44f3..236e179 100644
--- a/include/environment.h
+++ b/include/environment.h
@@ -193,6 +193,15 @@ void set_default_env(const char *s);
 /* Import from binary representation into hash table */
 int env_import(const char *buf, int check);
 
+/*
+ * Check if variable "name" can be changed from oldval to newval,
+ * and if so, apply the changes (e.g. baudrate).
+ * When (flag & H_FORCE) is set, it does not print out any error
+ * message and forces overwriting of write-once variables.
+ */
+int env_check_apply(const char *name, const char *oldval,
+   const char *newval, int flag);
+
 #endif /* DO_DEPS_ONLY */
 
 #endif /* _ENVIRONMENT_H_ */
diff --git a/include/search.h b/include/search.h
index 94d75fc..721c8ac 100644
--- a/include/search.h
+++ b/include/search.h
@@ -57,6 +57,16 @@ struct hsearch_data {
struct _ENTRY *table;
unsigned int size;
unsigned int filled;
+/*
+ * Callback function which will check whether the given change for variable
+ * "name" from "oldval" to "newval" may be applied or not, and possibly apply
+ * such change.
+ * When (flag & H_FORCE) is set, it shall not print out any error message and
+ * shall force overwriting of write-once variables.
+.* Must return 0 for approval, 1 for denial.
+ */
+   int (*apply)(const char *name, const char *oldval,
+   const char *newval, int flag);
 };
 
 /* Create a new hashing table which will at most contain NEL elements.  */
@@ -97,10 +107,12 @@ extern ssize_t hexport_r(struct hsearch_data *__htab,
 /*
  * nvars: length of vars array
  * vars: array of strings (variable names) to import (nvars == 0 means all)
+ * do_apply: whether to call callback function to check the new argument,
+ * and possibly apply changes (false means accept everything)
  */
 extern int himport_r(struct hsearch_data *__htab,
 const char *__env, size_t __size, const char __sep,
-int __flag, int nvars, char * const vars[]);
+int __flag, int nvars, char * const vars[], int do_

[U-Boot] [PATCH v3 4/6] env: check and apply changes on delete/destroy

[Gerlando Falauto]

Signed-off-by: Gerlando Falauto 
---
 common/cmd_nvedit.c |2 +-
 include/search.h|5 +++--
 lib/hashtable.c |   16 ++--
 3 files changed, 14 insertions(+), 9 deletions(-)

diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
index fc6165f..091cd46 100644
--- a/common/cmd_nvedit.c
+++ b/common/cmd_nvedit.c
@@ -375,7 +375,7 @@ int _do_env_set(int flag, int argc, char * const argv[])
 
/* Delete only ? */
if (argc < 3 || argv[2] == NULL) {
-   int rc = hdelete_r(name, &env_htab);
+   int rc = hdelete_r(name, &env_htab, 0);
return !rc;
}
 
diff --git a/include/search.h b/include/search.h
index 721c8ac..93e1cbc 100644
--- a/include/search.h
+++ b/include/search.h
@@ -73,7 +73,7 @@ struct hsearch_data {
 extern int hcreate_r(size_t __nel, struct hsearch_data *__htab);
 
 /* Destroy current internal hashing table.  */
-extern void hdestroy_r(struct hsearch_data *__htab);
+extern void hdestroy_r(struct hsearch_data *__htab, int do_apply);
 
 /*
  * Search for entry matching ITEM.key in internal hash table.  If
@@ -98,7 +98,8 @@ extern int hstrstr_r(const char *__match, int __last_idx, 
ENTRY ** __retval,
struct hsearch_data *__htab);
 
 /* Search and delete entry matching ITEM.key in internal hash table. */
-extern int hdelete_r(const char *__key, struct hsearch_data *__htab);
+extern int hdelete_r(const char *__key, struct hsearch_data *__htab,
+   int do_apply);
 
 extern ssize_t hexport_r(struct hsearch_data *__htab,
 const char __sep, char **__resp, size_t __size,
diff --git a/lib/hashtable.c b/lib/hashtable.c
index 6cfba56..f3f47de 100644
--- a/lib/hashtable.c
+++ b/lib/hashtable.c
@@ -142,7 +142,7 @@ int hcreate_r(size_t nel, struct hsearch_data *htab)
  * be freed and the local static variable can be marked as not used.
  */
 
-void hdestroy_r(struct hsearch_data *htab)
+void hdestroy_r(struct hsearch_data *htab, int do_apply)
 {
int i;
 
@@ -156,7 +156,10 @@ void hdestroy_r(struct hsearch_data *htab)
for (i = 1; i <= htab->size; ++i) {
if (htab->table[i].used > 0) {
ENTRY *ep = &htab->table[i].entry;
-
+   if (do_apply && htab->apply != NULL) {
+   /* deletion is always forced */
+   htab->apply(ep->key, ep->data, NULL, H_FORCE);
+   }
free((void *)ep->key);
free(ep->data);
}
@@ -401,7 +404,7 @@ int hsearch_r(ENTRY item, ACTION action, ENTRY ** retval,
  * do that.
  */
 
-int hdelete_r(const char *key, struct hsearch_data *htab)
+int hdelete_r(const char *key, struct hsearch_data *htab, int do_apply)
 {
ENTRY e, *ep;
int idx;
@@ -417,7 +420,8 @@ int hdelete_r(const char *key, struct hsearch_data *htab)
 
/* free used ENTRY */
debug("hdelete: DELETING key \"%s\"\n", key);
-
+   if (do_apply && htab->apply != NULL)
+   htab->apply(ep->key, ep->data, NULL, H_FORCE);
free((void *)ep->key);
free(ep->data);
htab->table[idx].used = -1;
@@ -682,7 +686,7 @@ int himport_r(struct hsearch_data *htab,
debug("Destroy Hash Table: %p table = %p\n", htab,
   htab->table);
if (htab->table)
-   hdestroy_r(htab);
+   hdestroy_r(htab, do_apply);
}
 
/*
@@ -748,7 +752,7 @@ int himport_r(struct hsearch_data *htab,
if (!is_var_in_set(name, nvars, vars))
continue;
 
-   if (hdelete_r(name, htab) == 0)
+   if (hdelete_r(name, htab, do_apply) == 0)
debug("DELETE ERROR 
##\n");
 
continue;
-- 
1.7.1

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

[U-Boot] [PATCH v3 1/6] env: unify logic to check and apply changes

[Gerlando Falauto]

The logic of checking special parameters (e.g. baudrate, stdin, stdout,
for a valid value and/or whether can be overwritten) and applying the
new value to the running system is now all within a single function
env_check_apply() which can be called whenever changes are made
to the environment, no matter if by set, default or import.

With this patch env_check_apply() is only called by "env set",
retaining previous behavior.

Signed-off-by: Gerlando Falauto 
---
 common/cmd_nvedit.c |  170 ---
 include/search.h|3 +-
 2 files changed, 109 insertions(+), 64 deletions(-)

diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
index 22f9821..e762e76 100644
--- a/common/cmd_nvedit.c
+++ b/common/cmd_nvedit.c
@@ -197,32 +197,21 @@ static int do_env_grep(cmd_tbl_t *cmdtp, int flag,
 #endif
 
 /*
- * Set a new environment variable,
- * or replace or delete an existing one.
+ * Perform consistency checking before setting, replacing, or deleting an
+ * environment variable, then (if successful) apply the changes to internals so
+ * to make them effective.  Code for this function was taken out of
+ * _do_env_set(), which now calls it instead.
+ * Returns 0 in case of success, 1 in case of failure.
+ * When (flag & H_FORCE) is set, do not print out any error message and force
+ * overwriting of write-once variables.
  */
-int _do_env_set(int flag, int argc, char * const argv[])
+
+int env_check_apply(const char *name, const char *oldval,
+   const char *newval, int flag)
 {
bd_t  *bd = gd->bd;
-   int   i, len;
+   int   i;
int   console = -1;
-   char  *name, *value, *s;
-   ENTRY e, *ep;
-
-   name = argv[1];
-
-   if (strchr(name, '=')) {
-   printf("## Error: illegal character '=' in variable name"
-  "\"%s\"\n", name);
-   return 1;
-   }
-
-   env_id++;
-   /*
-* search if variable with this name already exists
-*/
-   e.key = name;
-   e.data = NULL;
-   hsearch_r(e, FIND, &ep, &env_htab);
 
/* Check for console redirection */
if (strcmp(name, "stdin") == 0)
@@ -233,60 +222,76 @@ int _do_env_set(int flag, int argc, char * const argv[])
console = stderr;
 
if (console != -1) {
-   if (argc < 3) { /* Cannot delete it! */
-   printf("Can't delete \"%s\"\n", name);
+   if ((newval == NULL) || (*newval == '\0')) {
+   /* We cannot delete stdin/stdout/stderr */
+   if ((flag & H_FORCE) == 0)
+   printf("Can't delete \"%s\"\n", name);
return 1;
}
 
 #ifdef CONFIG_CONSOLE_MUX
-   i = iomux_doenv(console, argv[2]);
+   i = iomux_doenv(console, newval);
if (i)
return i;
 #else
/* Try assigning specified device */
-   if (console_assign(console, argv[2]) < 0)
+   if (console_assign(console, newval) < 0)
return 1;
 
 #ifdef CONFIG_SERIAL_MULTI
-   if (serial_assign(argv[2]) < 0)
+   if (serial_assign(newval) < 0)
return 1;
 #endif
 #endif /* CONFIG_CONSOLE_MUX */
}
 
/*
-* Some variables like "ethaddr" and "serial#" can be set only
-* once and cannot be deleted; also, "ver" is readonly.
+* Some variables like "ethaddr" and "serial#" can be set only once and
+* cannot be deleted, unless CONFIG_ENV_OVERWRITE is defined.
 */
-   if (ep) {   /* variable exists */
 #ifndef CONFIG_ENV_OVERWRITE
+   if (oldval != NULL &&   /* variable exists */
+   (flag & H_FORCE) == 0) {/* and we are not forced */
if (strcmp(name, "serial#") == 0 ||
(strcmp(name, "ethaddr") == 0
 #if defined(CONFIG_OVERWRITE_ETHADDR_ONCE) && defined(CONFIG_ETHADDR)
-&& strcmp(ep->data, MK_STR(CONFIG_ETHADDR)) != 0
+&& strcmp(oldval, MK_STR(CONFIG_ETHADDR)) != 0
 #endif /* CONFIG_OVERWRITE_ETHADDR_ONCE && CONFIG_ETHADDR */
)) {
printf("Can't overwrite \"%s\"\n", name);
return 1;
}
+   }
 #endif
+   /*
+* When we change baudrate, or we are doing an env default -a
+* (which will erase all variables prior to calling this),
+* we want the baudrate to actually change - for real.
+*/
+   if (oldval != NULL ||   /* variable exists */
+   (flag & H_NOCLEAR) == 0) {  /* or env is clear */
/*
 * Switch to new baudrate if new baudrate is supported
 */
if (strcmp(name, "baudrate") == 0) {
- 

[U-Boot] [PATCH v3 5/6] env: make "env default" selective, check and apply

[Gerlando Falauto]

Change the syntax (user API) for "env default":
  -f: override write-once variables
  var... : accept individual variable(s)
  -a: all (resetting the whole env is NOT the default behavior)

Enable variable checking and make changes effective by
enabling do_apply argument to himport_r().

Signed-off-by: Gerlando Falauto 
---
 common/cmd_nvedit.c   |   40 ++--
 common/env_common.c   |   28 +++-
 include/environment.h |3 +++
 3 files changed, 64 insertions(+), 7 deletions(-)

diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
index 091cd46..d8e233b 100644
--- a/common/cmd_nvedit.c
+++ b/common/cmd_nvedit.c
@@ -672,14 +672,41 @@ int envmatch(uchar *s1, int i2)
return -1;
 }
 
-static int do_env_default(cmd_tbl_t *cmdtp, int flag,
+static int do_env_default(cmd_tbl_t *cmdtp, int __flag,
  int argc, char * const argv[])
 {
-   if (argc != 2 || strcmp(argv[1], "-f") != 0)
-   return CMD_RET_USAGE;
+   int all = 0, flag = 0;
 
-   set_default_env("## Resetting to default environment\n");
-   return 0;
+   debug("Initial value for argc=%d\n", argc);
+   while (--argc > 0 && **++argv == '-') {
+   char *arg = *argv;
+
+   while (*++arg) {
+   switch (*arg) {
+   case 'a':   /* default all */
+   all = 1;
+   break;
+   case 'f':   /* force */
+   flag |= H_FORCE;
+   break;
+   default:
+   return cmd_usage(cmdtp);
+   }
+   }
+   }
+   debug("Final value for argc=%d\n", argc);
+   if (all && (argc == 0)) {
+   /* Reset the whole environment */
+   set_default_env("## Resetting to default environment\n");
+   return 0;
+   }
+   if (!all && (argc > 0)) {
+   /* Reset individual variables */
+   set_default_vars(argc, argv);
+   return 0;
+   }
+
+   return cmd_usage(cmdtp);
 }
 
 static int do_env_delete(cmd_tbl_t *cmdtp, int flag,
@@ -1010,7 +1037,8 @@ U_BOOT_CMD(
 #if defined(CONFIG_CMD_ASKENV)
"ask name [message] [size] - ask for environment variable\nenv "
 #endif
-   "default -f - reset default environment\n"
+   "default [-f] -a - [forcibly] reset default environment\n"
+   "env default [-f] var [...] - [forcibly] reset variable(s) to their 
default values\n"
 #if defined(CONFIG_CMD_EDITENV)
"env edit name - edit environment variable\n"
 #endif
diff --git a/common/env_common.c b/common/env_common.c
index 5558c1c..5104402 100644
--- a/common/env_common.c
+++ b/common/env_common.c
@@ -166,6 +166,11 @@ const uchar *env_get_addr(int index)
 
 void set_default_env(const char *s)
 {
+   /*
+* By default, do not apply changes as they will eventually
+* be applied by someone else
+*/
+   int do_apply = 0;
if (sizeof(default_environment) > ENV_SIZE) {
puts("*** Error - default environment is too large\n\n");
return;
@@ -177,6 +182,14 @@ void set_default_env(const char *s)
"using default environment\n\n",
s + 1);
} else {
+   /*
+* This set_to_default was explicitly asked for
+* by the user, as opposed to being a recovery
+* mechanism.  Therefore we check every single
+* variable and apply changes to the system
+* right away (e.g. baudrate, console).
+*/
+   do_apply = 1;
puts(s);
}
} else {
@@ -185,12 +198,25 @@ void set_default_env(const char *s)
 
if (himport_r(&env_htab, (char *)default_environment,
sizeof(default_environment), '\0', 0,
-   0, NULL, 0 /* do_apply */) == 0)
+   0, NULL, do_apply) == 0)
error("Environment import failed: errno = %d\n", errno);
 
gd->flags |= GD_FLG_ENV_READY;
 }
 
+
+/* [re]set individual variables to their value in the default environment */
+int set_default_vars(int nvars, char * const vars[])
+{
+   /*
+* Special use-case: import from default environment
+* (and use \0 as a separator)
+*/
+   return himport_r(&env_htab, (const char *)default_environment,
+   sizeof(default_environment), '\0', H_NOCLEAR,
+   nvars, vars, 1 /* do_apply */);
+}
+
 /*
  * Check if CRC is valid and (if yes) import the environment.
  * Note that "buf" may or may not be aligned.
diff --git a/incl

[U-Boot] [PATCH v3 0/6] env: handle special variables and selective env default

[Gerlando Falauto]

This patchset modifies the handling of all the operations on the environment
(set/import/default) so to unify handling of special variables.
On top of that we implement a selective "env default".

A selective "env import" would imply a user API change and should therefore
be discussed separately.

NOTE:
The entire patchset generates an increase in code size of about 1200 bytes
on a PowerPC target. 
As much as I would like to get rid of the set_default_vars() function in 
env_common.c, I have not found a nice way to do so.

Changes in the syntax (user API):
- "env default" -f: override write-once variables, -a means all
- display a warning when trying to set to default variables not
  present in the default env.

Changes from v2:
- removed typedef for callback, moved to the hashtable (struct hsearch_data)
- refactored patchset into smaller patches
  (only patch 5 and 6 should have any visible effect)
- added handling of selected variables not present in the imported env
- removed CONFIG_CMD_DEFAULTENV_VARS
- cosmetic formatting

Changes from v1:
- removed cosmetic patches (now mainstream)
- rebased to latest trunk
- removed subtle error in env_check_apply
  (comparing {loadaddr, bootfile} to values instead
  of variable names)
- changed env_check_apply so not to display warnings
  in case of H_FORCE flag being set

Changes from v0
- checkpatch cleanup
- removed himport_ex()
- removed warning for serial_assign()
- env import NOT implemented here

Gerlando Falauto (6):
  env: unify logic to check and apply changes
  env: make himport_r() selective on variables
  env: add check/apply logic to himport_r()
  env: check and apply changes on delete/destroy
  env: make "env default" selective, check and apply
  env: delete selected vars not present in imported env

 common/cmd_nvedit.c   |  216 +
 common/env_common.c   |   36 -
 include/environment.h |   12 +++
 include/search.h  |   26 +-
 lib/hashtable.c   |   95 --
 5 files changed, 300 insertions(+), 85 deletions(-)

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

Re: [U-Boot] [PATCH v2] mmc: mxsmmc: Fix operation with DMA

[Marek Vasut]

Dear Fabio Estevam,

> Initialize the DMA controller so that the following errors are fixed:
> 
> U-Boot 2012.04-rc1-1-g037cbfd (Apr 02 2012 - 10:57:48)
> 
> Freescale i.MX28 family at 454 MHz
> DRAM:  128 MiB
> MMC:   MXS MMC: 0
> MMC0: DMA transfer failed
> MMC0: DMA transfer failed
> MMC0: DMA transfer failed
> MMC0: DMA transfer failed
> MMC init failed
> 
> In order to not break the DMA NAND support, remove mxs_dma_init from the
> NAND driver now that it is called from the core dma file.
> 
> Signed-off-by: Fabio Estevam 
> --
> Changes since v1:
> - Call mxs_dma_init() from a common location and remove it
> from the mxs_nand driver
> 
>  drivers/dma/apbh_dma.c  |2 ++
>  drivers/mtd/nand/mxs_nand.c |3 ---
>  2 files changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/dma/apbh_dma.c b/drivers/dma/apbh_dma.c
> index c086629..68c4be2 100644
> --- a/drivers/dma/apbh_dma.c
> +++ b/drivers/dma/apbh_dma.c
> @@ -346,6 +346,8 @@ struct mxs_dma_desc *mxs_dma_desc_alloc(void)
>   struct mxs_dma_desc *pdesc;
>   uint32_t size;
> 
> + /* Initialize the DMA controller. */
> + mxs_dma_init();

This mxs_dma_desc_alloc() is called in a loop in the MXS NAND driver, this is 
even worse ;-)

Possibly some common mx28 init code would be better?

NAK (sorry, I know it hurts)

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] Prevent malloc with size 0

[Joakim Tjernlund]

Marek Vasut  wrote on 2012/04/02 20:00:03:
>
> Dear Joakim Tjernlund,
>
> > Marek Vasut  wrote on 2012/04/02 18:39:33:
> > > From: Marek Vasut 
> > >
> > > Dear Joakim Tjernlund,
> > >
> > > > Marek Vasut  wrote on 2012/04/02 17:23:03:
> > > > > Dear Joakim Tjernlund,
> > > > >
> > > > > > Marek Vasut  wrote on 2012/04/02 16:42:30:
> > > > > > > Dear Joakim Tjernlund,
> > > > > > >
> > > > > > > > Marek Vasut  wrote on 2012/04/02 
> > > > > > > > 16:05:13:
> > > > > > > > > Dear Joakim Tjernlund,
> > > > > > > > >
> > > > > > > > > > Hi Grame
> > > > > > > > > >
> > > > > > > > > > Graeme Russ  wrote on 2012/04/02
> 09:17:44:
> > > > > > > > > > > Hi Joakim,
> > > > > > > > > > >
> > > > > > > > > > > On Apr 2, 2012 4:55 PM, "Joakim Tjernlund"
> > > > > > > > > > > 
> > > > > > > > >
> > > > > > > > > wrote:
> > > > > > > > > > > > > Hi Marek,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Mon, Apr 2, 2012 at 1:36 PM, Marek Vasut
> > > > > > > > > > > > > 
> > > > > > > > >
> > > > > > > > > wrote:
> > > > > > > > > > > > > > Dear Mike Frysinger,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >> On Sunday 01 April 2012 20:25:44 Graeme Russ wrote:
> > > > > > > > > > > > > >> > b) The code calling malloc(0) is making a
> > > > > > > > > > > > > >> > perfectly legitimate assumption
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >> >based on how glibc handles malloc(0)
> > > > > > > > > > > > > >>
> > > > > > > > > > > > > >> not really.  POSIX says malloc(0) is
> > > > > > > > > > > > > >> implementation defined (so it may return a unique
> > > > > > > > > > > > > >> address, or it may return NULL). no userspace
> > > > > > > > > > > > > >> code assuming malloc(0) will return non-NULL is
> > > > > > > > > > > > > >> correct.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Which is your implementation-defined ;-) But I have
> > > > > > > > > > > > > > to agree with this one. So my vote is for
> > > > > > > > > > > > > > returning NULL.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Also, no userspace code assuming malloc(0) will
> > > > > > > > > > > > > return NULL is correct
> > > > > > > > > > > > >
> > > > > > > > > > > > > Point being, no matter which implementation is
> > > > > > > > > > > > > chosen, it is up to the caller to not assume that
> > > > > > > > > > > > > the choice that was made was, in fact, the choice
> > > > > > > > > > > > > that was made.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I.e. the behaviour of malloc(0) should be able to be
> > > > > > > > > > > > > changed on a whim with no side-effects
> > > > > > > > > > > > >
> > > > > > > > > > > > > So I think I should change my vote to returning NULL
> > > > > > > > > > > > > for one reason and one reason only - It is faster
> > > > > > > > > > > > > during run-time
> > > > > > > > > > > >
> > > > > > > > > > > > Then u-boot will be incompatible with both glibc and
> > > > > > > > > > > > the linux kernel, it seems
> > > > > > > > > > >
> > > > > > > > > > > Forget aboug other implementations...
> > > > > > > > > > > What matters is that the fact that the behaviour is
> > > > > > > > > > > undefined and it is up to the caller to take that into
> > > > > > > > > > > account
> > > > > > > > > >
> > > > > > > > > > Well, u-boot borrows code from both kernel and user space
> > > > > > > > > > so it would make sense if malloc(0) behaved the same.
> > > > > > > > > > Especially for kernel code which tend to depend on the
> > > > > > > > > > kernels impl.(just look at Scotts example)
> > > > > > > > > >
> > > > > > > > > > > > to me that any modern impl. of malloc(0) will return a
> > > > > > > > > > > > non NULL ptr.
> > > > > > > > > > > >
> > > > > > > > > > > > It does need to be slower, just return ~0 instead, the
> > > > > > > > > > > > kernel does something similar: if (!size)
> > > > > > > > > > > >
> > > > > > > > > > > > return ZERO_SIZE_PTR;
> > > > > > > > > > >
> > > > > > > > > > > That could work, but technically I don't think it
> > > > > > > > > > > complies as it is not a pointer to allocated memory...
> > > > > > > > > >
> > > > > > > > > > It doesn't not have to be allocated memory, just a ptr !=
> > > > > > > > > > NULL which you can do free() on.
> > > > > > > > >
> > > > > > > > > But kernel has something mapped there to trap these pointers
> > > > > > > > > I believe.
> > > > > > > >
> > > > > > > > So? That only means that the kernel has extra protection if
> > > > > > > > someone tries to deference such a ptr. You are not required to
> > > > > > > > do that(nice to have though) You don have any protection for
> > > > > > > > deferencing NULL either I think?
> > > > > > >
> > > > > > > Can't GCC track it?
> > > > > >
> > > > > > Track what? NULL ptrs? I don't think so. Possibly when you have a
> > > > > > static NULL ptr but not in the general case.
> > > > >
> > > > > Well of course.
> > > >
> > > > What did you mean then with "Can't GCC track it?" then? Just a b

Re: [U-Boot] [PATCH V2 2/4] ARM: 926ejs: use debug() for misaligned addresses

[Marek Vasut]

Dear Mike Frysinger,

> On Mon, Apr 2, 2012 at 12:18, Stefano Babic wrote:
> > Misaligned warnings are useful to debug faulty drivers.
> > A misaligned warning is printed also when the driver
> > is correct - use debug() instead of printf().
> 
> unfortunately, this turns the failure into a silent one.  if i read
> the code correctly, you still return an error in this code path which
> means things don't actually get flushed/invalidated.

You certainly do return an error, yes. And you don't do the op ... but then, 
what's the whole point of this check?

You can just ignore the return value in the flush() op, but I still don't like 
how this is ignored.

> to the original concept, i have no problem with cache funcs all
> warning on misalignment via debug() so developers can quickly see if
> things need to be reviewed.
> -mike

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