"Those interested in helping out", at this point, are generally only within the demographic of people interested in consuming 60,000 words of necessary braindumping/orientation/synchronization.

Device bringup is, as you say, complex. This complex.

Well, Dolphin is an emulator, so screenshots and videos are quite an obvious tool to demonstrate game emulation issues... and it's also easier to boil down most changes to "fixes X issue on Y game" for a mature project; that model doesn't map quite as well to the early stages of an OS port project, especially since most of the stuff in this first report is literally required to get anything to work at all. The one screenshot of the framebuffer with 8 penguins at the end effectively represents the result of the entire prior saga, and everything before it would be various flavours of "black screen", "kernel panic", "the serial port stops working", etc... not very interesting to show!

What kind of diagrams are you looking for? There's lots of things that could be diagrammed here, but comprehensively explaining every concept involved would turn this into an embedded systems course, diagrams or not. What I tried to do was give a brief introduction to concepts that are relevant to the issues we ran into, and have links for those who want to go deeper. If you have specific suggestions of bits that are hard to grok without diagrams though, please do let me know. It's tricky knowing what is most confusing to other folks when you've been neck-deep in this stuff for weeks.

The alternative to this long-form post is to just have a laundry list of things that work today, but I don't really know how I would get across what the challenges were without going into at least some level of details like I did here. I figure that if I'm going to do that, I might as well make it a more educational endeavour. Of course, if all you want to know is what works and what doesn't, it may not be for you... I'm open to suggestions though!

Keep in mind that a lot of the early work ends up being "how to find the right solution to problems" (and the post goes into more detail about this); the current feature support status of Linux on M1 almost hasn't changed for the past 30 days, because instead I've been re-visiting and re-working the code into a form that is upstreamable, as well as building tools and chipping away at little details. It's a lot of yak shaving, but it's all things that need to happen sooner or later. Unfortunately, it doesn't really tick boxes in a TL;DR bullet list of working hardware.

For my part, I loved the long form, in-depth post, and I learned a lot. I'll admit breaking it up visually with some diagrams or photos is tempting (maybe a photo of your serial setup?) but I felt the explanations were all clear without it.

Ah, that's a good point. I actually need to port over a Hugo shortcode to handle little image boxes for this kind of thing; once I have that it probably makes sense to add a little photo of my setup as an aside, not so much as an explanation but rather for visual interest.

> instead I've been re-visiting and re-working the code into a form that is upstreamable, as well as building tools and chipping away at little details. It's a lot of yak shaving

This is exactly what needs to be done to make this a viable project, and leaving this stuff out is, for me at least, what categorizes Correlium's project as a mere publicity stunt rather than a serious porting effort.

I liked the long form too because there is a lot to learn there. I really appreciate what you do. Actually one of the decisive factors for buying M1 was the fact that you work on making it gnu/linux friendly. Perhaps some shorter form in the beginning could also help for better understanding before one can comprehend all the details but if we ask for that it's better be done in a respectful way. Thank you for your hard work.