Does the m1/m2 expose a serial port on the USB-C connector? I haven't seen that outside of mobile phones that require special debugging jigs (most requiring a secret resistor values between various pins to turn it on).
This actually looks like something I needed to build for some low-level bootloader work, and I had exactly the same sort of poor failure rate for my USB switches. I chalked it up to my inexperience in board design at the time, but I guess the board production house might have just been pretty poor.
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.
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 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.
If a sufficiently robust integrity check is used, then an update failure is just a no-op, not a bricked (or even reduced capability) device, no?
Now, pushing a bad firmware version is another story, and impossible to prevent unless the firmware updater contains some impossibly complex static analysis tools to formally verify some set of correctness properties of the incoming update.
This is far more sophisticated than the protocol I was working with, cool!
In my design I needed to do the a similar thing -- physically switch the USB2.0 lines between USB and raw serial. Using the pico for a USB serial gadget is smart. I used a USB/serial adapter for my project and it was a PITA.
Providing tooling for entry is important if you want to grow an ecosystem (developers, developers, developers, developers!). This will probably significantly help people get into low level M-chip development.
It's a small number of people, but with huge multiplying force. Selling these is likely well worth the effort if you want the ecosystem to expand.
Why would apple ever release an SBC product? I could understand if a community grows up around repurposing iPhone logic boards, but sourcing their laptop SoCs or boards wouldn't be feasible commercially.
If it's about developing the ARM ecosystem, the Pi boards have systemready certification with ACPI tables and all the creature comforts, with supply issues improving.
As a consumer, a hypothetical Zen4 APU SBC would perform better (7840u) on both performance-per-watt and absolute performance metrics compared to equivalent price M series, while giving you access to the mature x86 ecosystem.
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 institutions are full of little creeps like you
Who do wrong things
[...]
Can it be used to power on a shutdown device? AFAIK one of issues with running Macs in datacenters is that they do not turn on by themselves after being connected to power (which makes sense for consumer HW, but is a PITA when someone has to go and physically click a power button).
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 control (~1990s era). I have not personally checked whether arm64 Macs have this feature, but I'd be surprised if they don't.
Most desktop computers are able to do this, pretty sure. I've used this on an old Dell plus a UPS with outlets that only activate when the PC is on to build an over complicated timer for a lamp before
I 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.
Yes wholistically this is probably only looking to cover costs. The low volume maunfacturing may be half that but you end up with so many other costs.
Still many many orders of magnitude simpler then the cheeper PI it plugs in to, which saves enough with scale to be viable.
Tangentially related. I’ve been doing a bunch of work with ESP32-S3 boards which have a direct to USB connection. Every so often this seems to completely jam up and only a hard reboot (actually power cycling the machine) seems to unstick things. Does anyone know of a way to reset the Mac’s USB driver/system?
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])
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 the market in favor of larger companies who can afford to hire compliance specialists.
If you look at it from the German perspective, I think a person who is in/from Germany and has a small online hobby electronics shop would not be impacted by this the same way you are - thus, I believe the side effect you mention could be seen as biasing the market in favor of domestic small entities, as opposed to international ones, which might be good for a self sufficient economy. Feature not a bug, basically, is my suspicion. Although I suspect the intended target is more likely to be on Aliexpress than Tindie.
I follow another small project who had to stop shipping from the UK to the EU from Tindie, because Tindie wasn't handling the VAT requirements that brexit opened them up to.
I can't promise I'm up to date on that - that was two years ago, but they're still selling to the EU from their own site, and rest of world from Tindie. So I'm working to the assumption that they wouldn't still refuse EU sales from Tindie unless they felt they still needed to.
More info in the README: https://git.kernel.org/pub/scm/linux/kernel/git/maz/cs-hw.gi...
This actually looks like something I needed to build for some low-level bootloader work, and I had exactly the same sort of poor failure rate for my USB switches. I chalked it up to my inexperience in board design at the time, but I guess the board production house might have just been pretty poor.
EDIT: I used a TS3USB30ERSWR in my design.