headers
Rabeeh Khoury | 1 Apr 2002 09:43
Picon

Re: [Ppcboot-users] Another performance patch for EVB64260 (enable CPU_CONF_FAST_CLK for all cpus)

Hi Nye,

The FAST_CLK should be always enabled when using a bus clock equal or 
greater the 100MHz.

Regards,
Rabeeh

Nye Liu wrote:

>Rabeeh at Galileo claims that FAST_CLK should always be enabled.
>
>Enclosed is the patch.
>
>On Tue, Mar 26, 2002 at 02:12:52PM -0800, Nye Liu wrote:
>
>>Patch enclosed relative to LABEL_2002_03_25_0020.
>>
>>Only tested on my galileo board and a 750cx. Untested with all other
>>cpus. If you have a 74xx or 7xx board (even if its non-galileo) please
>>take a peek at this patch as it may affect you.
>>
>>On Tue, Mar 26, 2002 at 01:18:38PM -0800, Nye Liu wrote:
>>
>>>btw. I got a note from Rabeeh from galileo regarding some performance
>>>issues in ppcboot.
>>>
>>>1) gt_cpu_config() is not setting CPU_CONF_PIPELINE in evb64260.c
>>>   He claims it is safe to enable for all cpus.
>>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rabeeh Khoury | 1 Apr 2002 10:36
Picon

Re: [Ppcboot-users] Galileo PIPELINE patch and 74xx_7xx stack-in-cache unlock patch

Nye,

As I understand from the source code, the stack in cache trick works on 
addresses 0x40000000 - 0x40001000.

Theoritcally, what should happen is, when entering the relocate_code 
function, the modfied cache blocks are ONLY at 0x40000000 - 0x40001000 
and few cache blocks containing parts of the data section of the PPCBoot 
(right ?). So what should happen is copying the ppcboot image to DRAM, 
the cache blocks containing the data section should be flushed, the 
cache blocks containing the addresses 0x40000000 - 0x40001000 need to be 
invalidated, and only afterwards unlocking the cache.

Now, today in the relocate_code function, you are using 'dcbst' on the 
cache blocks of the destination address space that will hold the newly 
copied PPCBoot image to DRAM. But you are not cache invaliding the 
0x40000000 - 0x40001000 !

Am I right in this scenario ? Am I missing something here ?

Regards,
Rabeeh

Nye Liu wrote:

>On Wed, Mar 27, 2002 at 03:11:14PM +0200, Rabeeh Khoury wrote:
>
>>Hi Nye,
>>
>>You can not just remove the lock. You need to cache invalidate the
(Continue reading)

Permalink | Reply | 2 comments |
headers
Wolfgang Denk | 1 Apr 2002 10:57
Picon
Picon
Favicon

Re: [Ppcboot-users] Galileo PIPELINE patch and 74xx_7xx stack-in-cache unlock patch

In message <3CA81C1D.9070500 <at> galileo.co.il> you wrote:
>
> Theoritcally, what should happen is, when entering the relocate_code 
> function, the modfied cache blocks are ONLY at 0x40000000 - 0x40001000 
> and few cache blocks containing parts of the data section of the PPCBoot 
> (right ?). So what should happen is copying the ppcboot image to DRAM, 
> the cache blocks containing the data section should be flushed, the 
> cache blocks containing the addresses 0x40000000 - 0x40001000 need to be 
> invalidated, and only afterwards unlocking the cache.

But only if the inital data that was stored in  cache  is  no  longer
referenced; this used to be the case. I remember that I wanted to get
this  fixed,  but  I  have  to  admit  that I lost track of it. So be
careful...

Wolfgang Denk

--

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd <at> denx.de
"We learn from history that we learn nothing from history."
- George Bernard Shaw
Permalink | Reply | 0 comments |
headers
Wolfgang Denk | 1 Apr 2002 10:57
Picon
Picon
Favicon

Re: [Ppcboot-users] Galileo PIPELINE patch and 74xx_7xx stack-in-cache unlock patch

In message <3CA81C1D.9070500 <at> galileo.co.il> you wrote:
>
> Theoritcally, what should happen is, when entering the relocate_code 
> function, the modfied cache blocks are ONLY at 0x40000000 - 0x40001000 
> and few cache blocks containing parts of the data section of the PPCBoot 
> (right ?). So what should happen is copying the ppcboot image to DRAM, 
> the cache blocks containing the data section should be flushed, the 
> cache blocks containing the addresses 0x40000000 - 0x40001000 need to be 
> invalidated, and only afterwards unlocking the cache.

But only if the inital data that was stored in  cache  is  no  longer
referenced; this used to be the case. I remember that I wanted to get
this  fixed,  but  I  have  to  admit  that I lost track of it. So be
careful...

Wolfgang Denk

--

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd <at> denx.de
"We learn from history that we learn nothing from history."
- George Bernard Shaw
Permalink | Reply | 0 comments |
headers
Jerry Van Baren | 1 Apr 2002 18:05

Re: [Ppcboot-users] [PATCH] 405GP i2c ehancements

Hi Wolfgang, Andrew:

The improvements look good to me.  Andrew is primarily working with the 
insides of the I2C code where the GUI2C patch is only touching the external 
interface.  I did see a couple of improvements to the interface code that I 
would support wholeheartedly.

Wolfgang, what is the status of your Sandpoint lab board?  I think I found 
and fixed the write problem (I sent a patch directly to you April 29th).  I 
should be able to squeeze a debug session or two in this week if the 
Sandpoint is available.

