core only ROS build?

Has anyone produced a ‘core-only’ build suitable for smaller SoC’s or dev. boards with no video?
If not would it be as simple as building just a core set of modules and booting into a little
‘command prompt-via-serial-to-terminal’ type program?
How small could RISC OS be made?

With an expected 20 million connected devices by 2020 in the Internet-Of-Things, surly we have the ideal OS for such devices…

Matt

It would be single tasking, so of little use.

I think ‘of little use’ is a bit strong – effectively you’d be left with a miniture BBC Micro ( once setup with a terminal ) which has been of much use over the years – especially for monitoring sensors. The sort of applications used in the Internet-Of-Things ( sensors, relays, etc ) would be very simple, and would most likely be single tasking – besides any needed background tasking could be easily taken care of by modules as would be interrupt related anyway – i.e packets arriving, I/O etc.

However I agree a more dedicated OS would be of more use, however I don’t think it currently exists. Perhaps (a new) ‘Embedded RISC OS’ could be the way forward – we are talking a huge future market, so this should be taken seriously.

Matt

It would be single tasking, so of little use.

True and false respectively.

I’ve long thought that the task management and WIMP GUI aspects of the Window Manager ought to have been separated, with the task stuff going into TaskManager (and the UI bits of that back into WindowManager).

The fact that you initialise tasks with WindowManager even if they don’t have a window but ask TaskManager for the list of current tasks is… odd.

Perhaps a new module, “Task”, which Wimp_Initialise, TaskManager_EnumerateTasks etc would proxy to. (Yes, I know TM_ET is not quite the same as Task_Enumerate would be… I’ve exploited that subtlety before).

Well… my central heating controller runs headless on an A3010. It definitely multi-tasks and indeed requires multi-tasking, because other apps (e.g. Alarm) are required to run.

If I ever get around to making it into a home automation gateway, even more apps will need to run, multi-tasking.

I’m not sure what benefit there is to be had by removing the Window Manager. I’m certain that apps that normally have a GUI, e.g. Alarm, would need to be runnable anyway.

Perhaps the simplest solution is to leave everything there, and configure the screen to a low resolution so as not to consume much RAM.

There has to be some way of dealing with Wimp error boxes.

Arguably, leave the Window manager there, run at a reasonable resolution, and supply a VNC or RDP server for remote management.

Perhaps (a new) ‘Embedded RISC OS’ could be the way forward – we are talking a huge future market, so this should be taken seriously.

I’ve been saying this for years – usually by picking holes in my ARM based PVR that overflowed its 16Mb flash just to record and play back video with a fancy looking UI. RISC OS ought to be much more cost effective in being smaller.

Limitations, however:

• we don’t natively support POSIX for pre existing code.
• we don’t support multitasking single tasking apps – it can be done on interrupt at system level, but this carries its own pitfalls.
• RISC OS is not particularly resilient against bad code at system level – forget to attack R14 before calling a SWI in module code and watch the machine hang.
• what is the maturity of our MySQL and PHP?

Don’t get me wrong, I would be totally behind an embedded platform running RISC OS; there has to be more than a hundred types of Linux; but there are some issues that would need to be considered.

As for a headless OS, I believe the system can accept input from serial and write VDU output to serial – cam this be altered (vectors?) to speak telnet instead?

we don’t natively support POSIX for pre existing code

Does UnixLib not provide that? (I don’t know)

we don’t support multitasking single tasking apps

TaskWindow. Note that the TaskWindow module does not require any particular UI (and would be happy with Telnet to use your example) but does require task switching… hence my comment.

RISC OS is not particularly resilient against bad code at system level

Nor is anything else, by definition. What you mean is it’s much easier to write system level code (and in fact you’re more often forced to) in RISC OS.

forget to attack R14 before calling a SWI

I’m pretty sure I always forget to do that. I scowl though, is that OK?

As for a headless OS, I believe the system can accept input from serial and write VDU output to serial

Yes.

can this be altered (vectors?) to speak telnet instead?

Yes.

There has to be some way of dealing with Wimp error boxes.

