- arm-netbook - Mailman test

Conflict-free minerals
by Jean Flamelle 18 Sep '17

18 Sep '17

I just thought I'd make a poke about this. Been a bit busy lately to contribute to the liberating chip or the standards thread, but will be getting back on those soon. No one has really mentioned conflict-free minerals, or does so often in the libre community. It's kinda like adding just one other complication to an already mess-y problem, but I'm interested to know more about the details and problems involved with paying attention to the actual mineral sourcing. I can imagine many OEM's don't publish or even pay attention to where they get minerals from, so I imagine the potential parts list dwindles beyond reason at simply limiting one's self to OEM's that at least list their mineral sources, much less then actually trying to them limit it based on the fairly subjective "conflict-free" qualification.

6 8

Retrfit a Nokia and KiCad fun
by mike.valk＠gmail.com 16 Sep '17

16 Sep '17

https://hackaday.com/2017/09/12/hackaday-prize-entry-retrofit-a-nokia/ https://hackaday.io/project/21263-nokia-3210-retro-fit-board Quote from the project log: "With the patched I submitted you can turn KiCad into a 'I know what I am doing' mode. Which meas you can place any type of via anywhere. You should not do it though. Vias are pretty well constraint by the manufacturer of the board. Since KiCad does not know of any layer thickness, production technologies and such it restricts to what is a sensible lowest common denominator." Hmm so KiCad does not have a "PCB manufacturer constraints" input? How handy... NOT

5 5

ppcnotebook
by ronwirring＠Safe-mail.net 14 Sep '17

14 Sep '17

https://www.powerpc-notebook.org/en/ Do you know them? Are they credible? Thank you.

8 13

pre-2.7.5 JAE DC3 micro-hdmi connector test PCB success
by Luke Kenneth Casson Leighton 13 Sep '17

13 Sep '17

http://rhombus-tech.net/allwinner_a10/news/ --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

5 6

Part sourcing
by mike.valk＠gmail.com 11 Sep '17

11 Sep '17

http://www.findchips.com/ We'll that's interesting. Doesn't beat the offline markets in Shenzhen I guess.

1 0

python coding help needed (sin, cosine, blah blah)
by Luke Kenneth Casson Leighton 10 Sep '17

10 Sep '17

http://hands.com/~lkcl/foldable3dsandwich200/belts.py ok, i could use some algorithm help, here, if anyone's interested. the key function is add_bearing in class Belt. basically what i have done is create a class which completely specifies a belt path, by starting out with the angle that the belt is wrapped around so far, plus the position, plus the diameter of the bearing (a fake bearing initially). subsequent bearings need only be added specifying their position, radius, and whether the belt is to go on the INTERIOR or the EXTERIOR of the bearing. the swapping-from-interior-to-exterior is where i'm having difficulties. i've made a half-assed approximation so far, i will upload a quick video about it... https://youtu.be/AV5yRz6GPX0 the problem i have is that the flip-over between interior and exterior is a little bit too complicated for my tiny brain to handle. i know that it involves twin offsets. i think it might be possible to work out the first angle between the bearings, then pretend that there's another bearing added on the *other* side (in the opposite configuration), then work out the angle of *that* (fake) bearing to the one before it... anyway if anybody would like to have a go at tackling this i would be really grateful. l.

4 13

