Call for SPARCengine 1e BSP

[Ivan Galkin]

Regarding MVME167 as a better match for our long-suffering sun4e sparc - 
I agree.

However, we have been playing with an Intel Rtems target for some months 
already, for a different project. Building a host bsp environment #3 for 
motorola... our setup today is confusing enough, and we really don't 
know how steep the Power PC curve is going to be.

RTEMS support of VME in motorolas is a strong point, though.

As for the second-hand boards, our hard-earned experience tells us not 
to get on that route without documentation and a ready to use BSP. It 
took us a couple of  months and triple the cost of the board to get docs 
for our sparcengine 1e.

Cheers for now.
E1

Joel Sherrill <joel at OARcorp.com> wrote:

> Ivan Galkin wrote:
>
>>
>> Jiri, many thanks for these important clarifications.
>> I only wish we knew that this sparc v7 board won't work a month ago.
>> We do need VME to control our VME hardware and sync to its timing.
>> I don't think we are going to spend $18K on a TSC695 starter kit. 
>> Does not sound right.
>> MiThOS will work on sun4e, but their development is defunct, and they 
>> never wrote a VME driver.
>> We are leaning towards scratching the idea and moving to an intel vme 
>> board. This will mean different bsp, vme, endian, CPU speed. But its 
>> better than sun4e, apparently.
>> Something like vp101 by ArcTechnico. This brings another question - 
>> do we order a linux VME driver from ActTechnico, hoping that we can 
>> make it work in Rtems? Another option in a VxWorks vme driver.
>
>
> Depending on what your CPU desire is, the Motorola PowerPC VMEBus boards
> have an active RTEMS user community.
>
> If you are trying to do this on the cheap, then a used MVME162 or
> MVME167 might make a nice option.
>
> The x86 VMEbus boards should work as well but you would probably have to
> adapt the VMEbus driver.
>
> --joel
>
>> Thanks again,
>> Ivan
>>
>>
>>
>> Jiri Gaisler wrote:
>>
>>>
>>> Since you asked, here my view on the topic ...
>>>
>>> The ERC32 is not very similar to the Fujitsu MB86901A
>>> processor used in the Sparcengine 1e. The integer
>>> pipeline implements the same SPARC V7 instruction set,
>>> but the memory hierarchy is completely different.
>>> MB86901A has a cache, an MMU, and DRAM main memory.
>>> ERC32 has no cache, no MMU and executes directly
>>> from 0-waitstate external static RAM. The peripherals
>>> (uart, timers, irq ctrl, I/O) are completely different.
>>> I also believe that the MB86901A has 7  register
>>> windows while ERC32 (based on Cypress 601) has 8.
>>>
>>> It should be possible to develop an SS 1E bsp, but
>>> all low level code (drivers and init) will becdifferent
>>> from ERC32. So the only RTEMS part you really can
>>> reuse is the general SPARC support. The complete
>>> bsp and associated drivers must be written from
>>> scratch. This means that you need detailed
>>> data sheets with register definitions, address
>>> allocation and interrupt routing. Unless you
>>> have that, it will be very difficult (impossible?).
>>>
>>> If you really want some cheap SPARC hardware,
>>> why not get a low-cost FPGA board (~ $500) and
>>> put a LEON3 on it. There is a stable RTEMS bsp
>>> for it (yes, I will soon merge it in to the main tree)
>>> and the VHDL code and development tools are free.
>>> OK, there is no VME but do you really need that?
>>>
>>> An other aspect is that we have today announced
>>> the availability of LEON3FT parts on the Actel
>>> RTAX2000 radiation-hardened FPGA devices. There
>>> will be various pre-programmed LEON3FT devices
>>> with 1553, CAN-2.0 and Spacewire available, as well
>>> as netlists if you want to make you own FPGA config.
>>> Performance is 20 - 30 MHz, on par or better than ERC32,
>>> but with only ~ 0.5W power consumption. For software
>>> development, you can use cheap Xilinx/ALtera boards
>>> or a commercial grade AX2000 device (~ $250).
>>> Debugging is also significantly easier than ERC32,
>>> you have a real on-chip debug support unit, with
>>> single-stepping, tracing and memory/register access.
>>>
>>> Jiri.
>>
>>
>>
>
>