arm-netbook

arm-netbook@lists.phcomp.co.uk

8 participants
1076 discussions

Re: [Arm-netbook] mailing list etiquette
by Luke Kenneth Casson Leighton 21 Jun '17

21 Jun '17

On Sun, Jun 18, 2017 at 9:59 PM, Brendan Sleight <bms.debian(a)barwap.com> wrote: >>> On Sat, Jun 17, 2017 at 6:35 PM, <ronwirring(a)safe-mail.net> wrote: >> No. I maintain that I prefer an email to display all previous > > No doubt you do, but this is a community. “Logic clearly dictates that > the needs of the many outweigh the needs of the few.” - Spock it's a leetle more complex than that, brendan, but... yeah. > Luke - I would be grateful if you could reduce the members on this > list to those who can follow the RFC. i am reluctant to take such draconian action without going through intermediate less drastic steps, explained at each and every stage to give him an opportunity to understand fully the gravity and consequences (inconvenience to others), so i've placed his messages under moderation as an intermediate step. that makes for a hell of a lot of otherwise unnecessary work for me but that's just how these things go. l.

3 3

EOMA68-A20 2.7.4 pre-production prototypes received and working
by Andrew Bolin 18 Jun '17

18 Jun '17

> > Date: Thu, 15 Jun 2017 15:02:07 +0100 > From: Luke Kenneth Casson Leighton <lkcl(a)lkcl.net> > > it was discovered that the VIAs underneath the pads for the JAE DC3 > Micro-HDMI connector are sucking the solder paste in and down, leaving > the pins not properly connected. > ... if anyone knows any tricks i would appreciate hearing them. > Can you enlarge the solder mask for these pads, thus providing enough solder to both fill the via and make the connection? This is the standard recommendation when using thermal pads / thermal vias.

2 1

u-boot A20 sunxi, added SPL dual MMC boot
by Luke Kenneth Casson Leighton 18 Jun '17

18 Jun '17

http://git.rhombus-tech.net/?p=u-boot.git;a=shortlog;h=refs/heads/sunxi it's a feature that's present in quite a lot of versions of u-boot but not in the sunxi one: i added a means to check *two* MMC slots in the early SPL loader. the problem without such a feature is: you can only boot from one MMC slot, even if you compile u-boot with support for two MMC slots... because the early SPL loader *only recognises loading u-boot from one MMC slot*. for those people not familiar with the A20 boot process: http://linux-sunxi.org/BROM#A10.2FA20 the BROM loads from a very specific sector of either MMC0 or MMC2 (in that order). maximum code size: 16k bytes. loading a full u-boot is not possible so u-boot has to be boot-strapped (aka SPL loader). the *existing* sunxi SPL loader *only* supports loading from a *single* MMC card slot. l. --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

1 0

mailing list etiquette
by Luke Kenneth Casson Leighton 18 Jun '17

18 Jun '17

On Sat, Jun 17, 2017 at 7:14 PM, Lars Kruse <lists(a)sumpfralle.de> wrote: > Hi Ron, > > > Am Sat, 17 Jun 2017 13:35:59 -0400 > schrieb ronwirring(a)Safe-mail.net: > >> [..] >> I prefere if others leave the full text in their emails. >> I prefere to not delete text in my own replies. >> I cannot make that decision about my replies? > > I could image, that Luke would like the participants of this mailinglist to use > a style similar to the one defined in RFC1985 ("Netiquette", see section 2.1.1): https://www.ietf.org/rfc/rfc1855.txt RFC 1855 not 1955. took a few minutes to find it. section 2.1.1 is a little dated, but 95% relevant. interestingly it contains no specific advice for mailing list interaction. this example contains good advice on mailing list etiquette: http://linux.sgms-centre.com/misc/netiquette.php please read - and follow and adhere to - section 9, ron. please also follow the link which leads here and read it: http://howto-pages.org/posting_style/ > Be brief without being overly terse. When replying to a message, > include enough original material to be understood but no more. It > is extremely bad form to simply reply to a message by including > all the previous message: edit out all the irrelevant material. > > > Since Luke maintains this mailinglist, I find it to be acceptable, that he > can define the communication policy of this list, if he prefers so. i do. i used to be quite lax about it but i feel it is becoming important. > Specifically in this case he is following a widely used style - even though we > are all aware of the fact, that there are different communities or contexts out > there using very different styles with regard to quoting. for a "chatty" list such as a support self-help (e.g. alcoholics anonymous) group, top-posting would be the norm as most people would interact with either single-sentence (top-posted) replies of encouragement, or they would write massive walls-of-text to which it would be typically be perfectly fine to top-post. this list is not such a list. this is a technical list and it can get very busy and very complex very quickly. following interaction rules that have been developed over many decades for technical lists would be a good idea. http://howto-pages.org/posting_style/ l.

1 0

mailing list etiquette
by Luke Kenneth Casson Leighton 18 Jun '17

18 Jun '17

