RE: linuxppc_2_4_dev tree

RE: linuxppc_2_4_dev tree

[Cameron, Steve]

Khai Trinh wrote:

> How can I build a kernel image with target filesystem
> mounted via NFS fro mthe dev tree? The dev tree
> doesn't seem to have the target filesystem directory
> structure like the ones distributed by MVista for NFS
> mount.
>

The bitkeeper tree is the kernel only.  A root filesystem
you have to make or get elsewhere.

I've had good luck with the DENX Embedded Linux Development Kit.

Here:  http://www.denx.de/ELDK/
It has a working rootfs that can be mounted via NFS.  You
can then pare that down to make it smaller if you need to.

Busybox and Tinylogin are also useful for creating user-land
to go with your kernel.

http://www.busybox.net/
http://tinylogin.busybox.net/

Busybox can act as init, though the inittab needs to
be a bit different than a regular inittab, if I remember
right.

I found getting a satisfactory rootfs
was not exactly easy.  Not too hard, but a lot of details to
get just right, especially if you need to make it small.  You'll
want to make a script to create your root fs, which you can then use
from a kernel which mounts it by NFS (useful for debugging
applications) or by cramfs/initrd setup where the whole image,
kernel and rootfs, is loaded into RAM.

Hope that helps some.

-- steve

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

MPC860 reorder and invalidate dcache

[Joakim Tjernlund]

Hi

I wonder if the MPC860 really can reorder I/O memory accesses?

I am using JFFS2 FS on Intel Strata flash. I remap the flash with
ioremap_nocache(flash_start, flash_size) and use the resulting address
to access the flash. Whenever a write is performed to the flash I do a
wmb() to enforce ordered writes and that affects performance somewhat.
Is the wmb() required or can I skip it?


Invalidate Data Cache
------------------------
I have noticed that invalidate_dcache_range() performs a 'sync' just before it returns. Why?
Is it not enough to execute 'dcbi' on the affected address space?

Is there a faster way to invalidate the dcache for a big(256KB) area than using invalidate_dcache_range().
The area is PAGE aligned.

 Regards
           Jocke


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: MPC860 reorder and invalidate dcache

[Dan Malek]

Joakim Tjernlund wrote:

> I wonder if the MPC860 really can reorder I/O memory accesses?

I don't believe so.  I have sloppily written code that would have
shown problems if it did, and have never seen it occur.

> .... affects performance somewhat.
> Is the wmb() required or can I skip it?

Can you actually quantify the performance difference and is it important?
I would strongly recommend using all of the proper memory/IO barriers since
you never know what will happen with a new version of processor.  It is
also nice to do this for someone that may wish to use the code in a more
general manner. :-)


> Is there a faster way to invalidate the dcache for a big(256KB) area than using invalidate_dcache_range().
> The area is PAGE aligned.

There are cache operations using SPRs unique to the 8xx that can do this, however,
I'm not sure it saves much over using the standard PowerPC functions. They are mostly
useful during initialization and for special static MMU applications.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: MPC860 reorder and invalidate dcache

[Joakim Tjernlund]

> Joakim Tjernlund wrote:
>
> > I wonder if the MPC860 really can reorder I/O memory accesses?
>
> I don't believe so.  I have sloppily written code that would have
> shown problems if it did, and have never seen it occur.
>
> > .... affects performance somewhat.
> > Is the wmb() required or can I skip it?
>
> Can you actually quantify the performance difference and is it important?

I could do a number of "time cp file1 file2" to measure the difference.
We do  logging every 15 min and SW upgrades. It would be nice if this went a little faster.

> I would strongly recommend using all of the proper memory/IO barriers since
> you never know what will happen with a new version of processor.  It is
> also nice to do this for someone that may wish to use the code in a more
> general manner. :-)

Point taken, but this is in the mtd flash map file which defines the layout of our flash in our custom board
so I don't think there is much to use in a general manner.

I may have some general changes to the enet.c file though, but these needs cleaning first.

>
> > Is there a faster way to invalidate the dcache for a big(256KB) area than using invalidate_dcache_range().
> > The area is PAGE aligned.
>
> There are cache operations using SPRs unique to the 8xx that can do this, however,
> I'm not sure it saves much over using the standard PowerPC functions. They are mostly
> useful during initialization and for special static MMU applications.

OK, maybe it would be faster to just invalidate the whole dcache?
I read somewhere that the 'sync' instruction is an expensive one and I don't understand
why it's used it in invalidate_dcache_range()

Finally(if I may):
Our app consists of a lot of processes that mostly pass messages(UNIX sockets) between eachother.
Do you think it's better to run the CPU in 66/66 MHz or (as we do today) 80/40 MHz?
Would the "pinned TLB" mode be helpful(we have plenty of memory,128MB)?

      Jocke

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: MPC860 reorder and invalidate dcache

