Print

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

[darthnVader]

I'd really like someone to try this on the Mini, as I don't have one right now.

WARNING:This could leave you Mac non-booting as we are masking PCI probing of the devices on the PCI bus, I'm hoping the Mini uses the same layout as the iBook( 6,5 ).

First boot into Open Firmware and change some value like fcode-debug?

Code: [Select]

setenv fcode-debug? true
shut-down
Now power up you Mini holding the power button, keep holding, wait for the programers tone, keep holding, wait for the boot chime, keep holding, the screen should light up in Open Firmware with the defaults loaded.

If this doesn't work do not proceed with the next steps

Assuming that worked, and we now know we can recover from a bad probe mask:

Code: [Select]

setenv pci-probe-mask 0xf8fbffff
setenv auto-boot? false
reset-all
With any luck our probe mask for the USB and Wifi are the same as they are on the iBook:

Again, we should be greeted by Open Firmware:

Code: [Select]

dev pci1 ls
We should now see that the 802.11 device and usb@1a are no longer in the device tree, they are keeping us from entering sleep.

Now boot your Mac into OS 9 and see if you can enter sleep, it should allow the power LED to pulse, if it does start pulsing, press the power button again to see if the system wakes, fingers crossed.

Let me know how it goes, or if you have an issue with that probe-mask.

Just remember, keep holding the power button to recover Open Firmware's defaults if something goes wrong.

[zefrenchtoon]

Hi
Are you still looking for someone to try this ?

Is your « warning » means that we can « brick » the Mini by doing this ?

[Daniel]

As long as the "boot while holding down power button" trick works, you can't brick it. That's an emergency recovery mode that completely ignores what NVRAM is set to, so you can use it to recover from very messed up default settings.

But yeah, the warning is that it could be bricked, if the recovery mode doesn't work for some reason (it should work, but it's definitely the sort of thing that should be tested right before you mess around).

[darthnVader]

As long as the "boot while holding down power button" trick works, you can't brick it. That's an emergency recovery mode that completely ignores what NVRAM is set to, so you can use it to recover from very messed up default settings.

But yeah, the warning is that it could be bricked, if the recovery mode doesn't work for some reason (it should work, but it's definitely the sort of thing that should be tested right before you mess around).

Yes, I'm still waiting for someone with a Mini G4 to try this.

Just check you can enter OF recovery before monkeying around with the PCI-probe-mask.

[zefrenchtoon]

Hey darth!

I did some tests on my mini.

First, I did some try and fail with different commands to familiarize with OF. (AZERTY keyboard does not help to …)
Then I did some of your commands but not all the way.

As you can see in the picture IMG_4709, here are my actual variables values.
Then I switched the fcode-debug one to true as requested (IMG_4711).
Then shut-dwon to try to get into recovery mode …
I had the programmer tone (which awaken my one year old son ) then the boot chime and finally entered into OF.
Once there, I did not find a good way to be sure that I booted using default values. 
Before trying your commands about pci-mask-probe, I did try the dev pci1 ls one to check "normal" values (IMG_4710).

Then I re-read entirely your procedure and try to understand the goal (as I am a software developer in my "real life", I have some skills to try to understand it).

And I think it will not get what you want if you check the address of usb1a and compare it to the mask you want to try.
Also, I did not find wifi in the pci1 list … but maybe I am not looking at the right keyword

Finally, I was wondering if we could not simply disconnect the bluetooth and wifi card into the mini to test because usb1a is the BT disguised into usb kb/mouse (I got a bt keyboard working in os9 so if we have to loose BT to get energy saving …  ).

Let me know of your thinking … 

I'm open to continue to do some tests.

[darthnVader]

Hey darth!

I did some tests on my mini.

First, I did some try and fail with different commands to familiarize with OF. (AZERTY keyboard does not help to …)
Then I did some of your commands but not all the way.

As you can see in the picture IMG_4709, here are my actual variables values.
Then I switched the fcode-debug one to true as requested (IMG_4711).
Then shut-dwon to try to get into recovery mode …
I had the programmer tone (which awaken my one year old son ) then the boot chime and finally entered into OF.
Once there, I did not find a good way to be sure that I booted using default values. 
Before trying your commands about pci-mask-probe, I did try the dev pci1 ls one to check "normal" values (IMG_4710).

Then I re-read entirely your procedure and try to understand the goal (as I am a software developer in my "real life", I have some skills to try to understand it).

And I think it will not get what you want if you check the address of usb1a and compare it to the mask you want to try.
Also, I did not find wifi in the pci1 list … but maybe I am not looking at the right keyword

Finally, I was wondering if we could not simply disconnect the bluetooth and wifi card into the mini to test because usb1a is the BT disguised into usb kb/mouse (I got a bt keyboard working in os9 so if we have to loose BT to get energy saving …  ).

Let me know of your thinking … 

I'm open to continue to do some tests.

Sorry it took awhile to get back to you on this, so many hacks so little time.

The pci106b,4318@12 is the AirPort Extreme card.

It is hard to say if disabling the probing of the usb@1a will disable the BT device because these are really muxed USB ports where USB1.1 and USB2 are muxed into a single connector. It is highly likely the BT device will still work at USB1.1 speeds. However that's all Open Firmware supports anyway. Tho it's still a possibility that skipping the probing of the 1a device will disable the BT device.

We have already confirmed the recovery mode, so you are good to test the pci-probe-mask I provided, as it looks like your devices( APE, USB2 ) are in the same addresses as the iBook, so the same pci-probe-mask should work.

The reason we need to disable these devices is OS 9 has no driver for them, so any PCI device installed in any OS 9 machine that has no driver will kill deep sleep because OS 9 has no way of dealing with the power management of an unknown device.

Try it and let use know!!!!!

IF the system enters deep sleep you will know, everything will power down and the power light will pulsate just like deep sleep in OS X, but you will have to wake the system by pressing the power button on the Mini as USB1.1 won't have the trickle voltage needed to wake the system.

The trickle voltage is likely something we can fix, but if the system crashes or reboots on wake from sleep like my two iBooks do, I have not found a way to debug that. I'm hoping DS works on the Mini and the crash on wake is an issue with the iBooks, but you know what they say about hope.

[Greystash]

Hey darthnVader,

Have you ever tried getting sleep to work on an unsupported PowerBook G4 (e.g. PowerBook5,2)?
I've been trying to disable devices with the following method in Open Firmware, but I haven't been able to find the devices preventing sleep:

Code: [Select]

" /pci@f2000000/mac-io@17/@3000" find-package drop delete-node
This successfully disables devices, but some of the devices listed using "devalias" which would be likely culprits don't exist, for example "wireless". I've disabled all of the obvious devices including USB etc. but haven't found a solution.

Are you aware of any particular devices/device addresses that should be disabled?