arm-netbook

arm-netbook@lists.phcomp.co.uk

1082 discussions

PCB Collaboration and Revision
by mike.valk＠gmail.com 14 Aug '17

14 Aug '17

https://hackaday.com/2011/10/14/hardware-version-control-using-visual-diff/ http://www.evilmadscientist.com/2011/improving-open-source-hardware-visual-… For the next project

3 4

riki200 revision.... 2 going on 3
by Luke Kenneth Casson Leighton 14 Aug '17

14 Aug '17

ok so the intermediary etch-a-sketch concept "works", but i'm definitely going to go for the design you came up with, benson: pulley'd ultimaker-2. actually.... reviewing the forum messages the mistake that i made was in *not* following what you originally suggested! http://forums.reprap.org/read.php?177,767087,780154#msg-780154 putting the 2 belts back-to-back round the idler and GT2, it's now obvious that the inner and outer belts travel different lengths round the arcs... so you get "pulling". whoops. anyway out with that - i'll begin on the pulley-augmented ultimaker style. l.

1 0

severe systemd bugs (two of them)
by Luke Kenneth Casson Leighton 12 Aug '17

12 Aug '17

https://it.slashdot.org/story/17/07/03/0343258/severe-systemd-bug-allowed-r… two years. that's how long one of these bugs has been in systemd. *via a remote network*. what the hell is an init system doing being accessible *via DNS queries*? for anyone who still believes that systemd is okay to use and deploy, and that there exist "great advantages that outweigh the risks", are you *finally* getting the message now? dozens of distros, millions of people, all affected by the irresponsible act of switching "en-masse" to a single over-reaching init system which is developed in a fashion that is not being properly managed or controlled. i do not understand why people do not understand this. l.

20 87

Eoma68 update
by Joseph Lira 12 Aug '17

12 Aug '17

Hello >From your last update I havent seen an update as to how the os will be delivered/installed can you give an update? Will it be an SD card? Also when do you plan to start shipping boards the crowdfunding says nov of this year is that still correct? Im asking becuase i wanted to use the eoma68 to be a little low power stream box actually can this be done? Or i wanted to replace my original pi that runs pi-hole I been very temped to buy a new raspberry pi 3 for streaming or a tiny intel nuc to do the same, but i held of because i truly want to support your project

7 10

HDMI High-Frequency Layout: Recommendations
by Andrew Bolin 11 Aug '17

11 Aug '17

>> Also I'd personally not use curved wriggles. HF signals travel in a >> straight direction. With curves they start diffracting and start >> bouncing cross each other and might start to radiate or echo back. > > mmmmm.... *stress*! anyone else feel the curves are "Bad"? No. You've followed a bunch of very good advice about length matching, impedance etc. It looks like you've generally kept the pairs parallel through the curves, which is great. If you have an easy option in your software to switch from 45 degree corners to smooth curves, I would do it - if there's not, don't worry. >> If tight for space you can use 90% corners with a chamfered outer >> edge. I suppose the chamfer acts like a mirror. The chamfer is there for impedance reasons, it's not a mirror, and note that a curve is preferred. You also run the risk of manufacturing problems by doing the chamfer - you're already at the minimum trace width, right? As you've previously said, the old layout was further away from best practices, and *it worked*.

2 1

my favourite dilbert... evvah!
by Luke Kenneth Casson Leighton 10 Aug '17

10 Aug '17

http://dilbert.com/strip/1994-02-06 still beautifully relevant today....

1 0

Side-Topic: Liberating PocketCHIP
by John Luke Gibson 08 Aug '17

08 Aug '17

