From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <5778ffc079ca4ad7227b37b1158b29f1@proxima.alt.za> <3b72cf2290d28c849e1f7a5ffde134a6@mikro.quanstro.net> Date: Wed, 5 Feb 2014 10:03:07 -0800 Message-ID: From: Skip Tavakkolian To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=047d7b33d67ca7633e04f1ac911d Subject: Re: [9fans] Inferno and the Parallella Topicbox-Message-UUID: b7ec3f18-ead8-11e9-9d60-3106f5b1d025 --047d7b33d67ca7633e04f1ac911d Content-Type: text/plain; charset=ISO-8859-1 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 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 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 >> > > --047d7b33d67ca7633e04f1ac911d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
this isn't exactly GNU Radio, but porting librtlsdr to= Plan 9 would enable interesting signal processing applications. =A0it woul= d 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 fo= r 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, P= lan 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@g= mail.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 targ= et, as much as I'd like. You also mention "to be (much) more inter= esting 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 c= ommitment, 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 quan= strom <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. =A0bootstrap 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. =A0write a compiler/assembler/linker for the epiphany multicore;
populate /epi/include. =A0a emulator may need to be written.
3. =A0write the libmach hooks for the same
4. =A0write the asm for /sys/src/lib*/epi (or at least libc)
5. =A0decide what kind of operating framework the epi
should have, and write the appropriate glue. =A0it'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. =A0but that's a stretch. =A03, 4 seem
to be properly sized for one student gsoc. =A05 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. =A0what if we get less than 5 students, or mentors, or slots?
b. =A0sadly, not all students complete the summer. =A0how do we
recover if even one person drops out?
c. =A0do we have someone qualified to be scrum master for
10 people (5 students and 5 mentors)? =A0with enough time?
d. =A05 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


--047d7b33d67ca7633e04f1ac911d--