Blackfin BSP

Joel Sherrill joel.sherrill at
Thu Dec 6 19:04:52 UTC 2007

Allan Hessenflow wrote:
> Hoan Hoang wrote:
>> I'm planning to make a BSP for the EZKIT-BF561 but haven't got time to 
>> get there yet also I don't have a GDB compatible Jtag.  I have the 
>> HPUSB-ICE but it not compatible with GDB.  I'm looking at USBProg, don't 
>> know if that could work.  The price tag for the Icebear is too high and 
>> the Igloo is too slow.  Any recomandation ? or anyone know how to make 
>> the HPUSB-ICE to work with GDB.
> I have no idea on the HPUSB-ICE.  The only JTAG pods I own myself are
> Xilinx, one parallel and one USB.  From the discussions at
> it sounds like there's some hope for the Xilinx
> parallel port one (the stuff in the google cache I found are only
> reports of problems, with an implication that it is supported.  At the
> moment seems to be dead so I can't look there
> further).  However I doubt that would be any faster than the Igloo.
>> I think it is a good idea to have a common Blackfin architecture to make 
>> the port easier for other Blackfin processors as well.  Can we use the 
>> .h defined in VDSP or may be base on that? 
> I don't have VDSP and so haven't seen what they did, but I suspect
> there may be license issues with using that.
> Joel Sherrill wrote:
>> Without a lot other than experience on other architectures
>> to go by, I would lean to the second option -- a base
>> architecture .h and a model specific one.  It could even
>> be structured like this:
>> bfXXX.h
>>    + define feature flags
>>    include bfin shared header file
>>   add more definitions
>> Then BSPs include a specific bfXXX.h and the shared code
>> for maintenance is invisible to them.
> This brings up one more point.  Nothing in cpukit cares about any of
> the peripherals that are currently defined in bf533.h.  I assume the
> file is in there because the peripherals are on the same chip as the
> cpu, but I think it would make more sense to move those definitions
> somewhere else, like under libbsp/bfin/shared.
Sounds like a logical alternative to me.  It may also
be logical to place it in libcpu/bfin.

> allan

More information about the users mailing list