Wolfgang Denk wrote:
> Dear Ben Warren,
>
> In message <49f2bed7.9070...@gmail.com> you wrote:
>>> - What about patches which are sent immediately after merge window
>>> closed (hours - 1 or 2 days)? I already heard something like 'no
>>> problem if it comes some hours later, if it is fine then
Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 23:01 Fri 24 Apr , Wolfgang Denk wrote:
>> Dear Jean-Christophe PLAGNIOL-VILLARD,
>>
>> In message <20090424200323.gd2...@game.jcrosoft.org> you wrote:
What exactly do you mean by "move the STD API"?
In which way should the "STD API"
Ben Warren wrote:
> Jean-Christophe PLAGNIOL-VILLARD wrote:
>> On 22:40 Fri 24 Apr , Dirk Behme wrote:
>>
>>> Dear Jean-Christophe,
>>>
>>> Jean-Christophe PLAGNIOL-VILLARD wrote:
>>>
On 18:49 Fri 24 Apr , Dirk Behme wrote:
> Sanjeev Premi wrote:
>
Dear Jean-Christophe,
Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 22:40 Fri 24 Apr , Dirk Behme wrote:
>> Dear Jean-Christophe,
>>
>> Jean-Christophe PLAGNIOL-VILLARD wrote:
>>> On 18:49 Fri 24 Apr , Dirk Behme wrote:
Sanjeev Premi wrote:
> The function display_board_info() displ
> -Original Message-
> From: Dirk Behme [mailto:dirk.be...@googlemail.com]
> Sent: Saturday, April 25, 2009 11:05 AM
> To: U-Boot user list; Jean-Christophe PLAGNIOL-VILLARD;
> Premi, Sanjeev; Tom Rix
> Cc: Wolfgang Denk
> Subject: Re: OMAP3: Pending patches
>
>
> Short status update af
Dear Karl,
In message <669754ad0903281214x77796b95x76062f1c428ec...@mail.gmail.com> you
wrote:
>
> I am simply using fdisk under Ubuntu 8.04 and a 2GB SD card, I create a
> primary partition of type 0x83. When I run dumpe2fs it shows an inode size
> of 256 bytes.
I confirm the problem. I finally
On Saturday 25 April 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
> For me when the first version of a [patch] is send after the close of the
> merge and
> it's not a bug fix, then it will go to the next MW. The only exception will be
> if the patch come from an announce or a thread discussion an
Hi Wolfgang,
On Saturday 25 April 2009, Wolfgang Denk wrote:
> in message <200904250555.17450.davi...@pacbell.net> you wrote:
> >
> > I think the questions on this topic reflect a reality that
> > such status updates aren't yet visible enough. (The original
> > question was generic, not ARM-speci
On 19:30 Sat 25 Apr , Wolfgang Denk wrote:
> Dear Jean-Christophe PLAGNIOL-VILLARD,
>
> In message <20090425170829.ga30...@game.jcrosoft.org> you wrote:
> >
> > > - What's about patches that are sent while open merge window or before,
> > > but need some update cycles and are finalized while
Dear Jean-Christophe PLAGNIOL-VILLARD,
In message <20090425170829.ga30...@game.jcrosoft.org> you wrote:
>
> > - What's about patches that are sent while open merge window or before,
> > but need some update cycles and are finalized while rc?
> Depends, if the patch is send just before the merge j
On Sat, Apr 25, 2009 at 11:41:43AM -0500, alfred steele wrote:
> I am using uboot on the MX31 PDk board. I am trying to dump the
> contents of a status register found at location 50004004. This status
> register shows the status of the SDHC( SD card host controller) like
> interrupt , card inser
On 09:07 Sat 25 Apr , Dirk Behme wrote:
> Hi Ben,
>
> Ben Warren wrote:
>> Hi Dirk,
>>
>> On Fri, Apr 24, 2009 at 10:17 PM, Dirk Behme
>> wrote:
>>
>>> Dear Jean-Christophe,
>>>
>>> David Brownell wrote:
>>> ...
>> http://lists.denx.de/pipermail/u-boot/2009-April/050802.html
> the Pa
Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 22:40 Fri 24 Apr , Dirk Behme wrote:
>
>> Dear Jean-Christophe,
>>
>> Jean-Christophe PLAGNIOL-VILLARD wrote:
>>
>>> On 18:49 Fri 24 Apr , Dirk Behme wrote:
>>>
Sanjeev Premi wrote:
> The function display_boa
Hi,
I am using uboot on the MX31 PDk board. I am trying to dump the
contents of a status register found at location 50004004. This status
register shows the status of the SDHC( SD card host controller) like
interrupt , card insertion, card removal etc. According to the MX31
manual, the status re
Hi Wolfgang,
Wolfgang Denk wrote:
> Dear Ben Warren,
>
> In message <49f2bed7.9070...@gmail.com> you wrote:
>
>>> - What about patches which are sent immediately after merge window
>>> closed (hours - 1 or 2 days)? I already heard something like 'no
>>> problem if it comes some hours later, i
Dear David,
in message <200904250555.17450.davi...@pacbell.net> you wrote:
>
> I think the questions on this topic reflect a reality that
> such status updates aren't yet visible enough. (The original
> question was generic, not ARM-specific.)
I'm not going to push this information down people's
Dear Dirk,
In message <49f2f59a.80...@googlemail.com> you wrote:
>
> > While I agree on your comment on flexibility, I strongly repudiate
> > the statement that the MW state is not clearly communicated. Please
> > have a look at http://www.denx.de/wiki/view/U-Boot/ReleaseCycle
>
> Ups, this lin
and fix comment
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD
---
v2:
Fix comment
Best Regards,
J.
common/Makefile |1 +
common/modem.c | 122 +++
lib_arm/board.c | 99
lib_ppc/board.c |
On Saturday 25 April 2009, Wolfgang Denk wrote:
> > Yes. The issue is needing to guess what's up ... so for
> > example, I seem to observe that "merge window closed" must
> > not be the same as "first RC is out", which isn't how the
> > Linux process works. But that's the only example I've
> > se
On 22:40 Fri 24 Apr , Dirk Behme wrote:
> Dear Jean-Christophe,
>
> Jean-Christophe PLAGNIOL-VILLARD wrote:
>> On 18:49 Fri 24 Apr , Dirk Behme wrote:
>>> Sanjeev Premi wrote:
The function display_board_info() displays incorrect
silicon revision - based on the return value from
>>
On 23:01 Fri 24 Apr , Wolfgang Denk wrote:
> Dear Jean-Christophe PLAGNIOL-VILLARD,
>
> In message <20090424200323.gd2...@game.jcrosoft.org> you wrote:
> >
> > > What exactly do you mean by "move the STD API"?
> > >
> > > In which way should the "STD API" be moved, and what exactly is the
>
On 00:14 Sat 25 Apr , Wolfgang Denk wrote:
> Dear Jean-Christophe PLAGNIOL-VILLARD,
>
> In message <20090424215804.gc10...@game.jcrosoft.org> you wrote:
> >
> ...
> > > +#define COPY_BUFFER_LOCATION 0x4000fde0
> > evenif it's soc specific flash support I think they need to be store with
> > t
Wolfgang Denk wrote:
> Dear David Brownell,
>
> In message <200904250105.41050.davi...@pacbell.net> you wrote:
>> Yes. The issue is needing to guess what's up ... so for
>> example, I seem to observe that "merge window closed" must
>> not be the same as "first RC is out", which isn't how the
>> L
Dear Wolfgang,
Wolfgang Denk wrote:
> Dear Ben Warren,
>
> In message <49f2bed7.9070...@gmail.com> you wrote:
>>> - What about patches which are sent immediately after merge window
>>> closed (hours - 1 or 2 days)? I already heard something like 'no
>>> problem if it comes some hours later, if
Dear David Brownell,
In message <200904250105.41050.davi...@pacbell.net> you wrote:
>
> Yes. The issue is needing to guess what's up ... so for
> example, I seem to observe that "merge window closed" must
> not be the same as "first RC is out", which isn't how the
> Linux process works. But that
Dear Ben Warren,
In message <49f2bed7.9070...@gmail.com> you wrote:
>
> > - What about patches which are sent immediately after merge window
> > closed (hours - 1 or 2 days)? I already heard something like 'no
> > problem if it comes some hours later, if it is fine then I will still
> > apply
Dear Dirk,
In message <49f2b6b9.7040...@googlemail.com> you wrote:
>
> > My approach is that once the merge window closes, new patches that are not
> > bug fixes go into 'next', which is for the release after the current one (in
> > this case 07). When the merge window opens again, next goes to
Dear David Brownell,
In message <200904250003.51845.davi...@pacbell.net> you wrote:
>
> Then I'm curious how that dm9000 EEPROM reading bugfix
> landed in net/next ... or is the point that the merge
> window for 2009.05 is still open, since RC1 hasn't yet
> been tagged?
No. End of merge window an
On Saturday 25 April 2009, Ben Warren wrote:
> > Then I'm curious how that dm9000 EEPROM reading bugfix
> > landed in net/next ... or is the point that the merge
> > window for 2009.05 is still open, since RC1 hasn't yet
> > been tagged?
> >
>
> In this case a pretty good argument could be made th
Wolfgang,
David Brownell wrote:
> From: David Brownell
>
> Make the U-Boot dm9000 driver read addresses from EEPROM just
> like Linux does ... read six bytes, instead of reading twelve
> bytes and then discarding every other one.
>
> Using the right Ethernet address is a big win.
>
> Signed-off-b
Hi Dirk,
Dirk Behme wrote:
> Hi Ben,
>
> Ben Warren wrote:
>> Hi Dirk,
>>
>> On Fri, Apr 24, 2009 at 10:17 PM, Dirk Behme
>> wrote:
>>
>>> Dear Jean-Christophe,
>>>
>>> David Brownell wrote:
>>> ...
>> http://lists.denx.de/pipermail/u-boot/2009-April/050802.html
> the Patch series and t
Hi David,
David Brownell wrote:
> On Friday 24 April 2009, Ben Warren wrote:
>
>> My approach is that once the merge window closes, new patches that are not
>> bug fixes go into 'next', which is for the release after the current one (in
>> this case 07).
>>
>
> Then I'm curious how that d
David Brownell wrote:
> On Friday 24 April 2009, Dirk Behme wrote:
>> Btw.: Now that -next exists, I can't find patch linked above in it,
>> though :(
>
> http://git.denx.de/?p=u-boot/u-boot-arm.git;a=shortlog;h=refs/heads/next
>
> shows it ... "respects SKIP_LOWLEVEL_INIT". Make sure
> to lo
Hi Ben,
Ben Warren wrote:
> Hi Dirk,
>
> On Fri, Apr 24, 2009 at 10:17 PM, Dirk Behme wrote:
>
>> Dear Jean-Christophe,
>>
>> David Brownell wrote:
>> ...
> http://lists.denx.de/pipermail/u-boot/2009-April/050802.html
the Patch series and this has been apply in the u-boot-arm/next
>>>
On Friday 24 April 2009, Ben Warren wrote:
> My approach is that once the merge window closes, new patches that are not
> bug fixes go into 'next', which is for the release after the current one (in
> this case 07).
Then I'm curious how that dm9000 EEPROM reading bugfix
landed in net/next ... or
35 matches
Mail list logo
