Strata Flash mappings for non continous flash devices

Strata Flash mappings for non continous flash devices

[Raghu]

Hello All, 

I have two I28F640J3C as ( x16 )device, on the IXP425,
mapped at addresses 
"0x50000000" and "0x51000000" with Chip selects CS0
and CS1.
CS0, 0xC4000000 = 0xBFFF3842
CS1, 0xC4000004 = 0xBFFF3842. 

I am able to use the Flash device mapped on CS0, and I
need to use the same Flash routines for CS1 chip.

How can we handle such cases where we have memory hole
since the flash devices are not continously mapped.
Regards,
Raghu.


		
__________________________________ 
Do you Yahoo!? 
Meet the all-new My Yahoo! - Try it today! 
http://my.yahoo.com 
 

Re: Strata Flash mappings for non continous flash devices

[Andrew Lunn]

On Thu, Jan 27, 2005 at 01:32:53AM -0800, Raghu wrote:
> Hello All, 
> 
> I have two I28F640J3C as ( x16 )device, on the IXP425,
> mapped at addresses 
> "0x50000000" and "0x51000000" with Chip selects CS0
> and CS1.
> CS0, 0xC4000000 = 0xBFFF3842
> CS1, 0xC4000004 = 0xBFFF3842. 
> 
> I am able to use the Flash device mapped on CS0, and I
> need to use the same Flash routines for CS1 chip.
> 
> How can we handle such cases where we have memory hole
> since the flash devices are not continously mapped.

The current flash code cannot handle this. 

However there is a new development of the flash code in a CVS branch
can handle this setup. Checkout the cvs branch flash_v2. Note that
this branch is still under development. The interfaces may change etc
and there are probably still bugs...

        Andrew

Dynamic SMP

[Jiri Gaisler]

We are in the processes of adding SMP support to the sparc port.
We have a running system, but I still have a few questions:

1. Is it really necessary to build the kernel for the exact
    number cpu's? We would like to build the kernel for a
    maximum number, e.g. 4, but run it on systems with 1 - 4
    cpu's without re-compiling.

2. If we would do the modifications to run a dynamic number
    of cpu's, would it be accepted into the eCos distribution?
    Or is it likely that we will break to many things which will
    require all other SMP ports to be modified and re-validated?


Jiri.

-- 
--------------------------------------------------------------------------
Gaisler Research, 1:a LÃ¥nggatan 19, 413 27 Goteborg, Sweden, +46-317758650
fax: +46-31421407 email: info@gaisler.com, home page: www.gaisler.com
--------------------------------------------------------------------------

Re: Dynamic SMP

[Nick Garnett]

Jiri Gaisler <jiri@gaisler.com> writes:

> We are in the processes of adding SMP support to the sparc port.
> We have a running system, but I still have a few questions:
> 
> 1. Is it really necessary to build the kernel for the exact
>     number cpu's? We would like to build the kernel for a
>     maximum number, e.g. 4, but run it on systems with 1 - 4
>     cpu's without re-compiling.

You can build the kernel for a maximum number of CPUs and discover at
runtime how many exist. HAL_SMP_CPU_MAX defines the maximum for which
the system is compiled and HAL_SMP_CPU_COUNT() returns the actual
number available at runtime. The code is fairly careful to use the
appropriate macro.

The system should also be able to handle a sparse population of
CPUs. For example if you have CPUs 0 and 2 of four. In that case
HAL_SMP_CPU_COUNT() should return 3 and HAL_SMP_CPU_START() on CPU 1
needs to detect that it is absent and do nothing. The same goes for
HAL_SMP_CPU_RESCHEDULE_INTERRUPT() and
HAL_SMP_CPU_TIMESLICE_INTERRUPT().

However, if you can arrange for the CPUs to appear to be numbered
consecutively, then it will be a lot simpler. Some simple translation
arrays in the HAL would do this with minimal effort and expense.

> 
> 2. If we would do the modifications to run a dynamic number
>     of cpu's, would it be accepted into the eCos distribution?
>     Or is it likely that we will break to many things which will
>     require all other SMP ports to be modified and re-validated?
>

No need, its already there!

