From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <3b72cf2290d28c849e1f7a5ffde134a6@mikro.quanstro.net> References: <5778ffc079ca4ad7227b37b1158b29f1@proxima.alt.za> <3b72cf2290d28c849e1f7a5ffde134a6@mikro.quanstro.net> Date: Thu, 6 Feb 2014 01:41:00 +1100 Message-ID: From: Shane Morris To: erik quanstrom Content-Type: multipart/alternative; boundary=001a1136b374dfc2b104f1a9be4a Cc: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] Inferno and the Parallella Topicbox-Message-UUID: b6cc8476-ead8-11e9-9d60-3106f5b1d025 --001a1136b374dfc2b104f1a9be4a Content-Type: text/plain; charset=ISO-8859-1 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 > --001a1136b374dfc2b104f1a9be4a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
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&= #39;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 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 quanstrom <quanstro@quanstro.net>= ; wrote:
> Oh, its ok. I like th= e 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

--001a1136b374dfc2b104f1a9be4a--