PowerMac 7100 and Linux

joevt

Tinkerer
Mar 5, 2023
135
47
28
I searched my Copland disk image for occurrences of a snippet from the nvramrc and found 7 occurrences.
I mounted the disk image and searched only the HFS partition which also has 7 occurrences which means all occurrences are in the HFS partition.
I take the offsets and divide them by 512 to get block numbers, then use fsck_hfs to get inode numbers.
I mount the disk in Leopard which supports HFS so that I can convert inode numbers to file paths.
Leopard doesn't have the -B option for fsck_hfs.

Code:
# Note grep -b doesn't work well in earlier macOS versions - it gets offset of line instead of occurrences in the line.
grep -a -b -o 'boot-device 2dup drop " /AAPL,ROM" comp if try then' Copland.dmg | perl -pe 's/:.*//'
hdiutil attach -nomount Copland.dmg
grep -a -b -o 'boot-device 2dup drop " /AAPL,ROM" comp if try then' /dev/disk15s9 | perl -pe "s/:.*//" > /tmp/offsets.txt
perl -ne '
    printf("%d ", ($_ / 512));
' /tmp/offsets.txt > /tmp/blocks.txt
fsck_hfs -B /tmp/blocks.txt /dev/disk15s9

# Mount the disk in a version of macOS that supports HFS, such as Leopard
# because FuseHFS does not use HFS inode numbers
diskutil mount disk15s9

GetFileInfo="GetFileInfo"
command -v GetFileInfo > /dev/null 2>&1 || {
    GetFileInfo="/Developer/Tools/GetFileInfo"
}

# Use this to get the volume id of the Copland partition:
stat /Volumes/Copland

# Use this to get the path for a file with volume id/inode number:
"$GetFileInfo" -P "/.vol/234881036/721"

# If it doesn't work then use find:
find /Volumes/Copland -inum 721

# Or use ls:
ls -liR /Volumes/Copland

All the important occurrences seem to be in Mac OS Loader. Here's a list of interesting resources in that file:
Code:
'opfw' (0).                         \ DBOF xcoff for NuBus Macs
'ofpt' (1, "OFPatches").            \ patches for OF not DBOF?
'ofpt' (2, "CONTROL Driver").       \ control
'ofpt' (3, "Platinum Driver").      \ platinum
'ofpt' (4, "Name Registry NVRAM").  \ OF code to load nvram properties into OF?
'ofpt' (128, "auto-boot?").         \ auto-boot? default value?
'ofpt' (129, "use-nvramrc?").       \ use-nvramrc? default value?
'ofpt' (130, "boot-command").       \ boot-command default value for OF?
'ofpt' (131, "load-base").          \ load-base default value?
'ofpt' (4177, "nvramrc").           \ nvramrc for OF not DBOF?
'ofpt' (-15, "nvramrc").            \ nvramrc for DBOF
'ofpt' (-14, "boot-command").       \ boot-command default value for DBOF?
'boot' (1).                         \ default boot block
'nkld' (128).                       \ new kernel loader?
'2ldr' (1, "SecondaryLoader").      \ secondary loader
'nvrm' (0).                         \ DBOF nvram source (modified by above overrides?)

I guess you'll want to look at 'ofpt' (131) and 'nvrm' (0).
load-base and real-base are at a specific offsets in the nvrm.
 

speakers

