<hno>
Turl, I know of that one, only didn't realize to use git reset during rebase.
<Turl>
:)
<mnemoc>
i can't get along with `stg` yet...
<mnemoc>
what I do for splitting is duplicating the line in `git rebase -i` and set the first to amend
<mnemoc>
then the next will get the parts I remove from the first
gsilvis has quit [Read error: Connection reset by peer]
gsilvis has joined #arm-netbook
tuliom has quit [Quit: Konversation terminated!]
alcides has quit [Quit: /(bb|[^b]{2})/ regular expression junkie + lover of literature...]
gsilvis has quit [Read error: Connection reset by peer]
gsilvis has joined #arm-netbook
<libv>
yay
<libv>
i managed to clone my 2600+ 7000- pvr cleanup from openpandora.org, which they found from some nokia submitted kernel OBS
<libv>
this cleans up the powervr driver to provide a much much cleaner interface to their "pdump" infrastructure, which allows, with a proper userspace and microcode, a full replay on imaginations simulator
<libv>
most importantly though, it introduces several nifty file handling bits through debugfs which are nice for reuse
specing has quit [Read error: Connection reset by peer]
<rm>
optimist: they will just take the soft core or even just the ISA, and then make a superb CPU from that, using their experience
<rm>
pessimist: come on, at the same time they're laying off 15% of the company, obviously they have decided to let other people (ARM) design their CPUs from now on
kaspter has joined #arm-netbook
AndChat138129 has quit [Quit: Bye]
eebrah has quit [Remote host closed the connection]
kaspter has quit [Ping timeout: 255 seconds]
kaspter has joined #arm-netbook
kaspter has quit [Remote host closed the connection]
<libv>
cores on the a10 mali: 1gp 1pp
<ZaEarl>
hehe, I was just going to say libv could probably confirm what it's got.
<libv>
ZaEarl: he can, when he is awake :p
<discopig>
yeah
<rz2k>
interesting, is it possible to run webgl on arm devices with native oGL ES acceleration..
Quarx has joined #arm-netbook
bsdfox has quit [Ping timeout: 260 seconds]
Sv has joined #arm-netbook
Sv has joined #arm-netbook
Sv has quit [Changing host]
Thomas42 has quit [Ping timeout: 244 seconds]
discopig has quit [Ping timeout: 276 seconds]
Thomas42 has joined #arm-netbook
mysteryname has quit [Ping timeout: 268 seconds]
<libv>
auwa, seems like the allwinner guys never bothered to find out what the _IO macros were for
orly_owl has joined #arm-netbook
<libv>
there is no way that disp is going to ever be accepted upstream with this interface
<libv>
there will be considerable api/abi changes, and most likely will be kms + extensions, which will hopefully be covered by ville's work, so it can all be marshalled and packaged sanely, with just a few ioctls defined
<libv>
there's no two ways about it, /dev/disp will go away, but i will try to limit the pain to a single big event
L84Supper has quit [Ping timeout: 260 seconds]
rellla has joined #arm-netbook
<libv>
and for failing that single event, there will be versioning in the meantime.
L84Supper has joined #arm-netbook
<andoma>
libv: is your wip available somewhere?
pawel5870 has joined #arm-netbook
<libv>
that just made it to stage
<andoma>
ah
<libv>
i am working on actually changing things now
<libv>
the start being a versioning ioctl
<libv>
added, of course, so no breakage occurs yet
<andoma>
cool
<libv>
but i should start a wiki page about the ioctls, and which need to be kept fully stable in the meantime, as they are in active use somewhere
<libv>
andoma: the kernel will warn about clients who did not do the versioning handshake though
<libv>
but that just means a message in dmesg
<libv>
pointing out the perp :)
<Maqs>
andoma: how's your progress with showtime + a10 video decoding?
<andoma>
Maqs: works fine
<Maqs>
wow, nice :-) is it already available somewhere?
<andoma>
biggest problem is that whenever i work on video decoding i always get stuck just wathing the video
<andoma>
and it's always the movie 2012 because it's first in my movies/ folder on my network share
<Maqs>
i guess showtime + tvheadend would run fine an a10
<andoma>
yeah
<Maqs>
:D
<andoma>
though, there's some problem with seeking right now but i hope to get that sorted tonight
<Maqs>
i guess after a few times you'll proceed to the next movie ;-)
<Maqs>
empat0's xbmc port has that problem, too.. but only the armhf version. armel works well
<libv>
andoma: pick a movie you do not like too much, and use that for testing, you will get sick of seeing it after a while
<Maqs>
just use big buck bunny.. watchable but short ;)
<andoma>
Maqs: ah ok .. i actually threw out all of the cedar code except libve.a itself
<libv>
well, do not like too much is a bit wrong, one that you are indifferent towards, dislike will come over time
<Maqs>
i do that with music.. listen to a song i like all day long and then i can't stand it any more
<andoma>
so i'm thinking of just not using the cedar phys mem allocation either but rather use libump for video as well
mysteryname has joined #arm-netbook
<Maqs>
the nicest thing would be to avoid using closed source allwinner stuff at all
<andoma>
yes
<andoma>
also realized that i got symbol conflicts between libve.a and libavcodec.a
<andoma>
i'm not saying they "borrowed" code but ... well
<andoma>
it was only one symbol though
<andoma>
msmpeg4_decode_picture_header() or something like that
<Maqs>
i guess there are a lot gpl violations left
<andoma>
probably
<Maqs>
but well.. it's the only way atm.. and the lib (and the android player that came with my mk802) support 3d video with different output methods etc
<mnemoc>
libv: can't /dev/disp remain as a sunxi-disp-legacy.ko?
<mnemoc>
scenes*
<mnemoc>
using the standard abi behind the schenes
<Maqs>
andoma: when do you think you'll make it available to the public or testers? :-)
<andoma>
Maqs: couple of weeks perhaps
<Maqs>
k
<mnemoc>
Gumboot: kontron boards are $1k+
<libv>
mnemoc: hrm... i guess so, but by that time i hope that we have a very clear picture of who actually uses /dev/disp
<libv>
mnemoc: there is a rather amazing amount of issues with it though, they really didn't even try to make an effort to make it useful
<mnemoc>
narf
<libv>
this is why this versioning is important, it will help us tell who is actually using this interface, a further patch will introduce a warning message pointing to the wiki page that needs to be created with the short and long term plans for disp, and which collects information about the users of this interface
<mnemoc>
I assume that if we make it kms compliant android will magically support it too
<libv>
mnemoc: err, no, not yet
<libv>
mnemoc: i never got to finish my hw composer work for intel
<libv>
and kms from before the summer really was not capable enough for giving what surfaceflinger needed
<mnemoc>
got a version ioctrl() I could add to stage to be merged tomorrow or so?
<mnemoc>
i see
<libv>
but i hope that ville syrjala is on top of things
<libv>
i am writing up some code to test the functionality of the versioning ioctl right now
cat_x301 has joined #arm-netbook
<andoma>
libv: i read "introducing a warning message posting to the wiki" .. thought.. "weird to update the wiki from the kernel" ..
<libv>
andoma: pointing to :)
<Maqs>
let's just make sunxi-wiki.ko ;-)
<libv>
andoma: we need to make ever /dev/disp user aware that /dev/disp is a bit of a dodo :)
<libv>
and we need to know who those users are
<libv>
and how we can make things the least painful for all
<andoma>
yeah
tzafrir_laptop has joined #arm-netbook
popolon has joined #arm-netbook
arokux1 has joined #arm-netbook
arokux has quit [Ping timeout: 260 seconds]
mSquare has quit [Ping timeout: 260 seconds]
kop has joined #arm-netbook
<oliv3r>
has hipboi solved his e-mail paypall issues yet?
<oliv3r>
30k, not bad!
<mnemoc>
he temporarily disappeared due to family matters :|
mSquare has joined #arm-netbook
<oliv3r>
horrible timing
<mnemoc>
very
<oliv3r>
well i did mail him details, i have setup an account for him on my mailserver so he can relay through it
<oliv3r>
for his own interest, he should take 30 minutes to set it up, test it and send out those 4k mails I suppose
<mnemoc>
also he doesn't seem to understand the importance of public relationships and customers at all
<mnemoc>
oliv3r: he is offline
<oliv3r>
since I guess his future financial survival could also depend on it, even so slightly?
<mnemoc>
oliv3r: normally I can see him connected from his android phone
<oliv3r>
well in case someone gets a chance to talk to him
<mnemoc>
oliv3r: but he is gone since sunday
<oliv3r>
i see
<oliv3r>
how old is he? Didn't seem to be that old, maybe about to hi 30?
<mnemoc>
i believe he is younger than that
<mnemoc>
24 maybe
<mnemoc>
he mentioned allwinner's was his first eng. job, and he joined at max 2y ago
mysteryname has quit [Ping timeout: 268 seconds]
sspiff has joined #arm-netbook
ssspiff has quit [Ping timeout: 260 seconds]
<oliv3r>
public relatinoships and customers are very important when working with 'kickstarter' I'd say
<oliv3r>
i just want him to succeed :)
<oliv3r>
He may very well be far from modern civilization, who knows :)
<jinzo>
or has problems with the preasure he got under with the success of cubieboard. It could be tottaly subconcious and could affect his health/feel.
<jinzo>
we just have to hope he and his family are OK and that he'll be back soon.
<mnemoc>
+1
<oliv3r>
and support him as much as wel can from our end :)
<jinzo>
ofcourse.
<rz2k>
rellla: is it ok for xbmc to compile multithreaded on A10? I have 100 LA and 300+ tasks
<rellla>
rz2k: i changed xbmc makefile to use a variable $(JOBS) for make -j$(JOBS). while merging empat0's changes, i forgot to set the $(JOBS) in depends.mk. you have to do this manually ;-)
<rellla>
rzk2: i used -j1 for native, -j4 for cross-compile. without $(JOBS) beeing set, cross-compile failed.... my virtual machine "exploded" ;-)
<rz2k>
my A10 will explode soon :p
<rellla>
rz2k: already corrected in my local rep, but not able to push atm
<rellla>
uptime gt 5h, seems that it's finished soon ;-)
<stefanro1>
mnemoc: u-boot related patches and discussions should move to the official u-boot list, once u-boot for sunxi is mainlined
<mnemoc>
sure
<stefanro1>
mnemoc: hopefully not too far away
<stefanro1>
mnemoc: thx
<mnemoc>
hopefully it will support nand soon too
<stefanro1>
i havent looked into details yet, only did some cleanup necessary for upstreaming
* stefanro1
is still waiting for the TTL-USB adapter :-(
<stefanro1>
btw: i noticed a very strange NAND driver in the sunxi linux port - not located under drivers/mtd
<mnemoc>
it's not an mtd driver
<mnemoc>
they invented their own thing
Almamuetya9 has joined #arm-netbook
Almamuetya8 has quit [Ping timeout: 260 seconds]
<mnemoc>
the "stock" allwinner u-boot comes after properietary boot0/boot1, loads the kernel image from a raw partition and the env from another raw partition
<stefanro1>
mnemoc: why did they "invent" something new? was it not possible to implement this as an MTD device?
<mnemoc>
unfortunatelly it doesn't pass either machine or memory info
Almamuetya10 has joined #arm-netbook
<mnemoc>
stefanro1: tom mentioned the nand team within allwinner believes mtd to be obsolete
<mnemoc>
and nothing we can do about it...
<stefanro1>
mnemoc: hmmm, i do work on different MTD drivers quite often - MTD is definitely *not* obsolete
<mnemoc>
i know
<mnemoc>
i only mean that even if sunxi/mmc gets mainlined most people won't be able to use it anyway
<mnemoc>
but of course it's a great milestone
<stefanro1>
mnemoc: could you please re-explain, why this is the case? why does the "stock" u-boot prevent us from using mainlined linux and/or u-boot?
<mnemoc>
stefanro1: doesn't prevent obviusly
Almamuetya9 has quit [Ping timeout: 248 seconds]
<mnemoc>
and our 3.4 kernel tree is already incompatible with the "stock" u-boot
<stefanro1>
mnemoc: you mean, using new linux will require a new u-boot?
QingPei has joined #arm-netbook
<mnemoc>
it does, because the "stock" doesn't pass standard info (machine type, atag)
<stefanro1>
mnemoc: this will definitely be the case, since upstream linux will have to support *only* DT and no ATAGs
<mnemoc>
the whole codebase needs to be rewritten before meeting upstream requirements
pucko has joined #arm-netbook
<stefanro1>
most likely - i didn't look at it closely yet
<mnemoc>
i'm not talking at all about upstream linux. I'm talking about "the users" been able to boot from nand while we move forward
<stefanro1>
but basic support (timer interrupt uart) should be quite easy with DT nowadays (if the devices are already supported)
<libv>
mnemoc: is there anyone looking into the rebooting/halting misbehaviour?
<mnemoc>
not that I know
<stefanro1>
mnemoc: okay, i have to dig deeper into all this sunxi booting/devices stuff before being able really comment here (just beginning on sunxi now)
<libv>
mnemoc: i am now doing some cosmetics, and adding in those missing licenses, but the versioning patch is looking good, will get it out in a few h, once i am happy with attaching my own (c) to dev_disp.c :)
<mnemoc>
the spl halts when detecting mmc after a reboot
<libv>
mnemoc: with me a reboot halts during serial initialization
<libv>
of the kernel
<mnemoc>
o_O
<mnemoc>
in 3.0?
<libv>
so it gets quite far
<libv>
yeah
<libv>
i will try to fix unloading of disp today still, it is really annoying having to power cycle the mele and probably not good for it
<libv>
but i am not going to dig out the shutdown/rebooting stuff :)
<mnemoc>
libv: I made the habit of `poweroff` instead of reboot :<
<libv>
as in, halt?
<libv>
this has me either sitting there for a minute pressing the power button, or i cycle the thing
<libv>
as it does not poweroff my mele
<mnemoc>
yes. and then I turn it on again by pressing the power button after replugging it :|
<libv>
:(
<libv>
not healthy
<libv>
as i said, i am going to try to get disp unloading to work
<libv>
but i am not stepping outside of disp :)
<mnemoc>
:)
<libv>
Turl with his clock bug finding skills is definitely so clued that he would have an easy time fixing those shutdown/reboot issues for us!
<mnemoc>
stefanro1: we are currently more focused in unifying/cleaning/fixing the code we have than trying to hunt mainline.
<stefanro1>
mnemoc: yes, i understand - makes sense
<mnemoc>
but having an mtd nand driver is particulary important because we need to extract boot1 from the boards to extract info for spl/board support
<mnemoc>
not clear what's the board support plan once u-boot-sunxi hits upstreams. there are just way too many to push them all
<mnemoc>
s/upstreams/upstream/
<ibot>
mnemoc meant: not clear what's the board support plan once u-boot-sunxi hits upstream. there are just way too many to push them all
<stefanro1>
mnemoc: what i have seen so far, the boards only differ in the DRAM setup - i might have missed other differences though
<mnemoc>
hno hasn't included anything about the pmu/battery yet
<hno>
?
<mnemoc>
but yes, currently it's only about dram
<mnemoc>
hno: hi :)
<hno>
oh, hi stefanro1
<stefanro1>
hno: hi
<stefanro1>
usually its no problem to support many boards from one SoC family in upstream u-boot, *if* all the board ports are maintained
<mnemoc>
these are thousands of boards
<stefanro1>
i see- okay, that's a bit too much
<mnemoc>
and we only have info about a handful :<
<stefanro1>
then lets support a "handful" :)
avernos has quit [Remote host closed the connection]
<hno>
One plan is to move the board details to a configurable binary header, allowing the SPL to be easily tuned to match a specific board.
<hno>
and provide defaults for the most important boards only.
<mnemoc>
safest could be to mimic boot0/boot1 headers
<hno>
this would allow a compiled SPL to easily be tuned for a specific board by connecting the board with USB, trigger FEL boot mode and run a tool for upating SPL from the boot0+1 headers.
<hno>
The format of the header do not really matter that much. Can't mimic boo0+boot1 as SPL is just one level.
<hno>
and boot0 header do not have all info needed.
<drachensun>
I'm curious, why can't u-boot read the bin file?
<drachensun>
if its updated with the dram settings, that is
<mnemoc>
egg-chicken problem. to read the sd/nand we already need stuff intialized
<mnemoc>
also most script.bin files don't include reliable info, as livesuit probes the board instead of believing the script.bin
<mnemoc>
so the fields in the script.bin aren't the same used by the board
<mnemoc>
I mean, dram_para's fields
<drachensun>
ah ok
<hno>
to make a long story short we can't trust script.bin with the early system initialization stuff and need to read that info from the boot blocks.
freakazoid0223 has joined #arm-netbook
<drachensun>
and we don't know how to do what livesuit does
<hno>
which is in raw NAND, outside the area accessible via the Linux emulated block device.
<drachensun>
nasty
<Gumboot>
How does the A10's ethernet work? That dmesg I got earlier jumps straight to eth1, which is on USB. Where's eth0?
<hno>
we don't know what livesuit does, and have no access to livesuit sources. And even if we had reproducing that for use with u-boot SPL is most likely some magnitudes more complex than figuring out how to read the already nicely composed boot headers in the boot blocks.
<mnemoc>
fel -> raw nand extractor -> boot0/boot1 dump -> decompiler -> make script.fex reliable -> generate reliable header for spl
<hno>
yes, something along those lines.
<mnemoc>
-> inject relaible spl in mmc and nand -> free world
<hno>
except no decompilation. Only parsing.
<mnemoc>
right
<mnemoc>
Gumboot: the soc has an ethernet mac (called wemac) inside
<Gumboot>
Are there drivers?
<mnemoc>
sure
<Gumboot>
So it's just that the OS decided to use the USB one instead?
<Gumboot>
Which stopped it getting announced as 'eth0'.
<Gumboot>
Even though its slot was allocated.
<mnemoc>
Gumboot: your userspace might have renamed it after the mac address changed
<Gumboot>
Who gave me that? It's gone out of my scrollback.
<drachensun>
I'm reading the fel code, it looks like fel can already dump the memory, is that right?
<mnemoc>
drachensun: yes, memory, not nand
<drachensun>
and boot1 doesn't load it into memory until later, ok
<mnemoc>
right
<mnemoc>
actually you can catch it from nand's u-boot
<mnemoc>
sometimes
<mnemoc>
as a leftover on dram
<hno>
FEL starts with only SRAM & USB available. To access DRAM the DRAM controller needs to be initialized.
<hno>
To read stuff from NAND a NAND driver needs to be uploaded to the board and executed.
avernos has joined #arm-netbook
avernos has quit [Changing host]
avernos has joined #arm-netbook
<rellla>
drachensun: have you seen my discussion-site for xbmc on linux-sunxi wiki? i've done a little brainstorming. but it's possible, that i've forgotten something... it was quite a try and error compiling but i reached the finish successful ;-) it was not that compilcated as i was afraid of before ;-)
<drachensun>
rellla: I got it to compile one locally, and everything works but the touch screen
<drachensun>
rellla: I found the bug in the code for the touch screen but I had to switch the kernel and u-boot to actually run xbmc so now the damn thing wont build again, I'm getting all these bizarre internal compiler errors again
<drachensun>
rellla: I have tried reverting my kernel and u-boot to the latest ones but something is different
<drachensun>
rellla: anyway, I wanted to give up building on the device is possible
<drachensun>
if possible I mean
<drachensun>
rellla: Ok, I hadn't seen this new info or the cross compile stuff, I'll give it another try
<rellla>
drachensun: would be good, if you could write down your steps of your new efforts, so we can update the wiki and be sure to not forget anything
<drachensun>
rellla: ok will d
<libv>
mnemoc: changes pushed to my tree
<mnemoc>
libv_disp ?
<libv>
yup
* mnemoc
wonders what was that hdmi_i2c stuff originally...
<libv>
if it turns up, it will not be hard to add
<libv>
my guess, external hdmi encoder
<libv>
ignore this stuff for now though, just noticed crap in version.c
<jinzo>
or cec controller over i2c?
<mnemoc>
ok
<libv>
leftover from testing
<drachensun>
ok, so now g++ is running fine with an older kernel for the native build so something must have brought in some instability
<drachensun>
well thats my guess, I don't really know enough g++ but that seemed to be the consensus before
QingPei has quit [Ping timeout: 245 seconds]
<mnemoc>
g++ is stressful
<drachensun>
I guess its a good test that way
sspiff has quit [Ping timeout: 260 seconds]
sspiff has joined #arm-netbook
<libv>
allwinner comment in the ioctl nr definitions: "fail when the value is 0x02 in linux,why???"
<libv>
should i add another comment to that: "No shit sherlock, go RTFM"
<mnemoc>
:)
<libv>
mnemoc: code available, rebased on stage already
<Turl>
I see he renamed it all over the place, I thought it was a typo at first :p
<WarheadsSE>
heh.
<mnemoc>
Turl: 'p' to suffix a pointer
<steev>
yeah, it does look like it, but sadly, it's not. it's shorthand for file pointer
<Turl>
I normally use "fp" for file pointer
<steev>
it threw me off a lot when i first started seeing it
<steev>
Turl: fp is floating point!
<Turl>
o.O
<steev>
hardfp, softfp
<steev>
you have hard file pointers?
<Turl>
fp for pointer, fd for descriptor
<Turl>
lol
<steev>
no, you have hard floating points!
<steev>
well, hardware floating point, but still
<libv>
Turl: this is _the_ standard
<steev>
Turl: In the kernel sources, a pointer to struct file is usually called either file or filp ("file pointer"). We'll consistently call the pointer filp to prevent ambiguities with the structure itself. Thus, file refers to the structure and filp to a pointer to the structure.
<libv>
Turl: when i first saw that a few y ago i was also not too happy, but this is such an old standard that one should not change it
<libv>
Turl: it's about as good as i,j for counters
<libv>
Turl: i give you ten guesses where i got that failure message :p
* steev
beady eyes Turl
<libv>
Turl: this code needs a second pass anyway, it needs to be more intelligent, and handle the versioning ioctl not existing
<libv>
but good catch
robws has quit [Ping timeout: 260 seconds]
robws has joined #arm-netbook
<Turl>
libv: ARM's kernel driver? :P
<Turl>
steev: lol
<steev>
:)
<steev>
gah
<libv>
mali_info, which gets address offsets, kernel driver version and gp and pp versions and counts
<steev>
i hate cgit
<Turl>
cgit?
<libv>
version.c is userspace code btw
<Turl>
libv: right, it doesn't make sense to open a device in kernel space :P
* t0dbld|work
ROFL @ Turl a java dev
<libv>
?
<libv>
*shrug*
<t0dbld|work>
Turl: HATES java
slash_random has quit [Ping timeout: 256 seconds]
specing has joined #arm-netbook
<libv>
oh, f me.
<libv>
DRV_DISP_Init is only called by the lcd module.
<libv>
no bloody miracle that hdmi does not work on its own
<libv>
and, takedown of disp tries to poke a register range that is only initialized in DRV_DISP_Init
<libv>
what an amazing mess this is
<libv>
seems like i should be aiming at throwing these three modules together first
<techn>
+1
ZaEarl has joined #arm-netbook
<techn>
libv: but notice that audio side has dependency to hdmi.. or other way around
<libv>
techn: yeah, i know, checkpatch uncovered that out of place extern too
<libv>
is anybody actually using panel timing that didn't come from from the fex?
<mnemoc>
+1 to remove those hooks
<techn>
dunno.. that's why i left them there
<libv>
well, my hyundai will be here tomorrow, i will have to find out whether i can get the panel going on that one and how that one really is wired up
<mnemoc>
even if they are, it's impossible for us to know what any manufacturer did there
<libv>
yes/no
<mnemoc>
none of us can answer that
<libv>
if it is the same setup as we have here, then a bit of disassembly will get us there quickly
<libv>
we know where to look, so it is easy.
<mnemoc>
i've been collecting .fex files, but no kernels..... as they are inside a raw partition
<libv>
mnemoc: do you have a .fex for the hyundai?
<libv>
(which has been reported as "panel not working" before)
<techn>
hyundai.. is that lcd panel or display?
<mnemoc>
hyundai a7hd is a pricy a10/ips 7" tablet
<mnemoc>
one of the first with ips iirc
<techn>
ah :)
<libv>
35.50 off of ebay :p
<mnemoc>
:)
<libv>
i wanted an aurora, but i amazingly won that bid :)
<mnemoc>
libv: no, sorry. i don't have it :<
<mnemoc>
neither does cnxsoft
<libv>
mnemoc: then i could need your help tomorrow getting as much info as possible out of the android installed on it
<mnemoc>
sure
merbzt has joined #arm-netbook
mikey_w has joined #arm-netbook
n6pfk has joined #arm-netbook
drachensun has quit [Remote host closed the connection]
zontar has quit [Remote host closed the connection]
<Turl>
silly carrier, offers me a 500 SMS gift if I move to online billing
Sv has joined #arm-netbook
Sv has quit [Changing host]
Sv has joined #arm-netbook
<ZaEarl>
I'm a big fan of pre-paid sims now.
Svet has quit [Ping timeout: 276 seconds]
* RaYmAn
grmbls at whiners wrt kickstarter projects not succeeding in delivering
<jelly-home>
RaYmAn: I'm not sure why people trust any random project developer if they don't know their work from before
<ZaEarl>
I have an A10 netbook with no OTG ports, so I can't figure out how to get ADB to see it. Can OTG be enabled in the fex?
<mnemoc>
adb works over tcp/ip too
<ZaEarl>
hmm, that might be ok
<t0dbld|work>
or wifi
<t0dbld|work>
upps yes
Sternennebel has joined #arm-netbook
eFfeM has joined #arm-netbook
<RaYmAn>
jelly-home: even if they do know their work beforehand, it's no guarantee it'll succeed
<RaYmAn>
case-in-point, openvizla usb analyzer... It's been 2 years :P But now people are talking about suing and shit *sigh*
eFfeM has quit [Client Quit]
<ZaEarl>
tweaking the fex didn't enable otg. that would have been too easy. :(
<RaYmAn>
if there are no otg ports, how are you going to get otg?
<RaYmAn>
:)
<t0dbld|work>
+1
<RaYmAn>
(also, a bunch of a10 devices seem to come with charger-only usb cables. Needs to be replaced with proper cables to get working otg)
<t0dbld|work>
you dont want otg mode for adb any how
<RaYmAn>
...
* RaYmAn
slaps t0dbld|work
<RaYmAn>
OTG mode is both device and host mode. :P
<t0dbld|work>
anyhow if your having that much trouble my suggestion is to install adb wireless and conenct that way .. if none of that is working see if you even have adbd installed and if permissions are set correctly to run
<t0dbld|work>
jsut read its a netbook ... than all the usb ports are likely host
<t0dbld|work>
which is why you cant adb it
<t0dbld|work>
you will have to do adb wireless
<t0dbld|work>
or tcp/ip
<ZaEarl>
since the a10 has the usb controller, why would all the ports be host-only?
<t0dbld|work>
its a netbook
<t0dbld|work>
why would they not be host like normal netbooks and computers
<ZaEarl>
because I doubt they created the motherboard from scratch. It's probably virtually identical to a tablet motherboard.
<RaYmAn>
there might be a header for the OTG port somewhere
<RaYmAn>
inside
<t0dbld|work>
i agree it might exist on the board it self but the external hooked up ports are jsut going to be host ports like a normal computer
<ZaEarl>
a10 has what, 4 usb ports? how many host and how many otg ports?
<RaYmAn>
I'm not sure, but I'd only expect one to be OTG
<t0dbld|work>
a10 is a chip it doesnt have any ports :-) but yet wouldnt call for more than one OTG but i doubt its hooked up
<ZaEarl>
a10 is an SoC
<ZaEarl>
the usb controller is inside it
<t0dbld|work>
assuming it even is hooked up than all of them have ground connected to ID pin hense why they are in usb host mode
<RaYmAn>
I wish companies would think about recoverability sometimes *sigh* FEL/livesuit is a perfectly good reason to include otg port :)
<t0dbld|work>
haha ya i can agree on that
eebrah has joined #arm-netbook
<ZaEarl>
livesuit does work on it
<RaYmAn>
uhm
<RaYmAn>
then you have a usb otg port.
<t0dbld|work>
umm than use that port
<ZaEarl>
I'm tweaking the fex to try to get it to work
<RaYmAn>
given livesuit only works over the 'primary' otg port :P
<t0dbld|work>
you jsut siad it did work
<ZaEarl>
livesuit works, adb over usb doesn't
<t0dbld|work>
wel lthan its unrelated to fex
<t0dbld|work>
or the port
<t0dbld|work>
is adbd in the system files
<t0dbld|work>
is it being started
<t0dbld|work>
does it have the right permissions
<Turl>
they probably just built the kernel with host mode support only
<t0dbld|work>
Turl: we thought that but he says live suit works
<t0dbld|work>
that was my assumption
<Turl>
livesuit is unaffected by the kernel
<RaYmAn>
indeed
<ZaEarl>
livesuit works when the device is turned off then switched into fel mode
<RaYmAn>
at any rate, livesuit prooves that there is device mode on that port
<t0dbld|work>
well than Turl is probably corret in which case use adb over tcp/ip
<RaYmAn>
you might need to force it though
freakazoid0223 has quit [Read error: Connection reset by peer]
<ZaEarl>
looks like adbd is running
<t0dbld|work>
ok so than Turl is right with 95% probability
<ZaEarl>
fex tweaking doesn't appear to help
rellla has joined #arm-netbook
<libv>
ZaEarl: do you have a root shell on the device already?
<ZaEarl>
yes
<libv>
ZaEarl: enabling adb to work over tcp needs a restart of adb