From charlesrcard at yahoo.com Mon Jan 1 07:58:42 2018 From: charlesrcard at yahoo.com (Chuck Card) Date: Mon, 1 Jan 2018 07:58:42 +0000 (UTC) Subject: [Arm-netbook] EOMA68 / Libre RISC-V team financing (Luke Kenneth Casson Leighton) In-Reply-To: References: <87shbwifcg.fsf@gnu.org> <87zi63s0hg.fsf@whist.hands.com> <287f0486-e220-e57e-dc85-1d3970ad4ffe@riseup.net> <87r2rb9pph.fsf@elephly.net> Message-ID: <1927801592.7037146.1514793522387@mail.yahoo.com> > ...i am back > - once again - to being DEPENDENT on donations and sponsorship and, > once a fucking gain getting money from contract work and/or having to > consider enslavement i mean employment which i know that people will > say "you're wasting your time, you're a threat to our jobs". Hi Luke, I backed this project because I feel what you are doing is extraordinary.I want to provide some additional funding, but I rather not open another account. Will paypal work for you? As Lee Camp would say "Keep fighting" On Sunday, December 31, 2017 6:39 PM, Luke Kenneth Casson Leighton wrote: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Sun, Dec 31, 2017 at 8:31 PM, zap wrote: > > > On 12/31/2017 05:17 AM, Luke Kenneth Casson Leighton wrote: >> --- >> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 >> >> >> On Sun, Dec 31, 2017 at 10:06 AM, Ricardo Wurmus wrote: >>> Hi Luke, >> >>>> Just one question: is canceling support for the CrowdSupply campaign an >>>> option if you go through with this? >>> I’m quoting this, because I very much agree with Julie and others who >>> oppose Bitcoin. >>  ricardo: it's a little late... and also no longer relevant.  it's too >> late because i had *already* - 34 days ago - used personal bitcoin >> mined over five years ago that has absolutely no connection WHATSOEVER >> to the EOMA68 project's (cash, USD/RMB) funds, and second it's no >> longer relevant because it's been established that it's a long-term >> investment not an "immediate financing of this and all possible >> projects we ever wanted to be funded" opportunity. >> >>  so your opposition is noted, respected... and at the same time can be >> disregarded. > > I must admit, I would not trust bitcoin either, but if you think its a > good idea to use, that's your prerogative. I just think you should use > liberapay for the majority of your donations.  and avoid bitcoin when > possible. the other difference here is - was (before i had enough information to be able to ascertain that it was not feasible to do so): * when i believed that bitclub was a high-exponential curve payout *I* intended *TO FUND* software libre projects with it * now that i *KNOW* that bitclub is a LONG TERM investment, i am back - once again - to being DEPENDENT on donations and sponsorship and, once a fucking gain getting money from contract work and/or having to consider enslavement i mean employment which i know that people will say "you're wasting your time, you're a threat to our jobs". door number one: financially independent and able to fund all projects i ever wanted to fund door number two: not financially independent and back to having to listen to people telling me i'm being a fucking idiot and incapable of making decisions. 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 Mon Jan 1 09:08:14 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 1 Jan 2018 09:08:14 +0000 Subject: [Arm-netbook] EOMA68 / Libre RISC-V team financing (Luke Kenneth Casson Leighton) In-Reply-To: <1927801592.7037146.1514793522387@mail.yahoo.com> References: <87shbwifcg.fsf@gnu.org> <87zi63s0hg.fsf@whist.hands.com> <287f0486-e220-e57e-dc85-1d3970ad4ffe@riseup.net> <87r2rb9pph.fsf@elephly.net> <1927801592.7037146.1514793522387@mail.yahoo.com> Message-ID: On Mon, Jan 1, 2018 at 7:58 AM, Chuck Card via arm-netbook wrote: > Hi Luke, > I backed this project because I feel what you are doing is extraordinary. thanks chuck. > I want to provide some additional funding, but I rather not open another > account. Will paypal work for you? that would be perfect - it'll need to be to my partner marie's paypal account? here's a convenient link: http://paypal.me/OrangeMarie marie says: "The account is registered in the UK. Pounds are preferred. When they click on the link, They should see my name...Marie Raymond and a picture of yarn balls and a crochet hook. And Newton Stewart as the location." > As Lee Camp would say "Keep fighting" :) i received from someone a really inspiring and thoughtful message, i've received permission to anonymously put it into an update. mostly as a reminder to myself. thx chuck. l. From lkcl at lkcl.net Mon Jan 1 09:34:47 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 1 Jan 2018 09:34:47 +0000 Subject: [Arm-netbook] EOMA68 / Libre RISC-V team financing In-Reply-To: References: Message-ID: [ron, thank you for writing this, it's very insightful and thoughtful] On Sat, Dec 30, 2017 at 10:01 AM, wrote: > If beneficial to lkcl, he can erase me from the > shipping list and no refund. I ask others to do the same. that's really appreciated, that you would consider making what is in effect a donation or sponsorship. my primary concern here, is, that the computers that i am making *remain in circulation and in use*. so this is actually really rather important (enough so that i'll probably make a special update about it, now that i think about it). if anyone is backing the project with the intention of seeing it succeed but *not* actually intending to find someone who will *actually* use the computer, please do contact crowdsupply - orders at crowdsupply.com - with your order number (cc me) and say "hello i would like to turn my pledge into a donation, for luke to find someone to donate or sell the computer to, thank you". > I think lkcl has done more than one can expect. He > likely has gathered experiences and > knowledge about libre hardware, he > can use moving forward. ... and anyone else can as well: that's primarily why i pushed through joshua's initial reticence at the length of each update that i write. i learned from openmoko, and from openpandora, and many others: i in turn am simply doing the same thing. > If lkcl can contribute to the riscv development, > he rather should do that, than potter > on an arm cpu, none of us like. > What I want to avoid is, that lkcl on > economic reasons gets discouraged and jammed. appreciated. > I know the following is not achievable. I say it anyway. > One option is, lkcl sets a monthly required amount of > money for the next 6 months. I am prepared to pay > lkcl 5usd a month. But only if I know lkcl gets the > required sum every month. 5Usd is cheap, I > know. If you want to pay more do it. everything helps. it's the fundamental basis of crowd-funding. > To me this matter is another prove of libre software > people not being streamlined. Libre software > people are up against companies like intel and > amd. Libre software people cannot expect to > achieve results if the matter is not better organized. well, what's really nice is that intel, amd and ARM are now up against the Indian Government. my unexpected role seems to be to keep madhu's feet on the ground as he's like.. a high-torque Muscle Car Motor... without a gearbox to put all that power into "rubber-on-the-road" :) > Among libre software people there should be a > system of fellowships enabling persons to work > on free software. No it does not have to > be lkcl. ... and it shouldn't. i have enough to do. > But such system should be created. > How should it be founded? there do exist several. it does seem though that certain well-known and well-respected people whose contribution has been consistent and long-term *within their community* can receive funding - if they ask for it - pretty much immediately. the value they're offering is clear. i'm thinking in particular of joey hess. joey raised i think it was USD $100,000 in a DAY or something mad for an idea he had to create a distributed automated home directory mounting system based around git, so that people in the free software community could not just back up files off-site but also if they went to conferences or wherever they could *borrow* a random piece of equipment when they arrived and gain *direct* access to their home directory. here he is: https://joeyh.name/blog/entry/DIY_crowdfunding_and_bitcoin/ so interestingly he started on kickstarter (where his project immediately became a "staff pick"), then did a second campaign using his own infrastructure... because he's technically competent to handle that, and because he is extremely well-known and well-liked. and has consistently demonstrated an ability to *communicate* effectively with people across the world. this is what crowdsupply helped *me* with, enormously: they provided me with a platform where i could easily *communicate*. i had to do non-stop 6 hour marathons *every damn day* on different forums (70 in total over the course of the campaign - i kept a list so i could myself keep track), *and* still spend time to write updates (every 2-3 days), without which there wouldn't be anything *to* actually talk about on those various forums. so... if anything... the lesson is that it's not so much the medium or method as it is the ability (and the tools behind you) to communicate effectively. l. From pablo at parobalth.org Mon Jan 1 13:38:15 2018 From: pablo at parobalth.org (Pablo Rath) Date: Mon, 1 Jan 2018 14:38:15 +0100 Subject: [Arm-netbook] EOMA68 / Libre RISC-V team financing In-Reply-To: References: Message-ID: <20180101133815.cojli7qv2wsus63v@cherry> On Mon, Jan 01, 2018 at 09:34:47AM +0000, Luke Kenneth Casson Leighton wrote: > > > But such system should be created. > > How should it be founded? > > there do exist several. it does seem though that certain well-known > and well-respected people whose contribution has been consistent and > long-term *within their community* can receive funding - if they ask > for it - pretty much immediately. the value they're offering is > clear. i'm thinking in particular of joey hess. Today I read an interesting blogpost of Joey about Patreon, Liberapay and Bitcoin. He recently created a liberapay account and he hopes liberapay works out. Read the post here: https://joeyh.name/blog/entry/two_holiday_stories/ kind regards Pablo From lkcl at lkcl.net Mon Jan 1 13:55:49 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 1 Jan 2018 13:55:49 +0000 Subject: [Arm-netbook] EOMA68 / Libre RISC-V team financing In-Reply-To: <20180101133815.cojli7qv2wsus63v@cherry> References: <20180101133815.cojli7qv2wsus63v@cherry> Message-ID: On Mon, Jan 1, 2018 at 1:38 PM, Pablo Rath wrote: > Today I read an interesting blogpost of Joey about Patreon, Liberapay > and Bitcoin. > He recently created a liberapay account and he hopes liberapay works out. > Read the post here: > https://joeyh.name/blog/entry/two_holiday_stories/ thanks pablo. yeah joey's cool. btw that prompted me to investigate and change the username http://liberapay/lkcl l. From pablo at parobalth.org Mon Jan 1 14:00:24 2018 From: pablo at parobalth.org (Pablo Rath) Date: Mon, 1 Jan 2018 15:00:24 +0100 Subject: [Arm-netbook] EOMA68 / Libre RISC-V team financing (Luke Kenneth Casson Leighton) In-Reply-To: References: <87zi63s0hg.fsf@whist.hands.com> <287f0486-e220-e57e-dc85-1d3970ad4ffe@riseup.net> <87r2rb9pph.fsf@elephly.net> <1927801592.7037146.1514793522387@mail.yahoo.com> Message-ID: <20180101140024.5sozjgdtkz6vgey5@cherry> On Mon, Jan 01, 2018 at 09:08:14AM +0000, Luke Kenneth Casson Leighton wrote: > On Mon, Jan 1, 2018 at 7:58 AM, Chuck Card via arm-netbook > wrote: > > > I want to provide some additional funding, but I rather not open another > > account. Will paypal work for you? > > that would be perfect - it'll need to be to my partner marie's paypal > account? here's a convenient link: > > http://paypal.me/OrangeMarie > I understand everyone who does not want to open another account. I did a quick check and it appears that paypals fees can be substantially higher than those of liberapay. Paypals fees seems to depend if you pay right out of your paypal balance or from credit card via paypal and if it is U.S. domestic (which it is not as the paypal account of lukes partner marie is from the UK) or international. Liberapays fees seem especially reasonable if you have a bank account in the European Union kind regards Pablo From lkcl at lkcl.net Wed Jan 3 12:03:29 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 3 Jan 2018 12:03:29 +0000 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations--Taper In-Reply-To: References: <6A65EECD-D935-4BBA-B83C-42704C1051C9@gmail.com> <6C61086D-6BEA-47D1-B2FD-3F91F94B0591@gmail.com> <98EDE830-70C2-44AB-8DF6-FDA4FDE82CBF@gmail.com> <6EC93879-90EC-414B-A7C3-04674CFBB3E2@gmail.com> Message-ID: ok i'm done with the 0805 10uF capacitors, and mostly-done messing about looking at the gerber files for areas where ground tracks are missing. currently i've added a keepout area around the DDR3 lines because that's what i've seen done in other designs. gotta get moving on this, richard - it'll be another 5-6 weeks if we miss the window of opportunity before chinese new year. l. From richard.wilbur at gmail.com Thu Jan 4 00:22:22 2018 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Wed, 3 Jan 2018 17:22:22 -0700 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations--Taper In-Reply-To: References: <6A65EECD-D935-4BBA-B83C-42704C1051C9@gmail.com> <6C61086D-6BEA-47D1-B2FD-3F91F94B0591@gmail.com> <98EDE830-70C2-44AB-8DF6-FDA4FDE82CBF@gmail.com> <6EC93879-90EC-414B-A7C3-04674CFBB3E2@gmail.com> Message-ID: On Jan 3, 2018, at 05:03, Luke Kenneth Casson Leighton wrote: > > ok i'm done with the 0805 10uF capacitors, and mostly-done messing > about looking at the gerber files for areas where ground tracks are > missing. currently i've added a keepout area around the DDR3 lines > because that's what i've seen done in other designs. > > gotta get moving on this, richard - it'll be another 5-6 weeks if we > miss the window of opportunity before chinese new year. My initial feedback is it looks pretty nice. I sat down, read the documentation for the gerber viewer that comes with KiCAD and started getting my feet wet. One recommendation for now as I have to leave for choir rehearsal--do the same thing with additional ground traces north and south of the ESD pads on layer 6 as you did on layer 1 to bring the distance between pad and ground down from 15mil to around the same as the pad-to-pad spacing of the ESD component pads. From lkcl at lkcl.net Thu Jan 4 04:53:37 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 4 Jan 2018 04:53:37 +0000 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations--Taper In-Reply-To: References: <6A65EECD-D935-4BBA-B83C-42704C1051C9@gmail.com> <6C61086D-6BEA-47D1-B2FD-3F91F94B0591@gmail.com> <98EDE830-70C2-44AB-8DF6-FDA4FDE82CBF@gmail.com> <6EC93879-90EC-414B-A7C3-04674CFBB3E2@gmail.com> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Thu, Jan 4, 2018 at 12:22 AM, Richard Wilbur wrote: > My initial feedback is it looks pretty nice. I sat down, read the documentation > for the gerber viewer that comes with KiCAD and started getting my feet wet. good god. you read documentation?? :) > One recommendation for now as I have to leave for choir rehearsal--do > the same thing with additional ground traces north and south of the ESD > pads on layer 6 as you did on layer 1 to bring the distance between pad > and ground down from 15mil to around the same as the pad-to-pad spacing > of the ESD component pads. yep sorted. will send you new gerber set, for anyone else to see (and also make it easier for you, richard) attached screenshot. l. -------------- next part -------------- A non-text attachment was scrubbed... Name: Untitled1.jpg Type: image/jpeg Size: 21855 bytes Desc: not available URL: From richard.wilbur at gmail.com Thu Jan 4 05:20:44 2018 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Wed, 3 Jan 2018 22:20:44 -0700 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations--Taper In-Reply-To: References: <6A65EECD-D935-4BBA-B83C-42704C1051C9@gmail.com> <6C61086D-6BEA-47D1-B2FD-3F91F94B0591@gmail.com> <98EDE830-70C2-44AB-8DF6-FDA4FDE82CBF@gmail.com> <6EC93879-90EC-414B-A7C3-04674CFBB3E2@gmail.com> Message-ID: On Wed, Jan 3, 2018 at 9:53 PM, Luke Kenneth Casson Leighton wrote: > On Thu, Jan 4, 2018 at 12:22 AM, Richard Wilbur > wrote: > >> My initial feedback is it looks pretty nice. I sat down, read the documentation >> for the gerber viewer that comes with KiCAD and started getting my feet wet. > > good god. you read documentation?? :) I scanned it fairly quickly to get a good idea of how to interact with the program. That way I had some idea what the icons meant and what functions were available in the user interface. (Okay, I've written documentation before so I figured since it was available I'd look it over. It gave me a pretty quick idea of how the user interactions are structured.) >> One recommendation for now as I have to leave for choir rehearsal--do >> the same thing with additional ground traces north and south of the ESD >> pads on layer 6 as you did on layer 1 to bring the distance between pad >> and ground down from 15mil to around the same as the pad-to-pad spacing >> of the ESD component pads. > > yep sorted. will send you new gerber set, for anyone else to see > (and also make it easier for you, richard) attached screenshot. Beautiful! I think that was the most important change I noticed. I am mainly looking at the HDMI which we have been laboring over the last few months. My next suggestion has an associated question: I notice that north of the long east-west transmission line, at the northern keepout boundary on layer 6, there are a couple of vias that have almost complete ground shield between the vias and the HDMI TX2 pair. Question: What is the fill polygon width for ground fill on layer 6? I can see two fairly simple solutions to complete the ground shield around these vias: 1. Add traces to complete the ground shield between vias and HDMI differential pair. 2. Adjust trace/fill polygon width for ground fill on layer 6 till the ground shield is complete. I'll sleep on it and take another look tomorrow morning. From desttinghimgame at gmail.com Thu Jan 4 21:25:15 2018 From: desttinghimgame at gmail.com (Louis Pearson) Date: Thu, 4 Jan 2018 15:25:15 -0600 Subject: [Arm-netbook] Meltdown and Spectre In-Reply-To: References: Message-ID: Has anybody else seen the recently published exploits Meltdown and Spectre? Here's a link: https://meltdownattack.com/ I'm wondering if this will increase in Risc-V processors, as most will not be vulnerable to this exploit. It relies on speculative and out-of-order execution which most current Risc-V processors do not have. From adam at vany.ca Thu Jan 4 23:13:45 2018 From: adam at vany.ca (Adam Van Ymeren) Date: Thu, 04 Jan 2018 18:13:45 -0500 Subject: [Arm-netbook] Meltdown and Spectre In-Reply-To: (Louis Pearson's message of "Thu, 4 Jan 2018 15:25:15 -0600") References: Message-ID: <87inchjjyu.fsf@vany.ca> Louis Pearson writes: > Has anybody else seen the recently published exploits Meltdown and Spectre? > Here's a link: https://meltdownattack.com/ The thing about Meltdown/Spectre is that they're really only problems if you rely on sandboxing to run untrusted code. This should be more incentive to run on fully free software. If the only code you run on your machine is free software, then there's essentially zero risk of Meltdown/Spectre being an issue. An important point to highlight is that this includes JavaScript that most people run in the browser. The JavaScript Trap [1] as Stallman explained a few years ago. If people can take back control of their computing but running free software and moving off virtual servers to dedicated serveres or their own product like FreedomBox [2] then issues like meltdown/spectre don't matter. [1] - https://www.gnu.org/philosophy/po/javascript-trap.ja-en.html [2] - https://freedomboxfoundation.org/ From hendrik at topoi.pooq.com Fri Jan 5 01:18:21 2018 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 4 Jan 2018 20:18:21 -0500 Subject: [Arm-netbook] Meltdown and Spectre In-Reply-To: <87inchjjyu.fsf@vany.ca> References: <87inchjjyu.fsf@vany.ca> Message-ID: <20180105011821.GA16866@topoi.pooq.com> On Thu, Jan 04, 2018 at 06:13:45PM -0500, Adam Van Ymeren wrote: > Louis Pearson writes: > > > Has anybody else seen the recently published exploits Meltdown and Spectre? > > Here's a link: https://meltdownattack.com/ > > The thing about Meltdown/Spectre is that they're really only problems if > you rely on sandboxing to run untrusted code. It doesn't care whether you sandbox. It makes a privilege escalation possible. If untrustworthy code runs with few privileges, it can exfiltrate enough information to accomplish a privilege escalation. The point of mentioneing the sandbox is simply that the sandbox doesn't help. Of courses it doesn't matter if you trust the code. It matters if it is trustworthy. -- hendrik From adam at vany.ca Fri Jan 5 02:32:42 2018 From: adam at vany.ca (Adam Van Ymeren) Date: Thu, 04 Jan 2018 21:32:42 -0500 Subject: [Arm-netbook] Meltdown and Spectre In-Reply-To: <20180105011821.GA16866@topoi.pooq.com> (Hendrik Boom's message of "Thu, 4 Jan 2018 20:18:21 -0500") References: <87inchjjyu.fsf@vany.ca> <20180105011821.GA16866@topoi.pooq.com> Message-ID: <87d12pjar9.fsf@vany.ca> Hendrik Boom writes: > On Thu, Jan 04, 2018 at 06:13:45PM -0500, Adam Van Ymeren wrote: >> Louis Pearson writes: >> >> > Has anybody else seen the recently published exploits Meltdown and Spectre? >> > Here's a link: https://meltdownattack.com/ >> >> The thing about Meltdown/Spectre is that they're really only problems if >> you rely on sandboxing to run untrusted code. > > It doesn't care whether you sandbox. It makes a privilege escalation > possible. If untrustworthy code runs with few privileges, it can > exfiltrate enough information to accomplish a privilege escalation. The > point of mentioneing the sandbox is simply that the sandbox doesn't > help. Yeah I didn't phrase that quite right. I meant that these vulnerabilites make it impossible to sandbox malicious code. > > Of courses it doesn't matter if you trust the code. It matters if it is > trustworthy. Indeed. From jackhill at jackhill.us Fri Jan 5 04:09:33 2018 From: jackhill at jackhill.us (Jack Hill) Date: Thu, 4 Jan 2018 23:09:33 -0500 (EST) Subject: [Arm-netbook] Meltdown and Spectre In-Reply-To: <87inchjjyu.fsf@vany.ca> References: <87inchjjyu.fsf@vany.ca> Message-ID: On Thu, 4 Jan 2018, Adam Van Ymeren wrote: > The thing about Meltdown/Spectre is that they're really only problems if > you rely on sandboxing to run untrusted code. I'm not convinced that sandboxing is only useful for untrusted code. Sometimes my trusted code has bugs (e.g. I would like to be able to look at random images or documents or expose my webapp to the world), and I would really like for it to not be able to be tricked into doing something it shouldn't. I would also like to be able to compute in shared environments. Best, Jack From jackhill at jackhill.us Fri Jan 5 04:55:49 2018 From: jackhill at jackhill.us (Jack Hill) Date: Thu, 4 Jan 2018 23:55:49 -0500 (EST) Subject: [Arm-netbook] Meltdown and Spectre In-Reply-To: References: <87inchjjyu.fsf@vany.ca> Message-ID: On Thu, 4 Jan 2018, Jack Hill wrote: > On Thu, 4 Jan 2018, Adam Van Ymeren wrote: > >> The thing about Meltdown/Spectre is that they're really only problems if >> you rely on sandboxing to run untrusted code. > > I'm not convinced that sandboxing is only useful for untrusted code. > Sometimes my trusted code has bugs (e.g. I would like to be able to look > at random images or documents or expose my webapp to the world), and > I would really like for it to not be able to be tricked into doing > something it shouldn't. I would also like to be able to compute in shared > environments. Oh, I guess it might be helpful to explain a little bit more why I would like to be able to continue to use shared computing environments. I've been increasing amazed and intimidated by what it takes to understand modern computing. One of my outlets for these emotions is Hcoöp [0], which is an internet service hosting coöperative. We run services such as email, web, and file collaboratively, which saves any one person for having to do all that work on their own. I appreciate the work of projects like Freedombox, but why stop the collaborating after writing the code? I want to be able to collaborate on running it as well! In addition, some things just don't make sense for all of us to own on our own. I might not often need a large memory or hundreds of core compute cluster, but when I do, it is nice to be able to use a shared resource rather than purchasing my own. Best, Jack [0] https://hcoop.net From richard.wilbur at gmail.com Fri Jan 5 07:32:26 2018 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Fri, 5 Jan 2018 00:32:26 -0700 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations--Taper In-Reply-To: References: <6A65EECD-D935-4BBA-B83C-42704C1051C9@gmail.com> <6C61086D-6BEA-47D1-B2FD-3F91F94B0591@gmail.com> <98EDE830-70C2-44AB-8DF6-FDA4FDE82CBF@gmail.com> <6EC93879-90EC-414B-A7C3-04674CFBB3E2@gmail.com> Message-ID: On Wed, Jan 3, 2018 at 10:20 PM, Richard Wilbur wrote: > I notice that north of the long east-west transmission line, at the > northern keepout boundary on layer 6, there are a couple of vias that > have almost complete ground shield between the vias and the HDMI TX2 > pair. > > Question: What is the fill polygon width for ground fill on layer 6? > > I can see two fairly simple solutions to complete the ground shield > around these vias: > 1. Add traces to complete the ground shield between vias and HDMI > differential pair. > 2. Adjust trace/fill polygon width for ground fill on layer 6 till > the ground shield is complete. > > I'll sleep on it and take another look tomorrow morning. Looks like you already addressed this in the latest gerbers! Any chance we could use another trace to even up the little dimples that are left in the edge facing the differential pairs? I glanced at parts of the rest of the board but it would be much more straightforward with the schematics. Do you have a way to compare changes with previous versions of the board to see if PADS did anything surprising behind your back? Sincerely, Richard From lkcl at lkcl.net Fri Jan 5 07:44:17 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 5 Jan 2018 07:44:17 +0000 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations--Taper In-Reply-To: References: <6A65EECD-D935-4BBA-B83C-42704C1051C9@gmail.com> <6C61086D-6BEA-47D1-B2FD-3F91F94B0591@gmail.com> <98EDE830-70C2-44AB-8DF6-FDA4FDE82CBF@gmail.com> <6EC93879-90EC-414B-A7C3-04674CFBB3E2@gmail.com> Message-ID: On Fri, Jan 5, 2018 at 7:32 AM, Richard Wilbur wrote: > Looks like you already addressed this in the latest gerbers! yehyeh. > Any > chance we could use another trace to even up the little dimples that > are left in the edge facing the differential pairs? always best to screenshot / arrow-mark it, richard. round-trip delays getting critical here, we're up to 5th january already. attached green arrows, i am guessing you mean, i remember you said that causes... something-or-other... capacitance-related? there's a few more like that back at the source diff-pair vias, i'll think about whether to drop a plain square keepout in place (to preserve 15mil) or a straight manual track. track would cut clearance to around 12mil. thoughts? > I glanced at parts of the rest of the board but it would be much more > straightforward with the schematics. not so concerned about the rest of the board, it's mainly the HDMI. PDF version of schematics should be here http://hands.com/~lkcl/eoma/DS113-V2.7-2017-02-17.pdf > Do you have a way to compare > changes with previous versions of the board to see if PADS did > anything surprising behind your back? the only way would be visual pdf diffs, and i've made several minor changes as well that would show up and need to be reviewed, one by one, and eliminated. i've found it's easier just to go over the board making minor tweaks, because each time i do so i find one more "little thing" such as a place where there's a capacitor that doesn't have a nearby GND via and so on. -------------- next part -------------- A non-text attachment was scrubbed... Name: Untitled.jpg Type: image/jpeg Size: 28600 bytes Desc: not available URL: From lkcl at lkcl.net Fri Jan 5 08:00:51 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 5 Jan 2018 08:00:51 +0000 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations--Taper In-Reply-To: References: <6A65EECD-D935-4BBA-B83C-42704C1051C9@gmail.com> <6C61086D-6BEA-47D1-B2FD-3F91F94B0591@gmail.com> <98EDE830-70C2-44AB-8DF6-FDA4FDE82CBF@gmail.com> <6EC93879-90EC-414B-A7C3-04674CFBB3E2@gmail.com> Message-ID: On Fri, Jan 5, 2018 at 7:44 AM, Luke Kenneth Casson Leighton wrote: > there's a few more like that back at the source diff-pair vias, i'll > think about whether to drop a plain square keepout in place (to > preserve 15mil) or a straight manual track. track would cut clearance > to around 12mil. thoughts? rectangular all-layers keepout, showing 1 and 3 here... damn layers 2 and 5 have a weird shape (not enough clearance auto-generated) let me make it an oval all-layers keepout instead... will deal with the other end next. l. -------------- next part -------------- A non-text attachment was scrubbed... Name: Untitled.jpg Type: image/jpeg Size: 10557 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Untitled.jpg Type: image/jpeg Size: 12854 bytes Desc: not available URL: From richard.wilbur at gmail.com Fri Jan 5 08:25:23 2018 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Fri, 5 Jan 2018 01:25:23 -0700 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations--Taper In-Reply-To: References: <6A65EECD-D935-4BBA-B83C-42704C1051C9@gmail.com> <6C61086D-6BEA-47D1-B2FD-3F91F94B0591@gmail.com> <98EDE830-70C2-44AB-8DF6-FDA4FDE82CBF@gmail.com> <6EC93879-90EC-414B-A7C3-04674CFBB3E2@gmail.com> Message-ID: On Fri, Jan 5, 2018 at 12:44 AM, Luke Kenneth Casson Leighton wrote: > On Fri, Jan 5, 2018 at 7:32 AM, Richard Wilbur wrote: >> Any >> chance we could use another trace to even up the little dimples that >> are left in the edge facing the differential pairs? > > always best to screenshot / arrow-mark it, richard. round-trip > delays getting critical here, we're up to 5th january already. I have attached a screenshot with red arrows. It is taken from the long straight differential microstrip transmission lines on layer 6. These are otherwise so clean and straight. > attached green arrows, i am guessing you mean, i remember you said > that causes... something-or-other... capacitance-related? The ones you marked weren't the ones I was looking at. I think they are probably fine as they aren't too sharp, they mind the 15mil clearance, and we are turning 90 degrees out of some signal vias onto the top of the board. (If they were pointing at a straight side I'd be more worried.) > there's a few more like that back at the source diff-pair vias, i'll > think about whether to drop a plain square keepout in place (to > preserve 15mil) or a straight manual track. track would cut clearance > to around 12mil. thoughts? It is kind of tumultuous with the pairs coming from close quarters on layer 1 and still to be sorted through the intra-pair skew-compensating wiggles. What you've done at that end looks much better. >> I glanced at parts of the rest of the board but it would be much more >> straightforward with the schematics. > > not so concerned about the rest of the board, it's mainly the HDMI. > PDF version of schematics should be here > http://hands.com/~lkcl/eoma/DS113-V2.7-2017-02-17.pdf I'll concentrate on the HDMI, then. >> Do you have a way to compare >> changes with previous versions of the board to see if PADS did >> anything surprising behind your back? > > the only way would be visual pdf diffs, and i've made several minor > changes as well that would show up and need to be reviewed, one by > one, and eliminated. i've found it's easier just to go over the board > making minor tweaks, because each time i do so i find one more "little > thing" such as a place where there's a capacitor that doesn't have a > nearby GND via and so on. Sounds good. -------------- next part -------------- A non-text attachment was scrubbed... Name: dimples_marked.png Type: image/png Size: 27610 bytes Desc: not available URL: From richard.wilbur at gmail.com Fri Jan 5 08:27:44 2018 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Fri, 5 Jan 2018 01:27:44 -0700 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations--Taper In-Reply-To: References: <6A65EECD-D935-4BBA-B83C-42704C1051C9@gmail.com> <6C61086D-6BEA-47D1-B2FD-3F91F94B0591@gmail.com> <98EDE830-70C2-44AB-8DF6-FDA4FDE82CBF@gmail.com> <6EC93879-90EC-414B-A7C3-04674CFBB3E2@gmail.com> Message-ID: On Fri, Jan 5, 2018 at 1:00 AM, Luke Kenneth Casson Leighton wrote: > On Fri, Jan 5, 2018 at 7:44 AM, Luke Kenneth Casson Leighton > wrote: > >> there's a few more like that back at the source diff-pair vias, i'll >> think about whether to drop a plain square keepout in place (to >> preserve 15mil) or a straight manual track. track would cut clearance >> to around 12mil. thoughts? > > rectangular all-layers keepout, showing 1 and 3 here... damn layers 2 > and 5 have a weird shape (not enough clearance auto-generated) let me > make it an oval all-layers keepout instead... Those do look very nice, indeed! From lkcl at lkcl.net Fri Jan 5 10:53:04 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 5 Jan 2018 10:53:04 +0000 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations--Taper In-Reply-To: References: <6A65EECD-D935-4BBA-B83C-42704C1051C9@gmail.com> <6C61086D-6BEA-47D1-B2FD-3F91F94B0591@gmail.com> <98EDE830-70C2-44AB-8DF6-FDA4FDE82CBF@gmail.com> <6EC93879-90EC-414B-A7C3-04674CFBB3E2@gmail.com> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Fri, Jan 5, 2018 at 8:25 AM, Richard Wilbur wrote: > On Fri, Jan 5, 2018 at 12:44 AM, Luke Kenneth Casson Leighton > wrote: >> On Fri, Jan 5, 2018 at 7:32 AM, Richard Wilbur wrote: >>> Any >>> chance we could use another trace to even up the little dimples that >>> are left in the edge facing the differential pairs? >> >> always best to screenshot / arrow-mark it, richard. round-trip >> delays getting critical here, we're up to 5th january already. > > I have attached a screenshot with red arrows. It is taken from the > long straight differential microstrip transmission lines on layer 6. > These are otherwise so clean and straight. gooot it. yehyeh there's signals (3V3) and stuff close by (unavoidably), and i have to put manual GND tracks in because the flood-fill won't blotch in to spaces narrower than 10mil... it's a setting somewhere and i kinda prefer it that way, otherwise flood-fill tends to get into some really small spaces and creates awkward-looking tiny shapes. >> attached green arrows, i am guessing you mean, i remember you said >> that causes... something-or-other... capacitance-related? > > The ones you marked weren't the ones I was looking at. I think they > are probably fine as they aren't too sharp, they mind the 15mil > clearance, and we are turning 90 degrees out of some signal vias onto > the top of the board. (If they were pointing at a straight side I'd > be more worried.) with you. >> there's a few more like that back at the source diff-pair vias, i'll >> think about whether to drop a plain square keepout in place (to >> preserve 15mil) or a straight manual track. track would cut clearance >> to around 12mil. thoughts? > > It is kind of tumultuous with the pairs coming from close quarters on > layer 1 and still to be sorted through the intra-pair > skew-compensating wiggles. What you've done at that end looks much > better. yay :) >>> I glanced at parts of the rest of the board but it would be much more >>> straightforward with the schematics. >> >> not so concerned about the rest of the board, it's mainly the HDMI. >> PDF version of schematics should be here >> http://hands.com/~lkcl/eoma/DS113-V2.7-2017-02-17.pdf > > I'll concentrate on the HDMI, then. yes please l. From lkcl at lkcl.net Fri Jan 5 11:05:44 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 5 Jan 2018 11:05:44 +0000 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations--Taper In-Reply-To: References: <6A65EECD-D935-4BBA-B83C-42704C1051C9@gmail.com> <6C61086D-6BEA-47D1-B2FD-3F91F94B0591@gmail.com> <98EDE830-70C2-44AB-8DF6-FDA4FDE82CBF@gmail.com> <6EC93879-90EC-414B-A7C3-04674CFBB3E2@gmail.com> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Fri, Jan 5, 2018 at 8:27 AM, Richard Wilbur wrote: > On Fri, Jan 5, 2018 at 1:00 AM, Luke Kenneth Casson Leighton > wrote: >> On Fri, Jan 5, 2018 at 7:44 AM, Luke Kenneth Casson Leighton >> wrote: >> >>> there's a few more like that back at the source diff-pair vias, i'll >>> think about whether to drop a plain square keepout in place (to >>> preserve 15mil) or a straight manual track. track would cut clearance >>> to around 12mil. thoughts? >> >> rectangular all-layers keepout, showing 1 and 3 here... damn layers 2 >> and 5 have a weird shape (not enough clearance auto-generated) let me >> make it an oval all-layers keepout instead... > > Those do look very nice, indeed! did the trick. pain doing them by hand, had to do the flood-fill, then adjust the keepout, then write down by hand the distances that the keepout fitted cleanly to the edges, _then_ throw that file away, _then_ go back and put the rectangle left-right... bletch :) anyway i moved the PWM via up a bit, left the 3V3 VIAs where they were - sorted. l. -------------- next part -------------- A non-text attachment was scrubbed... Name: Untitled.jpg Type: image/jpeg Size: 36833 bytes Desc: not available URL: From richard.wilbur at gmail.com Fri Jan 5 16:02:01 2018 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Fri, 5 Jan 2018 09:02:01 -0700 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations--Taper In-Reply-To: References: <6A65EECD-D935-4BBA-B83C-42704C1051C9@gmail.com> <6C61086D-6BEA-47D1-B2FD-3F91F94B0591@gmail.com> <98EDE830-70C2-44AB-8DF6-FDA4FDE82CBF@gmail.com> <6EC93879-90EC-414B-A7C3-04674CFBB3E2@gmail.com> Message-ID: On Fri, Jan 5, 2018 at 4:05 AM, Luke Kenneth Casson Leighton wrote: > On Fri, Jan 5, 2018 at 8:27 AM, Richard Wilbur wrote: >> On Fri, Jan 5, 2018 at 1:00 AM, Luke Kenneth Casson Leighton >> wrote: >>> rectangular all-layers keepout, showing 1 and 3 here... damn layers 2 >>> and 5 have a weird shape (not enough clearance auto-generated) let me >>> make it an oval all-layers keepout instead... >> >> Those do look very nice, indeed! > > did the trick. pain doing them by hand, had to do the flood-fill, > then adjust the keepout, then write down by hand the distances that > the keepout fitted cleanly to the edges, _then_ throw that file away, > _then_ go back and put the rectangle left-right... bletch :) > > anyway i moved the PWM via up a bit, left the 3V3 VIAs where they > were - sorted. The results are great! Thanks for all the hard work to make it happen. So I'm happy with the layout of the HDMI! I checked for vias in component pads (manufacturability issue) and since the gerber viewer I'm using complains about all the tools in the drill file when I load it, I can't see the via holes. So there may be several false alarms in this list. Could even be mostly false alarms. But I would definitely check out C3 on layer 1 as there seems to be a via in the middle of one of the pads. (Marked with red arrow in attached picture.) -------------- next part -------------- Component Pads Encroach Vias? Layer 1 C59, C60, C71 *C3 Layer 6 C139 C341 C340 C345 C332 C343 C335 C43 C69 C70 C99 C86 C106 C107 C57 C45 C50 C105 C108 C85 C96 C54 C38 C55 C85 C40, C41, C44 C305, C307, C308 -------------- next part -------------- A non-text attachment was scrubbed... Name: encroachment_marked.png Type: image/png Size: 29104 bytes Desc: not available URL: From lkcl at lkcl.net Sat Jan 6 04:28:55 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sat, 6 Jan 2018 04:28:55 +0000 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations--Taper In-Reply-To: References: <6A65EECD-D935-4BBA-B83C-42704C1051C9@gmail.com> <6C61086D-6BEA-47D1-B2FD-3F91F94B0591@gmail.com> <98EDE830-70C2-44AB-8DF6-FDA4FDE82CBF@gmail.com> <6EC93879-90EC-414B-A7C3-04674CFBB3E2@gmail.com> Message-ID: still doing these tiny little changes, it's just the way it goes: every time you look at the board in close zoom, it's like... "hmmm, yeah that could be improved" and this latest one, it's the (now pair of) capacitors for the main DDR3 power stabilisation. previously this was a single 0805 capacitor lined up vertically. there was plenty of connecting VIAs down to layer 4 DDR3 1.5v power plane.... but because there were a MASSIVE array of tracks underneath the GND pads there were no GND vias. whoops. and when replacing with two 0603 4.7uF capacitors, i maintained that mistake. i decided to turn both 0603 capacitors horizontal and then to beef up the number of GND vias. this has the unintended side-effect of drilling quite a lot of holes into the layer 4 DDR3 1.5v power plane however as the GND vias are at the edge of the plane i consider this acceptable. i have however made sure that the plane is free of holes for getting the actual 1.5v power *in* to the plane, if that makes any sense. anyway a few more things like this... richard if you're happy with the beginning of the HDMI area i'll send the gerbers off straight away. l. -------------- next part -------------- A non-text attachment was scrubbed... Name: Untitled.jpg Type: image/jpeg Size: 90400 bytes Desc: not available URL: From lkcl at lkcl.net Sat Jan 6 04:50:19 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sat, 6 Jan 2018 04:50:19 +0000 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations--Taper In-Reply-To: References: <6A65EECD-D935-4BBA-B83C-42704C1051C9@gmail.com> <6C61086D-6BEA-47D1-B2FD-3F91F94B0591@gmail.com> <98EDE830-70C2-44AB-8DF6-FDA4FDE82CBF@gmail.com> <6EC93879-90EC-414B-A7C3-04674CFBB3E2@gmail.com> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Fri, Jan 5, 2018 at 4:02 PM, Richard Wilbur wrote: > On Fri, Jan 5, 2018 at 4:05 AM, Luke Kenneth Casson Leighton > wrote: >> On Fri, Jan 5, 2018 at 8:27 AM, Richard Wilbur wrote: >>> On Fri, Jan 5, 2018 at 1:00 AM, Luke Kenneth Casson Leighton >>> wrote: >>>> rectangular all-layers keepout, showing 1 and 3 here... damn layers 2 >>>> and 5 have a weird shape (not enough clearance auto-generated) let me >>>> make it an oval all-layers keepout instead... >>> >>> Those do look very nice, indeed! >> >> did the trick. pain doing them by hand, had to do the flood-fill, >> then adjust the keepout, then write down by hand the distances that >> the keepout fitted cleanly to the edges, _then_ throw that file away, >> _then_ go back and put the rectangle left-right... bletch :) >> >> anyway i moved the PWM via up a bit, left the 3V3 VIAs where they >> were - sorted. > > The results are great! Thanks for all the hard work to make it happen. yeah you too. dang it's been a while :) > So I'm happy with the layout of the HDMI! aawesome > I checked for vias in component pads (manufacturability issue) and > since the gerber viewer I'm using complains about all the tools in the > drill file when I load it, I can't see the via holes. So there may be > several false alarms in this list. Could even be mostly false alarms. it's not. basically the trick has been, due to cramped space, to put at least 2 VIAs around power decoupling capacitors (not done by me), and they're just on the edge. space is pretty crowded and all previous boards worked fine (and there's been a *lot* of pre-production boards now). > But I would definitely check out C3 on layer 1 as there seems to be a > via in the middle of one of the pads. (Marked with red arrow in > attached picture.) yehyeh good call that one was me, i had to reorganise the nearby (East) power capacitors, and shuffle (West) the components next door, in order to fit two (horizontal) 0603 4.7uF where there was previously one (vertical) 0805 10uF. shuffled that VIA up as there's plenty of space. iiii think we're good. now the only concern is, blasted frickin apple, has sucked world-wide demand not just for the entire supply of 0.1 10 and 100uF capacitors but f*****g DDR3 and eMMC *as well*. i now have to be extremely careful on selecting the right DDR3 RAM ICs... *sigh*. l. From lkcl at lkcl.net Sat Jan 6 05:37:27 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sat, 6 Jan 2018 05:37:27 +0000 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations--Taper In-Reply-To: References: <6A65EECD-D935-4BBA-B83C-42704C1051C9@gmail.com> <6C61086D-6BEA-47D1-B2FD-3F91F94B0591@gmail.com> <98EDE830-70C2-44AB-8DF6-FDA4FDE82CBF@gmail.com> <6EC93879-90EC-414B-A7C3-04674CFBB3E2@gmail.com> Message-ID: ok gerbers sent. waiting for confirmation from mike. with DDR3 prices being insane i'm not going to push hard for the PCB to be made, nor the assembly done in a hurry. l. From richard.wilbur at gmail.com Sat Jan 6 06:24:35 2018 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Fri, 5 Jan 2018 23:24:35 -0700 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations--Taper In-Reply-To: References: <6A65EECD-D935-4BBA-B83C-42704C1051C9@gmail.com> <6C61086D-6BEA-47D1-B2FD-3F91F94B0591@gmail.com> <98EDE830-70C2-44AB-8DF6-FDA4FDE82CBF@gmail.com> <6EC93879-90EC-414B-A7C3-04674CFBB3E2@gmail.com> Message-ID: <21CC9CE5-A091-4FCF-924A-D7D0DD4D9FEE@gmail.com> On Jan 5, 2018, at 21:28, Luke Kenneth Casson Leighton wrote: > > still doing these tiny little changes, it's just the way it goes: > every time you look at the board in close zoom, it's like... "hmmm, > yeah that could be improved" and this latest one, it's the (now pair > of) capacitors for the main DDR3 power stabilisation. > > previously this was a single 0805 capacitor lined up vertically. > there was plenty of connecting VIAs down to layer 4 DDR3 1.5v power > plane.... but because there were a MASSIVE array of tracks underneath > the GND pads there were no GND vias. whoops. and when replacing with > two 0603 4.7uF capacitors, i maintained that mistake. > > i decided to turn both 0603 capacitors horizontal and then to beef up > the number of GND vias. this has the unintended side-effect of > drilling quite a lot of holes into the layer 4 DDR3 1.5v power plane > however as the GND vias are at the edge of the plane i consider this > acceptable. i have however made sure that the plane is free of holes > for getting the actual 1.5v power *in* to the plane, if that makes any > sense. Good stuff. Should make the power supply more stable for the DDR3 RAM chips! > anyway a few more things like this... richardt if you're happy with the > beginning of the HDMI area i'll send the gerbers off straight away. I am happy with the HDMI but I was going to ask about silkscreen on pads--I saw several instances of silkscreen on areas you'll want covered in solder. Sorry I didn't bring it up earlier. Not a problem if you aren't having the silkscreen printed. Your board fab may also do the right thing and move the offending notations. From lkcl at lkcl.net Sat Jan 6 06:27:13 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sat, 6 Jan 2018 06:27:13 +0000 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations--Taper In-Reply-To: <21CC9CE5-A091-4FCF-924A-D7D0DD4D9FEE@gmail.com> References: <6A65EECD-D935-4BBA-B83C-42704C1051C9@gmail.com> <6C61086D-6BEA-47D1-B2FD-3F91F94B0591@gmail.com> <98EDE830-70C2-44AB-8DF6-FDA4FDE82CBF@gmail.com> <6EC93879-90EC-414B-A7C3-04674CFBB3E2@gmail.com> <21CC9CE5-A091-4FCF-924A-D7D0DD4D9FEE@gmail.com> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Sat, Jan 6, 2018 at 6:24 AM, Richard Wilbur wrote: > I am happy with the HDMI but I was going to ask about silkscreen on pads--I saw several instances of silkscreen on areas you'll want covered in solder. Sorry I didn't bring it up earlier. Not a problem if you aren't having the silkscreen printed. Your board fab may also do the right thing and move the offending notations. they do. they exclude silkscreen from solder mask areas. l. From richard.wilbur at gmail.com Sat Jan 6 06:35:35 2018 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Fri, 5 Jan 2018 23:35:35 -0700 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations--Taper In-Reply-To: References: <6A65EECD-D935-4BBA-B83C-42704C1051C9@gmail.com> <6C61086D-6BEA-47D1-B2FD-3F91F94B0591@gmail.com> <98EDE830-70C2-44AB-8DF6-FDA4FDE82CBF@gmail.com> <6EC93879-90EC-414B-A7C3-04674CFBB3E2@gmail.com> Message-ID: On Jan 5, 2018, at 21:50, Luke Kenneth Casson Leighton wrote: >> On Fri, Jan 5, 2018 at 4:02 PM, Richard Wilbur wrote: >> On Fri, Jan 5, 2018 at 4:05 AM, Luke Kenneth Casson Leighton >> wrote: >>> On Fri, Jan 5, 2018 at 8:27 AM, Richard Wilbur wrote: >>>> On Fri, Jan 5, 2018 at 1:00 AM, Luke Kenneth Casson Leighton >>>> wrote: > > it's not. basically the trick has been, due to cramped space, to put > at least 2 VIAs around power decoupling capacitors (not done by me), > and they're just on the edge. space is pretty crowded and all > previous boards worked fine (and there's been a *lot* of > pre-production boards now). In that case, no problem. >> But I would definitely check out C3 on layer 1 as there seems to be a >> via in the middle of one of the pads. (Marked with red arrow in >> attached picture.) > > yehyeh good call that one was me, i had to reorganise the nearby > (East) power capacitors, and shuffle (West) the components next door, > in order to fit two (horizontal) 0603 4.7uF where there was previously > one (vertical) 0805 10uF. > > shuffled that VIA up as there's plenty of space. > > iiii think we're good. Well I'm glad I looked and you had chance to fix it! > now the only concern is, blasted frickin apple, has sucked world-wide > demand not just for the entire supply of 0.1 10 and 100uF capacitors > but f*****g DDR3 and eMMC *as well*. > > i now have to be extremely careful on selecting the right DDR3 RAM > ICs... *sigh*. So the situation is the chips at the speed you designed for are much more expensive while faster ones are cheaper? So the trick is how to choose a faster chip and integrate successfully into a system running at lower speed than it is specified for? From richard.wilbur at gmail.com Sat Jan 6 06:39:51 2018 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Fri, 5 Jan 2018 23:39:51 -0700 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations--Taper In-Reply-To: References: <6A65EECD-D935-4BBA-B83C-42704C1051C9@gmail.com> <6C61086D-6BEA-47D1-B2FD-3F91F94B0591@gmail.com> <98EDE830-70C2-44AB-8DF6-FDA4FDE82CBF@gmail.com> <6EC93879-90EC-414B-A7C3-04674CFBB3E2@gmail.com> <21CC9CE5-A091-4FCF-924A-D7D0DD4D9FEE@gmail.com> Message-ID: <39627E50-AB0B-49B2-B942-E6B344E49A0E@gmail.com> On Jan 5, 2018, at 23:27, Luke Kenneth Casson Leighton wrote: > On Sat, Jan 6, 2018 at 6:24 AM, Richard Wilbur wrote: >> I am happy with the HDMI but I was going to ask about silkscreen on pads--I saw several instances of silkscreen on areas you'll want covered in solder. Sorry I didn't bring it up earlier. Not a problem if you aren't having the silkscreen printed. Your board fab may also do the right thing and move the offending notations. > > they do. they exclude silkscreen from solder mask areas. Wonderful! One less problem to worry about. From richard.wilbur at gmail.com Sat Jan 6 06:45:03 2018 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Fri, 5 Jan 2018 23:45:03 -0700 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations--Taper In-Reply-To: References: <6A65EECD-D935-4BBA-B83C-42704C1051C9@gmail.com> <6C61086D-6BEA-47D1-B2FD-3F91F94B0591@gmail.com> <98EDE830-70C2-44AB-8DF6-FDA4FDE82CBF@gmail.com> <6EC93879-90EC-414B-A7C3-04674CFBB3E2@gmail.com> Message-ID: On Jan 5, 2018, at 22:37, Luke Kenneth Casson Leighton wrote: > ok gerbers sent. waiting for confirmation from mike. Cheers! > with DDR3 > prices being insane i'm not going to push hard for the PCB to be made, > nor the assembly done in a hurry. Not having a rush on PCB fabrication or assembly may help control costs. Do you see DDR3 prices relaxing after Chinese New Year? From lkcl at lkcl.net Sat Jan 6 06:49:28 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sat, 6 Jan 2018 06:49:28 +0000 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations--Taper In-Reply-To: References: <6A65EECD-D935-4BBA-B83C-42704C1051C9@gmail.com> <6C61086D-6BEA-47D1-B2FD-3F91F94B0591@gmail.com> <98EDE830-70C2-44AB-8DF6-FDA4FDE82CBF@gmail.com> <6EC93879-90EC-414B-A7C3-04674CFBB3E2@gmail.com> Message-ID: On Sat, Jan 6, 2018 at 6:35 AM, Richard Wilbur wrote: >> now the only concern is, blasted frickin apple, has sucked world-wide >> demand not just for the entire supply of 0.1 10 and 100uF capacitors >> but f*****g DDR3 and eMMC *as well*. >> >> i now have to be extremely careful on selecting the right DDR3 RAM >> ICs... *sigh*. > > So the situation is the chips at the speed you designed for are > much more expensive while faster ones are cheaper? yyup... except it's more complicated than that: insatiable demand for fulfilling apple apple apple apple apple apple orders is driving EVERYTHING up as there is only a fixed capacity at the foundries making DDR RAM. consequently, all remaining DDR RAM ICs at *ALL* capacities and sizes are falling behind... consequently prices are spiralling out of control. > So the trick is how to choose a faster chip and integrate successfully into a system running at lower speed than it is specified for? yyup. have to use the 1800mhz 1.5v x8 DDR3 IC, which fortunately happens to be down-compatible with 667mhz. the 1.35v DDR3L variant of the same chip is *not*. still, i cannot risk just relying on one possible DDR3 IC, so i will have to source 1600mhz as well... and also last resort a 2gigabit IC which will total, qty 4, only 1GBYTE of RAM. the budget's fixed... it's just the way it's going to have to be. make adjustments that fit within the budget, end of story. l. From lkcl at lkcl.net Sat Jan 6 06:49:52 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sat, 6 Jan 2018 06:49:52 +0000 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations--Taper In-Reply-To: References: <6A65EECD-D935-4BBA-B83C-42704C1051C9@gmail.com> <6C61086D-6BEA-47D1-B2FD-3F91F94B0591@gmail.com> <98EDE830-70C2-44AB-8DF6-FDA4FDE82CBF@gmail.com> <6EC93879-90EC-414B-A7C3-04674CFBB3E2@gmail.com> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Sat, Jan 6, 2018 at 6:45 AM, Richard Wilbur wrote: > On Jan 5, 2018, at 22:37, Luke Kenneth Casson Leighton wrote: >> ok gerbers sent. waiting for confirmation from mike. > > Cheers! > >> with DDR3 >> prices being insane i'm not going to push hard for the PCB to be made, >> nor the assembly done in a hurry. > > Not having a rush on PCB fabrication or assembly may help control costs. > Do you see DDR3 prices relaxing after Chinese New Year? absolutely no idea, and no way to tell. l. From richard.wilbur at gmail.com Sat Jan 6 07:12:23 2018 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Sat, 6 Jan 2018 00:12:23 -0700 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations--Taper In-Reply-To: References: <6A65EECD-D935-4BBA-B83C-42704C1051C9@gmail.com> <6C61086D-6BEA-47D1-B2FD-3F91F94B0591@gmail.com> <98EDE830-70C2-44AB-8DF6-FDA4FDE82CBF@gmail.com> <6EC93879-90EC-414B-A7C3-04674CFBB3E2@gmail.com> Message-ID: <23857C94-1607-4C78-8BC6-FAB76C2C53F7@gmail.com> On Jan 5, 2018, at 23:49, Luke Kenneth Casson Leighton wrote: > > On Sat, Jan 6, 2018 at 6:35 AM, Richard Wilbur wrote: >> So the trick is how to choose a faster chip and integrate successfully into a system running at lower speed than it is specified for? > > yyup. have to use the 1800mhz 1.5v x8 DDR3 IC, which fortunately > happens to be down-compatible with 667mhz. the 1.35v DDR3L variant of > the same chip is *not*. Your changes to the power supply capacitors and vias should help accommodate faster edges, etc. from the faster chips. > still, i cannot risk just relying on one possible DDR3 IC, so i will > have to source 1600mhz as well... and also last resort a 2gigabit IC > which will total, qty 4, only 1GBYTE of RAM. > > the budget's fixed... it's just the way it's going to have to be. > make adjustments that fit within the budget, end of story. Here's hoping the faster ones fit the budget and the circuit as I'm a big fan of providing as much RAM as possible! From lkcl at lkcl.net Sat Jan 6 09:17:33 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sat, 6 Jan 2018 09:17:33 +0000 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations--Taper In-Reply-To: <23857C94-1607-4C78-8BC6-FAB76C2C53F7@gmail.com> References: <6A65EECD-D935-4BBA-B83C-42704C1051C9@gmail.com> <6C61086D-6BEA-47D1-B2FD-3F91F94B0591@gmail.com> <98EDE830-70C2-44AB-8DF6-FDA4FDE82CBF@gmail.com> <6EC93879-90EC-414B-A7C3-04674CFBB3E2@gmail.com> <23857C94-1607-4C78-8BC6-FAB76C2C53F7@gmail.com> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Sat, Jan 6, 2018 at 7:12 AM, Richard Wilbur wrote: >> yyup. have to use the 1800mhz 1.5v x8 DDR3 IC, which fortunately >> happens to be down-compatible with 667mhz. the 1.35v DDR3L variant of >> the same chip is *not*. > > Your changes to the power supply capacitors and vias should > help accommodate faster edges, etc. from the faster chips. yehyeh. not sure if the A20 can handle faster, but we'll see what happens. some people have managed 450mhz i think. l. From richard.wilbur at gmail.com Sat Jan 6 14:28:45 2018 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Sat, 6 Jan 2018 07:28:45 -0700 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations--Taper In-Reply-To: References: <6A65EECD-D935-4BBA-B83C-42704C1051C9@gmail.com> <6C61086D-6BEA-47D1-B2FD-3F91F94B0591@gmail.com> <98EDE830-70C2-44AB-8DF6-FDA4FDE82CBF@gmail.com> <6EC93879-90EC-414B-A7C3-04674CFBB3E2@gmail.com> Message-ID: <781919D6-16AB-42B9-8238-6A0FD7A03FBA@gmail.com> On Jan 5, 2018, at 23:49, Luke Kenneth Casson Leighton wrote: > > On Sat, Jan 6, 2018 at 6:35 AM, Richard Wilbur wrote: >> So the trick is how to choose a faster chip and integrate successfully into a system running at lower speed than it is specified for? > > yyup. have to use the 1800mhz 1.5v x8 DDR3 IC, which fortunately > happens to be down-compatible with 667mhz. the 1.35v DDR3L variant of > the same chip is *not*. I was doing a little reading about DDR3 and noticed the 1.35V DDR3L memory chips are happy talking/running with 1.5V DDR3 systems.[1] So are you saying the 1800mhz 1.35v x8 DDR3L IC is not happy running at 667MHz? (Clock rate incompatibility versus voltage incompatibility?) References: [1] https://en.m.wikipedia.org/wiki/DDR3_SDRAM From lkcl at lkcl.net Sat Jan 6 16:00:24 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sat, 6 Jan 2018 16:00:24 +0000 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations--Taper In-Reply-To: <781919D6-16AB-42B9-8238-6A0FD7A03FBA@gmail.com> References: <6A65EECD-D935-4BBA-B83C-42704C1051C9@gmail.com> <6C61086D-6BEA-47D1-B2FD-3F91F94B0591@gmail.com> <98EDE830-70C2-44AB-8DF6-FDA4FDE82CBF@gmail.com> <6EC93879-90EC-414B-A7C3-04674CFBB3E2@gmail.com> <781919D6-16AB-42B9-8238-6A0FD7A03FBA@gmail.com> Message-ID: =On Sat, Jan 6, 2018 at 2:28 PM, Richard Wilbur wrote: > On Jan 5, 2018, at 23:49, Luke Kenneth Casson Leighton wrote: >> >> On Sat, Jan 6, 2018 at 6:35 AM, Richard Wilbur wrote: >>> So the trick is how to choose a faster chip and integrate successfully into a system running at lower speed than it is specified for? >> >> yyup. have to use the 1800mhz 1.5v x8 DDR3 IC, which fortunately >> happens to be down-compatible with 667mhz. the 1.35v DDR3L variant of >> the same chip is *not*. > > I was doing a little reading about DDR3 and noticed the 1.35V DDR3L memory chips are happy talking/running with 1.5V DDR3 systems.[1] So are you saying the 1800mhz 1.35v x8 DDR3L IC is not happy running at 667MHz? (Clock rate incompatibility versus voltage incompatibility?) correct. the 1800mhz hynix 1.35v is specifically cut off from supporting 667mhz and 800mhz modes. this boards' DDR3 layout is... not... exactly... great... but it works, as long as you don't go over 350mhz. funnily enough that turns out to be absolutely fine because four DDR3x8 ICs running at 350mhz is abouuut.... half a watt or thereabouts. power consumption goes up on a square law so it would be really bad to run much faster, even if it was possible. l. From ronwirring at Safe-mail.net Sat Jan 6 19:29:42 2018 From: ronwirring at Safe-mail.net (ronwirring at Safe-mail.net) Date: Sat, 6 Jan 2018 14:29:42 -0500 Subject: [Arm-netbook] will orange pi zero run libre version of freedombox? Message-ID: http://www.orangepi.org/orangepizero/ One or more of the freedombox images are libre software? Is there a libre software version of freedombox, which will run on the orange pi 0? Thank you. From ronwirring at Safe-mail.net Sun Jan 7 12:05:38 2018 From: ronwirring at Safe-mail.net (ronwirring at Safe-mail.net) Date: Sun, 7 Jan 2018 07:05:38 -0500 Subject: [Arm-netbook] EOMA68 / Libre RISC-V team financing Message-ID: -------- Original Message -------- From: Luke Kenneth Casson Leighton Apparently from: arm-netbook-bounces at lists.phcomp.co.uk To: Linux on small ARM machines Subject: [Arm-netbook] EOMA68 / Libre RISC-V team financing Date: Wed, 27 Dec 2017 09:59:04 +0000 > i find sources of funds Have you considered talking to http://www.lowrisc.org/? I do not think they have money. Maybe lowrisc can direct you to paid tasks. > 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 Jan 7 12:07:29 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 7 Jan 2018 12:07:29 +0000 Subject: [Arm-netbook] EOMA68 / Libre RISC-V team financing In-Reply-To: References: Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Sun, Jan 7, 2018 at 12:05 PM, wrote: > -------- Original Message -------- > From: Luke Kenneth Casson Leighton > Apparently from: arm-netbook-bounces at lists.phcomp.co.uk > To: Linux on small ARM machines > Subject: [Arm-netbook] EOMA68 / Libre RISC-V team financing > Date: Wed, 27 Dec 2017 09:59:04 +0000 > > >> i find sources of funds > > Have you considered talking to http://www.lowrisc.org/? i have > I do not think they have money. > Maybe lowrisc can direct you to paid tasks. they can't... but i was contacted by someone anonymously who sponsored me with a USD $2500 Zynq ZC706 FPGA developer kit. l. From mike.valk at gmail.com Mon Jan 8 08:29:59 2018 From: mike.valk at gmail.com (mike.valk at gmail.com) Date: Mon, 8 Jan 2018 09:29:59 +0100 Subject: [Arm-netbook] Crowsupply update Message-ID: https://www.crowdsupply.com/eoma68/micro-desktop/updates/eoma68-a20-2-7-5-gerbers-off-to-factory-thank-you-to-everyone-for-the-sponsorship From lkcl at lkcl.net Mon Jan 8 08:31:04 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 8 Jan 2018 08:31:04 +0000 Subject: [Arm-netbook] Crowsupply update In-Reply-To: References: Message-ID: oh that was quick, mike :) --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Mon, Jan 8, 2018 at 8:29 AM, mike.valk at gmail.com wrote: > https://www.crowdsupply.com/eoma68/micro-desktop/updates/eoma68-a20-2-7-5-gerbers-off-to-factory-thank-you-to-everyone-for-the-sponsorship > > _______________________________________________ > 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 lasich at gmail.com Mon Jan 8 09:08:08 2018 From: lasich at gmail.com (Hrvoje Lasic) Date: Mon, 8 Jan 2018 10:08:08 +0100 Subject: [Arm-netbook] Crowsupply update In-Reply-To: References: Message-ID: does it make sense before mass produce, make i.e 5 pcs and test? I understand PCB have been tested already, there is Chinese NT coming and most certainly all is ok but still! On 8 January 2018 at 09:31, Luke Kenneth Casson Leighton wrote: > oh that was quick, mike :) > --- > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 > > > On Mon, Jan 8, 2018 at 8:29 AM, mike.valk at gmail.com > wrote: > > https://www.crowdsupply.com/eoma68/micro-desktop/updates/ > eoma68-a20-2-7-5-gerbers-off-to-factory-thank-you-to- > everyone-for-the-sponsorship > > > > _______________________________________________ > > 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 > > _______________________________________________ > 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 Mon Jan 8 09:15:34 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 8 Jan 2018 09:15:34 +0000 Subject: [Arm-netbook] Crowsupply update In-Reply-To: References: Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Mon, Jan 8, 2018 at 9:08 AM, Hrvoje Lasic wrote: > does it make sense before mass produce, make i.e 5 pcs and test? question. would it be better to make 1000, only to discover that there's a fatal undetected design flaw? > I understand PCB have been tested already, 2.7.4 - which is COMPLETELY different layout from 2.7.5 - has been tested. 2.7.5 has not. even one track wrong - especially if it is in the middle layers - can result in a fatal error. that's ONE change!! on the original DS113 board from 4(!) years ago, the person doing the layout FAILED to run DRC before sending it to production. he had laid a track that crossed over a pad. it was a pretty damn obvious mistake. we paid USD 10,000 to that team. l. From lasich at gmail.com Mon Jan 8 09:32:39 2018 From: lasich at gmail.com (Hrvoje Lasic) Date: Mon, 8 Jan 2018 10:32:39 +0100 Subject: [Arm-netbook] Crowsupply update In-Reply-To: References: Message-ID: agree on your points. did you ever think about in investing in small PNP machine (or just small oven plus some hand tools), like being able to produce small batch in house and test it qucikly? do you have any idea how reliable www.openpnp.org project is currently, for example to meet your specs on board with soem available hardware? On 8 January 2018 at 10:15, Luke Kenneth Casson Leighton wrote: > --- > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 > > > On Mon, Jan 8, 2018 at 9:08 AM, Hrvoje Lasic wrote: > > does it make sense before mass produce, make i.e 5 pcs and test? > > question. would it be better to make 1000, only to discover that > there's a fatal undetected design flaw? > > > I understand PCB have been tested already, > > 2.7.4 - which is COMPLETELY different layout from 2.7.5 - has been tested. > > 2.7.5 has not. > > even one track wrong - especially if it is in the middle layers - can > result in a fatal error. that's ONE change!! > > on the original DS113 board from 4(!) years ago, the person doing the > layout FAILED to run DRC before sending it to production. he had laid > a track that crossed over a pad. it was a pretty damn obvious > mistake. > > we paid USD 10,000 to that team. > > 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 Mon Jan 8 10:06:18 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 8 Jan 2018 10:06:18 +0000 Subject: [Arm-netbook] Crowsupply update In-Reply-To: References: Message-ID: On Mon, Jan 8, 2018 at 9:32 AM, Hrvoje Lasic wrote: > agree on your points. > > did you ever think about in investing in small PNP machine (or just small > oven plus some hand tools), like being able to produce small batch in house > and test it qucikly? yehyeh, i did - at one point. although mike only charges abouuut... USD $300-400 for assembly. plus... i need to have a stable base otherwise i am disassembling equipment and shipping it overseas. last year i borrowed someone's equipment, i managed to do two of the RK3288 boards. RAM ICs $12 each (QTY 4 so that's... $48 in RAM ICs...), 650-pin 0.5mm pitch BGA processor $12.... you get that wrong it's f*****g expensive. by contrast whomever mike uses, apart from not filling in the huge 3mm hole under the AXP209 (i've now changed that to a hatch-pattern of about 15 small vias), i haven't actually had a board failure except where the USB-OTG and Micro-HDMI connectors had to be hand-soldered. > do you have any idea how reliable www.openpnp.org project is currently, for > example to meet your specs on board with soem available hardware? i did investigate openpnp - the critical thing if you are going to make one of those is, the rod across to the other side to keep the 2 belts in sync is **NOT** optional. the distance (span) is too great (600mm) for a single belt to reliablly keep the head position (H style) steady by driving only ONE side of the horizontal part of the "H". you MUST put the rod across so that the motor drives BOTH sides of the horizontal cross bar EQUALLY. here's the thing: if i was intending to manufacture boards "from home", no problem. set up a nice business, stay in one plaaaace, become a home-grown electronics factory, maybe in 10 years have a nice retirement fund. it's a nice thought, isn't it? :) but i'm not going there... that's not my life's purpose. l. From lasich at gmail.com Mon Jan 8 10:41:12 2018 From: lasich at gmail.com (Hrvoje Lasic) Date: Mon, 8 Jan 2018 11:41:12 +0100 Subject: [Arm-netbook] Crowsupply update In-Reply-To: References: Message-ID: On 8 January 2018 at 11:06, Luke Kenneth Casson Leighton wrote: > On Mon, Jan 8, 2018 at 9:32 AM, Hrvoje Lasic wrote: > > agree on your points. > > > > did you ever think about in investing in small PNP machine (or just small > > oven plus some hand tools), like being able to produce small batch in > house > > and test it qucikly? > > yehyeh, i did - at one point. although mike only charges abouuut... > USD $300-400 for assembly. plus... i need to have a stable base > otherwise i am disassembling equipment and shipping it overseas. > > last year i borrowed someone's equipment, i managed to do two of the > RK3288 boards. RAM ICs $12 each (QTY 4 so that's... $48 in RAM > ICs...), 650-pin 0.5mm pitch BGA processor $12.... you get that wrong > it's f*****g expensive. > > by contrast whomever mike uses, apart from not filling in the huge > 3mm hole under the AXP209 (i've now changed that to a hatch-pattern of > about 15 small vias), i haven't actually had a board failure except > where the USB-OTG and Micro-HDMI connectors had to be hand-soldered. > > > do you have any idea how reliable www.openpnp.org project is currently, > for > > example to meet your specs on board with soem available hardware? > > i did investigate openpnp - the critical thing if you are going to > make one of those is, the rod across to the other side to keep the 2 > belts in sync is **NOT** optional. the distance (span) is too great > (600mm) for a single belt to reliablly keep the head position (H > style) steady by driving only ONE side of the horizontal part of the > "H". you MUST put the rod across so that the motor drives BOTH sides > of the horizontal cross bar EQUALLY. > > here's the thing: if i was intending to manufacture boards "from > home", no problem. set up a nice business, stay in one plaaaace, > become a home-grown electronics factory, maybe in 10 years have a nice > retirement fund. it's a nice thought, isn't it? :) but i'm not > going there... that's not my life's purpose. > > l. > Agree, but I am more thinking in getting through lets say between 10 and couple of hundred board production. If you have 1000 pcs and stable pcb most likely you will order that in China. But that point that really kicks from zero to 1000 is critical as well as fast prototyping. But from perspective of your current project maybe not an issue as you need to produce it in qty, also later hopefully 1000 pcs may be not issue. But if you are small, starting business producing 100 pcs in house looks like good option. From lkcl at lkcl.net Mon Jan 8 11:17:50 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 8 Jan 2018 11:17:50 +0000 Subject: [Arm-netbook] Crowsupply update In-Reply-To: References: Message-ID: On Mon, Jan 8, 2018 at 10:41 AM, Hrvoje Lasic wrote: > But if you are small, starting business producing 100 pcs in house looks > like good option. yehyeh absolutely. i am however extremely lucky with mike, he will tolerate 100 pcs orders. l. From njansen1 at gmail.com Mon Jan 8 14:28:42 2018 From: njansen1 at gmail.com (Neil Jansen) Date: Mon, 8 Jan 2018 09:28:42 -0500 Subject: [Arm-netbook] Crowsupply update In-Reply-To: References: Message-ID: On Mon, Jan 8, 2018 at 4:32 AM, Hrvoje Lasic wrote: > did you ever think about in investing in small PNP machine (or just small > oven plus some hand tools), like being able to produce small batch in house > and test it qucikly? > No, this would be a horrible idea, I speak from experience here. If the end-product had a few parts (Arduino-ish, BOM < 30 parts), if the smallest passives were 0603's and if the smallest IC's were SSOP's, then yea it MIGHT be doable. But the EOMA68 board has BGA's and (I'm guessing) 0402's and likely some 0201's? The yield rate in a DIY situation would be prohibitive. It is actually cheaper to pay the labor rates and NRE's to a professional that has a process that's dialed in, and a line of machines that aren't toys. > do you have any idea how reliable www.openpnp.org project is currently, > for > example to meet your specs on board with soem available hardware? > I know the author of that program personally, I hired him and paid him to work on that program for a few months as we tried to make a small desktop machine that could do solder paste application and reflow in addition to pick and place. OpenPnP works, but that's not the issue. Stencil printing issues and reflow issues would still make the yield horrible. Cheap manual stencil printers lead to issues like tombstoning. Cheap reflows don't get the heat even, which means that certain parts of the board don't get fully soldered. There's a reason that the professional machines are several meters long with various temperature zones and there's a reason that they take a bit of effort to setup correctly. Even if he got some surplus machinery and an area to set it up (including ducting for the exhaust and three-phase AC hookup), there's still the issue of nailing down the actual process, there's just so much to go wrong and that's why so many companies leave that sort of stuff to other companies that are better situated to deal with those kind of problems. It's not exactly easy for me to say this either, because my dream was to make a machine for projects like EOMA68; to make the development cycle cheaper and quicker. I failed in that regard, and honestly nobody out there has really nailed it to the point where you could start churning out single board computers with BGA's an tiny parts and get close to 100% yields, in a DIY setup. It's sad but that's the reality that we live in. For the record, while I vehemently disagree with LKCL on other matters like 3D printing and funding via bitcoin mining, I do completely agree with his decision to get a few boards produced and tested before doing a complete run. Even with all the review, there are still plenty of possibilities for show-stoppers. The only suggestion that I would make -- and it's a big one -- is to send Mike (at the factory) a full test rig that is capable of verifying that an EOMA68 card works properly. This is an essential step of every production run, and I'm honestly surprised that in the update LKCL is planning on doing that himself. which pushes the schedule out to the right by another 3 days. This test rig would merely be a little board that the card plugs into, with HDMI monitor, keyboard, and some testing software to test the memory (Memtest86+), hard drive, peripherals, etc. Once production is going, the factory will need to be testing them anyway before they leave, this would be a good opportunity to test them, yet I saw nothing about that in any of the updates or email traffic. Even if this is something that LKCL personally does not have time to work on, surely someone in the forum could take on this task. So how were you planning on approaching the factory testing? If you've got it all figured out, then why isn't it going to be used for the next immediate run? And if you've not had time to get to it at all yet, why not let someone on the mailing list work on it? I can certainly give a lot of advice in this department. Hardware and software testing of embedded modules is not only what I do at my day job, I had a lot of experience while living in Shenzhen in how to make test fixtures for embedded products. I've got advice on how to make them bilingual so that they can actually be used in the factory by non-English speaking test technicians, and lots of other advice. Just let me know. From lkcl at lkcl.net Mon Jan 8 14:57:26 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 8 Jan 2018 14:57:26 +0000 Subject: [Arm-netbook] Crowsupply update In-Reply-To: References: Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Mon, Jan 8, 2018 at 2:28 PM, Neil Jansen wrote: > On Mon, Jan 8, 2018 at 4:32 AM, Hrvoje Lasic wrote: > >> did you ever think about in investing in small PNP machine (or just small >> oven plus some hand tools), like being able to produce small batch in house >> and test it qucikly? >> > > No, this would be a horrible idea, I speak from experience here. If the > end-product had a few parts (Arduino-ish, BOM < 30 parts), if the smallest > passives were 0603's and if the smallest IC's were SSOP's, then yea it > MIGHT be doable. But the EOMA68 board has BGA's and (I'm guessing) 0402's > and likely some 0201's? deliberately no 0201s. you can't pick them up. >> do you have any idea how reliable www.openpnp.org project is currently, >> for >> example to meet your specs on board with soem available hardware? >> > > I know the author of that program personally, I hired him and paid him to > work on that program for a few months as we tried to make a small desktop > machine that could do solder paste application and reflow in addition to > pick and place. cool! > It's not exactly easy for me to say this either, because my dream was to > make a machine for projects like EOMA68; to make the development cycle > cheaper and quicker. I failed in that regard, and honestly nobody out > there has really nailed it to the point where you could start churning out > single board computers with BGA's an tiny parts and get close to 100% > yields, in a DIY setup. It's sad but that's the reality that we live in. the whole point of doing the computer cards is that the base units - the Housings - *can* be done with 0603 and 0805 components, on 2 layer PCBs. > For the record, while I vehemently disagree with LKCL on other matters like > 3D printing and funding via bitcoin mining, well, if you have any ideas which stand a chance of fulfilling the goals that have been set i'd like to hear them. i didn't hear from anyone when i asked, several times, for help with sponsorship, contracts or anything else, so i had to make my own decisions. urgently. if people don't like that, tough: they should have responded sooner. i can't wait for people: i have to actually make *decisions*. > I do completely agree with his > decision to get a few boards produced and tested before doing a complete > run. Even with all the review, there are still plenty of possibilities for > show-stoppers. the 2.7.4 board is the fallback. it'll be... without an HDMI interface. that's just the way it'll be. > The only suggestion that I would make -- and it's a big one -- is to send > Mike (at the factory) a full test rig that is capable of verifying that an > EOMA68 card works properly. yehyeh. i'll have to go over to shenzhen to get one set up, and work with his engineers to make it really, _really_ easy to fit the Cards - and Micro-Desktops - into the rig. fixed (locked-down) cables, rails / slides to put the PCBs in so that the connectors go straight in, that sort of thing. the less time the better. > This is an essential step of every production > run, and I'm honestly surprised that in the update LKCL is planning on > doing that himself. which pushes the schedule out to the right by another 3 > days. This test rig would merely be a little board that the card plugs > into, with HDMI monitor, keyboard, and some testing software to test the > memory (Memtest86+), hard drive, peripherals, etc. Once production is > going, the factory will need to be testing them anyway before they leave, > this would be a good opportunity to test them, yet I saw nothing about that > in any of the updates or email traffic. i've mentioned it... half a dozen times over the past... 18-24 months. in several updates and several times on the mailing list. > Even if this is something that > LKCL personally does not have time to work on, surely someone in the forum > could take on this task. that would be really handy. > So how were you planning on approaching the > factory testing? If you've got it all figured out, then why isn't it going > to be used for the next immediate run? because i do the testing here, one at a time, here. take micro-sd card, take the PCMCIA header i've wired a 5V USB connector to and a UART, plug it in and go. otherwise i have to pay mike or one of mike's engineers to do it. > And if you've not had time to get > to it at all yet, why not let someone on the mailing list work on it? nobody's offered! > I can certainly give a lot of advice in this department. Hardware and > software testing of embedded modules is not only what I do at my day job, I > had a lot of experience while living in Shenzhen in how to make test > fixtures for embedded products. I've got advice on how to make them > bilingual so that they can actually be used in the factory by non-English > speaking test technicians, and lots of other advice. Just let me know. coool. well, the guy who mike employs, he's extremely good at making mechanical rigs and stamps and so on. he can easily put together something that ensures that the workers don't damage the boards during testing as the PCB will go into the rig "in only one physical way and with one physical move". software-wise i need something that does nothing more complex than mount stuff on a micro-sd card, show boot messages on both screens, and maybe has 2 keyboards plugged in (one into each USB socket) so that they can bash some keys and see that crud comes up on-screen for each. going beyond that... testing I2C, UART and the GPIO.... *sigh*... that involves writing some software. l. From njansen1 at gmail.com Mon Jan 8 15:32:48 2018 From: njansen1 at gmail.com (Neil Jansen) Date: Mon, 8 Jan 2018 10:32:48 -0500 Subject: [Arm-netbook] Crowsupply update In-Reply-To: References: Message-ID: On Mon, Jan 8, 2018 at 9:57 AM, Luke Kenneth Casson Leighton wrote: > the whole point of doing the computer cards is that the base units - > the Housings - *can* be done with 0603 and 0805 components, on 2 layer > PCBs. > Does the current housing design break EVERYTHING out? Or only the more important signals? if people don't like that, tough: they should have responded sooner. > I've got zero skin in the game, I'm not a backer of your campaign. So yea, don't kill yourself over my opinion of how you're managing this. The intention of saying that wasn't to derail the thread into bickering and arguing, but just to point out that I call 'em like I see 'em. While I think you're wrong on many important points, I'll gladly point out when you're doing something right but others are questioning you. That's OK. Running a business is subjective, and you can't make everyone happy. As long as the discussion is civil and open, it's all good. > yehyeh. i'll have to go over to shenzhen to get one set up, and work > with his engineers to make it really, _really_ easy to fit the Cards - > and Micro-Desktops - into the rig. fixed (locked-down) cables, rails > / slides to put the PCBs in so that the connectors go straight in, > that sort of thing. > If you're in Shenzhen, there are a few of the markets that have booths where they'll make you an entire mechanical test rig, with pogo pins, DESTACO clamps, LCD screens, buttons, locks, slides, ports, you name it... Just give them a drawing (CAD or otherwise) and come back in a few days. The prices are unbelievably cheap. Compared to my hourly rate, they're basically free. > nobody's offered! > Why not ask the community directly, via the mailing list, and/or the next update? If you say that it's really important and that your time is better spent doing other important facets of the project, that might be what it takes for someone to step forward. I do feel sympathy because back when I ran an open-source hardware company with a mailing list, and I never got the community support that I needed, unless I begged and pleaded. Everyone was happy to sit around and fire off emails and replies about how I was doing everything wrong, but nobody wanted to do any actual work. I think the word in the USA is 'peanut gallery'. I couldn't trust them any farther than I could throw them, when it came to doing real work. In the open-source hardware world, everyone gets entitled and wants you to give, give, give, and nobody really stops and thinks about what they can give back (other than their opinions and criticisms of course). So yea. It's an expectation management problem for sure. But still it's worth asking. You never know. We had a few guys really step up and deliver.. it was like 0.5% of our list size but hey I'll take what I can get. > well, the guy who mike employs, he's extremely good at making > mechanical rigs and stamps and so on. he can easily put together > something that ensures that the workers don't damage the boards during > testing as the PCB will go into the rig "in only one physical way and > with one physical move". > > software-wise i need something that does nothing more complex than > mount stuff on a micro-sd card, show boot messages on both screens, > and maybe has 2 keyboards plugged in (one into each USB socket) so > that they can bash some keys and see that crud comes up on-screen for > each. > > going beyond that... testing I2C, UART and the GPIO.... *sigh*... > that involves writing some software. Sounds like you need a test plan document, in the form of a wiki page or HTML page on your website that documents exactly what you need to test, and how you plan to test it. While I'm way too busy with back-taxes and overtime at work to actually write the code at the moment, I could certainly help put together a test plan document. That's well within my skill set for sure. If you'd like we could start a new thread to discuss. If I did find some time to write a bit of code, it would be Python because that's what I know best, and that might actually work well for a top-level testing interface, because it supports Unicode, and the Qt GUI bindings (PyQt5) would allow switchable translations. As long as the low-level testing code could be called from commandline using existing tools, then the Python environment is really just a test executive that calls the actual test code. Using the built-in Python unittesting framework would a good way to go here. It doesn't produce a test report document at the end, but it will tell you whether everything passed or failed. As far as testing I2C, UART, GPIO, that's all very very doable! Wraparound tests and fixtures and a bit of code is all you need there. But first let's get a plan together! Shall I start a new thread? From lkcl at lkcl.net Mon Jan 8 15:47:01 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 8 Jan 2018 15:47:01 +0000 Subject: [Arm-netbook] Crowsupply update In-Reply-To: References: Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Mon, Jan 8, 2018 at 3:32 PM, Neil Jansen wrote: > On Mon, Jan 8, 2018 at 9:57 AM, Luke Kenneth Casson Leighton > wrote: > >> the whole point of doing the computer cards is that the base units - >> the Housings - *can* be done with 0603 and 0805 components, on 2 layer >> PCBs. >> > > Does the current housing design break EVERYTHING out? the microdesktop 1.7 brings everything out. as it's only 68 pins, 24 of which are RGB/TTL, 4 are power, 8 are unused USB3, 7 are for micro-sd and 4 are for USB2, there's actually not a lot left. > Running a business is subjective, this isn't a business. even the EOMA68 Certification process i will put under a CIC (which is... _sort-of_ a "business" except not really). under the rules of Certification Marks i'm *not allowed* to quotes profit quotes or do anything that could be considered to be quotes competing quotes with quotes businesses quotes. several people have actually already asked me, "um if i make a housing what's to stop you from putting me out of business by making it yourself" and it's real simple: Certification *inherently* prohibits that. > and you can't make everyone happy. As > long as the discussion is civil and open, it's all good. > > > >> yehyeh. i'll have to go over to shenzhen to get one set up, and work >> with his engineers to make it really, _really_ easy to fit the Cards - >> and Micro-Desktops - into the rig. fixed (locked-down) cables, rails >> / slides to put the PCBs in so that the connectors go straight in, >> that sort of thing. >> > > If you're in Shenzhen, there are a few of the markets that have booths > where they'll make you an entire mechanical test rig, with pogo pins, > DESTACO clamps, LCD screens, buttons, locks, slides, ports, you name it... > Just give them a drawing (CAD or otherwise) and come back in a few days. > The prices are unbelievably cheap. Compared to my hourly rate, they're > basically free. :) that's the sort of thing that mike's in-house engineer does. > > >> nobody's offered! >> > > Why not ask the community directly, via the mailing list, and/or the next > update? i have!! about six times! > If you say that it's really important and that your time is better > spent doing other important facets of the project, that might be what it > takes for someone to step forward. > > I do feel sympathy because back when I ran an open-source hardware company > with a mailing list, and I never got the community support that I needed, > unless I begged and pleaded. Everyone was happy to sit around and fire off > emails and replies about how I was doing everything wrong, but nobody > wanted to do any actual work. well, that can begin to change when there's hardware in peoples' hands. >> well, the guy who mike employs, he's extremely good at making >> mechanical rigs and stamps and so on. he can easily put together >> something that ensures that the workers don't damage the boards during >> testing as the PCB will go into the rig "in only one physical way and >> with one physical move". >> >> software-wise i need something that does nothing more complex than >> mount stuff on a micro-sd card, show boot messages on both screens, >> and maybe has 2 keyboards plugged in (one into each USB socket) so >> that they can bash some keys and see that crud comes up on-screen for >> each. >> >> going beyond that... testing I2C, UART and the GPIO.... *sigh*... >> that involves writing some software. > > > Sounds like you need a test plan document, in the form of a wiki page or > HTML page on your website that documents exactly what you need to test, and > how you plan to test it. While I'm way too busy with back-taxes and > overtime at work to actually write the code at the moment, I could > certainly help put together a test plan document. that would be awesome. http://rhombus-tech.net/allwinner_a10/testing/ would be a good start. > That's well within my > skill set for sure. If you'd like we could start a new thread to discuss. > If I did find some time to write a bit of code, it would be Python because > that's what I know best, and that might actually work well for a top-level > testing interface, because it supports Unicode, and the Qt GUI bindings > (PyQt5) would allow switchable translations. As long as the low-level > testing code could be called from commandline using existing tools, then > the Python environment is really just a test executive that calls the > actual test code. Using the built-in Python unittesting framework would a > good way to go here. It doesn't produce a test report document at the end, > but it will tell you whether everything passed or failed. As far as testing > I2C, UART, GPIO, that's all very very doable! Wraparound tests and > fixtures and a bit of code is all you need there. But first let's get a > plan together! Shall I start a new thread? sure. great idea. l. From njansen1 at gmail.com Mon Jan 8 16:07:13 2018 From: njansen1 at gmail.com (Neil Jansen) Date: Mon, 8 Jan 2018 11:07:13 -0500 Subject: [Arm-netbook] Crowsupply update In-Reply-To: References: Message-ID: On Mon, Jan 8, 2018 at 10:47 AM, Luke Kenneth Casson Leighton wrote: > the microdesktop 1.7 brings everything out. as it's only 68 pins, 24 > of which are RGB/TTL, 4 are power, 8 are unused USB3, 7 are for > micro-sd and 4 are for USB2, there's actually not a lot left. > > that's the sort of thing that mike's in-house engineer does. > OK then, (A) is there a timetable for when he plans on having such a fixture ready? and (B) Do you have drawings for the fixture that you intend to give to him? Or do you need help with the design? Yes, in this case, I'm offering mechanical fixture design help if needed. > i have!! about six times! > I've been on the mailing list since May of 2017 and I don't recall seeing any direct calls for help in that department. Not saying that you haven't, but I'm just saying that although I've read all the posts and all of the updates since that date, I've not seen a call for help in that area, because if I did, I probably would have stepped up and volunteered. New people join all the time, and even more people lurk, so consider asking again. > well, that can begin to change when there's hardware in peoples' hands. > Very, very true. > that would be awesome. > http://rhombus-tech.net/allwinner_a10/testing/ would be a good start. > That's a great start. > [...] Shall I start a new thread? > > sure. great idea. > Will start one now. From lkcl at lkcl.net Mon Jan 8 19:07:21 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 8 Jan 2018 19:07:21 +0000 Subject: [Arm-netbook] Crowsupply update In-Reply-To: References: Message-ID: On Mon, Jan 8, 2018 at 4:07 PM, Neil Jansen wrote: >> > > OK then, (A) is there a timetable for when he plans on having such a > fixture ready? he isn't planning, i am. any time in the next... 4 months is fine. nothing could ever really be "planned" because there was no point [with a previously unknown and unknowable time on the critical path]. > and (B) Do you have drawings for the fixture that you intend > to give to him? no. i met mike a year ago in shenzhen and discussed the need for a test rig, not the actual details *of* a test rig. > Or do you need help with the design? Yes, in this case, > I'm offering mechanical fixture design help if needed. hmm.... i tell you what [and importantly, why] - i feel it would be best to let mike's guy come up with something based on a "requirements specification". that way he feels "needed and trusted" if you know what i mean. if he ballses it up on the other hand... :) >> i have!! about six times! >> > > I've been on the mailing list since May of 2017 and I don't recall seeing > any direct calls for help in that department. the list's being going since... 2011. > Not saying that you haven't, > but I'm just saying that although I've read all the posts and all of the > updates since that date, I've not seen a call for help in that area, > because if I did, I probably would have stepped up and volunteered. New > people join all the time, and even more people lurk, so consider asking > again. i forgot about that. whoops :) l. From richard.wilbur at gmail.com Mon Jan 8 21:22:34 2018 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Mon, 8 Jan 2018 14:22:34 -0700 Subject: [Arm-netbook] Crowsupply update In-Reply-To: References: Message-ID: <132A1FA8-9EE8-413C-8DFD-D9966046CF6D@gmail.com> On Jan 8, 2018, at 07:57, Luke Kenneth Casson Leighton wrote: >> On Mon, Jan 8, 2018 at 2:28 PM, Neil Jansen wrote: >> I do completely agree with his >> decision to get a few boards produced and tested before doing a complete >> run. Even with all the review, there are still plenty of possibilities for >> show-stoppers. > > the 2.7.4 board is the fallback. it'll be... without an HDMI > interface. that's just the way it'll be. One downside of the 2.7.4 board at this point is the changes in capacitor pricing that have been ameliorated only on version 2.7.5. Here's hoping the 2.7.5 board works! […] > software-wise i need something that does nothing more complex than > mount stuff on a micro-sd card, show boot messages on both screens, > and maybe has 2 keyboards plugged in (one into each USB socket) so > that they can bash some keys and see that crud comes up on-screen for > each. > > going beyond that... testing I2C, UART and the GPIO.... *sigh*... > that involves writing some software. I'd be happy to write some test software for I2C, UART, GPIO, etc. I've worked on drivers for those interfaces on embedded machines in the past. I also have experience creating and implementing software and hardware test designs. One example, I modified my employer's PCI VGA BIOS to test the card at boot which significantly streamlined testing of our cards. Another example, in order to test a design I created I2C driver and test code to demonstrate feasibility on a prototype and then incorporated it into production code in the BIOS and driver. Happy to collaborate on board bring up as well. I've worked on bringing up in-house boards for two employers: PCI graphics cards (for which we used oscilloscope and completed someone else's programmable logic design), embedded computers in different modules of high-speed wireless communications links (tools used: spectrum analyzer, oscilloscope, logic analyzer, PCI bus analyzer, MPEG protocol analysis software, processor In-Circuit Emulator, serial terminal). If you've got that covered, I'm happy playing the role of the ally you can describe the problem to and who, through listening to your description, helps you see the solution! Sincerely, Richard From lkcl at lkcl.net Mon Jan 8 22:09:40 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 8 Jan 2018 22:09:40 +0000 Subject: [Arm-netbook] Crowsupply update In-Reply-To: <132A1FA8-9EE8-413C-8DFD-D9966046CF6D@gmail.com> References: <132A1FA8-9EE8-413C-8DFD-D9966046CF6D@gmail.com> Message-ID: On Mon, Jan 8, 2018 at 9:22 PM, Richard Wilbur wrote: > One downside of the 2.7.4 board at this point is the changes in capacitor pricing that have been ameliorated only on version 2.7.5. Here's hoping the 2.7.5 board works! darn yeah i'd forgotten about the implications of the price-hike. whoops. > […] >> software-wise i need something that does nothing more complex than >> mount stuff on a micro-sd card, show boot messages on both screens, >> and maybe has 2 keyboards plugged in (one into each USB socket) so >> that they can bash some keys and see that crud comes up on-screen for >> each. >> >> going beyond that... testing I2C, UART and the GPIO.... *sigh*... >> that involves writing some software. > > I'd be happy to write some test software for I2C, UART, GPIO, etc. > I've worked on drivers for those interfaces on embedded machines in the past. > I also have experience creating and implementing software and hardware test > designs. One example, I modified my employer's PCI VGA BIOS to test the card > at boot which significantly streamlined testing of our cards. Another example, > in order to test a design I created I2C driver and test code to demonstrate feasibility > on a prototype and then incorporated it into production code in the BIOS and driver. nice! well, this would be a lot simple: scan the I2C bus (lmsensors debian package), see if a peripheral at address 0x51 comes up, if it does _great_. it's a few lines of shell script. UART: if i add a USB-to-UART adapter onto a "test" microdesktop unit, if there's output on the console and it's not garbage, that's good enough. the GPIO... yes, that's where some coding comes in. there's actually only a few pins spare, they're all on the 14-pin header of the microdesktop board. except for two which are intended for bit-banging a separate I2C driver for VGA "EDID" detection.... > Happy to collaborate on board bring up as well. great. > I've worked on bringing up in-house boards for two employers: > PCI graphics cards (for which we used oscilloscope and completed someone > else's programmable logic design), embedded computers in different modules > of high-speed wireless communications links (tools used: spectrum analyzer, > oscilloscope, logic analyzer, PCI bus analyzer, MPEG protocol analysis > software, processor In-Circuit Emulator, serial terminal). ooo fuuun :) honestly the board's pretty "mature" and a lot simpler than that. no PCI, no PCIe, it's all SD/MMC, UART, USB, I2C, SPI, RGB/TTL, that sort of thing, where all of those have all worked in previous boards, no reason why they shouldn't work in the 2.7.5 version (except i tidied up the USB lines a bit... never keen on altering stuff that works... ah well). on the actual board itself, it's so tightly integrated (and also quite simple) that it tends to be an all-or-nothing. does power work, measure the voltages, yes no. ok does plugging in USB-OTG only have it show up on "lsusb" yes no. yes ok great let's load the FEL, does _that_ work, yes no, yes ok great, now does loading u-boot directly into DDR3 RAM work, yes, no. the FEL (u-boot-spl) loader has a nice debug feature of displaying a few lines of early UART. so that's a really good way to tell if the A20's alive. from there i can compile u-boot to look for a particular micro-sd card slot, which it will scan, and show debug messages "SD card detected" and so on. i can do commands which list the partitions and so on. it's pretty straghtforward: anything not working shows up really quickly and easily. > If you've got that covered, I'm happy playing the role of the ally > you can describe the problem to and who, through listening to > your description, helps you see the solution! appreciated. ... y'know... when we get to the RISC-V 64-bit SoC then that's going to be a lot trickier. aside from anything it will be necessary to do the DDR3 layout from scratch. i can't stand doing DDR3 layouts, they're... blegh :) get it wrong and yeah you reaaaly need a logic analyzer... oh. i have an RK3288 board that could use your help. i only got one of the DDR3 lanes up and running. l. From richard.wilbur at gmail.com Mon Jan 8 23:24:28 2018 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Mon, 8 Jan 2018 16:24:28 -0700 Subject: [Arm-netbook] Crowsupply update In-Reply-To: References: <132A1FA8-9EE8-413C-8DFD-D9966046CF6D@gmail.com> Message-ID: <4609ED0A-4209-43C1-A7F1-6EE099610CA8@gmail.com> It all sounds like fun! What can I help with first? From eaterjolly at gmail.com Mon Jan 8 23:34:21 2018 From: eaterjolly at gmail.com (Jean Flamelle) Date: Mon, 8 Jan 2018 18:34:21 -0500 Subject: [Arm-netbook] Software as a Community Service Message-ID: In an ideal global community, there would be distributed to every language-bearing living being a modicum of electronic networking and information rendering hardware. That isn't going to be any day soon. I identify with arguments against SaaS,---and posed them to Urbit's bugtracker in issue 911---however software as a community service, without any potential for personal or collective gain that couldn't achieved by any kek of equal mind without prior reputation or special location, will include people who cannot effectively have compiled or rendered on their own. I would like to hear the arguments against ubuntu's launchpad buildbots specifically, because, if there are none specific to that case, I contend that every major libre project should host a ppa on launchpad to include the people of Africa and the Orient with limited devices not to mention youths of the world with limited support from their living communities stuck in highly restrictive computing environments lacking digital sovereignty over a physical device. From lkcl at lkcl.net Tue Jan 9 00:23:40 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 9 Jan 2018 00:23:40 +0000 Subject: [Arm-netbook] Crowsupply update In-Reply-To: <4609ED0A-4209-43C1-A7F1-6EE099610CA8@gmail.com> References: <132A1FA8-9EE8-413C-8DFD-D9966046CF6D@gmail.com> <4609ED0A-4209-43C1-A7F1-6EE099610CA8@gmail.com> Message-ID: On Mon, Jan 8, 2018 at 11:24 PM, Richard Wilbur wrote: > It all sounds like fun! What can I help with first? well... perhaps... something simple like.. a simple program that tests GPIO, assuming that say 4 hard-wires are connected between 8 GPIOs in pairs, turning one into an input and the other an output, then setting 0 and 1 and seeing if it's read correctly... then inverting each pair (out becomes in, in becomes out) and re-running the test. something in either c or python that uses the sunxi-3.4 gpio driver: https://github.com/linux-sunxi/linux-sunxi/blob/stage/sunxi-3.4/drivers/gpio/gpio-sunxi.c that _should_ be exposed as /dev/gpio which should in turn appear in either /sys or /proc... it should be a standard interface, with a standard way to set which banks are activated... you might have to do some digging. l. From crimier at yandex.ru Tue Jan 9 13:04:30 2018 From: crimier at yandex.ru (=?utf-8?B?UGnEjXVnaW5zIEFyc2VuaWpz?=) Date: Tue, 09 Jan 2018 15:04:30 +0200 Subject: [Arm-netbook] Crowsupply update In-Reply-To: References: Message-ID: <2531681515503070@web59g.yandex.ru> >  software-wise i need something that does nothing more complex than > mount stuff on a micro-sd card, show boot messages on both screens, > and maybe has 2 keyboards plugged in (one into each USB socket) so > that they can bash some keys and see that crud comes up on-screen for > each. > >  going beyond that... testing I2C, UART and the GPIO.... *sigh*... > that involves writing some software. Speaking about I2C, UART and GPIO testing - it sounds easy. I don't yet know which defects you'd want to cover with tests (mechanical, soldering, faulty parts, maybe all of them), but, as far as my research goes, you can test both UART and GPIOs with a loopback test, and I2C could be tested using a simple device - such as an EEPROM. Now, I don't have as much testing experience, but I've done a couple of DIY jigs - not automated, but that's yet to come - and I've been thinking about a way to make testing jigs. First thing is - it's best if the test program runs on the computer card itself. I see that's what you plan to do, and, if I'm not mistaken, cards are going to boot from a MicroSD card anyway - which is what's needed. Testing GPIOs can be done easily from software - connect GPIOs in pairs using resistors (say, 470ohm, just in case one of GPIOs is shorted to ground/VCC for some mechanical reason). Set first GPIO as input, second as output, then toggle the second GPIO and check that value that's read from the input is the same as value that's on the output. With more complicated interfaces, it depends. I2C should be testable by using an I2C device - since you have an EEPROM inside the card, it makes sense to first test if that's accessible, then test another device that's located in the test header (say, a GPIO expander or an ADC, you could use both of those for testing, too.) You can test SPI in loopback mode by connecting MISO and MOSI together, though you won't test SCK and CS that way. UART should easily be testable with a loopback - though I think you won't want to have the loopback hard-wired, to make sure that U-Boot messages won't get into U-Boot input and stop the boot process, or something of that kind =) If you want to test USB, you don't even need to have engineers mash on the keyboard, attach two USB devices with unique IDs (say, CP2012 - you can program those through USB connection) and make sure they're recognized - in case of CP2012, you can make a loopback test of their UART, just to make sure data passes through... Not sure how much sense it'll make, though =) Now, speaking about SDIO and parallel video interfaces that you have in EOMA68 pinouts, I have no idea how to test them automatically =( But the test I listed cover most mechanical pins, and half of the peripherals, which is already pretty good for avoiding RMAs of cards with bad solder joints in the USB or I2C lines. They're also cheap enough in terms of hardware& software required. So, the end result could be: a MicroSD card with a stripped down image of something something Linux that boots as quickly as possible (with cruft like networking disabled), shows the boot log on HDMI monitor - then draws a table on the monitor (I imagine it being a fullscreen application working with framebuffer, to avoid having to wait for X to load). Cells of that table would be filled with green or red, depending on whether tests pass on fail - and an all-green monitor would indicate all is well =) This should make for streamlined&quick testing and avoid lots of manual work (excluding that, well, you still have to plug the card into the testing jig and plug the cables in). Now, I don't have *that* much experience, I don't know which failures you want to protect against, but if I were to test these cards, this is what I'd do. Cheers! Arsenijs From richard.wilbur at gmail.com Tue Jan 9 13:26:46 2018 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Tue, 9 Jan 2018 06:26:46 -0700 Subject: [Arm-netbook] Crowsupply update In-Reply-To: References: <132A1FA8-9EE8-413C-8DFD-D9966046CF6D@gmail.com> <4609ED0A-4209-43C1-A7F1-6EE099610CA8@gmail.com> Message-ID: > On Jan 8, 2018, at 17:23, Luke Kenneth Casson Leighton wrote: > > On Mon, Jan 8, 2018 at 11:24 PM, Richard Wilbur > wrote: > >> It all sounds like fun! What can I help with first? > > well... perhaps... something simple like.. a simple program that tests > GPIO, assuming that say 4 hard-wires are connected between 8 GPIOs in > pairs, turning one into an input and the other an output, then setting > 0 and 1 and seeing if it's read correctly... then inverting each pair > (out becomes in, in becomes out) and re-running the test. I'd recommend resistors instead of wires. Something like 10KΩ because then if they are accidentally misconnected, Vcc(5V?) to ground would only amount to 0.5mA which is unlikely to stress anything unduly. What kind of logic are these GPIO pins? (CMOS, TTL, etc.) > something in either c or python that uses the sunxi-3.4 gpio driver: > https://github.com/linux-sunxi/linux-sunxi/blob/stage/sunxi-3.4/drivers/gpio/gpio-sunxi.c > > that _should_ be exposed as /dev/gpio which should in turn appear in > either /sys or /proc... it should be a standard interface, with a > standard way to set which banks are activated... you might have to do > some digging. So there are 4 pairs or 8 GPIO lines to test? (I thought we had 14 lines dedicated to GPIO and two more that were going to be used as I2C for VGA? Are only 8 easy to test?) I'll assume I either get the connected pairs via an environment variable, the command line, or a file (filename passed on command line). From lkcl at lkcl.net Tue Jan 9 13:41:57 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 9 Jan 2018 13:41:57 +0000 Subject: [Arm-netbook] Crowsupply update In-Reply-To: <2531681515503070@web59g.yandex.ru> References: <2531681515503070@web59g.yandex.ru> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Tue, Jan 9, 2018 at 1:04 PM, Pičugins Arsenijs wrote: >> software-wise i need something that does nothing more complex than >> mount stuff on a micro-sd card, show boot messages on both screens, >> and maybe has 2 keyboards plugged in (one into each USB socket) so >> that they can bash some keys and see that crud comes up on-screen for >> each. >> >> going beyond that... testing I2C, UART and the GPIO.... *sigh*... >> that involves writing some software. > > Speaking about I2C, UART and GPIO testing - it sounds easy. > I don't yet know which defects you'd want to cover with tests > (mechanical, soldering, faulty parts, maybe all of them), but, > as far as my research goes, you can test both UART and GPIOs > with a loopback test, and I2C could be tested using a simple > device - such as an EEPROM. funny but there's an EEPROM on-board the Micro-desktop PCB... :) > Now, I don't have as much testing experience, but I've done a couple > of DIY jigs - not automated, but that's yet to come - and I've been > thinking about a way to make testing jigs. First thing is - it's best if > the test program runs on the computer card itself. I see that's > what you plan to do, and, if I'm not mistaken, cards are going to boot > from a MicroSD card anyway - which is what's needed. yyep. there's two. > If you want to test USB, you don't even need to have engineers > mash on the keyboard, attach two USB devices with unique > IDs (say, CP2012 - you can program those through USB connection) ha good idea. could someone put these things into the testing page? l. From richard.wilbur at gmail.com Tue Jan 9 18:37:12 2018 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Tue, 9 Jan 2018 11:37:12 -0700 Subject: [Arm-netbook] Crowsupply update In-Reply-To: References: Message-ID: On Jan 8, 2018, at 08:47, Luke Kenneth Casson Leighton wrote: > On Mon, Jan 8, 2018 at 3:32 PM, Neil Jansen wrote: >> Does the current housing design break EVERYTHING out? > > the microdesktop 1.7 brings everything out. as it's only 68 pins, 24 > of which are RGB/TTL, 4 are power, 8 are unused USB3, 7 are for > micro-sd and 4 are for USB2, there's actually not a lot left. 68 - (24 + 4 + 8 + 7 + 4) = 68 - 47 = 21 What are the remaining 21 pins? From lkcl at lkcl.net Tue Jan 9 18:57:02 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 9 Jan 2018 18:57:02 +0000 Subject: [Arm-netbook] Crowsupply update In-Reply-To: References: Message-ID: On Tue, Jan 9, 2018 at 6:37 PM, Richard Wilbur wrote: > 68 - (24 + 4 + 8 + 7 + 4) = 68 - 47 = 21 > What are the remaining 21 pins? https://elinux.org/Embedded_Open_Modular_Architecture/EOMA68/Hardware#Pinouts_.28version_1.0.29 http://hands.com/~lkcl/eoma/microdesktop/microdesktop_v1_7.pdf From j.neuschaefer at gmx.net Tue Jan 9 22:22:57 2018 From: j.neuschaefer at gmx.net (Jonathan =?utf-8?Q?Neusch=C3=A4fer?=) Date: Tue, 9 Jan 2018 23:22:57 +0100 Subject: [Arm-netbook] Early UART output vs. housing board discovery Message-ID: <20180109222257.e5akm3qygves2dji@latitude> Hi, what follows are a few questions/remarks/misunderstandings regarding the UART pins during early boot. In the EOMA68 specification, the section "Start-up procedure"[1] specifies that "It is required that all pins be disabled (floating tri-state) with the exception of the I2C Bus, the 5.0v Power and the Ground Pins.", which would mean that *any software* running on a CPU card is required to check the housing board's EEPROM before it may output any data on the UART, if I read it correctly. This would make early debugging harder, because EEPROM detection has to be integrated in very early code, and early code can't simply use the UART as an unconditional debug channel, that's guaranteed to reach the outside of the card, anymore. The section "Requirements for UART"[2], however, states: "As this problem is to be taken care of on the I/O Board[3] it is worth observing that CPU Cards do not require UART buffering.", suggesting that the "Start-up procedure" section simply left out UART as one of the interfaces that do not need to be tri-stated by mistake. But I am unclear about the part "CPU Cards do not require UART buffering": - Does it mean that CPU cards do not require the housing board to perform UART buffering, because they do it themselves? - Or does it mean that CPU cards are not required to perform UART buffering? So, can a CPU card assume that it may use the UART right after reset, without first consulting the EEPROM? (I understand that if a housing board has, for example, a Bluetooth module connected to the UART, something must make sure that none of that early debug output reaches the BT module, but I guess one could easily enough have a GPIO pin that controls whether the UART is cut off from the BT module, and the OS could toggle this pin once it knows that it won't send debug output anymore. The same GPIO pin might also control if the Bluetooth module is powered up at all.) Best regards, Jonathan Neuschäfer [1]: https://elinux.org/Embedded_Open_Modular_Architecture/EOMA68/Hardware#Start-up_procedure [2]: https://elinux.org/Embedded_Open_Modular_Architecture/EOMA68/Hardware#Requirements_for_UART [3]: As a side-note, the term "I/O Board" is a little bit unclear to me: Both CPU cards/boards and housing boards perform I/O. I figured that "I/O board" means "housing board", but I (personally) think the spec would be clearer if it talked about "housings" or "housing boards" in the first place. From lkcl at lkcl.net Wed Jan 10 11:12:24 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 10 Jan 2018 11:12:24 +0000 Subject: [Arm-netbook] Early UART output vs. housing board discovery In-Reply-To: <20180109222257.e5akm3qygves2dji@latitude> References: <20180109222257.e5akm3qygves2dji@latitude> Message-ID: On Tue, Jan 9, 2018 at 10:22 PM, Jonathan Neuschäfer wrote: > Hi, > > what follows are a few questions/remarks/misunderstandings regarding the > UART pins during early boot. > > In the EOMA68 specification, the section "Start-up procedure"[1] > specifies that "It is required that all pins be disabled (floating > tri-state) with the exception of the I2C Bus, the 5.0v Power and the > Ground Pins.", which would mean that *any software* running on a CPU > card is required to check the housing board's EEPROM before it may > output any data on the UART, if I read it correctly. yyup. > This would make early debugging harder, because EEPROM detection has to > be integrated in very early code, and early code can't simply use the > UART as an unconditional debug channel, that's guaranteed to reach the > outside of the card, anymore. ok there's a difference between production and factory / testing. factory / testing is specifically permitted to do whatever they like, totally disregarding the EOMA68 standard IN FULL, should they choose to. it is only PRODUCTION where the EOMA68 Specification is REQUIRED - unconditionally - to be followed. could i leave it with you to alter the rest of what you wrote to take that into account before we proceed further? also, before proceeding, perhaps we should discuss how to make the above absolutely clear. it is very important that there be zero misunderstandings in the EOMA68 Standard. thanks johnathon. l. From j.neuschaefer at gmx.net Wed Jan 10 13:44:02 2018 From: j.neuschaefer at gmx.net (Jonathan =?utf-8?Q?Neusch=C3=A4fer?=) Date: Wed, 10 Jan 2018 14:44:02 +0100 Subject: [Arm-netbook] Early UART output vs. housing board discovery In-Reply-To: References: <20180109222257.e5akm3qygves2dji@latitude> Message-ID: <20180110134402.d6cyfzmscicglt6q@latitude> Hi, On Wed, Jan 10, 2018 at 11:12:24AM +0000, Luke Kenneth Casson Leighton wrote: > On Tue, Jan 9, 2018 at 10:22 PM, Jonathan Neuschäfer > wrote: > > Hi, > > > > what follows are a few questions/remarks/misunderstandings regarding the > > UART pins during early boot. > > > > In the EOMA68 specification, the section "Start-up procedure"[1] > > specifies that "It is required that all pins be disabled (floating > > tri-state) with the exception of the I2C Bus, the 5.0v Power and the > > Ground Pins.", which would mean that *any software* running on a CPU > > card is required to check the housing board's EEPROM before it may > > output any data on the UART, if I read it correctly. > > yyup. > > > This would make early debugging harder, because EEPROM detection has to > > be integrated in very early code, and early code can't simply use the > > UART as an unconditional debug channel, that's guaranteed to reach the > > outside of the card, anymore. > > ok there's a difference between production and factory / testing. > factory / testing is specifically permitted to do whatever they like, > totally disregarding the EOMA68 standard IN FULL, should they choose > to. > > it is only PRODUCTION where the EOMA68 Specification is REQUIRED - > unconditionally - to be followed. I can certainly see cases where a Technical Enduser, as the spec calls them, wants to modify or replace low-level software on an already produced card, and perform "testing": - A card only ships with the SoC vendor's fork of Linux, but the user wants to run/port mainline Linux. - The user wants to change something about the bootloader. - The card only runs Linux, but the user wants to port BSD. Thus it would be rather useful to have the UART available as an early debugging facility after production, and in a standardized way. A Technical Enduser could of course open a card, find the right test points for RX/TX, solder wires to them, run them out of the case, and close the case again, but this procedure is highly card-specific, and probably not always possible, e.g. when the RX/TX lines are routed in a way that makes soldering hard. In short: Thank you for the clarification. Now I disagree with this decision in the spec. :-/ (BTW, just to be very clear about the word "early": I mean early in the card's "run"-cycle (from power-up to power-down), not early in the the card's life-cycle (from production to destruction).) > could i leave it with you to alter the rest of what you wrote to take > that into account before we proceed further? also, before proceeding, > perhaps we should discuss how to make the above absolutely clear. it > is very important that there be zero misunderstandings in the EOMA68 > Standard. I listed some hard(er) to understand phrases in my initial mail: - "CPU Cards do not require UART buffering" - "I/O Board" vs. something more obviously unambiguous I suggest continuing the discussion about clarification of the current intention of the spec in reply to that mail. Thanks, Jonathan Neuschäfer From lkcl at lkcl.net Wed Jan 10 13:59:19 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 10 Jan 2018 13:59:19 +0000 Subject: [Arm-netbook] Early UART output vs. housing board discovery In-Reply-To: <20180110134402.d6cyfzmscicglt6q@latitude> References: <20180109222257.e5akm3qygves2dji@latitude> <20180110134402.d6cyfzmscicglt6q@latitude> Message-ID: On Wed, Jan 10, 2018 at 1:44 PM, Jonathan Neuschäfer wrote: > On Wed, Jan 10, 2018 at 11:12:24AM +0000, Luke Kenneth Casson Leighton wrote: >> it is only PRODUCTION where the EOMA68 Specification is REQUIRED - >> unconditionally - to be followed. > > I can certainly see cases where a Technical Enduser, as the spec calls > them, wants to modify or replace low-level software on an already > produced card, and perform "testing": > > - A card only ships with the SoC vendor's fork of Linux, but the user > wants to run/port mainline Linux. > - The user wants to change something about the bootloader. > - The card only runs Linux, but the user wants to port BSD. > > Thus it would be rather useful to have the UART available as an early > debugging facility after production, and in a standardized way. yes, absolutely.... and there is absolutely nothing stopping the "User" from, in effect, upgrading themselves mentally to the status of "Technical EndUser" - at which point there are completely different rules / state-diagram. so they would be perfectly and absolutely within their rights to take the Card out, plug it into a.... testing station of some kind (even if that's just a breakout board), plug in a MicroSD card with "UART debug enabled" and off they go. > A Technical Enduser could of course open a card, find the right test > points for RX/TX, solder wires to them, run them out of the case, and > close the case again, but this procedure is highly card-specific, and > probably not always possible, e.g. when the RX/TX lines are routed in > a way that makes soldering hard. no it's even more basic / simpler than that. they don't have to do that, they can just put the Card into a break-out PCMCIA holder socket. or anything else. > In short: Thank you for the clarification. Now I disagree with this > decision in the spec. :-/ ok, so bear in mind that the UART wires double up as GPIO, and that it is the HOUSING DESIGNER's right, under the EOMA68 specification, to make the decision to allocate eiher one (or both) of the UART wires to GPIO - as either Input or Output. .... so what do you think would happen, in this case, if someone plugged in a Card where it was FORCIBLY REQUIRED that UART *ABSOLUTELY MUST* transmit "early boot messages" on those two wires? > (BTW, just to be very clear about the word "early": I mean early in the > card's "run"-cycle (from power-up to power-down), not early in the the > card's life-cycle (from production to destruction).) yep understood. >> could i leave it with you to alter the rest of what you wrote to take >> that into account before we proceed further? also, before proceeding, >> perhaps we should discuss how to make the above absolutely clear. it >> is very important that there be zero misunderstandings in the EOMA68 >> Standard. > > I listed some hard(er) to understand phrases in my initial mail: i know... let's not forget about them but deal with things one at a time, if that's ok. i know from experience, from past discussions, that ANY clarification requires a HUGE amount of effort and discussion, with an exchange that can carry on for several days. i trust that you can appreciate that it would overwhelm both me and you and everyone on this list to have three ongoing *simultaneous* separate and distinct highly-technical logical reasoning discussions, yeh? l. From j.neuschaefer at gmx.net Wed Jan 10 16:11:35 2018 From: j.neuschaefer at gmx.net (Jonathan =?utf-8?Q?Neusch=C3=A4fer?=) Date: Wed, 10 Jan 2018 17:11:35 +0100 Subject: [Arm-netbook] Early UART output vs. housing board discovery In-Reply-To: References: <20180109222257.e5akm3qygves2dji@latitude> <20180110134402.d6cyfzmscicglt6q@latitude> Message-ID: <20180110161135.lbu5eafqvcasrrnc@latitude> On Wed, Jan 10, 2018 at 01:59:19PM +0000, Luke Kenneth Casson Leighton wrote: > On Wed, Jan 10, 2018 at 1:44 PM, Jonathan Neuschäfer wrote: > > On Wed, Jan 10, 2018 at 11:12:24AM +0000, Luke Kenneth Casson Leighton wrote: [...] > > Thus it would be rather useful to have the UART available as an early > > debugging facility after production, and in a standardized way. > > yes, absolutely.... and there is absolutely nothing stopping the > "User" from, in effect, upgrading themselves mentally to the status of > "Technical EndUser" - at which point there are completely different > rules / state-diagram. > > so they would be perfectly and absolutely within their rights to take > the Card out, plug it into a.... testing station of some kind (even if > that's just a breakout board), plug in a MicroSD card with "UART debug > enabled" and off they go. Although I don't like this solution (what if the on-card firmware wants to print debug logs?), I have to acknowledge that it is a solution. (I would prefer that early debug output is available without (even temporarily) rendering a CPU card non-compliant.) > > A Technical Enduser could of course open a card, find the right test > > points for RX/TX, solder wires to them, run them out of the case, and > > close the case again, but this procedure is highly card-specific, and > > probably not always possible, e.g. when the RX/TX lines are routed in > > a way that makes soldering hard. > > no it's even more basic / simpler than that. they don't have to do > that, they can just put the Card into a break-out PCMCIA holder > socket. or anything else. ... and enable early debug mode through unspecified means, right? > > In short: Thank you for the clarification. Now I disagree with this > > decision in the spec. :-/ > > ok, so bear in mind that the UART wires double up as GPIO, and that > it is the HOUSING DESIGNER's right, under the EOMA68 specification, to > make the decision to allocate eiher one (or both) of the UART wires to > GPIO - as either Input or Output. This is AFAICS not a big problem under my suggested change. For reference, this is my suggested change: - CPU Cards may use the UART lines for debug purposes while they are not fully (enough) booted. - When a CPU card has fully (enough) booted, it must use the UART pins in the function that's described in the EEPROM. For example, UART connected to a Bluetooth module, GPIO connected to whatever, etc. - If a housing needs to protect its components from debug traffic, it must provide (and describe in the EEPROM) a mechanism for the CPU card to signal that it has booted far enough to use the UART pins for the function intended by the housing. This can be done through a I2C register poke, toggling a (different) GPIO line, etc.[2] - I think it should be valid for a CPU card to follow the current model and keep the UART pins tri-stated until it's fully booted. A housing that wants to capture early debug traffic can generate a well-defined idle signal on the TX line with a pull-up. This is a debug facility. Not all CPU cards have to use it, but all housings must accept it. Thus it is just as (non-)optional as USB, with the difference that the CPU card decides whether it prints early debug messages, and the Housing decides whether it connects the USB pins to any USB devices or connectors. "Fully (enough) booted" in the above doesn't just mean the CPU has left the bootloader. It also has to have read the I2C EEPROM, which might require quite a bit of work in the kernel (initializing the I2C controller, at least). Things can go wrong before the CPU card has booted far enough before it can read and interpret the I2C EEPROM, which is my whole motivation. > .... so what do you think would happen, in this case, if someone > plugged in a Card where it was FORCIBLY REQUIRED that UART *ABSOLUTELY > MUST* transmit "early boot messages" on those two wires? Required by which part? (Or: Required by the standard on behalf of which part?) - Housings shouldn't require to see any debug messages from CPU cards, that's just silly. Boot debug output is necessarily CPU card specific, so it is not generally useful for any *software* on the housing board. It is only useful for humans[1]. - Housings are, under my suggested change, however required to tolerate early UART output. How this is done is up to the housing designer. For example, if the UART TX pin is connected to an activity LED, the designer might even choose to ignore the flickering during early boot. :-) > > I listed some hard(er) to understand phrases in my initial mail: > > i know... let's not forget about them but deal with things one at a > time, if that's ok. i know from experience, from past discussions, > that ANY clarification requires a HUGE amount of effort and > discussion, with an exchange that can carry on for several days. Alright. > i trust that you can appreciate that it would overwhelm both me and > you and everyone on this list to have three ongoing *simultaneous* > separate and distinct highly-technical logical reasoning discussions, > yeh? Yes. Thanks, Jonathan Neuschäfer [1]: ... or CPU card specific housings, which, as far as I understand the standard should be avoided as much as reasonably possible. [2]: I realize this increases the housing BOM by a few components. How large is the price impact? From lkcl at lkcl.net Wed Jan 10 19:22:16 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 10 Jan 2018 19:22:16 +0000 Subject: [Arm-netbook] Early UART output vs. housing board discovery In-Reply-To: <20180110161135.lbu5eafqvcasrrnc@latitude> References: <20180109222257.e5akm3qygves2dji@latitude> <20180110134402.d6cyfzmscicglt6q@latitude> <20180110161135.lbu5eafqvcasrrnc@latitude> Message-ID: On Wed, Jan 10, 2018 at 4:11 PM, Jonathan Neuschäfer wrote: > On Wed, Jan 10, 2018 at 01:59:19PM +0000, Luke Kenneth Casson Leighton wrote: >> so they would be perfectly and absolutely within their rights to take >> the Card out, plug it into a.... testing station of some kind (even if >> that's just a breakout board), plug in a MicroSD card with "UART debug >> enabled" and off they go. > > Although I don't like this solution (what if the on-card firmware wants > to print debug logs?), I have to acknowledge that it is a solution. > (I would prefer that early debug output is available without (even > temporarily) rendering a CPU card non-compliant.) another solution is: the designer of the Card ensures that, through the user-facing connectors of the Card, that early debug messages may be accessed through one of the peripherals. in the case of the EOMA68-A20 Card, that is possible with the insertion of a "MicroSD Breakout Board", whereupon both JTAG and UART0 are accessible if you boot with the correct pinmux settings. this, again, does NOT require that the UART wires of EOMA68 be placed into a state that results in total confusion over their use and purpose... more on this below. >> no it's even more basic / simpler than that. they don't have to do >> that, they can just put the Card into a break-out PCMCIA holder >> socket. or anything else. > > ... and enable early debug mode through unspecified means, right? no, it's very clearly specified that there *is* no limit or restriction. which is totally different from leaving things "unspecified". >> > In short: Thank you for the clarification. Now I disagree with this >> > decision in the spec. :-/ >> >> ok, so bear in mind that the UART wires double up as GPIO, and that >> it is the HOUSING DESIGNER's right, under the EOMA68 specification, to >> make the decision to allocate eiher one (or both) of the UART wires to >> GPIO - as either Input or Output. > > This is AFAICS not a big problem under my suggested change. > > For reference, this is my suggested change: > - CPU Cards may use the UART lines for debug purposes while they are not > fully (enough) booted. ok so that implies that the UART lines MAY be UART... they MIGHT also be GPIO. please bear in mind: anything that involves "confusion" is AUTOMATICALLY prohibited from being included in the EOMA68 Standard. i appreciate that in this case you describe a procedure that would remove doubt, but the procedure itself is very burdensome to implement. there is a story i told about the X25 Standard which illustrates how these kinds of choices result in lost opportunities and/or total confusion and thus destroy confidence in a standard. > - When a CPU card has fully (enough) booted, it must use the UART pins > in the function that's described in the EEPROM. ok so the boot process you propose is: * bring up the CPU (DDR3, PLLs) * initialise EEPROM GPIO pins and configure them as I2C * read an I2C EEPROM * decode it * work out if it's SAFE to write to UART * THEN write debug / print messages on the UART pins ... can you see how that's not "early" at all? > For example, UART > connected to a Bluetooth module, GPIO connected to whatever, etc. > - If a housing needs to protect its components from debug traffic, it > must provide (and describe in the EEPROM) a mechanism for the CPU card > to signal that it has booted far enough to use the UART pins for the > function intended by the housing. This can be done through a I2C > register poke, toggling a (different) GPIO line, etc.[2] this is _way_ too complicated, and also not clear. > - I think it should be valid for a CPU card to follow the current model > and keep the UART pins tri-stated until it's fully booted. A housing > that wants to capture early debug traffic can generate a well-defined > idle signal on the TX line with a pull-up. this is even more complicated... and also unnecessary when the person doing the debugging may either: * in-situ use multiplexing of user-facing connectors (A20 MicroSD / UART-JTAG capability) * take the Card out of the Housing and test it in a home-made or laboratory-owned test Housing. > This is a debug facility. Not all CPU cards have to use it, but all > housings must accept it. that places a huge technical burden and complexity on Housing Designers *and* Card Designers, where no such complexity or burdensome requirements exist at the moment. > Thus it is just as (non-)optional as USB, with the difference that the > CPU card decides whether it prints early debug messages, and the Housing > decides whether it connects the USB pins to any USB devices or > connectors. the purpose of requiring the "non-optionality" is to ensure that there is absolutely no way that a future Card or future Housing will be incompatible with an older Card or an older Housing, no matter how much faster the peripherals on either the Card(s) or the Housing(s) have become. SD/MMC itself is a perfect example, as not only is the speed auto-negotiated based on how many physical wires "happen to connect" - 1 2 or 4 - but there is also *automatic* host-to-card negotiation of speed capabilities *built into the protocol*. likewise SATA and USB, and also the ADSL / SDSL broadband protocol, and also PCIe. all of these protocols do "negotiation", right down to the VERY slowest, oldest possible equipment that could possibly be plugged in. all of these protocols are incredibly simple as far as EOMA68 is concerned: they "take care of themselves". UART, SPI, I2C, RGB/TTL and the three degenerate cases GPIO, PWM and EINT on the other hand, cannot "self-negotiate". that's what the I2C EEPROM is for: to describe and specify those functions totally unambiguously so that the Card is GUARANTEED - as long as it follows the EOMA68 specification - NOT to do any damage to itself or to the Housing. the other consideration i have is that the standard has to be simple, and implementation of Housings and Cards has to be very straightforward. what you are proposing has two possible alternatives (actually a third is as you suggested: open up the Card's case and start re-wiring things and hand-soldering on extra components or connections) where all of the alternatives achieve exactly the same thing.... *without *requiring that the EOMA68 Standard have additional complexity added to it. > "Fully (enough) booted" in the above doesn't just mean the CPU has left > the bootloader. It also has to have read the I2C EEPROM, which might > require quite a bit of work in the kernel (initializing the I2C > controller, at least). Things can go wrong before the CPU card has > booted far enough before it can read and interpret the I2C EEPROM, which > is my whole motivation. exactly. and that's precisely why additional complexity should *not* be added to the negotiation phase. >> .... so what do you think would happen, in this case, if someone >> plugged in a Card where it was FORCIBLY REQUIRED that UART *ABSOLUTELY >> MUST* transmit "early boot messages" on those two wires? > > Required by which part? sorry, the use of the word "part" is not clear. part of the standard? part of the Card? part of the Housing? part of the proposed modification to the standard? anyway, that was written when i believed that you were proposing that Cards are forced to transmit early boot messages over UART. > - Housings shouldn't require to see any debug messages from CPU cards, > that's just silly the point is: if the wires are to be forced to transmit early debug messages, then in ABSOLUTELY NO WAY can they also be allowed to change over to GPIO. there must be ABSOLUTELY NO POSSIBLE RISK that their use as UART could conceivably cause damage to either the CPU or to the Housing components. and if there is a current fight between a GPIO that is tied permanently to VREFTTL on the Housing and the forced requirement to transmit UART early debug messages tries to pull it high, we have a serious problem. i appreciate that you have come up with a solution to this, involving a complex process of ascertaining via the EEPROM whether the pins are GPIO or UART, but it is complexity where *none* exists at the moment, and there are two easy alternatives that place absolutely no burden whatsoever on the Technical EndUser. >> i trust that you can appreciate that it would overwhelm both me and >> you and everyone on this list to have three ongoing *simultaneous* >> separate and distinct highly-technical logical reasoning discussions, >> yeh? > > Yes. cool, whew :) this _is_ really important, to make absolutely sure that the standard will be useful and useable for at least the next decade. thanks johnathon. l. From lkcl at lkcl.net Wed Jan 10 20:34:39 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 10 Jan 2018 20:34:39 +0000 Subject: [Arm-netbook] http://www.nano-di.com/dragonfly-2020-pro Message-ID: oooo i want one! this can do 4 mil track widths and 5 mil clearance... it could handle the EOMA68-A20 PCB no problem whatsoever! that's 5mil tracks, 5mil clearance. for the RK3288 however it would not do the job: that has 0.6mm pin-pitch BGA and eMMC and you need 3mil track widths and 3mil clearance for that.... this is getting really exciting, this 3D printing of PCBs. l. From lasich at gmail.com Wed Jan 10 20:44:06 2018 From: lasich at gmail.com (Hrvoje Lasic) Date: Wed, 10 Jan 2018 21:44:06 +0100 Subject: [Arm-netbook] http://www.nano-di.com/dragonfly-2020-pro In-Reply-To: References: Message-ID: On 10 January 2018 at 21:34, Luke Kenneth Casson Leighton wrote: > oooo i want one! this can do 4 mil track widths and 5 mil > clearance... it could handle the EOMA68-A20 PCB no problem whatsoever! > that's 5mil tracks, 5mil clearance. for the RK3288 however it would > not do the job: that has 0.6mm pin-pitch BGA and eMMC and you need > 3mil track widths and 3mil clearance for that.... > > this is getting really exciting, this 3D printing of PCBs. > > l. > truth and combining with small setup for pick and place or even manual for protoypes really cool From j.neuschaefer at gmx.net Thu Jan 11 21:50:38 2018 From: j.neuschaefer at gmx.net (Jonathan =?utf-8?Q?Neusch=C3=A4fer?=) Date: Thu, 11 Jan 2018 22:50:38 +0100 Subject: [Arm-netbook] Early UART output vs. housing board discovery In-Reply-To: References: <20180109222257.e5akm3qygves2dji@latitude> <20180110134402.d6cyfzmscicglt6q@latitude> <20180110161135.lbu5eafqvcasrrnc@latitude> Message-ID: <20180111215038.pyki3h64mkt2gba3@latitude> Hi, Please excuse the verbosity of some parts of this email, where I tried to be extra clear. On Wed, Jan 10, 2018 at 07:22:16PM +0000, Luke Kenneth Casson Leighton wrote: > On Wed, Jan 10, 2018 at 4:11 PM, Jonathan Neuschäfer wrote: > > On Wed, Jan 10, 2018 at 01:59:19PM +0000, Luke Kenneth Casson Leighton wrote: [...] > >> no it's even more basic / simpler than that. they don't have to do > >> that, they can just put the Card into a break-out PCMCIA holder > >> socket. or anything else. > > > > ... and enable early debug mode through unspecified means, right? > > no, it's very clearly specified that there *is* no limit or > restriction. which is totally different from leaving things > "unspecified". The EOMA68 spec doesn't specify how to enable early debug mode, that's what I meant. > >> > In short: Thank you for the clarification. Now I disagree with this > >> > decision in the spec. :-/ > >> > >> ok, so bear in mind that the UART wires double up as GPIO, and that > >> it is the HOUSING DESIGNER's right, under the EOMA68 specification, to > >> make the decision to allocate eiher one (or both) of the UART wires to > >> GPIO - as either Input or Output. > > > > This is AFAICS not a big problem under my suggested change. > > > > For reference, this is my suggested change: > > - CPU Cards may use the UART lines for debug purposes while they are not > > fully (enough) booted. > > ok so that implies that the UART lines MAY be UART... they MIGHT also > be GPIO. please bear in mind: anything that involves "confusion" is > AUTOMATICALLY prohibited from being included in the EOMA68 Standard. Confusion for which group of people? USERS: Early debug output is a feature that probably shouldn't be documented for Retail Endusers anyway: They can't be expected to find it useful. Technical Endusers however can probably navigate the confusion, and understand the feature if it's documented well enough. CARD DESIGNERS: I don't think card hardware designs need to change. HOUSING DESIGNERS: Yes, this puts the burden to tolerate UART mode during early boot on housing designers. OPERATING SYSTEM DEVELOPERS: Yes, OSes may need to do a little more in order to use the full feature set of a housing. BOOTLOADER DEVELOPERS: AFAICS, they need to care less about EOMA68 then before, because they can now just print all the debug output they want, without looking at the EEPROM. > i appreciate that in this case you describe a procedure that would > remove doubt, but the procedure itself is very burdensome to > implement. > > there is a story i told about the X25 Standard which illustrates how > these kinds of choices result in lost opportunities and/or total > confusion and thus destroy confidence in a standard. > > > > - When a CPU card has fully (enough) booted, it must use the UART pins > > in the function that's described in the EEPROM. > > ok so the boot process you propose is: > > * bring up the CPU (DDR3, PLLs) > * initialise EEPROM GPIO pins and configure them as I2C > * read an I2C EEPROM > * decode it > * work out if it's SAFE to write to UART > * THEN write debug / print messages on the UART pins > > ... can you see how that's not "early" at all? No, what I'm trying to propose (and think through) is different: * Reset the SoC and bring the pins of the EOMA68 connector into the state that's mandated at reset (most pins tri-stated, etc.) * Bring some of the SoC (configure clock trees, maybe the DRAM, too) * Initialize the UART and start using it, because it is safe to use in early boot * Continue bringing up things and printing debug messages * Perhaps already load the OS kernel * Configure the I2C controller and read the EEPROM * Stop doing early debug output, and start using the UART pins in the way that's mandated by the EEPROM I can see two points where problems might occur: * If software fails to disable early debug output in the UART (this shouldn't too hard to solve in Linux, though). * If the CPU card spontaneously resets without first bringing the housing into a state where it tolerates early debug output (some housings might require such preparation before shutdown). > > For example, UART > > connected to a Bluetooth module, GPIO connected to whatever, etc. > > - If a housing needs to protect its components from debug traffic, it > > must provide (and describe in the EEPROM) a mechanism for the CPU card > > to signal that it has booted far enough to use the UART pins for the > > function intended by the housing. This can be done through a I2C > > register poke, toggling a (different) GPIO line, etc.[2] > > this is _way_ too complicated, and also not clear. Sorry, what exactly is unclear? > > - I think it should be valid for a CPU card to follow the current model > > and keep the UART pins tri-stated until it's fully booted. A housing > > that wants to capture early debug traffic can generate a well-defined > > idle signal on the TX line with a pull-up. > > this is even more complicated... and also unnecessary when the person > doing the debugging may either: > > * in-situ use multiplexing of user-facing connectors (A20 MicroSD / > UART-JTAG capability) Yes, because this is a completely different approach. > * take the Card out of the Housing and test it in a home-made or > laboratory-owned test Housing. How can a lab housing tell a card that it's safe to do early debug output? (Or is that still signaled out of band, e.g. by replacing the boot loader?) > > This is a debug facility. Not all CPU cards have to use it, but all > > housings must accept it. > > that places a huge technical burden and complexity on Housing > Designers *and* Card Designers, where no such complexity or burdensome > requirements exist at the moment. > > > > Thus it is just as (non-)optional as USB, with the difference that the > > CPU card decides whether it prints early debug messages, and the Housing > > decides whether it connects the USB pins to any USB devices or > > connectors. > > the purpose of requiring the "non-optionality" is to ensure that > there is absolutely no way that a future Card or future Housing will > be incompatible with an older Card or an older Housing, no matter how > much faster the peripherals on either the Card(s) or the Housing(s) > have become. [...] How is speed relevant to this discussion? > > "Fully (enough) booted" in the above doesn't just mean the CPU has left > > the bootloader. It also has to have read the I2C EEPROM, which might > > require quite a bit of work in the kernel (initializing the I2C > > controller, at least). Things can go wrong before the CPU card has > > booted far enough before it can read and interpret the I2C EEPROM, which > > is my whole motivation. > > exactly. and that's precisely why additional complexity should *not* > be added to the negotiation phase. I don't quite understand your argument here: The only way I'm complicating the "negotiation phase" is by requiring that the software stops any Debug UART output before it switches its use of the UART pins over to the housing-mandated use. I am not complicating negotiation itself (init I2C controller, read EEPROM, parse EEPROM, act on it). > >> .... so what do you think would happen, in this case, if someone > >> plugged in a Card where it was FORCIBLY REQUIRED that UART *ABSOLUTELY > >> MUST* transmit "early boot messages" on those two wires? > > > > Required by which part? > > sorry, the use of the word "part" is not clear. part of the standard? > part of the Card? part of the Housing? part of the proposed > modification to the standard? I mean hardware part, which would be either the CPU card or the Housing. > > - Housings shouldn't require to see any debug messages from CPU cards, > > that's just silly > > the point is: if the wires are to be forced to transmit early debug > messages, then in ABSOLUTELY NO WAY can they also be allowed to change > over to GPIO. there must be ABSOLUTELY NO POSSIBLE RISK that their > use as UART could conceivably cause damage to either the CPU or to the > Housing components. Ok, I think I see the point here. > and if there is a current fight between a GPIO that is tied > permanently to VREFTTL on the Housing and the forced requirement to > transmit UART early debug messages tries to pull it high, we have a > serious problem. Permanently (through PCB traces) tying pin 23 (GPIO8/UART_TX) to VREFTTL is not allowed under my proposal. (And I think you meant "tries to pull it *low*", not high.) > i appreciate that you have come up with a solution to this, involving > a complex process of ascertaining via the EEPROM whether the pins are > GPIO or UART, Figuring out (in software) whether the pins are used as UART or GPIO at runtime, by asking the EEPROM, is no more complex than before. > but it is complexity where *none* exists at the moment, > and there are two easy alternatives that place absolutely no burden > whatsoever on the Technical EndUser. Soldering to small test pads inside the card is a burden. Figuring out the pin muxing and ordering a microSD breakout board is also a burden. Those might be small burdens (depending on the experience and market situation of the Technical Enduser), but they are still burdens. Okay, I think I now understand the main problem with my proposal: Ensuring that it is safe for the CPU card to use pins 23 and 57 during early boot is hard or causes some additional complexity in the housing and software, because (a) because it may reset (and thus enter early boot) spontaneously, and (b) when it leaves early boot, it may have to tell the housing about it. My goal was to have a mechanism, specified by the EOMA68 standard, by which an interested Technical Enduser can access early debug output of any EOMA68 CPU card, without doing anything CPU card specific (such as ordering a Allwinner A20 µSD breakout board, or opening the card and soldering some wires to the right testpads, or loading a "debug enabled" version of the particular bootloader/OS running on a card). Here's a *completely different* and significantly simpler proposal, which also fulfills these goals. You probably won't like it because (a) it takes away a pin from general purpose use, (b) it breaks compatibility [see footnote 1] with current hardware. Replace one of the GPIO pins (such as pin 21, GPIO 20) with a single- purpose Debug UART TX pin, where the CPU card may print debug messages in 8N1 format. Debug UART TX high/low is measured against VREFTTL. CPU card-agnostic applications which require EOMA68, should still not rely on the Debug UART TX line. As to why the "may" above does not hurt non-optionality: This is not a Retail Enduser facing feature, and should not be advertised to Retail Endusers. If a card doesn't use the Debug UART TX line (i.e. never prints a message), then this doesn't break compatibility with any housings, even housings that are specifically made for the purpose of capturing Debug UART TX output. In the worst case, a Technical Enduser will think "Oh, this card doesn't output anything on the debug line. Now I can't debug it as easily", but not "This card doesn't output anything on the debug line, now my application doesn't work". (Such a CPU card is, in a way, only "hurting itself") Alternatively, this could be two pins (Debug UART TX and RX) so that something like a bootloader shell may be used. But this is probably worse because it takes another pin away from general-purpose use. Thanks, Jonathan Neuschäfer [footnote 1]: Current CPU card hardware could in fact generate a valid (idle) Debug UART TX signal, by driving Debug UART TX high. From lkcl at lkcl.net Fri Jan 12 10:29:14 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 12 Jan 2018 10:29:14 +0000 Subject: [Arm-netbook] Early UART output vs. housing board discovery In-Reply-To: <20180111215038.pyki3h64mkt2gba3@latitude> References: <20180109222257.e5akm3qygves2dji@latitude> <20180110134402.d6cyfzmscicglt6q@latitude> <20180110161135.lbu5eafqvcasrrnc@latitude> <20180111215038.pyki3h64mkt2gba3@latitude> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Thu, Jan 11, 2018 at 9:50 PM, Jonathan Neuschäfer wrote: > Hi, > > Please excuse the verbosity of some parts of this email, where I tried > to be extra clear. thanks jonathon. >> no, it's very clearly specified that there *is* no limit or >> restriction. which is totally different from leaving things >> "unspecified". > > The EOMA68 spec doesn't specify how to enable early debug mode, that's > what I meant. the correct technical phrase is "it is out of scope". which i forgot to add. so that's because it's assumed to be part of either a factory install (where the EOMA68 specification does not apply. or it does - or should say - "this is out of scope") or you are a Technical End-User.... where the EOMA68 specification does not apply. or.. it does, but it says - or should say - "this is out of scope" >> >> > In short: Thank you for the clarification. Now I disagree with this >> >> > decision in the spec. :-/ >> >> >> >> ok, so bear in mind that the UART wires double up as GPIO, and that >> >> it is the HOUSING DESIGNER's right, under the EOMA68 specification, to >> >> make the decision to allocate eiher one (or both) of the UART wires to >> >> GPIO - as either Input or Output. >> > >> > This is AFAICS not a big problem under my suggested change. >> > >> > For reference, this is my suggested change: >> > - CPU Cards may use the UART lines for debug purposes while they are not >> > fully (enough) booted. >> >> ok so that implies that the UART lines MAY be UART... they MIGHT also >> be GPIO. please bear in mind: anything that involves "confusion" is >> AUTOMATICALLY prohibited from being included in the EOMA68 Standard. > > Confusion for which group of people? mainly it's the end users > USERS: Early debug output is a feature that probably shouldn't be > documented for Retail Endusers anyway: absolutely. in fact it is the opposite: they should NOT be informed of its existence. they would be totally scared and freaked out. > They can't be expected to find > it useful. Technical Endusers however can probably navigate the > confusion, and understand the feature if it's documented well enough. ... exactly. > CARD DESIGNERS: I don't think card hardware designs need to change. yyyeah.... i think it should be _adviseable_ - not mandatory but _advised_ that easy and independent debugging - preferably without dismantlement of Cards - should be mentioned. > HOUSING DESIGNERS: Yes, this puts the burden to tolerate UART mode > during early boot on housing designers. that's the bit that's not acceptable. > OPERATING SYSTEM DEVELOPERS: Yes, OSes may need to do a little more in > order to use the full feature set of a housing. > > BOOTLOADER DEVELOPERS: AFAICS, they need to care less about EOMA68 then > before, because they can now just print all the debug output they want, > without looking at the EEPROM. ... and lose 2 critical GPIO pins where they are extremely precious, and if they are not available you have to add $1 to $1.50 to the Housing BOM to add an 8/32-bit MicroController, and massively complicate the OS and Housing design compared to just having 2 GPIO pins? ... no :) >> i appreciate that in this case you describe a procedure that would >> remove doubt, but the procedure itself is very burdensome to >> implement. >> >> there is a story i told about the X25 Standard which illustrates how >> these kinds of choices result in lost opportunities and/or total >> confusion and thus destroy confidence in a standard. >> >> >> > - When a CPU card has fully (enough) booted, it must use the UART pins >> > in the function that's described in the EEPROM. >> >> ok so the boot process you propose is: >> >> * bring up the CPU (DDR3, PLLs) >> * initialise EEPROM GPIO pins and configure them as I2C >> * read an I2C EEPROM >> * decode it >> * work out if it's SAFE to write to UART >> * THEN write debug / print messages on the UART pins >> >> ... can you see how that's not "early" at all? > > No, what I'm trying to propose (and think through) is different: > > * Reset the SoC and bring the pins of the EOMA68 connector into the > state that's mandated at reset (most pins tri-stated, etc.) > * Bring some of the SoC (configure clock trees, maybe the DRAM, too) > * Initialize the UART and start using it, because it is safe to use in > early boot yes. ok. this is where the problem starts. this is why i described it as "forced writing to UART". if you FORCE writing to UART, you MUST not have the possibility of these two pins potentially being GPIO. why? because you get into a CMOS current fight between UART and fixed GPIO function (short to GND or short to VREFTTL) which will either damage the UNBUFFERED processor pins or damage the housing. therefore you must make it MANDATORY that the ONLY function that those two pins have is: UART. therefore you LOSE two precious GPIO pins. and that is not acceptable. > * Continue bringing up things and printing debug messages > * Perhaps already load the OS kernel > * Configure the I2C controller and read the EEPROM > * Stop doing early debug output, and start using the UART pins in > the way that's mandated by the EEPROM too complicated. > I can see two points where problems might occur: > * If software fails to disable early debug output in the UART (this > shouldn't too hard to solve in Linux, though). there is also damage to the SoC or to the housing to take into consideration. > * If the CPU card spontaneously resets without first bringing the > housing into a state where it tolerates early debug output > (some housings might require such preparation before shutdown). exactly. and that is far too complicated. right now there is *zero* need - at all - for *any* kind of complexity on the Housings. the Micro-Desktop is.... it's just a bunch of connectors. as in, that's *all* that's needed. oh! ah.... that's another reason why the proposed change can't be done (aside from it being unnecessary, as there are debug mechanisms available): the MicroDesktop PCB is finalised. >> > For example, UART >> > connected to a Bluetooth module, GPIO connected to whatever, etc. >> > - If a housing needs to protect its components from debug traffic, it >> > must provide (and describe in the EEPROM) a mechanism for the CPU card >> > to signal that it has booted far enough to use the UART pins for the >> > function intended by the housing. This can be done through a I2C >> > register poke, toggling a (different) GPIO line, etc.[2] >> >> this is _way_ too complicated, and also not clear. > > Sorry, what exactly is unclear? it's too complcated, it raises the complexity of Housings from "passive I/O systems" to "requiring some form of boolean logic circuit". it's not needed, it's too complicated, and it's also, realistically, too late. >> > - I think it should be valid for a CPU card to follow the current model >> > and keep the UART pins tri-stated until it's fully booted. A housing >> > that wants to capture early debug traffic can generate a well-defined >> > idle signal on the TX line with a pull-up. >> >> this is even more complicated... and also unnecessary when the person >> doing the debugging may either: >> >> * in-situ use multiplexing of user-facing connectors (A20 MicroSD / >> UART-JTAG capability) > > Yes, because this is a completely different approach. > >> * take the Card out of the Housing and test it in a home-made or >> laboratory-owned test Housing. > > How can a lab housing tell a card that it's safe to do early debug > output? that's the responsibility of the Technical End-User to research and determine precisely that. > (Or is that still signaled out of band, e.g. by replacing the > boot loader?) you replace the bootloader. it is *REQUIRED* - as part of the EOMA68 Specification - that the replacement of the bootloader - all of it - be not only possible but the hardware be FULLY DOCUMENTED such that it IS possible. that allows for companies to provide proprietary bootloaders if they so wish (for which they will be charged extra fixed-rate non-percentage-based non-royalty-based license costs). if however they release FULL source code of the bootloader (and the full toolchain), they will not be charged any fees at all. >> > Thus it is just as (non-)optional as USB, with the difference that the >> > CPU card decides whether it prints early debug messages, and the Housing >> > decides whether it connects the USB pins to any USB devices or >> > connectors. >> >> the purpose of requiring the "non-optionality" is to ensure that >> there is absolutely no way that a future Card or future Housing will >> be incompatible with an older Card or an older Housing, no matter how >> much faster the peripherals on either the Card(s) or the Housing(s) >> have become. > [...] > > How is speed relevant to this discussion? it is an illustration of the fact that this is a long-term standard. >> > "Fully (enough) booted" in the above doesn't just mean the CPU has left >> > the bootloader. It also has to have read the I2C EEPROM, which might >> > require quite a bit of work in the kernel (initializing the I2C >> > controller, at least). Things can go wrong before the CPU card has >> > booted far enough before it can read and interpret the I2C EEPROM, which >> > is my whole motivation. >> >> exactly. and that's precisely why additional complexity should *not* >> be added to the negotiation phase. > > I don't quite understand your argument here: The only way I'm > complicating the "negotiation phase" is by requiring that the software > stops any Debug UART output before it switches its use of the UART pins > over to the housing-mandated use. that is far too complicated compared to the "passive" nature of, for example, the Micro-Desktop Housing. see above, the answer is the same as here. > I am not complicating negotiation itself (init I2C controller, read > EEPROM, parse EEPROM, act on it). the current design, there *is* no extra negotiation, period, on the Housings. therefore adding some *is*, by definition, a whole new level of complexity [that is not acceptable. and too late. and unnecessary]. >> >> .... so what do you think would happen, in this case, if someone >> >> plugged in a Card where it was FORCIBLY REQUIRED that UART *ABSOLUTELY >> >> MUST* transmit "early boot messages" on those two wires? >> > >> > Required by which part? >> >> sorry, the use of the word "part" is not clear. part of the standard? >> part of the Card? part of the Housing? part of the proposed >> modification to the standard? > > I mean hardware part, which would be either the CPU card or the Housing. precisely. you do not know. therefore there is the risk of confusion. and therefore, one - or other or both - would be damaged. it is ABSOLUTELY ESSENTIAL that there be ZERO possibility for ambiguity in a standard. >> > - Housings shouldn't require to see any debug messages from CPU cards, >> > that's just silly >> >> the point is: if the wires are to be forced to transmit early debug >> messages, then in ABSOLUTELY NO WAY can they also be allowed to change >> over to GPIO. there must be ABSOLUTELY NO POSSIBLE RISK that their >> use as UART could conceivably cause damage to either the CPU or to the >> Housing components. > > Ok, I think I see the point here. yehyeh. it's really, really important. >> and if there is a current fight between a GPIO that is tied >> permanently to VREFTTL on the Housing and the forced requirement to >> transmit UART early debug messages tries to pull it high, we have a >> serious problem. > > Permanently (through PCB traces) tying pin 23 (GPIO8/UART_TX) to VREFTTL > is not allowed under my proposal. that would need to be part of the specification. now you have to have a resistor in the circuit to stop damage. NOW you have to wonder if that will stop the GPIO pin, if it is an input, from being able to drive the line properly. ... do you see how it gets massively complex? and i haven't even gotten into how to protect the GPIO from over-voltage protection during power-down and power-up. it's just far, far too much, jonathon... *and completely unnecessary*. > (And I think you meant "tries to pull it *low*", not high.) it doesn't matter which it is: damage can occur either way. >> i appreciate that you have come up with a solution to this, involving >> a complex process of ascertaining via the EEPROM whether the pins are >> GPIO or UART, > > Figuring out (in software) whether the pins are used as UART or GPIO at > runtime, by asking the EEPROM, is no more complex than before. it's too complex, and you can't debug the chip during the EEPROM bring-up phase because it's too dangerous to do so. it's *too complex* jonathon. >> but it is complexity where *none* exists at the moment, >> and there are two easy alternatives that place absolutely no burden >> whatsoever on the Technical EndUser. > > Soldering to small test pads inside the card is a burden. yes. it's not recommended. > Figuring out the pin muxing and ordering a microSD breakout board is > also a burden. tough. a Technical End-User *will* be expected to figure it out. that's why they're called "Technical End-User". > Those might be small burdens (depending on the experience and market > situation of the Technical Enduser), but they are still burdens. yep. tough. if they can't figure it out, they can ask someone online how it's done. this is no different from any other dev-board. someone, somewhere, knows how to do it. > > Okay, I think I now understand the main problem with my proposal: > Ensuring that it is safe for the CPU card to use pins 23 and 57 during > early boot is hard or causes some additional complexity in the housing > and software, because (a) because it may reset (and thus enter early > boot) spontaneously, and (b) when it leaves early boot, it may have to > tell the housing about it. exactly. and the very fact that the housing has to have "logic" in it, where the Housings are currently TOTALLY passive, is a level of complexity that's unacceptable [and unnecessary]. > My goal was to have a mechanism, specified by the EOMA68 standard, by > which an interested Technical Enduser can access early debug output of > any EOMA68 CPU card, without doing anything CPU card specific (such as > ordering a Allwinner A20 µSD breakout board, or opening the card and > soldering some wires to the right testpads, or loading a "debug enabled" > version of the particular bootloader/OS running on a card). my goal is: to make it easy and safe for normal mass-volume end-users to use EOMA68 systems. "Just Plug It In, It Will Work". everyone else - everything else - comes secondary. > Here's a *completely different* and significantly simpler proposal, > which also fulfills these goals. You probably won't like it because > (a) it takes away a pin from general purpose use, (b) it breaks > compatibility [see footnote 1] with current hardware. > > Replace one of the GPIO pins (such as pin 21, GPIO 20) with a single- > purpose Debug UART TX pin, where the CPU card may print debug messages > in 8N1 format. Debug UART TX high/low is measured against VREFTTL. nope. not enough pins. you're thinking in terms of prioritising "Technical End-User" over "End-User". the volume of sales to "End User" is intended to be HUNDREDS OF MILLIONS. the volume of sales to "Technical End User" is expected to measure in the thousands. ... which should the project be prioritised for? if this was something like a "Mars Board" or a "Beagle Board" or {insert-other-technical-developer-board} it would be a totally different discussion. this is a *mass-volume* standard, ***NOT*** repeat ***NOT*** a TECHNICAL DEVELOPER user standard. > Alternatively, this could be two pins (Debug UART TX and RX) so that > something like a bootloader shell may be used. But this is probably > worse because it takes another pin away from general-purpose use. exactly. now you're getting it. the cost of adding break-out GPIO extenders could add 10 to 20% onto the BOM, and that's totally unacceptable in a *mass-volume* market. it's perfectly acceptable in a "Demo Board" or a "Reference Design Board" or a "Developer Board" scenario, but completely unacceptable for a mass-volume standard. l. From richard.wilbur at gmail.com Fri Jan 12 23:37:33 2018 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Fri, 12 Jan 2018 16:37:33 -0700 Subject: [Arm-netbook] Crowsupply update In-Reply-To: References: <132A1FA8-9EE8-413C-8DFD-D9966046CF6D@gmail.com> <4609ED0A-4209-43C1-A7F1-6EE099610CA8@gmail.com> Message-ID: <0A64185A-34C3-45EA-8B89-D025CC4F427B@gmail.com> Last time I asked these questions I succeeded in hiding them in the middle of a bunch of other text. On Jan 9, 2018, at 06:26, Richard Wilbur wrote: > What kind of logic are these GPIO pins? (CMOS, TTL, etc.) The type of logic determines the input and output voltage and current source and sink characteristics (both capabilities and expectations). Do you have the Allwinner documentation for the A20--specifically for the GPIO pins? > So there are 4 pairs or 8 GPIO lines to test? (I thought we had more lines dedicated to GPIO and two more that were going to be used as I2C for VGA? Are only 8 easy to test?) From lkcl at lkcl.net Sat Jan 13 01:15:35 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sat, 13 Jan 2018 01:15:35 +0000 Subject: [Arm-netbook] Crowsupply update In-Reply-To: <0A64185A-34C3-45EA-8B89-D025CC4F427B@gmail.com> References: <132A1FA8-9EE8-413C-8DFD-D9966046CF6D@gmail.com> <4609ED0A-4209-43C1-A7F1-6EE099610CA8@gmail.com> <0A64185A-34C3-45EA-8B89-D025CC4F427B@gmail.com> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Fri, Jan 12, 2018 at 11:37 PM, Richard Wilbur wrote: > Last time I asked these questions I succeeded in hiding them in the middle of a bunch of other text. > > On Jan 9, 2018, at 06:26, Richard Wilbur wrote: >> What kind of logic are these GPIO pins? (CMOS, TTL, etc.) > > The type of logic determines the input and output voltage and current > source and sink characteristics (both capabilities and expectations). > Do you have the Allwinner documentation for the A20--specifically for > the GPIO pins? ok google "allwinner a20 datasheet" or better "allwinner a20 reference manual" you'll find it. >> So there are 4 pairs or 8 GPIO lines to test? (I thought we >> had more lines dedicated to GPIO and two more that were >>going to be used as I2C for VGA? Are only 8 easy to test?) the choice - on the Microdesktop PCB - to arbitrarily utilise two of the GPIO pins as bit-banged I2C - is entirely one that is legitimate yet has absolutely nothing to do with the EOMA68 specification, *other* than, "It Is Permitted" under the EOMA68 specification to make such decisions. the choice - on the Microdesktop PCB - to arbitrarily utilise those two GPIO pins as bit-banged I2C - is done because the termination impedance for VGA EDID is, according to the specification, somewhere around 10 kOhms, whereas the normal I2C termination resistance is usually somewhere around 2.2kOhms. i felt therefore that it was important *not* to have the VGA I2C lines connected to the EOMA68 I2C bus. these decisions have *nothing to do with the EOMA68 specification*, they are simply "permitted under the EOMA68 specification" if that makes sense. l. From richard.wilbur at gmail.com Sat Jan 13 22:05:48 2018 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Sat, 13 Jan 2018 15:05:48 -0700 Subject: [Arm-netbook] Crowsupply update In-Reply-To: References: <132A1FA8-9EE8-413C-8DFD-D9966046CF6D@gmail.com> <4609ED0A-4209-43C1-A7F1-6EE099610CA8@gmail.com> <0A64185A-34C3-45EA-8B89-D025CC4F427B@gmail.com> Message-ID: <816541FF-C11F-4F9F-B586-CE11BAE45FD4@gmail.com> I am sorry if any of my comments came across with any flavour of criticism. I meant none towards anyone but myself. Thank you for the pointer to the Allwinner A20 documentation. I didn't know how easily available it was. I was just wondering whether there were more GPIO lines we could test (by hook or by crook). My goal is the best test coverage. No complaints about the EOMA specification or your design decisions on the microdesktop case. From lkcl at lkcl.net Sat Jan 13 22:11:17 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sat, 13 Jan 2018 22:11:17 +0000 Subject: [Arm-netbook] Crowsupply update In-Reply-To: <816541FF-C11F-4F9F-B586-CE11BAE45FD4@gmail.com> References: <132A1FA8-9EE8-413C-8DFD-D9966046CF6D@gmail.com> <4609ED0A-4209-43C1-A7F1-6EE099610CA8@gmail.com> <0A64185A-34C3-45EA-8B89-D025CC4F427B@gmail.com> <816541FF-C11F-4F9F-B586-CE11BAE45FD4@gmail.com> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Sat, Jan 13, 2018 at 10:05 PM, Richard Wilbur wrote: > I am sorry if any of my comments came across with any flavour of criticism. I meant none towards anyone but myself. nono, sorry, richard, i was up very late. and am again today. kept it very short. > Thank you for the pointer to the Allwinner A20 documentation. I didn't know how easily available it was. it can be a pain to find if you don't know the keywords > I was just wondering whether there were more GPIO lines we could test (by hook or by crook). My goal is the best test coverage. i also have to think how to minimise testing time, as it will be chargeable by the minute. either that or i do it... get *everything* shipped to my apartment.... oooo i always wanted an ultra-low-power beowulf clusterrrr... ooooo :) > No complaints about the EOMA specification or your design decisions on the microdesktop case. relief. btw jonathon, please do keep the momentum going, it's important. damn hard work, i've gone through several reviews like this, over the past 5 years, and four of them resulted in major changes. it's very *very* late in the day now so it's necessary to be extra-extra careful. l. From richard.wilbur at gmail.com Sun Jan 14 07:50:40 2018 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Sun, 14 Jan 2018 00:50:40 -0700 Subject: [Arm-netbook] Crowsupply update In-Reply-To: References: <132A1FA8-9EE8-413C-8DFD-D9966046CF6D@gmail.com> <4609ED0A-4209-43C1-A7F1-6EE099610CA8@gmail.com> <0A64185A-34C3-45EA-8B89-D025CC4F427B@gmail.com> <816541FF-C11F-4F9F-B586-CE11BAE45FD4@gmail.com> Message-ID: On Jan 13, 2018, at 15:11, Luke Kenneth Casson Leighton wrote: > On Sat, Jan 13, 2018 at 10:05 PM, Richard Wilbur > wrote: >> I was just wondering whether there were more GPIO lines we could test (by hook or by crook). My goal is the best test coverage. > > i also have to think how to minimise testing time, as it will be > chargeable by the minute. either that or i do it... get *everything* > shipped to my apartment.... oooo i always wanted an ultra-low-power > beowulf clusterrrr... ooooo :) >From what I've seen, I think we can automate a lot of this so it takes a second or two per card. I expect our tall tentpole (the thing that's holding everything up) will be booting the card. Do you know how long it takes the bootloader to come up from power on? How long does it take GNU/Linux to get to user login after that? From lkcl at lkcl.net Sun Jan 14 10:04:07 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 14 Jan 2018 10:04:07 +0000 Subject: [Arm-netbook] Crowsupply update In-Reply-To: References: <132A1FA8-9EE8-413C-8DFD-D9966046CF6D@gmail.com> <4609ED0A-4209-43C1-A7F1-6EE099610CA8@gmail.com> <0A64185A-34C3-45EA-8B89-D025CC4F427B@gmail.com> <816541FF-C11F-4F9F-B586-CE11BAE45FD4@gmail.com> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Sun, Jan 14, 2018 at 7:50 AM, Richard Wilbur wrote: > On Jan 13, 2018, at 15:11, Luke Kenneth Casson Leighton wrote: >> On Sat, Jan 13, 2018 at 10:05 PM, Richard Wilbur >> wrote: >>> I was just wondering whether there were more GPIO lines we could test (by hook or by crook). My goal is the best test coverage. >> >> i also have to think how to minimise testing time, as it will be >> chargeable by the minute. either that or i do it... get *everything* >> shipped to my apartment.... oooo i always wanted an ultra-low-power >> beowulf clusterrrr... ooooo :) > > From what I've seen, I think we can automate a lot of this so it takes > a second or two per card. it'll be a bit longer than that :) > I expect our tall tentpole (the thing > that's holding everything up) will be booting the card. Do you know > how long it takes the bootloader to come up from power on? it's about 1-2 seconds :) there's a 3 second automated delay for "user-input" which can be switched off. > How long > does it take GNU/Linux to get to user login after that? initialisation of the linux kernel depends very much on which kernel modules are compiled-in and which are modules, but let's say around 4-7 seconds. there is quite a lot of "delay" built-in, such as waiting for sd-cards to initialise, or waiting for this to initialise,waiting for that etc. from /sbin/init to a full GUI is about another.... 10-15 seconds. l. From richard.wilbur at gmail.com Tue Jan 16 21:06:24 2018 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Tue, 16 Jan 2018 14:06:24 -0700 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: <04496B4C-7BB6-4619-804C-C0296761F558@gmail.com> <0620D014-55E0-41C1-9CBF-B671898D7187@gmail.com> <110EC969-7221-42CE-9B54-F6D658E8BC90@gmail.com> <61C5A163-9A5C-4BD4-8DE6-65A418082907@gmail.com> <8A03534C-A3F6-4689-98FA-C4DD6CF465E2@gmail.com> <4E311CA5-D091-4E6B-8CD7-82F8DC7ECBD1@gmail.com> <544AD58E-3E36-411F-B75D-F49D08AD677B@gmail.com> <72396096-4F21-4668-877C-112A19194EB0@gmail.com> <9CEB80E3-5172-41E2-BECC-FE5551E070FE@gmail.com> <6DA57CDA-F7CC-42BF-B69C-0245D61F3E07@gmail.com> Message-ID: On Sep 20, 2017, at 13:27, Richard Wilbur wrote: > On Wed, Sep 20, 2017 at 1:57 AM, Luke Kenneth Casson Leighton > wrote: >> On Tue, Sep 19, 2017 at 11:26 PM, Richard Wilbur >> wrote: >>> I'm interested in >>> tracking down the power supply pins for the differential HDMI signals >>> as that is where our return path for common-mode signal has to go. >> >> there's no specific power pin for HDMI. the GND pins are grouped in >> with a whole stack of other GND pins, there's absolutely no way it's >> practical to get a special GND plane to it: the board is extremely >> full already. > > I'm not looking to provide any special connection to the power or > ground pins. I just want to make sure we don't obstruct the return > current path any more than necessary on its way from bottom reference > ground plane (layer 5) to top reference ground plane (layer 2) to the > power supply pins of the differential drivers: > 1. ground plane (layer 2) via to SoC ground pin land (layer 1) > 2. ground plane (layer 2) via to power supply decoupling capacitor > ground land (layer 1), through decoupling capacitor to land on power > supply trace (layer 1), through trace to SoC power supply pin land > (layer 1). > > The goal is to avoid unnecessarily impeding this return current path. > I'm trying to avoid making the path >~200mil and putting any major > obstruction (like a huge layer void) in the way. While browsing the A20 datasheet, I found that the HDMI section does have a power pin but not labelled the way I was asking you about. Page 18 mentions that VCC-HDMI is a power pin on ball #T13. On the schematic it is connected to net HVP which has power decoupling capacitor C108 which looks like "104" => 0.1uF. Looks like the path from the copper on layer 2 below the HDMI pins (balls #TUVW 22,23) on the SoC (processor) to the VCC-HDMI power pin (#T13) is ~300mil. It doesn't look overly impeded. From j.neuschaefer at gmx.net Tue Jan 16 22:34:08 2018 From: j.neuschaefer at gmx.net (Jonathan =?utf-8?Q?Neusch=C3=A4fer?=) Date: Tue, 16 Jan 2018 23:34:08 +0100 Subject: [Arm-netbook] Early UART output vs. housing board discovery In-Reply-To: References: <20180109222257.e5akm3qygves2dji@latitude> <20180110134402.d6cyfzmscicglt6q@latitude> <20180110161135.lbu5eafqvcasrrnc@latitude> <20180111215038.pyki3h64mkt2gba3@latitude> Message-ID: <20180116223408.uumafiiindpbakhh@latitude> Thanks for your explanations. That's all I really have to say after that mail. On Fri, Jan 12, 2018 at 10:29:14AM +0000, Luke Kenneth Casson Leighton wrote: [...] > > * If the CPU card spontaneously resets without first bringing the > > housing into a state where it tolerates early debug output > > (some housings might require such preparation before shutdown). > > exactly. and that is far too complicated. right now there is *zero* > need - at all - for *any* kind of complexity on the Housings. the > Micro-Desktop is.... it's just a bunch of connectors. as in, that's > *all* that's needed. I wasn't aware housings tend to be *this* simple. > > Here's a *completely different* and significantly simpler proposal, > > which also fulfills these goals. You probably won't like it because > > (a) it takes away a pin from general purpose use, (b) it breaks > > compatibility [see footnote 1] with current hardware. > > > > Replace one of the GPIO pins (such as pin 21, GPIO 20) with a single- > > purpose Debug UART TX pin, where the CPU card may print debug messages > > in 8N1 format. Debug UART TX high/low is measured against VREFTTL. > > nope. not enough pins. you're thinking in terms of prioritising > "Technical End-User" over "End-User". > > the volume of sales to "End User" is intended to be HUNDREDS OF MILLIONS. > > the volume of sales to "Technical End User" is expected to measure in > the thousands. Ok, makes sense. That's a valid design point. Thanks, Jonathan Neuschäfer From j.neuschaefer at gmx.net Wed Jan 17 00:31:22 2018 From: j.neuschaefer at gmx.net (Jonathan =?utf-8?Q?Neusch=C3=A4fer?=) Date: Wed, 17 Jan 2018 01:31:22 +0100 Subject: [Arm-netbook] Early UART output vs. housing board discovery In-Reply-To: <20180109222257.e5akm3qygves2dji@latitude> References: <20180109222257.e5akm3qygves2dji@latitude> Message-ID: <20180117003122.eacqqfh6p6iyvrbl@latitude> Ok, back to the question of how to improve the standard and reduce ambiguity. On Tue, Jan 09, 2018 at 11:22:57PM +0100, Jonathan Neuschäfer wrote: > Hi, > > what follows are a few questions/remarks/misunderstandings regarding the > UART pins during early boot. > > In the EOMA68 specification, the section "Start-up procedure"[1] > specifies that "It is required that all pins be disabled (floating > tri-state) with the exception of the I2C Bus, the 5.0v Power and the > Ground Pins.", which would mean that *any software* running on a CPU > card is required to check the housing board's EEPROM before it may > output any data on the UART, if I read it correctly. No need to change this, because it's correct. > The section "Requirements for UART"[2], however, states: "As this > problem is to be taken care of on the I/O Board[3] it is worth observing > that CPU Cards do not require UART buffering.", suggesting that the > "Start-up procedure" section simply left out UART as one of the > interfaces that do not need to be tri-stated by mistake. > > But I am unclear about the part "CPU Cards do not require UART buffering": > - Does it mean that CPU cards do not require the housing board to > perform UART buffering, because they do it themselves? > - Or does it mean that CPU cards are not required to perform UART > buffering? I suggest changing this passage: "As this problem is to be taken care of on the I/O Board it is worth observing that CPU Cards do not require UART buffering. They may however require level shifting:" To this: "As this problem is to be taken care of on the Housing Board it is worth observing that CPU Cards don't need to perform UART buffering. They may however need to perform level shifting:" ... or something like that. Furthermore, it would be useful if the diagram below that had labels for the CPU Card and the Housing board (*). Older versions of the diagram show that the circuit on the left is part of the Housing and the box on the right is the CPU Card, but it's not instantaneously obvious in the current version. (*) https://elinux.org/File:EOMA68-UART-RX-PROTECT.gif > [1]: https://elinux.org/Embedded_Open_Modular_Architecture/EOMA68/Hardware#Start-up_procedure > [2]: https://elinux.org/Embedded_Open_Modular_Architecture/EOMA68/Hardware#Requirements_for_UART > [3]: As a side-note, the term "I/O Board" is a little bit unclear to me: > Both CPU cards/boards and housing boards perform I/O. I figured > that "I/O board" means "housing board", but I (personally) think > the spec would be clearer if it talked about "housings" or "housing > boards" in the first place. What do you (LKCL) think about changing all instances of "I/O board" in the standard to "housing board", or perhaps "Housing Board", to reflect that Housing is defined in the terms section? (Unfortunately this won't be as easy as "sed" and "git commit", because the EOMA68 standard isn't maintained in Git :/.) Thanks, Jonathan Neuschäfer From lkcl at lkcl.net Wed Jan 17 05:17:24 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 17 Jan 2018 05:17:24 +0000 Subject: [Arm-netbook] Early UART output vs. housing board discovery In-Reply-To: <20180116223408.uumafiiindpbakhh@latitude> References: <20180109222257.e5akm3qygves2dji@latitude> <20180110134402.d6cyfzmscicglt6q@latitude> <20180110161135.lbu5eafqvcasrrnc@latitude> <20180111215038.pyki3h64mkt2gba3@latitude> <20180116223408.uumafiiindpbakhh@latitude> Message-ID: On Tue, Jan 16, 2018 at 10:34 PM, Jonathan Neuschäfer wrote: > Thanks for your explanations. That's all I really have to say after that > mail. ok cool. >> Micro-Desktop is.... it's just a bunch of connectors. as in, that's >> *all* that's needed. > > I wasn't aware housings tend to be *this* simple. yehyeh - the phrase is "passive components" or something... not sure which. the laptop pcb, microdesktop, tablet and the router, they're all basically nothing more than a power converter, current-limiting chip, an EEPROM and some connectors. for the video output the only minor "complication" is the inclusion of - again "passive conversion" circuits. an SN75LVDS83b or 6-bit A->D circuits for VGA. l. From lkcl at lkcl.net Wed Jan 17 05:52:50 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 17 Jan 2018 05:52:50 +0000 Subject: [Arm-netbook] Early UART output vs. housing board discovery In-Reply-To: <20180117003122.eacqqfh6p6iyvrbl@latitude> References: <20180109222257.e5akm3qygves2dji@latitude> <20180117003122.eacqqfh6p6iyvrbl@latitude> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Wed, Jan 17, 2018 at 12:31 AM, Jonathan Neuschäfer wrote: > Ok, back to the question of how to improve the standard and reduce > ambiguity. > > On Tue, Jan 09, 2018 at 11:22:57PM +0100, Jonathan Neuschäfer wrote: >> Hi, >> >> what follows are a few questions/remarks/misunderstandings regarding the >> UART pins during early boot. >> >> In the EOMA68 specification, the section "Start-up procedure"[1] >> specifies that "It is required that all pins be disabled (floating >> tri-state) with the exception of the I2C Bus, the 5.0v Power and the >> Ground Pins.", which would mean that *any software* running on a CPU >> card is required to check the housing board's EEPROM before it may >> output any data on the UART, if I read it correctly. > > No need to change this, because it's correct. > >> The section "Requirements for UART"[2], however, states: "As this >> problem is to be taken care of on the I/O Board[3] it is worth observing >> that CPU Cards do not require UART buffering.", suggesting that the >> "Start-up procedure" section simply left out UART as one of the >> interfaces that do not need to be tri-stated by mistake. >> >> But I am unclear about the part "CPU Cards do not require UART buffering": >> - Does it mean that CPU cards do not require the housing board to >> perform UART buffering, because they do it themselves? >> - Or does it mean that CPU cards are not required to perform UART >> buffering? > > I suggest changing this passage: > > "As this problem is to be taken care of on the I/O Board it is > worth observing that CPU Cards do not require UART buffering. > They may however require level shifting:" > > To this: > > "As this problem is to be taken care of on the Housing Board it > is worth observing that CPU Cards don't need to perform UART > buffering. They may however need to perform level shifting:" > > ... or something like that. yehyeh, I/O Board was an older phrase. i clarified that the level shifting is to take place on the Housing. also, i have set a grammatical rule (important for a standard, for clarity) never to use contractions "don't, they're, it's". > Furthermore, it would be useful if the diagram below that had labels for > the CPU Card and the Housing board (*). the level-shifting circuits are all solely and exclusively for Housings. it is absolutely imperative that all signals on the CPU Card be relative to VREFTTL and that VREFTTL be generated by the SoC. this is absolutely critical so as to ensure that the SoC is not damaged by over-voltage. > Older versions of the diagram > show that the circuit on the left is part of the Housing and the box on > the right is the CPU Card, but it's not instantaneously obvious in the > current version. ok - someone else did those diagrams. Housing is always on the left, CPU Card is always on the right. the use of the diodes is an interesting one, it results in current-sinking and only works because UART is "Open Drain" not CMOS. it took a while to understand. > What do you (LKCL) think about changing all instances of "I/O board" in > the standard to "housing board", or perhaps "Housing Board", to reflect > that Housing is defined in the terms section? yep it was an older term, changed about... 2-3 years ago. > (Unfortunately this won't be as easy as "sed" and "git commit", because > the EOMA68 standard isn't maintained in Git :/.) i knoooow, it was a decision a long time ago, to keep the standard on an independent third party "open" site. pain in the neck not having it in git. still, a good-old-fashioned cut/paste jobbie would do the trick :) l. From mikejackofalltrades at gmail.com Wed Jan 17 06:12:28 2018 From: mikejackofalltrades at gmail.com (Mike Henry) Date: Tue, 16 Jan 2018 23:12:28 -0700 Subject: [Arm-netbook] Early UART output vs. housing board discovery In-Reply-To: References: <20180109222257.e5akm3qygves2dji@latitude> <20180117003122.eacqqfh6p6iyvrbl@latitude> Message-ID: >> (Unfortunately this won't be as easy as "sed" and "git commit", because >> the EOMA68 standard isn't maintained in Git :/.) > > i knoooow, it was a decision a long time ago, to keep the standard on > an independent third party "open" site. pain in the neck not having > it in git. still, a good-old-fashioned cut/paste jobbie would do the > trick :) It would require some work to migrate the site, but gitlab is open source, free, and can host static pages. From lkcl at lkcl.net Wed Jan 17 06:18:00 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 17 Jan 2018 06:18:00 +0000 Subject: [Arm-netbook] Early UART output vs. housing board discovery In-Reply-To: References: <20180109222257.e5akm3qygves2dji@latitude> <20180117003122.eacqqfh6p6iyvrbl@latitude> Message-ID: On Wed, Jan 17, 2018 at 6:12 AM, Mike Henry wrote: > It would require some work to migrate the site, but gitlab > is open source, free, and can host static pages. it's ok, mike - i run my own git repository servers, the main thing is, an automated conversion / updating system would be needed... that in turn means a lot _more_ work... unless the standard was moved over to ikiwiki (which means conversion to markdown)... whatever is done it means quite a bit of work and in the process the "independent" use of an impartial and independent *relevant* site - elinux.org - would be lost in the process. the only two things which would warrant i think some work would be (a) a backup mechanism and (b) hosting - finally - on eoma68.com l. From lkcl at lkcl.net Wed Jan 17 10:28:15 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 17 Jan 2018 10:28:15 +0000 Subject: [Arm-netbook] RK3399 Message-ID: thank you very much to the anonymous person who pointed me at a *FULL* Rockchip RK3399 Reference Design including Technical Reference Manuals, full schematic file and full PCB CAD design files. using that design it will be possible to create an amazing CPU Card... unfortunately running MALI. http://rockchip.wikidot.com/rk3399 this shows that it has USB3 however it does not have RGB/TTL, so it will be necessary to do a conversion from MIPI to RGB/TTL with an SSD2828 or similar. the Reference Design has twin 32-bit-wide LPDDR3 ICs so there is the possibility of getting not just decent performance but also low power at the same time. l. From lkcl at lkcl.net Wed Jan 17 11:41:03 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 17 Jan 2018 11:41:03 +0000 Subject: [Arm-netbook] HDMI High-Frequency Layout: Recommendations In-Reply-To: References: <04496B4C-7BB6-4619-804C-C0296761F558@gmail.com> <0620D014-55E0-41C1-9CBF-B671898D7187@gmail.com> <110EC969-7221-42CE-9B54-F6D658E8BC90@gmail.com> <61C5A163-9A5C-4BD4-8DE6-65A418082907@gmail.com> <8A03534C-A3F6-4689-98FA-C4DD6CF465E2@gmail.com> <4E311CA5-D091-4E6B-8CD7-82F8DC7ECBD1@gmail.com> <544AD58E-3E36-411F-B75D-F49D08AD677B@gmail.com> <72396096-4F21-4668-877C-112A19194EB0@gmail.com> <9CEB80E3-5172-41E2-BECC-FE5551E070FE@gmail.com> <6DA57CDA-F7CC-42BF-B69C-0245D61F3E07@gmail.com> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Tue, Jan 16, 2018 at 9:06 PM, Richard Wilbur wrote: >> The goal is to avoid unnecessarily impeding this return current path. >> I'm trying to avoid making the path >~200mil and putting any major >> obstruction (like a huge layer void) in the way. > > While browsing the A20 datasheet, I found that the HDMI section does > have a power pin but not labelled the way I was asking you about. ah ok > Page 18 mentions that VCC-HDMI is a power pin on ball #T13. On the > schematic it is connected to net HVP which has power decoupling > capacitor C108 which looks like "104" => 0.1uF. yep. and a VIA to the other side (BOTTOM) C108 is about as close as you can possibly get > Looks like the path from the copper on layer 2 below the HDMI pins > (balls #TUVW 22,23) on the SoC (processor) to the VCC-HDMI power pin > (#T13) is ~300mil. It doesn't look overly impeded. yehh it seems to work fine, on this design and on other boards. l. From gacuest at gmail.com Wed Jan 17 12:08:38 2018 From: gacuest at gmail.com (Miguel Garcia) Date: Wed, 17 Jan 2018 13:08:38 +0100 Subject: [Arm-netbook] RK3399 In-Reply-To: References: Message-ID: 2018-01-17 11:28 GMT+01:00 Luke Kenneth Casson Leighton : > this shows that it has USB3 however it does not have RGB/TTL, so it > will be necessary to do a conversion from MIPI to RGB/TTL with an > SSD2828 or similar. Could you design an EOMA68+ with a different pinout? For example, the EOMA68 for less powerful devices, and an EOMA68+ for more powerful devices. For example, the EOMA68+ would have support for MIPI (instead of RGB), mandatory use of USB 3.0, etc. For example, I think that an Allwiner A20 or an Ingenic SoC does not make sense on a FullHD screen, and an Rk3399 does not make much sense on a 320x240 screen. From lkcl at lkcl.net Wed Jan 17 12:13:52 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 17 Jan 2018 12:13:52 +0000 Subject: [Arm-netbook] Early UART output vs. housing board discovery In-Reply-To: <20180110161135.lbu5eafqvcasrrnc@latitude> References: <20180109222257.e5akm3qygves2dji@latitude> <20180110134402.d6cyfzmscicglt6q@latitude> <20180110161135.lbu5eafqvcasrrnc@latitude> Message-ID: ok so i made a set of changes, replaced "I/O Board" with "Housing" everywhere, and updated the text as you suggest, jonathon. no on the contraction though. also added sentence (repeated) about UART level-shifting diagrams. From lkcl at lkcl.net Wed Jan 17 13:48:16 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 17 Jan 2018 13:48:16 +0000 Subject: [Arm-netbook] RK3399 In-Reply-To: References: Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Wed, Jan 17, 2018 at 12:08 PM, Miguel Garcia wrote: > 2018-01-17 11:28 GMT+01:00 Luke Kenneth Casson Leighton : >> this shows that it has USB3 however it does not have RGB/TTL, so it >> will be necessary to do a conversion from MIPI to RGB/TTL with an >> SSD2828 or similar. > > Could you design an EOMA68+ with a different pinout? the absolute absolute top priority is that there be absolutely NO chance - whatsoever - of confusion in the eyes of a hundred MILLION and above totally non-technical end-users. if there is any chance that two Cards with different pinouts could be plugged into the same socket if there is any chance that the owner of two Housings does not know if a Card is safe to plug in then the answer to the question you ask is NO. if however there is a way that the exact same connector could be used... *WITHOUT* there being a SHADOW OF DOUBT... then yes. what would you suggest, that could fit within that absolutely critical constraint? > For example, the EOMA68 for less powerful devices, and an EOMA68+ > for more powerful devices. For example, the EOMA68+ would have > support for MIPI (instead of RGB), mandatory use of USB 3.0, etc. > > For example, I think that an Allwiner A20 or an Ingenic SoC does not > make sense on a FullHD screen, and an Rk3399 does not make > much sense on a 320x240 screen. that's not.... within the "right" of EOMA68 to say to people "You Cannot Use An RK3399 Card for purpose X". should it be dictated that users MUST not plug Cards in just because we *happen* to think that there *might* not be *some* perfectly legitimate use-case which *right now* we cannot envisage? that would result in confusion in the standard, wouldn't it? l. From j.neuschaefer at gmx.net Wed Jan 17 14:47:23 2018 From: j.neuschaefer at gmx.net (Jonathan =?utf-8?Q?Neusch=C3=A4fer?=) Date: Wed, 17 Jan 2018 15:47:23 +0100 Subject: [Arm-netbook] Early UART output vs. housing board discovery In-Reply-To: References: <20180109222257.e5akm3qygves2dji@latitude> <20180117003122.eacqqfh6p6iyvrbl@latitude> Message-ID: <20180117144723.vgatvhmldarway2a@latitude> Hi, On Wed, Jan 17, 2018 at 05:52:50AM +0000, Luke Kenneth Casson Leighton wrote: > On Wed, Jan 17, 2018 at 12:31 AM, Jonathan Neuschäfer wrote: [...] > > I suggest changing this passage: > > > > "As this problem is to be taken care of on the I/O Board it is > > worth observing that CPU Cards do not require UART buffering. > > They may however require level shifting:" > > > > To this: > > > > "As this problem is to be taken care of on the Housing Board it > > is worth observing that CPU Cards don't need to perform UART > > buffering. They may however need to perform level shifting:" > > > > ... or something like that. > > yehyeh, I/O Board was an older phrase. i clarified that the level > shifting is to take place on the Housing. also, i have set a > grammatical rule (important for a standard, for clarity) never to use > contractions "don't, they're, it's". Ok, let me try again, without these less important differences: "As this problem is to be taken care of on the I/O Board it is worth observing that CPU Cards do not need to perform UART buffering. They may however need to perform level shifting:" Thanks, Jonathan Neuschäfer From j.neuschaefer at gmx.net Wed Jan 17 14:48:34 2018 From: j.neuschaefer at gmx.net (Jonathan =?utf-8?Q?Neusch=C3=A4fer?=) Date: Wed, 17 Jan 2018 15:48:34 +0100 Subject: [Arm-netbook] Early UART output vs. housing board discovery In-Reply-To: References: <20180109222257.e5akm3qygves2dji@latitude> <20180110134402.d6cyfzmscicglt6q@latitude> <20180110161135.lbu5eafqvcasrrnc@latitude> Message-ID: <20180117144834.lni7z2d7jnuepfxj@latitude> On Wed, Jan 17, 2018 at 12:13:52PM +0000, Luke Kenneth Casson Leighton wrote: > ok so i made a set of changes, replaced "I/O Board" with "Housing" > everywhere, and updated the text as you suggest, jonathon. no on the > contraction though. also added sentence (repeated) about UART > level-shifting diagrams. Thanks! From lkcl at lkcl.net Wed Jan 17 16:04:01 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 17 Jan 2018 16:04:01 +0000 Subject: [Arm-netbook] Early UART output vs. housing board discovery In-Reply-To: <20180117144723.vgatvhmldarway2a@latitude> References: <20180109222257.e5akm3qygves2dji@latitude> <20180117003122.eacqqfh6p6iyvrbl@latitude> <20180117144723.vgatvhmldarway2a@latitude> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Wed, Jan 17, 2018 at 2:47 PM, Jonathan Neuschäfer wrote: > Ok, let me try again, without these less important differences: > > "As this problem is to be taken care of on the I/O Board it > is worth observing that CPU Cards do not need to perform UART > buffering. They may however need to perform level shifting:" As this problem is to be taken care of on the Housing it is worth observing that CPU Cards do not need to perform UART buffering (as this would interfere with their potential use as GPIO lines). i realised that the reason *why* you don't level-shift on the Card was not mentioned. l. From calmstorm at posteo.de Wed Jan 17 19:49:12 2018 From: calmstorm at posteo.de (zap) Date: Wed, 17 Jan 2018 14:49:12 -0500 Subject: [Arm-netbook] RK3399 In-Reply-To: References: Message-ID: On 01/17/2018 05:28 AM, Luke Kenneth Casson Leighton wrote: > thank you very much to the anonymous person who pointed me at a *FULL* > Rockchip RK3399 Reference Design including Technical Reference > Manuals, full schematic file and full PCB CAD design files. > > using that design it will be possible to create an amazing CPU Card... > unfortunately running MALI. > > http://rockchip.wikidot.com/rk3399 Is it possible to remove the mali from the configuration or to use the rk3399 in a libre fashion? I am just curious. And if not, can you make it work? From lkcl at lkcl.net Wed Jan 17 20:26:32 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 17 Jan 2018 20:26:32 +0000 Subject: [Arm-netbook] RK3399 In-Reply-To: References: Message-ID: On Wed, Jan 17, 2018 at 7:49 PM, zap wrote: > Is it possible to remove the mali from the configuration of course, it's just a co-processor on the same internal shared memory bus - don't enable it, don't talk to it, don't compile the kernel config, don't run the proprietary userspace library > or to use the rk3399 in a libre fashion? probably not, it's one of the high-end T-blahblah ones > I am just curious. And if not, can you make it work? with probably about 18 months of full-time reverse-engineering, probably. but i've f*****g had it with ARM, the blatantly unethical f***s, trying to bribe people to shut down projects, and blackmailing companies to not pay software libre developers. so f*** 'em. l. From calmstorm at posteo.de Wed Jan 17 22:25:33 2018 From: calmstorm at posteo.de (zap) Date: Wed, 17 Jan 2018 17:25:33 -0500 Subject: [Arm-netbook] RK3399 In-Reply-To: References: Message-ID: <210f98ef-492b-d3ec-4508-ab1e859069ba@posteo.de> > with probably about 18 months of full-time reverse-engineering, > probably. but i've f*****g had it with ARM, the blatantly unethical > f***s, trying to bribe people to shut down projects, and blackmailing > companies to not pay software libre developers. > > so f*** 'em. I don't disagree, I just wondered if it was possible in the near future. Since its not, yeah... I guess we wait for something better. To arrive. such as Shakti processors right? :) > > 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 Wed Jan 17 22:36:10 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 17 Jan 2018 22:36:10 +0000 Subject: [Arm-netbook] RK3399 In-Reply-To: <210f98ef-492b-d3ec-4508-ab1e859069ba@posteo.de> References: <210f98ef-492b-d3ec-4508-ab1e859069ba@posteo.de> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Wed, Jan 17, 2018 at 10:25 PM, zap wrote: > >> with probably about 18 months of full-time reverse-engineering, >> probably. but i've f*****g had it with ARM, the blatantly unethical >> f***s, trying to bribe people to shut down projects, and blackmailing >> companies to not pay software libre developers. >> >> so f*** 'em. > I don't disagree, I just wondered if it was possible in the near future. > Since its not, yeah... if i start now it'll be about... 3 months and it'll cost about $2000 per set of 10 boards to test. > I guess we wait for something better. To arrive. such as Shakti > processors right? :) 18 months on that... but yeah. talking to jeff who did nyuzi, to see what it would take to at least get 25% the performance of MALI 400. nyuzi is a software-driven general-purpose compute engine that "happens to be reasonably good at 3D". based on some research work by intel. l. From ronwirring at Safe-mail.net Thu Jan 18 16:06:20 2018 From: ronwirring at Safe-mail.net (ronwirring at Safe-mail.net) Date: Thu, 18 Jan 2018 11:06:20 -0500 Subject: [Arm-netbook] RK3399 Message-ID: -------- Original Message -------- From: Luke Kenneth Casson Leighton Apparently from: arm-netbook-bounces at lists.phcomp.co.uk To: Eco-Conscious Computing Subject: Re: [Arm-netbook] RK3399 Date: Wed, 17 Jan 2018 20:26:32 +0000 > use the rk3399 in a libre fashion? Can you make a fsf compliant notebook based on the rk3399 mainboards I have seen for sale? All libre software is available except the gpu one? > 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 Thu Jan 18 16:17:18 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 18 Jan 2018 16:17:18 +0000 Subject: [Arm-netbook] RK3399 In-Reply-To: References: Message-ID: On Thu, Jan 18, 2018 at 4:06 PM, wrote: >> use the rk3399 in a libre fashion? > > Can you make a fsf compliant notebook based on the rk3399 > mainboards I have seen for sale? sure... i will however need sponsorship to cover the cost in time and also the parts, to do so - estimated about... a year, plus PCB prototypes, so around USD $25,000. l. From ronwirring at Safe-mail.net Thu Jan 18 16:35:23 2018 From: ronwirring at Safe-mail.net (ronwirring at Safe-mail.net) Date: Thu, 18 Jan 2018 11:35:23 -0500 Subject: [Arm-netbook] RK3399 Message-ID: -------- Original Message -------- From: Luke Kenneth Casson Leighton Apparently from: arm-netbook-bounces at lists.phcomp.co.uk To: Eco-Conscious Computing Subject: Re: [Arm-netbook] RK3399 Date: Thu, 18 Jan 2018 16:17:18 +0000 > sure... i will however need sponsorship to cover the cost in time and My phrasing was unclear. My question was not about an eoma pc card. For sale are rk3399 mainboards. I wanted to know if you could take one of them and put it into a common notebook cabinet and get the computer to work, assuming you are able to get the computer's devices connected. > 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 Thu Jan 18 16:58:55 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 18 Jan 2018 16:58:55 +0000 Subject: [Arm-netbook] RK3399 In-Reply-To: References: Message-ID: On Thu, Jan 18, 2018 at 4:35 PM, wrote: > -------- Original Message -------- > From: Luke Kenneth Casson Leighton > Apparently from: arm-netbook-bounces at lists.phcomp.co.uk > To: Eco-Conscious Computing > Subject: Re: [Arm-netbook] RK3399 > Date: Thu, 18 Jan 2018 16:17:18 +0000 > > >> sure... i will however need sponsorship to cover the cost in time and > > My phrasing was unclear. > My question was not about an eoma pc card. For sale are rk3399 > mainboards. I wanted to know if you could take one of them > and put it into a common notebook cabinet and get the > computer to work, assuming you are able to get the computer's > devices connected. no. it is a vast amount of work. the LCD has to be researched (if its datasheet is even available). a conversion circuit has to be designed and manufactuered.... and before that it is necesssary to work out if there is room for it. the keyboard hsa to be reverse-engineered the trackpad has to be reverse-engineered the connectors have to be researched (heights, sizes), PCB heights measured.... or you have to cut holes in the casework to get the PCB to fit. the battery has to be researched and reverse-engineered, paying attention to safety as you could set fire to it if you get it wrong. it is a MASSIVE amount of work, at the end of which you generally conclude, "what the f*** did i waste my life doing THAT for???" because all you have done is make ONE machine.... that took you hours to take apart (google "Bloom Laptop") because it was designed for ASSEMBLY *not* for REPAIR or DISassembly. no. re-using or converting existing designs is a total waste of time and resources. l. From desttinghimgame at gmail.com Thu Jan 18 17:07:15 2018 From: desttinghimgame at gmail.com (Louis Pearson) Date: Thu, 18 Jan 2018 11:07:15 -0600 Subject: [Arm-netbook] RK3399 In-Reply-To: References: Message-ID: On a slightly different topic, how much would it take for you to design a eoma68 compliant netbook housing? I was interested in the laptop, but it was (and still is) outside of my budget. Do you think you could make a netbook housing that is more budget friendly, or are there too many unknowns for you to say? From laserhawk64 at gmail.com Thu Jan 18 17:07:30 2018 From: laserhawk64 at gmail.com (Christopher Havel) Date: Thu, 18 Jan 2018 12:07:30 -0500 Subject: [Arm-netbook] RK3399 In-Reply-To: References: Message-ID: Not to mention that, at least in terms of hardware, there's very little that's standard about laptops, ever -- the display protocol, sort of maybe, and the drives, and that's about it. There;'s a reason those machines tend to go together and come apart like a jigsaw puzzle without the box! From lkcl at lkcl.net Thu Jan 18 18:57:49 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 18 Jan 2018 18:57:49 +0000 Subject: [Arm-netbook] RK3399 In-Reply-To: References: Message-ID: On Thu, Jan 18, 2018 at 5:07 PM, Louis Pearson wrote: > On a slightly different topic, how much would it take for you to design a > eoma68 compliant netbook housing? it'd be about the same amount of time as the laptop (about 18 months) as there is almost nothing in common that can be utilised between the two, with the possible exception of some of the libraries used in the 3D CAD design. specific components that would need to be researched are: * keyboard and securing a guaranteed supply of the same * trackpad and securing a guaranteed supply of the same * battery and securing a guaranteed supply of the same each of these - on their own - will require contacting a hundred to two hundred separate suppliers, each of whom will demand, "who are you, are you real, are you one of our competitors fishing for information, are you a waste of our time, are you going to order 50,000 units because otherwise we're wasting the factory's time" and so on. it's *extremely* complex basically and NOTHING that was done in the 15in laptop can be re-used. at all. > I was interested in the laptop, but it was (and > still is) > outside of my budget. Do you think you could make a netbook housing that is > more > budget friendly, or are there too many unknowns for you to say? having done several now i know pretty much exactly how long it will take, that's not the main problem. the main problem is, you have to find a sponsor willing to pay my time to do it, and at the end of all that, you then have to have a crowd-funding campaign where a minimum of 250 preferably 1000 preferably 10,000 people *actually want one*. l. From lkcl at lkcl.net Thu Jan 18 19:03:19 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 18 Jan 2018 19:03:19 +0000 Subject: [Arm-netbook] http://www.emff.urjc.es/members/arrayas_files/Articles/PhysRep.pdf Message-ID: hi theo, been talking to the mathematician behind that paper on knots, he explained that the "null condition" is where the EM field is... zero, and that the E is perpendicular to M at all points. it's not the same thing as the "non-radiating condition" for which you have to take a fourier transform. he sent a link to the above paper which he said may have some clues about non-radiating conditions. l. From richard.wilbur at gmail.com Thu Jan 18 22:11:47 2018 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Thu, 18 Jan 2018 15:11:47 -0700 Subject: [Arm-netbook] Testing: GPIO Message-ID: After looking at the schematics for the DS113 v2.7 2017-02-17 and the microdesktop v1.7 I feel the need to ask whether there are more up-to-date schematics available? Results of my sleuthing thus far attached. -------------- next part -------------- GPIO (General Purpose Input / Output) DS113 Schematic v2.7 2017-02-17 page 3, lists PA(18) with PA7-PA16 used as GPIO. PA7 ETXD0 PA8 ERXCK PA9 ERXERR PA10 ERXDV PA11 EMDC PA12 EMDIO PA13 ETXEN PA14 ETXCK PA15 ECRS PA16 ECOL Datasheet page 13, lists these all as Type = I/O, Reset State = Z, Default Pull Up/Down = NO PULL, Buffer Strength (mA) = 20 Ball # PA7 ETXD0 E8 PA8 ERXCK D9 PA9 ERXERR E9 PA10 ERXDV D10 PA11 EMDC E10 PA12 EMDIO D11 PA13 ETXEN E11 PA14 ETXCK D12 PA15 ECRS E12 PA16 ECOL D13 DS113 Schematic page 6, shows the U1-C pins for PA7-PA16 connected to the signals ethernet signals listed above. But DS113 Schematic page 13, which shows the 68-pin connector CON15, doesn’t mention any of these signals and has at least 8 pins named “NC”? The microdesktop housing board schematic v1.7 page 1 shows the 68-pin connector as J14 with pins labelled as PIN# Name Connected Net 16 GPIO_0 SD0-D3 50 GPIO_1 SD0-D2 17 GPIO_2 VESA_SDA 51 GPIO_3 GPIO_3 18 GPIO_4 SD0-CMD 52 GPIO_5 SD0-CLK 19 GPIO_6 SD0-D0 53 GPIO_7 SD0-D1 20 GPIO_8 54 GPIO_9 21 GPIO_10 55 GPIO_11 22 GPIO_12 VESA_SCL I haven’t yet found an equivalence mapping between the pinouts of the two 68-pin connectors of the two schematics. From lkcl at lkcl.net Thu Jan 18 23:37:00 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 18 Jan 2018 23:37:00 +0000 Subject: [Arm-netbook] Testing: GPIO In-Reply-To: References: Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Thu, Jan 18, 2018 at 10:11 PM, Richard Wilbur wrote: > After looking at the schematics for the DS113 v2.7 2017-02-17 and the > microdesktop v1.7 I feel the need to ask whether there are more > up-to-date schematics available? nnope. that's it. > Results of my sleuthing thus far attached. i'll have to double-check it. at least 8 pins are NC because they're allocated to USB3. the EOMA68 spec page on pinouts is absolute authoritative. l. From vkontogpls at gmail.com Fri Jan 19 02:35:32 2018 From: vkontogpls at gmail.com (Bill Kontos) Date: Fri, 19 Jan 2018 04:35:32 +0200 Subject: [Arm-netbook] RK3399 In-Reply-To: References: Message-ID: On Thu, Jan 18, 2018 at 6:58 PM, Luke Kenneth Casson Leighton wrote: > no. > > it is a vast amount of work. the LCD has to be researched (if its > datasheet is even available). a conversion circuit has to be designed > and manufactuered.... and before that it is necesssary to work out if > there is room for it. > > the keyboard hsa to be reverse-engineered > > the trackpad has to be reverse-engineered > > the connectors have to be researched (heights, sizes), PCB heights > measured.... or you have to cut holes in the casework to get the PCB > to fit. > > the battery has to be researched and reverse-engineered, paying > attention to safety as you could set fire to it if you get it wrong. > What if the laptop in question has coreboot support? From laserhawk64 at gmail.com Fri Jan 19 02:57:03 2018 From: laserhawk64 at gmail.com (Christopher Havel) Date: Thu, 18 Jan 2018 21:57:03 -0500 Subject: [Arm-netbook] RK3399 In-Reply-To: References: Message-ID: Forgive a top-post, please, Luke - I'm on my phone. Coreboot, IIRC, is a replacement for BIOS/UEFI. So if you have the original system's motherboard intact - in which case you cannot drop in the chip you want to drop in - you can replace the contents of what is essentially the boot ROM chip with coreboot. That's as far as that goes... In case you do not understand what BIOS and UEFI are, read on... When a computer is first turned on, the CPU automatically copies the contents of the BIOS (or UEFI) into RAM, which is called 'shadowing' the ROM. It then jumps to a specific address, hard-coded into the CPU, to start execution of part of those instructions. For the record, historical processors typically started either at 0x0000, assuming a 16b address bus, or at 0xFFFF. The 8086 and 8088 did something different, and I forget now what that address was, but it was in the middle somewhere, IIRC. *ahem* The code executed at boot is enough to test how much RAM is present and functional, and to bring up various parts and pieces of the system so that it can function cohesively and coherently. Hard drive interfaces and accessing. Some sort of display function for output. Keyboard and mouse interfaces. *Et cetera*. Once this is complete, and a limited 'sanity test' (POST, the Power On Self Test) is executed, the BIOS (UEFI) code loads the OS bootloader into RAM and begins executing that - whether it's GRUB or NTLDR, that is the part where the OS begins to take over. The bootloader pulls up the kernel and whatever init program is present, and away you go. ...all that to say that coreboot basically can't help you here, because all of that is what coreboot duplicates, and that's *all* it does. Sorry for the long yarn of explication, but I wanted to be thorough. My hand hurts now, though, so "here endeth the lesson", as my mother often says :) On Jan 18, 2018 9:35 PM, "Bill Kontos" wrote: > On Thu, Jan 18, 2018 at 6:58 PM, Luke Kenneth Casson Leighton > wrote: > > > no. > > > > it is a vast amount of work. the LCD has to be researched (if its > > datasheet is even available). a conversion circuit has to be designed > > and manufactuered.... and before that it is necesssary to work out if > > there is room for it. > > > > the keyboard hsa to be reverse-engineered > > > > the trackpad has to be reverse-engineered > > > > the connectors have to be researched (heights, sizes), PCB heights > > measured.... or you have to cut holes in the casework to get the PCB > > to fit. > > > > the battery has to be researched and reverse-engineered, paying > > attention to safety as you could set fire to it if you get it wrong. > > > > What if the laptop in question has coreboot support? > > _______________________________________________ > 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 calmstorm at posteo.de Fri Jan 19 03:17:27 2018 From: calmstorm at posteo.de (zap) Date: Thu, 18 Jan 2018 22:17:27 -0500 Subject: [Arm-netbook] RK3399 In-Reply-To: References: Message-ID: >> I was interested in the laptop, but it was (and >> still is) >> outside of my budget. Do you think you could make a netbook housing that is >> more >> budget friendly, or are there too many unknowns for you to say? > having done several now i know pretty much exactly how long it will > take, that's not the main problem. the main problem is, you have to > find a sponsor willing to pay my time to do it, and at the end of all > that, you then have to have a crowd-funding campaign where a minimum > of 250 preferably 1000 preferably 10,000 people *actually want one*. > > l. Looks like I am not the only person interested in a netbook format.  :)  although, what you just said does pose a particular problem. Probably a lot more than I realize. > > _______________________________________________ > 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 laserhawk64 at gmail.com Fri Jan 19 03:24:06 2018 From: laserhawk64 at gmail.com (Christopher Havel) Date: Thu, 18 Jan 2018 22:24:06 -0500 Subject: [Arm-netbook] RK3399 In-Reply-To: References: Message-ID: Quick follow-up (this time from my netbook) -- the 8086 and 8088 have a 20b address bus, so the address range is 0x00000 to 0xFFFFF. Execution starts at location 0xFFFF0, according to the datasheet for the 8086 that I have on file. That *almost* makes sense if you only have 64k of memory in your system -- but a 20b address bus can support a full megabyte of memory -- and the 8086/8088 addresses memory and I/O separately, unlike eg the 6502 (a historical CPU, used in most Commodore and pre-Mac Apple computers -- in derivative forms, sometimes) where IO is mapped to specific memory addresses as a matter of course -- I'll let you decide which scheme is more efficient; personally I like the 6502's memory-mapped I/O, but that is indeed only one man's opinion... BTW -- the reason that I said "almost" above, is because the 8086/8088 chips execute 'up' from the start of ROM -- from 0xFFFF0 through to 0xFFFFF is the reserved area for the boot code, as opposed to (again) the 6502, which executes 'down' from 0xFFFF to... basically wherever it's told that ROM stops and I/O begins (it's RAM at the bottom, ROM at the top, and I/O in between, for that processor family). Conceivably, you could have a single jump instruction and address at the top of 64k of memory with the 8086/8088 CPUs, and put the boot code for your computer at the other end of that jump, but that's the only way to make that work with that amount of memory... ...but this is all low-level crap that you don't need to worry about unless you're actually building a computer from scratch (schematic diagram level) with an x86 CPU at the heart of it... in other words, for our purposes I've just spun another ball of fluff text. So I'll shut up. (Again.) From laserhawk64 at gmail.com Fri Jan 19 03:49:12 2018 From: laserhawk64 at gmail.com (Christopher Havel) Date: Thu, 18 Jan 2018 22:49:12 -0500 Subject: [Arm-netbook] RK3399 In-Reply-To: References: Message-ID: BTW -- not *everything* is nearly as complex as Luke would have you believe. Close, but not quite, and the two doozies more than make up for the easier bits... Keyboards are invariably a passive switch matrix (look it up if you don't know -- you should, it's worth your time) and not that hard to reverse-engineer if you have a couple to burn through with a multimeter and hook probes. It's a matter of an afternoon or two. Touchpads are almost always either USB or PS/2 and not some alien bull**** (relatively speaking) like I2C or SPI unless they're bullt into a desktop keyboard (I have seen this, particularly with wireless keyboard/mouse combos). You probably can find a datasheet for the 'pad's controller chip and that will give up the info on how it connects to the world. It's the screen and battery interfaces that are going to get you and get you good, time-wise and effort-wise. LCDs are *very very very* rarely VGA (a *very* few *very* old laptops did that) and are often either LVDS or (if in a nearly brand-new machine) eDP. Once in a particularly blue moon, you'll potentially find one that runs parallel RGBTTL as its interface (my mother had a cheap tablet with an SVGA [800x600] screen that was RGBTTL.) The problem with LVDS is that the spec excludes a standard pinout and leaves that to the manufacturers -- so you've got to basically get in there with an old-fashioned oscilloscope and poke around until you have an understanding of which pin does what -- not a simple task when there's forty or fifty pins on a connector! ...oh, and some will be logic-level (typically 5v but sometimes 3.3v or even 1.8v) and some will *ahem* not be logic-level but rather analog or differential signals, which is why a logic analyzer won't do you here -- you'll blow its input circuits sky high. (...which you *really* don't want because logic analyzers are expensive... at least, the *useful* ones are.) RGBTTL is easier -- you can use a logic analyzer for that, if the datasheet doesn't have the pinout (which it basically always does) -- but, again, there's not really a standard there as far as pinout is concerned, and you have a fiddly surface-mount connector with remarkably tiny pin pitch to deal with as well -- after all, if you can actually solder to a flexible PCB (which is what those cables always are) without ruining it, you have soldering skills of near-mythical level and I have a few projects for you to help me with :P ). The battery invariably runs SMBus (short for System Management Bus) for communications, which is an I2C variant -- not too bad to deal with -- except that, like LVDS, there's no standard pinout, and oh by the way you need a charging circuit as well as knowing the commands to send and receive over SMBus to make it charge, discharge, and read out its level. Hint: the industry standard name for the controller chip in the battery is 'fuel guage', oddly enough -- you'll likely need to find its datasheet (good luck!) to get the commands, unless you really want to blackbox a battery that can literally burn your house down if you don't handle it with kid gloves. (Seriously, look up lithium battery fires on YouTube. If that stuff doesn't scare the p*ss out of you, either you're one serious pyromaniac or you have no bladder.) If you can handle all of that, you can do *exactly* what you're looking for. Personally, I'd rather figure out a way to basically make a portable desktop from readily available components (which I've done three times now, actually) and make do with that. From lkcl at lkcl.net Fri Jan 19 07:56:56 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 19 Jan 2018 07:56:56 +0000 Subject: [Arm-netbook] RK3399 In-Reply-To: References: Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Fri, Jan 19, 2018 at 2:35 AM, Bill Kontos wrote: > What if the laptop in question has coreboot support? that helps identify some of the components and peripherals... but all of those peripherals wtith the exception of any "management" ICs actually built-in to say the battery will be discarded, won't they? so coreboot will have all these options which #define ICs... that are going to be chucked out into landfill. l. From vkontogpls at gmail.com Fri Jan 19 14:59:19 2018 From: vkontogpls at gmail.com (Bill Kontos) Date: Fri, 19 Jan 2018 16:59:19 +0200 Subject: [Arm-netbook] RK3399 In-Reply-To: References: Message-ID: On Fri, Jan 19, 2018 at 4:57 AM, Christopher Havel wrote: > Forgive a top-post, please, Luke - I'm on my phone. > > Coreboot, IIRC, is a replacement for BIOS/UEFI. So if you have the original > system's motherboard intact - in which case you cannot drop in the chip you > want to drop in - you can replace the contents of what is essentially the > boot ROM chip with coreboot. That's as far as that goes... > Ok so it doesn't really do that much on it's own. Got it, thanks. I was thinking more along the lines of old thinkpads which have a decent amount of reverse engineering done to them. Even the x230 has the keyboard layout reverse engineered by a sysadmin who wanted to soehorn the old 7 row on it. From lkcl at lkcl.net Fri Jan 19 15:04:46 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 19 Jan 2018 15:04:46 +0000 Subject: [Arm-netbook] RK3399 In-Reply-To: References: Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Fri, Jan 19, 2018 at 2:59 PM, Bill Kontos wrote: > On Fri, Jan 19, 2018 at 4:57 AM, Christopher Havel > wrote: >> Forgive a top-post, please, Luke - I'm on my phone. >> >> Coreboot, IIRC, is a replacement for BIOS/UEFI. So if you have the original >> system's motherboard intact - in which case you cannot drop in the chip you >> want to drop in - you can replace the contents of what is essentially the >> boot ROM chip with coreboot. That's as far as that goes... >> > > Ok so it doesn't really do that much on it's own. Got it, thanks. I > was thinking more along the lines of old thinkpads which have a decent > amount of reverse engineering done to them. Even the x230 has the > keyboard layout reverse engineered by a sysadmin who wanted to soehorn > the old 7 row on it. it's just not worth it and drives up the price of the second-hand thinkpads, and pisses everyone off who is selling them to libre conscious people as they can't make a business case for even bothering to buy and convert them to libreboot. l. From lkcl at lkcl.net Fri Jan 19 16:06:51 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 19 Jan 2018 16:06:51 +0000 Subject: [Arm-netbook] Libre RISC-V SoC Message-ID: ok so, from the anonymous benefactor (independent of the shakti team), the one who sponsored me with the zc706 FPGA developer board, he has just had an interesting meeting with MOSIS, and has confirmed that they have an LPDDR3 PHY, so in combination with the DDR3 *controller* that was developed and released by someone working at CERN, this would be the last major piece of the "interfaces" side of puzzle that, until then, blocked progress. so he asked, also, what would it take to get things ready within a year, to hand over the ASIC-based design to MOSIS, for them to turn it into an ASIC, and i said "a team of engineers would need to be paid for". he asked - and please note the question very carefully - "would USD 250,000 be enough?" to which i replied (genuinely) yes... if done carefully. software also has to be taken care of. please note: *that's as far as the conversation has gone so far*. it is still exciting, and the next phase would be to get a strong committment and then i can start finding people to do software bring-up and also develop the VLSI / VHDL which will put all this together - mostly that's glue logic for the interfaces (putting them onto a "Tile" interface if using the rocket-chip or BOOM architecture) but also designing a multiplexer GPIO bank. i'm also talking to jeff from nyuzi, he designed a software-driven "compute engine that happens to be reasonably good at 3D", the interesting bit being that he's focussed on working out which areas need performance improvements. this is something that's almost completely lacking in the published academic world... *because nobody in the academic world has designed and published a GPU!* we worked out that nyuzi is approximately 1/16th the speed of MALI400. roughly. although area-for-area it's quite hard to tell whether that's a fair assessment because you can't *get* die areas for MALI400 (anyone know anything better than these estimates? https://forum.beyond3d.com/posts/1176110/ ) and it's the performance / mm^2 / watt that's critical, we worked out that if you put in 2 nyuzi cores and managed to halve the number of instructions / pixel by replacing critical path blocks with hardware-rendering ones, you'd end up at about 25% the performance of MALI400 and that i feel would be "good enough" for a first version. i'd be interested to hear what people think, here. the *general-purpose compute* performance of nyuzi on the other hand is really good. anyway lots of planning to do. l. --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From laserhawk64 at gmail.com Fri Jan 19 16:12:40 2018 From: laserhawk64 at gmail.com (Christopher Havel) Date: Fri, 19 Jan 2018 11:12:40 -0500 Subject: [Arm-netbook] Libre RISC-V SoC In-Reply-To: References: Message-ID: Whoo, excitement. I *really* wish I could help but I'm kind of a perpetually budding hobbyist here. Let me know if you need something strung up in 7400- or 4000-series logic, tho -- *that* is a language I can speak ;) From lkcl at lkcl.net Fri Jan 19 16:16:22 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 19 Jan 2018 16:16:22 +0000 Subject: [Arm-netbook] Libre RISC-V SoC In-Reply-To: References: Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Fri, Jan 19, 2018 at 4:12 PM, Christopher Havel wrote: > Whoo, excitement. I *really* wish I could help but I'm kind of a > perpetually budding hobbyist here. Let me know if you need something strung > up in 7400- or 4000-series logic, tho -- *that* is a language I can speak ;) :) From cand at gmx.com Fri Jan 19 16:22:45 2018 From: cand at gmx.com (Lauri Kasanen) Date: Fri, 19 Jan 2018 18:22:45 +0200 Subject: [Arm-netbook] Libre RISC-V SoC In-Reply-To: References: Message-ID: <20180119182245.150789591549428e35dcfe3f@gmx.com> On Fri, 19 Jan 2018 16:06:51 +0000 Luke Kenneth Casson Leighton wrote: > so he asked, also, what would it take to get things ready within a > year, to hand over the ASIC-based design to MOSIS, for them to turn it > into an ASIC, and i said "a team of engineers would need to be paid > for". he asked - and please note the question very carefully - "would > USD 250,000 be enough?" to which i replied (genuinely) yes... if done > carefully. software also has to be taken care of. A libre risc-v soc would indeed be great. > we worked out that if you put in 2 nyuzi > cores and managed to halve the number of instructions / pixel by > replacing critical path blocks with hardware-rendering ones, you'd end > up at about 25% the performance of MALI400 and that i feel would be > "good enough" for a first version. i'd be interested to hear what > people think, here. 25% of MALI400 is not enough for even mobile games: it is enough for spinning windows ala Compiz, but that can also be done with much less. So if the goal is something usable, rather than a platform to kickstart nyuzi development on, targeting lower perf with lower power usage would be better. Now, I don't remember if video decode blocks would be in the RISC parts or in nyuzi. GPUs are usually good at colorspace conversion and scaling, so if there are no dedicated blocks for those, then the nyuzi core should be targeted/sized at that usage. Bicubic upscaling + color conversion to fullhd - the texture units, memory bandwidth and compute parts need to have enough oomph. Radeon R300 parts are capable of that. I'm not sure how that maps to % of Mali. - Lauri From lkcl at lkcl.net Fri Jan 19 18:04:40 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 19 Jan 2018 18:04:40 +0000 Subject: [Arm-netbook] Libre RISC-V SoC In-Reply-To: <20180119182245.150789591549428e35dcfe3f@gmx.com> References: <20180119182245.150789591549428e35dcfe3f@gmx.com> Message-ID: On Fri, Jan 19, 2018 at 4:22 PM, Lauri Kasanen wrote: > On Fri, 19 Jan 2018 16:06:51 +0000 > 25% of MALI400 is not enough for even mobile games: it is enough for > spinning windows ala Compiz, but that can also be done with much less. > So if the goal is something usable, rather than a platform to kickstart > nyuzi development on, targeting lower perf with lower power usage would > be better. general-purpose software-based rendering engines are not parrtiicularly good at 3D, luckily jeff's work shows exactly where the prime focus would be needed. he did however point out that due to the sheer quantity of hardware needed to get that optimised hardware-accelerated "function" it would turn nyuzi into a totally different engine. still thinking about it. > Now, I don't remember if video decode blocks would be in the RISC parts > or in nyuzi. neither. opencores has a series of video "blocks" that could go in a separate engine, DMA-based etc. etc. these will need tto be added as well. l. From richard.wilbur at gmail.com Sat Jan 20 05:26:44 2018 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Fri, 19 Jan 2018 22:26:44 -0700 Subject: [Arm-netbook] Testing: GPIO In-Reply-To: References: Message-ID: Having taken a closer look I did find an equivalence mapping: DS113 microdesktop CON15 Net J14 pin name pin 1 SPI_MISO 1 2 SPI_MOSI 35 3 LCD0-D2 2 (LCDD2) 4 LCD0-D3 36 (LCDD3) 5 LCD0-D4 3 (LCDD4) 6 LCD0-D5 37 (LCDD5) 7 LCD0-D6 4 (LCDD6) 8 LCD0-D7 38 (LCDD7) 9 SPI_CLK 5 (SPI_SCK) 10 SPI_CE 39 (SPI_CS) 11 LCD0-D10 6 (LCDD10) 12 LCD0-D11 40 (LCDD11) 13 LCD0-D12 7 (LCDD12) 14 LCD0-D13 41 (LCDD13) 15 LCD0-D14 8 (LCDD14) 16 LCD0-D15 42 (LCDD15) 17 EINT1 9 (SC0-DETN) 18 POWER 43 (POWERON) 19 LCD0-D18 10 (LCDD18) 20 LCD0-D19 44 (LCDD19) 21 LCD0-D20 11 (LCDD20) 22 LCD0-D21 45 (LCDD21) 23 LCD0-D22 12 (LCDD22) 24 LCD0-D23 46 (LCDD23) 25 LCD0-CLK 13 (LCDCLK) 26 LCD0-VSYNC 47 (LCDVSYNC) 27 LCD0-HSYNC 14 (LCDHSYNC) 28 LCD0-DE 48 (LCDDE) 29 TWI1-SCK 15 (EOMA68-I2C-SCL) 30 TWI1-SDA 49 (EOMA68-I2C-SDA) 31 SD0-D3 16 32 SD0-D2 50 33 IR-RX 17 (VESA_SDA) 34 IR-TX 51 (GPIO_3) 35 SD0-CMD 18 36 SD0-CLK 52 37 SD0-D0 19 38 SD0-D1 53 39 NC 20 () 40 NC 54 () 41 NC 21 () 42 NC 55 () 43 PWM 22 (VESA_SCL) 44 PWFBOUT 56 (ETH_TAP) 45 UART0-TX 23 (EOMA68-UART_TX) 46 UART0-RX 57 (EOMA68-UART_RX) 47 ACIN-5V 24 (EOMA68-VCC-5V0) 48 ACIN-5V 58 (EOMA68-VCC-5V0) 49 NC 25 () 50 NC 59 () 51 EMAC-RDP 26 () 52 EMAC-RDN 60 () 53 EMAC-TDP 27 () 54 EMAC-TDN 61 () 55 NC 28 () 56 NC 62 () 57 ACIN-5V 29 (EOMA68-VCC-5V0) 58 ACIN-5V 63 (EOMA68-VCC-5V0) 59 DP1 30 (EOMA68-DP0) 60 DM1 64 (EOMA68-DM0) 61 GND 31 62 GND 65 63 EINT0 32 64 TTLREFOUT=VCC-3V3 66 (VREFTTL) 65 GND 33 66 GND 67 67 DP2 34 68 DM2 68 0 (GND) 0/2 (GND) 71 (GND) 72 (GND) 73 () 74 () From richard.wilbur at gmail.com Sat Jan 20 05:47:55 2018 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Fri, 19 Jan 2018 22:47:55 -0700 Subject: [Arm-netbook] Libre RISC-V SoC In-Reply-To: References: Message-ID: That's awesome news on so many fronts! (libre LPDDR3 PHY, working relationship with MOSIS, possibility of funding, VHDL glue logic for interfaces, multiplexer GPIO bank, performance tuning a libre GPU, video coprocessors with DMA) Sounds like lots of fun! From lkcl at lkcl.net Sat Jan 20 06:56:05 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sat, 20 Jan 2018 06:56:05 +0000 Subject: [Arm-netbook] Libre RISC-V SoC In-Reply-To: References: Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Sat, Jan 20, 2018 at 5:47 AM, Richard Wilbur wrote: > That's awesome news on so many fronts! (libre LPDDR3 PHY, working > relationship with MOSIS, possibility of funding, VHDL glue logic for > interfaces, multiplexer GPIO bank, performance tuning a libre GPU, > video coprocessors with DMA) > Sounds like lots of fun! yehyeh! don't forget unlimited resources at an indian university to create an 8-stage pipeline harvard architecture superscalar 16-core SMP processor that uses only 120mW per core in 28nm and can run at a 2.5ghz clock rate, mustn't forget that, y'know - i mean it's _just_ the processor bit... l. From lkcl at lkcl.net Sat Jan 20 07:01:29 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sat, 20 Jan 2018 07:01:29 +0000 Subject: [Arm-netbook] Testing: GPIO In-Reply-To: References: Message-ID: On Sat, Jan 20, 2018 at 5:26 AM, Richard Wilbur wrote: > Having taken a closer look I did find an equivalence mapping: yeah this is a pain in the ass. the person who did the work 5 years ago, after i EXPLICITLY sent them a schematic that had the correct mapping, COMPLETELY fucking well ignored it and changed it from a 1, 2, 3 .... 68 mapping to a 1, 35, 2, 36 ... mapping. fucking idiots. anyway it's meant that i've had to ignore the pin numbers in the schematic and go by pin positions. about 2 years ago i worked out a trick which wouldn't screw with the PCB layout: adding a SECOND connector, in position on top of the existing one, manually connecting the tracks and then deleting the old one with the wrong pinouts. the reason it has to be done that way is because if you *remove* the [older, wrong] connector PADS rips up the fucking tracks, right the way back to the damn processor pins. so i left it for 3 years until i had worked out / learned a technique to avoid that happening. *sigh*.... From ronwirring at Safe-mail.net Sat Jan 20 17:01:20 2018 From: ronwirring at Safe-mail.net (ronwirring at Safe-mail.net) Date: Sat, 20 Jan 2018 12:01:20 -0500 Subject: [Arm-netbook] RK3399 Message-ID: -------- Original Message -------- From: Christopher Havel Apparently from: arm-netbook-bounces at lists.phcomp.co.uk To: Linux on small ARM machines Subject: Re: [Arm-netbook] RK3399 Date: Thu, 18 Jan 2018 22:49:12 -0500 > BTW -- not *everything* is nearly as complex as Luke would have you > believe. If I ask about how to build a libre software mainboard into the cabinet of a common notebook, lkcl gets rather hectic on rebuffing such option. Some of his arguments I accept. Others I do not. One lkcl argument is, I should not spend thousands of usd on making an attempt with an uncertain outcome. I agree on that. For now I have spent 50usd on getting an asus 7inch eeepc. I like the size of it. It has a full keyboard. It is bulky. Therefore more likely to have space for building in another mainboard. Lkcl says, should I succeed in building one, only I would benefit. I disagree. I would tell others how to make a similar computer, should they want to. Then lkcl has this argument about reverse engineering a lot of computer devices. I do not understand it. Apart from the display all devices should be usb. Sound, touchpad, keyboard, ethernet, wifi, storage. Display should be hdmi. Rather I believe getting a battery and powersupply solution would be difficult. I would also like to make a libre software computer looking like the pocketchip. I have bought this generic 6usd keyboard. https://images-na.ssl-images-amazon.com/images/I/51q2r5Jvu2L.jpg I do not like the feel of the keys. Apart from that it is adequate sized. The keyboard does not work via usb wire. It would require the keyboard to get modified. > Keyboards are invariably a passive switch matrix (look it up if you don't > know About the asus eeepc's keyboard. I have. I am not clever enough. Lowpriced on ebay I found an ATMEGA328P-PU Microcontrolle​r. A GPIO kit Extension Board Adapter Breadboard. A flat cable Ribbon connector socket 30pin 1.0mm Pitch. Apparently using a raspberry pi, you should be able to program the microcontroller. How to make the keyboard's matrix, I do not know. > Touchpads are almost always either USB or PS/2 What I have been told. > It's the screen and battery interfaces that are going to get you This rk3399 mainboard https://www.cnx-software.com/2016/12/05/firefly-rk3399-rockchip-rk3399-development-board-launched-on-kickstarter-for-139-and-up/ has a hdmi port. What should be the difficulty in connecting the mainboard to a hdmi display? > 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 bluey at smallfootprint.info Mon Jan 22 09:07:30 2018 From: bluey at smallfootprint.info (Bluey) Date: Mon, 22 Jan 2018 20:07:30 +1100 Subject: [Arm-netbook] Transferring the EOMA standard from elinux.org to markdown / new website In-Reply-To: References: Message-ID: <61F353DA-E7AA-47D4-90B2-B60940F30780@smallfootprint.info> Hi Luke, I have some memory of a request for help in transferring the EOMA standard from the elinux.org site to markdown format (as a step towards publishing it on eoma68.com) but can’t find the exact reference in the mailing list archives. If I’ve remembered that correctly, and it’s something you are looking for help with, I’d be happy to volunteer. I have some experience with static-site generators (that, as you’d know, use markdown documents as source files), and could assemble something along those lines if you’d like. Here’s a quick mockup of a site for the EOMA standard using the MkDocs engine: https://my.pcloud.com/publink/show?code=kZP6WH7ZvLbZLKwpHaokSVkeG02gqd7dt5wQxEdk The present mockup design is based on the assumption that the specifications for all current and future EOMA standards would be housed on the same website (EOMA-26, EOMA-CF, EOMA-68, etc.); this would, I presume, consequently require the use of a more generic domain name (e.g., EOMAstandard.info/.org) instead of EOMA-68.com but obviously I’ll leave the decision about which way to go with you. I can easily change the site design to just cover EOMA-68 should that be your preference. You’ll notice that I’ve added in some suggested extra pages including: ‘Contribute', ‘About', 'News', and ‘FAQs'. For the ‘Contribute' page, I had in mind suggesting that people could offer technical, marketing, or financial support to the project. If you’d just prefer the pages in markdown (not assembled as a MkDocs site) I can also just do that, in which case I could just create a collection of individual pages in a flat file structure and leave any internal page links I find as they are. Cheers, Bluey — P.S. I have noticed that sometimes various versions of the standard (e.g., EOMA-68) are written with a hyphen and sometimes without. I personally feel that the best format would be to include some nominated character to clearly indicate that there are multiple variations of the standard. You could then use a different character to indicate variation according to type of SOC. For instance, the format might be: EOMA or EOMA-, EOMA-NN, and EOMA-NN:XYZ. Examples would then be... EOMA or EOMA- EOMA-26, EOMA-68, EOMA-200, etc. EOMA-68:A20, EOMA-68:RISC-V, EOMA-68:RK3399, etc. OR, swap the colon and hyphens around... EOMA or EOMA: EOMA:26, EOMA:68, EOMA:200, etc. EOMA:68-A20, EOMA:68-RISC-V, EOMA:68-RK3399, etc. OR, use the pipe or other symbol for SOC... EOMA or EOMA: EOMA:26, EOMA:68, EOMA:200, etc. EOMA:68|A20, EOMA:68|RISC-V, EOMA:68|RK3399, etc. EOMA or EOMA: EOMA:26, EOMA:68, EOMA:200, etc. EOMA:68~A20, EOMA:68~RISC-V, EOMA:68~RK3399, etc. From lkcl at lkcl.net Mon Jan 22 11:35:21 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 22 Jan 2018 11:35:21 +0000 Subject: [Arm-netbook] Transferring the EOMA standard from elinux.org to markdown / new website In-Reply-To: <61F353DA-E7AA-47D4-90B2-B60940F30780@smallfootprint.info> References: <61F353DA-E7AA-47D4-90B2-B60940F30780@smallfootprint.info> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Mon, Jan 22, 2018 at 9:07 AM, Bluey wrote: > Hi Luke, > > I have some memory of a request for help in transferring the EOMA standard from the elinux.org site to markdown format (as a step towards publishing it on eoma68.com) but can’t find the exact reference in the mailing list archives. If I’ve remembered that correctly, and it’s something you are looking for help with, I’d be happy to volunteer. oh - no it was a discussion where i assessed and preferred - at the time - that the standard remain (for now) independent and hosted on an independent third party site. whilst i really like the idea of having a special dedicated domain for it, the other problem is, the elinux.org site now has quite a high page-rank for the keyword search "EOMA68". what do you do with the page there? remove it? that would reduce page-rank and cause quite a lot of confusion, suddenly the standard doesn't exist any more?? what's going on?? so the solution i came up with was to simply iframe it. > I have some experience with static-site generators (that, as you’d know, use markdown documents as source files), and could assemble something along those lines if you’d like. Here’s a quick mockup of a site for the EOMA standard using the MkDocs engine: https://my.pcloud.com/publink/show?code=kZP6WH7ZvLbZLKwpHaokSVkeG02gqd7dt5wQxEdk > > The present mockup design is based on the assumption that the specifications for all current and future EOMA standards would be housed on the same website (EOMA-26, EOMA-CF, EOMA-68, etc.); this would, I presume, consequently require the use of a more generic domain name (e.g., EOMAstandard.info/.org) instead of EOMA-68.com but obviously I’ll leave the decision about which way to go with you. I can easily change the site design to just cover EOMA-68 should that be your preference. > > You’ll notice that I’ve added in some suggested extra pages including: ‘Contribute', ‘About', 'News', and ‘FAQs'. For the ‘Contribute' page, I had in mind suggesting that people could offer technical, marketing, or financial support to the project. i think, these would be great to have on something like eoma68.com where the standard is iframe'd in. the key thing to understand about the standard is that i, as the "Guardian Of The Standard", am NOT PERMITTED to manufacture or in any way compete with people who may wish to be implementors of the standard. i can barely get away with the current campaign by claiming to be a "contracted assistant and advisor on EOMA68 to a sponsor, a commercial company named ThinkPenguin". me personally actually making a PROFIT out of being such an assistant and advisor to ThinkPenguin is an absolute NO. > If you’d just prefer the pages in markdown (not assembled as a MkDocs site) I can also just do that, in which case I could just create a collection of individual pages in a flat file structure and leave any internal page links I find as they are. > > Cheers, > Bluey > — > P.S. I have noticed that sometimes various versions of the standard (e.g., EOMA-68) are written with a hyphen and sometimes without. this was discussed 2 years ago. the glossary section explains it. the hyphen is *NOT* correct. if you find any location which says "EOMA-NN" please let me know and i will correct it. > I personally feel that the best format would be to include some nominated character to clearly indicate that there are multiple variations of the standard. You could then use a different character to indicate variation according to type of SOC. > the decision was made 2 years ago to go with EOMANN-{specialisation} e.g. EOMA68-A20. l. From crimier at yandex.ru Mon Jan 22 16:47:02 2018 From: crimier at yandex.ru (=?utf-8?B?UGnEjXVnaW5zIEFyc2VuaWpz?=) Date: Mon, 22 Jan 2018 18:47:02 +0200 Subject: [Arm-netbook] RK3399 In-Reply-To: References: Message-ID: <92281516639622@web22o.yandex.ru> > I agree on that. For now I have spent 50usd on getting > an asus 7inch eeepc. I like the size of it. It has a full > keyboard. It is bulky. Therefore more likely to have space > for building in another mainboard. > ... > Then lkcl has this argument about reverse > engineering a lot of computer devices. I do > not understand it. Apart from the display all devices > should be usb. Sound, touchpad, keyboard, ethernet, > wifi, storage. Display should be hdmi. Rather I believe > getting a battery and powersupply solution would be > difficult. I have some EEE PCs (2 working and 2 spares), and I absolutely love them, I spent lots of time growing up with them, and learned to properly use command-line Linux while I was at it. My question - would you be interested in re-making it for EOMA-68 or something similar? I definitely am. EEE 701 has been thoroughly reverse-engineered, there are schematics available, as well as lots of interesting replacement parts. So, my plan: we'll need to re-place the motherboard, with something much more simple and much less power-guzzling. We'll also need to mod the chassis a little bit (to make an opening for an EOMA68 card). That's the extent of what we'll need to do - we won't need to replace anything in the upper half, and we'll be able to reuse many parts from the lower half. Here's how it goes: Screen: * The screen is RGBTTL, which is the same interface that an EOMA68 card has on its pinout. If my understanding is correct, it should be trivial to interface to. LVDS is used internally (for decreasing EMI, if I understand it correctly), and the upper half has a small board with LVDS2TTL IC - SN75LVDS86A. So, interfacing that to EOMA68 (specifically, the hardware side) would simply require using a TTL2LVDS IC - something like SN75LVDS84A, to convert EOMA's RGBTTL into LVDS. We'll be able to re-use the original LCD cable that way, too! * The LCD panel also has I2C, which is likely used for just interfacing to an EEPROM containing panel's resolution. If it's not only an EEPROM and there's some kind of control data going over there, it is likely sniffable using a 5$ logic analyzer (using all OSS software, too!). * I've got no idea if there's any kind of initialization sequence sent over TTL, but I think it's unlikely. If so, we might still be able to sniff it with a more advanced analyzer, or try to get a panel datasheet&init sequence somewhere (it is a popular panel, after all). So, we should be able to re-use the screen and all the surrounding parts - win! Battery: * Connector pinout is known, and desoldering the connector from the board is tricky but not too hard. * It uses a fuel gauge chip accessible over I2C, indeed. Thankfully, as I have two working EEEs (and three batteries), we should be able to sniff enough communication to determine which commands correspond to which data. Alternatively, it's very likely the fuel gauge's datasheet is available somewhere. * Charging the battery and powering the system will be a problem, indeed. Fortunately, the EEE's solution to this is documented, and we could, at the very least, learn from it - it's going to be an interesting journey for me, but nothing that's not been done by somebody else already. So, we should be able to re-use the battery - another big win! Other things we can re-use: * Camera is USB indeed, dead simple to interface. * Touchpad is PS/2, but that's not a big problem, PS/2 to USB converters are available cheaply. * Keyboard is a matrix one - but the pinout is known (the matrix isn't known though, but shouldn't be hard to figure out). Again, matrix-to-USB converters are both available cheaply, and DIY-able easily. * Speakers and microphone should be easily re-usable. Parts we won't be able to re-use: * Original Intel CPU, south and north bridges... We won't miss them, though =) * Embedded controller - the part that controls the power states, power button, LEDs, peripheral power (like, turning off the camera or the SD reader when they're not used). We can, and likely will, replace it with a microcontroller. * SD reader - it's too tightly integrated in the motherboard, even though it's USB. Desoldering lots of chips & support passives, as well as the connector, would be tricky, so it'd be best if we don't go that path. We might be able to use the SDIO from EOMA68 connector, though (alternatively, we could use that SDIO for WiFi). Also, we can simply add a USB SD reader, yay! * Ethernet - luckily, USB-ethernet chips are cheap and accessible, so if we need to add Ethernet, we can. * Audio - either an AC97 solution or a USB one will be suitable. * MiniPCI-E interface - no PCI-E on EOMA, maybe that's for the best, we don't need it for much (PCB layout would be tricky, too). Though I have to admit that a full-size WiFi would be nice to have. * SATA and IDE - again, godspeed, and we absolutely can use a converter chip if need arises. > Lkcl says, should I succeed in building one, only I would > benefit. I disagree. I would tell others how to make a > similar computer, should they want to. Totally agree. Once one does something, others can follow. The EEE PC was popular enough so that lots of other people can follow. Broken laptops and replacement parts are still available, too. > How to make the keyboard's matrix, I do not know. Interfacing to a keypad matrix is very easy nowadays. There are a lot of ready-to-go hardware and software solutions from the DIY keyboard community. > https://www.cnx-software.com/2016/12/05/firefly-rk3399-rockchip-rk3399-development-board-launched-on-kickstarter-for-139-and-up/ > has a hdmi port. What should be the difficulty in connecting > the mainboard to a hdmi display? As a rule of thumb, using HDMI internally, or converting high-speed interfaces into similar-but-not-quite high-speed interfaces, comes with an increased power consumption. You don't really want that - and it seems that EOMA68 should work without it, allowing us to use the HDMI for an additional display instead =) So, here's my summary - it's doable. If you're ready to work for this, we can have it done in half a year. I'll be more than happy to help (and I know some people that could help, too). However, there are a lot of parts that are small and easy, but time-consuming, and time is something I don't have much of, so expect there to be plenty of work for you =) Let me know (maybe email directly) if you're interested and ready to start working on this project together. Cheers! Arsenijs From vkontogpls at gmail.com Mon Jan 22 20:38:26 2018 From: vkontogpls at gmail.com (Bill Kontos) Date: Mon, 22 Jan 2018 22:38:26 +0200 Subject: [Arm-netbook] Libre RISC-V SoC In-Reply-To: References: Message-ID: On Fri, Jan 19, 2018 at 6:06 PM, Luke Kenneth Casson Leighton wrote: > > i'm also talking to jeff from nyuzi, he designed a software-driven > "compute engine that happens to be reasonably good at 3D", the > interesting bit being that he's focussed on working out which areas > need performance improvements. this is something that's almost > completely lacking in the published academic world... *because nobody > in the academic world has designed and published a GPU!* > > we worked out that nyuzi is approximately 1/16th the speed of MALI400. > roughly. although area-for-area it's quite hard to tell whether > that's a fair assessment because you can't *get* die areas for MALI400 > (anyone know anything better than these estimates? > https://forum.beyond3d.com/posts/1176110/ ) and it's the performance / > mm^2 / watt that's critical, we worked out that if you put in 2 nyuzi > cores and managed to halve the number of instructions / pixel by > replacing critical path blocks with hardware-rendering ones, you'd end > up at about 25% the performance of MALI400 and that i feel would be > "good enough" for a first version. i'd be interested to hear what > people think, here. > That would by no means be enough. We need video decoding blocks, without those the SoC is as good as an rpi for e.g. the education market that you have mentioned and I'm sure not interested personally on using a system as a desktop/laptop that can't play videos without stuttering while potentially doing something else at the same time. And I'm not even talking about games here. I don't know if there is a simd extension on the cpu cores that someone can write a real time decoder for and hook it up to whatever's needed for firefox etc to automatically redirect to( not that that's an easy thing), but 25% of an outdated low performance gpu sounds really low to me. What's the point of having such an awesome low power core if we can't use the thermal envelope for pushing graphics? > the *general-purpose compute* performance of nyuzi on the other hand > is really good. What is gpgpu used on desktops right now for? From vkontogpls at gmail.com Mon Jan 22 20:50:24 2018 From: vkontogpls at gmail.com (Bill Kontos) Date: Mon, 22 Jan 2018 22:50:24 +0200 Subject: [Arm-netbook] RK3399 In-Reply-To: References: Message-ID: On Fri, Jan 19, 2018 at 5:04 PM, Luke Kenneth Casson Leighton wrote: > --- > > > it's just not worth it and drives up the price of the second-hand > thinkpads, and pisses everyone off who is selling them to libre > conscious people as they can't make a business case for even bothering > to buy and convert them to libreboot. So buying a thinkpad and converting it to an ethical device is pissing off those who buy thinkpads and convert them to ethical devices? I'm not really into retro computers as these people seem to be but from my understanding they are very negative to each other as if we don't have enough to fight against already. From lkcl at lkcl.net Mon Jan 22 21:12:08 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 22 Jan 2018 21:12:08 +0000 Subject: [Arm-netbook] Libre RISC-V SoC In-Reply-To: References: Message-ID: On Mon, Jan 22, 2018 at 8:38 PM, Bill Kontos wrote: > That would by no means be enough. We need video decoding blocks, ... you mean like this? https://opencores.org/project,video_systems >> the *general-purpose compute* performance of nyuzi on the other hand >> is really good. > > What is gpgpu used on desktops right now for? something that usually uses four to ten times more power than the target power budget for the entire SoC. l. From lkcl at lkcl.net Mon Jan 22 21:21:22 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 22 Jan 2018 21:21:22 +0000 Subject: [Arm-netbook] RK3399 In-Reply-To: References: Message-ID: On Mon, Jan 22, 2018 at 8:50 PM, Bill Kontos wrote: > On Fri, Jan 19, 2018 at 5:04 PM, Luke Kenneth Casson Leighton > wrote: >> --- >> >> >> it's just not worth it and drives up the price of the second-hand >> thinkpads, and pisses everyone off who is selling them to libre >> conscious people as they can't make a business case for even bothering >> to buy and convert them to libreboot. > > So buying a thinkpad and converting it to an ethical device is pissing > off those who buy thinkpads and convert them to ethical devices? yyyup! the effort by the vera-apparatus team caused a *lot* of problems when they started buying up used thinkpad laptops to convert over. the supply is extremely limited. > I'm > not really into retro computers as these people seem to be but from my > understanding they are very negative to each other as if we don't have > enough to fight against already. that would be one way of looking at it. ... or... it could be the case that it is hopelessly unrealistic and just not worth the time and effort - in fact due to the amount of time and efffort it takes to do the disassembly and conversion, in combination with the fact that second-hand machines are firstly distributed world-wide so must be shipped to one location for disasseembly and second they're in short supply _anyway_, it could be viewed as being highly environmentally IRRESPONSIBLE to spend significant energy resources on converting such products. in other words: when you add up the amount of time and effort proposed to be spent, and convert it to an actual dollar amount, i estimate that it would come to an amount that would EASILY fund the development of an entirely new type of computer. one that can be designed to be repaired, upgraded, respect software freedom and not end up in landfill. ... .yeh? l. From ronwirring at Safe-mail.net Mon Jan 22 22:56:48 2018 From: ronwirring at Safe-mail.net (ronwirring at Safe-mail.net) Date: Mon, 22 Jan 2018 17:56:48 -0500 Subject: [Arm-netbook] RK3399 Message-ID: -------- Original Message -------- From: Pičugins Arsenijs Apparently from: arm-netbook-bounces at lists.phcomp.co.uk To: "arm-netbook at lists.phcomp.co.uk" Subject: Re: [Arm-netbook] RK3399 Date: Mon, 22 Jan 2018 18:47:02 +0200 > Pičugins Arsenijs Thank you for your email. There are a lot of pieces of information about this task. In this email I may forget to address some of them. I wanted a small eoma pc card notebook. That is why I obtained the asus 7inch eee pc 4g. When I got the notebook, I took out the mainboard because I wanted to see how much space is in the cabinet. As I mentioned, I wanted to convert the notebook to an eoma pc card notebook. Because shipping of the pc card keeps being delayed I have not done more about it. I mentioned the rk3399 mainboard, because it maybe would be an option if the pc card does not get made. > If you're ready to work for this Yes, but we have to set some references. I am not skilled on electronics. I will have to move on instructions. Costs may spiral. I am not going to accept that. If I am asked to buy a 100usd device, I will answer no. If I am asked to buy a 50usd device, I will likely answer no. I will comment briefly on what you wrote about various computer devices. > The screen is RGBTTL, which is the same interface >that an EOMA68 card has If we in a low priced way can get to use the build in display, that is what we should do. I mentioned getting a 7inch hdmi display if that was the only workable solution. My notebook is an asus 7inch eee pc 4g. I do not know the precise name of the build in display. Camera is not important. We will use the camera as an usb camera. Else we will not use it. About wifi card, I have small usb ar9271 wifi cards. They work on debian 9 64bit main. Saying the source software is available. We should use an usb ar9271 wifi card. About sound. I have an usb soundcard. It works on debian 9 64bit main. Saying the device's source software is available. We should use an usb soundcard. About sdcard reader. I have usb sdcard readers. They work on debian 9 64bit main. Saying the devices' source software is available. We should use an usb sdcard reader. About storage. My information is, the pc card will have an sdcard port on the pc card for storage. > matrix-to-USB converters are both available Turning the keyboard into an usb keyboard is an important move. I suggest we make turning the notebook's keyboard into an usb keyboard our first step. About a battery supplying power. I suggest we wait until we have a notebook, which will run on a power supply. > maybe email directly Maybe this modification of a notebook is of interest for other people. We should use this email list. > 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 richard.wilbur at gmail.com Mon Jan 22 23:32:27 2018 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Mon, 22 Jan 2018 16:32:27 -0700 Subject: [Arm-netbook] EOMA Standard Message-ID: <67377B3B-3307-4B66-B6C3-1E61753752C1@gmail.com> As I was reading the EOMA standard[*] in the section entitled "Interoperability Restrictions imposed by height limits", I came across a statement Type III 8.0mm cards must be actively prevented from slotting into Type I (5.0mm) Housings by ensuring that there is a physical slot in the casework that is no more than 5.5mm in height. which I think would probably reflect your meaning better if rewritten as follows: Type III 8.0mm cards must be actively prevented from slotting into Type II (5.0mm) Housings by ensuring that there is a physical slot in the casework that is no more than 5.5mm in height. Because the previous paragraph dealt with restrictions on Type I Housings (which accept 3.3mm high cards) and this mentions 5.0mm cards (which correspond to Type II). Reference: [*] https://elinux.org/Embedded_Open_Modular_Architecture/EOMA68/Hardware#Pinouts_.28version_1.0.29 Sent from my iPhone From lkcl at lkcl.net Mon Jan 22 23:55:51 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 22 Jan 2018 23:55:51 +0000 Subject: [Arm-netbook] RK3399 In-Reply-To: <92281516639622@web22o.yandex.ru> References: <92281516639622@web22o.yandex.ru> Message-ID: On Mon, Jan 22, 2018 at 4:47 PM, Pičugins Arsenijs wrote: > I have some EEE PCs (2 working and 2 spares), and I > absolutely love them, an eeepc would be a much better base than a thinkpad as it stays away from the [extremely resource-starved] market of replacing the bios in the libre community, i.e. doesn't gut machines that would otherwise be kept in circulation (and out of landfill) far longer by being in the hands of a responsible libre-software supporter. you will learn a lot from the task that you envision, arsenijs: if the reverse-engineering of the eeepc is that far along it takes care of many of the tasks on the list and yes, 6 months would not be an unreasonable estimate for the remainder. please however be under no illusion that, even at the end of all that effort, which if well-documented will be extremely valuable in its own right and on its own merit, you are still presenting people with the task of *hand-disassembling* a pre-existing system, that the number of people who will be interested to do so will be at most 100 in the world, and that bang-per-buck wise the effort spent has an extremely low *actual* environmental benefit compared to designing and building a system that's *actually* intented - from the start - to be eco-conscious. l. From lkcl at lkcl.net Mon Jan 22 23:57:31 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 22 Jan 2018 23:57:31 +0000 Subject: [Arm-netbook] EOMA Standard In-Reply-To: <67377B3B-3307-4B66-B6C3-1E61753752C1@gmail.com> References: <67377B3B-3307-4B66-B6C3-1E61753752C1@gmail.com> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Mon, Jan 22, 2018 at 11:32 PM, Richard Wilbur wrote: > As I was reading the EOMA standard[*] in the section entitled "Interoperability Restrictions imposed by height limits", I came across a statement > > Type III 8.0mm cards must be actively prevented from slotting into Type I (5.0mm) Housings by ensuring that there is a physical slot in the casework that is no more than 5.5mm in height. yep. > which I think would probably reflect your meaning better if rewritten as follows: > > Type III 8.0mm cards must be actively prevented from slotting into Type II (5.0mm) Housings by ensuring that there is a physical slot in the casework that is no more than 5.5mm in height. > > Because the previous paragraph dealt with restrictions on Type I Housings (which accept 3.3mm high cards) and this mentions 5.0mm cards (which correspond to Type II). ok it should be prevented from fitting into both Type I *and* Type II. l. From calmstorm at posteo.de Tue Jan 23 01:26:53 2018 From: calmstorm at posteo.de (zap) Date: Mon, 22 Jan 2018 20:26:53 -0500 Subject: [Arm-netbook] RK3399 In-Reply-To: References: Message-ID: <501a1255-cf6a-5b74-9702-4b7e8b10a556@posteo.de> > that would be one way of looking at it. > > ... or... it could be the case that it is hopelessly unrealistic and > just not worth the time and effort - in fact due to the amount of time > and efffort it takes to do the disassembly and conversion, in > combination with the fact that second-hand machines are firstly > distributed world-wide so must be shipped to one location for > disasseembly and second they're in short supply _anyway_, it could be > viewed as being highly environmentally IRRESPONSIBLE to spend > significant energy resources on converting such products. I am inclined to agree especially with the recent meltdown and spectre bugs... Who knows how many other terrible bugs exist that lie unknown... But yeah, its better just to make new laptops from scratch for that purpose. I previously disagreed with this with the exception of using librebooted devices, until again, those two bugs... opened my eyes.  In the future, I will buy your stuff for sure. I await the future of eoma68 standard. I hope you will make a new libre card at some point... but till then, I will use the libre tea computer card probably. > > in other words: when you add up the amount of time and effort > proposed to be spent, and convert it to an actual dollar amount, i > estimate that it would come to an amount that would EASILY fund the > development of an entirely new type of computer. > > one that can be designed to be repaired, upgraded, respect software > freedom and not end up in landfill. > > ... .yeh? You are correct, and I wish I had realized this a lot sooner.  My bad... > > 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 Tue Jan 23 01:34:51 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 23 Jan 2018 01:34:51 +0000 Subject: [Arm-netbook] RK3399 In-Reply-To: <501a1255-cf6a-5b74-9702-4b7e8b10a556@posteo.de> References: <501a1255-cf6a-5b74-9702-4b7e8b10a556@posteo.de> Message-ID: On Tue, Jan 23, 2018 at 1:26 AM, zap wrote: >> in other words: when you add up the amount of time and effort >> proposed to be spent, and convert it to an actual dollar amount, i >> estimate that it would come to an amount that would EASILY fund the >> development of an entirely new type of computer. >> >> one that can be designed to be repaired, upgraded, respect software >> freedom and not end up in landfill. >> >> ... .yeh? > You are correct, and I wish I had realized this a lot sooner. My bad... yyehh i've been down this evaluation path a number of times now on this list, with different groups of people at different times. it... kinda puts a dampener on peoples' enthusiasm for doing home-grown "hackaday" style projects... but... hackaday projects are for people to learn (and teach other people) electronics. this project is *specifically* about reducing *world-wide* e-waste on a *massive* scale by making desirable long-term upgradeable computing appliances, thus keeping stuff out of landfill as long as possible... and that *has* to be done not by disassembling pre-existing deeply flawed "Designed for Obsolescence and Manufacture" products but by going *right* back to the very source of the problem. totally different approach that's really hard for some people to understand or accept, the scale is about a hundred thousand times larger than they're able to get their minds around. l. From laserhawk64 at gmail.com Tue Jan 23 01:47:49 2018 From: laserhawk64 at gmail.com (Christopher Havel) Date: Mon, 22 Jan 2018 20:47:49 -0500 Subject: [Arm-netbook] RK3399 In-Reply-To: References: <501a1255-cf6a-5b74-9702-4b7e8b10a556@posteo.de> Message-ID: Forgive another phone top-post, please, but -- I have an ASUS EeePC 1005HA that, if someone else had one, I could help with reverse engineering. I will commit to getting the keyboard layout and the LCD datasheet (with the one caveat that the LCD datasheet must be freely available, i.e. not exclusively behind a paywall). I will NOT help with the battery or display cable, though. I realize that this has few environmental advantages over just binning the thing -- but you gotta get your feet wet somhow, and this looks to me like a great way to do that. If you'll excuse me, I have a copier power socket to glue back together now. See, my stepmother has a commercial-grade Koyocera (no, really, she does), and it apparently shook hands with a wall, cords and everything... this is what happens when you're the nerd in the family... ;) On Jan 22, 2018 8:35 PM, "Luke Kenneth Casson Leighton" wrote: > On Tue, Jan 23, 2018 at 1:26 AM, zap wrote: > > >> in other words: when you add up the amount of time and effort > >> proposed to be spent, and convert it to an actual dollar amount, i > >> estimate that it would come to an amount that would EASILY fund the > >> development of an entirely new type of computer. > >> > >> one that can be designed to be repaired, upgraded, respect software > >> freedom and not end up in landfill. > >> > >> ... .yeh? > > You are correct, and I wish I had realized this a lot sooner. My bad... > > yyehh i've been down this evaluation path a number of times now on > this list, with different groups of people at different times. it... > kinda puts a dampener on peoples' enthusiasm for doing home-grown > "hackaday" style projects... but... hackaday projects are for people > to learn (and teach other people) electronics. this project is > *specifically* about reducing *world-wide* e-waste on a *massive* > scale by making desirable long-term upgradeable computing appliances, > thus keeping stuff out of landfill as long as possible... and that > *has* to be done not by disassembling pre-existing deeply flawed > "Designed for Obsolescence and Manufacture" products but by going > *right* back to the very source of the problem. > > totally different approach that's really hard for some people to > understand or accept, the scale is about a hundred thousand times > larger than they're able to get their minds around. > > 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 bluey at smallfootprint.info Tue Jan 23 03:43:06 2018 From: bluey at smallfootprint.info (Bluey) Date: Tue, 23 Jan 2018 14:43:06 +1100 Subject: [Arm-netbook] Transferring the EOMA standard from elinux.org to markdown / new website In-Reply-To: References: <61F353DA-E7AA-47D4-90B2-B60940F30780@smallfootprint.info> Message-ID: <39E92586-987D-4914-B12E-8A65FD0BF9DB@smallfootprint.info> > oh - no it was a discussion where i assessed and preferred - at the > time - that the standard remain (for now) independent and hosted on an > independent third party site. No worries. > whilst i really like the idea of having a special dedicated domain > for it, the other problem is, the elinux.org site now has quite a high > page-rank for the keyword search "EOMA68". what do you do with the > page there? remove it? that would reduce page-rank and cause quite a > lot of confusion, suddenly the standard doesn't exist any more?? > what's going on?? > > so the solution i came up with was to simply iframe it. > When/if you decide to move the standard, my suggestion would be to put some text on the existing elinux EOMA pages to say that the standard has moved to a dedicated site. Over time the page ranks would shift over to the new site. There would also be a number of other SEO activities we could do to boost the page ranking once the new site is up. >> >> You’ll notice that I’ve added in some suggested extra pages including: ‘Contribute', ‘About', 'News', and ‘FAQs'. For the ‘Contribute' page, I had in mind suggesting that people could offer technical, marketing, or financial support to the project. > > i think, these would be great to have on something like eoma68.com > where the standard is iframe'd in. Cool. > the key thing to understand about the standard is that i, as the > "Guardian Of The Standard", am NOT PERMITTED to manufacture or in any > way compete with people who may wish to be implementors of the > standard. i can barely get away with the current campaign by claiming > to be a "contracted assistant and advisor on EOMA68 to a sponsor, a > commercial company named ThinkPenguin". me personally actually making > a PROFIT out of being such an assistant and advisor to ThinkPenguin is > an absolute NO. > Sure, I understand. However, I think we can keep it clean/ethical and differentiate between the various projects/teams/individuals easily enough. I would suggest the following financial and donations setup: - an ‘Individual' liberapay account for you, Luke, as a libre developer (this is already in place at https://liberapay.com/lkcl/ ); - a ‘Team' liberapay account for EOMA standard* development, web hosting, and administration (including a percentage of money as wages for those working on the standard); and - in addition to any money earned through Crowd Supply, an ‘Organisation’ or ‘Team’ liberapay account for Earth-friendly Computers that is managed by its sponsor, ThinkPenguin, with money directed to the project as the sponsor sees fit or that it explicitly specifies upfront. This might involve using the money to pay, for example, for equipment, raw materials, employee wages, marketing, or contracted assistants and advisors). * Note, for this 2nd item, that it seems reasonable to me that developing a standard takes legitimate resources that include website hosting, equipment, and time. To me, that’s not profit. Although ISO, IEC, etc. are commercial entities, some of the money they make goes to paying for those standards to be developed plus any and all employee and administrative costs. Essentially, I think of the EOMA standards project—in all but name—as a non-profit organisation that has operating costs. >> P.S. I have noticed that sometimes various versions of the standard (e.g., EOMA-68) are written with a hyphen and sometimes without. > > this was discussed 2 years ago. the glossary section explains it. > the hyphen is *NOT* correct. if you find any location which says > "EOMA-NN" please let me know and i will correct it. > Okay, no worries. To start with, I think most of the pages on elinux.org need reviewing, for example: https://elinux.org/Embedded_Open_Modular_Architecture (search for 'EOMA-‘ and you should find 7 matches) Plus all of the pages for the individual standards (EOMA-68, EOMA-200, etc.) The Crowd Supply site looks good. I found just two references to EOMA-68 (one on the front page referenced from an external review) plus one in the title of an update from 2016. Your liberapay page is fine: https://liberapay.com/lkcl/ There are various references on the Rhombus-Tech site if you put ‘EOMA-‘ in the search box. I’m not across any other sites you might have for the project, sorry. Cheers, Bluey From bluey at smallfootprint.info Tue Jan 23 03:55:16 2018 From: bluey at smallfootprint.info (Bluey) Date: Tue, 23 Jan 2018 14:55:16 +1100 Subject: [Arm-netbook] SoC + external graphics Message-ID: <7657DA3D-D688-4182-8B3F-F8F931F8981C@smallfootprint.info> Hi Luke, Forgive me if this has been discussed before but has the possibility of supporting a model where by a dedicated GPU could be installed in a second slot in order to work in concert with an EOMA SoC? For instance, a micro desktop / laptop could have two slots: - EOMA68 (for the SoC) - EOMAXX (for an optional external GPU) Cheers, Bluey From richard.wilbur at gmail.com Tue Jan 23 07:40:16 2018 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Tue, 23 Jan 2018 00:40:16 -0700 Subject: [Arm-netbook] Testing: GPIO In-Reply-To: References: Message-ID: On Sat, Jan 20, 2018 at 12:01 AM, Luke Kenneth Casson Leighton wrote: > anyway it's meant that i've had to ignore the pin numbers in the > schematic and go by pin positions. [...] so i left it for 3 years until i > had worked out / learned a technique to avoid that happening. I'm sorry to hear it has been such a thorn in the side! I went and read the EOMA68 specification since, as you mentioned, it is normative. I then tried to update the testing wiki page and it didn't seem to want to save my changes. I saved them off locally here so I can try to figure out the problem and then reapply the changes. From lkcl at lkcl.net Tue Jan 23 09:08:11 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 23 Jan 2018 09:08:11 +0000 Subject: [Arm-netbook] Testing: GPIO In-Reply-To: References: Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Tue, Jan 23, 2018 at 7:40 AM, Richard Wilbur wrote: > On Sat, Jan 20, 2018 at 12:01 AM, Luke Kenneth Casson Leighton > wrote: >> anyway it's meant that i've had to ignore the pin numbers in the >> schematic and go by pin positions. [...] so i left it for 3 years until i >> had worked out / learned a technique to avoid that happening. > > I'm sorry to hear it has been such a thorn in the side! ehn i got used to it. > I went and read the EOMA68 specification since, as you mentioned, it > is normative. cool. > I then tried to update the testing wiki page and it > didn't seem to want to save my changes. that's happened occasionally in the past. i've done a manual rebuild. > I saved them off locally here > so I can try to figure out the problem and then reapply the changes. git log compared to "Recent Changes" showed that there were 4 revisions that hadn't been applied. did you get at any point a failure of the "page updated" thing or at any point interrupt the cgi script whilst it was rebuilding the page? ikiwiki works by generating static HTML using cgi-bin perl scripts that pull markdown (etc.) out of the git repository. it can be... a little fragile. l. From lkcl at lkcl.net Tue Jan 23 09:53:05 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 23 Jan 2018 09:53:05 +0000 Subject: [Arm-netbook] SoC + external graphics In-Reply-To: <7657DA3D-D688-4182-8B3F-F8F931F8981C@smallfootprint.info> References: <7657DA3D-D688-4182-8B3F-F8F931F8981C@smallfootprint.info> Message-ID: On Tue, Jan 23, 2018 at 3:55 AM, Bluey wrote: > Hi Luke, > > Forgive me if this has been discussed before but has the possibility of supporting a model where by a dedicated GPU could be installed in a second slot in order to work in concert with an EOMA SoC? not a snowball / cat in hell's chance. how would it communicate? what's the means by which the Card would communicate with the GPU? most GPUs are done by PCI express which is... um... 32 GIGABYTES per second (!!!!!) on a PCIe 3.0 x16 system. the amount of power needed for that *alone* far exceeds the entire 5.0 watt power budget for EOMA68 Cards! and that's just for *driving* the PCIe signals! i'm going overboard somewhat: there is actually a way: use DisplayLink technology. DisplayLink has older products such as the UD160A using USB 2.0, and their newer ones use USB 3.0 and have improved the capabilities of what they can do / draw. however we cannot *rely* on any given Card being *guaranteed* to have USB 2.0, some Cards are perfectly well permitted to provide even USB 1.1 (it's not recommended but it's possible). using DisplayLink is something i put somewhere in the notes if Housing Designers really really want to create a Dual Screen Housing. l. From richard.wilbur at gmail.com Tue Jan 23 10:40:19 2018 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Tue, 23 Jan 2018 03:40:19 -0700 Subject: [Arm-netbook] Testing: GPIO In-Reply-To: References: Message-ID: On Jan 23, 2018, at 02:08, Luke Kenneth Casson Leighton wrote: > On Tue, Jan 23, 2018 at 7:40 AM, Richard Wilbur > wrote: […] > git log compared to "Recent Changes" showed that there were 4 > revisions that hadn't been applied. That may explain why the displayed version of the page didn't change but the preview did change and when I logged out and back in all of my previous edits showed back up in the page source. > did you get at any point a failure of the "page updated" thing or at > any point interrupt the cgi script whilst it was rebuilding the page? > ikiwiki works by generating static HTML using cgi-bin perl scripts > that pull markdown (etc.) out of the git repository. it can be... a > little fragile. I got an error message that said there had been a failure of the CGI script--I don't remember the exact wording. If I did interrupt something I'm not sure how I accomplished that as I was trying to be patient and wait till it was done before initiating anything new. From lkcl at lkcl.net Tue Jan 23 10:43:01 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 23 Jan 2018 10:43:01 +0000 Subject: [Arm-netbook] Testing: GPIO In-Reply-To: References: Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Tue, Jan 23, 2018 at 10:40 AM, Richard Wilbur wrote: > I got an error message that said there had been a failure of the CGI script--I don't remember the exact wording. If I did interrupt something I'm not sure how I accomplished that as I was trying to be patient and wait till it was done before initiating anything new. if it happens again please take a screenshot, it's important as it means there's a bug in ikiwiki that is essential to report and get fixed. l. From richard.wilbur at gmail.com Tue Jan 23 11:23:27 2018 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Tue, 23 Jan 2018 04:23:27 -0700 Subject: [Arm-netbook] Testing: GPIO In-Reply-To: References: Message-ID: <541D8818-446A-4196-83E8-99C9651B1977@gmail.com> On Jan 23, 2018, at 03:43, Luke Kenneth Casson Leighton wrote: > if it happens again please take a screenshot, it's important as it > means there's a bug in ikiwiki that is essential to report and get > fixed. I will do so. Thank you for helping sort this out. By the way, do you happen to know in what language ikiwiki is written? From lkcl at lkcl.net Tue Jan 23 11:33:42 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 23 Jan 2018 11:33:42 +0000 Subject: [Arm-netbook] Testing: GPIO In-Reply-To: <541D8818-446A-4196-83E8-99C9651B1977@gmail.com> References: <541D8818-446A-4196-83E8-99C9651B1977@gmail.com> Message-ID: On Tue, Jan 23, 2018 at 11:23 AM, Richard Wilbur wrote: > By the way, do you happen to know in what language ikiwiki is written? perl. *gibber, shake*. luckily it was written by an absolute genius who actually cares and is like... really responsible. otherwise ikiwiki would be a dog's dinner. l. From vkontogpls at gmail.com Tue Jan 23 12:23:23 2018 From: vkontogpls at gmail.com (Bill Kontos) Date: Tue, 23 Jan 2018 14:23:23 +0200 Subject: [Arm-netbook] Libre RISC-V SoC In-Reply-To: References: Message-ID: On Mon, Jan 22, 2018 at 11:12 PM, Luke Kenneth Casson Leighton wrote: > ... you mean like this? > https://opencores.org/project,video_systems > Yes, maybe with the adition of hevc. That would be ideal. From vkontogpls at gmail.com Tue Jan 23 12:26:24 2018 From: vkontogpls at gmail.com (Bill Kontos) Date: Tue, 23 Jan 2018 14:26:24 +0200 Subject: [Arm-netbook] RK3399 In-Reply-To: References: Message-ID: On Mon, Jan 22, 2018 at 11:21 PM, Luke Kenneth Casson Leighton wrote: > in other words: when you add up the amount of time and effort > proposed to be spent, and convert it to an actual dollar amount, i > estimate that it would come to an amount that would EASILY fund the > development of an entirely new type of computer. > > one that can be designed to be repaired, upgraded, respect software > freedom and not end up in landfill. I think you misunderstand the use case here. It's a personal project. I would totally do it myself if I had the skills. Besides I don't see why minifree & the likes are entitled to the entirety of the used thinkpad supply. It's not like their fight isn't a losing one anyway. From lkcl at lkcl.net Tue Jan 23 12:45:07 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 23 Jan 2018 12:45:07 +0000 Subject: [Arm-netbook] Libre RISC-V SoC In-Reply-To: References: Message-ID: On Tue, Jan 23, 2018 at 12:23 PM, Bill Kontos wrote: > On Mon, Jan 22, 2018 at 11:12 PM, Luke Kenneth Casson Leighton > wrote: > >> ... you mean like this? >> https://opencores.org/project,video_systems >> > > Yes, maybe with the adition of hevc. That would be ideal. do you happen to know if the building blocks - the key high-cpu-load parts - of HEVC (aka H.265) _happen_ to be the same or near-identical to MPEG or H.264 and so on? also critical will be a YUV->RGB converter plus scaler... and oh look! https://opencores.org/project,video_stream_scaler if anyone remembers the National Semi Geode LX800 (bought by AMD), that, staggeringly, could actually do 720p video displayed on 1600x1200 (with a bit of a tear at times), and could easily do 1280x720 (without tearing) @ 30fps.... *ENTIRELY IN SOFTWARE*... because it had a YUV->RGB converter hard macro that took care of the most expensive bit. ... and that was a 500mhz 486 with DDR2 RAM! absolutely incredible. so, anyway, yes: each little piece of the puzzle will be needed, saving big chunks of CPU cycles. l. From lkcl at lkcl.net Tue Jan 23 12:47:48 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 23 Jan 2018 12:47:48 +0000 Subject: [Arm-netbook] RK3399 In-Reply-To: References: Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Tue, Jan 23, 2018 at 12:26 PM, Bill Kontos wrote: > I think you misunderstand the use case here. It's a personal project. i do get it. i get that it means that people learn. i'm inviting them to think beyond that, that's all. l. From crimier at yandex.ru Tue Jan 23 18:11:55 2018 From: crimier at yandex.ru (=?utf-8?B?UGnEjXVnaW5zIEFyc2VuaWpz?=) Date: Tue, 23 Jan 2018 20:11:55 +0200 Subject: [Arm-netbook] arm-netbook Digest, Vol 90, Issue 26 In-Reply-To: References: Message-ID: <435091516731115@web10o.yandex.ru> >  you will learn a lot from the task that you envision, arsenijs: if > the reverse-engineering of the eeepc is that far along it takes care > of many of the tasks on the list and yes, 6 months would not be an > unreasonable estimate for the remainder. > >  please however be under no illusion that, even at the end of all that > effort, which if well-documented will be extremely valuable in its own > right and on its own merit, you are still presenting people with the > task of *hand-disassembling* a pre-existing system, that the number of > people who will be interested to do so will be at most 100 in the > world, and that bang-per-buck wise the effort spent has an extremely > low *actual* environmental benefit compared to designing and building > a system that's *actually* intented - from the start - to be > eco-conscious. While I do agree that making a EOMA68-based EEE is a fun and educational project and all people participating and watching will learn a lot, I believe that re-building a small (and, in a way, iconic) netbook is very important for the EOMA68 project - and this is the main reason I'm ready to spend time on it (it's not like I have too much free time =D ). First of all, it shows that EOMA68 is a mature and thought-out platform that actually allows people to be more eco-friendly, and allows people to reuse their old laptop hardware with a simple, modular, EOMA68-based motherboard (even if this is not the direction you're planning to go). This is in contrast to all the vaporware platforms that claimed everything they could, only to never deliver: here, this is an EOMA68-based device that shows how EOMA68 enables people to do more ethical decisions and restores old hardware, this is not some closed-source project done by university students that will then fade into oblivion, and not a Kickstarter campaign that overpromised and then delivered a product that you can't actually use for its goal! If done right, it will also serve as an "EOMA68 example hardware project" of sorts. If we publish schematics, PCB designs, assembly instructions, device tree overlays etc., it can easily show people: "Oh cool - they've breathed life into a legendary netbook, did some simple electronics, wrote great blog posts, and it's even future-proof! Hey, I can use this EOMA thing as a base for my own project, too!" If people are getting interested in this, this is a real chance for EOMA68 to be more popular among tinkerers. It might not be your target audience, but it can be a great one to have behind your back, and you might like selling some more hardware. On top of that, Asus EEE 701 was an important milestone in the history of computers. It was the first truly popular netbook, and a good business decision that was copied by multiple companies after Asus did it (and I'm sure they continued to cash in on the EEE brand for a long long time after the 701 was released). It was also famous for its modding capabilities - people were putting touchscreens, FM transmitters, HDDs and god knows what in it (usually with lots of USB hubs connecting everything). Hell, one of my first projects in electronics was trying to build a dock station for my EEE 1001, I didn't succeed but I did learn a fuckton of things. So, in a way, EEE is a symbol of small but powerful portable computers (that are extensible, too), and it still has a fanbase that's nostalgic about it. Getting associated with that symbol is great publicity - again, it might not be the publicity that the project is aiming for, but it's great publicity nonetheless. I won't even mention some things like "EOMA68-based EEE is an EEE, but *libre*", "first EEEs were shipped with Linux and it matters", and other small but nice points. Also, if some people are interested, I wouldn't have any qualms about selling conversion kits with a decent margin and donating part of the revenue to EOMA68. Undoubtedly, I'm biased, mostly in a way that I loved EEEs while I used to use them as my primary PC (2011-2015, I believe), and I'd love to get an EOMA68-based netbook, especially if it's a EEE! So, there might be problems with my reasoning =D When you're making long-term plans for EOMA68, I'm sure you have thought of commercialization and why it's important. My idea doesn't really allow for commercialization, indeed - it's not quite a project you can sell in thousands, neither it is easily manufacturable, it's mostly showcasing EOMA68 and promoting it. Plus, I have no idea about the EEE trademark which was, undoubtedly, filed by Asus. I actually have registered a domain name already, "eeeoma.tk" (from a free domain name registrar), the name seems suitable but I'm not sure we can use it. But then, there's somebody that can sue me for "ZeroPhone", too! To sum up, I think that making an EOMA68-based EEE an important project that can help EOMA68 become more popular, and I can get behind it - I can't do most of the things that could help EOMA68 (and what I can do, wouldn't be efficient to assign to me), but if I can work on something that I can do and I'm actually driven to do (and benefits me, too), I'll be more than happy to help. While this is not the main direction that EOMA68 will go, I believe this is an easily recognizable goal that will help EOMA68 get more recognition and respect. Cheers! Arsenijs From crimier at yandex.ru Tue Jan 23 18:46:07 2018 From: crimier at yandex.ru (=?utf-8?B?UGnEjXVnaW5zIEFyc2VuaWpz?=) Date: Tue, 23 Jan 2018 20:46:07 +0200 Subject: [Arm-netbook] RK3399 In-Reply-To: References: Message-ID: <199801516733167@web26o.yandex.ru> First of all, sorry for the wrong "Subject" of the last email! I'm guessing I should switch off "digest mode" on this ML =) > I wanted a small eoma pc card notebook. That is > why I obtained the asus 7inch eee pc 4g. > When I got the notebook, I took out the > mainboard because I wanted to see how > much space is in the cabinet. There's plenty of space, indeed, that's why modders liked it! Those old Intel systems were big and power-hungry - requiring 3 large chips and active cooling, then, slowly but surely, Moore's law caught up and we are where we are, where even our CPU has another CPU inside it =D > As I mentioned, I wanted to convert the notebook > to an eoma pc card notebook. Because shipping > of the pc card keeps being delayed I have not > done more about it. I mentioned the rk3399 > mainboard, because it maybe would be an > option if the pc card does not get made. First of all, by the time we get this done, or half-done, some computer cards should be available, at least for us =) Then, using a computer card is clearly a more sustainable and future-proof solution. However, that doesn't even matter for now - let's start with something that will work with both EOMA68 and RK3399 devboard, so we have a backup option! > Yes, but we have to set some references. > I am not skilled on electronics. I will have to > move on instructions. That's understandable - I'm willing to spend time walking you through the processes, at least initially =) > Costs may spiral. I am not going to accept > that. If I am asked to buy a 100usd device, I > will answer no. If I am asked to buy a 50usd > device, I will likely answer no. The mainboard should be the most expensive device of them all, whether it's a computer card or a RK3399 mainboard - this one is not something we can avoid. Other parts shouldn't cost any close to that. > If we in a low priced way can get to use the build > in display, that is what we should do. Absolutely. Sourcing a display that has the same size but different interface, then sourcing cables and making our own adapters could be problematic. > My notebook is an asus 7inch eee pc 4g. I do > not know the precise name of the build in > display. They should all be the same - we'll do some testing, too =) > About wifi card, I have small usb ar9271 wifi > cards. They work on debian 9 64bit main. Saying > the source software is available. We should > use an usb ar9271 wifi card. That's a good option, too. However, using SDIO for WiFi (instead of USB) could help us offload the USB bus, which is good for usability (have you heard all the RPi ramblings about RPi USB? it's not even quarter as bad as they make it sound, and this might actually be worse.) Regardless, it shouldn't be hard to support both options. > About sound. I have an usb soundcard. It works > on debian 9 64bit main. > About sdcard reader. I have usb sdcard > readers. They work on debian 9 64bit main. Yep, that's the good part about SD card readers and USB soundcards - they don't usually have many problems, and don't tend to need proprietary firmware. > About storage. My information is, the pc card > will have an sdcard port on the pc card for > storage. That SD card slot, as I understand, will be used for the system drive - so, an expansion slot would be useful. > Turning the keyboard into an usb keyboard is an > important move. I suggest we make turning the > notebook's keyboard into an usb keyboard our > first step. Agreed! My question is - would you be interested in a videocall of some sorts? We could start right off by drawing the PCB, I can show you the basics of KiCad. > About a battery supplying power. I suggest we > wait until we have a notebook, which will > run on a power supply. This is, undoubtedly, a good plan for a start, but it's important to remember that we'll eventually need battery power, and plan it in from the beginning - if we don't, that might cause problems down the road. Regardless, I'll take care of this =) > Maybe this modification of a notebook is of > interest for other people. We should use this > email list. If nobody else minds, then let's do it! From ronwirring at Safe-mail.net Tue Jan 23 21:21:41 2018 From: ronwirring at Safe-mail.net (ronwirring at Safe-mail.net) Date: Tue, 23 Jan 2018 16:21:41 -0500 Subject: [Arm-netbook] RK3399 Message-ID: > Pičugins Arsenijs Thank you for your email. > computer card or a RK3399 mainboard If the pc card gets shipped, then I got one. I want to frame this enterprise a bit more. It must be a hobby thing. You are not obliged to anything and you can skip any time you want. I will not hold it against you. One reason why I will not put large money into it. That way it is not a big deal if we do not succeed. We should do without time frames. Shipping the pc card appears to lay months ahead. > would you be interested in a videocall > of some sorts? On forums I prefer to stay anonymous. If things turn ugly I can walk away. If required can we get by using an irc or another messenger? > drawing the PCB, I can show you > the basics of KiCad For preparation, maybe you could state some links I should have a look on? I should mention I have a solder iron and a multimeter. About my comments on the devices I wanted to express that I prefer less complicated solutions. I was not telling you what solution to select. > important to remember that we'll > eventually need battery power, > and plan it in from the beginning Yes. The asus eee pc 4g's keyboard is model v072462ak1 revision 1.0 gr. The ribbon has 28 wires and the ribbon is 28mm wide. On ebay I have found this ribbon connector https://i.ebayimg.com/images/g/gkgAAOSwZB9Z-YIL/s-l1600.jpg. Should I get one? > 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 ronwirring at Safe-mail.net Tue Jan 23 21:36:48 2018 From: ronwirring at Safe-mail.net (ronwirring at Safe-mail.net) Date: Tue, 23 Jan 2018 16:36:48 -0500 Subject: [Arm-netbook] the potato mainboard Message-ID: https://www.heise.de/make/meldung/Nicht-ganz-frei-Libre-Computer-3946967.html From ronwirring at Safe-mail.net Tue Jan 23 21:46:36 2018 From: ronwirring at Safe-mail.net (ronwirring at Safe-mail.net) Date: Tue, 23 Jan 2018 16:46:36 -0500 Subject: [Arm-netbook] pyra computer Message-ID: https://pyra-handheld.com/boards/threads/getting-closer.82436/ I cannot remember if I previously have posted about the pyra computer. You can notice some of the same problems you see about the pc card. It seems the pyra's cabinet has been made. The cabinet has no pc card port. Has lkcl been in contact with pyra? The cabinet has no pc card slot. Is the pyra's cabinet relevant to the pc card? From vkontogpls at gmail.com Wed Jan 24 01:42:01 2018 From: vkontogpls at gmail.com (Bill Kontos) Date: Wed, 24 Jan 2018 03:42:01 +0200 Subject: [Arm-netbook] Libre RISC-V SoC In-Reply-To: References: Message-ID: On Tue, Jan 23, 2018 at 2:45 PM, Luke Kenneth Casson Leighton wrote: > > do you happen to know if the building blocks - the key high-cpu-load > parts - of HEVC (aka H.265) _happen_ to be the same or near-identical > to MPEG or H.264 and so on? > I don't know. But youtube is pushing vp9 and it's successor av1 now. These are royalty free, while the situation with h.265 is a bit unclear to me in regards to what products need royalties or not. One thing I do know is that h.265 uses blocks of 64x64 pixels for compression vs 16x16 of h.264. > also critical will be a YUV->RGB converter plus scaler... and oh > look! https://opencores.org/project,video_stream_scaler > > if anyone remembers the National Semi Geode LX800 (bought by AMD), > that, staggeringly, could actually do 720p video displayed on > 1600x1200 (with a bit of a tear at times), and could easily do > 1280x720 (without tearing) @ 30fps.... *ENTIRELY IN SOFTWARE*... > because it had a YUV->RGB converter hard macro that took care of the > most expensive bit. > > ... and that was a 500mhz 486 with DDR2 RAM! absolutely incredible. > That sounds impressive indeed. > so, anyway, yes: each little piece of the puzzle will be needed, > saving big chunks of CPU cycles. From laserhawk64 at gmail.com Wed Jan 24 01:48:13 2018 From: laserhawk64 at gmail.com (Christopher Havel) Date: Tue, 23 Jan 2018 20:48:13 -0500 Subject: [Arm-netbook] Libre RISC-V SoC In-Reply-To: References: Message-ID: I have a thin client with a 366MHz AMD Geode. YouTube anything (even @ 240p) almost literally sets it on fire, even with an extremely lightweight Linux distro on it. It doesn't so much skip frames as it does entire 10+sec chunks... and that's with 512MB RAM. I can put a gig in there, sort of... system has a low-level timing issue, I found out from an insider guy -- there is ONE make and model of 1gb PC2700 out there that will work. It's an APacer brand stick and it's absolutely hen's teeth because I've never found it. I've been looking for multiple years now... From lkcl at lkcl.net Wed Jan 24 05:44:47 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 24 Jan 2018 05:44:47 +0000 Subject: [Arm-netbook] Libre RISC-V SoC In-Reply-To: References: Message-ID: On Wed, Jan 24, 2018 at 1:48 AM, Christopher Havel wrote: > I have a thin client with a 366MHz AMD Geode. YouTube anything (even @ > 240p) almost literally sets it on fire, you need to find and compile up the accelerated video extension. last time i did that was 10 years ago. without it the processor will have to do its own YUV-to-RGB conversion and yes it will melt. l. From lkcl at lkcl.net Wed Jan 24 05:51:57 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 24 Jan 2018 05:51:57 +0000 Subject: [Arm-netbook] pyra computer In-Reply-To: References: Message-ID: On Tue, Jan 23, 2018 at 9:46 PM, wrote: > https://pyra-handheld.com/boards/threads/getting-closer.82436/ > > I cannot remember if I previously have posted about the pyra computer. > You can notice some of the same problems you see about > the pc card. > > It seems the pyra's cabinet has been made. The cabinet has no > pc card port. Has lkcl been in contact with pyra? yes lkcl has been in touch with the pyra team. ron can i ask you the favour of not referring to me in the 3rd person? i'm right here!!! l. From cand at gmx.com Wed Jan 24 07:26:16 2018 From: cand at gmx.com (Lauri Kasanen) Date: Wed, 24 Jan 2018 09:26:16 +0200 Subject: [Arm-netbook] Libre RISC-V SoC In-Reply-To: References: Message-ID: <20180124092616.94c024972ff28e0d1982cb0b@gmx.com> On Tue, 23 Jan 2018 20:48:13 -0500 Christopher Havel wrote: > I have a thin client with a 366MHz AMD Geode. YouTube anything (even @ > 240p) almost literally sets it on fire, even with an extremely lightweight > Linux distro on it. It doesn't so much skip frames as it does entire 10+sec > chunks... and that's with 512MB RAM. I can put a gig in there, sort of... > system has a low-level timing issue, I found out from an insider guy -- > there is ONE make and model of 1gb PC2700 out there that will work. It's an > APacer brand stick and it's absolutely hen's teeth because I've never found > it. I've been looking for multiple years now... ..plus you need to use proper software, not Firefox/Chrome/whatever, since those use inefficient methods to be able to overlay and transform the content. Something like mplayer is both fast and likely to support the accelerator(s). - Lauri From hendrik at topoi.pooq.com Wed Jan 24 13:19:27 2018 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Wed, 24 Jan 2018 08:19:27 -0500 Subject: [Arm-netbook] pyra computer In-Reply-To: References: Message-ID: <20180124131927.GA20748@topoi.pooq.com> On Wed, Jan 24, 2018 at 05:51:57AM +0000, Luke Kenneth Casson Leighton wrote: > > yes lkcl has been in touch with the pyra team. > > ron can i ask you the favour of not referring to me in the 3rd > person? i'm right here!!! So am I. The use of second person can be confusing. -- hendrik From ronwirring at Safe-mail.net Wed Jan 24 21:38:42 2018 From: ronwirring at Safe-mail.net (ronwirring at Safe-mail.net) Date: Wed, 24 Jan 2018 16:38:42 -0500 Subject: [Arm-netbook] pyra computer Message-ID: -------- Original Message -------- From: Luke Kenneth Casson Leighton Apparently from: arm-netbook-bounces at lists.phcomp.co.uk To: Eco-Conscious Computing Subject: Re: [Arm-netbook] pyra computer Date: Wed, 24 Jan 2018 05:51:57 +0000 > On Tue, Jan 23, 2018 at 9:46 PM, wrote: > yes lkcl has been in touch with the pyra team. Anything to report? > ron can i ask you the favour of not referring to me in the 3rd > person? i'm right here!!! If I write lkcl, I ask all persons on the email list. > 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 Wed Jan 24 23:09:31 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 24 Jan 2018 23:09:31 +0000 Subject: [Arm-netbook] pyra computer In-Reply-To: References: Message-ID: On Wed, Jan 24, 2018 at 9:38 PM, wrote: > Anything to report? they didn't like the modular concept :) they also really didn't like the standard. plus, the form-factor is a bit small to fit a 5x54x90 card and associated socket. >> ron can i ask you the favour of not referring to me in the 3rd >> person? i'm right here!!! > > If I write lkcl, I ask all persons on the email list. can i recommend making that clear? the list goes to 450+ people and i m not... 450 people :) l. From eaterjolly at gmail.com Fri Jan 26 16:57:21 2018 From: eaterjolly at gmail.com (Jean Flamelle) Date: Fri, 26 Jan 2018 11:57:21 -0500 Subject: [Arm-netbook] the potato mainboard In-Reply-To: References: Message-ID: Considering how complicated and deep the issue of libre firmware can go, I wish they provided more documentation. From lkcl at lkcl.net Fri Jan 26 17:23:40 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 26 Jan 2018 17:23:40 +0000 Subject: [Arm-netbook] the potato mainboard In-Reply-To: References: Message-ID: On Fri, Jan 26, 2018 at 4:57 PM, Jean Flamelle wrote: > Considering how complicated and deep the issue of libre firmware can > go, I wish they provided more documentation. sigh yeah, one of the first things i do when tracking a new board is, create a page and document the compile and board-bringup process. the RK3288 was absolute hell for completely different reasons. the internet is *completely overwhelmed* by ill-informed "wannabe-a-hacker" wordpress sites claiming to have the world's most easiest, most best, "it's"-ism'd documented method of installing {insert free os here}. most of them turn out to be chroot startup methods or keep the UEFI-partition-infested variant of u-boot that google insists on spamming the world with. booting any given processor is actually really really simple and straightforward, but you have to accept that it is at least a three-stage bootstrap process. once you recognise - and accept - that pattern, it's really quite easy to spot, and you don't *need* so much in the way of "documentation". finding the source code for the components (u-boot, linux kernel), *that* tends to be the main challenge, and you have to find the people who can tell you where to find those. in the case of the RK3288, that turned out to be #linux-rockchip on freenode. it's going to vary on a case-by-case basis. l. From richard.wilbur at gmail.com Fri Jan 26 19:43:13 2018 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Fri, 26 Jan 2018 12:43:13 -0700 Subject: [Arm-netbook] Testing: GPIO In-Reply-To: References: Message-ID: On Tue, Jan 23, 2018 at 3:43 AM, Luke Kenneth Casson Leighton wrote: [...] > if it happens again please take a screenshot, it's important as it > means there's a bug in ikiwiki that is essential to report and get > fixed. I added some more details and selected "Save" and after awhile my browser came back with a page that says only: "An error occurred while writing CGI reply" From richard.wilbur at gmail.com Fri Jan 26 19:45:33 2018 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Fri, 26 Jan 2018 12:45:33 -0700 Subject: [Arm-netbook] Testing: GPIO In-Reply-To: References: Message-ID: On Fri, Jan 26, 2018 at 12:43 PM, Richard Wilbur wrote: [...] > I added some more details and selected "Save" and after awhile my > browser came back with a page that says only: > "An error occurred while writing CGI reply" I don't know whether this is a cause of the error but I had forgotten to type anything in the comment section. If that causes problems, sounds like it would be a fine candidate for input data validation. From calmstorm at posteo.de Sat Jan 27 17:35:05 2018 From: calmstorm at posteo.de (zap) Date: Sat, 27 Jan 2018 12:35:05 -0500 Subject: [Arm-netbook] updates from eoma68-a20 Message-ID: I heard you considering only sending 1gb of ram instead of 2gb of ram.  I just wanted to ask, if it comes down to it, if you would be willing to still send 2gb of ram and have uboot preloaded even if it costs a little extra... for those of us who really need the 2gb of ram. 4gb would be nice too of course, but 2gb is probably good enough as long as you don't use virtualization for any reason. :) It also dawns on me, that meltdown does not affect the a20 arm processor...  This makes me think that I really will want what your selling more than I have before.  but yeah, this christmas which is a long way away, I know I have been saying this for a while, but with meltdown I believe I have good reason to say I will purchase one. PS, this applies mostly if the date of the eoma68-a20 libre laptop doesn't have to be sent later then expected... heh... :) I am grateful this opportunity even exists. Oh and for those on the mailing list who don't know this, A20 is apparently immune to meltdown and spectre. Because it is part of armv7.  So yeah, that really motivates me! I still hope for better though in the future... Shakti anyone? ;) From lkcl at lkcl.net Sat Jan 27 18:19:16 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sat, 27 Jan 2018 18:19:16 +0000 Subject: [Arm-netbook] updates from eoma68-a20 In-Reply-To: References: Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Sat, Jan 27, 2018 at 5:35 PM, zap wrote: > I heard you considering only sending 1gb of ram instead of 2gb of ram. > I just wanted to ask, if it comes down to it, if you would be willing to > still send 2gb of ram and have uboot preloaded even if it costs a little > extra... for those of us who really need the 2gb of ram. ok, so anything that goes beyond the available budget is just.... not possible. a mixture of RAM ICs would require an evaluation and a quote on exactly how much it would cost to split - and massively complicate - both the *ordering* of the RAM ICs *and* the production of the PCBs. so it may turn out that consideration of the proposed idea would be MASSIVELY more expensive even than doing all PCBs @ 2GB of RAM. a way to *increase* the budget is therefore the most sensible option to explore and consider. translation: someone needs to find more money. > 4gb would be > nice too of course, but 2gb is probably good enough as long as you don't > use virtualization for any reason. :) 4gb physical RAM addressing has never been possible with any Allwinner processor, ever. bit of an oversight on their part. > It also dawns on me, that meltdown does not affect the a20 arm > processor... correct. > heh... :) I am grateful this opportunity even exists. appreciated > Oh and for those on the mailing list who don't know this, A20 is > apparently immune to meltdown and spectre. Because it is part of armv7. > So yeah, that really motivates me! > > I still hope for better though in the future... Shakti anyone? ;) :) From calmstorm at posteo.de Sat Jan 27 21:11:43 2018 From: calmstorm at posteo.de (zap) Date: Sat, 27 Jan 2018 16:11:43 -0500 Subject: [Arm-netbook] updates from eoma68-a20 In-Reply-To: References: Message-ID: <103e8c25-9d50-ff4f-dd03-6784c1fee817@posteo.de> > ok, so anything that goes beyond the available budget is just.... not > possible. a mixture of RAM ICs would require an evaluation and a > quote on exactly how much it would cost to split - and massively > complicate - both the *ordering* of the RAM ICs *and* the production > of the PCBs. > > so it may turn out that consideration of the proposed idea would be > MASSIVELY more expensive even than doing all PCBs @ 2GB of RAM. > > a way to *increase* the budget is therefore the most sensible option > to explore and consider. translation: someone needs to find more > money. Okay, but when I meant paying a little more, I meant what you would need to do it for one person. Aka on an invididual basis if need be... request + money aka... If more money can be found however, everyone.  Though I dunno how much you would need...... > >> 4gb would be >> nice too of course, but 2gb is probably good enough as long as you don't >> use virtualization for any reason. :) > 4gb physical RAM addressing has never been possible with any > Allwinner processor, ever. bit of an oversight on their part. I would agree > >> It also dawns on me, that meltdown does not affect the a20 arm >> processor... > correct. I thought so... :) From Marqueteur at FineArtMarquetry.com Sat Jan 27 22:10:20 2018 From: Marqueteur at FineArtMarquetry.com (Tor, the Marqueteur) Date: Sat, 27 Jan 2018 12:10:20 -1000 Subject: [Arm-netbook] updates from eoma68-a20 In-Reply-To: <103e8c25-9d50-ff4f-dd03-6784c1fee817@posteo.de> References: <103e8c25-9d50-ff4f-dd03-6784c1fee817@posteo.de> Message-ID: <53226a1e-3b0c-9499-927f-ae52b3bf43e5@FineArtMarquetry.com> On 01/27/2018 11:11 AM, zap wrote: >> a way to *increase* the budget is therefore the most sensible option >> to explore and consider. translation: someone needs to find more >> money. > Okay, but when I meant paying a little more, I meant what you would need > to do it for one person. Aka on an invididual basis if need be... > request + money aka..> > If more money can be found however, everyone.  Though I dunno how much > you would need...... Given that a prototype batch of ten runs $2000 USD, I'd guess this is a floor for the increased cost without considering the component cost. Given the age of the processor and related components, this may be a high bar to reach. If there is interest, however, is it possible to use Crowd Supply or another crowd funding site to see if there is adequate interest in helping cover the additional budget required? I'd certainly be interested in the possibility. >>> It also dawns on me, that meltdown does not affect the a20 arm >>> processor... >> correct. > I thought so... :) I've just been doing some reading. IIUC, Meltdown is specific to Intel for a decade, and maybe a couple of very new/forthcoming processors. Spectre, on the other hand, is much more widespread, but without the Meltdown exploit to leverage a path in, it's very difficult to successfully attack a system. Tor -- Tor Chantara http://www.fineartmarquetry.com/ GPG Key: 2BE1 426E 34EA D253 D583 9DE4 B866 0375 134B 48FB *Be wary of unsigned emails* From lkcl at lkcl.net Sat Jan 27 22:28:14 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sat, 27 Jan 2018 22:28:14 +0000 Subject: [Arm-netbook] updates from eoma68-a20 In-Reply-To: <103e8c25-9d50-ff4f-dd03-6784c1fee817@posteo.de> References: <103e8c25-9d50-ff4f-dd03-6784c1fee817@posteo.de> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Sat, Jan 27, 2018 at 9:11 PM, zap wrote: > Okay, but when I meant paying a little more, I meant what you would need > to do it for one person. oh. ok. well, um... a _lot_. as in, it would be a custom board, done by hand. 10 PCBs tend to cost about $2000 all-in, so $200 would not be unreasonable. basically until you get to QTY 500 or above the setup and teardown costs are so high that companies are reluctant to do anything below 1,000 units. i'm lucky that mike's factory is small enough that he'll consider it. > Aka on an invididual basis if need be... > request + money aka... > > > > If more money can be found however, everyone. Though I dunno how much > you would need...... i really don't know. RAM prices are so mad that suppliers are actually reluctant to find out, because (a) they actually CAN'T get hold of them - as in there AREN'T ANY AVAIALBLE or (b) those that are available are in such demand that they don't want to commit unless you're actually serious and have cash RIGHT now. when i say "there aren't any available" i mean, "demand for apple products has gone so insane that the RAM foundries are so overwhelmed with APPLE's RAM orders that they haven't got TIME to manufacture anything else". l. From laserhawk64 at gmail.com Sat Jan 27 22:35:15 2018 From: laserhawk64 at gmail.com (Christopher Havel) Date: Sat, 27 Jan 2018 17:35:15 -0500 Subject: [Arm-netbook] updates from eoma68-a20 In-Reply-To: References: <103e8c25-9d50-ff4f-dd03-6784c1fee817@posteo.de> Message-ID: Oy, Luke, pardon a bit of an oddball idea -- my specialty, everyone elses' headache, typically -- but if you're desperate enough -- how much would it cost to buy a fat stack of DIMMs with the right chips and hire some bored dude with a hot air machine or reballing station and the skill to use it, to extract what you need and recycle the rest...? I know that's not the, er, usual way of acquiring chips of /any/ kind, but it sounds like we're approaching throw-it-at-the-wall-and-see-what-sticks territory anyways, so I thought I'd offer that one up, see how much glue it has to it :P From lkcl at lkcl.net Sat Jan 27 22:40:24 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sat, 27 Jan 2018 22:40:24 +0000 Subject: [Arm-netbook] updates from eoma68-a20 In-Reply-To: References: <103e8c25-9d50-ff4f-dd03-6784c1fee817@posteo.de> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Sat, Jan 27, 2018 at 10:35 PM, Christopher Havel wrote: > Oy, Luke, pardon a bit of an oddball idea -- my specialty, everyone elses' > headache, typically -- but if you're desperate enough -- how much would it > cost to buy a fat stack of DIMMs with the right chips and hire some bored > dude with a hot air machine or reballing station and the skill to use it, > to extract what you need and recycle the rest...? bleugh :) the problem is they need to be re-balled. as in, the solder balls on the underside completely cleaned off, then a new set added. i mean it can be done, but someone has to evaluate the cost of doing it. l. From laserhawk64 at gmail.com Sat Jan 27 22:45:56 2018 From: laserhawk64 at gmail.com (Christopher Havel) Date: Sat, 27 Jan 2018 17:45:56 -0500 Subject: [Arm-netbook] updates from eoma68-a20 In-Reply-To: References: <103e8c25-9d50-ff4f-dd03-6784c1fee817@posteo.de> Message-ID: On Sat, Jan 27, 2018 at 5:40 PM, Luke Kenneth Casson Leighton wrote: > > the problem is they need to be re-balled. Forgive both naïveté and apparent stupidity (or at least inexperience) -- but why? A conductor conducts, be it a copper trace, an aluminum wire, or a lump of solder in between the two. What's a little solder reuse between friends? From lkcl at lkcl.net Sat Jan 27 23:14:55 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sat, 27 Jan 2018 23:14:55 +0000 Subject: [Arm-netbook] updates from eoma68-a20 In-Reply-To: References: <103e8c25-9d50-ff4f-dd03-6784c1fee817@posteo.de> Message-ID: On Sat, Jan 27, 2018 at 10:45 PM, Christopher Havel wrote: >> the problem is they need to be re-balled. > > > Forgive both naïveté and apparent stupidity (or at least inexperience) -- > but why? A conductor conducts, be it a copper trace, an aluminum wire, or a > lump of solder in between the two. What's a little solder reuse between > friends? the solder balls on BGA and FBGA are specifically calculated to be a size that will spread evenly and create a successful circuit, whilst at the same time being of exactly the right size to support the weight of the IC itself against surface tension and not get so squashed so flat that they cause a short-circuit to the pad next door. when you REMOVE a BGA or FBGA IC from a circuit, that ball had ALREADY been destroyed and obviously needs to be replaced. with a ball of the exact same size. that costs money and time. l. From laserhawk64 at gmail.com Sun Jan 28 00:58:19 2018 From: laserhawk64 at gmail.com (Christopher Havel) Date: Sat, 27 Jan 2018 19:58:19 -0500 Subject: [Arm-netbook] updates from eoma68-a20 In-Reply-To: References: <103e8c25-9d50-ff4f-dd03-6784c1fee817@posteo.de> Message-ID: Replying by phone, usual constraints. Sorry. Your reply makes a lot of sense. I understand better now. That's quite an operation... On Jan 27, 2018 6:15 PM, "Luke Kenneth Casson Leighton" wrote: > On Sat, Jan 27, 2018 at 10:45 PM, Christopher Havel > wrote: > > >> the problem is they need to be re-balled. > > > > > > Forgive both naïveté and apparent stupidity (or at least inexperience) -- > > but why? A conductor conducts, be it a copper trace, an aluminum wire, > or a > > lump of solder in between the two. What's a little solder reuse between > > friends? > > the solder balls on BGA and FBGA are specifically calculated to be a > size that will spread evenly and create a successful circuit, whilst > at the same time being of exactly the right size to support the weight > of the IC itself against surface tension and not get so squashed so > flat that they cause a short-circuit to the pad next door. > > when you REMOVE a BGA or FBGA IC from a circuit, that ball had > ALREADY been destroyed and obviously needs to be replaced. > > with a ball of the exact same size. > > that costs money and time. > > 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 calmstorm at posteo.de Sun Jan 28 00:59:03 2018 From: calmstorm at posteo.de (zap) Date: Sat, 27 Jan 2018 19:59:03 -0500 Subject: [Arm-netbook] updates from eoma68-a20 In-Reply-To: References: <103e8c25-9d50-ff4f-dd03-6784c1fee817@posteo.de> Message-ID: On 01/27/2018 05:28 PM, Luke Kenneth Casson Leighton wrote: > --- > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 > > > On Sat, Jan 27, 2018 at 9:11 PM, zap wrote: > >> Okay, but when I meant paying a little more, I meant what you would need >> to do it for one person. > oh. ok. well, um... a _lot_. as in, it would be a custom board, > done by hand. 10 PCBs tend to cost about $2000 all-in, so $200 would > not be unreasonable. > > basically until you get to QTY 500 or above the setup and teardown > costs are so high that companies are reluctant to do anything below > 1,000 units. i'm lucky that mike's factory is small enough that he'll > consider it. > Hmm... I never realized it was that absurdly high of a price. I would do it don't get me wrong if needed, but yeah... >> Aka on an invididual basis if need be... >> request + money aka... >> >> >> >> If more money can be found however, everyone. Though I dunno how much >> you would need...... > i really don't know. RAM prices are so mad that suppliers are > actually reluctant to find out, because (a) they actually CAN'T get > hold of them - as in there AREN'T ANY AVAIALBLE or (b) those that are > available are in such demand that they don't want to commit unless > you're actually serious and have cash RIGHT now. > > when i say "there aren't any available" i mean, "demand for apple > products has gone so insane that the RAM foundries are so overwhelmed > with APPLE's RAM orders that they haven't got TIME to manufacture > anything else". Hmm... Interesting.  That is insane.  so basically for 2gb of ram it adds 200$ to the price tag or 100$... I am just wondering because 1gb of ram would be how much you would have if you didn't do this. Right? Well how much would that cost you? Don't get me wrong, I will pay 200$ extra if need be, but yeah... I am just curious.  Also, will the ram problem exist whenever shakti processors come out? > 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 Jan 28 01:17:00 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 28 Jan 2018 01:17:00 +0000 Subject: [Arm-netbook] updates from eoma68-a20 In-Reply-To: References: <103e8c25-9d50-ff4f-dd03-6784c1fee817@posteo.de> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Sun, Jan 28, 2018 at 12:59 AM, zap wrote: >> basically until you get to QTY 500 or above the setup and teardown >> costs are so high that companies are reluctant to do anything below >> 1,000 units. i'm lucky that mike's factory is small enough that he'll >> consider it. >> > Hmm... I never realized it was that absurdly high of a price. I would do > it don't get me wrong if needed, but yeah... it's down to the small quantities. >>> Aka on an invididual basis if need be... >>> request + money aka... >>> >>> >>> >>> If more money can be found however, everyone. Though I dunno how much >>> you would need...... >> i really don't know. RAM prices are so mad that suppliers are >> actually reluctant to find out, because (a) they actually CAN'T get >> hold of them - as in there AREN'T ANY AVAIALBLE or (b) those that are >> available are in such demand that they don't want to commit unless >> you're actually serious and have cash RIGHT now. >> >> when i say "there aren't any available" i mean, "demand for apple >> products has gone so insane that the RAM foundries are so overwhelmed >> with APPLE's RAM orders that they haven't got TIME to manufacture >> anything else". > Hmm... Interesting. That is insane. so basically for 2gb of ram it > adds 200$ to the price tag or 100$... yeah. that's if there's only 10 people. but there are 900 people. if half of them are prepared to pay extra, that's fine... but it means i now have to get quotes for 450 with 1gb and 450 with 2gb. that means ONLY an order of 2000 RAM ICs @ 2gb, and ONLY an order of 2000 RAM ICs @ 1gb. that in turn means that i can't use the supplier i was going to use, because he has a MOQ of 5000 units. that in turn pushes the prices up for BOTH SETS OF RAM also the split production will also be much more expensive per unit because now there will be TWO SETS OF SETUP AND TEARDOWN COSTS.... etc. etc. etc. etc. > I am just wondering because 1gb of ram would be how much you would have > if you didn't do this. Right? Well how much would that cost you? > > Don't get me wrong, I will pay 200$ extra if need be, but yeah... I am > just curious. > > Also, will the ram problem exist whenever shakti processors come out? that's about 18-24 months out so we have no way of telling. i was planning to use smartphone-style LPDDR3 x32 RAM ICs. i have a design of a PCB layout i was just going to *cough* copy the pin mapping and *cough* oh look! by a happy coincidence if i pull that SoC out and replace it with a Shakti one it fits perfectly and doesn't need the PCB layout changing *at all*! wow, isn't that an amazing happy coincidence? ... mind you i have to check that it's not a 650-pin monster. i wanted to keep the shakti m-class processor down to below 450 pins. heck i *might* be able to get away with adjusting the tracks a *little* bit (shorter, longer) but DDR3 layout is such a pain it's worth going to some lengths to avoid redoing layouts. l. From calmstorm at posteo.de Sun Jan 28 02:12:29 2018 From: calmstorm at posteo.de (zap) Date: Sat, 27 Jan 2018 21:12:29 -0500 Subject: [Arm-netbook] updates from eoma68-a20 In-Reply-To: References: <103e8c25-9d50-ff4f-dd03-6784c1fee817@posteo.de> Message-ID: <1a934f85-a61b-e2b3-d897-020a3bdce010@posteo.de> >>> i really don't know. RAM prices are so mad that suppliers are >>> actually reluctant to find out, because (a) they actually CAN'T get >>> hold of them - as in there AREN'T ANY AVAIALBLE or (b) those that are >>> available are in such demand that they don't want to commit unless >>> you're actually serious and have cash RIGHT now. >>> >>> when i say "there aren't any available" i mean, "demand for apple >>> products has gone so insane that the RAM foundries are so overwhelmed >>> with APPLE's RAM orders that they haven't got TIME to manufacture >>> anything else". >> Hmm... Interesting. That is insane. so basically for 2gb of ram it >> adds 200$ to the price tag or 100$... > yeah. that's if there's only 10 people. but there are 900 people. > if half of them are prepared to pay extra, that's fine... but it means > i now have to get quotes for 450 with 1gb and 450 with 2gb. > > that means ONLY an order of 2000 RAM ICs @ 2gb, and ONLY an order of > 2000 RAM ICs @ 1gb. > > that in turn means that i can't use the supplier i was going to use, > because he has a MOQ of 5000 units. > > that in turn pushes the prices up for BOTH SETS OF RAM > > also the split production will also be much more expensive per unit > because now there will be TWO SETS OF SETUP AND TEARDOWN COSTS.... > > etc. > > etc. > > etc. > > etc. This sounds very difficult, Well, you would also have to find out how many people want 2gb of ram with a poll or something.  Pity not everyone wants 2gb of ram that badly... ;/ From lkcl at lkcl.net Sun Jan 28 02:40:06 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 28 Jan 2018 02:40:06 +0000 Subject: [Arm-netbook] updates from eoma68-a20 In-Reply-To: <1a934f85-a61b-e2b3-d897-020a3bdce010@posteo.de> References: <103e8c25-9d50-ff4f-dd03-6784c1fee817@posteo.de> <1a934f85-a61b-e2b3-d897-020a3bdce010@posteo.de> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Sun, Jan 28, 2018 at 2:12 AM, zap wrote: > >>>> i really don't know. RAM prices are so mad that suppliers are >>>> actually reluctant to find out, because (a) they actually CAN'T get >>>> hold of them - as in there AREN'T ANY AVAIALBLE or (b) those that are >>>> available are in such demand that they don't want to commit unless >>>> you're actually serious and have cash RIGHT now. >>>> >>>> when i say "there aren't any available" i mean, "demand for apple >>>> products has gone so insane that the RAM foundries are so overwhelmed >>>> with APPLE's RAM orders that they haven't got TIME to manufacture >>>> anything else". >>> Hmm... Interesting. That is insane. so basically for 2gb of ram it >>> adds 200$ to the price tag or 100$... >> yeah. that's if there's only 10 people. but there are 900 people. >> if half of them are prepared to pay extra, that's fine... but it means >> i now have to get quotes for 450 with 1gb and 450 with 2gb. >> >> that means ONLY an order of 2000 RAM ICs @ 2gb, and ONLY an order of >> 2000 RAM ICs @ 1gb. >> >> that in turn means that i can't use the supplier i was going to use, >> because he has a MOQ of 5000 units. >> >> that in turn pushes the prices up for BOTH SETS OF RAM >> >> also the split production will also be much more expensive per unit >> because now there will be TWO SETS OF SETUP AND TEARDOWN COSTS.... >> >> etc. >> >> etc. >> >> etc. >> >> etc. > This sounds very difficult, i don't mind the "difficult" part: what i mind is that the total cost could well be in excess even of doing 2GB RAM for all boards. > Well, you would also have to find out how > many people want 2gb of ram with a poll or something. ... which wouldn't cost that much. my main concern would actually be: we have quite a lot of empirical evidence to suggest that most people don't f*****g well read the f*****g updates. witness the last set of complaints - RIGHT HERE - where people said, "but but you didn't say anything about that!!!" and i pointed them DIRECTLY at MULTIPLE updates which specifically, specifically demonstrated that they had simply not been paying attention. at all. so, sad as it is to have to point it out, i really do not have *any* confidence that people will actually bother to engage with a poll in any meaningful way. > Pity not everyone > wants 2gb of ram that badly... ;/ meh... *sigh*. i just have to deliver something as best as is possible. l. From calmstorm at posteo.de Sun Jan 28 08:40:02 2018 From: calmstorm at posteo.de (zap) Date: Sun, 28 Jan 2018 03:40:02 -0500 Subject: [Arm-netbook] updates from eoma68-a20 In-Reply-To: References: <103e8c25-9d50-ff4f-dd03-6784c1fee817@posteo.de> <1a934f85-a61b-e2b3-d897-020a3bdce010@posteo.de> Message-ID: <1f811294-204e-d223-b5ee-d146150eab10@posteo.de> > ... which wouldn't cost that much. my main concern would actually > be: we have quite a lot of empirical evidence to suggest that most > people don't f*****g well read the f*****g updates. witness the last > set of complaints - RIGHT HERE - where people said, "but but you > didn't say anything about that!!!" and i pointed them DIRECTLY at > MULTIPLE updates which specifically, specifically demonstrated that > they had simply not been paying attention. at all. Hmm...  I have read most of them. Although I may have skimmed through a few. Mostly because they had to do with hdmi which is not my main interest.  Sorry all the same man. > > so, sad as it is to have to point it out, i really do not have *any* > confidence that people will actually bother to engage with a poll in > any meaningful way. > Hm, you may have a point. Its not like you have a forum anyways after all right? and know who knows if they would after that anyways.  I am sorry if I came across as demanding, I just need 2gb of ram at the least for it to be usable on a regular basis for myself.  I never thought I would say this, but screw apple more than even microsoft. ugh... sorry did I say microsoft? I mad malwaresoft and as for apple I meant crapple... If it will help, I will try to at some point send more cash your way. From Marqueteur at FineArtMarquetry.com Sun Jan 28 09:12:50 2018 From: Marqueteur at FineArtMarquetry.com (Tor, the Marqueteur) Date: Sat, 27 Jan 2018 23:12:50 -1000 Subject: [Arm-netbook] updates from eoma68-a20 In-Reply-To: <1f811294-204e-d223-b5ee-d146150eab10@posteo.de> References: <103e8c25-9d50-ff4f-dd03-6784c1fee817@posteo.de> <1a934f85-a61b-e2b3-d897-020a3bdce010@posteo.de> <1f811294-204e-d223-b5ee-d146150eab10@posteo.de> Message-ID: <8ba18ee2-b6d8-8288-7d56-7175fcd86091@FineArtMarquetry.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/27/2018 10:40 PM, zap wrote: > lkcl wrote: >> ... which wouldn't cost that much. my main concern would >> actually be: we have quite a lot of empirical evidence to suggest >> that most people don't f*****g well read the f*****g updates. >> witness the last set of complaints - RIGHT HERE - where people >> said, "but but you didn't say anything about that!!!" and i >> pointed them DIRECTLY at MULTIPLE updates which specifically, >> specifically demonstrated that they had simply not been paying >> attention. at all. > Hmm... I have read most of them. Although I may have skimmed > through a few. Mostly because they had to do with hdmi which is not > my main interest. Unfortunately, if there is more than one topic in an email, post, etc., many people seem incapable of noticing it. Even when it seems they are being paid to read the thing. I don't know of a good solution there. >> >> so, sad as it is to have to point it out, i really do not have >> *any* confidence that people will actually bother to engage with a >> poll in any meaningful way. >> > Hm, you may have a point. Its not like you have a forum anyways > after all right? and know who knows if they would after that > anyways. > > I am sorry if I came across as demanding, I just need 2gb of ram at > the least for it to be usable on a regular basis for myself. IIUC, the current state of affairs is that: 1. The design costs have run high due to issues found in the prototype that was supposedly working after being designed by a competent designer. 2. The time required has similarly run high for the same reason. 3. In that time prices on key components have risen, as much because of a fluke of timing as because of valid price changes. 4. Given current prices, the only known way to make everything work with available resources is to put in lower capacity RAM ICs. While even a dedicated update to backers might get ignored, and it's not ideal in the first place, we obviously have some people prepared to pay significantly more than the price increase to get the 2GB RAM. Should a crowdfunding, all or nothing, be considered to gauge how much people care about the difference in RAM? Tor - -- Tor Chantara http://www.fineartmarquetry.com/ GPG Key: 2BE1 426E 34EA D253 D583 9DE4 B866 0375 134B 48FB *Be wary of unsigned emails* Stop spying: http://www.resetthenet.org/ -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQr4UJuNOrSU9WDneS4ZgN1E0tI+wUCWm2UCgAKCRC4ZgN1E0tI +2TjAJ0S1Vtq9vVZfHknIyLs36USoqPjOQCfT1ABVvj/Gdqqufs+Tdo9CsP6j98= =KIwm -----END PGP SIGNATURE----- From samuel at kodafritt.se Sun Jan 28 11:35:36 2018 From: samuel at kodafritt.se (=?UTF-8?Q?Samuel_Lid=c3=a9n_Borell?=) Date: Sun, 28 Jan 2018 12:35:36 +0100 Subject: [Arm-netbook] updates from eoma68-a20 In-Reply-To: References: <103e8c25-9d50-ff4f-dd03-6784c1fee817@posteo.de> <1a934f85-a61b-e2b3-d897-020a3bdce010@posteo.de> Message-ID: <180baf30-f18f-78d7-8a00-4e90bb681da1@kodafritt.se> On 2018-01-28 03:40, Luke Kenneth Casson Leighton wrote: > ... which wouldn't cost that much. my main concern would actually > be: we have quite a lot of empirical evidence to suggest that most > people don't f*****g well read the f*****g updates. witness the last > set of complaints - RIGHT HERE - where people said, "but but you > didn't say anything about that!!!" and i pointed them DIRECTLY at > MULTIPLE updates which specifically, specifically demonstrated that > they had simply not been paying attention. at all. Is there a reason why the crowdsupply project front page still says 2 GB? I think it would reduce the risk of misunderstandings if the RAM size reduction was mentioned clearly on that page :) > meh... *sigh*. i just have to deliver something as best as is > possible. 2 GB would have been nice, but as someone who has pre-ordered the card I agree it's more important to deliver. And I've always regarded this project as a first step towards fully open hardware. Regards, Samuel From lkcl at lkcl.net Sun Jan 28 12:41:31 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 28 Jan 2018 12:41:31 +0000 Subject: [Arm-netbook] updates from eoma68-a20 In-Reply-To: <1f811294-204e-d223-b5ee-d146150eab10@posteo.de> References: <103e8c25-9d50-ff4f-dd03-6784c1fee817@posteo.de> <1a934f85-a61b-e2b3-d897-020a3bdce010@posteo.de> <1f811294-204e-d223-b5ee-d146150eab10@posteo.de> Message-ID: On Sun, Jan 28, 2018 at 8:40 AM, zap wrote: > Hmm... I have read most of them. Although I may have skimmed through a > few. > Mostly because they had to do with hdmi which is not my main interest. you're one of the small percentage that does. > Hm, you may have a point. Its not like you have a forum anyways after > all right? a phpbb style forum would be an unmitigated disaster for this project, as it would be an indicative sign to average end-users that "everything is perfectly ready, everything will work 100% the moment you get it" which is most definitely NOT the case. > I am sorry if I came across as demanding, not at all. > I just need 2gb of ram at the > least for it to be usable on a regular basis for myself. well, if you're prepared to do help out in a way that benefits more than one person i can make sure you get one of the last remaining 2.7.4 Cards or one of the 2.7.5 pre-production prototypes when they're available. > I never thought I would say this, but screw apple more than even microsoft. it's not apple per se: if people world-wide weren't sleep-walking their oblivious way into giving apple money hand-over-fist.... l. From lkcl at lkcl.net Sun Jan 28 12:53:49 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 28 Jan 2018 12:53:49 +0000 Subject: [Arm-netbook] updates from eoma68-a20 In-Reply-To: <8ba18ee2-b6d8-8288-7d56-7175fcd86091@FineArtMarquetry.com> References: <103e8c25-9d50-ff4f-dd03-6784c1fee817@posteo.de> <1a934f85-a61b-e2b3-d897-020a3bdce010@posteo.de> <1f811294-204e-d223-b5ee-d146150eab10@posteo.de> <8ba18ee2-b6d8-8288-7d56-7175fcd86091@FineArtMarquetry.com> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Sun, Jan 28, 2018 at 9:12 AM, Tor, the Marqueteur wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 01/27/2018 10:40 PM, zap wrote: >> lkcl wrote: >>> ... which wouldn't cost that much. my main concern would >>> actually be: we have quite a lot of empirical evidence to suggest >>> that most people don't f*****g well read the f*****g updates. >>> witness the last set of complaints - RIGHT HERE - where people >>> said, "but but you didn't say anything about that!!!" and i >>> pointed them DIRECTLY at MULTIPLE updates which specifically, >>> specifically demonstrated that they had simply not been paying >>> attention. at all. >> Hmm... I have read most of them. Although I may have skimmed >> through a few. Mostly because they had to do with hdmi which is not >> my main interest. > > Unfortunately, if there is more than one topic in an email, post, etc., > many people seem incapable of noticing it. Even when it seems they are > being paid to read the thing. I don't know of a good solution there. it's ok: right now the project is not targetted 100% at busy average-use-case people. >>> >>> so, sad as it is to have to point it out, i really do not have >>> *any* confidence that people will actually bother to engage with a >>> poll in any meaningful way. >>> >> Hm, you may have a point. Its not like you have a forum anyways >> after all right? and know who knows if they would after that >> anyways. >> >> I am sorry if I came across as demanding, I just need 2gb of ram at >> the least for it to be usable on a regular basis for myself. > > IIUC, the current state of affairs is that: > 1. The design costs have run high due to issues found in the prototype > that was supposedly working after being designed by a competent designer. ok clarification: * 5 years ago the first version we paid USD 10,000 for them to fail to fucking well listen. i said the OUTER dimensions were 54 x 96, sent them the datasheet with the part from china and expected them to read it and communicate with me about the internal PCB dimensions needed to fit into the casework. luckily, when the PCB turned up and was 54x96 mm in size, there were critical flaws which indicated that the JUNIOR pcb engineer given the task had completely fucking well failed to even run the Design Validation Checks. * 4.5 years ago the second version was handed over to a COMPETENT engineer... we were ONLY charged USD 5,000 for this service. i decided that from this point onwards i would do the PCB layout myself. * 4 years ago the HDMI connector utilised on this second revision went END OF LIFE. * 2 years ago the REPLACEMENT HDMI connector went END OF LIFE * 1 year ago yet *ANOTHER* replacement HDMI connector turned out not to be available in reasonable quantities at reasonable prices. * 6 months ago the pressure on legacy TSSOP48 NAND (the A20 having a BOOT ROM that only reads older NAND block sizes / speeds) became too great and i went "fuck it, it's gone". *NONE OF THESE THINGS COULD HAVE BEEN AVOIDED*. you cannot know what you do not know that you do not know. > 2. The time required has similarly run high for the same reason. naturally. > 3. In that time prices on key components have risen, as much because > of a fluke of timing as because of valid price changes. this is the latest development, yes. > 4. Given current prices, the only known way to make everything work > with available resources is to put in lower capacity RAM ICs. we don't know that yet. it is *suspected* that that is the case. > While even a dedicated update to backers might get ignored, and it's > not ideal in the first place, we obviously have some people prepared to > pay significantly more than the price increase to get the 2GB RAM. .... and be prepared to cover the *INCREASED* cost due to reduced quantities but not a reduction in the fixed overheads associated with component sourcing, supply, and PCB production *and* PCB assembly... yes. > Should a crowdfunding, all or nothing, be considered to gauge how much > people care about the difference in RAM? it could... if someone else is prepared to take responsibility for it. i'll be absolutely honest: i'm getting tired of handling this stuff on my own. l. From lkcl at lkcl.net Sun Jan 28 12:55:33 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 28 Jan 2018 12:55:33 +0000 Subject: [Arm-netbook] updates from eoma68-a20 In-Reply-To: <180baf30-f18f-78d7-8a00-4e90bb681da1@kodafritt.se> References: <103e8c25-9d50-ff4f-dd03-6784c1fee817@posteo.de> <1a934f85-a61b-e2b3-d897-020a3bdce010@posteo.de> <180baf30-f18f-78d7-8a00-4e90bb681da1@kodafritt.se> Message-ID: On Sun, Jan 28, 2018 at 11:35 AM, Samuel Lidén Borell wrote: > Is there a reason why the crowdsupply project front page still says 2 > GB? I think it would reduce the risk of misunderstandings if the RAM > size reduction was mentioned clearly on that page :) because we don't know yet - for absolute certain - that it's not available. plus, in the next batch, there will no longer be the pre-production costs, it will be a straight matter of "placing another order with the factory". >> meh... *sigh*. i just have to deliver something as best as is >> possible. > > 2 GB would have been nice, but as someone who has pre-ordered the card I > agree it's more important to deliver. And I've always regarded this > project as a first step towards fully open hardware. appreciated samuel. From maillist_arm-netbook at aross.me Sun Jan 28 15:36:45 2018 From: maillist_arm-netbook at aross.me (Alexander Ross) Date: Sun, 28 Jan 2018 15:36:45 +0000 Subject: [Arm-netbook] updates from eoma68-a20 In-Reply-To: References: Message-ID: <1475fea9-6829-6c05-dc09-0c88b4d15079@aross.me> While 2gb ram would be great, I am wiling to accept compromise. With hope/thinking that i guess finishing first card, means next-gen cpu card could get more focus after the first one is out :D (pending sponsoring i assume). Look forward to lots of ram for that one instead heh :) From adam at vany.ca Sun Jan 28 16:36:19 2018 From: adam at vany.ca (Adam Van Ymeren) Date: Sun, 28 Jan 2018 11:36:19 -0500 Subject: [Arm-netbook] updates from eoma68-a20 In-Reply-To: <1475fea9-6829-6c05-dc09-0c88b4d15079@aross.me> References: <1475fea9-6829-6c05-dc09-0c88b4d15079@aross.me> Message-ID: <1B2939F4-1B96-45E0-ABB0-AEB3CB5315B1@vany.ca> On January 28, 2018 10:36:45 AM EST, Alexander Ross wrote: >While 2gb ram would be great, I am wiling to accept compromise. With >hope/thinking that i guess finishing first card, means next-gen cpu >card >could get more focus after the first one is out :D (pending sponsoring >i >assume). Look forward to lots of ram for that one instead heh :) I think getting to the next gen card is really important. The specifics of this card are really not a big deal in my opinion. It's already a bit outdated, and gets more so with each delay. But that's fine. The big opportunity here is once this card and associated housings is actually in people's hands, then they can experience the upgrade process with the next card comes out. That's the whole point of EOMA68 in the first place. To modularize your computing so upgrades are cheaper, easier and less wasteful. I think people are getting too caught up on how to make the a20 the perfect card, but that misses the big picture. This isn't a one off single board computer, it's a bootstrap of an ecosystem. And rather than try to make the first board perfect, it's more important to just get the first board done and move on to the second and third boards to really get the ecosystem going. From calmstorm at posteo.de Sun Jan 28 16:46:51 2018 From: calmstorm at posteo.de (zap) Date: Sun, 28 Jan 2018 11:46:51 -0500 Subject: [Arm-netbook] updates from eoma68-a20 In-Reply-To: References: <103e8c25-9d50-ff4f-dd03-6784c1fee817@posteo.de> <1a934f85-a61b-e2b3-d897-020a3bdce010@posteo.de> <1f811294-204e-d223-b5ee-d146150eab10@posteo.de> Message-ID: >> Hm, you may have a point. Its not like you have a forum anyways after >> all right? > a phpbb style forum would be an unmitigated disaster for this > project, as it would be an indicative sign to average end-users that > "everything is perfectly ready, everything will work 100% the moment > you get it" which is most definitely NOT the case. I don't always think through what I say I guess... :( > >> I am sorry if I came across as demanding, > not at all. > >> I just need 2gb of ram at the >> least for it to be usable on a regular basis for myself. > well, if you're prepared to do help out in a way that benefits more > than one person i can make sure you get one of the last remaining > 2.7.4 Cards or one of the 2.7.5 pre-production prototypes when they're > available. > > What does this involve though? Just curious... Am I like beta testing or... ? Idk... just curious. Don't get me wrong, I would like to help, of course I would need a monitor and keyboard to use it. Right? heh... I also would need to visit home before I could do any testing.  Because that's where I have my monitor and keyboard... ;) Feburary I may be able to do such a thing. Would that work for you? But yeah, tell me what this entails. From calmstorm at posteo.de Sun Jan 28 16:49:01 2018 From: calmstorm at posteo.de (zap) Date: Sun, 28 Jan 2018 11:49:01 -0500 Subject: [Arm-netbook] updates from eoma68-a20 In-Reply-To: References: <103e8c25-9d50-ff4f-dd03-6784c1fee817@posteo.de> <1a934f85-a61b-e2b3-d897-020a3bdce010@posteo.de> <1f811294-204e-d223-b5ee-d146150eab10@posteo.de> <8ba18ee2-b6d8-8288-7d56-7175fcd86091@FineArtMarquetry.com> Message-ID: <1e452931-5812-6117-9b7e-9fb1a106df38@posteo.de> >> Should a crowdfunding, all or nothing, be considered to gauge how much >> people care about the difference in RAM? > it could... if someone else is prepared to take responsibility for it. > i'll be absolutely honest: i'm getting tired of handling this stuff on > my own. Yes, understandable. Would chris from thinkpenguin have time not to be arrogant or anything, if he has no time or has done enough already, then maybe someone else? I don't know...? Hopefully someone trustworthy. > 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 maillist_arm-netbook at aross.me Sun Jan 28 18:07:33 2018 From: maillist_arm-netbook at aross.me (Alexander Ross) Date: Sun, 28 Jan 2018 18:07:33 +0000 Subject: [Arm-netbook] =?utf-8?q?Can=E2=80=99t_LogIn_To_Wiki=3F?= Message-ID: or is it just me? trying to update home page multiable_devices_diagram image url to new one. as the my stuff is no longer hosted on friends server. new url: http://rhombus-tech.aross.me/multiable_devices_diagram/eoma-68_multiable-devices.v2.320.jpg From lkcl at lkcl.net Sun Jan 28 19:22:03 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 28 Jan 2018 19:22:03 +0000 Subject: [Arm-netbook] updates from eoma68-a20 In-Reply-To: <1B2939F4-1B96-45E0-ABB0-AEB3CB5315B1@vany.ca> References: <1475fea9-6829-6c05-dc09-0c88b4d15079@aross.me> <1B2939F4-1B96-45E0-ABB0-AEB3CB5315B1@vany.ca> Message-ID: folks, gotta do another update, i'm leaving for brussels in 16 hours time. i have about *six* different things / meetings to do from the 2nd-4th, i'm then going to the UK from the 7th to the 20th and back again to Taiwan. i'm hand-couriering the remaining 2.7.4 Cards and the Microdesktop Housings there, and will leave them there and get them sent on. adam i'm thinking of you particularly. l. From adam at vany.ca Sun Jan 28 19:28:32 2018 From: adam at vany.ca (Adam Van Ymeren) Date: Sun, 28 Jan 2018 14:28:32 -0500 Subject: [Arm-netbook] updates from eoma68-a20 In-Reply-To: References: <1475fea9-6829-6c05-dc09-0c88b4d15079@aross.me> <1B2939F4-1B96-45E0-ABB0-AEB3CB5315B1@vany.ca> Message-ID: <4703C7C7-98C2-4100-8181-5DEB791B4E9C@vany.ca> On January 28, 2018 2:22:03 PM EST, Luke Kenneth Casson Leighton wrote: >folks, gotta do another update, i'm leaving for brussels in 16 hours >time. i have about *six* different things / meetings to do from the >2nd-4th, i'm then going to the UK from the 7th to the 20th and back >again to Taiwan. i'm hand-couriering the remaining 2.7.4 Cards and >the Microdesktop Housings there, and will leave them there and get >them sent on. adam i'm thinking of you particularly. > >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 Great! You're doing great work Luke, keep it up! From phil at hands.com Sun Jan 28 21:51:39 2018 From: phil at hands.com (Philip Hands) Date: Sun, 28 Jan 2018 22:51:39 +0100 Subject: [Arm-netbook] =?utf-8?q?Can=E2=80=99t_LogIn_To_Wiki=3F?= In-Reply-To: References: Message-ID: <878tchr6s4.fsf@whist.hands.com> On Sun, 28 Jan 2018, Alexander Ross wrote: > or is it just me? No, it's not just you -- It seems that nginx had a disagreement with fcgiwrap, and got in a huff about it. I think it's all better now, so give it another try. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/ http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg, GERMANY From calmstorm at posteo.de Sun Jan 28 21:54:59 2018 From: calmstorm at posteo.de (zap) Date: Sun, 28 Jan 2018 16:54:59 -0500 Subject: [Arm-netbook] updates from eoma68-a20 In-Reply-To: <4703C7C7-98C2-4100-8181-5DEB791B4E9C@vany.ca> References: <1475fea9-6829-6c05-dc09-0c88b4d15079@aross.me> <1B2939F4-1B96-45E0-ABB0-AEB3CB5315B1@vany.ca> <4703C7C7-98C2-4100-8181-5DEB791B4E9C@vany.ca> Message-ID: On 01/28/2018 02:28 PM, Adam Van Ymeren wrote: > On January 28, 2018 2:22:03 PM EST, Luke Kenneth Casson Leighton wrote: >> folks, gotta do another update, i'm leaving for brussels in 16 hours >> time. i have about *six* different things / meetings to do from the >> 2nd-4th, i'm then going to the UK from the 7th to the 20th and back >> again to Taiwan. i'm hand-couriering the remaining 2.7.4 Cards and >> the Microdesktop Housings there, and will leave them there and get >> them sent on. adam i'm thinking of you particularly. >> >> 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 > Great! You're doing great work Luke, keep it up! I have the same thoughts, Thank you Luke. Keep it up indeed! > _______________________________________________ > 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 Jan 28 22:53:37 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 28 Jan 2018 22:53:37 +0000 Subject: [Arm-netbook] =?utf-8?q?Can=E2=80=99t_LogIn_To_Wiki=3F?= In-Reply-To: <878tchr6s4.fsf@whist.hands.com> References: <878tchr6s4.fsf@whist.hands.com> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Sun, Jan 28, 2018 at 9:51 PM, Philip Hands wrote: > On Sun, 28 Jan 2018, Alexander Ross wrote: >> or is it just me? > > No, it's not just you -- It seems that nginx had a disagreement with > fcgiwrap, and got in a huff about it. https://science.slashdot.org/story/18/01/28/0332207/do-particles-have-consciousness eyy according to that article what you say phil makes *perfect sense*! all "aggregate things" are conscious, therefore nginx, ikiwiki and fcgiwrap are conscious, therefore yes they really can get into a huff. talking or praying to or swearing at your car is now... ok. it's official. science says so ;) l. From Marqueteur at FineArtMarquetry.com Mon Jan 29 02:01:52 2018 From: Marqueteur at FineArtMarquetry.com (Tor, the Marqueteur) Date: Sun, 28 Jan 2018 16:01:52 -1000 Subject: [Arm-netbook] updates from eoma68-a20 In-Reply-To: <1e452931-5812-6117-9b7e-9fb1a106df38@posteo.de> References: <103e8c25-9d50-ff4f-dd03-6784c1fee817@posteo.de> <1a934f85-a61b-e2b3-d897-020a3bdce010@posteo.de> <1f811294-204e-d223-b5ee-d146150eab10@posteo.de> <8ba18ee2-b6d8-8288-7d56-7175fcd86091@FineArtMarquetry.com> <1e452931-5812-6117-9b7e-9fb1a106df38@posteo.de> Message-ID: <4162c97d-27d6-540e-4f9b-0d4b1fe0b7a5@FineArtMarquetry.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/28/2018 06:49 AM, zap wrote: > lkcl wrote: >> Tor wrote: >>> Should a crowdfunding, all or nothing, be considered to gauge >>> how much people care about the difference in RAM? >> it could... if someone else is prepared to take responsibility >> for it. i'll be absolutely honest: i'm getting tired of handling >> this stuff on my own. > Yes, understandable. Would chris from thinkpenguin have time not to > be arrogant or anything, if he has no time or has done enough > already, then maybe someone else? I don't know...? Hopefully > someone trustworthy. I suspect this means "someone following the list". Sorry, but that won't be me. I'll contribute, I've got way too much online promotion that I should be doing but aren't because I don't like doing that in the first place. For now, it sounds like it's a case of waiting to see where things are after the latest prototypes come in. FWIW, I agree with what Adam said. Get this one out and delivered with what can be managed so it can be seen in the real world. Then stop putting effort into these near-EOL components and get to the next, better card. Thank you for all the effort you've poured into this project, Luke. Tor - -- Tor Chantara http://www.fineartmarquetry.com/ GPG Key: 2BE1 426E 34EA D253 D583 9DE4 B866 0375 134B 48FB *Be wary of unsigned emails* Stop spying: http://www.resetthenet.org/ -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQr4UJuNOrSU9WDneS4ZgN1E0tI+wUCWm6AiQAKCRC4ZgN1E0tI +5QoAJ9FWtwaWXfGaPfK74S0Ik9qYnYLqgCfTouFTXAg0oxVuuyYGCeRKXaMs38= =yfNR -----END PGP SIGNATURE----- From lkcl at lkcl.net Mon Jan 29 02:25:48 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 29 Jan 2018 02:25:48 +0000 Subject: [Arm-netbook] updates from eoma68-a20 In-Reply-To: <4162c97d-27d6-540e-4f9b-0d4b1fe0b7a5@FineArtMarquetry.com> References: <103e8c25-9d50-ff4f-dd03-6784c1fee817@posteo.de> <1a934f85-a61b-e2b3-d897-020a3bdce010@posteo.de> <1f811294-204e-d223-b5ee-d146150eab10@posteo.de> <8ba18ee2-b6d8-8288-7d56-7175fcd86091@FineArtMarquetry.com> <1e452931-5812-6117-9b7e-9fb1a106df38@posteo.de> <4162c97d-27d6-540e-4f9b-0d4b1fe0b7a5@FineArtMarquetry.com> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Mon, Jan 29, 2018 at 2:01 AM, Tor, the Marqueteur wrote: > I suspect this means "someone following the list". Sorry, but that > won't be me. I'll contribute, I've got way too much online promotion > that I should be doing but aren't because I don't like doing that in > the first place. not a problem. > For now, it sounds like it's a case of waiting to see where things are > after the latest prototypes come in. yes. > FWIW, I agree with what Adam said. Get this one out and delivered with > what can be managed so it can be seen in the real world. yehyeh > Then stop > putting effort into these near-EOL components and get to the next, > better card. ngggh > Thank you for all the effort you've poured into this project, Luke. appreciated tor - and everyone else who's been so encouraging. l. From chadvellacott at sasktel.net Mon Jan 29 03:28:07 2018 From: chadvellacott at sasktel.net (chadvellacott at sasktel.net) Date: Sun, 28 Jan 2018 21:28:07 -0600 Subject: [Arm-netbook] Crowsupply update In-Reply-To: References: <132A1FA8-9EE8-413C-8DFD-D9966046CF6D@gmail.com> Message-ID: <57ab3bd0-d355-b29b-c92d-5c253bc910c0@sasktel.net> On 18.1.8 16:9, Luke Kenneth Casson Leighton wrote: > On ~, [called month 1, day]~ 8, 2018 at 9:22 PM, Richard Wilbur wrote: > >> One downside of the 2.7.4 board at this point is the changes in capacitor pricing that have been ameliorated only on version 2.7.5. Here's hoping the 2.7.5 board works! > > darn yeah i'd forgotten about the implications of the price-hike. whoops. > So, if 2.7.5 is found to have a problem, then it might be cheaper to solve that, than to "fall back" to 2.7.4? From lkcl at lkcl.net Mon Jan 29 03:37:25 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 29 Jan 2018 03:37:25 +0000 Subject: [Arm-netbook] Crowsupply update In-Reply-To: <57ab3bd0-d355-b29b-c92d-5c253bc910c0@sasktel.net> References: <132A1FA8-9EE8-413C-8DFD-D9966046CF6D@gmail.com> <57ab3bd0-d355-b29b-c92d-5c253bc910c0@sasktel.net> Message-ID: On Mon, Jan 29, 2018 at 3:28 AM, wrote: > So, if 2.7.5 is found to have a problem, then it might be cheaper to > solve that, than to "fall back" to 2.7.4? i finally managed to pin mike down for long enough to get some estimates for the capacitors - we estimated it is around $2.50 where it was around $0.50 last year. i previously thought it would be $5 to $8. l. From eaterjolly at gmail.com Mon Jan 29 13:14:25 2018 From: eaterjolly at gmail.com (Jean Flamelle) Date: Mon, 29 Jan 2018 08:14:25 -0500 Subject: [Arm-netbook] =?utf-8?q?Can=E2=80=99t_LogIn_To_Wiki=3F?= In-Reply-To: References: <878tchr6s4.fsf@whist.hands.com> Message-ID: On 1/28/18, Luke Kenneth Casson Leighton wrote: > eyy according to that article what you say phil makes *perfect > sense*! all "aggregate things" are conscious tehehe, I believe that belief is called animism and it's the inverse of deism. To say every body of mass possesses spirit with a weaker influence if inanimate than animate bodies, but also with a different influence. A spirit which makes the lilies grow, for an animist, won't also be a ghost that can throw a book. Though nothing is to say book throwing ghosts can't communicate with lily growing mushi (japanese: "master spirit" implying "master of a specific domain" not "master of spirits"). From eaterjolly at gmail.com Mon Jan 29 16:46:13 2018 From: eaterjolly at gmail.com (Jean Flamelle) Date: Mon, 29 Jan 2018 11:46:13 -0500 Subject: [Arm-netbook] New Economics Wikipage Message-ID: I'm starting the new page to address ideas on how to incent more to support the project. Since cryptocurrency was a recent hot-topic and some appreciated my input there, I'll be starting with a brief rundown of why the topic is complicated and might one start if they want to deep dive into it. I don't want to give my opinion on which currencies we should accept, even standard ones, because the issue is so deep I'd rather help others break into the conversation. Mindshare is really crucial here, because this defines all-in-all the people the project supports, how much the project supports them, and who will be incent to support the project as a result. We don't want to goad people into spreading word, sharing references, and funding EOMA or FLOSS. We want to play nice and win their hearts then only after recognizing we've won them over convince them to do those things. The level of disclosure this mailing-list demonstrates such impeccable willingness to abide that principle, that is what really won me into participating. - Aside, I'm still going to be on and off contributing to the "proposed best practices" page. I would like to start with examples of what I consider pretty impressive projects. I am also interested in liberating CHIP, but I want to get a more thorough understanding of electronic circuit firmware before I move forward. As is important to say, I'd rather do well or have not done at all. From richard.wilbur at gmail.com Tue Jan 30 03:35:30 2018 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Mon, 29 Jan 2018 20:35:30 -0700 Subject: [Arm-netbook] updates from eoma68-a20 In-Reply-To: References: <1475fea9-6829-6c05-dc09-0c88b4d15079@aross.me> <1B2939F4-1B96-45E0-ABB0-AEB3CB5315B1@vany.ca> Message-ID: On Jan 28, 2018, at 12:22, Luke Kenneth Casson Leighton wrote: > > folks, gotta do another update, i'm leaving for brussels in 16 hours > time. i have about *six* different things / meetings to do from the > 2nd-4th, i'm then going to the UK from the 7th to the 20th and back > again to Taiwan. Best wishes with all the travel and meetings. > i'm hand-couriering the remaining 2.7.4 Cards and > the Microdesktop Housings there, and will leave them there and get > them sent on. adam i'm thinking of you particularly. Are there enough 2.7.4 cards and microdesktop housings that I could buy one of each to use for test development and software integration/porting? I know we reworked the HDMI layout and changed the connector. You also changed a lot of the power supply decoupling capacitors. What other differences were there between 2.7.4 and 2.7.5? From richard.wilbur at gmail.com Tue Jan 30 04:06:49 2018 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Mon, 29 Jan 2018 21:06:49 -0700 Subject: [Arm-netbook] updates from eoma68-a20 In-Reply-To: References: <1475fea9-6829-6c05-dc09-0c88b4d15079@aross.me> <1B2939F4-1B96-45E0-ABB0-AEB3CB5315B1@vany.ca> Message-ID: <84BCF521-D7FF-4902-941C-32D53F6729F5@gmail.com> Sent from my iPhone On Jan 29, 2018, at 20:35, Richard Wilbur wrote: > Are there enough 2.7.4 cards and microdesktop housings that I could buy one of each to use for test development and software integration/porting? So I'd be interested in: Libre Tea Card (v2.7.4), $65 on CrowdSupply (prototypes typically more expensive, please let me know how much) Microdesktop Housing, $55 on CrowdSupply PCMCIA/EOMA68 Breakout Board, $20 on CrowdSupply USB + HDMI Cable Set for Standalone Operation, $15 on CrowdSupply Should I (pre-?)order them on CrowdSupply? What arrangements will work (shipping, et cetera)? I realize some of these may not be currently available. From phil at hands.com Tue Jan 30 22:01:06 2018 From: phil at hands.com (Philip Hands) Date: Tue, 30 Jan 2018 23:01:06 +0100 Subject: [Arm-netbook] Exclave -- Factory Test Infrastructure Message-ID: <87wozzovkt.fsf@whist.hands.com> Hi, I just came across this: http://exclave.io/ as mentioned in this LCA2018 talk: https://www.youtube.com/watch?v=pcyuzB3qLVo and thought that it might be useful for testing EOMA boards. It's cute, as it lets you write tests in whatever works for you, and just pays attention to the last line of output, and the return code. You can knock up a shell script, say, and if you can run it on the command line and get it to work, then exclave can run it for you. This is what is used to run the factory test for Bunnie's chibitronics LoveToCode microcontroller boards, among other things. BTW The LCA talk includes some handy tips on how to make such tests work for factory workers who are not likely to read English, nor to have a lot of time/concentration spare. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/ http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg, GERMANY From lkcl at lkcl.net Tue Jan 30 22:18:21 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 30 Jan 2018 22:18:21 +0000 Subject: [Arm-netbook] Exclave -- Factory Test Infrastructure In-Reply-To: <87wozzovkt.fsf@whist.hands.com> References: <87wozzovkt.fsf@whist.hands.com> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Tue, Jan 30, 2018 at 10:01 PM, Philip Hands wrote: > Hi, > > I just came across this: > > http://exclave.io/ > > as mentioned in this LCA2018 talk: > > https://www.youtube.com/watch?v=pcyuzB3qLVo > > and thought that it might be useful for testing EOMA boards. > > It's cute, as it lets you write tests in whatever works for you, and > just pays attention to the last line of output, and the return code. nice! thanks phil. the test advice for factory workers is particularly useful From j.neuschaefer at gmx.net Wed Jan 31 06:33:31 2018 From: j.neuschaefer at gmx.net (Jonathan =?utf-8?Q?Neusch=C3=A4fer?=) Date: Wed, 31 Jan 2018 07:33:31 +0100 Subject: [Arm-netbook] Devicetree discussion Message-ID: <20180131063331.4ywev56uss3d2dvq@latitude> Hi, I've created a page on the wiki to collect some information about devicetree, so the exact scheme of devicetree support for EOMA68 housings can be worked out: http://rhombus-tech.net/devicetree/ Feel free to extend/correct/discuss it. Thanks, Jonathan Neuschäfer From lkcl at lkcl.net Wed Jan 31 17:31:37 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 31 Jan 2018 17:31:37 +0000 Subject: [Arm-netbook] Devicetree discussion In-Reply-To: <20180131063331.4ywev56uss3d2dvq@latitude> References: <20180131063331.4ywev56uss3d2dvq@latitude> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Wed, Jan 31, 2018 at 6:33 AM, Jonathan Neuschäfer wrote: > Hi, > > I've created a page on the wiki to collect some information about > devicetree, so the exact scheme of devicetree support for EOMA68 > housings can be worked out: > > http://rhombus-tech.net/devicetree/ > > Feel free to extend/correct/discuss it. ya looks pretty damn sensible / accurate. i would like the ID to be the same as for USB: manufacturer : device. also from a *lot* of experience on data formats an upwards-negotiation, i'd like to design something that involves "capabilities" for the format that will *always* be backwards-compatible. once a data-format is defined there will be *NO* changing it, even if the data has to be stored more than once in different formats. l. From maillist_arm-netbook at aross.me Wed Jan 31 17:46:37 2018 From: maillist_arm-netbook at aross.me (Alexander Ross) Date: Wed, 31 Jan 2018 17:46:37 +0000 Subject: [Arm-netbook] Alt Webpage & Logo Combo Message-ID: http://rhombus-tech.aross.me/webpagealt/ more of alt homepage but felt like calling it generic webpage instead. its a start, lots to do. using a designed i started for something else so its has ref to a background image that dont exist, etc. css needs more work but its taking the beginnings of a shape :) I combined to logos people made and also made some little mods of my own. i feel quite happy with the outcome :) feedback good to hear, what ya would like to do , how ya feel.. should really put efforts into modding wiki page... but this fresh start would have a diff outcome than fitting around existing wiki design... but yea i think i should face up to having ago at wiki css... just dont feel like it currently... so i thought i’d see how this goes. idk if ill manage to do any more... i guess ill see if i get inspired some more and rev up to it :) I would really like some/to get more photos of the cards and housings to play about making some pics that help people to go "arr i get it". As they browse and scroll down :) From lkcl at lkcl.net Wed Jan 31 18:35:43 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 31 Jan 2018 18:35:43 +0000 Subject: [Arm-netbook] Alt Webpage & Logo Combo In-Reply-To: References: Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Wed, Jan 31, 2018 at 5:46 PM, Alexander Ross wrote: > http://rhombus-tech.aross.me/webpagealt/ > more of alt homepage but felt like calling it generic webpage instead. eye-burning colours! coooool :) what does it look like with the blue and the purple reversed? > its a start, lots to do. using a designed i started for something else > so its has ref to a background image that dont exist, etc. css needs > more work but its taking the beginnings of a shape :) i prefer the square letters / numbers, all in a line. From lkcl at lkcl.net Wed Jan 31 18:49:16 2018 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 31 Jan 2018 18:49:16 +0000 Subject: [Arm-netbook] Exclave -- Factory Test Infrastructure In-Reply-To: <87wozzovkt.fsf@whist.hands.com> References: <87wozzovkt.fsf@whist.hands.com> Message-ID: linked here on http://rhombus-tech.net/allwinner_a10/testing/ thanks phil