gvb

At 10:17 PM 3/31/2002 +0200, Wolfgang Denk wrote:
>In message <20020329140251.D30512 <at> ecam.san.rr.com> you wrote:
> >
> > Here are some changes to the i2c code for the 405gp.
> >
> > It is a pretty major change to the i2c_transfer function
> > and I tried to describe it in more detail in the comment at
> > the start of the function.
>
>Jerry, can  you  please  comment  if  and  how  this  fits  with  the
>not-yet-finished Grand Unifying I2C interface patch?
>
>I rather not touch the same area as long  as  we  haven't  completely
>recovered from the damages done by the previous patches...
>
>Wolfgang Denk
(Continue reading)

Permalink | Reply | 2 comments |
headers
Wolfgang Denk | 1 Apr 2002 20:46
Picon
Picon
Favicon

Re: [Ppcboot-users] [PATCH] 405GP i2c ehancements

Hello,

in message <5.1.0.14.2.20020401094044.021298e0 <at> falcon.si.com> you wrote:
> 
> The improvements look good to me.  Andrew is primarily working with the 
> insides of the I2C code where the GUI2C patch is only touching the external 
> interface.  I did see a couple of improvements to the interface code that I 
> would support wholeheartedly.

OK, so I will try to merhge this later tonight. I'll have no time  to
work on PPCBoot for a couple of days, so I better do this now.

See also the announcement about  our  cleanup  patch  (follows  in  a
couple of minutes).

> Wolfgang, what is the status of your Sandpoint lab board?  I think I found 
> and fixed the write problem (I sent a patch directly to you April 29th).  I 

I nearly missed this patch. Merged it a couple of minutes  ago.  It's
tagged  as LABEL_2002_04_01_2040 on the CVS server. At least it fixes
the compile problems.

> should be able to squeeze a debug session or two in this week if the 
> Sandpoint is available.

The SP8240 is available, but I don't have a BDI free at the moment.
Sorry...

Wolfgang Denk
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wolfgang Denk | 1 Apr 2002 20:46
Picon
Picon
Favicon

Re: [Ppcboot-users] [PATCH] 405GP i2c ehancements

Hello,

in message <5.1.0.14.2.20020401094044.021298e0 <at> falcon.si.com> you wrote:
> 
> The improvements look good to me.  Andrew is primarily working with the 
> insides of the I2C code where the GUI2C patch is only touching the external 
> interface.  I did see a couple of improvements to the interface code that I 
> would support wholeheartedly.

OK, so I will try to merhge this later tonight. I'll have no time  to
work on PPCBoot for a couple of days, so I better do this now.

See also the announcement about  our  cleanup  patch  (follows  in  a
couple of minutes).

> Wolfgang, what is the status of your Sandpoint lab board?  I think I found 
> and fixed the write problem (I sent a patch directly to you April 29th).  I 

I nearly missed this patch. Merged it a couple of minutes  ago.  It's
tagged  as LABEL_2002_04_01_2040 on the CVS server. At least it fixes
the compile problems.

> should be able to squeeze a debug session or two in this week if the 
> Sandpoint is available.

The SP8240 is available, but I don't have a BDI free at the moment.
Sorry...

Wolfgang Denk
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wolfgang Denk | 1 Apr 2002 21:13
Picon
Picon
Favicon

Re: [Ppcboot-users] [PATCH] 405GP i2c ehancements

Dear Andrew,

in message <20020329140251.D30512 <at> ecam.san.rr.com> you wrote:
> 
> Here are some changes to the i2c code for the 405gp.

Added to CVS. Thanks.

Wolfgang Denk

--

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd <at> denx.de
The software required `Windows 95 or better', so I installed Linux.
Permalink | Reply | 0 comments |
headers
Wolfgang Denk | 1 Apr 2002 21:13
Picon
Picon
Favicon

Re: [Ppcboot-users] [PATCH] 405GP i2c ehancements

Dear Andrew,

in message <20020329140251.D30512 <at> ecam.san.rr.com> you wrote:
> 
> Here are some changes to the i2c code for the 405gp.

Added to CVS. Thanks.

Wolfgang Denk

--

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd <at> denx.de
The software required `Windows 95 or better', so I installed Linux.
Permalink | Reply | 0 comments |
headers
Wolfgang Denk | 1 Apr 2002 21:23
Picon
Picon
Favicon

PPCBoot driver cleanup patch

Hi everybody,

we applied some major reorganization of the current PPCBoot  code  to
get  rid  of  a  lot  of  duplicated  code in many board directories.
Instead of re-implementing the same device drivers again  and  again,
all  slightly different and a bit board-specific, we now use a common
"drivers/" directory which is (at the moment)  populated  with  stull
like that:

	Makefile
	dc2114x.c
	eepro100.c
	ns16550.c
	ns87308.c
	pci.c
	pci_auto.c
	pci_indirect.c
	serial.c
	sym53c8xx.c
	w83c553f.c

We have removed the  corresponding  files  from  all  affected  board
directories, trying not to break too much stuff. But obviously we can
test only on that many boards.

The current state is still a bit preliminary, with some minor cleanup
being still under works. But I wanted to get  this  out  as  fast  as
possible to avoid a duplication of efforts.

Please let me know your test results, and send  me  your  patches  as
(Continue reading)

Permalink | Reply | 0 comments |

Gmane