Hi Wolfgang,
On Tue, Jan 3, 2012 at 2:35 PM, Wolfgang Denk wrote:
> Dear Simon Glass,
>
> In message
> you
> wrote:
>>
>> I have brought in PPC to board_f.c and board_r.c but not dealt with
>> relocation. Once I have done that, gone through the new x86 series
>> again and MAKEALL doesn't screa
Dear Simon Glass,
In message
you wrote:
>
> I have brought in PPC to board_f.c and board_r.c but not dealt with
> relocation. Once I have done that, gone through the new x86 series
> again and MAKEALL doesn't scream too loudly I'll do another RFC along
> these lines.
I'm seriously concerned ab
Hi Wolfgang,
On Tue, Jan 3, 2012 at 12:12 AM, Wolfgang Denk wrote:
> Dear Simon Glass,
>
> In message
> you
> wrote:
>>
>> Well let's see how we go with the incremental approach - hopefully we
>> can get the same result with less pain and risk, and not too much
>> work.
>
> Did you miss my pro
Hi Wolfgang,
On 03/01/12 19:12, Wolfgang Denk wrote:
> Dear Simon Glass,
>
> In message
> you
> wrote:
>>
>> Well let's see how we go with the incremental approach - hopefully we
>> can get the same result with less pain and risk, and not too much
>> work.
>
> Did you miss my proposal not to
Dear Simon Glass,
In message
you wrote:
>
> Well let's see how we go with the incremental approach - hopefully we
> can get the same result with less pain and risk, and not too much
> work.
Did you miss my proposal not to change the existing coe for all
boards, but to provide anew implementati
Hi Wolfgang,
On Mon, Jan 2, 2012 at 6:46 AM, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message <4f019473.8000...@gmail.com> you wrote:
>>
>> The problem is not one of how sparsely the test/fix cycles are spread over
>> time, it is one of spreading the breakage over multiple patches - If you
Hi Graham,
On Mon, Jan 2, 2012 at 3:26 AM, Graeme Russ wrote:
> Hi Simon,
>
> In case you haven't noticed (I did not Cc you or Wolfgang, sorry 'bout
> that) I've posted the cleaned up version of my x86 init refactoring...
Yes I see it - thats great thanks. I will go through it and compare.
[big
Dear Graeme Russ,
In message <4f019473.8000...@gmail.com> you wrote:
>
> The problem is not one of how sparsely the test/fix cycles are spread over
> time, it is one of spreading the breakage over multiple patches - If you
> are replacing functionality then add the new functionality, add the hook
Hi Simon,
In case you haven't noticed (I did not Cc you or Wolfgang, sorry 'bout
that) I've posted the cleaned up version of my x86 init refactoring...
On 02/01/12 10:48, Simon Glass wrote:
> Hi Graeme,
>
> On Sat, Dec 31, 2011 at 3:52 AM, Graeme Russ wrote:
>> Hi Simon,
>>
>> On 31/12/11 13:02
Dear Simon Glass,
In message
you wrote:
>
> >> - getting generic relocation working
> >
> > I don;t see why this would be a direct prerequisite here. =A0We want to
> > have that, no boubt about that. =A0But it appears to be an unrelated
> > change to me.
>
> I don't think it's essential, but i
Hi Graeme,
On Sat, Dec 31, 2011 at 3:52 AM, Graeme Russ wrote:
> Hi Simon,
>
> On 31/12/11 13:02, Simon Glass wrote:
>> Hi Graeme,
>>
>> On Fri, Dec 30, 2011 at 7:49 AM, Graeme Russ wrote:
>>> Hi Simon,
>>>
>
> [snip]
>
>>> However, I think this approach is not the right one - and I think the CF
Hi Wolfgang,
On Sat, Dec 31, 2011 at 5:54 PM, Wolfgang Denk wrote:
> Dear Simon Glass,
>
> In message
> you
> wrote:
>>
>> Also it does depend on expectations. I would hope that moving an
>> architecture over would be a fairly small task:
>>
>> - getting generic relocation working
>
> I don;t
Dear Simon Glass,
In message
you wrote:
>
> Also it does depend on expectations. I would hope that moving an
> architecture over would be a fairly small task:
>
> - getting generic relocation working
I don;t see why this would be a direct prerequisite here. We want to
have that, no boubt abo
Hi Simon,
On 31/12/11 13:02, Simon Glass wrote:
> Hi Graeme,
>
> On Fri, Dec 30, 2011 at 7:49 AM, Graeme Russ wrote:
>> Hi Simon,
>>
[snip]
>> However, I think this approach is not the right one - and I think the CFI
>> driver backs me up. Your plan is to create generic code which you want ALL
Hi Graeme,
On Fri, Dec 30, 2011 at 7:49 AM, Graeme Russ wrote:
> Hi Simon,
>
> Sorry for the delay in reviewing this - I've been doing a lot of work on
> the x86 side of things. I now have a working solution to the
> board_init_f_r() / global data clobbering problem which involves having the
> gd
Dear Graeme Russ,
In message <4efddd7d.50...@gmail.com> you wrote:
>
> I honestly think we should get the x86 init sequence patches finalised
> first for several reasons:
>
> - Because x86 is so small, it provides a good test-bed - ELF relocation
>was first finalised on x86 (it came and went
Hi Simon,
Sorry for the delay in reviewing this - I've been doing a lot of work on
the x86 side of things. I now have a working solution to the
board_init_f_r() / global data clobbering problem which involves having the
gd 'variable' as a register like all other arch's. The solution is
non-trivial
Hi Wolfgang,
On Wed, Dec 28, 2011 at 9:30 AM, Wolfgang Denk wrote:
> Dear Simon,
>
> In message <1325054160-24894-1-git-send-email-...@chromium.org> you wrote:
>> This series creates a generic board.c implementation which contains
>> the essential functions of the various arch/xxx/lib/board.c fil
Dear Simon,
In message <1325054160-24894-1-git-send-email-...@chromium.org> you wrote:
> This series creates a generic board.c implementation which contains
> the essential functions of the various arch/xxx/lib/board.c files.
I'll be loking into this deeper when I'm back at work (i. e. starting
w
This series creates a generic board.c implementation which contains
the essential functions of the various arch/xxx/lib/board.c files.
What is the motivation for this change?
1. There is a lot of repeated code in the board.c files. Any change to
things like setting up the baud rate requires a cha
20 matches
Mail list logo
