Updating Open Projects

[Joel Sherrill]

On Sun, Feb 5, 2017 at 1:14 PM, Denis Obrezkov <denisobrezkov at gmail.com>
wrote:

>
>>> First.. does that CPU include a free toolset? A free simulator?
>>
>> As far as I know, it has a compiler, but I never tried it:
> https://gcc.gnu.org/onlinedocs/gcc/C6X-Options.html
>
> Also, there is a linux port that uses gcc:
> http://linux-c6x.org/wiki/index.php/Main_Page
>
>
That's a good sign. :)

I am asking these questions because a new port has more moving parts
than other RTEMS project. For example:

+ toolchain. If there is a c6x-elf, myself or Sebastian can usually add a
-rtems target pretty quickly. We have FSF assignment paperwork so that
much is handled. But a toolchain includes binutils, gcc, gdb, and newlib.
Newlib has to have at least setjmp/longjmp support for the CPU.

+ If available, a free simulator is nice because it eases initial
development
and long-term testing even if the simulator doesn't have interrupt support.

+ A BSP for the simulator.

+ A BSP for reference hardware.

You can't have a port without at least one BSP. Sometimes there are two
but you have to have one of those. It is highly desirable to have a BSP
that is easily available and affordable to the community.

If you decide to do this, we need to assess the tool chain situation.
My quick check of the source looks OK. I tried to build a tic6x-elf
tool chain from the tools master and it failed in gcc. I have emailed
the port maintainer to see if this is going to be an ongoing issue.
An unmaintained or lightly toolchain which is broken now is not a
good sign.

I know that there was simulators in CCS. But I found this phrase on their
> wiki:
> CCSv6 does NOT have any simulators. Texas Instruments is moving away from
>  providing simulators and instead is focusing on providing low cost
> development boards.
> (http://processors.wiki.ti.com/index.php/List_of_Simulator)
>
> I think I can ask more about simulators in BB and linux-c6x mailing lists.
>
> Simulators are never exactly the same as the HW. Maybe they just got tired
of investing money in them if they were far off the hardware. Even the most
basic simulator can help you get through context switch code and some
other fundamental problems.


> For that project I would be prone to list it as a separate project
>> and add to the BeagleBoard project to take advantage of that
>> project. So the port is step 1 and using that port in specific ways
>> on the BB is step 2.
>>
> Should I apply my proposal to BB GSoC too?
>
> If you have to develop targeting the c6x in the BB, then I think that
is just part of defining your project.

I am assuming you would start accessing the CPU via the Linux
tools (whatever they are).  And ensure that whatever method is used
to interact with the CPU works when running Linux.

Then when all is working, address how an RTEMS ARM app on
the BB interacts with it.

--joel


>
>
> --
> Regards, Denis Obrezkov
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20170205/189c97e1/attachment.html>