- arm-netbook - Mailman test

About, the rk processor.
by zap 22 Apr '17

22 Apr '17

something interesting I saw is that in the update picking a processor, it shows rk3188 as the rockchip processor you were going to reverse engineer. on the other hand, your rhombus-tech link shows that your looking at rk3288? Not to be annoying constantly, but I am curious are you looking at one or both? I appolgize if there is something I may have missed.

4 8

Re: [Arm-netbook] Certification Mark: My hat in the Ring
by John Luke Gibson 21 Apr '17

21 Apr '17

Didn't notice that it didn't go through. Here's the attachment.

7 11

System 76 - Entering Phase 3
by Mike Leimon 21 Apr '17

21 Apr '17

Lyberta: > Couple of points that got my attention. They say Linux instead of > GNU/Linux. Open source instead of Free/Libre Software. They also > mentioned Ubuntu. This was enough to me to stop having any respect for > them. At least based on that post. While I understand what you are saying I don't see how having one of the most Linux friendly laptop manufacturers making a laptop based on the EOMA68 standard would be a bad idea. Let's say hypothetically, they decided to make the most awesome modular EOMA68 laptop possible, dual usb-c 3.1 and the works. Even if they did ship the system with a CPU card that was running Ubuntu on it, the whole EOMA68 standard works on the premise that if you can plug it in, it will work. Therefore, couldn't you just swap out out the CPU card and put any other compatible EOMA68 CPU card in there to enjoy the benefits of a well designed laptop and run your preferred distro instead? I understand that Ubuntu isn't your distro of choice (it isn't mine either) however, I think that there aren't many Linux friendly computing companies out there, let alone those that don't sell computers running anything other than Linux. I think that it is certainly important to have principles and to stick to them when possible however, when there seems to be as much common ground between what we want to accomplish and what they want to accomplish I am thinking it might be better to at least try working together than to hunt around for reasons to be divisive. Allan Mwenda: > Well i dunno, system76 would want to make the fastest card not necessarily the freest. I'm not so sure about this. I get the impression from reading some of their blogs and whatnot that they spend quite a bit of time and effort vetting the particular components they are putting into their systems to guarantee compatibility with their Linux distribution of choice. So while I do think they put some degree of importance into making sure that their systems have good performance, I do think they are aware of what having upstream driver support means for system components. I would agree that they would probably want to get the best performance out of a CPU card that they could however, I don't think that they would be too keen to do so at the cost of selecting a chip that didn't have some degree of upstream support. l: > i sort-of thought about this overnight, and i think you're right, > allan. the hardware they're selling is typically mid to high-end x86 > hardware [plus yes they talk about ubuntu] something like EOMA200 > would be a much better bet... but then so would many of the other > (industrial) modular standards for their needs. I suppose I still don't see the harm in bringing the EOMA68 concept up to them. The worst they could say is that they aren't interested. However, they could potentially be a pretty good ally. Also, I did notice that in the past few months they added a 96 core arm server to their lineup: https://system76.com/servers/starling Which means to me that they aren't completely wedded to solely x86 hardware. Even with their tendency to build higher end laptops and systems I think that an EOMA68 based laptop could easily exist within their line-up as an upgradable chromebook alternative (something priced in the $250-500 range). That would allow them to test the EOMA68 waters while at the same time allow them to build on and expand their higher-end line of x86 systems as well. I guess all I am trying to say is, that we won't know what a person or a company will do until we ask the question.

5 5

The R/Evolution... will not be Televised
by Luke Kenneth Casson Leighton 21 Apr '17

21 Apr '17

http://www.metrolyrics.com/the-revolution-will-not-be-televised-lyrics-gil-… The R/Evolution will not be televised, NDA/d or incentivized. The R/Evolution will not be patented, DRM'd or proprietized. There will be no binary blobs to spy on you, no nagware to pry your money from you, or a rootkit to pre-fit, like the BMG baloney that harmed the modern Army: CDs played in secret bases: Classified files sent to Sony. The R/Evolution will not be televised: The R/Evolution will not be televised. Your freedom from reasons you don't know or even care about, exchanged for convenience or profit or meta-data or the contents of your pocket, stolen without your knowledge but you signed your rights away with a Hobson's Choice. Without the R/Evolution There will be no V for Vendetta, You'll be staring at a beretta for sharing files that much better than the RIAA or the Mafia ever did. Your friends will not know about the Internet Ghetto because they're in it already: when you're joined by so many you can't call it Net Neutrality if you agreed to the FCC's perfidity by funding the only Telco Monopoly that's in your vicinity. No my friends: The R/Evolution will not be televised because the Internet's incentivised, controlled and illegalised: Tim Cook's words "we did it to ourselves" ringing in our ears like bells, our defense shouted out "I HAD NOTHING TO HIDE" as your health insurance climbs or your're airport flight denied because the DNA of someone whose name rhymes with yours was a "perfect match" The R/Evolution will not be televised, because nobody will own a television. They'll be staring at a smartphone that they think they own sitting next to half a dozen people in a restaurant, all silent, only laughing out loud because someone made a joke on a Facebook group everyone at the table is in. The R/Evolution will not be televised: The R/Evolution will not be televised. it will be live.

4 5

Certification Mark: My hat in the Ring
by John Luke Gibson 21 Apr '17

21 Apr '17

The fish borrowed from Wenqing Yan's Fisheye Placebo. I'm sure it's modified enough to be fair use, but contacting them might be a good idea.

1 0

microdesktop v1.7 arrived, works fine... but...
by doark＠mail.com 19 Apr '17

19 Apr '17

On Thu, 6 Apr 2017 06:12:16 +0100 Luke Kenneth Casson Leighton <lkcl(a)lkcl.net> wrote: > ok so the story goes like this: > > back in august 2016 i got the A20 card up and running with mainline > 4.7rc1 (or thereabouts), including patching in NAND support for a > proper mtd device. it worked... up to a point... except when u-boot > did a complete scan it CORRUPTED the NAND flash... just from reads. > > i figured this was "just software" as it's pretty experimental, and > the 3.4.104 sunxi-nand works perfectly. > > fast-foward to a few months ago, when i was testing the external > micro-sd slot, weirdly it resulted in a kernel segfault *from the > sunxi-nand driver*. i thought, "that's weird, might be to do with > current-fighting from the micro-desktop PCB not having level-shifting" > > sooo... that's now fixed: the micro-sd slot works perfectly through > the new revision 1.7 microdesktop's level-shifting IC. however i got > exactly the same kernel segfault in the sunxi-nand driver, so i > temporarily took it out of the kernel config, tested again, and yes, > the micro-sd worked fine. > > ... except that when i booted it up again, the nand flash had been > corrupted. now, bear in mind there's *NO DRIVER INSTALLED*. > > this is just too weird for me to deal with. not to mention, because > of the age of the A20's Boot ROM there is now a limited set of > "legacy" NAND ICs available i've had it with them. > <snip> I'm sorry to hear you are having trouble. Personally, I like the super weird Linux problems. Can I have one of those malfunctioning alpha boards to try to figure out what's going on? I grant you that I've never worked on something quite this low level before, so I won't be solving it any time soon, but it would be worth looking into just so that we don't have this problem again (yes, I would like to learn how to create SBCs). Thanks, David

2 1

Fwd: Eurocircuits NEWS - Fantastic Q1-2017
by Luke Kenneth Casson Leighton 18 Apr '17

18 Apr '17

i don't normally like/forward this kind of stuff but just as a reminder, the shiny PCBs i did of the laptop were from this company. the pricing for the (very specific!) budget-end PCBs with 12mil vias, 10mil tracks and clearance and no green colouring was really *really* low cost, for europe: i was very surprised. also i was extremely impressed with the online viewer / gerber checker, it took a ton of hassle out of what would otherwise meant a manual process for them, which more than certainly is one of the reasons why they're affordable. l. --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 ---------- Forwarded message ---------- From: Eurocircuits <euro(a)eurocircuits.com> Date: Tue, Apr 18, 2017 at 9:28 AM Subject: Eurocircuits NEWS - Fantastic Q1-2017 To: Luke <luke.leighton(a)gmail.com> PCB services <http://relay.eurocircuits.com/sendy/l/sVzVSf8nL8whQSbMX05zfA/NGzaHKIfCdeyt4…> | eC-Solutions <http://relay.eurocircuits.com/sendy/l/sVzVSf8nL8whQSbMX05zfA/iVQmtsRh7639Jh…> To: luke.leighton(a)gmail.com, 75 Katwijkstraat, 2585VM Den Haag, Netherlands Dear Luke Leighton Eurocircuits NEWS - Fantastic 1st quarter of 2017 The New Year 2017 took a high flight right from the start. Customers were very active and Eurocircuits was filled with eager to launch new projects. Comparing the first quarter of 2016 and 2017 in PCB sales gives the following result: 1st quarter of the year 2016 2017 Customers 6 103 6 359 4,2% Orders 26 320 29 132 10,7% PCB sales 5 482 522 6 198 055 13,1% This proves to be a good start for the year. We will work very hard to continue to earn the trust of our continuously growing number of customers. Eurocircuits NEWS - Q1-2017 PCBA Visualizer launched in Beta Our Eurocircuits team was very exited to present our newest tool: PCBA Visualizer. Our PCB Visualizer tool for DRC/DFM analysis of the bare board has established itself as proven value to our customers. PCBA Visualizer or Assembly Visualizer is the natural extension of PCB Visualizer. PCBA Visualizer offers DRC-DFM functionality on the populated board even before anything has been produced thus allowing to fix mistakes at minimal cost. PCBA Visualizer has been received with a lot of fantastic feedback but also many questions about how you can utilise the PCBA Visualizer to save time and money by Verifying your Gerber data matches your Bill Of Materials (BoM) and Component Placement List (CPL), an early warning system to identify data issues and eventually resolve them online. You may have noticed when saving your offer the option to participate in our Beta testing In order to take advantage of this tool and understanding how you can benefit and correct your data please take 15 minutes to look at our PCBA Visualizer video below: <http://relay.eurocircuits.com/sendy/l/sVzVSf8nL8whQSbMX05zfA/ToQmYRPKCoU7tZ…> If you have any questions about this or any other service please feel free to get in touch and we will be more than happy to help! Try out our online chat! Blogs *Company news* - Looking back at 2016 <http://relay.eurocircuits.com/sendy/l/sVzVSf8nL8whQSbMX05zfA/FGuCoTARCvI763…> - New building in Eger - time laps video <http://relay.eurocircuits.com/sendy/l/sVzVSf8nL8whQSbMX05zfA/DeKwwo763zVOGm…> *Production* - The Impact of Different Copper Thicknesses on the Cooling of a SMD-Voltage Regulator: technical page <http://relay.eurocircuits.com/sendy/l/sVzVSf8nL8whQSbMX05zfA/z7630kqybMUfJA…> - Why you should supply us with Gerber X2 files? <http://relay.eurocircuits.com/sendy/l/sVzVSf8nL8whQSbMX05zfA/O763Is0sX9pkqc…>: All on Gerber X2. *eC-tools* - SMS messaging <http://relay.eurocircuits.com/sendy/l/sVzVSf8nL8whQSbMX05zfA/jTVjpRjmquGcKi…> for time critical orders - New Auto-repair function in PCB Visualizer <http://relay.eurocircuits.com/sendy/l/sVzVSf8nL8whQSbMX05zfA/763PeKx42FHjd8…>: automatic repair solution for annular ring issues. *eC-equipment* - eC-placer <http://relay.eurocircuits.com/sendy/l/sVzVSf8nL8whQSbMX05zfA/Ez7qM6qpa3Xwzu…>: fast, accurate PCB prototype assembly solution./li> If you would like us to produce a blog or white paper on a particular aspect of PCB manufacturing technology or PCB soldering, e-mail us at euro(a)eurocircuits.com Interact with us The best way to share ideas and knowledge is face to face. *Come and meet us at* - Check out our eC-calendar eC-calendar <http://relay.eurocircuits.com/sendy/l/sVzVSf8nL8whQSbMX05zfA/2u6rKDqg87fYtG…> *Eurocircuits meets students* - TU Delft Solar Boat Team <http://relay.eurocircuits.com/sendy/l/sVzVSf8nL8whQSbMX05zfA/koG5qJylRo763d…> – sponsored by Eurocircuits - STORM Eindhoven <http://relay.eurocircuits.com/sendy/l/sVzVSf8nL8whQSbMX05zfA/ez892tduYfWixD…> – an interesting and successful student project - Eurocircuits’ PCBs in the most efficient urban concept hydrogen car of Green Team Twente <http://relay.eurocircuits.com/sendy/l/sVzVSf8nL8whQSbMX05zfA/Aj763muwtPkO42…> *Eurocircuits N.V.* Antwerpsesteenweg 66, 2800 Mechelen, Belgium. Tel: +32 15 28 16 30 Fax: +32 15 28 16 31 Email: euro(a)eurocircuits.com Website: www.eurocircuits.com <http://relay.eurocircuits.com/sendy/l/sVzVSf8nL8whQSbMX05zfA/892u92h892pyCd…> If you don't want to receive updates. please unsubscribe <http://relay.eurocircuits.com/sendy/unsubscribe/7gUZsffeQO9mqTq7633T2xHBlD8…>.

1 0

ZeroPhone
by Louis Pearson 18 Apr '17

18 Apr '17

https://hackaday.io/project/19035-zerophone-a-raspberry-pi-smartphone Not exactly a netbook, but this looks like an interesting project. How much work would it take to create something like this using EOMA68? I know I would be interested in a device like that.

10 45

Re: [Arm-netbook] ZeroPhone
by dumblob 17 Apr '17

17 Apr '17

> > > Why not use the STM32F072 for audio on the laptop? > > not good enough dynamic range and quality, and it is still necessary > to have a amplifier. i tried doing audio on an STM32F103RBT6 - i > learned that it would not be enough. i *almost* managed it though. > http://www.henryaudio.com/ - the components used in this device would be my inspiration when it comes to audio quality

2 1

microdesktop case, laptop pcb1 and pcb2, etc.
by Luke Kenneth Casson Leighton 16 Apr '17

16 Apr '17

https://www.crowdsupply.com/eoma68/micro-desktop/updates/taiwan-micro-deskt… ok so i'm almost ready to send the laptop pcb1 and pcb4 off for prototyping, this gets about 20% the way towards getting the laptop done, but also is planned to be the basis of a new housing (an all-in-one PC) where sharing the exact same main PCB as in the laptop will cut costs of production of both. mark (van de borre): about the casework i've sent the DXF files off to a china prototyping company just so i can get something quickly. i don't expect them to be perfect first time, and to have do do another iteration. i'll want to do one last full systems test then the microdsktop v1.7 including casework can go into production. i haven't worked out if i have to do 2,000 of the corner pieces as 3D-printed or to get them injection-molded, at 2,000 pieces it *might* be worth doing as injection-molding. btw if anyone would like to see the gerber files for the three latest pcbs, they're here: http://hands.com/~lkcl/eoma/laptop_15in/pcb1/laptop_15in_pcb1_cam/ http://hands.com/~lkcl/eoma/laptop_15in/pcb4/laptop_15in_powerboard/ http://hands.com/~lkcl/eoma/microdesktop/eoma68_microdesktop_cam/ l. --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

2 4

microdesktop v1.7 arrived, works fine... but...
by Luke Kenneth Casson Leighton 07 Apr '17

07 Apr '17

ok so the story goes like this: back in august 2016 i got the A20 card up and running with mainline 4.7rc1 (or thereabouts), including patching in NAND support for a proper mtd device. it worked... up to a point... except when u-boot did a complete scan it CORRUPTED the NAND flash... just from reads. i figured this was "just software" as it's pretty experimental, and the 3.4.104 sunxi-nand works perfectly. fast-foward to a few months ago, when i was testing the external micro-sd slot, weirdly it resulted in a kernel segfault *from the sunxi-nand driver*. i thought, "that's weird, might be to do with current-fighting from the micro-desktop PCB not having level-shifting" sooo... that's now fixed: the micro-sd slot works perfectly through the new revision 1.7 microdesktop's level-shifting IC. however i got exactly the same kernel segfault in the sunxi-nand driver, so i temporarily took it out of the kernel config, tested again, and yes, the micro-sd worked fine. ... except that when i booted it up again, the nand flash had been corrupted. now, bear in mind there's *NO DRIVER INSTALLED*. this is just too weird for me to deal with. not to mention, because of the age of the A20's Boot ROM there is now a limited set of "legacy" NAND ICs available i've had it with them. now, i _could_ convert to eMMC but it's too much of a major redesign: it involves disrupting the RGB/TTL tracks, and may require at least two more rounds of pre-production prototyping... ... it's too much: it's too risky... and i'm getting fed up. so. what i'm going to do instead is: cut the NAND IC entirely, then wire SDC2 (which is the same pins as the NAND) to the *ON-BOARD* Micro-SD card slot, instead. what that will give is *two* bootable Micro-SD card options, priority being first the external one (MMC0) and second the on-board one (MMC2). the reason why this will be possible when it was not possible before was described in another post to the list a couple weeks back: there's simply no way to route the tracks on such a small 6-layer PCB with the NAND tracks going from right-to-left, MMC0 has no room to go left-to-right and at the same time MMC3 going left-to-right. that's over 30 tracks trying to cross through space that will only take about 15. BUT... ... if the NAND tracks are *removed*.... *NOW* i can route MMC2 (right-hand-side of the A20 pins) to the on-board MicroSD slot (right of the Card). i can always do a variant which has eMMC later.... but right now i just want to get something out the door as soon as possible with as little risk as possible. this approach does have the advantage that the BoM is about $5 less.... but it does mean i will need to get something like... 1,000 MicroSD cards, instead! l.

5 6

Where did you source the screens from?
by David Niklas 06 Apr '17

06 Apr '17

Hello, I was wondering where you bought the laptop displays from? Thanks, David

2 1

please use libre services for public discussion and development of EOMA68 libre hardware and software
by Luke Kenneth Casson Leighton 03 Apr '17

03 Apr '17

>> https://github.com/normandc/EOMA68/tree/master/Microdesktop/Images > > normand, can you please not use non-free proprietary git services for > this project, it sends completely the wrong message. please delete > that github repository immediately, it brings the EOMA68 project's > reputation into disrepute and that's completely unacceptable. correction: if you wish to you use proprietary services for private (paid, subscribed, totally isolated from public view) use that's absolutely fine and is entirely your prerogative and decision, but if it's public and *especially* if it's for interaction with people on this list, thus giving the impression that the use of proprietary non-free services for the development of libre hardware and software is perfectly acceptable at this very early phase of the EOMA68 project, that's not an acceptable impression to make. sorry for not mentioning it earlier. l.

6 6

microdesktop casework as DXF files for laser-cutting
by Luke Kenneth Casson Leighton 03 Apr '17

03 Apr '17

hi i'd like to introduce mark, one of the fosdem staffers, who runs a company http://lusis.eu and he has offered to do the micro-desktop casework. however first thing that's needed is: GPLv3-licensed DXF files! now, these need to be done as 3mm stacks, so that will be something like 7 separate DXF files. i _could_ do it but i'd like to give people the opportunity to be part of this project, first. we're gonna have to do the DXF files from PDFs (datasheets, PCB layout) and from looking at the photos of the prototype that was arranged by crowdsupply 2 years ago. http://hands.com/~lkcl/eoma/microdesktop - look for the 1.7 pcb pdf if you'd like to help. also apologies, being in china, the internet speed here is so f*****d i simply can't keep up with messages. i've seen the logo discussion, i'll be able to review it when i'm back in taiwan some time around the 1st april. if you are going to reply and would like to help with the DXF drawings PLEASE BE BRIEF and STAY ON-TOPIC under this subject-line. i know we generally don't do that here on arm-netbooks but in this case it's really important.... at least for the next 10 days. thanks everyone. l. --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

14 65

back to taiwan, internet access not available for a while
by Luke Kenneth Casson Leighton 29 Mar '17

29 Mar '17

am moving to a new apartment, internet access has to be applied for. don't know how long that will take. will need to arrange borrowing internet access. l.

4 6

passthrough card stm32f072 firmware
by Luke Kenneth Casson Leighton 21 Mar '17

21 Mar '17

On Mon, Mar 13, 2017 at 9:33 PM, Albert ARIBAUD <albert.aribaud(a)free.fr> wrote: > Hi Luke, > > Le Mon, 13 Mar 2017 16:13:26 +0000 > Luke Kenneth Casson Leighton <lkcl(a)lkcl.net> a écrit: > >> ah! albert! did you get my email, am looking to invite you to help >> with I2C EEPROM reading for the passthrough card (which has another >> STM32F072...) > > Yes -- sorry I did not answer this week-end. Of course I'd be happy to > help! aawesome okaaayy here's the schematic: http://hands.com/~lkcl/eoma/passthrough/ EOMA68_PASSTHROUGH_3.pdf i just realised i made a couple of mistakes, the reset "current-sinking-protecting-against-overvoltage" diode is the wrong way round, and the BOOT0 TP should be a 3.3v not ground oh well that explains a lot about why i can't see the damn thing on the USB bus after trying to reset it... :) ok the primary task that's needed is: to read the VESA I2C EEPROM from the microdesktop board and to feed the resultant data out, on request, to the TFP401a. so it's two main parts: * read (in bit-banging mode!) an I2C EEPROM * emulate an I2C EEPROM (probably best done via DMA and interrupts) let's track it through - microdesktop pinouts: http://hands.com/~lkcl/eoma/microdesktop/ v1.7 schematic microdesktop SCL 17 microdesktop SDA 22 and that goes through to.... GPIO_2 on passthrough schematic MCU_PWM0 on passthrough schematic which are PC6 (needing to be SCL) PA8 (needing to be SDA) respectively. the *secondary* task is that a userspace-programming firmware bootloader/uploader is needed... *on the USB* interface - the STM32F072 doesn't actually have one. i could have left BOOT0 pulled HIGH so that the STM32F072 always goes into bootloader mode but it may be needed for early power-on initialisation and to have some sort of "default" EDID response as well as bring up the TFP401a in cases where people simply don't upload firmware to it at all. the first part is critical to the functionality i believe - a first prototype phase would be to just set up a static EDID buffer (static string) and return that as an emulated I2C EEPROM "read" operation. btw if you haven't _got_ an I2C EEPROM of some kind (AT24C64) kicking around then perhaps simply wiring up two I2C interfaces back-to-back in DMA mode would do the trick :) *really* appreciated your help here albert. l.

2 7

Logos
by Mike Leimon 19 Mar '17

19 Mar '17

> The first one has something that looks suspiciously like a penis on the > bottom-right. > > I'm sure it doesn't look like that if you're an electrical engineer, or > whatever, but people -- especially kids and teenagers -- *will* see > that, and that's probably not the kind of attention EOMA needs. :) My apologies for the unintended phallic imagery... That wasn't what I was aiming for. I was actually just trying to use some different EE symbols to reconstruct the `M` and the `A` of EOMA. I was using the list of symbols from the following reference. http://rapidtables.com/electric/electrical_symbols.htm I think the offending symbol you are referring to is the `OR` symbol. Just to better explain what I was aiming at, I took some colors to the original symbols to highlight the individual letter representations. http://i.imgur.com/jjUbFx5.png In the color coded (first) version the E is in red, O is in blue, M is in green and A is in pink. > By the way, I think these are the best logos I've seen on this list. The > only gripe I have (well, other than the unintentional phallus in the > first one) is that they don't really seem to represent modularity; the > first one, in particular, rather looks like a circuit board, and one of > the major points of EOMA is that users *don't* have to look at circuit > boards to perform upgrades; they just have to pop out a card and replace > it with another card. It seems like there must be some possible way to > use this basic logo concept to represent that somehow. In both of the logos that sent out the `E` was actually supposed to represent an EOMA CPU/passthrough card. That is why it looks like a squatty elongated E. I represented the O in the way that I did as I wanted it to represent the PCMCIA slot or housing that it fits into. So together the E and the O represent a modular CPU card being inserted into a device/housing. For the first logo I was intending to show that the specification provides an incredibly low level connection between the CPU card and the housing. For the second logo... I was thinking that I liked some of the ideas and imagery of the first but that it was way too busy. Plus and end user might get a bit bewildered by it. Oh and I have one more general comment about logo creation of this sort... I think that it is very important to make sure it will look good rendered in only black and white because, that is essentially what it is going to look like when the logo/certification mark gets silk-screened onto a product. -Mike

