03:33 <fenixfunk> OK so I found a post on where the UART pads on the UG802 are. Since I can't get it to back to where I can flash it, should I maybe just try to hook up to the UART and see if I can get anything coming out that way? I know it's only a $40 stick but I just lost my job :/

04:06 <ferric> fenixfunk: why can't you flash it?

04:11 <fenixfunk> this board only has two pads near the NAND that I'm supposed to short so that rkbatchtool can see it

04:11 <fenixfunk> i've tried to shorting them to no avail. i believe it's a UG802 clone.

04:16 <ferric> aha

04:16 <ferric> damn the clones.

04:21 <fenixfunk> I also have the Timing Power rk3188 stick and the picuntu 4.5 image does not work for me so sometime this week I think I'll be trying to find UART pads on it, upload some pics and start working on getting a kernel up and going :)

04:28 <ferric> just run kitkat, fenix. :P

04:29 <ferric> fenixfunk: btw, the rk3288 soc design is up on rk3288.com if you're interested.

04:30 <fenixfunk> ;p

04:30 <fenixfunk> thanks for that! checking it out now!

05:11 <fenixfunk> HAH! Wouldn't you know! I just duct-taped the larger of two lenses from a pair of broken binoculars, used the flathead bit of a cheapo car boot screwdriver on those two pads i mentioned earlier, and rkbatchtool sees the device now. maybe this ug802 clone isn't worthless!

05:11 <fenixfunk> (i taped the lens to my face, left that out in the excitement...hah)

06:50 <fenixfunk> ok, the iPazzPort brand UG802 clone (model no. NC19) is now running an Ubuntu 3.0.8 kernel... this is definitely progress considering I thought I had lost it for good :)

10:36 <valentyn> Hello everyone. Question about my Minix Neo X7 Mini. I tried to reflash the system partition with rkflashtool, but it doesn't work. Flashing with upgrade_tool works fine.

10:36 <valentyn> Is rkflashtool out of date? Did something change in Rockchip's USB protocol?

10:37 <ncrmnt> valentyn: rkflashtool worked reliably for me so far.

10:39 <valentyn> what happens is rather odd:

10:39 <valentyn> $ sudo ./rkflashtool p

10:39 <valentyn> ... CMDLINE:console=ttyFIQ0 androidboot.console=ttyFIQ0 init=/init initrd=0x62000000,0x00800000 mtdparts=rk29xxnand:0x00002000@0x00002000(misc),0x00008000@0x00004000(kernel),0x00008000@0x00012000(boot),0x00010000@0x00020000(recovery),0x00020000@0x00030000(backup),0x00040000@0x00050000(cache),0x00800000@0x00090000(userdata),0x00002000@0x00890000(kpanic),0x00130000@0x00892000(system),-@0x009c5000(user)

10:40 <valentyn> Now I use: sudo ./rkflashtool r 0x0892000 0x0130000 > /tmp/systm.img

10:40 <valentyn> Then, immediately afterwards:

10:40 <valentyn> sudo ./rkflashtool w 0x0892000 0x0130000 < /tmp/systm.img

10:41 <valentyn> ... then a third time: $ sudo ./rkflashtool r 0x0892000 0x0130000 > /tmp/systm.img.rewritten

10:41 <valentyn> md5sum /tmp/systm.img*: c68fb2809046ec95ef2fa7c29b13ad5f /tmp/systm.img

10:41 <valentyn> a4ffc9c99766c7d68006a0e3c0290874 /tmp/systm.img.rewritten

10:42 <valentyn> ... and finally:

10:42 <valentyn> $ sudo ./upgrade_tool di -s /tmp/systm.img

10:42 <ncrmnt> Hm.... have a look with a hexeditor, may be some garbage/missing chunk at the end?

10:43 <ncrmnt> never actually cared to do md5summing

10:43 <valentyn> sudo ./rkflashtool r 0x0892000 0x0130000 > /tmp/systm.img.rewritten-with-upgrade_tool

10:43 <valentyn> ... md5sum is c68fb2809046ec95ef2fa7c29b13ad5f again!

10:44 <ncrmnt> try cmp

10:44 <valentyn> I already looked, there are subtle differences between systm.img and systm.img-rewritten

10:44 <ncrmnt> Where's the first mismatch?

10:45 <valentyn> for a in /tmp/systm.img*; do dd if=$a count=100 2>/dev/null|xxd > $a.xxd; done

10:45 <valentyn> diff /tmp/systm.img.rewritten.xxd /tmp/systm.img.xxd

10:45 <valentyn> < 0000400: e808 0000 2009 0700 0000 0000 ce01 0000 .... ...........

10:45 <valentyn> ---

10:45 <valentyn> < 0000410: 9302 0000 0100 0000 0000 0000 0000 0000 ................

10:45 <valentyn> > 0000400: 080c 0000 0080 0900 0000 0000 cc76 0200 .............v..

10:45 <valentyn> > 0000410: b305 0000 0100 0000 0000 0000 0000 0000 ................

10:45 <valentyn> 68c68

10:45 <valentyn> < 0000430: aa37 1f4d 0000 ffff 53ef 0200 0000 0000 .7.M....S.......

10:45 <valentyn> ---

10:45 <valentyn> > 0000430: 8e1d 1f4d 0000 ffff 53ef 0100 0000 0000 ...M....S.......

10:45 <valentyn> 70c70

10:45 <valentyn> < 0000450: 0000 0000 0b00 0000 8000 0000 2000 0000 ............ ...

10:45 <valentyn> ---

