Prop2 MMU
m00tykins
Posts: 73
Hello all,
I was wondering if the Prop2 will feature a MMU. Also, I realize this will be a newb question, but if not, could one of the cogs be designated as a MMU for the other cogs, so they could run a more "advanced" OS? Based on my limited understanding, I think this should be possible, since early computers used discrete MMU ICs. Why or why not? Thank you very much!
-m00ty
I was wondering if the Prop2 will feature a MMU. Also, I realize this will be a newb question, but if not, could one of the cogs be designated as a MMU for the other cogs, so they could run a more "advanced" OS? Based on my limited understanding, I think this should be possible, since early computers used discrete MMU ICs. Why or why not? Thank you very much!
-m00ty
Comments
Sorry, I don't see any mention of an MMU feature there... I'm guessing that's a no then? If so, is there any reason why an MMU can't be emulated in software on a separate cog? Thank you.
Why Propeller need more "advanced" OS? Why no run more "advanced" OS on ARM and leave Propeller for low level HARD REALTIME jobs?
Thinking FPU maybe?
I also don't understand... How would the CORDIC functions help implement a MMU?
The architecture is not yet settled. Thinking about MMU features is far from the short list of Prop2 features.
MMU might be realistic as a topic for future Prop3 design. Depends quite a bit on how well Hubexec pans out. And, really, even HubRAM is not enough space for talking MMUs, IMHO.
RAM might not be an issue if we use LMM though, right?
Prop1 XMM - execute from external SRAM - is likely what you are thinking about. It's quite slow. Throwing MMU functions on top of that can only be proof-of-concept material.
Chip is hinting he wants to also have hardware XIP for SDRAM on the Prop2. We'll see if that eventuates. Given that Cog instruction caching will likely be tuned for Hubexec then any external instruction fetching is likely to suffer badly due to large latencies.
Well, an MMU is all about fooling a CPU into thinking it has more RAM than the computer actually has. Or at least about stopping a process accessing memory it has no right to be using. Or mapping the addresses the processor thinks it is using to some other addresses where it's data actually is.
In order to do all that an MMU has to be able to cause a "fault" or interrupt when an address out of range is accessed. That interrupt generally get's control into some operating system which swaps memory around, from disk say, and then returns control to the application. The application does not know anything happened.
Clearly this fault/interrupt action cannot be emulated in software.
Unless of course your code is already being run by some interpreter, like Spin for example, that can check address ranges on each and every memory access. Thus making things horrible slow.
Question is, what advanced OS would you want to run on a Propeller? And why?
External device support is certainly going to be interesting, and a challenge to get right.
Some form of SDRAM state engine, that avoids software banging pins, would make a huge difference.
Likewise, HW support for the Spansion Hyperbus would allow low pin count memories to be easily added to what is a low pin count part.
There is mention of RAM coming on the Hyperbus, which could quickly transcend SDRAM, which is trailing edge DRAM now anyway.
External Memory is certainly cheap, on cents/MB basis, and it may be a page-aligned cache allows compilers/linkers to avoid crossing cache boundaries, and so thrash the cache.
Inner loops that can be crafted to load once, and then execute in cog, would have very high performances.
I see Spansion have Automotive MCU's (ARM R5) due to sample in Q4, that have Hyperbus Memory HW BUS for external code (and icons/fonts) fetch.
It could work so that you can specify one contiguous region of hubram per cog so that the cog either can only access memory inside (protection/exception catching) or outside (breakpoints) the region. When a violation occurs, the cog will be paused and a description of the entire offending operation (instruction, dest value, src value, new dest value, pc, flags, etc.) would be written to a dedicated per-cog but globally-accessible register somewhere so the debugger cog can get it and decide what to do. This removes the interrupts and replaces it with something much more propeller-ish, polling loops, and makes writing a debugger really easy (i.e. not impossible).
This can also be used for inter-cog communication by making it so the debugger cog can decide what the result of the operation is. A cog can request something by trying to access an illegal location, and another server cog can see the violation and return a value back to the cog.
Maybe there should also be a cogram version so you can debug things that run entirely or almost entirely out of cogram and still put breakpoints anywhere, but that would probably be slower and use more power. Maybe it could be simpler for cogram - just a single pc value that triggers the breakpoint.
This post brought to you by Carl's Jr
QuadSPI is still there, and [Dual DDR QuadSPI] is very close to Hyperbus, so I'm fine if Parallax want to support Dual DDR QuadSPI, with an optional CLK-in - the naming is mostly semantics anyway.
Many would prefer the packages of [Dual DDR QuadSPI]
Haha, I'm still wanting to make that networking-capable completely open-source computer I mentioned a while ago based on the prop2. I know it's a huge undertaking, but I'm sure even if turn out to be in over my head with this project I'll still certainly learn a lot. I'm planning on trying to port the seL4 microkernel to the prop2. It's "only" about 5 kloc and mostly written in C, and is faster than many monolithic kernels, so I'm sure it's *possible* to get it to run on the prop, though actual *difficulty* is another story XD. Being secure is one of the major design objectives I have, so a MMU is of course almost necessary for security applications, which is why I chose an OS that requires an MMU as opposed to an embedded OS like contiki.
Obviously, though, such features are not part of the feature list of current Prop2.
I see.... In that case I should probably try to start small with an embedded OS like Contiki, RIOT or eChronos. Do you see any inherent problems with porting one of these Operating Systems to the Prop2? Which would you recommend?
I'm leaning towards RIOT out of these three, since it only requires ~1.5kB RAM and can run on MCUs as small as the MSP430, while supporting multi-threading, networking and C++ application development. Full POSIX compliance for RIOT is also underway. eChronos would have been nice, especially since I've heard it will be released as FOSS and is entirely formally verified, but it is not designed for IoT so making it networking-capable might be a challenge in itself.
Of course, without an MMU security almost becomes a lost cause without formal verification, and as much as I like to dream big formally verifying all the software to run on this system is not something I can do in the near future, so I'll have to stick with my primary goal of making a completely open-source computing system and leave security for later.
Just out of curiosity though, is there any way to emulate interrupt support in the propeller? Perhaps by making a separate cog do polling?
That is the usual way.
Right, but I meant to emulate interrupt support for OSes that require that feature.
Funnily, Android frowns upon native code doesn't it? Or is that just convention these days?
That's what I was afraid of, that I'd finally need to make a VM in order to run certain OSes on it. I'll probably leave that for a separate project.
In that case, can anyone here recommend a good IoT OS that they would like to see ported to the prop2? Like I mentioned, I'm leaning towards RIOT, even though contiki is more popular. Are there any other IoT OSes that anyone would recommend?
PS Thanks so much for the help guys
I've historically seen comments along the line of "The compiler can be the OS" and other similarly titled topics. Really, the developer of the device fills the whole package. He picks and chooses just the features he wants to provide to the end user. There is no third party after market developers adding unexpected programs into the mix. Memory isolation shouldn't be needed at all.
In this setting, all can be provided with a bunch of libraries and stacks. Hell, just to keep the tasking simple, put one stack per core even.
Internet browsing?? Or are you looking for the ability to have sensed values from your IoT Prop2 sent to a server for additional processing? Two different beasties and sets of requirements put on the IoT device.
What is it you are actually trying to do? Your end goal is vaguely specified so it's impossible to advise.
There are many reasons on might want an operating system. Lets look at a couple:
1) Portability. It can be a huge advantage to be able to move ones application from machine to machine, architecture to architecture. This ensures your code is usable in many places. It protects you against the discontinuation of you current platform. Hopefully it ensures your code can live on in the future on platforms that have not been created yet.
To do this one needs to make use of a high level language that is available on your possible targets. One also needs an abstraction of all the interfaces your app uses rather than going directly to the hardware.
That abstraction layer can be as simple as an API that is available on the possible targets for your app. Preferably something commonly used and standardized. POSIX for example.
One can go a step down and say that an entire OS is your abstraction layer. Linux for example.
2) Ease of coding.
It is typical of real-time embedded code that it has to handle many external events arriving asynchronously to your program. Such code is often written as a collection of threads. That is to say a bunch of loops that must some how all go around together. Clearly if one loop is executing on a single processor machine the others cannot. This can be sorted out by using a real-time multi-tasking operating system that will grab processing time away from a thread and give it to some other thread as and when required.
This of course brings us to interrupts, but I will let others chime in on that. Over the years the debate about why we don't want interrupts on the Propeller has worn me out.
So. Do we need an OS on the Propeller?
Depends what you want to do. But I would observe that:
1) Given that we can program the PII in C and that any likely required hardware abstraction layers can be quite thin the requirement for an OS for Portability purposes is not so urgent.
2) From a program design point of view we mostly don't need that assistance with threads and interrupt handling. We have 16 cores. That is quite enough threads for most.
Having said that I can see that a port of something like contiki to the Propeller might be attractive if there is an existing pool of contiki applications/libraries you want to bring over to the Prop. Or you want to be able to move your application from the Prop to some other machines that have contiki.
I can also see the attraction of porting an OS to the Prop just, well, because. That's why we had to get CP/M running on the P1.
Sorry for the long essay here.
No worries, thank you for the in-depth response! My goal is just to make a simple web browser capable of displaying text and running the cjdns protocol. I know it's hugely ambitious but I'm sure it can be done, and even if I fail I'm sure I'll learn a lot. The reason I was considering contiki is because it implements the necessary protocols and GUI in a small memory footprint. I'm strongly considering programming the propeller without an OS, but just porting contiki might be easier.
Ambitious? certainly. Cool factor? Huge!
At this point it is a tradition around here that I assert that such a project is "impossible to do on a Propeller".
That generally ensures that it is either done already or done very soon?
Haha I'm just waiting on the prop2 to start...