From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 From: Cyber Fonic Date: Fri, 26 Jul 2019 16:37:13 +1000 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary="000000000000bd5640058e8fc697" Subject: [9fans] Plan 9 C compiler for Xtensa CPUs Topicbox-Message-UUID: 02ffece2-eada-11e9-9d60-3106f5b1d025 --000000000000bd5640058e8fc697 Content-Type: text/plain; charset="UTF-8" I was reading the post Why Didn't Plan 9 Succeed on Hacker News. Made me think that Plan 9 for IoT system of systems could be viable. To that end, ESP-32 modules look capable enough to run Plan 9, but is there a Plan 9 C compiler for Xtensa ISA CPUs? --000000000000bd5640058e8fc697 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I was reading the post=C2=A0Why Didn't Plan 9 Succeed=C2=A0on Hac= ker News.

Made me think that Plan 9 for IoT system of sy= stems could be viable.

To that end, ESP-32 modules= look capable enough to run Plan 9, but is there a Plan 9 C compiler for Xt= ensa ISA CPUs?=C2=A0

--000000000000bd5640058e8fc697-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Rodrigo_G=2E_L=C3=B3pez?= Date: Fri, 26 Jul 2019 12:02:49 +0200 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary="000000000000024b84058e92a671" Subject: Re: [9fans] Plan 9 C compiler for Xtensa CPUs Topicbox-Message-UUID: 0303f95e-eada-11e9-9d60-3106f5b1d025 --000000000000024b84058e92a671 Content-Type: text/plain; charset="UTF-8" there is not. contributions are welcome. :) -rodri On Fri, Jul 26, 2019, 8:38 AM Cyber Fonic wrote: > I was reading the post Why Didn't Plan 9 Succeed > on Hacker News. > > Made me think that Plan 9 for IoT system of systems could be viable. > > To that end, ESP-32 modules look capable enough to run Plan 9, but is > there a Plan 9 C compiler for Xtensa ISA CPUs? > > --000000000000024b84058e92a671 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

there is not.

contributions are welcome. :)

-rodri

On Fri, Jul 26, 2019, 8:3= 8 AM Cyber Fonic <cyberfonic@gma= il.com> wrote:

I was reading the post=C2=A0Why Didn't Plan 9= Succeed=C2=A0on Hacker News.

Made me think that Pla= n 9 for IoT system of systems could be viable.

To = that end, ESP-32 modules look capable enough to run Plan 9, but is there a = Plan 9 C compiler for Xtensa ISA CPUs?=C2=A0

--000000000000024b84058e92a671-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References: In-Reply-To: From: Charles Forsyth Date: Fri, 26 Jul 2019 11:30:02 +0100 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary="0000000000000ab13a058e9307bd" Subject: Re: [9fans] Plan 9 C compiler for Xtensa CPUs Topicbox-Message-UUID: 03083550-eada-11e9-9d60-3106f5b1d025 --0000000000000ab13a058e9307bd Content-Type: text/plain; charset="UTF-8" I was thinking of doing that since I've got an ESP-32 for some reason On Fri, Jul 26, 2019 at 7:38 AM Cyber Fonic wrote: > I was reading the post Why Didn't Plan 9 Succeed > on Hacker News. > > Made me think that Plan 9 for IoT system of systems could be viable. > > To that end, ESP-32 modules look capable enough to run Plan 9, but is > there a Plan 9 C compiler for Xtensa ISA CPUs? > > --0000000000000ab13a058e9307bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I was thinking of doing that since I've got an ESP-32 = for some reason

On Fri, Jul 26, 2019 at 7:38 AM Cyber Fonic <cyberfonic@gmail.com> wrote:

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">

I was rea= ding the post=C2=A0Why Didn't Plan 9 Succeed=C2=A0on Hacker News= .

Made me think that Plan 9 for IoT system of systems co= uld be viable.

To that end, ESP-32 modules look ca= pable enough to run Plan 9, but is there a Plan 9 C compiler for Xtensa ISA= CPUs?=C2=A0

--0000000000000ab13a058e9307bd-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References:

In-Reply-To: From: =?UTF-8?Q?Rodrigo_G=2E_L=C3=B3pez?= Date: Fri, 26 Jul 2019 14:04:29 +0200 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary="000000000000eee867058e945828" Subject: Re: [9fans] Plan 9 C compiler for Xtensa CPUs Topicbox-Message-UUID: 030c57e8-eada-11e9-9d60-3106f5b1d025 --000000000000eee867058e945828 Content-Type: text/plain; charset="UTF-8" you are one of the few who could pull that off. the alternative would be to send the board to cinap, and he'd probably deploy a compiler+kernel in a couple of weeks. On Fri, Jul 26, 2019, 12:31 PM Charles Forsyth wrote: > I was thinking of doing that since I've got an ESP-32 for some reason > > On Fri, Jul 26, 2019 at 7:38 AM Cyber Fonic wrote: > >> I was reading the post Why Didn't Plan 9 Succeed >> on Hacker News. >> >> Made me think that Plan 9 for IoT system of systems could be viable. >> >> To that end, ESP-32 modules look capable enough to run Plan 9, but is >> there a Plan 9 C compiler for Xtensa ISA CPUs? >> >> --000000000000eee867058e945828 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

you are one of the few who could pull that off.

the alternative would be to send the board to cinap, and= he'd probably deploy a compiler+kernel in a couple of weeks.

On Fri, Jul 26, 2019, 12:31 PM Charles Forsyth <charles.forsyth@gmail.com> wrote:

I was thinking of doing that s= ince I've got an ESP-32 for some reason

On Fri, Jul 26, 2019 at 7:38 AM = Cyber Fonic <cyberfonic@gmail.com> wrote:

I was reading the po= st=C2=A0Why Didn't Plan 9 Succeed=C2=A0on Ha= cker News.

Made me think that Plan 9 for IoT system of s= ystems could be viable.

To that end, ESP-32 module= s look capable enough to run Plan 9, but is there a Plan 9 C compiler for X= tensa ISA CPUs?=C2=A0

--000000000000eee867058e945828-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References:

In-Reply-To: From: Cyber Fonic Date: Fri, 26 Jul 2019 22:12:43 +1000 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary="00000000000090c910058e9476bc" Subject: Re: [9fans] Plan 9 C compiler for Xtensa CPUs Topicbox-Message-UUID: 03117692-eada-11e9-9d60-3106f5b1d025 --00000000000090c910058e9476bc Content-Type: text/plain; charset="UTF-8" Does anybody have any suggestions as to what it would take to create a C compiler for Xtensa (it is basically a 32 bit sorta-like RISC architecture)? Since C compilers do exist for Xtensa (both Arduino and ESIF) , is it at all possible to port Plan 9 C compilers using a "host" compiler as a semi-bootstrap? Or would it be more effectively to use an existing Plan 9 system, grab the sources for a similar compiler, e.g. MIPS and start building a Xtensa / ESP-32 specific one? On Fri, 26 Jul 2019 at 20:31, Charles Forsyth wrote: > I was thinking of doing that since I've got an ESP-32 for some reason > > On Fri, Jul 26, 2019 at 7:38 AM Cyber Fonic wrote: > >> I was reading the post Why Didn't Plan 9 Succeed >> on Hacker News. >> >> Made me think that Plan 9 for IoT system of systems could be viable. >> >> To that end, ESP-32 modules look capable enough to run Plan 9, but is >> there a Plan 9 C compiler for Xtensa ISA CPUs? >> >> --00000000000090c910058e9476bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Does anybody have any suggestions as to what it would take= to create a C compiler for Xtensa (it is basically a 32 bit sorta-like RIS= C architecture)?

Since C compilers do exist for Xtensa (= both Arduino and ESIF) , is it at all possible to port Plan 9 C compilers u= sing a "host" compiler as a semi-bootstrap?

<= div>Or would it be more effectively to use an existing Plan 9 system, grab = the sources for a similar compiler, e.g. MIPS and start building a Xtensa /= ESP-32 specific one?

On Fri, 26 Jul 2019 at 20:31, Charles Forsyth &l= t;charles.forsyth@gmail.com> wrote:

I was thinking of doing that since I've got an ESP-32 for= some reason

On Fri, Jul 26, 2019 at 7:38 AM Cyber Fonic <cyberfonic@gmail.com> wro= te:

I was reading the post=C2=A0Why Didn't Plan 9 Succeed=C2=A0= on Hacker News.

Made me think that Plan 9 for IoT system= of systems could be viable.

To that end, ESP-32 m= odules look capable enough to run Plan 9, but is there a Plan 9 C compiler = for Xtensa ISA CPUs?=C2=A0

--00000000000090c910058e9476bc-- From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <96CEB1CA62B67D504085AEB6BEE66264@felloff.net> Date: Fri, 26 Jul 2019 15:16:47 +0200 From: cinap_lenrek@felloff.net To: 9fans@9fans.net In-Reply-To: CA+cCjXp0SMUr4a67+wkQ+s-iCjM77HomXodh1riofTaoD3Scfg@mail.gmail.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Plan 9 C compiler for Xtensa CPUs Topicbox-Message-UUID: 03162318-eada-11e9-9d60-3106f5b1d025 nope. charles is your man. -- cinap From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References:

In-Reply-To: From: Charles Forsyth Date: Fri, 26 Jul 2019 16:23:42 +0100 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary="000000000000465cf5058e9721fc" Subject: Re: [9fans] Plan 9 C compiler for Xtensa CPUs Topicbox-Message-UUID: 031e5e3e-eada-11e9-9d60-3106f5b1d025 --000000000000465cf5058e9721fc Content-Type: text/plain; charset="UTF-8" I'd need a letter or number and thought about reusing x (xa/xc/xl) since the AT&T DSP is long gone On Fri, Jul 26, 2019 at 11:30 AM Charles Forsyth wrote: > I was thinking of doing that since I've got an ESP-32 for some reason > > On Fri, Jul 26, 2019 at 7:38 AM Cyber Fonic wrote: > >> I was reading the post Why Didn't Plan 9 Succeed >> on Hacker News. >> >> Made me think that Plan 9 for IoT system of systems could be viable. >> >> To that end, ESP-32 modules look capable enough to run Plan 9, but is >> there a Plan 9 C compiler for Xtensa ISA CPUs? >> >> --000000000000465cf5058e9721fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I'd need a letter or number and thought about reusing = x (xa/xc/xl) since the AT&T DSP is long gone

On Fri, Jul 26, 2019 at 11:= 30 AM Charles Forsyth <charles.forsyth@gmail.com> wrote:

I was thinking of d= oing that since I've got an ESP-32 for some reason

On Fri, Jul 26, 2019= at 7:38 AM Cyber Fonic <cyberfonic@gmail.com> wrote:

I was reading the post=C2= =A0Why Didn't Plan 9 Succeed=C2=A0on Hacker News.

=
Made me think that Plan 9 for IoT system of systems could be viable.

To that end, ESP-32 modules look capable enough to = run Plan 9, but is there a Plan 9 C compiler for Xtensa ISA CPUs?=C2=A0

--000000000000465cf5058e9721fc-- From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Sat, 27 Jul 2019 02:16:50 -0700 From: Anthony Martin To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20190727091650.GA10231@alice> References:

MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [9fans] Plan 9 C compiler for Xtensa CPUs Topicbox-Message-UUID: 032bbc50-eada-11e9-9d60-3106f5b1d025 Charles Forsyth once said: > I'd need a letter or number and thought about reusing x (xa/xc/xl) since > the AT&T DSP is long gone https://github.com/0intro/plan9-mips/tree/master/sys/src/cmd/4c https://github.com/0intro/plan9-mips/blob/master/rc/bin/xc I think I sent this to the list once before but here's a table that I made a while back. https://www.pbrane.org/comp.html The number 3 is free. Cheers, Anthony From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@9fans.net From: Richard Miller <9fans@hamnavoe.com> Date: Sat, 27 Jul 2019 12:10:15 +0100 In-Reply-To: <20190727091650.GA10231@alice> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Plan 9 C compiler for Xtensa CPUs Topicbox-Message-UUID: 033b7f0a-eada-11e9-9d60-3106f5b1d025 > https://www.pbrane.org/comp.html I've used .x for riscv32 but it's easily changed. I see the above list uses .e and .j for riscv and riscv64 - are these just reserved or are there actual compilers somewhere? From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Sat, 27 Jul 2019 09:29:34 -0700 From: Anthony Martin To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20190727162934.GA27798@alice> References: <20190727091650.GA10231@alice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [9fans] Plan 9 C compiler for Xtensa CPUs Topicbox-Message-UUID: 033f8226-eada-11e9-9d60-3106f5b1d025 Richard Miller <9fans@hamnavoe.com> once said: > I see the above list uses .e and .j for riscv and riscv64 - > are these just reserved or are there actual compilers somewhere? No, it was just a suggestion on my part. If I remember correctly, I thought it was mildly clever that 'e' is the fifth letter in the English alphabet and 'j' is five letters after that. I'm only aware of your riscv compiler. Anthony From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References:

In-Reply-To: From: Charles Forsyth Date: Wed, 7 Aug 2019 01:22:59 +0100 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary="0000000000003453bf058f7bf290" Subject: Re: [9fans] Plan 9 C compiler for Xtensa CPUs Topicbox-Message-UUID: 0364b73a-eada-11e9-9d60-3106f5b1d025 --0000000000003453bf058f7bf290 Content-Type: text/plain; charset="UTF-8" I've not previously seen an architecture where so many cache and TLB control instructions were in the primary space and took up so much of it. On Fri, Jul 26, 2019 at 11:30 AM Charles Forsyth wrote: > I was thinking of doing that since I've got an ESP-32 for some reason > > On Fri, Jul 26, 2019 at 7:38 AM Cyber Fonic wrote: > >> I was reading the post Why Didn't Plan 9 Succeed >> on Hacker News. >> >> Made me think that Plan 9 for IoT system of systems could be viable. >> >> To that end, ESP-32 modules look capable enough to run Plan 9, but is >> there a Plan 9 C compiler for Xtensa ISA CPUs? >> >> --0000000000003453bf058f7bf290 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I've not previously seen an architecture where so many= cache and TLB control instructions were in the primary space and took up s= o much of it.

On Fri, Jul 26, 2019 at 11:30 AM Charles Fors= yth <charles.forsyth@gmail.= com> wrote:

I was thinking of doing that since I've got an ESP-= 32 for some reason

On Fri, Jul 26, 2019 at 7:38 AM Cyber Fonic <cyberfonic@gmail.com= > wrote:
I was reading the post=C2=A0Why Didn't Plan 9 Succeed=C2=A0on Hacker News.

Made me think that Plan 9 for Io= T system of systems could be viable.

To that end, = ESP-32 modules look capable enough to run Plan 9, but is there a Plan 9 C c= ompiler for Xtensa ISA CPUs?=C2=A0

--0000000000003453bf058f7bf290-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References:

From: Lucio De Re Date: Wed, 7 Aug 2019 10:07:32 +0200 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset="UTF-8" Subject: Re: [9fans] Plan 9 C compiler for Xtensa CPUs Topicbox-Message-UUID: 0368e6fc-eada-11e9-9d60-3106f5b1d025 On 8/7/19, Charles Forsyth wrote: > I've not previously seen an architecture where so many cache and TLB > control instructions were in the primary space and took up so much of it. > I guess the remainder is RISC :-). Lucio. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bakul Shah Content-Type: multipart/alternative; boundary=Apple-Mail-1D6BF737-0F41-4BA5-8D24-299C78608572 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Date: Fri, 9 Aug 2019 07:17:46 -0700 Message-Id: <40745EA5-3815-4E4F-9FE0-8F83697E74BA@bitblocks.com> References:

