You mention the word "heterogeneous" but I think it should take this tack:

For what I'd like to do, I would require GNU Radio running on the host (ie,
ARM) CPU. GNU Radio isn't going to run under Plan 9 on an ARM target, as
much as I'd like. You also mention "to be (much) more interesting than a
standard ARM..." but in effect, it already is.

I could be barking up the wrong tree here, and I made a suggestion of
Styx-on-a-chip to ease development times, and also student commitment, it
will have to talk to Linux at the end of the day, lets start now?


On Wed, Feb 5, 2014 at 11:46 PM, erik quanstrom <quanstro@quanstro.net>wrote:

> > Oh, its ok. I like the GSoC idea. I just don't think I'm GSoC material,
> I'm
> > hardware type, even if I will be a uni student this year going forward -
> > "If it draws blood, its hardware" as the old maxim goes.
>
> it's great to hear the enthusiam, but sadly, it seems over
> ambitious.
>
> to work with this heterogeneous co-processor with the usual tools,
> and be any more interesting than a standard arm, i think at least
> the following needs to be done
> 1.  bootstrap the arm processor get plan 9 running.
> 1a. program the fpga with adapteva's binary blob.
> 1b. drivers for a minmal set of devices.
> 2.  write a compiler/assembler/linker for the epiphany multicore;
> populate /epi/include.  a emulator may need to be written.
> 3.  write the libmach hooks for the same
> 4.  write the asm for /sys/src/lib*/epi (or at least libc)
> 5.  decide what kind of operating framework the epi
> should have, and write the appropriate glue.  it's not
> clear to me that a standard kernel could work at all.
> (what kind of coherence model is there?)
>
> this can't be done by one gsoc student in a summer.
> and there's the open ended question of how to use the
> epi coprocessor.
>
> a very bright, gifted, experienced, stubborn, and diligent
> student might have some hope of accomplishing 1/1a or
> a significant part of 2.  but that's a stretch.  3, 4 seem
> to be properly sized for one student gsoc.  5 is unknown.
>
> so, in order to have something usable at the end, one would
> need 5 students, 5 mentors, someone to do 1b, and sort of a
> scrum master to help coordinate.
>
> i see several serious risks to this idea.
> a.  what if we get less than 5 students, or mentors, or slots?
> b.  sadly, not all students complete the summer.  how do we
> recover if even one person drops out?
> c.  do we have someone qualified to be scrum master for
> 10 people (5 students and 5 mentors)?  with enough time?
> d.  5 is open ended.
>
> this seems too big a leap, given the student success rate is
> not yet 100%.
>
> so if you're a student still excited about this project, reframing
> the problem so that it stands alone (even if it's just bootstrapping
> the arm chip) seems like the best option to me.
>
> now i could be wrong or overly pessamistic, so i'd love to
> hear other opinions.
>
> - erik
>