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:


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