[U-Boot] [PATCH] gpio: spear_gpio: Remove unused gpio_toggle_value() function
There is no user calling this function, thus remove it.
Signed-off-by: Axel Lin
---
drivers/gpio/spear_gpio.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpio/spear_gpio.c b/drivers/gpio/spear_gpio.c
index d3c728e..5b5521e 100644
--- a/drivers/gpio/spear_gpio.c
+++ b/drivers/gpio/spear_gpio.c
@@ -80,11 +80,6 @@ int gpio_free(unsigned gpio)
return 0;
}
-void gpio_toggle_value(unsigned gpio)
-{
- gpio_set_value(gpio, !gpio_get_value(gpio));
-}
-
int gpio_direction_input(unsigned gpio)
{
return gpio_direction(gpio, GPIO_DIRECTION_IN);
--
1.8.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] gpio: spear_gpio: Fix gpio_set_value() implementation
Hi
Il giorno 30/giu/2013 06:18, "Axel Lin" ha scritto:
>
> 2013/6/21 Michael Trimarchi :
> > On 06/21/2013 06:40 AM, Vipin Kumar wrote:
> >> On 6/20/2013 7:26 PM, Axel Lin wrote:
> >>> 2013/6/20 Marek Vasut
>
> Dear Axel Lin,
>
> > In current gpio_set_value() implementation, it always sets the gpio
control
> > bit no matter the value argument is 0 or 1. Thus the GPIOs never
set to
> > low. This patch fixes this bug.
> >
> > Signed-off-by: Axel Lin
> > ---
> > drivers/gpio/spear_gpio.c | 5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpio/spear_gpio.c b/drivers/gpio/spear_gpio.c
> > index d3c728e..8878608 100644
> > --- a/drivers/gpio/spear_gpio.c
> > +++ b/drivers/gpio/spear_gpio.c
> > @@ -52,7 +52,10 @@ int gpio_set_value(unsigned gpio, int value)
> > {
> >struct gpio_regs *regs = (struct gpio_regs
*)CONFIG_GPIO_BASE;
> >
> > - writel(1<< gpio,®s->gpiodata[DATA_REG_ADDR(gpio)]);
> > + if (value)
> > + writel(1<<
gpio,®s->gpiodata[DATA_REG_ADDR(gpio)]);
> > + else
> > + writel(0,®s->gpiodata[DATA_REG_ADDR(gpio)]);
>
> How can this possibly work? Writing 0 to the whole bank will unset
all the
> GPIOs, no ?
> >>>
> >>>
> >>> Because each GPIO is controlled by a register.
> >>> And only one bit will be set when set gpio to high.
> >>>
> >>> So it's safe to write 0 for clearing the bit.
> >>>
> >>> Note, the gpio_get_value() implementation also assumes there is only
one bit
> >>> will be set. ( If this is not true, both gpio_get_value() and
gpio_set_value()
> >>> need fix.)
> >>>
> >>> Vipin, can you review this patch and confirm this behavior?
> >>>
> >>
> >> Yes this is right. and the code is fine
> >>
> >
> > The problem is not in set one bit but in reset one bit. Can you check
> > the else path?
>
> Hi,
> I'm not the best person to answer this question because I don't have the
> hardware and datasheet.
> In the case only one bit is meaningful and the reset bits are 0,
> it looks ok for me to write 0 for clearing the bit.
> ( note, each gpio pin is controlled by different register.)
>
> This patch is acked and reviewed by Stefan Roese and Vipin Kumar.
> I'm wondering if this patch is acceptable?
> Or maybe a test-by can help to make this patch acceptable?
>
If each pin is controlled by a different register why you need to 1< Regards,
> Axel
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] gpio: spear_gpio: Fix gpio_set_value() implementation
2013/6/30 Michael Trimarchi :
> Hi
> Il giorno 30/giu/2013 06:18, "Axel Lin" ha scritto:
>
>
>>
>> 2013/6/21 Michael Trimarchi :
>> > On 06/21/2013 06:40 AM, Vipin Kumar wrote:
>> >> On 6/20/2013 7:26 PM, Axel Lin wrote:
>> >>> 2013/6/20 Marek Vasut
>>
>> Dear Axel Lin,
>>
>> > In current gpio_set_value() implementation, it always sets the gpio
>> > control
>> > bit no matter the value argument is 0 or 1. Thus the GPIOs never set
>> > to
>> > low. This patch fixes this bug.
>> >
>> > Signed-off-by: Axel Lin
>> > ---
>> > drivers/gpio/spear_gpio.c | 5 -
>> > 1 file changed, 4 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/gpio/spear_gpio.c b/drivers/gpio/spear_gpio.c
>> > index d3c728e..8878608 100644
>> > --- a/drivers/gpio/spear_gpio.c
>> > +++ b/drivers/gpio/spear_gpio.c
>> > @@ -52,7 +52,10 @@ int gpio_set_value(unsigned gpio, int value)
>> > {
>> >struct gpio_regs *regs = (struct gpio_regs
>> > *)CONFIG_GPIO_BASE;
>> >
>> > - writel(1<< gpio,®s->gpiodata[DATA_REG_ADDR(gpio)]);
>> > + if (value)
>> > + writel(1<<
>> > gpio,®s->gpiodata[DATA_REG_ADDR(gpio)]);
>> > + else
>> > + writel(0,®s->gpiodata[DATA_REG_ADDR(gpio)]);
>>
>> How can this possibly work? Writing 0 to the whole bank will unset
>> all the
>> GPIOs, no ?
>> >>>
>> >>>
>> >>> Because each GPIO is controlled by a register.
>> >>> And only one bit will be set when set gpio to high.
>> >>>
>> >>> So it's safe to write 0 for clearing the bit.
>> >>>
>> >>> Note, the gpio_get_value() implementation also assumes there is only
>> >>> one bit
>> >>> will be set. ( If this is not true, both gpio_get_value() and
>> >>> gpio_set_value()
>> >>> need fix.)
>> >>>
>> >>> Vipin, can you review this patch and confirm this behavior?
>> >>>
>> >>
>> >> Yes this is right. and the code is fine
>> >>
>> >
>> > The problem is not in set one bit but in reset one bit. Can you check
>> > the else path?
>>
>> Hi,
>> I'm not the best person to answer this question because I don't have the
>> hardware and datasheet.
>> In the case only one bit is meaningful and the reset bits are 0,
>> it looks ok for me to write 0 for clearing the bit.
>> ( note, each gpio pin is controlled by different register.)
>>
>> This patch is acked and reviewed by Stefan Roese and Vipin Kumar.
>> I'm wondering if this patch is acceptable?
>> Or maybe a test-by can help to make this patch acceptable?
>>
>
> If each pin is controlled by a different register why you need to 1< set path?
Because the meaningful bit for different register is different.
>
> And how it works for gpio 33?
SPEAR_GPIO_COUNT is 8, so this driver only allows setting gpio0 ~ gpio7.
Vipin, any chance to double check the datasheet and confirm if this patch is ok?
Regards,
Axel
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 4/4] arm: add machine ID for CloudBox
CloudBox device is device tree compliant, but older LaCie kernel uses
machine ID method to boot.
Signed-off-by: Frédéric Leroy
---
arch/arm/include/asm/mach-types.h | 14 ++
board/LaCie/cloudbox/cloudbox.c | 7 ++-
include/configs/lacie_kw.h| 1 +
3 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/mach-types.h
b/arch/arm/include/asm/mach-types.h
index 440b041..071bd11 100644
--- a/arch/arm/include/asm/mach-types.h
+++ b/arch/arm/include/asm/mach-types.h
@@ -1106,6 +1106,7 @@ extern unsigned int __machine_arch_type;
#define MACH_TYPE_OMAP5_SEVM 3777
#define MACH_TYPE_ARMADILLO_800EVA 3863
#define MACH_TYPE_KZM9G4140
+#define MACH_TYPE_CLOUDBOX 4170
#ifdef CONFIG_ARCH_EBSA110
# ifdef machine_arch_type
@@ -14235,6 +14236,19 @@ extern unsigned int __machine_arch_type;
# define machine_is_kzm9g()(0)
#endif
+#ifdef CONFIG_MACH_CLOUDBOX
+# ifdef machine_arch_type
+# undef machine_arch_type
+# define machine_arch_type__machine_arch_type
+# else
+# define machine_arch_typeMACH_TYPE_CLOUDBOX
+# endif
+# define machine_cloudbox()(machine_arch_type == MACH_TYPE_CLOUDBOX)
+#else
+# define machine_cloudbox()(0)
+#endif
+
+
/*
* These have not yet been registered
*/
diff --git a/board/LaCie/cloudbox/cloudbox.c b/board/LaCie/cloudbox/cloudbox.c
index e5ee5a3..51b1f96 100644
--- a/board/LaCie/cloudbox/cloudbox.c
+++ b/board/LaCie/cloudbox/cloudbox.c
@@ -64,7 +64,12 @@ int board_early_init_f(void)
int board_init(void)
{
- /* Nothing to do with fdt */
+ /* Machine number */
+ gd->bd->bi_arch_number = CONFIG_MACH_TYPE;
+
+ /* Boot parameters address */
+ gd->bd->bi_boot_params = kw_sdram_bar(0) + 0x100;
+
return 0;
}
diff --git a/include/configs/lacie_kw.h b/include/configs/lacie_kw.h
index 02e0882..b305bf6 100644
--- a/include/configs/lacie_kw.h
+++ b/include/configs/lacie_kw.h
@@ -22,6 +22,7 @@
* Machine number definition
*/
#if defined(CONFIG_CLOUDBOX)
+#define CONFIG_MACH_TYPE MACH_TYPE_CLOUDBOX
#define CONFIG_IDENT_STRING" CloudBox"
#elif defined(CONFIG_D2NET_V2)
#define CONFIG_MACH_TYPE MACH_TYPE_D2NET_V2
--
1.8.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/4] LaCie/common: Fix cloudbox ethernet leds
The cloudbox device have a different ethernet phy setup than other ns2
devices. We get initialization value from the GPL LaCie source
Signed-off-by: Frédéric Leroy
---
board/LaCie/common/common.c | 13 ++---
include/configs/lacie_kw.h | 5 +
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/board/LaCie/common/common.c b/board/LaCie/common/common.c
index a62bf9f..85480e7 100644
--- a/board/LaCie/common/common.c
+++ b/board/LaCie/common/common.c
@@ -21,6 +21,12 @@
#define MV88E1116_RGMII_TXTM_CTRL (1 << 4)
#define MV88E1116_RGMII_RXTM_CTRL (1 << 5)
+#if !defined(MII_MARVELL_LED_REG)
+# define MII_MARVELL_LED_REG 16
+# define MII_MARVELL_LED_MASK 0xf0
+# define MII_MARVELL_LED_VALUE 0x0f
+#endif
+
void mv_phy_88e1116_init(const char *name, u16 phyaddr)
{
u16 reg;
@@ -53,9 +59,10 @@ void mv_phy_88e1318_init(const char *name, u16 phyaddr)
* Set control mode 4 for LED[0].
*/
miiphy_write(name, phyaddr, MII_MARVELL_PHY_PAGE, 3);
- miiphy_read(name, phyaddr, 16, ®);
- reg |= 0xf;
- miiphy_write(name, phyaddr, 16, reg);
+ miiphy_read(name, phyaddr, MII_MARVELL_LED_REG, ®);
+ reg &= MII_MARVELL_LED_MASK;
+ reg |= MII_MARVELL_LED_VALUE;
+ miiphy_write(name, phyaddr, MII_MARVELL_LED_REG, reg);
/*
* Enable RGMII delay on Tx and Rx for CPU port
diff --git a/include/configs/lacie_kw.h b/include/configs/lacie_kw.h
index fe27bbe..02e0882 100644
--- a/include/configs/lacie_kw.h
+++ b/include/configs/lacie_kw.h
@@ -138,6 +138,11 @@
#ifdef CONFIG_CMD_NET
#define CONFIG_MVGBE_PORTS {1, 0} /* enable port 0 only */
#define CONFIG_NETCONSOLE
+#if defined(CONFIG_CLOUDBOX)
+# define MII_MARVELL_LED_REG 17
+# define MII_MARVELL_LED_MASK 0xffc0
+# define MII_MARVELL_LED_VALUE 0x15
+#endif
#endif
/*
--
1.8.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/4] lacie_kw: sort #ifdef lists by CONFIG_ identifiers
Signed-off-by: Frédéric Leroy --- include/configs/lacie_kw.h | 26 +- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/include/configs/lacie_kw.h b/include/configs/lacie_kw.h index e2b3b21..cac616a 100644 --- a/include/configs/lacie_kw.h +++ b/include/configs/lacie_kw.h @@ -21,29 +21,29 @@ /* * Machine number definition */ -#if defined(CONFIG_INETSPACE_V2) +#if defined(CONFIG_D2NET_V2) +#define CONFIG_MACH_TYPE MACH_TYPE_D2NET_V2 +#define CONFIG_IDENT_STRING" D2 v2" +#elif defined(CONFIG_INETSPACE_V2) #define CONFIG_MACH_TYPE MACH_TYPE_INETSPACE_V2 #define CONFIG_IDENT_STRING" IS v2" -#elif defined(CONFIG_NETSPACE_V2) -#define CONFIG_MACH_TYPE MACH_TYPE_NETSPACE_V2 -#define CONFIG_IDENT_STRING" NS v2" +#elif defined(CONFIG_NET2BIG_V2) +#define CONFIG_MACH_TYPE MACH_TYPE_NET2BIG_V2 +#define CONFIG_IDENT_STRING" 2Big v2" #elif defined(CONFIG_NETSPACE_LITE_V2) #define MACH_TYPE_NETSPACE_LITE_V2 2983 /* missing in mach-types.h */ #define CONFIG_MACH_TYPE MACH_TYPE_NETSPACE_LITE_V2 #define CONFIG_IDENT_STRING" NS v2 Lite" +#elif defined(CONFIG_NETSPACE_MAX_V2) +#define CONFIG_MACH_TYPE MACH_TYPE_NETSPACE_MAX_V2 +#define CONFIG_IDENT_STRING" NS Max v2" #elif defined(CONFIG_NETSPACE_MINI_V2) #define MACH_TYPE_NETSPACE_MINI_V2 2831 /* missing in mach-types.h */ #define CONFIG_MACH_TYPE MACH_TYPE_NETSPACE_MINI_V2 #define CONFIG_IDENT_STRING" NS v2 Mini" -#elif defined(CONFIG_NETSPACE_MAX_V2) -#define CONFIG_MACH_TYPE MACH_TYPE_NETSPACE_MAX_V2 -#define CONFIG_IDENT_STRING" NS Max v2" -#elif defined(CONFIG_D2NET_V2) -#define CONFIG_MACH_TYPE MACH_TYPE_D2NET_V2 -#define CONFIG_IDENT_STRING" D2 v2" -#elif defined(CONFIG_NET2BIG_V2) -#define CONFIG_MACH_TYPE MACH_TYPE_NET2BIG_V2 -#define CONFIG_IDENT_STRING" 2Big v2" +#elif defined(CONFIG_NETSPACE_V2) +#define CONFIG_MACH_TYPE MACH_TYPE_NETSPACE_V2 +#define CONFIG_IDENT_STRING" NS v2" #else #error "Unknown board" #endif -- 1.8.1.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/4] arm: add support for LaCie CloudBox
This series adds support for the LaCie Cloudbox v2 device. Changes in v2: - sort unsorted #ifdef list in lacie_kw.h - add entry to MAINTAINERS - remove unused GPIO definitions - remove empty misc_init_r() - add Machine ID - Use #define values for ethernet phy init - checkpatch compliant Frédéric Leroy (4): lacie_kw: sort #ifdef lists by CONFIG_ identifiers arm: add support for LaCie CloudBox LaCie/common: Fix cloudbox ethernet leds arm: add machine ID for CloudBox MAINTAINERS | 4 + arch/arm/include/asm/mach-types.h | 14 board/LaCie/cloudbox/Makefile | 46 +++ board/LaCie/cloudbox/cloudbox.c | 94 + board/LaCie/cloudbox/cloudbox.h | 36 board/LaCie/cloudbox/kwbimage.cfg | 167 ++ board/LaCie/common/common.c | 13 ++- boards.cfg| 1 + include/configs/lacie_kw.h| 44 ++ 9 files changed, 401 insertions(+), 18 deletions(-) create mode 100644 board/LaCie/cloudbox/Makefile create mode 100644 board/LaCie/cloudbox/cloudbox.c create mode 100644 board/LaCie/cloudbox/cloudbox.h create mode 100644 board/LaCie/cloudbox/kwbimage.cfg -- 1.8.1.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/4] arm: add support for LaCie CloudBox
The LaCie CloudBox device is a Kirkwood based nas :
- SoC: Marvell 88F6702 1000Mhz
- SDRAM memory: 256MB DDR2 400Mhz
- Gigabit ethernet: PHY Marvell 88E1318
- Flash memory: SPI NOR 512KB (Macronix MX25L4005A)
- 1 push button
- 1 reset switch
- 1 SATA port
- 1 LED (bi-color, blue and red)
Signed-off-by: Frédéric Leroy
---
Changes in v2:
- sort unsorted #ifdef list in lacie_kw.h
- add entry to MAINTAINERS
- remove unused GPIO definitions
- remove empty misc_init_r()
- add Machine ID
- Use #define values for ethernet phy init
- checkpatch compliant
MAINTAINERS | 4 +
board/LaCie/cloudbox/Makefile | 46 +++
board/LaCie/cloudbox/cloudbox.c | 89
board/LaCie/cloudbox/cloudbox.h | 36
board/LaCie/cloudbox/kwbimage.cfg | 167 ++
boards.cfg| 1 +
include/configs/lacie_kw.h| 14 +++-
7 files changed, 354 insertions(+), 3 deletions(-)
create mode 100644 board/LaCie/cloudbox/Makefile
create mode 100644 board/LaCie/cloudbox/cloudbox.c
create mode 100644 board/LaCie/cloudbox/cloudbox.h
create mode 100644 board/LaCie/cloudbox/kwbimage.cfg
diff --git a/MAINTAINERS b/MAINTAINERS
index 3e70b03..9bf561d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -770,6 +770,10 @@ Sergey Lapin
afeb9260ARM926EJS (AT91SAM9260 SoC)
+Frederic Leroy
+
+ cloudboxARM926EJS (Kirkwood SoC)
+
Valentin Longchamp
km_kirkwood ARM926EJS (Kirkwood SoC)
diff --git a/board/LaCie/cloudbox/Makefile b/board/LaCie/cloudbox/Makefile
new file mode 100644
index 000..d656951
--- /dev/null
+++ b/board/LaCie/cloudbox/Makefile
@@ -0,0 +1,46 @@
+#
+# Copyright (C) 2013 Frederic Leroy
+#
+# Based on Kirkwood support:
+# (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.
+#
+
+include $(TOPDIR)/config.mk
+ifneq ($(OBJTREE),$(SRCTREE))
+$(shell mkdir -p $(obj)../common)
+endif
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS := $(BOARD).o ../common/common.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/LaCie/cloudbox/cloudbox.c b/board/LaCie/cloudbox/cloudbox.c
new file mode 100644
index 000..e5ee5a3
--- /dev/null
+++ b/board/LaCie/cloudbox/cloudbox.c
@@ -0,0 +1,89 @@
+/*
+ * Copyright (C) 2013 Frederic Leroy
+ *
+ * Based on Kirkwood support:
+ * (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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "cloudbox.h"
+#include "../common/common.h"
+
+DECLARE_GLOBAL_DATA_PTR;
+
+int board_early_init_f(void)
+{
+ /* Gpio configuration */
+ kw_config_gpio(CLOUDBOX_OE_VAL_LOW, CLOUDBOX_OE_VAL_HIGH,
+ CLOUDBOX_OE_LOW, CLOUDBOX_OE_HIGH);
+
+ /* Multi-Purpose Pins Functionality configuration */
+ static const u32 kwmpp_config[] = {
+ MPP0_SPI_SCn,
+ MPP1_SPI_MOSI,
+ MPP2_SPI_SCK,
+ MPP3_SPI_MISO,
+ MPP4_GPIO, /* hard disk power */
+ MPP6_SYSRST_OUTn,
+ MPP8_TW_SDA,
+ MPP9_TW_SCK,
+ MPP10_UART0_TXD,
+ MPP11_UART0_RXD,
+ MPP14_GPIO, /* LED red control */
+ MPP15_SATA0_ACTn, /* LED blue control */
+ MPP16_GPIO, /* power push buton *
[U-Boot] [PATCH 0/3] Adopt u-boot build to OS X
Latest changes to mkimage, Makefile and added proftool broke compilation on OS X. This series makes u-boot build clean again with some little adoptions. Patch 'lib/rsa/rsa-sig.c: compile on OS X' supersedes http://patchwork.ozlabs.org/patch/255283/ Andreas Bießmann (3): lib/rsa/rsa-sig.c: compile on OS X tools/proftool: add missing definition Makefile: fix readelf usage Makefile | 2 +- lib/rsa/rsa-sign.c | 1 - tools/proftool.c | 5 + 3 files changed, 6 insertions(+), 2 deletions(-) -- 1.8.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] Makefile: fix readelf usage
Some OS (like OS X) do not provide a generic readelf. We should enforce to use the toochain provided readelf instead, to do so use $(CROSS_COMPILE)readelf. Signed-off-by: Andreas Bießmann --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index ba1c10b..446c2f8 100644 --- a/Makefile +++ b/Makefile @@ -747,7 +747,7 @@ endif # config.mk # ARM relocations should all be R_ARM_RELATIVE. checkarmreloc: $(obj)u-boot @if test "R_ARM_RELATIVE" != \ - "`readelf -r $< | cut -d ' ' -f 4 | grep R_ARM | sort -u`"; \ + "`$(CROSS_COMPILE)readelf -r $< | cut -d ' ' -f 4 | grep R_ARM | sort -u`"; \ then echo "$< contains relocations other than \ R_ARM_RELATIVE"; false; fi -- 1.8.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] tools/proftool: add missing definition
BSD (like OS X) variants of regex.h do not declare REG_NOERROR, add a simple
define for them.
Signed-off-by: Andreas Bießmann
---
tools/proftool.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/tools/proftool.c b/tools/proftool.c
index a48ed28..d910b50 100644
--- a/tools/proftool.c
+++ b/tools/proftool.c
@@ -35,6 +35,11 @@
#define MAX_LINE_LEN 500
+#ifndef REG_NOERROR
+/* BSD regex.h do not expose REG_NOERROR */
+# define REG_NOERROR 0
+#endif
+
enum {
FUNCF_TRACE = 1 << 0, /* Include this function in trace */
};
--
1.8.3.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] lib/rsa/rsa-sig.c: compile on OS X
Interfaces exposed by error.h seems not to be used in rsa-sig.c, remove it. This also fixes an compile error on OS X: ---8<--- u-boot/lib/rsa/rsa-sign.c:23:19: error: error.h: No such file or directory --->8--- Signed-off-by: Andreas Bießmann --- Supersedes http://patchwork.ozlabs.org/patch/255283/ lib/rsa/rsa-sign.c | 1 - 1 file changed, 1 deletion(-) diff --git a/lib/rsa/rsa-sign.c b/lib/rsa/rsa-sign.c index a75ae24..e30d8ca 100644 --- a/lib/rsa/rsa-sign.c +++ b/lib/rsa/rsa-sign.c @@ -20,7 +20,6 @@ #include "mkimage.h" #include #include -#include #include #include #include -- 1.8.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] lib/rsa/rsa-sig.c: compile on OS X
superseded by http://patchwork.ozlabs.org/patch/255877/ On 28.06.13 09:00, Andreas Bießmann wrote: > Interfaces exposed by error.h seems not to be used in rsa-sig.c, remove it. > This also fixes an compile error on OS X: > > ---8<--- > u-boot/lib/rsa/rsa-sign.c:23:19: error: error.h: No such file or directory > --->8--- > > Signed-off-by: Andreas Bießmann > --- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Regression due to 020bbcb "usb: hub: Power-cycle on root-hub ports"
Dear Stephen Warren, > (Sorry to those on to/cc; I'm resending this so it goes to the correct > mailing list) > > Commit 020bbcb "usb: hub: Power-cycle on root-hub ports" causes a > regression on Tegra systems. > > The first time "usb start" is executed, it appears to work correctly. > However, any subsequent time it is executed, it takes a long time, and > eventually fails to find any USB devices. > > This situation can happen quite often; for example, if the user forgets > to plug in a USB device before booting, runs "usb start", realizes that, > then plugs it in and runs "usb start" again. This is compounded on at > least one of the Tegra boards, since CONFIG_PREBOOT is set to "usb > start" on systems (laptops/clamshells) which have built-in USB keyboards. > > If I simply revert this patch, then everything works again. (Yes, > reverting requires fixing a small merge conflict.) > > Do you have any idea what the problem can be? I'm tempted to simply ask > for the patch to be reverted since it causes a regression. > > Thanks for any idea how to fix this! BUMP? Vivek, any ideas? Otherwise I'm reverting this. 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 1/4] lacie_kw: sort #ifdef lists by CONFIG_ identifiers
On Sun, Jun 30, 2013 at 12:12:26PM +0200, Frédéric Leroy wrote: > Signed-off-by: Frédéric Leroy > --- > include/configs/lacie_kw.h | 26 +- > 1 file changed, 13 insertions(+), 13 deletions(-) Acked-by: Simon Guinot > > diff --git a/include/configs/lacie_kw.h b/include/configs/lacie_kw.h > index e2b3b21..cac616a 100644 > --- a/include/configs/lacie_kw.h > +++ b/include/configs/lacie_kw.h > @@ -21,29 +21,29 @@ > /* > * Machine number definition > */ > -#if defined(CONFIG_INETSPACE_V2) > +#if defined(CONFIG_D2NET_V2) > +#define CONFIG_MACH_TYPE MACH_TYPE_D2NET_V2 > +#define CONFIG_IDENT_STRING " D2 v2" > +#elif defined(CONFIG_INETSPACE_V2) > #define CONFIG_MACH_TYPE MACH_TYPE_INETSPACE_V2 > #define CONFIG_IDENT_STRING " IS v2" > -#elif defined(CONFIG_NETSPACE_V2) > -#define CONFIG_MACH_TYPE MACH_TYPE_NETSPACE_V2 > -#define CONFIG_IDENT_STRING " NS v2" > +#elif defined(CONFIG_NET2BIG_V2) > +#define CONFIG_MACH_TYPE MACH_TYPE_NET2BIG_V2 > +#define CONFIG_IDENT_STRING " 2Big v2" > #elif defined(CONFIG_NETSPACE_LITE_V2) > #define MACH_TYPE_NETSPACE_LITE_V2 2983 /* missing in mach-types.h */ > #define CONFIG_MACH_TYPE MACH_TYPE_NETSPACE_LITE_V2 > #define CONFIG_IDENT_STRING " NS v2 Lite" > +#elif defined(CONFIG_NETSPACE_MAX_V2) > +#define CONFIG_MACH_TYPE MACH_TYPE_NETSPACE_MAX_V2 > +#define CONFIG_IDENT_STRING " NS Max v2" > #elif defined(CONFIG_NETSPACE_MINI_V2) > #define MACH_TYPE_NETSPACE_MINI_V2 2831 /* missing in mach-types.h */ > #define CONFIG_MACH_TYPE MACH_TYPE_NETSPACE_MINI_V2 > #define CONFIG_IDENT_STRING " NS v2 Mini" > -#elif defined(CONFIG_NETSPACE_MAX_V2) > -#define CONFIG_MACH_TYPE MACH_TYPE_NETSPACE_MAX_V2 > -#define CONFIG_IDENT_STRING " NS Max v2" > -#elif defined(CONFIG_D2NET_V2) > -#define CONFIG_MACH_TYPE MACH_TYPE_D2NET_V2 > -#define CONFIG_IDENT_STRING " D2 v2" > -#elif defined(CONFIG_NET2BIG_V2) > -#define CONFIG_MACH_TYPE MACH_TYPE_NET2BIG_V2 > -#define CONFIG_IDENT_STRING " 2Big v2" > +#elif defined(CONFIG_NETSPACE_V2) > +#define CONFIG_MACH_TYPE MACH_TYPE_NETSPACE_V2 > +#define CONFIG_IDENT_STRING " NS v2" > #else > #error "Unknown board" > #endif > -- > 1.8.1.2 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 4/4] arm: add machine ID for CloudBox
On Sun, Jun 30, 2013 at 12:12:29PM +0200, Frédéric Leroy wrote:
> CloudBox device is device tree compliant, but older LaCie kernel uses
> machine ID method to boot.
>
> Signed-off-by: Frédéric Leroy
> ---
> arch/arm/include/asm/mach-types.h | 14 ++
> board/LaCie/cloudbox/cloudbox.c | 7 ++-
> include/configs/lacie_kw.h| 1 +
> 3 files changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/include/asm/mach-types.h
> b/arch/arm/include/asm/mach-types.h
> index 440b041..071bd11 100644
> --- a/arch/arm/include/asm/mach-types.h
> +++ b/arch/arm/include/asm/mach-types.h
> @@ -1106,6 +1106,7 @@ extern unsigned int __machine_arch_type;
> #define MACH_TYPE_OMAP5_SEVM 3777
> #define MACH_TYPE_ARMADILLO_800EVA 3863
> #define MACH_TYPE_KZM9G4140
> +#define MACH_TYPE_CLOUDBOX 4170
>
> #ifdef CONFIG_ARCH_EBSA110
> # ifdef machine_arch_type
> @@ -14235,6 +14236,19 @@ extern unsigned int __machine_arch_type;
> # define machine_is_kzm9g() (0)
> #endif
>
> +#ifdef CONFIG_MACH_CLOUDBOX
> +# ifdef machine_arch_type
> +# undef machine_arch_type
> +# define machine_arch_type __machine_arch_type
> +# else
> +# define machine_arch_type MACH_TYPE_CLOUDBOX
> +# endif
> +# define machine_cloudbox() (machine_arch_type == MACH_TYPE_CLOUDBOX)
> +#else
> +# define machine_cloudbox() (0)
> +#endif
Hi Fred,
I think you can't update this file directly. Pulling the Linux mach-types
file is the ARM maintainer job.
Note that for the CloudBox board, the mach-types entry has been removed
because not needed by Linux. The Linux mainline support is only based on
DT. I had the same issue with the ns2 lite and mini. At the time, I have
been told to include the machine ID in the board header:
http://marc.info/?l=u-boot&m=134694402011372&w=2
Looks in configs/lacie_kw.h and grep for "missing in mach-types.h".
Besides, I don't understand why do you need a separate patch to add the
legacy boot support.
Simon
> +
> +
> /*
> * These have not yet been registered
> */
> diff --git a/board/LaCie/cloudbox/cloudbox.c b/board/LaCie/cloudbox/cloudbox.c
> index e5ee5a3..51b1f96 100644
> --- a/board/LaCie/cloudbox/cloudbox.c
> +++ b/board/LaCie/cloudbox/cloudbox.c
> @@ -64,7 +64,12 @@ int board_early_init_f(void)
>
> int board_init(void)
> {
> - /* Nothing to do with fdt */
> + /* Machine number */
> + gd->bd->bi_arch_number = CONFIG_MACH_TYPE;
> +
> + /* Boot parameters address */
> + gd->bd->bi_boot_params = kw_sdram_bar(0) + 0x100;
> +
> return 0;
> }
>
> diff --git a/include/configs/lacie_kw.h b/include/configs/lacie_kw.h
> index 02e0882..b305bf6 100644
> --- a/include/configs/lacie_kw.h
> +++ b/include/configs/lacie_kw.h
> @@ -22,6 +22,7 @@
> * Machine number definition
> */
> #if defined(CONFIG_CLOUDBOX)
> +#define CONFIG_MACH_TYPE MACH_TYPE_CLOUDBOX
> #define CONFIG_IDENT_STRING " CloudBox"
> #elif defined(CONFIG_D2NET_V2)
> #define CONFIG_MACH_TYPE MACH_TYPE_D2NET_V2
> --
> 1.8.1.2
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 3/4] LaCie/common: Fix cloudbox ethernet leds
On Sun, Jun 30, 2013 at 12:12:28PM +0200, Frédéric Leroy wrote:
> The cloudbox device have a different ethernet phy setup than other ns2
> devices. We get initialization value from the GPL LaCie source
>
> Signed-off-by: Frédéric Leroy
> ---
> board/LaCie/common/common.c | 13 ++---
> include/configs/lacie_kw.h | 5 +
> 2 files changed, 15 insertions(+), 3 deletions(-)
Acked-by: Simon Guinot
>
> diff --git a/board/LaCie/common/common.c b/board/LaCie/common/common.c
> index a62bf9f..85480e7 100644
> --- a/board/LaCie/common/common.c
> +++ b/board/LaCie/common/common.c
> @@ -21,6 +21,12 @@
> #define MV88E1116_RGMII_TXTM_CTRL(1 << 4)
> #define MV88E1116_RGMII_RXTM_CTRL(1 << 5)
>
> +#if !defined(MII_MARVELL_LED_REG)
> +# define MII_MARVELL_LED_REG 16
> +# define MII_MARVELL_LED_MASK 0xf0
> +# define MII_MARVELL_LED_VALUE 0x0f
> +#endif
> +
> void mv_phy_88e1116_init(const char *name, u16 phyaddr)
> {
> u16 reg;
> @@ -53,9 +59,10 @@ void mv_phy_88e1318_init(const char *name, u16 phyaddr)
>* Set control mode 4 for LED[0].
>*/
> miiphy_write(name, phyaddr, MII_MARVELL_PHY_PAGE, 3);
> - miiphy_read(name, phyaddr, 16, ®);
> - reg |= 0xf;
> - miiphy_write(name, phyaddr, 16, reg);
> + miiphy_read(name, phyaddr, MII_MARVELL_LED_REG, ®);
> + reg &= MII_MARVELL_LED_MASK;
> + reg |= MII_MARVELL_LED_VALUE;
> + miiphy_write(name, phyaddr, MII_MARVELL_LED_REG, reg);
>
> /*
>* Enable RGMII delay on Tx and Rx for CPU port
> diff --git a/include/configs/lacie_kw.h b/include/configs/lacie_kw.h
> index fe27bbe..02e0882 100644
> --- a/include/configs/lacie_kw.h
> +++ b/include/configs/lacie_kw.h
> @@ -138,6 +138,11 @@
> #ifdef CONFIG_CMD_NET
> #define CONFIG_MVGBE_PORTS {1, 0} /* enable port 0 only */
> #define CONFIG_NETCONSOLE
> +#if defined(CONFIG_CLOUDBOX)
> +# define MII_MARVELL_LED_REG 17
> +# define MII_MARVELL_LED_MASK 0xffc0
> +# define MII_MARVELL_LED_VALUE 0x15
> +#endif
> #endif
>
> /*
> --
> 1.8.1.2
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] blackfin: gpio: Use proper mask for comparing function
Acked-by: Sonic Zhang
On Fri, Jun 28, 2013 at 2:45 PM, Axel Lin wrote:
> The function return from P_FUNCT2MUX(per) takes 2 bits, however
> for BF537_FAMILY with offset != 1 the function is 1 bit.
>
> Also has small refactor for better readability.
> In portmux_setup(), it looks odd having "muxreg &= ~(3 << 1);"
> while in current code we do muxreg |= (function << offset);.
>
> Signed-off-by: Axel Lin
> ---
> arch/blackfin/cpu/gpio.c | 11 ++-
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/arch/blackfin/cpu/gpio.c b/arch/blackfin/cpu/gpio.c
> index f74a0b7..c4cddaf 100644
> --- a/arch/blackfin/cpu/gpio.c
> +++ b/arch/blackfin/cpu/gpio.c
> @@ -247,7 +247,7 @@ static struct {
>
> static void portmux_setup(unsigned short per)
> {
> - u16 y, offset, muxreg;
> + u16 y, offset, muxreg, mask;
> u16 function = P_FUNCT2MUX(per);
>
> for (y = 0; y < ARRAY_SIZE(port_mux_lut); y++) {
> @@ -258,12 +258,13 @@ static void portmux_setup(unsigned short per)
> offset = port_mux_lut[y].offset;
> muxreg = bfin_read_PORT_MUX();
>
> - if (offset != 1)
> - muxreg &= ~(1 << offset);
> + if (offset == 1)
> + mask = 3;
> else
> - muxreg &= ~(3 << 1);
> + mask = 1;
>
> - muxreg |= (function << offset);
> + muxreg &= ~(mask << offset);
> + muxreg |= ((function & mask) << offset);
> bfin_write_PORT_MUX(muxreg);
> }
> }
> --
> 1.8.1.2
>
>
>
> ___
> 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] blackfin: Fix using gd->baudrate before setting its value
Hi Axel,
On Sat, Jun 29, 2013 at 8:34 AM, Axel Lin wrote:
> Current code uses gd->baudrate before setting its value.
> Besides, I got below build warning which is introduced by
> commit ddb5c5be "blackfin: add baudrate to bdinfo".
>
> board.c:235:3: warning: passing argument 1 of 'simple_strtoul' makes pointer
> from integer without a cast [enabled by default]
> include/vsprintf.h:27:7: note: expected 'const char *' but argument is of
> type 'unsigned int'
>
> This patch moves the code using gd->baudrate to be after init_baudrate() call,
> this ensures we get the baudrate setting before using it.
>
> Signed-off-by: Axel Lin
> ---
> I forgot to CC u-boot mail list. here is a resend.
>
> Hi,
> I don't have this hardware to test.
> I'd appreciate if someone can test it.
>
> Thanks,
> Axel
> arch/blackfin/lib/board.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/blackfin/lib/board.c b/arch/blackfin/lib/board.c
> index f1d5547..9e2e9de 100644
> --- a/arch/blackfin/lib/board.c
> +++ b/arch/blackfin/lib/board.c
> @@ -231,8 +231,6 @@ static int global_board_data_init(void)
> bd->bi_sclk = get_sclk();
> bd->bi_memstart = CONFIG_SYS_SDRAM_BASE;
> bd->bi_memsize = CONFIG_SYS_MAX_RAM_SIZE;
> - bd->bi_baudrate = (gd->baudrate > 0)
> - ? simple_strtoul(gd->baudrate, NULL, 10) : CONFIG_BAUDRATE;
>
> return 0;
> }
> @@ -299,6 +297,7 @@ void board_init_f(ulong bootflag)
> env_init();
> serial_early_puts("Baudrate init\n");
> init_baudrate();
> + gd->bd->bi_baudrate = gd->baudrate;
I prefer to move this line into init_baudrate().
Regards,
Sonic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] blackfin: Fix using gd->baudrate before setting its value
2013/7/1 Sonic Zhang :
> Hi Axel,
>
> On Sat, Jun 29, 2013 at 8:34 AM, Axel Lin wrote:
>> Current code uses gd->baudrate before setting its value.
>> Besides, I got below build warning which is introduced by
>> commit ddb5c5be "blackfin: add baudrate to bdinfo".
>>
>> board.c:235:3: warning: passing argument 1 of 'simple_strtoul' makes pointer
>> from integer without a cast [enabled by default]
>> include/vsprintf.h:27:7: note: expected 'const char *' but argument is of
>> type 'unsigned int'
>>
>> This patch moves the code using gd->baudrate to be after init_baudrate()
>> call,
>> this ensures we get the baudrate setting before using it.
>>
>> Signed-off-by: Axel Lin
>> ---
>> I forgot to CC u-boot mail list. here is a resend.
>>
>> Hi,
>> I don't have this hardware to test.
>> I'd appreciate if someone can test it.
>>
>> Thanks,
>> Axel
>> arch/blackfin/lib/board.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/arch/blackfin/lib/board.c b/arch/blackfin/lib/board.c
>> index f1d5547..9e2e9de 100644
>> --- a/arch/blackfin/lib/board.c
>> +++ b/arch/blackfin/lib/board.c
>> @@ -231,8 +231,6 @@ static int global_board_data_init(void)
>> bd->bi_sclk = get_sclk();
>> bd->bi_memstart = CONFIG_SYS_SDRAM_BASE;
>> bd->bi_memsize = CONFIG_SYS_MAX_RAM_SIZE;
>> - bd->bi_baudrate = (gd->baudrate > 0)
>> - ? simple_strtoul(gd->baudrate, NULL, 10) : CONFIG_BAUDRATE;
>>
>> return 0;
>> }
>> @@ -299,6 +297,7 @@ void board_init_f(ulong bootflag)
>> env_init();
>> serial_early_puts("Baudrate init\n");
>> init_baudrate();
>> + gd->bd->bi_baudrate = gd->baudrate;
>
> I prefer to move this line into init_baudrate().
hi Sonic,
$ grep -r "int init_baudrate" -A 4 arch
It shows we have the same implementation for all supported architectures.
So I think init_baudrate() may be moved to a common place in the future.
I pernsonal prefer keep the code as is in this patch.
But if you insist on moving this line into init_baudrate(), I have no problem
to send a v2. Just let me know how do you think.
Thanks for the review,
Axel
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot2013:07-Recompile with -fPIC error for mips64 board
Gentle Reminder!! Hi Wolfgang, Can you please reply on this. Regards, Krishna On Fri, Jun 28, 2013 at 10:20 AM, krishna dwivedi < krishna.dwived...@gmail.com> wrote: > Hi Wolfgang, > > I am using xlp832 mips64 netlogic board.I referred these steps from > u-boot README file. > Configuration: > TARGET archCPU > BoardName > brcm8xx mipsmips64 brcm8xx > - - > Options > brcm8xx:SYS_BIG_ENDIAN > > > Regards, > Krishna > > > On Thu, Jun 27, 2013 at 11:19 PM, Wolfgang Denk wrote: > >> Dear krishna dwivedi, >> >> In message > d...@mail.gmail.com> you wrote: >> > --===1781805000== >> > Content-Type: multipart/alternative; >> boundary=047d7bd6c6425eb96b04e02592ae >> > >> > --047d7bd6c6425eb96b04e02592ae >> > Content-Type: text/plain; charset=ISO-8859-1 >> > >> > Hi All, >> > >> > I am cross-compiling u-boot2013-07 for mips64 board.These steps i have >> > followed: >> > 1)I have exported envionment variables CC,LD,AS,CCAS,AR and >> LD_LIBRARY_PATH. >> > 2)export CROSS_COMPILE=mips64-unknown-elf- >> > 3)make tools >> > 4)make board_config >> > 5)make all >> >> This is NOT the noral order of steps. There is no need to build >> "tools" manually, and in no way this should be done before the config >> target. >> >> I think I asked this before: which _exact_ machine configuration are >> you using, i. e. what is your board name? >> >> Best regards, >> >> Wolfgang Denk >> >> -- >> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel >> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany >> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de >> The optimum committee has no members. >>- Norman Augustine >> > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] exynos5250: move board specific configs to board specific config file
Hi, On Mon, Jul 1, 2013 at 1:08 PM, Chander Kashyap wrote: > On 28 June 2013 21:20, Simon Glass wrote: > > Hi Inderpal, > > > > On Thu, Jun 20, 2013 at 12:10 AM, Inderpal Singh > > wrote: > > > >> Hi Simon, > >> > >> Thanks for review. > >> > >> > >> On 11 June 2013 19:57, Simon Glass wrote: > >> > >>> Hi, > >>> > >>> On Fri, Jun 7, 2013 at 4:56 AM, Inderpal Singh < > inderpal.si...@linaro.org > >>> > wrote: > >>> > Not all boards based on exynos5250 have SPI flash, same serial port > and > might > not require display and the same lds script. Hence move them to board > specific > config file. > > >>> > >>> At least for the serial port this should be controlled by the device > >>> tree. There are quite a lot of pending patches for exynos, one of which > >>> enables this and removes the need for the CONFIG_SERIAL3 define. > >>> > >>> If you want to have a look, I pushed them to: > >>> > >>> http://git.denx.de/u-boot-x86.git in branch 'snow' > >>> > >> > >> I was not aware of this patchset. Thanks for pointing out. I will update > >> my patchset to use DT for serial. > >> > >> > >>> > > Signed-off-by: Inderpal Singh > --- > v1 was posted as the second patch of [1] > > Changes in v2: > - split from the patchset at [1] > - moved CONFIG_LCD and CONFIG_SPI_FLASH > - rebased to latest u-boot-samsung master branch > > [1] http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/157101 > > include/configs/exynos5250-dt.h | 11 +-- > include/configs/smdk5250.h | 16 ++-- > include/configs/snow.h | 16 ++-- > 3 files changed, 29 insertions(+), 14 deletions(-) > > diff --git a/include/configs/exynos5250-dt.h > b/include/configs/exynos5250-dt.h > index 03b07b2..22e47eb 100644 > --- a/include/configs/exynos5250-dt.h > +++ b/include/configs/exynos5250-dt.h > @@ -29,7 +29,6 @@ > #define CONFIG_SAMSUNG /* in a SAMSUNG core */ > #define CONFIG_S5P /* S5P Family */ > #define CONFIG_EXYNOS5 /* which is in a Exynos5 > Family > */ > -#define CONFIG_SMDK5250/* which is in a > SMDK5250 */ > > >>> > >>> This is a misnomer - it actually means Exynos 5250 I think. The only > >>> thing it controls is the generation of the SPL packaging tool. So for > now > >>> it should be defined for all Exynos5250 boards. > >>> > >> > >> Yes its a misnomer. I will change the name to CONFIG_EXYNOS5250. > >> > > > > Sounds good. > > > > > >> > >> > >>> > >>> > > #include /* get chip and board defs */ > > @@ -78,7 +77,6 @@ > #define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + (4 << 20)) > > /* select serial console configuration */ > -#define CONFIG_SERIAL3 /* use SERIAL 3 */ > #define CONFIG_BAUDRATE115200 > #define EXYNOS5_DEFAULT_UART_OFFSET0x01 > > @@ -148,8 +146,6 @@ > #define CONFIG_SPL > #define COPY_BL2_FNPTR_ADDR0x02020030 > > -/* specific .lds file */ > -#define CONFIG_SPL_LDSCRIPT > "board/samsung/smdk5250/smdk5250-uboot-spl.lds" > > >>> > >>> Again I suspect this is a misnomer. > >>> > >> > >> Since all boards might not need this lds file, so how about moving lds > >> file to board/samsung/common and renaming it to > exynos5250-uboot-spl.lds. > >> The boards needing this will have to include in their respective config > >> files. > >> Let me know your opinion. > >> > > > > OK, so long has you know of boards that don't need it? > > > > > >> > >> > >>> > >>> > #define CONFIG_SPL_TEXT_BASE 0x02023400 > #define CONFIG_SPL_MAX_FOOTPRINT (14 * 1024) > > @@ -158,7 +154,7 @@ > /* Miscellaneous configurable options */ > #define CONFIG_SYS_LONGHELP/* undef to save memory */ > #define CONFIG_SYS_HUSH_PARSER /* use "hush" command parser > */ > -#define CONFIG_SYS_PROMPT "SMDK5250 # " > +#define CONFIG_SYS_PROMPT "EXYNOS5250 # " > #define CONFIG_SYS_CBSIZE 256 /* Console I/O Buffer > Size */ > #define CONFIG_SYS_PBSIZE 384 /* Print Buffer Size > */ > #define CONFIG_SYS_MAXARGS 16 /* max number of > command > args */ > @@ -198,7 +194,6 @@ > /* FLASH and environment organization */ > #define CONFIG_SYS_NO_FLASH > #undef CONFIG_CMD_IMLS > -#define CONFIG_IDENT_STRING" for SMDK5250" > > #define CONFIG_SYS_MMC_ENV_DEV 0 > > @@ -247,9 +242,6 @@ > #define CONFIG_I2C_EDID > > /* SPI */ > -#define CONFIG_ENV_IS_IN_SPI_FLASH > -#define CONFIG_SPI_FLASH > - > #ifdef C
[U-Boot] I'm coming back :)
Hi Guys, Due to personal circumstances I left the U-Boot community back in late October 2012. Now I find my circumstances have been completely flipped upside down (long story) and I will soon have much more time on my hands. Unfortunately, I do not have a dev machine yet (that may take a couple of months) but at least I can start by reading the list again and get up to speed with what is going on. I want to send out a huge Thank You to Simon Glass for taking over the custodianship of the x86 repo. It's been really great to see my little baby grow up. Not only that, but he has taken over the campaign of architecture unification. I think I'm going to really like the new look U-Boot :) And another big Thanks toTom Rini, without whom U-Boot would have been at great risk of stumbling right when it was getting the greatest amount of momentum it ever had. Looking forward to being part of the team again. This time I will be focusing on ARM based devices, particularly the AllWinner A10 and A31. So Simon, I won't be taking x86 from you (I hope you don't mind) Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] gpio: spear_gpio: Fix gpio_set_value() implementation
On 6/30/2013 2:27 PM, Axel Lin wrote:
2013/6/30 Michael Trimarchi:
Hi
Il giorno 30/giu/2013 06:18, "Axel Lin" ha scritto:
2013/6/21 Michael Trimarchi:
On 06/21/2013 06:40 AM, Vipin Kumar wrote:
On 6/20/2013 7:26 PM, Axel Lin wrote:
2013/6/20 Marek Vasut
Dear Axel Lin,
In current gpio_set_value() implementation, it always sets the gpio
control
bit no matter the value argument is 0 or 1. Thus the GPIOs never set
to
low. This patch fixes this bug.
Signed-off-by: Axel Lin
---
drivers/gpio/spear_gpio.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/spear_gpio.c b/drivers/gpio/spear_gpio.c
index d3c728e..8878608 100644
--- a/drivers/gpio/spear_gpio.c
+++ b/drivers/gpio/spear_gpio.c
@@ -52,7 +52,10 @@ int gpio_set_value(unsigned gpio, int value)
{
struct gpio_regs *regs = (struct gpio_regs
*)CONFIG_GPIO_BASE;
- writel(1<< gpio,®s->gpiodata[DATA_REG_ADDR(gpio)]);
+ if (value)
+ writel(1<<
gpio,®s->gpiodata[DATA_REG_ADDR(gpio)]);
+ else
+ writel(0,®s->gpiodata[DATA_REG_ADDR(gpio)]);
How can this possibly work? Writing 0 to the whole bank will unset
all the
GPIOs, no ?
Because each GPIO is controlled by a register.
And only one bit will be set when set gpio to high.
So it's safe to write 0 for clearing the bit.
Note, the gpio_get_value() implementation also assumes there is only
one bit
will be set. ( If this is not true, both gpio_get_value() and
gpio_set_value()
need fix.)
Vipin, can you review this patch and confirm this behavior?
Yes this is right. and the code is fine
The problem is not in set one bit but in reset one bit. Can you check
the else path?
Hi,
I'm not the best person to answer this question because I don't have the
hardware and datasheet.
In the case only one bit is meaningful and the reset bits are 0,
it looks ok for me to write 0 for clearing the bit.
( note, each gpio pin is controlled by different register.)
This patch is acked and reviewed by Stefan Roese and Vipin Kumar.
I'm wondering if this patch is acceptable?
Or maybe a test-by can help to make this patch acceptable?
If each pin is controlled by a different register why you need to 1<
Because the meaningful bit for different register is different.
And how it works for gpio 33?
SPEAR_GPIO_COUNT is 8, so this driver only allows setting gpio0 ~ gpio7.
Vipin, any chance to double check the datasheet and confirm if this patch is ok?
The questions raised here are valid and it forced me to re-read the
datasheet. For your convenience, I must tell you that the device is
actually pl061 from ARM, so the driver can also be named so.
The datasheet is here
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0190b/I1002697.html
Quoting from the datasheet
"The GPIODATA register is the data register. In software control mode,
values written in the GPIODATA register are transferred onto the GPOUT
pins if the respective pins have been configured as outputs through the
GPIODIR register.
In order to write to GPIODATA, the corresponding bits in the mask,
resulting from the address bus, PADDR[9:2], must be HIGH. Otherwise the
bit values remain unchanged by the write.
Similarly, the values read from this register are determined for each
bit, by the mask bit derived from the address used to access the data
register, PADDR[9:2]. Bits that are 1 in the address mask cause the
corresponding bits in GPIODATA to be read, and bits that are 0 in the
address mask cause the corresponding bits in GPIODATA to be read as 0,
regardless of their value.
A read from GPIODATA returns the last bit value written if the
respective pins are configured as output, or it returns the value on the
corresponding input GPIN bit when these are configured as inputs. All
bits are cleared by a reset."
After reading all this I am confused about numbering of the gpio's. I
think the numbering should be from 1 to 8 for a device. And this would
mean that we should write to *®s->datareg[1 << (gpio - 1)]* instead
of the present code which is _®s->datareg[1 << (gpio + 2)]_
Moreover, One GPIO device can control only 8 pins, so there is no
question of having GPIO33. In an SoC design, GPIO33 may actually map to
GPIO1 of device 4. I hope I am clear on this
Regards
Vipin
Regards,
Axel
.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] exynos5250: move board specific configs to board specific config file
On 28 June 2013 21:20, Simon Glass wrote: > Hi Inderpal, > > On Thu, Jun 20, 2013 at 12:10 AM, Inderpal Singh > wrote: > >> Hi Simon, >> >> Thanks for review. >> >> >> On 11 June 2013 19:57, Simon Glass wrote: >> >>> Hi, >>> >>> On Fri, Jun 7, 2013 at 4:56 AM, Inderpal Singh >> > wrote: >>> Not all boards based on exynos5250 have SPI flash, same serial port and might not require display and the same lds script. Hence move them to board specific config file. >>> >>> At least for the serial port this should be controlled by the device >>> tree. There are quite a lot of pending patches for exynos, one of which >>> enables this and removes the need for the CONFIG_SERIAL3 define. >>> >>> If you want to have a look, I pushed them to: >>> >>> http://git.denx.de/u-boot-x86.git in branch 'snow' >>> >> >> I was not aware of this patchset. Thanks for pointing out. I will update >> my patchset to use DT for serial. >> >> >>> Signed-off-by: Inderpal Singh --- v1 was posted as the second patch of [1] Changes in v2: - split from the patchset at [1] - moved CONFIG_LCD and CONFIG_SPI_FLASH - rebased to latest u-boot-samsung master branch [1] http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/157101 include/configs/exynos5250-dt.h | 11 +-- include/configs/smdk5250.h | 16 ++-- include/configs/snow.h | 16 ++-- 3 files changed, 29 insertions(+), 14 deletions(-) diff --git a/include/configs/exynos5250-dt.h b/include/configs/exynos5250-dt.h index 03b07b2..22e47eb 100644 --- a/include/configs/exynos5250-dt.h +++ b/include/configs/exynos5250-dt.h @@ -29,7 +29,6 @@ #define CONFIG_SAMSUNG /* in a SAMSUNG core */ #define CONFIG_S5P /* S5P Family */ #define CONFIG_EXYNOS5 /* which is in a Exynos5 Family */ -#define CONFIG_SMDK5250/* which is in a SMDK5250 */ >>> >>> This is a misnomer - it actually means Exynos 5250 I think. The only >>> thing it controls is the generation of the SPL packaging tool. So for now >>> it should be defined for all Exynos5250 boards. >>> >> >> Yes its a misnomer. I will change the name to CONFIG_EXYNOS5250. >> > > Sounds good. > > >> >> >>> >>> #include /* get chip and board defs */ @@ -78,7 +77,6 @@ #define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + (4 << 20)) /* select serial console configuration */ -#define CONFIG_SERIAL3 /* use SERIAL 3 */ #define CONFIG_BAUDRATE115200 #define EXYNOS5_DEFAULT_UART_OFFSET0x01 @@ -148,8 +146,6 @@ #define CONFIG_SPL #define COPY_BL2_FNPTR_ADDR0x02020030 -/* specific .lds file */ -#define CONFIG_SPL_LDSCRIPT "board/samsung/smdk5250/smdk5250-uboot-spl.lds" >>> >>> Again I suspect this is a misnomer. >>> >> >> Since all boards might not need this lds file, so how about moving lds >> file to board/samsung/common and renaming it to exynos5250-uboot-spl.lds. >> The boards needing this will have to include in their respective config >> files. >> Let me know your opinion. >> > > OK, so long has you know of boards that don't need it? > > >> >> >>> >>> #define CONFIG_SPL_TEXT_BASE 0x02023400 #define CONFIG_SPL_MAX_FOOTPRINT (14 * 1024) @@ -158,7 +154,7 @@ /* Miscellaneous configurable options */ #define CONFIG_SYS_LONGHELP/* undef to save memory */ #define CONFIG_SYS_HUSH_PARSER /* use "hush" command parser */ -#define CONFIG_SYS_PROMPT "SMDK5250 # " +#define CONFIG_SYS_PROMPT "EXYNOS5250 # " #define CONFIG_SYS_CBSIZE 256 /* Console I/O Buffer Size */ #define CONFIG_SYS_PBSIZE 384 /* Print Buffer Size */ #define CONFIG_SYS_MAXARGS 16 /* max number of command args */ @@ -198,7 +194,6 @@ /* FLASH and environment organization */ #define CONFIG_SYS_NO_FLASH #undef CONFIG_CMD_IMLS -#define CONFIG_IDENT_STRING" for SMDK5250" #define CONFIG_SYS_MMC_ENV_DEV 0 @@ -247,9 +242,6 @@ #define CONFIG_I2C_EDID /* SPI */ -#define CONFIG_ENV_IS_IN_SPI_FLASH -#define CONFIG_SPI_FLASH - #ifdef CONFIG_SPI_FLASH #define CONFIG_EXYNOS_SPI #define CONFIG_CMD_SF @@ -306,7 +298,6 @@ #define CONFIG_SHA256 /* Display */ -#define CONFIG_LCD #ifdef CONFIG_LCD #define CONFIG_EXYNOS_FB #define CONFIG_EXYNOS_DP diff --git a/include/configs/smdk5250.h b/include/configs/smdk5250.h index 81f83a8..4af1909 100644 --- a/include/configs/smdk5250.
Re: [U-Boot] [PATCH] blackfin: Fix using gd->baudrate before setting its value
Hi Axel,
On Mon, Jul 1, 2013 at 12:11 PM, Axel Lin wrote:
> 2013/7/1 Sonic Zhang :
>> Hi Axel,
>>
>> On Sat, Jun 29, 2013 at 8:34 AM, Axel Lin wrote:
>>> Current code uses gd->baudrate before setting its value.
>>> Besides, I got below build warning which is introduced by
>>> commit ddb5c5be "blackfin: add baudrate to bdinfo".
>>>
>>> board.c:235:3: warning: passing argument 1 of 'simple_strtoul' makes
>>> pointer from integer without a cast [enabled by default]
>>> include/vsprintf.h:27:7: note: expected 'const char *' but argument is of
>>> type 'unsigned int'
>>>
>>> This patch moves the code using gd->baudrate to be after init_baudrate()
>>> call,
>>> this ensures we get the baudrate setting before using it.
>>>
>>> Signed-off-by: Axel Lin
>>> ---
>>> I forgot to CC u-boot mail list. here is a resend.
>>>
>>> Hi,
>>> I don't have this hardware to test.
>>> I'd appreciate if someone can test it.
>>>
>>> Thanks,
>>> Axel
>>> arch/blackfin/lib/board.c | 3 +--
>>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>>
>>> diff --git a/arch/blackfin/lib/board.c b/arch/blackfin/lib/board.c
>>> index f1d5547..9e2e9de 100644
>>> --- a/arch/blackfin/lib/board.c
>>> +++ b/arch/blackfin/lib/board.c
>>> @@ -231,8 +231,6 @@ static int global_board_data_init(void)
>>> bd->bi_sclk = get_sclk();
>>> bd->bi_memstart = CONFIG_SYS_SDRAM_BASE;
>>> bd->bi_memsize = CONFIG_SYS_MAX_RAM_SIZE;
>>> - bd->bi_baudrate = (gd->baudrate > 0)
>>> - ? simple_strtoul(gd->baudrate, NULL, 10) : CONFIG_BAUDRATE;
>>>
>>> return 0;
>>> }
>>> @@ -299,6 +297,7 @@ void board_init_f(ulong bootflag)
>>> env_init();
>>> serial_early_puts("Baudrate init\n");
>>> init_baudrate();
>>> + gd->bd->bi_baudrate = gd->baudrate;
>>
>> I prefer to move this line into init_baudrate().
> hi Sonic,
>
> $ grep -r "int init_baudrate" -A 4 arch
> It shows we have the same implementation for all supported architectures.
>
> So I think init_baudrate() may be moved to a common place in the future.
> I pernsonal prefer keep the code as is in this patch.
> But if you insist on moving this line into init_baudrate(), I have no problem
> to send a v2. Just let me know how do you think.
Yes, please.
Regards,
Sonic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] blackfin: Fix using gd->baudrate before setting its value
Current code uses gd->baudrate before setting its value.
Besides, I got below build warning which is introduced by
commit ddb5c5be "blackfin: add baudrate to bdinfo".
board.c:235:3: warning: passing argument 1 of 'simple_strtoul' makes pointer
from integer without a cast [enabled by default]
include/vsprintf.h:27:7: note: expected 'const char *' but argument is of type
'unsigned int'
This patch ensures we get the baudrate setting before using it.
Signed-off-by: Axel Lin
---
v2: The change is based on Sonic 's suggestion:
move "gd->bd->bi_baudrate = gd->baudrate;" into init_baudrate()
arch/blackfin/lib/board.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/blackfin/lib/board.c b/arch/blackfin/lib/board.c
index f1d5547..460c97d 100644
--- a/arch/blackfin/lib/board.c
+++ b/arch/blackfin/lib/board.c
@@ -63,6 +63,7 @@ static int display_banner(void)
static int init_baudrate(void)
{
gd->baudrate = getenv_ulong("baudrate", 10, CONFIG_BAUDRATE);
+ gd->bd->bi_baudrate = gd->baudrate;
return 0;
}
@@ -231,8 +232,6 @@ static int global_board_data_init(void)
bd->bi_sclk = get_sclk();
bd->bi_memstart = CONFIG_SYS_SDRAM_BASE;
bd->bi_memsize = CONFIG_SYS_MAX_RAM_SIZE;
- bd->bi_baudrate = (gd->baudrate > 0)
- ? simple_strtoul(gd->baudrate, NULL, 10) : CONFIG_BAUDRATE;
return 0;
}
--
1.8.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] gpio: spear_gpio: Fix gpio_set_value() implementation
>
> The questions raised here are valid and it forced me to re-read the
> datasheet. For your convenience, I must tell you that the device is actually
> pl061 from ARM, so the driver can also be named so.
>
> The datasheet is here
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0190b/I1002697.html
>
> Quoting from the datasheet
> "The GPIODATA register is the data register. In software control mode,
> values written in the GPIODATA register are transferred onto the GPOUT pins
> if the respective pins have been configured as outputs through the GPIODIR
> register.
>
> In order to write to GPIODATA, the corresponding bits in the mask, resulting
> from the address bus, PADDR[9:2], must be HIGH. Otherwise the bit values
> remain unchanged by the write.
>
> Similarly, the values read from this register are determined for each bit,
> by the mask bit derived from the address used to access the data register,
> PADDR[9:2]. Bits that are 1 in the address mask cause the corresponding bits
> in GPIODATA to be read, and bits that are 0 in the address mask cause the
> corresponding bits in GPIODATA to be read as 0, regardless of their value.
>
> A read from GPIODATA returns the last bit value written if the respective
> pins are configured as output, or it returns the value on the corresponding
> input GPIN bit when these are configured as inputs. All bits are cleared by
> a reset."
>
> After reading all this I am confused about numbering of the gpio's. I think
> the numbering should be from 1 to 8 for a device. And this would mean that
> we should write to *®s->datareg[1 << (gpio - 1)]* instead of the present
> code which is _®s->datareg[1 << (gpio + 2)]_
Hi Vipin,
Thanks for the review and providing the datasheet information.
You mentioned that this is PL061.
So... I just checked the gpio-pl061 driver in linux kernel.
It's writing to _®s->datareg[1 << (gpio + 2)]. and seems no bug
report for this.
And the gpio_get/set implementation in linux kernel has the same behavior as
this patch does:
( below is from linux/drivers/gpio/gpio-pl061.c )
static int pl061_get_value(struct gpio_chip *gc, unsigned offset)
{
struct pl061_gpio *chip = container_of(gc, struct pl061_gpio, gc);
return !!readb(chip->base + (1 << (offset + 2)));
}
static void pl061_set_value(struct gpio_chip *gc, unsigned offset, int value)
{
struct pl061_gpio *chip = container_of(gc, struct pl061_gpio, gc);
writeb(!!value << offset, chip->base + (1 << (offset + 2)));
}
BTW, it would be great if you have the hardware to test.
Regards,
Axel
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] gpio: spear_gpio: Fix gpio_set_value() implementation
On 7/1/2013 11:02 AM, Axel Lin wrote:
The questions raised here are valid and it forced me to re-read the
datasheet. For your convenience, I must tell you that the device is actually
pl061 from ARM, so the driver can also be named so.
The datasheet is here
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0190b/I1002697.html
Quoting from the datasheet
"The GPIODATA register is the data register. In software control mode,
values written in the GPIODATA register are transferred onto the GPOUT pins
if the respective pins have been configured as outputs through the GPIODIR
register.
In order to write to GPIODATA, the corresponding bits in the mask, resulting
from the address bus, PADDR[9:2], must be HIGH. Otherwise the bit values
remain unchanged by the write.
Similarly, the values read from this register are determined for each bit,
by the mask bit derived from the address used to access the data register,
PADDR[9:2]. Bits that are 1 in the address mask cause the corresponding bits
in GPIODATA to be read, and bits that are 0 in the address mask cause the
corresponding bits in GPIODATA to be read as 0, regardless of their value.
A read from GPIODATA returns the last bit value written if the respective
pins are configured as output, or it returns the value on the corresponding
input GPIN bit when these are configured as inputs. All bits are cleared by
a reset."
After reading all this I am confused about numbering of the gpio's. I think
the numbering should be from 1 to 8 for a device. And this would mean that
we should write to *®s->datareg[1<< (gpio - 1)]* instead of the present
code which is _®s->datareg[1<< (gpio + 2)]_
Hi Vipin,
Hello Alex,
Thanks for the review and providing the datasheet information.
You mentioned that this is PL061.
So... I just checked the gpio-pl061 driver in linux kernel.
It's writing to _®s->datareg[1<< (gpio + 2)]. and seems no bug
report for this.
Yes, I see it now. The difference is that we are using a writel and the
datareg is a u32 array.
And the gpio_get/set implementation in linux kernel has the same behavior as
this patch does:
( below is from linux/drivers/gpio/gpio-pl061.c )
static int pl061_get_value(struct gpio_chip *gc, unsigned offset)
{
struct pl061_gpio *chip = container_of(gc, struct pl061_gpio, gc);
return !!readb(chip->base + (1<< (offset + 2)));
}
static void pl061_set_value(struct gpio_chip *gc, unsigned offset, int value)
{
struct pl061_gpio *chip = container_of(gc, struct pl061_gpio, gc);
writeb(!!value<< offset, chip->base + (1<< (offset + 2)));
}
BTW, it would be great if you have the hardware to test.
I am sorry about this. I have now moved to a different group and I have
no access to the hardware
Regards
Vipin
Regards,
Axel
.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb:composite:fix Provide function data when addressing device with only one interface
On Thu, 27 Jun 2013 21:36:09 + (UTC), Tormod Volden wrote: Hi Tormod, > Lukasz Majewski writes: > > > > This commit fixes problems with some non-standard requests send with > > device address instead of interface address > > (bmRequestType.Receipent field). > > > > This happens with dfu-util (debian version: 0.5), which address non > > standard requests (like w_value=0x21 and bRequest=GET_DESCRIPTOR) > > to device. > > > Dear u-boot developers, > > The above comment seems to imply that dfu-util is sending non-standard > requests. For the record, that would be wrong. dfu-util is sending a > standard "get descriptor" request. These always go to the device, not > to an interface. The descriptor it is asking for is, although not > mandatory per the core USB standard, a class-specific descriptor > which is part of the DFU 1.0 standard. So this is all standard. > > While on this topic, I would recommend that you include this > descriptor in the configuration descriptor set, that is, in the > complete configuration descriptor that the host OS usually requests > during enumeration. Also this class-specific descriptor belongs here. > In that case, the OS and libusb will keep a copy of this descriptor, > and dfu-util will not have to send an explicit request (through > libusb_get_descriptor()) to retrieve it. Thanks for explanation. The commit about which we are discussing was a (reasonable) fix for the problem. I need to look into this and came up with proper solution. > > > > Without this fix, the above request is STALLED, and hence causes > > dfu-util to assume some standard configuration (packet size = 1024B > > instead of 4096B) > > Note that this number is the "Maximum number of bytes that the device > can accept per control-write transaction." I need to check this, but AFAIR there was a problem with dfu-util (and probably libusb under the hood) version 0.1 (shipped with "ancient" old stable debian) and 0.5 which is currently in use. > > The DFU transactions should work fine if a smaller packet size is > used - as long as it is larger or equal to the bMaxPacketSize0. Of > course, smaller packets will cause more overhead and be less > efficient, but you must make sure that your device can handle this. I > am not sure from these comments whether the smaller packet size > caused errors in your implementation, or if the problem was just > reduced performance. The change was driven by the need to improve performance, when downloading large files (with roofts) and to silent warning on the dfu-util side. > > Best regards, > Tormod Volden > > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot -- Best regards, Lukasz Majewski Samsung R&D Institute Poland (SRPOL) | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
