From paul at boddie.org.uk Sat Jun 1 19:04:42 2019 From: paul at boddie.org.uk (Paul Boddie) Date: Sat, 01 Jun 2019 20:04:42 +0200 Subject: [Arm-netbook] Schematic and PCB layout CAD files In-Reply-To: References: <2367927.efysoqg77r@jeremy> Message-ID: <1626503.RYl1xzT5xg@jeremy> On Friday 31. May 2019 23.49.57 Luke Kenneth Casson Leighton wrote: > On Saturday, June 1, 2019, Paul Boddie wrote: > > > > The inner dimensions are actually interesting for practical reasons, which > > was why I was asking about the range of PCB sizes. > > If there is no user facing connector, there is the possibility of a range > of length. > > If it is ok to stick the PCB out the end of the Card just like WIFI and Eth > PCMCIA used to do, length is limited only by practicalities. Yes, this makes sense. > Otherwise, there is no "range": the casework really does define the PCB > size to around a 0.1 mm tolerance or less. It was mostly needing to know how wide a PCB might need to be. Obviously, one can play it safe by keeping the width well within 54mm. [...] > > There was a run of cards done at one point (or more). Did anyone actually > > do anything with those cards at the time? I seem to remember confusion > > about engineering boards, people having one kind of board and not the > > other, and so on. Did they all end up in people's desk drawers or > > something? > > Pretty much. Do you have any reflections on that? Was there a realistic expectation that people might develop software or hardware to take advantage of those boards? Could more have been done to accelerate the initiative with this access to actual hardware? [...] > > Again, it was interesting to see this with regard to what kind of PCB > > sizes would actually be produced. > > 78.1 x 47.3 is what is required for the litkconn casework, and there is no > wiggle room on that. Right. [Amphenol 95622-004LF] > > When you note that 1.5mm is useless, do you mean that within a housing > > (casework), a 1.5mm board takes too much space from, say, 3.3mm (Type I) > > or 5.0mm (Type II), and that a thinner board is needed? > > Both. [...] > They are. This was described several times on this list and in at least one > update. Knowing your policy on information existing only on the list, I had hoped to see more information on the wiki, but it is useful to get more details again now. > The stainless steel is 0.1mm thick. That leaves 4.8mm. > > The SDMMC sits 1.9mm above the PCB, as does the mid mount USB OTG. > > The 2.2uH Inductors were also very very specifically chosen to fit under a > 1.9mm threshold, they are 3.2 x 3.2 mm and are quite expensive compared to > cheaper wire wound inductors which come in around the 2.5mm height mark. > > Also the SoC is around the same height, plus various large capacitors (1206 > 10uF) and one large diode have all had to be special item "Low Profile" > orders, all 1.9mm or lower. I must admit that I don't have a wide experience of SoC heights, with the only one to hand here being an Ingenic JZ4780 that doesn't really seem very tall. > So now we are down to 2.9mm. > > On the underside the *MID MOUNT* Micro HDMI and USB OTG connectors sit > 1.6mm below the PCB. > > No components above that height are permitted, it has meant a couple of > redesigns, moving some large 0805 capacitors topside. > > These underside capacitors, particularly under the CPU and DRAM, are > absolutely essential for stabilising power during peak loads, and they > clearly cannot go on TOP because they have to be extremely short tracks. > Being NEXT to the SoC would NOT be okay. They HAVE to go underside, as > close to the BGA pin where power is drained as physically possible. > > Aside from the Micro HDMI and OTG mid mount connectors there is nothing > over a 1mm height. Still, that is enough. > > 2.9 minus 1.6 is 1.3mm > > That leaves a mere TENTH of a millimetre spare clearance if using a 1.2mm > PCB. > > Can you see that for this type of design a 1.5mm PCB would be completely > impractical? Yes, it mostly makes sense. > If on the other hand there were no mid mount connectors it MIGHT be > possible. > > Anyway this is why Litkconn header and casework were selected because it > has all 68 PCMCIA pins on TOP instead of a twin pair staggered in height. Are such headers (I wasn't aware of the terminology) easy to find? Searching for PCMCIA headers in the mainstream channels, even using convenient sites like Octopart, is excruciating. [...] > > This is what I found, but I wondered why it wasn't mentioned on the > > specification pages, or why 55mm appears in the diagrams. I did find two > > pages with the 85mm x 54mm x 5mm dimensions on the Rhombus Tech site, > > however: > If you see any that are wrong please do correct them. The diagrams are the challenge since they are not readily editable. However, they possibly need reworking, anyway, partly due to their vintage. [...] > > Again, not having any experience with the casework, it would be > > interesting to know what the margins are, especially if ports would be > > exposed. > > 0.1mm would be an acceptable tolerance. Right. Good to know, thanks. [...] > > Yes, so my query was mostly motivated by a lack of familiarity with the > > variables unknown to me, which are mainly related to how bulky the > > casework is. > > The case is very very specifically tied to the connector. > > It's no good ordering random headers and hoping that the plastic and metal > case will fit it. > > The ends of the connector for example may have a different shape from > another manufacturer part. > > Bottom line, it is basically absolutely critical to get a matched set of > casework and connector. Yes, I understand that although the connector should be standardised, how the "non-mating" side of the connector fits into the housing might be wildly different from one kind of connector/header to the next. > The casework forms the basis of fitting in the rails. > > No casework, the bare PCB can be misaligned on insertion, not just > horizontally by a couple of pins, it can even be misinserted by an entire > row. This seems pretty unfortunate, really. It does seem that the Amphenol connector tries to guard against this - as well as I interpret the drawings - and I wonder if others also do so. But I wouldn't really know about these kinds of assembly problems. Do you think that, ultimately, some other connector standard would be more accessible? That is, easier to develop for without substantial tooling investment. > I deliberately overordered litkcon cases and headers, as a just in case. > And the AMP socket and rails, too. Meaning, some can be ordered from Mike > direct, if you really need them. > > And overordered somewhat on the JAE mid mount micro HDMI Type D, after > going through FOUR redesigns due to HDMI Connectors going EOL, sigh Yes, very frustrating. Paul From lkcl at lkcl.net Sat Jun 1 21:18:34 2019 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sat, 1 Jun 2019 21:18:34 +0100 Subject: [Arm-netbook] Schematic and PCB layout CAD files In-Reply-To: <1626503.RYl1xzT5xg@jeremy> References: <2367927.efysoqg77r@jeremy> <1626503.RYl1xzT5xg@jeremy> Message-ID: On Sat, Jun 1, 2019 at 7:05 PM Paul Boddie wrote: > > Otherwise, there is no "range": the casework really does define the PCB > > size to around a 0.1 mm tolerance or less. > > It was mostly needing to know how wide a PCB might need to be. Obviously, one > can play it safe by keeping the width well within 54mm. the connector end clearly has to be wide enough to actually fit the connector pins. that's somewhere around the 41 mm mark. > [...] > > > > There was a run of cards done at one point (or more). Did anyone actually > > > do anything with those cards at the time? I seem to remember confusion > > > about engineering boards, people having one kind of board and not the > > > other, and so on. Did they all end up in people's desk drawers or > > > something? > > > > Pretty much. > > Do you have any reflections on that? Was there a realistic expectation that > people might develop software or hardware to take advantage of those boards? the vivaldi project - where its leader aaron seigo lied to a *lot* of people in order to keep his standing with his team, after agreeing to the hardware spec *and* the approach taken (which then didn't work out, and he ran out of money to do another iteration) - that really f*****d things up. it didn't help that the people that he'd picked to work on the hardware and the website failed to listen to what i was saying: they made a board that didn't conform to the spec, and started publicly making unauthorized statements about what would go into the EOMA68 specification. that was the big opportunity to reach a lot more people - hardware and software engineers. it also didn't help that tsvetan has consistently and repeatedly lied to people in the sunxi community (and other businesses) about the goals and business collaboration that we proposed to him. his lying has caused several people in both the hardware and software communities to walk away, because they believed his lies. they didn't come and ask me, "is this true?", meaning that they *wanted* to believe the lying. > Could more have been done to accelerate the initiative with this access to > actual hardware? that was the idea: unfortunately, as those people were volunteers, they didn't take it further. someone will, at some point. > Knowing your policy on information existing only on the list, que? no, the wiki's there for people to edit and make the information more accessible. > > Also the SoC is around the same height, plus various large capacitors (1206 > > 10uF) and one large diode have all had to be special item "Low Profile" > > orders, all 1.9mm or lower. > > I must admit that I don't have a wide experience of SoC heights, with the only > one to hand here being an Ingenic JZ4780 that doesn't really seem very tall. it doesn't... and yet if you check, you'll find that the ethernet port is 10mm high (5x higher than the limit for components inside an EOMA68 Card on the TOP layer), a double-height USB2 stack is just over 12mm, and even the TOP mount Micro USB-OTG port will be somewhere around the 4mm mark. this is what has made the EOMA68 project so ridiculously difficult compared to "Just Yet Another SBC". availability of TOP mount standard-sized components like USB2, ETH, USB-OTG, SD/MMC, they're dead easy to get hold of, plus if the locations are slightly "off", so what? it was pure fluke for example that the MicroSD, Micro-HDMI and Micro-USB-OTG happen to fit in between the "teeth" of the Litkconn PCMCIA stainless steel shells (the ones that notch into the plastic). > > Anyway this is why Litkconn header and casework were selected because it > > has all 68 PCMCIA pins on TOP instead of a twin pair staggered in height. > > Are such headers (I wasn't aware of the terminology) easy to find? no they're not - PCMCIA is only now used in some obscure locations: France still has Satellite "Conditional Access Module" cards, and the supplier that i found in shenzhen has a big customer in Korea that still buys PCMCIA parts. > Searching > for PCMCIA headers in the mainstream channels, even using convenient sites > like Octopart, is excruciating. try finding a mid-mount Micro HDMI Type D, or a mid-mount Micro-USB-OTG. then check to see if they're not "last available supply in the world" (having been manufactured over 5-8 years ago, and Digikey is the last company in the world with the last remaining parts)... > > If you see any that are wrong please do correct them. > > The diagrams are the challenge since they are not readily editable. However, > they possibly need reworking, anyway, partly due to their vintage. i hand-edited them anyway. > > Bottom line, it is basically absolutely critical to get a matched set of > > casework and connector. > > Yes, I understand that although the connector should be standardised, how the > "non-mating" side of the connector fits into the housing might be wildly > different from one kind of connector/header to the next. they're all designed to slot together according to *external* dimensions, because that's what PCMCIA specified. the *internal* dimensions are what you cannot just go and mix-and-match random parts on, because the *internal* dimensions were never part of the PCMCIA specification. > > The casework forms the basis of fitting in the rails. > > > > No casework, the bare PCB can be misaligned on insertion, not just > > horizontally by a couple of pins, it can even be misinserted by an entire > > row. > > This seems pretty unfortunate, really. PCMCIA was never designed as a "bare PCB mechanism" for engineers, it was designed as a *mass-volume* standard, easy for *users*. > It does seem that the Amphenol > connector tries to guard against this - as well as I interpret the drawings - > and I wonder if others also do so. in combination with the correct matching casework, of course. being incompatible with the PCMCIA *external* specification would have been disastrous. > Do you think that, ultimately, some other connector standard would be more > accessible? That is, easier to develop for without substantial tooling > investment. if one existed i would have found it and written a spec based around it. as the number of pins would be completely different, it would *be* an entirely different standard, and would take a good year or so to properly review and get right. and would require basically leaving all other standards unfinished and require additional funding to complete. best to get this standard out the door, first. l. From doark at mail.com Mon Jun 3 16:18:06 2019 From: doark at mail.com (David Niklas) Date: Mon, 3 Jun 2019 11:18:06 -0400 Subject: [Arm-netbook] Intel's at it again Message-ID: <20190603111806.11497e3e@Phenom-II-x6.niklas.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Sorry to be the bearer of bad news, but Intel's at it again: https://www.anandtech.com/show/14467/intel-launches-the-nuc-compute-element-for-modular-computing-systems Yes, I already commented. Oddly, for the first time in my life on AT, I had to actually re-write my comment because the system thought it was spam. So luke, I'm your personal spam bot. ;) David -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEL2N7+xWmVOJDQxWGm3XCrhg2YP8FAlz1Oi4ACgkQm3XCrhg2 YP97fQ//deXcKeUqYSZqwPTElIv7Fys9d+aEgoNycE/eakef4fVW1BKOUMCOM7JR CDW1zoZUtg3JM122yEo/osi+d044xrNuLkPuVd0cvuLJez1PSn+VHLGJGeS3ET29 z93A0jD6GWoFKyaDOzNjqKdBo7J0ryuJn1IN58QuKpsYPh3uvBd3CTt6lbqkhp49 DlDQ0baU3dfTWm6lS/YQKIkoSq10hH29uQxrvwz0JpdILfoFssiyugGMtN6eg9fW zt2VrotoOnnu03r9mATphZYxJyayOL7Gh5bmQ8cLGLEkshvoU+bxQ+Uy0Qtuhnkx 8BRgdV6BDt9fwI4yD+Eawl6yoqLxl6fFlxMxo5sBEe0haqK5+90MvXWYESE+4WXh 0+qAsAfEIG2zoH9uQJFu2QXGIAjVeK/chRgCTqnpFxr8h3dJ/MqjU7Hy9dyFa9tw Iq998tMTWJ6QovxJtDMZNhr/Kba8yFncqRCSVPoBbq/jHsXhhcwOZD7TxPZbfFel op8VEQmeZWjbhI67uGM2W4CSzsCprhohKvcIqwH9ntdItebtVnFWcDiehlIpdOlO 77Bi9v7apuI3+uRAzuTrLHtkpMCJuzOOg6Sh9RyTxP23z2wBSduB5v+qkwZduINd 3PL1hcLB5nc4lF7Ug/tK6s/++jBb3QiyHVmiL1OtuNMllt7J/A0= =TAak -----END PGP SIGNATURE----- From lkcl at lkcl.net Mon Jun 3 20:59:11 2019 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 3 Jun 2019 20:59:11 +0100 Subject: [Arm-netbook] Intel's at it again In-Reply-To: <20190603111806.11497e3e@Phenom-II-x6.niklas.com> References: <20190603111806.11497e3e@Phenom-II-x6.niklas.com> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Mon, Jun 3, 2019 at 4:18 PM David Niklas wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Sorry to be the bearer of bad news, but Intel's at it again: > https://www.anandtech.com/show/14467/intel-launches-the-nuc-compute-element-for-modular-computing-systems oh look, it's EOMA200! From paul at boddie.org.uk Sun Jun 9 22:09:54 2019 From: paul at boddie.org.uk (Paul Boddie) Date: Sun, 09 Jun 2019 23:09:54 +0200 Subject: [Arm-netbook] Intel's at it again In-Reply-To: References: <20190603111806.11497e3e@Phenom-II-x6.niklas.com> Message-ID: <5716834.uCQ4SGDqOD@jeremy> On Monday 3. June 2019 20.59.11 Luke Kenneth Casson Leighton wrote: > > On Mon, Jun 3, 2019 at 4:18 PM David Niklas wrote: > > > > Sorry to be the bearer of bad news, but Intel's at it again: > > https://www.anandtech.com/show/14467/intel-launches-the-nuc-compute-element-for-modular-computing-systems A few people in the article's comments are already unhappy about it, having had to abandon their investment in Intel's last initiative. > oh look, it's EOMA200! Reminds me of Olimex's SOM204. Must be three times better than EOMA68: https://www.olimex.com/Products/SOM204/ Paul P.S. Any news on the production front? From lkcl at lkcl.net Sun Jun 9 22:38:55 2019 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 9 Jun 2019 22:38:55 +0100 Subject: [Arm-netbook] Intel's at it again In-Reply-To: <5716834.uCQ4SGDqOD@jeremy> References: <20190603111806.11497e3e@Phenom-II-x6.niklas.com> <5716834.uCQ4SGDqOD@jeremy> Message-ID: On Sun, Jun 9, 2019 at 10:10 PM Paul Boddie wrote: > Reminds me of Olimex's SOM204. Must be three times better than EOMA68: > > https://www.olimex.com/Products/SOM204/ standards need to be properly designed, otherwise they're not standards. > Paul > > P.S. Any news on the production front? mike's manager's quit, and the production knowledge which we learned and accumulated through the samples has gone with him. mike and i need to re-learn and recall the information. l. From calmstorm at posteo.de Sun Jun 9 22:47:17 2019 From: calmstorm at posteo.de (zap) Date: Sun, 9 Jun 2019 17:47:17 -0400 Subject: [Arm-netbook] Intel's at it again In-Reply-To: References: <20190603111806.11497e3e@Phenom-II-x6.niklas.com> <5716834.uCQ4SGDqOD@jeremy> Message-ID: <5288507b-c931-34b3-8905-61324ca0d083@posteo.de> >> P.S. Any news on the production front? > mike's manager's quit, and the production knowledge which we learned > and accumulated through the samples has gone with him. > > mike and i need to re-learn and recall the information. > > l. Rough, hope you can do this without anymore foul ups. Not saying its your fault either... as I said though, Don't give up! :) > > _______________________________________________ > arm-netbook mailing list arm-netbook at lists.phcomp.co.uk > http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook > Send large attachments to arm-netbook at files.phcomp.co.uk From adam at vany.ca Sun Jun 9 22:52:19 2019 From: adam at vany.ca (Adam Van Ymeren) Date: Sun, 09 Jun 2019 17:52:19 -0400 Subject: [Arm-netbook] Intel's at it again In-Reply-To: References: <20190603111806.11497e3e@Phenom-II-x6.niklas.com> <5716834.uCQ4SGDqOD@jeremy> Message-ID: On 9 June 2019 17:38:55 GMT-04:00, Luke Kenneth Casson Leighton wrote: >On Sun, Jun 9, 2019 at 10:10 PM Paul Boddie wrote: >> Paul >> >> P.S. Any news on the production front? > > mike's manager's quit, and the production knowledge which we learned >and accumulated through the samples has gone with him. > > mike and i need to re-learn and recall the information. Damn Luke, EOMA68 really can't catch a break can it. > >l. > >_______________________________________________ >arm-netbook mailing list arm-netbook at lists.phcomp.co.uk >http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook >Send large attachments to arm-netbook at files.phcomp.co.uk From lkcl at lkcl.net Sun Jun 9 22:57:57 2019 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 9 Jun 2019 22:57:57 +0100 Subject: [Arm-netbook] Intel's at it again In-Reply-To: References: <20190603111806.11497e3e@Phenom-II-x6.niklas.com> <5716834.uCQ4SGDqOD@jeremy> Message-ID: On Sun, Jun 9, 2019 at 10:52 PM Adam Van Ymeren wrote: > > mike's manager's quit, and the production knowledge which we learned > >and accumulated through the samples has gone with him. > > > > mike and i need to re-learn and recall the information. > > Damn Luke, EOMA68 really can't catch a break can it. if we had USD $1m - $2m in funding or it was part of a Corporation that had a large R&D budget, it would have been completed well over 3-4 years ago. success is achieved by solving the issues that come up one at a time *until* the goal (success) is met. not any other way. success doesn't happen by sitting back and hoping (or complaining)! l. From paul at boddie.org.uk Sun Jun 9 22:59:57 2019 From: paul at boddie.org.uk (Paul Boddie) Date: Sun, 09 Jun 2019 23:59:57 +0200 Subject: [Arm-netbook] Intel's at it again In-Reply-To: References: <20190603111806.11497e3e@Phenom-II-x6.niklas.com> <5716834.uCQ4SGDqOD@jeremy> Message-ID: <39005068.Q84rbLjIlJ@jeremy> On Sunday 9. June 2019 22.38.55 Luke Kenneth Casson Leighton wrote: > On Sun, Jun 9, 2019 at 10:10 PM Paul Boddie wrote: > > Reminds me of Olimex's SOM204. Must be three times better than EOMA68: > > > > https://www.olimex.com/Products/SOM204/ > > standards need to be properly designed, otherwise they're not standards. I think there's quite a bit of optional stuff in those 204 connections, arguably making it a bit like a breakout board for SoCs. That might be helpful for some applications, but probably isn't what one might call "plug and play". > > P.S. Any news on the production front? > > mike's manager's quit, and the production knowledge which we learned > and accumulated through the samples has gone with him. > > mike and i need to re-learn and recall the information. That is unfortunate news. I hope you can both figure things out without too much effort and inconvenience. Paul From lkcl at lkcl.net Sun Jun 9 23:04:53 2019 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 9 Jun 2019 23:04:53 +0100 Subject: [Arm-netbook] Intel's at it again In-Reply-To: <39005068.Q84rbLjIlJ@jeremy> References: <20190603111806.11497e3e@Phenom-II-x6.niklas.com> <5716834.uCQ4SGDqOD@jeremy> <39005068.Q84rbLjIlJ@jeremy> Message-ID: On Sun, Jun 9, 2019 at 11:00 PM Paul Boddie wrote: > > On Sunday 9. June 2019 22.38.55 Luke Kenneth Casson Leighton wrote: > > On Sun, Jun 9, 2019 at 10:10 PM Paul Boddie wrote: > > > Reminds me of Olimex's SOM204. Must be three times better than EOMA68: > > > > > > https://www.olimex.com/Products/SOM204/ > > > > standards need to be properly designed, otherwise they're not standards. > > I think there's quite a bit of optional stuff in those 204 connections, it's dead, then. anything that's made optional, you're screwed for compatibility, right from the start. how can you possibly make a base-board and hope to have any chance of upgrading the SOM in the future, if the future SOMs have "options" that are completely and utterly missing, and yet are absolutely essential for the correct functioning of the base-board?? stupid. > arguably making it a bit like a breakout board for SoCs. That might be helpful > for some applications, but probably isn't what one might call "plug and play". EOMA200 was very carefully designed from lessons learned from the standards that Intel has been involved in. COMExpress, PC-104 and so on. both of those are unnnbelievably well-designed standards. PC-104 has been incredibly successful: look at how long it's been around. over 25 years? l. > > > P.S. Any news on the production front? > > > > mike's manager's quit, and the production knowledge which we learned > > and accumulated through the samples has gone with him. > > > > mike and i need to re-learn and recall the information. > > That is unfortunate news. I hope you can both figure things out without too > much effort and inconvenience. > > Paul > > _______________________________________________ > arm-netbook mailing list arm-netbook at lists.phcomp.co.uk > http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook > Send large attachments to arm-netbook at files.phcomp.co.uk From doark at mail.com Mon Jun 10 04:10:59 2019 From: doark at mail.com (David Niklas) Date: Sun, 9 Jun 2019 23:10:59 -0400 Subject: [Arm-netbook] Intel's at it again In-Reply-To: References: <20190603111806.11497e3e@Phenom-II-x6.niklas.com> <5716834.uCQ4SGDqOD@jeremy> Message-ID: <20190609231059.4c858b28@Phenom-II-x6.niklas.com> On Sun, 9 Jun 2019 22:57:57 +0100 Luke Kenneth Casson Leighton wrote: > On Sun, Jun 9, 2019 at 10:52 PM Adam Van Ymeren wrote: > > > > mike's manager's quit, and the production knowledge which we learned > > >and accumulated through the samples has gone with him. > > > > > > mike and i need to re-learn and recall the information. > > > > D*** Luke, EOMA68 really can't catch a break can it. > > If we had USD $1m - $2m in funding or it was part of a Corporation > that had a large R&D budget, it would have been completed well over > 3-4 years ago. > > Success is achieved by solving the issues that come up one at a time > *until* the goal (success) is met. > > Not any other way. success doesn't happen by sitting back and hoping > (or complaining)! > > l. > And in our next episode: luke gets hit by lightening and the eoma68 gets to be completed by his daughter, a girl with a taste for pink PCBs and huge yellow heatsinks with stickers! ;-) Trying to cheer you up a little, David From lkcl at lkcl.net Mon Jun 10 04:22:37 2019 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 10 Jun 2019 04:22:37 +0100 Subject: [Arm-netbook] Intel's at it again In-Reply-To: <20190609231059.4c858b28@Phenom-II-x6.niklas.com> References: <20190603111806.11497e3e@Phenom-II-x6.niklas.com> <5716834.uCQ4SGDqOD@jeremy> <20190609231059.4c858b28@Phenom-II-x6.niklas.com> Message-ID: On Mon, Jun 10, 2019 at 4:11 AM David Niklas wrote: > And in our next episode: luke gets hit by lightening and the eoma68 gets > to be completed by his daughter, a girl with a taste for pink PCBs and > huge yellow heatsinks with stickers! ;-) :) actually it would likely be bright blue (her favourite colour), and the standard would make installation of Roblox and Minecraft mandatory... *sigh* :) l. From eaterjolly at gmail.com Mon Jun 10 19:54:18 2019 From: eaterjolly at gmail.com (Jean Flamelle) Date: Mon, 10 Jun 2019 14:54:18 -0400 Subject: [Arm-netbook] Intel's at it again In-Reply-To: References: <20190603111806.11497e3e@Phenom-II-x6.niklas.com> <5716834.uCQ4SGDqOD@jeremy> <20190609231059.4c858b28@Phenom-II-x6.niklas.com> Message-ID: > Minecraft https://terasology.org/ ; ) -- CC0 From lkcl at lkcl.net Tue Jun 11 02:19:29 2019 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 11 Jun 2019 02:19:29 +0100 Subject: [Arm-netbook] Intel's at it again In-Reply-To: References: <20190603111806.11497e3e@Phenom-II-x6.niklas.com> <5716834.uCQ4SGDqOD@jeremy> <20190609231059.4c858b28@Phenom-II-x6.niklas.com> Message-ID: On Mon, Jun 10, 2019 at 7:54 PM Jean Flamelle wrote: > > > Minecraft > > https://terasology.org/ ; ) oooo, that's really nice! we also tried minetest. l. From paul at boddie.org.uk Tue Jun 11 20:08:50 2019 From: paul at boddie.org.uk (Paul Boddie) Date: Tue, 11 Jun 2019 21:08:50 +0200 Subject: [Arm-netbook] Schematic and PCB layout CAD files In-Reply-To: References: <1626503.RYl1xzT5xg@jeremy> Message-ID: <5202655.ZohdQsCAVM@jeremy> On Saturday 1. June 2019 21.18.34 Luke Kenneth Casson Leighton wrote: > On Sat, Jun 1, 2019 at 7:05 PM Paul Boddie wrote: > > > > Knowing your policy on information existing only on the list, > > que? no, the wiki's there for people to edit and make the > information more accessible. That's what I meant. So I was looking on the Rhombus Tech and eLinux.org sites for information, but it wasn't so easy to find the essentials. [...] > > It does seem that the Amphenol > > connector tries to guard against this - as well as I interpret the > > drawings - and I wonder if others also do so. > > in combination with the correct matching casework, of course. being > incompatible with the PCMCIA *external* specification would have been > disastrous. On the topic of connectors and casework, I happened to come across this selection of products: http://www.morethanall.com/products/index/btype_id/5/type_id/62 (It was while investigating the Olimex KiCad footprints that I found an obscure product code for a microSD connector, this then yielding the above site when searching the Web.) I just thought I'd post the details here in case it happened to be of interest, the company being based in New Taipei City, no less. Paul From lkcl at lkcl.net Wed Jun 12 01:58:56 2019 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 12 Jun 2019 01:58:56 +0100 Subject: [Arm-netbook] Schematic and PCB layout CAD files In-Reply-To: <5202655.ZohdQsCAVM@jeremy> References: <1626503.RYl1xzT5xg@jeremy> <5202655.ZohdQsCAVM@jeremy> Message-ID: On Tue, Jun 11, 2019 at 8:09 PM Paul Boddie wrote: > http://www.morethanall.com/products/index/btype_id/5/type_id/62 > > (It was while investigating the Olimex KiCad footprints that I found an > obscure product code for a microSD connector, this then yielding the above > site when searching the Web.) > > I just thought I'd post the details here in case it happened to be of > interest, the company being based in New Taipei City, no less. ahh superb. From lkcl at lkcl.net Wed Jun 12 02:09:12 2019 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 12 Jun 2019 02:09:12 +0100 Subject: [Arm-netbook] Schematic and PCB layout CAD files In-Reply-To: References: <1626503.RYl1xzT5xg@jeremy> <5202655.ZohdQsCAVM@jeremy> Message-ID: On Wed, Jun 12, 2019 at 1:58 AM Luke Kenneth Casson Leighton wrote: > > On Tue, Jun 11, 2019 at 8:09 PM Paul Boddie wrote: > > > http://www.morethanall.com/products/index/btype_id/5/type_id/62 > > > > (It was while investigating the Olimex KiCad footprints that I found an > > obscure product code for a microSD connector, this then yielding the above > > site when searching the Web.) > > > > I just thought I'd post the details here in case it happened to be of > > interest, the company being based in New Taipei City, no less. > > ahh superb. added here http://rhombus-tech.net/pcmcia_sources/ From paul at boddie.org.uk Sun Jun 16 17:14:13 2019 From: paul at boddie.org.uk (Paul Boddie) Date: Sun, 16 Jun 2019 18:14:13 +0200 Subject: [Arm-netbook] Schematic and PCB layout CAD files In-Reply-To: References: Message-ID: <2573257.qglLn6YcPa@jeremy> On Wednesday 12. June 2019 02.09.12 Luke Kenneth Casson Leighton wrote: > > added here > http://rhombus-tech.net/pcmcia_sources/ I have updated this page with some more details and some remarks about the physical constraints involved. If such remarks belong elsewhere, feel free to move them. It was interesting to work through some of the calculations. The 0.4mm offset of one of the header parts seems like a curious figure until one does the calculations and determines that it must be intended for boards of 1.2mm thickness (or less) with components mounted on the upper side. Indeed, headers employing such an offset might conceivably be interesting when considering sockets on the "non-EOMA68" edge of a computer card, since these headers would maximise the space available to components on the upper side of a board, presumably permitting top-mount sockets to be used. I don't know whether this would have influenced the choice of sockets in the current batch of boards, but I wonder if it might be influential or useful to consider for any subsequent production. I hope this was helpful, anyway. Paul P.S. I have also been working on KiCad footprints for some of the parts I have found, in case anyone is still interested in such things. From lkcl at lkcl.net Mon Jun 17 08:40:22 2019 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 17 Jun 2019 08:40:22 +0100 Subject: [Arm-netbook] Schematic and PCB layout CAD files In-Reply-To: <2573257.qglLn6YcPa@jeremy> References: <2573257.qglLn6YcPa@jeremy> Message-ID: On Sun, Jun 16, 2019 at 5:14 PM Paul Boddie wrote: > > On Wednesday 12. June 2019 02.09.12 Luke Kenneth Casson Leighton wrote: > > > > added here > > http://rhombus-tech.net/pcmcia_sources/ > > I have updated this page with some more details and some remarks about the > physical constraints involved. If such remarks belong elsewhere, feel free to > move them. no, great idea. > It was interesting to work through some of the calculations. The 0.4mm offset > of one of the header parts seems like a curious figure until one does the > calculations and determines that it must be intended for boards of 1.2mm > thickness (or less) with components mounted on the upper side. yyep. so the female header on the Card clearly has to be at a fixed height relative to the plastic and the metal case, which means that the offsetting of the SMT pins on the header will actually raise or lower the PCB that is connected to it. therefore, get this wrong, and the PCB will be so low that you can't get any components on one of the two sides. > Indeed, headers employing such an offset might conceivably be interesting when > considering sockets on the "non-EOMA68" edge of a computer card, since these > headers would maximise the space available to components on the upper side of > a board, presumably permitting top-mount sockets to be used. interestingly, there's nothing to stop you putting the card inside the PCB at a slight angle, such that whilst at the PCMCIA header end there is plenty of room (relatively speaking) on either side of the PCB, and at the other end the PCB becomes flush with the floor of the metal case. > I don't know > whether this would have influenced the choice of sockets in the current batch > of boards, but I wonder if it might be influential or useful to consider for > any subsequent production. the issue is that even if the 1.2mm PCB is flush with the 5.0mm floor (leaving no room for underside components for about... 35 possibly even as much as 40mm (half) the Card, which would hugely complicate the design, the connectors are still around 3.3mm in height (USB-OTG, Micro-HDMI Type D) 5.0 - 0.1 (thickness of the metal) - 1.2 (PCB thickness) = 3.7mm 3.7 - 3.3 (height of the connector) = 0.4mm minus another 0.1mm for the top case shield. so that leaves only 0.3mm clearance, which means that the connectors will poke out in a completely asymmetric way, which is very ugly. the mid-mount option gave a reasonably symmetric above- and below- gap that doesn't look quite so ugly. plus, having 50% of the PCB impossible to put components on the BOTTOM side means that the PMIC area would need redesigning (again), spreading out the components to fit the ones that normally go on BOTTOM. > I hope this was helpful, anyway. yes, very. > Paul > > P.S. I have also been working on KiCad footprints for some of the parts I have > found, in case anyone is still interested in such things. superb. if you send me an ssh key i can arrange to add you to the repo that i started 6 years ago: http://git.rhombus-tech.net/?p=eoma.git;a=summary l. From paul at boddie.org.uk Mon Jun 17 12:15:18 2019 From: paul at boddie.org.uk (Paul Boddie) Date: Mon, 17 Jun 2019 13:15:18 +0200 Subject: [Arm-netbook] Schematic and PCB layout CAD files In-Reply-To: References: <2573257.qglLn6YcPa@jeremy> Message-ID: <5053023.LQY91DdYzL@jeremy> On Monday 17. June 2019 08.40.22 Luke Kenneth Casson Leighton wrote: > On Sun, Jun 16, 2019 at 5:14 PM Paul Boddie wrote: > > On Wednesday 12. June 2019 02.09.12 Luke Kenneth Casson Leighton wrote: > > > added here > > > http://rhombus-tech.net/pcmcia_sources/ > > > > I have updated this page with some more details and some remarks about the > > physical constraints involved. If such remarks belong elsewhere, feel free > > to move them. > > no, great idea. Phew! [...] > interestingly, there's nothing to stop you putting the card inside > the PCB at a slight angle, such that whilst at the PCMCIA header end > there is plenty of room (relatively speaking) on either side of the > PCB, and at the other end the PCB becomes flush with the floor of the > metal case. I think you'd really have to be confident amount the manufacturing process to do this. > > I don't know whether this would have influenced the choice of sockets in > > the current batch of boards, but I wonder if it might be influential or > > useful to consider for any subsequent production. > > the issue is that even if the 1.2mm PCB is flush with the 5.0mm floor > (leaving no room for underside components for about... 35 possibly > even as much as 40mm (half) the Card, which would hugely complicate > the design, the connectors are still around 3.3mm in height (USB-OTG, > Micro-HDMI Type D) > > 5.0 - 0.1 (thickness of the metal) - 1.2 (PCB thickness) = 3.7mm > > 3.7 - 3.3 (height of the connector) = 0.4mm > > minus another 0.1mm for the top case shield. > > so that leaves only 0.3mm clearance, which means that the connectors > will poke out in a completely asymmetric way, which is very ugly. I guess that the solution involving extending the board to provide connectors, in that classic PCMCIA/CardBus style seen with things like USB adapter cards, wasn't desirable because it would demand extra casework to be done at quite some expense. So the mid-mount connectors were a reasonable compromise. > the mid-mount option gave a reasonably symmetric above- and below- > gap that doesn't look quite so ugly. > > plus, having 50% of the PCB impossible to put components on the > BOTTOM side means that the PMIC area would need redesigning (again), > spreading out the components to fit the ones that normally go on > BOTTOM. Yes, I can imagine that limiting the components to one side brings its own challenges. For simple cards only providing flash memory and other such things (Web searches yield some kind of card for Mercedes vehicles of this nature), I guess that it isn't a major concern. [...] > > P.S. I have also been working on KiCad footprints for some of the parts I > > have found, in case anyone is still interested in such things. > > superb. if you send me an ssh key i can arrange to add you to the > repo that i started 6 years ago: > http://git.rhombus-tech.net/?p=eoma.git;a=summary I'll send you that, trying to remember the preferred form of the exported key this time. ;-) Paul From lkcl at lkcl.net Fri Jun 21 12:06:10 2019 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 21 Jun 2019 12:06:10 +0100 Subject: [Arm-netbook] eoma68 a20 card production Message-ID: (joshua appreciate you're busy with teardown, let's make this one short) Mike got back to me, his engineer completed the review of the BOM, and we managed to work out all of the information that had been lost by Mike's long standing manager quitting with no notice. The BOM still had components in it from the RTC, Ethernet and ONFI NAND, and we had had to change 10uF 0805 to a pair of 0603 4.7uF - all 12 or so of them - when there was that shortage caused by Apple, last year. All of this was *supposed* to be documented as part of the pre-production runs that cost USD 2500 a shot, so that the longer runs are far less risky because a short trial run is supposed to prepare the engineers for the longer one. We cannot keep doing that, it takes 2 to three months each time, so we have to take the risk and go straight to QTY 100. This is just how it is. Patience is required. Success happens by solving each unknown and unknowable issue that comes up. However, it would be appreciated if people would accept that this is not something that cannot be predicted, neither what might happen next nor how long it will take. Continuously asking "when is shipping going to happen" the answer is, always and will always be: until we have actual finished product ready to put into the hands of the shipping agents, we don't know and we can't know. It really is as simple as that. L. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From maillist_arm-netbook at aross.me Fri Jun 21 15:02:38 2019 From: maillist_arm-netbook at aross.me (Alexander Ross) Date: Fri, 21 Jun 2019 15:02:38 +0100 Subject: [Arm-netbook] eoma68 a20 card production In-Reply-To: References: Message-ID: Thanks for the update. your detailed updates are far better than most companies! Golden standard :) Shame about the lack of meant to be done doc but i guess all those mailing list posts contain reminders of things to check :) For me, Posts like these are far better than a date :) From allanitomwesh at gmail.com Fri Jun 21 15:28:53 2019 From: allanitomwesh at gmail.com (Allan Mwenda) Date: Fri, 21 Jun 2019 17:28:53 +0300 Subject: [Arm-netbook] eoma68 a20 card production In-Reply-To: References: Message-ID: On 6/21/19, Luke Kenneth Casson Leighton wrote: > (joshua appreciate you're busy with teardown, let's make this one short) > > Mike got back to me, his engineer completed the review of the BOM, and we > managed to work out all of the information that had been lost by Mike's > long standing manager quitting with no notice. > > The BOM still had components in it from the RTC, Ethernet and ONFI NAND, > and we had had to change 10uF 0805 to a pair of 0603 4.7uF - all 12 or so > of them - when there was that shortage caused by Apple, last year. > > All of this was *supposed* to be documented as part of the pre-production > runs that cost USD 2500 a shot, so that the longer runs are far less risky > because a short trial run is supposed to prepare the engineers for the > longer one. We cannot keep doing that, it takes 2 to three months each > time, so we have to take the risk and go straight to QTY 100. > > This is just how it is. > > Patience is required. Success happens by solving each unknown and > unknowable issue that comes up. However, it would be appreciated if people > would accept that this is not something that cannot be predicted, neither > what might happen next nor how long it will take. Continuously asking > "when is shipping going to happen" the answer is, always and will always > be: until we have actual finished product ready to put into the hands of > the shipping agents, we don't know and we can't know. It really is as > simple as that. > > L. > > > > > -- > --- > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 > _______________________________________________ > arm-netbook mailing list arm-netbook at lists.phcomp.co.uk > http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook > Send large attachments to arm-netbook at files.phcomp.co.uk good to know, better a good product that's a bit late than a rushed dud. From lkcl at lkcl.net Fri Jun 21 16:13:28 2019 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 21 Jun 2019 16:13:28 +0100 Subject: [Arm-netbook] eoma68 a20 card production In-Reply-To: References: Message-ID: On Friday, June 21, 2019, Alexander Ross wrote: > Thanks for the update. your detailed updates are far better than most > companies! Golden standard :) > > Shame about the lack of meant to be done doc but i guess all those > mailing list posts contain reminders of things to check :) > > Preetty much yeh > For me, Posts like these are far better than a date :) > > The irony is that the updates become a canonical list of Everything That Could Go Wrong on an ooen hardware project... L. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From calmstorm at posteo.de Fri Jun 21 17:18:40 2019 From: calmstorm at posteo.de (zap) Date: Fri, 21 Jun 2019 12:18:40 -0400 Subject: [Arm-netbook] eoma68 a20 card production In-Reply-To: References: Message-ID: >> For me, Posts like these are far better than a date :) >> >> > The irony is that the updates become a canonical list of Everything That > Could Go Wrong on an ooen hardware project... > > L. > > Seems like a lot went wrong, Still, I am certain you will succeed. :) And yes, better to be very late than have a product that sucks major dong. ;) Tell me, when I showed you that A64 processor, with the sunxi link, does it look like it could be run with only free software? If so that could be your next processor to use with the eoma68 standard. That aside, I wish you the best and hope you will succeed!  I am very hopeful you will. Same with the libre risc-v processor. We need one of those for the future. Quad core with 2.4 ghz/5glops + under 2.5 watts would be sick man. I hope as you learn more about how to do that stuff it will be achieveable. :) From maillist_arm-netbook at aross.me Fri Jun 21 18:13:37 2019 From: maillist_arm-netbook at aross.me (Alexander Ross) Date: Fri, 21 Jun 2019 18:13:37 +0100 Subject: [Arm-netbook] eoma68 a20 card production In-Reply-To: References: Message-ID: <7609e857-c057-e0e9-badd-9995284fdcc7@aross.me> On 21/06/2019 4:13 pm, Luke Kenneth Casson Leighton wrote:> On Friday, June 21, 2019, Alexander Ross > wrote: >> For me, Posts like these are far better than a date :) >> > The irony is that the updates become a canonical list of Everything That > Could Go Wrong on an ooen hardware project... also shows how your one of the few projects to get a lot of things right: *Is possible to devolop, make stuff in china. Without years of experience. By being in china. *You made contacts with locals like mike that have been very helpful. *Is possible to use china tricks to save money, lower bom. Cheaper, easy to get components in china markets that do the job. *-Getting the balance right with how cheap ya go. (the li batt charger, usb power IC pain). With success with components like cap choices, headphone amp,... Most techys avoid making stuff in china like the wind, buy everything from digikey at X markup. You sodded that and documented and helped shown it can be done. Lots of lessons like with anything but it is possible. Where’s most techys can’t face it. I do wish they adapt a can do attitude too. *Demonstrated tons of perseverance. if someone whats someone that gets the job done and doesn’t give up easily (If at all?!), your the person to hire :) * Example of careful considerate engineering. You thought about environmental impact of may parts of your designs. * You didn’t keep oppies behind closed doors. * you made sure you didn’t make stupid common proprietary mistakes, like accepting proprietary drivers. Unlike fairphone that disregarded that everything needed to use phone should be libre software. Then they had problem of there anti obsolescences phones becoming obsolescent like most phones which they marketed them selfs as not being! All because of the drivers! Then they do shiny marketing post to try and undo the damage. oow look we listening, a bit more now... urrgh well if only there where considerate in the first place! * librem had to do shiny oow look of course intel wont release there cpu firmware like we can encouraged you to think would happen but lets do a little campaign against mutli billion company, maybe if more of us ask nicely they will give us the code with all its usa backdoors :)? huh yea right. though they did seam to get something out of it after the campaign?? or was that someone elses work that helped save the day? i forget. * nokia made linux phone but key drivers where secret... well that phone didn’t get so much adaptation... put me off. * Ind.ie Sold the dream of a libre software phone, in the end delivered just the social network but for mac only. * Ubuntu nearly got enough millions of funding for phone. yet if they had gone for a not so hard to make design, hired you :) and got the same funding they maybe they could have made a phone after all. * intel thought eoma68 was a good idea too but just had to make there own version so they thought they could turn it into a intel only monopoly. Snag is that’s what killed it. If they had been more considerate and less fool. They would have then let go of sabotaging it by thy own monopoly effort in order for it to have a better chance of adaptation. Refreshingly your one of the few projects/people to not make those awful mainstream mistakes. No over selling, over promising, monopolization, Making practical choices for products more in reach with small production. The fact you have made such refreshing decisions means i am very willing to put up with lots of woes, lessons because you trying to do what others have not managed to do. I’m also quite forgiving anyway :) From pablo at parobalth.org Fri Jun 21 19:20:45 2019 From: pablo at parobalth.org (Pablo Rath) Date: Fri, 21 Jun 2019 20:20:45 +0200 Subject: [Arm-netbook] eoma68 a20 card production In-Reply-To: References: Message-ID: <20190621182045.mzteab6744m5f6m5@cherry> On Fri, Jun 21, 2019 at 12:06:10PM +0100, Luke Kenneth Casson Leighton wrote: ... > All of this was *supposed* to be documented as part of the pre-production > runs that cost USD 2500 a shot, so that the longer runs are far less risky > because a short trial run is supposed to prepare the engineers for the > longer one. We cannot keep doing that, it takes 2 to three months each > time, so we have to take the risk and go straight to QTY 100. > ... > > Patience is required. Success happens by solving each unknown and > unknowable issue that comes up. However, it would be appreciated if people > would accept that this is not something that cannot be predicted, neither > what might happen next nor how long it will take. Thanks for the update. I have read every update so far, read most of the emails on this list and skim those not so interesting to me. Following questions bother me and I don't recall that they have been already answered: Is it still planned to send pre-production cards to those (including me) who signed up? What is the status of the last pre-production prototype cards? Do they work? When can we test / will we know if Richards HDMI-layout is working? kind regards Pablo From lkcl at lkcl.net Fri Jun 21 19:36:53 2019 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 21 Jun 2019 19:36:53 +0100 Subject: [Arm-netbook] eoma68 a20 card production In-Reply-To: References: Message-ID: On Saturday, June 22, 2019, zap wrote: > > For me, Posts like these are far better than a date :) >>> >>> >>> The irony is that the updates become a canonical list of Everything That >> Could Go Wrong on an ooen hardware project... >> >> L. >> >> >> Seems like a lot went wrong, Still, I am certain you will succeed. :) > > And yes, better to be very late than have a product that sucks major dong. > ;) > > Tell me, when I showed you that A64 processor, with the sunxi link, does > it look like it could be run with only free software? If so that could be > your next processor to use with the eoma68 standard. > > I was annoyed with Allwinner and deleted the design I was working on. Also, I think they restricted the RGBTTL output to 1280x800 and EOMA68 requires 1366x768 minimum. After using a superb LCD driver under Mr Ding's design direction the other Business Units started to license some shoddy LCD driver that restricted the framebuffer to 1MByte in size. Any product that went beyond that *also licensed PowerVR* and there's no way in hell I'm doing a Card with a PowerVR GPU. All that having been said, it turns out yet again that it is Allwinner Marketing Dept lying and incompetence that shoots themselves in the foot. They started lying about the A20 a few years back, saying it is only capable of 1024x768 because otherwise it made other offerings, more "advanced", on the same marketing page, look bad. http://linux-sunxi.org/A64 says the A64 can do up to 1920x1080p60 on the RGBTTL interface. Sigh. > That aside, I wish you the best and hope you will succeed! I am very > hopeful you will. Same with the libre risc-v processor. We need one of > those for the future. > > Quad core with 2.4 ghz/5glops + under 2.5 watts would be sick man. I hope > as you learn more about how to do that stuff it will be achieveable. :) :) > > _______________________________________________ > arm-netbook mailing list arm-netbook at lists.phcomp.co.uk > http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook > Send large attachments to arm-netbook at files.phcomp.co.uk -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From calmstorm at posteo.de Fri Jun 21 19:47:17 2019 From: calmstorm at posteo.de (zap) Date: Fri, 21 Jun 2019 14:47:17 -0400 Subject: [Arm-netbook] eoma68 a20 card production In-Reply-To: References: Message-ID: > I was annoyed with Allwinner and deleted the design I was working on. Also, > I think they restricted the RGBTTL output to 1280x800 and EOMA68 requires > 1366x768 minimum. > > After using a superb LCD driver under Mr Ding's design direction the other > Business Units started to license some shoddy LCD driver that restricted > the framebuffer to 1MByte in size. > > Any product that went beyond that *also licensed PowerVR* and there's no > way in hell I'm doing a Card with a PowerVR GPU. > > All that having been said, it turns out yet again that it is Allwinner > Marketing Dept lying and incompetence that shoots themselves in the foot. > > They started lying about the A20 a few years back, saying it is only > capable of 1024x768 because otherwise it made other offerings, more > "advanced", on the same marketing page, look bad. > > http://linux-sunxi.org/A64 says the A64 can do up to 1920x1080p60 on the > RGBTTL interface. > > Sigh. So then, is there any 64 bit arm processor you think you could achieve this with? I mean one that is not allwinner > > >> That aside, I wish you the best and hope you will succeed! I am very >> hopeful you will. Same with the libre risc-v processor. We need one of >> those for the future. >> >> Quad core with 2.4 ghz/5glops + under 2.5 watts would be sick man. I hope >> as you learn more about how to do that stuff it will be achieveable. :) > > :) > Glad to be able to lift your spirits. :) >> _______________________________________________ >> arm-netbook mailing list arm-netbook at lists.phcomp.co.uk >> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook >> Send large attachments to arm-netbook at files.phcomp.co.uk > > From lkcl at lkcl.net Fri Jun 21 19:47:49 2019 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 21 Jun 2019 19:47:49 +0100 Subject: [Arm-netbook] eoma68 a20 card production In-Reply-To: <7609e857-c057-e0e9-badd-9995284fdcc7@aross.me> References: <7609e857-c057-e0e9-badd-9995284fdcc7@aross.me> Message-ID: On Saturday, June 22, 2019, Alexander Ross wrote: > On 21/06/2019 4:13 pm, Luke Kenneth Casson Leighton wrote:> On Friday, > June 21, 2019, Alexander Ross > > wrote: > >> For me, Posts like these are far better than a date :) > >> > > The irony is that the updates become a canonical list of Everything That > > Could Go Wrong on an ooen hardware project... > also shows how your one of the few projects to get a lot of things right: > > *Is possible to devolop, make stuff in china. Without years of > experience. By being in china. This is a really funny summary, to be fair to purism they are now a Benefit Corp, and they had some influence with Intel, their requests for switching off the ME by default actually resulted in internal buzz around a "ME-less BIOS". Then the "NSA off switch" was discovered and they were able to do FW BIOS patches for their products, without Intel's help, permission or involvement. Even as far back as 2011 I could have compromised, released some SBC design, made some cash, established a business, and funded EOMA68 with it. Or made some other compromise, done something a la fairphone or etc etc and got up and running that way. The risk was, getting sidetracked by running such a business, instead of focussing on EOMA68. Or, being criticised for compromising, undermining the whole purpose of the exercise. What can you do, eh? L. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From lkcl at lkcl.net Fri Jun 21 19:50:36 2019 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 21 Jun 2019 19:50:36 +0100 Subject: [Arm-netbook] eoma68 a20 card production In-Reply-To: <20190621182045.mzteab6744m5f6m5@cherry> References: <20190621182045.mzteab6744m5f6m5@cherry> Message-ID: On Saturday, June 22, 2019, Pablo Rath wrote: > On Fri, Jun 21, 2019 at 12:06:10PM +0100, Luke Kenneth Casson Leighton > wrote: > > ... > > > All of this was *supposed* to be documented as part of the pre-production > > runs that cost USD 2500 a shot, so that the longer runs are far less > risky > > because a short trial run is supposed to prepare the engineers for the > > longer one. We cannot keep doing that, it takes 2 to three months each > > time, so we have to take the risk and go straight to QTY 100. > > > ... > > > > Patience is required. Success happens by solving each unknown and > > unknowable issue that comes up. However, it would be appreciated if > people > > would accept that this is not something that cannot be predicted, neither > > what might happen next nor how long it will take. > > Thanks for the update. I have read every update so far, read most of > the emails on this list and skim those not so interesting to me. > Following questions bother me and I don't recall that they have been > already answered: > Is it still planned to send pre-production cards to those (including me) > who signed up? Yes, aiyaa I still have some at my mum's house. Keep forgetting. > What is the status of the last pre-production prototype cards? Do they > work? Yes. There are I think 3 available. > When can we test / will we know if Richards HDMI-layout is working? > > When someone works out the darn fex file. It is so long in between test runs I have to work out each time what the board bringup process is, over and over again. Sigh. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From calmstorm at posteo.de Fri Jun 21 19:51:12 2019 From: calmstorm at posteo.de (zap) Date: Fri, 21 Jun 2019 14:51:12 -0400 Subject: [Arm-netbook] eoma68 a20 card production In-Reply-To: References: <7609e857-c057-e0e9-badd-9995284fdcc7@aross.me> Message-ID: > > This is a really funny summary, to be fair to purism they are now a Benefit > Corp, and they had some influence with Intel, their requests for switching > off the ME by default actually resulted in internal buzz around a "ME-less > BIOS". > > Then the "NSA off switch" was discovered and they were able to do FW BIOS > patches for their products, without Intel's help, permission or involvement. > > Even as far back as 2011 I could have compromised, released some SBC > design, made some cash, established a business, and funded EOMA68 with it. > > Or made some other compromise, done something a la fairphone or etc etc and > got up and running that way. > > The risk was, getting sidetracked by running such a business, instead of > focussing on EOMA68. > > Or, being criticised for compromising, undermining the whole purpose of the > exercise. > > What can you do, eh? > > L. Frankly we need more people who will not compromise and will do what is right for the world, the future and for the love of God, what is good for freedom and justice alike! My point being, I thank you for going full freedom, integrity is a lost art in our world it seems like. > > > From lkcl at lkcl.net Fri Jun 21 20:18:34 2019 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 21 Jun 2019 20:18:34 +0100 Subject: [Arm-netbook] eoma68 a20 card production In-Reply-To: References: <7609e857-c057-e0e9-badd-9995284fdcc7@aross.me> Message-ID: On Saturday, June 22, 2019, zap wrote: > . >> > Frankly we need more people who will not compromise and will do what is > right for the world, the future and for the love of God, what is good for > freedom and justice alike! It is not a lot of fun, to be honest. I am really nit surprised that more people do not put their foot down. Then they go "err that really didn't work out, er what do we do now", and many of them regret how they shouted and blamed me, but cannot bring themselves to admit that. Several people in the samba team went through that painful lesson, 15+ years ago. > My point being, I thank you for going full freedom, integrity is a lost > art in our world it seems like. Appreciated. > >> >> >> > > _______________________________________________ > arm-netbook mailing list arm-netbook at lists.phcomp.co.uk > http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook > Send large attachments to arm-netbook at files.phcomp.co.uk -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From maillist_arm-netbook at aross.me Fri Jun 21 20:45:51 2019 From: maillist_arm-netbook at aross.me (Alexander Ross) Date: Fri, 21 Jun 2019 20:45:51 +0100 Subject: [Arm-netbook] eoma68 a20 card production In-Reply-To: References: <7609e857-c057-e0e9-badd-9995284fdcc7@aross.me> Message-ID: On 21/06/2019 7:47 pm, Luke Kenneth Casson Leighton wrote:> On Saturday, June 22, 2019, Alexander Ross > wrote: > >> On 21/06/2019 4:13 pm, Luke Kenneth Casson Leighton wrote:> On Friday, >> June 21, 2019, Alexander Ross >>> wrote: >>>> For me, Posts like these are far better than a date :) >>>> >>> The irony is that the updates become a canonical list of Everything That >>> Could Go Wrong on an ooen hardware project... >> also shows how your one of the few projects to get a lot of things right: >> >> *Is possible to devolop, make stuff in china. Without years of >> experience. By being in china. > > > This is a really funny summary, to be fair to purism they are now a Benefit > Corp, and they had some influence with Intel, their requests for switching > off the ME by default actually resulted in internal buzz around a "ME-less > BIOS". > > Then the "NSA off switch" was discovered and they were able to do FW BIOS > patches for their products, without Intel's help, permission or involvement. > Yea i was being hard on them. I may well end up getting there librem phone. I do wonder, suspect the fuss made + there clout of money they raised and media press and high end extra well paid worker/biz person target market, may well have helped things to change. > Even as far back as 2011 I could have compromised, released some SBC > design, made some cash, established a business, and funded EOMA68 with it. > > Or made some other compromise, done something a la fairphone or etc etc and > got up and running that way. > > The risk was, getting sidetracked by running such a business, instead of > focussing on EOMA68. > > Or, being criticised for compromising, undermining the whole purpose of the > exercise. > > What can you do, eh? yea its tricky. i see others that did those things and start to wonder but then i think, have they produced hw as free as what your work on? no. they may be about too, like librem phone but im waiting for final hardware before i believe it. maybe doing some of what they did but a lesser of the eviles version would have helped raise more money, fund efforts, make things easier. like pyra’s evil dragon shop selling gpd pocket laptops and other proprietary hardware of interest which helps to provide funds but it does take days out of dev time... or as you said sbc etc... IDK, hard to say whats right. There isn’t a right way but more annoying ways too see lessons leant :). I guess only do what ya can or think you should. As thats what happens any way :) Then again with libre-riscv, maybe things are going to get a lot bigger for ya, being involved with that project. new floss, innovative and cheap, under cutting status quo, cpu and related parts. Big potential but long way to go but maybe you be laughing in 10years time? :D with a nice amount in bank account :) From monnier at iro.umontreal.ca Fri Jun 21 21:33:51 2019 From: monnier at iro.umontreal.ca (Stefan Monnier) Date: Fri, 21 Jun 2019 16:33:51 -0400 Subject: [Arm-netbook] eoma68 a20 card production References: <20190621182045.mzteab6744m5f6m5@cherry> Message-ID: > When someone works out the darn fex file. Nowadays, you should just use a mainline linux kernel (with DT) rather than the old Allwinner kernel (with FEX). Of course, that just shifts the problem to "someone works out the darn DT file", but at least it's much better supported (and there's even an upcoming patch for that vanilla kernel which can finally lift the write speed limit on SATA from 50MB/s to 150MB/s or so). Stefan From lkcl at lkcl.net Fri Jun 21 22:13:02 2019 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 21 Jun 2019 22:13:02 +0100 Subject: [Arm-netbook] eoma68 a20 card production In-Reply-To: References: <20190621182045.mzteab6744m5f6m5@cherry> Message-ID: On Saturday, June 22, 2019, Stefan Monnier wrote: > > When someone works out the darn fex file. > > Nowadays, you should just use a mainline linux kernel (with DT) rather > than the old Allwinner kernel (with FEX). Of course, that just shifts > the problem to "someone works out the darn DT file", but at least it's > much better supported > Full hardware support still is not complete. Also I simply do not have the time to redo months of work. Any time I spend now basically means I get zero money from NLNet as the donations from them are based on *milestone* completion, *not* on "time spent". 4 weeks on OS rework equals ZERO PAYMENT from NLNet for that entire time. (and there's even an upcoming patch for that > vanilla kernel which can finally lift the write speed limit on SATA from > 50MB/s to 150MB/s or so). Reason why 3.4.104+ has to be shipped was explained 18 or so months ago. Entire OSes need to be redone otherwise. L. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From adam at vany.ca Sat Jun 22 01:00:53 2019 From: adam at vany.ca (Adam Van Ymeren) Date: Fri, 21 Jun 2019 20:00:53 -0400 Subject: [Arm-netbook] eoma68 a20 card production In-Reply-To: References: <20190621182045.mzteab6744m5f6m5@cherry> Message-ID: On 21 June 2019 17:13:02 GMT-04:00, Luke Kenneth Casson Leighton wrote: >On Saturday, June 22, 2019, Stefan Monnier >wrote: > >> > When someone works out the darn fex file. >> >> Nowadays, you should just use a mainline linux kernel (with DT) >rather >> than the old Allwinner kernel (with FEX). Of course, that just >shifts >> the problem to "someone works out the darn DT file", but at least >it's >> much better supported > > >> >Full hardware support still is not complete. Also I simply do not have >the >time to redo months of work. > >Any time I spend now basically means I get zero money from NLNet as the >donations from them are based on *milestone* completion, *not* on "time >spent". > >4 weeks on OS rework equals ZERO PAYMENT from NLNet for that entire >time. > > (and there's even an upcoming patch for that >> vanilla kernel which can finally lift the write speed limit on SATA >from >> 50MB/s to 150MB/s or so). > > >Reason why 3.4.104+ has to be shipped was explained 18 or so months >ago. Indeed. We have a working set of software. After shipping, motivated community members can look at upgrading to mainline. It's still libre software after all :). > >Entire OSes need to be redone otherwise. > >L. > > > >-- >--- >crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 >_______________________________________________ >arm-netbook mailing list arm-netbook at lists.phcomp.co.uk >http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook >Send large attachments to arm-netbook at files.phcomp.co.uk From doark at mail.com Sat Jun 22 04:23:30 2019 From: doark at mail.com (David Niklas) Date: Fri, 21 Jun 2019 23:23:30 -0400 Subject: [Arm-netbook] eoma68 a20 card production In-Reply-To: References: Message-ID: <20190621232330.7279a7ba@Phenom-II-x6.niklas.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Fri, 21 Jun 2019 16:13:28 +0100 Luke Kenneth Casson Leighton wrote: > On Friday, June 21, 2019, Alexander Ross > wrote: > > > Thanks for the update. your detailed updates are far better than most > > companies! Golden standard :) > > > > Shame about the lack of meant to be done doc but i guess all those > > mailing list posts contain reminders of things to check :) > > > > Preetty much yeh > > > > For me, Posts like these are far better than a date :) > > > > > The irony is that the updates become a canonical list of Everything That > Could Go Wrong on an ooen hardware project... > > L. > > And everyone who can go morally right. Like yourself. What it costs. What can be achieved. Why to do it. How to do it. But most notably, you show us what the industry of a failed method, the dishonest, avaricious, power hungry with a lack of solidarity method, is *really* like. That it's not all roses with rainbows and smiles like is depicted in the news, even the free speech online tech news. And thus, we are led to seek a better way... I'll let your imagination finish my email as I must go to sleep soon. You probably know where I'm going. David PS: One of the things that can go wrong is misspelling the word "open". :D -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEL2N7+xWmVOJDQxWGm3XCrhg2YP8FAl0NnzIACgkQm3XCrhg2 YP+piQ//TErijfqN3MeJzj09nAmFY7LY6IZAMDB/zOTtoIYle1pSi7q6TH1aczLV MFOPHEeYxT1mDYTOpD1VPO40ue9RH4FcN8iP88P81Ysnedzmnc/1TuADtQU4t6x3 PzCXYWO63FIM26BuhWR0hjuXUYyPVX298Ke9iQYg+yjdynzxuFHPr5YhKdn/kPUZ RmkWgDwGdmwZqwYCtGN59RXIK2UR0fPYljmnBQeOWGRZUKg3UmgJQJ5ER9Uoi1L1 dahSzdf+9mw7+A2o4zAjO4nEMn8Umt5sGGQxLkufeEDGLFz2RJ66aG1gKllBNLDU aZZUCoZckJAd9a24UaurDokIbllb+BNBRt3b8izzhgdrvcZdTY14qtYrPRAHp92s 2bd0cL8SXitwqAc3kPvKp3dGfcaE8JzYxR6BRijVaSVifAqm5xy+GOlzV7ZOEC/U nXp4ouU7dfMLC3+WljUA2+6FtMWLcyFW4w+5SzhtChq/QSVUzxFc3P/kffJvA+72 dELlkZCVmBH+rShTVXKi/ZC5uKSAeGlSQRLtSCIP4VPXVi70jQ2t2HYK7OlDuIy6 AKEP3KQGOQt0gNWZmOV+SuAFfybZjCmxRJHJnr5UkO/dOTWno/mw+y7N09BDB9KY YdBvod4kylPLQirEmfyKZFksvbY6khhFYtRnXEtc1/naBovsaG8= =9GzB -----END PGP SIGNATURE----- From paul at boddie.org.uk Sat Jun 29 22:54:43 2019 From: paul at boddie.org.uk (Paul Boddie) Date: Sat, 29 Jun 2019 23:54:43 +0200 Subject: [Arm-netbook] eoma68 a20 card production In-Reply-To: References: Message-ID: <2631063.bSJyEZgjQ2@jeremy> On Friday 21. June 2019 22.13.02 Luke Kenneth Casson Leighton wrote: > > Reason why 3.4.104+ has to be shipped was explained 18 or so months ago. > > Entire OSes need to be redone otherwise. I have tried to document some of this here: http://rhombus-tech.net/crowdsupply/status/ Some other topics are also covered, such as changes to the Computer Card hardware during the realisation of the campaign. I hope this summary proves to be helpful, anyway. Paul From lkcl at lkcl.net Sun Jun 30 06:33:55 2019 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 30 Jun 2019 06:33:55 +0100 Subject: [Arm-netbook] eoma68 a20 card production In-Reply-To: <2631063.bSJyEZgjQ2@jeremy> References: <2631063.bSJyEZgjQ2@jeremy> Message-ID: On Sat, Jun 29, 2019 at 10:55 PM Paul Boddie wrote: > > On Friday 21. June 2019 22.13.02 Luke Kenneth Casson Leighton wrote: > > > > Reason why 3.4.104+ has to be shipped was explained 18 or so months ago. > > > > Entire OSes need to be redone otherwise. > > I have tried to document some of this here: > > http://rhombus-tech.net/crowdsupply/status/ > > Some other topics are also covered, such as changes to the Computer Card > hardware during the realisation of the campaign. > > I hope this summary proves to be helpful, anyway. it's fantastic, thank you paul.