4 3

Logos
by Mike Leimon 19 Mar '17

19 Mar '17

Okay, I feel like I should take a swing or two at this as well. In the following two cases, there isn't any special font being used. I'm just using inkscape to trace out the characters that I want show... http://imgur.com/GrnfRHe Of these two logos that I sent, my preference is for the second. My personal opinion is that you shouldn't try and get too hung up about the acronym that you are trying to capture and represent... (I say this even though I did my best to incorporate the letters... blah). I think sometimes that capturing the concept is more important than capturing the acronym. Case in point, take a look at the USB logo: http://4.bp.blogspot.com/-cId-qdXRcqg/UXE0Nya6FAI/AAAAAAAAAPU/8KGiICpEQa0/s… The logo is incredibly simple and doesn't try and spell out USB.. however, it does capture the essence of the interface and what it seeks to accomplish and I think that is what makes it memorable. That is really all I wanted to drop by and say. -Mike

7 8

Logos
by John Luke Gibson 18 Mar '17

18 Mar '17

I was wondering what people think of the Cloister Black letter E for the EOMA logo. I can imagine that some people might find it hard to read or understand. Legible enough any one would suppose? http://www.deathnotenews.com/uploads/1/7/3/9/17393465/5192168_orig.png In case anyone is worried about copyright claim, apparently the original authors found the font on gimp, which is absurd because it's not an in-built font so it must have been a system font that they just casually assumed was free since they found it in gimp >.> Regardless, I found the font as a free [as in beer] font on a font sale website with the name matching and each letter meticulously matching. Through there I found the author's website which is in German and has many other font downloads of various styles. Through google-translate I discovered that german text on the page said free for "private" use, whatever that means (maybe if someone knows German?) and they reiterated "you may use" multiple times in the comments. Unfortunately, they seem to have a lot of fonts on the website which they've been updating occasionally "Cloister Black" included. In fact the name no longer shows "Cloister Black" on their website and instead shows "Old English", but through the wayback machine I found an archived version that shows "Cloister Black". I'll post the link here when I get a chance, I saved it on my other computer.

