iMac G3 (tray) bootROM dump (1Mbyte)

[jonhysams]

Hello to everyone,

I would like to know if someone have some information about where to look for an iMac G3 (tray loading) bootROM dump file.

I had searched multiple places in the web, and none of the "firmware" or "roms" of the iMac G3 are really dump files (the dump file must be exactly 1,048,576 bytes). All of the files I had encountered are firmware updates files that rely on the firmware bootloader code embedded to flash the bootROM through the operating system update, or are files for emulation purposes that do not resemble exactly the contents and length of the bootROM semiconductor chip soldered into the iMac G3 (by the way, the chip is an Intel 28F008B3T flash memory, size of 1Mbyte x 8 bits = 1,048,576 bytes).

The chip is a 40-lead TSOP package, very easy to soldering/desoldering.

Thank you for any help in advance.

Regards.

 

[philgxxd]

I think someone could dump it through telnet from another machine and use some commands through open firmware?

 

[philgxxd]

I only have slot loaders so can’t dig into it myself.
I personally would appreciate a follow up from you showing the method and process of desoldering and soldering the IC as I have never done that but do electronics work on a self trained level.

 

[jonhysams]

Thank you for your replies philgxxd.

I will be eager to show detailed process, advices, warnings and tips about desoldering/soldering the chip if I could get the original 1MB bootROM dump.

A couple of near friends tried to dump the bootROM through common OpenFirmware commands but were unsucessful. That is because when you access OpenFirmware the bootROM is not "living" in the physical addresses of the chip anymore (0x0000 to 0xFFFFF). Well, of course it stays into the chip forever, but iMac processor and operating system do not "see" it from the original addresses anymore. At booting, the entire bootROM is copied to RAM and also patched and replaced with other values at some places to indicate sucessful booting and initialization. That is the reason why you can see in the iMac properties "About this computer" that RAM is lesser than the total installed. Also, it is a common procedure for computers designers to copy flash/EEPROM/EPROM, etc. to static or dynamic RAM to run faster (the access of RAM in nanoseconds is commonly faster than with flash/EEPROM/EPROM, etc.). I do not know if all OpenFirmware versions have the necessary commands to read the true physical addresses (not the logical addresses, that, at least for the bootROM memory map (0x0000 to 0xFFFFF) appear virtualized in some OpenFirmware versions).

If at least a single byte of the bootROM does not have the original value, the iMac will refuse to start (no video, no hard disk, no keyboard, not even OpenFirmware, not Reset button, etc.) because it will fail the Checksum testing of the integrity of the bootROM contents.

 

[DearthnVader]

Thank you for your replies philgxxd.

I will be eager to show detailed process, advices, warnings and tips about desoldering/soldering the chip if I could get the original 1MB bootROM dump.

A couple of near friends tried to dump the bootROM through common OpenFirmware commands but were unsucessful. That is because when you access OpenFirmware the bootROM is not "living" in the physical addresses of the chip anymore (0x0000 to 0xFFFFF). Well, of course it stays into the chip forever, but iMac processor and operating system do not "see" it from the original addresses anymore. At booting, the entire bootROM is copied to RAM and also patched and replaced with other values at some places to indicate sucessful booting and initialization. That is the reason why you can see in the iMac properties "About this computer" that RAM is lesser than the total installed. Also, it is a common procedure for computers designers to copy flash/EEPROM/EPROM, etc. to static or dynamic RAM to run faster (the access of RAM in nanoseconds is commonly faster than with flash/EEPROM/EPROM, etc.). I do not know if all OpenFirmware versions have the necessary commands to read the true physical addresses (not the logical addresses, that, at least for the bootROM memory map (0x0000 to 0xFFFFF) appear virtualized in some OpenFirmware versions).

If at least a single byte of the bootROM does not have the original value, the iMac will refuse to start (no video, no hard disk, no keyboard, not even OpenFirmware, not Reset button, etc.) because it will fail the Checksum testing of the integrity of the bootROM contents.

telnet 10.1.2.3 | tee -a iMac.txt

ff800000 100000 dump

sed 's/^.*:/ /' iMac.txt | sed -n -e 's/\|.*\|/ /p' | xxd -r -p > iMac.bin

 

[joevt]

I've got a rom for an iMac with model PowerMac2,1

In Open Firmware, change the io to telnet (pick an unused address accessible by your other Mac)
" enet:telnet,10.1.42.148" io

Get some Open Firmware info:
dev / ls
dump-device-tree
words

In the dump-device-tree output, there's some memory ranges for the ROM. I guess you just want the boot-rom part (in my case, address:fff00000 length:00100000)

/rom@ff800000
PROPERTIES:
name                    rom
reg                     ff800000  00000000
ranges                  ff800000  00800000  ff800000
#address-cells          00000001