Since it seems like a trivially simple task that for some reason no one has taken up, I would like to take the opportunity to exercise a learning experience and simultaneously benefit the community, by liberating PocketCHIP by deblobbing the source and re-compiling. Browsing the archives to see if this had been talked about before, I find it very incredibly humourous I got name dropped on the mailing list by Parobath: > Date: Sat, 29 Oct 2016 20:13:10 +0200 > From: Parobalth <parobalth(a)gmail.com> > To: arm-netbook(a)lists.phcomp.co.uk > Subject: closed-source BootROM and RYF certification > User-Agent: Mutt/1.5.23 (2014-03-12) > > At the forum of NextThing Chip is a thread about Chip and a > possible RYF certification. I wrote there that I think that is unlikely > to happen and linked to https://www.crowdsupply.com/eoma68/micro-desktop/updates/fsf-ryf-background. > Then someone else mentioned that a closed-source BootROM is used for Chip. > Another guy with username "eaterjolly" wrote about this BootROM: "The same type of SOC is > used for the EOMA croud project which is vying for ryf-endorsement quite > openly [...]" > > You can find the forum thread here: > https://bbs.nextthing.co/t/ntc-thoughts-on-ryf-endorsement/4490 > > Because they use Discourse to power their forum which relies heavily on > JavaScript I also attach a Pdf version of the forum post. > > I wonder if the mentioned statements are correct and how it relates to > the RYF certification of the EOMA68-A20 Libre Tea card. > > kind regards > Paro Like reading that URL, I was like? didn't I start that thread? then I re-read the post and noticed I was quoted in the email xD I didn't participate in the list back then, cause I was afraid my ignorance would be spurred, of course I know that not to be true in hindsight. Feels a bit melodramatic being name dropped on a linux mailing list, usually you only see legends get mentioned by name when they aren't around xD Anywhoo, I more or less just wanted to start this thread because I wanted to know if any one could point out anything that would need be removed besides the wifi firmware. I searched the sunix-uboot repository on github for the word blob and got a few interesting hits for the code in the folder binman: https://github.com/linux-sunxi/u-boot-sunxi/search?q=blob Particularly in files mentioning the devil: "# Entry-type module for Intel Chip Microcode binary blob" I suppose this is just another aspect of mainlining, meant to be parsed out once it's discovered that there are no such blobs in the kernel, but personally I'd feel more comfortable with a script removing these sections of the code altogether. If I had been actually reading the list digests back when I could have posted more accurate information in that thread rather than just guessing. Well, I suppose I can do so now. How humorous it is though too that I've run into the same 40k file limit? Small tiny things suggesting the work of the vicissitudes of fate, much like deja vu in the matrix.

17 43

Injection Molding Cost
by Bill Kontos 05 Aug '17

05 Aug '17

Hi, I remember luke mentioning in the past that injection molding would be too expensive for such a low-volume project. However I found this project from crowd supply that is using molds for production on a total of ~3800 pledges https://www.crowdsupply.com/ugl/ultimate-hacking-keyboard/updates/2198 The numbers don't make any sense given the ~100k cost luke has mentioned in the past( the 2 keyboard halves have different designs). What am I getting wrong here ? The factory they will be using is located in Europe.

2 1

HDMI High-Frequency Layout: Impedance
by Richard Wilbur 04 Aug '17

04 Aug '17