7 14

rk3288 ddr ram initialisation reverse-engineering.... a ray of hope!
by Luke Kenneth Casson Leighton 16 Mar '17

16 Mar '17

yay i believe i may have _finally_ tracked down the issue with the DDR3 RAM initialisation - not the actual underlying problem with the PCB layout (which is down to impedance and is probably going to need insertion of a bank of... probably like... 60-80 resistors... *sigh*...) but with initialising the RK3288 RAM controller at the much lower clock rate of 200mhz. i _really_ should have checked the rkclk_configure_ddr function in u-boot-rockchip's clk_rk3288.c file first, but i have to say it's been great fun doing reverse-engineering again. i basically took the rkbin/rk32/ 32_LPDDR2_200MHz_LPDDR3_200MHz_DDR3_200MHz_20150318.bin file which rockchip supplied - and which is confirmed as successfully initialising the DDR3 controller (at 200mhz) on the EOMA68-RK3288 board - and have been rapidly working it back towards c-code. ... probably unnecessarily as it turns out, because *actually* what i quite likely only needed was to add "200mhz" as one of the supported switch-statements in rkclk_configure_ddr! ooops.... now, it has to be said that if i had not got as far through the reverse-engineering as i have, i would not have had the information that i needed in order to easily work out the PLL settings for the 200mhz clock-rate. the reason is quite straightforward: the proprietary binary is SIGNIFICANTLY more comprehensive in its initialisation, parameterisation, safety-checking and follow-up testing of the memory. i can see _where_ the u-boot-rockchip sdram initialisation comes from: many of the functions are the same but the key strategic ones are significantly improved. so, anyway, it's late evening, so i cannot go round to my host's house straight away and test this out, but i will do tomorrow first thing :) l. --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