[Dan Malek]

Joakim Tjernlund wrote:

> We do  logging every 15 min and SW upgrades. It would be nice if this went a little faster.

Every 15 minutes seems like lots of activity for flash.  Better do some
math based upon your expected product lifetime and ensure the flash will
work for that many write cycles.   A few milliseconds every 15 minutes
doesn't seem to be worth special software.


> I read somewhere that the 'sync' instruction is an expensive one and I don't understand
> why it's used it in invalidate_dcache_range()

You are nit picking details that aren't likely to have any effect on your
system performance.  You need to use 'sync' to ensure the processor pipelines
are drained into cache before you push the lines to memory.  Ensure you have
considered what will happen to your application after you completely invalidate
the cache, as there is more stuff in there than the range of data buffers
you are considering.  It isn't very costly to scan the cache and discover there
isn't as much to be done.  It is more costly to invalidate lines you are using
and reload them.


> Our app consists of a lot of processes that mostly pass messages(UNIX sockets) between eachother.
> Do you think it's better to run the CPU in 66/66 MHz or (as we do today) 80/40 MHz?

You will have to test it with your application.  My experience has been the faster
core speed was always the winner.

> Would the "pinned TLB" mode be helpful(we have plenty of memory,128MB)?

Maybe.  Again you will have to test this.  With that much main memory it
may not be helpful because you have to cover so much kernel space with
page tables anyway.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: MPC860 reorder and invalidate dcache

[Joakim Tjernlund]

>
> Every 15 minutes seems like lots of activity for flash.  Better do some
> math based upon your expected product lifetime and ensure the flash will
> work for that many write cycles.   A few milliseconds every 15 minutes
> doesn't seem to be worth special software.

You are rigth. I will check.
>
>
> > I read somewhere that the 'sync' instruction is an expensive one and I don't understand
> > why it's used it in invalidate_dcache_range()
>
> You are nit picking details that aren't likely to have any effect on your
> system performance.  You need to use 'sync' to ensure the processor pipelines
> are drained into cache before you push the lines to memory.  Ensure you have
> considered what will happen to your application after you completely invalidate
> the cache, as there is more stuff in there than the range of data buffers
> you are considering.  It isn't very costly to scan the cache and discover there
> isn't as much to be done.  It is more costly to invalidate lines you are using
> and reload them.

I do a lot of invalidate_dcache_range(). I have 2 mappings, one cached and one uncached. I
use the cached one when the FS  read data from the flash(this will burst read from
the flash). The other mapping is used for flash commands and to write data to flash.
Each time I read I do a invalidate_dcache_range() to pick up updates made from
the uncached mapping.

I was just hoping that the 'sync' instruction was an "accident", but now I know
better.

>
>
> > Our app consists of a lot of processes that mostly pass messages(UNIX sockets) between eachother.
> > Do you think it's better to run the CPU in 66/66 MHz or (as we do today) 80/40 MHz?
>
> You will have to test it with your application.  My experience has been the faster
> core speed was always the winner.

OK
>
> > Would the "pinned TLB" mode be helpful(we have plenty of memory,128MB)?
>
> Maybe.  Again you will have to test this.  With that much main memory it
> may not be helpful because you have to cover so much kernel space with
> page tables anyway.
OK

Thanks, for bearing with me.

      Jocke

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: MPC860 reorder and invalidate dcache

[Dan Malek]

Joakim Tjernlund wrote:


> ... The other mapping is used for flash commands and to write data to flash.
> Each time I read I do a invalidate_dcache_range() to pick up updates made from
> the uncached mapping.

Why don't you do a single invalidate after the write to cover the region
you just updated?

> I was just hoping that the 'sync' instruction was an "accident", but now I know
> better.

Those of us that have programmed PowerPC all of these years seldom include
a 'sync' instruction by accident.  We are more likely to not use them and
then discover later they are necessary :-)



	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: MPC860 reorder and invalidate dcache

[Joakim Tjernlund]

> > ... The other mapping is used for flash commands and to write data to flash.
> > Each time I read I do a invalidate_dcache_range() to pick up updates made from
> > the uncached mapping.
>
> Why don't you do a single invalidate after the write to cover the region
> you just updated?

You read my mind :-). I tried this once before but failed, but that was problably due to
some stupid mistake. Now I am ready to give it another try.

Just to make sure, I only need to invalidate the address space that actually modify
the flash contents?
>
> > I was just hoping that the 'sync' instruction was an "accident", but now I know
> > better.
>
> Those of us that have programmed PowerPC all of these years seldom include
> a 'sync' instruction by accident.  We are more likely to not use them and
> then discover later they are necessary :-)

Amen :-)
But I still think it is a bit strange that you need a sync when you invalidate since all
you want to do is throw away the data in the cache, but what do I know :-)

             Jocke


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/