A combination of a couple of utilities NoError (IIRC) and WimpLog (Theo’s stuff)
i.e. Error appears – WimpLog sticks it in a Syslog file and then noerror kills the box that you can’t see because you don’t have a gui.

we don’t natively support POSIX for pre existing code
Does UnixLib not provide that? (I don’t know)

I have highlighted the important word. UnixLib is an add-on.

Still, we don’t want to be POSIX compliant. It basically describes a generic Unix right down to how the filesystem looks and a bunch of commands that should be implemented, one of which is “awk” (sounds like an animal noise – awk! awk! awk!). What is the OS specification doing telling you that you need a pattern processing language? [http://pubs.opengroup.org/onlinepubs/9699919799/]

I notice also that the description of the directory structure [http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap10.html] glosses over the /bin /sbin /usr/bin /usr/sbin mess.

forget to attack R14 before calling a SWI
I’m pretty sure I always forget to do that. I scowl though, is that OK?

This is what happens when you have a phone with a broken text-entry UI (Sony, I’m looking at YOU – both the Xperia Mini Pro and the current Xperia U are the same) that doesn’t necessarily show you what you are writing but might display some other part of the text… and a tappey-swipey input system that takes guesses at what you wanted to say. stack, bad, attack, good. Bzzzt! Wrong!

That said, maybe the phone is right? Playing with R14 in SVC mode is like attacking it, and yeah, when the thing freezes and you have to reset, scowling is involved. And lots of words you don’t say in front of children or grannies.

Doesn’t the current layout of RISC OS imply that TaskWindow goes hand in hand with the Desktop? I’m not aware of any other task switcher option.

As for a headless OS, I believe the system can accept input from serial and write VDU output to serial
Yes.
can this be altered (vectors?) to speak telnet instead?
Yes.

Your reply suggests to me that you may be aware of an interrupt-driven telnet interface to replace VDU/kbd. Have I missed something interesting?

There’s code in HAL_DebugTXRX to essentially implement the ‘core only’ mode – boot to a Supervisor prompt using the serial port rather than video, which is used in board bringup . Any kind of ‘cloud image’ would still need to be targeted at a particular platform.

glosses over the /bin /sbin /usr/bin /usr/sbin mess

There’s a good reason for that. /usr may be on a network share or otherwise unmounted, so you need somewhere to put enough commands to be able to mount it and get at the rest of your files. Think discless machines with a tiny amount of ROM that’s enough to contain /bin and /sbin but not all the packages in the world. And sbin is for things that only root can use – hides them away from normal users who can’t run them. A multi-user networked OS is a different ballgame.

What is the OS specification doing telling you that you need a pattern processing language?

If it’s used by the basic system, you need it. Try running a RISC OS machine without BBC BASIC and see how far you get (“BASIC? Isn’t that a 1960s toy language…”)

one of which is “awk” (sounds like an animal noise – awk! awk! awk!).

Some say it’s an abreviation of AWKward. If you try working with it, you find the view is apt and you are in fact mostly working against it. (Or you are a super geek and its all perfectly normal)

Agreed RISC OS is a little way off running Apache, but we’re a lot closer to running a small footprint webserver than running a modern browser – I can’t see Silverlight / Flash on ROS in the near future.. As for non-deskop multi/backgroud-tasking I imagine an event manager that handled all the interrupts (safely) and provided an easy to use API for setting up handlers etc. would go along way. I guess a new messaging system would also be needed as the existing system is provided by the window manager. Although back to my original question – any size estimates for a core only RISC OS? I imagine a 256k ROM (with space for software) would be feasible.

Changing the subject a little I believe the modern ARM’s are too powerfull for the IOT – can you imagine how small / low power an ARM2 (with it’s lightening fast STM/LDMs and no cache issues ) could be if made today??

I can’tsee Silverlight /Flash on ROS in the near future..

Aren’t people trying to get rid of this stuff on the desktop? ;-)

I believe the modern ARM’s aretoo powerfull for the IOT –can you imagine how small / low power an ARM2 (with it’slightening fast STM/LDMs and no cache issues ) could be if made today??

