arm-netbook

arm-netbook@lists.phcomp.co.uk

1079 discussions

apologies
by luke.leighton 13 Nov '13

13 Nov '13

apologies to everyone on the list - you may have noticed i'm using brief and curt language at the moment. it's not personal: i just have far less time available and have to be very focussed. l.

5 16

Re: [Arm-netbook] update to EOMA68 specification [was Re: 5" LCD resolution 800x480 working for EOMA but color problems may exist because of miswire]
by luke.leighton 11 Nov '13

11 Nov '13

this is not a miswire. the specification has now changed to reflect what cannot now be changed. l. On Sun, Nov 10, 2013 at 1:15 PM, luke.leighton <luke.leighton(a)gmail.com> wrote: > On Tue, Nov 5, 2013 at 12:43 AM, joem <joem(a)martindale-electric.co.uk> wrote: >> Hi, >> >> 5" LCD resolution 800x480 working for EOMA. >> Details here >> http://www.gplsquared.com/eoma_boot/eoma_boot.html#eoma_with_5inch_lcd >> These displays are about $16 from Aliexpress: >> http://www.aliexpress.com/item/5inch-5-TFT-LCD-LCM-RGB-800-480-Display-TOUC… >> >> I still notice a problem with color - Red and Blue appear to be swapped. > > ok. the specification's going to have to change. we cannot modify > the CPU Card, so the spec has to be changed to match the card. what a > pain. > > l.

4 9

[flying-squirrel] revision 3 pcb gerbers off to factory for inspection
by luke.leighton 10 Nov '13

10 Nov '13

http://rhombus-tech.net/community_ideas/kde_tablet/news/ the gerber files have been sent to the factory. if they're acceptable the PCB will be printed up. l.

1 0

Two Questions: MEB/Card/Case and VGA Proto
by Christopher Havel 09 Nov '13

09 Nov '13

(1) *approximately* how much would it cost me to get an MEB, a current CPU Card (I assume that'd be A10 based?) and a case, almost-ready-to-go (as in, assemble the case, stick in the card, and drop on an OS), including shipping...? I'm in NC, US -- ZIP+4 for me is 27344-6644. (...or are we not quite there yet? I'm a little confused on that one.) To be super de doober clear -- estimate, not quote :P (2a) how realistic is the idea of putting together a prototype of the VGA adapter I came up with using perfboard? (I can't afford custom PCBs, and I can only do thru-hole soldering... I'll be socketing everything if I can work out the wiring for it!) What limitations should I expect, resolution-wise? (2b) alternatively, I have an eBay issue HDMI-to-VGA-and-Audio adapter, one of the ones that pulls power from the HDMI port. (It works, I've tested it.) Would that work with the MEB+CPU Card as things are now (don't mind needing adapter cables, but I am NOT rewiring the thing, even to provide extra power -- my soldering skills are simply too poor).

8 37

freescale LS1021A
by luke.leighton 08 Nov '13

08 Nov '13

http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=LS1021A&fpsp… what on _earth_ is this?? :) dual-core arm cortex a7 with serdes which can do PCIe, SATA3 and 3 gigabit ethernets?? oh and it happens to have pretty much everything that would make a great FSF-Endorseable EOMA68 CPU Card. USB3?? i am confuuused :) l.

4 4

identification EEPROM: writable or not?
by Aaron J. Seigo 07 Nov '13

07 Nov '13

hi.. the LAST thread in the saga! perhaps not as fun to read as your average Terry Pratchett novel, but hopefully as or more useful ;) ok, so this thread is about the decision of whether to permit within the EOMA68 spec for the identification EEPROM to be writable. there are three options: a) the ID EEPROM must be writable b) the ID EEPROM must not be writable c) the ID EEPROM may be writable, but this should not be relied on by any software let’s consider each in turn: a) must be writable this option raises quality issues for consumer devices where easy access to the EEPROM may be implicated in a variety of device damaging events. from virus propagation to accidental destruction of the device tree due to user- initiated EEPROM write ... this just isn’t a great option for many mass-market devices. ergo, (a) is not an option. b) must not be writable for generic chassis (including, but not limited to, engineering boards) being able to write to the EEPROM is a requirement. so if the EOMA68 standard says that the EEPROM “must not be writable” then none of those boards can ever be certified as EOMA68 compliant. this will result in specification defying chassis that work with EOMA68 CPU cards, but which aren’t themselves EOMA68 chassis. encouraging such defiance of the standard simply to fulfill completely valid use cases is a great way to lower the value of the standard" "sure, there’s a standard *wink* *wink* but we all know that not all devices *really* follow it." that is a horrible precedence to set in the very first revision of the spec. c) may be writable, but portable software may not rely on this this is a middle ground which allows devices which would be in violation of the standard in the (b) case to remain compliant, while allowing devices which really are best served by (a) to not only be compliant but also avoid having theoretically portable software not performing correctly on them. basically, (c) implies that the EEPROM must be treated as not-writable in the general case. any user actions or software that attemps to write to the EEPROM is classified as non-portable and device-specific, and the EOMA68 would provide zero guarantees as to the expected behaviour in such cases. as this allows for compliant generic chassis *and* mass-market consumer devices, i highly recommend (c) -- Aaron J. Seigo

