arm-netbook January 2018

arm-netbook@lists.phcomp.co.uk

27 participants
38 discussions

Re: [Arm-netbook] Crowsupply update
by Pičugins Arsenijs 09 Jan '18

09 Jan '18

> 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

2 1

Software as a Community Service
by Jean Flamelle 08 Jan '18

08 Jan '18

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.

1 0

Re: [Arm-netbook] EOMA68 / Libre RISC-V team financing
by ronwirring＠Safe-mail.net 07 Jan '18

07 Jan '18

2 1

will orange pi zero run libre version of freedombox?
by ronwirring＠Safe-mail.net 06 Jan '18

06 Jan '18

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.

1 0

Re: [Arm-netbook] HDMI High-Frequency Layout: Recommendations--Taper
by Richard Wilbur 06 Jan '18

06 Jan '18

The goal of the taper is to minimize the reflection coefficient involved with changes in impedance caused by changes in transmission line geometry. In essence we are trying to make the changes so gentle that we don't scare any electrons. The scared electrons reflect at the point of abrupt changes in impedance(flee back in the direction they came from) which weakens the signal delivered to the HDMI cable and, finally, the display. (Forgive the anthropomorphization of the electrons--it is purely for illustrative purposes.) As the high-frequency differential lines traverse the board from processor pin to connector pin certain parts of the geometry and electromagnetic environment stay fairly constant, other aspects in certain places are not conducive to the transmission environment needed by the HDMI signals we wish to deliver to the connector. Three principles are at work here: 1. Whatever conditions are apparent over the majority of the conduction path will dominate the transmission characteristics. (You could think of the overall impedance as being similar to a length-weighted average of the local impedance of all the sections along the path.) 2. The abruptness of changes in geometry will determine the abruptness of changes in impedance and thus the reflection coefficient associated with the perturbation. 3. Reflections are more troublesome the further you get from the signal source. Close to the source the reflection arrives at the source during the signal rise time and can be overcome by the line driver. The trace width stays mostly constant at 5mil except for component pads at processor, ESD chip, and connector and the two through-hole vias used to transition from layer 1 (processor) to layer 6 (room for differential microstrip transmission lines) back to layer 1 (connector). Both the signal trace copper thickness and the dielectric thickness between signal traces and ground plane change only at the signal vias. The room available on layer 6 allows us to make a controlled-impedance differential transmission line for a good share of the transmission path. Since the HDMI standard specifies 100 +/-15% Ohm impedance, we have designed the geometry to provide a characteristic impedance close to the upper end of the tolerance of the nominal impedance. We have room to impose this geometry for most of the length of the sojourn. At both ends the space is restricted such that the close quarters will no doubt result in a lower local impedance. Where we have room, the distance between a differential pair and any other copper (be it another differential pair or ground) is 15mil. At both ends this is restricted by the spacing between lands in the component layouts down to 5-7mil. From the first principle, we see that the influence of the lower local impedance from the restricted sections will serve to lower the overall impedance. In order to stay within the tolerances of the nominal impedance we attempt to limit the length of the restricted sections (where the inter-pair distance <15mil). In some places this could lead us to maintain 15mil inter-pair distance right up to an obstruction which imposes a 5-7mil inter-pair distance. The second principle leads us to recognize this is an abrupt change and expect that it will cause reflections. The third principle suggests it is more important to deal with abrupt changes at the connector end of the transmission line than the processor end. Hence, we are exploring the feasibility of tapering the inter-pair distance down from 15mil to 5mil as we get to the connector end, in order to soften the effects of the unavoidable space restrictions at the connector end. The other important point is that since we are dealing with differential signals, we are interested in trying to maintain symmetry in dealing with the two traces of each differential pair, lest we push signal energy into common-mode. The idea was inspired by my reading of a discussion on "Microwaves101"[*] of an impedance taper first described by R. W. Klopfenstein in a paper titled "A Transmission Line Taper of Improved Design", published in the Proceedings of the IRE, page 31-35, January 1956. We aren't really doing his work justice as our frequencies are so low that our board is too small to accommodate the length required to get the good low frequency response he demonstrates. Nevertheless, we are interested in making the sequence of small transitions in a somewhat similar fashion. Transmission Line geometry (widths) North ground fill keep out Inter-pair Distance = 15mil HDMI TX2P trace = 5mil Intra-pair Spacing = 5mil HDMI TX2N trace = 5mil Inter-pair Distance = 15mil HDMI TX1P trace = 5mil Intra-pair Spacing = 5mil HDMI TX1N trace = 5mil Inter-pair Distance = 15mil HDMI TX0P trace = 5mil Intra-pair Spacing = 5mil HDMI TX0N trace = 5mil Inter-pair Distance = 15mil HDMI TXCP trace = 5mil Intra-pair Spacing = 5mil HDMI TXCN trace = 5mil Inter-pair Distance = 15mil South ground fill keep out Adding this up yields a total = 135mil When we scale the Inter-pair Distance = 5mil, the total = 85mil This drops 50mil in width. <step> <Inter-pair Distance> <Change> 0 15mil 1 14mil -1mil 2 13mil -1mil 3 12mil -1mil 4 10mil -2mil 5 08mil -2mil 6 07mil -1mil 7 06mil -1mil 8 05mil -1mil If we use 15mil along the signal conduction path from the onset of one change to the next and 45 degree turns to initiate and complete all the changes, and if we choose a geometry to lengthen TXC (clock) the most and leave unchanged TX2, the length along the signal path of the taper will be 7*15mil + 4*1mil = 109mil after which we have no need of manual keep outs for the ground fill as the board rule of 5mil minimum Cu-Cu spacing will suffice. Deviations from path in due NorthEast direction (+ signifies change in the NorthWest direction, - signifies change in the SouthEast direction, units in mil) <step> <Northern keepout> <TX1> <TX0> <TXC> <Southern keepout> 0 0 0 0 0 0 1 -1 1 2 3 4 2 -1 1 2 3 4 3 -1 1 2 3 4 4 -2 2 4 6 8 5 -2 2 4 6 8 6 -1 1 2 3 4 7 -1 1 2 3 4 8 -1 1 2 3 4 Diagram attached below. Good grief that took awhile! I'm now completely sold on the concept of Computer-Aided Design (I've used some awkward implementations before but this was done with pencil, pen, measuring tape, and book spine for straight edge). Reference: [*] https://www.microwaves101.com/encyclopedias/klopfenstein-taper

