Important Notice regarding X5000 Firmware Updates
  • MorphOS Developer
    bigfoot
    Posts: 508 from 2003/4/11
    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.
  • »28.10.20 - 18:19
    Profile Visit Website
  • Priest of the Order of the Butterfly
    Priest of the Order of the Butterfly
    KennyR
    Posts: 868 from 2003/3/4
    From: #AmigaZeux, Gu...
    I'm frankly astonished you ever bothered to have anything to do with them in the first place.
  • »28.10.20 - 18:30
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    takemehomegrandma
    Posts: 2720 from 2003/2/24
    Wow...
    MorphOS is Amiga done right! :-)
    MorphOS NG will be AROS done right! :-)
  • »28.10.20 - 18:51
    Profile
  • rob
  • Acolyte of the Butterfly
    Acolyte of the Butterfly
    rob
    Posts: 139 from 2008/7/22
    I've posted a link to your post in the Amiwest show report thread on AW where Steve said he'd answer questions on ExecSG.
  • »28.10.20 - 18:51
    Profile
  • Butterfly
    Butterfly
    kas1e
    Posts: 97 from 2005/10/31
    I think they just do not know what they will do. I.e. there no plan, just wishes, and they tried to play with all the possible ideas till some of them will work by luck, position it after as "true only omg we did all correctly"
  • »28.10.20 - 20:44
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 12058 from 2003/5/22
    From: Germany
    > 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.

    Interesting. Thanks for the insight.

    > 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.

    Withering assessment.
  • »28.10.20 - 20:56
    Profile
  • Acolyte of the Butterfly
    Acolyte of the Butterfly
    TrevorDick
    Posts: 130 from 2005/10/12
    From: Wellington
    Mark,

    Not sure why you posted on a public forum but I can assure you that uboot firmware updates for the X5000 have not been circulated outside the ExecSG team.

    The excellent work you did for me on uboot helped the ExecSG team create a standard uboot build process. As I assured you at the time, I will ensure that any and all future uboot updates for the the X5000/20 and X5000/40 will support MorphOS. I have a vested interest since I run MorphOS on my X5000/20 :-)

    The ExecSG kernel work will not impact on MorphOS support.

    Trevor

    [ Edited by TrevorDick 29.10.2020 - 09:28 ]
  • »28.10.20 - 21:14
    Profile
  • Priest of the Order of the Butterfly
    Priest of the Order of the Butterfly
    Cool_amigaN
    Posts: 745 from 2011/11/30
    Tbh I think it's good for their userbase to be experimenting with different alternatives and approaches for such an important feature, even by taking (technically) the wrong path and perhaps ending up breaking other stuff. Vast majority of owners must have bought X5k for OS4, a tiny percentage for MorphOS (even if some users switched in between) and perhaps virtually no one for explicit linux desktop purpose. I don't think that even a fraction of OS4 X5k users would care if bringing SMP is being delivered with a "hacky" or technically competence way or if it leads to Linux or MorphOS installations stop working (which might have not even been installed to begin with), as long as such an important feature (cause it is important nonetheless) is present and actually works from user's pov. Well, at least I know I wouldn't give a damn if MorphOS x64 prevented Windows (or any other OS) from booting on latest Intel i7 :) Regarding MorphOS official support, can easily and formally be revoked if a non approved third party UBoot firmware is installed. It's a simple and clear statement, so any potential buyer/user can weight his final decision for purchase.
    Amiga gaming Tribute: Watch, rate, comment :)
  • »28.10.20 - 21:18
    Profile Visit Website
  • Priest of the Order of the Butterfly
    Priest of the Order of the Butterfly
    Crumb
    Posts: 730 from 2003/2/24
    From: aGaS & CUAZ Al...
    Knowing SSolie dirty tactics (remember the announcement of os4 laptop because MorphOS had recent PowerBook support or the os4 fanboys publishing news about random os4 sdl Game ports quickly after a MorphOS release to try to hide them?) it's no surprise. He's a MorphOS hater as shown in various forums, he came to troll here about MorphOS funding and other random stuff, he fought for controlling OS4 to end up stagnating OS4, he hoarded the Mozilla sources to avoid releasing them (thus violating the bounty agreement), but hey he has read very interesting books about project leadership so he's probably the best choice to put the last nail in the os4 coffin. I'm sad for all the efforts you put but it's better to stay away from os4 developers/managers and os4 hardware as both are toxic.

    [ Edited by Crumb 28.10.2020 - 22:21 ]
  • »28.10.20 - 21:20
    Profile Visit Website
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 12058 from 2003/5/22
    From: Germany
    > SSolie dirty tactics (remember the announcement of os4 laptop
    > because MorphOS had recent PowerBook support [...])

    If this was a "dirty tactics", it certainly wasn't SSolie's, who simply read out the announcement he was given by Ben Hermans. He made some stupid mistakes by doing so and it was easy to believe when he said he had no clue about what it was that he was reading out.

    > ([...] or the os4 fanboys publishing news about random os4 sdl
    > Game ports quickly after a MorphOS release to try to hide them?)

    How is that a "dirty tactics" of SSolie?

    > it's no surprise

    As I read bigfoot's story, SSolie was the one who actually revealed the reason to him.
  • »28.10.20 - 21:48
    Profile
  • MorphOS Developer
    Piru
    Posts: 575 from 2003/2/24
    From: finland, the l...
    Quote:

    TrevorDick wrote:
    Mark,

    Not sure why you posted on a public forum

    Probably because it would be too late to warn people if a broken firmware were to be installed. Since it is not known when such firmware might be released the warning had to come out now.

    Quote:

    As I assured you at the time, I will ensure that any and all future uboot updates for the the X5000/20 and X5000/40 will support MorphOS. ... The ExecSG kernel work will not impact on MorphOS support.


    I genuinely think you're a nice guy, but are you qualified to understand the finer details of firmware development? If yes, then I might have some more confidence in this statement. The incompetence of the ExecSG Team in around building the firmware suggests another scenario though: No one in the team has a clue what they're doing. While there likely is no malicious intent, it could well end up breaking the support by accident.

    Hence the warning.

    [ Edited by Piru 28.10.2020 - 23:55 ]
  • »28.10.20 - 21:53
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    amigadave
    Posts: 2793 from 2006/3/21
    From: Northern Calif...
    I like Trevor and truly believe that his intentions have been to help the "community", but I must totally agree with what Piru just wrote. There is no way that Trevor can guarantee that any work the ExecSG team releases won't break something else. Even extensive beta testing does not always reveal every problem in new work.
    MorphOS - The best Next Gen Amiga choice.
  • »28.10.20 - 23:25
    Profile
  • Acolyte of the Butterfly
    Acolyte of the Butterfly
    TrevorDick
    Posts: 130 from 2005/10/12
    From: Wellington
    Quote:

    Piru wrote:
    "I genuinely think you're a nice guy" Thanks :)

    >> but are you qualified to understand the finer details of firmware development<<

    Whether I'm qualified or not, I don't intend to approve the release of uboot firmware for A-EON's X5000/20 or X5000/40 systems which does not support the booting of MorphOS.

    I trust that is the end of the discussion.

    Trevor
  • »28.10.20 - 23:27
    Profile
  • ASiegel
    Posts: 1369 from 2003/2/15
    From: Central Europe
    I took the liberty of adding bold styling to a portion of Mark's post. Hopefully, this will make it clearer that this is about far more than the mere ability to somehow boot into the MorphOS desktop environment.
  • »29.10.20 - 07:56
    Profile
  • MorphOS Developer
    Piru
    Posts: 575 from 2003/2/24
    From: finland, the l...
    None of the answers seen (here or otherwise) actually address the concerns raised.

    As such the original statement stands: Do no upgrade the firmware to versions other than ones approved by bigfoot if you wish to be certain that MorphOS continues to work.
  • »29.10.20 - 09:36
    Profile
  • Cocoon
    Cocoon
    amigakit
    Posts: 43 from 2005/8/24
    A-EON Technology is not affiliated to the "ExecSG" team as Trevor has pointed out.

    The private branch of the firmware is used for testing and developing the ExecSG projects and has nothing to do with the consumer release of the firmware.

    The official X5000 firmware that is distributed on X5000 systems and board is the version that BigFoot has worked on for A-EON over some years.

    He is the official maintainer of the firmware for A-EON. A-EON is happy for this relationship to continue going forward and presumably BigFoot is too (his schedule permitting).
    www.amigakit.com - Amiga store
  • »29.10.20 - 13:17
    Profile Visit Website
  • MorphOS Developer
    Piru
    Posts: 575 from 2003/2/24
    From: finland, the l...
    Quote:

    amigakit wrote:
    The private branch of the firmware is used for testing and developing the ExecSG projects and has nothing to do with the consumer release of the firmware.


    I'm even more confused now. Does this mean that the firmware is only needed for development purposes and no new firmware update will be needed for end users?

    Even more confusingly the ExecSG presentation slides say:

    Quote:

    U-Boot and AmigaBoot updated to support multicore


    Some clarification is in order I think.
  • »29.10.20 - 13:33
    Profile
  • Cocoon
    Cocoon
    amigakit
    Posts: 43 from 2005/8/24
    Quote:

    I'm even more confused now. Does this mean that the firmware is only needed for development purposes and no new firmware update will be needed for end users?


    A-EON only distributes and releases official firmware which BigFoot is the maintainer. He took over from Varisys' contractor for A-EON quite some time ago. We were very happy that he could maintain the firmware and get the project back on track.

    I have no idea what happens in the ExecSG Team internally. Third party branches are not official updates and therefore are not distributed by A-EON or installed on A-EON consumer product when they go out of the door.
    www.amigakit.com - Amiga store
  • »29.10.20 - 13:41
    Profile Visit Website
  • MorphOS Developer
    Piru
    Posts: 575 from 2003/2/24
    From: finland, the l...
    Quote:

    amigakit wrote:
    Quote:

    I'm even more confused now. Does this mean that the firmware is only needed for development purposes and no new firmware update will be needed for end users?


    A-EON only distributes and releases official firmware which BigFoot is the maintainer. He took over from Varisys' contractor for A-EON quite some time ago. We were very happy that he could maintain the firmware and get the project back on track.

    I have no idea what happens in the ExecSG Team internally. Third party branches are not official updates and therefore are not distributed by A-EON or installed on A-EON consumer product when they go out of the door.



    Okay sounds good, except that it doesn't answer my question definitely. "Yes" or "no" would suffice.

    Also there is this statement from Steven Solie:
    Quote:

    The only U-Boot firmware you need comes directly from the board manufacturer (A-EON) and includes "aeon" in the version string. The new U-Boot will be released after beta testing has been completed.

    So there is something being beta tested that is supposed to be released. How come bigfoot is totally unaware what this new firmware does?

    My confusion remains.
  • »29.10.20 - 14:13
    Profile
  • MorphOS Developer
    Piru
    Posts: 575 from 2003/2/24
    From: finland, the l...
    Free hint: You guys (Trevor, Matthew & Steven, plus whoever else might be involved) should talk to each other first and agree on what you're actually doing and how, and how it will be communicated and by whom.

    Also: If you intend Bigfoot to be the gatekeeper of the firmware, then please please involve him in the process properly. He has been extremely patient (more than I would have ever been in the same position) in trying to offer his help in ensuring things don't get fucked up. He has been completely ignored. Hence us being in this situation.
  • »29.10.20 - 14:31
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 12058 from 2003/5/22
    From: Germany
    >> U-Boot molsen-2018-10-05 (Oct 05 2018 - 17:02:05)

    > "The only U-Boot firmware you need [...] includes "aeon" in the version string."
    > [...] My confusion remains.

    Same here :-)
  • »29.10.20 - 14:50
    Profile
  • Cocoon
    Cocoon
    amigakit
    Posts: 43 from 2005/8/24
    @Piru

    There are two distinct entities here:

    * ExecSG Team with a private branch of the source code

    * A-EON Technology Ltd with official source maintained by BigFoot

    I am not involved, or have been asked to be involved with ExecSG Team and therefore do not speak for them. I also do not know what they are working on except for news snippets of information that come my way from time to time.

    Quote:

    You guys (Trevor, Matthew & Steven, plus whoever else might be involved)


    Bundling us together is maybe why you and others are confused and asking for clarification.

    Quote:

    So there is something being beta tested that is supposed to be released. How come bigfoot is totally unaware what this new firmware does?


    I have not been give access or ever used this new third-party firmware so I am unaware also. I presume that SSolie will distribute it to their group of beta testers. I am seeking clarification now. As I mentioned before, official A-EON X5000 firmware is maintained by BigFoot unless he chooses otherwise.
    www.amigakit.com - Amiga store
  • »29.10.20 - 15:18
    Profile Visit Website
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 12058 from 2003/5/22
    From: Germany
    > Bundling us together is maybe why you and others are confused
    > and asking for clarification. [...] I am seeking clarification now.

    ;-)
  • »29.10.20 - 15:28
    Profile
  • MorphOS Developer
    Piru
    Posts: 575 from 2003/2/24
    From: finland, the l...
    Quote:

    amigakit wrote:
    @Piru

    There are two distinct entities here:

    * ExecSG Team with a private branch of the source code

    * A-EON Technology Ltd with official source maintained by BigFoot

    I am not involved, or have been asked to be involved with ExecSG Team and therefore do not speak for them. I also do not know what they are working on except for news snippets of information that come my way from time to time.

    Quote:

    You guys (Trevor, Matthew & Steven, plus whoever else might be involved)


    Bundling us together is maybe why you and others are confused and asking for clarification.


    Ok, fine. Considering that the communication coming from other parties involves X5000, it is quite possible to assume that you should be at least somehow working together on this. As it is now (from outsider's point of view) it sure looks like some important internal communication is missing, and thus has resulted in:

    1. Bigfoot being withheld important information and his offer to help being ignored, resulting in well founded fears of some disastrous changes being done to the firmware that may result in future problems
    2. Mixed public signals from number of parties (more or less) involved.

    Quote:

    Quote:

    So there is something being beta tested that is supposed to be released. How come bigfoot is totally unaware what this new firmware does?


    I have not been give access or ever used this new third-party firmware so I am unaware also. I presume that SSolie will distribute it to their group of beta testers. I am seeking clarification now. As I mentioned before, official A-EON X5000 firmware is maintained by BigFoot unless he chooses otherwise.


    Thanks, clarity would be great in this matter, indeed.
  • »29.10.20 - 15:58
    Profile
  • Cocoon
    Cocoon
    amigakit
    Posts: 43 from 2005/8/24
    Quote:

    Ok, fine. Considering that the communication coming from other parties involves X5000, it is quite possible to assume that you should be at least somehow working together on this.


    Sure, I can see how it could be assumed the case, but it is not.

    I have suggested to the ExecSG team that they send their update information and other relevant files to BigFoot for review. We do not want it having any unintended adverse effects on the MorphOS Kernel if any of the changes are eventually put into the official firmware.
    www.amigakit.com - Amiga store
  • »29.10.20 - 16:10
    Profile Visit Website