arm-netbook

arm-netbook@lists.phcomp.co.uk

1082 discussions

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

arm-netbook