METHODS:
encode-unit     decode-unit     close           open         

/rom@ff800000/boot-rom@fff00000
PROPERTIES:
name                    boot-rom
reg                     fff00000  00100000
write-characteristic    flash
model                   Apple PowerMac2,1 4.1.9f1 BootROM built on 09/14/01 at 13:18:04
BootROM-version         $0004.19f1
BootROM-build-date      09/14/01 at 13:18:04
security-modes          6e6f6e65 2c206675 6c6c2c20 636f6d6d 616e64

info                    fff00000 00003f00 000419f1 20010914 43b8671b
                        fff08000 00078001 000419f1 20010914 f05f6b03
                        fff80000 00080002 000419f1 20010914 d85d3f5a
                        fff03f00 00000083 000419f1 20010914 a7233187
                        fff03f80 00000084 e1dd2819 15a81001 ffffffff
                        fff04000 00004005 6e767261 6d000000 00000000         nvram


info                    fff00000 00003f00 000419f1 20010914 43b8671b
                        fff03f00 00000083 000419f1 20010914 a7233187
                        fff03f80 00000084 e1dd2819 15a81001 ffffffff
                        fff04000 00004005 6e767261 6d000000 00000000         nvram
                        fff08000 00078001 000419f1 20010914 f05f6b03
                        fff80000 00080002 000419f1 20010914 d85d3f5a

has-config-block

Create a command to dump the bytes (this is more efficient than dump because it doesn't include extra characters)
: dumpbytes bounds ?do i c@ 2.r loop ;

For Old World Macs (which don't have 2.r):
: dumpbytes bounds ?do i c@ 2 u.r loop ;

On the destination Mac:
telnet 10.1.42.148 > thecapture.txt

In Open Firmware, you might need to map the ROM bytes first:
fff00000 dup 100000 28 do-map

Then dump the ROM bytes:
fff00000 100000 dumpbytes

I've got a script (not included) that can disassemble or detokenize the Open Firmware parts (requires MPW).

 

[philgxxd]

Awesome. This sounds promising.

 

[jonhysams]

Thank you DearthnVader, joevt, and philgxxd.

Also awaiting another tray loading iMac in the next days to begin the tests. I will post the procedures and pictures.

 

[ADunsmuir]

I've got a script (not included) that can disassemble or detokenize the Open Firmware parts (requires MPW).

Would it be possible for you to post that script, please?

 

[joevt]

Would it be possible for you to post that script, please?

For disassembly, the DumpMacRom script calls the detok command which uses a PowerPC disassembler library that was included with MPW (without source code) so I didn't try to convert that stuff to Mac OS X. Update: now the disassembler in my detok no longer requires classic macOS or MPW - the tools should now be used in Mac OS X.

The Power Mac G5 Quad Core was nearly the last Open Firmware. The interesting thing about its boot rom is that most or all the Open Firmware functions are named (I haven't looked at the iMac G5: PowerMac12,1). You can probably find names for unnamed functions in older Open Firmware Macs by looking for similar functions in the G5's boot rom. Update: Open Firmware 2.4 also has all the names visible.

Update: links are at #543

 

[ADunsmuir]

For disassembly, the DumpMacRom script calls the detok command which uses a PowerPC disassembler library that was included with MPW (without source code) so I didn't try to convert that stuff to Mac OS X.

The Power Mac G5 Quad Core was nearly the last Open Firmware Mac made. The interesting thing about its boot rom is that most or all the Open Firmware functions are named (I haven't looked at the iMac G5: PowerMac12,1). You can probably find names for unnamed functions in older Open Firmware Macs by looking for similar functions in the G5's boot rom.

Thank you!

 

[DearthnVader]

For disassembly, the DumpMacRom script calls the detok command which uses a PowerPC disassembler library that was included with MPW (without source code) so I didn't try to convert that stuff to Mac OS X.

The Power Mac G5 Quad Core was nearly the last Open Firmware Mac made. The interesting thing about its boot rom is that most or all the Open Firmware functions are named (I haven't looked at the iMac G5: PowerMac12,1). You can probably find names for unnamed functions in older Open Firmware Macs by looking for similar functions in the G5's boot rom.

Not to get too far off topic, but this is really cool stuff, I think you sent me this script a few years back, but I can't really recall if I ever used it. It would be nice at some point when OpenBios is a little more mature to try and replace OF with OpenBios on a real Mac.

OpenBios offers some things that Apple's implementation of OF lacks, such as true to ?fcode-verbose and being able to load PCI ROMs without having to strip the PCI headers, and of course it's open source so we can manipulate it any way we want too.

Tho Apple's OF uses hard coded device trees, and OB lacks the ability to execute Fcode Roms at startup.