I think this area is sewn up with the existing hardware. The thing is, low power devices don’t need fast processing. My bread maker uses an 8051 clone clocking…well, it is a 4MHz oscillator… The PVR is ARM (200MHz) and DSP (100MHz) combo and while the UI is laggy, it can record 640×480 in realtime with AAC audio. Other embedded devices would fall between those extremes.

Oh, and it would need to be a 32 bit ARM2 with onboard MMU and some I/O and timers and such. These devices already exist, look at other members of the OMAP and DM320 family. The only thing is, the devices that run a good ARM with basic graphics (if any) aren’t cool for running Linux upon. The Pi is basically a hardcore video chip with an ARM thrown in to tie the knots…..

Yeah, I think 256K ought to be doable – RISC OS 2 was only 512 all in wasn’t it?
Might even, gasp, for into 128?! :-)

implement all of the extended HW in software using Bit Banging techneques.

You may find timing to be… interesting. Having written emulators, you ought to know that a bunch of things running async is really seriously hard to get accurately correct when it is a single thread of a single program doing the task of emulation.

I’d stick with an SoC – simpler and they already exist. ;-)

Just out of interest, why did you pick the MIPS 220?

simpler to simulate HW on a CPU

Simpler for who?

After you have farmed off all of the slow speed interfaces to another chip and written the interface on that chip to communicate with it. How is that different to me as the user of that chip to programming the same devices on a SOC. For you its different you wrote it you understand it but for me I need the documentation to work out what to do. I have just as much chance of being able to work out how to use a SOC interface as your interface.

I have the same problem with software libraries. I write the library what it does is obvious, other peoples libraries don’t always work in the way I think.

Bit-banging is of very limited usefulness. It doesn’t lend itself to multi-tasking. It ties up the CPU in a task that must not be interrupted. Worst of all is bit-banging input, where you have to tie the CPU up in a permanent listening task.

And you can completely forget high speed USB.

In reality it’s enormously better to have appropriate I/O subsystems that do their low level stuff autonomously. Those tasks can carry on simultaneously.

But we all agree, without adequate documentation we’re stuffed.

In reality it’s enormously better to have appropriate I/O subsystems that do their low level stuff autonomously.

Exactly. While it is fun to bit-bang stuff, it doesn’t scale. If you are handling SPI for SD cards, USB, Ethernet, a serial port, and IIC – and you want to run a fast IIC, what do you do? Ignore the other stuff while you contentrate on the IIC? What if something is busy-waiting but you have to keep the other systems alive through this? I think the code to try to cope would become quite hellish in short order. Oh, and let’s not forget the amount of processing power required to bit-bang rapidly, due to the amount of code, the variance in what a processor is doing at any one time, and so on.

Quote:

I guess the maximum latencies should be below 50 µsec for 9600 baud to not get errors and any latency of over 100 µsec causes completely missing a bit in transmission or reception.
This is all without even touching the GPIO pins yet. Since I could not get a clean run even with just 2 seconds, it seems safe to say that without real-time patches the Raspberry Pi can not bit bang a 9600 baud serial link without generating errors for any serious amount of time.

