cnxsoft changed the topic of #imx6-dongle to: i.MX6 HDMI Dongle Software Development. You can also join us at https://groups.google.com/forum/?fromgroups#!forum/imx6-dongle - IRC Logs - http://irclog.whitequark.org/imx6-dongle/
<EvilMrJohn> exit
EvilMrJohn has quit [Quit: leaving]
EvilMrJohn has joined #imx6-dongle
BleedingBytes has quit []
ajayr has quit [Quit: leaving]
ajayr has joined #imx6-dongle
ajayr has quit [Client Quit]
ajayr has joined #imx6-dongle
hp__ has quit [Ping timeout: 240 seconds]
cnxsoft has joined #imx6-dongle
hp__ has joined #imx6-dongle
<dgp> Juggie: 1080p family guy episode played pretty well in dice player, no idea what the difference is
newbie has joined #imx6-dongle
newbie is now known as Guest458
hp__ has quit [Ping timeout: 240 seconds]
Guest458 is now known as hp__
newbie13 has joined #imx6-dongle
newbie13 is now known as hp___
hp__ has quit [Ping timeout: 240 seconds]
linaro has quit [Read error: Operation timed out]
linaro has joined #imx6-dongle
EvilMrJohn has quit [Ping timeout: 256 seconds]
EvilMrJohn has joined #imx6-dongle
rz2k has joined #imx6-dongle
pH5 has joined #imx6-dongle
Strswrd has joined #imx6-dongle
Strswrd has left #imx6-dongle ["parted"]
Strswrd has joined #imx6-dongle
hp___ is now known as hp__
mary1 has joined #imx6-dongle
<dgp> Strswrd: Try out dice player for video if you want smooth playback. It played the 1080p tv episodes I tested it with perfectly :)
mary1 has left #imx6-dongle [#imx6-dongle]
<Strswrd> ok... sounds good!
<Strswrd> I just had to tweak the partition layout of your image so I'm able to install more apps... took a couple of tries in gparted, but got it right in the end
<dgp> yeah I'm going to fix that. I thought apps would go to the "sd card"
<Strswrd> yeah.. -also.. I'm getting some "unfortunately the process.android.process.acore has stopped" messages. especially when I have just installed an app from play store.
<dgp> The sd card maker script can make images with any layout you want
<Strswrd> ok
<dgp> Can you dump the log from logcat when that happens?
<dgp> I haven't had it yet but I haven't installed much stuff
<Strswrd> yup... lets see if it happens when I install dice player..
<dgp> that works fine for me. The config of that image is the bare minimum (hence it's 80mb compressed) so it could be we're missing some framework or something that apps in the market expect to have
<Strswrd> the apps install fine.. its just an anoying message that shows...
<dgp> There should be a nice lump of output in logcat to show whats happening there
<Strswrd> ofc it didnt happen this time... i'll keep on trying
<dgp> are you still running it in the stock casing?
<dgp> Temple run seems to make my stick reboot
<Strswrd> I'am.. I'll download temple run.. btw 1080p movies seems to work quite good in diceplayer.. some minor stuttering here and there...watchable for sure. gonna try "birds" and see what happens
<Strswrd> is it possible to set resolution somehow?
<Strswrd> logcat from an "..process.acore..."exception:
<Strswrd> pastebin.com/h4rxkFfc
<dgp> If I can work out how the resolution stuff works yes, but I haven't found any leads on that yet
<dgp> Ok, I think that crash is because I haven't added the google sync stuff
<Strswrd> aha..ehm.. Templrun starts up here. but I cant use my mouse to click on anything
<dgp> Ah, the sync stuff maybe isn't the issue
<dgp> the crash in native code probably is
<Strswrd> got another crash...it says FATAL EXCEPTION ContactsProviderWorker in logcat
<dgp> I probably need to add a few more of the google apks
<dgp> I wanted to avoid adding gmail etc if possible
<Strswrd> are you getting the error?.. could be something I have did... since I install everything I can find atm
<Strswrd> *done
<dgp> I think the thing you're getting in native code could be due to heat
<dgp> The other bits are probably because stuff is looking for google services that I didn't add
<Strswrd> btw templerun still runs... locking at a shiny frog with light moving in the background (start screen) ... the image is tilted though... like antutu
<dgp> I wonder why I can't get it to run here. Power issue?
<dgp> Is your gk802 one of the newer ones?
<Strswrd> I dont know... how can you tell?
<dgp> I think it says on the PCB.
<dgp> I've only had mine for a month or so so I assume it's one of the new ones
<dgp> Says 2013-01-03 on mine
<Strswrd> I have seen 2012-something on my pcb... its in the case now so I cant see exactly the date right now
<Strswrd> ..terrible sentence... but you know what I mean I hope..
<dgp> i think you have one of the older ones then
<Strswrd> I bought it in january I belive
<dgp> I would be interested in seeing the dmesg output from a cold boot. Mine says that it can't read the edid I think
<Strswrd> I will get me a serial adapter.. :) Have you tried with different screens?
<dgp> if you run dmesg in the adbshell it should give you the same output :)
<dgp> you will need to su first I think
<Strswrd> oh ok
<dgp> serial adapter will be useful for debugging if it crashes in the kernel though so you should still get one :)
<Strswrd> pastebin.com/G9QMWrwa
<Strswrd> dmesg
<dgp> It'll need to be just after reboot as old stuff gets pushed out of the log
<dgp> <7>thermal_notify: trip_hot reached!
<dgp> <4>Hot alarm is canceled. GPU3D clock will return to 64/64
rz2k has quit [Read error: Connection reset by peer]
<dgp> I think that's why you're getting crashes
<Strswrd> ok..it's still running templerun,so.. i'll reboot then. hold on..
<dgp> I think video probably stutters because it gets hot and has to down clock the gpu to get it back under control
<Strswrd> it was way hot now... i'll let it cool down some
<dgp> I don't think they sat down and worked out if the case was suitable for the amount of heat the SoC puts out when it's running at full wack
<dgp> whack
<Strswrd> pastebin.com/73efmNES
<Strswrd> new demsg
<Strswrd> after reboot
<dgp> the really early stuff is still rolling off the end :(
<dgp> The rtl wireless driver is too damn noisy
<Strswrd> damn
<dgp> Doesn't matter too much. To get resolution changing working we need to have working EDID though
<dgp> I still need to find out where all the TV sticks are getting that from though. I can't find any info about it
<hste> dgp: CONFIG_LOG_BUF_SHIFT=16 instead of 14 gives more info into dmesg
<Strswrd> I don't think I can be of much help.. :(
<dgp> hste: I'll add that to my new build
<dgp> Strswrd: How big did you make the data partition?
<dgp> I'm going to do a new build now with more of the google apps binaries included. That might solve a few issues with store apps
<Strswrd> hmm 2 gigs I belive (on a 16 gig card)
<dgp> Ah you moved it onto a bigger card
<Strswrd> yeah..
<Strswrd> doesn't matter.. I know how to change it now :)
<dgp> Probably a good idea. I managed to kill one of the 8gb cards within a day
<Strswrd> hehe
<dgp> I'm going to add usb ethernet drivers too but I'm not sure how that works on the android side yet
<Strswrd> sounds nice! btw.. have you looked into I/O scheduler? right now it uses "cfq" which is the normal linux scheduler suited for server applications.. not for "fluidness"
<dgp> Which does it say is the best?
* dgp is going to be running menuconfig in about 2 minutes..
<Strswrd> thats a controversy.. i guess.. CM seems to use bfq
<dgp> IIRC if I think you can actually change that at run time.. So if I build a few of them in you could change them and run benchmarks
<Strswrd> great..!
<Strswrd> noop deadline and cfq is built in now..
<dgp> Just going to check what is available
<dgp> There is only deadline and cfq available in menuconfig
<Strswrd> well.. its no biggie. I dont think we need to bother about it right now
<hste> you could try add CONFIG_IOSCHED_NOOP=y too the defconf file you use
<Strswrd> it was just a thought.. since we are using the sd card for the "root memory", we might see some diff in performance..
<Strswrd> I'm in no way competent to say really.. but I've stumbled upon many forum posts discussing I/O scheduling for different android ROM's in the past..
<dgp> I'm open to suggestions. I think a lot of people have arguments on forums without having any idea what they're talking about though
<Strswrd> true!
<dgp> you see it with filesystems all the time. The only way to be sure is to test it and get real numbers
<Strswrd> .. and then there will be discussions and arguments about the test method... :)
<dgp> haha, yeah, it doesn't end
<Strswrd> perhaps we should leave it for now :)
<dgp> Well, you can configure it at runtime at least
* dgp wishes google had actually kept the porting docs up to date
<Strswrd> yeah.. gonna try noop now. need to figure out a test method first..
<dgp> antutu has a disk benchmark. not sure how good it is
<Strswrd> it wasn't consistent for me.. varied a lot from run to run
<dgp> I would strap some extra metal onto the case too, if it starts clocking down during the benchmark the results will be all over the place
<Strswrd> yeah... I'll do that.
<Strswrd> but I think there is a point to keep it in the "from-factory" state for other tests.. in case you want to release something to the public
<dgp> I'm not too interested in that tbh. This is purely tinkering
<Strswrd> ok.. I'll go crazy with the metall then :)
<dgp> Cutting a whole in the case and putting a nick big sink in there would be good :)
<dgp> I think I'm going to make up a board that straps onto the back and has points to wire up SATA etc so mine will probably never go back in the case
<Strswrd> cool
<Strswrd> ..in more ways than one
* Strswrd bad joke
<dgp> What is the end target for you gk802? Just a media player?
<Strswrd> well... nothing really. I just bought it cause I wanted to try this android tvstick thing out.. but a media player is ofc nice..
<Strswrd> ..and at the moment with the aid of you I'm learning alot
<dgp> learning is always good :)
<Strswrd> yeah, the only asset that can't be taken away from you..
<dgp> Interesting, I'll take a look
<dgp> It really sucks that all of the docs of how android stuff works are written by people that banged their head on their desk for a few hours trying to get it to work
<Strswrd> yeah, I guess.. the upside is however that there will be alot of android experts around in the end..
<dgp> I think Android will replace WinCE in embedded and kiosk style apps
<dgp> it's going to be wedged into all sorts of places it wasn't meant to go
<Strswrd> probably... and I bet that just up google's alley..
<Strswrd> they'd like that..
<dgp> AOSP doesn't have any of the google tracking stuff :)
<Strswrd> true... but the more android the more usage of google services..
<Strswrd> I think.. I should say
<dgp> I think most people just want the UI and Java VM
<dgp> I have a bunch of Android projects on my desk at the moment, they are all google-free
<Strswrd> sure.. I'm not saying its a bad thing.. but the more people who are familiar with the UI the better for google I think..
<dgp> yes of course
<dgp> and it's all opensource so it's not like google can rip it away from the people using it. If google start being dicks someone will fork it
<Strswrd> yeah..
<Strswrd> its way better than wince!
<dgp> I've never seen what wince looks like inside. But I would prefer everything to be running on top of Linux
<Strswrd> agreed
<dgp> New image is building now. It would be good if we could put together a "problem apps" list
<Strswrd> I'm up for testing stuff... just tell me what to do and I'll do what I can within my limited abilities.. :)
* dgp wonders if it's legal to distribute images with the google apks
<Strswrd> hmm.. how does for example cyanogen mod handle that?
<dgp> Does a vanilla cm image have the apps in there? the only ones I've used have been hacked up ones with everything built in
<Strswrd> me too... so I don't know
<Strswrd> "licensing" chapter
<dgp> That's what I thought, shipping the play store etc is basically a no no
<dgp> oh well
<Strswrd> but you could use apk's from the original image ... if I understood it right
<dgp> I think that the arrangement between google and CM is that users can put the applications that were on their phone back on there phone running CM
<dgp> but CM can't ship with those apps
<Strswrd> ohh.. ok
<dgp> so really I should be making images without that stuff and then users have to put it back
<dgp> sounds like a lot of hassle for the 10 or so people max that are interested
<Strswrd> yeah..
<dgp> just keep it hush ;)
<Strswrd> will do.. :) I haven't "redistributed" anything yet and will not do that unless its OK with you
<dgp> I don't mind that. Just make sure that it's not a serious effort to make a perfect rom
<dgp> *make sure to tell people
<Strswrd> sure!
<dgp> Did you test out anything like emulators etc?
<Strswrd> No not yet...
cnxsoft has quit [Remote host closed the connection]
<pH5> Hi, is there any information on what devices are connected to gk802's i2c2 bus?
<dgp> i2c2 has nothing I think
<pH5> i2cdetect reports something at 0x10, 0x11, 0x15, 0x16, and 0x51.
<dgp> sometimes 0x50 shows up, but when I hard i2c stuff connected to it went away
<pH5> the 0x51 one is the smsc dm2016 I believe
<dgp> ah you mean i2c2 on the chip not in linux
<pH5> dgp, yes, i2c2 as in the soc reference manual
<dgp> I see that stuff too
<dgp> the dm2016 is the eeprom right?
<pH5> yes
<dgp> If there is a pinout for it I can put a logic analyser on it's pins and check
* pH5 checks out DM2016_datasheet_sop8.pdf ...
<dgp> are you considering taking the chip off and using the i2c lines?
<pH5> I was looking for a pmic. Is there even any on this board?
<dgp> unless it's a very small chip I can't see anything that could be one
<pH5> thanks
<pH5> I've just written a device tree for barebox/mainline linux, and naturally I'm curious what those things on i2c2 could be.
<dgp> I have a board that has most of the chips removed. There aren't that many major components it sems
<pH5> dgp, cool. so you an trace connections? :)
<dgp> don't those sorts of DDR rams have eeproms in them with the access times etc in them?
<dgp> Sort of.. the soc got run over before I could take the hot air to it so the soc pads are missing in a lot of places
<dgp> I traced out SATA and some PCI signals on the top side though
<pH5> the pinout of the dm2016 sop8 package is, counterclockwise from pin1 to pin8: a0, sta, nc, gnd, sda, scl, nc, vcc
<dgp> ok, once I have this image built and flashed I'll dump what happens on those pins when I use i2cdetect
<pH5> interesting. esata would be useful for a media player
<dgp> I'm more interested in the PCI-E :)
<dgp> I want to have a PCI-E card taped onto the thing
<rm> USB is the new PCI(-E) :)
<dgp> rm: you could have a PCI-E usb card
<rm> I know
<dgp> and watch as your house burns down because the chinese power supply exploded under the load
<rm> I just mean that with these ARM SBCs it's USB that is an all-purpose ubiquitous expansion bus for all sorts of devices
<rm> kinda like PCI was back in the old x86 days
<dgp> USB is a cheap and nasty way to add stuff
<rm> PCI and PCI-E kind of fade out of general usage today even on x86
<dgp> look at the ethernet on the raspberry pi
<dgp> I wouldn't want a GPU connected via USB
<rm> with everything majority of users need being integrated into the motherboard
<pH5> dgp, don't tell me you are planning to add a pcie graphics card??
<dgp> pH5: if I can get a slot working I would try it
<rm> PCI-E for GPU is one common usage scenario that's left
<pH5> :D
<dgp> can you run gigabit ethernet over usb?
<pH5> now I want to see a pcie slot on grafted into the original enclosure.
<pH5> s/on//
<dgp> it would be badass
<rm> dgp, I got about 280 mbit/sec on USB 2.0 gigabit
<dgp> I can't seem to find a 1x pci-e connector on ebay for a decent price though
<dgp> rm: That's not too bad, but not great at the same time
<rm> well that was on Allwinner A10
<rm> but anyway with the USB 2.0's maximum being 480 Mbit, pretty good in any case
iamfrankenstein5 has joined #imx6-dongle
mary1 has joined #imx6-dongle
<dgp> pH5: your i2c detect output is like this right? http://pastebin.com/gRLqk71X
<pH5> dgp, exactly (except 0x50 is empty).
<pH5> but that's usually monitor edid data, and I have nothing connected and hdmi tx disabled.
rz2k has joined #imx6-dongle
<dgp> The eeprom doesn't seem to be on that bus, not getting a trigger off of either SCL or SDA
<pH5> strange, that would have fit really well
<dgp> do you know what the mux settings are for the first bus?
<pH5> i2cdump 0 0x51 shows 128 bytes of 0xff
<dgp> it times out scanning here I think
<pH5> and writing to them survives a reboot
<pH5> one sec..
<dgp> maybe I have the wrong pins wired up
<pH5> MX6Q_PAD_KEY_COL3__I2C2_SCL, MX6Q_PAD_KEY_ROW3__I2C2_SDA
<pH5> i2cpads need SION set and 0x1b8b1 pad ctrl settings
<pH5> for i2c3 I have MX6Q_PAD_GPIO_5__I2C3_SCL, MX6Q_PAD_GPIO_16__I2C3_SDA
<pH5> those are copied from the factory u-boot that came with the device.
<dgp> I think I put the right settings for the bus on the header on the wiki
<dgp> I tried all of them until I found a pair that would talk to an io expander
mary1 has left #imx6-dongle [#imx6-dongle]
deadhp1_away has joined #imx6-dongle
deadhp1 has quit [Ping timeout: 252 seconds]
mary1 has joined #imx6-dongle
mary1 has left #imx6-dongle [#imx6-dongle]
<dgp> pH5: update; the eeprom is on the bus you thougt it was
<dgp> test clip was bad
hp__ has quit [Read error: Connection reset by peer]
<pH5> dgp, thanks!
<pH5> do you know how the rda bluetooth chip is connected?
<dgp> that's already worked out.. it's on a uart and there is an enable pin
<dgp> the enable pin isn't a simple on/off sort of thing though, it's used to put the chip into some sort of parameter upload mode
<pH5> excellent. is this in the wiki somewhere? I only know of the GK802 hardware page.
<dgp> I think jas has it working in linux
<dgp> I have it working in android but I'm using the hciattach binary from the original android image
<dgp> I just added that the eeprom is on i2c2 to the wiki
<pH5> the ram pinout doesn't show any i2c scl/sda balls.
<dgp> you mean the pin mux settings in ram?
<dgp> i2c3 didn't work with the stock kernel IIRC
<pH5> dgp, I think they multiplex those pads to the hdmi tx block, by default.
<pH5> this bus is also on the hdmi connector
<dgp> yes, the board files control switching the settings for i2c2 from what I can see
<dgp> i2c3 isn't connected to anything except the header from what I can tell
<pH5> I mean, I've looked at the samsung ram datasheets. And those are not the 0x1? i2c devices.
<pH5> sure? I've seen my hdmi-dvi-adapter on i2c3
<dgp> do the DDR chips have eeproms in them according to the data sheet?
<dgp> ok, yeah there is 0x50 on there now that I have my monitor connected again
<dgp> maybe this is way edid reading doesn't work on the newer boards?
<pH5> Not that I can see. Isn't this only common for desktop ram?
<dgp> s/way/why
<pH5> embedding i2c eeproms, that is.
<dgp> I thought it could be possible, 4 addresses, 4 chips
<pH5> could well be the case. i'm not sure if the android hdmi drivers try to use i2c3 or the hdmi tx's ddc i2c master to talk to the monitor.
<dgp> I thought the edid part was done by some freescale stuff in the kernel
<dgp> <6>mxc_hdmi mxc_hdmi: Read EDID again
<pH5> right, freescale's hdmi driver
<dgp> I'm not sure what they do in the original android to change the resolution on the fly
ajayr has quit [Ping timeout: 246 seconds]
ajayr has joined #imx6-dongle
fossxplorer has quit [Remote host closed the connection]
fossxplorer has joined #imx6-dongle
fossxplorer has joined #imx6-dongle
fossxplorer has quit [Changing host]
pH5 has quit [Quit: Verlassend]
fossxplorer has quit [Ping timeout: 252 seconds]
Strswrd has quit [Remote host closed the connection]
projectgus has quit [Quit: leaving]
projectgus has joined #imx6-dongle
rz2k has quit []