skyeye was Re: Blackfin interrupt handling patches

[Allan Hessenflow]

> Allan Hessenflow wrote:
>> The basic problem here is that skyeye is not loading section .l1code,
>> which is where the ezkit533 bsp puts its startup code.  I don't know
>> skyeye well enough to know how to get it to load that section.  One
>> workaround is to modify /c/src/lib/libbsp/bfin/shared/start/start.S,
>> changing the line:
>>         .section .l1code
>> to:
>>         .section .init
>>
>> skyeye does load the .init section.  I don't know what the reason is
>> for putting the startup code in .l1code (which points to onboard SRAM),
>> so I can't say if it's reasonable to change that for the eZKit533 BSP.
>> I do put the startup code in .init for my bf537 Stamp BSP.
>>
>> When I just did that for eZKit533, it made hello.exe work correctly with
>> skyeye 1.2.4 and 1.2.5.  However, ticker.exe only worked correctly with
>> skyeye 1.2.4; under skyeye 1.2.5 it fails with an io error.  I'll look
>> into that a little later.

For that last problem, I had negelected to make a change to skyeye 1.2.5
that I had put into 1.2.4; change BF533_HZ in arch/bfin/mach/bf533_io.c
from 50 to 70000.  If I do that then the eZKit533 ticker.exe works again.
This change is noted in the rtems wiki on the EZKit533 and the SkyEye
pages.  I suppose that without it timer interrupts are occurring too
quickly and blowing the stack, although I haven't examined it in any detail
to see if that is really what's happening.

Incidentally, I also changed BF537_HZ in bf537_io.c to see if I could get
ticker.exe built against my BF537 BSP to run under skyeye.  It did run
(after disabling some register accesses that skyeye doesn't seem to know
exist on the BF537), but I found I didn't have to increase BF537_HZ nearly
as much as I had to increase BF533_HZ (5000 seems to work fine, while
BF533_HZ seems to need something close to 70000).

allan

-- 
Allan N. Hessenflow      allanh at kallisti.com