[source: http://raspberrypi.stackexchange.com/questions/1987/can-raspberry-pi-reliably-bit-bang-a-9600-baud-serial-and-is-there-example-code ]

If a ~700MHz machine cannot reliably bit-bang 9600bps serial… This isn’t to say it cannot handle running I/O at those sorts of speeds, I think the main problem here is the timing is completely out of whack. In the example above (the IIC stuff), you realise that dealing with IIC while there is ongoing serial communications means a very good chance the serial comms will get trashed. It is very time sensitive, as explained in the quote.

Perhaps a way to look at the SoC is a dozen tiny processors all merrily bit-banging their own protocols, leaving you to respond to tidily arranged (if not always logical) messages. A good example of the usefulness of this is the ADLC that was for Econet. Each bit of each network packet interrupts the computer, however once the packet has been determined as not being relevant to us (ie not our station number), the ADLC itself can discard the remainder of the packet without bothering us. This is the sort of advantage we can levy when using prebuilt I/O subsystems – let them do as much as possible so we don’t have to!

In case anyone wants a real ARM2, the Amber core runs at 80MHz on a Virtex 6 FPGA. I imagine it could probably be squeezed a bit further. However the real equivalent to an ARM2 today in terms of size and complexity would be a Cortex M0 at about 50MHz (12K gates, >0.01mm^2, 4uW/MHz in a 40nm process).

It is possible to create a simpler interface, more like the old ones that were easy to wrk with, and with a total overhead in coding that is less than that of using the newer device controlers.

Certainly – one would imagine that the point of having intelligent controllers is that they are, you know, intelligent.

In this day and age, it would be nice to be able to think that talking to an SD card is more or less: Is an SD card present? Yes? Okay, read the descriptor block so we know how big it is and such. Okay, good, not read sectors 0 through 7 so we can work out partitioning and format. Anything more complicated than that, you’d wonder why you couldn’t just bit-bang SPI out of some GPIOs and wrap it all up in a few higher level routines.
After all, it is surely the job of the SD controller to talk to SD cards, not you to tell the SD controller how to do it.

Bit Banging (with an very litle passive external HW) is the only I had ever done High Speed USB before working on the ROOL USB Stack.

I am a believer in having simple hardware and putting the smarts in software. I did a project many many years ago to implement a serial port on my A3000 using a MAX232 wired to the parallel port. I was able to, with interrupts disabled, bang out 1200bps moderately reliably but it took a lot of scouring the ARMinstrs document and some rather peculiar code to get the timing exactly right. I reckon I might have been able to push the code to 2400bps (it was a little erratic at that speed, but mostly worked).
This was, mind you, a banging loop with interrupts disabled. Running with interrupts enabled, even 1200bps was erratic.
Now, shall we talk about receiving data? You couldn’t run with interrupts disabled because you use an interrupt to tell when data is present. When you get it, you disable interrupts so you can concentrate on receiving, only to find you have missed bits.
In the end I coughed up for the 6551 ACIA and fitted that.

More recently, I have only worked with bit-banging IIC which has the beauty of being a clocked protocol so you can run it at whatever speed the computer is comfortable with timing jitter not being a concern so long as the 4.7uS is respected.

This is also the reason that I no longer program for the x86 series of CPUs, with the unreasonable implementations of pipelining, out of order execution, etc optimizing for them takes to long to be worth it.

This is because few people bother with assembly these days and some compilers are… lacking. So essentially you are trying to optimise for the processor and the processor is trying to optimise for you.
Oh, and yes, what is the current generation of x86 cores, something like forty-odd stages of pipeline? WTF? Back in the day it was 1:Fetch, 2:Execute, 3:Deal With Results. That’s the 6502. Then processors added a “pipeline” to have a number of instructions pre-fetched, and possibly part-decoded. This is reasonable as it probably allows zero-cost features like logical shifts and rotates that don’t take extra cycles. Then a cache was added because we all know that processors run faster than memory so getting lumps of code into memory running at processor speeds should make things a lot better. This works better with architectures like the ARM that are Load/Store instead of ones like 6502,x86 that require many memory accesses. Then branch prediction was created, this again is useful for systems that are unlike the ARM and don’t have conditional execution. The problem is when a branch is taken, the pipeline and cache are rendered useless and the contents need to be thrown away and it all fetched anew. The solution is to either attempt to predict which part of the branch will be the most likely to be taken, or to fetch both paths in parallel and discard the one that isn’t correct. This again makes sense.
Then it all went crazy.
Surely out of order execution is to attempt to eke some speed out of some poorly compiled code? If the compiler had sufficient knowledge of the processor, it ought to be able to schedule how things happen, so you can call the FP unit, do something else, and when you’re done the FP unit will have the data ready (instead of either busy-waiting on the reply, or having the CPU itself reorder the instructions).

A 700MHz machine would be overkill, the limitation that you were refering to has nothing to do with the machine speed 50 microseconds, that could be accomplished by a Z80 running at 0.2MHz (200KHz) with plenty of time to spare.

I understand that a 700MHz processor ought to be able to bang 9600bps serial. Certainly, it has been proven that C code with a good library can bang GPIO at around 20MHz (and possibly a lot more if you use assembler and disable interrupts).

However the issue here is not whether or not the processor is capable of doing this task, but rather can it do it competently. It is not; not through an inability to run at such speeds, but rather through an inability to do so without timing jitter. There is something important to remember about serial comms – it is NOT an ack/nak protocol. It absolutely depends upon accurate timing. It only needs to maintain this for a single frame as it can sync off the start bit, but for that period it must not jitter. Sadly, if you are running a software serial and an operating system, you cannot guarantee that the timing will be accurate.
The solution people have used is to use the PWM controller which runs its own timing and feed data into the serial shift register; but this is not directly bit-banging serial.

It will work a lot better for clocked and ack/nak protocols. Bit-banging IIC is effortless. However a processor can’t reliably handle a time-sensitive protocol unless that is all it does. Dedicated hardware is much better at this task. If you don’t believe me, you can get 16550 clones running up to 230-460Kbps; try to imagine the sort of processing power you’d need to do that in code. Will your IRQ latency be sufficient or would you need to continuously sample? You’d need to sample at 2-4 times the data rate to be sure to catch glitches. You would need to detect bits, set yourself up to accept a new byte, do the bit processing, store the byte, and all the while every single time taking the same number of cycles so you don’t drift.
Or you can use a chip that is dedicated to this task.

ARM timings for the Cortex-A8 are on ARM.com. Curiously, the ARM ARM (thin white and big blue) don’t contain a table of timings anywhere. Hmm!

We’ll all agree on one thing though – hardware without proper documentation is about as useful as two tampons tied together would be for acting as a telephone…

The simple example of 640×480@5BPP using an external latch and resistor dac you have to provide data at 25MHz, that is once every 40 nanoseconds and this leaves plenty of time to do other things in the mean time,

Hmm… Within C, and I presume with Linux active, the maximum they could push the GPIO on the Pi to was 21.9MHz. [source: http://codeandlife.com/2012/07/03/benchmarking-raspberry-pi-gpio-speed/ ] I did laugh at the 3.4kHz using the shell (!), and it was “interesting” that all these different languages and libraries and there was no pure assembler.

Of course, bit-banging custom VGA can be done with much lesser hardware than a ~700MHz Pi. Like, say, a 20MHz microcontroller [ http://www.linusakesson.net/scene/craft/ ]. However, the thing is that the microcontroller has the luxury of being dedicated to just the one task. A CPU has to do it in addition to everything else.

This is the essence of my issue with using bit-banging. I have no problems with one processor banging one interface, but do worry about timing and contention (etc) of one processor handling multiple interfaces. Hence my comments about serial. It can be done, but it can be done only when there is a processor dedicated entirely to that and nothing else.

Which gets back to Colin’s point (of May 17th), that if you have a bunch of processors providing a bunch of interfaces, haven’t you just basically duplicated the core interfaces of the typical SoC?

Now the best solution would be to make the HW interfaces simple like the should be

I think the trend these days is to make the interfaces complex with the intention that more work can be offloaded from the CPU.

Think about it. Let’s just assume you are creating an interface for IIC using a piece of bit-bang code on a lowly PIC. The initial set of resources will be check bus, start, get byte, put byte, stop. Those are all that is necessary for a functional IIC implementation. Now tell me that you wouldn’t be tempted to add “get byte*s*” and “put byte*s*” and maybe some other stuff like the ability to act as a master or a slave? Then you can go a step further with “transfer in”, “send”, “receive”, “transfer out”. This will make your device really simple to use – you simply load up to n bytes into the PIC’s RAM and tell it to “send” and it will interrupt when it is done or upon failure. You’ll be talking to your device in a way not unlike calling OS_IICOp instead of start, send, send, send, (repeat x times), stop.
Which is, more or less, what is happening with embedded controllers. Now, yes, some are more complicated than you would imagine necessary, and some have an API that is almost as big a pile of poo as the Windows API (written by drunken monkeys if you ask me), but they do attempt to offload some of the work from the main processor. To varying degrees of success. ;-)

and document them well so that we can program for them.

Damn right.

As you are writing code for USB, I thought I’d chuck in randomly – the USB Mass Storage support in Android leaves a hell of a lot to be desired. My older phones, my Motorola Defy and my Sony Xperia Mini Pro both had “issues” when transferring large files via USB when the storage was in mass storage mode. The Defy would break the connection leading to an incomplete file. The Mini Pro would either break the connection, or “just reboot”. It was 50-50, and if it rebooted, there was a risk the SD card’s map would be a mess. Android would fix it, but at the risk of trashing a bunch of innocent files along the way. Once I sussed this, I found it a lot simpler and safer to dismount the card (a nice feature of the X-MiniPro was you could remove the back and slide out the uSD, it wasn’t buried under the battery or anything) and perform the copy using a regular card reader.
My current phone (Xperia U) has 4Gb internally (no uSD) and it only works in MTP mode. This is more reliable, although it has a tendency to create large files in the LOST.DIR folder… mmmm…
Anyway, just an anecdote of no consequence whatsoever, other than to suggest that if Google and Motorola/Sony can’t get it right… ;-)

(or maybe their documentation was lacking too?)

http://www.linusakesson.net/scene/craft/

Watch the video. It’s real retro, I remember stuff like this on Acorn User cover discs. But, more than that, it is really impressive for being generated by a 20MHz microcontroller banging out a VGA signal and audio and doing the calculations necessary to draw the screen in realtime.

<keanu> Whoa. </keanu>

and document them well so that we can program for them.

I have no experience of implementing usb and only know what I’ve read from the few documents I’ve read on the net. But it seems to me that usb has the most comprehensive documentation I’ve seen. The EHCI specification (usb 2),for example, defines a register level interface that must be adhered to for all EHCI host controllers and tells you how to feed them (the devices handle all scheduling/priorities of the lists of data fed). So a EHCI driver will (I’m going to say will because I’m naive) work with any EHCI device.

Doesn’t make the programming (or the reading) easy though :-)