10:45 <valentyn> > 0000450: 0000 0000 0b00 0000 8000 0000 2400 0000 ............$...

10:46 <valentyn> That's not what I'd call "random garbage at the end", it's random extra 1 bits for free or something.

10:46 <ncrmnt> Hm... First time I see this, lol.

10:46 <ncrmnt> git://git.code.sf.net/p/rkflashtool/Git - I got my rkflashtool here

10:47 <ncrmnt> Since there's a dozen forks and no semiofficial may be you got a buggy build?

10:47 <ncrmnt> Although... sounds really unlikely.

10:47 <valentyn> You see, I wrote http://valentijn.sessink.nl/?p=382 september 2012, then found out this very procedure messed up my Neo X5 in december 2012;

10:48 <valentyn> ... then, April 2013 someone asked me by mail - and I wrote http://valentijn.sessink.nl/?p=446#more-446 this follow-up...

10:48 <ncrmnt> Do you have any other devices with rk3188?

10:49 <valentyn> ... and now the same happens with my X7. (I found out how to fix it :-)

10:49 <valentyn> Yes, I own a tablet with rk3066

10:49 <valentyn> That's what the original rkflashtool message was about.

10:50 <ncrmnt> Hm... Is it the same nasty stuff there as well?

10:50 <ncrmnt> The only thing I can suggest - is trying to debug it.

10:51 <valentyn> No, I guess not - I rooted my tablet with it originally.

10:51 <ncrmnt> Might be well a usb problem. dwc_otg the rockchip uses is 146%-shitty ASIC by design.

10:52 <ncrmnt> If it turns out to be a dwc_otg weirdness when connected to your super-special usb-host on the PC - I won't be surprised.

10:52 <valentyn> It probably is. Still, upgrade_tool does work and rkflashtool doesn't...

10:53 <ncrmnt> Well, may be it' time to look at their sources

10:53 <ncrmnt> rz2k: ping

10:53 <rz2k> ncrmnt: whats up

10:54 <ncrmnt> Trying to get fbturbo and kwin_gles working in jessie. Well, it mostly works, but dragging windows is slow as hell with working mali.

10:54 <ncrmnt> And es2_info segfaults. Looks like the XInitThreads problem exception13 solved by patching

10:55 <valentyn> Hmm. It gets weirder now: I seem to have managed to rewrite a clean image for the first time, md5sums match :-S

10:55 <valentyn> Obscure timing problem :-(

10:56 <ncrmnt> Since my blobs didn't pop XinitThreads in readelf, I quickly threw up an LD_PRELOAD hack (the second, after fake_mali_clz_lut.so)

10:56 <ncrmnt> But so far it didn't help. Is there any known working method of fixing this one?

10:57 <ncrmnt> I also have es2gears background transparent (lol), but that looks like a totally different problem.

10:58 <ncrmnt> valentyn: try connecting to a different usb host on the pc with no hubs.

10:59 <ncrmnt> rz2k: xf86-video-mali from the sunxi repo looks totally screwed up. Is it being maintained in any way?

10:59 <rz2k> no

10:59 <rz2k> throw it away and use fbturbo

10:59 <rz2k> it has mali drm support

10:59 <rz2k> as well as sunxi display layers and etc

10:59 <rz2k> for zerocopy

11:00 <ncrmnt> Well, see my writeup above about performance.

11:00 <rz2k> es2_info segfaulting was patched long ago in sunxi-mali repo

11:01 <ncrmnt> Hm, I'm using the current master branch

11:01 <rz2k> also I bet you wont be able to have a decent desktop experience out of rk and mali

11:02 <rz2k> there might be anything in between starting from low memory bw ending with fb written with mdelay()'s between syncs

11:02 <ncrmnt> Well, so far 2d performance in kicad is quite decent.

11:02 <tonikasch> i have been using rk with mali and fbturbo without problems...

11:03 <ncrmnt> tonikasch: Does kwin_gles work for you?

11:03 <tonikasch> mmm, I haven't checked that

11:04 <tonikasch> Not near a rk device now, I'll check later

11:04 <ncrmnt> rz2k: Does fbturbo need a lot of ofscreen memory? Looking at my current kernel - I have 24MiBs allocated for FB0

11:04 <ncrmnt> which is 1920*1080 @ 32bpp

11:05 <rz2k> if I remember correctly, yes

11:05 <rz2k> for sunxi_disp it even has a check for that

11:05 <rz2k> so it wont use disp if you dont have resolution x 3 of memory

11:06 <ncrmnt> 1920*1080*4*3 =24883200, that's just what I have allocated

11:07 <ncrmnt> so, unlikely

11:07 <tonikasch> have you managed to get true color?

11:09 <ncrmnt> Yep

11:09 <ncrmnt> In fact, true color was a hell of a lol. I used radxa wiki fbset tricks

11:10 <ncrmnt> to get true color, but the fonts and the borders of window still looked like shit

11:10 <ncrmnt> causing even my eyes to bleed

11:10 <ncrmnt> After 2 days of digging into the guts of rk_fb I decided to take a screenshot and open on a laptop

11:11 <ncrmnt> Well, it turned out that Philips 55' TV has some 'Digital Crystal Clear' tech that 'improves' the picture quality.

11:11 <ncrmnt> With it disable the picture is... well, distorted.

11:11 <ncrmnt> *disabled.

11:12 <tonikasch> :\

13:33 <ncrmnt> Great, ap6210 is giving me creeps already. Anybody managed to get bluetooth part of it working?