In-Reply-To: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] Plan 9 C compiler for Xtensa CPUs Topicbox-Message-UUID: 03999428-eada-11e9-9d60-3106f5b1d025 --Apple-Mail-1D6BF737-0F41-4BA5-8D24-299C78608572 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable esp32 doesn=E2=80=99t have an mmu, right? > On Jul 26, 2019, at 03:30, Charles Forsyth wro= te: >=20 > I was thinking of doing that since I've got an ESP-32 for some reason >=20 >> On Fri, Jul 26, 2019 at 7:38 AM Cyber Fonic wrote:= >> I was reading the post Why Didn't Plan 9 Succeed on Hacker News. >>=20 >> Made me think that Plan 9 for IoT system of systems could be viable. >>=20 >> To that end, ESP-32 modules look capable enough to run Plan 9, but is the= re a Plan 9 C compiler for Xtensa ISA CPUs?=20 >>=20 --Apple-Mail-1D6BF737-0F41-4BA5-8D24-299C78608572 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

esp= 32 doesn=E2=80=99t have an mmu, right?

On Jul 26, 2= 019, at 03:30, Charles Forsyth <charles.forsyth@gmail.com> wrote:

I was thinking of doing that since I= 've got an ESP-32 for some reason

On Fri, Jul 26, 2019 at 7:38 AM Cyber Fonic &= lt;cyberfonic@gmail.com> wrot= e:
I was reading the post Why Didn't Plan 9 Succeed on Hacker= News.

Made me think that Plan 9 for IoT system of system= s could be viable.

To that end, ESP-32 modules look= capable enough to run Plan 9, but is there a Plan 9 C compiler for Xtensa I= SA CPUs?

= --Apple-Mail-1D6BF737-0F41-4BA5-8D24-299C78608572-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References:

<40745EA5-3815-4E4F-9FE0-8F83697E74BA@bitblocks.com> In-Reply-To: <40745EA5-3815-4E4F-9FE0-8F83697E74BA@bitblocks.com> From: Charles Forsyth Date: Fri, 9 Aug 2019 15:50:13 +0100 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary="0000000000005a0b1e058fb04bf5" Subject: Re: [9fans] Plan 9 C compiler for Xtensa CPUs Topicbox-Message-UUID: 03a2ad24-eada-11e9-9d60-3106f5b1d025 --0000000000005a0b1e058fb04bf5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The ESP32 has got several MMUs. The characteristics are different depending on the part that a given MMU accesses (flash, ROM, SRAM, external memory). Some things are accessed using Memory Protection Units instead, which control access by Process ID, but don't do mapping. Others including some of the SRAMs are accessed through an MMU that can do virtual to physical mapping. The MMUs for internal SRAM0 and 2 choose protection for a given physical page as none, one or all of PIDs 2 to 7, with the virtual address that maps to it. PIDs 0 and 1 can access everything. PID 0 can execute privileged instructions. A large chunk of SRAM (SRAM 1) has only Memory Protection and no translation. The external memory MMU is the most general (most conventional). On Fri, Aug 9, 2019 at 3:19 PM Bakul Shah wrote: > esp32 doesn=E2=80=99t have an mmu, right? > > On Jul 26, 2019, at 03:30, Charles Forsyth > wrote: > > I was thinking of doing that since I've got an ESP-32 for some reason > > On Fri, Jul 26, 2019 at 7:38 AM Cyber Fonic wrote: > >> I was reading the post Why Didn't Plan 9 Succeed >> on Hacker News. >> >> Made me think that Plan 9 for IoT system of systems could be viable. >> >> To that end, ESP-32 modules look capable enough to run Plan 9, but is >> there a Plan 9 C compiler for Xtensa ISA CPUs? >> >> --0000000000005a0b1e058fb04bf5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

The ESP32 has got several MMUs. The characteristics are di= fferent depending on the part that a given MMU accesses (flash, ROM, SRAM, = external memory).

Some things are accessed using Memory Protection Unit= s instead, which control access by Process ID, but don't do mapping. Ot= hers including some of the SRAMs are accessed through

an MMU that= can do virtual to physical mapping. The MMUs for internal SRAM0 and 2 choo= se protection for a given physical page as none, one or all of PIDs 2 to 7,= with the virtual address that

maps to it. PIDs 0 and 1 can acces= s everything. PID 0 can execute privileged instructions.

A large = chunk of SRAM (SRAM 1) has only Memory Protection and no translation. The e= xternal memory MMU is the most general (most conventional).

On Fri, Au= g 9, 2019 at 3:19 PM Bakul Shah <= bakul@bitblocks.com> wrote:

esp32 doesn=E2=80=99t have an mmu, right?

On Ju= l 26, 2019, at 03:30, Charles Forsyth <charles.forsyth@gmail.com> wrote:
<= br>
I was = thinking of doing that since I've got an ESP-32 for some reason
On Fri, = Jul 26, 2019 at 7:38 AM Cyber Fonic <cyberfonic@gmail.com> wrote:
I was reading t= he post=C2=A0Why Didn't Plan 9 Succeed=C2=A0on Hacker News.
=
Made me think that Plan 9 for IoT system of systems could be= viable.

To that end, ESP-32 modules look capable = enough to run Plan 9, but is there a Plan 9 C compiler for Xtensa ISA CPUs?= =C2=A0

--0000000000005a0b1e058fb04bf5-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References:

<40745EA5-3815-4E4F-9FE0-8F83697E74BA@bitblocks.com> In-Reply-To: From: Charles Forsyth Date: Fri, 9 Aug 2019 16:50:40 +0100 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary="0000000000008ae112058fb12380" Subject: Re: [9fans] Plan 9 C compiler for Xtensa CPUs Topicbox-Message-UUID: 03a999ae-eada-11e9-9d60-3106f5b1d025 --0000000000008ae112058fb12380 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The device I've got is ESP32-WROOM-32. None of the boards I've seen that use it bother with external memory, so memory is limited, especially the way it's partitioned. On Fri, Aug 9, 2019 at 3:50 PM Charles Forsyth wrote: > The ESP32 has got several MMUs. The characteristics are different > depending on the part that a given MMU accesses (flash, ROM, SRAM, extern= al > memory). > Some things are accessed using Memory Protection Units instead, which > control access by Process ID, but don't do mapping. Others including some > of the SRAMs are accessed through > an MMU that can do virtual to physical mapping. The MMUs for internal > SRAM0 and 2 choose protection for a given physical page as none, one or a= ll > of PIDs 2 to 7, with the virtual address that > maps to it. PIDs 0 and 1 can access everything. PID 0 can execute > privileged instructions. > A large chunk of SRAM (SRAM 1) has only Memory Protection and no > translation. The external memory MMU is the most general (most > conventional). > > On Fri, Aug 9, 2019 at 3:19 PM Bakul Shah wrote: > >> esp32 doesn=E2=80=99t have an mmu, right? >> >> On Jul 26, 2019, at 03:30, Charles Forsyth >> wrote: >> >> I was thinking of doing that since I've got an ESP-32 for some reason >> >> On Fri, Jul 26, 2019 at 7:38 AM Cyber Fonic wrote= : >> >>> I was reading the post Why Didn't Plan 9 Succeed >>> on Hacker News. >>> >>> Made me think that Plan 9 for IoT system of systems could be viable. >>> >>> To that end, ESP-32 modules look capable enough to run Plan 9, but is >>> there a Plan 9 C compiler for Xtensa ISA CPUs? >>> >>> --0000000000008ae112058fb12380 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

The device I've got is ESP32-WROOM-32. None of the boa= rds I've seen that use it bother with external memory,

so memory is= limited, especially the way it's partitioned.

On Fri, Aug 9, 2019= at 3:50 PM Charles Forsyth <charles.forsyth@gmail.com> wrote:

The ESP32 has got several MMUs.= The characteristics are different depending on the part that a given MMU a= ccesses (flash, ROM, SRAM, external memory).
Some things are accessed u= sing Memory Protection Units instead, which control access by Process ID, b= ut don't do mapping. Others including some of the SRAMs are accessed th= rough
an MMU that can do virtual to physical mapping. The MMUs fo= r internal SRAM0 and 2 choose protection for a given physical page as none,= one or all of PIDs 2 to 7, with the virtual address that
maps to= it. PIDs 0 and 1 can access everything. PID 0 can execute privileged instr= uctions.
A large chunk of SRAM (SRAM 1) has only Memory Protectio= n and no translation. The external memory MMU is the most general (most con= ventional).

On Fri, Aug 9, 2019 at 3:19 PM Bakul Shah <bakul@bitblocks.com> wr= ote:
esp32 doesn=E2=80=99t have a= n mmu, right?

On Jul 26, 2019, at 03:30, Charles = Forsyth <= charles.forsyth@gmail.com> wrote:

I was thinking of doing that since I= 've got an ESP-32 for some reason

<= div dir=3D"ltr" class=3D"gmail_attr">On Fri, Jul 26, 2019 at 7:38 AM Cyber = Fonic <cyberfo= nic@gmail.com> wrote:
I was reading the post=C2=A0Why Didn't= Plan 9 Succeed=C2=A0on Hacker News.

Made me think t= hat Plan 9 for IoT system of systems could be viable.

<= div>To that end, ESP-32 modules look capable enough to run Plan 9, but is t= here a Plan 9 C compiler for Xtensa ISA CPUs?=C2=A0

--0000000000008ae112058fb12380-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References:

<40745EA5-3815-4E4F-9FE0-8F83697E74BA@bitblocks.com> In-Reply-To: From: Charles Forsyth Date: Fri, 9 Aug 2019 22:34:43 +0100 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary="000000000000efa9b6058fb5f17b" Subject: Re: [9fans] Plan 9 C compiler for Xtensa CPUs Topicbox-Message-UUID: 03dfe504-eada-11e9-9d60-3106f5b1d025 --000000000000efa9b6058fb5f17b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Since the resources are small if not tiny, a little systems analysis and design is probably needed, but it looks like a bit of fun, until the inevitable moment of "why am I here?". On Fri, Aug 9, 2019 at 4:50 PM Charles Forsyth wrote: > The device I've got is ESP32-WROOM-32. None of the boards I've seen that > use it bother with external memory, > so memory is limited, especially the way it's partitioned. > > On Fri, Aug 9, 2019 at 3:50 PM Charles Forsyth > wrote: > >> The ESP32 has got several MMUs. The characteristics are different >> depending on the part that a given MMU accesses (flash, ROM, SRAM, exter= nal >> memory). >> Some things are accessed using Memory Protection Units instead, which >> control access by Process ID, but don't do mapping. Others including som= e >> of the SRAMs are accessed through >> an MMU that can do virtual to physical mapping. The MMUs for internal >> SRAM0 and 2 choose protection for a given physical page as none, one or = all >> of PIDs 2 to 7, with the virtual address that >> maps to it. PIDs 0 and 1 can access everything. PID 0 can execute >> privileged instructions. >> A large chunk of SRAM (SRAM 1) has only Memory Protection and no >> translation. The external memory MMU is the most general (most >> conventional). >> >> On Fri, Aug 9, 2019 at 3:19 PM Bakul Shah wrote: >> >>> esp32 doesn=E2=80=99t have an mmu, right? >>> >>> On Jul 26, 2019, at 03:30, Charles Forsyth >>> wrote: >>> >>> I was thinking of doing that since I've got an ESP-32 for some reason >>> >>> On Fri, Jul 26, 2019 at 7:38 AM Cyber Fonic >>> wrote: >>> >>>> I was reading the post Why Didn't Plan 9 Succeed >>>> on Hacker News. >>>> >>>> Made me think that Plan 9 for IoT system of systems could be viable. >>>> >>>> To that end, ESP-32 modules look capable enough to run Plan 9, but is >>>> there a Plan 9 C compiler for Xtensa ISA CPUs? >>>> >>>> --000000000000efa9b6058fb5f17b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Since the resources are small if not tiny, a little system= s analysis and design is probably needed, but it looks like a bit of fun, u= ntil the inevitable moment of "why am I here?".

On Fri, Aug 9, 201= 9 at 4:50 PM Charles Forsyth <charles.forsyth@gmail.com> wrote:

The device I've got is ESP= 32-WROOM-32. None of the boards I've seen that use it bother with exter= nal memory,
so memory is limited, especially the way it's partition= ed.

On Fri, Aug 9, 2019 at 3:50 PM Charles Forsyth <charles.forsyth@gmail.com> wrote:
The ESP32 has got several MMUs. The characteristics are diff= erent depending on the part that a given MMU accesses (flash, ROM, SRAM, ex= ternal memory).
Some things are accessed using Memory Protection Units = instead, which control access by Process ID, but don't do mapping. Othe= rs including some of the SRAMs are accessed through
an MMU that c= an do virtual to physical mapping. The MMUs for internal SRAM0 and 2 choose= protection for a given physical page as none, one or all of PIDs 2 to 7, w= ith the virtual address that
maps to it. PIDs 0 and 1 can access = everything. PID 0 can execute privileged instructions.
A large ch= unk of SRAM (SRAM 1) has only Memory Protection and no translation. The ext= ernal memory MMU is the most general (most conventional).

On Fri, Aug = 9, 2019 at 3:19 PM Bakul Shah <bakul@bitblocks.com> wrote:
esp32 doesn=E2=80=99t have an mmu, right?

On Jul 26, 2019, at 03:30, Charles Forsyth <charles.forsyth@gmail.com> wrote:

I was thinking of doing that since I've got an ESP-32 for s= ome reason

On Fri, Jul 26, 2019 at 7:38 AM Cyber Fonic <cyberfonic@gmail.com> wrote= :
I was reading the post=C2=A0Why Didn't Plan 9 Succeed=C2=A0on= Hacker News.

Made me think that Plan 9 for IoT system o= f systems could be viable.

To that end, ESP-32 mod= ules look capable enough to run Plan 9, but is there a Plan 9 C compiler fo= r Xtensa ISA CPUs?=C2=A0

--000000000000efa9b6058fb5f17b-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References:

