I'm not gonna be angry at false advertising, but OS attempts only become appropriate to discuss once you made drivers and actually ran stuff on physical hardware
Before that point it's just one of the many dozens and dozens other half-efforted attempts at OS that have been done over and over to death by now
Well, given that it’s built on FreeRTOS, this stuff should be fairly cheap to implement. I think you’re being a little overly critical for an early stage project that fills an interesting niche (GUI OS for MCUs).
Fair, but that’s still probably easier than building for all the various targets from scratch. And people said ARM SBC boards were a mess, lol! (They were/are but the ESP “platform” is even less coherent. Thank you to the people doing the heavy lifting here.)
> Olimex esp32-p4-pc, the flagship product: new, powerful
That's a very cool board, but pretty tricky. Great idea to run an old Mac OS on it. I try on and off to port the Oberon System 3 to this board since I received it in February. The display already works pretty good, but still a lot of road blocks.
Hi, Could you say a few words what makes this board tricky? I've wanted to get one for a similar reason as the OP, although I'm thinking a scheme-like VM with GUI.
There were dozens of pretty complex challenges, too many to describe here. So just a few examples. First of all, I'm fully bare-metal, with no ESP-IDF (though I use it for studying). A major annoyance is the USB-JTAG flapping which is the same on both board copies and different hosts; so debugging is even more difficult; partly worked around by logging via additional TTL UART connection. It's worse right after power-on and after EN pulses, then stabilizes for ~tens of minutes; could be thermal/supply settling, or simply the burst of re-enumerations any reset causes. Then the LT8912B I2C is shared with HDMI DDC; a lot of time went to find the right drive strength so the LT inits with the cable is in. Also a couple of rev v1.0 silicon issues, e.g two-step cache writeback, dead GPSPI clock, etc. For the display, the Olimex demo was very helpful; dumping all DSI/bridge/GDMA/clock registers over JTAG became an important debugging tool. Now the SD card and display work more or less. Right now, I'm really struggling with the USB keyboard, which is a low-speed device behind the onboard FE1.1s hub; both ways of reaching it fail identically with a bare chhltd and no cause bit.
I'm using my OP2 Oberon compiler version and also my Micron compiler, and both indeed just need a few seconds for the build of the whole Oberon or Micron System 3 and only a few megabytes of source code. Version 6 of IDF didn't even work on my host.
Claude managed to get idf v6 to work in a docker container, but I've ripped that out now. would you say that most of the issues you had with the p4 was the board, rather than the underlying cpu? the one I have in mind is more this sort of thing: https://www.aliexpress.com/item/1005009278783008.html (as opposed to a SBC like the rpi).
> would you say that most of the issues you had with the p4 was the board
Both. The USB-JTAG flapping is probably a board issue, as is the HDMI integration; and they use the 1.0 version of the P4 which also has its issues. Your link doesn't work from my location, and I don't have experience with other P4 versions so far.
Thanks, I hope I'll be able to get it done in a timely manner. Currently I have to decompose the statically linked inner core because it doesn't fit into the dedicated memory slot anymore. Did you also have issues with the ttyACM0 connection which starts to drop regularly under certain conditions?
It's indeed amazing that these MCUs essentially correspond to or even exceed the performance of the original Ceres systems in the nineties. The Oberon System and also the later AOS/Bluebottle multi core system are particularly suited for today's MCUs because they don't assume an MMU.
Oh, I’m not the developer of this, I just follow these sorts of projects because I’m interested in alternative OSes and particularly OSes that run under constrained environments. I haven’t personally tested it. There’s several of these under development now, as well as many emulators; the ESP CYD (and clones) seems to be a favored target.
If it's running on MMU-less systems, I'd be interested in how it loads multiple programs into memory: does it need to relocate each program binary? If so, doesn't that preclude using execute-in-place (XIP)?
"COM" programs as seen in MS DOS and earlier CP/M systems contain only relative addresses, and can run from any "segment" of RAM, as the addresses are relative to the value of a segment register. This was used to load "background" services, typically servicing hardware devices.
MCUs with MMUs are starting to appear, such as the ESP32-S31.
Generally, running in a MMU without static task config would require relocatable binaries. I'm not sure why it'd preclude execute-in-place. As a relocatable binary should be executable from generally any address space. However I suspect that hardware without an MMU is not super likely to be able to support XIP.
It is based on FreeRTOS, so it should be fairly well documented.
> I suspect that hardware without an MMU is not super likely to be able to support XIP.
This seems strange to me. Don't most microcontrollers support executing directly from flash? Some even can't execute from RAM.
Though I agree with the main point, you can compile code as "PIC" - position independent code, and not bother with (ELF) relocations except for linking.
> On top of that, Sylphide OS adds:
> drivers for mouse, keyboard, display, storage and network
and couple lines later
> What you don't have yet, but definitely planned:
> storage (microsd, usb) > network (ethernet, wifi)
I'm not gonna be angry at false advertising, but OS attempts only become appropriate to discuss once you made drivers and actually ran stuff on physical hardware
Before that point it's just one of the many dozens and dozens other half-efforted attempts at OS that have been done over and over to death by now
Well, given that it’s built on FreeRTOS, this stuff should be fairly cheap to implement. I think you’re being a little overly critical for an early stage project that fills an interesting niche (GUI OS for MCUs).
It's so platform dependent though, for many FreeRTOS targets I think you're just gonna be integrating against a vendor specific stack
Fair, but that’s still probably easier than building for all the various targets from scratch. And people said ARM SBC boards were a mess, lol! (They were/are but the ESP “platform” is even less coherent. Thank you to the people doing the heavy lifting here.)
> you’re being a little overly critical for an early stage project
no, I'm exactly critical *because* it is early-stage
"early-stage OSes" are dime a dozen, just as ideas without code they are worth nothing.
> Olimex esp32-p4-pc, the flagship product: new, powerful
That's a very cool board, but pretty tricky. Great idea to run an old Mac OS on it. I try on and off to port the Oberon System 3 to this board since I received it in February. The display already works pretty good, but still a lot of road blocks.
Hi, Could you say a few words what makes this board tricky? I've wanted to get one for a similar reason as the OP, although I'm thinking a scheme-like VM with GUI.
There were dozens of pretty complex challenges, too many to describe here. So just a few examples. First of all, I'm fully bare-metal, with no ESP-IDF (though I use it for studying). A major annoyance is the USB-JTAG flapping which is the same on both board copies and different hosts; so debugging is even more difficult; partly worked around by logging via additional TTL UART connection. It's worse right after power-on and after EN pulses, then stabilizes for ~tens of minutes; could be thermal/supply settling, or simply the burst of re-enumerations any reset causes. Then the LT8912B I2C is shared with HDMI DDC; a lot of time went to find the right drive strength so the LT inits with the cable is in. Also a couple of rev v1.0 silicon issues, e.g two-step cache writeback, dead GPSPI clock, etc. For the display, the Olimex demo was very helpful; dumping all DSI/bridge/GDMA/clock registers over JTAG became an important debugging tool. Now the SD card and display work more or less. Right now, I'm really struggling with the USB keyboard, which is a low-speed device behind the onboard FE1.1s hub; both ways of reaching it fail identically with a bare chhltd and no cause bit.
Thanks! I too am going baremetal, as I prefer 5 second builds to 45 minutes - but yes the board sounds like a bit of a pain...
And that was only the summary of a selection ;-)
I'm using my OP2 Oberon compiler version and also my Micron compiler, and both indeed just need a few seconds for the build of the whole Oberon or Micron System 3 and only a few megabytes of source code. Version 6 of IDF didn't even work on my host.
Claude managed to get idf v6 to work in a docker container, but I've ripped that out now. would you say that most of the issues you had with the p4 was the board, rather than the underlying cpu? the one I have in mind is more this sort of thing: https://www.aliexpress.com/item/1005009278783008.html (as opposed to a SBC like the rpi).
> would you say that most of the issues you had with the p4 was the board
Both. The USB-JTAG flapping is probably a board issue, as is the HDMI integration; and they use the 1.0 version of the P4 which also has its issues. Your link doesn't work from my location, and I don't have experience with other P4 versions so far.
Oberon would be a great fit for this board, your efforts are appreciated.
It’s amazing how these inexpensive “MCUs” (not even sure you can call them that) are overtaking old PCs now.
Thanks, I hope I'll be able to get it done in a timely manner. Currently I have to decompose the statically linked inner core because it doesn't fit into the dedicated memory slot anymore. Did you also have issues with the ttyACM0 connection which starts to drop regularly under certain conditions?
It's indeed amazing that these MCUs essentially correspond to or even exceed the performance of the original Ceres systems in the nineties. The Oberon System and also the later AOS/Bluebottle multi core system are particularly suited for today's MCUs because they don't assume an MMU.
Oh, I’m not the developer of this, I just follow these sorts of projects because I’m interested in alternative OSes and particularly OSes that run under constrained environments. I haven’t personally tested it. There’s several of these under development now, as well as many emulators; the ESP CYD (and clones) seems to be a favored target.
If it's running on MMU-less systems, I'd be interested in how it loads multiple programs into memory: does it need to relocate each program binary? If so, doesn't that preclude using execute-in-place (XIP)?
"COM" programs as seen in MS DOS and earlier CP/M systems contain only relative addresses, and can run from any "segment" of RAM, as the addresses are relative to the value of a segment register. This was used to load "background" services, typically servicing hardware devices.
MCUs with MMUs are starting to appear, such as the ESP32-S31.
Generally, running in a MMU without static task config would require relocatable binaries. I'm not sure why it'd preclude execute-in-place. As a relocatable binary should be executable from generally any address space. However I suspect that hardware without an MMU is not super likely to be able to support XIP.
It is based on FreeRTOS, so it should be fairly well documented.
> I suspect that hardware without an MMU is not super likely to be able to support XIP.
This seems strange to me. Don't most microcontrollers support executing directly from flash? Some even can't execute from RAM.
Though I agree with the main point, you can compile code as "PIC" - position independent code, and not bother with (ELF) relocations except for linking.
> Don't most microcontrollers support executing directly from flash?
Yes... I presume they meant XIP for multiple programs at once, since you'd need an MMU for that.
> since you'd need an MMU for that.
Or PIC code... PalmOS 5 & 6 allowed multiple programs in same memory and they were simply compiled pic. MMU was not used
Some architectures (ARM, RISCV, aarch64) are well suited for this kind of code. Others are extremely poorly suited (x86, MIPS), but all CAN do it
Or the program use relative addressing.
On one hand: Cool!
On the other hand: I have a lot of old hardware in my 'too good to go' garbage bin that can run a full fledged Linux, so what.
[flagged]
[flagged]