More actions
mNo edit summary |
mNo edit summary |
||
| Line 77: | Line 77: | ||
'''Test date''': 2025.09.26 | '''Test date''': 2025.09.26 | ||
'''Description''': Replacing UF500 by an SN25A23P bought "new" (Mobilesentrix). | '''Description''': Replacing UF500 by an SN25A23P bought "new" (Mobilesentrix), but already used in Test 2. | ||
'''OS''': Tahoe. | '''OS''': Tahoe. | ||
| Line 96: | Line 96: | ||
Test date: 2025.09.27 | Test date: 2025.09.27 | ||
Description: Replacing U5500 by an SN25A23P bought "new" (Mobilesentrix). | Description: Replacing U5500 by an SN25A23P bought "new" (Mobilesentrix), but already used in Tests 2 and 3. | ||
'''OS''': Tahoe. | '''OS''': Tahoe. | ||
| Line 110: | Line 110: | ||
The device works normally after another DFU Restore. | The device works normally after another DFU Restore. | ||
'''Conclusion:''' Major failure, and could cause major problems with after sales, since the device seems to work perfectly at first. But the next time the customer runs an update, they will lose every functionality through USB-C / Magsafe. | '''Conclusion:''' Major failure, and could cause major problems with after sales, since the device seems to work perfectly at first. But the next time the customer runs an update, they will lose every functionality through USB-C / Magsafe. The device seems to absolutely want the original U5500. | ||
The observation seems to indicate some kind of pairing of the original U5500 to the device. But it could be anything: the ROM, the SOC, the other port controllers, etc. It could be that the pairing happened the first time that IC was used, on previous tests. This is a major problem. | The observation seems to indicate some kind of pairing of the original U5500 to the device. But it could be anything: the ROM, the SOC, the other port controllers, etc. It could be that the pairing happened the first time that IC was used, on previous tests. This is a major problem. | ||
Revision as of 20:06, 27 September 2025
| Apple ACE3 Controllers | |
|---|---|
| Manufacturer | Apple |
| Code name | ACE3 |
| Release date | 2023 |
| Device type | Laptop |
This is a placeholder to document testing done with ACE3 controllers on Macbooks, and add knowledge tidbits as they trickle down. Once we understand these controllers, the page will be reorganized as a proper explanation on the ACE3.
Testing on a working A3113
Types of controllers encountered so far: SN25A23P.
ACE configuration: Controllers for receptacles are in Master - Slave configuration, Magsafe controller is Master.
Test 1: Swapping UF400 and UF500
Test date: 2025.09.26
Description: Just swapping the two controllers, from that board.
OS: Sonoma.
The device seems to work right away, and normally.
DFU Restore (Tahoe): Ok.
Display output: Ok, both receptacles.
Charging: Ok (both receptacles + Magsafe).
Data (Thunderbolt): Ok (both receptacles).
Conclusion: Nothing abnormal, it looks like both are interchangeable.
Test 2: Replacing UF400
Test date: 2025.09.26
Description: Replacing UF400 by an SN25A23P bought new (Mobilesentrix).
OS: Tahoe.
DFU Restore (Tahoe): Impossible. The board is placed in DFU mode by jumping PP1V25_S2 to PMU_UPC_FORCE_DFU, confirmation with DFU_STATUS. But it does not appear in the Finder on the host computer. Using the wrong receptacle (closest to trackpad), the target Mac appears in the Finder, but as expected cannot be restored (error 4042, timeout).
When connecting to the correct receptacle, the Terminal of the host computer outputs the following, indicating that the target Mac is detected:
Broadcast Message from root@David
(no tty) at 15:04 CEST...
amai: UARP Restore Initialize Common.
Broadcast Message from root@David
(no tty) at 15:04 CEST...
amai: Ace3UARPExternalDFUApplePropertyUpdate.
Broadcast Message from root@David
(no tty) at 15:04 CEST...
amai: Ace3UARPExternalDFUApplePropertyUpdate.
Broadcast Message from root@David
(no tty) at 15:04 CEST...
amai: Ace3UARPExternalDFUPropertiesComplete.
Display output: Ok, both receptacles.
Charging: Ok (both receptacles + Magsafe).
Data (Thunderbolt): Ok (both receptacles).
Conclusion: Nothing abnormal within the OS, but executing a DFU Restore is not possible anymore.
Test 3: Replacing UF500
Test date: 2025.09.26
Description: Replacing UF500 by an SN25A23P bought "new" (Mobilesentrix), but already used in Test 2.
OS: Tahoe.
The device seems to work right away and normally.
DFU Restore (Tahoe): Ok.
Display output: Ok, both receptacles.
Charging: Ok (both receptacles + Magsafe).
Data (Thunderbolt): Ok (both receptacles).
Conclusion: Nothing abnormal, it looks like UF500 can be changed by a "new" SN25A23P.
Test 4: Replacing U5500
Test date: 2025.09.27
Description: Replacing U5500 by an SN25A23P bought "new" (Mobilesentrix), but already used in Tests 2 and 3.
OS: Tahoe.
The device seems to work right away and normally (every USB function is working), until a DFU Restore is tried. It goes through without errors. Then the device loses all communication functionality through USB-C, in particular no-charging, no boosting to 20V.
Listening on the I2C1 bus shows that 0x3B is present at power up, but disappears after a few seconds. This indicates that U5500 turns on initially, and is then told to shut down.
The problem is still present after a new DFU Restore.
The problem is still present after reinstalling the original U5500.
The device works normally after another DFU Restore.
Conclusion: Major failure, and could cause major problems with after sales, since the device seems to work perfectly at first. But the next time the customer runs an update, they will lose every functionality through USB-C / Magsafe. The device seems to absolutely want the original U5500.
The observation seems to indicate some kind of pairing of the original U5500 to the device. But it could be anything: the ROM, the SOC, the other port controllers, etc. It could be that the pairing happened the first time that IC was used, on previous tests. This is a major problem.