<40745EA5-3815-4E4F-9FE0-8F83697E74BA@bitblocks.com> In-Reply-To: From: Shane Morris Date: Sat, 10 Aug 2019 07:48:08 +1000 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary="0000000000001091bf058fb6229f" Subject: Re: [9fans] Plan 9 C compiler for Xtensa CPUs Topicbox-Message-UUID: 03e42402-eada-11e9-9d60-3106f5b1d025 --0000000000001091bf058fb6229f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Wireless NinePea perhaps? https://github.com/echoline/NinePea On Sat, Aug 10, 2019 at 7:36 AM Charles Forsyth wrote: > Since the resources are small if not tiny, a little systems analysis and > design is probably needed, but it looks like a bit of fun, until the > inevitable moment of "why am I here?". > > On Fri, Aug 9, 2019 at 4:50 PM Charles Forsyth > wrote: > >> The device I've got is ESP32-WROOM-32. None of the boards I've seen that >> use it bother with external memory, >> so memory is limited, especially the way it's partitioned. >> >> On Fri, Aug 9, 2019 at 3:50 PM Charles Forsyth >> wrote: >> >>> The ESP32 has got several MMUs. The characteristics are different >>> depending on the part that a given MMU accesses (flash, ROM, SRAM, exte= rnal >>> memory). >>> Some things are accessed using Memory Protection Units instead, which >>> control access by Process ID, but don't do mapping. Others including so= me >>> of the SRAMs are accessed through >>> an MMU that can do virtual to physical mapping. The MMUs for internal >>> SRAM0 and 2 choose protection for a given physical page as none, one or= all >>> of PIDs 2 to 7, with the virtual address that >>> maps to it. PIDs 0 and 1 can access everything. PID 0 can execute >>> privileged instructions. >>> A large chunk of SRAM (SRAM 1) has only Memory Protection and no >>> translation. The external memory MMU is the most general (most >>> conventional). >>> >>> On Fri, Aug 9, 2019 at 3:19 PM Bakul Shah wrote: >>> >>>> esp32 doesn=E2=80=99t have an mmu, right? >>>> >>>> On Jul 26, 2019, at 03:30, Charles Forsyth >>>> wrote: >>>> >>>> I was thinking of doing that since I've got an ESP-32 for some reason >>>> >>>> On Fri, Jul 26, 2019 at 7:38 AM Cyber Fonic >>>> wrote: >>>> >>>>> I was reading the post Why Didn't Plan 9 Succeed >>>>> on Hacker News. >>>>> >>>>> Made me think that Plan 9 for IoT system of systems could be viable. >>>>> >>>>> To that end, ESP-32 modules look capable enough to run Plan 9, but is >>>>> there a Plan 9 C compiler for Xtensa ISA CPUs? >>>>> >>>>> --0000000000001091bf058fb6229f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Wireless NinePea perhaps?

https://github.com/echoline/N= inePea

On Sat, Aug 10, 2019 at 7:36 AM Charles Forsyth <charles.forsyth@gmail.com> wro= te:

Since the resources are small if not tiny, a little systems analysis a= nd design is probably needed, but it looks like a bit of fun, until the ine= vitable moment of "why am I here?".

On Fri, Aug 9, 2019 at 4:50 PM= Charles Forsyth <charles.forsyth@gmail.com> wrote:
The device I've got = is ESP32-WROOM-32. None of the boards I've seen that use it bother with= external memory,
so memory is limited, especially the way it's par= titioned.

On Fri, Aug 9, 2019 at 3:50 PM Charles Forsyth <charles.forsyth@gma= il.com> wrote:
The ESP32 has got several MMUs. The characteristics = are different depending on the part that a given MMU accesses (flash, ROM, = SRAM, external memory).
Some things are accessed using Memory Protectio= n Units instead, which control access by Process ID, but don't do mappi= ng. Others including some of the SRAMs are accessed through
an MM= U that can do virtual to physical mapping. The MMUs for internal SRAM0 and = 2 choose protection for a given physical page as none, one or all of PIDs 2= to 7, with the virtual address that
maps to it. PIDs 0 and 1 can= access everything. PID 0 can execute privileged instructions.
A = large chunk of SRAM (SRAM 1) has only Memory Protection and no translation.= The external memory MMU is the most general (most conventional).

On F= ri, Aug 9, 2019 at 3:19 PM Bakul Shah <bakul@bitblocks.com> wrote:
esp32 doesn=E2=80=99t have an mmu, right?

On Jul 26, 2019, at 03:30, Charles Forsyth <charles.forsyth@gma= il.com> wrote:

I was thinking of doing that since I've got an ESP-= 32 for some reason

On Fri, Jul 26, 2019 at 7:38 AM Cyber Fonic <cyberfonic@gmail.com= > wrote:
I was reading the post=C2=A0Why Didn't Plan 9 Succeed=C2=A0on Hacker News.

Made me think that Plan 9 for Io= T system of systems could be viable.

To that end, = ESP-32 modules look capable enough to run Plan 9, but is there a Plan 9 C c= ompiler for Xtensa ISA CPUs?=C2=A0

--0000000000001091bf058fb6229f-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bakul Shah Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 9 Aug 2019 15:51:22 -0700 References:

<40745EA5-3815-4E4F-9FE0-8F83697E74BA@bitblocks.com> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-Reply-To: Message-Id: Subject: Re: [9fans] Plan 9 C compiler for Xtensa CPUs Topicbox-Message-UUID: 03fa245a-eada-11e9-9d60-3106f5b1d025 On Aug 9, 2019, at 2:34 PM, Charles Forsyth = wrote: >=20 > Since the resources are small if not tiny, a little systems analysis = and design is probably needed, but it looks like a bit of fun, until the = inevitable moment of "why am I here?". >=20 > On Fri, Aug 9, 2019 at 4:50 PM Charles Forsyth = wrote: > The device I've got is ESP32-WROOM-32. None of the boards I've seen = that use it bother with external memory, > so memory is limited, especially the way it's partitioned. >=20 > On Fri, Aug 9, 2019 at 3:50 PM Charles Forsyth = wrote: > The ESP32 has got several MMUs. The characteristics are different = depending on the part that a given MMU accesses (flash, ROM, SRAM, = external memory). > Some things are accessed using Memory Protection Units instead, which = control access by Process ID, but don't do mapping. Others including = some of the SRAMs are accessed through > an MMU that can do virtual to physical mapping. The MMUs for internal = SRAM0 and 2 choose protection for a given physical page as none, one or = all of PIDs 2 to 7, with the virtual address that > maps to it. PIDs 0 and 1 can access everything. PID 0 can execute = privileged instructions. > A large chunk of SRAM (SRAM 1) has only Memory Protection and no = translation. The external memory MMU is the most general (most = conventional). Thanks. Not ideal for plan9 but it would be nice to have access to all its IO = capabilities over 9p.= From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References:

<40745EA5-3815-4E4F-9FE0-8F83697E74BA@bitblocks.com> In-Reply-To: From: Skip Tavakkolian Date: Fri, 9 Aug 2019 15:53:59 -0700 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary="0000000000006ed7bd058fb70d7f" Subject: Re: [9fans] Plan 9 C compiler for Xtensa CPUs Topicbox-Message-UUID: 04010518-eada-11e9-9d60-3106f5b1d025 --0000000000006ed7bd058fb70d7f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm not sure if the effort would be worth it; but if you add support for esp32, I think it would be better for the os to be something like the one you had in kencc for AVR (*) or possibly Russ' libtask, rather than Plan 9. Staying with FreeRTOS would need removal of GCC specific things from OS and dealing with lots of drivers in C++. The Cortex-M based mpus (e.g. Teensy 4 with Cortex M7 @ 600MHz) seem more appropriate for an "embedded" Plan 9. (*) for those who have not seen it, it is here: % ls -l /n/sources/contrib/forsyth/avr* --rw-rw-r-- M 518 bootes sys 251227 Sep 4 2011 /n/sources/contrib/forsyth/avr.9gz On Fri, Aug 9, 2019 at 2:36 PM Charles Forsyth wrote: > Since the resources are small if not tiny, a little systems analysis and > design is probably needed, but it looks like a bit of fun, until the > inevitable moment of "why am I here?". > > On Fri, Aug 9, 2019 at 4:50 PM Charles Forsyth > wrote: > >> The device I've got is ESP32-WROOM-32. None of the boards I've seen that >> use it bother with external memory, >> so memory is limited, especially the way it's partitioned. >> >> On Fri, Aug 9, 2019 at 3:50 PM Charles Forsyth >> wrote: >> >>> The ESP32 has got several MMUs. The characteristics are different >>> depending on the part that a given MMU accesses (flash, ROM, SRAM, exte= rnal >>> memory). >>> Some things are accessed using Memory Protection Units instead, which >>> control access by Process ID, but don't do mapping. Others including so= me >>> of the SRAMs are accessed through >>> an MMU that can do virtual to physical mapping. The MMUs for internal >>> SRAM0 and 2 choose protection for a given physical page as none, one or= all >>> of PIDs 2 to 7, with the virtual address that >>> maps to it. PIDs 0 and 1 can access everything. PID 0 can execute >>> privileged instructions. >>> A large chunk of SRAM (SRAM 1) has only Memory Protection and no >>> translation. The external memory MMU is the most general (most >>> conventional). >>> >>> On Fri, Aug 9, 2019 at 3:19 PM Bakul Shah wrote: >>> >>>> esp32 doesn=E2=80=99t have an mmu, right? >>>> >>>> On Jul 26, 2019, at 03:30, Charles Forsyth >>>> wrote: >>>> >>>> I was thinking of doing that since I've got an ESP-32 for some reason >>>> >>>> On Fri, Jul 26, 2019 at 7:38 AM Cyber Fonic >>>> wrote: >>>> >>>>> I was reading the post Why Didn't Plan 9 Succeed >>>>> on Hacker News. >>>>> >>>>> Made me think that Plan 9 for IoT system of systems could be viable. >>>>> >>>>> To that end, ESP-32 modules look capable enough to run Plan 9, but is >>>>> there a Plan 9 C compiler for Xtensa ISA CPUs? >>>>> >>>>> --0000000000006ed7bd058fb70d7f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I'm not sure if the effort would be worth it; but if y= ou add support for esp32, I think it would be better for the os to be somet= hing like the one you had in kencc for AVR (*) or possibly Russ' libtas= k, rather than Plan 9. Staying with FreeRTOS would need removal of GCC spec= ific things from OS and dealing with lots of drivers in C++.

<= /div>

The Cortex-M based mpus (e.g. Teensy 4 with Cortex M7 @ 600MHz) s= eem more appropriate for an "embedded" Plan 9.

(*) for those who have not seen it, it is here:

% ls -l /n= /sources/contrib/forsyth/avr*

--rw-rw-r-- M 518 bootes sys 251227 Sep = =C2=A04 =C2=A02011 /n/sources/contrib/forsyth/avr.9gz

On Fri, Aug 9, 2= 019 at 2:36 PM Charles Forsyth <charles.forsyth@gmail.com> wrote:

Since the resources are smal= l if not tiny, a little systems analysis and design is probably needed, but= it looks like a bit of fun, until the inevitable moment of "why am I = here?".

On Fri, Aug 9, 2019 at 4:50 PM Charles Forsyth <charles.forsyth@gmail.co= m> wrote:
The device I've got is ESP32-WROOM-32. None of the bo= ards I've seen that use it bother with external memory,
so memory i= s limited, especially the way it's partitioned.

On Fri, Aug 9, 201= 9 at 3:50 PM Charles Forsyth <charles.forsyth@gmail.com> wrote:
The ESP32 ha= s got several MMUs. The characteristics are different depending on the part= that a given MMU accesses (flash, ROM, SRAM, external memory).
Some th= ings are accessed using Memory Protection Units instead, which control acce= ss by Process ID, but don't do mapping. Others including some of the SR= AMs are accessed through
an MMU that can do virtual to physical m= apping. The MMUs for internal SRAM0 and 2 choose protection for a given phy= sical page as none, one or all of PIDs 2 to 7, with the virtual address tha= t
maps to it. PIDs 0 and 1 can access everything. PID 0 can execu= te privileged instructions.
A large chunk of SRAM (SRAM 1) has on= ly Memory Protection and no translation. The external memory MMU is the mos= t general (most conventional).

On Fri, Aug 9, 2019 at 3:19 PM Bakul Sh= ah <bakul@bitbl= ocks.com> wrote:
esp32 doe= sn=E2=80=99t have an mmu, right?

On Jul 26, 2019,= at 03:30, Charles Forsyth <charles.forsyth@gmail.com> wrote:

I was thinking of= doing that since I've got an ESP-32 for some reason

On Fri, Jul 26, 201= 9 at 7:38 AM Cyber Fonic <cyberfonic@gmail.com> wrote:
I was reading the post=C2= =A0Why Didn't Plan 9 Succeed=C2=A0on Hacker News.

=
Made me think that Plan 9 for IoT system of systems could be viable.

To that end, ESP-32 modules look capable enough to = run Plan 9, but is there a Plan 9 C compiler for Xtensa ISA CPUs?=C2=A0

--0000000000006ed7bd058fb70d7f-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References:

<40745EA5-3815-4E4F-9FE0-8F83697E74BA@bitblocks.com>

In-Reply-To: From: Cyber Fonic Date: Sat, 10 Aug 2019 19:09:58 +1000 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary="000000000000aa5b5d058fbfa8cb" Subject: Re: [9fans] Plan 9 C compiler for Xtensa CPUs Topicbox-Message-UUID: 040e8d46-eada-11e9-9d60-3106f5b1d025 --000000000000aa5b5d058fbfa8cb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The emergent problem with IoT is the lack of security. From my understanding of Plan9's architecture. 9p protocol and the "root-less" security model suggests to me that a Plan9 swarm of IoT devices could be the "killer app" where Plan9 emerges on the strength of the vision of decades ago. Looking at other RT OSes the security models are often bolted on. Plan9 worked well on IBM PC era hardware. An ESP-32 has more resources and better networking than the early PCs. From my tinkering and reverse engineering of IoT devices, almost all use 8266 based WiFi and often in conjunction with a uController. An ESP-32 is dual processor and with sufficient I/O for most simple tasks. With IoT, in general, you don't need a lot of I/O, you simply throw more CPUs into the mix. On Sat, 10 Aug 2019 at 08:55, Skip Tavakkolian wrote: > I'm not sure if the effort would be worth it; but if you add support for > esp32, I think it would be better for the os to be something like the one > you had in kencc for AVR (*) or possibly Russ' libtask, rather than Plan = 9. > Staying with FreeRTOS would need removal of GCC specific things from OS a= nd > dealing with lots of drivers in C++. > > The Cortex-M based mpus (e.g. Teensy 4 with Cortex M7 @ 600MHz) seem more > appropriate for an "embedded" Plan 9. > > (*) for those who have not seen it, it is here: > % ls -l /n/sources/contrib/forsyth/avr* > --rw-rw-r-- M 518 bootes sys 251227 Sep 4 2011 > /n/sources/contrib/forsyth/avr.9gz > > On Fri, Aug 9, 2019 at 2:36 PM Charles Forsyth > wrote: > >> Since the resources are small if not tiny, a little systems analysis and >> design is probably needed, but it looks like a bit of fun, until the >> inevitable moment of "why am I here?". >> >> On Fri, Aug 9, 2019 at 4:50 PM Charles Forsyth >> wrote: >> >>> The device I've got is ESP32-WROOM-32. None of the boards I've seen tha= t >>> use it bother with external memory, >>> so memory is limited, especially the way it's partitioned. >>> >>> On Fri, Aug 9, 2019 at 3:50 PM Charles Forsyth < >>> charles.forsyth@gmail.com> wrote: >>> >>>> The ESP32 has got several MMUs. The characteristics are different >>>> depending on the part that a given MMU accesses (flash, ROM, SRAM, ext= ernal >>>> memory). >>>> Some things are accessed using Memory Protection Units instead, which >>>> control access by Process ID, but don't do mapping. Others including s= ome >>>> of the SRAMs are accessed through >>>> an MMU that can do virtual to physical mapping. The MMUs for internal >>>> SRAM0 and 2 choose protection for a given physical page as none, one o= r all >>>> of PIDs 2 to 7, with the virtual address that >>>> maps to it. PIDs 0 and 1 can access everything. PID 0 can execute >>>> privileged instructions. >>>> A large chunk of SRAM (SRAM 1) has only Memory Protection and no >>>> translation. The external memory MMU is the most general (most >>>> conventional). >>>> >>>> On Fri, Aug 9, 2019 at 3:19 PM Bakul Shah wrote: >>>> >>>>> esp32 doesn=E2=80=99t have an mmu, right? >>>>> >>>>> On Jul 26, 2019, at 03:30, Charles Forsyth >>>>> wrote: >>>>> >>>>> I was thinking of doing that since I've got an ESP-32 for some reason >>>>> >>>>> On Fri, Jul 26, 2019 at 7:38 AM Cyber Fonic >>>>> wrote: >>>>> >>>>>> I was reading the post Why Didn't Plan 9 Succeed >>>>>> on Hacker News. >>>>>> >>>>>> Made me think that Plan 9 for IoT system of systems could be viable. >>>>>> >>>>>> To that end, ESP-32 modules look capable enough to run Plan 9, but i= s >>>>>> there a Plan 9 C compiler for Xtensa ISA CPUs? >>>>>> >>>>>> --000000000000aa5b5d058fbfa8cb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

