Help needed for Blackfin eZKit533 BSP

[Allan Hessenflow]

On Mon, Sep 28, 2009 at 05:45:27PM +0200, Florian Kandzia wrote:
> Now I tried the whole thing with rtems 4.8.0. Because it comes with an older 
> version of gcc, the executables run well on skyeye. Of course, only after 
> changing start.S. The funny thing is, these executables also run on the real 
> hardware, when I load them with bfin-elf-gdb + bfin-elf-gdbproxy.

Yes, there's no reason the executables built for skyeye shouldn't work
on real hardware, to a point.  There are three reasons for the
BFIN_ON_SKYEYE conditional:

One is to move the start.S code into a segment skyeye will load.  This
would probably be okay to do in general, but since I don't know the
reason start.S was put into on-chip SRAM in the first place I didn't want
to change it (especially since I can't test the eZKit533 BSP on real
hardware).

Another is to disable access to peripherals that are not implemented in
skyeye.

The last is to put in a clock driver hack to let simulations that make
use of clock ticks run in a reasonable amount of time (it causes a clock
tick anytime the system is idle).

> For me it's OK that 4.8.0 works, I can stick to that version. Maybe I'll 
> also try the current CVS version, but there is no real need for me.
> Would it be of any use for you if you knew whether the current CVS code runs 
> on my ezkit?

You may have problems with interrupt handling/preemption with 4.8.0.  If
you don't require it to behave as a preemptive RTOS then you might be okay,
but even then you might not be.  The interrupt handling in 4.8.0 uses a 
method of doing context switches that is not always safe to do.  It
attempts to work around that limitation by peeking at the code that was
interrupted to determine if it is safe to do a context switch or not.
This leads to two problems.  One is that there are times that an interrupt
can occur when it will be unable to do a context switch, so you can't
guarantee any particular response time when relying on preemption.  The
other is that the test to determine when it is safe to do a context switch
is fragile; it depends on particular code sequences being generated by the
compiler for function entry/exit, and that you won't write any assembly
language that doesn't follow the same conventions.

This is corrected in the CVS head, and I'm fairly certain in 4.9.2.

But that brings back the problem that 4.9.2 isn't working for you.  I
vaguely recall a bug I introduced where the eZKit533 BSP would access
some register that doesn't exist in the bf533, which might explain that
problem.  Unfortunately I don't recall exactly when that was corrected
and can't easily check at the moment, so I can't say if that would impact
4.9.2, I can only state that CVS head should not have that problem.

So you might want to try CVS head, if you have the time to test that.

allan

-- 
Allan N. Hessenflow      allanh at kallisti.com