@kas1e I don't know but I don't think any OF implementation is still developed since Sun and Apple stopped using it so the one from 20 years ago may still be the latest. If you try to get that ported I'd suggest to first try to reconstruct the pegasos2 ROM so you know better what to do than trying to port it right away to a different platform but maybe it's easier to port in a different way, I don't know. The pegasos2 rom seems to have two parts: a compressed image at around 0x20000 that is called oftest_64M.rom which I think is actual SmartFirmware that you could build from the open sources maybe with some patches and a loader called PegasosII Boot Strap that first starts, inits the machine and memory and then uncompresses and starts SmartFirmware. This is the bPlan code that isn't open sourced. This also includes a low level monitor called IKARUS low level console that is entered when no memory is found. You can force that on QEMU with removing the SPD EEPROM by commenting these lines (and the variable definitions) in qemu/hw/ppc/pegasos.c::pegasos_init()
$ qemu-system-ppc -M pegasos2 -serial mon:stdio -bios pegasos2.rom
PegasosII Boot Strap (c) 2002-2003 bplan GmbH
Running on CPU PVR:80020102
Enable L1 ICache... Done.
Clean/Flush Block enabled
Reading W83194 : FAILED.
Setting Front Side Bus to 133MHz... FAILED.
Configuring DDR... Done.
Configuring PCI0... Done.
Configuring PCI1... Done.
Configuring ETH... Done.
Releasing IDE reset ... Done.
Configuring Legacy Devices
Initializing KBD... Done.
Testing 00000000 Bytes, Pass: 00000000 Failed: 00000000
RAM TEST (fill linear)... Done.
FFFFFFFF
Entering IKARUS low level console
>
This has a helpful help command: pressing ? prints #RTFM but there's some info on this here. The output above shows what this code is doing and you can probably trace on QEMU what registers these access so to reconstruct it you'd need to reverse and reimplement it then combine with the SmartFirmware. If SmartFirmware has a compressed loader then this may be based on that with the above hardware init added. if that loader is not in SmartFirmware it may be similar to what PMON does. The most complex part is probably getting SPD data over i2c and init the memory controller based on that. I've asked bPlan before if they could open source their part but I never got any answer from them. Genesi open sourced what they had including the full schematics that I've linked from my page about Pegasos2 emulation.
@balaton So if this 20 years old one is one used by peg2 and broadcom (and then x1000 with fixes) then yeah, that one way to go. And yes, if go that way firstly pegasos2 then, because easy to test basics on qemu before real reflashing. Then after can be adapted to x1000.
Yes, it looks for all block devices : i already made USB boot working by adding to relevant pci@13 a node with "block" and correct methods and amigaboot finds it fine (together with HDD and CD), see (UDH2n that usb stick + CD + DH0):
Amazing that it worked. I would have expected it to be harder. Needing to hook into USB driver routines and code a custom seek and read method.
Quote:
I didn't use static addresses already : because i even with sata have issues when user have added one or more PCI card at top, or have 2 gfx cards at the same time, and addresses shifts.
I would have expected the SATA ports to be mapped to one hardware address for IDE registers. I suppose it's not as simple as serial, if it's sitting on PCI bus and SATA ports don't have an exact hardware address.
Quote:
For sata i scan heap on known range for a pci@12\0 string + some checks. The same i do now for USB, i simple scan for "pci@13\0", and then scans for usbmass_driver struct for "Mass-Storage Device" string.
I wonder if CFE reads a static device tree from ROM or dynamic from memory? With the devtree option. The extra SATA devices were "blocked" in but when I listed the devtree I didn't see any extra "block" devices for any USB devices. I saved a serial log so can go back and check.
Edited by Hypex on 2026/4/15 5:30:58 Edited by Hypex on 2026/4/15 5:31:56
The extra SATA devices were "blocked" in but when I listed the devtree I didn't see any extra "block" devices for any USB devices. I saved a serial log so can go back and check.
All i can say currently that i know where in memory dev tree placed, and how to change/add things to it, but how it were build by CFE dunno..
By default CFE didn't create "block" devices in devtree for USB massstorages, as well as it didn't use channel1 at all so also not add any blocks there.
More of it, devtree is static, so nothing updated in (except some easy bits like envs, etc), it just builds one time on run.
What i did for both sata and usbsticks is create "block" devices + correct method for read/seek/etc. But this method i simple copy by memory dump from working block devices in channel0 , and then create new nodes with block devices for other originally non working sata ports as well as for usb devices. But by default, there is simple channel0 (port0 and 2) in cfe, and no port 1/3 , and no usb. For usb i hook detach/attach usb functions, so when attach - create node with block, when detach - remove one. And amigaboot happy about )
@Joerg Want to create SFS2 reading-loading supportIs in CFE, and can you plz say if SFS sources on os4depot is SFS0/1 ones, but the one OS4's SFS2 is the same just large file support added with a bit changed structure ?
AFAIK amigaboot.(of|ub) includes (a port of) my SFS functions from SLB_v2, which should support both SFS\0 and SFS\2.
SFS sources on os4depot.net??? The (sources of the) SFS tools included in https://os4depot.net/?function=showfil ... driver/filesystem/sfs.lha should work with any SFS version since they just use the SFS specific DOS packets and don't access SFS blocks on the disk directly.
All public SFS sources, https://sourceforge.net/p/smartfilesystem/code/ (IIRC an old version, maybe 1.58, GPL), ACube's Parthenope/ub2lb SFS implementation and the AROS port are SFS\0 only. MorphOS is SFS\0 only as well, but like me, Olsen and several other developers, one of the AROS developers, one of the MorphOS developers (IIRC Ralph Schmidt), etc. got the last version of John's SFS sources, version 1.84. In total there should be about 5-6 developers who got John's last version of the SFS sources, without any usage restrictions like GPL.
Additionally there is, or was, a very broken SFS re-implenaation in Linux not based on the original SFS sources but only on it's documentation, but only use it in read-only mode, unless you need an easy way to destroy SFS partitions
@joerg Amigaboot support it for sure, but CFE is not : i.e. i can't dir/boot amigaboot from SFS2 formatted media, so that what i add.
I just add it as "Read only", because i only need dir, load, boot to work, and find out that when i tried to make it based on this sources from os4depot, that structure in compare changes in sfs2, so i had again to shifts offsets, etc.
@All I start to have some issues , called "i run out of space for all hooks/trampolines/structs/buffers i use for all the pathes". On the boot i see that:
Total memory used by CFE: 0x7FD1DF60 - 0x80000000 (3023008)
Initialized Data: 0x7FDD8420 - 0x7FDF8B00 (132832)
BSS Area: 0x7FDF8B00 - 0x7FDFF000 (25856)
Local Heap: 0x7FDFF000 - 0x7FFFF000 (2097152)
Stack Area: 0x7FFFF000 - 0x80000000 (4096)
Text (code) segment: 0x7FD1DF60 - 0x7FDCBE60 (712448)
Relocation Factor: I:7FE1DF60 - D:7FE1DF60
I start to use this GAP area for all my things, mostly dead reloc table (as it used only once on boot), but then, i can't go over the live GOT stuff , etc. I choose this place because before i tried to use some other areas of memory, but meet with kernel allocations after the modules loads up which i unknown where. And i don't know what exactly and where amiboot allocate too (i only know it loads up on 0x20000).
Question is: what the area is 100% safe to be used, at least 1-2megabytes, which stays the same does not matter which memory-config user have and so on. Any ideas ? Maybe something below interrupts at very beginning of memory or something ?
All i can say currently that i know where in memory dev tree placed, and how to change/add things to it, but how it were build by CFE dunno..
It looks like the design makes it easy to change items on the tree.
For example prom_setprop() function can be called from prom_init.c code in Linux kernel to change cell values in device tree.
Quote:
By default CFE didn't create "block" devices in devtree for USB massstorages, as well as it didn't use channel1 at all so also not add any blocks there.
The block devices that do exist are assigned to permanent devices like SATA ports so that may explain why they don't exist for USB and the ones that do exist return 0 blocks for device not present.
Quote:
More of it, devtree is static, so nothing updated in (except some easy bits like envs, etc), it just builds one time on run.
Makes sense.
Quote:
What i did for both sata and usbsticks is create "block" devices + correct method for read/seek/etc. But this method i simple copy by memory dump from working block devices in channel0 , and then create new nodes with block devices for other originally non working sata ports as well as for usb devices. But by default, there is simple channel0 (port0 and 2) in cfe, and no port 1/3 , and no usb. For usb i hook detach/attach usb functions, so when attach - create node with block, when detach - remove one. And amigaboot happy about )
By the looks of it, for a complex situation in adding detection and read support, that that was the least complex way of achieving it.
Quote:
Amigaboot support it for sure, but CFE is not : i.e. i can't dir/boot amigaboot from SFS2 formatted media, so that what i add.
It was good to have file support. But was strange, as in it detected all but ffs, when firmware was designed for Amiga users in mind or an Amiga machine. It also complicated the boot block, since there needed to be a boot loader volume to load a booter file from, where previously UBoot just scanned HDD drives for BOOT directly within an RDSK formatted drive.
Quote:
Question is: what the area is 100% safe to be used, at least 1-2megabytes, which stays the same does not matter which memory-config user have and so on. Any ideas ? Maybe something below interrupts at very beginning of memory or something ?
This may give a clue, which is what amigaboot.of does before it loads the modules in.
@Hypex I found words "finddevice" only in amigaboot, so probably it's amigaboot.of claim for first string, and then , another one for 20mb is the kernel ?
The current memory map then looks like this (correct me if i wrong somewhere):
0x00000000 - 0x00000FFF 4KB PPC exception vector table
0x100 System Reset 0x800 FP Unavailable
0x200 Machine Check 0x900 Decrementer (timer)
0x300 Data Storage (DSI) 0xC00 System Call
0x400 Instruction Storage 0xD00 Trace / Single Step
0x500 External Interrupt 0x1000 Instruction TLB Miss
0x600 Alignment 0x1100 Data Load TLB Miss
0x700 Program Check 0x1200 Data Store TLB Miss
Looking at the TRM it lists the EEPROM as 24LC128 which still looks common. Board image is a but blurry or pixelated up close but looks like chip is soldered on board.
I checked TRM, and one you mention its about one connected via SMBus 0 (I2C) which a 128 Kbit (16KB) serial EEPROM and probably holds board configuration data, MAC address, serial number, etc. So different bus, different protocol, much smaller, not our flashes.
Our ones is 2 SPIs which should be able to hold per 2MB each at least.
I made a good detailed photos and probably find them, see:
Then more closed look on whole part:
And now each chip (i not sure, but IMHO the one closer to the CPU is the main one, and one at bottom is the rescue one).
So, 1st one which is closer to CPU (main one probably):
Both identical absolutely mean that those are indeed our flashes. Both are 16mbit (2mb), low voltage (2.7-3.6V) and both from year 2010 :)
Now I need to desolder the chips, solder sockets on the board, and make a 10-15 cm adapter with a socket on both ends. It’ll just work as an extension cable, so I can plug/unplug the flash chips easily without constantly messing with the board.
I found words "finddevice" only in amigaboot, so probably it's amigaboot.of claim for first string, and then , another one for 20mb is the kernel ?
I'd say so. I also found "finddevice" in loader.of. That could be allocating the 20MB since it loads the kernel and modules from the module list and links all the ELF binaries together into the final Kickstart in RAM.
Quote:
The current memory map then looks like this (correct me if i wrong somewhere):
Looks good. Map makes sense.
I'm still trying to make sense of RTAS itself. I found no "RTAS" in the CFE.bin and amigaboot.of finds a 0 RTAS which would mean not found. But from what I've read about it RTAS needs to survive or be present when the OS load and work as some kind of HAL. So it may be creating RTAS, which would be opposite to how I was thinking, because I thought it would be in OF or part of it.
Quote:
So the "free" zone is 0x03400000-0x7CCFFFFF ?
It looks like it yes. A few years back I was doing some hacking about and seeing where amigaboot.of loaded the modules in. It was in the high RAM. Possible 0x7ED10000 as it looks familiar. But I can't find where I stored my notes. Nothing on my X1000 in any obvious place. My early hacks just wrote startup registers passed to CFE binary to $24000000 and stored some data found. Later, I experimented with Kickstart modules, to see what amigaboot.of passed to the loader.of. If it sits in that 16MB allocation that makes sense, as any file close to 16MB inside a Kicklayout breaks.
Also, I found out that any client needs to pass pointers in the lower RAM area to the OF handler. I don't recall where CFE was loading it, possibly in the default 0x20000000 area. The code didn't crash, it just didn't work. OF calls were ignored. I had to lower my ELF location to 0x240000 for it to work. I noticed amigaboot.of loaded at 0x200000. This goes against CFE loader which defaults to a "broken" address in OF client terms.
Both identical absolutely mean that those are indeed our flashes. Both are 16mbit (2mb), low voltage (2.7-3.6V) and both from year 2010 :)
Now I need to desolder the chips, solder sockets on the board, and make a 10-15 cm adapter with a socket on both ends. It’ll just work as an extension cable, so I can plug/unplug the flash chips easily without constantly messing with the board.
The datasheet I've found (not sure it's the exact same chip) said these could take 100,000 reflash cycles so unlikely you could kill them. Maybe there's no need to desolder it before it dies to avoid damaging the board.
I'm still trying to make sense of RTAS itself. I found no "RTAS" in the CFE.bin and amigaboot.of finds a 0 RTAS which would mean not found. But from what I've read about it RTAS needs to survive or be present when the OS load and work as some kind of HAL. So it may be creating RTAS, which would be opposite to how I was thinking, because I thought it would be in OF or part of it.
Reading the above I can't make sense of what you're trying make sense but RTAS is part of PowerPC CHRP (Common Hardware Reference Platform) so look for that specification, it's documented in there. The OS needs to "instantiate RTAS" which copies some code that calls back intro the ROM which the OS later needs to call if it wants to access RTAS services. You can see in QEMU pegasos.c which RTAS services are needed by AmigaOS because I only bothered to implement those.
I checked TRM, and one you mention its about one connected via SMBus 0 (I2C) which a 128 Kbit (16KB) serial EEPROM and probably holds board configuration data, MAC address, serial number, etc. So different bus, different protocol, much smaller, not our flashes.
Ok, then the manual is a bit vague. Most references to EEPROM are for the BIOS. So this section doesn't help: Quote:
SMbus 0 is connected to the 4 DIMM sockets to support Serial Presence Detect (SPD). For further details, see section 5. It is also connected to a standard 24LC128 EEPROM, and a temperature sensor (Texas Instruments TMP423). This sensor is
Quote:
Our ones is 2 SPIs which should be able to hold per 2MB each at least. I made a good detailed photos and probably find them, see:
Yes, so two chips then. Why is this info missing from TRM?
Quote:
So: main one: SST 25VF016B, SQ-41-S2AF, 1032VJA-C rescue one: SST 25VF016B, SQ-41-S2AF, 1032VJS-C Both identical absolutely mean that those are indeed our flashes. Both are 16mbit (2mb), low voltage (2.7-3.6V) and both from year 2010 :)
That should make it easier to work on.
Quote:
Now I need to desolder the chips, solder sockets on the board, and make a 10-15 cm adapter with a socket on both ends. It’ll just work as an extension cable, so I can plug/unplug the flash chips easily without constantly messing with the board.
Ouch. Getting hardcore. I'm tempted to test my CH341 on my rescue BIOS, but I would like three, in case the rescue chip didn't like it and got screwed.
Reading the above I can't make sense of what you're trying make sense but RTAS is part of PowerPC CHRP (Common Hardware Reference Platform) so look for that specification, it's documented in there. The OS needs to "instantiate RTAS" which copies some code that calls back intro the ROM which the OS later needs to call if it wants to access RTAS services. You can see in QEMU pegasos.c which RTAS services are needed by AmigaOS because I only bothered to implement those.
Here's the problem. There is no RTAS in CFE or the OF embedded in this CFE. I've seen amigaboot.of or the loader.of looking for an "rtas" and not finding it. Given CFE isn't designed to be an OF in the first place, and the OF in there appears to be as some kind of generic binary standard, it cannot be trusted to be fully working OF implementation. So the OS4 kernel would need to include an RTAS itself, to simulate it, using some kind of HAL API.
The following OF methods or forth words if you will are what I found in the cfe.bin:
open
close
finddevice
getproplen
getprop
setprop
nextprop
instance-to-path
instance-to-package
package-to-path
canon
peer
child
parent
claim
release
exit
test
milliseconds
call-method
start-cpu
quiesce
boothack
seek
Some method tokens:
read
seek
#blocks
block-size
The following are console devices:
bootconsole
stdin
stdout
Now, despite the forth nature of OF, I wouldn't call them forth words myself. I would call them methods or function names, because the CFE OF has no forth interpreter. There is no interpret word in CFE.
@Hypex These are what Open Firmware calls client interface. Then CFE is like VOF in QEMU that only emulates this and provides enough of the Open Firmware enviromnent that simple boot loaders need. Except that CFE also supports reading blocks from disks which isn't implemented in QEMU's VOF.
These are what Open Firmware calls client interface. Then CFE is like VOF in QEMU that only emulates this and provides enough of the Open Firmware enviromnent that simple boot loaders need. Except that CFE also supports reading blocks from disks which isn't implemented in QEMU's VOF.
Suppose block support would be considered a lower level access. This would be needed because amigaboot.of needs to scans drive for partitions and determining filesystem. I don't recall the history but I wonder if the OF interface in CFE is present because they could take the Pegasos OF loader and easily port it to the X1000. Now days SLB is mostly dropped. Amigaboot is coded in OF and UB variants so they do share the same code base.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