Tinkerer
Nov 5, 2021
140
92
28
San Jose, CA
peak-weber.net
I searched my Copland disk image for occurrences of a snippet from the nvramrc and found 7 occurrences.
I mounted the disk image and searched only the HFS partition which also has 7 occurrences which means all occurrences are in the HFS partition.
I take the offsets and divide them by 512 to get block numbers, then use fsck_hfs to get inode numbers.
I mount the disk in Leopard which supports HFS so that I can convert inode numbers to file paths.
Leopard doesn't have the -B option for fsck_hfs.
Thanks for this effort. It does seem to show that the Loader constructs nvram in memory from using a number of its resources.
All the important occurrences seem to be in Mac OS Loader. Here's a list of interesting resources in that file:
Code:
'opfw' (0).                         \ DBOF xcoff for NuBus Macs
'ofpt' (1, "OFPatches").            \ patches for OF not DBOF?
'ofpt' (2, "CONTROL Driver").       \ control
'ofpt' (3, "Platinum Driver").      \ platinum
'ofpt' (4, "Name Registry NVRAM").  \ OF code to load nvram properties into OF?
'ofpt' (128, "auto-boot?").         \ auto-boot? default value?
'ofpt' (129, "use-nvramrc?").       \ use-nvramrc? default value?
'ofpt' (130, "boot-command").       \ boot-command default value for OF?
'ofpt' (131, "load-base").          \ load-base default value?
'ofpt' (4177, "nvramrc").           \ nvramrc for OF not DBOF?
'ofpt' (-15, "nvramrc").            \ nvramrc for DBOF
'ofpt' (-14, "boot-command").       \ boot-command default value for DBOF?
'boot' (1).                         \ default boot block
'nkld' (128).                       \ new kernel loader?
'2ldr' (1, "SecondaryLoader").      \ secondary loader
'nvrm' (0).                         \ DBOF nvram source (modified by above overrides?)
I guess you'll want to look at 'ofpt' (131) and 'nvrm' (0).

This is consistent with what I see in ResEdit for the Loader:
Screenshot 2025-07-14 at 9.43.56 AM.png

This is taken from the install kit. I can edit 'auto-boot?' to false, re-install and have it take effect. However, changes to 'load-base' have no effect and 'real-base' is absent.

load-base and real-base are at a specific offsets in the nvrm.

Looking at the Copland Installer, I see the resource 'nvd$':
Screenshot 2025-07-14 at 9.56.03 AM.png

This appears to be a dictionary of OFW variables. Perhaps it's their offsets into the in-memory nvram???

The 'nvrm' resource is 8k of mostly zeroes but with a small chunk containing the values of 'boot-command', 'input-device', 'output-device', 'diag-device' and 'boot-device'. Although after installation it also includes a string starting '" kbd" find-device'.

Note that on my real 7100, I can (using the original subject of this thread) boot Debian to poke in the Copland volume. The tools may be more reliable than Leopard's.
 

joevt

Tinkerer
Mar 5, 2023
135
47
28
This appears to be a dictionary of OFW variables. Perhaps it's their offsets into the in-memory nvram???
Appears to be C strings followed by variable type and bit number or offset (01=boolean, with bit number, 02=number with offset to value, 03=string with offset to string)

So `real-base` is at offset 0x10 in the nvrm resource. It seems to have a value of FFFFFFFF = -1 in the Mac OS Loader resource fork.

You can look at the DingusPPC source code to see the format of the Old World NVRAM variables.

I think New World NVRAM variables use strings for the number types. Look at the DingusPPC source code to be sure.

The string starting with '" kbd" find-device' is for the nvramrc string variable.
 
Last edited:

speakers

Tinkerer
Nov 5, 2021
140
92
28
San Jose, CA
peak-weber.net
I've now confirmed that the nvrm resource of Mac OS Loader can be edited to change the initial value of 'real-base' and 'load-base' variables etc. And it is indeed necessary to update the checksum word (16-bit word offset 2) of the resource.

I use DeRez on OSX to decompile the resource fork of Mac OS Loader to produce a text description file of the nvrm resource. This file can be updated with modified values and a python script used to update the checksum. I could't convince Rez to reconstitute the binary, so I use ResEdit to edit word changes into the active MAc OS Loader image in Mac OS Folder.

