<naobsd>
mmm, only rock2 square dts has chosen { stdout-path = "serial2:115200n8"; }; ...?
<sjoerd>
yeah the other dts' didn't seem to have done that
<sjoerd>
people should really add those depending on what the sensible output is
<naobsd>
this is the reason that I cannot see any output...
<naobsd>
add workaround "fdt addr ${fdt_addr_r}; fdt resize; fdt set /chosen stdout-path serial2:115200n8;" on u-boot for now...
<sjoerd>
naobsd: add console=ttyS2 to bootargs
<sjoerd>
that works as well
<naobsd>
oh
<naobsd>
surely console= is missing in default env...
<naobsd>
I have to learn more about mainline u-boot :(
<sjoerd>
it's not set by default
<sjoerd>
imho people should start setting it in the dtb
<naobsd>
set it in rock2 dts was accepted, there is not reason not to follow it :)
<naobsd>
my work machine at home is now "Linux version 4.3.0-next-20151106 (fun@ubuntu) (gcc version 5.1.0 (Ubuntu 5.1.0-0ubuntu11~14.04.1) ) #1 SMP Fri Nov 6 14:33:56 UTC 2015" on firefly-beta
<naobsd>
self compiled kernel :)
Sadneophyte has quit [Read error: Connection reset by peer]
bbelos has quit [Ping timeout: 260 seconds]
bbelos has joined #linux-rockchip
<sjoerd>
naobsd: I think it's one of those things that just isn't well-known enough
cnxsoft has joined #linux-rockchip
<naobsd>
hmm.. uSD card works fine on firefly-beta, but error on rock2...
<naobsd>
is io_domains: io-domains { sdcard-supply = <&vccio_sd>; } required?
<naobsd>
mmm
<naobsd>
it's not dts issue... some cards work, some cards don't work :(
<naobsd>
oh my uSD cards are really terrible...
<naobsd>
hmm... all of terrible uSD cards works fine on firefly... there might be board specific issue...?
<naobsd>
oops
<naobsd>
popmetal doesn't support boot from SD...?
<naobsd>
very nice, Orion R68 UART4 is working with boot from SD :)
<naobsd>
mmm, R68 hangs around "rk3x-i2c ff650000.i2c: using default SCL frequency: 100000"... :(
<naobsd>
disabling i2c0 in dts...
<naobsd>
now it boots...
<naobsd>
I think changing uart2 -> uart4 doesn't affect i2c0...
<naobsd>
mmind00: is i2c0 working on rk3368 with very recent linux-next?
<naobsd>
hm, my RK3368 box is now running with bootable SD card + USB rootfs + GbE + ubuntu trusty arm64 userland...
<naobsd>
sdmmc is not enabled yet so I cannot touch SD card from Linux ;)
<libv>
and the firefly page also looks pretty empty
jas-hacks has joined #linux-rockchip
naobsd has quit [Remote host closed the connection]
naobsd has joined #linux-rockchip
gb_master has quit [Quit: Leaving]
<mmind00>
naobsd: i2c on the 3368 was at least working in general ... as it was already talking sucessfully to the cpu regulator and rtc
pulser has joined #linux-rockchip
<naobsd>
mmind00: yeah, it was worked around 20150916...
<mmind00>
naobsd: hmm, the ip is the always the same, so any problem you experience on rk3368 should also be visible on 3288 and earier
<mmind00>
naobsd: we'll probably need to recheck mainline next weekend, if any of this made it in during the merge-window
<mmind00>
naobsd: or is there some interesting error message right now?
<naobsd>
same linux-next tree is working fine on rk3288 boards
<naobsd>
so it should rk3368 or board specific issue...
<naobsd>
it just hangs
<naobsd>
last message was "rk3x-i2c ff650000.i2c: using default SCL frequency: 100000"
<naobsd>
next should be fan53555-regulator things
<naobsd>
I don't have enough time for now
<naobsd>
I will try some more when I have time
<pulser>
mmind00: just dropped in to say your somewhat stable kernel seems to be working fine on the rk3288 Asus chromebooks - I assume there is little to no graphics abilities on the rk3288 (I saw your work on armsoc/fbdev, but wasn't able to get anything working here that I can see)
<pulser>
power consumption is (as you said on G+ at the time) not as low in sleep as chromeOS, but I didn't yet look at trying to merge in the power stuff yet
<mmind00>
pulser: great ... hopefully shortly real mainline should also work, once the display-port driver made it in ... as for graphics, as you probably have seen, the mali-binaries are somewhat usable with the armsoc-x11 driver ... webgl works nicely for example
<pulser>
hmm, I did not spot that actually - interesting
<pulser>
glad to give that a shot too - a colleague of mine said "this chromebook is awesome, BUT no linux", so he loaned me it somewhat indefinitely to see what I can do to it
<pulser>
OK - so I am using that too (via the arch package xf86-video-armsoc-rockchip), which I checked the head commit matched yours
<pulser>
were you testing webgl in firefox?
<mmind00>
nope, chromeium .. with the --use-gl=egl option
<pulser>
if I don't add that flag, I assume chromium fails on the GPU error?
<mmind00>
yep
<pulser>
that may explain it - I couldn't get chromium to start, and I assumed I was being dense
<pulser>
so I was stuck using firefox, going "eh this is not amazing"
<mmind00>
I guess you could also just start with glgears-es2 or how that is named
<pulser>
ah right - I was meaning to look for that actually
<pulser>
as I saw folks using glgears-es2, and I am oldschool using glxgears
<pulser>
I did install the glshim as part of my experiments, but not sure it's doing so much
<pulser>
OK, so chromium fails with --use-gl=egl; seems I should use debian then!
<pulser>
at least until I can debug their package and fix it
<mmind00>
Debian actually doesn't provide chromium for am ... I use some binary from some ubuntu ppa
<pulser>
ah interesting - in which case, I shall maybe just grab the binary from there then
<pulser>
and cross my fingers, then discover it doesn't work, and swap to debian anyway
<mmind00>
pulser: also not sure, if I actuall spelled that option correctly
<pulser>
OK no worries, I shall check the docs first
<mmind00>
always bad at remembering such stuff :-)
<pulser>
I was getting decent video decoding, although I am not sure if it was CPU or not
<pulser>
I think it was working via vaapi, and x11
<pulser>
OK yes, so "mpv --vo=x11 --hwdec=vaapi filename" is giving me decent video performance, and looking at CPU usage, mpv is using around 13% or so, suggesting vaapi is working for video accel at least
<mmind00>
never heard of that yet [but I'm a kernel-guy anyway] ... but I know there is currently no support for the video encoder/decoder in the 3288 in mainline
<mmind00>
chromeos has support for it, but noone tried bringing that over yet
<pulser>
interesting - I am a bit of a hybrid; I have little knowledge of the "APIs" and how things are done, but I've done a load on the android platform, so I learned stuff by osmosis
<pulser>
I think what is happening here is it's using the "GPU" via the driver to do some kind of accelerated stuff, but not using the real VPU (at least that's my guess)
<pulser>
I shall put the video encoder/decoder onto my "todo list". I do know I started off this chromebook using the chromeos kernel on arch, and I didn't have much working, but I think I figured out a fair bit since then, which might be worth me revisiting
<naobsd>
just a note: "20150916, UART2 console, eMMC boot(no SD)" i2c0 ok, "20151106, UART4 console, SD boot" i2c0 hang
<naobsd>
and I used rk3368_defconfig from somewhat-stable. it might be wrong with latest linux-next
<mmind00>
naobsd: that is probably your sd instead ... sd and uart2 share their pins
<mmind00>
you only get either one
<naobsd>
mmind00: UART_4_ and SD for now
<naobsd>
btw SD card detaching is not working (kernel hang)
<naobsd>
reading SD is ok at least
<naobsd>
I'm not sure my dts is fine
gb_master has joined #linux-rockchip
gb_master has left #linux-rockchip [#linux-rockchip]
<pulser>
mmind00: oh nice, I see on the mailing list someone is working on the crypto accelerator on rk3288 :) that shall be nice, I might need to try to pull their patches and test
<mmind00>
pulser: yep ... see my comment in v1 about the reset ... looks like the current v2, didn't take that into account yet ... probably need to reply there too
<pulser>
ah yes, good point
<pulser>
crypto engine will be in a half-enabled state when handed over to the kernel
cnxsoft has quit [Quit: cnxsoft]
dlezcano has quit [Ping timeout: 240 seconds]
dlezcano has joined #linux-rockchip
hipboi has joined #linux-rockchip
jas-hacks has quit [Quit: Leaving.]
hipboi has quit [Ping timeout: 250 seconds]
ganbold has quit [Quit: Leaving]
ganbold has joined #linux-rockchip
<c0d3z3r0>
hi guys, I've got a question on rk3188. I know that there is no sensor for temperature I could access through kernel but is there ANY heat protection or would the cpu just die if it's too hot?
<c0d3z3r0>
the trm doesn't say anything about heat protection… but max. 125°C on one page and 85°C on another… interesting o.O
cristian_c has joined #linux-rockchip
cristian_c has quit [Read error: Connection reset by peer]
cristian_c has joined #linux-rockchip
cristian_c has quit [Read error: Connection reset by peer]
<naobsd>
mmm??? 20150916 doesn't boot :(
<naobsd>
SD boot makes something bad?
cristian_c has joined #linux-rockchip
cristian_c has quit [Read error: Connection reset by peer]
cristian_c has joined #linux-rockchip
markm has quit [Ping timeout: 244 seconds]
rubensm has quit [Ping timeout: 260 seconds]
rubensm has joined #linux-rockchip
<chris2>
"Nvidia Jetson TK1 Development Board is Now Selling for $99"
jas-hacks has joined #linux-rockchip
premoboss has quit [Remote host closed the connection]
<c0d3z3r0>
mmind00: Hi :) I did some testing without arc emac but with an usb ethernet adapter. the panics caused by arc emac are gone but I got two errors at 2.062333 and many exceptions… maybe you could have a look at this when you have some time? http://pastebin.com/VUPVPpjT
<mmind00>
c0d3z3r0: not sure what the dwc2 does, but that is more a warning, as it will have used another value already ... as for the longer list of dumps below, I don't know, but it seems to have something to do with the twd (the per-cpu localtimer)
<mmind00>
c0d3z3r0: not sure if that is also similar to the global-timer issues we see, but normally the smp_twd code should already adapt to clock-rate changes
<c0d3z3r0>
mmind00: oh bad… so we have another clock problem :/
<mmind00>
c0d3z3r0: that was just guess, as it was complaining about twd-related stuff
<c0d3z3r0>
mmind00: hmm ok.. I have another different question to you about clock/voltage on rk3188. the trm says 1.1V is the absolute maximum for AVDD/ARM_VDD but the kernel sets it to 1.35V at 1,6GHz. where does this value come from? is the trm wrong/old/whatever?
<mmind00>
c0d3z3r0: the values come from the vendor-kernels ... the TRM-values never really match somehow
<pulser>
mmind00: not wanting to disturb you as you seem busy, but I got debian running on the rk3288 chromebook and am going to have a play - debian feels smoother already (scrolling etc), and I haven't put in gpu drivers
<c0d3z3r0>
mmind00: yay. rockchip is great. not. :D
<pulser>
haha well, it seems to be getting slightly closer to mainline these days
<mmind00>
pulser: really np ... I'm not that busy ;-)
<pulser>
heh ;)
<pulser>
I had suspected
<pulser>
I think debian uses a better setup out of the box
<pulser>
firefox was actually scrolling not too badly (well, iceweasel)
<pulser>
usably enough I think I will be going to the store to buy my own on Monday or Tuesday
<mmind00>
pulser: :-)
<pulser>
aluminium chassis, 13 hour battery life even on linux... it's a no-brainer
<mmind00>
and we will get those specs on mainline too in time (hopefully shorter than longer)
<pulser>
yeah - I was having a little look and your branch didn't seem too deviated
<pulser>
are you the "submitter" to mainline (I am not familiar with the terminology)
<pulser>
maintainer I think is a better word?
<mmind00>
yep I'm the maintainer for Rockchip stuff (that is not drivers)
<pulser>
very nice :)
<pulser>
yes, I was very pleased when I found your work on the rockchip devices
<pulser>
there is lots of stuff out there using them, and few people working to standardise them and give them a lifespan longer than the usual 6 months
<mmind00>
in the beginning (2013) I was also doing all the coding, but currently as you might've seen there are so many people providing code ... it really has come a long way
<pulser>
I remember the rk3066, when I was trying to get a €40 tv stick to work on a clean android install
<pulser>
oh indeed, it definitely has
<pulser>
I think I saw some contributions from RK directly too?
<pulser>
although they may have been cherrypicks from google's kernel rather than direct contributions
<mmind00>
nope ... Rockchip itself also has come a long way
<mmind00>
i.e. they did provide the whole drm/kms stuff ... including the rework of the dw_hdmi driver ... now the analogix-dp we share with exynos
<pulser>
oh brilliant
<pulser>
that reminds me, I have a pile of cables so I can test out the micro HDMI port
<mmind00>
that are real mainline works by Rockchip engineers
<pulser>
impressive
<pulser>
a far cry from 2012/13
<mmind00>
and the analogix-work actually will be mainline-first
<pulser>
now that is impressive
<pulser>
thing is, really everyone benefits here
<pulser>
as RK being more mainline saves them time, and their customers time
<pulser>
so they can actually use this as a selling feature
<pulser>
"hey, works with mainline kernel 4.4 or later"
<pulser>
when I see that, I go "well that is WAY better than the alternatives"
<mmind00>
yep ... but I don't know if anybody from the Android world cares about that
<pulser>
oh they don't, sadl
<pulser>
although sony are doing this now
<pulser>
you will find the Sony Xperia range are now on a unified kernel internally
<mmind00>
yep ... I was at the BoF Tim Bird held in Dublin
<pulser>
they realised the development outlay was more than it would be to make a single proper unified kernel
<pulser>
oh very nice
<pulser>
Sony aren't mainline because a load of qcom stuff isn't mainline, but they are arguably the "best" in terms of supporting upstreaming
<pulser>
in the long term though, the market is struggling and I think we will see people trying to go mainline in the next year or two, or they might not survive (smaller players mainly)
<mmind00>
yeah, I've seen qcom kernels at my primary employer ...
<pulser>
yup, I've dealt with them too
<mmind00>
and even bootet a near-mainline on one of our phones ... didn't get to graphics sadly
<pulser>
it's a shame everything is so "specific" to versions and similar
<pulser>
oh nice
<pulser>
qcom appears to change their android-level HAL regularly, to force their clients to pay for updats
<pulser>
updates *
<pulser>
(cynical view)
jas-hacks has left #linux-rockchip [#linux-rockchip]
<pulser>
I am guessing you've had the UART-over-USBport working? :)
<pulser>
when I read about that, I was very happy! I will need to build a little rig up and get that going myself (thinking a USB to micro USB going in the port, then using a micro USB female to breakout to get it all nice and neat
<mmind00>
pulser: yep the usbuart is working on my chromebooks
<pulser>
very nice, will need to get the parts together for that
<pulser>
RE your GPU blob download package, I think I am missing a dependency; it requries glx-diversions, and glx-alternative-mesa, which it cannot seem to find
<pulser>
I had a quick look and see mention of those packages elsewhere, but don't see them in debian, so I'm wondering if you are using sid perhaps?
<mmind00>
nope they are available everywhere ... you just need to add "contrib" to your package list
<pulser>
ah perfect thanks - knew I forgot something!
<pulser>
a while since I debootsrap'd debian
<mmind00>
as the whole glx-alternatives stuff is for all that binary gpu drivers (fglrx and nvidia)
<pulser>
yeah indeed
<pulser>
I use arch on the desktop with radeonsi, but I remember lookng at this when I tried debian
<pulser>
and I didn't fancy fglrx
<mmind00>
for that bit of gaming I do, fglrx works ok for me at home :-) ... at least Cities Skylines runs fine
<pulser>
yeah :) I play games very very rarely, and I found radeonsi was remarkably impressive actually
<pulser>
haven't tried cities skylines, but it does look good!
cristian_c has quit [Read error: Connection reset by peer]
cristian_c has joined #linux-rockchip
cristian_c has quit [Read error: No route to host]
cristian_c has joined #linux-rockchip
cristian_c has quit [Read error: Connection reset by peer]
cristian_c has joined #linux-rockchip
cristian_c has quit [Ping timeout: 260 seconds]
<pulser>
probably a silly question, mmind00 - I have now got your driver, and your armsoc driver installed
<pulser>
is there anything I need to do to "enable" it (I don't see an xorg.conf.d file like I am used to, to check armsoc is being used(
<mmind00>
pulser: not sure do you see a /etc/X11/xorg.conf.d/armsoc.conf ?
<pulser>
no; there is no xorg.conf.d dir there as I would have expected
<pulser>
oh wait, I see a packaging-debian branch
<pulser>
since you merged the rockchip stuff into it, I shall use it instead
<mmind00>
yep ... and there you will also find a debian/armsoc.conf that gets put into the right location
<pulser>
gotcha :)
<pulser>
hmm, debian package refuses to build, asking for a tarball of the sources (for quilt)
<pulser>
although seems making my own tarball worked fine :)
<mmind00>
great then :-)
<mmind00>
that stuff really is mainly for myself and people able to help themselfs, like you just did ... especially as the relevant changes should go up into the official armsoc xserver anyway
<pulser>
yeah :) btw, the xorg.conf.d folder isn't made by default, so the conf wasn't copied
<pulser>
so I will jsut do it manually (just in case anyone has an issue thought I'd mention it)
<mmind00>
ah "somebody" forgot "dirs" file in the debian dir
<pulser>
ahh that would explain it
<pulser>
btw, one thing I wanted to check; when you said "There are two possible solutions, simply doing a symlink to the mesa-libGL and providing libGL from the glshim library demonstrated some weeks ago. For now just create the link manually :-) .", what should be symlinked here?
<pulser>
(I am looking at glshim too, but it got me curious as to if I should be symlinking something)
ojn has quit [Ping timeout: 264 seconds]
ojn has joined #linux-rockchip
<mmind00>
pulser: glx-diversions moves all the mesa GL libs out of the way into a mesa-subdir
<mmind00>
you won't have much fun with glshim ... enough for a buggy extremetuxracer, but nothing more
<pulser>
OK, so if I am not using glshim, there is no real action requird?
<pulser>
as the glx-diversions should have taken care of it?
<mmind00>
there is action required ... creating that libGL symlink
<pulser>
ah right - so I need to symlink /usr/lib/libGL.so to /usr/lib/mesa/libGL.so ?
<mmind00>
hmm ... trying to remember how that did go ... a bit ago that I last played with that part :-)
<mmind00>
if you have a usr/lib/arm-linux-gnueabihf/libGL.so.1 pointing to /etc/alternatives/glx--libGL.so.1-arm-linux-gnueabihf everything should be fine
<pulser>
I have that already in place, it seems
<mmind00>
which should happen if you install that glx-alternative-mali package build from my mali-driver sources
kapouer has joined #linux-rockchip
<pulser>
Ok great
<mmind00>
ok, so the g+ post is older than that glx-alternatives package
<pulser>
so this should now in theory be working
<pulser>
ahhh, that would explain it then :)
<mmind00>
correct, should in theory work
<pulser>
right, so what is the best "check"? to get es2gears going or something?
<kapouer>
hello
<pulser>
or maybe a CLI tool to "read back" which driver is in use? glxinfo isn't too helpful iirc, but it does imply it's working as it complains of the missing rockchip_dri as usual :)
* kapouer
is probably trying to do the same thing as pulser
<pulser>
kapouer: trying to get an rk3288 working with graphics?
<kapouer>
yes c201
<pulser>
ah right, I have C100P :)
<pulser>
which is identical internally except from chassis and touchscreen, pretty much
<mmind00>
es2gears or es2info ... should at least say something about the gl-provider being mali
<mmind00>
(or maybe it's called es2_info)
<mmind00>
always not sure
<pulser>
I will take a look for it
<mmind00>
package is mesa-utils-extra if you didn't install that already
<pulser>
yes, I had spotted and installed it
<pulser>
OK it is using software, it sas "failed to open armsoc (Search paths ....)"
<pulser>
also got a libEL warning for MESA-LOADER of malformed/no PCI ID (makes sense, no PCI bus)
<mmind00>
ah ...
<pulser>
although that is DRI2 error, and we don't have a "real" DRI for rockchip afaik
<mmind00>
update-alternatives --config glx
<mmind00>
and then actually selecting the mali one :-)
<pulser>
Only one alternative in link group glx (providing /usr/lib/glx): /usr/lib/mesa-diverted
<kapouer>
pulser: i can help you probably with this
<pulser>
ah, you had this before?
<mmind00>
pulser: when you build the mali-driver package, it should've created two (mali-driver and glx-alternative-mali) ... did you install both?
<kapouer>
:)
<pulser>
I noticed both and *thought* I installed both
<pulser>
let me re-do and ensure I do this time
<pulser>
so I reinstalled the mali-driver and it appeared now
<pulser>
I think that I maybe installed them in teh wrong order before (if that is possible)
<pulser>
i.e. installed the drive after the alternative
<pulser>
mali + midguard :)
<pulser>
thanks mmind00
<kapouer>
are you using debian kernel ?
<pulser>
no, I am using mmind00's branch somewhat-stable
<kapouer>
ok now i'm just missing how to install it ? just dd to /devmmcblk1p1 (i'm on sd card)
<pulser>
simply as I had compiled it before already for arch, and just rebuilt it with the new ramdisk
<pulser>
OK I am on SD as well - when you have your signed (remember to sign!) image, just dd it to the partition on the SD
<pulser>
if in doubt, do lsblk and check which mmcblk is internal, and use the other one
<pulser>
kernel will be ~16 MB partition
<pulser>
once you're done, ensure you use cgpt to set the flags so it knows to boot that partition :)
<kapouer>
partition is ok, i'm already booting chromeos kernel from there
<pulser>
OK cool
<pulser>
so just dd if=your.kpart of=/dev/mmcblkXpY
<kapouer>
tried by taking vmlinuz from latest debian arm, doesn't work
<kapouer>
black screen
<pulser>
you're trying to use the debian upstream kernel?
<pulser>
I don't think that will work - rk3288 isn't fully supported in mainline yet (it's not far off though)
<kapouer>
yes, why not
<kapouer>
<mmind00> nope Debian ... with mainline kernel
<pulser>
I think by that, he means mainline kernel from kernel.org (4.3.0 or whatever)
<kapouer>
misinterpretation...
<pulser>
rather than distro-packaged kernel
<kapouer>
ok now i only need to get a kernel config
<mmind00>
the mainline kernel is missing the driver for the edp, thus you don't get output on the internal display
<mmind00>
hdmi is working with mainline itself though
<pulser>
it is only 2 lines tweaked from mmind00's
<kapouer>
(after a successful install of course)
<pulser>
but I suggest you highlight that the incbin lines will need adjusted per your own device
<pulser>
as I hard-coded in my device config name, since I just wanted a kernel there and then!
<mmind00>
kapouer: not sure what you mean with "those informations", but I don't think we should be pointing more people than necessary to my dev-branch :-)
<kapouer>
fair enough
<pulser>
I think he means to update the FIT given on that page to use an absolute path
<mmind00>
kapouer: in theory the edp driver should make it into 4.5
<pulser>
rather than a relative path
<kapouer>
ok, thank you both. BTW mmind00 do you think the mali-driver-1.0 package should make it into debian (non-free) ?
<mmind00>
kapouer: again, I don't think so ... ChromeOS moved away from x11 and the newer driver version did not build with x11 anymore, so they dropped it
<mmind00>
kapouer: so we're essentially stuck at the current version for the near future
<pulser>
I'd concur, given their move to Freon
<mmind00>
they had this nice special case for me in their build script to build a x11 version too ... but when the build broke it seems nobody was to keen on fixing it
<pulser>
I have not looked into it at all, to see if it's possible/practical/desireable to even look at using Freon on a system, especially given wayland is a thing, and exists...
<pulser>
ah, that's a shame
<pulser>
I am surprised they did that tbh - they are not as nice as that on the android side of things
<mmind00>
that are very different teams ... in terms of persons but also in terms of how they work :-)
<pulser>
oh yes indeed
<pulser>
I note the "developer mode" on Chromium
<pulser>
android-division should REALLY take heed and follow that lead
<pulser>
this is why I found the rumour of the merge of chromeOS and Android to be rather "interesting" to say the least - I could just imagine the arguments spilling into public mailing lists etc
<mmind00>
I found that rumor rather freightening ... in terms of market relevance it would probably be more like being Android taking
<mmind00>
over
<pulser>
yeah, pretty much
<pulser>
as if you look at the android ecosystem
<pulser>
the idea of google providing updates would cause riots and fires by OEMs and carriers
<pulser>
as chromeOS presents one consistent UX across all devices, rather than allowing carriers to fill the device up with rubbish :)
<pulser>
if you let android get their hands on it, there would be no developer mode etc
<pulser>
they'd also sign the SPI Flash and force verification of it, rather than use the write-protect screw
<mmind00>
that's more a decision of the devicemaker though ... the phones from my current employer are unsigned by choice
<pulser>
indeed
<pulser>
although they are basically requiring signing/validation with 6.0 CDD
<pulser>
very interesting - even though I've not set up my touchscreen or anything (it works as a mouse due to standard xorg input drivers), chromium browser regards it as a touchscreen, and lets me do "fling" scroll
<kapouer>
omg yesterday i compiled the kernel on the actual device, not cross compiled it
<pulser>
haha how long did that take?
<pulser>
I compiled some packages on the device and it wasn't TOO bad - I imagine with -j4 and running on the SSD it wouldn't be TOO bad
<kapouer>
less than 8 hours, though it was very slow because of running it on the external sd card
<pulser>
yeah
<pulser>
so the internal is around 80 MB/s write give-or-take
<pulser>
so it may be around an hour if you were fully I/O bound
<kapouer>
it took me ages to realize the chicken-and-egg problem is solved by making a weasel build the chicken
<pulser>
pretty much :)
<kapouer>
hmmm the "midgard r5p0-06rel0" gpu user space driver contains libmali.so ? what's the deal ?
<kapouer>
(talking about the one from malideveloper.com)
<mmind00>
kapouer: that is somehow build against the fbdev based firefly vendor kernel
<mmind00>
(and older than the driver currently in used from chromeos)