headers
Zaahir | 1 Dec 2008 05:45
Picon

Strata Flash access problem

Hello,

Thanks for ur support I was able to modify the platform.h file.
I am using customized iMx27ADS board.
Using Redboot src provided by FreeScale.

Version-----> 
(redboot_200749)
(Non-certified release, version FSL 200749
Platform: MX27 ADS/EVB (Freescale i.MX27 based) PASS 2.1 [x32 SDR])

With that support (platform.h) modification.
we are able to detect Intel Strata Flash  JS48F4400VB00s.
Its a 64MB (2-die)  flash. Each die of 32MB

We are able to accesses  Lower 32MB of Flash (0xC000 0000 - 0xC1FFFFFF).

Our flash is address from 0xC000 0000 to 0xC400 0000

When we are trying to access upper 32MB getting error illegal memory 
access .

... Unlock from 0xc3fe0000-0xc4000000: ** command abort - illegal memory 
access?

... Erase from 0xc2000000-0xc2020000: ** command abort - illegal memory 
access?

Please help !!!!!
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andrew Lunn | 1 Dec 2008 06:55
Picon

Re: Strata Flash access problem

On Mon, Dec 01, 2008 at 10:15:24AM +0530, Zaahir wrote:
> Hello,
>
> Thanks for ur support I was able to modify the platform.h file.
> I am using customized iMx27ADS board.
> Using Redboot src provided by FreeScale.
>
> Version-----> (redboot_200749)
> (Non-certified release, version FSL 200749
> Platform: MX27 ADS/EVB (Freescale i.MX27 based) PASS 2.1 [x32 SDR])
>
> With that support (platform.h) modification.
> we are able to detect Intel Strata Flash  JS48F4400VB00s.
> Its a 64MB (2-die)  flash. Each die of 32MB
>
> We are able to accesses  Lower 32MB of Flash (0xC000 0000 - 0xC1FFFFFF).
>
> Our flash is address from 0xC000 0000 to 0xC400 0000
>
> When we are trying to access upper 32MB getting error illegal memory  
> access .
>
> ... Unlock from 0xc3fe0000-0xc4000000: ** command abort - illegal memory  
> access?
>
> ... Erase from 0xc2000000-0xc2020000: ** command abort - illegal memory  
> access?

Probably your MMU is blocking access.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nick Garnett | 1 Dec 2008 11:06
Favicon

Re: Re: Alpha release eCos NAND Flash, eCos YAFFS

"Gábor Török" <tgabor84 <at> gmail.com> writes:

> On Sun, Nov 30, 2008 at 11:53 AM, Andrew Lunn <andrew <at> lunn.ch> wrote:
> > On Fri, Nov 28, 2008 at 01:30:23AM +0100, Rutger Hofman wrote:
> >> Last time I visited a conference, everybody spoke about 'Release early,
> >> release often'.
> >>
> >> Here comes an alpha release of the eCos NAND Flash library and the eCos
> >> YAFFS wrapper library (r536 of our repository).
> >
> > Thanks for showing us the code at this early state. I just started
> > browsing through it.
> >
> > ... ...
> >
> >
> > The idea of generic GPIO functions needs to be discussed in the bigger
> > context. More likely these need to be HAL macros, CYG_HAL_GPIO_SET().
> > We want these to be fast as generally they are just two or three
> > assembly instructions. Doing a function call is too expensive in most
> > cases. You also need a generic way to address pins. The AT91 var hal
> > has some ideas here.
> >
> 
> I think also that generic GPIO woukld be a good idea. This would
> simplify writing generic drivers, etc.

I've looked at this several times and decided that it does not make
sense.  The problem with a generic API is that GPIO pins have a large
number of properties. Different manufacturers have wildy different
(Continue reading)

Permalink | Reply | 0 comments |
headers
abhishek srivastava | 1 Dec 2008 12:09
Picon
Favicon

problem in downloading image files

sir,
i had managed to create gdb_

      Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/

--

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Permalink | Reply | 0 comments |
headers
abhishek srivastava | 1 Dec 2008 12:10
Picon
Favicon

sorry,last post was by mistake


      Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/

--

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Permalink | Reply | 0 comments |
headers
vibisreenivasan | 1 Dec 2008 14:08

any new tool chain for arm (arm-elf-gcc > 3.2.1)

hello ,
	is there any new gcc available for arm other than 
	arm-elf-gcc 3.2.1.
	I am having a problem in compiling jffs2 for arm.

thanks in advance 
vibi sreenivasan

--

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Permalink | Reply | 9 comments |
headers
Tomas Pop | 1 Dec 2008 15:05
Picon
Favicon

