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