arm-netbook

arm-netbook@lists.phcomp.co.uk

8 participants
1077 discussions

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

arm-netbook