HDMI Layout Notes for EOMA68 Cards by Richard Wilbur Impedance Trace Impedance: 100 Ohm +/-15% differential[11][12], 55 Ohm +/-15% single-ended[3] (90 Ohm +/-15% differential, 50 Ohm +/-15% single-ended[3]) There seems to be some small disagreement between sources on the differential trace impedance for HDMI high-speed signals. Chrontel[11], Texas Instruments[12], and JAE[13] all quote 100 Ohm but with different tolerances--Chrontel +/-10%, Texas Instruments +/-15%, JAE +/-25% (in connector area[13])--while Toradex[3] quotes the goal as 90 Ohm +/-15%. These ranges overlap but the normal variation in manufacturing is more likely to exceed the limits of the acceptable range if we design to the wrong goal! 90 Ohm +/-15% = [76.5, 103.5] Ohm 100 Ohm +/-15% = [85, 115] Ohm It seems the consensus is on 100 Ohm +/-15% for the differential impedance. Toradex mentions something else which helps with the selection of design parameters: "The differential impedance is always smaller than twice the single-ended impedance" Z(differential) < 2 * Z(single-ended)[14] => Z(single-ended) > Z(differential) / 2 Thus, if we wish to have Z(differential) = 100 Ohm +/-15%, we should choose the single-ended impedance such that Z(single-ended) > (100 Ohm +/-15%) / 2 = 50 Ohm +/-7.5% Toradex suggests 55 Ohm single-ended impedance to coincide with 100 Ohm differential impedance.[15] In order to model and calculate expected impedance we need to describe the geometry of the arrangement of traces, reference planes, and dielectric layers in the PCB. PCB Dimensions (not drawn to scale or even to correct aspect ratio): ______ ^ T (thickness of copper in signal layer) v _______________________________ ^ H (thickness or height of insulator) v _______________________________ reference plane (GND or Power) _______________________________ The 6-layer FR-4 PCB chosen for EOMA68-A20 has the following characteristic dimensions: total thickness of PCB = 1.2mm ~= 47.3mil H(height of dielectric between outer copper layer and adjacent reference plane) = 6.4mil copper cladding = 1oz min{W(trace width)} = 5mil min{S(trace-to-trace space)} = 5mil min{diameter(plated through-hole vias)} = 6mil diameter(via surround/pad) = 12mil To calculate the thickness (T) of 1 ounce copper requires several conversion factors and the density of copper. "1 ounce copper" refers to the thickness of 1 ounce (avoirdupois versus troy) of copper spread over 1 square foot. There is at least one web site which purports to calculate the thickness in mils of a particular weight of copper cladding[16], but they use some pretty heavy approximations for otherwise well-known conversion factors and conclude that 1.37 mil = 1 oz Cu. I used the standard unit conversion factors as shown below: Given: Areal density = 1 oz Cu / ft^2 Exact conversion factors: 1 (avoirdupois) oz = 28.349523125g [17] 1 ft^2 = (1ft * 12in/1ft * 2.54cm/1in)^2 = (30.48cm)^2 Empirical value: Density (Cu pure) rho = 8.96 g / cm^3 [18][19: CRC, LNG] Calculation: T = areal density(given) * conversion(oz->g) / (volume density) / conversion(ft->cm)^2[16] T = 1 oz Cu / ft^2 * 28.349523125g / 1 oz * 1 cm^3 Cu / 8.96 g Cu * 1 ft^2 / (30.48cm)^2 = 0.003405711cm Cu = 0.03405711mm * 1in / 25.4mm * 1000mil / 1in = 1.34mil Cu (Using 8.92 gCu / cm^3 [19: WEL] => T = 1.35mil Cu) The most well-attested value for copper's density was 8.96 g/cm^3 yielding T = 1.34mil Cu. Illustrating the sensitivity of the calculation to variation of parameters, the minority density value of 8.92 g/cm^3 yielded T = 1.35mil Cu. Microstrip PCB Dimensions (not drawn to scale or even to correct aspect ratio): <-W-><--- S ---><-W-><----- D -----> __IIIII___________IIIII___________________IIIII Signal:+ - x W = design width of trace S = spacing between traces of differential pair (+,-) D = spacing to unrelated signal "x" (another pair, ground shield, etc.) Texas Instruments gives some equations to help calculate trace geometries for 100 Ohm differential impedance.[12] Z(differential) = 2 * Z(single-ended) * (1 - 0.48 * exp(-0.96 * S / H)) Z(single-ended) = 88.75/sqrt(relative permittivity + 1.47) * ln(5.97 * H / (0.8 * W + T)) Since the board material and manufacturing process specify the parameters: relative permittivity(FR-4) = 4.4[1] H = 6.4mil T = 1.34mil and the HDMI standard specifies: Z(differential) = 100 Ohm we have two equations in three unknowns: Z(single-ended), W, S Given the guidance that Z(single-ended) > 50 Ohm, we can solve the second equation for W(Z(single-ended)), W<mils> = 7.463 * H * exp(-Z(single-ended) * sqrt(relative permittivity + 1.47) / 88.75) -1.25 * T Then select a value for Z(single-ended), turn the crank and see what value of W we come up with. After looking at the result we may decide to select a different value for Z(single-ended) and calculate the concomitant W in order to find a routable trace width and a usable single-ended impedance. Let's try this for Z(single-ended) = 55 Ohm. W(Z(single-ended) = 55 Ohm) = 7.463 * 6.4mil * exp (-55 Ohm * sqrt(4.4 + 1.47)/88.75) - 1.25 * 1.34mil = 8.97mil Then we can solve the equation that gives differential impedance for S, plug in our values for single-ended and differential impedance and see what trace-spacing (S) we get. S = -H / 0.96 * ln((2 * Z(single-ended) - Z(differential)) / 0.96 / Z(single-ended)) S(Z(single-ended) = 55 Ohm) = -6.4mil / 0.96 * ln((2 * 55 Ohm - 100 Ohm) / 0.96 / 55 Ohm) = 11.1mil The distance, D, to adjacent signal pairs and shield traces is suggested to be, D >= 3 * S[12] with the caveat that running a ground shield trace on only one side can create an imbalance that increases EMI. "Ground trace shields should have a scattering of vias to the underlying ground plane."[12] Z(single-ended) W<mil> S<mil> min{D}<mil> <Ohm> 51 10.2 21.3 63.9 55 8.97 11.1 33.3 60.1 7.58 7.00 21.0 64.6 6.51 5.02 15.1 Table of single-ended impedances and associated trace width and spacing.[These numbers are based on formulas which are approximations with error bounds of +/-10%.][12] Here we can see the effect of changing the single-ended impedance on width and spacing of traces in a differential pair of given differential impedance. By raising the single-ended impedance we reduced both the width of the traces and also the spacing. The other outgrowth is that the common-mode rejection is improved by lowering the single-ended impedance of the traces. Common-mode signal stems from other signals (EMI) coupled into the traces, uncompensated intra-pair skew, and imperfect differential signal drivers at the source. Common-mode signal will radiate (EMI) from circuit board traces. So we have a trade-off to consider: 1. We can minimize common-mode signal by lowering single-ended impedance which increases the trace width and spacing for a given differential impedance. 2. This is limited by the fact that, for a microstrip differential pair, the single-ended impedance is greater than half the differential impedance. Looking at the single-ended impedance values, the difference between 51 Ohm and 64.6 Ohm is an increase of less than 30% and thus won't drastically change the common-mode performance, so my inclination if you're strapped for space would be to use the higher single-ended impedance with 6.5mil wide traces spaced apart 5mils and try for 15mils between pairs. Reviewing with reference to TI's "Routing Guidelines"[20]: i. Use the smallest trace spacing possible, which usually is specified by your PCB vendor: in our case 5 mils ii. Make sure the geometries obey: a. S < H; (S = 5mil) < (H = 6.4mil) b. S < W; (S = 5mil) < (W = 6.5mil) c. W < 2H; (W = 6.5mil) < (2H = 12.8mil) d. D > 2S = 10mil Looks like we abide by their guidelines if we use the 64.6 Ohm single-ended impedance values. It seems the distance, D, to the next trace is somewhat flexible because in this reference it is reduced from 3S to 2S. (I'm sure 3S is better than 2S, if you have the space.) Ground Planes under Pads Toradex mentions the lower impedance between wide traces and the reference plane causing impedance mismatch at large pads for components and connectors.[21] The width of the pads in the illustration are 5-6x the width of the traces connecting to them. On the micro-HDMI connector the width of the pads is around 0.2mm (JAE DC3R019JA7R1500 pad width = 0.23 +/-0.03 mm ~= 9.1 +/- 1.1 mil), where the smallest trace we can have is 5 mil thus our greatest proportion is 10.2 mil / 5 mil ~ 2. So this is probably less of a problem than if the pads were 5-6 times the width of our traces. In fact if we compare the dimensions of the connector pads and spacing (which is about the same as pad width) to those of the trace width and spacing for 55 Ohm single-ended impedance in the table above, they nearly match. Thus I don't think this will be a big issue for this board because while the pads are wider than our traces, they're spaced about as far apart as we would space traces that are that wide to still get 100 Ohm differential impedance. Via Impedance If and when we start supporting HDMI v2.0+ we will need to tune the impedance of our signal vias even more keenly as our signals will surpass the 10GHz barrier.[22] Presently we also have the happy situation that since our high-frequency signal vias always connect between top and bottom layers, our stub length is 0 on signal vias. Creating transparent (tuned) vias requires familiarity with a 3-D EM simulator and some time to set up, run, evaluate results of simulations, and then repeat in order to tune the impedance. (See section below "Libre Field Solvers".) We can still take some of the recommendations to heart: 1. Use minimal size vias for high-frequency traces to reduce parasitic capacitance.[23] 2. Place the two vias of the differential pair in close proximity to increase capacitive coupling between the signals.(smaller via pitch) 3. Instead of using two separate anti-pads on signal vias, combine them into oval shared antipads (on every layer) to reduce parasitic capacitance. 4. Place ground vias next to signal vias to provide ground-return paths.[22, Figure 2] References: [1] https://en.wikipedia.org/wiki/FR-4 [2] Toradex, page 21 [3] Toradex, page 38 [4] TI, page 4 [5] Chrontel, page 5 [6] https://forum.allaboutcircuits.com/threads/hdmi-inter-intra-pair-skew-inter… [7] https://e2e.ti.com/support/interface/high_speed_interface/f/138/t/267205 [8] https://www.researchgate.net/publication/224650488_Effects_of_skew_on_EMI_f… [9] Toradex, page 17, Figures 12 & 13 [10] Toradex, pages 22-23 [11] Chrontel, page 4 [12] TI, page 5 [13] JAE, page 1 [14] Toradex, page 12 [15] Toradex, page 13, Table 3 [16] http://referencedesigner.com/cal/cal_02.php [17] https://en.wikipedia.org/wiki/Ounce#International_avoirdupois_ounce [18] https://en.wikipedia.org/wiki/Copper [19] https://en.wikipedia.org/wiki/Densities_of_the_elements_(data_page) [20] TI, page 8 [21] Toradex, pages 18-19, Figure 16 [22] https://e2e.ti.com/blogs_/b/analogwire/archive/2015/06/10/differential-pair… [23] TI, page 9 Bibliography: Chrontel: Application Note AN-B026, "PCB Layout and Design Guide for CH7101A HDMI to VGA Converter", http://www.chrontel.com/media/Application%20Notes/AN-B026%20Rev0.2.pdf Japan Aviation Electronics Industry, Ltd. (JAE): "HDMI Standard Type D HDMI Micro Connector: DC3 Series", Connector MB-0233-2, May 2013, http://www.jae.com/z-en/pdf_download_exec.cfm?param=MB-0233-2E_DC3.pdf Texas Instruments (TI): "HDMI Design Guide", High-Speed Interface Products, June 2007, http://e2e.ti.com/cfs-file/__key/telligent-evolution-components-attachments… Toradex: "Layout Design Guide", v1.0, 14 April 2015, http://docs.toradex.com/102492-layout-design-guide.pdf

