On 8/18/12, Mike Frysinger wrote:
> On Saturday 18 August 2012 08:22:51 Zhi-zhou Zhang wrote:
>> On Sat, Aug 18, 2012 at 3:31 AM, Mike Frysinger wrote:
>> > On Friday 17 August 2012 11:30:44 Zhizhou Zhang wrote:
>> > > --- a/arch/mips/config.mk
>> > > +++ b/arch/mips/config.mk
>> > >
>> > > +ifeq
Dear Łukasz Dałek,
[...]
The following comment still doesn't seem right.
> +/*
> --
> - + * endpoint related parts of the api to the usb controller hardware, +
> * used by gadget driver; and the inner talker-to-hardware
On 8/18/12, Mike Frysinger wrote:
> On Saturday 18 August 2012 08:22:51 Zhi-zhou Zhang wrote:
>> On Sat, Aug 18, 2012 at 3:31 AM, Mike Frysinger wrote:
>> > On Friday 17 August 2012 11:30:44 Zhizhou Zhang wrote:
>> > > --- a/arch/mips/config.mk
>> > > +++ b/arch/mips/config.mk
>> > >
>> > > +ifeq
Hi Stefano,
> >> #define MXC_GPIO_PORT_TO_NUM(port, bit) (((port - 1) << 5) + (bit
> >> &
> >> 0x1f))
> >
> > Keeping this is also useless. GPIO_NUMBER() from the new
> >
> > can be used instead everywhere needed.
>
> That is right - I drop it.
I don't know if you are aware of it, but just
Dear Fabio Estevam,
> From: Fabio Estevam
>
> commit d92591a (mxs: Convert sys_proto.h prefixes to 'mxs') introduced
> a mxs_dram_init() function, which is not used anywhere.
>
> Fix it, so that the following warning goes away:
>
> mx28evk.c: In function ‘dram_init’:
> mx28evk.c:67:2: warning:
Dear Fabio Estevam,
> From: Fabio Estevam
>
> There is no need to undef an option that is not enabled by default.
>
> Signed-off-by: Fabio Estevam
> ---
> include/configs/mx28evk.h |1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.
From: Fabio Estevam
commit d92591a (mxs: Convert sys_proto.h prefixes to 'mxs') introduced
a mxs_dram_init() function, which is not used anywhere.
Fix it, so that the following warning goes away:
mx28evk.c: In function ‘dram_init’:
mx28evk.c:67:2: warning: implicit declaration of function ‘mx28
From: Fabio Estevam
There is no need to undef an option that is not enabled by default.
Signed-off-by: Fabio Estevam
---
include/configs/mx28evk.h |1 -
1 file changed, 1 deletion(-)
diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h
index 4e70617..b677e51 100644
--- a/inc
Dear Steve Heckman,
> Oh yeah, forgot about that...;)
>
> I just downloaded the ext4 branch tarball and built it.
>
> The test_unit_ready calls were still in there.
>
> With or without those it took 0m 45s to load a ~150MB image.
>
> In our original branch (2011.12), the test_unit_ready calls
Dear Jim Shimer,
> Hi Marek,
>
> I looked at the ext4 branch. It looks like he has the patch to remove the
> usb_test_unit_ready() calls which were not needed. Actually those calls are
> commented out on that branch:
> #if 0
> if (usb_test_unit_ready(srb, ss)) {
> printf(
Dear Łukasz Dałek,
> Signed-off-by: Łukasz Dałek
[...]
> +/*
> + * Intel(R) PXA255 Processor Specification Update (page 31)
> + * define new "must be one" bits in UDCCFR
> + */
I adjusted this a bit.
> +#define UDCCFR_MB1 (0xff & ~(UDCCFR_AREN | UDCCFR_ACM))
> +
> +#define UFNRH_SIR
Dear Fabio Estevam,
> Hi Stefano,
>
> On Sat, Aug 18, 2012 at 12:26 PM, Stefano Babic wrote:
> > +#define GPIO_NUMBER(port, index)
> > port)-1)*32)+((index)&31))
>
> What about calling this macro IMX_GPIO_NR instead?
>
> This way we can have the same macro name in U-boot and
Dear stefano babic,
> Am 19/08/2012 00:28, schrieb Otavio Salvador:
> > On Sat, Aug 18, 2012 at 7:06 PM, Marek Vasut wrote:
> >> Dear Otavio Salvador,
> >>
> >>> On Sat, Aug 18, 2012 at 3:03 PM, Marek Vasut
wrote:
> I think we should try and see if the mx28 and mx23 .bd can't be
> co
Hi Stefano,
On Sat, Aug 18, 2012 at 12:26 PM, Stefano Babic wrote:
> +#define GPIO_NUMBER(port, index) port)-1)*32)+((index)&31))
What about calling this macro IMX_GPIO_NR instead?
This way we can have the same macro name in U-boot and in the kernel.
Thanks,
Fabio Estevam
_
Am 19/08/2012 00:29, schrieb Marek Vasut:
> Dear Matt Sealey,
>
>> On Sat, Aug 18, 2012 at 10:34 AM, Stefano Babic wrote:
>>> On 17/08/2012 20:19, Matt Sealey wrote:
The i.MX Boot ROM lets us set up certain registers before U-Boot even
gets executed. Rather than setting up DDR, putting
Am 19/08/2012 00:28, schrieb Otavio Salvador:
> On Sat, Aug 18, 2012 at 7:06 PM, Marek Vasut wrote:
>> Dear Otavio Salvador,
>>
>>> On Sat, Aug 18, 2012 at 3:03 PM, Marek Vasut wrote:
I think we should try and see if the mx28 and mx23 .bd can't be converged
together too. Remind me in th
Am 18/08/2012 23:18, schrieb Matt Sealey:
>
> I will, for now it's the top of Linus' tree, but this code is going to
> get removed from the Linux kernel soon, so I understand, we need to
> figure out where it will last forever (probably linux-stable@3.5) so
> we can always reference it.
Right. A
Am 18/08/2012 23:11, schrieb Matt Sealey:
>>> @@ -1,7 +1,7 @@
>>> #
>>> +# Copyright (C) 2009 Pegatron Corporation
>> ^---
>>
>> Was this added for mistake ? I think you should add only yours.
>
> The drive strength settings came from Pegatron a long, long time ago
> (2009 :)
Am 18/08/2012 23:02, schrieb Matt Sealey:
> On Sat, Aug 18, 2012 at 10:50 AM, Stefano Babic wrote:
>> On 17/08/2012 20:19, Matt Sealey wrote:
>>
>> Anyway, who will maintain the efikas in future ? Marek, do you hold it,
>> or Matt will take this job ?
>
> I can't test every patch
> everyone sends
Dear Matt Sealey,
> On Sat, Aug 18, 2012 at 10:34 AM, Stefano Babic wrote:
> > On 17/08/2012 20:19, Matt Sealey wrote:
> >> The i.MX Boot ROM lets us set up certain registers before U-Boot even
> >> gets executed. Rather than setting up DDR, putting U-Boot in place, and
> >> getting into pre-relo
On Sat, Aug 18, 2012 at 7:06 PM, Marek Vasut wrote:
> Dear Otavio Salvador,
>
>> On Sat, Aug 18, 2012 at 3:03 PM, Marek Vasut wrote:
>> > I think we should try and see if the mx28 and mx23 .bd can't be converged
>> > together too. Remind me in the evening (~4-5 hours from now) to try it.
>>
>> We
Dear Matt Sealey,
> On Sat, Aug 18, 2012 at 10:50 AM, Stefano Babic wrote:
> > On 17/08/2012 20:19, Matt Sealey wrote:
> >
> > Anyway, who will maintain the efikas in future ? Marek, do you hold it,
> > or Matt will take this job ?
>
> I'll do it but I doubt I'm going to be around as much as Ma
Signed-off-by: Łukasz Dałek
---
arch/arm/include/asm/arch-pxa/regs-usb.h | 160 ++
1 files changed, 160 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/include/asm/arch-pxa/regs-usb.h
diff --git a/arch/arm/include/asm/arch-pxa/regs-usb.h
b/arch/arm/includ
Am 18/08/2012 21:25, schrieb Benoît Thébaudeau:
>> #define MXC_GPIO_PORT_TO_NUM(port, bit) (((port - 1) << 5) + (bit &
>> 0x1f))
>
> Keeping this is also useless. GPIO_NUMBER() from the new
>
> can be used instead everywhere needed.
That is right - I drop it.
>>
>> -/* GPIO registers */
>
Dear Otavio Salvador,
> On Sat, Aug 18, 2012 at 3:03 PM, Marek Vasut wrote:
> > I think we should try and see if the mx28 and mx23 .bd can't be converged
> > together too. Remind me in the evening (~4-5 hours from now) to try it.
>
> We can try but mx23 cannot use the ivt helper; so we ended hav
Dear Matt Sealey,
> On Sat, Aug 18, 2012 at 2:25 PM, Benoît Thébaudeau
>
> wrote:
> > Hi Stefano,
> >
> > This is a bit off topic, but shouldn't the iomux-v3 stuff be moved to a
> > common location for all these i.MXs too? As to the header file, it's
> > already done, but the C file is under ar
Am 08/08/2012 19:04, schrieb Philippe Reynes:
> This driver has been tested on board armadeus apf27.
>
> Signed-off-by: Philippe Reynes
> ---
Hi Philippe,
> arch/arm/include/asm/arch-mx27/imx-regs.h |3 +
> arch/arm/include/asm/arch-mx27/regs-rtc.h | 40 ++
> drivers/rtc/Make
On Sat, Aug 18, 2012 at 4:46 PM, Benoît Thébaudeau
wrote:
> Hi Matt,
>
>> >> create mode 100644 arch/arm/include/asm/arch-mx5/iomux-mx51.h
>> >>
>> >
>> > As far as I can see iomux-mx51.h is coming from the linux kernel.
>> > Then
>> > please add in the commit message information about which vers
Hi Matt,
> >> create mode 100644 arch/arm/include/asm/arch-mx5/iomux-mx51.h
> >>
> >
> > As far as I can see iomux-mx51.h is coming from the linux kernel.
> > Then
> > please add in the commit message information about which version of
> > the
> > kernel you borrow this code, better add the kerne
On Sat, Aug 18, 2012 at 10:18 AM, Stefano Babic wrote:
> On 17/08/2012 20:16, Matt Sealey wrote:
>> Essentially now we can share code with the MX6 boards, reducing redundant
>> pin definitions across boards and lengthy configuration of external pads
>> on the i.MX51.
>>
>> Signed-off-by: Matt Seal
On Sat, Aug 18, 2012 at 10:34 AM, Stefano Babic wrote:
> On 17/08/2012 20:19, Matt Sealey wrote:
>> The i.MX Boot ROM lets us set up certain registers before U-Boot even gets
>> executed. Rather than setting up DDR, putting U-Boot in place, and getting
>> into pre-relocation init to set up DDR aga
On Sat, Aug 18, 2012 at 10:50 AM, Stefano Babic wrote:
> On 17/08/2012 20:19, Matt Sealey wrote:
>
> Anyway, who will maintain the efikas in future ? Marek, do you hold it,
> or Matt will take this job ?
I'll do it but I doubt I'm going to be around as much as Marek. What
I'm a little fearful of
On Sat, Aug 18, 2012 at 2:25 PM, Benoît Thébaudeau
wrote:
> Hi Stefano,
>
> This is a bit off topic, but shouldn't the iomux-v3 stuff be moved to a common
> location for all these i.MXs too? As to the header file, it's already done,
> but
> the C file is under arch/arm/cpu/armv7/imx-common/ while
On Sat, Aug 18, 2012 at 07:15:56AM -0700, Tom Rini wrote:
> On Sat, Aug 18, 2012 at 08:28:55AM +0200, Albert ARIBAUD wrote:
> > Hi Tom,
> >
> > On Fri, 17 Aug 2012 14:52:01 -0700, Tom Rini wrote:
> >
> > > Hello,
> > >
> > > This replaces my previous pull-request and is new warning free on
> >
Hi Stefano,
> Each i.MX has its own gpio.h, defining the same structure.
> The internal GPIO controller has the same layout
> (at least for the register used by u-boot) and can be shared.
Good!
>
> Signed-off-by: Stefano Babic
> CC: Matt Sealey
> CC: Marek Vasut
> CC: Benoit Thebaudeau
> CC
On 08/13/2012 06:23 PM, Scott Wood wrote:
> On 08/13/2012 01:10 PM, Matthew McClintock wrote:
>> This change reduces the SPL size by removing the redundant syncs produced
>> by out_be32 and just replies on one final sync
>>
>> Done with:
>>
>> sed -r '/in_be32/b; s/(out_be32)\(([^,]*),\s+(.*)\)/__r
Currently the -PC variants of the P1/P2 RDB boards do not print it on boot --
e.g. a P2020RDB-PC will claim to be a plain P2020RDB. Besides being incorrect,
this can confuse a user into building U-Boot for P2020RDB rather than
P2020RDB-PC,
resulting in a board that does not boot.
P1024RDB and P1
On Sat, Aug 18, 2012 at 3:03 PM, Marek Vasut wrote:
> I think we should try and see if the mx28 and mx23 .bd can't be converged
> together too. Remind me in the evening (~4-5 hours from now) to try it.
We can try but mx23 cannot use the ivt helper; so we ended having a
specific file for each proc
Dear Otavio Salvador,
> For i.MX233 addition the base registers need to be change so the SoC
> definition needs to be known before the header include.
>
> The following boards has been changed:
>
> * apx4devkit
> * m28evk
> * mx28evk
> * sc_sps_1
>
> Signed-off-by: Otavio Salvador
> Acked-
Dear Otavio Salvador,
> The elftosb call needs to use a target param specific for i.MX28. This
> patch allow for later addition of i.MX233.
>
> Signed-off-by: Otavio Salvador
> ---
> Changes in v2:
> - fix Makefile according
> - move u-boot.bd to u-boot-imx28.bd
>
> Makefile
When writting the changelog of a series it is expect that this order
is going to be respected.
The sorting can make it out of context of the order had a meaning for
the reader so this patch remove the sort of items.
Signed-off-by: Otavio Salvador
---
tools/patman/series.py |2 +-
1 file cha
Specially when many revisions are need for a patchset, the most
interesting information is about the last set of changes so we output
the changelog in reverse order to easy identification of most recent
change set.
Signed-off-by: Otavio Salvador
---
tools/patman/series.py |8
1 file
On Fri, Aug 17, 2012 at 6:35 PM, Simon Glass wrote:
> On Fri, Aug 17, 2012 at 1:14 PM, Otavio Salvador
> wrote:
>> On Fri, Aug 17, 2012 at 5:01 PM, Tom Rini wrote:
>>> It looks like today was the day that Joe and I both decided to give
>>> patman a whirl. On IRC we both hit the same annoyance o
For i.MX233 addition the base registers need to be change so the SoC
definition needs to be known before the header include.
The following boards has been changed:
* apx4devkit
* m28evk
* mx28evk
* sc_sps_1
Signed-off-by: Otavio Salvador
Acked-by: Stefano Babic
---
Changes in v2:
- no chan
The elftosb call needs to use a target param specific for i.MX28. This
patch allow for later addition of i.MX233.
Signed-off-by: Otavio Salvador
---
Changes in v2:
- fix Makefile according
- move u-boot.bd to u-boot-imx28.bd
Makefile |5 -
In case an address is listed in the To list, those will be skipped on
Cc list or user might end with a duplicated message.
This fixes the case when a tag points to same address used as series
destination thus avoiding duplicated sending.
Signed-off-by: Otavio Salvador
---
Changes in v2:
- use if
In case an address is listed in the To list, those will be skipped on
Cc list or user might end with a duplicated message.
This fixes the case when a tag points to same address used as series
destination thus avoiding duplicated sending.
Signed-off-by: Otavio Salvador
---
Changes in v2:
- use if
On 17/08/2012 20:19, Matt Sealey wrote:
> Change summary:
>
> * Use iomux-mx51.h include to simplify board configuration.
> * Remove LED toggle function as it had no real users.
> * Red LED is now on for pre-reloc, Blue LED for "in U-Boot"
> * Function renames for readability.
> * Some board ident
On Saturday 18 August 2012 08:22:51 Zhi-zhou Zhang wrote:
> On Sat, Aug 18, 2012 at 3:31 AM, Mike Frysinger wrote:
> > On Friday 17 August 2012 11:30:44 Zhizhou Zhang wrote:
> > > --- a/arch/mips/config.mk
> > > +++ b/arch/mips/config.mk
> > >
> > > +ifeq "$(CPU)" "mips64"
> > > +CONFIG_STANDALONE
On 17/08/2012 20:19, Matt Sealey wrote:
> The i.MX Boot ROM lets us set up certain registers before U-Boot even gets
> executed. Rather than setting up DDR, putting U-Boot in place, and getting
> into pre-relocation init to set up DDR again, just do it once in the correct
> place. This also solves
Each i.MX has its own gpio.h, defining the same structure.
The internal GPIO controller has the same layout
(at least for the register used by u-boot) and can be shared.
Signed-off-by: Stefano Babic
CC: Matt Sealey
CC: Marek Vasut
CC: Benoit Thebaudeau
CC: Jason Liu
---
arch/arm/include/asm/
Dear Otavio Salvador,
> For i.MX233 addition the base registers need to be change so the SoC
> definition needs to be known before the header include.
>
> The following boards has been changed:
>
> * apx4devkit
> * m28evk
> * mx28evk
> * sc_sps_1
>
> Signed-off-by: Otavio Salvador
> ---
>
Dear Otavio Salvador,
> The elftosb call needs to use a target param specific for i.MX28. This
> patch allow for later addition of i.MX233.
>
> Signed-off-by: Otavio Salvador
> ---
> Makefile |5 -
> arch/arm/cpu/arm926ejs/mxs/{u-boot.bd
On 17/08/2012 20:16, Matt Sealey wrote:
> Essentially now we can share code with the MX6 boards, reducing redundant
> pin definitions across boards and lengthy configuration of external pads
> on the i.MX51.
>
> Signed-off-by: Matt Sealey
> ---
Hi Matt,
> arch/arm/include/asm/arch-mx5/iomux-m
On Sat, Aug 18, 2012 at 08:28:55AM +0200, Albert ARIBAUD wrote:
> Hi Tom,
>
> On Fri, 17 Aug 2012 14:52:01 -0700, Tom Rini wrote:
>
> > Hello,
> >
> > This replaces my previous pull-request and is new warning free on
> > MAKEALL -a arm for ELDK4.2/5.1/5.2.1.
> >
> > The following changes since
On Sat, Aug 18, 2012 at 3:31 AM, Mike Frysinger wrote:
> On Friday 17 August 2012 11:30:44 Zhizhou Zhang wrote:
> > --- a/arch/mips/config.mk
> > +++ b/arch/mips/config.mk
> >
> > +ifeq "$(CPU)" "mips64"
> > +CONFIG_STANDALONE_LOAD_ADDR ?= 0xFfffFfff8020 -T mips64.lds
> > +else
> > CONFIG_ST
Hi,
On 08/16/2012 12:43 PM, Nikita Kiryanov wrote:
If the bmp pointer is null (for example because the environment
variable "splashimage" was not defined) then U-Boot will get stuck
when trying to load the image.
Which branch is this? At [1] there is a check for this..
1600 s = getenv(
Am 17.08.2012 13:16, schrieb Alex Zeffertt:
I get the following warning when I boot our openrd based board:
U-Boot 2012.07 (Aug 17 2012 - 10:45:29)
OpenRD-Base
SoC: Kirkwood 88F6281_A1
DRAM: 128 MiB
WARNING: Caches not enabled
NAND: 512 MiB
The warning tells you that the plaform has no imp
Am 17/08/2012 20:15, schrieb Matt Sealey:
> Use calloc() instead of malloc() to allocate the mxc_spi_slave structure.
> Clearing the memory is necessary since most of the time this gets done
> super early in boot, but on warm reboots, and when SPI probing is done
> long after the init stages it cou
Am 17/08/2012 20:15, schrieb Matt Sealey:
> Use calloc() instead of malloc() to allocate the mxs_spi_slave structure.
> Clearing the memory is necessary since most of the time this gets done
> super early in boot, but on warm reboots, and when SPI probing is done
> long after the init stages it cou
Le 18/08/2012 00:44, Zhong Hongbo a écrit :
On 08/18/2012 05:17 AM, Allen Martin wrote:
On Thu, Aug 16, 2012 at 04:03:15PM -0700, Zhong Hongbo wrote:
On 08/17/2012 05:04 AM, Allen Martin wrote:
@@ -167,6 +177,7 @@ stack_setup:
adr r0, _start
cmp r0, r6
+ moveq
61 matches
Mail list logo
