Serial adapter/reboot controller for Apple M1/M2
31–40 of 42 posts
Re: Serial adapter/reboot controller for Apple M1/M2
#32I have no idea about serial adapters, nor I need one. However, the surprising part is that it's only $20. Are they that cheap to make? The R part of R&D must be a lot more, but I assume that's work by an enthusiast rather than a business, hence the price.
Re: Serial adapter/reboot controller for Apple M1/M2
#33Earlier quoted context omitted.
Traditionally Macs have had an nvram setting that enables automatic boot when power is applied. It can be set from within the macOS power settings using the checkbox labeled "Start up automatically after a power failure". Once set, applying power will boot the OS (even an alternative OS like linux). Some variation of this feature has existed in all Macs since the earliest ones that supported software-based power cont…
One of my favourite "strange" features of my G3 Desktop Mac was "Scheduled startup". You could set a time and date, then shut down the mac. On schedule, it would boot right up (as long as it was plugged in at the time)
Re: Serial adapter/reboot controller for Apple M1/M2
#34Earlier quoted context omitted.
Elucidate us.
Frank Zappa - The Central Scrutinizer Lyrics: This is the Central Scrutinizer... It is my responsibility to enforce all the laws That haven't been passed yet It is also my responsibility to alert each and every one of you To the potential consequences Of various ordinary everyday activities You might be performing which could eventually lead to The death penalty - or affect your parents' credit rating... Our criminal…
Re: Serial adapter/reboot controller for Apple M1/M2
#35Earlier quoted context omitted.
I don't have experience with such category of electronics, but anecdotally small online sellers in my country (USA) often have troubles complying with German customs - there seems to be a high rate of packages returned to sender due to various intricacies of German import law. (Such as the 'Packaging Act' [1]) [1]: https://packhelp.com/german-packaging-act/
Agreed, this seems a likely explanation to me. I run a small hobby electronics business in my free time and although I ship some items to the EU I explicitly don't ship to Germany due to the additional complexity there; it's simply not worth my time for maybe 3 additional orders a year. I'm sure the regulation is well-intentioned (and could even be great in aggregate effect too!), but a side-effect is that it biases…
Re: Serial adapter/reboot controller for Apple M1/M2
#36Re: Serial adapter/reboot controller for Apple M1/M2
#37I have no idea about serial adapters, nor I need one. However, the surprising part is that it's only $20. Are they that cheap to make? The R part of R&D must be a lot more, but I assume that's work by an enthusiast rather than a business, hence the price.
0.2 RS2227 multiplexers x2
0.5 FUSB302BMPX
0.2 1050170001 MOLEX usb B
0.4 USB 3.1 Female Type-C, Molex would cost $1
0.008 mosfet
0.0004 capacitor x6
0.0002 resistors x8
0.02 header
~2 assembly, half of that goes to 40 pin header for the pico!
~$1 pcb
all in all ~$6 per unit
Re: Serial adapter/reboot controller for Apple M1/M2
#38Earlier quoted context omitted.
See https://github.com/AsahiLinux/docs/wiki/HW%3AUSB-PD - some of the USB-C ports respond to USB PD Vendor-Defined Messages to trigger a bunch of debug features, including rebooting the SoC or configuring one of the internal UARTs to output to two pins on the USB-C connector.
Related to anyone seeing this: https://support.apple.com/guide/apple-configurator-mac/reviv... If an update goes really wrong (ie. battery died in middle of an update), the Mac may need to go into DFU mode and get a firmware write over USB. I don't know if this is the actual format the firmware update uses, but the ports listed in the official documents match the "special" ports in the wiki there.
(1) is never overwritten
(2) is capable of accepting firmware updates over serial connection / TFTP / etc.
(3) checksums the newest firmware "partition" runs it if the checksum checks out
(4) falls back to the older "partition" of firmware if the checksum indicates corruption and/or partial update
Having had to TFTP-update several (and in one case exacto-knife jump two pins on the flash) WRT-54G firmware updates before I learned that the WRT-54G firmware update had issues with FireFox's HTTP POST implementation, I really wish firmware updates were more robust. A firmware update also bricked an early FitBit of mine.Re: Serial adapter/reboot controller for Apple M1/M2
#39Earlier quoted context omitted.
Related to anyone seeing this: https://support.apple.com/guide/apple-configurator-mac/reviv... If an update goes really wrong (ie. battery died in middle of an update), the Mac may need to go into DFU mode and get a firmware write over USB. I don't know if this is the actual format the firmware update uses, but the ports listed in the official documents match the "special" ports in the wiki there.
Honestly, with flash so cheap these days, why isn't the firmware structured as two "partitions", each with a timestamp and checksum, and a small stub that (1) is never overwritten (2) is capable of accepting firmware updates over serial connection / TFTP / etc. (3) checksums the newest firmware "partition" runs it if the checksum checks out (4) falls back to the older "partition" of firmware if the checksum indicates…
It really comes down to how much time and care the developers have in their implementation.
Re: Serial adapter/reboot controller for Apple M1/M2
#40Earlier quoted context omitted.
Related to anyone seeing this: https://support.apple.com/guide/apple-configurator-mac/reviv... If an update goes really wrong (ie. battery died in middle of an update), the Mac may need to go into DFU mode and get a firmware write over USB. I don't know if this is the actual format the firmware update uses, but the ports listed in the official documents match the "special" ports in the wiki there.
Honestly, with flash so cheap these days, why isn't the firmware structured as two "partitions", each with a timestamp and checksum, and a small stub that (1) is never overwritten (2) is capable of accepting firmware updates over serial connection / TFTP / etc. (3) checksums the newest firmware "partition" runs it if the checksum checks out (4) falls back to the older "partition" of firmware if the checksum indicates…