Re: [9fans] Inferno and the Parallella

[Skip Tavakkolian <skip.tavakkolian@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3700 bytes --]

this isn't exactly GNU Radio, but porting librtlsdr to Plan 9 would enable
interesting signal processing applications.  it would be doable as a GSoC
project since the majority of the work would involve switching from libusb
to Plan 9's usb (this was a project suggestion for 2013).

there are several useful apps that use rtlsdr, written in C and portable to
Plan 9 (AM/FM receiver, AIS, ADS-B, etc.). alternatively, Plan 9 nodes can
be a receiver network to feed GNU Radio running on another OS.



On Wed, Feb 5, 2014 at 6:41 AM, Shane Morris <edgecomberts@gmail.com> wrote:

> 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
>>
>
>

[-- Attachment #2: Type: text/html, Size: 4614 bytes --]