On Sat, Jun 17, 2017 at 6:35 PM, <ronwirring(a)safe-mail.net> wrote: >> ron hi please remember to cut context. there is 3 paragraphs >> comprising several hundred words, repeated, followed by a single >> sentence and then a single-sentence question. >> >> these last two sentences are the only relevant context: the rest of >> the context you have forced over 400 people to re -read unnecessarily. > > > > I have not forced anyone to read anything. ron: there are over 400 people on this list. many of them receive hundreds of messages per day. they read them all. they do not know that you are violating the rules of the list until they begin to read your message. when they find, after several seconds of scrolling down, that their time has been completely wasted because nothing has been added, they are going to be pissed. > Anyone may ignore my emails. ron: if the mailing list administrator tells you that you're disobeying the rules of interaction which put people to significant inconvenience, do you believe that it is ok to respond with such a sentence? > You know where to look. It is where there are no '>'. and how long does it take to do that? it takes a long time, ron. people are forced to scroll down for a significant amount of time. if they have a hundred or several hundred messages to read each day, and they are forced to scroll down more than is necessary only to find that there was nothing new added, because there is one person who does not respect the rules which make their lives easier, how long do you think they are going to continue to contribute to that llist? > I prefere if others leave the full text in their emails. that is fine if you are interacting privately: it is not fine when you are interacting with 400 people. you have been asked multiple times to respect the rules of the list. > I prefere to not delete text in my own replies. your personal preferences are not relevant when it comes to interacting with 400 other people. > I cannot make that decision about my replies? yes you can, because you are being requested to do so by the mailing list administrator. out of respect for others, you are being requested to follow the rules of interaction set for this list. you do not set the rules for this list: i set the rules for this list. i get the impression that you are not really listening or respecting what i am saying, ron. that therefore forces me to escalate matters. if you do not respond indicating that you intend to respect the rules of this list (standard netiquette) then reluctantly i will be forced to escalate to moderation of your messages until such time as you do listen. this will place a huge burden of extra work onto me, as for every single message that you send i will receive a notification, then i will be forced to go to a web interface, then i will be forced to read and review your message in full, and then either approve or reject i, writing a review each and every time explaining why your message is being rejected, should it be rejected. do you, through not listening to what you are being told, *genuinely* wish to force me to take such action? what do you think the implications would be of forcing me to take such action to protect this list and its members? would you agree that it would be a good idea for you to say "whoops i'm sorry, i understand now that this is serious, i will listen and follow your advice so that i do not inconvenience so many people" ? l.

1 0

Fwd: [trinity-devel] TDE Fundraiser
by Luke Kenneth Casson Leighton 17 Jun '17

17 Jun '17

please do distribute to interested parties / lists, TDE (aka KDE 3.5) is strategically quite important as it's one of the remaining comprehensive desktop environments that is also light-weight and relevant. l. ---------- Forwarded message ---------- From: Timothy Pearson <kb9vqf(a)pearsoncomputing.net> Date: Wed, Apr 19, 2017 at 7:19 PM Subject: [trinity-devel] TDE Fundraiser To: trinity-devel(a)lists.pearsoncomputing.net -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224 All, It's that time of year again! As we look toward the release of Debian Stretch and another version of TDE, I'd like to ask for your continued support to help keep TDE online. This year I'm going to try something new. If you donate $40 to TDE [1], I will allow 2 months access to the nightly build repositories that now include Debian Stretch and Raspbian Jessie. Additionally, I'd like those who donate at this level to nominate two bugs that I will personally look into (excepting those relating to support for Wayland, Qt4/Qt5, or Webkit). This way your donations have a direct and positive effect on TDE itself, and TDE can continue to exist in its current form. Personally I would suggest the LibreOffice integration bug or possibly an update of the GTK3 theme engine to fix the rendering bugs as potential candidates, but in the end it's up to you! A full listing of open bugs is available here: http://bugs.trinitydesktop.org/buglist.cgi?bug_status=__open__&content=&no_… As always, thank you for your support and continued feedback -- we couldn't develop TDE without it! Tim [1] https://trinitydesktop.org/donate.php -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iFYEARELAAYFAlj3qjAACgkQLaxZSoRZrGEhXwDcDpHwUy8Z77OEEKHrdVMSqlcW 6uT+v3pMwqNAXQDeM9WnwPpziYGFQIsfb5I6DiVBLNsZaBL2tab+yw== =FFOS -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: trinity-devel-unsubscribe(a)lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help(a)lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting

9 25

Re: [Arm-netbook] bunnie about riscv
by ronwirring＠Safe-mail.net 17 Jun '17

17 Jun '17