3 89

Meltdown and Spectre
by Louis Pearson 05 Jan '18

05 Jan '18

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.

4 5

EOMA68 / Libre RISC-V team financing
by Luke Kenneth Casson Leighton 01 Jan '18

01 Jan '18

ok so the past couple of updates i sent out i mentioned that there's no longer sufficient funds in the current campaign to further pay accommodation or any other living expenses. thus it is *really important* that i find sources of funds, immediately. beyond that, i may have found something that's worth exploring that has the potential to fund pretty much absolutely everything that we want to achieve, if it is leveraged correctly. one of the options that i am exploring is bltclub. i happened to have 0.65 BTC available, the price of bitcoin happened to be rising such that it was worth around USD $5000 at the time, i happened to hear about bitclub from a friend, and my prior experience with bitcoin mining i'd already done the preliminary analysis so it was an extremely easy and fast decision. bitclub - a group of like-minded people who happen to share a common interest - mine three percent of the world's bitcoin. three percent. at today's market rate that's twenty four ***MILLION*** US Dollars being generated by this group, every month. that's a staggering amount of money which immediately made it worthwhile investigating. the members basically make their money in two ways: (a) mining (of which they receive A HUNDRED PERCENT of the bitcoin mined - unlike many other mining clubs which take say 10%) (b) multi-level marketing. this is by far and above the more profitable method and the fact that it exists is precisely why the club can provide 100% of the mined bitcoin to people who *only* wish... to mine bitcoin. if you have ever done bitcoin mining, you will know that it is an absolute pain in the neck, and you will also know that you cannot get the equipment now for love nor money. not even bribes will work because you still have to out-bid everyone else who's offering bribes as well. and once you GET the equipment, if it breaks you lose downtime... that's if you can actually get the person you bribed to honour the warranty. by using a *POOL* of people - buying in bulk - the "share" of the *POOL* is available to you. one piece of equipment fails, so what, that's amortised across thounsands of people. you also don't pay for electricity or cooling. or have fans whirring 24x7 in your house. now, i *already have* two other people signed up: i am a few points away from hitting the first MLM milestone which would result in me receiving TWO HUNDRED US DOLLARS A DAY in *addition* to the bitcoin mining which is coming online in the next 48 hours. i have two separate and distinct questions: (1) is there anyone who does NOT wish to put their own money into buying bitclub shares who would like ME to sign them up, and, over the next few weeks and months, PAY their membership AND pay for their equipment. (2) is there anyone who CAN put their own money into bitclub who would be interested to know more. if yes, and you already know about bitcoin mining and about MLM etc. the link is here http://bitclub.network/lkcl the goal basically is to leverage this to become financially independently wealthy, and use it to fund libre hardware and software. there's about maybe 3 to 5 years in which bitcoin - specifically GROUP mining NOT individual mining - is a viable way to do that. any questions feel free to ask. l.

19 71

Re: [Arm-netbook] EOMA68 / Libre RISC-V team financing
by ronwirring＠Safe-mail.net 01 Jan '18

01 Jan '18

-------- Original Message -------- From: Luke Kenneth Casson Leighton <lkcl(a)lkcl.net> Apparently from: arm-netbook-bounces(a)lists.phcomp.co.uk To: Linux on small ARM machines <arm-netbook(a)lists.phcomp.co.uk> Subject: [Arm-netbook] EOMA68 / Libre RISC-V team financing Date: Wed, 27 Dec 2017 09:59:04 +0000 On the current pc card situation I have some remarks. Primarily directed at other pc card supporters. I got the pc card after making some assessments. Did I believe it was a scam, no. Did I believe the pc card had a chance of getting made, yes. Did I believe the pc card enterprise could shipwreck, yes. If so I decided lkcl would not hear a word for it from me. Of course I only made such decision because to me the pc card's price is negligible. If beneficial to lkcl, he can erase me from the shipping list and no refund. I ask others to do the same. 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. 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. 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. 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. 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. But such system should be created. How should it be founded? > 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

6 11

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

arm-netbook January 2018