Hi Graeme,
On Wed, Feb 8, 2012 at 7:38 PM, Graeme Russ wrote:
> Hi Simon,
>
> On Wed, Feb 8, 2012 at 6:12 PM, Simon Glass wrote:
>
>> Also make sure that the I-Cache is on as early as possible. Relocation
>> is done with the d-cache off so is slow. Takes about 40ms for me from
>
> Have a close l
Hi Simon,
On Wed, Feb 8, 2012 at 6:12 PM, Simon Glass wrote:
> Also make sure that the I-Cache is on as early as possible. Relocation
> is done with the d-cache off so is slow. Takes about 40ms for me from
Have a close look at the latest x86 patches (not yet pulled into mainline)
as an example
Hi Simon,
On Wed, Feb 8, 2012 at 6:12 PM, Simon Glass wrote:
> Hi Dirk,
>
> But turning on the cache should be trivial - it is already supported
> so you just need to implement the enable_dcache() function(?) I think.
>
> Also make sure that the I-Cache is on as early as possible. Relocation
> i
Dear Dirk Behme,
In message <4f321b8c.3090...@de.bosch.com> you wrote:
>
> > - They are not actually talking about relocation at all.
> > - They don't base their accessment on any real, measured timings, or
> > otherwise they would start optimizing completely different areas of
> > the code.
>
On 08.02.2012 08:12, Simon Glass wrote:
Hi Dirk,
On Tue, Feb 7, 2012 at 10:51 PM, Dirk Behme wrote:
On 08.02.2012 00:36, Wolfgang Denk wrote:
Dear Graeme Russ,
In message
you
wrote:
If SPL was to determing the relocation address, it would also have to
read the environment, because there ar
Hi Dirk,
On Tue, Feb 7, 2012 at 10:51 PM, Dirk Behme wrote:
> On 08.02.2012 00:36, Wolfgang Denk wrote:
>>
>> Dear Graeme Russ,
>>
>> In message
>> you
>> wrote:
If SPL was to determing the relocation address, it would also have to
read the environment, because there are a number
On 08.02.2012 00:36, Wolfgang Denk wrote:
Dear Graeme Russ,
In message
you wrote:
If SPL was to determing the relocation address, it would also have to
read the environment, because there are a number of environment
variables which can cause (dynamically) the relocation address to
change.
Bu
On 08.02.2012 00:48, Graeme Russ wrote:
Hi Wolfgang,
On Wed, Feb 8, 2012 at 10:36 AM, Wolfgang Denk wrote:
Dear Graeme Russ,
In message
you wrote:
If SPL was to determing the relocation address, it would also have to
read the environment, because there are a number of environment
variables
Hi Wolfgang,
On Wed, Feb 8, 2012 at 10:36 AM, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message
> you
> wrote:
>>
>> > If SPL was to determing the relocation address, it would also have to
>> > read the environment, because there are a number of environment
>> > variables which can cause
Dear Graeme Russ,
In message
you wrote:
>
> > If SPL was to determing the relocation address, it would also have to
> > read the environment, because there are a number of environment
> > variables which can cause (dynamically) the relocation address to
> > change.
>
> But this is not neccessa
Hi Wolfgang,
On Wed, Feb 8, 2012 at 10:23 AM, Wolfgang Denk wrote:
> Dear Dirk Behme,
>
> In message <4f30c794.50...@de.bosch.com> you wrote:
>>
>> > Also, if SPL can determine total SDRAM, copy U-Boot to the final location
>> > and perform the relocations, there is no need for relocation to be d
Dear Dirk Behme,
In message <4f30c794.50...@de.bosch.com> you wrote:
>
> > Also, if SPL can determine total SDRAM, copy U-Boot to the final location
> > and perform the relocations, there is no need for relocation to be done by
> > U-Boot. As I understand it, SPL loads U-Boot into a fixed address
Hi Simon,
On 02/06/2012 10:41 AM, Simon Glass wrote:
> Hi Graeme,
>
> On Sun, Feb 5, 2012 at 3:37 PM, Graeme Russ wrote:
>> Hi Simon
>>
>> On Mon, Feb 6, 2012 at 10:32 AM, Simon Glass wrote:
>>> Hi Graeme,
[snip]
>>> Which reminds me - did you do that pull request for your x86 refactor?
>>> I
On Monday 06 February 2012 08:19 PM, Tom Rini wrote:
On Mon, Feb 6, 2012 at 1:43 AM, Graeme Russ wrote:
Hi Wolfgang,
On 02/06/2012 06:51 PM, Wolfgang Denk wrote:
Dear Graeme Russ,
In message
you wrote:
I think the immediate focus should be on centralising the init sequence
processing int
On 06.02.2012 22:17, Albert ARIBAUD wrote:
Le 06/02/2012 20:27, Mike Frysinger a écrit :
On Monday 06 February 2012 09:49:27 Tom Rini wrote:
On Mon, Feb 6, 2012 at 1:43 AM, Graeme Russ wrote:
On 02/06/2012 06:51 PM, Wolfgang Denk wrote:
Graeme Russ wrote:
I think the immediate focus should b
On 06.02.2012 21:25, Graeme Russ wrote:
Hi Mike,
On Tue, Feb 7, 2012 at 6:27 AM, Mike Frysinger wrote:
On Monday 06 February 2012 09:49:27 Tom Rini wrote:
On Mon, Feb 6, 2012 at 1:43 AM, Graeme Russ wrote:
On 02/06/2012 06:51 PM, Wolfgang Denk wrote:
Graeme Russ wrote:
I think the immediat
Dear Albert ARIBAUD,
In message <4f304376.3020...@aribaud.net> you wrote:
>
> Now if the platform is static and has a preloader of sorts, then one can
> predict (or just observe) where U-Boot would want to relocate, and set
> the preloader once and for all (for a given release of U-Boot, that is)
Le 06/02/2012 20:27, Mike Frysinger a écrit :
On Monday 06 February 2012 09:49:27 Tom Rini wrote:
On Mon, Feb 6, 2012 at 1:43 AM, Graeme Russ wrote:
On 02/06/2012 06:51 PM, Wolfgang Denk wrote:
Graeme Russ wrote:
I think the immediate focus should be on centralising the init sequence
processi
Hi Mike,
On Tue, Feb 7, 2012 at 6:27 AM, Mike Frysinger wrote:
> On Monday 06 February 2012 09:49:27 Tom Rini wrote:
>> On Mon, Feb 6, 2012 at 1:43 AM, Graeme Russ wrote:
>> > On 02/06/2012 06:51 PM, Wolfgang Denk wrote:
>> >> Graeme Russ wrote:
>> >>> I think the immediate focus should be on cen
On Mon, Feb 6, 2012 at 12:27 PM, Mike Frysinger wrote:
> On Monday 06 February 2012 09:49:27 Tom Rini wrote:
>> On Mon, Feb 6, 2012 at 1:43 AM, Graeme Russ wrote:
>> > On 02/06/2012 06:51 PM, Wolfgang Denk wrote:
>> >> Graeme Russ wrote:
>> >>> I think the immediate focus should be on centralising
On Monday 06 February 2012 09:49:27 Tom Rini wrote:
> On Mon, Feb 6, 2012 at 1:43 AM, Graeme Russ wrote:
> > On 02/06/2012 06:51 PM, Wolfgang Denk wrote:
> >> Graeme Russ wrote:
> >>> I think the immediate focus should be on centralising the init sequence
> >>> processing into /common/init.c and th
On Mon, Feb 6, 2012 at 1:43 AM, Graeme Russ wrote:
> Hi Wolfgang,
>
> On 02/06/2012 06:51 PM, Wolfgang Denk wrote:
>> Dear Graeme Russ,
>>
>> In message
>> you
>> wrote:
>>>
>>> I think the immediate focus should be on centralising the init sequence
>>> processing into /common/init.c and then b
Hi Wolfgang,
On 02/06/2012 06:51 PM, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message
> you
> wrote:
>>
>> I think the immediate focus should be on centralising the init sequence
>> processing into /common/init.c and then bringing the new'initcall'
>> architecture online
>
> Agreed.
>
Dear Graeme Russ,
In message
you wrote:
>
> I think the immediate focus should be on centralising the init sequence
> processing into /common/init.c and then bringing the new'initcall'
> architecture online
Agreed.
> Once these have been done, any board can just specific:
>
> SKIP_INIT(RELOC
Hi Simon,
On Mon, Feb 6, 2012 at 10:41 AM, Simon Glass wrote:
> Hi Graeme,
>
> On Sun, Feb 5, 2012 at 3:37 PM, Graeme Russ wrote:
>> Hi Simon
>>
[snip]
>> Sorry for the dealy, but hopefully I'll have it all sorted by the end of
>> the week
>
> OK thanks for the update. Would be keen to get my
Hi Graeme,
On Sun, Feb 5, 2012 at 3:37 PM, Graeme Russ wrote:
> Hi Simon
>
> On Mon, Feb 6, 2012 at 10:32 AM, Simon Glass wrote:
>> Hi Graeme,
>>
>> On Sun, Feb 5, 2012 at 3:23 PM, Graeme Russ wrote:
>>> Hi Wolfgang, Simon,
>>>
>>> On Mon, Feb 6, 2012 at 9:44 AM, Wolfgang Denk wrote:
Dear
Hi Simon
On Mon, Feb 6, 2012 at 10:32 AM, Simon Glass wrote:
> Hi Graeme,
>
> On Sun, Feb 5, 2012 at 3:23 PM, Graeme Russ wrote:
>> Hi Wolfgang, Simon,
>>
>> On Mon, Feb 6, 2012 at 9:44 AM, Wolfgang Denk wrote:
>>> Dear Simon Glass,
>>>
>>> In message
>>> you
>>> wrote:
This patch
Hi Graeme,
On Sun, Feb 5, 2012 at 3:23 PM, Graeme Russ wrote:
> Hi Wolfgang, Simon,
>
> On Mon, Feb 6, 2012 at 9:44 AM, Wolfgang Denk wrote:
>> Dear Simon Glass,
>>
>> In message
>> you
>> wrote:
>>>
>>> This patch shows how to do this sort of thing on ARM. I would like to
>>> see this featur
Hi Wolfgang,
On Sun, Feb 5, 2012 at 2:44 PM, Wolfgang Denk wrote:
> Dear Simon Glass,
>
> In message
> you
> wrote:
>>
>> This patch shows how to do this sort of thing on ARM. I would like to
>> see this feature in mainline, but it makes more sense to do it
>> properly if/when generic relocati
Hi Wolfgang, Simon,
On Mon, Feb 6, 2012 at 9:44 AM, Wolfgang Denk wrote:
> Dear Simon Glass,
>
> In message
> you
> wrote:
>>
>> This patch shows how to do this sort of thing on ARM. I would like to
>> see this feature in mainline, but it makes more sense to do it
>> properly if/when generic r
Dear Simon Glass,
In message
you wrote:
>
> This patch shows how to do this sort of thing on ARM. I would like to
> see this feature in mainline, but it makes more sense to do it
> properly if/when generic relocation is in. Then it will automatically
> work for all archs. For now it is a useful
Hi Mike, Wolfgang,
On Sun, Feb 5, 2012 at 12:38 PM, Mike Frysinger wrote:
> On Sunday 05 February 2012 07:05:13 Marek Vasut wrote:
>> > On Sunday 05 February 2012 01:44:19 Simon Glass wrote:
>> > > This permits disabling the code relation in U-Boot which is useful when
>> > > debugging with an IC
On Sunday 05 February 2012 07:05:13 Marek Vasut wrote:
> > On Sunday 05 February 2012 01:44:19 Simon Glass wrote:
> > > This permits disabling the code relation in U-Boot which is useful when
> > > debugging with an ICE.
> > >
> > > To use it define CONFIG_SYS_SKIP_ARM_RELOCATION in your board.
>
Dear Simon Glass,
In message <1328424259-12914-1-git-send-email-...@chromium.org> you wrote:
> This permits disabling the code relation in U-Boot which is useful when
> debugging with an ICE.
>
> To use it define CONFIG_SYS_SKIP_ARM_RELOCATION in your board.
>
> Signed-off-by: Simon Glass
NAK.
> This permits disabling the code relation in U-Boot which is useful when
> debugging with an ICE.
>
> To use it define CONFIG_SYS_SKIP_ARM_RELOCATION in your board.
>
> Signed-off-by: Simon Glass
> ---
> arch/arm/config.mk |2 ++
> arch/arm/cpu/armv7/start.S |3
> On Sunday 05 February 2012 01:44:19 Simon Glass wrote:
> > This permits disabling the code relation in U-Boot which is useful when
> > debugging with an ICE.
> >
> > To use it define CONFIG_SYS_SKIP_ARM_RELOCATION in your board.
>
> any reason for "ARM" in there ?
Because this is only for ARM?
On Sunday 05 February 2012 01:44:19 Simon Glass wrote:
> This permits disabling the code relation in U-Boot which is useful when
> debugging with an ICE.
>
> To use it define CONFIG_SYS_SKIP_ARM_RELOCATION in your board.
any reason for "ARM" in there ?
-mike
signature.asc
Description: This is a
This permits disabling the code relation in U-Boot which is useful when
debugging with an ICE.
To use it define CONFIG_SYS_SKIP_ARM_RELOCATION in your board.
Signed-off-by: Simon Glass
---
arch/arm/config.mk |2 ++
arch/arm/cpu/armv7/start.S |3 +--
arch/arm/incl
38 matches
Mail list logo