-- 
Nick Garnett                                          eCos Kernel Architect
http://www.ecoscentric.com                     The eCos and RedBoot experts
Besuchen Sie uns vom 22.-24.02.05 auf der Embedded World 2005, Stand 11-124
Visit us at Embedded World 2005, Nürnberg, Germany, 22-24 Feb, Stand 11-124

SPARC patch to gcc-3.2.3

[Jiri Gaisler]

[-- Attachment #1: Type: text/plain, Size: 759 bytes --]


I finally managed to track down why gcc-3.x would not create
proper eCos images for sparc targets. It is because the gcc
sparc-elf target has the C++ pragma init_priority disabled by
default! eCos uses this to run the constructors in a
particular order. I have attached a patch if anyone is
interested. With this patch, a tool chain with binutils-2.13,
gcc-3.2.3 and newlib-1.12 is built without problems for
--target=sparc-elf

A pre-built tool-chain for linux hosts (bcc-linux-1.0.9)
is availble from:

http://www.gaisler.se/bin/bcc-linux-1.0.9.tar.bz2

Should be installed in /opt .

The same problem still remains in gcc-3.4.3, but this
gcc version does not build newlib correctly, so sparc
users should stay with gcc-3.2.3 for the time being ...

Jiri.

[-- Attachment #2: gcc-3.2.3-sparc-init-priority.diff --]
[-- Type: text/plain, Size: 485 bytes --]

diff -Naur gcc-3.2.3/gcc/config/sparc/elf.h gcc-3.2.3.new/gcc/config/sparc/elf.h
--- gcc-3.2.3/gcc/config/sparc/elf.h	2002-04-05 09:42:43.000000000 +0200
+++ gcc-3.2.3.new/gcc/config/sparc/elf.h	2005-01-30 17:43:32.000000000 +0100
@@ -56,3 +56,11 @@
 #undef UDIVDI3_LIBCALL
 #undef MODDI3_LIBCALL
 #undef UMODDI3_LIBCALL
+
+/* Undefine this so that attribute((init_priority)) works.  */
+#undef CTORS_SECTION_ASM_OP
+#undef DTORS_SECTION_ASM_OP
+
+#define SUPPORTS_INIT_PRIORITY 1
+
+

Re: SPARC patch to gcc-3.2.3

[Andrew Lunn]

On Sun, Jan 30, 2005 at 11:44:35PM +0100, Jiri Gaisler wrote:
> 
> I finally managed to track down why gcc-3.x would not create
> proper eCos images for sparc targets. It is because the gcc
> sparc-elf target has the C++ pragma init_priority disabled by
> default!

Any idea why? Do the gcc team have a reason for this or is it a bug?
I would of thought other programs would of broken as well, eCos cannot
be the only thing using this feature.

        Andrew

Re: SPARC patch to gcc-3.2.3

[Jiri Gaisler]

Other sparc targets, such as solaris, linux and sparclite-elf
does enable init_priority by default. It is only the basic
sparc-elf that does not have it. I think it is a pure
oversight, probably because there are not many sparc-elf
users (most sparc ecos systems use sparclite).

Jiri.

Andrew Lunn wrote:
> On Sun, Jan 30, 2005 at 11:44:35PM +0100, Jiri Gaisler wrote:
> 
>>I finally managed to track down why gcc-3.x would not create
>>proper eCos images for sparc targets. It is because the gcc
>>sparc-elf target has the C++ pragma init_priority disabled by
>>default!
> 
> 
> Any idea why? Do the gcc team have a reason for this or is it a bug?
> I would of thought other programs would of broken as well, eCos cannot
> be the only thing using this feature.
> 
>         Andrew
> 
> .
> 

Re: SPARC patch to gcc-3.2.3

[Andrew Lunn]

On Mon, Jan 31, 2005 at 12:01:57AM +0100, Jiri Gaisler wrote:
> 
> Other sparc targets, such as solaris, linux and sparclite-elf
> does enable init_priority by default. It is only the basic
> sparc-elf that does not have it. I think it is a pure
> oversight, probably because there are not many sparc-elf
> users (most sparc ecos systems use sparclite).

OK. Is there a gcc bugzilla bug for this? Thats probably the best way
to get it fixed in the next release. (Too lazy to go and look myself:-)

        Andrew