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
>
> 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
> ---
> 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
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 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 Signed-off-by: Thierry Reding --- 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 Active arm armv7 zynqxilinx zynq zynq_dcc zynq:ZYNQ_DCC Michal Simek Active arm armv7:arm720t tegra114nvidia dalmore dalmore - Tom Warren -Active arm armv7:arm720t tegra20 avionic-design medcom-wide medcom-wide - Thierry Reding -Active arm armv7:arm720t tegra20 avionic-design plutux plutux - Thierry Reding -Active arm armv7:arm720t tegra20 avionic-design tec tec - Thierry Reding +Active arm armv7:arm720t tegra20 avionic-design medcom-wide medcom-wide - Alban Bedel +Active arm armv7:arm720t tegra20 avionic-design plutux plutux - Alban Bedel +Active arm armv7:arm720t tegra20 avionic-design tec tec - Alban Bedel Active arm armv7:arm720t tegra20 compal paz00 paz00- Tom Warren :Stephen Warren Active arm armv7:arm720t tegra20 compulabtrimslice trimslice- Tom Warren :Stephen Warren Active arm armv7:arm720t tegra20 nvidia harmony harmony - Tom Warren -- 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 CC: Stefano Babic --- 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 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 > > --- Acked-by: Otavio Salvador 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
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
> Signed-off-by: Michal Simek
> ---
> 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 > > 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 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 > Cc: tiger...@viatech.com.cn > Cc: Albert ARIBAUD > --- > 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
> 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
>> Signed-off-by: Michal Simek
>> ---
>> 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 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 > Signed-off-by: Michal Simek > > --- > 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
wrote:
> On 09/23/2013 02:31 PM, Albert ARIBAUD wrote:
> > Hi Michal,
> >
> > On Thu, 22 Aug 2013 14:52:02 +0200, Michal Simek
> > 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
> >> Signed-off-by: Michal Simek
> >> ---
> >> 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 Burr
> Cc: Heiko Schocher
> Cc: Michal Simek
> ---
> 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 > > > > 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
> wrote:
>
>> On 09/23/2013 02:31 PM, Albert ARIBAUD wrote:
>>> Hi Michal,
>>>
>>> On Thu, 22 Aug 2013 14:52:02 +0200, Michal Simek
>>> 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
Signed-off-by: Michal Simek
---
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 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 > Cc: Martijn de Gouw > Cc: Albert Aribaud > --- > 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 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 CC: Stefano Babic --- 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 ___ 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
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
> ---
>
> 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/confi
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 > 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
> >> ---
> >> 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 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 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
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
>
> ---
>
> 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 you wrote: > On Sun, Sep 22, 2013 at 10:21 PM, Steven Falco 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 > > > > --- > > Acked-by: Otavio Salvador > > 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 Signed-off-by: Tom Rini --- 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 --- 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
> Cc: Wolfgang Denk
> CC: Pavel Machek
> Cc: Dinh Nguyen
> ---
> 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
> + *
> + * SPDX-License-Identifier: GPL-2.0+
> + */
> +
> +
Remove extra line here...
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +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?
> + reg_valu
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 > 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 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 > > 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 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
---
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
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
Reviewed-by: Tom Warren
Signed-off-by: Thierry Reding
---
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 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 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 > > 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 > >>> > >>> 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 > > --- > 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 > > 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 ___ 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 > > Previous process of compiling a PBL boot image is: > 1: make > 2: make u-boot.pbl > > for example: > make T4240QDS_SDCARD_config > make u-boot.pbl > > Now the process is: > 1: make > > for example: > make T4240QDS_SDCARD > > Also, updated README.pblimage. > > Signed-off-by: Shaohui Xie > --- > 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 _SPIFLASH_config > - make u-boot.pbl > + make _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 _SDCARD_config > - make u-boot.pbl > + make _SDCARD > > - For Nand boot(available on P3041/P5020): > + For Nand boot(available on P2041/P3041/P5020/P5040): > To build the NAND boot image: > - make _NAND_config > - make u-boot.pbl > + make _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
Cc: Heiko Schocher
Cc: Michal Simek
---
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 Signed-off-by: Simon Glass --- 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 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
---
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 st
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 --- 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 --- 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
---
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
-#
-# Copyright (C) 2004, 2005
-# Cory T. Tusar, Videon Central, Inc.,
-#
-# Copyright (C) 2006
-# Dominic Rath
-#
-# 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
- *
- * Copyright (C) 2004, 2005
- * Cory T. Tusar, Videon Central, Inc.,
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#include
-#include
-#include
-
-/* 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
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#include
-#include
-#include
-#include
-
-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)
-{
- switch_LED_off(STATUS_LED_GREEN);
-}
-
-void __led_init(led_id_t mask, int state)
-{
- __led_set(mask, state);
-}
-
-void __led_toggle(led_id_t mask)
-{
- if (STATUS_LED_RED == mask) {
-
[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
---
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
- *
- * Copyright (C) 2004, 2005
- * Cory T. Tusar, Videon Central, Inc.,
- *
- * 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.
- *
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#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(" descriptor address word1 word2\n");
- for (i = 0; i < NUMRXDESC; i++) {
- 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 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
> Signed-off-by: Kyungmin Park
> CC: Minkyu Kang
> ---
> 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
> +#
> +# 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
> + *
> + * See file CREDITS for list of people who contributed to this
> + * project.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> + * MA 02111-1307 USA
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +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)
> + return -1;
> +
> + *vcell = (u32)(value >> 3);
> + *vcell = *vcel
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 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
---
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
Re: [U-Boot] [PATCH 5/5] net: ep93xx_eth: remove a dead driver.
Hi Masahiro,
And this driver works fine when my patch
(http://patchwork.ozlabs.org/patch/276429/) applied.
Best Regards,
Sergey Kostanbaev
On Tue, Sep 24, 2013 at 5:32 AM, Masahiro Yamada
wrote:
> 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
> ---
> 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
> - *
> - * Copyright (C) 2004, 2005
> - * Cory T. Tusar, Videon Central, Inc.,
> - *
> - * 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.
> - *
> - *
> - * SPDX-License-Identifier:GPL-2.0+
> - */
> -
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#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.bas
Re: [U-Boot] [PATCH 4/5] ep93xx: remove remainders of dead board
Hi Masahiro,
EP93xx is not dead! I recently submit patch for full support of
edb9315a board (see http://patchwork.ozlabs.org/patch/276429/). And
it's working well on my boards and on the original evaluation board.
Best Regards,
Sergey Kostanbaev
On Tue, Sep 24, 2013 at 5:32 AM, Masahiro Yamada
wrote:
> 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
> ---
> 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
> -#
> -# Copyright (C) 2004, 2005
> -# Cory T. Tusar, Videon Central, Inc.,
> -#
> -# Copyright (C) 2006
> -# Dominic Rath
> -#
> -# 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
> - *
> - * Copyright (C) 2004, 2005
> - * Cory T. Tusar, Videon Central, Inc.,
> - *
> - * SPDX-License-Identifier:GPL-2.0+
> - */
> -
> -#include
> -#include
> -#include
> -
> -/* 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
> - *
> - * SPDX-License-Identifier:GPL-2.0+
> - */
> -
> -#include
> -#include
> -#include
> -#include
> -
> -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_reg
[U-Boot] [PATCH v2] arm: Remove IXP425 boards pdnb3 and scpu
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
Cc: Martijn de Gouw
Cc: Albert Aribaud
---
v2:
- Rebased on current master
- Added entries for pdnb3 and scpu to doc/README.scrapyard
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 -
doc/README.scrapyard | 2 +
include/configs/pdnb3.h | 322 --
7 files changed, 2 insertions(+), 774 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
diff --git a/board/prodrive/pdnb3/Makefile b/board/prodrive/pdnb3/Makefile
deleted file mode 100644
index 5e4a909..000
--- a/board/prodrive/pdnb3/Makefile
+++ /dev/null
@@ -1,28 +0,0 @@
-#
-# (C) Copyright 2006
-# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
-#
-# SPDX-License-Identifier: GPL-2.0+
-#
-
-include $(TOPDIR)/config.mk
-
-LIB= $(obj)lib$(BOARD).o
-
-COBJS := flash.o pdnb3.o nand.o
-
-SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
-OBJS := $(addprefix $(obj),$(COBJS))
-SOBJS := $(addprefix $(obj),$(SOBJS))
-
-$(LIB):$(obj).depend $(OBJS)
- $(call cmd_link_o_target, $(OBJS))
-
-#
-
-# defines $(obj).depend target
-include $(SRCTREE)/rules.mk
-
-sinclude $(obj).depend
-
-#
diff --git a/board/prodrive/pdnb3/flash.c b/board/prodrive/pdnb3/flash.c
deleted file mode 100644
index 75b5d05..000
--- a/board/prodrive/pdnb3/flash.c
+++ /dev/null
@@ -1,73 +0,0 @@
-/*
- * (C) Copyright 2006
- * Stefan Roese, DENX Software Engineering, s...@denx.de.
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#include
-#include
-
-#if !defined(CONFIG_FLASH_CFI_DRIVER)
-
-/*
- * include common flash code (for esd boards)
- */
-#include "../common/flash.c"
-
-/*
- * Prototypes
- */
-static ulong flash_get_size (vu_long * addr, flash_info_t * info);
-
-static inline ulong ld(ulong x)
-{
- ulong k = 0;
-
- while (x >>= 1)
- ++k;
-
- return k;
-}
-
-unsigned long flash_init(void)
-{
- unsigned long size;
- int i;
-
- /* Init: no FLASHes known */
- for (i=0; i
-
-#if defined(CONFIG_CMD_NAND)
-
-#include
-
-struct pdnb3_ndfc_regs {
- uchar cmd;
- uchar wait;
- uchar addr;
- uchar term;
- uchar data;
-};
-
-static u8 hwctl;
-static struct pdnb3_ndfc_regs *pdnb3_ndfc;
-
-#define readb(addr)*(volatile u_char *)(addr)
-#define readl(addr)*(volatile u_long *)(addr)
-#define writeb(d,addr) *(volatile u_char *)(addr) = (d)
-
-/*
- * The PDNB3 has a NAND Flash Controller (NDFC) that handles all accesses to
- * the NAND devices. The NDFC has command, address and data registers that
- * when accessed will set up the NAND flash pins appropriately. We'll use the
- * hwcontrol function to save the configuration in a global variable.
- * We can then use this information in the read and write functions to
- * determine which NDFC register to access.
- *
- * There is one NAND devices on the board, a Hynix HY27US08561A (32 MByte).
- */
-static void pdnb3_nand_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int
ctrl)
-{
- struct nand_chip *this = mtd->priv;
-
- if (ctrl & NAND_CTRL_CHANGE) {
- if ( ctrl & NAND_CLE )
- hwctl |= 0x1;
- else
- hwctl &= ~0x1;
- if ( ctrl & NAND_ALE )
- hwctl |= 0x2;
- else
- hwctl &= ~0x2;
- if ( (ctrl & NAND_NCE) != NAND_NCE)
- writeb(0x00, &(pdnb3_ndfc->term));
- }
- if (cmd != NAND_CMD_NONE)
- writeb(cmd, this->IO_ADDR_W);
-}
-
-
-static u_char pdnb3_nand_read_byte(struct mtd_info *mtd)
-{
- return readb(&(pdnb3_ndfc->data));
-}
-
-static void pdnb3_nand_write_buf(struct mtd_info *mtd, const u_char *buf, int
len)
-{
- int i;
-
- for (i = 0; i < len; i++) {
- if (hwctl & 0x1)
- writeb(buf[i], &(pdnb3_ndfc->cmd));
- else if (hwctl & 0x2)
- writeb(buf[i], &(pdnb3_ndfc->addr));
- else
- writeb(buf[i], &(pdnb3_ndfc->data));
- }
-}
-
-static void pdnb3_nand_read_buf(struct mtd_info *mtd, u_char *buf, int len)
-{
- int i;
-
- for (i = 0; i < len; i++)
- buf[i] = readb(&(pdnb3_ndfc->data));
-}
-
-static int pdnb3_
Re: [U-Boot] [RFC] i2c_reloc_fixup fails on m68k
Hello Jens,
Am 23.09.2013 15:50, schrieb Jens Scharsig:
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.
Which toolchain?
Can anybody confirm this?
Added Mike Frysinger, Sonic Zhang (for blackfin) Jason Jin (for m68k)
and Macpaul Lin (for nds32) to Cc ...
I think also m68k, backfin and nds32 systems are affected
Sorry, I have no such system ... maybe you are the first who stepped
in it ...
---
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;
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
[U-Boot] [PATCH 4/4] arm: rmobile: Add support Koelsch board
The koelsch board has R8A7791, 2GB DDR3-SDRAM, USB,
Quad SPI, Ethernet, and more.
This patch supports the following functions:
- DDR3-SDRAM
- SCIF
- Quad SPI
- Ether
Signed-off-by: Nobuhiro Iwamatsu
Signed-off-by: Hisashi Nakamura
CC: Nobuhiro Iwamatsu
CC: Albert Aribaud
---
board/renesas/koelsch/Makefile | 34
board/renesas/koelsch/koelsch.c | 360
board/renesas/koelsch/qos.c | 148 +
board/renesas/koelsch/qos.h | 12 ++
boards.cfg | 2 +
include/configs/koelsch.h | 182
6 files changed, 738 insertions(+)
create mode 100644 board/renesas/koelsch/Makefile
create mode 100644 board/renesas/koelsch/koelsch.c
create mode 100644 board/renesas/koelsch/qos.c
create mode 100644 board/renesas/koelsch/qos.h
create mode 100644 include/configs/koelsch.h
diff --git a/board/renesas/koelsch/Makefile b/board/renesas/koelsch/Makefile
new file mode 100644
index 000..e0efbc4
--- /dev/null
+++ b/board/renesas/koelsch/Makefile
@@ -0,0 +1,34 @@
+#
+# board/renesas/koelsch/Makefile
+#
+# Copyright (C) 2013 Renesas Electronics Corporation
+#
+# SPDX-License-Identifier: GPL-2.0
+#
+
+include$(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS := koelsch.o qos.o
+
+SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+
+$(LIB): $(obj).depend $(OBJS) $(SOBJS)
+ $(call cmd_link_o_target, $(OBJS) $(SOBJS))
+
+clean:
+ rm -f $(SOBJS) $(OBJS)
+
+distclean: clean
+ rm -f $(LIB) core *.bak $(obj).depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/renesas/koelsch/koelsch.c b/board/renesas/koelsch/koelsch.c
new file mode 100644
index 000..73cad66
--- /dev/null
+++ b/board/renesas/koelsch/koelsch.c
@@ -0,0 +1,360 @@
+/*
+ * board/renesas/koelsch/koelsch.c
+ *
+ * Copyright (C) 2013 Renesas Electronics Corporation
+ *
+ * SPDX-License-Identifier: GPL-2.0
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "qos.h"
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define s_init_wait(cnt) \
+ ({ \
+ u32 i = 0x1 * cnt; \
+ while (i > 0) \
+ i--;\
+ })
+
+
+#define dbpdrgd_check(bsc) \
+ ({ \
+ while ((readl(&bsc->dbpdrgd) & 0x1) != 0x1) \
+ ; \
+ })
+
+#if defined(CONFIG_NORFLASH)
+static void bsc_init(void)
+{
+ struct r8a7791_lbsc *lbsc = (struct r8a7791_lbsc *)LBSC_BASE;
+ struct r8a7791_dbsc3 *dbsc3_0 = (struct r8a7791_dbsc3 *)DBSC3_0_BASE;
+
+ /* LBSC */
+ writel(0x0020, &lbsc->cs0ctrl);
+ writel(0x0020, &lbsc->cs1ctrl);
+ writel(0x2020, &lbsc->ecs0ctrl);
+ writel(0x2020, &lbsc->ecs1ctrl);
+
+ writel(0x077F077F, &lbsc->cswcr0);
+ writel(0x077F077F, &lbsc->cswcr1);
+ writel(0x077F077F, &lbsc->ecswcr0);
+ writel(0x077F077F, &lbsc->ecswcr1);
+
+ /* DBSC3 */
+ s_init_wait(10);
+
+ writel(0xA55A, &dbsc3_0->dbpdlck);
+ writel(0x0001, &dbsc3_0->dbpdrga);
+ writel(0x8000, &dbsc3_0->dbpdrgd);
+ writel(0x0004, &dbsc3_0->dbpdrga);
+ dbpdrgd_check(dbsc3_0);
+
+ writel(0x0006, &dbsc3_0->dbpdrga);
+ writel(0x0001C000, &dbsc3_0->dbpdrgd);
+
+ writel(0x0023, &dbsc3_0->dbpdrga);
+ writel(0x00FD2480, &dbsc3_0->dbpdrgd);
+
+ writel(0x0010, &dbsc3_0->dbpdrga);
+ writel(0xF004649B, &dbsc3_0->dbpdrgd);
+
+ writel(0x000F, &dbsc3_0->dbpdrga);
+ writel(0x00181EE4, &dbsc3_0->dbpdrgd);
+
+ writel(0x000E, &dbsc3_0->dbpdrga);
+ writel(0x33C03812, &dbsc3_0->dbpdrgd);
+
+ writel(0x0003, &dbsc3_0->dbpdrga);
+ writel(0x0300C481, &dbsc3_0->dbpdrgd);
+
+ writel(0x0007, &dbsc3_0->dbkind);
+ writel(0x10030A02, &dbsc3_0->dbconf0);
+ writel(0x0001, &dbsc3_0->dbphytype);
+ writel(0x, &dbsc3_0->dbbl);
+ writel(0x000B, &dbsc3_0->dbtr0);
+ writel(0x0008, &dbsc3_0->dbtr1);
+ writel(0x, &dbsc3_0->dbtr2);
+ writel(0x000B, &dbsc3_0->dbtr3);
+ writel(0x000C000B, &dbsc3_0->dbtr4);
+ writel(0x0027, &dbsc3_0->dbtr5);
+ writel(0x001C, &dbsc3_0->dbtr6);
+ writel(0x0005, &dbsc3_0->dbtr7);
+ writel(0x0018, &dbsc3_0->dbtr8);
+ writel(0x0008, &dbsc3_0->dbtr9);
+ writel(0x000C, &dbsc3_0->dbtr10);
+ writel(0x0009, &dbsc3_0->dbtr11);
+ writel(0x0012, &dbsc3_0->dbtr12);
+ writel(0x00D0, &dbsc3_0->dbtr13);
+ writel(0x00140005, &dbsc3_0->dbtr14);
[U-Boot] [PATCH 1/4] serial: sh: Add support R8A7791
This adds the preset value to register for R8A7791.
Signed-off-by: Nobuhiro Iwamatsu
CC: Nobuhiro Iwamatsu
---
drivers/serial/serial_sh.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/serial/serial_sh.h b/drivers/serial/serial_sh.h
index a6558af..556b868 100644
--- a/drivers/serial/serial_sh.h
+++ b/drivers/serial/serial_sh.h
@@ -224,7 +224,7 @@ struct uart_port {
# define SCSPTR3 0xffc60020/* 16 bit SCIF */
# define SCIF_ORER 0x0001 /* Overrun error bit */
# define SCSCR_INIT(port) 0x38/* TIE=0,RIE=0,TE=1,RE=1,REIE=1 */
-#elif defined(CONFIG_R8A7790)
+#elif defined(CONFIG_R8A7790) || defined(CONFIG_R8A7791)
# define SCIF_ORER 0x0001
# define SCSCR_INIT(port) 0x32/* TIE=0,RIE=0,TE=1,RE=1,REIE=0, */
#else
@@ -301,7 +301,7 @@ struct uart_port {
/* SH7763 SCIF2 support */
# define SCIF2_RFDC_MASK 0x001f
# define SCIF2_TXROOM_MAX 16
-#elif defined(CONFIG_R8A7790)
+#elif defined(CONFIG_R8A7790) || defined(CONFIG_R8A7791)
# define SCIF_ERRORS (SCIF_PER | SCIF_FER | SCIF_ER | SCIF_BRK)
# define SCIF_RFDC_MASK0x003f
#else
@@ -585,7 +585,7 @@ SCIF_FNS(SCSPTR,0, 0, 0, 0)
#else
SCIF_FNS(SCSPTR,0, 0, 0x20, 16)
#endif
-#if defined(CONFIG_R8A7790)
+#if defined(CONFIG_R8A7790) || defined(CONFIG_R8A7791)
SCIF_FNS(DL, 0, 0, 0x30, 16)
SCIF_FNS(CKS, 0, 0, 0x34, 16)
#endif
@@ -730,7 +730,7 @@ static inline int scbrr_calc(struct uart_port port, int
bps, int clk)
#define SCBRR_VALUE(bps, clk) scbrr_calc(sh_sci, bps, clk)
#elif defined(__H8300H__) || defined(__H8300S__)
#define SCBRR_VALUE(bps, clk) (((clk*1000/32)/bps)-1)
-#elif defined(CONFIG_R8A7790)
+#elif defined(CONFIG_R8A7790) || defined(CONFIG_R8A7791)
#define SCBRR DL
#define SCBRR_VALUE(bps, clk) (clk / bps / 16)
#else /* Generic SH */
--
1.8.4.rc3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] net: sh-eth: Add support R8A7791
R8A7791 has the same sh-ether IP core as other SH/rmobile.
This patch adds support of R8A7791.
Signed-off-by: Nobuhiro Iwamatsu
CC: Nobuhiro Iwamatsu
CC: Joe Hershberger
---
drivers/net/sh_eth.c | 5 +++--
drivers/net/sh_eth.h | 4 ++--
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/sh_eth.c b/drivers/net/sh_eth.c
index b936808..8c23e30 100644
--- a/drivers/net/sh_eth.c
+++ b/drivers/net/sh_eth.c
@@ -410,7 +410,7 @@ static int sh_eth_config(struct sh_eth_dev *eth, bd_t *bd)
#if defined(CONFIG_CPU_SH7734) || defined(CONFIG_R8A7740)
sh_eth_write(eth, CONFIG_SH_ETHER_SH7734_MII, RMII_MII);
-#elif defined(CONFIG_R8A7790)
+#elif defined(CONFIG_R8A7790) || defined(CONFIG_R8A7791)
sh_eth_write(eth, sh_eth_read(eth, RMIIMR) | 0x1, RMIIMR);
#endif
/* Configure phy */
@@ -435,7 +435,8 @@ static int sh_eth_config(struct sh_eth_dev *eth, bd_t *bd)
sh_eth_write(eth, GECMR_100B, GECMR);
#elif defined(CONFIG_CPU_SH7757) || defined(CONFIG_CPU_SH7752)
sh_eth_write(eth, 1, RTRATE);
-#elif defined(CONFIG_CPU_SH7724) || defined(CONFIG_R8A7790)
+#elif defined(CONFIG_CPU_SH7724) || defined(CONFIG_R8A7790) || \
+ defined(CONFIG_R8A7791)
val = ECMR_RTM;
#endif
} else if (phy->speed == 10) {
diff --git a/drivers/net/sh_eth.h b/drivers/net/sh_eth.h
index 43b8ac9..8aa7109 100644
--- a/drivers/net/sh_eth.h
+++ b/drivers/net/sh_eth.h
@@ -301,7 +301,7 @@ static const u16
sh_eth_offset_fast_sh4[SH_ETH_MAX_REGISTER_OFFSET] = {
#elif defined(CONFIG_R8A7740)
#define SH_ETH_TYPE_GETHER
#define BASE_IO_ADDR 0xE9A0
-#elif defined(CONFIG_R8A7790)
+#elif defined(CONFIG_R8A7790) || defined(CONFIG_R8A7791)
#define SH_ETH_TYPE_ETHER
#define BASE_IO_ADDR 0xEE700200
#endif
@@ -507,7 +507,7 @@ enum FELIC_MODE_BIT {
ECMR_PRM = 0x0001,
#ifdef CONFIG_CPU_SH7724
ECMR_RTM = 0x0010,
-#elif defined(CONFIG_R8A7790)
+#elif defined(CONFIG_R8A7790) || defined(CONFIG_R8A7791)
ECMR_RTM = 0x0004,
#endif
--
1.8.4.rc3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 07/28] sf: probe: Add support for W25* flash parts
Hi Sascha,
Thanks for your inputs.
I think you commented w.r.t old driver configurations.
Yes, I will do these changes on next versions.
On Sun, Sep 22, 2013 at 12:24 AM, Sascha Silbe wrote:
> Jagannadha Sutradharudu Teki
> writes:
>
>> Added W25* parts are which are avilable in spi_flash_probe_legacy.c.
>>
>> Updated the sector_size attributes as per the flash parts.
>> Looks fine for with this sector_size for computing the size
>> of flash.
>
>
> This breaks sector-sized (i.e. 4KiB) erases on W25Q32BV (and many other
> Winbond chips). The sizes are set differently by the old code and yours:
>
> old yours
> page_size 256 256
> sector_size 4K 64K
> size 4M 4M
>
>
> The data sheet defines three different granularities: pages (256B, used
> for writing), sectors (4KiB, used for erasing), blocks (64KiB, used for
> write protection in some configurations). You seem to have mixed sectors
> and blocks. The total size is the same, but sector-sized erases stop
> working.
>
> With the following change, my (rather simple) test cases work again:
>
>
> diff --git i/drivers/mtd/spi/spi_flash_probe.c
> w/drivers/mtd/spi/spi_flash_probe.c
> index 1ff3b60..6f13484 100644
> --- i/drivers/mtd/spi/spi_flash_probe.c
> +++ w/drivers/mtd/spi/spi_flash_probe.c
> @@ -85,7 +85,7 @@ static const struct spi_flash_params
> spi_flash_params_table[] = {
> {"W25X64", 0xef3017, 0x0, 64 * 1024,128},
> {"W25Q80BL",0xef4014, 0x0, 64 * 1024, 16},
> {"W25Q16CL",0xef4015, 0x0, 64 * 1024, 32},
> - {"W25Q32BV",0xef4016, 0x0, 64 * 1024, 64},
> + {"W25Q32BV",0xef4016, 0x0, 4 * 1024, 1024},
> {"W25Q64CV",0xef4017, 0x0, 64 * 1024,128},
> {"W25Q128BV", 0xef4018, 0x0, 64 * 1024,256},
> {"W25Q256", 0xef4019, 0x0, 64 * 1024,512},
>
>
> The other chips will need similar changes.
>
> Sascha
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
--
Thanks,
Jagan.
Jagannadha Sutradharudu Teki,
E: jagannadh.t...@gmail.com, P: +91-9676773388
Engineer - System Software Hacker
U-boot - SPI Custodian and Zynq APSOC
Ln: http://www.linkedin.com/in/jaganteki
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