6 17

defining the eoma68 eeprom usage
by Aaron J. Seigo 06 Nov '13

06 Nov '13

Hi... On the eoma68 spec it says: "The EEPROM MUST NOT be used for the storage of user data: it is reserved exclusively for EOMA-68." My understanding from past threads on the matter is that currently the only specified usage for this by EOMA-68 is a product ID string + device node tree. It would be most useful if there was a definition on the layout. *cough* A defined data structure allowing for future expansion as well as vendor specific additions would be golden. A simple page based system would suffice afaics. Sth like: Address Size Value ====== === ==== 0x00 2 Page identifier (defined by EOMA68 spec) 0x02 2 Size of page data 0x06 val 0x02 Page data Page data would (obviously) be limited to a maximum 64k in size, but that really should not be an issue given the application (and given how much data you can read at a time via i2c_smbus calls). A checksum could be added to the page header if desired to verify the data read in, but that could also be left to the page specific data. I don’t think a checksum is needed for the device ID page, for instance. Page identifiers would be things like: "0x01 Device ID". A simple, sequential page ordering would to make it easy to use a function lookup table to parse the data. Page 0x00 would be a special “there are no more pages” id. The page ID # space could be split in 2 between EOMA68 and vendor, giving 32768 possible page IDs to both (far more than necessary, but 1 byte isn’t enough, and i don’t see any benefit to trying to pack bytes together and bit twiddling on the software side to unpack them). this would have the nice characteristic of any page id with the high bit set to 1 would be a vendor page. The device ID page data definition might look sth like: Size in Byte(s) Value ========== ====================== 2 Device type (assigned centrally) 2 Device revision 4 Vendor ID (assigned centrally) 4 Product ID (vendor generated, registered centrally) N Manufacturer cstring N Product cstring N Serial number cstring A set of defined pages would be marked as REQUIRED and standard page IDs would be defined as well. I’d actually recommend this definition to be housed *outside* of the EOMA68 spec so that it can be used more broadly by the open hardware community (where such things seem non-existent) and to keep the EOMA68 spec from becoming too monstrous. This approach would have a number of advantages imo: * quick access to any given page without lots of index overhead (just jump through the page headers) * minimum size is self documenting: all REQUIRED pages (e.g. device ID page) become the minimum size for the EEPROM on the device * It avoids (imho) stupid hard coded lengths; it’s no longer 1985, even in the embedded world people and many/most of the products we’re working on have application class processors, and even the ones with “just” microcontrolers can do a hell of a lot such that hard coded page sizes just don’t make sense * It allows some vendor flexibility I am willing to write a small C library that takes a well formed set of data, parses all the EOMA68 bits and offers nice API to access things like device ID data, keeping implementation details at arms length from applications. I could also provide a tool that takes a descriptor file in a human readable format and converts it into a proper EOMA68 packed structure to be written to an EEPROM. Obviously we need agreement on the above before I do this. Some additional semi-random notes from reading the EOMA68 spec regarding the EEPROM: In the "Start-up procedure” section, it gives the EEPROM address as 0xA2 rather than 0x51. I would recommend not putting the address here, but rather dealing with all those details in the "Requirements for I2C” section and giving the EEPROM a proper name there (e.g. the RID EEPROM, for Required IDentification). In fact, I’d re-org that section entirely to be like: Required Interfaces Rational for interface selections* i2c The "Required IDentification” EEPROM USB SATA ETHERNET RGB/TTL * I would remove all mention of specific vendors here; this is a specification after all, so I’d kill the last para about All Winner and costing. I would also move each of the line items about the interfaces to the section on that interface Thoughts? -- Aaron J. Seigo

8 18

identification EEPROM: device ID and device tree pages
by Aaron J. Seigo 06 Nov '13

06 Nov '13

hi... Purpose: assuming agreement on the DIDS layout, below is a proposed definition for the two pages we currently know we must have: * a device ID page * a device tree page Goals: To standardize the process of identifying a chassis (or any hardware device, for that matter?) and the components/devices on the chassis which can not be discovered reliably through probing. Proposal: Define two DIDS conforming pages, one for identification information and the other for device tree information, and assign them Page Identifiers (PID). Implementation: Name: Device Identification PID: 0x01 Page data layout: Byte(s) Value ========== ====================== 2 Device type (assigned centrally) 2 Device revision 4 Vendor ID (assigned centrally) 4 Product ID (vendor generated, registered centrally) N Manufacturer cstring N Product cstring N Serial number cstring Name: Device tree PID: 0x02 Page data consists of a standard “dtb” blob as generated by a device tree compiler (dtc) compliant with the Device Tree standard defined at http://devicetree.org -- Aaron J. Seigo