The Libre Guild of Program Changers [Formerly "Re: Standards Organization as a Potentially Universal Free/Libre Software Developement Sustenance Model:
by Jean Flamelle 06 Sep '17

06 Sep '17

So to kind of clarify on my original idea a bit. (finally found the words) Essentially, the point of libre software is that anyone can change it to do what they want the program to do, and, if someone doesn't have the know-how, they can ask someone else. That's the heart of the idea. There should be an organization not-unlike an artists' guild, where people can go to and commission customizations to libre software. The idea of a standards organization, was more meant as a certain standard expected of all guild members. Projects live mostly off of donations, but they can certified based on their members' respective statuses in the guild and their portfolio of commissioned mods they've accomplished. Supposedly major companies could commission a major modified fork from a project (like Blender or Gimp) and that there would be a certification mark the commissioning company could bear indicating that they supported as well as respected free software in this way. (i.e. not trying to convince the foundation to sign an NDA, close or obfuscate parts of the fork, or write any kind of exploitive or otherwise disreputable software.) And, if a company dedicates their own staffed developers to the effort, basically the mark would also indicate that those developers weren't disruptive and were respectful. On 5/31/17, John Luke Gibson <eaterjolly(a)gmail.com> wrote: > Neverminding the ridiculous length of that subject line.. > > I just thought an interesting thought. > > First, a little context, (I know how rms feels about blockchains) I > was investigating slock.it and thinking to myself "why don't they just > make a hardware standard like eoma instead of closing their > development and calling it open?" (Like, Pi-Top is [n]ever gonna > release those stl files) > (I realize that's a loaded 'just' cause it sounds easy, but is one of > the most difficult possible) > > Then, it dawned on me: Lulzbot doesn't do that.. Wait, Lulzbot > exclusively uses open software in their development.. Then *bam* like > a boulder (nothing to do with Lulzbot): GPL-violations, improper GUI > training, failing to extend using APIs/Addons, failing to > bugsmash/'track-issues', failing to participate in mailing-lists and > irc, failing to simply fork when development goals conflict, planned > esoteric-ism and/or planned obsolescence, failure to secure clientèle > data by using fully free systems (when relevant), failure to > participate-in and be-aware-of public conversations about the > underlining security of said systems (when relevant), failure to > disclose supplychain information/identities (when relevant), failure > at general transparency. > > All of these things traditionally go wrong with not only companies > that use open source, but companies in-general. > > Then, it truly truly dawned on me, free software needs standards > organizations as well. >

4 4

[Formerly "Re: Standards Organization as a Potentially Universal Free/Libre Software Developement Sustenance Model:
by Jean Flamelle 05 Sep '17

05 Sep '17

On 5/31/17, John Luke Gibson <eaterjolly(a)gmail.com> wrote: > Neverminding the ridiculous length of that subject line.. > > I just thought an interesting thought. > > First, a little context, (I know how rms feels about blockchains) I > was investigating slock.it and thinking to myself "why don't they just > make a hardware standard like eoma instead of closing their > development and calling it open?" (Like, Pi-Top is [n]ever gonna > release those stl files) > (I realize that's a loaded 'just' cause it sounds easy, but is one of > the most difficult possible) > > Then, it dawned on me: Lulzbot doesn't do that.. Wait, Lulzbot > exclusively uses open software in their development.. Then *bam* like > a boulder (nothing to do with Lulzbot): GPL-violations, improper GUI > training, failing to extend using APIs/Addons, failing to > bugsmash/'track-issues', failing to participate in mailing-lists and > irc, failing to simply fork when development goals conflict, planned > esoteric-ism and/or planned obsolescence, failure to secure clientèle > data by using fully free systems (when relevant), failure to > participate-in and be-aware-of public conversations about the > underlining security of said systems (when relevant), failure to > disclose supplychain information/identities (when relevant), failure > at general transparency. > > All of these things traditionally go wrong with not only companies > that use open source, but companies in-general. > > Then, it truly truly dawned on me, free software needs standards > organizations as well. >

1 0

physics analysis needed of belt-driven pulley system
by Luke Kenneth Casson Leighton 29 Aug '17

29 Aug '17

some background: http://forums.reprap.org/read.php?177,767087,784083#msg-784083 and the same question here: https://physics.stackexchange.com/questions/352661/ can anyone help? basically - and i really should have done this before going ahead... *sigh*... - when you have a pulley system is the amount of force on the belt less, equal, or greater, under the same *print-head* acceleration conditions, compared to a *non* pulley system? l.

3 8

m
by Richard Wilbur 25 Aug '17

25 Aug '17

Sent from my iPhone

4 6

http://rhombus-tech.net/allwinner_a10/news/
by Luke Kenneth Casson Leighton 24 Aug '17

24 Aug '17

ok so i did a quick summary (despite the length) of the status so far... i hope there is light at the end of the tunnel.... --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

1 0

frickin funny
by Luke Kenneth Casson Leighton 15 Aug '17

15 Aug '17

https://motherboard.vice.com/en_us/article/78w8jy/pcmcia-once-defined-porta… i had no idea this article existed... i absolutely love the conclusion.... --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

7 7

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

HDMI High-Frequency Layout: Libre Field Solvers
by Richard Wilbur 04 Aug '17

04 Aug '17

HDMI Layout Notes for EOMA68 Cards by Richard Wilbur Libre Field Solvers[24] (Free Computational Electromagnetic Modeling Codes list at the Clemson University Vehicular Electronics Laboratory) Name License URL Angora GPL http://www.angorafdtd.org/ atlc - Arbitrary Transmission Line Calculator (for transmission lines and directional couplers) GPL http://atlc.sourceforge.net/ Elmer GPL/LGPL https://www.csc.fi/web/elmer EMAP BSD-esque? http://www.cvel.clemson.edu/modeling/EMAG/EMAP/emap5/ FastImp MIT http://www.rle.mit.edu/cpg/fastimp.htm GSVIT GPL http://gsvit.net/ MEEP GPL http://ab-initio.mit.edu/wiki/index.php/Meep MMTL - Multilayer Multiconductor Transmission Line GPL http://mmtl.sourceforge.net/ openEMS GPLv3+ http://openems.de/start/index.php OpenMaXwell GPLv3+ http://openmax.ethz.ch/ (runs on Linux under wine) pdnMesh GPLv2 http://pdnmesh.sourceforge.net/ Puma-EM GPLv2 https://sourceforge.net/projects/puma-em/ WOLFSIM GPLv2 https://sourceforge.net/projects/wolfsim/ xfemm - Cross-platform Finite Element Method Magnetics Aladdin Free Public License, Apache Licence v2.0 https://sourceforge.net/projects/xfemm/ These are the field solvers that had what I understood to be a libre license from Clemson's list. There are fourteen packages here that made the cut and align with the goals of this project. I have no familiarity nor expertise with any of them or I would be in a better position to make a recommendation. It would be useful to be able to model not only the differential microstrip structure with ground shield traces and vias, but also signal vias for tuning them to transparency. References: [24] http://www.cvel.clemson.edu/modeling/EMAG/free-codes.html

1 0

HDMI High-Frequency Layout: Goals
by Richard Wilbur 03 Aug '17

03 Aug '17

HDMI Layout Notes for EOMA68 Cards by Richard Wilbur Goals The portion of the HDMI transmission path contained on the PCB has several goals: 1. Support all operating modes of the HDMI v1.4 interface of which the A20 chip is capable (clock up to 340MHz, data up to 3.4GHz). 2. Match the characteristic impedance of the rest of the HDMI transmission path (connectors, cable, and receiver) to minimize reflections and deliver a recoverable/decodeable signal to the receiver. [low distortion, sufficient amplitude] 3. Minimize radiated Electro-Magnetic Interference which could adversely effect other circuits on the EOMA68-A20 or in its surroundings, or exceed regulatory limits of concerned agencies: FCC, CSA, etc. 4. Minimize sensitivity to EMI from other circuits on the EOMA68-A20 and its surroundings. Of these goals careful layout realizing a microstrip geometry helps with minimizing EMI radiation and sensitivity, while impedance matching both minimizes signal reflections which distort the transmitted signal and delivers the signal energy to the intended receiver.

1 0

Re: [Arm-netbook] HDMI High-Frequency Layout: Introduction
by Andrew Bolin 02 Aug '17

02 Aug '17

> > Date: Tue, 1 Aug 2017 03:45:19 -0600 > From: Richard Wilbur <richard.wilbur(a)gmail.com> > To: Eco-Conscious <arm-netbook(a)lists.phcomp.co.uk> > Subject: [Arm-netbook] HDMI High-Frequency Layout: Introduction > Message-ID: > <CAC4=CAENg63=p1CfYFE6QPVp+g1-SRnznHbXTsVcNkLXh=EY9A@mail. > gmail.com> > Content-Type: text/plain; charset="UTF-8" > > This is a discussion of the considerations when designing and > executing a PCB layout containing high-frequency signal > traces--specifically in this case HDMI. It is being published to the > [arm-netbook] mailing list in several sections dealing with related > topics. The original was created in Open Document Text and I have > dumped it into Unicode Text in order to accommodate the mailing list. > Great collection of info Richard. I'd appreciate a copy of the original file to keep for my reference, if/when you have a chance to upload it somewhere (I'm guessing I'm not the only one?), or email it direct and I can find a place to share it.

3 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

arm-netbook