Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Daniel]

Ugh. Do this.

Code: [Select]

dev /cpus lsSelect the first device reported by that.
Then do this.

Code: [Select]

.properties words
100000 4 claim dup fff00000 swap 100000 10 map 10000 dump

[darthnVader]

Ugh. Do this.

Code: [Select]

dev /cpus lsSelect the first device reported by that.
Then do this.

Code: [Select]

.properties words
100000 4 claim dup fff00000 swap 100000 10 map 10000 dump

Sorry, you're just confusing me.

[Daniel]

Sorry. I guess I need to be more clear with what I am saying.
You need to select the primary CPU. This is because it has the memory management functions in it.
The OF command sequence:

Code: [Select]

dev /cpus lsShould have an output looking somewhat like this:

Code: [Select]

0 > dev /cpus ls
ff83d900: /PowerPC,750@0
ff83dcc0:    /l2-cacheThere may be more than one CPU, and the name of it depends on what CPU your machine is.
You select it with dev. In my example, it would look like this:

Code: [Select]

dev /cpus/PowerPC,750@0Then, lets do a simple sanity check so it will be easier to find any problems in the next step.

Code: [Select]

pwd .properties wordsNow we move on to the actual code that dumps the rom:

Code: [Select]

100000 4 claim dup fff00000 swap 100000 10 map 10000 dumpAll of this is done on the OF prompt so far. If it works, you will be able to use the bash script I showed you earlier  to get the raw rom, which should be a 1MB binary mess of powerpc code and data structures.

[darthnVader]

Sorry. I guess I need to be more clear with what I am saying.
You need to select the primary CPU. This is because it has the memory management functions in it.
The OF command sequence:

Code: [Select]

dev /cpus lsShould have an output looking somewhat like this:

Code: [Select]

0 > dev /cpus ls
ff83d900: /PowerPC,750@0
ff83dcc0:    /l2-cacheThere may be more than one CPU, and the name of it depends on what CPU your machine is.
You select it with dev. In my example, it would look like this:

Code: [Select]

dev /cpus/PowerPC,750@0Then, lets do a simple sanity check so it will be easier to find any problems in the next step.

Code: [Select]

pwd .properties wordsNow we move on to the actual code that dumps the rom:

Code: [Select]

100000 4 claim dup fff00000 swap 100000 10 map 10000 dumpAll of this is done on the OF prompt so far. If it works, you will be able to use the bash script I showed you earlier  to get the raw rom, which should be a 1MB binary mess of powerpc code and data structures.

Thanks for bearing with me, I was pretty sure you meant to dev /cpu/@0, just wanted to be sure.

However, the conversion still turns up garbage.

The .txt file is the result of the telnet dump/log, and the .bin file is the result of the sed conversion.

[Daniel]

Sorry. I guess I need to be more clear with what I am saying.
You need to select the primary CPU. This is because it has the memory management functions in it.
The OF command sequence:

Code: [Select]

dev /cpus lsShould have an output looking somewhat like this:

Code: [Select]

0 > dev /cpus ls
ff83d900: /PowerPC,750@0
ff83dcc0:    /l2-cacheThere may be more than one CPU, and the name of it depends on what CPU your machine is.
You select it with dev. In my example, it would look like this:

Code: [Select]

dev /cpus/PowerPC,750@0Then, lets do a simple sanity check so it will be easier to find any problems in the next step.

Code: [Select]

pwd .properties wordsNow we move on to the actual code that dumps the rom:

Code: [Select]

100000 4 claim dup fff00000 swap 100000 10 map 10000 dumpAll of this is done on the OF prompt so far. If it works, you will be able to use the bash script I showed you earlier  to get the raw rom, which should be a 1MB binary mess of powerpc code and data structures.

Thanks for bearing with me, I was pretty sure you meant to dev /cpu/@0, just wanted to be sure.

However, the conversion still turns up garbage.

The .txt file is the result of the telnet dump/log, and the .bin file is the result of the sed conversion.

I guess that means something is very wrong in my assumptions.

dev /cpus/@0 works perfect. I didn't know you could do that.

I will be back once I figure out another way to do this. It might take a while.

[Daniel]

I seem to have overlooked a much simpler way of doing this. It looks like you can just do this in OF:

Code: [Select]

ff800000 100000 dumpThe rom image starts with a bunch of 0xdeadbeef values, interleaved with ppc code at offsets divisible by 0x100. This is the exception vector table, and it starts at 0xFFF00000 in physical address space. Just trace through everything, starting with the reset vector.

[darthnVader]

I don't know, looking at the firmware updates for the G4's, it's hard to tell where the firmware starts. The "firmware" file also contains a script or some sort of forth executable that does the flashing.

I think the firmware in the firmware updates is at least partially compressed.

I'm also not sure how to get a proper dump of the firmware from one of my G4 systems, but here is one that would appear to be about the correct size, however we need to alter our sed command somehow, because it's "doubling" the data it converts.

Code: [Select]

telnet 10.1.2.3 | tee -a powerbook6,7.txt

Code: [Select]