2 3

identification eeprom: data layout
by Aaron J. Seigo 06 Nov '13

06 Nov '13

hi all, i’m going to try this again in a new thread and with hopefully more clarity. i mixed 4 related topics into one email last time and apparently that doesn’t work here, which is fine. i’ll try again and break this into dedicated threads for each so we can (hopefully) discuss each topic without distraction. this email is about the layout of data on the EEPROM. Purpose: Each chassis needs to ship chassis-specific information such as the vendor and device ID on the identification EEPROM. There must be a defined data structure for that information such that a bootloader/OS loaded on any given CPU card can read it out. Goals: * Appropriate for storage on an EEPROM (low overhead) * Appropriate for access via i2c+smbus * Can be use to store heterogeneous data. Already identified are: * Device and vendor ID * Device tree * Reliable, within the first two constraints, it must involve as few hacks as possible and as many reasonable mechanisms for reliable usage * Extensible, allowing for future expansion as necessary Proposal: To create a specification for the “device information data segment” (DIDS) to be referenced by the EOMA68 standard in relation to the data stored on the EOMA68 identification EEPROM. Keeping it separate from the EOMA68 standard: * keeps the EOMA68 spec concise * allows other open hardware implementations to more easily consider adoption Implementation: The DIDS will consist of a single contiguous block of binary data. The IDS will be segmented into variable size pages, and the IDS will be prefaced with a header. Header The header will be 4 bytes in size with the following layout: Byte Size Value ====== === ==== 0x00 2 Capabilities bytes 0x02 1 Checksum byte 0x03 1 Reserved The capabilities bytes are a bitfield. All bits are currently reserved for future usage and may only be assigned in future revisions of the EOMA68 specification. An IDS for this version of the EOMA68 spec must contain the value 0x00 The checksum byte is the CRC-8 result of the IDS. (The CRC-8 algorithm must be referenced from the final specification to avoid any ambiguities.) The final byte is reserved for future use. Pages Other than the header, the remainder of the IDS will be divided into variable length pages. Each page starts with a header with the following format: Byte Size Value ====== === ==== 0x00 2 Page identifier (defined by EOMA68 spec) 0x02 2 Size of page data The page identifier (PID) is used to detect the layout of the data in the page, and all PIDs up to and including 32768 are defined in the DIDS specification. Values above 32768 are reserved. The page data then follows directly after the header. The maximum size of page data is limited by the page size value contained in 2 bytes, or 64k. A page may consist of 0 bytes of data, which may be used in cases where the PID itself is sufficiently informative on its own. The only page layout exception allowed is for the last, or terminal, page. The 0x00 value is used to identify the terminal page, and the remaining 2 bytes are ignored and therefore may contain any values. The terminal page always has page size of zero, regardless of the value stored in the last 2 bytes. Navigating between pages becomes an exercise in reading page headers, seeking to the end of the page (processing the contents along the way if desired) and repeating for the next page until the terminal page is encountered. There is no page index. Variable length pages without an accompanying index means that it is not possible to seek directly to a given page; however given the relatively small size of the IDS, the small number of pages and that the headers allow skipping from page to page this is deemed acceptable. -- Aaron J. Seigo

4 7

[flying squirrel] need quick review of power input for RTC battery on ATSAM4S
by luke.leighton 06 Nov '13

06 Nov '13

this is mainly a question for joe (and anyone else with schematics review experience!) the goal is to provide dual-power for the ATSAM4S. atmel recommend using 2 diodes however the voltage for the IO needs to be above 3.0v in order to run USB, the AXP209 can only output 3.3v max and a diode would suck 0.7v off of that. so i've been advised to use a MOSFET instead, and need to check it's going to work. so here's the schematic that needs checking: * http://hands.com/~lkcl/eoma/kde_tablet/rev3_review/atsam_vddio_power.png * note the diode which provides backup power (from the AXP209 RTC supply) * also i'd like to use the AXP209's "PWROK" signal to control when the ATSAM4S powers up. the datasheet says it's "HIGH" when power is "OK" and it starts off "LOW" when the AXP209 starts up. as the AXP209 PWROK signal is "HIGH" when "OK", that's why i *believe* that the transistor (Q6) is needed, to invert that so that when PWROK is "HIGH", the MOSFET delivers power. greatly appreciated a quick review of that logic. l.

2 5

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

arm-netbook