Re: [U-Boot] Please pull u-boot-staging/tr...@ti.com
Hi Tom,
On Fri, 17 Aug 2012 14:52:01 -0700, Tom Rini tr...@ti.com wrote:
Hello,
This replaces my previous pull-request and is new warning free on
MAKEALL -a arm for ELDK4.2/5.1/5.2.1.
The following changes since commit
4d3c95f5ea7c737a21cd6b9c59435ee693b3f127:
zfs: Add ZFS filesystem support (2012-08-09 23:42:20 +0200)
are available in the git repository at:
git://git.denx.de/u-boot-staging tr...@ti.com
for you to fetch changes up to
5d26e4de33fab7b132e8a8036ac54176f537d79f:
ARM: add Raspberry Pi model B board, using BCM2835 SoC (2012-08-15
09:43:47 -0700)
John Rigby (1):
u8500: Separating mmc config parameters from driver
Mathieu J. Poirier (10):
snowball: Add support for ux500 based snowball board
u8500: Moving prcmu to cpu directory
snowball: Adding architecture dependent initialisation
snowball: Adding CPU clock initialisation
snowball: Moving to ux500.v2 addess scheme for PRCMU access
snowball: applying power to LAN and GBF controllers
u8500: Moving processor-specific functions to cpu area.
u8500: Enabling power to MMC device on AB8500 V2
armv7: Adding cpu specific cache managmenent
snowball: Adding board specific cache cleanup routine
Stephen Warren (4):
README: fix references to config_cmd_default.h
ARM: arm1176: enable instruction cache in arch_cpu_init()
ARM: add basic support for the Broadcom BCM2835 SoC
ARM: add Raspberry Pi model B board, using BCM2835 SoC
MAINTAINERS|8 +
README |4 +-
arch/arm/cpu/arm1176/bcm2835/Makefile | 37 +
arch/arm/cpu/arm1176/bcm2835/config.mk | 19 +
arch/arm/cpu/arm1176/bcm2835/lowlevel_init.S | 19 +
arch/arm/cpu/arm1176/bcm2835/reset.c | 35 +
arch/arm/cpu/arm1176/bcm2835/timer.c | 55 ++
arch/arm/cpu/arm1176/cpu.c |7 +
arch/arm/cpu/armv7/cpu.c |8 +
arch/arm/cpu/armv7/u8500/Makefile |2 +-
arch/arm/cpu/armv7/u8500/clock.c | 34 +
arch/arm/cpu/armv7/u8500/cpu.c | 192 +
.../arm/cpu/armv7}/u8500/prcmu.c | 128 +++-
arch/arm/include/asm/arch-bcm2835/gpio.h | 66 ++
arch/arm/include/asm/arch-bcm2835/timer.h | 37 +
arch/arm/include/asm/arch-bcm2835/wdog.h | 36 +
arch/arm/include/asm/arch-u8500/clock.h|5 +-
arch/arm/include/asm/arch-u8500/db8500_gpio.h | 42 ++
arch/arm/include/asm/arch-u8500/db8500_pincfg.h| 170 +
arch/arm/include/asm/arch-u8500/hardware.h | 33 +-
.../arm/include/asm/arch-u8500/prcmu.h | 35 +-
arch/arm/include/asm/arch-u8500/sys_proto.h|1 +
board/armltd/vexpress/ca9x4_ct_vxp.c | 21 +-
board/raspberrypi/rpi_b/Makefile | 34 +
board/raspberrypi/rpi_b/rpi_b.c| 34 +
board/st-ericsson/snowball/Makefile| 49 ++
board/st-ericsson/snowball/db8500_pins.h | 745
board/st-ericsson/snowball/snowball.c | 348 +
board/st-ericsson/u8500/Makefile |2 +-
board/st-ericsson/u8500/u8500_href.c | 100 +--
boards.cfg |2 +
drivers/gpio/Makefile |2 +
drivers/gpio/bcm2835_gpio.c| 89 +++
drivers/gpio/db8500_gpio.c | 221 ++
drivers/mmc/arm_pl180_mmci.c | 131 ++--
drivers/mmc/arm_pl180_mmci.h | 27 +-
drivers/serial/serial_pl01x.c |2 +
include/configs/rpi_b.h| 104 +++
include/configs/snowball.h | 266 +++ 39
files changed, 2937 insertions(+), 213 deletions(-) create mode
100644 arch/arm/cpu/arm1176/bcm2835/Makefile create mode 100644
arch/arm/cpu/arm1176/bcm2835/config.mk create mode 100644
arch/arm/cpu/arm1176/bcm2835/lowlevel_init.S create mode 100644
arch/arm/cpu/arm1176/bcm2835/reset.c create mode 100644
arch/arm/cpu/arm1176/bcm2835/timer.c create mode 100644
arch/arm/cpu/armv7/u8500/cpu.c rename {board/st-ericsson =
arch/arm/cpu/armv7}/u8500/prcmu.c (58%) create mode 100644
arch/arm/include/asm/arch-bcm2835/gpio.h create mode 100644
arch/arm/include/asm/arch-bcm2835/timer.h create mode 100644
arch/arm/include/asm/arch-bcm2835/wdog.h create mode 100644
arch/arm/include/asm/arch-u8500/db8500_gpio.h create mode 100644
arch/arm/include/asm/arch-u8500/db8500_pincfg.h rename
board/st-ericsson/u8500/prcmu-fw.h =
arch/arm/include/asm/arch-u8500/prcmu.h (55%) create mode 100644
Re: [U-Boot] [PATCH v9 07/15] ARM: Fix arm720t SPL build
Le 18/08/2012 00:44, Zhong Hongbo a écrit : On 08/18/2012 05:17 AM, Allen Martin wrote: On Thu, Aug 16, 2012 at 04:03:15PM -0700, Zhong Hongbo wrote: On 08/17/2012 05:04 AM, Allen Martin wrote: @@ -167,6 +177,7 @@ stack_setup: adr r0, _start cmp r0, r6 + moveq r9, #0 /* no relocation. relocation offset(r9) = 0 */ Hi Allen, I have already do a patch to fix all the arm common issue: http://patchwork.ozlabs.org/patch/174471/ [V2] arm: Fixed the offset for the no relocation. Hi Allen Thanks for pointing that out, what's the status of that patch? At first, I fix the issue in arm1176 and send it in my s3c64xx patch thread, But Albert suggest me to correct all the arm platform. Is it being reviewed for u-boot/master? Up to now, I have not o receive any response from the patch. My patch is being carried in the u-boot-tegra/master tree and Tom is about to issue a pull request for u-boot-arm. If your patch is going up first I can rebase mine on top of that. Ok, Thanks, hongbo -Allen 1. Somebody is using my non-u-boot e-mail address for u-boot mails... Anyone, please make sure you're using albert.u.b...@aribaud.net, not albert.arib...@free.fr. 2. I'll check Hongbo's patch series sometime on Sunday and do some regression on it. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] spi: fix mxs_spi_slave structure allocation to clear memory
Am 17/08/2012 20:15, schrieb Matt Sealey: Use calloc() instead of malloc() to allocate the mxs_spi_slave structure. Clearing the memory is necessary since most of the time this gets done super early in boot, but on warm reboots, and when SPI probing is done long after the init stages it could actually pick up previously used memory, and things like the chipselect polarity and other data end up being filled with trash data if not explicitly set by the board files. This solves a semi-random, almost unreproducable error whereby SPI devices act very, very strangly on boot. Signed-off-by: Matt Sealey m...@genesi-usa.com --- drivers/spi/mxs_spi.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/spi/mxs_spi.c b/drivers/spi/mxs_spi.c index a037c13..5fa7f2b 100644 --- a/drivers/spi/mxs_spi.c +++ b/drivers/spi/mxs_spi.c @@ -91,7 +91,7 @@ struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs, return NULL; } - mxs_slave = malloc(sizeof(struct mxs_spi_slave)); + mxs_slave = calloc(sizeof(struct mxs_spi_slave), 1); if (!mxs_slave) return NULL; Acked-by: Stefano Babic sba...@denx.de 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
Re: [U-Boot] [PATCH 1/2] spi: fix mxc_spi_slave structure allocation to clear memory
Am 17/08/2012 20:15, schrieb Matt Sealey:
Use calloc() instead of malloc() to allocate the mxc_spi_slave structure.
Clearing the memory is necessary since most of the time this gets done
super early in boot, but on warm reboots, and when SPI probing is done
long after the init stages it could actually pick up previously used memory,
and things like the chipselect polarity and other data end up being filled
with trash data if not explicitly set by the board files.
This solves a semi-random, almost unreproducable error whereby SPI devices
act very, very strangly on boot. Tested on Efika MX over several years..
Signed-off-by: Matt Sealey m...@genesi-usa.com
---
drivers/spi/mxc_spi.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c
index 2e15318..d1dab18 100644
--- a/drivers/spi/mxc_spi.c
+++ b/drivers/spi/mxc_spi.c
@@ -408,7 +408,7 @@ struct spi_slave *spi_setup_slave(unsigned int bus,
unsigned int cs,
if (bus = ARRAY_SIZE(spi_bases))
return NULL;
- mxcs = malloc(sizeof(struct mxc_spi_slave));
+ mxcs = calloc(sizeof(struct mxc_spi_slave), 1);
if (!mxcs) {
puts(mxc_spi: SPI Slave not allocated !\n);
return NULL;
Agree, the structure must be zeroed.
Acked-by: Stefano Babic sba...@denx.de
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
Re: [U-Boot] WARNING: Caches not enabled on openrd based board
Am 17.08.2012 13:16, schrieb Alex Zeffertt: I get the following warning when I boot our openrd based board: U-Boot 2012.07 (Aug 17 2012 - 10:45:29) OpenRD-Base SoC: Kirkwood 88F6281_A1 DRAM: 128 MiB WARNING: Caches not enabled NAND: 512 MiB The warning tells you that the plaform has no implementation of function enable_caches. At the moment the l2cache and icache is enabled in function arch_misc_init. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] common/lcd: add protection from null bmp pointer
Hi,
On 08/16/2012 12:43 PM, Nikita Kiryanov wrote:
If the bmp pointer is null (for example because the environment
variable splashimage was not defined) then U-Boot will get stuck
when trying to load the image.
Which branch is this? At [1] there is a check for this..
1600 s = getenv(splashimage);
1601 if (s != NULL) {
...
Regards,
Jeroen
[1] drivers/video/cfb_console.c.
Just ignore above, since there are apparently more BMP drawing routines,
and I mentioned the wrong one. The same check is in lcd.c though:
822: if (do_splash (s = getenv(splashimage)) != NULL) {
Regards,
Jeroen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [[Patch V2] mips: 01/16] add mips64 standalone support
On Sat, Aug 18, 2012 at 3:31 AM, Mike Frysinger vap...@gentoo.org wrote: On Friday 17 August 2012 11:30:44 Zhizhou Zhang wrote: --- a/arch/mips/config.mk +++ b/arch/mips/config.mk +ifeq $(CPU) mips64 +CONFIG_STANDALONE_LOAD_ADDR ?= 0xFfffFfff8020 -T mips64.lds +else CONFIG_STANDALONE_LOAD_ADDR ?= 0x8020 -T mips.lds +endif the cpu config.mk is sourced after this one. you could change this to: CONFIG_STANDALONE_LOAD_ADDR ?= $(DEFAULT_MIPS_STANDALONE_LOAD_ADDR) DEFAULT_MIPS_STANDALONE_LOAD_ADDR = 0x8020 -T mips.lds then in the mips64/config.mk: DEFAULT_MIPS_STANDALONE_LOAD_ADDR = 0xFfffFfff8020 -T mips64.lds -mike Thanks for you advising. But if I changed like so, I should modify mips32/ config.mk and xburst/config.mk as also. I think that's not good for modified too much files. -- Regards, Zhizhou Zhang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-staging/tr...@ti.com
On Sat, Aug 18, 2012 at 08:28:55AM +0200, Albert ARIBAUD wrote:
Hi Tom,
On Fri, 17 Aug 2012 14:52:01 -0700, Tom Rini tr...@ti.com wrote:
Hello,
This replaces my previous pull-request and is new warning free on
MAKEALL -a arm for ELDK4.2/5.1/5.2.1.
The following changes since commit
4d3c95f5ea7c737a21cd6b9c59435ee693b3f127:
zfs: Add ZFS filesystem support (2012-08-09 23:42:20 +0200)
are available in the git repository at:
git://git.denx.de/u-boot-staging tr...@ti.com
for you to fetch changes up to
5d26e4de33fab7b132e8a8036ac54176f537d79f:
ARM: add Raspberry Pi model B board, using BCM2835 SoC (2012-08-15
09:43:47 -0700)
John Rigby (1):
u8500: Separating mmc config parameters from driver
Mathieu J. Poirier (10):
snowball: Add support for ux500 based snowball board
u8500: Moving prcmu to cpu directory
snowball: Adding architecture dependent initialisation
snowball: Adding CPU clock initialisation
snowball: Moving to ux500.v2 addess scheme for PRCMU access
snowball: applying power to LAN and GBF controllers
u8500: Moving processor-specific functions to cpu area.
u8500: Enabling power to MMC device on AB8500 V2
armv7: Adding cpu specific cache managmenent
snowball: Adding board specific cache cleanup routine
Stephen Warren (4):
README: fix references to config_cmd_default.h
ARM: arm1176: enable instruction cache in arch_cpu_init()
ARM: add basic support for the Broadcom BCM2835 SoC
ARM: add Raspberry Pi model B board, using BCM2835 SoC
MAINTAINERS|8 +
README |4 +-
arch/arm/cpu/arm1176/bcm2835/Makefile | 37 +
arch/arm/cpu/arm1176/bcm2835/config.mk | 19 +
arch/arm/cpu/arm1176/bcm2835/lowlevel_init.S | 19 +
arch/arm/cpu/arm1176/bcm2835/reset.c | 35 +
arch/arm/cpu/arm1176/bcm2835/timer.c | 55 ++
arch/arm/cpu/arm1176/cpu.c |7 +
arch/arm/cpu/armv7/cpu.c |8 +
arch/arm/cpu/armv7/u8500/Makefile |2 +-
arch/arm/cpu/armv7/u8500/clock.c | 34 +
arch/arm/cpu/armv7/u8500/cpu.c | 192 +
.../arm/cpu/armv7}/u8500/prcmu.c | 128 +++-
arch/arm/include/asm/arch-bcm2835/gpio.h | 66 ++
arch/arm/include/asm/arch-bcm2835/timer.h | 37 +
arch/arm/include/asm/arch-bcm2835/wdog.h | 36 +
arch/arm/include/asm/arch-u8500/clock.h|5 +-
arch/arm/include/asm/arch-u8500/db8500_gpio.h | 42 ++
arch/arm/include/asm/arch-u8500/db8500_pincfg.h| 170 +
arch/arm/include/asm/arch-u8500/hardware.h | 33 +-
.../arm/include/asm/arch-u8500/prcmu.h | 35 +-
arch/arm/include/asm/arch-u8500/sys_proto.h|1 +
board/armltd/vexpress/ca9x4_ct_vxp.c | 21 +-
board/raspberrypi/rpi_b/Makefile | 34 +
board/raspberrypi/rpi_b/rpi_b.c| 34 +
board/st-ericsson/snowball/Makefile| 49 ++
board/st-ericsson/snowball/db8500_pins.h | 745
board/st-ericsson/snowball/snowball.c | 348 +
board/st-ericsson/u8500/Makefile |2 +-
board/st-ericsson/u8500/u8500_href.c | 100 +--
boards.cfg |2 +
drivers/gpio/Makefile |2 +
drivers/gpio/bcm2835_gpio.c| 89 +++
drivers/gpio/db8500_gpio.c | 221 ++
drivers/mmc/arm_pl180_mmci.c | 131 ++--
drivers/mmc/arm_pl180_mmci.h | 27 +-
drivers/serial/serial_pl01x.c |2 +
include/configs/rpi_b.h| 104 +++
include/configs/snowball.h | 266 +++ 39
files changed, 2937 insertions(+), 213 deletions(-) create mode
100644 arch/arm/cpu/arm1176/bcm2835/Makefile create mode 100644
arch/arm/cpu/arm1176/bcm2835/config.mk create mode 100644
arch/arm/cpu/arm1176/bcm2835/lowlevel_init.S create mode 100644
arch/arm/cpu/arm1176/bcm2835/reset.c create mode 100644
arch/arm/cpu/arm1176/bcm2835/timer.c create mode 100644
arch/arm/cpu/armv7/u8500/cpu.c rename {board/st-ericsson =
arch/arm/cpu/armv7}/u8500/prcmu.c (58%) create mode 100644
arch/arm/include/asm/arch-bcm2835/gpio.h create mode 100644
arch/arm/include/asm/arch-bcm2835/timer.h create mode 100644
arch/arm/include/asm/arch-bcm2835/wdog.h create mode 100644
arch/arm/include/asm/arch-u8500/db8500_gpio.h create mode 100644
Re: [U-Boot] [PATCH] mx5: add iomux-mx51.h include
On 17/08/2012 20:16, Matt Sealey wrote:
Essentially now we can share code with the MX6 boards, reducing redundant
pin definitions across boards and lengthy configuration of external pads
on the i.MX51.
Signed-off-by: Matt Sealey m...@genesi-usa.com
---
Hi Matt,
arch/arm/include/asm/arch-mx5/iomux-mx51.h | 144
1 file changed, 144 insertions(+)
create mode 100644 arch/arm/include/asm/arch-mx5/iomux-mx51.h
As far as I can see iomux-mx51.h is coming from the linux kernel. Then
please add in the commit message information about which version of the
kernel you borrow this code, better add the kernel commit-id. This
allows to have a track where the code is coming from.
+/*
+ * this is in imx-regs.h for i.MX6 but it probably should be in
+ * imx-common/iomux-v3.h - however, since we're trying to be
+ * compatible with all the other boards using this include, and
+ * i.MX6 has this defined in arch-mx5/imx_regs.h we don't want
+ * to create a build breakage or even just a warning at this time.
+ *
+ * So, we can move it to imx-common/iomux-v3.h when this is all
+ * figured out, and all i.MX5+ boards use the common iomux-v3
+ * functionality, but until then it's needlessly duplicated here.
+ */
+#define GPIO_NUMBER(port, index) port)-1)*32)+((index)31))
I do like we add a second identical defeine why we discover an issue in
another part of code. I know for experience that code introduced this
the goal to fix it later will never be fixed. So let's see if we can jut
do the right thing.
I do not think imx-common/iomux-v3.h is the right place. What has the
pinmux with gpio to do ? This is also wrongit is GPIO related, it
should go into gpio.h.
Well, I see there are 6 gpio.h, and each of them is declaring the same
structure:
./arch/arm/include/asm/arch-mx6/gpio.h
./arch/arm/include/asm/arch-mx31/gpio.h
./arch/arm/include/asm/arch-mxs/gpio.h
./arch/arm/include/asm/arch-mx5/gpio.h
./arch/arm/include/asm/arch-mx35/gpio.h
./arch/arm/include/asm/arch-mx25/gpio.h
What a crap ! Time to clean up. I have prepared a patch, I will send to
ML for review. If we agree then how to proceed, you can drop this stuff
from here.
+
+/*
+ * The naming convention for the pad modes is MX51_PAD_padname__padmode
+ * If padname or padmode refers to a GPIO, it is named GPIOunit_num
+ * See also iomux-v3.h
+ */
+
+/*
PADMUX ALT INPSE PATH PADCTRL */
+enum {
+ MX51_PAD_EIM_CS0__GPIO2_25 = IOMUX_PAD(0x474,
0x0e0, 1, __NA_, 0, MX51_GPIO_PAD_CTRL),
+ MX51_PAD_EIM_CS2__SD1_CD= IOMUX_PAD(0x47c,
0x0e8, 1, __NA_, 0, MX51_ESDHC_PAD_CTRL),
+ MX51_PAD_EIM_CS3__GPIO2_28 = IOMUX_PAD(0x480,
0x0ec, 1, __NA_, 0, MX51_GPIO_PAD_CTRL),
+ MX51_PAD_EIM_CS4__GPIO2_29 = IOMUX_PAD(0x484,
0x0f0, 1, __NA_, 0, MX51_GPIO_PAD_CTRL),
+ MX51_PAD_NANDF_WE_B__PATA_DIOW = IOMUX_PAD(0x4e4, 0x108, 1,
__NA_, 0, NO_PAD_CTRL),
+ MX51_PAD_NANDF_RE_B__PATA_DIOR = IOMUX_PAD(0x4e8, 0x10c, 1,
__NA_, 0, NO_PAD_CTRL),
+ MX51_PAD_NANDF_ALE__PATA_BUFFER_EN = IOMUX_PAD(0x4ec, 0x110, 1,
__NA_, 0, NO_PAD_CTRL),
+ MX51_PAD_NANDF_CLE__PATA_RESET_B= IOMUX_PAD(0x4f0, 0x114, 1,
__NA_, 0, NO_PAD_CTRL),
+ MX51_PAD_NANDF_WP_B__PATA_DMACK = IOMUX_PAD(0x4f4, 0x118, 1,
__NA_, 0, NO_PAD_CTRL),
+ MX51_PAD_NANDF_RB0__PATA_DMARQ = IOMUX_PAD(0x4f8, 0x11c, 1,
__NA_, 0, NO_PAD_CTRL),
+ MX51_PAD_NANDF_RB1__PATA_IORDY = IOMUX_PAD(0x4fc, 0x120, 1,
__NA_, 0, NO_PAD_CTRL),
+ MX51_PAD_GPIO_NAND__PATA_INTRQ = IOMUX_PAD(0x514, 0x12c, 1,
__NA_, 0, NO_PAD_CTRL),
+ MX51_PAD_NANDF_CS2__PATA_CS_0 = IOMUX_PAD(0x520, 0x138, 1,
__NA_, 0, NO_PAD_CTRL),
+ MX51_PAD_NANDF_CS3__PATA_CS_1 = IOMUX_PAD(0x524, 0x13c, 1,
__NA_, 0, NO_PAD_CTRL),
+ MX51_PAD_NANDF_CS4__PATA_DA_0 = IOMUX_PAD(0x528, 0x140, 1,
__NA_, 0, NO_PAD_CTRL),
+ MX51_PAD_NANDF_CS5__PATA_DA_1 = IOMUX_PAD(0x52c, 0x144, 1,
__NA_, 0, NO_PAD_CTRL),
+ MX51_PAD_NANDF_CS6__PATA_DA_2 = IOMUX_PAD(0x530, 0x148, 1,
__NA_, 0, NO_PAD_CTRL),
+ MX51_PAD_NANDF_D15__PATA_DATA15 = IOMUX_PAD(0x53c, 0x154, 1,
__NA_, 0, NO_PAD_CTRL),
+ MX51_PAD_NANDF_D14__PATA_DATA14 = IOMUX_PAD(0x540, 0x158, 1,
__NA_, 0, NO_PAD_CTRL),
+ MX51_PAD_NANDF_D13__PATA_DATA13 = IOMUX_PAD(0x544, 0x15c, 1,
__NA_, 0, NO_PAD_CTRL),
+ MX51_PAD_NANDF_D12__PATA_DATA12 = IOMUX_PAD(0x548, 0x160, 1,
__NA_, 0, NO_PAD_CTRL),
+ MX51_PAD_NANDF_D11__PATA_DATA11 = IOMUX_PAD(0x54c, 0x164, 1,
__NA_, 0, NO_PAD_CTRL),
+ MX51_PAD_NANDF_D10__PATA_DATA10 = IOMUX_PAD(0x550, 0x168, 1,
__NA_, 0, NO_PAD_CTRL),
+
Re: [U-Boot] [PATCH 1/2] MX28: config: Allow different target generation in elftosb call
Dear Otavio Salvador,
The elftosb call needs to use a target param specific for i.MX28. This
patch allow for later addition of i.MX233.
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
Makefile |5 -
arch/arm/cpu/arm926ejs/mxs/{u-boot.bd = u-boot.bd.imx28} |0
2 files changed, 4 insertions(+), 1 deletion(-)
rename arch/arm/cpu/arm926ejs/mxs/{u-boot.bd = u-boot.bd.imx28} (100%)
diff --git a/Makefile b/Makefile
index f6471e2..5f11bb7 100644
--- a/Makefile
+++ b/Makefile
@@ -452,8 +452,11 @@ $(obj)u-boot.ais: $(obj)spl/u-boot-spl.bin
$(obj)u-boot.bin cat $(obj)spl/u-boot-spl-pad.ais $(obj)u-boot.bin \
$(obj)u-boot.ais
+# Specify the target for use in elftosb call
+ELFTOSB_TARGET-$(CONFIG_MX28) = imx28
+
$(obj)u-boot.sb: $(obj)u-boot.bin $(obj)spl/u-boot-spl.bin
- elftosb -zdf imx28 -c $(TOPDIR)/$(CPUDIR)/$(SOC)/u-boot.bd \
+ elftosb -zdf $(ELFTOSB_TARGET-y) -c
$(TOPDIR)/$(CPUDIR)/$(SOC)/u-boot.bd.$(ELFTOSB_TARGET-y) \ -o
$(obj)u-boot.sb
Swap this to u-boot.$(ELFTOSB_TARGET-y).bd ... so the .bd suffix is always at
the end.
# On x600 (SPEAr600) U-Boot is appended to U-Boot SPL.
diff --git a/arch/arm/cpu/arm926ejs/mxs/u-boot.bd
b/arch/arm/cpu/arm926ejs/mxs/u-boot.bd.imx28 similarity index 100%
rename from arch/arm/cpu/arm926ejs/mxs/u-boot.bd
rename to arch/arm/cpu/arm926ejs/mxs/u-boot.bd.imx28
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] MX28: Move regs-base.h include after SoC type configuration
Dear Otavio Salvador, For i.MX233 addition the base registers need to be change so the SoC definition needs to be known before the header include. The following boards has been changed: * apx4devkit * m28evk * mx28evk * sc_sps_1 Signed-off-by: Otavio Salvador ota...@ossystems.com.br --- include/configs/apx4devkit.h |4 ++-- include/configs/m28evk.h |4 ++-- include/configs/mx28evk.h|5 +++-- include/configs/sc_sps_1.h |4 ++-- 4 files changed, 9 insertions(+), 8 deletions(-) Seems ok to me Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] MX: Set a common gpio.h for all i.MX
Each i.MX has its own gpio.h, defining the same structure.
The internal GPIO controller has the same layout
(at least for the register used by u-boot) and can be shared.
Signed-off-by: Stefano Babic sba...@denx.de
CC: Matt Sealey m...@genesi-usa.com
CC: Marek Vasut ma...@denx.de
CC: Benoit Thebaudeau benoit.thebaud...@advansee.com
CC: Jason Liu jason@linaro.org
---
arch/arm/include/asm/arch-mx25/gpio.h| 12 +
arch/arm/include/asm/arch-mx31/gpio.h|7 +-
arch/arm/include/asm/arch-mx35/gpio.h| 12 +
arch/arm/include/asm/arch-mx5/gpio.h |7 +-
arch/arm/include/asm/arch-mx6/gpio.h |7 +-
arch/arm/include/asm/arch-mx6/imx-regs.h |2 --
arch/arm/include/asm/imx-common/gpio.h | 39 ++
include/configs/mx6qsabrelite.h |1 +
8 files changed, 45 insertions(+), 42 deletions(-)
create mode 100644 arch/arm/include/asm/imx-common/gpio.h
diff --git a/arch/arm/include/asm/arch-mx25/gpio.h
b/arch/arm/include/asm/arch-mx25/gpio.h
index dc6edc7..5ab1f6d 100644
--- a/arch/arm/include/asm/arch-mx25/gpio.h
+++ b/arch/arm/include/asm/arch-mx25/gpio.h
@@ -30,16 +30,6 @@
*/
#define MXC_GPIO_PORT_TO_NUM(port, bit) (((port - 1) 5) + (bit 0x1f))
-/* GPIO registers */
-struct gpio_regs {
- u32 gpio_dr;/* data */
- u32 gpio_dir; /* direction */
- u32 psr;/* pad satus */
- u32 icr1; /* interrupt config 1 */
- u32 icr2; /* interrupt config 2 */
- u32 imr;/* interrupt mask */
- u32 isr;/* interrupt status */
- u32 edge_sel; /* edge select */
-};
+#include asm/imx-common/gpio.h
#endif
diff --git a/arch/arm/include/asm/arch-mx31/gpio.h
b/arch/arm/include/asm/arch-mx31/gpio.h
index 95b73bf..55c0afa 100644
--- a/arch/arm/include/asm/arch-mx31/gpio.h
+++ b/arch/arm/include/asm/arch-mx31/gpio.h
@@ -25,11 +25,6 @@
#ifndef __ASM_ARCH_MX31_GPIO_H
#define __ASM_ARCH_MX31_GPIO_H
-/* GPIO Registers */
-struct gpio_regs {
- u32 gpio_dr;
- u32 gpio_dir;
- u32 gpio_psr;
-};
+#include asm/imx-common/gpio.h
#endif
diff --git a/arch/arm/include/asm/arch-mx35/gpio.h
b/arch/arm/include/asm/arch-mx35/gpio.h
index 7bcc3e8..1deb292 100644
--- a/arch/arm/include/asm/arch-mx35/gpio.h
+++ b/arch/arm/include/asm/arch-mx35/gpio.h
@@ -25,16 +25,6 @@
#ifndef __ASM_ARCH_MX35_GPIO_H
#define __ASM_ARCH_MX35_GPIO_H
-/* GPIO registers */
-struct gpio_regs {
- u32 gpio_dr;/* data */
- u32 gpio_dir; /* direction */
- u32 psr;/* pad satus */
- u32 icr1; /* interrupt config 1 */
- u32 icr2; /* interrupt config 2 */
- u32 imr;/* interrupt mask */
- u32 isr;/* interrupt status */
- u32 edge_sel; /* edge select */
-};
+#include asm/imx-common/gpio.h
#endif
diff --git a/arch/arm/include/asm/arch-mx5/gpio.h
b/arch/arm/include/asm/arch-mx5/gpio.h
index 1dc34e9..b1b1218 100644
--- a/arch/arm/include/asm/arch-mx5/gpio.h
+++ b/arch/arm/include/asm/arch-mx5/gpio.h
@@ -25,11 +25,6 @@
#ifndef __ASM_ARCH_MX5_GPIO_H
#define __ASM_ARCH_MX5_GPIO_H
-/* GPIO registers */
-struct gpio_regs {
- u32 gpio_dr;
- u32 gpio_dir;
- u32 gpio_psr;
-};
+#include asm/imx-common/gpio.h
#endif
diff --git a/arch/arm/include/asm/arch-mx6/gpio.h
b/arch/arm/include/asm/arch-mx6/gpio.h
index 20c4e57..24c10f8 100644
--- a/arch/arm/include/asm/arch-mx6/gpio.h
+++ b/arch/arm/include/asm/arch-mx6/gpio.h
@@ -25,11 +25,6 @@
#ifndef __ASM_ARCH_MX6_GPIO_H
#define __ASM_ARCH_MX6_GPIO_H
-/* GPIO registers */
-struct gpio_regs {
- u32 gpio_dr;
- u32 gpio_dir;
- u32 gpio_psr;
-};
+#include asm/imx-common/gpio.h
#endif /* __ASM_ARCH_MX6_GPIO_H */
diff --git a/arch/arm/include/asm/arch-mx6/imx-regs.h
b/arch/arm/include/asm/arch-mx6/imx-regs.h
index 5d77603..f3e58b5 100644
--- a/arch/arm/include/asm/arch-mx6/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx6/imx-regs.h
@@ -172,8 +172,6 @@
#define IMX_IIM_BASE OCOTP_BASE_ADDR
#define FEC_QUIRK_ENET_MAC
-#define GPIO_NUMBER(port, index) port)-1)*32)+((index)31))
-
#if !(defined(__KERNEL_STRICT_NAMES) || defined(__ASSEMBLY__))
#include asm/types.h
diff --git a/arch/arm/include/asm/imx-common/gpio.h
b/arch/arm/include/asm/imx-common/gpio.h
new file mode 100644
index 000..fcc25e8
--- /dev/null
+++ b/arch/arm/include/asm/imx-common/gpio.h
@@ -0,0 +1,39 @@
+/*
+ * Copyright (C) 2011
+ * Stefano Babic, DENX Software Engineering, sba...@denx.de
+ *
+ * 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
Re: [U-Boot] [PATCH 2/4] efikamx: remove drive strength hack from early_init_f and move it to the DCD
On 17/08/2012 20:19, Matt Sealey wrote: The i.MX Boot ROM lets us set up certain registers before U-Boot even gets executed. Rather than setting up DDR, putting U-Boot in place, and getting into pre-relocation init to set up DDR again, just do it once in the correct place. This also solves an issue where the Smarttop DDR pad settings were being applied on Smartbook. While we're at it, configure PCBID0,1,2 and the LED GPIO since we've still got room in the DCD to do so. Signed-off-by: Matt Sealey m...@genesi-usa.com --- Hi Matt, diff --git a/board/genesi/mx51_efikamx/imximage_mx.cfg b/board/genesi/mx51_efikamx/imximage_mx.cfg index 6fe0ff9..ac9aa9a 100644 --- a/board/genesi/mx51_efikamx/imximage_mx.cfg +++ b/board/genesi/mx51_efikamx/imximage_mx.cfg @@ -1,7 +1,7 @@ # +# Copyright (C) 2009 Pegatron Corporation ^--- Was this added for mistake ? I think you should add only yours. # Copyright (C) 2010 Marek Vasut marek.va...@gmail.com -# -# BASED ON: imx51evk +# Copyright (C) 2009-2012 Genesi USA, Inc. # # (C) Copyright 2009 # Stefano Babic DENX Software Engineering sba...@denx.de. @@ -43,48 +43,44 @@ BOOT_FROM spi #Address absolute address of the register #value value to be stored in the register I agree with Marek that you break the copyright stuff. -# Setting IOMUXC -DATA 4 0x73fa88a0 0x000 -DATA 4 0x73fa850c 0x20c5 -DATA 4 0x73fa8510 0x20c5 -DATA 4 0x73fa883c 0x5 -DATA 4 0x73fa8848 0x5 -DATA 4 0x73fa84b8 0xe7 -DATA 4 0x73fa84bc 0x45 -DATA 4 0x73fa84c0 0x45 -DATA 4 0x73fa84c4 0x45 -DATA 4 0x73fa84c8 0x45 -DATA 4 0x73fa8820 0x0 -DATA 4 0x73fa84a4 0x5 -DATA 4 0x73fa84a8 0x5 -DATA 4 0x73fa84ac 0xe5 -DATA 4 0x73fa84b0 0xe5 -DATA 4 0x73fa84b4 0xe5 -DATA 4 0x73fa84cc 0xe5 -DATA 4 0x73fa84d0 0xe4 +# Essential GPIO settings to be done as early as possible +# PCBID pad settings are all the defaults except #2 which needs HVE off +DATA 4 0x73fa8134 0x3# PCBID0 ALT3 GPIO 3_16 +DATA 4 0x73fa8130 0x3# PCBID1 ALT3 GPIO 3_17 +DATA 4 0x73fa8128 0x3# PCBID2 ALT3 GPIO 3_11 +DATA 4 0x73fa8504 0xe4 # PCBID2 PAD ~HVE +DATA 4 0x73fa8198 0x3# LED0 ALT3 GPIO 3_13 +DATA 4 0x73fa81c4 0x3# LED1 ALT3 GPIO 3_14 +DATA 4 0x73fa81c8 0x3# LED2 ALT3 GPIO 3_15 -DATA 4 0x73fa882c 0x4 -DATA 4 0x73fa88a4 0x4 -DATA 4 0x73fa88ac 0x4 -DATA 4 0x73fa88b8 0x4 +# DDR bus IOMUX PAD settings +DATA 4 0x73fa850c 0x20c5 # SDODT1 +DATA 4 0x73fa8510 0x20c5 # SDODT0 +DATA 4 0x73fa84ac 0xc5 # SDWE +DATA 4 0x73fa84b0 0xc5 # SDCKE0 +DATA 4 0x73fa84b4 0xc5 # SDCKE1 +DATA 4 0x73fa84cc 0xc5 # DRAM_CS0 +DATA 4 0x73fa84d0 0xc5 # DRAM_CS1 +DATA 4 0x73fa882c 0x2# DRAM_B4 +DATA 4 0x73fa88a4 0x2# DRAM_B0 +DATA 4 0x73fa88ac 0x2# DRAM_B1 +DATA 4 0x73fa88b8 0x2# DRAM_B2 +DATA 4 0x73fa84d4 0xc5 # DRAM_DQM0 +DATA 4 0x73fa84d8 0xc5 # DRAM_DQM1 +DATA 4 0x73fa84dc 0xc5 # DRAM_DQM2 +DATA 4 0x73fa84e0 0xc5 # DRAM_DQM3 -# Setting DDR for micron -# 13 Rows, 10 Cols, 32 bit, SREF=4 Micron Model -# CAS=3 BL=4 -# ESDCTL_ESDCTL0 -DATA 4 0x83fd9000 0x82a2 -# ESDCTL_ESDCTL1 -DATA 4 0x83fd9008 0x82a2 -# ESDCTL_ESDMISC -DATA 4 0x83fd9010 0xcaaaf6d0 -# ESDCTL_ESDCFG0 -DATA 4 0x83fd9004 0x3f3574aa -# ESDCTL_ESDCFG1 -DATA 4 0x83fd900c 0x3f3574aa +# Setting DDR for Micron +# 13 Rows, 10 Cols, 32 bit +# SREF=4 Micron Model CAS=3 BL=4 +DATA 4 0x83fd9000 0x82a2 # ESDCTL_ESDCTL0 +DATA 4 0x83fd9008 0x82a2 # ESDCTL_ESDCTL1 +DATA 4 0x83fd9010 0xcaaaf6d0 # ESDCTL_ESDMISC +DATA 4 0x83fd9004 0x3f3574aa # ESDCTL_ESDCFG0 +DATA 4 0x83fd900c 0x3f3574aa # ESDCTL_ESDCFG1 # Init DRAM on CS0 -# ESDCTL_ESDSCR -DATA 4 0x83fd9014 0x04008008 +DATA 4 0x83fd9014 0x04008008 # ESDCTL_ESDSCR DATA 4 0x83fd9014 0x801a DATA 4 0x83fd9014 0x801b DATA 4 0x83fd9014 0x00448019 @@ -110,13 +106,8 @@ DATA 4 0x83fd9014 0x0632801c DATA 4 0x83fd9014 0x0380801d DATA 4 0x83fd9014 0x0040801d DATA 4 0x83fd9014 0x8004 - -# Write to CTL0 -DATA 4 0x83fd9000 0xb2a2 -# Write to CTL1 -DATA 4 0x83fd9008 0xb2a2 -# ESDMISC -DATA 4 0x83fd9010 0x000ad6d0 -#ESDCTL_ESDCDLYGD -DATA 4 0x83fd9034 0x9000 +DATA 4 0x83fd9000 0xb2a2 # Write to CTL0 +DATA 4 0x83fd9008 0xb2a2 # Write to CTL1 +DATA 4 0x83fd9010 0x000ad6d0 # ESDMISC +DATA 4 0x83fd9034 0x9000 # ESDCTL_ESDCDLYGD DATA 4 0x83fd9014 0x I join Marek, it is quite difficult to review it and understand which was changed. It looks like a new file.. Best regards, Stefano Babic --
Re: [U-Boot] [[Patch V2] mips: 01/16] add mips64 standalone support
On Saturday 18 August 2012 08:22:51 Zhi-zhou Zhang wrote: On Sat, Aug 18, 2012 at 3:31 AM, Mike Frysinger wrote: On Friday 17 August 2012 11:30:44 Zhizhou Zhang wrote: --- a/arch/mips/config.mk +++ b/arch/mips/config.mk +ifeq $(CPU) mips64 +CONFIG_STANDALONE_LOAD_ADDR ?= 0xFfffFfff8020 -T mips64.lds +else CONFIG_STANDALONE_LOAD_ADDR ?= 0x8020 -T mips.lds +endif the cpu config.mk is sourced after this one. you could change this to: CONFIG_STANDALONE_LOAD_ADDR ?= $(DEFAULT_MIPS_STANDALONE_LOAD_ADDR) DEFAULT_MIPS_STANDALONE_LOAD_ADDR = 0x8020 -T mips.lds then in the mips64/config.mk: DEFAULT_MIPS_STANDALONE_LOAD_ADDR = 0xFfffFfff8020 -T mips64.lds Thanks for you advising. But if I changed like so, I should modify mips32/ config.mk and xburst/config.mk as also. why ? my suggestion shouldn't affect any other cpu config.mk. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] efikamx: update to Efika MX Smarttop and Smartbook boards
On 17/08/2012 20:19, Matt Sealey wrote:
Change summary:
* Use iomux-mx51.h include to simplify board configuration.
* Remove LED toggle function as it had no real users.
* Red LED is now on for pre-reloc, Blue LED for in U-Boot
* Function renames for readability.
* Some board identification string changes
* Reduce CPU core voltage to 1.1V (per TO3 spec)
* Implicitly remove support for TO2 boards
Signed-off-by: Matt Sealey m...@genesi-usa.com
---
Hi Matt,
board/genesi/mx51_efikamx/efikamx.c | 611
+--
1 file changed, 230 insertions(+), 381 deletions(-)
diff --git a/board/genesi/mx51_efikamx/efikamx.c
b/board/genesi/mx51_efikamx/efikamx.c
index 12371c9..16e877f 100644
--- a/board/genesi/mx51_efikamx/efikamx.c
+++ b/board/genesi/mx51_efikamx/efikamx.c
@@ -1,7 +1,7 @@
/*
+ * Copyright (C) 2009 Freescale Semiconductor, Inc.
* Copyright (C) 2010 Marek Vasut marek.va...@gmail.com
- *
- * (C) Copyright 2009 Freescale Semiconductor, Inc.
+ * Copyright (C) 2009-2012 Genesi USA, Inc.
*
* See file CREDITS for list of people who contributed to this
* project.
@@ -24,9 +24,7 @@
#include common.h
#include asm/io.h
-#include asm/arch/imx-regs.h
-#include asm/arch/mx5x_pins.h
-#include asm/arch/iomux.h
+#include asm/arch/iomux-mx51.h
#include asm/gpio.h
#include asm/errno.h
#include asm/arch/sys_proto.h
@@ -48,16 +46,12 @@ DECLARE_GLOBAL_DATA_PTR;
#endif
/*
- * Shared variables / local defines
+ * Board revisions
+ *
+ * Note that we get these revisions here for convenience, but we only set
+ * up for the production model Smarttop (1.3) and Smartbook (2.0).
+ *
*/
-/* LED */
-#define EFIKAMX_LED_BLUE0x1
-#define EFIKAMX_LED_GREEN 0x2
-#define EFIKAMX_LED_RED 0x4
-
-void efikamx_toggle_led(uint32_t mask);
-
-/* Board revisions */
#define EFIKAMX_BOARD_REV_110x1
#define EFIKAMX_BOARD_REV_120x2
#define EFIKAMX_BOARD_REV_130x3
@@ -69,66 +63,67 @@ void efikamx_toggle_led(uint32_t mask);
/*
* Board identification
*/
-u32 get_efikamx_rev(void)
+static u32 get_mx_rev(void)
{
u32 rev = 0;
/*
* Retrieve board ID:
- * rev1.1: 1,1,1
- * rev1.2: 1,1,0
- * rev1.3: 1,0,1
- * rev1.4: 1,0,0
+ *
+ * gpio: 16 17 11
+ * ==
+ * r1.1: 1+ 1 1
+ * r1.2: 1 1 0
+ * r1.3: 1 0 1
+ * r1.4: 1 0 0
+ *
+ * + note: r1.1 does not strap this pin properly so it needs to
+ * be hacked or ignored.
*/
- mxc_request_iomux(MX51_PIN_NANDF_CS0, IOMUX_CONFIG_GPIO);
- /* set to 1 in order to get correct value on board rev1.1 */
- gpio_direction_output(IOMUX_TO_GPIO(MX51_PIN_NANDF_CS0), 1);
+
+ /* set to 1 in order to get correct value on board rev 1.1 */
+ gpio_direction_output(GPIO_NUMBER(3, 16), 1);
+ gpio_direction_input(GPIO_NUMBER(3, 11));
+ gpio_direction_input(GPIO_NUMBER(3, 16));
+ gpio_direction_input(GPIO_NUMBER(3, 17));
- mxc_request_iomux(MX51_PIN_NANDF_CS0, IOMUX_CONFIG_GPIO);
- mxc_iomux_set_pad(MX51_PIN_NANDF_CS0, PAD_CTL_100K_PU);
- gpio_direction_input(IOMUX_TO_GPIO(MX51_PIN_NANDF_CS0));
- rev |= (!!gpio_get_value(IOMUX_TO_GPIO(MX51_PIN_NANDF_CS0))) 0;
-
- mxc_request_iomux(MX51_PIN_NANDF_CS1, IOMUX_CONFIG_GPIO);
- mxc_iomux_set_pad(MX51_PIN_NANDF_CS1, PAD_CTL_100K_PU);
- gpio_direction_input(IOMUX_TO_GPIO(MX51_PIN_NANDF_CS1));
- rev |= (!!gpio_get_value(IOMUX_TO_GPIO(MX51_PIN_NANDF_CS1))) 1;
-
- mxc_request_iomux(MX51_PIN_NANDF_RB3, IOMUX_CONFIG_GPIO);
- mxc_iomux_set_pad(MX51_PIN_NANDF_RB3, PAD_CTL_100K_PU);
- gpio_direction_input(IOMUX_TO_GPIO(MX51_PIN_NANDF_RB3));
- rev |= (!!gpio_get_value(IOMUX_TO_GPIO(MX51_PIN_NANDF_RB3))) 2;
+ rev |= (!!gpio_get_value(GPIO_NUMBER(3, 16))) 0;
+ rev |= (!!gpio_get_value(GPIO_NUMBER(3, 17))) 1;
+ rev |= (!!gpio_get_value(GPIO_NUMBER(3, 11))) 2;
return (~rev 0x7) + 1;
}
-inline u32 get_efikasb_rev(void)
+static iomux_v3_cfg_t efikasb_revision_pads[] = {
+ MX51_PAD_EIM_CS3__GPIO2_28,
+ MX51_PAD_EIM_CS4__GPIO2_29,
+};
+
+static inline u32 get_sb_rev(void)
{
u32 rev = 0;
- mxc_request_iomux(MX51_PIN_EIM_CS3, IOMUX_CONFIG_GPIO);
- mxc_iomux_set_pad(MX51_PIN_EIM_CS3, PAD_CTL_100K_PU);
- gpio_direction_input(IOMUX_TO_GPIO(MX51_PIN_EIM_CS3));
- rev |= (!!gpio_get_value(IOMUX_TO_GPIO(MX51_PIN_EIM_CS3))) 0;
-
- mxc_request_iomux(MX51_PIN_EIM_CS4, IOMUX_CONFIG_GPIO);
- mxc_iomux_set_pad(MX51_PIN_EIM_CS4, PAD_CTL_100K_PU);
- gpio_direction_input(IOMUX_TO_GPIO(MX51_PIN_EIM_CS4));
- rev |= (!!gpio_get_value(IOMUX_TO_GPIO(MX51_PIN_EIM_CS4))) 1;
+ imx_iomux_v3_setup_multiple_pads(efikasb_revision_pads,
[U-Boot] [PATCH] patman: Do not Cc addresses included in To list
In case an address is listed in the To list, those will be skipped on Cc list or user might end with a duplicated message. This fixes the case when a tag points to same address used as series destination thus avoiding duplicated sending. Signed-off-by: Otavio Salvador ota...@ossystems.com.br --- Changes in v2: - use if 'to' in self: to remove the try block tools/patman/series.py |4 1 file changed, 4 insertions(+) diff --git a/tools/patman/series.py b/tools/patman/series.py index eda1e9b..663990b 100644 --- a/tools/patman/series.py +++ b/tools/patman/series.py @@ -114,6 +114,10 @@ class Series(dict): cc_list += gitutil.BuildEmailList(commit.tags) cc_list += gitutil.BuildEmailList(commit.cc_list) +# Skip items in To list +if 'to' in self: +map(cc_list.remove, gitutil.BuildEmailList(self.to)) + for email in cc_list: if email == None: email = col.Color(col.YELLOW, alias '%s' not found -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] patman: Do not Cc addresses included in To list
In case an address is listed in the To list, those will be skipped on Cc list or user might end with a duplicated message. This fixes the case when a tag points to same address used as series destination thus avoiding duplicated sending. Signed-off-by: Otavio Salvador ota...@ossystems.com.br --- Changes in v2: - use if 'to' in self: to remove the try block Changes in v3: - readd try / except block to handle the valid error tools/patman/series.py |7 +++ 1 file changed, 7 insertions(+) diff --git a/tools/patman/series.py b/tools/patman/series.py index eda1e9b..7829dc7 100644 --- a/tools/patman/series.py +++ b/tools/patman/series.py @@ -114,6 +114,13 @@ class Series(dict): cc_list += gitutil.BuildEmailList(commit.tags) cc_list += gitutil.BuildEmailList(commit.cc_list) +# Skip items in To list +if 'to' in self: +try: +map(cc_list.remove, gitutil.BuildEmailList(self.to)) +except ValueError: +pass + for email in cc_list: if email == None: email = col.Color(col.YELLOW, alias '%s' not found -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] MX28: config: Allow different target generation in elftosb call
The elftosb call needs to use a target param specific for i.MX28. This
patch allow for later addition of i.MX233.
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
Changes in v2:
- fix Makefile according
- move u-boot.bd to u-boot-imx28.bd
Makefile |5 -
arch/arm/cpu/arm926ejs/mxs/{u-boot.bd = u-boot-imx28.bd} |0
2 files changed, 4 insertions(+), 1 deletion(-)
rename arch/arm/cpu/arm926ejs/mxs/{u-boot.bd = u-boot-imx28.bd} (100%)
diff --git a/Makefile b/Makefile
index f6471e2..1df4c1d 100644
--- a/Makefile
+++ b/Makefile
@@ -452,8 +452,11 @@ $(obj)u-boot.ais: $(obj)spl/u-boot-spl.bin
$(obj)u-boot.bin
cat $(obj)spl/u-boot-spl-pad.ais $(obj)u-boot.bin \
$(obj)u-boot.ais
+# Specify the target for use in elftosb call
+ELFTOSB_TARGET-$(CONFIG_MX28) = imx28
+
$(obj)u-boot.sb: $(obj)u-boot.bin $(obj)spl/u-boot-spl.bin
- elftosb -zdf imx28 -c $(TOPDIR)/$(CPUDIR)/$(SOC)/u-boot.bd \
+ elftosb -zdf $(ELFTOSB_TARGET-y) -c
$(TOPDIR)/$(CPUDIR)/$(SOC)/u-boot-$(ELFTOSB_TARGET-y).bd \
-o $(obj)u-boot.sb
# On x600 (SPEAr600) U-Boot is appended to U-Boot SPL.
diff --git a/arch/arm/cpu/arm926ejs/mxs/u-boot.bd
b/arch/arm/cpu/arm926ejs/mxs/u-boot-imx28.bd
similarity index 100%
rename from arch/arm/cpu/arm926ejs/mxs/u-boot.bd
rename to arch/arm/cpu/arm926ejs/mxs/u-boot-imx28.bd
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] MX28: Move regs-base.h include after SoC type configuration
For i.MX233 addition the base registers need to be change so the SoC definition needs to be known before the header include. The following boards has been changed: * apx4devkit * m28evk * mx28evk * sc_sps_1 Signed-off-by: Otavio Salvador ota...@ossystems.com.br Acked-by: Stefano Babic sba...@denx.de --- Changes in v2: - no changes include/configs/apx4devkit.h |4 ++-- include/configs/m28evk.h |4 ++-- include/configs/mx28evk.h|5 +++-- include/configs/sc_sps_1.h |4 ++-- 4 files changed, 9 insertions(+), 8 deletions(-) diff --git a/include/configs/apx4devkit.h b/include/configs/apx4devkit.h index b5ae44f..af0b714 100644 --- a/include/configs/apx4devkit.h +++ b/include/configs/apx4devkit.h @@ -22,8 +22,6 @@ #ifndef __CONFIG_H #define __CONFIG_H -#include asm/arch/regs-base.h - /* SoC configurations */ #define CONFIG_MX28/* i.MX28 SoC */ #define CONFIG_MXS_GPIO/* GPIO control */ @@ -32,6 +30,8 @@ #define MACH_TYPE_APX4DEVKIT 3712 #define CONFIG_MACH_TYPE MACH_TYPE_APX4DEVKIT +#include asm/arch/regs-base.h + #define CONFIG_SYS_NO_FLASH #define CONFIG_BOARD_EARLY_INIT_F #define CONFIG_ARCH_CPU_INIT diff --git a/include/configs/m28evk.h b/include/configs/m28evk.h index b3ac316..91c6bb9 100644 --- a/include/configs/m28evk.h +++ b/include/configs/m28evk.h @@ -20,8 +20,6 @@ #ifndef __M28EVK_CONFIG_H__ #define __M28EVK_CONFIG_H__ -#include asm/arch/regs-base.h - /* * SoC configurations */ @@ -36,6 +34,8 @@ #defineCONFIG_MACH_TYPEMACH_TYPE_M28EVK +#include asm/arch/regs-base.h + #defineCONFIG_SYS_NO_FLASH #defineCONFIG_BOARD_EARLY_INIT_F #defineCONFIG_ARCH_MISC_INIT diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h index 4e70617..ac06caf 100644 --- a/include/configs/mx28evk.h +++ b/include/configs/mx28evk.h @@ -19,17 +19,18 @@ #ifndef __MX28EVK_CONFIG_H__ #define __MX28EVK_CONFIG_H__ -#include asm/arch/regs-base.h - /* * SoC configurations */ #define CONFIG_MX28/* i.MX28 SoC */ + #define CONFIG_MXS_GPIO/* GPIO control */ #define CONFIG_SYS_HZ 1000/* Ticks per second */ #define CONFIG_MACH_TYPE MACH_TYPE_MX28EVK +#include asm/arch/regs-base.h + #define CONFIG_SYS_NO_FLASH #define CONFIG_BOARD_EARLY_INIT_F #define CONFIG_ARCH_MISC_INIT diff --git a/include/configs/sc_sps_1.h b/include/configs/sc_sps_1.h index f0b6f2b..0ebdfb8 100644 --- a/include/configs/sc_sps_1.h +++ b/include/configs/sc_sps_1.h @@ -22,8 +22,6 @@ #ifndef __SC_SPS_1_H__ #define __SC_SPS_1_H__ -#include asm/arch/regs-base.h - /* * SoC configurations */ @@ -38,6 +36,8 @@ #define CONFIG_MACH_TYPE MACH_TYPE_SC_SPS_1 +#include asm/arch/regs-base.h + #define CONFIG_SYS_NO_FLASH #define CONFIG_SYS_ICACHE_OFF #define CONFIG_SYS_DCACHE_OFF -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] patman feature request
On Fri, Aug 17, 2012 at 6:35 PM, Simon Glass s...@chromium.org wrote: On Fri, Aug 17, 2012 at 1:14 PM, Otavio Salvador ota...@ossystems.com.br wrote: On Fri, Aug 17, 2012 at 5:01 PM, Tom Rini tr...@ti.com wrote: It looks like today was the day that Joe and I both decided to give patman a whirl. On IRC we both hit the same annoyance of commits like: Cosmetic: Something causing patman to look for a maintainer for cosmetic and failing fatally. Could we please make maintainer alias not found a warning and not a fatal error (so the human can go oh, that's not a real area, that's fine ? My ~/.patman is almost more fixups than real aliases. I agree; I have also sent two minor fixes to patman and I've been putting fixups on my .patman to make it run and it does seem it would work better if it was an warn. Yes I like the idea of a warning instead of an error. It annoys me too sometimes, although I do use it as a check against adding a tag that no one has heard of. Another idea is to have a wildcard that matches as a fallback. I suppose wildcards matches might be useful - could be overkill though. Maybe the .patman might support a regexp for the tag; this way we can have things like: mx[s5]: ... -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] patman: Use reverse order for changelog
Specially when many revisions are need for a patchset, the most interesting information is about the last set of changes so we output the changelog in reverse order to easy identification of most recent change set. Signed-off-by: Otavio Salvador ota...@ossystems.com.br --- tools/patman/series.py |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/tools/patman/series.py b/tools/patman/series.py index 7829dc7..dddfab4 100644 --- a/tools/patman/series.py +++ b/tools/patman/series.py @@ -145,18 +145,18 @@ class Series(dict): Return: The change log as a list of strings, one per line +Changes in v2: +- Jog the dial back closer to the widget + Changes in v1: - Fix the widget - Jog the dial -Changes in v2: -- Jog the dial back closer to the widget - etc. final = [] need_blank = False -for change in sorted(self.changes): +for change in sorted(self.changes, reverse=True): out = [] for this_commit, text in self.changes[change]: if commit and this_commit != commit: -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] patman: Do not sort changlog items order
When writting the changelog of a series it is expect that this order is going to be respected. The sorting can make it out of context of the order had a meaning for the reader so this patch remove the sort of items. Signed-off-by: Otavio Salvador ota...@ossystems.com.br --- tools/patman/series.py |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/patman/series.py b/tools/patman/series.py index dddfab4..34eea92 100644 --- a/tools/patman/series.py +++ b/tools/patman/series.py @@ -164,7 +164,7 @@ class Series(dict): if text not in out: out.append(text) if out: -out = ['Changes in v%d:' % change] + sorted(out) +out = ['Changes in v%d:' % change] + out if need_blank: out = [''] + out final += out -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] MX28: config: Allow different target generation in elftosb call
Dear Otavio Salvador,
The elftosb call needs to use a target param specific for i.MX28. This
patch allow for later addition of i.MX233.
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
Changes in v2:
- fix Makefile according
- move u-boot.bd to u-boot-imx28.bd
Makefile |5 -
arch/arm/cpu/arm926ejs/mxs/{u-boot.bd = u-boot-imx28.bd} |0
2 files changed, 4 insertions(+), 1 deletion(-)
rename arch/arm/cpu/arm926ejs/mxs/{u-boot.bd = u-boot-imx28.bd} (100%)
diff --git a/Makefile b/Makefile
index f6471e2..1df4c1d 100644
--- a/Makefile
+++ b/Makefile
@@ -452,8 +452,11 @@ $(obj)u-boot.ais: $(obj)spl/u-boot-spl.bin
$(obj)u-boot.bin cat $(obj)spl/u-boot-spl-pad.ais $(obj)u-boot.bin \
$(obj)u-boot.ais
+# Specify the target for use in elftosb call
+ELFTOSB_TARGET-$(CONFIG_MX28) = imx28
+
$(obj)u-boot.sb: $(obj)u-boot.bin $(obj)spl/u-boot-spl.bin
- elftosb -zdf imx28 -c $(TOPDIR)/$(CPUDIR)/$(SOC)/u-boot.bd \
+ elftosb -zdf $(ELFTOSB_TARGET-y) -c
$(TOPDIR)/$(CPUDIR)/$(SOC)/u-boot-$(ELFTOSB_TARGET-y).bd \ -o
$(obj)u-boot.sb
# On x600 (SPEAr600) U-Boot is appended to U-Boot SPL.
diff --git a/arch/arm/cpu/arm926ejs/mxs/u-boot.bd
b/arch/arm/cpu/arm926ejs/mxs/u-boot-imx28.bd similarity index 100%
rename from arch/arm/cpu/arm926ejs/mxs/u-boot.bd
rename to arch/arm/cpu/arm926ejs/mxs/u-boot-imx28.bd
I think we should try and see if the mx28 and mx23 .bd can't be converged
together too. Remind me in the evening (~4-5 hours from now) to try it.
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 2/2] MX28: Move regs-base.h include after SoC type configuration
Dear Otavio Salvador, For i.MX233 addition the base registers need to be change so the SoC definition needs to be known before the header include. The following boards has been changed: * apx4devkit * m28evk * mx28evk * sc_sps_1 Signed-off-by: Otavio Salvador ota...@ossystems.com.br Acked-by: Stefano Babic sba...@denx.de Seems ok --- Changes in v2: - no changes include/configs/apx4devkit.h |4 ++-- include/configs/m28evk.h |4 ++-- include/configs/mx28evk.h|5 +++-- include/configs/sc_sps_1.h |4 ++-- 4 files changed, 9 insertions(+), 8 deletions(-) diff --git a/include/configs/apx4devkit.h b/include/configs/apx4devkit.h index b5ae44f..af0b714 100644 --- a/include/configs/apx4devkit.h +++ b/include/configs/apx4devkit.h @@ -22,8 +22,6 @@ #ifndef __CONFIG_H #define __CONFIG_H -#include asm/arch/regs-base.h - /* SoC configurations */ #define CONFIG_MX28 /* i.MX28 SoC */ #define CONFIG_MXS_GPIO /* GPIO control */ @@ -32,6 +30,8 @@ #define MACH_TYPE_APX4DEVKIT 3712 #define CONFIG_MACH_TYPE MACH_TYPE_APX4DEVKIT +#include asm/arch/regs-base.h + #define CONFIG_SYS_NO_FLASH #define CONFIG_BOARD_EARLY_INIT_F #define CONFIG_ARCH_CPU_INIT diff --git a/include/configs/m28evk.h b/include/configs/m28evk.h index b3ac316..91c6bb9 100644 --- a/include/configs/m28evk.h +++ b/include/configs/m28evk.h @@ -20,8 +20,6 @@ #ifndef __M28EVK_CONFIG_H__ #define __M28EVK_CONFIG_H__ -#include asm/arch/regs-base.h - /* * SoC configurations */ @@ -36,6 +34,8 @@ #define CONFIG_MACH_TYPEMACH_TYPE_M28EVK +#include asm/arch/regs-base.h + #define CONFIG_SYS_NO_FLASH #define CONFIG_BOARD_EARLY_INIT_F #define CONFIG_ARCH_MISC_INIT diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h index 4e70617..ac06caf 100644 --- a/include/configs/mx28evk.h +++ b/include/configs/mx28evk.h @@ -19,17 +19,18 @@ #ifndef __MX28EVK_CONFIG_H__ #define __MX28EVK_CONFIG_H__ -#include asm/arch/regs-base.h - /* * SoC configurations */ #define CONFIG_MX28 /* i.MX28 SoC */ + #define CONFIG_MXS_GPIO /* GPIO control */ #define CONFIG_SYS_HZ1000/* Ticks per second */ #define CONFIG_MACH_TYPE MACH_TYPE_MX28EVK +#include asm/arch/regs-base.h + #define CONFIG_SYS_NO_FLASH #define CONFIG_BOARD_EARLY_INIT_F #define CONFIG_ARCH_MISC_INIT diff --git a/include/configs/sc_sps_1.h b/include/configs/sc_sps_1.h index f0b6f2b..0ebdfb8 100644 --- a/include/configs/sc_sps_1.h +++ b/include/configs/sc_sps_1.h @@ -22,8 +22,6 @@ #ifndef __SC_SPS_1_H__ #define __SC_SPS_1_H__ -#include asm/arch/regs-base.h - /* * SoC configurations */ @@ -38,6 +36,8 @@ #define CONFIG_MACH_TYPE MACH_TYPE_SC_SPS_1 +#include asm/arch/regs-base.h + #define CONFIG_SYS_NO_FLASH #define CONFIG_SYS_ICACHE_OFF #define CONFIG_SYS_DCACHE_OFF 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/2] MX28: config: Allow different target generation in elftosb call
On Sat, Aug 18, 2012 at 3:03 PM, Marek Vasut marek.va...@gmail.com wrote: I think we should try and see if the mx28 and mx23 .bd can't be converged together too. Remind me in the evening (~4-5 hours from now) to try it. We can try but mx23 cannot use the ivt helper; so we ended having a specific file for each processor. If we can get those merged, good. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/p1_p2_rdb_pc: print -PC suffix in board name
Currently the -PC variants of the P1/P2 RDB boards do not print it on boot -- e.g. a P2020RDB-PC will claim to be a plain P2020RDB. Besides being incorrect, this can confuse a user into building U-Boot for P2020RDB rather than P2020RDB-PC, resulting in a board that does not boot. P1024RDB and P1025RDB are not included, as these boards apparently do not have -PC as part of their name, even though they are supported by p1_p2_rdb_pc. Signed-off-by: Scott Wood scottw...@freescale.com --- include/configs/p1_p2_rdb_pc.h | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h index a8882d4..58af3a5 100644 --- a/include/configs/p1_p2_rdb_pc.h +++ b/include/configs/p1_p2_rdb_pc.h @@ -31,7 +31,7 @@ #endif #if defined(CONFIG_P1020MBG) -#define CONFIG_BOARDNAME P1020MBG +#define CONFIG_BOARDNAME P1020MBG-PC #define CONFIG_P1020 #define CONFIG_VSC7385_ENET #define CONFIG_SLIC @@ -41,7 +41,7 @@ #endif #if defined(CONFIG_P1020UTM) -#define CONFIG_BOARDNAME P1020UTM +#define CONFIG_BOARDNAME P1020UTM-PC #define CONFIG_P1020 #define __SW_BOOT_MASK 0x03 #define __SW_BOOT_NOR 0xe0 @@ -49,7 +49,7 @@ #endif #if defined(CONFIG_P1020RDB) -#define CONFIG_BOARDNAME P1020RDB +#define CONFIG_BOARDNAME P1020RDB-PC #define CONFIG_NAND_FSL_ELBC #define CONFIG_P1020 #define CONFIG_SPI_FLASH @@ -64,7 +64,7 @@ #endif #if defined(CONFIG_P1021RDB) -#define CONFIG_BOARDNAME P1021RDB +#define CONFIG_BOARDNAME P1021RDB-PC #define CONFIG_NAND_FSL_ELBC #define CONFIG_P1021 #define CONFIG_QE @@ -111,7 +111,7 @@ #endif #if defined(CONFIG_P2020RDB) -#define CONFIG_BOARDNAME P2020RDB +#define CONFIG_BOARDNAME P2020RDB-PC #define CONFIG_NAND_FSL_ELBC #define CONFIG_P2020 #define CONFIG_SPI_FLASH -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] nand_spl: change out_be32 to raw_writel and depend on subsequent sync
On 08/13/2012 06:23 PM, Scott Wood wrote: On 08/13/2012 01:10 PM, Matthew McClintock wrote: This change reduces the SPL size by removing the redundant syncs produced by out_be32 and just replies on one final sync Done with: sed -r '/in_be32/b; s/(out_be32)\(([^,]*),\s+(.*)\)/__raw_writel(\3, \2)/g' -i `git grep --name-only sdram_init nand_spl/` Signed-off-by: Matthew McClintock m...@freescale.com --- nand_spl/board/freescale/p1010rdb/nand_boot.c | 54 ++--- nand_spl/board/freescale/p1023rds/nand_boot.c | 42 nand_spl/board/freescale/p1_p2_rdb_pc/nand_boot.c | 48 +- 3 files changed, 71 insertions(+), 73 deletions(-) This should come first if the other patches break without it, to preserve bisectability. Note that I'm going to try to convert this stuff (at least one board as an example, but hopefully it should be easy enough to do additional boards once the first is done) to the new spl Really Soon Now(tm), so it doesn't make much sense to fiddle around with the old stuff right now unless I miss the merge window. I'll incorporate these changes into the new-spl version. I may do that by applying these patches first, but I'd rather they not go via the mpc85xx tree (and please CC me on NAND patches). I'm not going to have this working by the end of the merge window, so these patches can go in as is. Andy, do you want to take them or should I? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MX: Set a common gpio.h for all i.MX
Hi Stefano,
Each i.MX has its own gpio.h, defining the same structure.
The internal GPIO controller has the same layout
(at least for the register used by u-boot) and can be shared.
Good!
Signed-off-by: Stefano Babic sba...@denx.de
CC: Matt Sealey m...@genesi-usa.com
CC: Marek Vasut ma...@denx.de
CC: Benoit Thebaudeau benoit.thebaud...@advansee.com
CC: Jason Liu jason@linaro.org
---
arch/arm/include/asm/arch-mx25/gpio.h| 12 +
arch/arm/include/asm/arch-mx31/gpio.h|7 +-
arch/arm/include/asm/arch-mx35/gpio.h| 12 +
arch/arm/include/asm/arch-mx5/gpio.h |7 +-
arch/arm/include/asm/arch-mx6/gpio.h |7 +-
arch/arm/include/asm/arch-mx6/imx-regs.h |2 --
arch/arm/include/asm/imx-common/gpio.h | 39
++
include/configs/mx6qsabrelite.h |1 +
8 files changed, 45 insertions(+), 42 deletions(-)
create mode 100644 arch/arm/include/asm/imx-common/gpio.h
diff --git a/arch/arm/include/asm/arch-mx25/gpio.h
b/arch/arm/include/asm/arch-mx25/gpio.h
index dc6edc7..5ab1f6d 100644
--- a/arch/arm/include/asm/arch-mx25/gpio.h
+++ b/arch/arm/include/asm/arch-mx25/gpio.h
@@ -30,16 +30,6 @@
*/
#define MXC_GPIO_PORT_TO_NUM(port, bit) (((port - 1) 5) + (bit
0x1f))
Keeping this is also useless. GPIO_NUMBER() from the new asm/imx-common/gpio.h
can be used instead everywhere needed.
-/* GPIO registers */
-struct gpio_regs {
- u32 gpio_dr;/* data */
- u32 gpio_dir; /* direction */
- u32 psr;/* pad satus */
- u32 icr1; /* interrupt config 1 */
- u32 icr2; /* interrupt config 2 */
- u32 imr;/* interrupt mask */
- u32 isr;/* interrupt status */
- u32 edge_sel; /* edge select */
-};
+#include asm/imx-common/gpio.h
#endif
diff --git a/arch/arm/include/asm/arch-mx31/gpio.h
b/arch/arm/include/asm/arch-mx31/gpio.h
index 95b73bf..55c0afa 100644
--- a/arch/arm/include/asm/arch-mx31/gpio.h
+++ b/arch/arm/include/asm/arch-mx31/gpio.h
@@ -25,11 +25,6 @@
#ifndef __ASM_ARCH_MX31_GPIO_H
#define __ASM_ARCH_MX31_GPIO_H
-/* GPIO Registers */
-struct gpio_regs {
- u32 gpio_dr;
- u32 gpio_dir;
- u32 gpio_psr;
-};
+#include asm/imx-common/gpio.h
#endif
diff --git a/arch/arm/include/asm/arch-mx35/gpio.h
b/arch/arm/include/asm/arch-mx35/gpio.h
index 7bcc3e8..1deb292 100644
--- a/arch/arm/include/asm/arch-mx35/gpio.h
+++ b/arch/arm/include/asm/arch-mx35/gpio.h
@@ -25,16 +25,6 @@
#ifndef __ASM_ARCH_MX35_GPIO_H
#define __ASM_ARCH_MX35_GPIO_H
-/* GPIO registers */
-struct gpio_regs {
- u32 gpio_dr;/* data */
- u32 gpio_dir; /* direction */
- u32 psr;/* pad satus */
- u32 icr1; /* interrupt config 1 */
- u32 icr2; /* interrupt config 2 */
- u32 imr;/* interrupt mask */
- u32 isr;/* interrupt status */
- u32 edge_sel; /* edge select */
-};
+#include asm/imx-common/gpio.h
#endif
diff --git a/arch/arm/include/asm/arch-mx5/gpio.h
b/arch/arm/include/asm/arch-mx5/gpio.h
index 1dc34e9..b1b1218 100644
--- a/arch/arm/include/asm/arch-mx5/gpio.h
+++ b/arch/arm/include/asm/arch-mx5/gpio.h
@@ -25,11 +25,6 @@
#ifndef __ASM_ARCH_MX5_GPIO_H
#define __ASM_ARCH_MX5_GPIO_H
-/* GPIO registers */
-struct gpio_regs {
- u32 gpio_dr;
- u32 gpio_dir;
- u32 gpio_psr;
-};
+#include asm/imx-common/gpio.h
#endif
diff --git a/arch/arm/include/asm/arch-mx6/gpio.h
b/arch/arm/include/asm/arch-mx6/gpio.h
index 20c4e57..24c10f8 100644
--- a/arch/arm/include/asm/arch-mx6/gpio.h
+++ b/arch/arm/include/asm/arch-mx6/gpio.h
@@ -25,11 +25,6 @@
#ifndef __ASM_ARCH_MX6_GPIO_H
#define __ASM_ARCH_MX6_GPIO_H
-/* GPIO registers */
-struct gpio_regs {
- u32 gpio_dr;
- u32 gpio_dir;
- u32 gpio_psr;
-};
+#include asm/imx-common/gpio.h
#endif /* __ASM_ARCH_MX6_GPIO_H */
Why do you keep all these old asm/gpio.h? The new asm/imx-common/gpio.h can
be included instead everywhere needed.
diff --git a/arch/arm/include/asm/arch-mx6/imx-regs.h
b/arch/arm/include/asm/arch-mx6/imx-regs.h
index 5d77603..f3e58b5 100644
--- a/arch/arm/include/asm/arch-mx6/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx6/imx-regs.h
@@ -172,8 +172,6 @@
#define IMX_IIM_BASE OCOTP_BASE_ADDR
#define FEC_QUIRK_ENET_MAC
-#define GPIO_NUMBER(port, index) port)-1)*32)+((index)31))
-
#if !(defined(__KERNEL_STRICT_NAMES) || defined(__ASSEMBLY__))
#include asm/types.h
diff --git a/arch/arm/include/asm/imx-common/gpio.h
b/arch/arm/include/asm/imx-common/gpio.h
new file mode 100644
index 000..fcc25e8
--- /dev/null
+++ b/arch/arm/include/asm/imx-common/gpio.h
@@ -0,0 +1,39 @@
+/*
+ * Copyright (C) 2011
+ * Stefano Babic, DENX Software Engineering, sba...@denx.de
+ *
+ * See file
Re: [U-Boot] Please pull u-boot-staging/tr...@ti.com
On Sat, Aug 18, 2012 at 07:15:56AM -0700, Tom Rini wrote:
On Sat, Aug 18, 2012 at 08:28:55AM +0200, Albert ARIBAUD wrote:
Hi Tom,
On Fri, 17 Aug 2012 14:52:01 -0700, Tom Rini tr...@ti.com wrote:
Hello,
This replaces my previous pull-request and is new warning free on
MAKEALL -a arm for ELDK4.2/5.1/5.2.1.
The following changes since commit
4d3c95f5ea7c737a21cd6b9c59435ee693b3f127:
zfs: Add ZFS filesystem support (2012-08-09 23:42:20 +0200)
are available in the git repository at:
git://git.denx.de/u-boot-staging tr...@ti.com
for you to fetch changes up to
5d26e4de33fab7b132e8a8036ac54176f537d79f:
ARM: add Raspberry Pi model B board, using BCM2835 SoC (2012-08-15
09:43:47 -0700)
John Rigby (1):
u8500: Separating mmc config parameters from driver
Mathieu J. Poirier (10):
snowball: Add support for ux500 based snowball board
u8500: Moving prcmu to cpu directory
snowball: Adding architecture dependent initialisation
snowball: Adding CPU clock initialisation
snowball: Moving to ux500.v2 addess scheme for PRCMU access
snowball: applying power to LAN and GBF controllers
u8500: Moving processor-specific functions to cpu area.
u8500: Enabling power to MMC device on AB8500 V2
armv7: Adding cpu specific cache managmenent
snowball: Adding board specific cache cleanup routine
Stephen Warren (4):
README: fix references to config_cmd_default.h
ARM: arm1176: enable instruction cache in arch_cpu_init()
ARM: add basic support for the Broadcom BCM2835 SoC
ARM: add Raspberry Pi model B board, using BCM2835 SoC
MAINTAINERS|8 +
README |4 +-
arch/arm/cpu/arm1176/bcm2835/Makefile | 37 +
arch/arm/cpu/arm1176/bcm2835/config.mk | 19 +
arch/arm/cpu/arm1176/bcm2835/lowlevel_init.S | 19 +
arch/arm/cpu/arm1176/bcm2835/reset.c | 35 +
arch/arm/cpu/arm1176/bcm2835/timer.c | 55 ++
arch/arm/cpu/arm1176/cpu.c |7 +
arch/arm/cpu/armv7/cpu.c |8 +
arch/arm/cpu/armv7/u8500/Makefile |2 +-
arch/arm/cpu/armv7/u8500/clock.c | 34 +
arch/arm/cpu/armv7/u8500/cpu.c | 192 +
.../arm/cpu/armv7}/u8500/prcmu.c | 128 +++-
arch/arm/include/asm/arch-bcm2835/gpio.h | 66 ++
arch/arm/include/asm/arch-bcm2835/timer.h | 37 +
arch/arm/include/asm/arch-bcm2835/wdog.h | 36 +
arch/arm/include/asm/arch-u8500/clock.h|5 +-
arch/arm/include/asm/arch-u8500/db8500_gpio.h | 42 ++
arch/arm/include/asm/arch-u8500/db8500_pincfg.h| 170 +
arch/arm/include/asm/arch-u8500/hardware.h | 33 +-
.../arm/include/asm/arch-u8500/prcmu.h | 35 +-
arch/arm/include/asm/arch-u8500/sys_proto.h|1 +
board/armltd/vexpress/ca9x4_ct_vxp.c | 21 +-
board/raspberrypi/rpi_b/Makefile | 34 +
board/raspberrypi/rpi_b/rpi_b.c| 34 +
board/st-ericsson/snowball/Makefile| 49 ++
board/st-ericsson/snowball/db8500_pins.h | 745
board/st-ericsson/snowball/snowball.c | 348 +
board/st-ericsson/u8500/Makefile |2 +-
board/st-ericsson/u8500/u8500_href.c | 100 +--
boards.cfg |2 +
drivers/gpio/Makefile |2 +
drivers/gpio/bcm2835_gpio.c| 89 +++
drivers/gpio/db8500_gpio.c | 221 ++
drivers/mmc/arm_pl180_mmci.c | 131 ++--
drivers/mmc/arm_pl180_mmci.h | 27 +-
drivers/serial/serial_pl01x.c |2 +
include/configs/rpi_b.h| 104 +++
include/configs/snowball.h | 266 +++ 39
files changed, 2937 insertions(+), 213 deletions(-) create mode
100644 arch/arm/cpu/arm1176/bcm2835/Makefile create mode 100644
arch/arm/cpu/arm1176/bcm2835/config.mk create mode 100644
arch/arm/cpu/arm1176/bcm2835/lowlevel_init.S create mode 100644
arch/arm/cpu/arm1176/bcm2835/reset.c create mode 100644
arch/arm/cpu/arm1176/bcm2835/timer.c create mode 100644
arch/arm/cpu/armv7/u8500/cpu.c rename {board/st-ericsson =
arch/arm/cpu/armv7}/u8500/prcmu.c (58%) create mode 100644
arch/arm/include/asm/arch-bcm2835/gpio.h create mode 100644
arch/arm/include/asm/arch-bcm2835/timer.h
Re: [U-Boot] [PATCH] MX: Set a common gpio.h for all i.MX
On Sat, Aug 18, 2012 at 2:25 PM, Benoît Thébaudeau benoit.thebaud...@advansee.com wrote: Hi Stefano, This is a bit off topic, but shouldn't the iomux-v3 stuff be moved to a common location for all these i.MXs too? As to the header file, it's already done, but the C file is under arch/arm/cpu/armv7/imx-common/ while it is absolutely not armv7-specific. True, I'd advocate that. -- Matt Sealey m...@genesi-usa.com Product Development Analyst, Genesi USA, Inc. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] efikamx: update to Efika MX Smarttop and Smartbook boards
On Sat, Aug 18, 2012 at 10:50 AM, Stefano Babic sba...@denx.de wrote: On 17/08/2012 20:19, Matt Sealey wrote: Anyway, who will maintain the efikas in future ? Marek, do you hold it, or Matt will take this job ? I'll do it but I doubt I'm going to be around as much as Marek. What I'm a little fearful of is having patches try and hit the Efika stuff and me not having much time that day to review, they either stagnate or get accepted anyway breaking something. I can't test every patch everyone sends, we just want to be sure it's hit a certain level of quality and solve some of the issues we hacked around at the Freescale BSP level are in mainline as we simply can't use the BSP version anymore (doesn't support bootz or device trees...) In last case I would like to see a patch for the MAINTAINER file. I'll submit it when I feel like we're actually being forced to maintain it. I am of two minds; I will be the responsible party if needs be, but that means Efika MX stuff is going to be commercially driven by our needs (i.e. runs our boot scripts, supports the board the way we dictate (no video, no usb keyboards..), no changes to support developers if they are simply being too needy), and if it doesn't suit us in terms of breaking something or changing behaviour wildly, we'll NACK the crap out of it. If that's acceptable, sure... Marek says U-Boot doesn't follow this development model, but that would put Denx out of business. -- Matt Sealey m...@genesi-usa.com Product Development Analyst, Genesi USA, Inc. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] efikamx: remove drive strength hack from early_init_f and move it to the DCD
On Sat, Aug 18, 2012 at 10:34 AM, Stefano Babic sba...@denx.de wrote: On 17/08/2012 20:19, Matt Sealey wrote: The i.MX Boot ROM lets us set up certain registers before U-Boot even gets executed. Rather than setting up DDR, putting U-Boot in place, and getting into pre-relocation init to set up DDR again, just do it once in the correct place. This also solves an issue where the Smarttop DDR pad settings were being applied on Smartbook. While we're at it, configure PCBID0,1,2 and the LED GPIO since we've still got room in the DCD to do so. Signed-off-by: Matt Sealey m...@genesi-usa.com --- Hi Matt, diff --git a/board/genesi/mx51_efikamx/imximage_mx.cfg b/board/genesi/mx51_efikamx/imximage_mx.cfg index 6fe0ff9..ac9aa9a 100644 --- a/board/genesi/mx51_efikamx/imximage_mx.cfg +++ b/board/genesi/mx51_efikamx/imximage_mx.cfg @@ -1,7 +1,7 @@ # +# Copyright (C) 2009 Pegatron Corporation ^--- Was this added for mistake ? I think you should add only yours. The drive strength settings came from Pegatron a long, long time ago (2009 :) and our old config and the function is copyrighted to them. Just because Marek took them out and recopyrighted the file I derived them from in this case doesn't mean they lost their copyright.. I join Marek, it is quite difficult to review it and understand which was changed. It looks like a new file.. It's just because I moved the comments to the end of the line, so it's blocking it up. Sometimes it's nicer if it's -this line +that line -this line +that line .. but that's not how git does it when the change is more than a few characters and multiple lines changed.. I can submit it differently but I can't change the way it's producing the diff. -- Matt Sealey m...@genesi-usa.com Product Development Analyst, Genesi USA, Inc. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx5: add iomux-mx51.h include
On Sat, Aug 18, 2012 at 10:18 AM, Stefano Babic sba...@denx.de wrote: On 17/08/2012 20:16, Matt Sealey wrote: Essentially now we can share code with the MX6 boards, reducing redundant pin definitions across boards and lengthy configuration of external pads on the i.MX51. Signed-off-by: Matt Sealey m...@genesi-usa.com --- Hi Matt, arch/arm/include/asm/arch-mx5/iomux-mx51.h | 144 1 file changed, 144 insertions(+) create mode 100644 arch/arm/include/asm/arch-mx5/iomux-mx51.h As far as I can see iomux-mx51.h is coming from the linux kernel. Then please add in the commit message information about which version of the kernel you borrow this code, better add the kernel commit-id. This allows to have a track where the code is coming from. I will, for now it's the top of Linus' tree, but this code is going to get removed from the Linux kernel soon, so I understand, we need to figure out where it will last forever (probably linux-stable@3.5) so we can always reference it. I do like we add a second identical defeine why we discover an issue in another part of code. I know for experience that code introduced this the goal to fix it later will never be fixed. So let's see if we can jut do the right thing. I do not think imx-common/iomux-v3.h is the right place. What has the pinmux with gpio to do? This is also wrongit is GPIO related, it should go into gpio.h. That's true. I did not want to mess the patchset up with boards I cannot test though, and I don't like committing code I didn't test (mx3 gpio etc.) even if the docs say as much as it's identical. I see you already fixed that though. I'll rebase on Monday and submit something new... see below, though.. + +#endif /* __IOMUX_MX51_H__ */ Ok, good, this is the same as in kernel. Right. This all came from a discussion with Troy and Eric at BoundaryDevices about i2c multi-bus support, they sent us a file with MX6 support and a hack for MX5 support to go with it; it didn't work and I figured it'd be a good thing to complete. Troy suggested not copying the Linux file verbatim (after all, why include camera bus pinmux when U-Boot won't support a camera bus?) and just include the pins we wanted. So, this is what I did, but right now I'm going to find a nice stable commit and tree where this file exists (the one I copy pasted the pins out of..). I just noticed that the imx-common/iomux-v3.h is out of date re the latest kernel too (some bits have moved as MX6 needs extra space to store some setting) so I'll patch that in as well. I think we need to make a small discussion point here (new thread?) about what needs to be done and what has been done, since if this isn't a tree and just patches on a mailing list or in a patchwork it's infuriatingly hard to track what is going on and who patched what and what to base against. I may have to wait until something like your gpio.h changes hit the u-boot-imx tree.. -- Matt Sealey m...@genesi-usa.com Product Development Analyst, Genesi USA, Inc. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx5: add iomux-mx51.h include
Hi Matt, create mode 100644 arch/arm/include/asm/arch-mx5/iomux-mx51.h As far as I can see iomux-mx51.h is coming from the linux kernel. Then please add in the commit message information about which version of the kernel you borrow this code, better add the kernel commit-id. This allows to have a track where the code is coming from. I will, for now it's the top of Linus' tree, but this code is going to get removed from the Linux kernel soon, Good to know. Where did you get that information from? As of now, it is still in linux-next and in Sascha's tree, which means that it will probably be in linux 3.7 too. Is it because of the move to DT that would in the end set up pads from DT file info? Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx5: add iomux-mx51.h include
On Sat, Aug 18, 2012 at 4:46 PM, Benoît Thébaudeau benoit.thebaud...@advansee.com wrote: Hi Matt, create mode 100644 arch/arm/include/asm/arch-mx5/iomux-mx51.h As far as I can see iomux-mx51.h is coming from the linux kernel. Then please add in the commit message information about which version of the kernel you borrow this code, better add the kernel commit-id. This allows to have a track where the code is coming from. I will, for now it's the top of Linus' tree, but this code is going to get removed from the Linux kernel soon, Good to know. Where did you get that information from? As of now, it is still in linux-next and in Sascha's tree, which means that it will probably be in linux 3.7 too. Is it because of the move to DT that would in the end set up pads from DT file info? By 3.7 (most) or 3.8 (maybe all) a lot of boards will be device tree only. iomux stuff in board files has been replaced with pinctrl in device trees.. Shawn will know his schedule better than me (CCd) -- Matt Sealey m...@genesi-usa.com Product Development Analyst, Genesi USA, Inc. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] rtc: add support of mx27 rtc
Am 08/08/2012 19:04, schrieb Philippe Reynes:
This driver has been tested on board armadeus apf27.
Signed-off-by: Philippe Reynes trem...@yahoo.fr
---
Hi Philippe,
arch/arm/include/asm/arch-mx27/imx-regs.h |3 +
arch/arm/include/asm/arch-mx27/regs-rtc.h | 40 ++
drivers/rtc/Makefile |1 +
drivers/rtc/mx27rtc.c | 83
+
4 files changed, 127 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/include/asm/arch-mx27/regs-rtc.h
create mode 100644 drivers/rtc/mx27rtc.c
diff --git a/arch/arm/include/asm/arch-mx27/imx-regs.h
b/arch/arm/include/asm/arch-mx27/imx-regs.h
index ced5b2a..f7cf85b 100644
--- a/arch/arm/include/asm/arch-mx27/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx27/imx-regs.h
@@ -24,6 +24,8 @@
#ifndef _IMX_REGS_H
#define _IMX_REGS_H
+#include asm/arch/regs-rtc.h
+
#ifndef __ASSEMBLY__
extern void imx_gpio_mode (int gpio_mode);
@@ -224,6 +226,7 @@ struct fuse_bank0_regs {
#define IMX_TIM1_BASE(0x03000 + IMX_IO_BASE)
#define IMX_TIM2_BASE(0x04000 + IMX_IO_BASE)
#define IMX_TIM3_BASE(0x05000 + IMX_IO_BASE)
+#define IMX_RTC_BASE (0x07000 + IMX_IO_BASE)
#define UART1_BASE (0x0a000 + IMX_IO_BASE)
#define UART2_BASE (0x0b000 + IMX_IO_BASE)
#define UART3_BASE (0x0c000 + IMX_IO_BASE)
diff --git a/arch/arm/include/asm/arch-mx27/regs-rtc.h
b/arch/arm/include/asm/arch-mx27/regs-rtc.h
new file mode 100644
index 000..4f92d0f
--- /dev/null
+++ b/arch/arm/include/asm/arch-mx27/regs-rtc.h
@@ -0,0 +1,40 @@
+/*
+ * Freescale i.MX27 RTC Register Definitions
+ *
+ * Copyright (C) 2012 Philippe Reynes trem...@yahoo.fr
+ *
+ * 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 __MX27_REGS_RTC_H__
+#define __MX27_REGS_RTC_H__
+
+#ifndef __ASSEMBLY__
+struct rtc_regs {
+ u32 hourmin;
+ u32 seconds;
+ u32 alrm_hm;
+ u32 alrm_sec;
+ u32 rtcctl;
+ u32 rtcisr;
+ u32 rtcienr;
+ u32 stpwch;
+ u32 dayr;
+ u32 dayalarm;
+};
+#endif /* __ASSEMBLY__*/
+
+#endif /* __MX28_REGS_RTC_H__ */
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index faf4fcd..640f148 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -57,6 +57,7 @@ COBJS-$(CONFIG_RTC_MK48T59) += mk48t59.o
COBJS-$(CONFIG_RTC_MPC5200) += mpc5xxx.o
COBJS-$(CONFIG_RTC_MPC8xx) += mpc8xx.o
COBJS-$(CONFIG_RTC_MV) += mvrtc.o
+COBJS-$(CONFIG_RTC_MX27) += mx27rtc.o
COBJS-$(CONFIG_RTC_MXS) += mxsrtc.o
COBJS-$(CONFIG_RTC_PCF8563) += pcf8563.o
COBJS-$(CONFIG_RTC_PL031) += pl031.o
diff --git a/drivers/rtc/mx27rtc.c b/drivers/rtc/mx27rtc.c
new file mode 100644
index 000..7628dec
--- /dev/null
+++ b/drivers/rtc/mx27rtc.c
@@ -0,0 +1,83 @@
+/*
+ * Freescale i.MX27 RTC Driver
+ *
+ * Copyright (C) 2012 Philippe Reynes trem...@yahoo.fr
+ *
+ * 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 common.h
+#include rtc.h
+#include asm/io.h
+#include asm/arch/imx-regs.h
+
+#define HOUR_SHIFT 8
+#define HOUR_MASK 0x1f
+#define MIN_SHIFT 0
+#define MIN_MASK 0x3f
+
+int rtc_get(struct rtc_time *time)
+{
+ struct rtc_regs *rtc_regs = (struct rtc_regs *)IMX_RTC_BASE;
+ uint32_t day, hour, min, sec;
+
+ day = readl(rtc_regs-dayr);
+ hour = readl(rtc_regs-hourmin);
+ sec = readl(rtc_regs-seconds);
+
+ min = (hour MIN_SHIFT) MIN_MASK;
+ hour = (hour HOUR_SHIFT) HOUR_MASK;
+
+ sec
Re: [U-Boot] [PATCH] MX: Set a common gpio.h for all i.MX
Dear Matt Sealey, On Sat, Aug 18, 2012 at 2:25 PM, Benoît Thébaudeau benoit.thebaud...@advansee.com wrote: Hi Stefano, This is a bit off topic, but shouldn't the iomux-v3 stuff be moved to a common location for all these i.MXs too? As to the header file, it's already done, but the C file is under arch/arm/cpu/armv7/imx-common/ while it is absolutely not armv7-specific. True, I'd advocate that. Ceretainly, but it can be done in a subsequent 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 v2 1/2] MX28: config: Allow different target generation in elftosb call
Dear Otavio Salvador, On Sat, Aug 18, 2012 at 3:03 PM, Marek Vasut marek.va...@gmail.com wrote: I think we should try and see if the mx28 and mx23 .bd can't be converged together too. Remind me in the evening (~4-5 hours from now) to try it. We can try but mx23 cannot use the ivt helper; so we ended having a specific file for each processor. Ooooh, that's correct. If we can get those merged, good. 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] MX: Set a common gpio.h for all i.MX
Am 18/08/2012 21:25, schrieb Benoît Thébaudeau:
#define MXC_GPIO_PORT_TO_NUM(port, bit) (((port - 1) 5) + (bit
0x1f))
Keeping this is also useless. GPIO_NUMBER() from the new
asm/imx-common/gpio.h
can be used instead everywhere needed.
That is right - I drop it.
-/* GPIO registers */
-struct gpio_regs {
-u32 gpio_dr;
-u32 gpio_dir;
-u32 gpio_psr;
-};
+#include asm/imx-common/gpio.h
#endif /* __ASM_ARCH_MX6_GPIO_H */
Why do you keep all these old asm/gpio.h? The new asm/imx-common/gpio.h
can
be included instead everywhere needed.
No. The GPIO is common for all SOCs in u-boot, not only i.MX. The common
interface requires that a asm/gpio.h exists. See common/cmd_gpio.c.
+#ifndef __ASM_ARCH_IMX_GPIO_H
+#define __ASM_ARCH_IMX_GPIO_H
+
+#if !(defined(__KERNEL_STRICT_NAMES) || defined(__ASSEMBLY__))
+/* GPIO registers */
+struct gpio_regs {
+u32 gpio_dr;/* data */
+u32 gpio_dir; /* direction */
+u32 psr;/* pad satus */
Why don't you rename this to gpio_psr to be more consistent?
I can do it, or drop it: psr is not used by the driver.
This made me wonder how mxc_gpio.c could build successfully with this naming.
psr is not used
It's because gpio_get_value() uses DR instead of PSR.
Exactly
This is an issue. Linux
uses PSR, and U-Boot should do so since DR does not always reflect the pin
state, while PSR does. This makes a big difference if you want to detect a
short
circuit on a GPIO pin configured as output, or if you want to read the level
of
a pin driven by a non-GPIO function. This is another patch to make.
Right, this is a patch for the gpio driver itself.
The rest sounds good.
This is a bit off topic,
Never mind.
but shouldn't the iomux-v3 stuff be moved to a common
location for all these i.MXs too? As to the header file, it's already done,
but
the C file is under arch/arm/cpu/armv7/imx-common/ while it is absolutely not
armv7-specific. Unlike Linux's, U-Boot's SoC files are organized per CPU
instead
of per platform, which makes the organization of such platform common code a
bit
complicated.
Right. I miss in u-boot a plat-mxc for common code.
This also encourages the duplication of platform code. Perhaps it
could be moved to a new arch/arm/cpu/imx-common/ folder (this would require an
addition to the main Makefile)?
Up now it was not yet done, because it is an exception in u-boot. But
surely, a common place for code across cpu boundaries helps for i.MX.
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-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 1/2] pxa25x: Add UDC registers definitions
Signed-off-by: Łukasz Dałek luk0...@gmail.com
---
arch/arm/include/asm/arch-pxa/regs-usb.h | 160 ++
1 files changed, 160 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/include/asm/arch-pxa/regs-usb.h
diff --git a/arch/arm/include/asm/arch-pxa/regs-usb.h
b/arch/arm/include/asm/arch-pxa/regs-usb.h
new file mode 100644
index 000..661ffe2
--- /dev/null
+++ b/arch/arm/include/asm/arch-pxa/regs-usb.h
@@ -0,0 +1,160 @@
+/*
+ * PXA25x UDC definitions
+ *
+ * Copyright (C) Łukasz Dałek luk0...@gmail.com
+ *
+ * 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 __REGS_USB_H__
+#define __REGS_USB_H__
+
+struct pxa25x_udc_regs {
+
+ /* UDC Control Register */
+ uint32_tudccr; /* 0x000 */
+ uint32_treserved1;
+
+ /* UDC Control Function Register */
+ uint32_tudccfr; /* 0x008 */
+ uint32_treserved2;
+
+ /* UDC Endpoint Control/Status Registers */
+ uint32_tudccs[16]; /* 0x010 - 0x04c */
+
+ /* UDC Interrupt Control/Status Registers */
+ uint32_tuicr0; /* 0x050 */
+ uint32_tuicr1; /* 0x054 */
+ uint32_tusir0; /* 0x058 */
+ uint32_tusir1; /* 0x05c */
+
+ /* UDC Frame Number/Byte Count Registers */
+ uint32_tufnrh; /* 0x060 */
+ uint32_tufnrl; /* 0x064 */
+ uint32_tubcr2; /* 0x068 */
+ uint32_tubcr4; /* 0x06c */
+ uint32_tubcr7; /* 0x070 */
+ uint32_tubcr9; /* 0x074 */
+ uint32_tubcr12; /* 0x078 */
+ uint32_tubcr14; /* 0x07c */
+
+ /* UDC Endpoint Data Registers */
+ uint32_tuddr0; /* 0x080 */
+ uint32_treserved3[7];
+ uint32_tuddr5; /* 0x0a0 */
+ uint32_treserved4[7];
+ uint32_tuddr10; /* 0x0c0 */
+ uint32_treserved5[7];
+ uint32_tuddr15; /* 0x0e0 */
+ uint32_treserved6[7];
+ uint32_tuddr1; /* 0x100 */
+ uint32_treserved7[31];
+ uint32_tuddr2; /* 0x180 */
+ uint32_treserved8[31];
+ uint32_tuddr3; /* 0x200 */
+ uint32_treserved9[127];
+ uint32_tuddr4; /* 0x400 */
+ uint32_treserved10[127];
+ uint32_tuddr6; /* 0x600 */
+ uint32_treserved11[31];
+ uint32_tuddr7; /* 0x680 */
+ uint32_treserved12[31];
+ uint32_tuddr8; /* 0x700 */
+ uint32_treserved13[127];
+ uint32_tuddr9; /* 0x900 */
+ uint32_treserved14[127];
+ uint32_tuddr11; /* 0xb00 */
+ uint32_treserved15[31];
+ uint32_tuddr12; /* 0xb80 */
+ uint32_treserved16[31];
+ uint32_tuddr13; /* 0xc00 */
+ uint32_treserved17[127];
+ uint32_tuddr14; /* 0xe00 */
+
+};
+
+#define PXA25X_UDC_BASE0x4060
+
+#define UDCCR_UDE (1 0)
+#define UDCCR_UDA (1 1)
+#define UDCCR_RSM (1 2)
+#define UDCCR_RESIR(1 3)
+#define UDCCR_SUSIR(1 4)
+#define UDCCR_SRM (1 5)
+#define UDCCR_RSTIR(1 6)
+#define UDCCR_REM (1 7)
+
+/* Bulk IN endpoint 1/6/11 */
+#define UDCCS_BI_TSP (1 7)
+#define UDCCS_BI_FST (1 5)
+#define UDCCS_BI_SST (1 4)
+#define UDCCS_BI_TUR (1 3)
+#define UDCCS_BI_FTF (1 2)
+#define UDCCS_BI_TPC (1 1)
+#define UDCCS_BI_TFS (1 0)
+
+/* Bulk OUT endpoint 2/7/12 */
+#define UDCCS_BO_RSP (1 7)
+#define UDCCS_BO_RNE (1 6)
+#define UDCCS_BO_FST (1 5)
+#define UDCCS_BO_SST (1 4)
+#define UDCCS_BO_DME (1 3)
+#define UDCCS_BO_RPC (1 1)
+#define UDCCS_BO_RFS (1 0)
+
+/* Isochronous OUT endpoint 4/9/14 */
+#define UDCCS_IO_RSP (1 7)
+#define UDCCS_IO_RNE (1 6)
+#define UDCCS_IO_DME (1 3)
+#define UDCCS_IO_ROF (1 2)
+#define UDCCS_IO_RPC (1 1)
+#define UDCCS_IO_RFS (1 0)
+
+/* Control endpoint 0 */
+#define UDCCS0_OPR
Re: [U-Boot] [PATCH 3/4] efikamx: update to Efika MX Smarttop and Smartbook boards
Dear Matt Sealey, On Sat, Aug 18, 2012 at 10:50 AM, Stefano Babic sba...@denx.de wrote: On 17/08/2012 20:19, Matt Sealey wrote: Anyway, who will maintain the efikas in future ? Marek, do you hold it, or Matt will take this job ? I'll do it but I doubt I'm going to be around as much as Marek. What I'm a little fearful of is having patches try and hit the Efika stuff and me not having much time that day to review, they either stagnate or get accepted anyway breaking something. So your commercial QA has to arrive at the RC stage and fix it if needed ... every around 3-4 months. I can't test every patch everyone sends, we just want to be sure it's hit a certain level of quality and solve some of the issues we hacked around at the Freescale BSP level are in mainline as we simply can't use the BSP version anymore (doesn't support bootz or device trees...) In last case I would like to see a patch for the MAINTAINER file. I'll submit it when I feel like we're actually being forced to maintain it. I am of two minds; I will be the responsible party if needs be, but that means Efika MX stuff is going to be commercially driven by our needs (i.e. runs our boot scripts, supports the board the way we dictate (no video, no usb keyboards..), no changes to support developers if they are simply being too needy), and if it doesn't suit us in terms of breaking something or changing behaviour wildly, we'll NACK the crap out of it. I think you need to understand that FOSS is a cooperative effort. It is not any commercial crap which you roll out and throw away when it made enough money. We will not stop hacking on mx51 only because it might break your platform, that's not how it works. To put it into more commercial terms, we are not paid to support your platform, on the other hand, we already gave you the source code. So to restore the balance, you help us keeping it working well by investing in QA. Everyone's happy. Besides, if you want to deploy less potent version, you can always configure your u-boot in such way and deploy it to customer, noone can prevent you from that. But since there is support for certain additional hardware in upstream already, I'd object to remove it. If that's acceptable, sure... Marek says U-Boot doesn't follow this development model, but that would put Denx out of business. Please stop putting words in my mouth, it is fairy insulting. See how the mx28 stuff is being developed to see what I mean. Me, Fabio, Otavio and many others are adjusting each others boards and it works very well. 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/2] MX28: config: Allow different target generation in elftosb call
On Sat, Aug 18, 2012 at 7:06 PM, Marek Vasut ma...@denx.de wrote: Dear Otavio Salvador, On Sat, Aug 18, 2012 at 3:03 PM, Marek Vasut marek.va...@gmail.com wrote: I think we should try and see if the mx28 and mx23 .bd can't be converged together too. Remind me in the evening (~4-5 hours from now) to try it. We can try but mx23 cannot use the ivt helper; so we ended having a specific file for each processor. Ooooh, that's correct. If we can get those merged, good. So; what we should do? Do you think this can be merged as is? -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] efikamx: remove drive strength hack from early_init_f and move it to the DCD
Dear Matt Sealey, On Sat, Aug 18, 2012 at 10:34 AM, Stefano Babic sba...@denx.de wrote: On 17/08/2012 20:19, Matt Sealey wrote: The i.MX Boot ROM lets us set up certain registers before U-Boot even gets executed. Rather than setting up DDR, putting U-Boot in place, and getting into pre-relocation init to set up DDR again, just do it once in the correct place. This also solves an issue where the Smarttop DDR pad settings were being applied on Smartbook. While we're at it, configure PCBID0,1,2 and the LED GPIO since we've still got room in the DCD to do so. Signed-off-by: Matt Sealey m...@genesi-usa.com --- Hi Matt, diff --git a/board/genesi/mx51_efikamx/imximage_mx.cfg b/board/genesi/mx51_efikamx/imximage_mx.cfg index 6fe0ff9..ac9aa9a 100644 --- a/board/genesi/mx51_efikamx/imximage_mx.cfg +++ b/board/genesi/mx51_efikamx/imximage_mx.cfg @@ -1,7 +1,7 @@ # +# Copyright (C) 2009 Pegatron Corporation ^--- Was this added for mistake ? I think you should add only yours. The drive strength settings came from Pegatron a long, long time ago (2009 :) and our old config and the function is copyrighted to them. Just because Marek took them out and recopyrighted the file I derived them from in this case doesn't mean they lost their copyright.. This file was taken from mx51evk. It's written there. Please stop this nonsense, it's troubling me. I join Marek, it is quite difficult to review it and understand which was changed. It looks like a new file.. It's just because I moved the comments to the end of the line, so it's blocking it up. Sometimes it's nicer if it's -this line +that line -this line +that line .. but that's not how git does it when the change is more than a few characters and multiple lines changed.. I can submit it differently but I can't change the way it's producing the diff. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] efikamx: update to Efika MX Smarttop and Smartbook boards
Am 18/08/2012 23:02, schrieb Matt Sealey: On Sat, Aug 18, 2012 at 10:50 AM, Stefano Babic sba...@denx.de wrote: On 17/08/2012 20:19, Matt Sealey wrote: Anyway, who will maintain the efikas in future ? Marek, do you hold it, or Matt will take this job ? I can't test every patch everyone sends, we just want to be sure it's hit a certain level of quality and solve some of the issues we hacked around at the Freescale BSP level are in mainline as we simply can't use the BSP version anymore (doesn't support bootz or device trees...) In last case I would like to see a patch for the MAINTAINER file. I'll submit it when I feel like we're actually being forced to maintain it. You are absolutely not forced - my was a simple question. I am of two minds; I will be the responsible party if needs be, but that means Efika MX stuff is going to be commercially driven by our needs (i.e. runs our boot scripts, supports the board the way we dictate (no video, no usb keyboards..), no changes to support developers if they are simply being too needy), You are confusing commercial goals with an open source project, as u-boot is. and if it doesn't suit us in terms of breaking something or changing behaviour wildly, we'll NACK the crap out of it. If that's acceptable, sure... You can propose your boot scripts to the ML, and they can be accepted or not, depending if they are helpful for the project. Marek says U-Boot doesn't follow this development model, but that would put Denx out of business. Not really - again, you are confusing the way you want to put your products on the market with an open source project. You can sell of course your product with the software you decide and you think it is better - this is your commercial decision. An open source project is developped with different goals, that are not strictly bound to a single commercial product. 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
Re: [U-Boot] [PATCH 2/4] efikamx: remove drive strength hack from early_init_f and move it to the DCD
Am 18/08/2012 23:11, schrieb Matt Sealey: @@ -1,7 +1,7 @@ # +# Copyright (C) 2009 Pegatron Corporation ^--- Was this added for mistake ? I think you should add only yours. The drive strength settings came from Pegatron a long, long time ago (2009 :) and our old config and the function is copyrighted to them. Just because Marek took them out and recopyrighted the file I derived them from in this case doesn't mean they lost their copyright.. Ok, explained - then it is a fixed for a missing copyright. I join Marek, it is quite difficult to review it and understand which was changed. It looks like a new file.. It's just because I moved the comments to the end of the line, so it's blocking it up. Sometimes it's nicer if it's -this line +that line -this line +that line .. but that's not how git does it when the change is more than a few characters and multiple lines changed.. I can submit it differently but I can't change the way it's producing the diff. In principle I have not a problem with it - you are the best tester for the DCD table, and you report it is well tested for your board. It is customized for your board and it is not common i.MX code - I can't only make a review because it is difficult to read it. 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
Re: [U-Boot] [PATCH] mx5: add iomux-mx51.h include
Am 18/08/2012 23:18, schrieb Matt Sealey: I will, for now it's the top of Linus' tree, but this code is going to get removed from the Linux kernel soon, so I understand, we need to figure out where it will last forever (probably linux-stable@3.5) so we can always reference it. Right. Add the Linux commit-id in your commit message. I do like we add a second identical defeine why we discover an issue in another part of code. I know for experience that code introduced this the goal to fix it later will never be fixed. So let's see if we can jut do the right thing. I do not think imx-common/iomux-v3.h is the right place. What has the pinmux with gpio to do? This is also wrongit is GPIO related, it should go into gpio.h. That's true. I did not want to mess the patchset up with boards I cannot test though, and I don't like committing code I didn't test (mx3 gpio etc.) even if the docs say as much as it's identical. I see you already fixed that though. Ok, but again thanks for raise the issue. I'll rebase on Monday and submit something new... see below, though.. + +#endif /* __IOMUX_MX51_H__ */ Ok, good, this is the same as in kernel. Right. This all came from a discussion with Troy and Eric at BoundaryDevices about i2c multi-bus support, they sent us a file with MX6 support and a hack for MX5 support to go with it; it didn't work and I figured it'd be a good thing to complete. Troy suggested not copying the Linux file verbatim (after all, why include camera bus pinmux when U-Boot won't support a camera bus?) and just include the pins we wanted. I agree with Troy. U-boot should set only what it needs, nothing more. I just noticed that the imx-common/iomux-v3.h is out of date re the latest kernel too (some bits have moved as MX6 needs extra space to store some setting) so I'll patch that in as well. I think we need to make a small discussion point here (new thread?) about what needs to be done and what has been done, since if this isn't a tree and just patches on a mailing list or in a patchwork it's infuriatingly hard to track what is going on and who patched what and what to base against. Youm see that the maintainer's work can be hard...;-) I may have to wait until something like your gpio.h changes hit the u-boot-imx tree.. I got a lot of patches in the last time, not only from you and Benoit. Some of them are related, and I do not want to push a broken tree. My plan is to merge the patches that are acked and free of comments, pushing them to u-boot-imx. I think you have not to wait long. 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-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] MX28: config: Allow different target generation in elftosb call
Am 19/08/2012 00:28, schrieb Otavio Salvador: On Sat, Aug 18, 2012 at 7:06 PM, Marek Vasut ma...@denx.de wrote: Dear Otavio Salvador, On Sat, Aug 18, 2012 at 3:03 PM, Marek Vasut marek.va...@gmail.com wrote: I think we should try and see if the mx28 and mx23 .bd can't be converged together too. Remind me in the evening (~4-5 hours from now) to try it. We can try but mx23 cannot use the ivt helper; so we ended having a specific file for each processor. Ooooh, that's correct. If we can get those merged, good. So; what we should do? Do you think this can be merged as is? IMHO yes and I will do it, if one of you don't stop me... Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] efikamx: remove drive strength hack from early_init_f and move it to the DCD
Am 19/08/2012 00:29, schrieb Marek Vasut: Dear Matt Sealey, On Sat, Aug 18, 2012 at 10:34 AM, Stefano Babic sba...@denx.de wrote: On 17/08/2012 20:19, Matt Sealey wrote: The i.MX Boot ROM lets us set up certain registers before U-Boot even gets executed. Rather than setting up DDR, putting U-Boot in place, and getting into pre-relocation init to set up DDR again, just do it once in the correct place. This also solves an issue where the Smarttop DDR pad settings were being applied on Smartbook. While we're at it, configure PCBID0,1,2 and the LED GPIO since we've still got room in the DCD to do so. Signed-off-by: Matt Sealey m...@genesi-usa.com --- Hi Matt, diff --git a/board/genesi/mx51_efikamx/imximage_mx.cfg b/board/genesi/mx51_efikamx/imximage_mx.cfg index 6fe0ff9..ac9aa9a 100644 --- a/board/genesi/mx51_efikamx/imximage_mx.cfg +++ b/board/genesi/mx51_efikamx/imximage_mx.cfg @@ -1,7 +1,7 @@ # +# Copyright (C) 2009 Pegatron Corporation ^--- Was this added for mistake ? I think you should add only yours. The drive strength settings came from Pegatron a long, long time ago (2009 :) and our old config and the function is copyrighted to them. Just because Marek took them out and recopyrighted the file I derived them from in this case doesn't mean they lost their copyright.. This file was taken from mx51evk. It's written there. Please stop this nonsense, it's troubling me. Then Pegatron has nothing to do with it. The original comes from Freescale, and the copyright was set. 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
Re: [U-Boot] [PATCH] MX: Set a common gpio.h for all i.MX
Hi Stefano, On Sat, Aug 18, 2012 at 12:26 PM, Stefano Babic sba...@denx.de wrote: +#define GPIO_NUMBER(port, index) port)-1)*32)+((index)31)) What about calling this macro IMX_GPIO_NR instead? This way we can have the same macro name in U-boot and in the kernel. Thanks, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] MX28: config: Allow different target generation in elftosb call
Dear stefano babic, Am 19/08/2012 00:28, schrieb Otavio Salvador: On Sat, Aug 18, 2012 at 7:06 PM, Marek Vasut ma...@denx.de wrote: Dear Otavio Salvador, On Sat, Aug 18, 2012 at 3:03 PM, Marek Vasut marek.va...@gmail.com wrote: I think we should try and see if the mx28 and mx23 .bd can't be converged together too. Remind me in the evening (~4-5 hours from now) to try it. We can try but mx23 cannot use the ivt helper; so we ended having a specific file for each processor. Ooooh, that's correct. If we can get those merged, good. So; what we should do? Do you think this can be merged as is? IMHO yes and I will do it, if one of you don't stop me... Yes please, throw it in the machine! :-) Acked-by: Marek Vasut ma...@denx.de 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] MX: Set a common gpio.h for all i.MX
Dear Fabio Estevam, Hi Stefano, On Sat, Aug 18, 2012 at 12:26 PM, Stefano Babic sba...@denx.de wrote: +#define GPIO_NUMBER(port, index) port)-1)*32)+((index)31)) What about calling this macro IMX_GPIO_NR instead? This way we can have the same macro name in U-boot and in the kernel. Agreed 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 1/2] pxa25x: Add UDC registers definitions
Dear Łukasz Dałek, Signed-off-by: Łukasz Dałek luk0...@gmail.com [...] +/* + * Intel(R) PXA255 Processor Specification Update (page 31) + * define new must be one bits in UDCCFR + */ I adjusted this a bit. +#define UDCCFR_MB1 (0xff ~(UDCCFR_AREN | UDCCFR_ACM)) + +#define UFNRH_SIR(1 7)/* SOF interrupt request */ +#define UFNRH_SIM(1 6)/* SOF interrupt mask */ +#define UFNRH_IPE14 (1 5)/* ISO packet error, ep14 */ +#define UFNRH_IPE9 (1 4)/* ISO packet error, ep9 */ +#define UFNRH_IPE4 (1 3)/* ISO packet error, ep4 */ + +#endif /* __REGS_USB_H__ */ Applied and pushed to u-boot-usb.git, thanks! Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] usb_test_unit_ready called every block read - performance
Dear Jim Shimer,
Hi Marek,
I looked at the ext4 branch. It looks like he has the patch to remove the
usb_test_unit_ready() calls which were not needed. Actually those calls are
commented out on that branch:
#if 0
if (usb_test_unit_ready(srb, ss)) {
printf(Device NOT ready\n Request Sense returned %02X
%02X
%02X\n, srb-sense_buf[2], srb-sense_buf[12],
srb-sense_buf[13]);
return 0;
}
#endif
In the u-boot-usb.git, this code is removed so at some point there will be
a merge conflict.
Also the ext4 branch still has the mdelay(5) always being done in
usb_stor_BBB_transport() line 696 which we found to be the largest
performance killer.
The ext4 branch doesn't contain a few other things indeed. Can you try applying
the ext4 patches on uboot-usb and retest?
Regards,
Jim
On Sun, Aug 12, 2012 at 7:54 PM, Marek Vasut ma...@denx.de wrote:
Dear Jim Shimer,
While tuning ext2load, we found that usb_test_unit_ready was being
called every block read. We compared the usb block storage to the
scsi block storage cmd_scsi.c, and found that the scsi device was only
calling its scsi_setup_test_unit_ready() during scsi_can. It appears
that usb_test_unit_ready() really only needs to be called once during
usb_stor_scan(), via usb_stor_get_info(). Is there a particular
reason usb_test_unit_ready is called for every block read, or do you
think its
ok
to only call during usb_stor_scan()? We're finding this speeds up
ext2load
quite a bit.
Jim, did we get anywhere on this one ? Can you try with the new ext4 code
in
Wolfgangs' u-boot-master/ext4 branch?
Regards,
Jim
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] usb_test_unit_ready called every block read - performance
Dear Steve Heckman,
Oh yeah, forgot about that...;)
I just downloaded the ext4 branch tarball and built it.
The test_unit_ready calls were still in there.
With or without those it took 0m 45s to load a ~150MB image.
In our original branch (2011.12), the test_unit_ready calls had more of an
impact. The stock 2011.12 u-boot image took 6m 22s to load the 150MB file.
Without test_unit_ready, it took 3m 15s. Without test_unit_ready and
wait_ms(5) in usb_stor_BBB_transport() it took 0m 16s.
In the ext4 branch, I removed test_unit_ready and the mdelay(5) call
from usb_stor_BBB_transport() function and was able to load the same file
in 0m 8s.
So, removing the mdelay(5) call is the biggest improvement. Removing both
is the best.
To recap:
with w/o w/o
TUR TUR TUR and 5ms wait
2011.12 6:25 3:15 0:16
ext40:45 0:45 0:08
Note: all these time include the 3-4 seconds it takes to do the usb
start.
Coolness ! :-) Please just retest by applying those ext4 patches on top of
uboot
usb and see how fast it goes :)
Regards,
-Steve
On Wed, Aug 15, 2012 at 10:19 AM, Jim Shimer mgi2...@motorola.com wrote:
Hi Marek,
I looked at the ext4 branch. It looks like he has the patch to remove
the usb_test_unit_ready() calls which were not needed. Actually those
calls are commented out on that branch:
#if 0
if (usb_test_unit_ready(srb, ss)) {
printf(Device NOT ready\n Request Sense returned %02X
%02X
%02X\n, srb-sense_buf[2], srb-sense_buf[12],
srb-sense_buf[13]);
return 0;
}
#endif
In the u-boot-usb.git, this code is removed so at some point there will
be a merge conflict.
Also the ext4 branch still has the mdelay(5) always being done in
usb_stor_BBB_transport() line 696 which we found to be the largest
performance killer.
Regards,
Jim
On Sun, Aug 12, 2012 at 7:54 PM, Marek Vasut ma...@denx.de wrote:
Dear Jim Shimer,
While tuning ext2load, we found that usb_test_unit_ready was being
called
every block read. We compared the usb block storage to the scsi block
storage cmd_scsi.c, and found that the scsi device was only calling
its scsi_setup_test_unit_ready() during scsi_can. It appears that
usb_test_unit_ready() really only needs to be called once during
usb_stor_scan(), via usb_stor_get_info(). Is there a particular
reason usb_test_unit_ready is called for every block read, or do you
think its
ok
to only call during usb_stor_scan()? We're finding this speeds up
ext2load
quite a bit.
Jim, did we get anywhere on this one ? Can you try with the new ext4
code in
Wolfgangs' u-boot-master/ext4 branch?
Regards,
Jim
Best regards,
Marek Vasut
--
*James H Shimer*
Motorola Mobility T3-12-HH72
900 Chelmsford Street
Lowell MA 08151
978-614-3550
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] mx28evk: Remove unneeded 'undef'
From: Fabio Estevam fabio.este...@freescale.com There is no need to undef an option that is not enabled by default. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- include/configs/mx28evk.h |1 - 1 file changed, 1 deletion(-) diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h index 4e70617..b677e51 100644 --- a/include/configs/mx28evk.h +++ b/include/configs/mx28evk.h @@ -215,7 +215,6 @@ #define CONFIG_SF_DEFAULT_SPEED2400 /* (redundant) environemnt in SPI flash */ -#undef CONFIG_ENV_IS_IN_SPI_FLASH #ifdef CONFIG_ENV_IS_IN_SPI_FLASH #define CONFIG_SYS_REDUNDAND_ENVIRONMENT #define CONFIG_ENV_SIZE0x1000 /* 4KB */ -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] mxs: Use correct function name to initialize dram
From: Fabio Estevam fabio.este...@freescale.com
commit d92591a (mxs: Convert sys_proto.h prefixes to 'mxs') introduced
a mxs_dram_init() function, which is not used anywhere.
Fix it, so that the following warning goes away:
mx28evk.c: In function ‘dram_init’:
mx28evk.c:67:2: warning: implicit declaration of function ‘mx28_dram_init’
[-Wimplicit-function-declaration]
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
arch/arm/include/asm/arch-mxs/sys_proto.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/arch-mxs/sys_proto.h
b/arch/arm/include/asm/arch-mxs/sys_proto.h
index 9d1e599..4610363 100644
--- a/arch/arm/include/asm/arch-mxs/sys_proto.h
+++ b/arch/arm/include/asm/arch-mxs/sys_proto.h
@@ -69,6 +69,6 @@ struct mxs_spl_data {
uint32_tmem_dram_size;
};
-int mxs_dram_init(void);
+int mx28_dram_init(void);
#endif /* __SYS_PROTO_H__ */
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] mx28evk: Remove unneeded 'undef'
Dear Fabio Estevam, From: Fabio Estevam fabio.este...@freescale.com There is no need to undef an option that is not enabled by default. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- include/configs/mx28evk.h |1 - 1 file changed, 1 deletion(-) diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h index 4e70617..b677e51 100644 --- a/include/configs/mx28evk.h +++ b/include/configs/mx28evk.h @@ -215,7 +215,6 @@ #define CONFIG_SF_DEFAULT_SPEED 2400 /* (redundant) environemnt in SPI flash */ -#undef CONFIG_ENV_IS_IN_SPI_FLASH #ifdef CONFIG_ENV_IS_IN_SPI_FLASH #define CONFIG_SYS_REDUNDAND_ENVIRONMENT #define CONFIG_ENV_SIZE 0x1000 /* 4KB */ Acked-by: Marek Vasut ma...@denx.de Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] mxs: Use correct function name to initialize dram
Dear Fabio Estevam,
From: Fabio Estevam fabio.este...@freescale.com
commit d92591a (mxs: Convert sys_proto.h prefixes to 'mxs') introduced
a mxs_dram_init() function, which is not used anywhere.
Fix it, so that the following warning goes away:
mx28evk.c: In function ‘dram_init’:
mx28evk.c:67:2: warning: implicit declaration of function ‘mx28_dram_init’
[-Wimplicit-function-declaration]
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
arch/arm/include/asm/arch-mxs/sys_proto.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/arch-mxs/sys_proto.h
b/arch/arm/include/asm/arch-mxs/sys_proto.h index 9d1e599..4610363 100644
--- a/arch/arm/include/asm/arch-mxs/sys_proto.h
+++ b/arch/arm/include/asm/arch-mxs/sys_proto.h
@@ -69,6 +69,6 @@ struct mxs_spl_data {
uint32_tmem_dram_size;
};
-int mxs_dram_init(void);
+int mx28_dram_init(void);
#endif /* __SYS_PROTO_H__ */
Acked-by: Marek Vasut ma...@denx.de
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MX: Set a common gpio.h for all i.MX
Hi Stefano,
#define MXC_GPIO_PORT_TO_NUM(port, bit) (((port - 1) 5) + (bit
0x1f))
Keeping this is also useless. GPIO_NUMBER() from the new
asm/imx-common/gpio.h
can be used instead everywhere needed.
That is right - I drop it.
I don't know if you are aware of it, but just to let you know, I've seen the
following patch that will interfere:
http://patchwork.ozlabs.org/patch/165311/
http://git.denx.de/?p=u-boot/u-boot-staging.git;a=commitdiff;h=72739219a12bf02820d29a89cb2b7fdc4d0e840f
You may want to merge it to your imx tree and rebase after it for your patch.
-/* GPIO registers */
-struct gpio_regs {
- u32 gpio_dr;
- u32 gpio_dir;
- u32 gpio_psr;
-};
+#include asm/imx-common/gpio.h
#endif/* __ASM_ARCH_MX6_GPIO_H */
Why do you keep all these old asm/gpio.h? The new
asm/imx-common/gpio.h can
be included instead everywhere needed.
No. The GPIO is common for all SOCs in u-boot, not only i.MX. The
common
interface requires that a asm/gpio.h exists. See common/cmd_gpio.c.
Right.
Best regards,
Benoît
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [[Patch V2] mips: 01/16] add mips64 standalone support
On 8/18/12, Mike Frysinger vap...@gentoo.org wrote: On Saturday 18 August 2012 08:22:51 Zhi-zhou Zhang wrote: On Sat, Aug 18, 2012 at 3:31 AM, Mike Frysinger wrote: On Friday 17 August 2012 11:30:44 Zhizhou Zhang wrote: --- a/arch/mips/config.mk +++ b/arch/mips/config.mk +ifeq $(CPU) mips64 +CONFIG_STANDALONE_LOAD_ADDR ?= 0xFfffFfff8020 -T mips64.lds +else CONFIG_STANDALONE_LOAD_ADDR ?= 0x8020 -T mips.lds +endif the cpu config.mk is sourced after this one. you could change this to: CONFIG_STANDALONE_LOAD_ADDR ?= $(DEFAULT_MIPS_STANDALONE_LOAD_ADDR) DEFAULT_MIPS_STANDALONE_LOAD_ADDR = 0x8020 -T mips.lds then in the mips64/config.mk: DEFAULT_MIPS_STANDALONE_LOAD_ADDR = 0xFfffFfff8020 -T mips64.lds Thanks for you advising. But if I changed like so, I should modify mips32/ config.mk and xburst/config.mk as also. why ? my suggestion shouldn't affect any other cpu config.mk. -mike Oh, I'm so sorry, I think that you mean to replace CONFIG_STANDALONE_LOAD_ADDR by DEFAULT_MIPS_STANDALONE_LOAD_ADDR. So your idea is to keep both CONFIG_STANDALONE_LOAD_ADDR and DEFAULT_MIPS_STANDALONE_LOAD_ADDR, one for mips64, anther for mips32. Actually I haven't test standalone example. I add standalone config and build option for I would get an error if didn't do that. It brings me a lot of mess. I want to disable stanalone support in TOP Makefile, could I do that? -- Regards, Zhizhou Zhang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] pxa25x: Add USB ethernet gadget driver
Dear Łukasz Dałek,
[...]
The following comment still doesn't seem right.
+/*
--
- + * endpoint related parts of the api to the usb controller hardware, +
* used by gadget driver; and the inner talker-to-hardware core.
+ *
--
- + */
[...]
+
+/*
+ * when a driver is successfully registered, it will receive
+ * control requests including set_configuration(), which enables
+ * non-control requests. then usb traffic follows until a
+ * disconnect is reported. then a host may connect again, or
+ * the driver might get unbound.
+ */
+int usb_gadget_register_driver(struct usb_gadget_driver *driver)
+{
All this should certainly go into arch/arm/cpu/pxa/ ... as something like
get_cpu_revision or such ... don't you think? Then it can be used elsewhere
too if needed, give it some thought ;-)
+ struct pxa25x_udc *dev = memory;
+ int retval;
+ uint32_t chiprev;
+
+ if (!driver
+ || driver-speed USB_SPEED_FULL
+ || !driver-disconnect
+ || !driver-setup)
+ return -EINVAL;
+ if (!dev)
+ return -ENODEV;
+ if (dev-driver)
+ return -EBUSY;
+
+ /* Enable clock for usb controller */
+ setbits_le32(CKEN, CKEN11_USB);
+
+ /* first hook up the driver ... */
+ dev-driver = driver;
+ dev-pullup = 1;
+
+ /* insist on Intel/ARM/XScale */
+ asm(mrc%? p15, 0, %0, c0, c0 : =r (chiprev));
+ if ((chiprev CP15R0_VENDOR_MASK) != CP15R0_XSCALE_VALUE) {
+ printf(%s: not XScale!\n, DRIVER_NAME);
+ return -ENODEV;
+ }
+
+ /* trigger chiprev-specific logic */
+ switch (chiprev CP15R0_PRODREV_MASK) {
+ case PXA255_A0:
+ dev-has_cfr = 1;
+ break;
+ case PXA250_A0:
+ case PXA250_A1:
+ /* A0/A1 not released; ep 13, 15 unusable */
+ /* fall through */
+ case PXA250_B2: case PXA210_B2:
+ case PXA250_B1: case PXA210_B1:
+ case PXA250_B0: case PXA210_B0:
+ /* OUT-DMA is broken ... */
+ /* fall through */
+ case PXA250_C0: case PXA210_C0:
+ break;
+ default:
+ printf(%s: unrecognized processor: %08x\n,
+ DRIVER_NAME, chiprev);
+ return -ENODEV;
+ }
+
+ the_controller = dev;
+
+ /* prepare watchdog timer */
+ dev-watchdog.running = 0;
+ dev-watchdog.period = 5000 * CONFIG_SYS_HZ / 100; /* 5 ms */
+ dev-watchdog.function = udc_watchdog;
+
+ udc_disable(dev);
+ udc_reinit(dev);
+
+ dev-mach = mach_info;
+
+ dev-gadget.name = pxa2xx_udc;
+ retval = driver-bind(dev-gadget);
+ if (retval) {
+ printf(bind to driver %s -- error %d\n,
+ DRIVER_NAME, retval);
+ dev-driver = NULL;
+ return retval;
+ }
+
+ /*
+ * ... then enable host detection and ep0; and we're ready
+ * for set_configuration as well as eventual disconnect.
+ */
+ printf(registered gadget driver '%s'\n, DRIVER_NAME);
+
+ pullup(dev);
+ dump_state(dev);
+ return 0;
+}
[...]
+struct pxa25x_request {
+ struct usb_request req;
+ struct list_headqueue;
+};
+
+enum ep0_state {
+ EP0_IDLE,
+ EP0_IN_DATA_PHASE,
+ EP0_OUT_DATA_PHASE,
+ EP0_END_XFER,
+ EP0_STALL,
+};
+
+#define EP0_FIFO_SIZE((unsigned)16)
Wasn't there something like 16U or something instead of the typecast?
+#define BULK_FIFO_SIZE ((unsigned)64)
+#define ISO_FIFO_SIZE((unsigned)256)
+#define INT_FIFO_SIZE((unsigned)8)
+
+struct udc_stats {
+ struct ep0stats {
+ unsigned long ops;
+ unsigned long bytes;
+ } read, write;
+ unsigned long irqs;
+};
+
+#ifdef CONFIG_USB_PXA25X_SMALL
+/* when memory's tight, SMALL config saves code+data. */
+#define PXA_UDC_NUM_ENDPOINTS 3
+#endif
+
+#ifndef PXA_UDC_NUM_ENDPOINTS
+#define PXA_UDC_NUM_ENDPOINTS 16
+#endif
+
+struct pxa25x_watchdog {
+ unsignedrunning:1;
+ ulong period;
+ ulong base;
+ struct pxa25x_udc *udc;
+
+ void (*function)(struct pxa25x_udc *udc);
+};
+
+struct pxa25x_udc {
+ struct usb_gadget gadget;
+ struct usb_gadget_driver*driver;
+ struct pxa25x_udc_regs *regs;
+
+ enum ep0_state ep0state;
+ struct udc_statsstats;
+ unsigned