The emergent problem with IoT is the lack of security.=C2= =A0 From my understanding of Plan9's architecture. 9p protocol and the = "root-less" security model suggests to me that a Plan9 swarm of I= oT devices could be the "killer app" where Plan9 emerges on the s= trength of the vision of decades ago.=C2=A0 Looking at other RT OSes the se= curity models are often bolted on.=C2=A0 Plan9 worked well on IBM PC era ha= rdware. An ESP-32 has more resources and better networking than the early P= Cs.=C2=A0 From my tinkering and reverse engineering of IoT devices, almost = all use 8266 based WiFi and often in conjunction with a uController. An ESP= -32 is dual processor and with sufficient I/O for most simple tasks.=C2=A0 = With IoT, in general, you don't need a lot of I/O, you simply throw mor= e CPUs into the mix.

On Sat, 10 Aug 2019 at 08:55, Skip Tavakkolian <skip.tavakkolian@gmail.com>= ; wrote:

I'm not sure if the effort would be worth it; but if you add = support for esp32, I think it would be better for the os to be something li= ke the one you had in kencc for AVR (*) or possibly Russ' libtask, rath= er than Plan 9. Staying with FreeRTOS would need removal of GCC specific th= ings from OS and dealing with lots of drivers in C++.

The Cortex-M based mpus (e.g. Teensy 4 with Cortex M7 @ 600MHz) seem mor= e appropriate for an "embedded" Plan 9.

= (*) for those who have not seen it, it is here:
% ls -l /n/source= s/contrib/forsyth/avr*
--rw-rw-r-- M 518 bootes sys 251227 Sep =C2=A04= =C2=A02011 /n/sources/contrib/forsyth/avr.9gz

On Fri, Aug 9, 2019 at = 2:36 PM Charles Forsyth <charles.forsyth@gmail.com> wrote:

Since the resourc= es are small if not tiny, a little systems analysis and design is probably = needed, but it looks like a bit of fun, until the inevitable moment of &quo= t;why am I here?".

On Fri, Aug 9, 2019 at 4:50 PM Charles Forsyth <<= a href=3D"mailto:charles.forsyth@gmail.com" target=3D"_blank">charles.forsy= th@gmail.com> wrote:

The device I've got is ESP32-WROOM-32. Non= e of the boards I've seen that use it bother with external memory,
= so memory is limited, especially the way it's partitioned.
<= br>
On Fri,= Aug 9, 2019 at 3:50 PM Charles Forsyth <charles.forsyth@gmail.com> wrote:
T= he ESP32 has got several MMUs. The characteristics are different depending = on the part that a given MMU accesses (flash, ROM, SRAM, external memory).<= div>Some things are accessed using Memory Protection Units instead, which c= ontrol access by Process ID, but don't do mapping. Others including som= e of the SRAMs are accessed through
an MMU that can do virtual to= physical mapping. The MMUs for internal SRAM0 and 2 choose protection for = a given physical page as none, one or all of PIDs 2 to 7, with the virtual = address that
maps to it. PIDs 0 and 1 can access everything. PID = 0 can execute privileged instructions.
A large chunk of SRAM (SRA= M 1) has only Memory Protection and no translation. The external memory MMU= is the most general (most conventional).

On Fri, Aug 9, 2019 at 3:19 = PM Bakul Shah <= bakul@bitblocks.com> wrote:
esp32 doesn=E2=80=99t have an mmu, right?

On Ju= l 26, 2019, at 03:30, Charles Forsyth <charles.forsyth@gmail.com> wrote:
<= br>
I was = thinking of doing that since I've got an ESP-32 for some reason
On Fri, = Jul 26, 2019 at 7:38 AM Cyber Fonic <cyberfonic@gmail.com> wrote:
I was reading t= he post=C2=A0Why Didn't Plan 9 Succeed=C2=A0on Hacker News.
=
Made me think that Plan 9 for IoT system of systems could be= viable.

To that end, ESP-32 modules look capable = enough to run Plan 9, but is there a Plan 9 C compiler for Xtensa ISA CPUs?= =C2=A0

--000000000000aa5b5d058fbfa8cb-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References:

<40745EA5-3815-4E4F-9FE0-8F83697E74BA@bitblocks.com>

In-Reply-To: From: Shane Morris Date: Sat, 10 Aug 2019 19:15:57 +1000 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary="000000000000df5a82058fbfbde0" Subject: Re: [9fans] Plan 9 C compiler for Xtensa CPUs Topicbox-Message-UUID: 04de6ff2-eada-11e9-9d60-3106f5b1d025 --000000000000df5a82058fbfbde0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Everything old is new again? On Sat, Aug 10, 2019 at 7:11 PM Cyber Fonic wrote: > The emergent problem with IoT is the lack of security. From my > understanding of Plan9's architecture. 9p protocol and the "root-less" > security model suggests to me that a Plan9 swarm of IoT devices could be > the "killer app" where Plan9 emerges on the strength of the vision of > decades ago. Looking at other RT OSes the security models are often bolt= ed > on. Plan9 worked well on IBM PC era hardware. An ESP-32 has more resourc= es > and better networking than the early PCs. From my tinkering and reverse > engineering of IoT devices, almost all use 8266 based WiFi and often in > conjunction with a uController. An ESP-32 is dual processor and with > sufficient I/O for most simple tasks. With IoT, in general, you don't ne= ed > a lot of I/O, you simply throw more CPUs into the mix. > > On Sat, 10 Aug 2019 at 08:55, Skip Tavakkolian > wrote: > >> I'm not sure if the effort would be worth it; but if you add support for >> esp32, I think it would be better for the os to be something like the on= e >> you had in kencc for AVR (*) or possibly Russ' libtask, rather than Plan= 9. >> Staying with FreeRTOS would need removal of GCC specific things from OS = and >> dealing with lots of drivers in C++. >> >> The Cortex-M based mpus (e.g. Teensy 4 with Cortex M7 @ 600MHz) seem mor= e >> appropriate for an "embedded" Plan 9. >> >> (*) for those who have not seen it, it is here: >> % ls -l /n/sources/contrib/forsyth/avr* >> --rw-rw-r-- M 518 bootes sys 251227 Sep 4 2011 >> /n/sources/contrib/forsyth/avr.9gz >> >> On Fri, Aug 9, 2019 at 2:36 PM Charles Forsyth >> wrote: >> >>> Since the resources are small if not tiny, a little systems analysis an= d >>> design is probably needed, but it looks like a bit of fun, until the >>> inevitable moment of "why am I here?". >>> >>> On Fri, Aug 9, 2019 at 4:50 PM Charles Forsyth < >>> charles.forsyth@gmail.com> wrote: >>> >>>> The device I've got is ESP32-WROOM-32. None of the boards I've seen >>>> that use it bother with external memory, >>>> so memory is limited, especially the way it's partitioned. >>>> >>>> On Fri, Aug 9, 2019 at 3:50 PM Charles Forsyth < >>>> charles.forsyth@gmail.com> wrote: >>>> >>>>> The ESP32 has got several MMUs. The characteristics are different >>>>> depending on the part that a given MMU accesses (flash, ROM, SRAM, ex= ternal >>>>> memory). >>>>> Some things are accessed using Memory Protection Units instead, which >>>>> control access by Process ID, but don't do mapping. Others including = some >>>>> of the SRAMs are accessed through >>>>> an MMU that can do virtual to physical mapping. The MMUs for internal >>>>> SRAM0 and 2 choose protection for a given physical page as none, one = or all >>>>> of PIDs 2 to 7, with the virtual address that >>>>> maps to it. PIDs 0 and 1 can access everything. PID 0 can execute >>>>> privileged instructions. >>>>> A large chunk of SRAM (SRAM 1) has only Memory Protection and no >>>>> translation. The external memory MMU is the most general (most >>>>> conventional). >>>>> >>>>> On Fri, Aug 9, 2019 at 3:19 PM Bakul Shah wrote= : >>>>> >>>>>> esp32 doesn=E2=80=99t have an mmu, right? >>>>>> >>>>>> On Jul 26, 2019, at 03:30, Charles Forsyth >>>>>> wrote: >>>>>> >>>>>> I was thinking of doing that since I've got an ESP-32 for some reaso= n >>>>>> >>>>>> On Fri, Jul 26, 2019 at 7:38 AM Cyber Fonic >>>>>> wrote: >>>>>> >>>>>>> I was reading the post Why Didn't Plan 9 Succeed >>>>>>> on Hacker News. >>>>>>> >>>>>>> Made me think that Plan 9 for IoT system of systems could be viable= . >>>>>>> >>>>>>> To that end, ESP-32 modules look capable enough to run Plan 9, but >>>>>>> is there a Plan 9 C compiler for Xtensa ISA CPUs? >>>>>>> >>>>>>> --000000000000df5a82058fbfbde0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Everything old is new again?

On Sat, Aug 10, 2019 at 7:= 11 PM Cyber Fonic <cyberfonic@gm= ail.com> wrote:

The emergent problem with IoT is the lack of securi= ty.=C2=A0 From my understanding of Plan9's architecture. 9p protocol an= d the "root-less" security model suggests to me that a Plan9 swar= m of IoT devices could be the "killer app" where Plan9 emerges on= the strength of the vision of decades ago.=C2=A0 Looking at other RT OSes = the security models are often bolted on.=C2=A0 Plan9 worked well on IBM PC = era hardware. An ESP-32 has more resources and better networking than the e= arly PCs.=C2=A0 From my tinkering and reverse engineering of IoT devices, a= lmost all use 8266 based WiFi and often in conjunction with a uController. = An ESP-32 is dual processor and with sufficient I/O for most simple tasks.= =C2=A0 With IoT, in general, you don't need a lot of I/O, you simply th= row more CPUs into the mix.

On Sat, 10 Aug 2019 at 08:55, Skip Tavakkolian &= lt;skip.tav= akkolian@gmail.com> wrote:
I'm not sure if the effort would be = worth it; but if you add support for esp32, I think it would be better for = the os to be something like the one you had in kencc for AVR (*) or possibl= y Russ' libtask, rather than Plan 9. Staying with FreeRTOS would need r= emoval of GCC specific things from OS and dealing with lots of drivers in C= ++.

The Cortex-M based mpus (e.g. Teensy 4 with Cor= tex M7 @ 600MHz) seem more appropriate for an "embedded" Plan 9.<= /div>

(*) for those who have not seen it, it is here:
% ls -l /n/sources/contrib/forsyth/avr*
--rw-rw-r-- M 518 boot= es sys 251227 Sep =C2=A04 =C2=A02011 /n/sources/contrib/forsyth/avr.9gz

On Fri, Aug 9, 2019 at 2:36 PM Charles Forsyth <charles.forsyth@gmail.com> = wrote:
Since the resources are small if not tiny, a little systems analys= is and design is probably needed, but it looks like a bit of fun, until the= inevitable moment of "why am I here?".

On Fri, Aug 9, 2019 at 4:5= 0 PM Charles Forsyth <charles.forsyth@gmail.com> wrote:
The device I've = got is ESP32-WROOM-32. None of the boards I've seen that use it bother = with external memory,
so memory is limited, especially the way it's= partitioned.

On Fri, Aug 9, 2019 at 3:50 PM Charles Forsyth <charles.forsyth@g= mail.com> wrote:
The ESP32 has got several MMUs. The characteristic= s are different depending on the part that a given MMU accesses (flash, ROM= , SRAM, external memory).
Some things are accessed using Memory Protect= ion Units instead, which control access by Process ID, but don't do map= ping. Others including some of the SRAMs are accessed through
an = MMU that can do virtual to physical mapping. The MMUs for internal SRAM0 an= d 2 choose protection for a given physical page as none, one or all of PIDs= 2 to 7, with the virtual address that
maps to it. PIDs 0 and 1 c= an access everything. PID 0 can execute privileged instructions.
= A large chunk of SRAM (SRAM 1) has only Memory Protection and no translatio= n. The external memory MMU is the most general (most conventional).

On= Fri, Aug 9, 2019 at 3:19 PM Bakul Shah <bakul@bitblocks.com> wrote:
esp32 doesn=E2=80=99t have an mmu, right?
=

On Jul 26, 2019, at 03:30, Charles Forsyth <charles.forsyth@gma= il.com> wrote:

I was thinking of doing that since I've got an ESP-= 32 for some reason

On Fri, Jul 26, 2019 at 7:38 AM Cyber Fonic <cyberfonic@gmail.com= > wrote:
I was reading the post=C2=A0Why Didn't Plan 9 Succeed=C2=A0on Hacker News.

Made me think that Plan 9 for Io= T system of systems could be viable.

To that end, = ESP-32 modules look capable enough to run Plan 9, but is there a Plan 9 C c= ompiler for Xtensa ISA CPUs?=C2=A0

--000000000000df5a82058fbfbde0-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References:

<40745EA5-3815-4E4F-9FE0-8F83697E74BA@bitblocks.com>

