arm-netbook

arm-netbook@lists.phcomp.co.uk

8 participants
1076 discussions

[eoma68] power issues
by luke.leighton 02 Nov '13

02 Nov '13

folks, as you saw a couple months back we have an issue with the EOMA68-A20 CPU Card where [without authorisation] some changes were made to the power distribution by the ODM. i still haven't worked out if those changes were/are a blessing or a curse. a reminder of the issue: they connected the ACIN *directly* to VBUS on the USB-OTG input, removing the usual safety and detection features (a SY6280 plus use of some GPIO) which allow programmable (or AXP209-controlled at least) switching between USB-OTG power and 5V input power. i have this sneaking suspicion that the solution might actually be staring me in the face, so wanted to run it by people, see what they thought. what i *believe* the solution is, is to simply move that USB-OTG/5V detection circuitry (in this case a SY6280 plus use of some GPIO) onto the I/O boards, and to effectively treat the EOMA68 5V power "as if" it was a USB-OTG two-way power system. so rather than have in the spec "you must provide 5V power", change that to "you must imagine that the power circuits are identical to what you'd normally have to do for USB-OTG". which, because wits-tech directly connected the bloody USB-OTG power to the ACIN by fusing the pins together at the AXP209 is actually exactly how it is. the advantage of this change (i say change, it's more like being frog-marched unwillingly towards a solution...) is that if people happen to accidentally plug in the CPU Card into a USB-OTG socket and keep it powered up, then a) the CPU Card will survive unplugging and can transition happily from one chassis to another b) as long as it doesn't draw too much current it would be possible to power a portable device *from* the USB-OTG... or at least charge its battery (if it has one) c) i'm sure there's something else... anyway i *think* it's a blessing - it would just have been nice to have been consulted by the ODM, eh? if anyone's got any other suggestions on how to manage USB-OTG power switching it would be very helpful to hear them: i will put them into the EOMA68 spec as implementation guidelines. l.

1 0

Double checking script.fex for eoma68-a20
by Ryan Mullen 01 Nov '13

01 Nov '13

