<oliv3r>
but thre's some learning curve to go passing by :p; I really have to refrain myself from starting with registers, so I can finish on the documentation :)
<oliv3r>
there's no clockworkmod tree is there
<oliv3r>
on the wiki; anyway, if i discover anything i'll write a page on it
<mnemoc>
:)
<mnemoc>
refactoring existing pages is also welcomed
<mnemoc>
every tutorial decided to teach (again) how to install a compiler :|
<oliv3r>
while linux documentation overal is good and things are wel explained, i find android/roms to be more like the 90's 'warez' scene, zips, binaries and half/vague instructions
<oliv3r>
its redumentary but there's _something_ :p
<zub>
rm: I'd also vote for cleaning up defconfig, as some options seems wrong/useless
<mnemoc>
patches welcomed
<zub>
rm: btw. I've been playing with my "minimal config" and I keep running into strange issues, crashes on boot. It seems to be related to CONFIG_PREEMPT
<zub>
mnemoc: I think I already used up my credit :( and I'm not really sure myself what should be included in the defconfig, jsut some options seems obviously useless, while some just suspect
<mnemoc>
the problem with preempt should now be solved with the fix on the regulator detection and the changes in the clock handling
<zub>
rm: thx
<mnemoc>
rm: i would rather take a patch
<mnemoc>
#52 is more of a wishlist
<oliv3r>
What are the differences in speed between a reasonable fast SD card, and the onboard nand? how fast IS the nand? will i notice much difference in speed when using an older 512mb SD card for example (for testing)
<mnemoc>
oliv3r: I personally totally ignore the NAND
<mnemoc>
it's driver is crap and loves to halt the world when there is some writting
<oliv3r>
good, since i have an arsenal of old SD cards (512MiB-8GiB)
<oliv3r>
one of the 'improvements' needed I assume?/
<mnemoc>
totaly rewrite I would say :|
<mnemoc>
but we still don't know enough about the nandc to do so
<zub>
it seems to be randomly caused by changing config
<oliv3r>
the hardware DOES expoxe the mtd 'layer'?
<mnemoc>
nope
<zub>
fea836a3876514a9097de4fe6181d0cb1b332a44 is the latest commit, linux-sunxi-3.4
<zub>
so I think it's up to date
<mnemoc>
usb on 3.4 is known to have troubles, yes
<mnemoc>
the forward-port is still incomplete
<mnemoc>
specially on the gadget side
<mnemoc>
but needs love in general
<zub>
mnemoc: the actual line that dies is "status = usb_add_hcd(sw_hcd_to_hcd(sw_hcd), -1, 0);" (line 1480 in sw_hcd0.c), and that is caused by usb_add_hcd (dies in dev_info(hcd->self.controller, "%s\n", hcd->product_desc);
<zub>
the pointr is not null... but apart form that I don't know how/why dies it explode
<mnemoc>
zub: we still don't have usb maintainer... do you volunteer? ;-)
<zub>
funny thing is it's sort-of-random, I didn't figure out one config item that causes it... it seems idfferent ocnfig = different result, maybe affected by build
<zub>
mnemoc: I have already failed
<zub>
if you need some touchscreen hacks, or freescale framebuffer hacks, I could know something :-P
<zub>
too bad there's not freescale FB on the allwinner :)
<mnemoc>
failure is a requirement to real success ;-)
<zub>
I already asked, but let me try again: CONFIG_BLK_DEV_INTEGRITY - does this make sense on the allwinner? does it even do anything at all? it's on in the defconfig
<mnemoc>
silence usually means "no idea"
<zub>
it seems to have affected the crashes with usb, but it could be that just the code is laid out differently/soem random effect
<zub>
btw. anybody here is using gdb/something to debug the kernel? I guess JTAG is one option. Bit what about things like kgdb? (I don't have JTAG. I guess I could get it via the uSD hack, but don't have it so far.)
<mnemoc>
hno and RaYmAn use jtag
<mnemoc>
i bought one, but haven't needed to learn to use it yet...
<zub>
so you're going with printk? :)
<mnemoc>
yup :p
<zub>
what irritates me the most is inserting/removing the uSD all the time... :(
<zub>
MK802+ doesn't have the eth connected, so I guess I can't boot from net even if uBoot could do it; maybe boot-over-serial (never tried)
<mnemoc>
i keep two uImage files, if the development one fails I tell u-boot to use the known-to-work one
<mnemoc>
zub: you can try using `fel`
<zub>
ah, and then you update the uImage w/o removing the card. good idea
<zub>
mnemoc: is it possible to use FEL to receive and start an uImage?
<zub>
(or, well, any kernel image)
<mnemoc>
spl + atags + uImage, theoretically should work
<zub>
A10 is magic! :)
RITRedbeard_ has quit [Ping timeout: 245 seconds]
<zub>
I think two uImages will work for me, that sounds easy enough
<mnemoc>
works for me well enough to not need to explore other options yet ;-)
<mnemoc>
zub: the A10 is VERY hacker friendly
<lundman>
gets a 8/10 in hacking, and 6/10 for developer :)
ZaEarl has joined #arm-netbook
<mnemoc>
a 2/10 for user wanting video decoding on linux :<
<RaYmAn>
mnemoc: psh, next thing, you'll say tegra is very hacker friendly
<RaYmAn>
:P
ZaEarl_ has joined #arm-netbook
ZaEarl has quit [Read error: Connection reset by peer]
<ZaEarl_>
ugh, crummy hotel wifi
ZaEarl_ is now known as ZaEarl
<rellla>
rm: doing a recopy of uImage and kernel libs did it. it's online again ;-)
<mnemoc>
RaYmAn: :p
<mnemoc>
RaYmAn: i meant the design of the chip itself.... the lack of documentation and crappy code hurts obviusly
<RaYmAn>
;)
<RaYmAn>
Tegra isn't very friendly at all. You look at it wrong and it starts to sleep-of-death
<RaYmAn>
(Seriously - ASUS disabled the low-power core in their JB release for the tegra3 tablets because of SOD)
<mnemoc>
o_O
<oliv3r>
ironically, video decoding in linux is 8/10 for me :)
<ZaEarl>
anyone else in Hong Kong this week?
<zub>
I wish :)
<oliv3r>
next to searching all over the net, what's the best option to identify the harware in my tablet? I'll get busybox with lsusb and lspci to work; but then there's probably some i2c hardware?
<mnemoc>
oliv3r: usually people takes them apart :p
<ZaEarl>
oliv3r, a lot of devices don't show up in lsusb/lspci
<oliv3r>
zaearl why not? I'd expect anything connected to those busses to show up
<mnemoc>
ts for example is usually connected via i2c
<oliv3r>
oh, gotta look for some teardown pics/stuff; the yarvic tab26[04]/momo9 is quite common
<ZaEarl>
because they're connected other ways
<oliv3r>
ah, well duh then :)
<zub>
wasn't there some tool to list stuff on i2c (to the extent the stuff can be probed...)
<oliv3r>
i know lm_sensors probes stuff with sensors detect
<oliv3r>
I saw on the mailing list, that the A10 rev C has a bug with PLL4 (sata?); /proc/cpuinfo does list some form of rev numbers, but mine is 'rev 2'. I doubt there's been 11 revisions since? the rev C correlate to the /proc/cpuinfo?
<mnemoc>
oliv3r: afaik all new A10 chips are rev C
<oliv3r>
boxchip may have been better
<oliv3r>
:p
<oliv3r>
mnemoc: well version 2, could be rev B then?
<mnemoc>
i guess so
<mnemoc>
unless the code counts from 0
<RaYmAn>
i2cdetect is..well.. unstable by definition. There's no standard way to detect if a device is present on the i2c bus (it's device specific to the target device)
<oliv3r>
true, well tablets don't use sata ports anyway, so it shouldn't matter, but still
<RaYmAn>
but you can probably find some info from sysfs i2c stuff
<oliv3r>
well on a pre-configured running stock ROM you should get most/all i2c connected devices i'd say
<RaYmAn>
sure, but i2cdetect will not necessarily show them all (is my point)
<oliv3r>
yeah, i guess they guestimate on based on known chips
jquip has joined #arm-netbook
<oliv3r>
does anybody use any of the windows only tools? Like 'redscorpio's' tools etc? Do they work reliably in wine? I guess any big fuckup can be fixed by booting via uSD? as long as you don't break the BROM
<RaYmAn>
If possible, it's a good idea to dump boot0 and boot1 before starting to play
<RaYmAn>
but might require JTAG to do properly
<ZaEarl>
oliv3r, yeah, a lot of that stuff works nicely in wine
<ZaEarl>
you can't break brom
<oliv3r>
i'd imagine that with jtag you can still flash BROM, oth, it also makes a lot of sense if it where true rom baked into the asic
<RaYmAn>
indeed, but you can end up in a place where your device no longer works if you don't have the boot0/boot1 because they contains ram initialization parameters and similar
<ZaEarl>
right, so keep a LiveSuit image around.
<RaYmAn>
also, no , BROM is read only
<oliv3r>
so boot0/boot1 is still read (by BROM) even when booting from uSD?
<mnemoc>
nope
<mnemoc>
when booting from uSD both are bypassed
<oliv3r>
so in theory, i could fill the entire nand with 0; only have BROM working (duh) and safely boot from uSD and restore boot0/1 (from a backup)
rz2k has quit [Ping timeout: 245 seconds]
<RaYmAn>
we don't know how to access the part of the nand that contains boot0/boot1 :/
<RaYmAn>
but otherwise, yes
<oliv3r>
so you cannot end up in a place where you cannot boot, as long as you have a workable bootable uSD card then
<RaYmAn>
correct
<ZaEarl>
LiveSuit can install a fresh rom without booting the device
<RaYmAn>
ZaEarl: it kind of assumes you have a livesuit image for your device
<RaYmAn>
or a compatible one
<oliv3r>
livesuit a DFU utility? (direct flash)
<ZaEarl>
of course
<mnemoc>
he code to do raw access to the nand is available... we only need time and willing to dive into it and export those raw blocks as a /dev
<mnemoc>
s/he/the/
<ibot>
mnemoc meant: the code to do raw access to the nand is available... we only need time and willing to dive into it and export those raw blocks as a /dev
<RaYmAn>
ah
<RaYmAn>
mnemoc: where?
<mnemoc>
in drivers/block/sunxi_nand/ :)
<ZaEarl>
there are tons of generic livesuit images out there, that'll restore basic funcationality to most devices
<RaYmAn>
ZaEarl: yes, assuming they have compatible ram.
<oliv3r>
once you have restored some functionality via livesuite, you can always go from there I suppose
<oliv3r>
I guess a 'livesuite' image, is nothing mmore then a complete nand dump
<RaYmAn>
in essense, yeah (as usual, it's a bit more than that, but yeah)
<ZaEarl>
it's a bit more complicated than that
<oliv3r>
inc. the android stuff? or just boot stuff, u-boot etc
<mnemoc>
livesuit seems to do some probing and write whatever it wants in boot1's header. not exactly what is in the provided script.bin
<oliv3r>
well since we can't access boot0 and boot1 yet, doinga complete dump is imposslbe atm anyhow
<mnemoc>
oliv3r: we can, from nand's uboot
<RaYmAn>
without jtag, yeah
<oliv3r>
oh, so with jtag we can doa full dump
<RaYmAn>
even if jtag can't access nand, it's possible to dump it from memory
<oliv3r>
maybe i should talk to hipboi and see if he sells me one of those uSD -> jtag adapters
<zub>
what is the relationship between boot0/boot1 and /dev/nand?
<oliv3r>
mnemoc: oh; so if i boot into a proper u-boot from uSD, i can use that to dump the full nand?
<mnemoc>
oliv3r: no, only if you boot from nand's u-boot
<zub>
is boot0/boot1 in an area that is not visible in /dev/nand?
<oliv3r>
so based on zub's question, I'd assume, the linux/android kernel doesn't expose ALL of the flash in /dev/nand
ZaEarl_ has joined #arm-netbook
<RaYmAn>
zub: yes
<mnemoc>
oliv3r: only the logical layer
<zub>
:(
<mnemoc>
boot0/boot1 live before that
<oliv3r>
mnemoc: confusing, but I understand, the original u-boot knows more and thus exposes it properly
<RaYmAn>
mnemoc: it must be slightly more complicated than that, otherwise the /dev/nand expose patch would make it appear
<zub>
btw. how does the nan partitioning (/dev/nanda, /dev/nandb...) work? can we alter the partitioning?
<zub>
nand
<mnemoc>
zub: there is a tool in sunxi-tools to repartition /dev/nand
<oliv3r>
is this info on the wiki btw? instead of bombing you with the same questions over and over :)
ZaEarl has quit [Read error: Connection reset by peer]
<oliv3r>
mnemoc: i assume to partition only the 'known' region
<mnemoc>
oliv3r: the logical layer, yes
<oliv3r>
so the A10 doesn't need to be told what the partition sizes are! (I know some phones with mtd based partitions, get told the partition sizes at boot time)
<mnemoc>
/dev/nand has a custom partition table
<mnemoc>
in the first block before nanda
<mnemoc>
but "the tool" deals with that
<oliv3r>
yeah but the partition table is (exposed) actually written to nand! that's good :) my phone doesn't have a partition table, i think the internal SPL/bootloader tells the kernel the partition dimensions via mtd= boot cmdline
<mnemoc>
yuck
<zub>
oliv3r: yup, seen that with mtd too
<oliv3r>
well it is 'stored' in some way I suppose :)
<oliv3r>
you can modify it, but only by overriding the mtd parameter, i think the spl stored value, is no way around it. a lot of phones actually do it that way it seems
<zub>
oliv3r: you could hack the kernel to ignore the supplied mtd and use some hardcoded :)
<oliv3r>
well yeah
<zub>
yay for ugly hacks!
<mnemoc>
that's the way of "the industry"
<oliv3r>
I still fail to understand why are they so hard trying to make it 'annoying' (not hard, not difficult, just annoying).
<mnemoc>
"get it done now! no one cares how. but it has to be done NOW!"
<oliv3r>
regular consumers aren't ever gonna mess with this
<oliv3r>
i ment their 'protection ''schemes'''
<oliv3r>
but yeah, crappy code is deffinatly in that department
<oliv3r>
I guess on the hardware side they shouldn't be allowed to work that way
<mnemoc>
carriers claim they protect the networks
<oliv3r>
it's hard to release a software update for a hardware flaw :)
<mnemoc>
because a rooted phone is a liability
<oliv3r>
that may be true and well
pawel5870 has joined #arm-netbook
<oliv3r>
but you can have hacker friendly hardware, and still sell unrooted phones
<oliv3r>
my tablet btw, came pre-rooted
<oliv3r>
no official market, and I think it runs some development mode rom
<mnemoc>
that's the case for most A10 devices
<oliv3r>
Ah ok
<zub>
I hate the idea of me buyin a device and not being allowed to do whatever I polease with it. I paid the $. Now give me my device w/o stupid DRM/locks/...
<oliv3r>
exactly
<mnemoc>
zub: apple fanboy I presume ;-)
<oliv3r>
*I* worked for the money, *I* bought the device, *I* own it, yet i cannot do whatever I please with it
<zub>
mnemoc: ehm? never had any apple device and I don't plan to buy any
<oliv3r>
(cedar/mali even here applies, boot0/1 etc follows)
<zub>
mnemoc: I prefer Allwinner to Apple :-P
<oliv3r>
I must say, I do find the A10 SoC very very interesting chip (probably due to its hacker friendlyness/price)
<mnemoc>
same. no sony, no apple, no amazon. no any device from a company who believes they need to keep control of the products after they are sold
<zub>
but I bought an HTC phone. Part of that $ came to M$ (patents). :(
<zub>
and it was locked, but I picked one that was easy to root
<ZaEarl_>
now, if we could just get the OEMs to respect the GPL
<oliv3r>
i got an old (used) iPhone 3gs from work, that i had for a few days and traded it for an old very little used HTC hero
<oliv3r>
but it was free, so can't complain. I do own a samsung washingmachine though :)
<zub>
:)
<zub>
oliv3r: does it have JTAG? :)
<RaYmAn>
hacking your washingmachine seems like taking things a bit far :P
<mnemoc>
but hacking those cleaning robots seems fun :p
<RaYmAn>
yeah
<oliv3r>
lol haven't it opened it yet :D
<oliv3r>
RaYmAn: now, maybe, but in time, when we have all opensource sofware everywhere, we'll need a new challange i'm sue :p
<oliv3r>
also, washing mashines will get more 'powerfull' and will feature a true OS at some point
<oliv3r>
think, touch screen, 'options'
<zub>
"clone my great washing programme from git:/... :)"
<oliv3r>
washes twice as clean, twice as fast, at half the cost
<oliv3r>
and no more reboots!
<oliv3r>
hmm, the momo9 tablet (twin brother it is said, or rebadged) boots from USB
<oliv3r>
one last question before I get to work; all those CWM/Android flashing 'tools/instructions' don't really do anything other then format/mount/rm -rf/extract? If I change the partitioning scheme, those all should remain to work error-free I assume
<mnemoc>
CWM/Android flashing are windows-people oriented
<mnemoc>
but livesuit images come with encrypted partition images and a .fex file including repartitioning info
<mnemoc>
so it will kill anything you do
<oliv3r>
yeah, everything is dumbed down too much imo and it's all 'hacker-secret-club' sorta thing
<oliv3r>
anyhow, the stock software is quite crap, and some people have build CM9 roms and CWM roms, so installing those should be no prblem after partitioning :)
<mnemoc>
Turl has a pretty clean tree for CM10 for A10
rz2k has joined #arm-netbook
<oliv3r>
but even things like 'built from allwinner's sources (baseband 1.2) ... what? baseband is a wireless communication thing I would think, I know they use it on radio-firmwares too, but not sure what baseband relates to wrt allwinner
<oliv3r>
yeah but I wonder if it'll work on my tablet, can try of course, i'll look it over
<mnemoc>
as long as you keep your script.bin and you don't rely in a .ko we don't have in the open tree. it will work
<oliv3r>
the wiki mentions for nand-part that you need a kernel patch to expuse the FULL nand block device, i take it that is not entirly true? since there's some hidden bits (where boot0 and boot1 reside)?
<mnemoc>
it's the full *logical* nand block
<oliv3r>
thought so
<mnemoc>
rm: have you tried to enable thumb2 on an A10 kernel?
<rm>
no
<rm>
you mean "compile kernel as thumb (experimental)"?
<mnemoc>
yes
<rm>
no, didn't try that
<rm>
sounds interesting, would be nice to try and somehow benchmark the effects
<mnemoc>
indeed
<rm>
but I'm afraid the kernel will flat out not boot
<rm>
and I don't have convenient means to debug
<lundman>
did you try --force!
<mnemoc>
hno: http://sprunge.us/ZaeS?diff <--- improved simmetry and dropped CONFIG_ rename (for the sake of 3.0 "stability")
<jquip>
hows linux on nand? i was told to think with ubifs or yaffs... i'm still having an SD card :/ what's the best way to do this? nande apparently has enough space... anybody try nand repartioning? Thinking about a linux only tablet....
<mnemoc>
CONFIG_THUMB2_KERNEL=y .... so here we go
<mnemoc>
jquip: on linux you don't have raw nand, so raw nand filesystem don't work
<mnemoc>
same on SD cards
<jquip>
mnemoc: yes yes and no no... ubifs/yaffs works I hear..
<mnemoc>
/sys/kernel/debug/kmemleak is always angry :<
<hno>
zub, please read code and expand on the register guide so a better driver can be written.
<mnemoc>
hno: what do you think it's an excess there?
<hno>
Having more than one define.
<zub>
hno: I'll give it a try, but knowing myself (I know nothing about USB/kernel, and I don't have that much free time anyway) I can't promise anything :(
<oliv3r>
hno: do you know more about the CPUCFG register with regard to the chip version? you write 00 = A, 11 = B and ?? = C. with only 2 bits available, got any more info by any chance now?
<mnemoc>
hno: it's one for allwinner boot hacks, and a second to request mali's reserve
<hno>
mnemoc, and head.S part is not about mali, it's about booting directly from boot1.
<mnemoc>
hno: yes, that change is to kill the machine type hack together with the memsize hacks
<oliv3r>
hno: the datasheet says default: 0x03 (I assume that to be rev C, but you claim it to be B?) and says 'reserved to 2'b11 ??
<mnemoc>
hno: obviusly the define needs to be renamed
<mnemoc>
'A'+x == 'C' for x == 2
<oliv3r>
anywhere in the source I could check that?
<mnemoc>
hno: but the idea was to bind both hacks in the same CONFIG_
<hno>
And that head.S code should move somewhere else. I.e. zimage header or a custom header.
<oliv3r>
mnemoc: i get the simple math behind it :p; but if 0 = A, and 3 = B, C would have to be either 1 or 2, which ... seems odd :p
<hno>
oliv3r, rev A & B have the same value.
<oliv3r>
so that register is somewhat useless? :S
<hno>
Olny RevC needs code to behave slightly different.
<oliv3r>
let me rephrase, what shall I put up on the wiki :p
<oliv3r>
your notes seem to not match what you say here
<oliv3r>
I doubt there's any reference in the source about it? other then reading the value
<oliv3r>
hno: I take it you refer to the PLL4/Sata patch?
<mnemoc>
oliv3r: in arch/arm/mach-sun4i/core.c of the kernel look for sw_get_ic_ver
<oliv3r>
hno: you made me all confused! I will change that and then save the timers page; which means its ready for review and done! took me only 2 1/2 days! :(
<mnemoc>
once you have figured out what files are worthy :)
<drachensun>
heh sure
<mnemoc>
thank you :)
<ManoftheSea>
mnemoc, I seem to think you've got extensive arm device experience. How does Linux signal an ARM core to turn off the system?
<ManoftheSea>
(Very high level is okay! I'll research from there)
<mnemoc>
ManoftheSea: i'm a noob. but i know the kernel asks the PMU to do so
<ManoftheSea>
So, it goes through to runlevel 0, everything shutdown/unmounted, then sends some kind of signal?
<ManoftheSea>
and in x86, that signal seems to be an ACPI or APM signal. Which are told to the chip by the bios.
<mnemoc>
[ 5913.230000] Power down.
<mnemoc>
[axp] send power-off command!
<mnemoc>
^--- from A10
<ManoftheSea>
So, in device tree, it'd have to identify a signal to cut power.
<ManoftheSea>
ok.
* ManoftheSea
writes that down.
<mnemoc>
in EOMA he will tell the EC to do so
<ManoftheSea>
yep. I'm just wondering how flexible that is. Given the set of signals that cross the header.... I'm wondering if you can't have a USB device to do that.
<zub>
ManoftheSea: w.r.t. the user-space part, see man 2 reboot - an interesting syscall :)
<ManoftheSea>
Assuming the STM32F is wonderful and great and all that: It's doing mouse, keyboard, backlight...
<ManoftheSea>
zub: I have to tell my current laptop "reboot=e" at the cmdline.
<ManoftheSea>
So, certainly there are many ways to cut powre.
<mnemoc>
i assume one will be able to write something in a magic address (register)
<ManoftheSea>
mnemoc: register of the ARM?
<mnemoc>
EC
<ManoftheSea>
Er, yeah, I guess I should call it that.
<ManoftheSea>
But EC is so tied to x86
<mnemoc>
EC = MCU of the i/o board where the module is connected
<ManoftheSea>
MCU?
<mnemoc>
micro controller
drachensun has quit [Ping timeout: 260 seconds]
<mnemoc>
don't know if that "openec" uses a register (memory mapped) or a protocol over i2c
<ManoftheSea>
that's the LPC I was talking about.
<mnemoc>
first time I see that 3-letter-acronym
<ManoftheSea>
The chip does some EC stuff in hardware, from port 62h and 66h.
<ManoftheSea>
That's where I said "Low Pin Count". It's a quad pumped 4 wire interface to replace ISA.
<mnemoc>
too low for me :)
<ManoftheSea>
too low? ISA being Industry Standard Architecture (?)
<mnemoc>
for me ISA is the slot that came before PCI
<mnemoc>
but nevermind. I got it.
<ManoftheSea>
yeah, that's what I'm saying. It's OLD. '85
<mnemoc>
we don't need something fancy to talk with the EC
NAiL__ is now known as NAiL
mSquare has left #arm-netbook [#arm-netbook]
NAiL has quit [Changing host]
NAiL has joined #arm-netbook
<ManoftheSea>
ok... there's discussion of "gpio-poweroff" driver, through i2c gpios.
<ManoftheSea>
Which fits into device tree.
<mnemoc>
afaik lkcl goal is to port openec, not to implement something new
<ManoftheSea>
Hmm, I'm assembling info on why that's wrong. I'll make a case later.
<ManoftheSea>
Though, gpio-poweroff isn't "new"
<mnemoc>
:)
<ManoftheSea>
It's from the arm discussion list.
<mnemoc>
but it's poweroff-specific
<mnemoc>
we need full access to whatever is going on there
<ManoftheSea>
OpenEC would make the EOMA card have to emulate x86 to communicate.
<ManoftheSea>
Which would be great for an x86 EOMA card.
<mnemoc>
i suppose the idea is to implement an open standard already suppoered by the kernel
<ManoftheSea>
mnemoc: no, but whatever's not usb is i2c or gpio, and specified in device tree.
<ManoftheSea>
Making it discoverable.
<ZaEarl>
I sure wish Allwinner would announce something about sun6i this week.
<ManoftheSea>
Hmm, I'll try looking up that dvi-lvds chip that's specified in the EOMA page.
ZaEarl has quit [Quit: Ex-Chat]
ZaEarl_ has joined #arm-netbook
gzamboni has joined #arm-netbook
<mnemoc>
ManoftheSea: btw, are you Gordan Bobic?
<ManoftheSea>
no. I thought you were.
<mnemoc>
Derek LaHousse
<ManoftheSea>
yeah
<mnemoc>
:)
<ManoftheSea>
what? did you /who me?
<mnemoc>
yes
<mnemoc>
should have done it before asking :p
<ManoftheSea>
oh, it's not dvi->lvds, it's RGB->lvds
<ManoftheSea>
so yeah, the SN75LVDS83B doesn't do backlight.
phh has quit [Quit: No Ping reply in 180 seconds.]
phh has joined #arm-netbook
<ManoftheSea>
Did I sound particularly knowledgeable?
<mnemoc>
here? sure, you know far more than I about hw
pawel5870 has quit [Remote host closed the connection]
techn has joined #arm-netbook
vinifr has joined #arm-netbook
pawel5870 has joined #arm-netbook
ZaEarl_ has quit [Ping timeout: 244 seconds]
popolon has quit [Quit: Quitte]
gimli has joined #arm-netbook
rellla has quit [Quit: rellla]
tzafrir has quit [Ping timeout: 240 seconds]
Quarx has quit []
<lkcl>
ManoftheSea: yeah OpenEC is far more involved than it seems. it's 10,000 lines of c-code. keyboard matrix. mouse driver. battery charging (PWM and level reading). the works. it's... complex.
<lkcl>
ManoftheSea: TFP410 and TFP401. they're DVI-to-RGB/TTL (and vice-versa)
<ManoftheSea>
lkcl: I take it you've been reading back?
<lkcl>
ManoftheSea: que? :) oh - yes :)
<ManoftheSea>
What's the DVI comment about?
<lkcl>
"ManoftheSea> Hmm, I'll try looking up that dvi-lvds chip that's specified in the EOMA page."
<lkcl>
TFP410 for dvi->rgb/ttl
<ManoftheSea>
I was discussing going from EOMA RGB to the panel LVDS. I mistakenly thought the EOMA was DVI
<ManoftheSea>
I see.
<lkcl>
TFP401 rgb/ttl -> DVI
<ManoftheSea>
No, I actually meant the SN75LVDS83B
<lkcl>
ah then you want SN75LVDS83B or equivalent.
<ManoftheSea>
Which you've specified EOMA must be compatible with.
<lkcl>
that's only for panels up to (about) 1440x900
<ManoftheSea>
I thought it provided up to 5 LVDS channels.
<lkcl>
well, it's the easiest way to put it, that the signals must be 5V tolerant etc. etc.
<lkcl>
SN75LVDS83B is only single-channel LVDS
<lkcl>
the reason for specifying 24-pin RGB/TTL is because you can do *anything* with it, not costing a fortune in ICs.
<ManoftheSea>
oh, is it 5 line drivers in a single LVDS channel?
<lkcl>
sounds about right.
<ManoftheSea>
So, there's another chip to do higher screens?
<lkcl>
a single LVDS channel involves 3 colours and i think one clock line pair.
<lkcl>
yes, a different IC is needed - one that does dual LVDS.
<lkcl>
i don't know one: if you find one that's popular please do let me know, i need to document it.
<ManoftheSea>
hmm... The SN75LVDS83B shows 4 7-bit shift registers, and a clock. Rather than 3 8-bit colors.
<ManoftheSea>
If I find something, I'll shout.
<ManoftheSea>
But I did want to ask a bit more about OpenEC, and whether it's necessary.
<lkcl>
star.
<lkcl>
it is.
<lkcl>
cost of a battery management IC: $1.50
<lkcl>
cost of a 0.5 watt audio driver IC: $1.50
<lkcl>
cost of a USB-based keyboard/mouse driver IC: $1.50
<ManoftheSea>
No no, not just doing battery management on the I/O board with STM
<ManoftheSea>
mnemoc: at that point, it's the mini
<lkcl>
it's the closest term that the industry will recognise.
<mnemoc>
ManoftheSea: we don't need lvds or wifi
<lkcl>
yes. do really want someone to come forward and take the leaflab's maple schematics and add the extra connectors
<ManoftheSea>
I must bow to your greater experience, but from the research I did, they'll recognize it as "x86 stuff"
<ManoftheSea>
I haven't heard from Prof Pierce in 2 weeks either.
<ManoftheSea>
er, Pearce.
<mnemoc>
uefi on arm is real, and will become the standard regardless who likes it or not :|
raver2046 has joined #arm-netbook
<ManoftheSea>
mnemoc: the standard for people who want Windows 8.
<mnemoc>
and that means every major manufacturer and most mid/small ones
<mnemoc>
then the rest will fall
<mnemoc>
as usual
<ManoftheSea>
But since Win8 UEFI devices are completely locked out... they're uninteresting.
<lkcl>
ManoftheSea: ah hmm... well... that may be an advantage. maybe not. we'll see.
<xxiao>
M$ die die die
<mnemoc>
uefi doesn't need to lock linux out. that's a contract thing between MS and manufacturers
<lkcl>
ManoftheSea: ah? hm. wonder where he's got to?
<ManoftheSea>
yes. In the x86 world, it says "consumers must be able to run their own code." In the ARM world, it says "FOAD".
<mnemoc>
unlocked devices will come with uefi too
vinifr has quit [Ping timeout: 245 seconds]
<lkcl>
xxiao: peace! we want to take M$'s money! :) we would *love* them to make an EOMA-68 CPU Card, because the patent licensing will help fund their replacement :)
<xxiao>
hopefully
<xxiao>
but that sounds more of a intel thing
<jelly-home>
I'd also love a board to plug said card into!
<ManoftheSea>
oh hey... there's a USB audio streaming demo for the STL
<ManoftheSea>
STM
rellla has quit [Quit: rellla]
<ManoftheSea>
It needs an external audio DAC, though...
<xxiao>
anyone benchmarked A10's SATA port?
<lkcl>
ManoftheSea: yeah. well, it'd work for low-ish quality audio. i don't imagine it'll require that many external discrete components
<xxiao>
i was told by a guy that Marvell's kirkwood has issues on sata etc but its price is irresitable