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 <charles.fors...@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. > 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 == 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 <cyberfo...@gmail.com> 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 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 < >> skip.tavakkol...@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 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 < >>> charles.fors...@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.fors...@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.fors...@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 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 <ba...@bitblocks.com> >>>>>> wrote: >>>>>> >>>>>>> esp32 doesn’t have an mmu, right? >>>>>>> >>>>>>> On Jul 26, 2019, at 03:30, Charles Forsyth < >>>>>>> charles.fors...@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 <cyberfo...@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>>> I was reading the post Why Didn't Plan 9 Succeed >>>>>>>> <https://news.ycombinator.com/item?id=20527650> 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? >>>>>>>> >>>>>>>>