Microsoft open-sources ThreadX
theregister.com
theregister.com
Bill Lamie left to start PX5 and work on a new lightweight embedded RTOS and took most of the talent with him. If Microsoft is doing this, they're pretty much walking away from their roadmap for Azure RTOS and IoT nodes along those lines.
I call it a win, ThreadX had a lot more ecosystem behind it than FreeRTOS ever did. And it does run on things other than Raspberry Pis. Renesas used to give it away for free if you bought their SoCs.
The article says ThreadX used to be what Intel Management Engine ME ran on? How do I configure the ME / AMT VNC auth in there?
"currently running on over 12 billion devices around the world"
Is this like another baseband processor?
Everything from your x64 CPU to microSD to credit cards(not the readers; readers run antiquated Android and soon known-bad Chromium) runs some form of weird slow proprietary RTOS. It is what it is. I bet it takes ~century with help of superhuman AI to make those run an open and verified code. The situation is improving too, slowly, because using buggy proprietary code is not a goal, but means.
It's ok to be disgusted about the status quo, but that is not necessarily worth your time; IIRC one of original complaints by RMS on the state of software freedom that lead to Free Software Movement was about some HP printer running buggy custom OS. Even the point people said enough is enough goes back that far.
> weird slow proprietary
They're often not weird, a simple single task runner with a few libraries to handle common tasks and cryptographic operations. Very simple, lightweight, and they generally share a common high level architecture (there's not much variation in an RTOS)
They're often not slow, they're minimalist OSes - barely qualifying as an OS if at all - designed to run a single task, with time guarantees, and to get out of the way. In fact, if it's a single task you need to run, they're faster than any general purpose OS - by design!
They're often not proprietary - a handful of RTOS with huge market penetration used in billions of devices (and now ThreadX) - are open source and have permissive licenses. What IS often proprietary about them are BSPs, but that's a whole separate issue. Yes, there are a lot of proprietary ones out there, but as a blanket statement, it's simply not true.
> readers run antiquated Android
Many use a stripped down version of AOSP, which has become a de facto standard BSP, yes. But many, many others do not (usually a flavor of embedded linux, or an RTOS).
> about some HP printer running buggy custom OS
It was a Xerox printer, and it was because he was frustrated from adding existing job management and notification features he had written to the new printer.
History of Linux: https://en.wikipedia.org/wiki/History_of_Linux
MINIX: https://en.wikipedia.org/wiki/Minix
Redox OS: https://en.wikipedia.org/wiki/Redox_(operating_system) :
> Redox is a Unix-like microkernel operating system written in the programming language Rust, which has a focus on safety, stability, and performance. [4][5][6] Redox aims to be secure, usable, and free.
For the last statement, Wikipedia disagrees:
> https://en.wikipedia.org/w/index.php?title=Minix&oldid=11846...
"Eric Raymond claimed that Linus hasn't actually written Linux from scratch, but rather reused source code of MINIX itself to have working codebase. As the development progressed, MINIX code was gradually phased out completely."
quoting "The Cathedral and the Bazaar"
> https://monoskop.org/images/e/e0/Raymond_Eric_S_The_Cathedra...
for this statement. On p. 24 you can read:
"Linus Torvalds (http://www.tuxedo.org/˜esr/faqs/linus), for example, didn’t actually try to write Linux from scratch. Instead, he started by reusing code and ideas from Minix, a tiny Unix-like operating system for PC clones. Eventually all the Minix code went away or was completely rewritten—but while it was there, it provided scaffolding for the infant that would eventually become Linux."
The only thing Linus 'copied' (rather, modelled) was the initial directory tree layout and some of the names of the core module filenames - none of the code.
Linus was interested in MINIX, no question - and motivated to write his own kernel - but he literally did not fork MINIX.
In "History of Linux" this falsehood is addressed - and it has to be said is amazing that you are parroting even still today:
https://en.wikipedia.org/wiki/History_of_Linux
I challenge you to find the code, from MINIX, that Linus copied and then modified and called it Linux. This is what forking means.
That is not true and never was.
It was in part bootstrapped on Minix but it contains no Minix code at all and was built with GNU tools.
That the MINIX code was replaced before release does not make it not a fork.
Fork: take the existing code, make your own version and start modifying. That does not apply here.
Torvalds did not take any Minix code; one of the reasons he did his own was that the licence agreement on Minix prevented distribution of modified versions. At the time Freax/Linux got started, people were distributing patch sets to Minix to add 286 memory management, 386 handling and so on, because they could not distribute modified versions.
The Linux kernel started out as 100% new original code. I was there; I watched the mailing lists and the USEnet posts as it happened. It's the year I started paying for my own personal online account and email, after 4Y in the industry.
The origins of Torvalds' kernel were as a homegrown terminal emulator. He wanted it to be able to do downloads in the background while he worked in a different terminal session. This required timeslicing. He tried and found it was complicated, so he started implementing a very simple little program that time-sliced between 2 tasks, one printing "AAAAAA..." to the console and the other printing "BBBBB..."
This is all documented history, which it seems you have not read.
You are wrong.
Furthermore:
> including the regression to a macrokernel.
This indicates that you are not aware of the differences between Minix 1, 2 and 3.
Minix 3 (2005) is a microkernel.
Minix 1 (1987) was not and does not support an MMU. It runs on the 8086 and 68000 among other things.
Linux (1991) was originally a native 80386 OS, the first x86-32 device and a chip that was not yet on sale the year that Minix 1 was first published.
Summary:
Linux is not a fork of Minix and is unrelated to Minix code.
By buying FreeRTOS and building up the ecosystem, they were hoping to own the OS for IOTs.
Taking stewardship of FreeRTOS allows them to develop a SDK, with or without a hardware kit included, to encourage IoT developers to lock into the Amazon ecosystem.
https://docs.aws.amazon.com/freertos/latest/userguide/c-sdk....
Microsoft saw this chain of events and panicked, buying up ThreadX to create Azure RTOS. I believe MS is now abandoning this path and focusing on other green fields...the recent events with OpenAI being a huge signal.
A "software defined vehicle" [1].
Those R&D teams spend a small fortune on devboards with each new generation and only use them for ~a couple years or so. So renting time on AWS is appealing because it's not depreciating capital and because they can be more flexible in how they adjust spending to suit development cycle phases where they need more/fewer concurrent units.
Having freertos allows them to have credible experts in the space their customers are working in, and they can make design changes to freertos to suit this SDV concept.
[1] https://aws.amazon.com/automotive/software-defined-vehicle/
I never understood why they got it, when they already had Azure Sphere OS.
At least they are open sourcing it, instead of leaving it in some digital vault.
Azure Sphere OS is based on Linux, thus needs much more powerful hardware than ThreadX.
Having two OSes for the same space, even if ThreadX is less resource hungry makes marketing and developer support more complex.
They say they want to maintain the certifications - that will be tricky unless there's some investment coming from somewhere. It's a lot of fairly bureaucratic work to understand the safety standards, put the right development processes in place and maintain those as your software changes. It's not nearly as simple as just writing code and running it. It's definitely not the kind of software development someone would do as a hobby. I hope Microsoft are going to fund some of that development effort.
Interestingly although FreeRTOS isn't safety certified, SAFERTOS (https://www.highintegritysystems.com/safertos/) is - which is a commercial implementation with the same APIs.
It was super light weight and quite nice to get stuff done. You call tx_thread_create or some such and then tx_malloc and so on and then they have tx queues and semaphores and mutexes and so on.
Neat to see it's still living on.
In our case we were doing real-time power/fan/thermal control loops so we needed control over when certain actions were happening and needed to be able to guarantee that we could sense a problem and then (within X ticks) issue commands to respond, or make the system safe to prevent damage.
Yes, that's called an RTOS.
The Azure branding makes little sense, beyond maybe that IoT things communicate with the cloud or something.
They already started up a competitor.
:(
(This is the RPi boot blob)
> Now, there is at least some hope that the Raspberry Pi Foundation might be able to get permission to release the source code for its version.
Indeed that would be something!
Opening up any GPU code, from any maker, invites patent lawsuits from competitors. And then the injunctions start flying.
I think though they're finally realized trying to charge people for drivers has made them a hated name & gotten them no where. GMA500 is a long awful wound on everyone & held Intel back from being much better at embedded than they could have been. Powervr has been one of those living embodiments of the phrase "expensive chips without good drivers are just expensive sand", or however it goes. So now this stuff hypothetically is going to start to be broadly usable (only on Linux underimited architrctures I guess? Since it's mostly binary blobs?).
> Broadcom when they developed the original Videocore firmware bought a licence for ThreadX from the writer. AIUI, a lifetime licence, it never expires. No royalties or anything like that. Raspberry Pi have modified that firmware many many times over the last 10 years, but no royalties to pay. Many years later the writer of ThreadX sold the thing to Microsoft.
So sounds like the RPi folks have a free hand over this firmware and they might be able to open it now?
Why?
It's very cool that ThreadX has been open sourced as it offers an additional battle tested and mature alternative to FreeRTOS for new projects. If they're able to get and maintain the various safety certifications for ThreadX under the Eclipse foundation, this could be game-changing in a very different space from the Pi. But in terms of reverse engineering or open sourcing the Raspberry Pi VideoCore blob, open source ThreadX is pretty much a non-event IMO.
It's one step closer to an open Pi firmware in some ways, but probably not a meaningful step.
"the Pi5 has a massively reduced firmware (as much as possible is moved to ARM/kernel space). It now does very little."
I did a quick search and came up empty. Does anybody have any more info about this?
I'm 95% sure that if AMD released their firmware and/or their drivers source code, NVidia wouldn't learn anything of value, they wrote the same stuff anyway. That's just sad \o/
It might not even be realistic that some jerk is going to search through 10 million lines of driver code looking for patent violations, but these are corporations we're talking about. They're twitchy when it comes to risk. So the source of insanity here is the broken patent system, isn't it? (I agree that while you get to write vaguely clever code, even specialized software dev is 99% perspiration.)
It died ~2011
It's really something I would only use for an extremely simple safety-critical device, one that absolutely needed Real Time.
Microsoft deserves praise and even adulation for this, but time will tell how well supported the project is. They have a good track record so I'm very optimistic, but this is going to require a lot of ongoing support. That shouldn't be and isn't on Microsoft alone now, but they may have to shoulder a larger burden while getting things moving.
Many projects seem to be ditched by corporations and kind of orphaned in Eclipse and Apache
I'm assuming that every dev ends up consumed by endless rewrites of the Azure client libraries.
Example.
In file threadx-master/ports/cortex_a7/gnu/src/tx_thread_schedule.S
in this code
/* Increment the run count for this thread. */
LDR r2, [r0, #4] // Pickup run counter
LDR r3, [r0, #24] // Pickup time-slice for this thread
ADD r2, r2, #1 // Increment thread run-counter
STR r2, [r0, #4] // Store the new run counter
But it can be made it easier, with another layer and macro preprocessing. So make a header one for the assembly and one for the C code, and define the struct with the macro. The assembly code can be compiled with C preprocessor, so the macros will work.
This way the C and the ASM stay sync. Only drawback, that the struct must be defined with this macros. But this is only for the structures that are used both in assembly and C or higher level.
Anyway if the indexes in the assembly code would be macros, that would be also much easier to modify.
At the end of the day, I end up often using microchip studio because that is my board and it just works nicely. However, I have tons of tiny personal projects I'll spin up with vscode and platformIO and knock stuff out. Heck, even when I was merely playing around with it, I was able to FOSS my way to building and sending everything with various software.
I cannot imagine embedded pre ardunio. You'd think it would have created a scarcity of workers.
That made it a useful market to be in (as a developer.) My first embedded task was on a PDP 11/23 sans OS (despite the fact that DEC had suitable RTOSs like RSX-11M)
The development experience was miserable. The embedded code was in C, and, when something went wrong, there was about a 50% chance that the bug was in the proprietary compiler from the vendor and not in the C code at all.
There was probably some way to debug the live system, but I never found it. I’m not sure where was any way to simulate the system well enough to run our code short of actually uploading it to the device.
The world has come a long way :). An RPi or Arduino or anything else along those lines would likely also survive the treatment we gave this thing as long as all the connectors were very well secured.
https://github.com/azure-rtos/threadx/blob/master/LICENSE.tx...
https://github.com/azure-rtos/threadx/blob/master/LICENSED-H...
This is out of date; the announcement was only days ago, which is why I wrote TFA, and they've not updated the licence files on Github yet.
Right ?
Either way, Microsoft can afford to do that if they want to. But I would (naively) expect the rules to apply to anyone who wants to modify the code base, I don't think Microsoft has any privileged position when it comes to that.
There's genuinely good parts of the standards, but a lot of the rituals are just checklist items to assure certification authorities you have a defined process similar to what they've seen before, regardless of whether that's actually effective at issue reduction/detection. In many cases, they're actually counterproductive and encourage people to focus on minute, obscure error sources rather than addressing significantly more common issues like memory safety and undefined behavior.
That said, I'm surprised you've never encountered issues with people e.g. not understanding how serious UB is vs other types of issues in C-family languages. That's fairly universal even among developers from what I've seen.
This is incorrect. Microsoft does not have free license to change the code and retain certification.
The certification is handled by a separate entity. The certification rules apply to contributions from everyone, including Microsoft.
Raspberry Pi is probably one of the less notable users.
This news about Azure RTOS has been posted to HN a few times over the last week or so, even once by me, but I didn't realize you had to put "Raspberry Pi" in the headline to get traction.
> I didn't realize you had to put "Raspberry Pi" in the headline to get traction.
Yes, this was my theory. I was guessing most people hadn't heard of ThreadX and didn't know what it was or that it was used in devices they already owned. That is the sort of info that gets stuff read and shared.
I know of ThreadX and its use in the Pi was why. I noted that most of the existing coverage of the move to FOSS didn't mention it, and realised that the writers didn't know. That's why I wrote the article.
This is something that always irked me about RPi's. How the fuck, you, the hardware vendor, that's suppose to know the inner guts of your product, do not have full production for its software? That you need it to rely on undisclosed 3rd party blobs!! Yes, yes, I know about the politics and the business logic that led to this situation but that was at beginning, when money were need it. Nowadays they are in a good place in that regard, might wanna pivot so they fully control everything, but I guess once you go with a bad design, the complacent around that just grows.
Custom silicon is hard and few would accept significant a step down in raw power compared to the previous generation while the transition occurs.
> RPi foundation could probably have their own SoC made at this point
"Could have"? The RP2040 chip in the Pi Pico is their own silicon. The RP1 "south bridge" chip in the new Pi 5 is also their own silicon.
https://www.theregister.com/2021/01/21/pi_pico/
This is nothing new. They've been doing it since 2016-2018.
"Every once in a while, a revolutionary product comes along that changes everything" - steve jobs announcing the iPhone in 2007
Like running a sample on a supported board with Zephyr is pretty trivial. With ThreadX it seems to be included in the vendor sdk much like freertos might be. Some pros and cons to each certainly.
> A corresponding open source project has not yet been created
(via https://news.ycombinator.com/item?id=38445039, but we merged that thread hither)
[1] https://www.investopedia.com/news/blackberry-shares-jump-mic...
Very interesting factoid - I had no idea.
Or "open sourcing" with money and commitment and developers behind it?
Could they run, say, Doom?
Define "very recently". It was nearly 5Y ago now. I'd not call that very recent, no.
This publication was literally founded by a boomer, so I don't think your conclusory whining is particularly well-targeted.
Anyway, I wrote this version and I did explain what an RTOS is. I think the other submission used to link to the Eclipse announcement, and they didn't. (A bad sign.)
A foundation so bureaucratic that there is OSS that new people can't take over because it requires years of bureaucratic process.
How it something OSS if you cannot fork?
Seems like it's a win-win. If there's a group that can't abide whatever constraints exist with Eclipse, then they can fork. If not, it's still better off being open than not. I don't really see a downside here.