I really wish I didn't have to do this publicly, but unfortunately I have been left with no other choice.
If you are running MorphOS on your X5000, and you would like to continue to do so, then you should not upgrade your X5000 firmware to anything released after 2019 unless it was released directly by me. As of time of writing, the latest X5000 firmware that is supported by MorphOS has the following version string:
Quote:
U-Boot molsen-2018-10-05 (Oct 05 2018 - 17:02:05)
Installing an unsupported firmware version may result in failure to boot, unpredictable instabilities and/or data loss.I will update this post and add more information at the bottom should a newer firmware version which MorphOS supports be released.
---
I believe that Trevor Dickinson refers to ExecSG as his project personally and not related to A-Eon or anything else. I don't know the exact structure of the ownership or the development, but in this post I'm gonna refer to "The ExecSG Team" to mean Trevor Dickinson and whoever is working on the ExecSG source code, including Steven Solie.
I've been aware of The ExecSG Team's intent to modify and distribute a new version of U-Boot for the X5000 since April 2020, where I was contacted by Trevor Dickinson and asked for a copy of the U-Boot source code for the X5000, for the explicit purpose of making changes to it related to ExecSG. At that point already the alarm bells were going off. Being familiar with U-Boot, and knowing what the number one promised feature of ExecSG was, I was immediately thinking that the changes they wanted to make were related to supporting more than one CPU core.
U-Boot already has existing code that resets and brings up the non-boot cores on the CPU that's used in the X5000, and even an interface that allows you to direct the control of non-boot cores from the command line in U-Boot. It was my guess that The ExecSG Team was planning on modifying this code and somehow integrate it with ExecSG. The problem is that doing it this way is the entirely wrong way to go about it, on both fronts.
The firmware is supposed to be a generic and agnostic piece of software that does not care what kernel or operating system you ultimately boot. It merely brings up the hardware, loads the next program to be run, and passes on enough information to the loaded program for it to successfully take over control of the machine from the firmware. The firmware usually, and in the case of U-Boot, also presents a sort of guarantee, a contract with the program it loads, about how the program is called, and how the program can call functions in, and retrieve information from, U-Boot. This is a combination of ABI and API. What's guaranteed by this "contract" is what the loaded program can use and do. Anything outside of that there's no guarantee about, and it's very likely to break.
Now, I have previously observed The ExecSG Team completely ignore this ABI and API contract and do things that have caused problems in the past, and will probably continue to cause problems in the future. For example U-Boot has an API call to enumerate and retrieve all the U-Boot environment variables at boot time. If your operating system needs to know the contents of any such variable, it needs to use this API to retrieve and copy every environment variable, and do so before it takes over the system from U-Boot. ExecSG does not do this. It instead relies on U-Boot storing its environment variables in a specific place on the firmware SD card, and in a specific binary format. This breaks if the environment variables move, or if U-Boot changes its internal binary format for environment variable storage. If you adhere to the ABI and API contract, your access to U-Boot environment variables will continue to work. If you hack and make invalid assumptions about U-Boot, then things will break. ExecSG does the latter.
Supporting multiple CPUs or CPU cores in your OS is not an entirely light weight task. However, it's also not an insurmountable task. Just to give some background: I'm sure most of you are aware of my efforts to port MorphOS to, and run MorphOS on, AMD64 hardware. To this end, I ended up writing a new kernel from scratch. However, this new kernel was actually first written for PowerPC before later being ported to AMD64. The main PowerPC hardware I developed this kernel on is actually the X5000. When run on the X5000, this kernel runs natively in 64 bit mode and it supports SMP. It already boots and runs both (or all four, depending on the CPU) cores of the X5000. Just to clarify, though, these extra cores are not available inside the ABox. That's a whole other can of worms that's for another time.
Now, in order to support using multiple CPUs or CPU cores in your OS in a remotely reasonable fashion, you need a minimum amount of infrastructure in your kernel. You need a way to communicate between CPU cores, basically. Now once you have that code, you're also 90% of the way there to being able to reset and take over a CPU core from scratch. Actually all that's needed from there on is resetting the CPU core and then bringing the CPU core from its initial boot state to a state that's consistent with your kernel. Resetting the CPU core happens pretty much the same way you communicate with it normally, so that code already exists. What remains then is bringing the CPU core from its initial state to your desired kernel state, which can be a bit tricky, but not super complicated. And what's more, no matter if you decided to do this in a reasonable fashion or not, 90% of that work is also the same.
So that leaves us with... Is The ExecSG Team doing this in a reasonable fashion? Well, I don't actually know for sure. But all evidence points to "no". What I guessed back in April, and what seems to be sort of confirmed now, is that The ExecSG Team instead opted to modify U-Boot to redirect its already booted CPU cores to run code in ExecSG, without having to actually add the code to support multiple cores inside ExecSG itself. Now, let it be said that you
can actually do this, and you
can actually do it in a way that doesn't cause any problems. However, given that it's already a fact that The ExecSG Team does not care about breaking compatibility with U-Boot, with itself or with anything else that might run on the system, and given that there's very little difference in the amount of effort required to support multiple CPU cores in a reasonable fashion and then in this U-Boot hacky way, and that it looks like they chose the hacky way anyway, I have no faith that these U-Boot changes have been made in a competent fashion with care taken to make sure that there are no unintended side effects, and that's why I'm issuing this warning today.
The reason I'm issuing this warning publicly is that when I predicted that exactly this would happen back in April, I offered my support to Trevor Dickinson. I offered to consult on their U-Boot changes, to help them make whatever changes they needed, and to make sure that things were done in a proper fashion and wouldn't cause any problems for MorphOS. I did this several times over a long time frame, but my offer was rejected every time. I'm gonna include in this post quotes from some of the emails I sent to The ExecSG Team on this topic. Here is what I replied to Trevor on 2020/04/18:
Quote:
Sure, of course you can have the source code. But please let me preface it by mentioning that, without knowing the specifics, if you need to make changes to the firmware for ExecSG, then likely something is being done in a wrong way, and a way that's likely to cause problems for other things now or in the future.
If you're willing to share what changes you're planning to make, then maybe I could give my opinion on if said changes would cause problems and if maybe there is a better way to do it.
This was ignored, and later I was asked to assist Steven Solie in compiling U-Boot, to which I replied on 2020/05/08:
Quote:
Well, I'm still stuck a bit between a rock and a hard place on this one. So far nobody has been willing to tell me what it is Steven wants to actually change in U-Boot, and the original explanation I got that it was needed to "make a few minor changes for ExecSG", which as I stated in an original mail made alarm bells go off, because the list of legitimate changes you could make to U-Boot for ExecSG is exceedingly small, and the list of changes you could make that should absolutely in no way be in U-Boot, and which would likely cause problems for Linux and MorphOS, and probably even Amiga OS 4 too, is almost infinitely long, and even if it is a legitimate change that's required, it's very easy to implement it wrongly as well.
So the thing is that I'm a bit wary of spending my time coaching Steven on how to set up a U-Boot development environment, then once it's done hear nothing more, to then find out later that a new X5000 firmware has been released which can no longer boot MorphOS.
I'm not trying to be hostile here, I'm merely trying to avoid both current and future headaches for me, Frank and MorphOS users, and to do that, I really need to know what the plan here is.
This pleading was unfortunately also ignored.
Then in a reply to Steven, I wrote also on 2020/05/08:
Quote:
As I mentioned to Trevor, and as included in the quoted part of your email, I'd really like to hear what kind of changes you're planning to make. What I heard was that you needed to make changes in U-Boot for ExecSG, which immediately threw up some red flags here, so I hope you can appreciate that I'd like to make sure that I don't end up creating more problems and work down the line for me, other MorphOS team members or MorphOS users.
Which was also ignored.
I then got another email from Trevor, indicating that The ExecSG Team had compiled U-Boot, but that it didn't work. I replied to that on 2020/05/22:
Quote:
The source code I supplied is in a fully working state - I built and tested a U-Boot binary based on it to make sure everything was in order.
Are you sure you still don't want to tell me what changes you're planning to do?
To which I actually got a reply! However, the reply was that they wanted to make changes that at first might sound like it was related to U-Boot, but which were actually to things outside of U-Boot. Thus if the stated changes they wanted to make was true, then they wouldn't actually include any changes to U-Boot, as none of those things were contained inside U-Boot.
So to attempt one more time to find out what changes they were planning to make to U-Boot, I wrote this to Steven Solie on 2020/05/24:
Quote:
Seems like you're in luck here. U-Boot doesn't contain any device tree for Linux - it is loaded externally, and since U-Boot doesn't contain any device tree, I can only assume the same is true for any BSD variant. The FMan firmware can be replaced without compiling U-Boot. In fact it is not part of the U-Boot build at all.
What about the changes for ExecSG, what are you planning there?
To which I got a reply telling me that now there was plans to change U-Boot for ExecSG, contradicting what I had been told earlier.
Then on 2020/06/17, I got another email from Trevor requesting help with compiling U-Boot, which I replied to on 2020/06/18:
Quote:
Again, let me reiterate that I'm not imagining that anyone of you will intentionally try to sabotage MorphOS support. However, it is very, very easy to *INADVERTENTLY* cause problems in a component as central and important as the firmware, problems that might not even appear obvious at a first glance, which is what there's a high likelihood will happen. With a team full of people who can't even compile U-Boot, it does not instil much confidence in me that said team will always make the right decisions when it comes to making changes to the firmware.
Now I mean no harm with the following, but my patience really is wearing thin. From my point of view, it has not exactly been a pleasant experience to be asked for help, but also having to go through 5 or more iterations of email ping pong, asking for some very basic info on what it is you need the help for, only to be seemingly taken for a fool with a string of replies that did not answer that one simple question, then eventually getting a reply that seems to be entirely made up and which certainly doesn't sound truthful to me, and now you're pretty much contradicting said reply in the quote above.
Following that, and giving up on ever getting The ExecSG Team to ever admit to what they wanted to change, I offered to Trevor that I, for a fee, could set up a virtual machine image and give him instructions on how to use the virtual machine image, and how to use it to compile U-Boot, which he accepted. I did that, sent him the data and documentation and that was the last I heard about this till I was made aware that there had been
a public presentation done on ExecSG, which included the tidbit of information that ExecSG now supports multiple cores, but for this to work, it required an updated copy of U-Boot. This piece of information confirmed to me that The ExecSG Team had decided to add support for using multiple cores in the non-reasonable fashion outlined above, and that's why I'm writing this post today.
I rarely log in to MorphZone which means that I often miss private messages sent on here. If you wish to contact me, please email me at [username]@asgaard.morphos-team.net, where [username] is my username here on MorphZone.