-------- Original Message -------- From: Luke Kenneth Casson Leighton <lkcl(a)lkcl.net> Apparently from: arm-netbook-bounces(a)lists.phcomp.co.uk To: Eco-Conscious Computing <arm-netbook(a)lists.phcomp.co.uk> Subject: Re: [Arm-netbook] bunnie about riscv Date: Wed, 14 Jun 2017 09:30:45 +0100 > ron hi please remember to cut context. there is 3 paragraphs > comprising several hundred words, repeated, followed by a single > sentence and then a single-sentence question. > > these last two sentences are the only relevant context: the rest of > the context you have forced over 400 people to re -read unnecessarily. I have not forced anyone to read anything. Anyone may ignore my emails. You know where to look. It is where there are no '>'. I prefere if others leave the full text in their emails. I prefere to not delete text in my own replies. I cannot make that decision about my replies? > > please consider the impact that you are having on the members of the > list by following the required etiquette which, by following it, i am > permitting you to be a member of this list. > > thank you for understanding and respecting the interaction rules of this list. > > l. > > On Tue, Jun 13, 2017 at 6:30 PM, <ronwirring(a)safe-mail.net> wrote: > > >> > We should have libre software hdds and ram. > >> > >> Can you elaborate on that a bit? I don't understand what you mean. > > https://www.theverge.com/2015/2/16/8048243/nsa-hard-drive-firmware-virus-st… > > > > > > > > > > Devices like hdd, ram, sd card have their own system software. > > You cannot access it and do not know what it can do. > > https://opencores.org/ > > _______________________________________________ > 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

DIY laptop part 1: screen
by David Niklas 17 Jun '17

17 Jun '17

BTW: This little series has little to nothing to do with the eoma68. Don't feel obligated to reply. Hello, For a while now I've been working on making myself a new laptop. I wanted one that was 17 in. wide. It has proven difficult to locate a screen, I have search alibaba, amazon, and a few other assorted site without success. I need one that has: 1. Matte finish 2. 17 in. wide, not diagonally. 3. eDP 30 pin connector or MIPI-DSI connector. 4. 16.7 Million colours -- that would be 8-bit colour as opposed to 6-bit which you can find many of on alibaba. 5. Preferably, it is a touchscreen. If anyone has suggestions please point me in the right direction. Thanks, David

3 4

Re: [Arm-netbook] bunnie about riscv
by ronwirring＠Safe-mail.net 14 Jun '17

14 Jun '17

-------- Original Message -------- From: Neil Jansen <njansen1(a)gmail.com> Apparently from: arm-netbook-bounces(a)lists.phcomp.co.uk To: Eco-Conscious Computing <arm-netbook(a)lists.phcomp.co.uk> Subject: Re: [Arm-netbook] bunnie about riscv Date: Sun, 11 Jun 2017 11:07:56 -0400 Thank you for the information. I have watched a rutkowska video on how complicated intel's management features are. Difficult. > 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 Remarkable that you cannot do a verification using a microscope. > 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. > > We should have libre software hdds and ram. > 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

5 5

Re: [Arm-netbook] bunnie about riscv
by ronwirring＠Safe-mail.net 14 Jun '17

14 Jun '17

From: Neil Jansen <njansen1(a)gmail.com> > On Sun, Jun 11, 2017 at 4:38 PM, <ronwirring(a)safe-mail.net> wrote: > > Thank you for the information. > > I have watched a rutkowska video on how complicated > > intel's management features are. > > Difficult. > > That's why I'm here, lol. The Intel stuff is getting bad enough that it > has me wondering what I can do for the open source hardware world. Moving > to ARM via EOMA68 is a good near-term solution, but even that's not going > to be 100% trustable at lest by bunnie's standards in the lecture. > Something like RISC-V has the potential to get there, but as he pointed > out, even that's not completely open. I think right now the important > thing is to just be an early adopter of this stuff to show that the > market's there. bunnie broke the demographics down pretty well, there's > definitely money to be made. Back to Intel though. It makes me want to > jump on eBay and pick up some older vintage Intel CPU's that didn't have > the management features, but obviously there's no way to know if those > aren't blown wide open by other means. Man, very interesting times we live > in. > > > > Remarkable that you cannot do a verification using a microscope. > > You can do exactly this, and it'll get you to maybe 99% of the way there. > Companies like ChipWorks do exactly this for money. Others do it for hobby > (see: http://www.visual6502.org/, http://siliconpr0n.org/, > https://zeptobars.com/en/, http://www.righto.com/). It can often get great > results. bunnie was playing devils advocate by saying even if you did > this, there are still things that can be present but in an obfuscated > manner, that could be malicious or careless. This doesn't really mean to > throw the baby out with the bathwater. Having a reverse engineered CPU > with a small possibility of shenanigans is still better than having a 100% > proprietary CPU or a 50% proprietary CPU. Security through obscurity and > all that. > > > > We should have libre software hdds and ram. > > Can you elaborate on that a bit? I don't understand what you mean. https://www.theverge.com/2015/2/16/8048243/nsa-hard-drive-firmware-virus-st… Devices like hdd, ram, sd card have their own system software. You cannot access it and do not know what it can do. https://opencores.org/ > _______________________________________________ > 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:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

arm-netbook