4 14

Re: [Arm-netbook] bunnie about riscv - NSA in today's CPUs
by dumblob 04 Aug '17

04 Aug '17

https://brmlab.cz/user/jenda/intel One evil HW comparator and we're all screwed :-( 2017-06-11 17:07 GMT+02:00 Neil Jansen <njansen1(a)gmail.com>: > On Sat, Jun 10, 2017 at 11:54 AM, <ronwirring(a)safe-mail.net> wrote: > >> It was very informative. A lot of the technical matter I did not > understand. > > This was a GREAT talk. Thanks for the link. > >> Can you explain: >> 23.04 The 2 lowermost boxes? > > 1) PDK / Foundries. The factories in which the chips are made in. They're > not open. They're proprietary and there's a implication of trust. > 2) Equipment / Raw Materials. The equipment that makes the chips and the > raw materials that go into the chips. All a very cloudy and and murky area > that is not open, and very proprietary. > > He's basically saying that those that want *100%* open source hardware > would require infinite recursion down to the raw components, which is > impossible. That's the whole point of the talk. The 'impedance mismatch' > thing is a sort of metaphor to describe the unrealistic expectations of > those idealists that want 100% open source hardware. He's saying it cannot > happen today. And BTW I've met Bunnie on several occasions, he's legit, > and you can trust what he's saying to be technically correct. He's the > real deal. > >> What is a stepper? > > A stepper motor. That is, do you trust the motors that move the machines > that made the integrated circuits? > >> What is fuse? > > See this link: > https://electronics.stackexchange.com/questions/1262/what-are-atmel-fuses > > >> 25.15 The 4 lowermost boxes? > > * BIOS > * Firmware > * Hidden / fused silicon blocks - Blocks of silicon on the chip that aren't > usually turned on, but are there. Lots of big vendors are doing this now: > Intel, AMD, Nvidia, and it's anyone's guess as to what their real purpose > is. That leads to conspiracy theories, as Bunnie said. This is a problem > because if you put a chip like this into an open source laptop, it begs the > question of what would happen if something turned on that section and > started execution code from it? Nobody will know until (A) documentation > is leaked from the company or (B) someone reverse engineers it. Basically > if you use anything application processor chip made in the last 5-10 years, > you probably have some hidden / fused silicon blocks doing god knows what. > * Pre-boot microcode - Microcode (https://en.wikipedia.org/wiki/Microcode) > that executes BEFORE your computer boots. This is a big deal, because > everything that happens after this point can be considered suspect. > (similar to how a boot virus would spread because it executes first). > * IP industry practices - Intellectual property used by silicon > manufacturers that are not open. What he's saying is, say that you're a > silicon vendor and you just bought a intellectual property from ARM to make > an ARM chip. They're giving you HDL (hardware description language) and > netlists (a large list of the connections to be made in the die), and guess > what, they gave them to you encrypted so that their intellectual property > is safe. You (the guy that runs a third party chip factory) cannot review > or inspect the intellectual property that ARM gave you. The point here is > that unless you're using an open source (RISC-V, etc) core, then using an > ARM isn't really 100% open source hardware. > * Mask trojans & glitches - These are malicious things in the CPU die > itself, that even if you were looking at the silicon die under a microscope > and studying it, you'd still completely miss it. Very nasty but they > exist. Hackaday.com has a lot of interesting articles that break these > sort of things down in layman's terms. Very interesting. Basically > because these exist, there's no way to know that you are really executing > what you think you are executing unless you built the foundry and > supervised the chips being made, and analyzed everything that went into the > manufacture of them. It's a trust problem. > > These are all highly complex subjects that hardware engineers like Bunnie > deal with a lot, and other (I'll say idealist) software guys probably have > never thought of. They're important in that when you realize that they're > there, you will then understand how silly wanting 100% open hardware really > is. It's a huge problem that hardly anybody is trying to fix. > > > Recently the 6502 was completely dissected and recreated, so that's one of > the only fully documented (and I'd say fully trusted) cores out there > today. And that was made probably before I was born. Everything since > that should be assumed to be compromised and < 100% open. Oh, and even > then, the 6502 would have to hook up to OTHER chips like flash, RAM, and > whatever generates the video and handles the peripherals. Those have not > been completely dissected, and could be suspect. Do you see what Bunnie > means now? That's the impedance mismatch. > > > P.S. my apologies to LKCL and others, I don't have a plain text email > client. > _______________________________________________ > arm-netbook mailing list arm-netbook(a)lists.phcomp.co.uk > http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook > Send large attachments to arm-netbook(a)files.phcomp.co.uk

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

arm-netbook