1 0

AMD considering releasing the PSP
by Julie Marchant 15 Mar '17

15 Mar '17

Trisquel forum thread here: https://trisquel.info/en/forum/amd-apparently-taking-requests-feedback-comm… And this is the Reddit thread where it happened: https://www.reddit.com/r/Amd/comments/5x4hxu/we_are_amd_creators_of_athlon_… It would be a good idea to encourage AMD to do this. Who knows? It could lead us to an x86 EOMA computer card of some sort in the future. ;) Not to mention, it would just be better for us overall to have AMD on our side. -- Julie Marchant https://onpon4.github.io Protect your emails with GnuPG: https://emailselfdefense.fsf.org

9 32

AMD considering releasing the PSP
by Mike Leimon 15 Mar '17

15 Mar '17

> Ok so basically this will allow type II cards( smaller) to fit into type > III housings and utilize higher clocks ? I think the idea is a bit better than that even. I think that by default all Type II cards must adhere/support the 5W upper thermal limit. However, even in a Type II slot the card may negotiate with a housing and if the housing can support heat removal from the card to allow it to operate at a higher (10W?) limit, then the card may then utilize a faster clock rate or activate more cores (at that point). > Also from my understanding the > type III card will be the physical form factor used for the EOMA 200 > standard ? No, I think this is a misunderstanding. I'm pretty sure that the EOMA-200 standard will have 202 pins Please see the following page for details: http://elinux.org/Embedded_Open_Modular_Architecture/EOMA-200

