This was "Azure RTOS", bought by Microsoft in haste after Amazon acquired FreeRTOS.
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.
My belief is that Amazon sees IoT as a way to further grow AWS backend services. All those nodes need a cloud, somewhere.
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.
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.
Amazon is heavily marketing AWS ro automotive R&D teams. They want them to run their software on Graviton nodes for near-hw performance. And they have virtio-everything interfaces for you to use so your core functionality can be tested in AWS and you have some kind of hypervisor to partition and/or abstract the real HW interfaces.
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.
that's really cool idea, but for such r&d local hardware/vm seems to be more ergonomic for attaching debugger and if you have to create such abstractions anyways, I'm not sure if dev board with second CPU or FPGA for hw emulation wouldn't be better way to handle it, as this would allow you to reuse same boats between generations
The development of ThreadX has nothing to do with all with RPi and VideoCore. It's a software component that was used to develop a larger architecture.
Is it like another Intel ME, phone modem firmware, etc? Absolutely!
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.
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.
> 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.
Linux was NEVER a fork of MINIX. That is just false. Linus developed Linux in response to the experience he had with MINIX - but there is no MINIX code in Linux and never was.
"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."
"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."
I was there. I watched Linux from the beginning, including the minix-list discussions.
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:
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.
If the planet was covered in Alexa devices and Dash buttons I'd say maybe. But even Amazon knows IoT node hardware is a sucker's game. Unless you have a highly vertical application that you can charge customers for, it's a market none of the FAANGs will touch.
Not sure your point. For me at least, it's about FreeRTOS's freedom and not being mangled by some megacorp since it's one of the few battle tested Firmware OSes out there.
The safety certifications are particularly interesting. It's a lot of work to develop "safe software" - that is software that is developed according to a safety standard and certified to a "safety integrity level". Having an RTOS which is both open source and safety certified is pretty great.
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.
Yes, that ongoing certification will be costly but they mention the support of companies with pretty deep pockets: "In addition to the project, we are also announcing the creation of an interest group focused on developing an industry-supported, sustainable funding model for ThreadX. We are excited that AMD, Cypherbridge, Microsoft, NXP, PX5, Renesas, ST Microelectronics, Silicon Labs, and Witekio (an Avnet company) have all committed to supporting this conversation"
This is huge. Automakers won’t touch something unless it is iso 26262, and it commands a 10x premium. It is very hard to functional safety right, and this compliance is a key component in enabling tier 2 manufacturers.
I really liked ThreadX when I was working with it a while ago. Calling it an "operating system" is charitable in the sense that it's an interrupt service routine and a bunch of functions to handle 'creating threads' and managing memory allocations.
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.
> I really liked ThreadX when I was working with it a while ago. Calling it an "operating system" is charitable in the sense that it's an interrupt service routine and a bunch of functions to handle 'creating threads' and managing memory allocations.
For those wondering why Azure has an RTOS, Microsoft bought Express Logic and their ThreadX RTOS in 2019. ThreadX is in use on a large number of resource constrained microcontrollers.
The Azure branding makes little sense, beyond maybe that IoT things communicate with the cloud or something.
I understand the notion here that opening up ThreadX will start to allow visibility into VideoCore, since ThreadX runs the thing. But an RTOS/scheduler is only a miniscule part of a GPU and since Broadcom never opens up anything, I believe it's a false hope.
Opening up any GPU code, from any maker, invites patent lawsuits from competitors. And then the injunctions start flying.
Having worked (very) closely on GPU firmwares and drivers, I always find it funny that it is still something so closely guarded and protected. Honestly there isn't much to it. That's fairly regular code, not like futuristic algorithms. You won't find any novel rasterizing code or ways to order your commands or whatever, 99% of the interesting work is done by the GPU. You'll find basic or vaguely clever code to order lists and optimize the order of the commands, but that's it.
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/
This is really just the modern patent regime at work, isn't it? Any random problem a chip company SE or EE can solve in an afternoon can get that solution whisked past an overworked patent examiner. Now open-sourcing your basic code to "optimize the order of the commands" opens your company up to a hojillion-dollar lawsuit from a patent troll or any competitor that feels like going nuclear. Maybe the patent is BS but it'll take a multi-million-dollar lawsuit to prove it.
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.)
I was going to point out that Linux 6.8 seems on target to be shipping pretty decent powervr drivers, but yeah, probably a huge massive chunk of the magic is in the firmware blob, which is closed as heck as usual for this industry. Both drivers & boob very recently dropped: https://www.phoronix.com/news/PowerVR-Firmware-Blob
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 never opens up anything". True, but from a link in the related article from The Guardian [0]
> 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?
ThreadX is just the scheduler / OS functionality. There are tons of other components in the firmware (namely, the parts that actually do things) which are still encumbered by patent and copyright issues, not to mention the DRM modules which are somewhat security-by-obscurity based.
It's one step closer to an open Pi firmware in some ways, but probably not a meaningful step.
Sure, and it's been done: https://github.com/christinaa/rpi-open-firmware - but that doesn't involve ThreadX source, just some standard reverse engineering work. ThreadX is really the least interesting part of this whole operation in terms of the Raspberry Pi.
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.
Wow, ThreadX. To quote Obi-wan, "That's a name I've not heard in a long time". I last worked on a ThreadX based product about 20 years ago. It was annoying because our application device did not require Real Time scheduling, or a particularly fast boot, but the decision to go with ThreadX rather than, say, embedded Linux was made way over my Junior head. We even had a separate "higher end" product that ran embedded Linux, which was a joy to work with, so it's not like we didn't think Linux would work. Everything we ended up doing on that product took 2X to 3X as long to develop, debug, and test because a lot of the niceties that you come to rely on from a kernel simply didn't exist with ThreadX.
It's really something I would only use for an extremely simple safety-critical device, one that absolutely needed Real Time.
This is indeed a major deal, and having the Eclipse Foundation shepherd it is wonderful.
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.
A _lot_ of Microsoft's open source projects are basically ghost towns. EF core and the SQL server driver appear to be maybe a handful of people, and there is a disturbing amount of "the only person who understood this is gone so we can't fix it.". Get into some of the more esoteric projects and you're lucky if there's someone dropping in to accept a PR once a year.
I'm assuming that every dev ends up consumed by endless rewrites of the Azure client libraries.
Yeah...I'd love a blow by blow on Eclipse, my (joking) understanding prior to this article was it was an IDE open source project that grew so unwieldly/abandoned that some combo of JetBrains & Google was able to co-opt it and end up owning it entirely.
My view that, this code is nice, however IMO there are several ways to make it more portable, and programer friendly, specially the ported assembly code part.
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
the indexes to the data structures are really hard to modify, so you can't make modifications to the structures easy, the C structures and the assembly code indexes must be in sync, or the system will crash. And there are literally 100s of files with assembly indexes in the code.
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.
It's a fine RTOS, at least it was when I was working on Deskjet firmware. At the time the open source OSes and especially the tooling really wasn't up to the task. Things really have changed though, now there are alternatives.
The progress the embedded world has made on FOSS has been incredible. I started in like 2016 or 2017(ignoring the ~8 years I played with Arduino).
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.
One of my first projects was an embedded thing, long before 2016, where the number of deployments was exactly one. (It was a ruggedized device embedded into an experiment that we literally dropped from an eight story building twice a day. The device in question did just fine, although, unsurprisingly, a bunch of the rest of the apparatus needed rather regular repairs.)
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.
> 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)
Is it me or certification is a very powerful way to keep control on the open sourced code ? I mean it's open so you can modify it but as soon as you touch one line, you can't claim the certification anymore... Therefore only MSFT has the ability to change the code (because I suppose they don't have to re-do the whole certification); until another big player gets the certification.
Not really. It's pretty rare to use an RTOS without making _some_ modifications and it's intertwined with your application anyways. If you need certification, you're going to have to get it for the combined app/RTOS/RTOS-modifications anyways. And you're in better shape starting from a base that you know passes certification.
Yes! There are some industries that will not tolerate seat-of-the-pants development. Functional safety requirements make a nice tall fence to keep out risky developers. Which is why china automakers have no such regulations.
Sorry to burst your bubble, but FuSa dev teams are often full of "risky developers" who frankly shouldn't be within mile of any codebase your life depends on. You can only hope the safety culture and tooling keeps them in check.
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.
Thanks for your insight! As someone who has lead FuSa certification on multiple automotive products, I can’t disagree with you more. But maybe you just had a bad experience.
I've also led the process at multiple companies. It's a big enough space that there's definitely room for different experiences, even within the same companies.
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.
I think you might be confusing software standards with functional safety standards. They are related, but one is required by the other. FuSa from my role has been predominantly architecture and process. Developers do need to follow coding and documentation guidelines. If they are fighting that then there are bigger problems with leadership.
It's one of the [major] hazards you have to deal with in FuSa software systems, so I'd say it goes under both. So much of 26262-6 is about limiting the scope of those those sorts of issues that just waving it away as a prerequisite ends up being neither practical nor realistic.
My understanding is you need to re-certify in some form upon changing anything about the code. I'm not sure if it's the same process each time or if you can do some kind of incremental re-certification for minor updates.
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.
But it makes RPi fans perk up their ears because it's part of the GPU blob that they still haven't been able to reverse-engineer.
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.
Yes, it is. I wonder why. There is nothing factually inaccurate or anything here.
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.
Quote: " 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"
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.
Getting downvoted because nobody took the time to read your post, I assume. RPi foundation could probably have their own SoC made at this point, and (finally) having fully open firmware would be a huge selling point and maybe help stave off the clones. So why don't they do that?
They almost certainly cannot afford to do that at the prices they are selling these things for. I'm also not entirely certain a large enough fraction of their customer base cares enough for them to take action here. They are likely doing the practical thing that makes the most sense.
Designing / building an entire modern(ish) SoC is an order of magnitude different than building a microcontroller (or even something as ambitious as RP1)—I don't think it's impossible for Raspberry Pi someday, but certainly not at their current size / staffing!
Zephyr is a lot more complicated than ThreadX and has been trying to get safety certified for many years now. It does have a really nice testing and board package story though, along with many other features ThreadX doesn't have.
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.
It’s pretty easy and convenient to get running, but it’s mostly written by students - so core components are left unmaintained once their authors graduate to other things.
How QNX plays in all this picture/benchmark? [1] I understand this is a different RTOS but do we expect Microsoft to open source QNX as well or because it was the cash cow of the sector they will wait? QNX has several licensing options.
> [ThreadX firmware binary] runs on the Pi's VideoCore GPU. This is the primary device, the part that boots up the Pi and controls its hardware: the Arm cores are slave devices to the VideoCore GPU.
It'll be really interesting to see how this shakes out in terms of other open rtos projects given a safety certified RTOS is now available under a nice license with wide architecture support.
It took a lot of reading of that blogpost before I realized that it was about an operating system. I seriously thought it was about some parallel threading standard. Especially for a broad announcement like that, they should give readers some more context.
AFAICT these comments are from a merged submission of a different link. If I may say so, @dang, that's a bad idea: if it is same URL then merge it, but if it's different coverage then don't. IMHO.
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.)
It's also accepted publishing standards to expand an acronym the first time it is used. Of course, kids today don't know what standards are because a boomer made them or some such nonsense excuse for just I do what I want
The first two uses of the term are part of product names, not uses of the term itself. They almost immediately explain the acronym in the next paragraph, and give alert readers a tremendous hint in the very first sentence. I think they did a perfectly acceptable job of providing context here.
This publication was literally founded by a boomer, so I don't think your conclusory whining is particularly well-targeted.
According to the article the software is MIT licenced - one of the most permissive licences available. The Eclipse Foundation is an unusual choice, but amyone can use/modify or even fork this code if they want.
It will only rot if nobody wants to work on it. If Eclipse is horribly bureaucratic, then developers who don't want to participate in an Eclipse project may now fork it.
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.
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.