headers
Markus Schaber | 1 Apr 2008 13:14
Favicon

Re: Porting a new flash driver

Hi, all,

Markus Schaber <schabi <at> logix-tt.com> wrote:

> I have a NAND flash controller hardware that seems not yet supported by
> eCos, and example drivers (e. G. for openOCD) and documentation.
[snip]

As there was no answer to my questions:

Is this list the correct one, or should I send to ecos-devel instead?

Regards,
Markus

-- 
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf.     | Software Development GIS

Fight against software patents in Europe! www.ffii.org
www.nosoftwarepatents.org

--

-- 
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
Chris Zimman | 1 Apr 2008 13:17
Favicon

RE: Porting a new flash driver

> > I have a NAND flash controller hardware that seems not yet supported
> by
> > eCos, and example drivers (e. G. for openOCD) and documentation.
> [snip]
> 
> As there was no answer to my questions:
> 
> Is this list the correct one, or should I send to ecos-devel instead?

Hi Markus,

I don't think there is any general infrastructure to support NAND flash at
the moment.  I say that without knowing what you intend on doing with it
though.  I guess if you wanted to make it appear as a block device, you could
just implement it that way.

What is the end goal of the implementation?

--Chris

--

-- 
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 | 8 comments |
headers
Markus Schaber | 1 Apr 2008 13:22
Favicon

Re: Porting a new flash driver

Hi, Chris,

"Chris Zimman" <czimman <at> bloomberg.com> wrote:

> I don't think there is any general infrastructure to support NAND flash at
> the moment.  I say that without knowing what you intend on doing with it
> though.  I guess if you wanted to make it appear as a block device, you could
> just implement it that way.
> 
> What is the end goal of the implementation?

We want to have jffs2 running on a part (some megabytes / one FIS
partition) of the NAND flash, to store configuration and theming data.

I'm currently reading the sources, and it seems ugly, but doable.

Ugly, because it looks like the flash driver interface consists of some
static functions, so it will be impossible to support different flashes
concurrently. Luckily, we'll only need a single flash unit at the
moment.

Thanks for your answer,
Markus

--

-- 
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf.     | Software Development GIS

Fight against software patents in Europe! www.ffii.org
www.nosoftwarepatents.org
(Continue reading)

Permalink | Reply | 7 comments |
headers
Andrew Lunn | 1 Apr 2008 13:29
Picon

Re: Porting a new flash driver

> Ugly, because it looks like the flash driver interface consists of some
> static functions, so it will be impossible to support different flashes
> concurrently. Luckily, we'll only need a single flash unit at the
> moment.

Take a look at the flash_v2 branch. We hope that in the next few
months to merge this into the trunk.

       Andrew

--

-- 
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 | 6 comments |
headers
Markus Schaber | 1 Apr 2008 17:39
Favicon

Re: Porting a new flash driver

Hi, Andrew,

Andrew Lunn <andrew <at> lunn.ch> wrote:

> > Ugly, because it looks like the flash driver interface consists of some
> > static functions, so it will be impossible to support different flashes
> > concurrently. Luckily, we'll only need a single flash unit at the
> > moment.
> 
> Take a look at the flash_v2 branch. We hope that in the next few
> months to merge this into the trunk.

That sounds interesting, I'll have a look at it. But I'm afraid that,
for now, I'll go the short path.

Regards,
Markus

-- 
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf.     | Software Development GIS

Fight against software patents in Europe! www.ffii.org
www.nosoftwarepatents.org

--

-- 
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 | 5 comments |
headers
Gary Thomas | 1 Apr 2008 17:54
Favicon

Re: Porting a new flash driver

Markus Schaber wrote:
> Hi, Andrew,
> 
> Andrew Lunn <andrew <at> lunn.ch> wrote:
> 
>>> Ugly, because it looks like the flash driver interface consists of some
>>> static functions, so it will be impossible to support different flashes
>>> concurrently. Luckily, we'll only need a single flash unit at the
>>> moment.
>> Take a look at the flash_v2 branch. We hope that in the next few
>> months to merge this into the trunk.
> 
> That sounds interesting, I'll have a look at it. But I'm afraid that,
> for now, I'll go the short path.

Albeit more complex, using the flash_v2 branch is probably your
only choice if you want to run JFFS2 on NAND.  There's quite a lot
of work involved in making this functional (hence why it's not already
in the tree!).  In particular, the JFFS2 code will need to be updated
and there are many NAND specific functions which it expects to be
available which the mainline (flash_v1) does not support.

Alternatively, you could go with the current (flash_v1) setup which
does support NAND devices (somewhat - it's not 100% pretty).  RedBoot
and FIS can be run in this mode, just not JFFS2.

Look at the TAMS MOAB port for an example.

What NAND device(s) are you thinking about using?
What's the target architecture?
(Continue reading)

Permalink | Reply | 4 comments |
headers
Markus Schaber | 1 Apr 2008 18:15
Favicon

Re: Porting a new flash driver

Hi, Gary,

Gary Thomas <gary <at> mlbassoc.com> wrote:

> Alternatively, you could go with the current (flash_v1) setup which
> does support NAND devices (somewhat - it's not 100% pretty).  RedBoot
> and FIS can be run in this mode, just not JFFS2.

Ah, that's sad. But as there's no other writable file system which runs
on NAND flash, I don't have any other choice, right?

> Look at the TAMS MOAB port for an example.

Thanks for the pointer.

> What NAND device(s) are you thinking about using?
> What's the target architecture?

It is the builtin NAND controller in a Centrality (now SIRF) Atlas
II / Atlas III CPU (an Arm9 derivate), on our own board.

We already have running eCos on it, including RedBoot, and most other
drivers we need.

Regards,
Markus

--

-- 
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf.     | Software Development GIS
(Continue reading)

Permalink | Reply | 0 comments |
headers
airdelroy | 2 Apr 2008 03:48

Re: RAM Images on AT91SAM7s256


I am also trying to get a RAM image running on an AT91SAM7s256.  I ultimately
will run my applications from the flash, would like to debug in RAM. 
Currently I can load via sam-ba a rom image that will communicate over the
serial port, so I have this to start from.

Sam-ba I believe uses the first 8k of RAM.  So I think that the ldi file
should look like this:

MEMORY
{
    ram : ORIGIN = 0x00202000, LENGTH = 0xE000
}

SECTIONS
{
    SECTIONS_BEGIN
    SECTION_rom_vectors (ram, 0x00202000, LMA_EQ_VMA)
    SECTION_fixed_vectors (ram, 0x00200040, LMA_EQ_VMA)
    SECTION_text (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_fini (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_rodata (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_rodata1 (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_fixup (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_gcc_except_table (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_data (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_bss (ram, ALIGN (0x4), LMA_EQ_VMA)
    CYG_LABEL_DEFN(__heap1) = ALIGN (0x8);
    SECTIONS_END
}
(Continue reading)

Permalink | Reply | 2 comments |
headers
Tom Deconinck | 2 Apr 2008 08:12
Picon

Re: RAM Images on AT91SAM7s256

On Wed, Apr 2, 2008 at 3:48 AM, airdelroy
<aaron-nabble <at> planetrichardson.net> wrote:
>
>  I am also trying to get a RAM image running on an AT91SAM7s256.  I ultimately
>  will run my applications from the flash, would like to debug in RAM.
>  Currently I can load via sam-ba a rom image that will communicate over the
>  serial port, so I have this to start from.
>
>  Sam-ba I believe uses the first 8k of RAM.  So I think that the ldi file
>  should look like this:
>
>
>  MEMORY
>  {
>     ram : ORIGIN = 0x00202000, LENGTH = 0xE000
>  }
>
>  SECTIONS
>  {
>     SECTIONS_BEGIN
>     SECTION_rom_vectors (ram, 0x00202000, LMA_EQ_VMA)
>     SECTION_fixed_vectors (ram, 0x00200040, LMA_EQ_VMA)
>     SECTION_text (ram, ALIGN (0x4), LMA_EQ_VMA)
>
>     SECTION_fini (ram, ALIGN (0x4), LMA_EQ_VMA)
>     SECTION_rodata (ram, ALIGN (0x4), LMA_EQ_VMA)
>     SECTION_rodata1 (ram, ALIGN (0x4), LMA_EQ_VMA)
>     SECTION_fixup (ram, ALIGN (0x4), LMA_EQ_VMA)
>     SECTION_gcc_except_table (ram, ALIGN (0x4), LMA_EQ_VMA)
>     SECTION_data (ram, ALIGN (0x4), LMA_EQ_VMA)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jonathan Larmour | 2 Apr 2008 16:19
Favicon

Re: ARM EABI port / static constructor priority removal

Chris Zimman wrote:
>> Also ugly. You break the nice packing model. Say i have an out of tree
>> package, a device driver for the wall clock on my hardware. The
>> current code allows my code to have a static initializer with priority
>> that is after I2C is up and running and it is totally independent of
>> the in tree code.

And also needs to be run _after_ the kernel code, but potentially before
the libc code (which may reference the RTC), etc.etc. It's just not
feasible while retaining modularity which is far more valuable.

>> I don't need to modify the in tree code at all. The
>> linker sorts it all out. Your suggestion would force me to modify the
>> in tree list of constructors.
> 
> With what you're talking about here, you'd have to modify cyg_type.h anyway

Not really. In cyg_type.h CYG_INIT_APPLICATION is defined, and priorities
60000 up to 65534 are free for application use.

> if you want to add a new init priority unless you want to keep it private,
> which is kind of bogus.  With the current model anyhow, you *have* to be
> aware of the ordering in cyg_type.h and known what values are assigned to
> which constructors.  That's pretty ugly in and of itself.

Arguably not with a reserved range for application use.

> There's also no inherent reason you would have to modify in tree code to
> accomplish what you're suggesting.  Sections can be created for just that
> purpose.  Even enforcing startup ordering rules is pretty straight forward
(Continue reading)

Permalink | Reply | 1 comment |

Gmane