2 1

Prototype Circuit Board Printer
by Mike Leimon 15 Mar '17

15 Mar '17

Just in case you all haven't seen this before (or haven't thought about it). I was thinking that since it seems like lots of prototype boards are being made perhaps a prototype circuit board printer like the following might be useful for prototyping some of the simpler support boards (e.g. some of the laptop PCBs). https://voltera.io/ I'm not exactly sure how much cheaper (if any) that it would be compared to getting prototype boards printed up by another company but, I could imagine that being able to print up your own circuit boards would probably help speed up the design/prototype iteration cycle. -Mike

2 1

Funding
by mike.valk＠gmail.com 15 Mar '17

15 Mar '17

Interesting read: https://medium.com/open-collective/why-and-how-to-fund-the-open-source-proj…

1 0

EOMA68 booting process
by Luke Kenneth Casson Leighton 14 Mar '17

14 Mar '17

On Thu, Mar 9, 2017 at 3:46 PM, mike.valk(a)gmail.com <mike.valk(a)gmail.com> wrote: thanks for the explanation, mike. > So for EOMA we must set/invent a standard which Installers can use > regardless the SoC type used in the EOMA card. ah. right. the way i see it, the only thing that needs to happen is that the card has to have enough on-board storage to get to u-boot (or similar) where it can then recognise the EOMA68 I2C EEPROM (and get the ID info) or for it to (pretty much) always boot externally and do the same. anything beyond tthat needs to be analysed *really* carefully, right through its impllications down the *entire* lifecycle. which is why i currently have it as (pretty much) "card must self-boot and must adapt to EOMA68 EEPROM ID" and it's left as generically as that > On A20 et.al. there is the FEL mode. Which is initialized by that first > loaded program. from ROM. > In this FEL mode you can push an image over USB-OTG. But > that requires an active USB host not just an USB thumb drive. i do this all the time. i don't develop for the A20 in any other way. when i see the shit that people get themselves into *even though usb-fel was written years ago* by trying to un-fuck their systems using LIVESHIT.EXE and other crap i'm just... staggered and genuinely confused. it's *real* simple and needs just *seven* lines of bash script: fel write 0x2000 ./fel-boot-spl-EOMA68_A20_2GB.bin sleep 1 fel exe 0x2000 sleep 1 fel write 0x4a000000 u-boot.new.bin sleep 1 fel exe 0x4a000000 the fel-boot-spl.bin is actually the u-boot-spl.bin executable that's compiled by default in u-boot if you select "CONFIG_SPL". the u-boot.new.bin is u-boot without the spl part tacked onto the front. it really couldn't be simpler. you can if you want directly upload the linux kernel, script.bin, dtb file, initramdisk WHATEVER YOU LIKE directly into memory and then execute it DIRECTLY. you don't even need u-boot to do it. > http://linux-sunxi.org/FEL/USBBoot#Booting_U-Boot_over_USB > http://linux-sunxi.org/BROM > > So the question is are "we" going to build such a thing? i'm yet to be convinced that it's necessary, beyond adapting u-boot and the linux kernel to read and adapt to the ID in the EOMA68 EEPROM. what specifically did you have in mind? l. > >> >> >> -- hendrik >> >> >> _______________________________________________ >> 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 > > > > _______________________________________________ > 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 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

arm-netbook