Thank you to everyone who responded about the 3D printing: a special update is being drafted. The pre-production EOMA68-A20 revision 2.7.4 samples arrived and have been tested. Decisions need to be made on how to deliver OSes to people.
Briefly: a huge thank you to everyone who responded regarding the Existential 3D Printing Moments, particularly to those people who provided valuable corrections as well as offers of assistance. A more comprehensive update will follow.
These pre-production samples were where the decision was made to remove the problematic (and end-of-life) legacy TSSOP-48 NAND IC. Interestingly, it was learned that the use of these same TSSOP-48 NAND ICs has caused major corporations to cancel mass-produced products very recently. From the prior update I outlined why this NAND IC had to go: the good news is that, hardware-wise, the re-routing to use the A20’s SDC2 and SDC0 worked perfectly.
The annoying news is that the software is lacking: the standard 2015 sunxi u-boot expects to see only one microSD card. So I modified u-boot SPL to attempt to load u-boot from sector 32 from first SDC0 and if that fails to try SDC2 instead. That also had to be matched by modifying the default "scan" procedure in u-boot to also look for uEnv.txt, boot.scr and so on. These changes have been committed to the git.rhombus-tech.net u-boot repository under the sunxi branch and they work well.
The linux-sunxi-3.4.104 kernel on the other hand has bugs in it (which are different from the bugs in the mainline sunxi linux kernel). Basically the symptoms are: if you boot from SDC0 (on the Micro Desktop housing) and then put a microSD card into SDC2 (on the EOMA68-A20 Card) all is well. If however booting is carried out from SDC2 followed by inserting a Card into SDC0, SDC0 is guaranteed to get a "read error". This is annoying… and I am not going to fix it: I just don’t have time. If anyone would like to submit a patch or knows of a fix…. or is prepared to make a bug report (using the proprietary services that the sunxi community utilise) you are most welcome to do so: you would be helping out 800 other people in the process.
The issue that is of more concern is the JAE DC3 mid-mount Micro-HDMI connector. These connectors are as rare as rocking-horse poop. We are on to the fourth such connector in the five years of looking. The first one - a part from Amphenol - was absolutely perfect, but it has been discontinued. They are happy to restart production but only if a million units are ordered. An ongoing discussion is on the mailing list here if anyone can help: the issue is that space is extremely tight such that VIAs need to be brought up in the middle of the pads… which are only 0.2 mm wide and 0.7 mm long The via holes are 0.15 mm in diameter and the solder paste sucks down into the hole when the PCB is put into the oven.
But that’s not all: inspection of the 10 samples (only one of which had a semi-working HDMI output) it was observed that the inner set of pins was not even in contact with the PCB! The reasons for this are that either this tiny connector has been improperly manufactured, or that during installation, the use of a heat gun melted the plastic inside the connector sufficiently that the outer (top) pins bent downwards, preventing and prohibiting the inner (bottom) pins from contacting the PCB.
So, sad to say: we cannot yet go to production, unless we simply go to production without the HDMI connector. That would cut off dual-screen as a feature, and also cut off a second 1920x1080 output when output on the EOMA68 RGB/TTL connector is limited to 1366x768.
Why was this not noticed before? Well, it’s very simple: this is only the second revision of this PCB which has used this connector (2.7.2 before now), and the assembly of the 2.7.2 PCBs was done by hand. We intended to go to production with the 2.7.4 PCBs so the factory tried to use production techniques to assemble the boards: only then was it discovered that the solder paste was being wicked away down the pads.
This is just how it goes. You do not discover these things - one after another - until you actually try them out. You cannot anticipate what you do not know, if you do not know it. And, as this is hardware, it’s a three- to eight-week turnaround in addition to testing, debugging, analysis, problem-solving, and redesign time. This is just how things are, and we need to be extraordinarily patient.
Now, given that the cost each time is around \$1600 to \$2000 we simply cannot spend that much each time: for each pre-production run costing $USD 2000 that is 100 production units that could have been sent out. Instead what we will do is create another test board, only 2 layer, to try out different techniques. The cost of a 1" x 2", two-layer PCB will be minimal and the turn-around time much quicker. Several different redesigns of footprints will be tested out at the same time, to see which ones work. These test sample PCBs will be put through the production process to make sure that they work. Once we have a working technique, only then will the successful footprint be put onto a 2.7.5 PCB.
If however that does not work, then I will, sadly, just call it a day on the Micro-HDMI connectors. This has gone on long enough and I would like to actually deliver something to people. I will do the best that I can.
With the removal of the problematic legacy NAND TSSOP and the decision not to put an eMMC in its place (in order to reduce risk), boot can only be done from external microSD cards. That in turn means that 1,000 microSD cards would need to be bought, prepared and tested. Some of the OS images are too large to fit onto a 4 GB Card: that means 8 or 16 GB is needed. 8 GB and 16 GB microSD cards are actually quite expensive, pushing up the cost considerably when compared to using a NAND IC.
So I am considering instead to simply provide download scripts for people, and/or to offer much smaller 128 MB or 256 MB microSD cards which have an absolute bare minimum OS on them, with scripts that will download an OS onto their own (self-supplied) 4 GB, 8 GB or 16 GB or other sized microSD card. This really does need to be considered because the unanticipated iterations have eaten into the available budget. I would consider it reasonable to assume that people can obtain or already have their own microSD cards and have some spare, or if not can obtain one at a local supermarket, nearby tech store, or purchase one online.
However before making a decision I would appreciate some feedback (preferably on the mailing list) as this is something that needs to be discussed, how people would feel about the need to save on cost of production vs convenience and expectations. Some people, for example, may not have a reliable Internet connection or may not be expecting to connect their EOMA68-A20 Card to the Internet at all, or for whatever reason may not actually have the means to download a 1.7 GB file off the Internet. I will therefore start an appropriate discussion which you can follow and contribute to, on the list.