headers
Nick Garnett | 3 Jan 2006 11:40
Favicon

Re: Subtle bug not calling DSRs.

Sergei Organov <osv <at> javad.com> writes:

> Hello,
> 
> I believe I've found bug when eCos doesn't call pended DSR(s) until
> _next_ time the scheduler lock is released. The scenario I see is like
> this:
> 
> 1. Start single thread that is run as soon as scheduler is enabled.
> 2. The thread suspends itself that way or another (wait on a primitive
>    or just sleep, -- it doesn't matter).
> 3. The (2) results in context switch from this thread to the idle thread
>    from within Cyg_Scheduler::unlock_inner(0).
> 4. During context switch interrupt happens that is requesting
>    corresponding DSR to be run. However, as scheduler is locked during
>    context switch, the DSR is not invoked on exit from the interrupt.
> 5. Context switch continues and transfers control to the idle thread
>    entry address being Cyg_HardwareThread::thread_entry(). This is
>    because the idle thread had no chance to run before this point.
> 6. Cyg_HardwareThread::thread_entry() has no code to check for pended
>    DSRs, so the DSR posted in (4) is not run.

Good catch.

This is a somewhat obscure bug since the number of applications that
start the scheduler and then do nothing at all is very small. However,
failing to handle DSRs across the context switch to start a thread is
clearly wrong.

>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Sergei Organov | 10 Jan 2006 14:48
Favicon

Re: Subtle bug not calling DSRs.

Nick Garnett <nickg <at> ecoscentric.com> writes:
[...]
> I think the following patch fixes the bug and reorganizes things to be
> a little tidier. If this proves to be the case I'll generate a
> ChangeLog entry and check it in in a couple of days.

Looks fine to me, -- I've applied the patch and it does fix the problem.

--

-- 
Sergei.
Permalink | Reply | 0 comments |
headers
Paul Chavent | 12 Jan 2006 23:07
Picon
Favicon

Platform HAL porting and structure.

Hello.

I try to create a new platform hal. It's for the gameboy advance (so 
ARM7TDMI).

There is one which already exist, but i will do it to learn myself howto 
do (and add some custom features).

So i use the existing port as an example.

But i'am not able to understand a part of the Ecos Reference Manual.

In "Chapter 6 Hal structure -> Platform hal", there is one example that 
differ from the actual structure for my platform. It seems that the 
example apply to a PPC based architecture.

In "Chapter 6 Platform HAL Porting -> Minimal requirements ยง9", there is 
two kind of naming convention if we are on PPC or ARM.

So my question is : "Is there a new naming scheme common to all 
architectures/variant/platform for futures version of ecos that should 
follow the 'Chapter 6 Hal structure' model ?"

Thanks !

Paul Chavent.
Permalink | Reply | 0 comments |
headers
oliver munz @ s p e a g | 13 Jan 2006 00:15
Picon

Why is ZLIB_COMPRESSION_OVERHEAD soooo big?

 How knows why zlib needs more 3/4 of my RAM per default? What's the minimum 
ZLIB_COMPRESSION_OVERHEAD ?

decompress.c:

 78 #ifdef CYGOPT_REDBOOT_FIS_ZLIB_COMMON_BUFFER
 79 # define ZLIB_COMPRESSION_OVERHEAD 
CYGNUM_REDBOOT_FIS_ZLIB_COMMON_BUFFER_SIZE
 80 #else
 81 # define ZLIB_COMPRESSION_OVERHEAD 0xC000
 82 #endif

Would zlib work with 0c8000?

Thanks
Oliver Munz
Permalink | Reply | 0 comments |

Gmane