[U-Boot] [PATCH] coldfire: cpu5282: increase malloc space to fix crash on start u-boot
From: Jens Scharsig (BuS Elektronik) e...@bus-elektronik.de The malloc space is to small to boot, the current uboot 2013.10-rcX, This will fix the startup problems by increasing the mallog space to 4MiB. Signed-off-by: Jens Scharsig (BuS Elektronik) e...@bus-elektronik.de --- include/configs/eb_cpu5282.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/eb_cpu5282.h b/include/configs/eb_cpu5282.h index 08ba883..e49b2b8 100644 --- a/include/configs/eb_cpu5282.h +++ b/include/configs/eb_cpu5282.h @@ -153,7 +153,7 @@ #defineCONFIG_SYS_SDRAM_SIZE CONFIG_SYS_SDRAM_SIZE0 #define CONFIG_SYS_MONITOR_LEN 0x2 -#define CONFIG_SYS_MALLOC_LEN (256 10) +#define CONFIG_SYS_MALLOC_LEN (4 * 1024 * 1024) #define CONFIG_SYS_BOOTPARAMS_LEN 64*1024 /* -- 1.8.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] mx35pdk: Fix error handling in board_late_init()
On 20/09/2013 21:30, Fabio Estevam wrote:
From: Fabio Estevam fabio.este...@freescale.com
If smc911x_initialize() fails we should return the error immediately.
While at it, also check the error from cpu_eth_init().
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
board/freescale/mx35pdk/mx35pdk.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/board/freescale/mx35pdk/mx35pdk.c
b/board/freescale/mx35pdk/mx35pdk.c
index 427c83a..9fabef5 100644
--- a/board/freescale/mx35pdk/mx35pdk.c
+++ b/board/freescale/mx35pdk/mx35pdk.c
@@ -251,14 +251,12 @@ int board_late_init(void)
int board_eth_init(bd_t *bis)
{
- int rc = -ENODEV;
#if defined(CONFIG_SMC911X)
- rc = smc911x_initialize(0, CONFIG_SMC911X_BASE);
+ int rc = smc911x_initialize(0, CONFIG_SMC911X_BASE);
+ if (rc)
+ return rc;
#endif
-
- cpu_eth_init(bis);
-
- return rc;
+ return cpu_eth_init(bis);
}
#if defined(CONFIG_FSL_ESDHC)
Acked-by: Stefano Babic sba...@denx.de
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] ARM: tegra: support SKU b1 of Tegra30
On Fri, 20 Sep 2013 10:57:42 -0700 Tom Warren twar...@nvidia.com wrote: Alban, Were you going to do a V2 of this patchset? I expected to, but up to now there was no concrete change request. Should I split the PMU stuff to its own mini driver, or is it acceptable as is for now? Alban ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Change maintainer for Avionic Design boards
I no longer work for Avionic Design and don't have access to hardware, so I'll pass on maintainership to Alban. Acked-by: Alban Bedel alban.be...@avionic-design.de Signed-off-by: Thierry Reding tred...@nvidia.com --- Hi Tom, I assume this is something you'd want to take through the Tegra tree? Thierry boards.cfg | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/boards.cfg b/boards.cfg index dbd8479..dfd874b 100644 --- a/boards.cfg +++ b/boards.cfg @@ -342,9 +342,9 @@ Active arm armv7 vf610 freescale vf610twr Active arm armv7 zynqxilinx zynq zynq - Michal Simek mon...@monstr.eu Active arm armv7 zynqxilinx zynq zynq_dcc zynq:ZYNQ_DCC Michal Simek mon...@monstr.eu Active arm armv7:arm720t tegra114nvidia dalmore dalmore - Tom Warren twar...@nvidia.com -Active arm armv7:arm720t tegra20 avionic-design medcom-wide medcom-wide - Thierry Reding thierry.red...@avionic-design.de -Active arm armv7:arm720t tegra20 avionic-design plutux plutux - Thierry Reding thierry.red...@avionic-design.de -Active arm armv7:arm720t tegra20 avionic-design tec tec - Thierry Reding thierry.red...@avionic-design.de +Active arm armv7:arm720t tegra20 avionic-design medcom-wide medcom-wide - Alban Bedel alban.be...@avionic-design.de +Active arm armv7:arm720t tegra20 avionic-design plutux plutux - Alban Bedel alban.be...@avionic-design.de +Active arm armv7:arm720t tegra20 avionic-design tec tec - Alban Bedel alban.be...@avionic-design.de Active arm armv7:arm720t tegra20 compal paz00 paz00- Tom Warren twar...@nvidia.com:Stephen Warren swar...@nvidia.com Active arm armv7:arm720t tegra20 compulabtrimslice trimslice- Tom Warren twar...@nvidia.com:Stephen Warren swar...@nvidia.com Active arm armv7:arm720t tegra20 nvidia harmony harmony - Tom Warren twar...@nvidia.com -- 1.8.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot PPC405EX with DDR2 DIMM
Hi Steve,
On 18.09.2013 13:26, Steve Miller wrote:
I have inherited a design using the PPC405EX that was based on the
Kilauea reference design. One of the changes was Kilauea uses on-board
DDR2 DRAM ICs and this design uses DDR2 DIMMs. The u-boot is working,
except only 256MB of RAM is available instead of the 1GIG that the
module supports. This working 256MB matches the memory that the
Kilauea had. In looking into this, the CONFIG_SPD_EEPROM was undefined,
as that was what was appropriate for the Kilauea. I defined this but
got lots of compiler errors. So I did the following:
1.Updated the eldk to 5.4
2. Downloaded the latest u-boot source code I could find.
(Version 2013)
Good. Using the latest version is always a good thing to do.
I still get compiler errors. The first error is in 40x_spd_sdram.cI
do not believe it should be attempting to compile this as it appears to
be SPD setting for SDRAM modules and not DDR2 modules. I added another
check to line 50 of 40x_spd_sdram.c to skip that file if it is a 405EX.
This of course, eliminated those compiler errors.
Yes, this file should not be used on 405ex. Its for the older 405
variants with SDRAM and not DDR2.
Next place is has trouble is 44x_spd_ddr2.c In line 460 it cannot find
SDR0_SRST0_DMC for example. Another example is line 821, it cannot find
SDR0_DDR0. In searching the PPC405EX datasheet, I do not find that
these registers exist in this part.I believe it is supposed to
compile this file, as the file has specific references to the 405EX.
However, I do not know what I am missing to get this to compile for that
processor.
Questions:
1.Has anyone compiled u-boot for the 405EX using a DIMM, aka an
SPD defined RAM?
I don't remember one. Not 100% sure, since 4xx development is quite dead
since a few years.
2. Is there something obvious that I need to place in the config
to get this to work? I compared this config to another product that
uses a 460SX. I did not see anything special that the 460SX was
configuring to make the system work with the SPD of the DIMM.
IIRC, then 405EX uses the same DDR2 controller as for example 460EX
does. Most likely a different version of this IP core though. Perhaps
with some extensions missing because of 460EX supporting bigger address
spaces. So you should take the canyonlands defines as a reference:
#define CONFIG_SPD_EEPROM
#define SPD_EEPROM_ADDRESS {0x50, 0x51}
You need to adjust the EEPROM addresses to your board of course. And its
very likely that you need to change/fix the 44x_spd_ddr2.c code to
really support the 405EX.
Best regards,
Stefan
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: off...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mx6: Fix use of improper value in enable_ipu_clock
The value MXC_CCM_CCGR3_IPU1_IPU_DI0_OFFSET that was used to initialize the CCGR3 register caused an undefined value for CG0. Signed-off-by: Pierre Aubert p.aub...@staubli.com CC: Stefano Babic sba...@denx.de --- arch/arm/cpu/armv7/mx6/clock.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c index 7efb0d2..0f7bcbc 100644 --- a/arch/arm/cpu/armv7/mx6/clock.c +++ b/arch/arm/cpu/armv7/mx6/clock.c @@ -457,7 +457,7 @@ void enable_ipu_clock(void) struct mxc_ccm_reg *mxc_ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR; int reg; reg = readl(mxc_ccm-CCGR3); - reg |= MXC_CCM_CCGR3_IPU1_IPU_DI0_OFFSET; + reg |= MXC_CCM_CCGR3_IPU1_IPU_MASK; writel(reg, mxc_ccm-CCGR3); } /***/ -- 1.7.6.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Prevent a U-Boot crash on Wandboard
On Sun, Sep 22, 2013 at 10:21 PM, Steven Falco stevenfa...@gmail.com wrote: Prevent a crash when PXE boot calls do_bootm with a vmlinuz formatted image. In this case, there will be a null cmdtp pointer, and we must not dereference it. Signed-off-by: Steven A. Falco stevenfa...@gmail.com --- Acked-by: Otavio Salvador ota...@ossystems.com.br Tom, will you pick this or should it be Cced to someone specific? -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot PPC405EX with DDR2 DIMM
Just wanted to tell the group that I am abandoning using the SPD data on PPC405EX. As I stated earlier, I inherited this design from others. As I dug deeper into the HW, I found that a X64 module was used on a processor that only has a X32 wide bus. Apparently, they could get modules for less than 1/2 the DRAM cost as 50% of the memory is unused. This is most likely why no one is currently using DIMMs on the 405EX. There are no commercially available X32 DIMMs in DDR2. My thanks to Stefan and others for their suggestions.I believe this design I am working on will be limited to only one DIMM type. Therefore, I am just going to assign the parameters in the header file for this board. Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] zynq: Use arch_cpu_init() instead of lowlevel_init()
Hi Michal,
On Thu, 22 Aug 2013 14:52:02 +0200, Michal Simek
michal.si...@xilinx.com wrote:
Zynq lowlevel_init() was implemented in C but stack
pointer is setup after function call in _main().
Move architecture setup to arch_cpu_init() which is call
as the first function in board_init_f() which
already have correct stack pointer.
Reported-by: Sven Schwermer sven.schwer...@tuhh.de
Signed-off-by: Michal Simek michal.si...@xilinx.com
---
I can't see any problem to call zynq setup a little
bit later. There is already expectation that u-boot
runs from DDR.
Moving lowlevel_init from C to ASM is possible but
I will have to introduce new macros with hardcoded
values. Using structures is much nicer.
---
arch/arm/cpu/armv7/zynq/cpu.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/cpu/armv7/zynq/cpu.c b/arch/arm/cpu/armv7/zynq/cpu.c
index 4367d1a..8846f30 100644
--- a/arch/arm/cpu/armv7/zynq/cpu.c
+++ b/arch/arm/cpu/armv7/zynq/cpu.c
@@ -11,6 +11,10 @@
void lowlevel_init(void)
{
+}
I'd rather you deleted lowlevel_init() as a C function with this
name should not exist.
+int arch_cpu_init(void)
+{
zynq_slcr_unlock();
/* remap DDR to zero, FILTERSTART */
writel(0, scu_base-filter_start);
@@ -31,6 +35,8 @@ void lowlevel_init(void)
writel(0xC, slcr_base-ddr_urgent);
zynq_slcr_lock();
+
+ return 0;
}
void reset_cpu(ulong addr)
--
1.8.2.3
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 02/10] USB: xHCI: Add stack support for xHCI
Marek and Vivek On 09/14/2013 03:32 AM, Vivek Gautam wrote: This adds stack layer for eXtensible Host Controller Interface which facilitates use of USB 3.0 in host mode. Adapting xHCI host controller driver in linux-kernel by Sarah Sharp to needs in u-boot. Initial porting from Linux kernel version 3.4, with following top commit history of drivers/usb/host/xhci* : cf84055 xHCI: Cleanup isoc transfer ring when TD length mismatch found snip I am checking with Sarah Sharp on the stability of the xHCI stack in 3.4. I talked to her @ LPC and she eluded that 3.8 was a stable stack. But I asked for her comments off line. I will give her a couple days to respond. Otherwise I am rebasing my code on top of these and testing this out. Sorry for the delay on review and comment but I was travelling last week and did not have the oppourtunity to review or test. Dan -- -- Dan Murphy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: prevent using movt/movw address loads
Hi Jeroen, On Sat, 24 Aug 2013 13:55:38 +0200, Jeroen Hofstee jer...@myspectrum.nl wrote: The movt/movw instruction can be used to hardcode an memory location in the instruction itself. The linker starts complaining about this if the compiler decides to do so: relocation R_ARM_MOVW_ABS_NC against `a local symbol' can not be used and it is not support by U-boot as well. Prevent their use by requiring word relocations. This allows u-boot to be build at other optimalization levels then -Os. Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl Cc: tiger...@viatech.com.cn Cc: Albert ARIBAUD albert.u.b...@aribaud.net --- arch/arm/config.mk | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/arm/config.mk b/arch/arm/config.mk index 540a119..2277c82 100644 --- a/arch/arm/config.mk +++ b/arch/arm/config.mk @@ -94,7 +94,11 @@ PLATFORM_RELFLAGS += -fno-optimize-sibling-calls endif endif -# check that only R_ARM_RELATIVE relocations are generated ifneq ($(CONFIG_SPL_BUILD),y) -ALL-y+= checkarmreloc +# Check that only R_ARM_RELATIVE relocations are generated. +ALL-y += checkarmreloc +# The movt / movw can hardcode 16 bit parts of the addresses in the +# instruction. Relocation is not supported for that case, so disable +# such usage by requiring word relocations. +PLATFORM_CPPFLAGS += $(call cc-option, -mword-relocations) endif Applied as a bugfix to u-boot-arm/master, thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC] i2c_reloc_fixup fails on m68k
Hello,
I have a access violation problem with i2c_reloc_fixup on coldfire
m68k systems.
I found out, the i2c_reloc_fixup tries to relocate the adapter itself,
but at this time i2c_adap_p is already relocated.
Can anybody confirm this?
I think also m68k, backfin and nds32 systems are affected
regards
Jens
---
diff --git a/drivers/i2c/i2c_core.c b/drivers/i2c/i2c_core.c
index d1072e8..bb5d4db 100644
--- a/drivers/i2c/i2c_core.c
+++ b/drivers/i2c/i2c_core.c
@@ -53,10 +53,6 @@ void i2c_reloc_fixup(void)
return;
for (i = 0; i max; i++) {
- /* adapter itself */
- addr = (unsigned long)i2c_adap_p;
- addr += gd-reloc_off;
- i2c_adap_p = (struct i2c_adapter *)addr;
/* i2c_init() */
addr = (unsigned long)i2c_adap_p-init;
addr += gd-reloc_off;
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] zynq: Use arch_cpu_init() instead of lowlevel_init()
On 09/23/2013 02:31 PM, Albert ARIBAUD wrote:
Hi Michal,
On Thu, 22 Aug 2013 14:52:02 +0200, Michal Simek
michal.si...@xilinx.com wrote:
Zynq lowlevel_init() was implemented in C but stack
pointer is setup after function call in _main().
Move architecture setup to arch_cpu_init() which is call
as the first function in board_init_f() which
already have correct stack pointer.
Reported-by: Sven Schwermer sven.schwer...@tuhh.de
Signed-off-by: Michal Simek michal.si...@xilinx.com
---
I can't see any problem to call zynq setup a little
bit later. There is already expectation that u-boot
runs from DDR.
Moving lowlevel_init from C to ASM is possible but
I will have to introduce new macros with hardcoded
values. Using structures is much nicer.
---
arch/arm/cpu/armv7/zynq/cpu.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/cpu/armv7/zynq/cpu.c b/arch/arm/cpu/armv7/zynq/cpu.c
index 4367d1a..8846f30 100644
--- a/arch/arm/cpu/armv7/zynq/cpu.c
+++ b/arch/arm/cpu/armv7/zynq/cpu.c
@@ -11,6 +11,10 @@
void lowlevel_init(void)
{
+}
I'd rather you deleted lowlevel_init() as a C function with this
name should not exist.
Ok. Do you want me to create almost empty low_level.S or just use
arch/arm/cpu/arvm7/lowlevel_init.S and define empty s_init()?
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP - KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
signature.asc
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: zynq: Fix timer loadaddress
Hi Michal, On Wed, 28 Aug 2013 07:36:31 +0200, Michal Simek michal.si...@xilinx.com wrote: Reload address was written to the counter register instead of load register. The problem happens when timer expires but never reload to ~0UL (it is downcount timer). Reported-by: Stephen MacMahon steph...@xilinx.com Signed-off-by: Michal Simek michal.si...@xilinx.com --- arch/arm/cpu/armv7/zynq/timer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/cpu/armv7/zynq/timer.c b/arch/arm/cpu/armv7/zynq/timer.c index 0133565..3b8d949 100644 --- a/arch/arm/cpu/armv7/zynq/timer.c +++ b/arch/arm/cpu/armv7/zynq/timer.c @@ -57,7 +57,7 @@ int timer_init(void) SCUTIMER_CONTROL_ENABLE_MASK; /* Load the timer counter register */ - writel(0x, timer_base-counter); + writel(0x, timer_base-load); /* * Start the A9Timer device -- 1.8.2.3 Applied bugfix to u-boot-arm/master, thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] zynq: Use arch_cpu_init() instead of lowlevel_init()
Hi Michal,
On Mon, 23 Sep 2013 16:19:52 +0200, Michal Simek mon...@monstr.eu
wrote:
On 09/23/2013 02:31 PM, Albert ARIBAUD wrote:
Hi Michal,
On Thu, 22 Aug 2013 14:52:02 +0200, Michal Simek
michal.si...@xilinx.com wrote:
Zynq lowlevel_init() was implemented in C but stack
pointer is setup after function call in _main().
Move architecture setup to arch_cpu_init() which is call
as the first function in board_init_f() which
already have correct stack pointer.
Reported-by: Sven Schwermer sven.schwer...@tuhh.de
Signed-off-by: Michal Simek michal.si...@xilinx.com
---
I can't see any problem to call zynq setup a little
bit later. There is already expectation that u-boot
runs from DDR.
Moving lowlevel_init from C to ASM is possible but
I will have to introduce new macros with hardcoded
values. Using structures is much nicer.
---
arch/arm/cpu/armv7/zynq/cpu.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/cpu/armv7/zynq/cpu.c b/arch/arm/cpu/armv7/zynq/cpu.c
index 4367d1a..8846f30 100644
--- a/arch/arm/cpu/armv7/zynq/cpu.c
+++ b/arch/arm/cpu/armv7/zynq/cpu.c
@@ -11,6 +11,10 @@
void lowlevel_init(void)
{
+}
I'd rather you deleted lowlevel_init() as a C function with this
name should not exist.
Ok. Do you want me to create almost empty low_level.S or just use
arch/arm/cpu/arvm7/lowlevel_init.S and define empty s_init()?
Urgh. I realize removing the C function would give you more work than
simply keeping it empty until the whole s_init() mess is cleaned up. :(
I'll take your change as-is, sorry for the noise.
Thanks,
Michal
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] i2c:zynq: I2C multi-bus support on Zynq
See below... (My replies are tagged with [MRB:].)
Michael Burr // Software Engineer II
Logic PD
T // 612.436.7273
NOTICE: Important disclaimers and limitations apply to this email.
Please see this web page for our disclaimers and limitations:
http://logicpd.com/email-disclaimer/
-Original Message-
From: Heiko Schocher [mailto:h...@denx.de]
Sent: Sunday, September 22, 2013 2:33 AM
To: Michael Burr
Cc: u-boot@lists.denx.de; Michal Simek
Subject: Re: [PATCH] i2c:zynq: I2C multi-bus support on Zynq
Hello Michael,
Am 20.09.2013 22:40, schrieb Michael Burr:
Changes:
'zynq_i2c.c':
Adapted driver for compliance with new I2C driver model
(CONFIG_SYS_I2C).
Support for 0-length register address in 'i2c_write', 'i2c_read'.
'i2c.h', 'i2c_core.c':
Support for Texas Instruments PCA9548 bus multiplexer.
Your commit message implements, that your patch contains 3 independent changes
... it would be better to seperate your patch in 3 pieces ... so if your patch
introduces a problem, it is better to identify, which part it introduced ...
Can you do this easy?
[MRB:] I will give it a try...
Except of this, I have only one minor Codingstyle comment
Tested:
Xilinx ZC702 eval board (single bus master 'I2C0' with multiplexer
PCA9548).
Write and read registers with addresses of length 0 and 1.
Note:
Mainline code does not work out of the box on ZC702 at this time; ad
hoc adaptations based on 'u-boot-xlnx' repository were needed in order
to test on this board. (Those adapatations are not included with this
patch.)
? Where can I find this repository?
[MRB:] At the following address. (I believe Michal Simek is the person who
manages this.)
http://github.com/Xilinx/u-boot-xlnx/
Signed-off-by: Michael Burrmichael.b...@logicpd.com
Cc: Heiko Schocherh...@denx.de
Cc: Michal Simekmon...@monstr.eu
---
drivers/i2c/i2c_core.c |5 ++
drivers/i2c/zynq_i2c.c | 148
+---
include/i2c.h |3 +
3 files changed, 97 insertions(+), 59 deletions(-)
[...]
diff --git a/include/i2c.h b/include/i2c.h index 8fd17d1..683affe
100644
--- a/include/i2c.h
+++ b/include/i2c.h
@@ -40,6 +40,7 @@
#define CONFIG_SYS_I2C_MAX_HOPS 0
#define CONFIG_SYS_NUM_I2C_BUSESll_entry_count(struct i2c_adapter, i2c)
#else
+
Change not needed!
[MRB:] Oops. I'll get rid of that...
/* we use i2c muxes */
#undef CONFIG_SYS_I2C_DIRECT_BUS
#endif
@@ -135,6 +136,8 @@ extern struct i2c_bus_hosei2c_bus[];
#define I2C_MUX_PCA9544 {I2C_MUX_PCA9544_ID, PCA9544A}
#define I2C_MUX_PCA9547_ID 4
#define I2C_MUX_PCA9547 {I2C_MUX_PCA9547_ID, PCA9547A}
+#define I2C_MUX_PCA9548_ID 5
+#define I2C_MUX_PCA9548 {I2C_MUX_PCA9548_ID, PCA9548}
#endif
#ifndef I2C_SOFT_DECLARATIONS
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 02/10] USB: xHCI: Add stack support for xHCI
Dear Dan Murphy, Marek and Vivek On 09/14/2013 03:32 AM, Vivek Gautam wrote: This adds stack layer for eXtensible Host Controller Interface which facilitates use of USB 3.0 in host mode. Adapting xHCI host controller driver in linux-kernel by Sarah Sharp to needs in u-boot. Initial porting from Linux kernel version 3.4, with following top commit history of drivers/usb/host/xhci* : cf84055 xHCI: Cleanup isoc transfer ring when TD length mismatch found snip I am checking with Sarah Sharp on the stability of the xHCI stack in 3.4. I talked to her @ LPC and she eluded that 3.8 was a stable stack. But I asked for her comments off line. I will give her a couple days to respond. Otherwise I am rebasing my code on top of these and testing this out. Sorry for the delay on review and comment but I was travelling last week and did not have the oppourtunity to review or test. Thanks. Let's see where this goes. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] zynq: Use arch_cpu_init() instead of lowlevel_init()
On 09/23/2013 04:37 PM, Albert ARIBAUD wrote:
Hi Michal,
On Mon, 23 Sep 2013 16:19:52 +0200, Michal Simek mon...@monstr.eu
wrote:
On 09/23/2013 02:31 PM, Albert ARIBAUD wrote:
Hi Michal,
On Thu, 22 Aug 2013 14:52:02 +0200, Michal Simek
michal.si...@xilinx.com wrote:
Zynq lowlevel_init() was implemented in C but stack
pointer is setup after function call in _main().
Move architecture setup to arch_cpu_init() which is call
as the first function in board_init_f() which
already have correct stack pointer.
Reported-by: Sven Schwermer sven.schwer...@tuhh.de
Signed-off-by: Michal Simek michal.si...@xilinx.com
---
I can't see any problem to call zynq setup a little
bit later. There is already expectation that u-boot
runs from DDR.
Moving lowlevel_init from C to ASM is possible but
I will have to introduce new macros with hardcoded
values. Using structures is much nicer.
---
arch/arm/cpu/armv7/zynq/cpu.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/cpu/armv7/zynq/cpu.c b/arch/arm/cpu/armv7/zynq/cpu.c
index 4367d1a..8846f30 100644
--- a/arch/arm/cpu/armv7/zynq/cpu.c
+++ b/arch/arm/cpu/armv7/zynq/cpu.c
@@ -11,6 +11,10 @@
void lowlevel_init(void)
{
+}
I'd rather you deleted lowlevel_init() as a C function with this
name should not exist.
Ok. Do you want me to create almost empty low_level.S or just use
arch/arm/cpu/arvm7/lowlevel_init.S and define empty s_init()?
Urgh. I realize removing the C function would give you more work than
simply keeping it empty until the whole s_init() mess is cleaned up. :(
I'll take your change as-is, sorry for the noise.
No problem with that.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP - KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
signature.asc
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Remove IXP425 boards pdnb3 and scpu
Hi Stefan, On Tue, 10 Sep 2013 17:17:40 +0200, Stefan Roese s...@denx.de wrote: Remove Prodrive pdnb3 board (including the scpu variant) support from mainline. As its unmaintained and not needed any more for quite some time. Signed-off-by: Stefan Roese s...@denx.de Cc: Martijn de Gouw martijn.de.g...@prodrive.nl Cc: Albert Aribaud albert.u.b...@aribaud.net --- MAINTAINERS | 3 - board/prodrive/pdnb3/Makefile | 28 board/prodrive/pdnb3/flash.c | 73 -- board/prodrive/pdnb3/nand.c | 129 - board/prodrive/pdnb3/pdnb3.c | 220 - boards.cfg| 2 - include/configs/pdnb3.h | 322 -- 7 files changed, 777 deletions(-) delete mode 100644 board/prodrive/pdnb3/Makefile delete mode 100644 board/prodrive/pdnb3/flash.c delete mode 100644 board/prodrive/pdnb3/nand.c delete mode 100644 board/prodrive/pdnb3/pdnb3.c delete mode 100644 include/configs/pdnb3.h Patch fails due to boards.cfg change; please rebase on top of current u-boot/master. Also, please also update doc/README.graveyard by adding your board on top and filling in any missing removal dates and commits in the folowing lines. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 00/10] USB: XHCI: Add xHCI host controller stack driver
Dear Vivek Gautam, + Marek, Dan, Julius, Simon and Vikas for this cover patch ;-) [...] Thanks, I have the patches lined up. Just waiting for Dans' talk with Sarah. Maybe we should put her on CC too next time so she can rip us to shreds for our mistakes in the implementation ? :) Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Prevent a U-Boot crash on Wandboard
On Mon, Sep 23, 2013 at 1:11 PM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Then shouldn't the patch subject/summary be print command name only if cmdtp is not NULL rather than the quite uninformative prevent a crash? Yes, I agree that original subject is a bit misleading. When I read it I thought it was a Wandboard related problem. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx6: Fix use of improper value in enable_ipu_clock
On 09/23/2013 04:37 AM, Pierre Aubert wrote: The value MXC_CCM_CCGR3_IPU1_IPU_DI0_OFFSET that was used to initialize the CCGR3 register caused an undefined value for CG0. Signed-off-by: Pierre Aubert p.aub...@staubli.com CC: Stefano Babic sba...@denx.de --- arch/arm/cpu/armv7/mx6/clock.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c index 7efb0d2..0f7bcbc 100644 --- a/arch/arm/cpu/armv7/mx6/clock.c +++ b/arch/arm/cpu/armv7/mx6/clock.c @@ -457,7 +457,7 @@ void enable_ipu_clock(void) struct mxc_ccm_reg *mxc_ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR; int reg; reg = readl(mxc_ccm-CCGR3); - reg |= MXC_CCM_CCGR3_IPU1_IPU_DI0_OFFSET; + reg |= MXC_CCM_CCGR3_IPU1_IPU_MASK; writel(reg, mxc_ccm-CCGR3); } /***/ Acked-by: Eric Nelson eric.nel...@boundarydevices.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: refactor compiler options in config.mk
Hi Masahiro,
On Sat, 7 Sep 2013 17:42:37 +0900, Masahiro Yamada
yamad...@jp.panasonic.com wrote:
Every ARM cpu config.mk (arch/arm/cpu/{CPUDIR}/config.mk) defines:
PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float
So, this patch moves the common compiler options to arch/arm/config.mk.
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---
Note:
This commit keeps arch/arm/cpu/s3c44b0/config.mk untouched.
because arch/arm/cpu/s3c44b0/* is the remainder of dead board
and is expected to deleted soon.
See 'ARM: s3c44b0: remove remainders of dead board' patch
posted by me, Aug 19, 2013.
arch/arm/config.mk |3 ++-
arch/arm/cpu/arm1136/config.mk |1 -
arch/arm/cpu/arm1176/config.mk |1 -
arch/arm/cpu/arm720t/config.mk |2 --
arch/arm/cpu/arm920t/config.mk |2 --
arch/arm/cpu/arm925t/config.mk |2 --
arch/arm/cpu/arm926ejs/config.mk |2 --
arch/arm/cpu/arm946es/config.mk |2 --
arch/arm/cpu/arm_intcm/config.mk |2 --
arch/arm/cpu/armv7/config.mk |1 -
arch/arm/cpu/armv7/rmobile/config.mk |1 -
arch/arm/cpu/ixp/config.mk |2 +-
arch/arm/cpu/pxa/config.mk |2 --
arch/arm/cpu/sa1100/config.mk|2 --
14 files changed, 3 insertions(+), 22 deletions(-)
diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index 540a119..a2f3261 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -16,7 +16,8 @@ endif
endif
LDFLAGS_FINAL += --gc-sections
-PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections
+PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections \
+ -fno-common -ffixed-r8 -msoft-float
# Support generic board on ARM
__HAVE_ARCH_GENERIC_BOARD := y
diff --git a/arch/arm/cpu/arm1136/config.mk b/arch/arm/cpu/arm1136/config.mk
index 1ef6061..b4d396d 100644
--- a/arch/arm/cpu/arm1136/config.mk
+++ b/arch/arm/cpu/arm1136/config.mk
@@ -4,7 +4,6 @@
#
# SPDX-License-Identifier: GPL-2.0+
#
-PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float
# Make ARMv5 to allow more compilers to work, even though its v6.
PLATFORM_CPPFLAGS += -march=armv5
diff --git a/arch/arm/cpu/arm1176/config.mk b/arch/arm/cpu/arm1176/config.mk
index 917da03..f4631cb 100644
--- a/arch/arm/cpu/arm1176/config.mk
+++ b/arch/arm/cpu/arm1176/config.mk
@@ -4,7 +4,6 @@
#
# SPDX-License-Identifier: GPL-2.0+
#
-PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float
# Make ARMv5 to allow more compilers to work, even though its v6.
PLATFORM_CPPFLAGS += -march=armv5t
diff --git a/arch/arm/cpu/arm720t/config.mk b/arch/arm/cpu/arm720t/config.mk
index 56b6280..2581f0a 100644
--- a/arch/arm/cpu/arm720t/config.mk
+++ b/arch/arm/cpu/arm720t/config.mk
@@ -6,8 +6,6 @@
# SPDX-License-Identifier: GPL-2.0+
#
-PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float
-
PLATFORM_CPPFLAGS += -march=armv4 -mtune=arm7tdmi
# =
#
diff --git a/arch/arm/cpu/arm920t/config.mk b/arch/arm/cpu/arm920t/config.mk
index 58fd756..67537dc 100644
--- a/arch/arm/cpu/arm920t/config.mk
+++ b/arch/arm/cpu/arm920t/config.mk
@@ -5,8 +5,6 @@
# SPDX-License-Identifier: GPL-2.0+
#
-PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float
-
PLATFORM_CPPFLAGS += -march=armv4
# =
#
diff --git a/arch/arm/cpu/arm925t/config.mk b/arch/arm/cpu/arm925t/config.mk
index 58fd756..67537dc 100644
--- a/arch/arm/cpu/arm925t/config.mk
+++ b/arch/arm/cpu/arm925t/config.mk
@@ -5,8 +5,6 @@
# SPDX-License-Identifier: GPL-2.0+
#
-PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float
-
PLATFORM_CPPFLAGS += -march=armv4
# =
#
diff --git a/arch/arm/cpu/arm926ejs/config.mk
b/arch/arm/cpu/arm926ejs/config.mk
index 917ff7e..12b0d09 100644
--- a/arch/arm/cpu/arm926ejs/config.mk
+++ b/arch/arm/cpu/arm926ejs/config.mk
@@ -5,8 +5,6 @@
# SPDX-License-Identifier: GPL-2.0+
#
-PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float
-
PLATFORM_CPPFLAGS += -march=armv5te
# =
#
diff --git a/arch/arm/cpu/arm946es/config.mk b/arch/arm/cpu/arm946es/config.mk
index 1e41c11..eb81a57 100644
--- a/arch/arm/cpu/arm946es/config.mk
+++ b/arch/arm/cpu/arm946es/config.mk
@@ -5,8 +5,6 @@
# SPDX-License-Identifier: GPL-2.0+
#
-PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float
-
PLATFORM_CPPFLAGS += -march=armv4
# =
#
diff --git a/arch/arm/cpu/arm_intcm/config.mk
b/arch/arm/cpu/arm_intcm/config.mk
index 1e41c11..eb81a57 100644
--- a/arch/arm/cpu/arm_intcm/config.mk
+++
Re: [U-Boot] [PATCH] Prevent a U-Boot crash on Wandboard
On Mon, Sep 23, 2013 at 01:21:34PM -0300, Fabio Estevam wrote: On Mon, Sep 23, 2013 at 1:11 PM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Then shouldn't the patch subject/summary be print command name only if cmdtp is not NULL rather than the quite uninformative prevent a crash? Yes, I agree that original subject is a bit misleading. I'm re-wording the commit message now, just got side-tracked fixing another problem I introduced on Friday :( -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 4/5] SPL:Defines function required to env read for IFC env_nand
On Wed, 2013-09-18 at 16:40 +0530, Prabhakar Kushwaha wrote:
Thanks Scott for taking time and reviewing the RFC patch.
Please find my reply in-lined.
On 09/17/2013 05:23 AM, Scott Wood wrote:
On Mon, 2013-09-16 at 21:35 +0530, Prabhakar Kushwaha wrote:
fsl_ifs_spl.c reads data from NAND and store at a memory location in raw
mode.
It does not used MTD layer.
To read env variable from NAND MTD layer read/write required.
Hence, add mtd_block_isbad nand_read_skip_bad function required during
env variable read.
Also, avoid nand_info during env read for SPL
Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
---
common/env_nand.c |7 ---
drivers/mtd/nand/Makefile |2 +-
drivers/mtd/nand/fsl_ifc_spl.c | 22 ++
3 files changed, 27 insertions(+), 4 deletions(-)
diff --git a/common/env_nand.c b/common/env_nand.c
index 7530962..7a7107f 100644
--- a/common/env_nand.c
+++ b/common/env_nand.c
@@ -246,11 +246,13 @@ int readenv(size_t offset, u_char *buf)
u_char *char_ptr;
blocksize = nand_info[0].erasesize;
+#ifndef CONFIG_SPL_BUILD
if (!blocksize)
return 1;
-
len = min(blocksize, CONFIG_ENV_SIZE);
-
+#else
+ len = CONFIG_ENV_SIZE;
+#endif
Use positive logic (ifdef/else, not ifndef/else).
I will fix it.
Are you sure that CONFIG_ENV_SIZE will always be appropriate? Shouldn't
you use CONFIG_SYS_NAND_BLOCK_SIZE in place of nand_info[0].erasesize?
I can use CONFIG_SYS_NAND_BLOCK_SIZE . but i can not use in SPL as its
is defined as 128K.
You can't redefine the block size to suit your needs. It's a property
of the hardware. What difference does it make, as long as
CONFIG_ENV_SIZE is smaller?
+#ifndef CONFIG_SPL_INIT_MINIMAL
+struct mtd_info nand_info[CONFIG_SYS_MAX_NAND_DEVICE];
+
+int mtd_block_isbad(struct mtd_info *mtd, loff_t ofs)
+{
+ return 0;
+}
+
+int nand_read_skip_bad(struct mtd_info *nand, loff_t offset, size_t
*length,
+ size_t *actual, loff_t lim, u_char *buffer)
+{
+ nand_load(offset, *length, buffer);
+ return 0;
+}
+#endif
What does this have to do with minimal init?
This has nothing to do with minimal init.
Then what does it have to do with CONFIG_SPL_INIT_MINIMAL, which is
specifically for configuring minimial init?
These function will comes into during CONFIG_SPL_BUILD and !defined
CONFIG_SPL_INIT_MINIMAL.
These function will be used for reading env variables.
Then use some SPL symbol indicating environment support is needed.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 00/10] USB: XHCI: Add xHCI host controller stack driver
Marek On 09/23/2013 10:29 AM, Marek Vasut wrote: Dear Vivek Gautam, + Marek, Dan, Julius, Simon and Vikas for this cover patch ;-) [...] Thanks, I have the patches lined up. Just waiting for Dans' talk with Sarah. Maybe we should put her on CC too next time so she can rip us to shreds for our mistakes in the implementation ? :) Best regards, Marek Vasut Did you line up the OMAP5 patches as well? I have verified that v3 of these patches (at least the first 3 with the OMAP5 patches on top are functional. No changes to the OMAP patches just removed the single header file patch that Vivek graciously fixed in his code. Tested-by: Dan Murphy dmur...@ti.com Dan -- -- Dan Murphy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Prevent a U-Boot crash on Wandboard
Dear Fabio Estevam, In message caomzo5aj56kvtfrqbd3wq7oip8q3wa0yv4evuzerkxfufvx...@mail.gmail.com you wrote: Then shouldn't the patch subject/summary be print command name only if cmdtp is not NULL rather than the quite uninformative prevent a crash? Yes, I agree that original subject is a bit misleading. When I read it I thought it was a Wandboard related problem. I don't know if it's only Wandboard, or if other boards are affected, too (which are these? under which exact test cases?). In any case. the problem is not here, but on the caller's side. It should not call a function which expects a command name with a NULL pointer passed as argument. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The Buddha, the Godhead, resides quite as comfortably in the circuits of a digital computer or the gears of a cycle transmission as he does at the top of a mountain or in the petals of a flower. - R. Pirsig, Zen and the Art of Motorcycle Maintenance ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Prevent a U-Boot crash on Wandboard
Hi Steven, On Sun, 22 Sep 2013 21:21:32 -0400, Steven Falco stevenfa...@gmail.com wrote: Prevent a crash when PXE boot calls do_bootm with a vmlinuz formatted image. In this case, there will be a null cmdtp pointer, and we must not dereference it. Signed-off-by: Steven A. Falco stevenfa...@gmail.com --- In file cmd_pxe.c around line 687 is a call: do_bootm(NULL, 0, bootm_argc, bootm_argv); Notice that the first argument is NULL. Therefore, the cmdtp pointer will always be NULL when using the pxe boot mechanism. do_bootm() eventually calls boot_get_kernel(), still with cmdtp == NULL. In the Wandboard case, the vmlinuz binary is not legacy format, nor is it fit format, so U-Boot attempts to print: printf(Wrong Image Format for %s command\n, cmdtp-name); That is doomed to fail, because cmdtp is NULL. The following patch corrects the problem; the command name will be printed only if the pointer is valid. Then shouldn't the patch subject/summary be print command name only if cmdtp is not NULL rather than the quite uninformative prevent a crash? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NAND flash question
On 09/20/2013 11:27 AM, ANDY KENNEDY wrote: -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Peter Barada Sent: Thursday, September 19, 2013 3:26 PM To: u-boot@lists.denx.de; Peter Barada Subject: Re: [U-Boot] NAND flash question On 09/19/2013 04:04 PM, ANDY KENNEDY wrote: All, We have a design that has NAND as a secondary device (not the boot device). The last four pages of the NAND flash are reported as bad. Should this be true for all NAND flash devices we have? No, I wouldn't think so. Manufacturers qualify their parts and mark bad blocks found during qualification testing. Most data sheets indicate that the number of bad blocks marked bad during manufacturer is below a set percentage(if above thent he part is rejected). Some parts that are meant to be used during boot (such as NAND meant for OMAP parts) will have certain blocks that are guaranteed good (i.e. the boot blocks). Past that bad blocks could be anywhere in a particular device. Okay, well, next question: So on EVERY unit we have designed with a NAND flash, when u-Boot reads the NAND flash it reports that it couldn't locate a bad block table and states that it cannot read the last four pages of the flash. Next, when one does a 'nand bad' on these boards, these last four pages are reported by u-Boot as bad. Looking at the code, we believe that this is by design. Is that correct? Has anyone else done a 'nand bad' on a board and seen the same information? Thanks again for any information you can provide, Andy If you are using a NAND-based bad block table (i.e. set the NAND_USE_FLASH_BBT bit in nand-options), then the MTD layer will internally use the last four blocks to hold the bad block table _and_ report those blocks as bad to prevent the user from accidentally modifying them... -- Peter Barada peter.bar...@logicpd.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Prevent a U-Boot crash on Wandboard
Dear Otavio Salvador, In message cap9odkrdjdph+8mrxof+zojzl3qs1u9k5kadey896foo_cl...@mail.gmail.com you wrote: On Sun, Sep 22, 2013 at 10:21 PM, Steven Falco stevenfa...@gmail.com wrote: Prevent a crash when PXE boot calls do_bootm with a vmlinuz formatted image. In this case, there will be a null cmdtp pointer, and we must not dereference it. Signed-off-by: Steven A. Falco stevenfa...@gmail.com --- Acked-by: Otavio Salvador ota...@ossystems.com.br Tom, will you pick this or should it be Cced to someone specific? Please don't. This should be fixed at the root of the problem instead. And in no case a bogus error message should be printed. 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 Horses just naturally have mohawk haircuts. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] cmd_bootm.c: Only pass BOOTM_STATE_OS_CMDLINE on PowerPC/MIPS
In 5c427e4 we pass BOOTM_STATE_OS_CMDLINE as part of the bootm states to run, on all arches. However, this is only valid / useful on PowerPC and MIPS, and causes a problem on ARM where we specifically do not use it. Rather than make this state fake pass like we do for GO on some arches (which need updating to use the GO state), we should just not pass CMDLINE except when it may be used, like before. Tested-by: Dan Murphy dmur...@ti.com Signed-off-by: Tom Rini tr...@ti.com --- common/cmd_bootm.c |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c index 349f165..166b901 100644 --- a/common/cmd_bootm.c +++ b/common/cmd_bootm.c @@ -800,7 +800,10 @@ int do_bootm(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) return do_bootm_states(cmdtp, flag, argc, argv, BOOTM_STATE_START | BOOTM_STATE_FINDOS | BOOTM_STATE_FINDOTHER | - BOOTM_STATE_LOADOS | BOOTM_STATE_OS_CMDLINE | + BOOTM_STATE_LOADOS | +#if defined(CONFIG_PPC) || defined(CONFIG_MIPS) + BOOTM_STATE_OS_CMDLINE | +#endif BOOTM_STATE_OS_PREP | BOOTM_STATE_OS_FAKE_GO | BOOTM_STATE_OS_GO, images, 1); } -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 10/17] usb: gadget: mv_udc: optimize bounce
On 9/22/2013 5:02 PM, Marek Vasut wrote: Dear Troy Kisky, On 9/20/2013 3:58 AM, Marek Vasut wrote: Dear Troy Kisky, Only perform one copy, either in the bounce routine for IN transfers, or the debounce rtn for OUT transfer. On out transfers, only copy the number of bytes received from the bounce buffer Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com --- v4: no change Just a question here. Are you sure we never Send AND Reserve the data in one turn? Because that would need two copyings. ??? s/Reserve/Receive/ As far as I'm aware, a single buffer is only ever used to capture or provide data not both. But, if 2 transfers were queued, an OUT and then an IN using the same Actually, I should have said an IN (tx to the host controller) and then an OUT(rx from the host controller) buffer, if it worked before this patch, it should work after as well. How come? Before, it was doing flush before and inval after the transfer, right ? The 1st IN transfer (tx to the host), will [copy]/flush on mv_bounce and [free]/nothing on mv_debounce. The 2nd OUT transfer (rx from the host) will flush on mv_bounce and invalidate/[copy/free] on mv_debounce. btw what does this part of the patch do/mean ? Why is it there? @@ -387,10 +383,9 @@ static void handle_ep_complete(struct mv_ep *ep) num, in ? in : out, item-info, item-page0); len = (item-info 16) 0x7fff; - - mv_debounce(ep); - ep-req.length -= len; + mv_debounce(ep, in); + That implements the On out transfers, only copy the number of bytes received from the bounce buffer portion of the commit message. Thanks Troy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] socfpga: Adding Freeze Controller driver
On Fri, 2013-09-20 at 00:08 -0500, Chin Liang See wrote:
Adding Freeze Controller driver. All HPS IOs need to be
in freeze state during pin mux or IO buffer configuration.
It is to avoid any glitch which might happen
during the configuration from propagating to external devices.
Signed-off-by: Chin Liang See cl...@altera.com
Cc: Wolfgang Denk w...@denx.de
CC: Pavel Machek pa...@denx.de
Cc: Dinh Nguyen dingu...@altera.com
---
Changes for v3
- Removed unused macro in freeze_controller.h
Changes for v2
- Removed FREEZE_CONTROLLER_FSM_HW
- Removed the get_timer_count_masked and convert to use delay in us
- Used shorter local variables
---
arch/arm/cpu/armv7/socfpga/Makefile|2 +-
arch/arm/cpu/armv7/socfpga/freeze_controller.c | 242
arch/arm/cpu/armv7/socfpga/spl.c | 16 ++
.../include/asm/arch-socfpga/freeze_controller.h | 50
4 files changed, 309 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/cpu/armv7/socfpga/freeze_controller.c
create mode 100644 arch/arm/include/asm/arch-socfpga/freeze_controller.h
diff --git a/arch/arm/cpu/armv7/socfpga/Makefile
b/arch/arm/cpu/armv7/socfpga/Makefile
index 0859e44..10d20f2 100644
--- a/arch/arm/cpu/armv7/socfpga/Makefile
+++ b/arch/arm/cpu/armv7/socfpga/Makefile
@@ -14,7 +14,7 @@ LIB = $(obj)lib$(SOC).o
SOBJS:= lowlevel_init.o
COBJS-y := misc.o timer.o reset_manager.o system_manager.o
-COBJS-$(CONFIG_SPL_BUILD) += spl.o
+COBJS-$(CONFIG_SPL_BUILD) += spl.o freeze_controller.o
COBJS:= $(COBJS-y)
SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
diff --git a/arch/arm/cpu/armv7/socfpga/freeze_controller.c
b/arch/arm/cpu/armv7/socfpga/freeze_controller.c
new file mode 100644
index 000..93ad22a
--- /dev/null
+++ b/arch/arm/cpu/armv7/socfpga/freeze_controller.c
@@ -0,0 +1,242 @@
+/*
+ * Copyright (C) 2013 Altera Corporation www.altera.com
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+
Remove extra line here...
+#include common.h
+#include asm/io.h
+#include asm/arch/freeze_controller.h
+#include asm/arch/timer.h
+#include asm/errno.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+
+
Remove extra lines here...
+static const struct socfpga_freeze_controller *freeze_controller_base =
+ (void *)(SOCFPGA_SYSMGR_ADDRESS + SYSMGR_FRZCTRL_ADDRESS);
+
+/*
+ * Default state from cold reset is FREEZE_ALL; the global
+ * flag is set to TRUE to indicate the IO banks are frozen
+ */
+static uint32_t frzctrl_channel_freeze[FREEZE_CHANNEL_NUM]
+ = { FREEZE_CTRL_FROZEN, FREEZE_CTRL_FROZEN,
+ FREEZE_CTRL_FROZEN, FREEZE_CTRL_FROZEN};
+
+
Ditto...
+/* Freeze HPS IOs */
+u32 sys_mgr_frzctrl_freeze_req(u32 channel_id)
+{
+ u32 ioctrl_reg_offset;
+ u32 reg_value;
+ u32 reg_cfg_mask;
+
+ /* select software FSM */
+ writel(SYSMGR_FRZCTRL_SRC_VIO1_ENUM_SW, freeze_controller_base-src);
+
+ /* Freeze channel ID checking and base address */
+ switch (channel_id) {
+ case 0:
+ case 1:
+ case 2:
+ ioctrl_reg_offset = (u32)(
+ freeze_controller_base-vioctrl +
+ (channel_id SYSMGR_FRZCTRL_VIOCTRL_SHIFT));
+
+ /*
+ * Assert active low enrnsl, plniotri
+ * and niotri signals
+ */
+ reg_cfg_mask =
+ SYSMGR_FRZCTRL_VIOCTRL_SLEW_MASK
+ | SYSMGR_FRZCTRL_VIOCTRL_WKPULLUP_MASK
+ | SYSMGR_FRZCTRL_VIOCTRL_TRISTATE_MASK;
+ clrbits_le32(ioctrl_reg_offset, reg_cfg_mask);
+
+ /*
+ * Note: Delay for 20ns at min
+ * Assert active low bhniotri signal and de-assert
+ * active high csrdone
+ */
Where's the delay?
+ reg_cfg_mask
+ = SYSMGR_FRZCTRL_VIOCTRL_BUSHOLD_MASK
+ | SYSMGR_FRZCTRL_VIOCTRL_CFG_MASK;
+ clrbits_le32(ioctrl_reg_offset, reg_cfg_mask);
+
+ /* Set global flag to indicate channel is frozen */
+ frzctrl_channel_freeze[channel_id] = FREEZE_CTRL_FROZEN;
+ break;
+
+ case 3:
+ /*
+ * Assert active low enrnsl, plniotri and
+ * niotri signals
+ */
+ reg_cfg_mask
+ = SYSMGR_FRZCTRL_HIOCTRL_SLEW_MASK
+ | SYSMGR_FRZCTRL_HIOCTRL_WKPULLUP_MASK
+ | SYSMGR_FRZCTRL_HIOCTRL_TRISTATE_MASK;
+ clrbits_le32(freeze_controller_base-hioctrl, reg_cfg_mask);
+
+ /*
+ * Note: Delay for 40ns at min
+ * assert active low bhniotri nfrzdrv signals,
+ * de-assert active high csrdone and assert
+ * active high frzreg and nfrzdrv signals
+ */
Where's the delay?
+
Re: [U-Boot] [PATCH] Prevent a U-Boot crash on Wandboard
On Mon, Sep 23, 2013 at 08:50:55PM +0200, Wolfgang Denk wrote: Dear Fabio Estevam, In message caomzo5aj56kvtfrqbd3wq7oip8q3wa0yv4evuzerkxfufvx...@mail.gmail.com you wrote: Then shouldn't the patch subject/summary be print command name only if cmdtp is not NULL rather than the quite uninformative prevent a crash? Yes, I agree that original subject is a bit misleading. When I read it I thought it was a Wandboard related problem. I don't know if it's only Wandboard, or if other boards are affected, too (which are these? under which exact test cases?). In any case. the problem is not here, but on the caller's side. It should not call a function which expects a command name with a NULL pointer passed as argument. I looked around at this a bit this morning. cmd_pxe.c would need a lot of mangling to pass around cmdtp, just for the sake of an error message that's then ignored as the caller logic is: 1) Try bootm on the image 2) If CONFIG_CMD_BOOTZ, if bootm returned, maybe we got a zImage? do_bootz instead (also NULL cmdtp). The error message wouldn't exactly make sense here either, being invoked via menu. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/3] ARM: use r9 for gd instead of r8
Hi Jeroen, On Sat, 21 Sep 2013 14:04:39 +0200, Jeroen Hofstee jer...@myspectrum.nl wrote: Changes for v3: Drop the unneeded cc-option for the fixed flag. Drop make reserving the gd register a make variable and use http://patchwork.ozlabs.org/patch/273377/ ARM: refactor compiler options in config.mk instead. Changes for v2: Update the README as requested by Wolfgang Denk Jeroen Hofstee (3): ARM,relocate: do not use r9 ARM: use r9 for gd README: update ARM register usage README | 8 +--- arch/arm/config.mk | 2 +- arch/arm/cpu/armv7/lowlevel_init.S | 4 ++-- arch/arm/include/asm/global_data.h | 2 +- arch/arm/lib/crt0.S| 16 arch/arm/lib/relocate.S| 6 +++--- 6 files changed, 20 insertions(+), 18 deletions(-) Applied to u-boot-arm/master (with the fix to the 2/3 comment), thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Prevent a U-Boot crash on Wandboard
Dear Steven Falco, In message 523f979c.1070...@gmail.com you wrote: Prevent a crash when PXE boot calls do_bootm with a vmlinuz formatted image. In this case, there will be a null cmdtp pointer, and we must not dereference it. ... - printf(Wrong Image Format for %s command\n, cmdtp-name); + if (cmdtp) + printf(Wrong Image Format for %s command\n, cmdtp-name); + else + printf(Wrong Image Format for command\n); This is the wrong way to fix it. Instead of handling this here, please fix the place where a NULL pointer is passed incorrectly. Also, the error message Wrong Image Format for command makes no sense and gives no help to the user to understand what's wrong. NAK. 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 Never worry about theory as long as the machinery does what it's supposed to do. - R. A. Heinlein ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Prevent a U-Boot crash on Wandboard
On Mon, Sep 23, 2013 at 03:17:57PM -0400, Tom Rini wrote: On Mon, Sep 23, 2013 at 08:50:55PM +0200, Wolfgang Denk wrote: Dear Fabio Estevam, In message caomzo5aj56kvtfrqbd3wq7oip8q3wa0yv4evuzerkxfufvx...@mail.gmail.com you wrote: Then shouldn't the patch subject/summary be print command name only if cmdtp is not NULL rather than the quite uninformative prevent a crash? Yes, I agree that original subject is a bit misleading. When I read it I thought it was a Wandboard related problem. I don't know if it's only Wandboard, or if other boards are affected, too (which are these? under which exact test cases?). In any case. the problem is not here, but on the caller's side. It should not call a function which expects a command name with a NULL pointer passed as argument. I looked around at this a bit this morning. cmd_pxe.c would need a lot of mangling to pass around cmdtp, just for the sake of an error message that's then ignored as the caller logic is: 1) Try bootm on the image 2) If CONFIG_CMD_BOOTZ, if bootm returned, maybe we got a zImage? do_bootz instead (also NULL cmdtp). The error message wouldn't exactly make sense here either, being invoked via menu. So, I went off an modified cmd_pxe.c to pass around cmdtp so that we get an error message out, and it's not too bad looking, but it highlights another problem, which is that we could really use a way to get at least the is this a ... ? code, and just get the error code, rather than printouts. The pxe (and really it's the syslinux.conf/extlinux.conf parsing) code shouldn't be doing bootm();bootz() but checking the image type and calling the right boot. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 03/17] usb: gadget: ether set wMaxPacketSize
On 9/22/2013 5:04 PM, Marek Vasut wrote: Dear Troy Kisky, On 9/20/2013 3:52 AM, Marek Vasut wrote: Dear Troy Kisky, set wMaxPacketSize for full speed descriptors fs_source_desc, fs_sink_desc to 64. Full-speed bulk endpoint can have a maximum packet size of 8, 16, 32, or 64 bytes, so choice 64. The hs_source_desc, hs_sink_desc, already have their wMaxPacketSize set to 512. That is the only legal value for high speed bulk endpoints. Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com Why do we need this patch? What issue does this fix ? Best regards, Marek Vasut I could try full speed mode without this and see how linux behaves when given bad data, but that would not says anything about other O.S.es. It seems safer just not to give out bad data. Certainly. Will this not cause issues with the MPC8xx controller and OMAP1510 controller? Best regards, Marek Vasut Good point. ether.c is compiled when CONFIG_USB_ETHER is set. And omap1510_udc.c, mpc8xx_udc.c will only be compiled when CONFIG_USB_ETHER is NOT set. So, not a issue at present. I doubt anyone will upgrade these old boards to support CONFIG_USB_ETHER. Thanks Troy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] Tegra114: Do not program CPCON field for PLLX
PLLX no longer has the CPCON field on Tegra114, so do not attempt to
program it.
Signed-off-by: Thierry Reding tred...@nvidia.com
---
Changes in v2:
- new patch
arch/arm/cpu/arm720t/tegra-common/cpu.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/arm720t/tegra-common/cpu.c
b/arch/arm/cpu/arm720t/tegra-common/cpu.c
index aa1e04f..5ab2ebf 100644
--- a/arch/arm/cpu/arm720t/tegra-common/cpu.c
+++ b/arch/arm/cpu/arm720t/tegra-common/cpu.c
@@ -135,6 +135,7 @@ void adjust_pllp_out_freqs(void)
int pllx_set_rate(struct clk_pll_simple *pll , u32 divn, u32 divm,
u32 divp, u32 cpcon)
{
+ int chip = tegra_get_chip();
u32 reg;
/* If PLLX is already enabled, just return */
@@ -151,7 +152,8 @@ int pllx_set_rate(struct clk_pll_simple *pll , u32 divn,
u32 divm,
writel(reg, pll-pll_base);
/* Set cpcon to PLLX_MISC */
- reg = (cpcon PLL_CPCON_SHIFT);
+ if (chip == CHIPID_TEGRA20 || chip == CHIPID_TEGRA30)
+ reg = (cpcon PLL_CPCON_SHIFT);
/* Set dccon to PLLX_MISC if freq 600MHz */
if (divn 600)
--
1.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] Tegra114: Fix PLLX M, N, P init settings
From: Jimmy Zhang jimmzh...@nvidia.com
The M, N and P width have been changed from Tegra30. The maximum value
for N is limited to 255. So, the tegra_pll_x_table for Tegra114 should
be set accordingly.
Signed-off-by: Jimmy Zhang jimmzh...@nvidia.com
Reviewed-by: Tom Warren twar...@nvidia.com
Signed-off-by: Thierry Reding tred...@nvidia.com
---
Changes in v2:
- clean up table layout and comments
arch/arm/cpu/arm720t/tegra-common/cpu.c | 83 +++--
1 file changed, 59 insertions(+), 24 deletions(-)
diff --git a/arch/arm/cpu/arm720t/tegra-common/cpu.c
b/arch/arm/cpu/arm720t/tegra-common/cpu.c
index 9294611..aa1e04f 100644
--- a/arch/arm/cpu/arm720t/tegra-common/cpu.c
+++ b/arch/arm/cpu/arm720t/tegra-common/cpu.c
@@ -49,33 +49,68 @@ int get_num_cpus(void)
* Timing tables for each SOC for all four oscillator options.
*/
struct clk_pll_table tegra_pll_x_table[TEGRA_SOC_CNT][CLOCK_OSC_FREQ_COUNT] = {
- /* T20: 1 GHz */
- /* n, m, p, cpcon */
- {{ 1000, 13, 0, 12},/* OSC 13M */
-{ 625, 12, 0, 8}, /* OSC 19.2M */
-{ 1000, 12, 0, 12},/* OSC 12M */
-{ 1000, 26, 0, 12},/* OSC 26M */
+ /*
+* T20: 1 GHz
+*
+* Register Field Bits Width
+* --
+* PLLX_BASE p 22:203
+* PLLX_BASE n 17: 8 10
+* PLLX_BASE m 4: 05
+* PLLX_MISC cpcon 11: 84
+*/
+ {
+ { .n = 1000, .m = 13, .p = 0, .cpcon = 12 }, /* OSC: 13.0 MHz */
+ { .n = 625, .m = 12, .p = 0, .cpcon = 8 }, /* OSC: 19.2 MHz */
+ { .n = 1000, .m = 12, .p = 0, .cpcon = 12 }, /* OSC: 12.0 MHz */
+ { .n = 1000, .m = 26, .p = 0, .cpcon = 12 }, /* OSC: 26.0 MHz */
},
-
- /* T25: 1.2 GHz */
- {{ 923, 10, 0, 12},
-{ 750, 12, 0, 8},
-{ 600, 6, 0, 12},
-{ 600, 13, 0, 12},
+ /*
+* T25: 1.2 GHz
+*
+* Register Field Bits Width
+* --
+* PLLX_BASE p 22:203
+* PLLX_BASE n 17: 8 10
+* PLLX_BASE m 4: 05
+* PLLX_MISC cpcon 11: 84
+*/
+ {
+ { .n = 923, .m = 10, .p = 0, .cpcon = 12 }, /* OSC: 13.0 MHz */
+ { .n = 750, .m = 12, .p = 0, .cpcon = 8 }, /* OSC: 19.2 MHz */
+ { .n = 600, .m = 6, .p = 0, .cpcon = 12 }, /* OSC: 12.0 MHz */
+ { .n = 600, .m = 13, .p = 0, .cpcon = 12 }, /* OSC: 26.0 MHz */
},
-
- /* T30: 1.4 GHz */
- {{ 862, 8, 0, 8},
-{ 583, 8, 0, 4},
-{ 700, 6, 0, 8},
-{ 700, 13, 0, 8},
+ /*
+* T30: 1.4 GHz
+*
+* Register Field Bits Width
+* --
+* PLLX_BASE p 22:203
+* PLLX_BASE n 17: 8 10
+* PLLX_BASE m 4: 05
+* PLLX_MISC cpcon 11: 84
+*/
+ {
+ { .n = 862, .m = 8, .p = 0, .cpcon = 8 }, /* OSC: 13.0 MHz */
+ { .n = 583, .m = 8, .p = 0, .cpcon = 4 }, /* OSC: 19.2 MHz */
+ { .n = 700, .m = 6, .p = 0, .cpcon = 8 }, /* OSC: 12.0 MHz */
+ { .n = 700, .m = 13, .p = 0, .cpcon = 8 }, /* OSC: 26.0 MHz */
},
-
- /* T114: 1.4 GHz */
- {{ 862, 8, 0, 8},
-{ 583, 8, 0, 4},
-{ 696, 12, 0, 8},
-{ 700, 13, 0, 8},
+ /*
+* T114: 700 MHz
+*
+* Register Field Bits Width
+* --
+* PLLX_BASE p 23:204
+* PLLX_BASE n 15: 88
+* PLLX_BASE m 7: 08
+*/
+ {
+ { .n = 108, .m = 1, .p = 1 }, /* OSC: 13.0 MHz */
+ { .n = 73, .m = 1, .p = 1 }, /* OSC: 19.2 MHz */
+ { .n = 116, .m = 1, .p = 1 }, /* OSC: 12.0 MHz */
+ { .n = 108, .m = 2, .p = 1 }, /* OSC: 26.0 MHz */
},
};
--
1.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 01/17] usb: gadget: mv_udc: don't check CONFIG_USB_MAX_CONTROLLER_COUNT
On 9/22/2013 5:05 PM, Marek Vasut wrote: Dear Troy Kisky, On 9/20/2013 3:45 AM, Marek Vasut wrote: Dear Troy Kisky, i.mx6 has 1 otg controller, and 3 host ports. So, CONFIG_USB_MAX_CONTROLLER_COUNT can be greater than 1 even though only 1 device mode controller is supported. Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com The problem is, will the 3 additional ports still work? I suspect they will, but then if you run 'usb reset', the gadget port will also be switched back into USB Host function, no Best regards, Marek Vasut The next patch checks the OTG id before switching to host mode. If it is grounded, then it enters host mode, otherwise it doesn't. But, running 'usb reset' on a netconsole may kill your connection. It won't if you properly ignore rhis one controller depending on the OTG pin then, no ? I can return an error code from ehci_hcd_init, so that ehci_reset will not be called. But then usb_lowlevel_init will also return an error, which is good for the call from usb_init, but bad for the call in usb_gadget_register_driver. Perhaps I should return a 1, instead of 0, when the otg_id pin is high? And check for 0 before aborting from usb_gadget_register_driver ? Thanks Troy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Prevent a U-Boot crash on Wandboard
Dear Tom, In message 20130923191757.GZ5273@bill-the-cat you wrote: I don't know if it's only Wandboard, or if other boards are affected, too (which are these? under which exact test cases?). In any case. the problem is not here, but on the caller's side. It should not call a function which expects a command name with a NULL pointer passed as argument. I looked around at this a bit this morning. cmd_pxe.c would need a lot of mangling to pass around cmdtp, just for the sake of an error message that's then ignored as the caller logic is: 1) Try bootm on the image 2) If CONFIG_CMD_BOOTZ, if bootm returned, maybe we got a zImage? do_bootz instead (also NULL cmdtp). The error message wouldn't exactly make sense here either, being invoked via menu. To me that meens that the whole logic needs rework. We should never just try out if an image is in uImage format or a zImage - we are perfectly able to detect such information from the file header (in case of uImage at least). If we keep the code as is, what's wrong then with using the pxe command as ID string? Then the end user knows at least that it was this command which was failing (or producing the message). 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 Plan to throw one away. You will anyway. - Fred Brooks, The Mythical Man Month ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Prevent a U-Boot crash on Wandboard
Dear Tom, In message 20130923194554.GA5273@bill-the-cat you wrote: So, I went off an modified cmd_pxe.c to pass around cmdtp so that we get an error message out, and it's not too bad looking, but it highlights another problem, which is that we could really use a way to get at least the is this a ... ? code, and just get the error code, rather than printouts. The pxe (and really it's the syslinux.conf/extlinux.conf parsing) code shouldn't be doing bootm();bootz() but checking the image type and calling the right boot. Ah, full ACK (I should have read the thread to end before posting). 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 Here's a fish hangs in the net like a poor man's right in the law. 'Twill hardly come out. - Shakespeare, Pericles, Act II, Scene 1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 01/17] usb: gadget: mv_udc: don't check CONFIG_USB_MAX_CONTROLLER_COUNT
On 9/23/2013 1:23 PM, Troy Kisky wrote: On 9/22/2013 5:05 PM, Marek Vasut wrote: Dear Troy Kisky, On 9/20/2013 3:45 AM, Marek Vasut wrote: Dear Troy Kisky, i.mx6 has 1 otg controller, and 3 host ports. So, CONFIG_USB_MAX_CONTROLLER_COUNT can be greater than 1 even though only 1 device mode controller is supported. Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com The problem is, will the 3 additional ports still work? I suspect they will, but then if you run 'usb reset', the gadget port will also be switched back into USB Host function, no Best regards, Marek Vasut The next patch checks the OTG id before switching to host mode. If it is grounded, then it enters host mode, otherwise it doesn't. But, running 'usb reset' on a netconsole may kill your connection. It won't if you properly ignore rhis one controller depending on the OTG pin then, no ? I can return an error code from ehci_hcd_init, so that ehci_reset will not be called. But then usb_lowlevel_init will also return an error, which is good for the call from usb_init, but bad for the call in usb_gadget_register_driver. Perhaps I should return a 1, instead of 0, when the otg_id pin is high? And check for 0 before aborting from usb_gadget_register_driver ? Thanks Troy Or maybe add a parameter to usb_lowlevel_init specifying if I desire host or device mode? Thanks Troy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 01/17] usb: gadget: mv_udc: don't check CONFIG_USB_MAX_CONTROLLER_COUNT
Dear Troy Kisky, On 9/23/2013 1:23 PM, Troy Kisky wrote: On 9/22/2013 5:05 PM, Marek Vasut wrote: Dear Troy Kisky, On 9/20/2013 3:45 AM, Marek Vasut wrote: Dear Troy Kisky, i.mx6 has 1 otg controller, and 3 host ports. So, CONFIG_USB_MAX_CONTROLLER_COUNT can be greater than 1 even though only 1 device mode controller is supported. Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com The problem is, will the 3 additional ports still work? I suspect they will, but then if you run 'usb reset', the gadget port will also be switched back into USB Host function, no Best regards, Marek Vasut The next patch checks the OTG id before switching to host mode. If it is grounded, then it enters host mode, otherwise it doesn't. But, running 'usb reset' on a netconsole may kill your connection. It won't if you properly ignore rhis one controller depending on the OTG pin then, no ? I can return an error code from ehci_hcd_init, so that ehci_reset will not be called. But then usb_lowlevel_init will also return an error, which is good for the call from usb_init, but bad for the call in usb_gadget_register_driver. Perhaps I should return a 1, instead of 0, when the otg_id pin is high? And check for 0 before aborting from usb_gadget_register_driver ? Thanks Troy Or maybe add a parameter to usb_lowlevel_init specifying if I desire host or device mode? Check [PATCH v4] usb: new board-specific USB init interface That might give you some ideas. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 03/17] usb: gadget: ether set wMaxPacketSize
Dear Troy Kisky, On 9/22/2013 5:04 PM, Marek Vasut wrote: Dear Troy Kisky, On 9/20/2013 3:52 AM, Marek Vasut wrote: Dear Troy Kisky, set wMaxPacketSize for full speed descriptors fs_source_desc, fs_sink_desc to 64. Full-speed bulk endpoint can have a maximum packet size of 8, 16, 32, or 64 bytes, so choice 64. The hs_source_desc, hs_sink_desc, already have their wMaxPacketSize set to 512. That is the only legal value for high speed bulk endpoints. Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com Why do we need this patch? What issue does this fix ? Best regards, Marek Vasut I could try full speed mode without this and see how linux behaves when given bad data, but that would not says anything about other O.S.es. It seems safer just not to give out bad data. Certainly. Will this not cause issues with the MPC8xx controller and OMAP1510 controller? Best regards, Marek Vasut Good point. ether.c is compiled when CONFIG_USB_ETHER is set. And omap1510_udc.c, mpc8xx_udc.c will only be compiled when CONFIG_USB_ETHER is NOT set. So, not a issue at present. I doubt anyone will upgrade these old boards to support CONFIG_USB_ETHER. Did you manage to get any feedback from the OMAP1 and MPC8xx guys on the USB topic? btw. it might be actually better to split out the MX6 fixes and general USB fixes so the MX6 ones can go in before the rest. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 10/17] usb: gadget: mv_udc: optimize bounce
Dear Troy Kisky, On 9/22/2013 5:02 PM, Marek Vasut wrote: Dear Troy Kisky, On 9/20/2013 3:58 AM, Marek Vasut wrote: Dear Troy Kisky, Only perform one copy, either in the bounce routine for IN transfers, or the debounce rtn for OUT transfer. On out transfers, only copy the number of bytes received from the bounce buffer Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com --- v4: no change Just a question here. Are you sure we never Send AND Reserve the data in one turn? Because that would need two copyings. ??? s/Reserve/Receive/ As far as I'm aware, a single buffer is only ever used to capture or provide data not both. But, if 2 transfers were queued, an OUT and then an IN using the same Actually, I should have said an IN (tx to the host controller) and then an OUT(rx from the host controller) buffer, if it worked before this patch, it should work after as well. How come? Before, it was doing flush before and inval after the transfer, right ? The 1st IN transfer (tx to the host), will [copy]/flush on mv_bounce and [free]/nothing on mv_debounce. The 2nd OUT transfer (rx from the host) will flush on mv_bounce and invalidate/[copy/free] on mv_debounce. btw what does this part of the patch do/mean ? Why is it there? @@ -387,10 +383,9 @@ static void handle_ep_complete(struct mv_ep *ep) num, in ? in : out, item-info, item-page0); len = (item-info 16) 0x7fff; - - mv_debounce(ep); - ep-req.length -= len; + mv_debounce(ep, in); + That implements the On out transfers, only copy the number of bytes received from the bounce buffer portion of the commit message. OK, thanks. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] Tegra114: Fix PLLX M, N, P init settings
On 09/23/2013 02:07 PM, Thierry Reding wrote: From: Jimmy Zhang jimmzh...@nvidia.com The M, N and P width have been changed from Tegra30. The maximum value for N is limited to 255. So, the tegra_pll_x_table for Tegra114 should be set accordingly. The series, Acked-by: Stephen Warren swar...@nvidia.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/tool/pbl: fix pbl image compiling process
On 09/10/2013 11:48 PM, shh@gmail.com wrote: From: Shaohui Xie shaohui@freescale.com Previous process of compiling a PBL boot image is: 1: make board_name_config 2: make u-boot.pbl for example: make T4240QDS_SDCARD_config make u-boot.pbl Now the process is: 1: make board_name for example: make T4240QDS_SDCARD Also, updated README.pblimage. Signed-off-by: Shaohui Xie shaohui@freescale.com --- Makefile|1 + doc/README.pblimage | 15 ++- 2 files changed, 7 insertions(+), 9 deletions(-) diff --git a/Makefile b/Makefile index 8aa8039..9ae1719 100644 --- a/Makefile +++ b/Makefile @@ -397,6 +397,7 @@ ALL-y += $(obj)u-boot.srec $(obj)u-boot.bin $(obj)System.map ALL-$(CONFIG_NAND_U_BOOT) += $(obj)u-boot-nand.bin ALL-$(CONFIG_ONENAND_U_BOOT) += $(obj)u-boot-onenand.bin +ALL-$(CONFIG_RAMBOOT_PBL) += $(obj)u-boot.pbl ALL-$(CONFIG_SPL) += $(obj)spl/u-boot-spl.bin ALL-$(CONFIG_SPL_FRAMEWORK) += $(obj)u-boot.img ALL-$(CONFIG_TPL) += $(obj)tpl/u-boot-tpl.bin diff --git a/doc/README.pblimage b/doc/README.pblimage index 2b9bb5c..7fdd26b 100644 --- a/doc/README.pblimage +++ b/doc/README.pblimage @@ -14,20 +14,17 @@ Building PBL Boot Image and boot steps 1. Building PBL Boot Image. The default Image is u-boot.pbl. - For eSPI boot(available on P3041/P4080/P5020): + For eSPI boot(available on P2041/P3041/P4080/P5020/P5040/T4240): To build the eSPI boot image: - make board_name_SPIFLASH_config - make u-boot.pbl + make board_name_SPIFLASH - For SD boot(available on P3041/P4080/P5020): + For SD boot(available on P2041/P3041/P4080/P5020/P5040/T4240): To build the SD boot image: - make board_name_SDCARD_config - make u-boot.pbl + make board_name_SDCARD - For Nand boot(available on P3041/P5020): + For Nand boot(available on P2041/P3041/P5020/P5040): To build the NAND boot image: - make board_name_NAND_config - make u-boot.pbl + make board_name_NAND 2. pblimage support available with mkimage utility will generate Freescale PBL Tom, Can I get your ack since this patch changes Makefile? York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] i2c: Zynq: Support for TI PCA9548 bus multiplexer
(Interface is not quite the same as Phillips PCA9547.)
Signed-off-by: Michael Burr michael.b...@logicpd.com
Cc: Heiko Schocher h...@denx.de
Cc: Michal Simek mon...@monstr.eu
---
drivers/i2c/i2c_core.c |5 +
include/i2c.h |2 ++
2 files changed, 7 insertions(+)
diff --git a/drivers/i2c/i2c_core.c b/drivers/i2c/i2c_core.c
index d1072e8..b263562 100644
--- a/drivers/i2c/i2c_core.c
+++ b/drivers/i2c/i2c_core.c
@@ -138,6 +138,11 @@ static int i2c_mux_set(struct i2c_adapter *adap, int
mux_id, int chip,
return -1;
buf = (uint8_t)((channel 0x07) | (1 3));
break;
+ case I2C_MUX_PCA9548_ID:
+ if (channel 7)
+ return -1;
+ buf = (uint8_t)(0x01 channel);
+ break;
default:
printf(%s: wrong mux id: %d\n, __func__, mux_id);
return -1;
diff --git a/include/i2c.h b/include/i2c.h
index 8fd17d1..c1be533 100644
--- a/include/i2c.h
+++ b/include/i2c.h
@@ -135,6 +135,8 @@ extern struct i2c_bus_hose i2c_bus[];
#define I2C_MUX_PCA9544{I2C_MUX_PCA9544_ID, PCA9544A}
#define I2C_MUX_PCA9547_ID 4
#define I2C_MUX_PCA9547{I2C_MUX_PCA9547_ID, PCA9547A}
+#define I2C_MUX_PCA9548_ID 5
+#define I2C_MUX_PCA9548{I2C_MUX_PCA9548_ID, PCA9548}
#endif
#ifndef I2C_SOFT_DECLARATIONS
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-boot] OOB-Layout question in NAND Flash chip
On Sun, 2013-09-22 at 11:58 +0800, tiger...@viatech.com.cn wrote: Hi, experts: Is the u-boot's NAND OOB-layout same with linux kernel's nand drivers? It's supposed to be, though it's defined by individual drivers and there may be some where the layout has been (unfortunately) changed over time -- such as if a vendor kernel/U-Boot did it differently from upstream. Is there a specific NAND driver you're referring to? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/5] Add device tree support for VxWorks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/21/2013 10:57 PM, myan wrote: Hi Tom, I posted some patches to add device tree support for VxWorks several days ago. Wolfgang provided me with some very useful feedback, and I sent v2 patches. The discussion and patches are recorded here: http://u-boot.10912.n7.nabble.com/PATCH-0-5-Add-device-tree-support-for-VxWorks-td163268.html I see you are the master branch custodian, so do you think these patches are OK to be integrated or more discussions are needed ? What else should I do to make this upstream ? Thank you. I think things look OK, but as they were posted after the merge window closed, they won't go in to master until after the v2013.10 release, thanks! - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSQM58AAoJENk4IS6UOR1WG+QQALLtbiycW+RhfZ5Wi79ltpj9 A/Lv4hcGz9HkgS1ODE3L/lbUpmzmGEyDtBv/+O2qPDKJ8aB317mGbZklcFGG3oGC MOZA5TqTk+sP3gVCZ7+0hTy/iHJj37MD7O3Xcx6b34VYCNA0ccl2z0NdwwPBTh9w aoRH0NPVsYfUHX8/r3k+4q0/JxXCJhcyZk/RnYfF2w/7pwNELxUFn+uaN/+jMLHk 8YY9JaSztFPk3gAk2tcaY+WG+z8xzF/0b0YsRK9vAbXKUTR1Kd9bhzBrD17CopWZ BMiiTsG1l+xoQPt8HP1CsIAArsaF26sWaCsJOJiNp93TscwgsmO9A4aNCzYexH2D CuPejp/qRzHr00kZjuij9SgVWY9t7rbYFByCEoOPfmZDr8IOhqIkffgsZvCFkcmw JADjfEnqTkheJbL9U/e2hhAG48d8ugwGA3RBOtY5JxprviK3B45gmzr+PvXXETk3 Ur3VRYeG1r+eneAZ6IjlZedN53C3pKsjOyZpj98a19K+/JQUmSD3oZydYS6B3xQH uVg7o4j4AW2AyXrlUMAGV0CWc3Sg99P7VmI7PaEJomn+yJ382wMMgWckCOVZQAK8 i/AX17aH8AV8SuWMi71yXa0z0tvnpLO5n+mAN7GxaxnVLQIr1TFtVEyuE/WRMHka NYyFoEgA0DQ0TsgCTxx2 =Myl2 -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Prevent a U-Boot crash on Wandboard
On 09/23/2013 04:44 PM, Wolfgang Denk wrote: Dear Tom, In message 20130923194554.GA5273@bill-the-cat you wrote: So, I went off an modified cmd_pxe.c to pass around cmdtp so that we get an error message out, and it's not too bad looking, but it highlights another problem, which is that we could really use a way to get at least the is this a ... ? code, and just get the error code, rather than printouts. The pxe (and really it's the syslinux.conf/extlinux.conf parsing) code shouldn't be doing bootm();bootz() but checking the image type and calling the right boot. Ah, full ACK (I should have read the thread to end before posting). Thanks! Best regards, Wolfgang Denk I understand your point that it is better to fix the problem at the source. I also like Tom's suggestion that the type be checked earlier, and then just directly choose the right bootX() variant. So naturally, I withdraw my patch, in favor of your fix - at least I was able to isolate the source of the crash for you. :-) Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] buildman: Adjust tests for new boards.cfg format
Commit 27af930e9a5c91365ca639ada580b338eabe4989 changed the boards.cfg format but missed to change the parsing in buildman. A follow-on commit 03c1bb242548e4e9d267d784861ccd69a1887aa0 fixed this but missed fixing the tests. This patch updates the tests to fit the new Board constructor. ./tools/buildman/buildman -t unittest.result.TestResult run=1 errors=0 failures=0 Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: None tools/buildman/test.py | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/tools/buildman/test.py b/tools/buildman/test.py index bcdedfb..068784a 100644 --- a/tools/buildman/test.py +++ b/tools/buildman/test.py @@ -60,11 +60,11 @@ commits = [ ] boards = [ -['board0', 'arm', 'armv7', 'ARM Board 1', 'Tester', '', ''], -['board1', 'arm', 'armv7', 'ARM Board 2', 'Tester', '', ''], -['board2', 'powerpc', 'powerpc', 'PowerPC board 1', 'Tester', '', ''], -['board3', 'powerpc', 'mpc5xx', 'PowerPC board 2', 'Tester', '', ''], -['board4', 'sandbox', 'sandbox', 'Sandbox board', 'Tester', '', ''] +['Active', 'arm', 'armv7', '', 'Tester', 'ARM Board 1', 'board0', ''], +['Active', 'arm', 'armv7', '', 'Tester', 'ARM Board 2', 'board1', ''], +['Active', 'powerpc', 'powerpc', '', 'Tester', 'PowerPC board 1', 'board2', ''], +['Active', 'powerpc', 'mpc5xx', '', 'Tester', 'PowerPC board 2', 'board3', ''], +['Active', 'sandbox', 'sandbox', '', 'Tester', 'Sandbox board', 'board4', ''], ] class Options: -- 1.8.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] ARM: tegra: support SKU b1 of Tegra30
It's fine as-is for now. Send a V2 with any changes Stephen, et al requested (if any), and I'll get it into tegra-next when I return from vacation next Monday (assuming it's been Acked). Thanks, Tom -Original Message- From: Alban Bedel [mailto:alban.be...@avionic-design.de] Sent: Monday, September 23, 2013 1:52 AM To: Tom Warren Cc: u-boot@lists.denx.de; julian.sch...@avionic-design.de; Tom Warren; Stephen Warren; Thierry Reding (thierry.red...@gmail.com) Subject: Re: [U-Boot] [PATCH 1/2] ARM: tegra: support SKU b1 of Tegra30 On Fri, 20 Sep 2013 10:57:42 -0700 Tom Warren twar...@nvidia.com wrote: Alban, Were you going to do a V2 of this patchset? I expected to, but up to now there was no concrete change request. Should I split the PMU stuff to its own mini driver, or is it acceptable as is for now? Alban -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] buildman: Allow make flags to be specified for each board
There are a few make options such as BUILD_TAG which can be provided when
building U-Boot. Provide a way for buildman to pass these flags to make
also.
The flags should be in a [make-flags] section and arranged by target name
(the 'target' column in boards.cfg. See the README for more details.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v2:
Correct unit test invocation
tools/buildman/README | 22
tools/buildman/bsettings.py | 3 --
tools/buildman/builder.py | 1 +
tools/buildman/buildman.py | 13
tools/buildman/toolchain.py | 81 +++--
5 files changed, 115 insertions(+), 5 deletions(-)
diff --git a/tools/buildman/README b/tools/buildman/README
index 734ada6..f63f278 100644
--- a/tools/buildman/README
+++ b/tools/buildman/README
@@ -629,6 +629,28 @@ It is common when refactoring code for the rodata to
decrease as the text size
increases, and vice versa.
+Providing 'make' flags
+==
+
+U-Boot's build system supports a few flags (such as BUILD_TAG) which affect
+the build product. These flags can be specified in the buildman settings
+file. They can also be useful when building U-Boot against other open source
+software.
+
+[make-flags]
+at91-boards=ENABLE_AT91_TEST=1
+snapper9260=${at91-boards} BUILD_TAG=442
+snapper9g45=${at91-boards} BUILD_TAG=443
+
+This will use 'make ENABLE_AT91_TEST=1 BUILD_TAG=442' for snapper9260
+and 'make ENABLE_AT91_TEST=1 BUILD_TAG=442' for snapper9g45. A special
+variable ${target} is available to access the target name (snapper9260 and
+snapper9g20 in this case). Variables are resolved recursively.
+
+It is expected that any variables added are dealt with in U-Boot's
+config.mk file and documented in the README.
+
+
Other options
=
diff --git a/tools/buildman/bsettings.py b/tools/buildman/bsettings.py
index c801130..9164798 100644
--- a/tools/buildman/bsettings.py
+++ b/tools/buildman/bsettings.py
@@ -36,9 +36,6 @@ def GetItems(section):
return settings.items(section)
except ConfigParser.NoSectionError as e:
print e
-print (Warning: No tool chains - please add a [toolchain] section
-to your buildman config file %s. See README for details %
-config_fname)
return []
except:
raise
diff --git a/tools/buildman/builder.py b/tools/buildman/builder.py
index 29da67a..4a2d753 100644
--- a/tools/buildman/builder.py
+++ b/tools/buildman/builder.py
@@ -253,6 +253,7 @@ class BuilderThread(threading.Thread):
args.extend(['-j', str(self.builder.num_jobs)])
config_args = ['%s_config' % brd.target]
config_out = ''
+args.extend(self.builder.toolchains.GetMakeArguments(brd))
# If we need to reconfigure, do that now
if do_config:
diff --git a/tools/buildman/buildman.py b/tools/buildman/buildman.py
index 6fba2f2..43895b8 100755
--- a/tools/buildman/buildman.py
+++ b/tools/buildman/buildman.py
@@ -32,6 +32,19 @@ import toolchain
def RunTests():
import test
+import doctest
+
+result = unittest.TestResult()
+for module in ['toolchain']:
+suite = doctest.DocTestSuite(module)
+suite.run(result)
+
+# TODO: Surely we can just 'print' result?
+print result
+for test, err in result.errors:
+print err
+for test, err in result.failures:
+print err
sys.argv = [sys.argv[0]]
suite = unittest.TestLoader().loadTestsFromTestCase(test.TestBuild)
diff --git a/tools/buildman/toolchain.py b/tools/buildman/toolchain.py
index dfa1d00..a292338 100644
--- a/tools/buildman/toolchain.py
+++ b/tools/buildman/toolchain.py
@@ -3,6 +3,7 @@
# SPDX-License-Identifier: GPL-2.0+
#
+import re
import glob
import os
@@ -97,12 +98,18 @@ class Toolchains:
def __init__(self):
self.toolchains = {}
self.paths = []
-for name, value in bsettings.GetItems('toolchain'):
+toolchains = bsettings.GetItems('toolchain')
+if not toolchains:
+print (Warning: No tool chains - please add a [toolchain] section
+ to your buildman config file %s. See README for details %
+ config_fname)
+
+for name, value in toolchains:
if '*' in value:
self.paths += glob.glob(value)
else:
self.paths.append(value)
-
+self._make_flags = dict(bsettings.GetItems('make-flags'))
def Add(self, fname, test=True, verbose=False):
Add a toolchain to our list
@@ -167,3 +174,73 @@ class Toolchains:
if not arch in self.toolchains:
raise ValueError, (No tool chain found for arch '%s' % arch)
return self.toolchains[arch]
+
+def ResolveReferences(self, var_dict, args):
+Resolve variable references in a string
+
+This converts ${blah} within the
Re: [U-Boot] [U-boot] OOB-Layout question in NAND Flash chip
Hi, Scott: Thanks for your answer! It's supposed to be, though it's defined by individual drivers and there may be some where the layout has been (unfortunately) changed over time -- such as if a vendor kernel/U-Boot did it differently from upstream. Is there a specific NAND driver you're referring to? Not yet! Just be curious! :) Best wishes, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/5] cosmetic: UDM-net: clean up the remainders of dead driver
This commit omits non-existing drivers/net/netarm_eth.c from the list. This driver is deleted by commit b411eb30f. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com --- doc/driver-model/UDM-net.txt | 6 -- 1 file changed, 6 deletions(-) diff --git a/doc/driver-model/UDM-net.txt b/doc/driver-model/UDM-net.txt index ef80964..097ed69 100644 --- a/doc/driver-model/UDM-net.txt +++ b/doc/driver-model/UDM-net.txt @@ -338,12 +338,6 @@ III) Analysis of in-tree drivers This file implements external functions necessary for native NE2000 compatible networking card to work. - drivers/net/netarm_eth.c - - - This driver uses the old, legacy, network API and will either have to be - converted or removed. - drivers/net/netconsole.c -- 1.8.1.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/5] cosmetic: UDM-serial: clean up the remainders of dead driver
The following serial drivers do not exist any more. - ns9750_serial.c: deleted by commit 4cfc611b4 - s3c4510b_uart.c: deleted by commit afad40299 - serial_clps7111.c: deleted by commit f2e080156 - serial_netarm.c: deleted by commit b411eb30f This commit cleans up UDM-serial.txt. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com --- doc/driver-model/UDM-serial.txt | 16 1 file changed, 16 deletions(-) diff --git a/doc/driver-model/UDM-serial.txt b/doc/driver-model/UDM-serial.txt index da6d429..279e941 100644 --- a/doc/driver-model/UDM-serial.txt +++ b/doc/driver-model/UDM-serial.txt @@ -84,18 +84,10 @@ III) Analysis of in-tree drivers during conversion. This driver is implemented in very universal manner, therefore it'll be necessary to properly design it's platform_data. - ns9750_serial.c - --- - Unmaintained port. Code got removed. - opencores_yanu.c No support for CONFIG_SERIAL_MULTI. Simple conversion possible. - s3c4510b_uart.c - --- - No support for CONFIG_SERIAL_MULTI. Simple conversion possible. - sandbox.c - No support for CONFIG_SERIAL_MULTI. Simple conversion possible. @@ -104,10 +96,6 @@ III) Analysis of in-tree drivers This is a complementary part of NS16550 UART driver, see above. - serial_clps7111.c - - - No support for CONFIG_SERIAL_MULTI. Simple conversion possible. - serial_imx.c No support for CONFIG_SERIAL_MULTI. Simple conversion possible. This driver @@ -129,10 +117,6 @@ III) Analysis of in-tree drivers No support for CONFIG_SERIAL_MULTI. Simple conversion possible. - serial_netarm.c - --- - No support for CONFIG_SERIAL_MULTI. Simple conversion possible. - serial_pl01x.c -- No support for CONFIG_SERIAL_MULTI. Simple conversion possible, though this -- 1.8.1.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/5] ep93xx: remove remainders of dead board
commit 716f7ade104a9aeed647e19a8b8c9ed9f491359d
deleted all ep93xx SoC boards.
Now ep93xx SoC specific code
- arch/arm/cpu/arm920t/ep93xx/
- arch/arm/include/asm/arch-ep93xx/
are not used at all.
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---
arch/arm/cpu/arm920t/ep93xx/Makefile| 41 --
arch/arm/cpu/arm920t/ep93xx/cpu.c | 37 --
arch/arm/cpu/arm920t/ep93xx/led.c | 85
arch/arm/cpu/arm920t/ep93xx/lowlevel_init.S | 49 ---
arch/arm/cpu/arm920t/ep93xx/speed.c | 96 -
arch/arm/cpu/arm920t/ep93xx/timer.c | 120 --
arch/arm/cpu/arm920t/ep93xx/u-boot.lds | 54 ---
arch/arm/include/asm/arch-ep93xx/ep93xx.h | 582
8 files changed, 1064 deletions(-)
delete mode 100644 arch/arm/cpu/arm920t/ep93xx/Makefile
delete mode 100644 arch/arm/cpu/arm920t/ep93xx/cpu.c
delete mode 100644 arch/arm/cpu/arm920t/ep93xx/led.c
delete mode 100644 arch/arm/cpu/arm920t/ep93xx/lowlevel_init.S
delete mode 100644 arch/arm/cpu/arm920t/ep93xx/speed.c
delete mode 100644 arch/arm/cpu/arm920t/ep93xx/timer.c
delete mode 100644 arch/arm/cpu/arm920t/ep93xx/u-boot.lds
delete mode 100644 arch/arm/include/asm/arch-ep93xx/ep93xx.h
diff --git a/arch/arm/cpu/arm920t/ep93xx/Makefile
b/arch/arm/cpu/arm920t/ep93xx/Makefile
deleted file mode 100644
index 7a75c86..000
--- a/arch/arm/cpu/arm920t/ep93xx/Makefile
+++ /dev/null
@@ -1,41 +0,0 @@
-#
-# Cirrus Logic EP93xx CPU-specific Makefile
-#
-# Copyright (C) 2009 Matthias Kaehlcke matth...@kaehlcke.net
-#
-# Copyright (C) 2004, 2005
-# Cory T. Tusar, Videon Central, Inc., ctu...@videon-central.com
-#
-# Copyright (C) 2006
-# Dominic Rath dominic.r...@gmx.de
-#
-# Based on an original Makefile, which is
-#
-# (C) Copyright 2000, 2001, 2002
-# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
-#
-# SPDX-License-Identifier: GPL-2.0+
-#
-include $(TOPDIR)/config.mk
-
-LIB = $(obj)lib$(SOC).o
-
-COBJS = cpu.o led.o speed.o timer.o
-SOBJS = lowlevel_init.o
-
-SRCS:= $(SOBJS:.o=.S) $(COBJS:.o=.c)
-OBJS:= $(addprefix $(obj),$(SOBJS) $(COBJS))
-
-all:$(obj).depend $(LIB)
-
-$(LIB): $(OBJS)
- $(call cmd_link_o_target, $(OBJS))
-
-#
-
-# defines $(obj).depend target
-include $(SRCTREE)/rules.mk
-
-sinclude $(obj).depend
-
-#
diff --git a/arch/arm/cpu/arm920t/ep93xx/cpu.c
b/arch/arm/cpu/arm920t/ep93xx/cpu.c
deleted file mode 100644
index bb5ffd2..000
--- a/arch/arm/cpu/arm920t/ep93xx/cpu.c
+++ /dev/null
@@ -1,37 +0,0 @@
-/*
- * Cirrus Logic EP93xx CPU-specific support.
- *
- * Copyright (C) 2009 Matthias Kaehlcke matth...@kaehlcke.net
- *
- * Copyright (C) 2004, 2005
- * Cory T. Tusar, Videon Central, Inc., ctu...@videon-central.com
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#include common.h
-#include asm/arch/ep93xx.h
-#include asm/io.h
-
-/* We reset the CPU by generating a 1--0 transition on DeviceCfg bit 31. */
-extern void reset_cpu(ulong addr)
-{
- struct syscon_regs *syscon = (struct syscon_regs *)SYSCON_BASE;
- uint32_t value;
-
- /* Unlock DeviceCfg and set SWRST */
- writel(0xAA, syscon-sysswlock);
- value = readl(syscon-devicecfg);
- value |= SYSCON_DEVICECFG_SWRST;
- writel(value, syscon-devicecfg);
-
- /* Unlock DeviceCfg and clear SWRST */
- writel(0xAA, syscon-sysswlock);
- value = readl(syscon-devicecfg);
- value = ~SYSCON_DEVICECFG_SWRST;
- writel(value, syscon-devicecfg);
-
- /* Dying... */
- while (1)
- ; /* noop */
-}
diff --git a/arch/arm/cpu/arm920t/ep93xx/led.c
b/arch/arm/cpu/arm920t/ep93xx/led.c
deleted file mode 100644
index 6144729..000
--- a/arch/arm/cpu/arm920t/ep93xx/led.c
+++ /dev/null
@@ -1,85 +0,0 @@
-/*
- * Copyright (C) 2010, 2009 Matthias Kaehlcke matth...@kaehlcke.net
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#include asm/io.h
-#include asm/arch/ep93xx.h
-#include config.h
-#include status_led.h
-
-static uint8_t saved_state[2] = {STATUS_LED_OFF, STATUS_LED_OFF};
-static uint32_t gpio_pin[2] = {1 STATUS_LED_GREEN,
- 1 STATUS_LED_RED};
-
-inline void switch_LED_on(uint8_t led)
-{
- register struct gpio_regs *gpio = (struct gpio_regs *)GPIO_BASE;
-
- writel(readl(gpio-pedr) | gpio_pin[led], gpio-pedr);
- saved_state[led] = STATUS_LED_ON;
-}
-
-inline void switch_LED_off(uint8_t led)
-{
- register struct gpio_regs *gpio = (struct gpio_regs *)GPIO_BASE;
-
- writel(readl(gpio-pedr) ~gpio_pin[led], gpio-pedr);
- saved_state[led] = STATUS_LED_OFF;
-}
-
-void red_led_on(void)
-{
- switch_LED_on(STATUS_LED_RED);
-}
-
-void red_led_off(void)
-{
- switch_LED_off(STATUS_LED_RED);
-}
-
-void green_led_on(void)
-{
- switch_LED_on(STATUS_LED_GREEN);
-}
-
-void green_led_off(void)
-{
-
[U-Boot] [PATCH 5/5] net: ep93xx_eth: remove a dead driver.
commit 716f7ade104a9aeed647e19a8b8c9ed9f491359d
deleted all ep93xx SoC boards.
Now there are no boards enabling CONFIG_EP93XX,
no boards using ep93xx_eth driver.
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---
doc/driver-model/UDM-net.txt | 6 -
drivers/net/Makefile | 1 -
drivers/net/ep93xx_eth.c | 639 ---
drivers/net/ep93xx_eth.h | 127 -
include/common.h | 3 +-
include/netdev.h | 1 -
6 files changed, 1 insertion(+), 776 deletions(-)
delete mode 100644 drivers/net/ep93xx_eth.c
delete mode 100644 drivers/net/ep93xx_eth.h
diff --git a/doc/driver-model/UDM-net.txt b/doc/driver-model/UDM-net.txt
index 097ed69..f447f59 100644
--- a/doc/driver-model/UDM-net.txt
+++ b/doc/driver-model/UDM-net.txt
@@ -217,12 +217,6 @@ III) Analysis of in-tree drivers
This driver uses the standard new networking API, therefore there should be
no
obstacles throughout the conversion process.
- drivers/net/ep93xx_eth.c
-
-
- This driver uses the standard new networking API, therefore there should be
no
- obstacles throughout the conversion process.
-
drivers/net/ethoc.c
---
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 18fd54f..7436e64 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -25,7 +25,6 @@ COBJS-$(CONFIG_E1000) += e1000.o
COBJS-$(CONFIG_E1000_SPI) += e1000_spi.o
COBJS-$(CONFIG_EEPRO100) += eepro100.o
COBJS-$(CONFIG_ENC28J60) += enc28j60.o
-COBJS-$(CONFIG_EP93XX) += ep93xx_eth.o
COBJS-$(CONFIG_ETHOC) += ethoc.o
COBJS-$(CONFIG_FEC_MXC) += fec_mxc.o
COBJS-$(CONFIG_FSLDMAFEC) += fsl_mcdmafec.o mcfmii.o
diff --git a/drivers/net/ep93xx_eth.c b/drivers/net/ep93xx_eth.c
deleted file mode 100644
index 1c09f10..000
--- a/drivers/net/ep93xx_eth.c
+++ /dev/null
@@ -1,639 +0,0 @@
-/*
- * Cirrus Logic EP93xx ethernet MAC / MII driver.
- *
- * Copyright (C) 2010, 2009
- * Matthias Kaehlcke matth...@kaehlcke.net
- *
- * Copyright (C) 2004, 2005
- * Cory T. Tusar, Videon Central, Inc., ctu...@videon-central.com
- *
- * Based on the original eth.[ch] Cirrus Logic EP93xx Rev D. Ethernet Driver,
- * which is
- *
- * (C) Copyright 2002 2003
- * Adam Bezanson, Network Audio Technologies, Inc.
- * bezan...@netaudiotech.com
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#include command.h
-#include common.h
-#include asm/arch/ep93xx.h
-#include asm/io.h
-#include malloc.h
-#include miiphy.h
-#include linux/types.h
-#include ep93xx_eth.h
-
-#define GET_PRIV(eth_dev) ((struct ep93xx_priv *)(eth_dev)-priv)
-#define GET_REGS(eth_dev) (GET_PRIV(eth_dev)-regs)
-
-/* ep93xx_miiphy ops forward declarations */
-static int ep93xx_miiphy_read(const char * const dev, unsigned char const addr,
- unsigned char const reg, unsigned short * const value);
-static int ep93xx_miiphy_write(const char * const dev, unsigned char const
addr,
- unsigned char const reg, unsigned short const value);
-
-#if defined(EP93XX_MAC_DEBUG)
-/**
- * Dump ep93xx_mac values to the terminal.
- */
-static void dump_dev(struct eth_device *dev)
-{
- struct ep93xx_priv *priv = GET_PRIV(dev);
- int i;
-
- printf(\ndump_dev()\n);
- printf( rx_dq.base %p\n, priv-rx_dq.base);
- printf( rx_dq.current %p\n, priv-rx_dq.current);
- printf( rx_dq.end %p\n, priv-rx_dq.end);
- printf( rx_sq.base %p\n, priv-rx_sq.base);
- printf( rx_sq.current %p\n, priv-rx_sq.current);
- printf( rx_sq.end %p\n, priv-rx_sq.end);
-
- for (i = 0; i NUMRXDESC; i++)
- printf( rx_buffer[%2.d] %p\n, i, NetRxPackets[i]);
-
- printf( tx_dq.base %p\n, priv-tx_dq.base);
- printf( tx_dq.current %p\n, priv-tx_dq.current);
- printf( tx_dq.end %p\n, priv-tx_dq.end);
- printf( tx_sq.base %p\n, priv-tx_sq.base);
- printf( tx_sq.current %p\n, priv-tx_sq.current);
- printf( tx_sq.end %p\n, priv-tx_sq.end);
-}
-
-/**
- * Dump all RX status queue entries to the terminal.
- */
-static void dump_rx_status_queue(struct eth_device *dev)
-{
- struct ep93xx_priv *priv = GET_PRIV(dev);
- int i;
-
- printf(\ndump_rx_status_queue()\n);
- printf( descriptor address word1 word2\n);
- for (i = 0; i NUMRXDESC; i++) {
- printf( [ %p ] %08X%08X\n,
- priv-rx_sq.base + i,
- (priv-rx_sq.base + i)-word1,
- (priv-rx_sq.base + i)-word2);
- }
-}
-
-/**
- * Dump all RX descriptor queue entries to the terminal.
- */
-static void dump_rx_descriptor_queue(struct eth_device *dev)
-{
- struct ep93xx_priv *priv = GET_PRIV(dev);
- int i;
-
- printf(\ndump_rx_descriptor_queue()\n);
- printf(
[U-Boot] [PATCH 0/5] cleanup docs and remove remainders of dead board
This series deletes the remainders of dead board: - arch/arm/cpu/arm920t/ep93xx/* - arch/arm/include/asm/arch-ep93xx/* - drivers/net/ep93xx_eth.[ch] But while I was working to delete a dead driver ep93xx_eth, I realized re-numbering the drivers list in doc/driver-model/UDM-net.txt was a painful task. Is this numbering really necessary? So, first of all I decided to delete sequencial numbers in doc/driver-model/UDM-*.txt. (This was done in 0001.) I also noticed dead serial and net drivers still remaining in the list. So cleaned up them. (This was done in 0002 and 0003.) The ep93xx related code was removed by 0004. The ep93xx_eth driver was deleted by 0005. Masahiro Yamada (5): cosmetic: doc: driver-model: Do not number driver lists cosmetic: doc: UDM-serial: clean up the remainders of dead driver cosmetic: doc: UDM-net: clean up the remainders of dead driver ep93xx: remove remainders of dead board net: ep93xx_eth: remove a dead driver. arch/arm/cpu/arm920t/ep93xx/Makefile| 41 -- arch/arm/cpu/arm920t/ep93xx/cpu.c | 37 -- arch/arm/cpu/arm920t/ep93xx/led.c | 85 arch/arm/cpu/arm920t/ep93xx/lowlevel_init.S | 49 --- arch/arm/cpu/arm920t/ep93xx/speed.c | 96 - arch/arm/cpu/arm920t/ep93xx/timer.c | 120 -- arch/arm/cpu/arm920t/ep93xx/u-boot.lds | 54 --- arch/arm/include/asm/arch-ep93xx/ep93xx.h | 582 - doc/driver-model/UDM-block.txt | 56 +-- doc/driver-model/UDM-gpio.txt | 32 +- doc/driver-model/UDM-hwmon.txt | 36 +- doc/driver-model/UDM-keyboard.txt | 12 +- doc/driver-model/UDM-mmc.txt| 72 ++-- doc/driver-model/UDM-net.txt| 220 +- doc/driver-model/UDM-pci.txt| 124 +++--- doc/driver-model/UDM-pcmcia.txt | 24 +- doc/driver-model/UDM-power.txt | 12 +- doc/driver-model/UDM-rtc.txt| 152 +++ doc/driver-model/UDM-serial.txt | 106 ++--- doc/driver-model/UDM-spi.txt| 96 ++--- doc/driver-model/UDM-stdio.txt | 16 +- doc/driver-model/UDM-twserial.txt | 4 +- doc/driver-model/UDM-video.txt | 24 +- doc/driver-model/UDM-watchdog.txt | 204 - drivers/net/Makefile| 1 - drivers/net/ep93xx_eth.c| 639 drivers/net/ep93xx_eth.h| 127 -- include/common.h| 3 +- include/netdev.h| 1 - 29 files changed, 582 insertions(+), 2443 deletions(-) delete mode 100644 arch/arm/cpu/arm920t/ep93xx/Makefile delete mode 100644 arch/arm/cpu/arm920t/ep93xx/cpu.c delete mode 100644 arch/arm/cpu/arm920t/ep93xx/led.c delete mode 100644 arch/arm/cpu/arm920t/ep93xx/lowlevel_init.S delete mode 100644 arch/arm/cpu/arm920t/ep93xx/speed.c delete mode 100644 arch/arm/cpu/arm920t/ep93xx/timer.c delete mode 100644 arch/arm/cpu/arm920t/ep93xx/u-boot.lds delete mode 100644 arch/arm/include/asm/arch-ep93xx/ep93xx.h delete mode 100644 drivers/net/ep93xx_eth.c delete mode 100644 drivers/net/ep93xx_eth.h -- 1.8.1.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 00/10] USB: XHCI: Add xHCI host controller stack driver
Hi Marek, On Mon, Sep 23, 2013 at 8:59 PM, Marek Vasut ma...@denx.de wrote: Dear Vivek Gautam, + Marek, Dan, Julius, Simon and Vikas for this cover patch ;-) [...] Thanks, I have the patches lined up. Just waiting for Dans' talk with Sarah. Maybe we should put her on CC too next time so she can rip us to shreds for our mistakes in the implementation ? :) Yeah, of-course. Always welcome for improvements. Do you want me to CC Sarah here in this thread itself, or should i re-spin the patches keeping her in CC. :-) Best regards, Marek Vasut -- Best Regards Vivek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [U-boot]question: why write bbt and search bbt use different ops mode in nand_bbt.c in U-boot 2013.04?
Hi , Scott:
First, My uboot version is 2013.04.
In the function scan_write_bbt(), U-boot uses MTD_OOB_PLACE to write BBT
data and BBT pattern. See below
static int scan_write_bbt(struct mtd_info *mtd, loff_t offs, size_t len,
uint8_t *buf, uint8_t *oob)
{
struct mtd_oob_ops ops;
ops.mode = MTD_OOB_PLACE;
ops.ooboffs = 0;
ops.ooblen = mtd-oobsize;
ops.datbuf = buf;
ops.oobbuf = oob;
ops.len = len;
return mtd-write_oob(mtd, offs, ops);
}
while in funtion search_bbt() (actually in function
scan_read_raw_oob()), U-boot uses MTD_OOB_RAW to read BBT data and BBT
pattern. See below.
static int scan_read_raw_oob(struct mtd_info *mtd, uint8_t *buf, loff_t
offs,
size_t len)
{
struct mtd_oob_ops ops;
int res;
ops.mode = MTD_OOB_RAW;
ops.ooboffs = 0;
ops.ooblen = mtd-oobsize;
while (len 0) {
if (len = mtd-writesize) {
ops.oobbuf = buf + len;
ops.datbuf = buf;
ops.len = len;
return mtd-read_oob(mtd, offs, ops);
} else {
ops.oobbuf = buf + mtd-writesize;
ops.datbuf = buf;
ops.len = mtd-writesize;
res = mtd-read_oob(mtd, offs, ops);
if (res)
return res;
}
buf += mtd-oobsize + mtd-writesize;
len -= mtd-writesize;
}
return 0;
}
It's confused that search BBT and write BBT uses different mtd ops mode.
And also data will not be valid if U-boot uses mtd ops MTD_OOB_RAW
during reading and no software ECC is implemented.
I also noticed that in U-boot2013.07 both search BBT and write BBT uses
mtd ops MTD_OPS_PLACE_OOB.
Best wishes,
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers:power:max77693: add support for new multi function pmic max77693
Dear Piotr Wilczek,
On 21/05/13 22:00, Piotr Wilczek wrote:
This patch add support for new multi function pmic max77693.
The driver is split into three modules: pmic, muic and fuelgage.
Signed-off-by: Piotr Wilczek p.wilc...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Minkyu Kang mk7.k...@samsung.com
---
Makefile |1 +
drivers/power/mfd/Makefile| 49 +
drivers/power/mfd/fg_max77693.c | 143
+
drivers/power/mfd/muic_max77693.c | 91 +++
drivers/power/mfd/pmic_max77693.c | 110
include/power/max77693_fg.h | 65 +
include/power/max77693_muic.h | 90 +++
include/power/max77693_pmic.h | 56 +++
8 files changed, 605 insertions(+)
create mode 100644 drivers/power/mfd/Makefile
create mode 100644 drivers/power/mfd/fg_max77693.c
create mode 100644 drivers/power/mfd/muic_max77693.c
create mode 100644 drivers/power/mfd/pmic_max77693.c
create mode 100644 include/power/max77693_fg.h
create mode 100644 include/power/max77693_muic.h
create mode 100644 include/power/max77693_pmic.h
diff --git a/Makefile b/Makefile
index c52f0f1..ea2cc11 100644
--- a/Makefile
+++ b/Makefile
@@ -298,6 +298,7 @@ LIBS-y += drivers/pci/libpci.o
LIBS-y += drivers/pcmcia/libpcmcia.o
LIBS-y += drivers/power/libpower.o \
drivers/power/fuel_gauge/libfuel_gauge.o \
+ drivers/power/mfd/libmfd.o \
drivers/power/pmic/libpmic.o \
drivers/power/battery/libbattery.o
LIBS-y += drivers/spi/libspi.o
diff --git a/drivers/power/mfd/Makefile b/drivers/power/mfd/Makefile
new file mode 100644
index 000..2ab3b00
--- /dev/null
+++ b/drivers/power/mfd/Makefile
@@ -0,0 +1,49 @@
+#
+# Copyright (C) 2013 Samsung Electronics
+# Piotr Wilczek p.wilc...@samsung.com
+#
+# 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 $(TOPDIR)/config.mk
+
+LIB := $(obj)libmfd.o
+
+COBJS-$(CONFIG_POWER_PMIC_MAX77693) += pmic_max77693.o
+COBJS-$(CONFIG_POWER_MUIC_MAX77693) += muic_max77693.o
+COBJS-$(CONFIG_POWER_FG_MAX77693) += fg_max77693.o
+
+COBJS:= $(COBJS-y)
+SRCS := $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+
+all: $(LIB)
+
+$(LIB): $(obj).depend $(OBJS)
+ $(call cmd_link_o_target, $(OBJS))
+
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+
diff --git a/drivers/power/mfd/fg_max77693.c b/drivers/power/mfd/fg_max77693.c
new file mode 100644
index 000..0004cf8
--- /dev/null
+++ b/drivers/power/mfd/fg_max77693.c
@@ -0,0 +1,143 @@
+/*
+ * Copyright (C) 2013 Samsung Electronics
+ * Piotr Wilczek p.wilc...@samsung.com
+ *
+ * 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 power/pmic.h
+#include power/max77693_fg.h
+#include i2c.h
+#include power/power_chrg.h
+#include power/battery.h
+#include power/fg_battery_cell_params.h
+#include errno.h
+
+static int max77693_get_vcell(u32 *vcell)
+{
+ u16 value;
+ u8 ret;
+
+ ret = i2c_read(MAX77693_FUEL_I2C_ADDR, MAX77693_VCELL, 1,
+(u8 *)value, 2);
+ if (ret)
+
Re: [U-Boot] [PATCH] usb: ehci: Fix test mode for connected ports
Hi Simon, It seems like you could do something like /* * This is the delay for ...the spec requires a minimum of ... */ #define SOME_SUITABLE_NAME 8000 at the top of the file and then use it twice in your function. The file contains a dozen handshake() calls that have a literal 100 * 1000 in there, and none of them have any special meaning in regards to the spec... it's all just a random guess. I'd be happy to change the timeouts in my patch to 100 for consistency, but it really doesn't make sense to single this one out with a #define. (Maybe we should make it a #define DEFAULT_TIMEOUT 10 for all of them, but not in this patch.) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: ehci: Fix test mode for connected ports
Hi Julius, On Mon, Sep 23, 2013 at 8:55 PM, Julius Werner jwer...@chromium.org wrote: Hi Simon, It seems like you could do something like /* * This is the delay for ...the spec requires a minimum of ... */ #define SOME_SUITABLE_NAME 8000 at the top of the file and then use it twice in your function. The file contains a dozen handshake() calls that have a literal 100 * 1000 in there, and none of them have any special meaning in regards to the spec... it's all just a random guess. I'd be happy to change the timeouts in my patch to 100 for consistency, but it really doesn't make sense to single this one out with a #define. (Maybe we should make it a #define DEFAULT_TIMEOUT 10 for all of them, but not in this patch.) I guess we are trying to distinguish between how the code is and how we would like it to me. From that point of view your patch is independent of the existing code. Since you have a clear reason for the timeout you have chose, you can document that and set a good example for others! Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] USB: gadget: atmel: disconnect before unbind
When unbind the gadget driver, need call disconnect first.
Signed-off-by: Bo Shen voice.s...@atmel.com
---
drivers/usb/gadget/atmel_usba_udc.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/atmel_usba_udc.c
b/drivers/usb/gadget/atmel_usba_udc.c
index f146c48..c99208d 100644
--- a/drivers/usb/gadget/atmel_usba_udc.c
+++ b/drivers/usb/gadget/atmel_usba_udc.c
@@ -1240,11 +1240,12 @@ int usb_gadget_unregister_driver(struct
usb_gadget_driver *driver)
{
struct usba_udc *udc = controller;
- if (!driver || !driver-bind || !driver-setup) {
+ if (!driver || !driver-unbind || !driver-disconnect) {
error(bad paramter\n);
return -EINVAL;
}
+ driver-disconnect(udc-gadget);
driver-unbind(udc-gadget);
udc-driver = NULL;
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
