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.

All patches done on "cfe_2012_june_08.lha" version, on the boot you should have:
"Build Date: Fri Jun 8 16:04:49 CEST 2012 (hfrieden@jumpgate)"

or check it from CFE promt:

CFE> d 0x7FDC4028
.


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 */

@TearsOfMe

Quote:

At least when i do "show pmu" in CFE, i got that:



a4/a5/a6 just same, need do dig in to check if this can be changed, and what benefits it will give and where if we will set let's say 2000.


@all

Wow this looks fantastic.

@TerasOfME
And now about this A5/A6 thing, i find out how bypass it easy:



By some reasons we can't set to 5 or to 6 (probably that what they removed, simple you can't use number more than 4), but you simple can set to any of those any value you need, i tried 1900 and 2000, and they both works, there we go:

(press open in new tab for full size):



In other words there maybe worth to patch to have 5 and 6 be 1900 and 2000 or something, just to avoid typing it all manually, but for while being it all can be added right in STARTUP, like:



Through i do not know how stable it all and how hot it all, but from what i understand, for the 1200, 1600 and 1800 (i.e. a2, a3 and a4) we have 1:1 the same voltage , and only less for a0 (500 mhz) and a1 (800 mhz). So, everything which we set above to a4, will be of the same voltage (so it shouldn't be hot or anything), just with bigger frequency.

And as i read in the Elektra's uboot code (pre-Nemo board), you can't set more than this voltage programmable, so to not burn it.
What mean that we can test any value until we hit a wall with stability, maybe even 2200 will be ok , who know. 2000 seems fine, but that all need tests of course, especially if it indeed no voltage increase.

EDIT: ok, found:

2600mhz - freeze
2500mhz - freeze
2400mhz - exception (MCE 0x200)
2300mhz - back to CFE prompt OK, but calling "menu" -> freeze
2200mhz - much better, can start OS, but once workbench loads all sorts of freezes
2100mhz - amigaos runs fine, inside run Spencer game and play for a few minutes.


So, our safe limit is 2100. Which is also good enough, just ~16% for free from nothing. Of course that need more stress tests, but even if it will be "just" 2000 in end, that not bad too imho. Need to test some real life apps to measure if it real gain, and not just numbers.

EDIT2:
Actually, Sysmon's RAgemem benchmark on my 2100 over stock 1800 x1000 shows now +13-17% everywhere. Same as sortbench : +17% everywhere. And same as SDL Bench.. Quite cool !

Thanks for testing. Looks good. I will look to change tomorrow my Rx card back to a HD for testing.