0 > dev /rom  ok
0 > ls
ff89cb08: /boot-rom@fff00000
ff89cd00: /macos ok

Code: [Select]

ff89cb08 100000 dump

Code: [Select]

sed 's/^.*:/ /p' powerbook6,7.txt | sed -n -e 's/\|.*\|/ /p' | xxd -r -p > powerbook6,7.bin
Sed is just doubling every line of data. Maybe we can rerun Sed on the PowerBook6,7.bin, and get it to pipe only every other line to a file?

 

 

[Daniel]

I don't know, looking at the firmware updates for the G4's, it's hard to tell where the firmware starts. The "firmware" file also contains a script or some sort of forth executable that does the flashing.

I think the firmware in the firmware updates is at least partially compressed.

I'm also not sure how to get a proper dump of the firmware from one of my G4 systems, but here is one that would appear to be about the correct size, however we need to alter our sed command somehow, because it's "doubling" the data it converts.

Code: [Select]

telnet 10.1.2.3 | tee -a powerbook6,7.txt

Code: [Select]

0 > dev /rom  ok
0 > ls
ff89cb08: /boot-rom@fff00000
ff89cd00: /macos ok

Code: [Select]

ff89cb08 100000 dump

Code: [Select]

sed 's/^.*:/ /p' powerbook6,7.txt | sed -n -e 's/\|.*\|/ /p' | xxd -r -p > powerbook6,7.bin
Sed is just doubling every line of data. Maybe we can rerun Sed on the PowerBook6,7.bin, and get it to pipe only every other line to a file?

That ff89cb08 is definitely wrong. That is the address of a device tree structure that ls happens to be printing. Please try ff800000 100000 and send me the text. It works on my computer, and I want to know if it works on yours

[darthnVader]

Here if the dump of ff800000:

[Daniel]

I appear to have finally succeeded at getting a OF rom from a device. Here is this one from my main Mac OS 9 machine (a Pismo). I should probably try this on my Mac Mini sometime because the later models tend to have less bugs and more features. It looks like the Mini might even be able to write to files from an OF prompt, which I have never been able to do on any other OF machine.

The ROM image starts at phys address 0xFFF00000, and begins with the PPC vector table. I think offset 0x100 is the reset vector where the rom boots up. I haven't bothered tracing the execution path yet.

[darthnVader]

Your ROM image is still doubling ever line of data.

[Daniel]

It appears I really don't know how to use sed. The proper OF log to binary conversion script is:

Code: [Select]

sed 's/^.*:/ /' powerbook6,7.txt | sed -n -e 's/\|.*\|/ /p' | xxd -r -p > powerbook6,7.binAll I needed to do was remove one character and it works

Here is that Pismo Rom reprocessed.

[darthnVader]

It appears I really don't know how to use sed. The proper OF log to binary conversion script is:

Code: [Select]

sed 's/^.*:/ /' powerbook6,7.txt | sed -n -e 's/\|.*\|/ /p' | xxd -r -p > powerbook6,7.binAll I needed to do was remove one character and it works

Here is that Pismo Rom reprocessed.

Awesome, sadly Apple put the flash utility into the rom update, and I don't know if they are one off fcode, and each machine needs it's own logic to program the rom chip or we could use the fcode flasher from one Mac on any New World machine.

I've got an iBook G4 that DieHard sent may way, it has video issue, and would be a good test bed to see if we can read the ROM and flash it back.

[darthnVader]

Here is some data from the 4.4.8f2 firmware update.

The file flasher.fcode doesn't look to be fcode at all, it looks like bare forth, so just rename it flasher.txt and open in you favorite text editor and you'll get a pretty good idea what is done to flash a new world rom.

Also, I have an extra logic board for my QuickSilver, as the one I'm using can't get any input in a telnet session in OF, it would be no skin off my nose if I brick it.

[Daniel]

Here is a blog post by someone who experimented with the updater for a G3 Blue and White.
https://www.downtowndougbrown.com/2012/07/power-macintosh-g3-blue-and-white-custom-startup-sound/

Also, nvram seems to contained in the flash chip at offset 0x4000. This means that all NewWorld Macs have some capability of writing to their flash roms. Potentially we could fake it out and make it write the whole thing?

I tried looking at the forth nvram implementation on my mini, but it is very confusing. Several levels of functions referred to only by address. My head explodes before I come close to understanding it.

[powermax]

Here is a blog post by someone who experimented with the updater for a G3 Blue and White.
https://www.downtowndougbrown.com/2012/07/power-macintosh-g3-blue-and-white-custom-startup-sound/

Also, nvram seems to contained in the flash chip at offset 0x4000. This means that all NewWorld Macs have some capability of writing to their flash roms.

NVRAM on some post-Yosemite machines (Sawtooth, for example) is just a partition of the BootROM (small & slow 8-bit Flash ROM). It's apparently controlled by "Grackle" (Motorola MPC106) that provides write-enable bits for each flash partition in its PCI space.

I've read somewhere that HWInit code does protect the BootROM partition from flashing as soon as it gains control on reset. That means that it isn't possible to flash anything to the protected areas from within OF until the write lock is released.