However, the Copland DBOF seems intolerant to changes to real-base: only -1 or 0x400000 appear viable :(

And I still can't find a load-base setting to avoid claim failure when loading client code (ofwboot in particulat). I'd like to get a memory map of allocated spaces managed by OFW so I could resolve this.
 

joevt

Tinkerer
Mar 5, 2023
135
47
28
And I still can't find a load-base setting to avoid claim failure when loading client code (ofwboot in particulat). I'd like to get a memory map of allocated spaces managed by OFW so I could resolve this.
You have the Open Firmware code (assembly and Forth) from my dump. You can look at the code to see what's happening. I don't know when real-base and load-base are setup/used - is it before Open Firmware has started (in System 7), or in the Open Firmware init code (Part1.txt) or in Open Firmware (Part2.of)?

The available property in /memory (memory ihandle in /chosen) shows physical RAM addresses that are available.
The available property in the cpu node (mmu ihandle in /chosen) shows virtual addresses that are available.
The translations property in the cpu node has a list of current translations.

The lists of ranges are kept in queues (mem-avail and vert-avail). Here's some code I created for later Open Firmware versions that can dump them.
Code:
: dump-vt { ; q entry }
    cr
    translations dup -> q
    >q.next@ -> entry
    begin
        entry q <>
    while
        entry >vt.virt @ ."  virt:" 8 u.r
        entry >vt.size @ ."  size:" 8 u.r
        entry >vt.phys @ ."  phys:" 8 u.r
        entry >vt.mode @ ."  mode:" 8 u.r
        cr
        entry >q.next@ -> entry
    repeat
    ;

: dump-avail ( q -- ) { q ; entry }
    cr
    q >q.next@ -> entry
    begin
        entry q <>
    while
        entry >fa.addr @ ."  addr:" 8 u.r
        entry >fa.size @ ."  size:" 8 u.r
        cr
        entry >q.next@ -> entry
    repeat
    ;

\ available physical address for RAM \ ra-prop|mem-avail|claim-mem|release-mem
\ words: claim-mem release-mem
\ device: memory ; words: claim = claim-mem, release = release-mem ; properties: available
\ - on initialization, the amount of RAM detected at startup is released.
\ - claims first 16K of RAM for interrupt vectors
\ - used during probing of PCI (with mapping)
mem-avail dump-avail

\ available physical addresses for I/O \ real-avail|claim-real|release-real
\ words: claim-real (for claiming physical addresses for I/O and PCI devices) release-real
\ - on initialization, releases the range 0x80000000..0xFFFFFFFF.
real-avail dump-avail

\ available virtual addresses \ va-prop|virt-avail|claim-virt|release-virt
\ words: claim-virt release-virt
\ device: cpus ; words: claim release ; properties: available
\ device: macparts ; words: map-space (claims mem and virt and maps them)
\ - on initialization, releases ranges 0x0000000..virt_base-1 and virt_base+1MiB..rombase=0ffc00000-1
virt-avail dump-avail

\ translations
\ device: cpu ; properties: translations
dump-vt

mem-avail dump-avail
real-avail dump-avail
virt-avail dump-avail
dump-vt

@startvec contains a list of fields. Many of them point to structures in memory. The following code lists the fields of @startvec and the values for each field:
Code:
\ For Open Firmware 2.4 and earlier, >h.count needs to be changed to 4+ because xt>hdr points to >h.flags instead of >h.link

: dump-fields { addr fcodestart fcodeend ; token ptr }
    cr
    fcodeend 1+ fcodestart do
        i ." 0x" 4 u.r space
        i get-token drop -> token
        0 token execute 4 u.r space
        addr token execute dup 8 u.r space
        token name.
        #out @ d# 42 < if d# 42 #out @ - spaces then
        @ -> ptr
        ptr 8 u.r space
        \ check if the field might point to a xt token and if so, output its name
        ptr @startvec u> ptr 7 and 0= and if
            ptr xt>hdr 4+ ( >h.count ) dup c@ + 8 + -8 and ptr = if ptr name. then
        then
        cr
    loop
;

: dump-startvec
    \ Dump all fields of @startvec
    @startvec 48a 4d1 dump-fields ;

dump-startvec

I believe copland @startvec fields have fcode numbers 48a ... 4d1. This will be different in different versions of Open Firmware.

Once you dump the fields and their values, you can sort by values to get a memory map (but some fields are not pointers so you should remove those from the memory map).

Here's an example from a Beige G3 with OF 2.4:
Code:
\=========================================================================================
\ Open Firmware memory map for OF 2.4
\
\ fields marked "\ real" store a real address (change FF8 to 004)

FF800000  >real_base     \ real
FF800000  >virt_base     
FF800400  >dp            
FF800800  >rp            
FF800C00  >lp            
FF801000  >fp            
FF801800  >ep            
FF801C00  >tib           
FF802000  >noname        
FF804000  >ttp           
FF808000  >regsvalid?    
FF808940  >endiango      
FF809D10  >'<sc-int>     \ real
FF809E18  >'cientry      cientry 
FF80A350  >'(poplocals)  (poplocals) 
FF80D0B0  >'ferror       ferror 
FF80D8D0  >'my-self      
FF80F738  >'cold-load    cold-load 
FF811FA0  >'abort        abort 
FF8179A8  >'quit         quit 
FF818350  >'cold-init    _cold-init 
FF819338  >'excp         _exception 
FF819638  >'syscatch     _syscatch 
FF829498  >'cicall       cicall 
FF82A3D0  >ciwords       
FF85D4E8  >word-list     
FF85D524  >here          
FF8D0000  >free-bot      
FF8D6000  >ttp800        
FF8DF600  >intvectv      
FF8DF600  >intvectr      \ real
FF8DF800  >ciregsv       
FF8DF800  >ciregsr       \ real
FF8DFA00  >ofregsv       ^-720600  
FF8DFA00  >ofregsr       \ real
FF8DFC00  >real-vt-hd    \ real
FF8E0000  >free-top      
FF8E0000  >htab          \ real
FF8F0800  >dl-buf
All of these are in the Open Firmware range (1MB virtual address range FF800000 .. FF8FFFFF). Later versions of Open Firmware have larger ranges (up to 3 MB in the latest).

You can convert physical addresses to/from virtual addresses using virt->real[icode] and [icode]real->virt but only for addresses related to virt_base and real_base? Otherwise, you can use the translate method of the mmu ihandle (or use do-translate anywhere) to convert a virtual address to a physical address which will use the translations list.

Since we can dump most of the Open Firmware DBOF, we can also modify it using a reverse process (may need to update some fields in @startvec which has default values in the beginning of DBOF). The Forth fcode tokenizer needs to be updated to handle some Apple Open Firmware features.
 

speakers

Tinkerer
Nov 5, 2021
140
92
28
San Jose, CA
peak-weber.net
Thanks greatly for these code snippets which (except for dump-vt) work well on my 7100 and Beige G3.

The main issue with the 7100 appears to be its discontiguous RAM. Banks are separated by awkward holes that results in OFW claim failures loading the BSD Booter, ofwboot.xcf. There's also reserved chunks of low memory used by the keyboard and framebuffer requiring special handling.

I've built a modified BSD booter that works around the memory discontinuity and this now boots. So .. some progress!
 

joevt

Tinkerer
Mar 5, 2023
135
47
28
Thanks greatly for these code snippets which (except for dump-vt) work well on my 7100 and Beige G3.
You should be able to correct dump-vt for the versions of OF that it doesn't work on.
It works for me with DingusPPC pm6100 with Copland DBOF. What error are you seeing?
Code:
 virt:00000000 size:00040000 phys:00000000 mode:00000000
 virt:00040000 size:00040000 phys:00040000 mode:00000028
 virt:F8000000 size:00001000 phys:F8000000 mode:00000028
 virt:FF800000 size:00100000 phys:00400000 mode:00000010
 virt:FFC00000 size:00400000 phys:FFC00000 mode:00000000

The translations queue is hidden (words are headerless) in OF 1.0.5 and on Beige G3 with OF 2.0f1. Is that the ROM you have?
later Beige G3's have OF 2.4 which does not use headerless.

The following code in nvramrc will add the hidden words:
Code:
h# fb2 get-token drop execute \ (install-console)
." hello" cr
defer translations
h# 80d get-token drop to translations
struct			
/n field >q.next
/n field >q.back
constant /q		
struct				
/q field >vt.queue	
/n field >vt.virt	
/n field >vt.size	
/n field >vt.phys	
/n field >vt.mode	
constant /vt-list-size
: >q.next@ dup >q.next @ + ;
." [ probe-all" cr
probe-all
." ] probe-all" cr
banner

It calls (install-console) so that it can output text to serial port before PCI slots are probed (useful for debugging). You can remove that code if you're using the screen and keyboard for I/O.

The main issue with the 7100 appears to be its discontiguous RAM. Banks are separated by awkward holes that results in OFW claim failures loading the BSD Booter, ofwboot.xcf. There's also reserved chunks of low memory used by the keyboard and framebuffer requiring special handling.

I've built a modified BSD booter that works around the memory discontinuity and this now boots. So .. some progress!
The memory holes should be described by missing ranges in the memory available list. I think an Open Firmware boot loader should honour the info in that list.

Are the chunks of low memory not described by holes in the available lists or by translations?

Here's code to test all pages in the 4 GB memory range to see what virtual addresses are mapped. The errors are PPC exception vector addresses (200 for machine check, 300 for DSI, 900 for decrementer exception).
Code:
: test-ranges ( max min -- )
    { _max _min ; _rerr _err }
    cr 
    -1 -> _rerr
    _max _min do
        ( ) i ['] l@ catch ?dup if -> _err drop else 0 -> _err drop then
        _err h# fffff and 900 = if
            i ['] l@ catch ?dup if -> _err drop else 0 -> _err drop then
        then
        _err _rerr <> if
            i 8 u.r ." : "
            _err if ." error " _err 8 u.r then
            cr
            _err -> _rerr
        then
    1000 +loop
    ;

-1 0 test-ranges

The ranges should align with those in translations
 

speakers

Tinkerer
Nov 5, 2021
140
92
28
San Jose, CA
peak-weber.net
You should be able to correct dump-vt for the versions of OF that it doesn't work on.
It works for me with DingusPPC pm6100 with Copland DBOF. What error are you seeing?
It does work for OF 2.4 on my G3 (I mispoke) but on DBOF 2.0, I get translatiions, no word as you surmise.
...
later Beige G3's have OF 2.4 which does not use headerless.

The following code in nvramrc will add the hidden words:
Code:
h# fb2 get-token drop execute \ (install-console)
." hello" cr
defer translations
h# 80d get-token drop to translations
struct           
/n field >q.next
/n field >q.back
constant /q       
struct               
/q field >vt.queue   
/n field >vt.virt   
/n field >vt.size   
/n field >vt.phys   
/n field >vt.mode   
constant /vt-list-size
: >q.next@ dup >q.next @ + ;
." [ probe-all" cr
probe-all
." ] probe-all" cr
banner
Using the above, I get this error when running dump-vt:
Code:
0 > dump-vt 
DEFAULT CATCH!, code=FFFFFFF3 at   %SRR0: FF80BC14   %SRR1: 00000030 
 ok

The memory holes should be described by missing ranges in the memory available list. I think an Open Firmware boot loader should honour the info in that list.

On-board 8MB RAM is 0x0-0x800000 with additional 8MB SiMMS at 0x1000000 (bank1) and 0x5000000 (bank2):
Code:
0 > mem-avail dump-avail 
addr:00080000 size:00080000
addr:00200000 size:00200000
addr:00500000 size:00300000
addr:01000000 size:00800000
addr:05000000 size:00800000
 ok
The booter ofwboot.xcf is built to load/run at 0xe00000 which can't be honored.

Your test-ranges snippet fails for me as follows:
Code:
0 > -1 0 test-ranges 
00000000: 
00080000: error FFF00300
DEFAULT CATCH!, code=FFF00200 at   %SRR0: FF8096B4   %SRR1: 00000030 
 ok
 

joevt

Tinkerer
Mar 5, 2023
135
47
28
but on DBOF 2.0, I get translatiions, no word as you surmise.
But translations should exist as a word in Copland DBOF 2.0:
Code:
0 > see translations
buffer: translations  ok
Are you using Copland D11E4 or an earlier version? I haven't looked at earlier versions.

Using the above, I get this error when running dump-vt:
Code:
0 > dump-vt 
DEFAULT CATCH!, code=FFFFFFF3 at   %SRR0: FF80BC14   %SRR1: 00000030 
 ok
80d get-token drop is only going to work inside the nvramrc before probe-all

At the OF prompt, 80d get-token drop will return the execution token of ferror which contains -D throw which is the code -D=FFFFFFF3 that you see in the error message. Basically, the error passed to throw is how you find where the error came from.
Code:
0 > h# 80d get-token drop (see) 
: ferror 
  -D throw ; ok

Since translations is not a word in the Open Firmware IEEE-1275 spec, it's fcode number 0x80d is a user defined number (≥0x800) and it could be different in other versions of Open Firmware if any words were added or removed between versions before translations is defined. DBOF of Copland D11E4 and OF 2.0f1 both happen to use 0x80d for the translations word. Here is the fcode number used in some other versions of Open Firmware:

Code:
1.1.22       80d
2.0 Copland  80d
2.0a9        80d
2.3          80d
2.4          80d
3.1.0f1      810
3.1.3f2      810
3.1.3f3      810
3.2.4f1      810
3.3.2f1      810
4.1.0f1      810
4.1.7f4      810
4.1.8f5      810
4.1.9f1      810
4.2.5f1      158d
4.2.7f1      158d
4.2.8f1      810
4.3.2f1      158d
4.4.0f1      1590
4.4.1f1      1590
4.4.5f3      1646
4.4.8f2      1647
4.5.4f1      1693
4.5.7f1      1717
4.5.8f1      1718
4.6.0f1      1717
4.6.2f1      171a
4.6.4f1      1734
4.7.1f1      17c4
4.8.5f0      1860
4.8.7f1      1949
4.8.9f4      198f
4.9.3f0      1a5b
4.9.4f1      1a5b
4.9.5f3      1a6e
4.9.6f0      1a6e
5.1.5f2      1816
5.2.7f1      1ab8
Any version not listed is one I don't have or where translations is defined as a headerless word (where the name is not included in the fcode).
Note how versions of OF after 4.2.5f1 have 16-bit fcode numbers (against the IEEE-1275 spec of 12-bit fcode numbers). Apple decided they needed more fcode numbers.

On-board 8MB RAM is 0x0-0x800000 with additional 8MB SiMMS at 0x1000000 (bank1) and 0x5000000 (bank2):
Code:
0 > mem-avail dump-avail 
addr:00080000 size:00080000
addr:00200000 size:00200000
addr:00500000 size:00300000
addr:01000000 size:00800000
addr:05000000 size:00800000
Your available ranges overlap 100% with the RAM ranges that you listed as expected.

The RAM layout is described by the reg property of memory
For my pm6100 in DingusPPC, I see the RAM DIMMs have consecutive ranges when using 8+8+8 MB:
Code:
0 > dev /memory  ok
0 > .properties 
name                    memory
device_type             memory
reg                     00000000  00800000 
                        00800000  00800000 
                        01000000  00800000 
available               00080000 00080000
                        00200000 00200000
                        00500000 01300000
All the ranges in the available list overlap 100% with ranges in the reg list as expected.

Using 8 (onboard)+64+64 MB DIMMS results in discontiguous memory ranges:
Code:
0 > dev /memory  ok
0 > .properties 
name                    memory
device_type             memory
reg                     00000000  00800000 
                        10000000  04000000 
                        08000000  04000000 
available               00080000 00080000
                        00200000 00200000
                        00500000 00300000
                        08000000 04000000 
                        10000000 04000000
All the ranges in the available list still overlap 100% with ranges in the reg list as expected.
It's easier to see if you convert the start length pairs to start stop ranges:
Code:
reg: [00000000, 00800000)  available: [00080000, 00100000), [00200000, 00400000), [00500000, 00800000)
reg: [08000000, 0C000000)  available: [08000000, 0C000000)
reg: [10000000, 14000000)  available: [10000000, 14000000)

The booter ofwboot.xcf is built to load/run at 0xe00000 which can't be honored.
Hence the need for you to create your modified BSD booter.

Your test-ranges snippet fails for me as follows:
Code:
0 > -1 0 test-ranges 
00000000: 
00080000: error FFF00300
DEFAULT CATCH!, code=FFF00200 at   %SRR0: FF8096B4   %SRR1: 00000030 
 ok
Strange that it couldn't catch that machine check exception. I have catch in all the places that it is needed. I wonder if a double catch would work? You could try changing both occurrences of l@ to c@
 

joevt

Tinkerer
Mar 5, 2023
135
47
28
Strange that it couldn't catch that machine check exception. I have catch in all the places that it is needed. I wonder if a double catch would work? You could try changing both occurrences of l@ to c@
Here's an implementation with a second level of catch:
Code:
0 value _rerr
0 value _page
0 value _err

: test-ranges ( max min -- )
    do
    	i to _page
        ( ) i ['] l@ catch ?dup if to _err drop else 0 to _err drop then
        _err h# fffff and 900 = if
	        i ['] l@ catch ?dup if to _err drop else 0 to _err drop then
        then
		_err _rerr <> if
            i 8 u.r ." : "
            _err if ." error " _err 8 u.r then
            cr
            _err to _rerr
        then
    1000 +loop
    ;

: test-all
    cr 
	0 to _page
    -1 to _rerr
    -1 0 test-ranges
	begin
		( ) -1 _page ['] test-ranges catch ?dup if to _err else 0 to _err then
		_err if
			-1 _page ['] test-ranges catch ?dup if to _err else 0 to _err then
	        _err if _page 8 u.r ." = error " _err 8 u.r then
            _err to _rerr
            _page h# fffff000 < if
	            _page h# 1000 + to _page
	            false
	        else
	        	true
	        then
		else
			_page h# fffff000 =
		then
	until
	;

test-all
 

speakers

Tinkerer
Nov 5, 2021
140
92
28
San Jose, CA
peak-weber.net
Are you using Copland D11E4 or an earlier version? I haven't looked at earlier versions.
Yep, D11E4.

And I do see translations. And dump-vt is now working for me!

I've mucked further with the memory config which may be the issue (again). DBOF didn't boot when I had 8+32+32+32+32; it booted with 8+0+0+8+8 but dump-vt failed; now with 8+8+8+0+0 dump-vt is good.
 

joevt

Tinkerer
Mar 5, 2023
135
47
28
Neither changing l@ to c@ nor using the new method makes a difference. Same error exactly. :(
An external variable _page is used to keep track of where it stopped. What's the value? Can you read from the address manually?
Code:
cr _page 8 u.r cr
cr _page c@ . cr
cr _page ['] c@ catch if ." error: " 8 u.r cr else . then

If you give an example of a bad address, then I can make DingusPPC do the same exception to see if test-all has the same behavior in DingusPPC.

I don't think you need to get further into this problem for your boot loader. If one wanted to get to the bottom of this problem, then one might do the following :

Check the exception table code to see what's happening. Is the exception handler for 200 (machine check) different than 300 (DSI)?

Use the python tbxi dump command to dump the pm7100 rom.
https://github.com/elliotnunn/tbxi

There's an ExceptionTable file created in the dump. Compare that with what Open Firmware has (FFF00000, FFF0C000]
Code:
FFF00000 C000 dump
I guess they would be different since OF has different requirements than whatever the ROM needs to do for normal boot?

Compare the 256 bytes of FFF00200 and FFF00300.
I guess they would be similar in normal OF but maybe different in DBOF?

Since DBOF is the only version of Apple Open Firmware with a disassembler, try this:
Code:
FFF00000 dis
dis may encounter an exception when disassembling some instructions (I'm not sure why - I think it might try to read from the effective address of some branches?). badaddress l@ . those addresses, then continue dis at the badaddress + 4.

My DumpMacRom.sh script can also disassemble PPC instructions.
https://github.com/joevt/OpenBIOSStuff
Use it like this:
Code:
OpenBIOSStuff="/Volumes/Updates/Docs/Open_Firmware_and_Forth/OpenBIOS/joevt-OpenBIOSStuff"
PATH="$OpenBIOSStuff"/detok/obj-amd64:"$OpenBIOSStuff"/toke/obj-amd64:"$OpenBIOSStuff"/macOS:/Volumes/Work/Programming/lzss/joevt-lzss:/usr/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/joevt/Library/Python/2.7/bin:/opt/X11/bin:/Library/Apple/usr/bin

thefile="path to ExceptionTable"
DumpStartDir="$(dirname "${thefile}")/DumpStart"
fullpath="$(realpath "${thefile}")"
mkdir -p "$DumpStartDir"
pushd "$DumpStartDir"
	DumpMacRom.sh -d "${fullpath}" > /dev/null
popd

The relevant file that is created in this case is All.txt.

The Open Firmware part of a ROM is saved by tbxi in a file called OpenFW
My DumpMacRom.sh script was meant for that part of a ROM. It dumps the PPC assembly into Part1.txt and fcode (converted to Forth) into Part2.of

The tbxi dump may include a DeclData file. My SlotsParse command can parse the contents. It contains SlotManager data for the Mac. PCI Macs have a minimal DeclData. New World Macs have none.
https://github.com/joevt/SlotsDump
Use it like this:
Code:
./SlotsParse "DeclData" > "DeclData.parsed.txt"

Some files produced by tbxi may be PEF or XCOFF.
Use the file -b command to detect the type of the file.

MPW has commands DumpPEF and DumpXCOFF that can disassemble those file types. You can use MPW commands in modern macOS:
https://github.com/ksherlock/mpw
 

joevt

Tinkerer
Mar 5, 2023
135
47
28
I've mucked further with the memory config which may be the issue (again). DBOF didn't boot when I had 8+32+32+32+32; it booted with 8+0+0+8+8 but dump-vt failed; now with 8+8+8+0+0 dump-vt is good.
didn't boot - are you talking about booting Copland or getting into DBOF? Are you saying you can't get into DBOF with 8+32+32+32+32?

Not sure how dump-vt could fail. word not found? Not sure how words can disappear depending on RAM layout unless something got corrupted?

Output from dev / ls unselect-dev " devalias" evaluate " printenv" evaluate dump-device-tree words in each case might be interesting.

You'll probably want your BSD boot loader to work with any possible memory config?
 

speakers

Tinkerer
Nov 5, 2021
140
92
28
San Jose, CA
peak-weber.net
didn't boot - are you talking about booting Copland or getting into DBOF? Are you saying you can't get into DBOF with 8+32+32+32+32?
It failed to launch Copland with 136MB. I don't know if it got into DBOF because that was before I discovered how to override auto-boot?

I'll need to re-install the larger SIMMs and that's awkward on the PM7100 since memory is under the drive chassis which requires the machine to be dismantled. Later form-factors like the G3 were much more serviceable in this respect.