In-Reply-To: From: Charles Forsyth Date: Sat, 10 Aug 2019 17:18:16 +0100 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary="000000000000142941058fc5a48c" Subject: Re: [9fans] Plan 9 C compiler for Xtensa CPUs Topicbox-Message-UUID: 04e36110-eada-11e9-9d60-3106f5b1d025 --000000000000142941058fc5a48c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable At a glance it looked as though the MMUs for the on-chip stuff were more suitable for Unix Seventh Edition (no later) than "full" Plan 9. The MMU for the external memory looked fine, but as I said, the device I've got, and several other boards based on WROOM seem not to bother with external memory. I didn't look widely, though. The processor is adequate, I think, but double =3D=3D float (there's only single precision). The existing systems use one processor for applications, and the other mainly for communications. I haven't had a lot of spare time, but I did the assembler and am about 3/4 through the loader. For the most part it's a straightforward RISC. Might do the disassembler next to help debug the rest, and finally the compiler. On Sat, Aug 10, 2019 at 10:11 AM Cyber Fonic wrote: > The emergent problem with IoT is the lack of security. From my > understanding of Plan9's architecture. 9p protocol and the "root-less" > security model suggests to me that a Plan9 swarm of IoT devices could be > the "killer app" where Plan9 emerges on the strength of the vision of > decades ago. Looking at other RT OSes the security models are often bolt= ed > on. Plan9 worked well on IBM PC era hardware. An ESP-32 has more resourc= es > and better networking than the early PCs. From my tinkering and reverse > engineering of IoT devices, almost all use 8266 based WiFi and often in > conjunction with a uController. An ESP-32 is dual processor and with > sufficient I/O for most simple tasks. With IoT, in general, you don't ne= ed > a lot of I/O, you simply throw more CPUs into the mix. > > On Sat, 10 Aug 2019 at 08:55, Skip Tavakkolian > wrote: > >> I'm not sure if the effort would be worth it; but if you add support for >> esp32, I think it would be better for the os to be something like the on= e >> you had in kencc for AVR (*) or possibly Russ' libtask, rather than Plan= 9. >> Staying with FreeRTOS would need removal of GCC specific things from OS = and >> dealing with lots of drivers in C++. >> >> The Cortex-M based mpus (e.g. Teensy 4 with Cortex M7 @ 600MHz) seem mor= e >> appropriate for an "embedded" Plan 9. >> >> (*) for those who have not seen it, it is here: >> % ls -l /n/sources/contrib/forsyth/avr* >> --rw-rw-r-- M 518 bootes sys 251227 Sep 4 2011 >> /n/sources/contrib/forsyth/avr.9gz >> >> On Fri, Aug 9, 2019 at 2:36 PM Charles Forsyth >> wrote: >> >>> Since the resources are small if not tiny, a little systems analysis an= d >>> design is probably needed, but it looks like a bit of fun, until the >>> inevitable moment of "why am I here?". >>> >>> On Fri, Aug 9, 2019 at 4:50 PM Charles Forsyth < >>> charles.forsyth@gmail.com> wrote: >>> >>>> The device I've got is ESP32-WROOM-32. None of the boards I've seen >>>> that use it bother with external memory, >>>> so memory is limited, especially the way it's partitioned. >>>> >>>> On Fri, Aug 9, 2019 at 3:50 PM Charles Forsyth < >>>> charles.forsyth@gmail.com> wrote: >>>> >>>>> The ESP32 has got several MMUs. The characteristics are different >>>>> depending on the part that a given MMU accesses (flash, ROM, SRAM, ex= ternal >>>>> memory). >>>>> Some things are accessed using Memory Protection Units instead, which >>>>> control access by Process ID, but don't do mapping. Others including = some >>>>> of the SRAMs are accessed through >>>>> an MMU that can do virtual to physical mapping. The MMUs for internal >>>>> SRAM0 and 2 choose protection for a given physical page as none, one = or all >>>>> of PIDs 2 to 7, with the virtual address that >>>>> maps to it. PIDs 0 and 1 can access everything. PID 0 can execute >>>>> privileged instructions. >>>>> A large chunk of SRAM (SRAM 1) has only Memory Protection and no >>>>> translation. The external memory MMU is the most general (most >>>>> conventional). >>>>> >>>>> On Fri, Aug 9, 2019 at 3:19 PM Bakul Shah wrote= : >>>>> >>>>>> esp32 doesn=E2=80=99t have an mmu, right? >>>>>> >>>>>> On Jul 26, 2019, at 03:30, Charles Forsyth >>>>>> wrote: >>>>>> >>>>>> I was thinking of doing that since I've got an ESP-32 for some reaso= n >>>>>> >>>>>> On Fri, Jul 26, 2019 at 7:38 AM Cyber Fonic >>>>>> wrote: >>>>>> >>>>>>> I was reading the post Why Didn't Plan 9 Succeed >>>>>>> on Hacker News. >>>>>>> >>>>>>> Made me think that Plan 9 for IoT system of systems could be viable= . >>>>>>> >>>>>>> To that end, ESP-32 modules look capable enough to run Plan 9, but >>>>>>> is there a Plan 9 C compiler for Xtensa ISA CPUs? >>>>>>> >>>>>>> --000000000000142941058fc5a48c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

At a glance it looked as though the MMUs for the on-chip s= tuff were more suitable for Unix Seventh Edition (no later) than "full= " Plan 9.

The MMU for the external memory looked fine, but as I sa= id, the device I've got, and several other boards based on WROOM seem n= ot

to bother with external memory. I didn't look widely, thou= gh.

The processor i= s adequate, I think, but double =3D=3D float (there's only single preci= sion).

The existing systems use one processor = for applications, and the other mainly for communications.

I haven't had a lot of spare time, but I did the assembler and= am about 3/4 through the loader.

For the most part it's a st= raightforward RISC.

Might do the disassembler next to help debug = the rest, and finally the compiler.

On Sat, Aug 10, 2019 at 10:11 AM C= yber Fonic <cyberfonic@gmail.com= > wrote:

=
The emergent problem with IoT is the lack of security.=C2= =A0 From my understanding of Plan9's architecture. 9p protocol and the = "root-less" security model suggests to me that a Plan9 swarm of I= oT devices could be the "killer app" where Plan9 emerges on the s= trength of the vision of decades ago.=C2=A0 Looking at other RT OSes the se= curity models are often bolted on.=C2=A0 Plan9 worked well on IBM PC era ha= rdware. An ESP-32 has more resources and better networking than the early P= Cs.=C2=A0 From my tinkering and reverse engineering of IoT devices, almost = all use 8266 based WiFi and often in conjunction with a uController. An ESP= -32 is dual processor and with sufficient I/O for most simple tasks.=C2=A0 = With IoT, in general, you don't need a lot of I/O, you simply throw mor= e CPUs into the mix.

On Sat, 10 Aug 2019 at 08:55, Skip Tavakkolian <skip.tavakkolia= n@gmail.com> wrote:
I'm not sure if the effort would be worth i= t; but if you add support for esp32, I think it would be better for the os = to be something like the one you had in kencc for AVR (*) or possibly Russ&= #39; libtask, rather than Plan 9. Staying with FreeRTOS would need removal = of GCC specific things from OS and dealing with lots of drivers in C++.

The Cortex-M based mpus (e.g. Teensy 4 with Cortex M7 = @ 600MHz) seem more appropriate for an "embedded" Plan 9.

(*) for those who have not seen it, it is here:
% ls -l /n/sources/contrib/forsyth/avr*
--rw-rw-r-- M 518 bootes sys = 251227 Sep =C2=A04 =C2=A02011 /n/sources/contrib/forsyth/avr.9gz

On Fr= i, Aug 9, 2019 at 2:36 PM Charles Forsyth <charles.forsyth@gmail.com> wrote:<= br>

Since the resources are small if not tiny, a little systems analysis and d= esign is probably needed, but it looks like a bit of fun, until the inevita= ble moment of "why am I here?".

On Fri, Aug 9, 2019 at 4:50 PM Cha= rles Forsyth <charles.forsyth@gmail.com> wrote:
The device I've got is E= SP32-WROOM-32. None of the boards I've seen that use it bother with ext= ernal memory,
so memory is limited, especially the way it's partiti= oned.

On Fri, Aug 9, 2019 at 3:50 PM Charles Forsyth <charles.forsyth@gmail.com= > wrote:
=
The ESP32 has got several MMUs. The characteristics are di= fferent depending on the part that a given MMU accesses (flash, ROM, SRAM, = external memory).
Some things are accessed using Memory Protection Unit= s instead, which control access by Process ID, but don't do mapping. Ot= hers including some of the SRAMs are accessed through
an MMU that= can do virtual to physical mapping. The MMUs for internal SRAM0 and 2 choo= se protection for a given physical page as none, one or all of PIDs 2 to 7,= with the virtual address that
maps to it. PIDs 0 and 1 can acces= s everything. PID 0 can execute privileged instructions.
A large = chunk of SRAM (SRAM 1) has only Memory Protection and no translation. The e= xternal memory MMU is the most general (most conventional).

=
On Fri, Au= g 9, 2019 at 3:19 PM Bakul Shah <bakul@bitblocks.com> wrote:
esp32 doesn=E2=80=99t have an mmu, right?

On Jul 26, 2019, at 03:30, Charles Forsyth <charles.forsyth@gmail.com> wrote:

I was thinking of doing that since I've got an ESP-32 for s= ome reason

On Fri, Jul 26, 2019 at 7:38 AM Cyber Fonic <cyberfonic@gmail.com> wrote= :
I was reading the post=C2=A0Why Didn't Plan 9 Succeed=C2=A0on= Hacker News.

Made me think that Plan 9 for IoT system o= f systems could be viable.

To that end, ESP-32 mod= ules look capable enough to run Plan 9, but is there a Plan 9 C compiler fo= r Xtensa ISA CPUs?=C2=A0

--000000000000142941058fc5a48c-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lyndon Nerenberg To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-reply-to: References:

<40745EA5-3815-4E4F-9FE0-8F83697E74BA@bitblocks.com>

MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <44958.1565549964.1@orthanc.ca> Date: Sun, 11 Aug 2019 11:59:24 -0700 Message-ID: <40c93bbee7086022@orthanc.ca> Subject: Re: [9fans] Plan 9 C compiler for Xtensa CPUs Topicbox-Message-UUID: 04f77948-eada-11e9-9d60-3106f5b1d025 Charles Forsyth writes: > At a glance it looked as though the MMUs for the on-chip stuff were more > suitable for Unix Seventh Edition (no later) than "full" Plan 9. Wouldn't Inferno be a better fit for these sort of devices? In my experience these things are used primarily as I/O devices, with most of the CPU cycles going towards reducing/normalizing/marshalling the data in and out. Nothing I've ever built out of an ESP*, Feather, Teensy, etc., would benefit from a full-on Plan9 kernel. But having a fully-integrated 9P+auth stack would make these microcontrollers a dream to integrate into a Plan9 environment. --lyndon From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References:

<40745EA5-3815-4E4F-9FE0-8F83697E74BA@bitblocks.com>

In-Reply-To: From: Charles Forsyth Date: Sun, 18 Aug 2019 15:10:20 +0100 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary="0000000000004d01f9059064c914" Subject: Re: [9fans] Plan 9 C compiler for Xtensa CPUs Topicbox-Message-UUID: 05454920-eada-11e9-9d60-3106f5b1d025 --0000000000004d01f9059064c914 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There is another existing variant of ESP32 with flash and RAM, and that one would provide the external memory MMU. It seems there could be a range from a small RT-ish kernel, with and without a user mode, on little ESP32, to a Plan 9 kernel with a few specialised processes on the bigger one. An Inferno-like system might also straddle the boundaries. On Sat, Aug 10, 2019 at 5:18 PM Charles Forsyth wrote: > At a glance it looked as though the MMUs for the on-chip stuff were more > suitable for Unix Seventh Edition (no later) than "full" Plan 9. > The MMU for the external memory looked fine, but as I said, the device > I've got, and several other boards based on WROOM seem not > to bother with external memory. I didn't look widely, though. > > The processor is adequate, I think, but double =3D=3D float (there's only > single precision). > > The existing systems use one processor for applications, and the other > mainly for communications. > > I haven't had a lot of spare time, but I did the assembler and am about > 3/4 through the loader. > For the most part it's a straightforward RISC. > Might do the disassembler next to help debug the rest, and finally the > compiler. > > On Sat, Aug 10, 2019 at 10:11 AM Cyber Fonic wrote= : > >> The emergent problem with IoT is the lack of security. From my >> understanding of Plan9's architecture. 9p protocol and the "root-less" >> security model suggests to me that a Plan9 swarm of IoT devices could be >> the "killer app" where Plan9 emerges on the strength of the vision of >> decades ago. Looking at other RT OSes the security models are often bol= ted >> on. Plan9 worked well on IBM PC era hardware. An ESP-32 has more resour= ces >> and better networking than the early PCs. From my tinkering and reverse >> engineering of IoT devices, almost all use 8266 based WiFi and often in >> conjunction with a uController. An ESP-32 is dual processor and with >> sufficient I/O for most simple tasks. With IoT, in general, you don't n= eed >> a lot of I/O, you simply throw more CPUs into the mix. >> >> On Sat, 10 Aug 2019 at 08:55, Skip Tavakkolian < >> skip.tavakkolian@gmail.com> wrote: >> >>> I'm not sure if the effort would be worth it; but if you add support fo= r >>> esp32, I think it would be better for the os to be something like the o= ne >>> you had in kencc for AVR (*) or possibly Russ' libtask, rather than Pla= n 9. >>> Staying with FreeRTOS would need removal of GCC specific things from OS= and >>> dealing with lots of drivers in C++. >>> >>> The Cortex-M based mpus (e.g. Teensy 4 with Cortex M7 @ 600MHz) seem >>> more appropriate for an "embedded" Plan 9. >>> >>> (*) for those who have not seen it, it is here: >>> % ls -l /n/sources/contrib/forsyth/avr* >>> --rw-rw-r-- M 518 bootes sys 251227 Sep 4 2011 >>> /n/sources/contrib/forsyth/avr.9gz >>> >>> On Fri, Aug 9, 2019 at 2:36 PM Charles Forsyth < >>> charles.forsyth@gmail.com> wrote: >>> >>>> Since the resources are small if not tiny, a little systems analysis >>>> and design is probably needed, but it looks like a bit of fun, until t= he >>>> inevitable moment of "why am I here?". >>>> >>>> On Fri, Aug 9, 2019 at 4:50 PM Charles Forsyth < >>>> charles.forsyth@gmail.com> wrote: >>>> >>>>> The device I've got is ESP32-WROOM-32. None of the boards I've seen >>>>> that use it bother with external memory, >>>>> so memory is limited, especially the way it's partitioned. >>>>> >>>>> On Fri, Aug 9, 2019 at 3:50 PM Charles Forsyth < >>>>> charles.forsyth@gmail.com> wrote: >>>>> >>>>>> The ESP32 has got several MMUs. The characteristics are different >>>>>> depending on the part that a given MMU accesses (flash, ROM, SRAM, e= xternal >>>>>> memory). >>>>>> Some things are accessed using Memory Protection Units instead, whic= h >>>>>> control access by Process ID, but don't do mapping. Others including= some >>>>>> of the SRAMs are accessed through >>>>>> an MMU that can do virtual to physical mapping. The MMUs for interna= l >>>>>> SRAM0 and 2 choose protection for a given physical page as none, one= or all >>>>>> of PIDs 2 to 7, with the virtual address that >>>>>> maps to it. PIDs 0 and 1 can access everything. PID 0 can execute >>>>>> privileged instructions. >>>>>> A large chunk of SRAM (SRAM 1) has only Memory Protection and no >>>>>> translation. The external memory MMU is the most general (most >>>>>> conventional). >>>>>> >>>>>> On Fri, Aug 9, 2019 at 3:19 PM Bakul Shah >>>>>> wrote: >>>>>> >>>>>>> esp32 doesn=E2=80=99t have an mmu, right? >>>>>>> >>>>>>> On Jul 26, 2019, at 03:30, Charles Forsyth < >>>>>>> charles.forsyth@gmail.com> wrote: >>>>>>> >>>>>>> I was thinking of doing that since I've got an ESP-32 for some reas= on >>>>>>> >>>>>>> On Fri, Jul 26, 2019 at 7:38 AM Cyber Fonic >>>>>>> wrote: >>>>>>> >>>>>>>> I was reading the post Why Didn't Plan 9 Succeed >>>>>>>> on Hacker News. >>>>>>>> >>>>>>>> Made me think that Plan 9 for IoT system of systems could be viabl= e. >>>>>>>> >>>>>>>> To that end, ESP-32 modules look capable enough to run Plan 9, but >>>>>>>> is there a Plan 9 C compiler for Xtensa ISA CPUs? >>>>>>>> >>>>>>>> --0000000000004d01f9059064c914 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

There is another existing variant of ESP32 with flash and = RAM, and that one would provide the external memory MMU.

It seems there= could be a range from a small RT-ish kernel, with and without a user mode,= on little ESP32, to a Plan 9 kernel with a few specialised processes on th= e bigger one.

An Inferno-like system might also straddle the boun= daries.

On Sat, Aug 10, 2019 at 5:18 PM Charles Forsyth <charles.forsyth@gmail.com> wrote:=

At a glance it looked as though the MMUs for the on-chip stuff were more = suitable for Unix Seventh Edition (no later) than "full" Plan 9.<= div>The MMU for the external memory looked fine, but as I said, the device = I've got, and several other boards based on WROOM seem not
to= bother with external memory. I didn't look widely, though.
<= br class=3D"gmail-m_-5003069044351978166gmail-Apple-interchange-newline">Th= e processor is adequate, I think, but double =3D=3D float (there's only= single precision).

The existing systems use o= ne processor for applications, and the other mainly for communications.

I haven't had a lot of spare time, but I did the = assembler and am about 3/4 through the loader.
For the most part = it's a straightforward RISC.
Might do the disassembler next t= o help debug the rest, and finally the compiler.

On Sat, Aug 10, 2019= at 10:11 AM Cyber Fonic <cyberfonic@gmail.com> wrote:
The emergent problem with= IoT is the lack of security.=C2=A0 From my understanding of Plan9's ar= chitecture. 9p protocol and the "root-less" security model sugges= ts to me that a Plan9 swarm of IoT devices could be the "killer app&qu= ot; where Plan9 emerges on the strength of the vision of decades ago.=C2=A0= Looking at other RT OSes the security models are often bolted on.=C2=A0 Pl= an9 worked well on IBM PC era hardware. An ESP-32 has more resources and be= tter networking than the early PCs.=C2=A0 From my tinkering and reverse eng= ineering of IoT devices, almost all use 8266 based WiFi and often in conjun= ction with a uController. An ESP-32 is dual processor and with sufficient I= /O for most simple tasks.=C2=A0 With IoT, in general, you don't need a = lot of I/O, you simply throw more CPUs into the mix.

On Sat, 10 Aug 2019 at = 08:55, Skip Tavakkolian <skip.tavakkolian@gmail.com> wrote:
I'm not sur= e if the effort would be worth it; but if you add support for esp32, I thin= k it would be better for the os to be something like the one you had in ken= cc for AVR (*) or possibly Russ' libtask, rather than Plan 9. Staying w= ith FreeRTOS would need removal of GCC specific things from OS and dealing = with lots of drivers in C++.

The Cortex-M based mpu= s (e.g. Teensy 4 with Cortex M7 @ 600MHz) seem more appropriate for an &quo= t;embedded" Plan 9.

(*) for those who have no= t seen it, it is here:
% ls -l /n/sources/contrib/forsyth/avr*--rw-rw-r-- M 518 bootes sys 251227 Sep =C2=A04 =C2=A02011 /n/sources/co= ntrib/forsyth/avr.9gz

On Fri, Aug 9, 2019 at 2:36 PM Charles Forsyth &= lt;charles.f= orsyth@gmail.com> wrote:
Since the resources are small if not tiny,= a little systems analysis and design is probably needed, but it looks like= a bit of fun, until the inevitable moment of "why am I here?".
On= Fri, Aug 9, 2019 at 4:50 PM Charles Forsyth <charles.forsyth@gmail.com> wrot= e:
The device I've got is ESP32-WROOM-32. None of the boards I've = seen that use it bother with external memory,
so memory is limited, esp= ecially the way it's partitioned.

On Fri, Aug 9, 2019 at 3:50 PM C= harles Forsyth <charles.forsyth@gmail.com> wrote:
The ESP32 has got several= MMUs. The characteristics are different depending on the part that a given= MMU accesses (flash, ROM, SRAM, external memory).
Some things are acce= ssed using Memory Protection Units instead, which control access by Process= ID, but don't do mapping. Others including some of the SRAMs are acces= sed through
an MMU that can do virtual to physical mapping. The M= MUs for internal SRAM0 and 2 choose protection for a given physical page as= none, one or all of PIDs 2 to 7, with the virtual address that
m= aps to it. PIDs 0 and 1 can access everything. PID 0 can execute privileged= instructions.
A large chunk of SRAM (SRAM 1) has only Memory Pro= tection and no translation. The external memory MMU is the most general (mo= st conventional).

On Fri, Aug 9, 2019 at 3:19 PM Bakul Shah <bakul@bitblocks.com&= gt; wrote:
esp32 doesn=E2=80=99t = have an mmu, right?

On Jul 26, 2019, at 03:30, Ch= arles Forsyth <charles.forsyth@gmail.com> wrote:

I was thinking of doing that s= ince I've got an ESP-32 for some reason

On Fri, Jul 26, 2019 at 7:38 AM = Cyber Fonic <c= yberfonic@gmail.com> wrote:
I was reading the post=C2=A0Why Didn= 't Plan 9 Succeed=C2=A0on Hacker News.

Made me t= hink that Plan 9 for IoT system of systems could be viable.

<= /div>
To that end, ESP-32 modules look capable enough to run Plan 9, bu= t is there a Plan 9 C compiler for Xtensa ISA CPUs?=C2=A0

--0000000000004d01f9059064c914-- From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <93fae7d571501c85b3b9cf118b4abb7b@hamnavoe.com> To: 9fans@9fans.net From: Richard Miller <9fans@hamnavoe.com> Date: Sun, 18 Aug 2019 15:28:07 +0100 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Plan 9 C compiler for Xtensa CPUs Topicbox-Message-UUID: 054afc1c-eada-11e9-9d60-3106f5b1d025 Charles Forsyth I haven't had a lot of spare time, but I did the assembler and am about > 3/4 through the loader. > For the most part it's a straightforward RISC. > Might do the disassembler next to help debug the rest, and finally the > compiler. Nowadays I do the disassembler first. Advantages: (a) useful tool for debugging the assembler and loader; (b) disassembling binaries produced by some other toolchain provides a useful check for my understanding of the instruction encoding. From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References:

<40745EA5-3815-4E4F-9FE0-8F83697E74BA@bitblocks.com>

In-Reply-To: From: Cyber Fonic Date: Mon, 19 Aug 2019 21:51:14 +1000 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary="0000000000000207b5059076f67c" Subject: Re: [9fans] Plan 9 C compiler for Xtensa CPUs Topicbox-Message-UUID: 055c965c-eada-11e9-9d60-3106f5b1d025 --0000000000000207b5059076f67c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable For IoT deployments, I suppose that one processor core on the ESP32 could run the WiFi / networking stack and the other act as a CPU-like server and thus run a small number of servers to expose the interface(s) in a 9P mountable fashion to more powerful nodes. A RT-ish kernel might suffice in most practical use cases - it is IoT after all. In my vision for Plan9 IoT I never considered running file-server or terminal server on ESP-32 hardware. There are more capable nodes which would be better suited for those purposes. Of course, these observations presume that the 9p protocol provides sufficient security against any ESP-32 node going rogue for whatever reason. It has been said : "The 'S' in IoT stands for security". If Plan9 can address that deficiency of the current state of the art for IoT devices, then it would be a worthwhile exercise. On Mon, 19 Aug 2019 at 00:12, Charles Forsyth wrote: > There is another existing variant of ESP32 with flash and RAM, and that > one would provide the external memory MMU. > It seems there could be a range from a small RT-ish kernel, with and > without a user mode, on little ESP32, to a Plan 9 kernel with a few > specialised processes on the bigger one. > An Inferno-like system might also straddle the boundaries. > > On Sat, Aug 10, 2019 at 5:18 PM Charles Forsyth > wrote: > >> At a glance it looked as though the MMUs for the on-chip stuff were more >> suitable for Unix Seventh Edition (no later) than "full" Plan 9. >> The MMU for the external memory looked fine, but as I said, the device >> I've got, and several other boards based on WROOM seem not >> to bother with external memory. I didn't look widely, though. >> >> The processor is adequate, I think, but double =3D=3D float (there's onl= y >> single precision). >> >> The existing systems use one processor for applications, and the other >> mainly for communications. >> >> I haven't had a lot of spare time, but I did the assembler and am about >> 3/4 through the loader. >> For the most part it's a straightforward RISC. >> Might do the disassembler next to help debug the rest, and finally the >> compiler. >> >> On Sat, Aug 10, 2019 at 10:11 AM Cyber Fonic >> wrote: >> >>> The emergent problem with IoT is the lack of security. From my >>> understanding of Plan9's architecture. 9p protocol and the "root-less" >>> security model suggests to me that a Plan9 swarm of IoT devices could b= e >>> the "killer app" where Plan9 emerges on the strength of the vision of >>> decades ago. Looking at other RT OSes the security models are often bo= lted >>> on. Plan9 worked well on IBM PC era hardware. An ESP-32 has more resou= rces >>> and better networking than the early PCs. From my tinkering and revers= e >>> engineering of IoT devices, almost all use 8266 based WiFi and often in >>> conjunction with a uController. An ESP-32 is dual processor and with >>> sufficient I/O for most simple tasks. With IoT, in general, you don't = need >>> a lot of I/O, you simply throw more CPUs into the mix. >>> >>> On Sat, 10 Aug 2019 at 08:55, Skip Tavakkolian < >>> skip.tavakkolian@gmail.com> wrote: >>> >>>> I'm not sure if the effort would be worth it; but if you add support >>>> for esp32, I think it would be better for the os to be something like = the >>>> one you had in kencc for AVR (*) or possibly Russ' libtask, rather tha= n >>>> Plan 9. Staying with FreeRTOS would need removal of GCC specific thing= s >>>> from OS and dealing with lots of drivers in C++. >>>> >>>> The Cortex-M based mpus (e.g. Teensy 4 with Cortex M7 @ 600MHz) seem >>>> more appropriate for an "embedded" Plan 9. >>>> >>>> (*) for those who have not seen it, it is here: >>>> % ls -l /n/sources/contrib/forsyth/avr* >>>> --rw-rw-r-- M 518 bootes sys 251227 Sep 4 2011 >>>> /n/sources/contrib/forsyth/avr.9gz >>>> >>>> On Fri, Aug 9, 2019 at 2:36 PM Charles Forsyth < >>>> charles.forsyth@gmail.com> wrote: >>>> >>>>> Since the resources are small if not tiny, a little systems analysis >>>>> and design is probably needed, but it looks like a bit of fun, until = the >>>>> inevitable moment of "why am I here?". >>>>> >>>>> On Fri, Aug 9, 2019 at 4:50 PM Charles Forsyth < >>>>> charles.forsyth@gmail.com> wrote: >>>>> >>>>>> The device I've got is ESP32-WROOM-32. None of the boards I've seen >>>>>> that use it bother with external memory, >>>>>> so memory is limited, especially the way it's partitioned. >>>>>> >>>>>> On Fri, Aug 9, 2019 at 3:50 PM Charles Forsyth < >>>>>> charles.forsyth@gmail.com> wrote: >>>>>> >>>>>>> The ESP32 has got several MMUs. The characteristics are different >>>>>>> depending on the part that a given MMU accesses (flash, ROM, SRAM, = external >>>>>>> memory). >>>>>>> Some things are accessed using Memory Protection Units instead, >>>>>>> which control access by Process ID, but don't do mapping. Others in= cluding >>>>>>> some of the SRAMs are accessed through >>>>>>> an MMU that can do virtual to physical mapping. The MMUs for >>>>>>> internal SRAM0 and 2 choose protection for a given physical page as= none, >>>>>>> one or all of PIDs 2 to 7, with the virtual address that >>>>>>> maps to it. PIDs 0 and 1 can access everything. PID 0 can execute >>>>>>> privileged instructions. >>>>>>> A large chunk of SRAM (SRAM 1) has only Memory Protection and no >>>>>>> translation. The external memory MMU is the most general (most >>>>>>> conventional). >>>>>>> >>>>>>> On Fri, Aug 9, 2019 at 3:19 PM Bakul Shah >>>>>>> wrote: >>>>>>> >>>>>>>> esp32 doesn=E2=80=99t have an mmu, right? >>>>>>>> >>>>>>>> On Jul 26, 2019, at 03:30, Charles Forsyth < >>>>>>>> charles.forsyth@gmail.com> wrote: >>>>>>>> >>>>>>>> I was thinking of doing that since I've got an ESP-32 for some >>>>>>>> reason >>>>>>>> >>>>>>>> On Fri, Jul 26, 2019 at 7:38 AM Cyber Fonic >>>>>>>> wrote: >>>>>>>> >>>>>>>>> I was reading the post Why Didn't Plan 9 Succeed >>>>>>>>> on Hacker News. >>>>>>>>> >>>>>>>>> Made me think that Plan 9 for IoT system of systems could be >>>>>>>>> viable. >>>>>>>>> >>>>>>>>> To that end, ESP-32 modules look capable enough to run Plan 9, bu= t >>>>>>>>> is there a Plan 9 C compiler for Xtensa ISA CPUs? >>>>>>>>> >>>>>>>>> --0000000000000207b5059076f67c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

For IoT deployments, I suppose that one processor core on = the ESP32 could run the WiFi / networking stack and the other act as a CPU-= like server and thus run a small number of servers to expose the interface(= s) in a 9P mountable fashion to more powerful nodes.=C2=A0 A RT-ish kernel = might suffice in most practical use cases - it is IoT after all.=C2=A0 In m= y vision for Plan9 IoT I never considered running file-server or terminal s= erver on ESP-32 hardware. There are more capable nodes which would be bette= r suited for those purposes.=C2=A0 Of course, these observations presume th= at the 9p protocol provides sufficient security against any ESP-32 node goi= ng rogue for whatever reason.

It has been said :=C2=A0 &= quot;The 'S' in IoT stands for security".=C2=A0 If Plan9 can a= ddress that deficiency of the current state of the art for IoT devices, the= n it would be a worthwhile exercise.

On Mon, 19 Aug 2019 at 00:12, Cha= rles Forsyth <charles.forsy= th@gmail.com> wrote:

There is another existing variant of ESP32 wit= h flash and RAM, and that one would provide the external memory MMU.
It= seems there could be a range from a small RT-ish kernel, with and without = a user mode, on little ESP32, to a Plan 9 kernel with a few specialised pro= cesses on the bigger one.
An Inferno-like system might also strad= dle the boundaries.

On Sat, Aug 10, 2019 at 5:18 PM Charles Forsyth &l= t;charles.fo= rsyth@gmail.com> wrote:
At a glance it looked as though the MMUs fo= r the on-chip stuff were more suitable for Unix Seventh Edition (no later) = than "full" Plan 9.
The MMU for the external memory looked fi= ne, but as I said, the device I've got, and several other boards based = on WROOM seem not
to bother with external memory. I didn't lo= ok widely, though.

The processor is ade= quate, I think, but double =3D=3D float (there's only single precision)= .

The existing systems use one processor for a= pplications, and the other mainly for communications.

<= div>I haven't had a lot of spare time, but I did the assembler and am a= bout 3/4 through the loader.
For the most part it's a straigh= tforward RISC.
Might do the disassembler next to help debug the r= est, and finally the compiler.

On Sat, Aug 10, 2019 at 10:11 AM Cyber = Fonic <cyberfo= nic@gmail.com> wrote:
The emergent problem with IoT is the lack of = security.=C2=A0 From my understanding of Plan9's architecture. 9p proto= col and the "root-less" security model suggests to me that a Plan= 9 swarm of IoT devices could be the "killer app" where Plan9 emer= ges on the strength of the vision of decades ago.=C2=A0 Looking at other RT= OSes the security models are often bolted on.=C2=A0 Plan9 worked well on I= BM PC era hardware. An ESP-32 has more resources and better networking than= the early PCs.=C2=A0 From my tinkering and reverse engineering of IoT devi= ces, almost all use 8266 based WiFi and often in conjunction with a uContro= ller. An ESP-32 is dual processor and with sufficient I/O for most simple t= asks.=C2=A0 With IoT, in general, you don't need a lot of I/O, you simp= ly throw more CPUs into the mix.

On Sat, 10 Aug 2019 at 08:55, Skip Tavakkol= ian <ski= p.tavakkolian@gmail.com> wrote:
I'm not sure if the effort woul= d be worth it; but if you add support for esp32, I think it would be better= for the os to be something like the one you had in kencc for AVR (*) or po= ssibly Russ' libtask, rather than Plan 9. Staying with FreeRTOS would n= eed removal of GCC specific things from OS and dealing with lots of drivers= in C++.

The Cortex-M based mpus (e.g. Teensy 4 wit= h Cortex M7 @ 600MHz) seem more appropriate for an "embedded" Pla= n 9.

(*) for those who have not seen it, it is her= e:
% ls -l /n/sources/contrib/forsyth/avr*
--rw-rw-r-- M 518= bootes sys 251227 Sep =C2=A04 =C2=A02011 /n/sources/contrib/forsyth/avr.9g= z

On Fri, Aug 9, 2019 at 2:36 PM Charles Forsyth <charles.forsyth@gmail.com= > wrote:
Since the resources are small if not tiny, a little systems an= alysis and design is probably needed, but it looks like a bit of fun, until= the inevitable moment of "why am I here?".

On Fri, Aug 9, 2019 = at 4:50 PM Charles Forsyth <charles.forsyth@gmail.com> wrote:
The device I&#= 39;ve got is ESP32-WROOM-32. None of the boards I've seen that use it b= other with external memory,
so memory is limited, especially the way it= 's partitioned.

On Fri, Aug 9, 2019 at 3:50 PM Charles Forsyth <= ;charles.for= syth@gmail.com> wrote:
The ESP32 has got several MMUs. The characte= ristics are different depending on the part that a given MMU accesses (flas= h, ROM, SRAM, external memory).
Some things are accessed using Memory P= rotection Units instead, which control access by Process ID, but don't = do mapping. Others including some of the SRAMs are accessed through
an MMU that can do virtual to physical mapping. The MMUs for internal SR= AM0 and 2 choose protection for a given physical page as none, one or all o= f PIDs 2 to 7, with the virtual address that
maps to it. PIDs 0 a= nd 1 can access everything. PID 0 can execute privileged instructions.
A large chunk of SRAM (SRAM 1) has only Memory Protection and no tran= slation. The external memory MMU is the most general (most conventional).

On Fri, Aug 9, 2019 at 3:19 PM Bakul Shah <bakul@bitblocks.com> wrote:
esp32 doesn=E2=80=99t have an mmu, right?=

On Jul 26, 2019, at 03:30, Charles Forsyth <<= a href=3D"mailto:charles.forsyth@gmail.com" target=3D"_blank">charles.forsy= th@gmail.com> wrote:

I was thinking of doing that since I've got a= n ESP-32 for some reason

On Fri, Jul 26, 2019 at 7:38 AM Cyber Fonic <cyberfonic@gmail.com= > wrote:
=
I was reading the post=C2=A0Why Didn't Plan 9 Succe= ed=C2=A0on Hacker News.

Made me think that Plan 9 fo= r IoT system of systems could be viable.

To that e= nd, ESP-32 modules look capable enough to run Plan 9, but is there a Plan 9= C compiler for Xtensa ISA CPUs?=C2=A0

--0000000000000207b5059076f67c-- From mboxrd@z Thu Jan 1 00:00:00 1970 User-Agent: Cyrus-JMAP/3.1.6-877-g11309a8-fmstable-20190819v1 Mime-Version: 1.0 Message-Id: <1e801ae2-0d18-4df9-a9a7-ec6480b9b6aa@www.fastmail.com> In-Reply-To: References:

<40745EA5-3815-4E4F-9FE0-8F83697E74BA@bitblocks.com>

Date: Mon, 19 Aug 2019 15:52:36 +0100 From: "Ethan Gardener" To: 9fans@9fans.net Content-Type: text/plain Subject: [9fans] Plan 9 security Topicbox-Message-UUID: 056a4f9a-eada-11e9-9d60-3106f5b1d025 On Mon, Aug 19, 2019, at 12:53 PM, Cyber Fonic wrote: > > It has been said : "The 'S' in IoT stands for security". If Plan9 can address that deficiency of the current state of the art for IoT devices, then it would be a worthwhile exercise. Plan 9 may have a decent security model, but it's never been audited. Auditing a codebase, even one as small as Plan 9's, is a lot of work. Are you willing to make a start on it? If you want something free and already audited, with more security features, (but perhaps not quite the same convenience,) look into OpenBSD. -- I love that *Open*BSD is so *security*-focused! From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References:

<40745EA5-3815-4E4F-9FE0-8F83697E74BA@bitblocks.com>

<1e801ae2-0d18-4df9-a9a7-ec6480b9b6aa@www.fastmail.com> In-Reply-To: <1e801ae2-0d18-4df9-a9a7-ec6480b9b6aa@www.fastmail.com> From: Cyber Fonic Date: Tue, 20 Aug 2019 23:13:34 +1000 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary="00000000000042438c05908c3a6c" Subject: Re: [9fans] Plan 9 security Topicbox-Message-UUID: 0589b0d8-eada-11e9-9d60-3106f5b1d025 --00000000000042438c05908c3a6c Content-Type: text/plain; charset="UTF-8" I don't think OpenBSD will run on an ESP-32. That is part of the problem with IoT, the nodes are made on the cheap and thus use the cheapest viable network capable device. On Tue, 20 Aug 2019 at 00:54, Ethan Gardener wrote: > On Mon, Aug 19, 2019, at 12:53 PM, Cyber Fonic wrote: > > > > It has been said : "The 'S' in IoT stands for security". If Plan9 can > address that deficiency of the current state of the art for IoT devices, > then it would be a worthwhile exercise. > > Plan 9 may have a decent security model, but it's never been audited. > Auditing a codebase, even one as small as Plan 9's, is a lot of work. Are > you willing to make a start on it? > > If you want something free and already audited, with more security > features, (but perhaps not quite the same convenience,) look into OpenBSD. > > -- > I love that *Open*BSD is so *security*-focused! > > --00000000000042438c05908c3a6c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I don't think OpenBSD will run on an ESP-32.=C2=A0 Tha= t is part of the problem with IoT, the nodes are made on the cheap and thus= use the cheapest viable network capable device.

On Tue, 20 Aug 2019 at 00:5= 4, Ethan Gardener <eekee57@fastma= il.fm> wrote:

On Mon, Aug 19, 2019, at 12:53 PM, Cyber Fonic wrote:
>
> It has been said : "The 'S' in IoT stands for security&qu= ot;. If Plan9 can address that deficiency of the current state of the art f= or IoT devices, then it would be a worthwhile exercise.

Plan 9 may have a decent security model, but it's never been audited.= =C2=A0 Auditing a codebase, even one as small as Plan 9's, is a lot of = work.=C2=A0 Are you willing to make a start on it?

If you want something free and already audited, with more security features= , (but perhaps not quite the same convenience,) look into OpenBSD.

--
I love that *Open*BSD is so *security*-focused!

--00000000000042438c05908c3a6c-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Don A. Bailey" Content-Type: multipart/alternative; boundary=Apple-Mail-A0D0F983-318F-449C-BC7B-889673196E1E Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Date: Tue, 20 Aug 2019 09:28:20 -0400 Message-Id: <02669859-3065-478A-AC9E-2C921976A745@gmail.com> References:

<40745EA5-3815-4E4F-9FE0-8F83697E74BA@bitblocks.com>

<1e801ae2-0d18-4df9-a9a7-ec6480b9b6aa@www.fastmail.com> In-Reply-To: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] Plan 9 security Topicbox-Message-UUID: 059109be-eada-11e9-9d60-3106f5b1d025 --Apple-Mail-A0D0F983-318F-449C-BC7B-889673196E1E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Fwiw Plan 9=E2=80=99s code vase has indeed been audited. By me. Several expl= oitable bugs were found including a kernel exploit due to the env driver. I w= rote a working PoC for it which is somewhere on the internet, but it=E2=80=99= s quite old. Much of the code hasn=E2=80=99t changed, and, I would suspect, is largely se= cure. But you=E2=80=99re talking implementation security versus architectural secu= rity. In the case of IoT, Plan 9 does exceptional things to close the gaps t= hat embedded systems supply its users, but it is nowhere near complete. Notably, a trusted root environment needs to be added - which Plan 9 only sl= ightly addresses.=20 Best, D > On Aug 20, 2019, at 9:13 AM, Cyber Fonic wrote: >=20 > I don't think OpenBSD will run on an ESP-32. That is part of the problem w= ith IoT, the nodes are made on the cheap and thus use the cheapest viable ne= twork capable device. >=20 >> On Tue, 20 Aug 2019 at 00:54, Ethan Gardener wrote:= >> On Mon, Aug 19, 2019, at 12:53 PM, Cyber Fonic wrote: >> >=20 >> > It has been said : "The 'S' in IoT stands for security". If Plan9 can a= ddress that deficiency of the current state of the art for IoT devices, then= it would be a worthwhile exercise. >>=20 >> Plan 9 may have a decent security model, but it's never been audited. Au= diting a codebase, even one as small as Plan 9's, is a lot of work. Are you= willing to make a start on it? >>=20 >> If you want something free and already audited, with more security featur= es, (but perhaps not quite the same convenience,) look into OpenBSD. >>=20 >> --=20 >> I love that *Open*BSD is so *security*-focused! >>=20 --Apple-Mail-A0D0F983-318F-449C-BC7B-889673196E1E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Fwi= w Plan 9=E2=80=99s code vase has indeed been audited. By me. Several exploit= able bugs were found including a kernel exploit due to the env driver. I wro= te a working PoC for it which is somewhere on the internet, but it=E2=80=99s= quite old.

Much of the cod= e hasn=E2=80=99t changed, and, I would suspect, is largely secure.

But you=E2=80=99re talking implement= ation security versus architectural security. In the case of IoT, Plan 9 doe= s exceptional things to close the gaps that embedded systems supply its user= s, but it is nowhere near complete.

Notably, a trusted root environment needs to be added - which Plan 9= only slightly addresses.

Best,

On Aug 20, 2019= , at 9:13 AM, Cyber Fonic <cyberf= onic@gmail.com> wrote:

I don't think OpenBSD will run on an ESP-32. = ; That is part of the problem with IoT, the nodes are made on the cheap and t= hus use the cheapest viable network capable device.

On Tue, 20 Aug 2019 at 00:= 54, Ethan Gardener <eekee57@fastma= il.fm> wrote:
On Mon, Aug 19, 2019, at 12:53 PM, Cyber Fonic wrote:
>
> It has been said : "The 'S' in IoT stands for security". If Plan9 can a= ddress that deficiency of the current state of the art for IoT devices, then= it would be a worthwhile exercise.

Plan 9 may have a decent security model, but it's never been audited. A= uditing a codebase, even one as small as Plan 9's, is a lot of work. A= re you willing to make a start on it?

If you want something free and already audited, with more security features,= (but perhaps not quite the same convenience,) look into OpenBSD.

--
I love that *Open*BSD is so *security*-focused!

= --Apple-Mail-A0D0F983-318F-449C-BC7B-889673196E1E-- From mboxrd@z Thu Jan 1 00:00:00 1970 User-Agent: Cyrus-JMAP/3.1.6-916-g49fca03-fmstable-20190821v7 Mime-Version: 1.0 Message-Id: <115a2abc-2231-4492-be26-8e8f7f133559@www.fastmail.com> In-Reply-To: <02669859-3065-478A-AC9E-2C921976A745@gmail.com> References:

<40745EA5-3815-4E4F-9FE0-8F83697E74BA@bitblocks.com>

<1e801ae2-0d18-4df9-a9a7-ec6480b9b6aa@www.fastmail.com> <02669859-3065-478A-AC9E-2C921976A745@gmail.com> Date: Fri, 23 Aug 2019 19:45:28 +0100 From: "Ethan Gardener" To: 9fans@9fans.net Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] Plan 9 security Topicbox-Message-UUID: 064d577c-eada-11e9-9d60-3106f5b1d025 On Tue, Aug 20, 2019, at 2:29 PM, Don A. Bailey wrote: >=20 > Fwiw Plan 9=E2=80=99s code vase has indeed been audited. By me. Severa= l exploitable bugs were found including a kernel exploit due to the env = driver. I wrote a working PoC for it which is somewhere on the internet,= but it=E2=80=99s quite old. My apologies! > Much of the code hasn=E2=80=99t changed, and, I would suspect, is larg= ely secure. Good to know. :) I wonder how many relevant parts have changed in 9front? There are regu= lar kernel changes, some of which were made to handle the heavy shell-sc= ript load of running werc sites. (For a short time, the load on cat-v.o= rg was very heavy.) > But you=E2=80=99re talking implementation security versus architectura= l security. In the case of IoT, Plan 9 does exceptional things to close = the gaps that embedded systems supply its users, but it is nowhere near = complete. I guess I am, and yes, Plan 9 is sadly incomplete in many areas. =20 From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References:

<40745EA5-3815-4E4F-9FE0-8F83697E74BA@bitblocks.com>

<1e801ae2-0d18-4df9-a9a7-ec6480b9b6aa@www.fastmail.com> <02669859-3065-478A-AC9E-2C921976A745@gmail.com> <115a2abc-2231-4492-be26-8e8f7f133559@www.fastmail.com> In-Reply-To: <115a2abc-2231-4492-be26-8e8f7f133559@www.fastmail.com> From: Don Bailey Date: Fri, 23 Aug 2019 13:41:44 -0600 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary="000000000000a8c6dc0590cdff51" Subject: Re: [9fans] Plan 9 security Topicbox-Message-UUID: 066acdc0-eada-11e9-9d60-3106f5b1d025 --000000000000a8c6dc0590cdff51 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Aug 23, 2019 at 12:47 PM Ethan Gardener wrote= : > On Tue, Aug 20, 2019, at 2:29 PM, Don A. Bailey wrote: > > > > Fwiw Plan 9=E2=80=99s code vase has indeed been audited. By me. Several > exploitable bugs were found including a kernel exploit due to the env > driver. I wrote a working PoC for it which is somewhere on the internet, > but it=E2=80=99s quite old. > > My apologies! > No apologies necessary, you didn't know. > > > Much of the code hasn=E2=80=99t changed, and, I would suspect, is large= ly secure. > > Good to know. :) > > I wonder how many relevant parts have changed in 9front? There are > regular kernel changes, some of which were made to handle the heavy > shell-script load of running werc sites. (For a short time, the load on > cat-v.org was very heavy.) > > A delta audit would be useful and might be fun. I don't think I have the time, currently, but I wouldn't mind to get back into it. > > But you=E2=80=99re talking implementation security versus architectural > security. In the case of IoT, Plan 9 does exceptional things to close the > gaps that embedded systems supply its users, but it is nowhere near > complete. > > I guess I am, and yes, Plan 9 is sadly incomplete in many areas. > I don't think it's sadly incomplete. Plan 9 is awesome. However, it isn't really Plan 9's job to address silicon security and hardware trust. Some integrations could be made into the kernel authentication stack and the Secure Store et. al., but that is a gap easily closed. The hard part is choosing cost effective hardware that does the job. The Linux BIOS team (Ron and Pals) have done a great job of getting closer to The Source, but that isn't really something an OS should address. That's more of a firmware/BIOS/CPU thing. --000000000000a8c6dc0590cdff51 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Fri, Aug 23, 2019 at 12:47 PM Etha= n Gardener <eekee57@fastmail.fm> wrote:

On= Tue, Aug 20, 2019, at 2:29 PM, Don A. Bailey wrote:
>
> Fwiw Plan 9=E2=80=99s code vase has indeed been audited. By me. Severa= l exploitable bugs were found including a kernel exploit due to the env dri= ver. I wrote a working PoC for it which is somewhere on the internet, but i= t=E2=80=99s quite old.

My apologies!

No apologies necessary, y= ou didn't know.

=C2=A0

> Much of the code hasn=E2=80=99t changed, and, I would suspect, is larg= ely secure.

Good to know. :)

I wonder how many relevant parts have changed in 9front?=C2=A0 There are re= gular kernel changes, some of which were made to handle the heavy shell-scr= ipt load of running werc sites.=C2=A0 (For a short time, the load on cat-v.org w= as very heavy.)

A delta audit would be useful and migh= t be fun. I don't think I have the time, currently, but I wouldn't = mind to get back into it.=C2=A0

=C2=A0

> But you=E2=80=99re talking implementation security versus architectura= l security. In the case of IoT, Plan 9 does exceptional things to close the= gaps that embedded systems supply its users, but it is nowhere near comple= te.

I guess I am, and yes, Plan 9 is sadly incomplete in many areas.=C2=A0
=

I don't think it's sadly incomplet= e. Plan 9 is awesome. However, it isn't really Plan 9's job to addr= ess silicon security and hardware trust. Some integrations could be made in= to the kernel authentication stack and the Secure Store et. al., but that i= s a gap easily closed. The hard part is choosing cost effective hardware th= at does the job. The Linux BIOS team (Ron and Pals) have done a great job o= f getting closer to The Source, but that isn't really something an OS s= hould address. That's more of a firmware/BIOS/CPU thing.=C2=A0

=C2=A0

--000000000000a8c6dc0590cdff51-- From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 6531 invoked from network); 4 Dec 2023 23:20:48 -0000 Received: from tb-ob0.topicbox.com (64.147.108.117) by inbox.vuxu.org with ESMTPUTF8; 4 Dec 2023 23:20:48 -0000 Received: from tb-mx0.topicbox.com (tb-mx0.nyi.icgroup.com [10.90.30.73]) by tb-ob0.topicbox.com (Postfix) with ESMTP id 0493D1BC54 for ; Mon, 4 Dec 2023 18:20:46 -0500 (EST) (envelope-from bounce.mM18104fe21d2fb13232ef76a6.r522be890-2105-11eb-b15e-8d699134e1fa@9fans.bounce.topicbox.com) Received: by tb-mx0.topicbox.com (Postfix, from userid 1132) id F263A5F881B; Mon, 4 Dec 2023 18:20:45 -0500 (EST) ARC-Authentication-Results: i=2; topicbox.com; arc=pass; dkim=pass (1024-bit rsa key sha256) header.d=boddie.org.uk header.i=@boddie.org.uk header.b=beLgqDJB header.a=rsa-sha256 header.s=dkim x-bits=1024; dmarc=none policy.published-domain-policy=none policy.applied-disposition=none policy.evaluated-disposition=none (p=none,d=none,d.eval=none) policy.policy-from=p header.from=boddie.org.uk; spf=pass smtp.mailfrom=david@boddie.org.uk smtp.helo=smtp1.de.opalstack.com; x-internal-arc=fail (as.1.topicbox.com=pass, ams.1.topicbox.com=fail (message has been altered)) (Message modified while forwarding at Topicbox) ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d= topicbox.com; h=mime-version:date:from:to:subject:message-id :content-type:content-transfer-encoding:list-help:list-id :list-post:list-subscribe:reply-to:list-unsubscribe; s=sysmsg-1; t=1701732045; bh=3qnqdFClRUWCbXEmya0TKSY6CzRSdzvv5oQ6zRwEfX0=; b= XWG+85g1qSeMlqnY44he7WXrLzhaeCTOPaJuRBYru6WcrUvUeK/6Ydi7Li46Z+tH F94kp5wYwDSd1QFNEgJsvHwvsOg6+fOuXU1+3SwjsPfIsxcuAL6PLzbY88DLFXLZ uM2V/s5Yr92weaXJ14K0DtEfM6F5PEUpjeiIrBRHwK8= ARC-Seal: i=2; a=rsa-sha256; cv=pass; d=topicbox.com; s=sysmsg-1; t= 1701732045; b=r8ONCy70cRpbK4WHi2ie6365k/QVATI6ONDtz9MtPraSjvTXt2 5qPxt7Vi+y1zuEqb1989L+Lr2cbArxkDgEz87HoaejLSu/t2Mley+U3HoCEEDtW0 qsxv7nLCWTdcFu7pCfqZidoyfzFb6Sjc/A1eyEa8qqFlyr+Txj4OLO0YI= Authentication-Results: topicbox.com; arc=pass; dkim=pass (1024-bit rsa key sha256) header.d=boddie.org.uk header.i=@boddie.org.uk header.b=beLgqDJB header.a=rsa-sha256 header.s=dkim x-bits=1024; dmarc=none policy.published-domain-policy=none policy.applied-disposition=none policy.evaluated-disposition=none (p=none,d=none,d.eval=none) policy.policy-from=p header.from=boddie.org.uk; spf=pass smtp.mailfrom=david@boddie.org.uk smtp.helo=smtp1.de.opalstack.com; x-internal-arc=fail (as.1.topicbox.com=pass, ams.1.topicbox.com=fail (message has been altered)) (Message modified while forwarding at Topicbox) X-Received-Authentication-Results: tb-mx1.topicbox.com; arc=none (no signatures found); bimi=skipped (DMARC did not pass); dkim=pass (1024-bit rsa key sha256) header.d=boddie.org.uk header.i=@boddie.org.uk header.b=beLgqDJB header.a=rsa-sha256 header.s=dkim x-bits=1024; dmarc=none policy.published-domain-policy=none policy.applied-disposition=none policy.evaluated-disposition=none (p=none,d=none,d.eval=none) policy.policy-from=p header.from=boddie.org.uk; iprev=pass smtp.remote-ip=46.165.236.26 (smtp1.de.opalstack.com); spf=pass smtp.mailfrom=david@boddie.org.uk smtp.helo=smtp1.de.opalstack.com; x-aligned-from=pass (Address match); x-me-sender=none; x-ptr=pass smtp.helo=smtp1.de.opalstack.com policy.ptr=smtp1.de.opalstack.com; x-return-mx=pass header.domain=boddie.org.uk policy.is_org=yes (MX Records found: mx1.us.opalstack.com,mx2.us.opalstack.com); x-return-mx=pass smtp.domain=boddie.org.uk policy.is_org=yes (MX Records found: mx1.us.opalstack.com,mx2.us.opalstack.com); x-tls=pass smtp.version=TLSv1.2 smtp.cipher=ECDHE-RSA-AES256-GCM-SHA384 smtp.bits=256/256; x-vs=clean score=0 state=0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=9fans.net; h= mime-version:date:from:to:subject:message-id:content-type :content-transfer-encoding:list-help:list-id:list-post :list-subscribe:reply-to:list-unsubscribe; s=dkim-1; t= 1701732045; x=1701818445; bh=3qnqdFClRUWCbXEmya0TKSY6CzRSdzvv5oQ 6zRwEfX0=; b=bOoi7XzKN3mN/aiP9jNPuHtIFKtcwo61/M2fGkd1XYZd1XRGXN5 +qKAaD2vGBqkhd4wTBSwqQSIzj3vjpHp69N5jYC7vXZA0CeLEDKXG736DGpRjppN R+wUFUQp+8M1BRPqF0w/xs4IJpjAk5uqJh4GbjokXcHloOjGPnjbn+/0= Received: from tb-mx1.topicbox.com (localhost.local [127.0.0.1]) by tb-mx1.topicbox.com (Postfix) with ESMTP id 4660D55816D for <9fans@9fans.net>; Mon, 4 Dec 2023 18:20:27 -0500 (EST) (envelope-from david@boddie.org.uk) Received: from tb-mx1.topicbox.com (localhost [127.0.0.1]) by tb-mx1.topicbox.com (Authentication Milter) with ESMTP id 4A97CF1A944; Mon, 4 Dec 2023 18:20:27 -0500 ARC-Seal: i=1; a=rsa-sha256; cv=none; d=topicbox.com; s=arcseal; t= 1701732027; b=wqsM1fdx96WpbPidrIKl/NSGnrZ8Ghv8le6nwRk5r/XRNcoHzd E/uvtvbByMeULmuBmxf4xATOHNyghT8rBA4mWmhfMsQ8dE9V+tu9vKtk/uVlfa/f TcQpzANRuRgwxZeK5+fBprW78B3vDlWabzOEDOBx9A2NzVbA7ssikLDeTRj6CgmS fIdPVE/qr+T4Sgb9rSo4H8nrdwk3fr0sbmpS+iflj9d8mt8nkYVxVEYlnVcf/HhM jcI2v+e2u8J0uzHjrOGrMl18VKgObZyURv3haj5H+rqM0kTExflcMvFCiQNlw3MG wvbtM7H0wJqzEAM0oCEtwa2hkB6QnqZJQh2g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d= topicbox.com; h=mime-version:date:from:to:subject:message-id :content-type:content-transfer-encoding; s=arcseal; t= 1701732027; bh=hxZCVWVLtnoWNyFYavWYSSzYiPJ2NHvBMibphbI3zGY=; b=N swcGwIcOgeJfLjhKT/21+PvHvYYhy//Z5Eh0SoHBxpqV6I3b+tbQZ9k2TYvEILBA NWALcwvebZtvgoMzml9iI8GJtXYzl238bHDin1al87JDyJ2T89OUNO6MqXTV1ghS snTMHY4AmiI7vR7IystvZV2nsJYAs60P8oXiEMLnwO4Ts5nvQKEk1yDYL5j8HQ39 xP8BShW7e+8KkRjtIa9OEAlhvSwjBHOQA4iI8oErvViU9CppPh0WrDHXM+v4xP65 E3cq/qZq0DEScSkxykZppUaLO6cBzVdY/z5KqItOqdzYzagmD27LFCLRHbO7M1gm mLZy+GK+VHnpOoncUdCYA== ARC-Authentication-Results: i=1; tb-mx1.topicbox.com; arc=none (no signatures found); bimi=skipped (DMARC did not pass); dkim=pass (1024-bit rsa key sha256) header.d=boddie.org.uk header.i=@boddie.org.uk header.b=beLgqDJB header.a=rsa-sha256 header.s=dkim x-bits=1024; dmarc=none policy.published-domain-policy=none policy.applied-disposition=none policy.evaluated-disposition=none (p=none,d=none,d.eval=none) policy.policy-from=p header.from=boddie.org.uk; iprev=pass smtp.remote-ip=46.165.236.26 (smtp1.de.opalstack.com); spf=pass smtp.mailfrom=david@boddie.org.uk smtp.helo=smtp1.de.opalstack.com; x-aligned-from=pass (Address match); x-me-sender=none; x-ptr=pass smtp.helo=smtp1.de.opalstack.com policy.ptr=smtp1.de.opalstack.com; x-return-mx=pass header.domain=boddie.org.uk policy.is_org=yes (MX Records found: mx1.us.opalstack.com,mx2.us.opalstack.com); x-return-mx=pass smtp.domain=boddie.org.uk policy.is_org=yes (MX Records found: mx1.us.opalstack.com,mx2.us.opalstack.com); x-tls=pass smtp.version=TLSv1.2 smtp.cipher=ECDHE-RSA-AES256-GCM-SHA384 smtp.bits=256/256; x-vs=clean score=0 state=0 X-ME-VSCause: gggruggvucftvghtrhhoucdtuddrgedvkedrudejjedgtdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpeggfffhvf fukfigtgfgsehtjehjtddttddvnecuhfhrohhmpeffrghvihguuceuohguughivgcuoegu rghvihgusegsohguughivgdrohhrghdruhhkqeenucggtffrrghtthgvrhhnpefggefggf efhefhlefgieduffefkeegffffkeethfevveelfeelieehleefieefieenucfkphepgeei rdduieehrddvfeeirddviedpudejvddruddtgedrvddthedrhedunecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehinhgvthepgeeirdduieehrddvfeeirddviedphhgv lhhopehsmhhtphdurdguvgdrohhprghlshhtrggtkhdrtghomhdpmhgrihhlfhhrohhmpe eouggrvhhiugessghougguihgvrdhorhhgrdhukheq X-ME-VSScore: 0 X-ME-VSCategory: clean Received-SPF: pass (boddie.org.uk: Sender is authorized to use 'david@boddie.org.uk' in 'mfrom' identity (mechanism 'include:spf.opalstack.com' matched)) receiver=tb-mx1.topicbox.com; identity=mailfrom; envelope-from="david@boddie.org.uk"; helo=smtp1.de.opalstack.com; client-ip=46.165.236.26 Received: from smtp1.de.opalstack.com (smtp1.de.opalstack.com [46.165.236.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tb-mx1.topicbox.com (Postfix) with ESMTPS for <9fans@9fans.net>; Mon, 4 Dec 2023 18:20:26 -0500 (EST) (envelope-from david@boddie.org.uk) Received: from webmail.de.opalstack.com (webmail.de.opalstack.com [172.104.205.51]) by smtp1.de.opalstack.com (Postfix) with ESMTPSA id D65551328C5; Mon, 4 Dec 2023 23:20:23 +0000 (UTC) MIME-Version: 1.0 Date: Mon, 04 Dec 2023 23:20:23 +0000 From: David Boddie To: 9fans <9fans@9fans.net> Subject: Re: [9fans] Plan 9 C compiler for Xtensa CPUs Message-ID: <198d4465ce0325f1ad12666fb769b4f4@boddie.org.uk> X-Sender: david@boddie.org.uk Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Topicbox-Policy-Reasoning: allow: sender is a member Topicbox-Message-UUID: b86ace8a-92fb-11ee-9581-c44418501439 Archived-At: =?UTF-8?B?PGh0dHBzOi8vOWZhbnMudG9waWNib3guY29tL2dyb3Vwcy85?= =?UTF-8?B?ZmFucy9UODllMzk2MDMxNjQ2YmEyMC1NMTgxMDRmZTIxZDJmYjEzMjMyZWY3?= =?UTF-8?B?NmE2Pg==?= List-Help: List-Id: "9fans" <9fans.9fans.net> List-Post: List-Software: Topicbox v0 List-Subscribe: Precedence: list Reply-To: 9fans <9fans@9fans.net> List-Unsubscribe: , Topicbox-Delivery-ID: 2:9fans:437d30aa-c441-11e9-8a57-d036212d11b0:522be890-2105-11eb-b15e-8d699134e1fa:M18104fe21d2fb13232ef76a6:1:lerHf1axeOkNIg2CMg7nWUmtbwMPE3SXyB7oVt_rXK4 On Sat, 10 Aug 2019 16:18:16 +0000, Charles Forsyth wrote: > I haven't had a lot of spare time, but I did the assembler and am about=20 > 3/4 > through the loader. > For the most part it's a straightforward RISC. > Might do the disassembler next to help debug the rest, and finally the > compiler. Did you get any further with this? I'm interested in attempting a port of Inferno to an ESP32 board I've just picked up. Learning the instruction set is going to be interesting. David ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T89e396031646ba20-M18104= fe21d2fb13232ef76a6 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription