headers
Szentirmai Gergely | 1 May 2009 01:43
Picon
Favicon

Re: Disk I/O -> scheduling problems]


Paul D. DeRocco írta:
>> From: Szentirmai Gergely
>>
>> I have an SD card with FAT filesystem, handled throught an MCI
>> interface. eCos did not have support for this interface (target
>> AT91SAM7A3), and I have written an extension - based on Atmel's library
>> - for the MMC driver to support it.
>> I have a sensor connected with SPI, and this sensor has an interrupt,
>> which is handled this way isr -> dsr (flag set) -> thread (flag wait) ->
>> spi_read. This reader thread has a high pritority.
>>
>> When I write the card with a low priority thread, it blocks reading the
>> sensor. Sensor reading should be done in about every 5 ms.
>>
>> This is because dsr-s are locked by io/src/disk.c. So the question is,
>> what should I do to prevent losing samples? Writing a blocks of data
>> (512Byte) to the card can take some time (approx. 10 ms). Are these
>> really concurent request, so this locking mechanism is needed?
>>
> <snip>
>> So what is the recommened solution for handling lengthy operations in a
>>   driver?
>>
>> This is a code part from the Atmel AT91 SPI driver:
>>              // Wait for its completion
>>              cyg_drv_dsr_lock();
>>              {
>>                  while (!spi_bus->transfer_end)
>>                      cyg_drv_cond_wait(&spi_bus->transfer_cond);
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul D. DeRocco | 1 May 2009 05:05
Picon

RE: Disk I/O -> scheduling problems

> From: Szentirmai Gergely [mailto:gergely.szentirmai <at> axelero.hu]
>
> Paul D. DeRocco írta:
>
> >   Does the existing MCI driver do the
> > entire sector transfer without using any interrupts?
>
> No, but it polls for the result. This is what could be modified to the
> code here, I have posted.
>
> Here comes the thing which is not clear. Examine this code (perhaps an
> eCos-recommended solution, is it?):
>  >>              cyg_drv_dsr_lock();
>  >>              {
>  >>                  while (!spi_bus->transfer_end)
>  >>                      cyg_drv_cond_wait(&spi_bus->transfer_cond);
>  >>              }
>  >>              cyg_drv_dsr_unlock();
>
> spi_bus->transfer_cond is set by an interrupt. Until the operation is
> not finished, dsr-s are locked.
>
> I have found my answer, what is the difference between these
> implementations:
> http://osdir.com/ml/ecos.general/2003-03/msg00178.html
> DSR locking works in a per-thread basis. So
> cyg_drv_cond_wait(&spi_bus->transfer_cond); would trigger a task switch.
>
> Thank you for your help!
> Gergely Szentirmai
(Continue reading)

Permalink | Reply | 2 comments |
headers
Szentirmai Gergely | 1 May 2009 18:19
Picon
Favicon

Re: Disk I/O -> scheduling problems

Paul D. DeRocco írta:
>> From: Szentirmai Gergely [mailto:gergely.szentirmai <at> axelero.hu]
>>
>> Paul D. DeRocco írta:
>>
>>>   Does the existing MCI driver do the
>>> entire sector transfer without using any interrupts?
>> No, but it polls for the result. This is what could be modified to the
>> code here, I have posted.
>>
>> Here comes the thing which is not clear. Examine this code (perhaps an
>> eCos-recommended solution, is it?):
>>  >>              cyg_drv_dsr_lock();
>>  >>              {
>>  >>                  while (!spi_bus->transfer_end)
>>  >>                      cyg_drv_cond_wait(&spi_bus->transfer_cond);
>>  >>              }
>>  >>              cyg_drv_dsr_unlock();
>>
>> spi_bus->transfer_cond is set by an interrupt. Until the operation is
>> not finished, dsr-s are locked.
>>
>> I have found my answer, what is the difference between these
>> implementations:
>> http://osdir.com/ml/ecos.general/2003-03/msg00178.html
>> DSR locking works in a per-thread basis. So
>> cyg_drv_cond_wait(&spi_bus->transfer_cond); would trigger a task switch.
>>
>> Thank you for your help!
>> Gergely Szentirmai
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tarmo Kuuse | 2 May 2009 17:16
Picon
Favicon

Synthetic target on linux x86_64 host

Hi!

I've been trying get vanilla synthetic target up and running on 64-bit 
Debian testing. It's definitely a painful experience (well, more than 
usual). Is this host platform unsupported?

This is what I did:

1. Getting tools and code

I installed eCos with i386-elf tools as described in 
http://ecos.sourceware.org/getstart.html.

I also fetched fresh source from anonymous CVS and set $ECOS_REPOSITORY 
to point to it.

2. Prepations

Started configtool, verified repository (OK, set to anoncvs).

Picked default template "Linux synthetic target".

3. Building the library

Configtools shows that global command prefix is "i686-pc-linux-gnu". WTF 
is that?

I remove the command prefix entirely to build with my native gcc 
toolchain (Debian 4.3.3-3).
(Continue reading)

Permalink | Reply | 10 comments |
headers
Andrew Lunn | 2 May 2009 23:14
Picon

Re: Synthetic target on linux x86_64 host

> Can synthetic target even be built with native x86_64 tools?

I don't think so. Synth calls kernel system calls directly, using
assembly language. I expect this part needs re-writing into 64 bit
code.

Also, eCos is very much used on 32 bit systems. I don't know of
anybody using it on 64 bit systems. You are bound to run into problems
with assumptions that sizeof(int)==4 etc. However synth probably is a
good platform to find and fix some of these, once you have done the
basic HAL port.

     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 | 3 comments |
headers
Tarmo Kuuse | 2 May 2009 23:44
Picon
Favicon

Re: Synthetic target on linux x86_64 host

Andrew Lunn wrote:
>> Can synthetic target even be built with native x86_64 tools?
> 
> I don't think so. Synth calls kernel system calls directly, using
> assembly language. I expect this part needs re-writing into 64 bit
> code.

That is a bit surprising - I assumed the synthetic target was just 
another application from the compiler's side.

Anyway it is good to have a clear answer. Thanks.

> Also, eCos is very much used on 32 bit systems. I don't know of
> anybody using it on 64 bit systems. You are bound to run into problems
> with assumptions that sizeof(int)==4 etc. However synth probably is a
> good platform to find and fix some of these, once you have done the
> basic HAL port.

I don't know anything about the x86 or (shudder) x86-64 bowels and would 
prefer to live a long and sane life by keeping it that way :)

--
Kind regards,
Tarmo Kuuse

--

-- 
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 | 2 comments |
headers
Andrew Lunn | 3 May 2009 09:18
Picon

Re: Re: Synthetic target on linux x86_64 host

On Sun, May 03, 2009 at 12:44:13AM +0300, Tarmo Kuuse wrote:
> Andrew Lunn wrote:
>>> Can synthetic target even be built with native x86_64 tools?
>>
>> I don't think so. Synth calls kernel system calls directly, using
>> assembly language. I expect this part needs re-writing into 64 bit
>> code.
>
> That is a bit surprising - I assumed the synthetic target was just  
> another application from the compiler's side.

From the compiler, yes, its just an application. However because eCos
has a libc, you cannot use the native libc as the interface to the
native kernel. You have to call the kernel directly. Hence the system
call issues.

> I don't know anything about the x86 or (shudder) x86-64 bowels and would  
> prefer to live a long and sane life by keeping it that way :)

Then take a look at x86 emulators which you can run on 32 bit more on
top of a 64 bit system. eg http://bochs.sourceforge.net/

    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 | 1 comment |
headers
Ross Younger | 3 May 2009 12:24
Favicon

Re: Synthetic target on linux x86_64 host

Tarmo Kuuse wrote:
> Can synthetic target even be built with native x86_64 tools?

As Andrew has said it's not a supported environment - synth predates x86_64 
by some years - and I suspect would require a proper porting effort in due 
course.

However, I did find myself poking at the synth target on my workstation a 
few weeks ago (Ubuntu 8.10, 64-bit) and was able to get it going, after a 
fashion, without very much trouble (and without having to know much about 
x86/x86_64 guts!) in order to play with some new code I was writing.

I was using the eCos i386-elf toolchain; the syscalls and so on all seemed 
to just work thanks to x86_64's backwards compatibility (and I have various 
32-bit compatibility libs installed, which may or may not have helped).

I manually configured my ecos.ecc to use i386-elf, and once I had built eCos 
I had to edit target.ld by hand and remove the mention of libgcc_eh.a in 
order for my test applications to link. For debugging, the native gdb (not 
i386-elf-gcc!) just worked.

Obviously, running synth cross-architecture in this way is not tested at all 
- it seemed to work for my limited purposes, and might for you, but if it 
breaks you get to keep both pieces :-)

Ross

--

-- 
eCosCentric Ltd, Barnwell House, Barnwell Drive, Cambridge CB5 8UU, UK
Registered in England no. 4422071.                 www.ecoscentric.com
(Continue reading)

Permalink | Reply | 5 comments |
headers
Nick Garnett | 3 May 2009 15:28
Favicon

Re: Synthetic target on linux x86_64 host

Ross Younger <wry <at> ecoscentric.com> writes:

> Tarmo Kuuse wrote:
> > Can synthetic target even be built with native x86_64 tools?
> 
> As Andrew has said it's not a supported environment - synth predates
> x86_64 by some years - and I suspect would require a proper porting
> effort in due course.
> 
> However, I did find myself poking at the synth target on my
> workstation a few weeks ago (Ubuntu 8.10, 64-bit) and was able to get
> it going, after a fashion, without very much trouble (and without
> having to know much about x86/x86_64 guts!) in order to play with some
> new code I was writing.
> 
> I was using the eCos i386-elf toolchain; the syscalls and so on all
> seemed to just work thanks to x86_64's backwards compatibility (and I
> have various 32-bit compatibility libs installed, which may or may not
> have helped).
> 
> I manually configured my ecos.ecc to use i386-elf, and once I had
> built eCos I had to edit target.ld by hand and remove the mention of
> libgcc_eh.a in order for my test applications to link. For debugging,
> the native gdb (not i386-elf-gcc!) just worked.
> 
> Obviously, running synth cross-architecture in this way is not tested
> at all - it seemed to work for my limited purposes, and might for you,
> but if it breaks you get to keep both pieces :-)

I have also been running the synthetic target on my OpenSuSE 11.0
(Continue reading)

Permalink | Reply | 4 comments |
headers
Tarmo Kuuse | 3 May 2009 21:30
Picon
Favicon

Re: Synthetic target on linux x86_64 host

Andrew Lunn wrote:
> On Sun, May 03, 2009 at 12:44:13AM +0300, Tarmo Kuuse wrote:
>> Andrew Lunn wrote:
>>>> Can synthetic target even be built with native x86_64 tools?
>>> I don't think so. Synth calls kernel system calls directly, using
>>> assembly language. I expect this part needs re-writing into 64 bit
>>> code.
>> That is a bit surprising - I assumed the synthetic target was just  
>> another application from the compiler's side.
> 
> From the compiler, yes, its just an application. However because eCos
> has a libc, you cannot use the native libc as the interface to the
> native kernel. You have to call the kernel directly. Hence the system
> call issues.
> 
>> I don't know anything about the x86 or (shudder) x86-64 bowels and would  
>> prefer to live a long and sane life by keeping it that way :)
> 
> Then take a look at x86 emulators which you can run on 32 bit more on
> top of a 64 bit system. eg http://bochs.sourceforge.net/

I now have a 32-bit Debian system running inside VirtualBox on my 64-bit 
Debian system. Synthetic target works as expected, host tools for 
Ethernet can be built, etc.

I suspected it would end up like this when starting...

--
Kind regards,
Tarmo Kuuse
(Continue reading)

Permalink | Reply | 0 comments |

Gmane