Re: [U-Boot] [RFC} [PATCH] Feature removal due to lack of custodians
Hi Wolfgang, On Sat, Feb 25, 2012 at 2:10 PM, Wolfgang Denk w...@denx.de wrote: Despite several calls nobody volunteered to help out. Signed-off-by: Wolfgang Denk w...@denx.de --- doc/feature-removal-schedule.txt | 14 ++ 1 files changed, 14 insertions(+), 0 deletions(-) diff --git a/doc/feature-removal-schedule.txt b/doc/feature-removal-schedule.txt index e04ba2d..f0b828e 100644 --- a/doc/feature-removal-schedule.txt +++ b/doc/feature-removal-schedule.txt @@ -7,6 +7,20 @@ file. --- +What: USB Support +When: v2012.06 +Why: Lack of a custodian, and lack of time and/or sponsors. +Who: Wolfgang Denk w...@denx.de + +--- + +What: Network Support +When: v2012.09 +Why: Lack of a custodian, and lack of time and/or sponsors. +Who: Wolfgang Denk w...@denx.de I might be able to help out with the network side. I am unsure of the qualifications needed to be a custodian though. Regards, Simon + +--- + What: Users of the legacy miiphy_* code When: undetermined -- 1.7.7.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] [OMAP3] Pass timings structure pointer to board_get_mem_timings()
Instead of passing individual registers by value to board_get_mem_timings,
pass a board_mem_timings structure pointer for the board files to fill in.
Pass same structure pointer to write_sdrc_timings. This saves about
90 bytes of space in SPL.
Signed-off-by: Peter Barada peter.bar...@logicpd.com
---
arch/arm/cpu/armv7/omap3/sdrc.c | 36 --
arch/arm/include/asm/arch-omap3/sys_proto.h | 12 +-
board/corscience/tricorder/tricorder.c | 13 +++
board/overo/overo.c | 37 +--
board/ti/beagle/beagle.c| 53 +--
board/ti/evm/evm.c | 19 +-
board/timll/devkit8000/devkit8000.c | 13 +++
7 files changed, 91 insertions(+), 92 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap3/sdrc.c b/arch/arm/cpu/armv7/omap3/sdrc.c
index 91f42c0..4d8a57a 100644
--- a/arch/arm/cpu/armv7/omap3/sdrc.c
+++ b/arch/arm/cpu/armv7/omap3/sdrc.c
@@ -113,18 +113,18 @@ u32 get_sdr_cs_offset(u32 cs)
* - Test CS to make sure it's OK for use
*/
static void write_sdrc_timings(u32 cs, struct sdrc_actim *sdrc_actim_base,
- u32 mcfg, u32 ctrla, u32 ctrlb, u32 rfr_ctrl, u32 mr)
+ struct board_mem_timings *timings)
{
/* Setup timings we got from the board. */
- writel(mcfg, sdrc_base-cs[cs].mcfg);
- writel(ctrla, sdrc_actim_base-ctrla);
- writel(ctrlb, sdrc_actim_base-ctrlb);
- writel(rfr_ctrl, sdrc_base-cs[cs].rfr_ctrl);
+ writel(timings-mcfg, sdrc_base-cs[cs].mcfg);
+ writel(timings-ctrla, sdrc_actim_base-ctrla);
+ writel(timings-ctrlb, sdrc_actim_base-ctrlb);
+ writel(timings-rfr_ctrl, sdrc_base-cs[cs].rfr_ctrl);
writel(CMD_NOP, sdrc_base-cs[cs].manual);
writel(CMD_PRECHARGE, sdrc_base-cs[cs].manual);
writel(CMD_AUTOREFRESH, sdrc_base-cs[cs].manual);
writel(CMD_AUTOREFRESH, sdrc_base-cs[cs].manual);
- writel(mr, sdrc_base-cs[cs].mr);
+ writel(timings-mr, sdrc_base-cs[cs].mr);
/*
* Test ram in this bank
@@ -143,7 +143,7 @@ static void write_sdrc_timings(u32 cs, struct sdrc_actim
*sdrc_actim_base,
void do_sdrc_init(u32 cs, u32 early)
{
struct sdrc_actim *sdrc_actim_base0, *sdrc_actim_base1;
- u32 mcfg, ctrla, ctrlb, rfr_ctrl, mr;
+ struct board_mem_timings timings;
sdrc_actim_base0 = (struct sdrc_actim *)SDRC_ACTIM_CTRL0_BASE;
sdrc_actim_base1 = (struct sdrc_actim *)SDRC_ACTIM_CTRL1_BASE;
@@ -158,7 +158,7 @@ void do_sdrc_init(u32 cs, u32 early)
* setup CS1.
*/
#ifdef CONFIG_SPL_BUILD
- get_board_mem_timings(mcfg, ctrla, ctrlb, rfr_ctrl, mr);
+ get_board_mem_timings(timings);
#endif
if (early) {
/* reset sdrc controller */
@@ -177,11 +177,9 @@ void do_sdrc_init(u32 cs, u32 early)
writel(ENADLL | DLLPHASE_90, sdrc_base-dlla_ctrl);
sdelay(0x2);
#ifdef CONFIG_SPL_BUILD
- write_sdrc_timings(CS0, sdrc_actim_base0, mcfg, ctrla, ctrlb,
- rfr_ctrl, mr);
+ write_sdrc_timings(CS0, sdrc_actim_base0, timings);
make_cs1_contiguous();
- write_sdrc_timings(CS0, sdrc_actim_base1, mcfg, ctrla, ctrlb,
- rfr_ctrl, mr);
+ write_sdrc_timings(CS0, sdrc_actim_base1, timings);
#endif
}
@@ -193,14 +191,12 @@ void do_sdrc_init(u32 cs, u32 early)
* so we may be asked now to setup CS1.
*/
if (cs == CS1) {
- mcfg = readl(sdrc_base-cs[CS0].mcfg),
- rfr_ctrl = readl(sdrc_base-cs[CS0].rfr_ctrl);
- ctrla = readl(sdrc_actim_base0-ctrla),
- ctrlb = readl(sdrc_actim_base0-ctrlb);
- mr = readl(sdrc_base-cs[CS0].mr);
- write_sdrc_timings(cs, sdrc_actim_base1, mcfg, ctrla, ctrlb,
- rfr_ctrl, mr);
-
+ timings.mcfg = readl(sdrc_base-cs[CS0].mcfg);
+ timings.rfr_ctrl = readl(sdrc_base-cs[CS0].rfr_ctrl);
+ timings.ctrla = readl(sdrc_actim_base0-ctrla),
+ timings.ctrlb = readl(sdrc_actim_base0-ctrlb);
+ timings.mr = readl(sdrc_base-cs[CS0].mr);
+ write_sdrc_timings(cs, sdrc_actim_base1, timings);
}
}
diff --git a/arch/arm/include/asm/arch-omap3/sys_proto.h
b/arch/arm/include/asm/arch-omap3/sys_proto.h
index 2a89e56..723e445 100644
--- a/arch/arm/include/asm/arch-omap3/sys_proto.h
+++ b/arch/arm/include/asm/arch-omap3/sys_proto.h
@@ -32,6 +32,15 @@ struct emu_hal_params {
u32 param1;
};
+/* Board DRAM timing values */
+struct board_mem_timings {
+ u32 mcfg;
+ u32 ctrla;
+ u32 ctrlb;
+ u32 rfr_ctrl;
+ u32 mr;
+};
+
void prcm_init(void);
void per_clocks_enable(void);
void ehci_clocks_enable(void);
@@ -39,8 +48,7 @@ void
Re: [U-Boot] [PATCH v4 07/13] davinci: Use correct #ifdef around gdata/bdata
Hi Sughosh, On Thu, Feb 23, 2012 at 9:25 AM, Sughosh Ganu urwithsugh...@gmail.com wrote: hi Simon, On Mon Feb 20, 2012 at 05:32:49PM -0800, Simon Glass wrote: This fixes the following warnings in an SPL build when libcommon is in use: spl.c:37: warning: 'gdata' defined but not used spl.c:38: warning: 'bdata' defined but not used Signed-off-by: Simon Glass s...@chromium.org --- Changes in v4: - Add new patch to fix davinci build warnings arch/arm/cpu/arm926ejs/davinci/spl.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/cpu/arm926ejs/davinci/spl.c b/arch/arm/cpu/arm926ejs/davinci/spl.c index b1eff26..2861907 100644 --- a/arch/arm/cpu/arm926ejs/davinci/spl.c +++ b/arch/arm/cpu/arm926ejs/davinci/spl.c @@ -32,10 +32,12 @@ #ifdef CONFIG_SPL_LIBCOMMON_SUPPORT +#ifdef CONFIG_SPL_SPI_LOAD DECLARE_GLOBAL_DATA_PTR; /* Define global data structure pointer to it*/ static gd_t gdata __attribute__ ((section(.data))); static bd_t bdata __attribute__ ((section(.data))); +#endif Can you specify which boards you get this warning for. With your patch to add libcommon to hawkboard's spl image, this is now also needed for hawkboard which uses CONFIG_SPL_NAND_LOAD. Perhaps it is any davinci board, with SPI? I don't have any of these - I was just fixing what I thought was a minor #ifdef bug in the code. Regards, Simon -sughosh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 09/13] hawkboard: Modify to work with generic relocation
Hi, On Thu, Feb 23, 2012 at 7:11 AM, Sughosh Ganu urwithsugh...@gmail.com wrote: On Thu, Feb 23, 2012 at 2:13 PM, Sughosh Ganu urwithsugh...@gmail.com wrote: hi Simon, On Mon Feb 20, 2012 at 05:32:51PM -0800, Simon Glass wrote: Add use of common/ and lib/ libraries for the SPL stage, and add the new link symbol required for generic relocation. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v4: - Split out hawkboard changes into new patch board/davinci/da8xxevm/u-boot-spl-hawk.lds | 1 + include/configs/hawkboard.h | 2 ++ 2 files changed, 3 insertions(+), 0 deletions(-) snip Btw, i had quite a substantial increase in the spl image size with these additions with a 4.5 based toolchain(will provide exact toolchain details and size difference tonight). Building with a 4.6 based toolchain got the size increase down by quite a bit. Although i don't have any size restrictions with spl on my board, this could be a problem on boards which have these restrictions with toolchains before 4.6. gcc(arm-none-linux-gnueabi) -- 4.5.2 binutils -- 2.20 spl size without this patch text data bss dec hex filename 5208 620 464 6292 1894 spl/u-boot-spl spl size with this patch text data bss dec hex filename 8897 620 476 9993 2709 spl/u-boot-spl gcc(arm-none-eabi) -- 4.6.2 binutils -- 2.21 spl size without this patch text data bss dec hex filename 4692 620 464 5776 1690 spl/u-boot-spl spl size with this patch text data bss dec hex filename 4812 620 476 5908 1714 spl/u-boot-spl -sughosh Thanks for looking at this. I'm not sure why it doesn't happen with your 4.6.2 compiler. With my 4.6.0 I do see the size increase. It seems to be due to vsprintf: textdata bss dec hex filename 4011 0 224033 fc1 spl/lib/vsprintf.o I wonder if it is a call to printf that the older compiler is failing to optimize out? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] sandbox: tweak style in linker script
We use tabs for indentation, not spaces.
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
arch/sandbox/cpu/u-boot.lds | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/sandbox/cpu/u-boot.lds b/arch/sandbox/cpu/u-boot.lds
index 2d2e50f..0c56aa7 100644
--- a/arch/sandbox/cpu/u-boot.lds
+++ b/arch/sandbox/cpu/u-boot.lds
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2011 The Chromium OS Authors.
+ * Copyright (c) 2011-2012 The Chromium OS Authors.
* Use of this source code is governed by a BSD-style license that can be
* found in the LICENSE file.
*
@@ -24,11 +24,11 @@
SECTIONS
{
- __u_boot_cmd_start = .;
- .u_boot_cmd : { *(.u_boot_cmd) }
- __u_boot_cmd_end = .;
- __bss_start = .;
+ __u_boot_cmd_start = .;
+ _u_boot_cmd : { *(.u_boot_cmd) }
+ __u_boot_cmd_end = .;
+ __bss_start = .;
}
INSERT BEFORE .data;
--
1.7.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/14] Nokia RX-51 support
On Tuesday 24 January 2012 15:27:57 Pali Rohár wrote: This patch series add support for new board Nokia RX-51 (aka N900). Last two patches adding on screen bootmenu support. This series supersedes the last sent version. Hi, what is state of this patch series? From our discussion is only problematic bootmenu part, but other could be OK. So what is needed for including this patches (without bootmenu support) to uboot master? -- Pali Rohár pali.ro...@gmail.com 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
[U-Boot] [PATCH] sandbox: disable fortification
Since we provide all our own library calls, the fortification from glibc just gets in our way (which some distros enable by default). Signed-off-by: Mike Frysinger vap...@gentoo.org --- arch/sandbox/config.mk |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/sandbox/config.mk b/arch/sandbox/config.mk index 2ec1bb7..02ce4a4 100644 --- a/arch/sandbox/config.mk +++ b/arch/sandbox/config.mk @@ -17,5 +17,5 @@ # Foundation, Inc., 59 Temple Place, Suite 330, Boston, # MA 02111-1307 USA -PLATFORM_CPPFLAGS += -DCONFIG_SANDBOX -D__SANDBOX__ +PLATFORM_CPPFLAGS += -DCONFIG_SANDBOX -D__SANDBOX__ -U_FORTIFY_SOURCE PLATFORM_LIBS += -lrt -- 1.7.8.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 8/8] sandbox: Add basic command line parsing
On Wednesday 15 February 2012 18:51:18 Simon Glass wrote:
--- a/arch/sandbox/cpu/os.c
+++ b/arch/sandbox/cpu/os.c
+#include stdio.h
+void os_usage(int err)
+{
+ if (err 0)
+ fprintf(stderr, Try `--help' for more information.\n);
+ fprintf(err 0 ? stderr : stdout, u-boot,
+ a command line test interface to U-Boot\n\n
+ usage:\tu-boot [-ch]\n
+ Options:\n
+ \t-h\tDisplay help\n
+ \t-c command\tExecute U-Boot command\n);
this actually doesn't work. we're using the stdio from u-boot itself, so we
can't use stdio.h from glibc. if it works for you, i'm pretty sure it's
purely an accident (perhaps related to the fortification change i just posted).
-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] [i2c] Pull request
Dear Heiko Schocher, In message 4f433dad.6050...@denx.de you wrote: Hello Wolfgang, The following changes since commit 2acca35ce4604dcef933f07d90aa9c9c930e1049: Merge branch 'master' of git://git.denx.de/u-boot-mmc (2012-02-17 23:54:46 +0100) are available in the git repository at: git://git.denx.de/u-boot-i2c.git master Tom Rini (2): Revert ARM: AM33XX: Add AM33XX I2C driver support Revert ARM: I2C: I2C Multi byte address support drivers/i2c/omap24xx_i2c.c | 475 drivers/i2c/omap24xx_i2c.h |2 - 2 files changed, 174 insertions(+), 303 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de You can fool some of the people all of the time, and You can fool all of the people some of the time, but You can't fool mom. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request - microblaze
Dear Michal Simek, In message 4f46224c.8010...@monstr.eu you wrote: Dear Wolfgang, please pull the following changes. Especially the first patch is important because it fixes build error. Thanks, Michal The following changes since commit 2acca35ce4604dcef933f07d90aa9c9c930e1049: Wolfgang Denk (1): Merge branch 'master' of git://git.denx.de/u-boot-mmc are available in the git repository at: git://www.denx.de/git/u-boot-microblaze.git master Stephan Linz (3): microblaze: fix build failure due to undefined reference to `get_ticks' microblaze: avoid interrupt race conditions microblaze: Enable TFTP put command arch/microblaze/cpu/interrupts.c |4 ++-- arch/microblaze/cpu/timer.c | 18 ++ include/configs/microblaze-generic.h |1 + 3 files changed, 21 insertions(+), 2 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de ...all the good computer designs are bootlegged; the formally planned products, if they are built at all, are dogs! - David E. Lundstrom, A Few Good Men From Univac, MIT Press, 1987 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mx6q: mx6qsabrelite: setup_spi() should be called in board_init to allow use for environment
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com --- board/freescale/mx6qsabrelite/mx6qsabrelite.c |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/board/freescale/mx6qsabrelite/mx6qsabrelite.c b/board/freescale/mx6qsabrelite/mx6qsabrelite.c index db1bea9..7fe2dc9 100644 --- a/board/freescale/mx6qsabrelite/mx6qsabrelite.c +++ b/board/freescale/mx6qsabrelite/mx6qsabrelite.c @@ -259,10 +259,6 @@ int board_eth_init(bd_t *bis) if (ret) printf(FEC MXC: %s:failed\n, __func__); -#ifdef CONFIG_MXC_SPI - setup_spi(); -#endif - return 0; } @@ -278,6 +274,10 @@ int board_init(void) /* address of boot parameters */ gd-bd-bi_boot_params = PHYS_SDRAM + 0x100; +#ifdef CONFIG_MXC_SPI + setup_spi(); +#endif + return 0; } -- 1.7.9 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/14] Nokia RX-51 support
On Tuesday 24 January 2012 15:27:57 Pali Rohár wrote: This patch series add support for new board Nokia RX-51 (aka N900). Last two patches adding on screen bootmenu support. This series supersedes the last sent version. Hi, what is state of this patch series? From our discussion is only problematic bootmenu part, but other could be OK. So what is needed for including this patches (without bootmenu support) to uboot master? You should probably split the patches into smaller series and resubmit individually. M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/7] Set of various i.MX28 patches
These patches fix random issues on the i.MX28 series. Marek Vasut (4): M28: Fix LCD PINMUX M28: Support for the old M28 SoM v1.0 i.MX28: Reformat the DRAM memory configuration data i.MX28: Enable additional DRAM address bits Robert Delien (3): Renamed mx28_register to mx28_register_32 to prepare for mx28_register_8 Introducing 8-bit wide register, mx28_register_8 Fix erroneous 32-bit access to hw_clkctrl_frac0 and hw_clkctrl_frac1 registers arch/arm/cpu/arm926ejs/mx28/clock.c | 74 +++- arch/arm/cpu/arm926ejs/mx28/iomux.c |6 +- arch/arm/cpu/arm926ejs/mx28/mx28.c|6 +- arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c| 112 ++- arch/arm/include/asm/arch-mx28/regs-apbh.h| 254 arch/arm/include/asm/arch-mx28/regs-bch.h | 42 ++-- arch/arm/include/asm/arch-mx28/regs-clkctrl.h | 98 -- arch/arm/include/asm/arch-mx28/regs-common.h | 28 ++- arch/arm/include/asm/arch-mx28/regs-gpmi.h| 26 ++-- arch/arm/include/asm/arch-mx28/regs-i2c.h | 28 ++-- arch/arm/include/asm/arch-mx28/regs-ocotp.h | 86 arch/arm/include/asm/arch-mx28/regs-pinctrl.h | 168 arch/arm/include/asm/arch-mx28/regs-power.h | 28 ++-- arch/arm/include/asm/arch-mx28/regs-rtc.h | 28 ++-- arch/arm/include/asm/arch-mx28/regs-ssp.h | 40 ++-- arch/arm/include/asm/arch-mx28/regs-timrot.h | 38 ++-- arch/arm/include/asm/arch-mx28/regs-usbphy.h | 20 +- arch/arm/include/asm/arch-mx28/sys_proto.h| 10 +- board/denx/m28evk/spl_boot.c | 16 +- drivers/gpio/mxs_gpio.c | 16 +- drivers/usb/host/ehci-mxs.c |8 +- 21 files changed, 562 insertions(+), 570 deletions(-) -- 1.7.9 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/7] M28: Support for the old M28 SoM v1.0
This prototype version SoM is unused and not available to public.
Support this only for internal debugging purposes.
Signed-off-by: Marek Vasut ma...@denx.de
---
board/denx/m28evk/spl_boot.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/board/denx/m28evk/spl_boot.c b/board/denx/m28evk/spl_boot.c
index 91316a7..a04fe18 100644
--- a/board/denx/m28evk/spl_boot.c
+++ b/board/denx/m28evk/spl_boot.c
@@ -72,8 +72,13 @@ const iomux_cfg_t iomux_setup[] = {
MX28_PAD_LCD_ENABLE__LCD_ENABLE | MUX_CONFIG_LCD,
/* UART1 */
+#ifdef CONFIG_DENX_M28_V10
+ MX28_PAD_AUART0_CTS__DUART_RX,
+ MX28_PAD_AUART0_RTS__DUART_TX,
+#else
MX28_PAD_PWM0__DUART_RX,
MX28_PAD_PWM1__DUART_TX,
+#endif
MX28_PAD_AUART0_TX__DUART_RTS,
MX28_PAD_AUART0_RX__DUART_CTS,
--
1.7.9
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/7] Renamed mx28_register to mx28_register_32 to prepare for mx28_register_8
From: Robert Delien rob...@delien.nl
This patch renames mx28_register to mx28_register_32 in order to
prepare for the introduction of an 8-bit register, mx28_register_8.
Signed-off-by: Robert Delien rob...@delien.nl
Acked-by: Marek Vasut ma...@denx.de
Tested-by: Marek Vasut ma...@denx.de
---
arch/arm/cpu/arm926ejs/mx28/clock.c |4 +-
arch/arm/cpu/arm926ejs/mx28/iomux.c |6 +-
arch/arm/cpu/arm926ejs/mx28/mx28.c|6 +-
arch/arm/include/asm/arch-mx28/regs-apbh.h| 254
arch/arm/include/asm/arch-mx28/regs-bch.h | 42 ++--
arch/arm/include/asm/arch-mx28/regs-clkctrl.h | 58 +++---
arch/arm/include/asm/arch-mx28/regs-common.h | 12 +-
arch/arm/include/asm/arch-mx28/regs-gpmi.h| 26 ++--
arch/arm/include/asm/arch-mx28/regs-i2c.h | 28 ++--
arch/arm/include/asm/arch-mx28/regs-ocotp.h | 86
arch/arm/include/asm/arch-mx28/regs-pinctrl.h | 168
arch/arm/include/asm/arch-mx28/regs-power.h | 28 ++--
arch/arm/include/asm/arch-mx28/regs-rtc.h | 28 ++--
arch/arm/include/asm/arch-mx28/regs-ssp.h | 40 ++--
arch/arm/include/asm/arch-mx28/regs-timrot.h | 38 ++--
arch/arm/include/asm/arch-mx28/regs-usbphy.h | 20 +-
arch/arm/include/asm/arch-mx28/sys_proto.h| 10 +-
drivers/gpio/mxs_gpio.c | 16 +-
drivers/usb/host/ehci-mxs.c |8 +-
19 files changed, 441 insertions(+), 437 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mx28/clock.c
b/arch/arm/cpu/arm926ejs/mx28/clock.c
index f698506..9d3a018 100644
--- a/arch/arm/cpu/arm926ejs/mx28/clock.c
+++ b/arch/arm/cpu/arm926ejs/mx28/clock.c
@@ -223,7 +223,7 @@ void mx28_set_sspclk(enum mxs_sspclock ssp, uint32_t freq,
int xtal)
return;
clkreg = (uint32_t)(clkctrl_regs-hw_clkctrl_ssp0) +
- (ssp * sizeof(struct mx28_register));
+ (ssp * sizeof(struct mx28_register_32));
clrbits_le32(clkreg, CLKCTRL_SSP_CLKGATE);
while (readl(clkreg) CLKCTRL_SSP_CLKGATE)
@@ -272,7 +272,7 @@ static uint32_t mx28_get_sspclk(enum mxs_sspclock ssp)
return XTAL_FREQ_KHZ;
clkreg = (uint32_t)(clkctrl_regs-hw_clkctrl_ssp0) +
- (ssp * sizeof(struct mx28_register));
+ (ssp * sizeof(struct mx28_register_32));
tmp = readl(clkreg) CLKCTRL_SSP_DIV_MASK;
diff --git a/arch/arm/cpu/arm926ejs/mx28/iomux.c
b/arch/arm/cpu/arm926ejs/mx28/iomux.c
index 9ea411f..12916b6 100644
--- a/arch/arm/cpu/arm926ejs/mx28/iomux.c
+++ b/arch/arm/cpu/arm926ejs/mx28/iomux.c
@@ -43,7 +43,7 @@ int mxs_iomux_setup_pad(iomux_cfg_t pad)
{
u32 reg, ofs, bp, bm;
void *iomux_base = (void *)MXS_PINCTRL_BASE;
- struct mx28_register *mxs_reg;
+ struct mx28_register_32 *mxs_reg;
/* muxsel */
ofs = 0x100;
@@ -70,7 +70,7 @@ int mxs_iomux_setup_pad(iomux_cfg_t pad)
/* vol */
if (PAD_VOL_VALID(pad)) {
bp = PAD_PIN(pad) % 8 * 4 + 2;
- mxs_reg = (struct mx28_register *)(iomux_base + ofs);
+ mxs_reg = (struct mx28_register_32 *)(iomux_base + ofs);
if (PAD_VOL(pad))
writel(1 bp, mxs_reg-reg_set);
else
@@ -82,7 +82,7 @@ int mxs_iomux_setup_pad(iomux_cfg_t pad)
ofs = PULL_OFFSET;
ofs += PAD_BANK(pad) * 0x10;
bp = PAD_PIN(pad);
- mxs_reg = (struct mx28_register *)(iomux_base + ofs);
+ mxs_reg = (struct mx28_register_32 *)(iomux_base + ofs);
if (PAD_PULL(pad))
writel(1 bp, mxs_reg-reg_set);
else
diff --git a/arch/arm/cpu/arm926ejs/mx28/mx28.c
b/arch/arm/cpu/arm926ejs/mx28/mx28.c
index b235091..9bfd83b 100644
--- a/arch/arm/cpu/arm926ejs/mx28/mx28.c
+++ b/arch/arm/cpu/arm926ejs/mx28/mx28.c
@@ -63,7 +63,7 @@ void reset_cpu(ulong ignored)
;
}
-int mx28_wait_mask_set(struct mx28_register *reg, uint32_t mask, int timeout)
+int mx28_wait_mask_set(struct mx28_register_32 *reg, uint32_t mask, int
timeout)
{
while (--timeout) {
if ((readl(reg-reg) mask) == mask)
@@ -74,7 +74,7 @@ int mx28_wait_mask_set(struct mx28_register *reg, uint32_t
mask, int timeout)
return !timeout;
}
-int mx28_wait_mask_clr(struct mx28_register *reg, uint32_t mask, int timeout)
+int mx28_wait_mask_clr(struct mx28_register_32 *reg, uint32_t mask, int
timeout)
{
while (--timeout) {
if ((readl(reg-reg) mask) == 0)
@@ -85,7 +85,7 @@ int mx28_wait_mask_clr(struct mx28_register *reg, uint32_t
mask, int timeout)
return !timeout;
}
-int mx28_reset_block(struct mx28_register *reg)
+int mx28_reset_block(struct mx28_register_32 *reg)
{
/* Clear SFTRST */
writel(MX28_BLOCK_SFTRST, reg-reg_clr);
diff --git
[U-Boot] [PATCH 1/7] M28: Fix LCD PINMUX
The LCD pins configuration was wrong in U-Boot, configure pins properly.
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Wolfgang Denk w...@denx.de
Cc: Detlev Zundel d...@denx.de
Cc: Stefano Babic sba...@denx.de
Cc: Fabio Estevam feste...@gmail.com
---
board/denx/m28evk/spl_boot.c | 11 ++-
1 files changed, 2 insertions(+), 9 deletions(-)
diff --git a/board/denx/m28evk/spl_boot.c b/board/denx/m28evk/spl_boot.c
index 86d7d87..91316a7 100644
--- a/board/denx/m28evk/spl_boot.c
+++ b/board/denx/m28evk/spl_boot.c
@@ -31,7 +31,7 @@
#include asm/arch/sys_proto.h
#defineMUX_CONFIG_LED (MXS_PAD_3V3 | MXS_PAD_4MA | MXS_PAD_NOPULL)
-#defineMUX_CONFIG_LCD (MXS_PAD_3V3 | MXS_PAD_4MA)
+#defineMUX_CONFIG_LCD (MXS_PAD_3V3 | MXS_PAD_4MA | MXS_PAD_NOPULL)
#defineMUX_CONFIG_TSC (MXS_PAD_3V3 | MXS_PAD_8MA | MXS_PAD_PULLUP)
#defineMUX_CONFIG_SSP0 (MXS_PAD_3V3 | MXS_PAD_12MA | MXS_PAD_PULLUP)
#defineMUX_CONFIG_SSP2 (MXS_PAD_3V3 | MXS_PAD_4MA | MXS_PAD_PULLUP)
@@ -68,15 +68,8 @@ const iomux_cfg_t iomux_setup[] = {
MX28_PAD_LCD_D21__LCD_D21 | MUX_CONFIG_LCD,
MX28_PAD_LCD_D22__LCD_D22 | MUX_CONFIG_LCD,
MX28_PAD_LCD_D23__LCD_D23 | MUX_CONFIG_LCD,
- MX28_PAD_LCD_RD_E__LCD_VSYNC | MUX_CONFIG_LCD,
- MX28_PAD_LCD_WR_RWN__LCD_HSYNC | MUX_CONFIG_LCD,
- MX28_PAD_LCD_RS__LCD_DOTCLK | MUX_CONFIG_LCD,
- MX28_PAD_LCD_CS__LCD_CS | MUX_CONFIG_LCD,
- MX28_PAD_LCD_VSYNC__LCD_VSYNC | MUX_CONFIG_LCD,
- MX28_PAD_LCD_HSYNC__LCD_HSYNC | MUX_CONFIG_LCD,
MX28_PAD_LCD_DOTCLK__LCD_DOTCLK | MUX_CONFIG_LCD,
- MX28_PAD_LCD_ENABLE__GPIO_1_31 | MUX_CONFIG_LCD,
- MX28_PAD_LCD_RESET__GPIO_3_30 | MUX_CONFIG_LCD,
+ MX28_PAD_LCD_ENABLE__LCD_ENABLE | MUX_CONFIG_LCD,
/* UART1 */
MX28_PAD_PWM0__DUART_RX,
--
1.7.9
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/7] i.MX28: Enable additional DRAM address bits
Signed-off-by: Marek Vasut ma...@denx.de
---
arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
b/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
index 4af9eb7..fd18f70 100644
--- a/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
+++ b/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
@@ -39,7 +39,7 @@ uint32_t dram_vals[] = {
0x, 0x0100, 0x, 0x,
0x, 0x, 0x, 0x,
0x, 0x, 0x00010101, 0x01010101,
- 0x000f0f01, 0x0f02020a, 0x, 0x00010101,
+ 0x000f0f01, 0x0f02010a, 0x, 0x00010101,
0x0100, 0x0100, 0x, 0x0002,
0x0101, 0x05060302, 0x06005003, 0x0ac8,
0x02009c40, 0x030c, 0x0036a609, 0x031a0612,
--
1.7.9
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/7] Introducing 8-bit wide register, mx28_register_8
From: Robert Delien rob...@delien.nl
This patch introduces an 8-bit register, mx28_register_8, in order to
prepare for fixing erroneous 32-bit wide access of registers
hw_clkctrl_frac0 and hw_clkctrl_frac1.
Signed-off-by: Robert Delien rob...@delien.nl
Acked-by: Marek Vasut ma...@denx.de
Tested-by: Marek Vasut ma...@denx.de
---
arch/arm/include/asm/arch-mx28/regs-common.h | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/arch-mx28/regs-common.h
b/arch/arm/include/asm/arch-mx28/regs-common.h
index 75cc9a6..94b512d 100644
--- a/arch/arm/include/asm/arch-mx28/regs-common.h
+++ b/arch/arm/include/asm/arch-mx28/regs-common.h
@@ -47,16 +47,32 @@
*
*/
+#define__mx28_reg_8(name) \
+ uint8_t name[4];\
+ uint8_t name##_set[4]; \
+ uint8_t name##_clr[4]; \
+ uint8_t name##_tog[4]; \
+
#define__mx28_reg_32(name) \
uint32_t name; \
uint32_t name##_set;\
uint32_t name##_clr;\
uint32_t name##_tog;
+struct mx28_register_8 {
+ __mx28_reg_8(reg)
+};
+
struct mx28_register_32 {
__mx28_reg_32(reg)
};
+#definemx28_reg_8(name)\
+ union { \
+ struct { __mx28_reg_8(name) }; \
+ struct mx28_register_32 name##_reg; \
+ };
+
#definemx28_reg_32(name) \
union { \
struct { __mx28_reg_32(name) }; \
--
1.7.9
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 7/7] Fix erroneous 32-bit access to hw_clkctrl_frac0 and hw_clkctrl_frac1 registers
From: Robert Delien rob...@delien.nl
This patch fixes erroneous 32-bit access to registers
hw_clkctrl_frac0 and hw_clkctrl_frac1.
Signed-off-by: Robert Delien rob...@delien.nl
Acked-by: Marek Vasut ma...@denx.de
Tested-by: Marek Vasut ma...@denx.de
---
arch/arm/cpu/arm926ejs/mx28/clock.c | 70 ++---
arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c| 26 -
arch/arm/include/asm/arch-mx28/regs-clkctrl.h | 44 +---
3 files changed, 52 insertions(+), 88 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mx28/clock.c
b/arch/arm/cpu/arm926ejs/mx28/clock.c
index 9d3a018..0439f9c 100644
--- a/arch/arm/cpu/arm926ejs/mx28/clock.c
+++ b/arch/arm/cpu/arm926ejs/mx28/clock.c
@@ -46,8 +46,8 @@ static uint32_t mx28_get_pclk(void)
struct mx28_clkctrl_regs *clkctrl_regs =
(struct mx28_clkctrl_regs *)MXS_CLKCTRL_BASE;
- uint32_t clkctrl, clkseq, clkfrac;
- uint32_t frac, div;
+ uint32_t clkctrl, clkseq, div;
+ uint8_t clkfrac, frac;
clkctrl = readl(clkctrl_regs-hw_clkctrl_cpu);
@@ -67,8 +67,8 @@ static uint32_t mx28_get_pclk(void)
}
/* REF Path */
- clkfrac = readl(clkctrl_regs-hw_clkctrl_frac0);
- frac = clkfrac CLKCTRL_FRAC0_CPUFRAC_MASK;
+ clkfrac = readb(clkctrl_regs-hw_clkctrl_frac0[CLKCTRL_FRAC0_CPU]);
+ frac = clkfrac CLKCTRL_FRAC_FRAC_MASK;
div = clkctrl CLKCTRL_CPU_DIV_CPU_MASK;
return (PLL_FREQ_MHZ * PLL_FREQ_COEF / frac) / div;
}
@@ -96,8 +96,8 @@ static uint32_t mx28_get_emiclk(void)
struct mx28_clkctrl_regs *clkctrl_regs =
(struct mx28_clkctrl_regs *)MXS_CLKCTRL_BASE;
- uint32_t frac, div;
- uint32_t clkctrl, clkseq, clkfrac;
+ uint32_t clkctrl, clkseq, div;
+ uint8_t clkfrac, frac;
clkseq = readl(clkctrl_regs-hw_clkctrl_clkseq);
clkctrl = readl(clkctrl_regs-hw_clkctrl_emi);
@@ -109,11 +109,9 @@ static uint32_t mx28_get_emiclk(void)
return XTAL_FREQ_MHZ / div;
}
- clkfrac = readl(clkctrl_regs-hw_clkctrl_frac0);
-
/* REF Path */
- frac = (clkfrac CLKCTRL_FRAC0_EMIFRAC_MASK)
- CLKCTRL_FRAC0_EMIFRAC_OFFSET;
+ clkfrac = readb(clkctrl_regs-hw_clkctrl_frac0[CLKCTRL_FRAC0_EMI]);
+ frac = clkfrac CLKCTRL_FRAC_FRAC_MASK;
div = clkctrl CLKCTRL_EMI_DIV_EMI_MASK;
return (PLL_FREQ_MHZ * PLL_FREQ_COEF / frac) / div;
}
@@ -123,8 +121,8 @@ static uint32_t mx28_get_gpmiclk(void)
struct mx28_clkctrl_regs *clkctrl_regs =
(struct mx28_clkctrl_regs *)MXS_CLKCTRL_BASE;
- uint32_t frac, div;
- uint32_t clkctrl, clkseq, clkfrac;
+ uint32_t clkctrl, clkseq, div;
+ uint8_t clkfrac, frac;
clkseq = readl(clkctrl_regs-hw_clkctrl_clkseq);
clkctrl = readl(clkctrl_regs-hw_clkctrl_gpmi);
@@ -135,11 +133,9 @@ static uint32_t mx28_get_gpmiclk(void)
return XTAL_FREQ_MHZ / div;
}
- clkfrac = readl(clkctrl_regs-hw_clkctrl_frac1);
-
/* REF Path */
- frac = (clkfrac CLKCTRL_FRAC1_GPMIFRAC_MASK)
- CLKCTRL_FRAC1_GPMIFRAC_OFFSET;
+ clkfrac = readb(clkctrl_regs-hw_clkctrl_frac1[CLKCTRL_FRAC1_GPMI]);
+ frac = clkfrac CLKCTRL_FRAC_FRAC_MASK;
div = clkctrl CLKCTRL_GPMI_DIV_MASK;
return (PLL_FREQ_MHZ * PLL_FREQ_COEF / frac) / div;
}
@@ -152,11 +148,12 @@ void mx28_set_ioclk(enum mxs_ioclock io, uint32_t freq)
struct mx28_clkctrl_regs *clkctrl_regs =
(struct mx28_clkctrl_regs *)MXS_CLKCTRL_BASE;
uint32_t div;
+ int io_reg;
if (freq == 0)
return;
- if (io MXC_IOCLK1)
+ if ((io MXC_IOCLK0) || (io MXC_IOCLK1))
return;
div = (PLL_FREQ_KHZ * PLL_FREQ_COEF) / freq;
@@ -167,23 +164,13 @@ void mx28_set_ioclk(enum mxs_ioclock io, uint32_t freq)
if (div 35)
div = 35;
- if (io == MXC_IOCLK0) {
- writel(CLKCTRL_FRAC0_CLKGATEIO0,
- clkctrl_regs-hw_clkctrl_frac0_set);
- clrsetbits_le32(clkctrl_regs-hw_clkctrl_frac0,
- CLKCTRL_FRAC0_IO0FRAC_MASK,
- div CLKCTRL_FRAC0_IO0FRAC_OFFSET);
- writel(CLKCTRL_FRAC0_CLKGATEIO0,
- clkctrl_regs-hw_clkctrl_frac0_clr);
- } else {
- writel(CLKCTRL_FRAC0_CLKGATEIO1,
- clkctrl_regs-hw_clkctrl_frac0_set);
- clrsetbits_le32(clkctrl_regs-hw_clkctrl_frac0,
- CLKCTRL_FRAC0_IO1FRAC_MASK,
- div CLKCTRL_FRAC0_IO1FRAC_OFFSET);
- writel(CLKCTRL_FRAC0_CLKGATEIO1,
- clkctrl_regs-hw_clkctrl_frac0_clr);
- }
+ io_reg = CLKCTRL_FRAC0_IO0 - io;/* Register order is reversed */
+ writeb(CLKCTRL_FRAC_CLKGATE,
+
[U-Boot] [PATCH 3/7] i.MX28: Reformat the DRAM memory configuration data
Reformat the data so it's easier to navigate through them.
Signed-off-by: Marek Vasut ma...@denx.de
---
arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c | 86 +++
1 files changed, 48 insertions(+), 38 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
b/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
index db67011..4af9eb7 100644
--- a/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
+++ b/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
@@ -32,44 +32,54 @@
#include mx28_init.h
uint32_t dram_vals[] = {
- 0x, 0x, 0x, 0x, 0x,
- 0x, 0x, 0x, 0x, 0x,
- 0x, 0x, 0x, 0x, 0x,
- 0x, 0x, 0x0100, 0x, 0x,
- 0x, 0x, 0x, 0x, 0x,
- 0x, 0x00010101, 0x01010101, 0x000f0f01, 0x0f02020a,
- 0x, 0x00010101, 0x0100, 0x0100, 0x,
- 0x0002, 0x0101, 0x05060302, 0x06005003, 0x0ac8,
- 0x02009c40, 0x030c, 0x0036a609, 0x031a0612, 0x02030202,
- 0x00c8001c, 0x, 0x, 0x00012100, 0x0303,
- 0x00012100, 0x0303, 0x00012100, 0x0303, 0x00012100,
- 0x0303, 0x0003, 0x, 0x, 0x,
- 0x, 0x, 0x, 0x, 0x,
- 0x, 0x0612, 0x01000F02, 0x06120612, 0x0200,
- 0x00020007, 0xf5014b27, 0xf5014b27, 0xf5014b27, 0xf5014b27,
- 0x07000300, 0x07000300, 0x07000300, 0x07000300, 0x0006,
- 0x, 0x, 0x0100, 0x01020408, 0x08040201,
- 0x000f1133, 0x, 0x1f04, 0x1f04, 0x1f04,
- 0x1f04, 0x1f04, 0x1f04, 0x1f04, 0x1f04,
- 0x, 0x, 0x, 0x, 0x,
- 0x, 0x, 0x, 0x, 0x,
- 0x, 0x, 0x, 0x, 0x,
- 0x, 0x, 0x, 0x, 0x,
- 0x, 0x, 0x, 0x, 0x,
- 0x, 0x, 0x, 0x, 0x,
- 0x, 0x, 0x, 0x, 0x,
- 0x, 0x, 0x, 0x, 0x,
- 0x, 0x, 0x, 0x, 0x,
- 0x, 0x, 0x, 0x, 0x,
- 0x, 0x, 0x, 0x, 0x,
- 0x, 0x, 0x, 0x, 0x,
- 0x, 0x, 0x, 0x, 0x,
- 0x, 0x, 0x0001, 0x00020304, 0x0004,
- 0x, 0x, 0x, 0x, 0x,
- 0x, 0x0101, 0x0100, 0x0303, 0x00010303,
- 0x01020202, 0x, 0x02040303, 0x21002103, 0x00061200,
- 0x06120612, 0x04320432, 0x04320432, 0x00040004, 0x00040004,
- 0x, 0x, 0x, 0x, 0x00010001
+ 0x, 0x, 0x, 0x,
+ 0x, 0x, 0x, 0x,
+ 0x, 0x, 0x, 0x,
+ 0x, 0x, 0x, 0x,
+ 0x, 0x0100, 0x, 0x,
+ 0x, 0x, 0x, 0x,
+ 0x, 0x, 0x00010101, 0x01010101,
+ 0x000f0f01, 0x0f02020a, 0x, 0x00010101,
+ 0x0100, 0x0100, 0x, 0x0002,
+ 0x0101, 0x05060302, 0x06005003, 0x0ac8,
+ 0x02009c40, 0x030c, 0x0036a609, 0x031a0612,
+ 0x02030202, 0x00c8001c, 0x, 0x,
+ 0x00012100, 0x0303, 0x00012100, 0x0303,
+ 0x00012100, 0x0303, 0x00012100, 0x0303,
+ 0x0003, 0x, 0x, 0x,
+ 0x, 0x, 0x, 0x,
+ 0x, 0x, 0x0612, 0x01000F02,
+ 0x06120612, 0x0200, 0x00020007, 0xf5014b27,
+ 0xf5014b27, 0xf5014b27, 0xf5014b27, 0x07000300,
+ 0x07000300, 0x07000300, 0x07000300, 0x0006,
+ 0x, 0x, 0x0100, 0x01020408,
+ 0x08040201, 0x000f1133, 0x, 0x1f04,
+ 0x1f04, 0x1f04, 0x1f04, 0x1f04,
+ 0x1f04, 0x1f04, 0x1f04, 0x,
+ 0x, 0x, 0x, 0x,
+ 0x, 0x, 0x, 0x,
+ 0x, 0x, 0x, 0x,
+ 0x, 0x, 0x, 0x,
+ 0x, 0x, 0x, 0x,
+ 0x, 0x, 0x, 0x,
+ 0x, 0x, 0x, 0x,
+ 0x, 0x, 0x, 0x,
+ 0x, 0x, 0x, 0x,
+ 0x,
[U-Boot] [PATCH 1/3] sandbox: add concept of sandbox state
From: Simon Glass s...@chromium.org
The state exists through the life of U-Boot. It can be adjusted by command
line options and perhaps later through a config file. It is available to
U-Boot through state_...() calls (within sandbox code).
The primary purpose of this is to contain the hardware state. It should
only be used by sandbox internal code.
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
arch/sandbox/cpu/Makefile|2 +-
arch/sandbox/cpu/start.c |9 +-
arch/sandbox/cpu/state.c | 51 ++
arch/sandbox/include/asm/state.h | 57 ++
4 files changed, 117 insertions(+), 2 deletions(-)
create mode 100644 arch/sandbox/cpu/state.c
create mode 100644 arch/sandbox/include/asm/state.h
diff --git a/arch/sandbox/cpu/Makefile b/arch/sandbox/cpu/Makefile
index 2ae0f71..6fd09ff 100644
--- a/arch/sandbox/cpu/Makefile
+++ b/arch/sandbox/cpu/Makefile
@@ -27,7 +27,7 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(CPU).o
-COBJS := cpu.o start.o os.o
+COBJS := cpu.o os.o start.o state.o
SRCS := $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS))
diff --git a/arch/sandbox/cpu/start.c b/arch/sandbox/cpu/start.c
index a429e29..2b66eed 100644
--- a/arch/sandbox/cpu/start.c
+++ b/arch/sandbox/cpu/start.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2011 The Chromium OS Authors.
+ * Copyright (c) 2011-2012 The Chromium OS Authors.
* See file CREDITS for list of people who contributed to this
* project.
*
@@ -20,9 +20,16 @@
*/
#include common.h
+#include asm/state.h
int main(int argc, char *argv[])
{
+ int err;
+
+ err = state_init();
+ if (err)
+ return err;
+
/*
* Do pre- and post-relocation init, then start up U-Boot. This will
* never return.
diff --git a/arch/sandbox/cpu/state.c b/arch/sandbox/cpu/state.c
new file mode 100644
index 000..88ae2b0
--- /dev/null
+++ b/arch/sandbox/cpu/state.c
@@ -0,0 +1,51 @@
+/*
+ * Copyright (c) 2011-2012 The Chromium OS Authors.
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include common.h
+#include asm/state.h
+
+/* Main state record for the sandbox */
+static struct sandbox_state main_state;
+static struct sandbox_state *state;/* Pointer to current state record */
+
+void state_record_exit(enum exit_type_id exit_type)
+{
+ state-exit_type = exit_type;
+}
+
+struct sandbox_state *state_get_current(void)
+{
+ assert(state);
+ return state;
+}
+
+int state_init(void)
+{
+ state = main_state;
+
+ /*
+* Example of how to use GPIOs:
+*
+* sandbox_gpio_set_direction(170, 0);
+* sandbox_gpio_set_value(170, 0);
+*/
+ return 0;
+}
diff --git a/arch/sandbox/include/asm/state.h b/arch/sandbox/include/asm/state.h
new file mode 100644
index 000..5b34e94
--- /dev/null
+++ b/arch/sandbox/include/asm/state.h
@@ -0,0 +1,57 @@
+/*
+ * Copyright (c) 2011-2012 The Chromium OS Authors.
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#ifndef __SANDBOX_STATE_H
+#define __SANDBOX_STATE_H
+
+/* How we exited U-Boot */
+enum exit_type_id {
+ STATE_EXIT_NORMAL,
+ STATE_EXIT_COLD_REBOOT,
+ STATE_EXIT_POWER_OFF,
+};
+
+/* The complete state of the test system */
+struct sandbox_state {
+ const char *cmd;/* Command to execute */
+
[U-Boot] [PATCH 2/3] sandbox: allow processing before main loop
From: Simon Glass s...@chromium.org
In order to pass command line arguments to sandbox we need to be able
to act on them. So take control back at the end of board_init_r() from
where we can call the main loop or do something else.
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
arch/sandbox/cpu/start.c |5 +
arch/sandbox/include/asm/u-boot-sandbox.h |3 +++
arch/sandbox/lib/board.c |2 ++
3 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/sandbox/cpu/start.c b/arch/sandbox/cpu/start.c
index 2b66eed..dc020ee 100644
--- a/arch/sandbox/cpu/start.c
+++ b/arch/sandbox/cpu/start.c
@@ -22,6 +22,11 @@
#include common.h
#include asm/state.h
+int sb_main_loop_init(void)
+{
+ return 0;
+}
+
int main(int argc, char *argv[])
{
int err;
diff --git a/arch/sandbox/include/asm/u-boot-sandbox.h
b/arch/sandbox/include/asm/u-boot-sandbox.h
index 236b4ee..f0e8b3c 100644
--- a/arch/sandbox/include/asm/u-boot-sandbox.h
+++ b/arch/sandbox/include/asm/u-boot-sandbox.h
@@ -35,4 +35,7 @@
int board_init(void);
int dram_init(void);
+/* start.c */
+int sb_main_loop_init(void);
+
#endif /* _U_BOOT_SANDBOX_H_ */
diff --git a/arch/sandbox/lib/board.c b/arch/sandbox/lib/board.c
index 6d464d6..1082e7d 100644
--- a/arch/sandbox/lib/board.c
+++ b/arch/sandbox/lib/board.c
@@ -269,6 +269,8 @@ void board_init_r(gd_t *id, ulong dest_addr)
post_run(NULL, POST_RAM | post_bootmode_get(0));
#endif
+ sb_main_loop_init();
+
/*
* For now, run the main loop. Later we might let this be done
* in the main program.
--
1.7.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] sandbox: add getopt support
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
arch/sandbox/cpu/os.c | 64 ++
arch/sandbox/cpu/start.c | 83 +
arch/sandbox/cpu/u-boot.lds |4 ++
arch/sandbox/include/asm/state.h |5 ++
arch/sandbox/include/asm/u-boot-sandbox.h |1 +
arch/sandbox/lib/board.c |1 +
include/os.h | 35
7 files changed, 193 insertions(+), 0 deletions(-)
diff --git a/arch/sandbox/cpu/os.c b/arch/sandbox/cpu/os.c
index cb469e0..4b1c987 100644
--- a/arch/sandbox/cpu/os.c
+++ b/arch/sandbox/cpu/os.c
@@ -21,6 +21,7 @@
#include errno.h
#include fcntl.h
+#include getopt.h
#include stdlib.h
#include termios.h
#include time.h
@@ -32,6 +33,7 @@
#include linux/types.h
#include os.h
+#include asm/state.h
/* Operating System Interface */
@@ -155,3 +157,65 @@ u64 os_get_nsec(void)
return tv.tv_sec * 10ULL + tv.tv_usec * 1000;
#endif
}
+
+extern struct sb_cmdline_option *__u_boot_sb_getopt_start[],
+ *__u_boot_sb_getopt_end[];
+static char *short_opts;
+static struct option *long_opts;
+
+int os_parse_args(struct sandbox_state *state, int argc, char *argv[])
+{
+ struct sb_cmdline_option **sb_opt = __u_boot_sb_getopt_start;
+ size_t num_flags = __u_boot_sb_getopt_end - __u_boot_sb_getopt_start;
+ size_t i;
+
+ int hidden_short_opt;
+ size_t si;
+
+ int c;
+
+ if (short_opts || long_opts)
+ os_exit(1);
+
+ state-argc = argc;
+ state-argv = argv;
+
+ short_opts = os_malloc(sizeof(*short_opts) * (num_flags + 1));
+ long_opts = os_malloc(sizeof(*long_opts) * num_flags);
+ if (!short_opts || !long_opts)
+ os_exit(1);
+
+ si = 0;
+ hidden_short_opt = 0x80;
+ for (i = 0; i num_flags; ++i) {
+ long_opts[i].name = sb_opt[i]-flag;
+ long_opts[i].has_arg = sb_opt[i]-has_arg ?
+ required_argument : no_argument;
+ long_opts[i].flag = NULL;
+
+ if (sb_opt[i]-flag_short)
+ short_opts[si++] = long_opts[i].val =
sb_opt[i]-flag_short;
+ else
+ long_opts[i].val = sb_opt[i]-flag_short =
hidden_short_opt++;
+ }
+ short_opts[si] = '\0';
+
+ /* We need to handle output ourselves since u-boot provides printf */
+ opterr = 0;
+
+ while ((c = getopt_long(argc, argv, short_opts, long_opts, NULL)) !=
-1) {
+ for (i = 0; i num_flags; ++i) {
+ if (sb_opt[i]-flag_short == c) {
+ sb_opt[i]-callback(state, optarg);
+ break;
+ }
+ }
+ if (i == num_flags) {
+ /* store the faulting flag index for later */
+ state-parse_err = -optind;
+ break;
+ }
+ }
+
+ return 0;
+}
diff --git a/arch/sandbox/cpu/start.c b/arch/sandbox/cpu/start.c
index dc020ee..895ec49 100644
--- a/arch/sandbox/cpu/start.c
+++ b/arch/sandbox/cpu/start.c
@@ -22,19 +22,102 @@
#include common.h
#include asm/state.h
+#include os.h
+
+extern struct sb_cmdline_option *__u_boot_sb_getopt_start[],
+ *__u_boot_sb_getopt_end[];
+
+int sb_early_getopt_check(void)
+{
+ struct sandbox_state *state = state_get_current();
+ struct sb_cmdline_option **sb_opt = __u_boot_sb_getopt_start;
+ size_t num_flags = __u_boot_sb_getopt_end - __u_boot_sb_getopt_start;
+ size_t i;
+ int max_arg_len, max_noarg_len;
+
+ if (state-parse_err == 0)
+ return 0;
+
+ if (state-parse_err 0)
+ printf(error: unknown option: %s\n\n,
+ state-argv[-state-parse_err - 1]);
+
+ printf(
+ u-boot, a command line test interface to U-Boot\n\n
+ Usage: u-boot [options]\n
+ Options:\n);
+
+ max_arg_len = 0;
+ for (i = 0; i num_flags; ++i)
+ max_arg_len = max(strlen(sb_opt[i]-flag), max_arg_len);
+ max_noarg_len = max_arg_len + 7;
+
+ for (i = 0; i num_flags; ++i) {
+ /* first output the short flag if it has one */
+ if (sb_opt[i]-flag_short = 0x80)
+ printf( );
+ else
+ printf( -%c, , sb_opt[i]-flag_short);
+
+ /* then the long flag */
+ if (sb_opt[i]-has_arg)
+ printf(--%-*s, max_noarg_len, sb_opt[i]-flag);
+ else
+ printf(--%-*s arg , max_arg_len, sb_opt[i]-flag);
+
+ /* finally the help text */
+ printf( %s\n, sb_opt[i]-help);
+ }
+
+ os_exit(state-parse_err 0 ? 1 : 0);
+}
+
+static int
Re: [U-Boot] [PATCH v3] AVR32: fix timer_init() function
Dear Sven, Date: Sun, 4 Oct 2015 21:53:32 +0200 would you be willing to disclose the secrets of running such a time machine ? In message 1443988412-13421-1-git-send-email-sv...@stackframe.org you wrote: timer_init() now returns an int (the error code) instead of void. This makes compilation fail with: interrupts.c:111: error: conflicting types for 'timer_init' /home/svens/u-boot/u-boot/include/common.h:246: error: previous declaration of 'timer_init' was here make[1]: *** [interrupts.o] Error 1 We're just discussing to drop support for AVR32 systems due to lack of a custodian, and appearent lack of interest, see 02/25 To:u-boot@lists.d [PATCH] AVR32 removal due to lack of custodian. http://article.gmane.org/gmane.comp.boot-loaders.u-boot/125752 Are you still interestedin AVR32? Would you be willing to volunteer to take over custodianship for this processor family? Or Andreas, would you? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A good aphorism is too hard for the tooth of time, and is not worn away by all the centuries, although it serves as food for every epoch. - Friedrich Wilhelm Nietzsche _Miscellaneous Maxims and Opinions_ no. 168 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] sandbox: mark os_exit as noreturn
Signed-off-by: Mike Frysinger vap...@gentoo.org --- include/os.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/os.h b/include/os.h index aea4503..35ef9b0 100644 --- a/include/os.h +++ b/include/os.h @@ -95,7 +95,7 @@ int os_close(int fd); * * @param exit_codeexit code for U-Boot */ -void os_exit(int exit_code); +void os_exit(int exit_code) __attribute__((noreturn)); /** * Put tty into raw mode to mimic serial console better -- 1.7.8.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Deprecation (planned removal) of 'maintainer-less' code
Hi Wolfgang, I notice you've finally gotten sick of 'talking to the wall' regarding unmaintained code (net, USB, AVR32, etc.) To make life a little easier for everyone, maybe we can put together a list of U-Boot sub-components which do not have an active maintainer so we can discuss what to do about it as a whole rather than in a piecemeal fashion Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Deprecation (planned removal) of 'maintainer-less' code
Hi Wolfgang, I notice you've finally gotten sick of 'talking to the wall' regarding unmaintained code (net, USB, AVR32, etc.) To make life a little easier for everyone, maybe we can put together a list of U-Boot sub-components which do not have an active maintainer so we can discuss what to do about it as a whole rather than in a piecemeal fashion And this'll produce more talk to the wall. I'll take over the USB, so you better CC me for USB patches. We need someone for NET now ... M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/3] Enable access to FAT filesystem in an ISO9660 El-Torito volume
This series fixes several bugs in the FAT code and the USB storage stack to make it possible to read from a FAT filesystem image embedded as an El-Torito boot image in an ISO9660 volume (IE: a CD or DVD). This has been tested on the eXMeritus HWW-1U-1A I've addressed the review commentary on these patches and I believe that they should be acceptable for merging into next now. Cheers, Kyle Moffett Hi, what's the status of this patch/patchset? Thanks M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Fastboot gadget, v2
This series contains a smaller version of the fastboot gadget. I removed the flash/mmc/write to media part and re-add once I'm through with this basic thing :) This basic gadget supports the retrieval of variables (like serial number), reboot functionality, download of binary data and booting them in case the binary data is a bootable image. I did not include the fastboot client in this series. Remy asked about this. I could take it and stash it in tools if someone really wants this to have. This would include the fastboot and libzipfile folder from Andorid's system/core repository. An online version can be found at [0]. I haven't seen the library somewhere else than Android. For basic testing, the library could be excluded. v1..v2: fixed all issues that came up so far, including: - s/andoir_img_get_kload/android_img_get_kload/ spotted by Mike - adjusted Copyright message to GPLv2 or later for f_fastboot.c and removed change comments. - removed two header files in example patch 3/3 I believe that the All rights reserved problem got resolved. Hi, what's the status of this patch/patchset? Thanks M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] net: re-enumerating usb-ethernet devices hangs the system
Hi Vincent, as you already know, the re-enumerating of usb ethernet devices (calling usb start twice) hangs the system because eth_register() is called more than once. If have found a related patch from you with the subject eth: remove usb-ethernet devices before re-enumerating them in the chromium.org git repos. Could that be pushed mainline. Feel free to add my Tested-by: Wolfgang Grandegger w...@denx.de. Thanks, Wolfgang. Hi, what's the status of this patch/patchset? Thanks M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/16] tegra: Add fdt definitions and USB driver
This series brings in the kernel fdt file and provides a working USB driver for Tegra2 Seaboard. (I have done this in one series since otherwise most of the fdt additions will just look like dead code.) The driver requires CONFIG_OF_CONTROL and a device tree to operate. Some enhancements to fdtdec are required to make this easier, and these are included in the series also. I have had to bring in basic GPIO support due to the request to put the USB VBUS into the fdt. Since the kernel recently got a very minimal USB binding, I have started with that and extended it where appropriate. Tegra likes to have cache-aligned buffers. I have dropped the patch which implements this since we will solve this problem by making callers align their buffers (as we did with MMC). Changes in v2: - Use okay instead of ok for fdt node status - Remove 0x from fdt aliases - Rename params to timing - Store entire fdt config in port list, not just register pointer - Remove non-fdt operation of USB, since it is not needed - Decode USB VBUS GPIO from the fdt - Decode phy type differently (to match new kernel fdt) - Rename tegra20-usb to tegra20-ehcui (to match new kernel fdt) - Improve debug() printouts in case of failure to init USB - Add setting of pinmux for USB VBUS GPIO - Remove unneeded CONFIG_TEGRA_USBx defines Changes in v3: - Remove okay from nodes since this is the default anyway - Fix device tree indenting with tabs instead of spaces - Disable USB2 which is not used on Seaboard - Remove usbparams properties from fdt and moved them to C code - Drop Tegra USB alignment patch as we will deal with this another way Simon Glass (16): fdt: Tidy up a few fdtdec problems fdt: Add functions to access phandles, arrays and bools Add gpio_request() to asm-generic header fdt: Add basic support for decoding GPIO definitions arm: fdt: Ensure that an embedded fdt is word-aligned arm: fdt: Add skeleton device tree file from kernel tegra: fdt: Add Tegra2x device tree file from kernel tegra: fdt: Add device tree file for Tegra2 Seaboard from kernel tegra: usb: fdt: Add additional device tree definitions for USB ports tegra: usb: fdt: Add USB definitions for Tegra2 Seaboard usb: Add support for txfifo threshold tegra: usb: Add support for Tegra USB peripheral tegra: usb: Add USB support to nvidia boards tegra: usb: Add common USB defines for tegra2 boards tegra: usb: Enable USB on Seaboard tegra: fdt: Enable FDT support for Seaboard README|3 + arch/arm/cpu/armv7/tegra2/Makefile|4 +- arch/arm/cpu/armv7/tegra2/config.mk |2 + arch/arm/cpu/armv7/tegra2/usb.c | 430 + arch/arm/cpu/armv7/u-boot.lds | 5 + arch/arm/dts/skeleton.dtsi| 13 + arch/arm/dts/tegra20.dtsi | 172 arch/arm/include/asm/arch-tegra2/tegra2.h |2 + arch/arm/include/asm/arch-tegra2/usb.h| 255 + board/nvidia/common/board.c |8 + board/nvidia/dts/tegra2-seaboard.dts | 47 drivers/usb/host/Makefile |1 + drivers/usb/host/ehci-hcd.c |7 + drivers/usb/host/ehci-tegra.c | 63 + drivers/usb/host/ehci.h |6 +- dts/Makefile |2 +- include/asm-generic/gpio.h| 10 + include/configs/seaboard.h| 12 + include/configs/tegra2-common.h | 14 + include/fdtdec.h | 109 +++- lib/fdtdec.c | 168 +++- 21 files changed, 1320 insertions(+), 13 deletions(-) create mode 100644 arch/arm/cpu/armv7/tegra2/usb.c create mode 100644 arch/arm/dts/skeleton.dtsi create mode 100644 arch/arm/dts/tegra20.dtsi create mode 100644 arch/arm/include/asm/arch-tegra2/usb.h create mode 100644 board/nvidia/dts/tegra2-seaboard.dts create mode 100644 drivers/usb/host/ehci-tegra.c Hi, what's the status of this patch/patchset? Thanks M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 0/2] fdt: Deal correctly with alias nodes
This series proposes a new way to deal with alias nodes and introduces a function to take care of it. It includes an example of converting USB code over to use this new function. Note: At present it does not deal automatically with disabled nodes, but perhaps it should? Or perhaps this is better as an option. Something to leave for later perhaps. Note 2: The actual logic of this function is not properly tested yet. Simon Glass (2): fdt: Add fdtdec_find_aliases() to deal with alias nodes tegra: Use fdtdec_find_aliases() to find USB ports arch/arm/cpu/armv7/tegra2/usb.c | 17 include/fdtdec.h| 51 ++ lib/fdtdec.c| 89 +++ 3 files changed, 148 insertions(+), 9 deletions(-) Hi, what's the status of this patch/patchset? Thanks M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] eth: remove usb-ethernet devices before re-enumerating them
Fix the crash when running several times usb_init() with a USB ethernet device plugged. Signed-off-by: Vincent Palatin vpala...@chromium.org Tested-by: Wolfgang Grandegger w...@denx.de --- Hi, what's the status of this patch/patchset? Thanks M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] USB: relax usbcore reset timings
From: Wolfgang Grandegger w...@denx.de Following the corresponding Linux code, this patch relaxes reset timings waiting at least 100ms after power to the ports. There are some reports that it helps make enumeration work better on some high speed devices. Furthermore, the wait is only done once after power has been enabled on all ports. CC: Remy Bohmer li...@bohmer.net CC: Vincent Palatin vpala...@chromium.org Signed-off-by: Wolfgang Grandegger w...@denx.de --- Hi, what's the status of this patch/patchset? Thanks M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] USB: fix USB keyboard polling parameter
When doing a GET_REPORT request on the keyboard control endpoint, the report ID should 0 (ie report ID not used) rather than 1 as reports are not used in boot mode. Signed-off-by: Vincent Palatin vpala...@chromium.org --- common/usb_kbd.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/common/usb_kbd.c b/common/usb_kbd.c index 75107c9..aaf7d6f 100644 --- a/common/usb_kbd.c +++ b/common/usb_kbd.c @@ -320,7 +320,7 @@ static inline void usb_kbd_poll_for_event(struct usb_device *dev) struct usb_kbd_pdata *data = dev-privptr; iface = dev-config.if_desc[0]; usb_get_report(dev, iface-desc.bInterfaceNumber, - 1, 1, data-new, sizeof(data-new)); + 1, 0, data-new, sizeof(data-new)); if (memcmp(data-old, data-new, sizeof(data-new))) usb_kbd_irq_worker(dev); #endif Hi, what's the status of this patch/patchset? Thanks M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: add numeric keypad support to HID driver
When keys are pressed on the numeric keypad, emit key codes for the numbers, operators, dot and enter. Signed-off-by: Vincent Palatin vpala...@chromium.org --- Hi, what's the status of this patch/patchset? Thanks M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: omap3: temporary disable USB on TAM3517 boards
The TAM3517 boards require a patch for EHCI OMAP that does not yet find a way to mainline. The patch disables temporary USB until EHCI OMAP will be supported. Signed-off-by: Stefano Babic sba...@denx.de Cc: Tom Rini tom.r...@gmail.com Cc: Albert Aribaud albert.u.b...@aribaud.net --- include/configs/tam3517-common.h |7 +-- 1 files changed, 5 insertions(+), 2 deletions(-) Hi, what's the status of this patch/patchset? Thanks M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] USB: move keyboard polling into kbd driver
This moves keyboard polling logic from USB HCD drivers into USB keyboard driver. Remove usb_event_poll() as keyboard polling was the only user of this API. With this patch USB keyboard works with EHCI controllers again. Tested on a tegra2 seaboard. Signed-off-by: Allen Martin amar...@nvidia.com --- common/usb_kbd.c| 18 +- drivers/usb/host/ehci-hcd.c | 30 -- drivers/usb/host/ohci-hcd.c |6 -- drivers/usb/host/r8a66597-hcd.c |6 -- drivers/usb/musb/musb_hcd.c | 28 include/usb.h |1 - 6 files changed, 17 insertions(+), 72 deletions(-) Hi, what's the status of this patch/patchset? Thanks M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] USB: reevaluate iomux stdin on USB kbd detect
If CONSOLE_MUX is enabled, reevaluate console stdin when USB keyboard device is detected. Signed-off-by: Allen Martin amar...@nvidia.com --- Hi, what's the status of this patch/patchset? Thanks M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH]powerpc/8xxx:Add MPH controller support in USB device-tree fixup
Add support for fixing usb mode and phy type for MPH(Multi Port Host) USB controllers in device-tree nodes. Required for socs like P3060, P5020, etc having MPH USB controller. Signed-off-by: Ramneek Mehresh ramneek.mehr...@freescale.com --- arch/powerpc/cpu/mpc8xxx/fdt.c | 46 ++-- include/fdt_support.h | 4 +- 2 files changed, 32 insertions(+), 18 Hi, what's the status of this patch/patchset? Thanks M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] USB: Armada100: Add UTMI PHY interface driver
This patch adds USB host controller's UTMI PHY interface driver for Armada100 SOCs. Signed-off-by: Ajay Bhargav ajay.bhar...@einfochips.com --- arch/arm/include/asm/arch-armada100/armada100.h |7 ++ drivers/usb/host/utmi-armada100.c | 87 +++ drivers/usb/host/utmi-armada100.h | 79 3 files changed, 173 insertions(+), 0 deletions(-) create mode 100644 drivers/usb/host/utmi-armada100.c create mode 100644 drivers/usb/host/utmi-armada100.h Hi, what's the status of this patch/patchset? Thanks M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/usb: fix bug of CPU halt when missing USB PHY clock
when missing USB PHY clock and issuing usb start at u-boot prompt, writing to or_portsc register will cause CPU halt. We should check USBGP[PHY_CLK_VALID] bit at the first time in ehci_hcd_init() to avoid CPU hang in this case. Signed-off-by: Shengzhou Liu shengzhou@freescale.com --- drivers/usb/host/ehci-fsl.c | 22 +++--- 1 files changed, 19 insertions(+), 3 deletions(-) Hi, what's the status of this patch/patchset? Thanks M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/4] Clean up ehci-omap and extend support for omap3/4 socs
From: Govindraj.R govindraj.r...@ti.com Clean up ehci-omap added and make it generic to extend support for omap4 socs. Add ehci support for panda board. Patch series depends on below patch: http://patchwork.ozlabs.org/patch/130952/ Patch series based commit id: 9a4209869bd2c37affd931d627b3c3e72952 This patch series long with above dependent patch is avialable at: git://gitorious.org/denx_u-boot/denx_uboot_omap.git v2_ehci_omap4 Fatls, ping and tftp was tested with this patch series. Test log for Panda available here: http://pastebin.pandaboard.org/index.php/view/55361716 Test log for Beagle-XM available here: http://pastebin.pandaboard.org/index.php/view/98437825 Hi, what's the status of this patch/patchset? Thanks M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 0/18] tegra: Add fdt definitions and USB driver
This series brings in the Linux kernel fdt file and provides a working USB driver for Tegra2 Seaboard. (I have done this in one series since otherwise most of the fdt additions will just look like dead code.) The driver requires CONFIG_OF_CONTROL and a device tree to operate. Some enhancements to fdtdec are required to make this easier, and these are included in the series also. I have had to bring in basic GPIO support due to the request to put the USB VBUS into the fdt. Since the kernel recently got a very minimal USB binding, I have started with that and extended it where appropriate. Tegra likes to have cache-aligned buffers. I have dropped the patch which implements this since we will solve this problem by making callers align their buffers (as we did with MMC). Hi, what's the status of this patch/patchset? Thanks M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: musb: fix printf warning
musb_hcd.c: In function 'musb_submit_rh_msg': musb_hcd.c:827:2: warning: format '%d' expects type 'int', but argument 3 has type 'long unsigned int' Signed-off-by: Mike Frysinger vap...@gentoo.org --- drivers/usb/musb/musb_hcd.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Hi, what's the status of this patch/patchset? Thanks M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 10/18] tegra: usb: fdt: Add additional device tree definitions for USB ports
This adds clock references to the USB part of the device tree for U-Boot, and marks USB1 as supporting legacy mode (which we disable in the driver). The USB timing information may vary between boards sometimes, but for now we hard-code it in C. This is because all current T2x boards use the same values, we will deal with T3x later and we first need to agree on the format for this timing information in the fdt and may in fact decide that it has no place there. Hi, what's the status of this patch/patchset? Thanks M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH]powerpc/8xxx: Cleanup USB device-tree fixup
Some code cleanup done for USB device-tree fixup: - handling error value returned from fdt_fixup_usb_mode_phy_type() - using ARRAY_SIZE macro - using snprintf instead of sprintf Signed-off-by: Ramneek Mehresh ramneek.mehr...@freescale.com --- KW Warnings fixed: using snprintf instead of sprintf Hi, what's the status of this patch/patchset? Thanks M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Deprecation (planned removal) of 'maintainer-less' code
Hi Marek, On Mon, Feb 27, 2012 at 10:06 AM, Marek Vasut marek.va...@gmail.com wrote: Hi Wolfgang, I notice you've finally gotten sick of 'talking to the wall' regarding unmaintained code (net, USB, AVR32, etc.) To make life a little easier for everyone, maybe we can put together a list of U-Boot sub-components which do not have an active maintainer so we can discuss what to do about it as a whole rather than in a piecemeal fashion And this'll produce more talk to the wall. Sorry, should have been more specific - List all the code that does not have a maintainer in one thread and set a timeframe on deprication of the lot unless maintainers are found (say 3 months) and then just depricate it all in one go... I'll take over the USB, so you better CC me for USB patches. We need someone for NET now ... I still wonder if we can't just move all the unmaintained code off to a corner like /depricated with a CONFIG_SYS_ENABLE_DEPRICATED with a big fat warning that there is no support for depricated code? Anything that stays in depricated for longer than 6 months can them be thrown away. Make a rule that no board configuration which sets CONFIG_SYS_ENABLE_DEPRICATED will be accepted into mainline - If you really want feature 'X' for your board and simply cannot live without it, be prepared to maintain it :) Like Wolfgang, I would like to see these sub-systems that are prone to bit-rot removed, but I think we should be able to come to a comprimise and 'box' the bit-rot (kind of an inverse to the Linux 'staging' strategy which prevents non-compliant code getting into the main kernel code base) Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Deprecation (planned removal) of 'maintainer-less' code
Hi Marek, On Mon, Feb 27, 2012 at 10:06 AM, Marek Vasut marek.va...@gmail.com wrote: Hi Wolfgang, I notice you've finally gotten sick of 'talking to the wall' regarding unmaintained code (net, USB, AVR32, etc.) To make life a little easier for everyone, maybe we can put together a list of U-Boot sub-components which do not have an active maintainer so we can discuss what to do about it as a whole rather than in a piecemeal fashion And this'll produce more talk to the wall. Sorry, should have been more specific - List all the code that does not have a maintainer in one thread and set a timeframe on deprication of the lot unless maintainers are found (say 3 months) and then just depricate it all in one go... I'll take over the USB, so you better CC me for USB patches. We need someone for NET now ... I still wonder if we can't just move all the unmaintained code off to a corner like /depricated with a CONFIG_SYS_ENABLE_DEPRICATED with a big fat warning that there is no support for depricated code? Anything that stays in depricated for longer than 6 months can them be thrown away. Make a rule that no board configuration which sets CONFIG_SYS_ENABLE_DEPRICATED will be accepted into mainline - If you really want feature 'X' for your board and simply cannot live without it, be prepared to maintain it :) Like Wolfgang, I would like to see these sub-systems that are prone to bit-rot removed, but I think we should be able to come to a comprimise and 'box' the bit-rot (kind of an inverse to the Linux 'staging' strategy which prevents non-compliant code getting into the main kernel code base) Or find some maintainers ... M Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: musb: fix printf warning
On Sunday 26 February 2012 18:13:58 Marek Vasut wrote: musb_hcd.c: In function 'musb_submit_rh_msg': musb_hcd.c:827:2: warning: format '%d' expects type 'int', but argument 3 has type 'long unsigned int' what's the status of this patch/patchset? the usb ones are waiting for someone to pick up -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] usb: musb: fix printf warning
On Sunday 26 February 2012 18:13:58 Marek Vasut wrote: musb_hcd.c: In function 'musb_submit_rh_msg': musb_hcd.c:827:2: warning: format '%d' expects type 'int', but argument 3 has type 'long unsigned int' what's the status of this patch/patchset? the usb ones are waiting for someone to pick up -mike Ok, can you please resend and Cc me so I can pick them up? M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: musb: fix printf warning
On Sunday 26 February 2012 18:48:26 Marek Vasut wrote: On Sunday 26 February 2012 18:13:58 Marek Vasut wrote: musb_hcd.c: In function 'musb_submit_rh_msg': musb_hcd.c:827:2: warning: format '%d' expects type 'int', but argument 3 has type 'long unsigned int' what's the status of this patch/patchset? the usb ones are waiting for someone to pick up Ok, can you please resend and Cc me so I can pick them up? http://patchwork.ozlabs.org/patch/139366/ -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] AVR32 removal due to lack of custodian.
Adding linux maintainers to CC, since if it dies here, it should probably also die in the linux kernel as well... P. --- On Sat, Feb 25, 2012 at 5:13 PM, Wolfgang Denk w...@denx.de wrote: AVR32 appaers to be unmaintained, and nobody appears to care about that. Let's get rid fof it. Signed-off-by: Wolfgang Denk w...@denx.de --- doc/feature-removal-schedule.txt | 7 ++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/doc/feature-removal-schedule.txt b/doc/feature-removal-schedule.txt index e04ba2d..f0b828e 100644 --- a/doc/feature-removal-schedule.txt +++ b/doc/feature-removal-schedule.txt @@ -7,6 +7,20 @@ file. --- +What: ARV32 Support +When: v2012.06 +Why: Lack of a custodian and of interest, and lack of time and/or sponsors. +Who: Wolfgang Denk w...@denx.de + +--- + What: Users of the legacy miiphy_* code When: undetermined -- 1.7.7.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] sandbox: allow processing before main loop
Hi Mike,
On Sun, Feb 26, 2012 at 2:38 PM, Mike Frysinger vap...@gentoo.org wrote:
From: Simon Glass s...@chromium.org
In order to pass command line arguments to sandbox we need to be able
to act on them. So take control back at the end of board_init_r() from
where we can call the main loop or do something else.
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
arch/sandbox/cpu/start.c | 5 +
arch/sandbox/include/asm/u-boot-sandbox.h | 3 +++
arch/sandbox/lib/board.c | 2 ++
3 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/sandbox/cpu/start.c b/arch/sandbox/cpu/start.c
index 2b66eed..dc020ee 100644
--- a/arch/sandbox/cpu/start.c
+++ b/arch/sandbox/cpu/start.c
@@ -22,6 +22,11 @@
#include common.h
#include asm/state.h
+int sb_main_loop_init(void)
Would prefer sandbox_main_loop_init()
+{
+ return 0;
+}
+
int main(int argc, char *argv[])
{
int err;
diff --git a/arch/sandbox/include/asm/u-boot-sandbox.h
b/arch/sandbox/include/asm/u-boot-sandbox.h
index 236b4ee..f0e8b3c 100644
--- a/arch/sandbox/include/asm/u-boot-sandbox.h
+++ b/arch/sandbox/include/asm/u-boot-sandbox.h
@@ -35,4 +35,7 @@
int board_init(void);
int dram_init(void);
+/* start.c */
+int sb_main_loop_init(void);
+
#endif /* _U_BOOT_SANDBOX_H_ */
diff --git a/arch/sandbox/lib/board.c b/arch/sandbox/lib/board.c
index 6d464d6..1082e7d 100644
--- a/arch/sandbox/lib/board.c
+++ b/arch/sandbox/lib/board.c
@@ -269,6 +269,8 @@ void board_init_r(gd_t *id, ulong dest_addr)
post_run(NULL, POST_RAM | post_bootmode_get(0));
#endif
+ sb_main_loop_init();
+
/*
* For now, run the main loop. Later we might let this be done
* in the main program.
--
1.7.8.4
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] sandbox: add concept of sandbox state
On Sun, Feb 26, 2012 at 2:38 PM, Mike Frysinger vap...@gentoo.org wrote:
From: Simon Glass s...@chromium.org
The state exists through the life of U-Boot. It can be adjusted by command
line options and perhaps later through a config file. It is available to
U-Boot through state_...() calls (within sandbox code).
The primary purpose of this is to contain the hardware state. It should
only be used by sandbox internal code.
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Mike Frysinger vap...@gentoo.org
Acked-by: Simon Glass s...@chromium.org
---
arch/sandbox/cpu/Makefile | 2 +-
arch/sandbox/cpu/start.c | 9 +-
arch/sandbox/cpu/state.c | 51 ++
arch/sandbox/include/asm/state.h | 57
++
4 files changed, 117 insertions(+), 2 deletions(-)
create mode 100644 arch/sandbox/cpu/state.c
create mode 100644 arch/sandbox/include/asm/state.h
diff --git a/arch/sandbox/cpu/Makefile b/arch/sandbox/cpu/Makefile
index 2ae0f71..6fd09ff 100644
--- a/arch/sandbox/cpu/Makefile
+++ b/arch/sandbox/cpu/Makefile
@@ -27,7 +27,7 @@ include $(TOPDIR)/config.mk
LIB = $(obj)lib$(CPU).o
-COBJS := cpu.o start.o os.o
+COBJS := cpu.o os.o start.o state.o
SRCS := $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS))
diff --git a/arch/sandbox/cpu/start.c b/arch/sandbox/cpu/start.c
index a429e29..2b66eed 100644
--- a/arch/sandbox/cpu/start.c
+++ b/arch/sandbox/cpu/start.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2011 The Chromium OS Authors.
+ * Copyright (c) 2011-2012 The Chromium OS Authors.
* See file CREDITS for list of people who contributed to this
* project.
*
@@ -20,9 +20,16 @@
*/
#include common.h
+#include asm/state.h
int main(int argc, char *argv[])
{
+ int err;
+
+ err = state_init();
+ if (err)
+ return err;
+
/*
* Do pre- and post-relocation init, then start up U-Boot. This will
* never return.
diff --git a/arch/sandbox/cpu/state.c b/arch/sandbox/cpu/state.c
new file mode 100644
index 000..88ae2b0
--- /dev/null
+++ b/arch/sandbox/cpu/state.c
@@ -0,0 +1,51 @@
+/*
+ * Copyright (c) 2011-2012 The Chromium OS Authors.
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include common.h
+#include asm/state.h
+
+/* Main state record for the sandbox */
+static struct sandbox_state main_state;
+static struct sandbox_state *state; /* Pointer to current state record */
+
+void state_record_exit(enum exit_type_id exit_type)
+{
+ state-exit_type = exit_type;
+}
+
+struct sandbox_state *state_get_current(void)
+{
+ assert(state);
+ return state;
+}
+
+int state_init(void)
+{
+ state = main_state;
+
+ /*
+ * Example of how to use GPIOs:
+ *
+ * sandbox_gpio_set_direction(170, 0);
+ * sandbox_gpio_set_value(170, 0);
+ */
+ return 0;
+}
diff --git a/arch/sandbox/include/asm/state.h
b/arch/sandbox/include/asm/state.h
new file mode 100644
index 000..5b34e94
--- /dev/null
+++ b/arch/sandbox/include/asm/state.h
@@ -0,0 +1,57 @@
+/*
+ * Copyright (c) 2011-2012 The Chromium OS Authors.
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#ifndef __SANDBOX_STATE_H
+#define __SANDBOX_STATE_H
+
+/* How we exited U-Boot */
+enum
Re: [U-Boot] u-boot for SPEAr1310
Hello Pavel, Not bad so far. :) ...it started something. According to gdb it looks like new u-boot executes briefly, but fails in C code while processing intialization, and it seems that old u-boot takes over. (Some kind of failure and board resets itself?). Yes, the u-boot resets itself. This is a workaround of a known problem The code lies at arch/arm/cpu/arm_cortexa8/spear13xx/cpu.c search for config_spear1300_issue_101435. It can be disabled during development Regards Vipin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/usb: fix bug of CPU halt when missing USB PHY clock
-Original Message- From: Marek Vasut [mailto:ma...@denx.de] Sent: Monday, February 27, 2012 7:13 AM To: u-boot@lists.denx.de Cc: Liu Shengzhou-B36685 Subject: Re: [U-Boot] [PATCH] powerpc/usb: fix bug of CPU halt when missing USB PHY clock when missing USB PHY clock and issuing usb start at u-boot prompt, writing to or_portsc register will cause CPU halt. We should check USBGP[PHY_CLK_VALID] bit at the first time in ehci_hcd_init() to avoid CPU hang in this case. Signed-off-by: Shengzhou Liu shengzhou@freescale.com --- drivers/usb/host/ehci-fsl.c | 22 +++--- 1 files changed, 19 insertions(+), 3 deletions(-) Hi, what's the status of this patch/patchset? Thanks M Currently we found that usb CTRL_PHY_CLK_VALID bit breaks on P1022 platform, which not contains this bit. - P1023/P3041/P5020 etc, have this bit - P3060/4080/PSC913x do have this bit, but not mentioned in RM. - P1022(perhaps and other) has no this bit I'm waiting for the response from FSL silicon team to confirm whether there is other platform not including this bit or not, so this patch maybe have to be pending until I get confirmation. Thanks, Shengzhou ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] sandbox: add getopt support
Hi Mike,
On Sun, Feb 26, 2012 at 2:38 PM, Mike Frysinger vap...@gentoo.org wrote:
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
arch/sandbox/cpu/os.c | 64 ++
arch/sandbox/cpu/start.c | 83
+
arch/sandbox/cpu/u-boot.lds | 4 ++
arch/sandbox/include/asm/state.h | 5 ++
arch/sandbox/include/asm/u-boot-sandbox.h | 1 +
arch/sandbox/lib/board.c | 1 +
include/os.h | 35
7 files changed, 193 insertions(+), 0 deletions(-)
diff --git a/arch/sandbox/cpu/os.c b/arch/sandbox/cpu/os.c
index cb469e0..4b1c987 100644
--- a/arch/sandbox/cpu/os.c
+++ b/arch/sandbox/cpu/os.c
@@ -21,6 +21,7 @@
#include errno.h
#include fcntl.h
+#include getopt.h
#include stdlib.h
#include termios.h
#include time.h
@@ -32,6 +33,7 @@
#include linux/types.h
#include os.h
+#include asm/state.h
/* Operating System Interface */
@@ -155,3 +157,65 @@ u64 os_get_nsec(void)
return tv.tv_sec * 10ULL + tv.tv_usec * 1000;
#endif
}
+
+extern struct sb_cmdline_option *__u_boot_sb_getopt_start[],
+ *__u_boot_sb_getopt_end[];
I wonder if we can put this in asm-generic/sections.h - or perhaps
that doesn't exist yet?
Also how about __u_boot_sandbox_option_start/end? I'm really not keen on 'sb'.
+static char *short_opts;
+static struct option *long_opts;
+
+int os_parse_args(struct sandbox_state *state, int argc, char *argv[])
+{
+ struct sb_cmdline_option **sb_opt = __u_boot_sb_getopt_start;
+ size_t num_flags = __u_boot_sb_getopt_end - __u_boot_sb_getopt_start;
num_options?
+ size_t i;
+
+ int hidden_short_opt;
+ size_t si;
si?
+
+ int c;
+
+ if (short_opts || long_opts)
+ os_exit(1);
+
+ state-argc = argc;
+ state-argv = argv;
+
+ short_opts = os_malloc(sizeof(*short_opts) * (num_flags + 1));
Comment on why +1? is it for \0 terminator?
+ long_opts = os_malloc(sizeof(*long_opts) * num_flags);
+ if (!short_opts || !long_opts)
+ os_exit(1);
+
+ si = 0;
+ hidden_short_opt = 0x80;
+ for (i = 0; i num_flags; ++i) {
+ long_opts[i].name = sb_opt[i]-flag;
+ long_opts[i].has_arg = sb_opt[i]-has_arg ?
+ required_argument : no_argument;
+ long_opts[i].flag = NULL;
+
+ if (sb_opt[i]-flag_short)
+ short_opts[si++] = long_opts[i].val =
sb_opt[i]-flag_short;
+ else
+ long_opts[i].val = sb_opt[i]-flag_short =
hidden_short_opt++;
What is this hidden_short_opt for? Suggest a comment.
+ }
+ short_opts[si] = '\0';
+
+ /* We need to handle output ourselves since u-boot provides printf */
+ opterr = 0;
+
+ while ((c = getopt_long(argc, argv, short_opts, long_opts, NULL)) !=
-1) {
+ for (i = 0; i num_flags; ++i) {
+ if (sb_opt[i]-flag_short == c) {
+ sb_opt[i]-callback(state, optarg);
+ break;
+ }
+ }
+ if (i == num_flags) {
+ /* store the faulting flag index for later */
+ state-parse_err = -optind;
+ break;
+ }
+ }
+
+ return 0;
+}
diff --git a/arch/sandbox/cpu/start.c b/arch/sandbox/cpu/start.c
index dc020ee..895ec49 100644
--- a/arch/sandbox/cpu/start.c
+++ b/arch/sandbox/cpu/start.c
@@ -22,19 +22,102 @@
#include common.h
#include asm/state.h
+#include os.h
+
+extern struct sb_cmdline_option *__u_boot_sb_getopt_start[],
+ *__u_boot_sb_getopt_end[];
As above
+
+int sb_early_getopt_check(void)
+{
+ struct sandbox_state *state = state_get_current();
+ struct sb_cmdline_option **sb_opt = __u_boot_sb_getopt_start;
+ size_t num_flags = __u_boot_sb_getopt_end - __u_boot_sb_getopt_start;
num_options again
+ size_t i;
+ int max_arg_len, max_noarg_len;
+
+ if (state-parse_err == 0)
+ return 0;
+
Comment: parse_error stores -n where n is the index of the option that
we faulted.
+ if (state-parse_err 0)
+ printf(error: unknown option: %s\n\n,
+ state-argv[-state-parse_err - 1]);
+
+ printf(
do we need this extra newline?
+ u-boot, a command line test interface to U-Boot\n\n
+ Usage: u-boot [options]\n
+ Options:\n);
+
+ max_arg_len = 0;
+ for (i = 0; i num_flags; ++i)
+ max_arg_len = max(strlen(sb_opt[i]-flag), max_arg_len);
+ max_noarg_len = max_arg_len + 7;
+
+ for (i = 0; i num_flags; ++i) {
+
Re: [U-Boot] [PATCH v4 8/8] sandbox: Add basic command line parsing
Hi Mike,
On Sun, Feb 26, 2012 at 1:04 PM, Mike Frysinger vap...@gentoo.org wrote:
On Wednesday 15 February 2012 18:51:18 Simon Glass wrote:
--- a/arch/sandbox/cpu/os.c
+++ b/arch/sandbox/cpu/os.c
+#include stdio.h
+void os_usage(int err)
+{
+ if (err 0)
+ fprintf(stderr, Try `--help' for more information.\n);
+ fprintf(err 0 ? stderr : stdout, u-boot,
+ a command line test interface to U-Boot\n\n
+ usage:\tu-boot [-ch]\n
+ Options:\n
+ \t-h\tDisplay help\n
+ \t-c command\tExecute U-Boot command\n);
this actually doesn't work. we're using the stdio from u-boot itself, so we
can't use stdio.h from glibc. if it works for you, i'm pretty sure it's
purely an accident (perhaps related to the fortification change i just
posted).
From memory this actually used U-Boot's fprintf, not stdio's, but I
can't really remember why it worked.
Given your efforts on the cmdline parsing I'm beginning to think we
should perhaps add os_printf() and os_printf_stderr() and provide an
explicit interface. It might only be useful prior to main(), then
again I'm not so sure.
-mike
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/16] tegra: Add fdt definitions and USB driver
Hi Marek, On Sun, Feb 26, 2012 at 3:09 PM, Marek Vasut ma...@denx.de wrote: This series brings in the kernel fdt file and provides a working USB driver for Tegra2 Seaboard. (I have done this in one series since otherwise most of the fdt additions will just look like dead code.) The driver requires CONFIG_OF_CONTROL and a device tree to operate. Some enhancements to fdtdec are required to make this easier, and these are included in the series also. I have had to bring in basic GPIO support due to the request to put the USB VBUS into the fdt. Since the kernel recently got a very minimal USB binding, I have started with that and extended it where appropriate. Tegra likes to have cache-aligned buffers. I have dropped the patch which implements this since we will solve this problem by making callers align their buffers (as we did with MMC). Changes in v2: - Use okay instead of ok for fdt node status - Remove 0x from fdt aliases - Rename params to timing - Store entire fdt config in port list, not just register pointer - Remove non-fdt operation of USB, since it is not needed - Decode USB VBUS GPIO from the fdt - Decode phy type differently (to match new kernel fdt) - Rename tegra20-usb to tegra20-ehcui (to match new kernel fdt) - Improve debug() printouts in case of failure to init USB - Add setting of pinmux for USB VBUS GPIO - Remove unneeded CONFIG_TEGRA_USBx defines Changes in v3: - Remove okay from nodes since this is the default anyway - Fix device tree indenting with tabs instead of spaces - Disable USB2 which is not used on Seaboard - Remove usbparams properties from fdt and moved them to C code - Drop Tegra USB alignment patch as we will deal with this another way Simon Glass (16): fdt: Tidy up a few fdtdec problems fdt: Add functions to access phandles, arrays and bools Add gpio_request() to asm-generic header fdt: Add basic support for decoding GPIO definitions arm: fdt: Ensure that an embedded fdt is word-aligned arm: fdt: Add skeleton device tree file from kernel tegra: fdt: Add Tegra2x device tree file from kernel tegra: fdt: Add device tree file for Tegra2 Seaboard from kernel tegra: usb: fdt: Add additional device tree definitions for USB ports tegra: usb: fdt: Add USB definitions for Tegra2 Seaboard usb: Add support for txfifo threshold tegra: usb: Add support for Tegra USB peripheral tegra: usb: Add USB support to nvidia boards tegra: usb: Add common USB defines for tegra2 boards tegra: usb: Enable USB on Seaboard tegra: fdt: Enable FDT support for Seaboard README | 3 + arch/arm/cpu/armv7/tegra2/Makefile | 4 +- arch/arm/cpu/armv7/tegra2/config.mk | 2 + arch/arm/cpu/armv7/tegra2/usb.c | 430 + arch/arm/cpu/armv7/u-boot.lds | 5 + arch/arm/dts/skeleton.dtsi | 13 + arch/arm/dts/tegra20.dtsi | 172 arch/arm/include/asm/arch-tegra2/tegra2.h | 2 + arch/arm/include/asm/arch-tegra2/usb.h | 255 + board/nvidia/common/board.c | 8 + board/nvidia/dts/tegra2-seaboard.dts | 47 drivers/usb/host/Makefile | 1 + drivers/usb/host/ehci-hcd.c | 7 + drivers/usb/host/ehci-tegra.c | 63 + drivers/usb/host/ehci.h | 6 +- dts/Makefile | 2 +- include/asm-generic/gpio.h | 10 + include/configs/seaboard.h | 12 + include/configs/tegra2-common.h | 14 + include/fdtdec.h | 109 +++- lib/fdtdec.c | 168 +++- 21 files changed, 1320 insertions(+), 13 deletions(-) create mode 100644 arch/arm/cpu/armv7/tegra2/usb.c create mode 100644 arch/arm/dts/skeleton.dtsi create mode 100644 arch/arm/dts/tegra20.dtsi create mode 100644 arch/arm/include/asm/arch-tegra2/usb.h create mode 100644 board/nvidia/dts/tegra2-seaboard.dts create mode 100644 drivers/usb/host/ehci-tegra.c Hi, what's the status of this patch/patchset? It needs a small update to the Tegra device tree files (2 of the patches) and another change to deal with peripheral IDs (another 2 of the patches). I expect to get this done in the next few days. After that I am hoping we are done, but let's see. Regards, Simon Thanks M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sandbox: tweak style in linker script
On Sun, Feb 26, 2012 at 11:26 AM, Mike Frysinger vap...@gentoo.org wrote:
We use tabs for indentation, not spaces.
Signed-off-by: Mike Frysinger vap...@gentoo.org
Acked-by: Simon Glass s...@chromium.org
---
arch/sandbox/cpu/u-boot.lds | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/sandbox/cpu/u-boot.lds b/arch/sandbox/cpu/u-boot.lds
index 2d2e50f..0c56aa7 100644
--- a/arch/sandbox/cpu/u-boot.lds
+++ b/arch/sandbox/cpu/u-boot.lds
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2011 The Chromium OS Authors.
+ * Copyright (c) 2011-2012 The Chromium OS Authors.
* Use of this source code is governed by a BSD-style license that can be
* found in the LICENSE file.
*
@@ -24,11 +24,11 @@
SECTIONS
{
- __u_boot_cmd_start = .;
- .u_boot_cmd : { *(.u_boot_cmd) }
- __u_boot_cmd_end = .;
- __bss_start = .;
+ __u_boot_cmd_start = .;
+ _u_boot_cmd : { *(.u_boot_cmd) }
+ __u_boot_cmd_end = .;
+ __bss_start = .;
}
INSERT BEFORE .data;
--
1.7.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sandbox: disable fortification
On Sun, Feb 26, 2012 at 1:01 PM, Mike Frysinger vap...@gentoo.org wrote: Since we provide all our own library calls, the fortification from glibc just gets in our way (which some distros enable by default). Signed-off-by: Mike Frysinger vap...@gentoo.org Acked-by: Simon Glass s...@chromium.org --- arch/sandbox/config.mk | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/sandbox/config.mk b/arch/sandbox/config.mk index 2ec1bb7..02ce4a4 100644 --- a/arch/sandbox/config.mk +++ b/arch/sandbox/config.mk @@ -17,5 +17,5 @@ # Foundation, Inc., 59 Temple Place, Suite 330, Boston, # MA 02111-1307 USA -PLATFORM_CPPFLAGS += -DCONFIG_SANDBOX -D__SANDBOX__ +PLATFORM_CPPFLAGS += -DCONFIG_SANDBOX -D__SANDBOX__ -U_FORTIFY_SOURCE PLATFORM_LIBS += -lrt -- 1.7.8.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 0/18] tegra: Add fdt definitions and USB driver
Hi Marek, On Sun, Feb 26, 2012 at 3:13 PM, Marek Vasut ma...@denx.de wrote: This series brings in the Linux kernel fdt file and provides a working USB driver for Tegra2 Seaboard. (I have done this in one series since otherwise most of the fdt additions will just look like dead code.) The driver requires CONFIG_OF_CONTROL and a device tree to operate. Some enhancements to fdtdec are required to make this easier, and these are included in the series also. I have had to bring in basic GPIO support due to the request to put the USB VBUS into the fdt. Since the kernel recently got a very minimal USB binding, I have started with that and extended it where appropriate. Tegra likes to have cache-aligned buffers. I have dropped the patch which implements this since we will solve this problem by making callers align their buffers (as we did with MMC). Hi, what's the status of this patch/patchset? Superceded, v6 is on its way in the next few days. Thanks M Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 8/8] sandbox: Add basic command line parsing
On Sunday 26 February 2012 21:50:32 Simon Glass wrote: Given your efforts on the cmdline parsing I'm beginning to think we should perhaps add os_printf() and os_printf_stderr() and provide an explicit interface. It might only be useful prior to main(), then again I'm not so sure. i've been pondering this. on one hand, we want to parse flags as soon as possible, but on the other, we want to be able to not have to worry about what state the system is in when parsing things. maybe we specially mark the few flags that we need very early on and parse those, and then parse the rest once the system is mostly functional ? i can really only think of one or two flags that we *might* need very early -- namely, ones that'd select a config or fdt. on the other hand, are there things that we'd want to change that'd affect everything from console_init_f() and earlier ? wrt os_printf/etc..., the only way we could do that is if we dlopen-ed glibc and called the symbol directly. u-boot provides printf() so we can't have an os_printf() in os.c call printf() in glibc simply because we included stdio.h from glibc. -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 00/14] Nokia RX-51 support
On Sunday 26 February 2012 17:08:04 Marek Vasut wrote: On Tuesday 24 January 2012 15:27:57 Pali Rohár wrote: This patch series add support for new board Nokia RX-51 (aka N900). Last two patches adding on screen bootmenu support. This series supersedes the last sent version. Hi, what is state of this patch series? From our discussion is only problematic bootmenu part, but other could be OK. So what is needed for including this patches (without bootmenu support) to uboot master? You should probably split the patches into smaller series and resubmit individually. yeah, we aren't keen on manually trying to pick things out of a patchset since it's hard for us to know what is required to be together. a patchset, by nature, should be merged as a group. -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/3] sandbox: add getopt support
On Sunday 26 February 2012 21:46:23 Simon Glass wrote:
On Sun, Feb 26, 2012 at 2:38 PM, Mike Frysinger wrote:
--- a/arch/sandbox/cpu/os.c
+++ b/arch/sandbox/cpu/os.c
+extern struct sb_cmdline_option *__u_boot_sb_getopt_start[],
+ *__u_boot_sb_getopt_end[];
I wonder if we can put this in asm-generic/sections.h - or perhaps
that doesn't exist yet?
sorry, should have labeled this patch more as a PoC as i know it requires a
little more polish. these would go into sandbox's asm/sections.h since these
are specific to the sandbox port.
Also how about __u_boot_sandbox_option_start/end? I'm really not keen on
'sb'.
for these two vars, that's fine. i prefer sb for internal static stuff since
sandbox can get wordy real fast.
+ int hidden_short_opt;
+ size_t si;
si?
short_opt_index is the self-commenting name
+ short_opts = os_malloc(sizeof(*short_opts) * (num_flags + 1));
Comment on why +1? is it for \0 terminator?
yes, the getopt_long() api requires a NUL terminated string
+ si = 0;
+ hidden_short_opt = 0x80;
+ for (i = 0; i num_flags; ++i) {
+ long_opts[i].name = sb_opt[i]-flag;
+ long_opts[i].has_arg = sb_opt[i]-has_arg ?
+ required_argument : no_argument;
+ long_opts[i].flag = NULL;
+
+ if (sb_opt[i]-flag_short)
+ short_opts[si++] = long_opts[i].val =
sb_opt[i]-flag_short; + else
+ long_opts[i].val = sb_opt[i]-flag_short =
hidden_short_opt++;
What is this hidden_short_opt for? Suggest a comment.
i think most options we have will be long only. much harder to make sure you
don't have collisions in the entire base when the flag definition is in the
subfiles. but getopt_long() needs a unique int for each long flag, so hidden
just means not an ascii char.
+ if (state-parse_err 0)
+ printf(error: unknown option: %s\n\n,
+ state-argv[-state-parse_err - 1]);
+
+ printf(
do we need this extra newline?
i find the extra newline helps to differentiate from the noise when we turn
around and dump the --help output. alternative would be to not automatically
show --help.
+ for (i = 0; i num_flags; ++i) {
+ /* first output the short flag if it has one */
+ if (sb_opt[i]-flag_short = 0x80)
Can we declare a pointer to sb_opt[i] and the top here and use it below?
yes
+ printf( );
+ else
+ printf( -%c, , sb_opt[i]-flag_short);
+
+ /* then the long flag */
+ if (sb_opt[i]-has_arg)
+ printf(--%-*s, max_noarg_len, sb_opt[i]-flag);
+ else
+ printf(--%-*s arg , max_arg_len,
sb_opt[i]-flag); +
+ /* finally the help text */
+ printf( %s\n, sb_opt[i]-help);
puts() might be safer, but then again I think we have vsnprintf() turned on
now.
not sure what you mean by safer ... if you mean the implicit stack overflows,
i don't think that'll be an issue here. the help strings aren't very long.
int main(int argc, char *argv[])
{
...
+ state = state_get_current();
+ os_parse_args(state, argc, argv);
We don't check the return value. Perhaps add a comment as to why.
since the code takes care of setting parse_err itself now, i'm not sure what
to do with the return value
-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/3] sandbox: add getopt support
Hi Mike,
On Sun, Feb 26, 2012 at 8:20 PM, Mike Frysinger vap...@gentoo.org wrote:
On Sunday 26 February 2012 21:46:23 Simon Glass wrote:
On Sun, Feb 26, 2012 at 2:38 PM, Mike Frysinger wrote:
--- a/arch/sandbox/cpu/os.c
+++ b/arch/sandbox/cpu/os.c
+extern struct sb_cmdline_option *__u_boot_sb_getopt_start[],
+ *__u_boot_sb_getopt_end[];
I wonder if we can put this in asm-generic/sections.h - or perhaps
that doesn't exist yet?
sorry, should have labeled this patch more as a PoC as i know it requires a
little more polish. these would go into sandbox's asm/sections.h since these
are specific to the sandbox port.
Also how about __u_boot_sandbox_option_start/end? I'm really not keen on
'sb'.
for these two vars, that's fine. i prefer sb for internal static stuff
since
sandbox can get wordy real fast.
+ int hidden_short_opt;
+ size_t si;
si?
short_opt_index is the self-commenting name
+ short_opts = os_malloc(sizeof(*short_opts) * (num_flags + 1));
Comment on why +1? is it for \0 terminator?
yes, the getopt_long() api requires a NUL terminated string
+ si = 0;
+ hidden_short_opt = 0x80;
+ for (i = 0; i num_flags; ++i) {
+ long_opts[i].name = sb_opt[i]-flag;
+ long_opts[i].has_arg = sb_opt[i]-has_arg ?
+ required_argument : no_argument;
+ long_opts[i].flag = NULL;
+
+ if (sb_opt[i]-flag_short)
+ short_opts[si++] = long_opts[i].val =
sb_opt[i]-flag_short; + else
+ long_opts[i].val = sb_opt[i]-flag_short =
hidden_short_opt++;
What is this hidden_short_opt for? Suggest a comment.
i think most options we have will be long only. much harder to make sure you
don't have collisions in the entire base when the flag definition is in the
subfiles. but getopt_long() needs a unique int for each long flag, so
hidden
just means not an ascii char.
+ if (state-parse_err 0)
+ printf(error: unknown option: %s\n\n,
+ state-argv[-state-parse_err - 1]);
+
+ printf(
do we need this extra newline?
i find the extra newline helps to differentiate from the noise when we turn
around and dump the --help output. alternative would be to not automatically
show --help.
+ for (i = 0; i num_flags; ++i) {
+ /* first output the short flag if it has one */
+ if (sb_opt[i]-flag_short = 0x80)
Can we declare a pointer to sb_opt[i] and the top here and use it below?
yes
+ printf( );
+ else
+ printf( -%c, , sb_opt[i]-flag_short);
+
+ /* then the long flag */
+ if (sb_opt[i]-has_arg)
+ printf(--%-*s, max_noarg_len, sb_opt[i]-flag);
+ else
+ printf(--%-*s arg , max_arg_len,
sb_opt[i]-flag); +
+ /* finally the help text */
+ printf( %s\n, sb_opt[i]-help);
puts() might be safer, but then again I think we have vsnprintf() turned on
now.
not sure what you mean by safer ... if you mean the implicit stack
overflows,
i don't think that'll be an issue here. the help strings aren't very long.
int main(int argc, char *argv[])
{
...
+ state = state_get_current();
+ os_parse_args(state, argc, argv);
We don't check the return value. Perhaps add a comment as to why.
since the code takes care of setting parse_err itself now, i'm not sure what
to do with the return value
I agree it is right, just asking for a comment. Same with most of my
other things - more comments as I suggested is nice for people that
come into the code fresh.
Regards,
Simon
-mike
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/15] common/main.c: Fix function readline
On Saturday 07 January 2012 03:51:16 Pali Rohár wrote: On Friday 06 January 2012 15:15:29 Mike Frysinger wrote: On Sunday 18 December 2011 16:34:01 Pali Rohár wrote: * Ignore ANSI escape codes for moving cursor, which are generated by keyboard this probably should be behind an appropriate CONFIG knob. i don't think this is relevant to serial users (which are the majority of boards). I think this is also relevant to serial console too. I tried serial console (over USB) with Nokia N900 on computer (ANSI terminal) and if I pressed cursor key (UP/DOWN/LEFT/RIGHT) it moved cursor. But in readline function buffer was stored ANSI sequence. So when I pressed ENTER, u-boot tried to execute that buffer and showed me error. But it showed error message something like unknown command ansi_seq. ansi_seq was recognized in ansi terminal on computer and it garbaged output. (for example if asn_seq was move up, error message continued on previous line...) This patch ignore ansi codes which can be generated by curosor keys, so there will not be that bad error messages... do you have CONFIG_CMDLINE_EDITING enabled ? arrow keys work just fine when that's enabled, and if it isn't, then i think it's expected behavior that pressing the arrow keys would generate junk that u-boot wouldn't interpret. -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 v4 8/8] sandbox: Add basic command line parsing
Hi Mike, On Sun, Feb 26, 2012 at 8:08 PM, Mike Frysinger vap...@gentoo.org wrote: On Sunday 26 February 2012 21:50:32 Simon Glass wrote: Given your efforts on the cmdline parsing I'm beginning to think we should perhaps add os_printf() and os_printf_stderr() and provide an explicit interface. It might only be useful prior to main(), then again I'm not so sure. i've been pondering this. on one hand, we want to parse flags as soon as possible, but on the other, we want to be able to not have to worry about what state the system is in when parsing things. maybe we specially mark the few flags that we need very early on and parse those, and then parse the rest once the system is mostly functional ? i can really only think of one or two flags that we *might* need very early -- namely, ones that'd select a config or fdt. on the other hand, are there things that we'd want to change that'd affect everything from console_init_f() and earlier ? IMO flags should purely update the initial state and therefore we don't need the system to be function to parse them. Once the system is functional, the various bits that are interested can go and look at the state to get the info they want. IOW I don't think we need to delay parsing until the system is functional - we just need to take 'action' then. Anyway once we have a lot of test subsystems we are going to want to have options in a config file. wrt os_printf/etc..., the only way we could do that is if we dlopen-ed glibc and called the symbol directly. u-boot provides printf() so we can't have an os_printf() in os.c call printf() in glibc simply because we included stdio.h from glibc. Yes that reminds me why I didn't do that last time. I was wondering about using a link flag to rename the library version of the call but it seemed a bit ugly. Regards, Simon -mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] sandbox: add getopt support
On Sunday 26 February 2012 23:26:52 Simon Glass wrote:
On Sun, Feb 26, 2012 at 8:20 PM, Mike Frysinger wrote:
On Sunday 26 February 2012 21:46:23 Simon Glass wrote:
On Sun, Feb 26, 2012 at 2:38 PM, Mike Frysinger wrote:
int main(int argc, char *argv[])
{
...
+ state = state_get_current();
+ os_parse_args(state, argc, argv);
We don't check the return value. Perhaps add a comment as to why.
since the code takes care of setting parse_err itself now, i'm not sure
what to do with the return value
I agree it is right, just asking for a comment. Same with most of my
other things - more comments as I suggested is nice for people that
come into the code fresh.
my plan was to clean this up a bit more before submitting (such as adding
comments). i was looking more for feedback on the general approach here and
any fundamental sticking points since this is a semi-radical departure from
what either of us posted earlier.
in this case, i'm asking: should we just toss the return value and have it be
void ?
-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/3] sandbox: add getopt support
Hi Mike,
On Sun, Feb 26, 2012 at 8:35 PM, Mike Frysinger vap...@gentoo.org wrote:
On Sunday 26 February 2012 23:26:52 Simon Glass wrote:
On Sun, Feb 26, 2012 at 8:20 PM, Mike Frysinger wrote:
On Sunday 26 February 2012 21:46:23 Simon Glass wrote:
On Sun, Feb 26, 2012 at 2:38 PM, Mike Frysinger wrote:
int main(int argc, char *argv[])
{
...
+ state = state_get_current();
+ os_parse_args(state, argc, argv);
We don't check the return value. Perhaps add a comment as to why.
since the code takes care of setting parse_err itself now, i'm not sure
what to do with the return value
I agree it is right, just asking for a comment. Same with most of my
other things - more comments as I suggested is nice for people that
come into the code fresh.
my plan was to clean this up a bit more before submitting (such as adding
comments). i was looking more for feedback on the general approach here and
any fundamental sticking points since this is a semi-radical departure from
what either of us posted earlier.
OK I see. Well actually I was expecting that we would need something
along these lines eventually, since arg parsing belongs with the
module that provides the argument I think. So as well to have it now,
even if it doesn't have a lot of uses yet. It will.
in this case, i'm asking: should we just toss the return value and have it be
void ?
I suggest not - even if we ignore it, it seems like information that
should be returned. Perhaps we should make it more explicit by
returning state-return_code with a comment that callers can use it
now or later. But I think the way you have done it is fine.
Regards,
Simon
-mike
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 8/8] sandbox: Add basic command line parsing
On Sunday 26 February 2012 23:33:25 Simon Glass wrote:
On Sun, Feb 26, 2012 at 8:08 PM, Mike Frysinger wrote:
On Sunday 26 February 2012 21:50:32 Simon Glass wrote:
Given your efforts on the cmdline parsing I'm beginning to think we
should perhaps add os_printf() and os_printf_stderr() and provide an
explicit interface. It might only be useful prior to main(), then
again I'm not so sure.
i've been pondering this. on one hand, we want to parse flags as soon as
possible, but on the other, we want to be able to not have to worry about
what state the system is in when parsing things. maybe we specially
mark the few flags that we need very early on and parse those, and then
parse the rest once the system is mostly functional ? i can really only
think of one or two flags that we *might* need very early -- namely,
ones that'd select a config or fdt. on the other hand, are there things
that we'd want to change that'd affect everything from console_init_f()
and earlier ?
IMO flags should purely update the initial state and therefore we
don't need the system to be function to parse them. Once the system is
functional, the various bits that are interested can go and look at
the state to get the info they want. IOW I don't think we need to
delay parsing until the system is functional - we just need to take
'action' then.
ok, so for example, i updated my spi flash patch to do:
drivers/mtd/spi/sandbox.c:
static int sb_cmdline_cb_spi_sf(struct sandbox_state *state, const char *arg)
{
unsigned long bus, cs;
const char *spec = sb_spi_parse_spec(arg, bus, cs);
if (!spec)
return 1;
state-spi[bus][cs][0] = sb_sf_ops;
state-spi[bus][cs][1] = spec;
return 0;
}
SB_CMDLINE_OPT(spi_sf, 1, connect a SPI flash: bus:cs:id:file);
and people could do:
./u-boot --spi_sf 0:3:m25p16:./some-file.bin
this would connect the spi flash simulation up to the simulated spi bus 0 on cs
3 and have it simulate a m25p16 flash with some-file.bin backing it.
if someone were to enter the wrong value for 0:3:m25p16:./some-file.bin, how
do you propose we communicate that ? the existing code can easily signal the
higher parsing logic via return values, but then we'd just get:
failed to parse option: 0:3:m25p16:./some-file.bin
but what exactly did the code not like ? was it the bus # ? the cs # ? the
spi flash id ? the backing file ? if the getopt code has access to printf(),
we can clearly communicate to the user what is going wrong.
-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
[U-Boot] Facing the problem with yaffs2 from uboot
Hi, Iam using SMDK6410 arm11 board having the samsung Nandflash with a capacity of 1Gb.Iam not able to load the yaffs2image on to the Nandflash from uboot by the command nandwrite,yaffs.Though the command works well ,the data is not added to Nand flash.Iam using uboot-1.1.6 version and kernel-2.6.28.6.Please Can you suggest on it. WithRegards V.Balaji ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH]powerpc/8xxx:Add MPH controller support in USB device-tree fixup
Hi Marek, The final version of this patch is under review, didn't get any more comments, waiting for its acceptance... http://patchwork.ozlabs.org/patch/140557/ Thanks and Regards, Ramneek -Original Message- From: Marek Vasut [mailto:ma...@denx.de] Sent: Monday, February 27, 2012 4:42 AM To: u-boot@lists.denx.de Cc: Mehresh Ramneek-B31383 Subject: Re: [U-Boot] [PATCH]powerpc/8xxx:Add MPH controller support in USB device-tree fixup Add support for fixing usb mode and phy type for MPH(Multi Port Host) USB controllers in device-tree nodes. Required for socs like P3060, P5020, etc having MPH USB controller. Signed-off-by: Ramneek Mehresh ramneek.mehr...@freescale.com --- arch/powerpc/cpu/mpc8xxx/fdt.c | 46 ++-- include/fdt_support.h | 4 +- 2 files changed, 32 insertions(+), 18 Hi, what's the status of this patch/patchset? Thanks M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Facing the problem with yaffs2 from uboot
Hi Viswanadhula, On Mon, Feb 27, 2012 at 3:37 PM, VISWANADHULA BALAJI vbalaj...@gmail.com wrote: Hi, Iam using SMDK6410 arm11 board having the samsung Nandflash with a capacity of 1Gb.Iam not able to load the yaffs2image on to the Nandflash from uboot by the command nandwrite,yaffs.Though the command works well ,the data is not added to Nand flash.Iam using uboot-1.1.6 version and I'm sorry to say, but you're not likely to get much of a response with such an ancient version of U-Boot - Try latest release (2011.12) and if the problem persists, re-post your question kernel-2.6.28.6.Please Can you suggest on it. Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 8/8] sandbox: Add basic command line parsing
Hi Mike,
On Sun, Feb 26, 2012 at 8:42 PM, Mike Frysinger vap...@gentoo.org wrote:
On Sunday 26 February 2012 23:33:25 Simon Glass wrote:
On Sun, Feb 26, 2012 at 8:08 PM, Mike Frysinger wrote:
On Sunday 26 February 2012 21:50:32 Simon Glass wrote:
Given your efforts on the cmdline parsing I'm beginning to think we
should perhaps add os_printf() and os_printf_stderr() and provide an
explicit interface. It might only be useful prior to main(), then
again I'm not so sure.
i've been pondering this. on one hand, we want to parse flags as soon as
possible, but on the other, we want to be able to not have to worry about
what state the system is in when parsing things. maybe we specially
mark the few flags that we need very early on and parse those, and then
parse the rest once the system is mostly functional ? i can really only
think of one or two flags that we *might* need very early -- namely,
ones that'd select a config or fdt. on the other hand, are there things
that we'd want to change that'd affect everything from console_init_f()
and earlier ?
IMO flags should purely update the initial state and therefore we
don't need the system to be function to parse them. Once the system is
functional, the various bits that are interested can go and look at
the state to get the info they want. IOW I don't think we need to
delay parsing until the system is functional - we just need to take
'action' then.
ok, so for example, i updated my spi flash patch to do:
drivers/mtd/spi/sandbox.c:
static int sb_cmdline_cb_spi_sf(struct sandbox_state *state, const char *arg)
{
unsigned long bus, cs;
const char *spec = sb_spi_parse_spec(arg, bus, cs);
if (!spec)
return 1;
state-spi[bus][cs][0] = sb_sf_ops;
state-spi[bus][cs][1] = spec;
return 0;
}
SB_CMDLINE_OPT(spi_sf, 1, connect a SPI flash: bus:cs:id:file);
sandbox...give me your address and I'll send you a cheque to cover the
bytes so used :-)
and people could do:
./u-boot --spi_sf 0:3:m25p16:./some-file.bin
this would connect the spi flash simulation up to the simulated spi bus 0 on
cs
3 and have it simulate a m25p16 flash with some-file.bin backing it.
if someone were to enter the wrong value for 0:3:m25p16:./some-file.bin, how
do you propose we communicate that ? the existing code can easily signal the
higher parsing logic via return values, but then we'd just get:
failed to parse option: 0:3:m25p16:./some-file.bin
but what exactly did the code not like ? was it the bus # ? the cs # ? the
spi flash id ? the backing file ? if the getopt code has access to printf(),
we can clearly communicate to the user what is going wrong.
Yes I think printf() is useful in getopt, I just would prefer to avoid
using U-Boot's printf. It goes through all the console code, and we
might be running a test that deliberately breaks that, perhaps.
Actually this could be a pretty important thing to sort out - we need
to keep a clear boundary between test code and U-Boot code (as we
discussed over GPIO). Having the test code use U-Boot's printf() is
blurring that.
To your example, if the syntax is correct perhaps, then it got through
initial parsing. If the filename is wrong, or the bus number, then
perhaps there will be a message and failure much later. Perhaps the
initial parsing just does what it can to avoid running past an obvious
syntax error. But we can't really know success until we open the file,
or try the bus.
Regards,
Simon
-mike
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Unable to run scripts with autoscr command
Hi any updates on this? On Sat, Feb 25, 2012 at 6:44 AM, Graeme Russ graeme.r...@gmail.com wrote: Hi Asif, On 02/24/2012 04:43 PM, Asif Sulikeri wrote: Thanks Graeme, replies in-line, Appreciated (after all, that is ML etiquette) On Fri, Feb 24, 2012 at 11:01 AM, Graeme Russ graeme.r...@gmail.com mailto:graeme.r...@gmail.com wrote: Hi Asif, On Fri, Feb 24, 2012 at 4:25 PM, Asif Sulikeri asifiqbal...@gmail.com mailto:asifiqbal...@gmail.com wrote: Hi, any updates on this, this is a blocker for me, and waiting for your suggestions to resolve this issue. On Mon, Feb 20, 2012 at 3:45 PM, Asif Sulikeri asifiqbal...@gmail.com mailto:asifiqbal...@gmail.comwrote: Detlev Zundel dzu at denx.de http://denx.de writes: Appreciate your reply Detlev, please find my replies in-line, what is the DM365-IPNC-1.0.14 version about? I cannot see such a version (or tag) in mainline U-Boot. I'm sorry for the typo that is supposed to be 1.0.1. Don't expect much response if you stay with version 1.0.1 I'm sorry for all the confusion, the u-boot version is actually 1.3.4 and 1.0.1 is added as a suffix for internal use, sorry for that. Am I still not liable to get help for this version(1.3.4) of u-boot? Nope - 1.3.4 is 3.5 years old - more than half of the commits in mainline have been applied since then. On the other hand, davinci_dm365evm is a supported configuration in mainline, so why not try current code. This way we would be in a much better position to help you. I'll consider the suggestion, but since I've spent considerable time on this, want to make sure where actually the problem lies. Have you tried the suggestion of using the current mainline code? If the problem still exists in latest mainline, you stand a fair chance that we'll make an effort to help you out :) :) Thats definitely not the way you bail me out ;), jokes apart, I did try using u-boot-2010.06 but the u-boot binary generated is bulky 252KB, as compared the usual 150KB, this leads to another blocker as the UBL(User Boot Loader) is now unable to load this bulky u-boot into RAM(or may be some other issue), and gets stuck as below: Well 2010.06 is also very old - the latest release is 2011.12 And the increase of 100kB is massive - are you sure you are compiling with the same set of options defined in the board config file? If you are sure, then it would be interesting to find out what has caused it. Could you try some intermediate releases (2008.10 is the next release after 1.3.4) DM36x initialization passed! TI UBL Base Version: 1.50 Boot Loader BootMode = NAND Starting NAND Copy... Valid magicnum, 0xA1ACED66, found in block 0x0008. Boot Mode Task Completed IPNC UBL Version: 1.1.0 Platform: DM365 Jumping to entry point at 0x8108 and there's no response whatsoever after this. what might be the issue now? This is outside my knowledge - I've Cc'd the davinci_dm365evm (Sandeep Paulraj), maybe he can provide some pointers... Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Unable to run scripts with autoscr command
Hi, On Feb 27, 2012 4:57 PM, Asif Sulikeri asifiqbal...@gmail.com wrote: Hi any updates on this? Have you looked into any of my other suggestions? Regards, Graeme On Sat, Feb 25, 2012 at 6:44 AM, Graeme Russ graeme.r...@gmail.com wrote: Hi Asif, On 02/24/2012 04:43 PM, Asif Sulikeri wrote: Thanks Graeme, replies in-line, Appreciated (after all, that is ML etiquette) On Fri, Feb 24, 2012 at 11:01 AM, Graeme Russ graeme.r...@gmail.com mailto:graeme.r...@gmail.com wrote: Hi Asif, On Fri, Feb 24, 2012 at 4:25 PM, Asif Sulikeri asifiqbal...@gmail.com mailto:asifiqbal...@gmail.com wrote: Hi, any updates on this, this is a blocker for me, and waiting for your suggestions to resolve this issue. On Mon, Feb 20, 2012 at 3:45 PM, Asif Sulikeri asifiqbal...@gmail.com mailto:asifiqbal...@gmail.comwrote: Detlev Zundel dzu at denx.de http://denx.de writes: Appreciate your reply Detlev, please find my replies in-line, what is the DM365-IPNC-1.0.14 version about? I cannot see such a version (or tag) in mainline U-Boot. I'm sorry for the typo that is supposed to be 1.0.1. Don't expect much response if you stay with version 1.0.1 I'm sorry for all the confusion, the u-boot version is actually 1.3.4 and 1.0.1 is added as a suffix for internal use, sorry for that. Am I still not liable to get help for this version(1.3.4) of u-boot? Nope - 1.3.4 is 3.5 years old - more than half of the commits in mainline have been applied since then. On the other hand, davinci_dm365evm is a supported configuration in mainline, so why not try current code. This way we would be in a much better position to help you. I'll consider the suggestion, but since I've spent considerable time on this, want to make sure where actually the problem lies. Have you tried the suggestion of using the current mainline code? If the problem still exists in latest mainline, you stand a fair chance that we'll make an effort to help you out :) :) Thats definitely not the way you bail me out ;), jokes apart, I did try using u-boot-2010.06 but the u-boot binary generated is bulky 252KB, as compared the usual 150KB, this leads to another blocker as the UBL(User Boot Loader) is now unable to load this bulky u-boot into RAM(or may be some other issue), and gets stuck as below: Well 2010.06 is also very old - the latest release is 2011.12 And the increase of 100kB is massive - are you sure you are compiling with the same set of options defined in the board config file? If you are sure, then it would be interesting to find out what has caused it. Could you try some intermediate releases (2008.10 is the next release after 1.3.4) DM36x initialization passed! TI UBL Base Version: 1.50 Boot Loader BootMode = NAND Starting NAND Copy... Valid magicnum, 0xA1ACED66, found in block 0x0008. Boot Mode Task Completed IPNC UBL Version: 1.1.0 Platform: DM365 Jumping to entry point at 0x8108 and there's no response whatsoever after this. what might be the issue now? This is outside my knowledge - I've Cc'd the davinci_dm365evm (Sandeep Paulraj), maybe he can provide some pointers... Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Unable to run scripts with autoscr command
Hi Graeme, On Mon, Feb 27, 2012 at 11:33 AM, Graeme Russ graeme.r...@gmail.com wrote: Hi, On Feb 27, 2012 4:57 PM, Asif Sulikeri asifiqbal...@gmail.com wrote: Hi any updates on this? Have you looked into any of my other suggestions? Regards, Graeme I'm sorry don't know how I missed out to see the updated mail from you, I thought there was no response at all, sorry though. On Sat, Feb 25, 2012 at 6:44 AM, Graeme Russ graeme.r...@gmail.com wrote: Hi Asif, On 02/24/2012 04:43 PM, Asif Sulikeri wrote: Thanks Graeme, replies in-line, Appreciated (after all, that is ML etiquette) On Fri, Feb 24, 2012 at 11:01 AM, Graeme Russ graeme.r...@gmail.com mailto:graeme.r...@gmail.com wrote: Hi Asif, On Fri, Feb 24, 2012 at 4:25 PM, Asif Sulikeri asifiqbal...@gmail.com mailto:asifiqbal...@gmail.com wrote: Hi, any updates on this, this is a blocker for me, and waiting for your suggestions to resolve this issue. On Mon, Feb 20, 2012 at 3:45 PM, Asif Sulikeri asifiqbal...@gmail.com mailto:asifiqbal...@gmail.comwrote: Detlev Zundel dzu at denx.de http://denx.de writes: Appreciate your reply Detlev, please find my replies in-line, what is the DM365-IPNC-1.0.14 version about? I cannot see such a version (or tag) in mainline U-Boot. I'm sorry for the typo that is supposed to be 1.0.1. Don't expect much response if you stay with version 1.0.1 I'm sorry for all the confusion, the u-boot version is actually 1.3.4 and 1.0.1 is added as a suffix for internal use, sorry for that. Am I still not liable to get help for this version(1.3.4) of u-boot? Nope - 1.3.4 is 3.5 years old - more than half of the commits in mainline have been applied since then. Hmmm, seems to be I'm on my own if I have decided to resolve this particular issue on this particular version. On the other hand, davinci_dm365evm is a supported configuration in mainline, so why not try current code. This way we would be in a much better position to help you. I'll consider the suggestion, but since I've spent considerable time on this, want to make sure where actually the problem lies. Have you tried the suggestion of using the current mainline code? If the problem still exists in latest mainline, you stand a fair chance that we'll make an effort to help you out :) :) Thats definitely not the way you bail me out ;), jokes apart, I did try using u-boot-2010.06 but the u-boot binary generated is bulky 252KB, as compared the usual 150KB, this leads to another blocker as the UBL(User Boot Loader) is now unable to load this bulky u-boot into RAM(or may be some other issue), and gets stuck as below: Well 2010.06 is also very old - the latest release is 2011.12 And the increase of 100kB is massive - are you sure you are compiling with the same set of options defined in the board config file? If you are sure, then it would be interesting to find out what has caused it. I am compiling with the default options, with no additional changes made to the conf file, the 1.3.4 version used to give me 150kB binary as compared to the 252kB binary generated by the 2010.06 version. Could you try some intermediate releases (2008.10 is the next release after 1.3.4) I would definitely give it a try. I want to resolve this with whatever it takes. :) DM36x initialization passed! TI UBL Base Version: 1.50 Boot Loader BootMode = NAND Starting NAND Copy... Valid magicnum, 0xA1ACED66, found in block 0x0008. Boot Mode Task Completed IPNC UBL Version: 1.1.0 Platform: DM365 Jumping to entry point at 0x8108 and there's no response whatsoever after this. what might be the issue now? This is outside my knowledge - I've Cc'd the davinci_dm365evm (Sandeep Paulraj), maybe he can provide some pointers... Thanks for all the help, definitely appreciate your support and the early help. Regards, Graeme Regards, Asif ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/4] Clean up ehci-omap and extend support for omap3/4 socs
Hi Marek, On Mon, Feb 27, 2012 at 4:43 AM, Marek Vasut ma...@denx.de wrote: From: Govindraj.R govindraj.r...@ti.com Clean up ehci-omap added and make it generic to extend support for omap4 socs. Add ehci support for panda board. Patch series depends on below patch: http://patchwork.ozlabs.org/patch/130952/ Patch series based commit id: 9a4209869bd2c37affd931d627b3c3e72952 This patch series long with above dependent patch is avialable at: git://gitorious.org/denx_u-boot/denx_uboot_omap.git v2_ehci_omap4 Fatls, ping and tftp was tested with this patch series. Test log for Panda available here: http://pastebin.pandaboard.org/index.php/view/55361716 Test log for Beagle-XM available here: http://pastebin.pandaboard.org/index.php/view/98437825 Hi, what's the status of this patch/patchset? It's merged. ubnuser@ula0131859:~/clones/mainline_loaders/u-boot$ gls dd54d31..49be71c 49be71c OMAP4: ehci-omap: enable ehci-omap for panda boards (2 weeks ago) 860004c OMAP4: clock-common: Move the usb dppl configuration to new func (2 weeks ago) 95f8791 OMAP3+: Clock: Adding ehci clock enabling (2 weeks ago) 43b6239 ehci-omap: Clean up added ehci-omap.c (2 weeks ago) 29321c0 ehci-omap: driver for EHCI host on OMAP3 (2 weeks ago) 928c4bd usb: ulpi: Add omap-ulpi-view port support (2 weeks ago) 3e6e809 usb: ulpi: Extend the existing ulpi framework. (2 weeks ago) -- Thanks, Govindraj.R ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Unable to run scripts with autoscr command
Hi Asif, On 02/27/2012 05:26 PM, Asif Sulikeri wrote: And the increase of 100kB is massive - are you sure you are compiling with the same set of options defined in the board config file? If you are sure, then it would be interesting to find out what has caused it. I am compiling with the default options, with no additional changes made to the conf file, the 1.3.4 version used to give me 150kB binary as compared to the 252kB binary generated by the 2010.06 version. Ah - Looks like some more options have crept into the default configuration - Can you send the two board config files (as inline text, not attachments) so I can compare? Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: omap3: temporary disable USB on TAM3517 boards
On 02/27/12 01:10, Marek Vasut wrote: The TAM3517 boards require a patch for EHCI OMAP that does not yet find a way to mainline. The patch disables temporary USB until EHCI OMAP will be supported. Signed-off-by: Stefano Babic sba...@denx.de Cc: Tom Rini tom.r...@gmail.com Cc: Albert Aribaud albert.u.b...@aribaud.net --- include/configs/tam3517-common.h |7 +-- 1 files changed, 5 insertions(+), 2 deletions(-) Hi, what's the status of this patch/patchset? Superseded by: 8c589d6f (OMAP3: TAM3517: update ehci interface) -- Regards, Igor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [OMAP3] Pass timings structure pointer to board_get_mem_timings()
Hi Peter, Good work! Thanks. On 02/26/12 17:30, Peter Barada wrote: Instead of passing individual registers by value to board_get_mem_timings, pass a board_mem_timings structure pointer for the board files to fill in. Pass same structure pointer to write_sdrc_timings. This saves about 90 bytes of space in SPL. Signed-off-by: Peter Barada peter.bar...@logicpd.com Acked-by: Igor Grinberg grinb...@compulab.co.il -- Regards, Igor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] USB:host: Attribute packed removed from usb structures
On 2/25/2012 3:42 PM, Albert ARIBAUD wrote: Hi Amit, Hello Albert, Le 24/02/2012 12:58, Amit Virdi a écrit : From: Vipin Kumarvipin.ku...@st.com Packed attribute is forcing a bytewise write on device registers, there by, resulting in a misbehavior on gcc-4.4.1. Reverting the structures to non-packed If (just asking, not asserting) the issue is caused by fields being u8 where u8 access is not possible, then should you not make the fields u16 / u32 according to access requirements? The problem is not with the fields being of a different width. AFAIK, the packed attribute changes the generated code to access even the word field elements in a byte by byte manner Infact, there is a discussion on lkml that I can point https://lkml.org/lkml/2011/4/27/278 It seems that the discussion did not lead to a conclusion but it was sensible (at least for ARM) to remove the packed attribute from this structure Regards Vipin Amicalement, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