Re:[ECOS] any new tool chain for arm (arm-elf-gcc > 3.2.1)


If you are looking for precompiled version, I know about arm-elf-gcc 3.4.4, but I'm not sure It heps you.

It is included in the linuxhost.tar.gz file, let's have a look here:

http://examples.oreilly.com/embsys2/

T.

> ------------ Původní zpráva ------------
> Od: vibisreenivasan <vibi_sreenivasan <at> cms.com>
> Předmět: [ECOS] any new tool chain for arm (arm-elf-gcc > 3.2.1)
> Datum: 01.12.2008 14:46:23
> ----------------------------------------
> hello ,
> 	is there any new gcc available for arm other than
> 	arm-elf-gcc 3.2.1.
> 	I am having a problem in compiling jffs2 for arm.
>
> thanks in advance
> vibi sreenivasan
>
>
>
> --
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>
>
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sergei Gavrikov | 1 Dec 2008 15:41

Re: any new tool chain for arm (arm-elf-gcc > 3.2.1)

On Mon, Dec 01, 2008 at 06:38:05PM +0530, vibisreenivasan wrote:
> hello ,
> 	is there any new gcc available for arm other than 
> 	arm-elf-gcc 3.2.1.
> 	I am having a problem in compiling jffs2 for arm.

There are the latest development gnutools from ecoscentric
ftp://ecos.sourceware.org/pub/ecos/gnutools/

i386linux/ecoscentric-gnutools-arm-eabi-20081107-sw.i386linux.tar.bz2
cygwin/ecoscentric-gnutools-arm-eabi-20081107-sw.cygwin.tar.bz2

Note: you have to set cdl_option CYGBLD_GLOBAL_COMMAND_PREFIX (arm-eabi)
and perhaps fix cdl_option CYGBLD_GLOBAL_CFLAGS.

Look for more information in the November's posts in the list.

Sergei

--

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Permalink | Reply | 7 comments |
headers
Bart Veer | 1 Dec 2008 16:08
Favicon

Re: synthetic ethernet

>>>>> "Sergei" == Sergei Gavrikov <sergei.gavrikov <at> gmail.com> writes:

    Sergei> On Fri, Nov 28, 2008 at 04:47:19PM +0100, Simon Kallweit wrote:
    >> Sergei Gavrikov wrote:
    >>> Simon Kallweit wrote:
    >>> 
    >>>> 0Failed to initialize /dev/net/tun, errno Operationa not
    >>>> permitted (1)
    >>>> 
    >>>> Running rawether using sudo, it actually seems to work. Now I
    >>>> don't quite see where the difference between the suid and
    >>>> sudo method is?!? But I guess I miss the obvious here ...
    >>>> 
    >>>> Any advice?
    >>>> 
    >>> 
    >>> Try tunctl. man tunctl.
    >>> 
    >> 
    >> Thanks, got it working. Might be worth to add a little note in
    >> the ecos documentation.

    Sergei> I would prefer to exclude setuid setup at all from install
    Sergei> rules. I install tools with prefix
    Sergei> --prefix=${HOME}/ecos/tools, and I hate to type sudo make
    Sergei> install; sudo chown -R ...

Do please remember that rawether is intended to work with real
ethernet devices as well, not just /dev/net/tun. In fact that is a lot
easier nowadays than it used to be: just plug in a cheap USB ethernet
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rutger Hofman | 1 Dec 2008 17:26
Picon
Picon

Re: Alpha release eCos NAND Flash, eCos YAFFS

(Limited the reply to the discuss list)

Andrew Lunn wrote:
> ecos-nand-flash-api-err.html: 
> 
> If a function fails, a global variable is set that indicates where the
> error occurred and for what reason
> 
> I don't like this. How do you protect against race conditions with
> multiple threads doing accesses? It either needs to be a variable
> passed with each function call, or at least in thread local storage.

I also prefer thread-local. However, if each thread needs to allocate a 
struct for error handling, there must be some memory allocator. And it 
cannot be the one that is passed to cyg_nand_init() because that is too 
late (and it is nand-struct-specific). Is there a kernel allocator (in 
the vein of kmalloc) that I could use?

> ecos-nand-flash-api-anc.html:
> 
> cyg_flash_get_info() -> cyg_nand_get_info() 

Thanks, fixed.

> ecos-nand-flash-api-anc.html:
> 
> "use_cache is a boolean". eCos has a boolean type, cyg_bool. 
> 
> Checks the BBT (Bad Block Table) if this block is good, worn bad,
> reserved, or factory-bad. If no BBT is used, attempts to check the
(Continue reading)

Permalink | Reply | 0 comments |

Gmane