Watch the video. It’s real retro, I remember stuff like this on Acorn User cover discs. But, more than that, it is really impressive for being generated by a 20MHz microcontroller banging out a VGA signal and audio and doing the calculations necessary to draw the screen in realtime.

Actually, I found this rather disappointing compared to the newer stuff they do on a CPC (4 MHz Z80 with a lousy 6845 CRT).

Has anybody ever tried the minimal amount of RISC OS possible on a Pi with video and keyboard? (essentially, as mentioned above, a turbocharged Beeb)

I tried copying the Pi project files (as BCMmini) and knocking out many modules, but the result didn’t work – boot LED blinks as if image is being loaded, but then…nothing. [as in nothing on the screen; I don’t have a serial level convertor for outputting debug]
Are there any explicit dependencies (like must have FPEmulator, or something?).
Might play some more tomorrow.

Before anybody asks – just wondering how small I can make RISC OS while having it still remain capable (so had BCMVideo, SDFS, SDIO, RTC, BASIC, USB…).

Are there any explicit dependencies (like must have FPEmulator, or something?).

This is the minimal set of modules that were used to get the first few OMAP3 builds working over a serial terminal. A bit more minimal than what you’re aiming for, but it highlights the core modules that are needed in order to get the CLI working.

For the features you’re after, off the top of my head, I think the requirements are: (not including the modules from the base set above)

• BCMVideo – requires VCHIQ if you want to avoid mouse trails
• SDFS & SDIODriver – requires FileCore, DOSFS (assuming you want access to the DOS partition), SharedRISC_OSLib (i.e. the shared C library), PCI (I think – not sure)
• RTC – requires SharedRISC_OSLib
• BASIC – no dependencies now that BASICTrans is gone. BASIC64 requires FPEmulator however.
• USB – requires RTSupport, USBDriver, DWCDriver, SharedRISC_OSLib, PCI, DeviceFS. Also FileCore, DOSFS, SCSISoftUSB, SCSISwitch, SCSIFS, and the CDFS modules depending on what types of storage you want to use.

Some sub-dependencies:

• VCHIQ needs SharedRISC_OSLib and RTSupport
• SharedRISC_OSLib needs FPEmulator