X1000 CFE Patches: Testers Welcome (Fear not: real-time, no reflashing) v.01

Preface

As we are all aware (or not), we do not have the CFE source code for the X1000 that includes the
changes from PA-Semi and Hyperion. However, we do have the full CFE source code prior to those
specific changes. Combined with Ghidra for PowerPC decompilation and various disassembly tools-plus
the knowledge I gained working on the PA6T network driver regarding CFE binaries and its API-it is
now possible to create CFE patches even without the original source code.

Note that x1000's CFE firmware is the property of A-EON/Trevor, so I cannot distribute a ready-to-use
patched version of x1000's CFE myself (right? or can i?). But what I can distribute later for the brave
is a tool to patch your own CFE. Of course, I will test everything on my own hardware first; I currently
have a hardware programmer, so I can wipe and re-flash at any time without risk.

That is for later, though. Currently, I am making all patches "real-time," meaning you don’t need to
re-flash anything. They reside only in the current CFE memory and will be gone after a reboot or
power-off.



What is the practical use of this in its current form ?

You can add them to CFE and have them run at boot, or manually load them via TFTP. The real goal is to
verify that they fix existing issues without introducing new ones. Once everything is stable enough,
I will start experimenting with my own flash to make them permanent.

In other words: any X1000 user can play with these now without fear. However, if you "burn and die," I
take no responsibility. You should know what you are doing.


Running the patches

Patches should be executed using the boot -elf -noints xxxxxx.elf command. Both flags are necessary
(without -noints, the system will simply reboot after a few seconds).
You can run patches in any way you wish - just one per session, or all 3 at once
(the hooks are placed at different addresses and do not interfere with each other), like:



or via TFTP if you want to test them one by one:



or if you have no CF card, you can simply put the patches on your Amiga FFS BOOT partition alongside
your amigaboot.of, and run them from there. These patches are built in a way that will not crash even
if run from CFE's AmigaFS, which lacks (or has a broken/unimplemented) seek() implementation, so this will
work too:



To make them run automatically (all patches, or just one - which will likely be keycon for most of us),
change your STARTUP label from just set pmu -astate=a4; menu to:



Now it will run on every boot.

So...

What we have now ?

Patch #1: SATA (sata.elf)

- Added probing for Channel 1, so SATA ports 3 and 1 now work.
- Fixed detection of "slave" devices even if no "master" is present.
- Devices on any port will now be detected. You can have Port 0 (Ch0) and Port 3 (Ch1),
or Port 2 (Ch0) and Port 1 (Ch1) working together, etc.


Patch #2: Keyboard/Console (keycon.elf)

- Key repeat - Holding a key now auto-repeats (500ms delay, ~33/sec repeat)
- Home/End keys - Jump to beginning/end of line
- Delete key - Forward delete with repeat
- VESA cross-line backspace - Backspace at column 0 now wraps to end of previous line
(was moving cursor off-screen to pixel x=-8)
- VESA cross-line left arrow - Left arrow at column 0 also wraps to previous line
- VESA ghost character fix - Up/Down history no longer leaves remnants of longer commands
(VGA's writechar didn't implement it originally)


Patch #3: External commands (cmds.elf)

- "cls" - clear the screen
- "version" - returns the CFE version.


Download them from there:
https://kas1e.mikendezign.com/aos4/x10 ... rmware/cfe_busted_v01.zip

Have fun and let me know how it goes, thanks !

@kas1e
Very interesting. Nice Work.

Maybe there is a way to change the astate?
200Mhz more can be nice and my procesor temp is always low at around 40 degree Celsius so temp wise ist see no Problem.

@kas1e
It looks very interesting. Thanks for developement!
I will try on weekend.

@TearsOfMe
Quote:

Yes, but you probably mean set it right once computer boots, and cfe only starts to load things up to speed up whole CFE booting process? Or you mean to change state when we already have CFE loaded till the prompt/menu ?

Why i ask it's because for now we do real-time patches, mean we need environment of CFE from where we run them. So we already in loaded CFE, where we already can do "set pmu -astate=a4" which as far as i understand (seeing linux's cpu_freq.c and cfe's disassembly) doing exactly that, set it to 1.8ghz

So probably what you mean is to set it to 1800 right at the beginning of reading date from EEPROM so to have 1800 for whole process till menu, which can only be done by permanent patches later, not by real time one.

Ah okay.
I thought it is possible to use modes A5 and A6.
From what i understand, they’ve been removed in linux, but maybe its possible to add them. I have no idea.

*/We support 5(A0-A4) power states excluding turbo(A5-A6) modes */