I don't know how it works on Yosemite machines though...

[darthnVader]

Ok, so the point of this thread was to see if we could extract/replace the version of Open Firmware on the logic board.

If it does indeed live in the 1mb boot rom, surely we can decode it, find it, and replace it. Likely it's compressed, so we'd have to figure the decompression algorithm.

Does anyone think it would be ELF format?

One day, I'd like to figure out how to replace Open Firmware with Open Bios, as we have the source code.

Also, there were some Yellowdog Power Servers with IBM's version of Open Firmware known as SLOF( Open Source ). These systems were able to use PC VBios video cards. So it would be nice, one day, as a goal, to be able to replace Apple's Open Firmware implementation with something of our own so we can use PC graphics cards in our PowerPC towers, without the need to flash them.

The nVidia drivers for OS X support a lot for later Graphics cards than the best we have Fcode Rom's for( GTX7800 ). We should be able to use 8800GT/X cards and later, it's just we have no FCode ROMs for them.

After the die shrink of the 7800/7900/7600 nVidia changed the format of the NVDA,BMP, and I was never able to fully decode the new format. This is why there are no FCode Roms for later cards, despite the fact I put a large amount of effort into it.

I could like give it a go again and make some new FCode Roms, it's just not worth the effort, and to tell the truth, it's a little maddening staring at a hex editor all day trying to decode it, edit it, and test it.

It would just be a lot better/easier to make PC VBios cards work out of the box. Tho it would require an injector kext driver to inject the properties the drivers expect to be in the device tree for FCode Rom cards. We really already have these injectors, thank to OS X86 project, I'd just have to recompile NVInject for PPC and make a few changes.

[Daniel]

I am not sure what the contents of it are, but it probably isn't an ELF. The first few pages (page size is 0x1000) of the bootrom will be a PowerPC exception table. Execution will start at the reset location of 0x100 in the file (0xFFF00100 in the actual physical memory map for the system).

Presumably, there will be a POST (power-on self-test) and then Open Firmware will start running. I have no idea how it does any of that.

[powermax]

I am not sure what the contents of it are, but it probably isn't an ELF. The first few pages (page size is 0x1000) of the bootrom will be a PowerPC exception table. Execution will start at the reset location of 0x100 in the file (0xFFF00100 in the actual physical memory map for the system).

Yes.

Presumably, there will be a POST (power-on self-test) and then Open Firmware will start running. I have no idea how it does any of that.

POST is called "Hardware Init" in Apple's jargon and that describes really good what's going on there: various ASICs, required for the OF to run, will be initialized. These include the memory controller, the interrupt controller, the peripherals controller and some basic hardware (PRAM, sound, display). Additionally, CPU and bus speed will be determined.

Some quick tests of the built-in memory and cache will be conducted there. But these tests are mostly there for determining memory size. Other tests based on complex check patterns are simply too slow to be performed during the cold start.

Then the startup bong will be synchronously played. After that, the OF will be decompressed into RAM and ran from there. FlashROM is usually too slow for running the OF.

The hardware initialization code is highly hardware-dependent. In other words, it will be individually compiled for each hardware configuration. It doesn't do any generic HW scanning like OF does for PCI, for example. It talks to the HW directly using predefined I/O addresses and communication protocols.

[Daniel]

Tiny bit risky, that! Would it be possible to load a new Boot ROM image from disk into RAM, then reset the machine to execute it?

I am not sure what the contents of it are, but it probably isn't an ELF. The first few pages (page size is 0x1000) of the bootrom will be a PowerPC exception table. Execution will start at the reset location of 0x100 in the file (0xFFF00100 in the actual physical memory map for the system).

Yes.

Presumably, there will be a POST (power-on self-test) and then Open Firmware will start running. I have no idea how it does any of that.

POST is called "Hardware Init" in Apple's jargon and that describes really good what's going on there: various ASICs, required for the OF to run, will be initialized. These include the memory controller, the interrupt controller, the peripherals controller and some basic hardware (PRAM, sound, display). Additionally, CPU and bus speed will be determined.

Some quick tests of the built-in memory and cache will be conducted there. But these tests are mostly there for determining memory size. Other tests based on complex check patterns are simply too slow to be performed during the cold start.

Then the startup bong will be synchronously played. After that, the OF will be decompressed into RAM and ran from there. FlashROM is usually too slow for running the OF.

The hardware initialization code is highly hardware-dependent. In other words, it will be individually compiled for each hardware configuration. It doesn't do any generic HW scanning like OF does for PCI, for example. It talks to the HW directly using predefined I/O addresses and communication protocols.

Now I really want to try and load an OF image manually. Any clue on the environment conditions like the compressed image format, starting register assignments, and memory layout when OF boots up?

I bet that if we have a client program quiesce OF, it will be able to overwrite it with a new instance that can then be run. I wonder what the level of compatibility is between OF implementations. Some of the later versions (such as the one on the Mac Mini) actually let you write to files. That would be really nice to make universal.