Hi, I am booting an eoma68-a20 using the script.fex (converted to script.bin with sunxi-tools' fex2bin) found here: http://rhombus-tech.net/allwinner/a20/boot/script.fex I have run the instructions found on that page under the subtitle "setup boot instructions for booting directly off of sd/mmc" and all seems well. However, my kernel (linux-sunxi 3.4 with some custom config options) tells me this when booting: [ 1.663649] [mmc-msg] sw_mci_init [ 1.667156] [mmc-msg] get mmc1's IO(det) failed [ 1.671684] [mmc-msg] Not using mmc1 due to script.bin parse failure [ 1.678123] [mmc-msg] MMC host used card: 0x9, boot card: 0x0, io_card 8 [ 1.685471] [mmc-msg] sdc0 set round clock 400000, src 24000000 [ 1.691708] [mmc-msg] sdc0 set ios: clk 0Hz bm OD pm OFF vdd 3.3V width 1 timing LEGACY(SDR12) dt B [ 1.702062] [mmc-msg] sdc0 Probe: base:0xf0034000 irq:64 sg_cpu:ffdfb000(4fc00000) ret 0. [ 1.710382] [mmc-msg] sdc3 set round clock 400000, src 24000000 [ 1.716717] [mmc-msg] sdc3 set ios: clk 0Hz bm OD pm OFF vdd 3.3V width 1 timing LEGACY(SDR12) dt B [ 1.726839] [mmc-msg] sdc3 Probe: base:0xf0036000 irq:67 sg_cpu:ffdfa000(4fc01000) ret 0. After I boot an initrd, there are no /dev/mmcblk0 entries in my dev filesystem. However, I can make it appear if I do the following: echo 1 > /proc/driver/sunxi-mmc.3/insert This causes the card to be registered at /dev/mmcblk0 as expected. Digging deeper, it would seem that the script.fex sets the card-detect mode for mmc0 and mmc1 both to 1, which is CARD_DETECT_BY_GPIO. The failure in the kernel log occurs when the script.bin parser tries to read the "sdc_det" key and doesn't get a valid value describing the GPIO it should be using, I assume. mmc3 doesn't have that problem because script.fex sets the card-detect mode to 4, which is manual mode - this requires me to write a 1 to the control node in the procfs as I experienced. Is the script.fex incomplete? What's going on here? Thanks for any help, Ryan

3 12

Interfacing touch screen to EOMA68-A20
by joem 01 Nov '13

01 Nov '13

Hi, I got me 5 pieces of 4.3" touch screens. It should be same as the lcd described here that is already working: http://gplsquared.com/eoma_boot/eoma_boot.html#working_lcd It has something extra - 4 wires for a touch interface - resistive. The signal pins are marked: 37 XR Touch panel XR 38 YD Touch panelYD 39 XL Touch panel XL 40 YU Touch panel YU They were purchased from Aliexpress - (cheaper when I bought it). http://www.aliexpress.com/item/4-3-inch-KD43G18-40NB-A1-KD43G18-A5-4-3-C430… Any ideas which cheapie chips best to use with EOMA68-A20 to get touch screen operational? I assume it has to be I2C and somehow a bit of driver software will run and convert the I2C signals to mouse movements. Any pointers appreciated.

2 2

BOM of Cubietruck?
by Alexey Eromenko 30 Oct '13

30 Oct '13

SoC Allwinner A20 $8 (I assume only a bit more expensive than last year's A10 at $7) RAM chip $4 per 4 gigabit. (512 MB) x4 = $16. (Dram exchange) Flash 8GB $2 (dram exchange) Gigabit Ethernet PHY $4 (guesstimate based on old data) Intermediate total ($30) Do you happen to know the price of the following: Wifi+BT chip (it seems to have antenna on chip) How much for ports? VGA HDMI TOSLI NK RJ45 2X USB PCB (board itself) headphones audio out MicroSD slot Assembly work $4 ? Cables Package This will give us a very rough gross profit margin of Cubie.

4 3

goodbye LM13700, hello CM108AH
by luke.leighton 29 Oct '13

29 Oct '13

it is with much sadness and regret that for parts in the flying squirrel i say goodbye to the LM13700M, a part with a huge and rich history, having seen its first emergence into the world around 1967 even predating the moon landing. the reason is simple: the bias for the diodes is 3x 0.7 volts and on rails of +/-2.5V it's simply not enough. i'm seeing silence at low volumes... and then huge clipping. i simply don't have time to resolve this. instead unless there's a good reason (e.g. conexant responds to enquiries) i'm going with the CM108AH and keeping the TDA2822 as a speaker amplifier. the reason for choosing the CM108AH: no good reason other than the datasheet contains an example schematic and there were no NDAs required to get hold of that datasheet. l.

2 2

[flying squirrel] schematics review needed
by luke.leighton 29 Oct '13

29 Oct '13

hi folks i'm onto the 3rd revision of the flying squirrel, i need help: a systematic review of the schematic pages, to make sure i haven't missed anything. the schematic is partly copied from other drawings as well as application notes. the CM108AH is to be replaced with a Conexant USB-Audio IC. the pdf's here: http://hands.com/~lkcl/eoma/tablet2.pdf - any comments gratefully received. timescales are short but a careful review is essential. thank you everyone. l.

1 1

car "infotainment" doesn't upgrade....
by luke.leighton 24 Oct '13

24 Oct '13

http://tech.slashdot.org/story/13/10/22/2211209/automakers-struggle-with-pa… funny that....

3 5

[flying squirrel] revision 3 started
by luke.leighton 24 Oct '13

24 Oct '13

http://rhombus-tech.net/community_ideas/kde_tablet/news/revision_3_starts/ well... i've been quiet for the past few days because i've been incredibly busy. the experiments with the STM32F103 for use as a camera _would_ i think eventually have been fine... except that the speed simply wasn't up to scratch. so instead an extremely rapid bit of evaluation took place (thanks to a friend at atmel) and the SAM4S QFN64 was picked. the past two evenings have been spent doing a near-complete re-layout of the PCB. by shrinking the component sizes (0402) it's been possible to make just enough space to optionally fit a SATA, Ethernet, 4-pin header for USB and a 12-pin FPC as an expansion port. WIFI stacks on top via a 2nd 4-pin USB header with 3.3v power. there's going to be a bit of connector shuffling before this goes out, but it's basically doable. so, in effect, this PCB is one step away from being the Monster Engineering Board. it's also only 12cm x 10cm (under 5in x 4in) which is nice. l.

1 0

One other thing -- emulation question...
by Christopher Havel 23 Oct '13

23 Oct '13

One more idea that just popped up (I promise I won't spam the list too much with this kind of junk). How much of a performance penalty/loss would be incurred by "pulling a Transmeta" -- by which I mean emulating x86 hardware with, in this case, ARM...? Say, convincing an A20 to emulate something like a P3 CPU? The idea comes from the Transmeta Crusoe CPU -- which is NOT x86 at all! It's something I'm really unfamiliar with called VLIW, and it has what amounts to a software emulation layer between it and the rest of the system, so that it can run x86 code. Of course that incurs an INSANE amount of overhead, because the CPU is basically doing its job twice -- translating the instructions and then executing them. It's a remarkable kludge if you ask me, but it works.

5 13

Just a thought...
by Christopher Havel 23 Oct '13

23 Oct '13

It occurred to me, just now, that if the MEB (or any other EOMA-68 carrier board) is put in a housing with built-in guides for the CPU Card, then we don't necessarily need a proper PCMCIA slot -- just a 2x34 right-angle pin header with 1.27mm spacing. Have the bezel of the CPU card stick out just a touch from the housing, so that someone can get their fingernail (or a small slot screwdriver) under it and pry just enough so that they can yank it out. Seems to me that it'd be a cheaper option as well, because of the wonders of injection-molded plastic... even making the housing out of something fairly sturdy, say 2mm ABS, surely wouldn't cost too terribly much... plus, it's potentially possible to 3d print such a thing, which would make this stuff even more accessible to the (far richer than me) hobbyist. (Of course it'd also be possible to 'jerry-rig' it with scrap materials and lots of fussing.) I'd love to see a housing like that, with a small carrier board (perhaps a VGA-enabled version of the MEB?) and a VESA 75mm mounting option. It would enjoy a permanent placement on the back of my spare LCD for sure. (The carrier board would definitely have to support VGA through some means, though, to work with that screen.)

4 9

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

arm-netbook