ChanServ changed the topic of #linux-rockchip to: Rockchip development discussion | IRC log http://irclog.whitequark.org/linux-rockchip | Community GH https://github.com/linux-rockchip | Rockchip GH https://github.com/rockchip-linux | ML https://groups.google.com/group/linux-rockchip
Xal1u5 has joined #linux-rockchip
BenG has quit [Ping timeout: 252 seconds]
vstehle has quit [Ping timeout: 252 seconds]
Tef613 has joined #linux-rockchip
adjtm has quit [Ping timeout: 252 seconds]
dol-sen has quit [Ping timeout: 260 seconds]
MoeIcenowy has quit [Quit: ZNC 1.6.5+deb1 - http://znc.in]
MoeIcenowy has joined #linux-rockchip
Xal1u5 has quit [Quit: Leaving]
lkcl has quit [Ping timeout: 252 seconds]
dlezcano- has joined #linux-rockchip
hanetzer has joined #linux-rockchip
lkcl has joined #linux-rockchip
jwerner has quit [Ping timeout: 245 seconds]
vstehle has joined #linux-rockchip
chewitt has quit [Quit: Zzz..]
chewitt has joined #linux-rockchip
vicencb has joined #linux-rockchip
vicencb has quit [Quit: Leaving.]
matthias_bgg has joined #linux-rockchip
ramcq has quit [Ping timeout: 252 seconds]
ramcq has joined #linux-rockchip
ldevulder has joined #linux-rockchip
afaerber has joined #linux-rockchip
chewitt has quit [Quit: Zzz..]
afaerber has quit [Quit: Leaving]
chewitt has joined #linux-rockchip
s_frit has quit [Remote host closed the connection]
s_frit has joined #linux-rockchip
ldevulder has quit [Ping timeout: 252 seconds]
adjtm has joined #linux-rockchip
vicencb has joined #linux-rockchip
afaerber has joined #linux-rockchip
ldevulder has joined #linux-rockchip
vicencb has quit [Quit: Leaving.]
JohnDoe_71Rus has joined #linux-rockchip
JohnDoe_71Rus has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/]
JohnDoe_71Rus has joined #linux-rockchip
Kwiboo has quit [Quit: .]
Kwiboo has joined #linux-rockchip
nashpa has quit [Ping timeout: 245 seconds]
nashpa has joined #linux-rockchip
matthias_bgg has quit [Read error: Connection reset by peer]
matthias_bgg has joined #linux-rockchip
ldevulder has quit [Quit: Leaving]
vagrantc has joined #linux-rockchip
afaerber has quit [Quit: Leaving]
Ke has joined #linux-rockchip
<Ke> has someone already fixed the keyboard problem on Kevin?
<Ke> before I look any further
<sphalerite> so I'm on a gru-bob (rk3399) chromebook, and as the arch linux arm wiki describes, "Note that the port will display as "Headphones" despite using the speakers. When paired with pulseaudio and pulseaudio-alsa, be aware that the full volume range is addressed through levels 0-9 of the Master volume control. Levels 10-100 provide no additional gain." — but this isn't normal AFAIU :) is there a way to
<sphalerite> fix this?
<sphalerite> Ke: keyboard problem? (asking because I had a keyboard problem with mainline on bob, left and right arrow keys didn't do anything)
<Ke> yes, that is the one
<sphalerite> good to know I'm not alone in experiencing it :') but I don't have anything useful to contribute, sorry
<Ke> yup it's fine, I am just hoping I am not debugging this for nothing
<Ke> column 12 seems to be always 0
kaspter has quit [Read error: Connection reset by peer]
kaspter has joined #linux-rockchip
<Ke> I guess the next part is investigating, who is supposed to set that col[12]
aalm has quit [Ping timeout: 245 seconds]
scelestic has quit [Quit: leaving]
matthias_bgg has quit [Quit: Leaving]
scelestic has joined #linux-rockchip
<Ke> found something that looks suspicious
<Ke> ec_dev->event_size = ret - 1;
<Ke> -1 and I am seeing the last byte being 0
aalm has joined #linux-rockchip
<Ke> this could possibly mean that people who have old ec fw have the bug and the ones that have the new one do now
<Ke> Esmil: any comments on your ec fw version?
<Ke> or anyone can comment on how to figure out mine?
<asciilifeform> Ke: if you have the debug cable ( http://www.loper-os.org/?p=2415 or i hear google actually sells it now ) there's a ec console on /dev/ttyUSB2 on boot, prints ver etc
<asciilifeform> ( i actually have this same machine, but not yet gotten to where would see this bug , still trying to bake a replacement bootloader )
<Ke> which bug?
<asciilifeform> the keyboard thing mentioned earlier
<Ke> well I am testing a fix now
<Ke> asciilifeform: assuming I don't want to solder, any tips on how to find that cable?
<Ke> asciilifeform: also replacement bootloader would be very welcome
<asciilifeform> Ke: i think amazon sells now
<Ke> at least, if it would give me the ATF updates
<Ke> asciilifeform: I need some search terms, I am not an electric engineer?
<Ke> suzy-q is not helping
<Ke> I guess someone else might know
<urjaman> https://www.sparkfun.com/products/14746 -- i suppose amazon/ebay will be cheaper but this is where i had seen them :P
<Ke> heh, $14 is not a problem
<urjaman> i dont have a device where this would be useful so ...
<Ke> thanks
<asciilifeform> that's the cable yes
<Ke> hah, fixed it
<Ke> now I deserve a cookie
<Ke> I am pretty sure someone has fixed it already in some branch and was waiting for me to make the efoort before making the pull request
<urjaman> or it's a patch sitting on some ml archives for months by now
<urjaman> that's what i found out when i "fixed" the C201 usb hot plug :P
<Ke> quite
<Ke> I made a patch to fix compile failure in mv-ddr-marvell and noticed there were already 2 pull requests for it, after I made mine
<Ke> mv-ddr-marvell is definitely not caring about outside contributions
<Ke> probably wanting to keep the copyrights or something
<Esmil> Ke: heh yeah. reverting 57e94c8b974db2d83c60e1139c89a70806abbea0 seems to help
<Ke> did someone fix it already?
<Esmil> I don't know. I just tried reverting that commit
<Ke> did you tell anyone?
<Ke> not me obviously
<Ke> 57e94c8b974db2d83c60e1139c89a70806abbea0 is the commit indeed
<Ke> it makes the memcopy too short
<Esmil> no, I only tried it now because you said that code looked supicious
<Ke> v0 protocol has different semantics
<Ke> I am now the expert having investigated this thing for several minutes
<Ke> !
<Esmil> Ke: btw. do you also get the reserve_memblock_reserved_regions WARNING in the early dmesg?
<Ke> I can check soon
kaspter1 has joined #linux-rockchip
kaspter has quit [Ping timeout: 244 seconds]
kaspter1 is now known as kaspter
<Esmil> Ke: alse cat /sys/class/chromeos/cros_ec/version says RW version kevin_v1.10.234-d3eb899
<Ke> asciilifeform: what about yours?
<Ke> btw. what was the thing about updating that ec fw, is it possible?
<Esmil> I haven't actually touched the on-board mmc, so I can just boot chromeos and hope something happens automatically ;)
<asciilifeform> Ke: don't have mine handy currently, so no idea re ver. and yes you can reflash via the usb cable.
<asciilifeform> ( with google's patched 'flashrom' )
<Ke> how safe is that reflash?
<Ke> is it brick, if it fails?
<asciilifeform> Ke: on the c101pa boxen, the flashing is done by cr50, which isn't overwriteable except by official vendor bins
<asciilifeform> so it's theoretically unbrickable
<asciilifeform> ( i.e. separate chip drives the usb debug, and can rewrite both ac and ap (cpu) boot roms )
<Ke> ambedded controller?
<asciilifeform> Ke: http://www.loper-os.org/?p=2433 << everything i currently know re the controller
<asciilifeform> aside from 1 fact, since that piece google released a cr50 firmware that enables spi rom writes , currently i use it in my box
<Ke> yeah I remember the cr50 discussions
<asciilifeform> ( it still won't rewrite itself with arbitrary bin, but at least can be used as 'unbrickable' debugger for ec and ap now )
<Ke> ok so ac was a typo indeed
<asciilifeform> yea it's 'ap' in the official docs
<asciilifeform> ( i.e. the cpu boot rom )
<asciilifeform> 8MB on this unit.
<Ke> no you wrote "ac and ap" ec and ap are very familiar terms for me also
<asciilifeform> sorry typo
<asciilifeform> ap ( cpu bootloader ) and ec (embedded controller) aha.
<Ke> sure, I just wanted to confirm
<asciilifeform> formerly if you wanted an 'unbrickable' bootloader dev box, had to solder probes.
<asciilifeform> ( c101pa doesn't ship with the 'servo' connector populated, and besides nobody sells the 'servo' device afaik )
<Ke> well.. you know SD boot
<asciilifeform> Ke: this box won't boot the bootloader from sd
<asciilifeform> http://www.loper-os.org/?p=2382 << tried experimentally.
<Ke> and it really makes a huge difference in convenience
<asciilifeform> later somebody here explained that google disabled this feature permanently by shorting the relevant solder balls.
<Ke> I have not bothered to update chromebook fw even once, but mcbin fw is updated like monthly
<asciilifeform> ( chinese rockchip boards will happily bootload from sd )
<Ke> oh, I thought the SD power line was just disconnected until early boot is done
<Ke> yeah, I know
<asciilifeform> aha iirc that was how.
<asciilifeform> at any rate bootloader only loads from the spi rom.
<Ke> yes
JohnDoe_71Rus has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/]
<asciilifeform> i have not yet found how to build a working bootloader from stock uboot, for this machine ( actually whole reason i bought it, was that this is theoretically possible, i am not interested in having the 'press ctrl-D or i format your hdd' prompt, nor interested in having to package kernels with google's signing too, want 'normal' linux box out of it . )
<asciilifeform> *signing tool
<asciilifeform> naively imagined that someone, somewhere would have baked this already, but afaik no dice.
<Ke> well people have various solutions
<asciilifeform> iirc there is a working uboot for c200, but it is very different iron and not compat.
<Ke> I just wrapped the script
<asciilifeform> which script
<Ke> also you could chainload the u-boot on some devices
<Ke> the signing thing
<asciilifeform> chainload does me 0 good, you still get the nag prompt
<asciilifeform> i don't need a box that can't reboot unattended, for anything
<urjaman> shouldnt they eventually boot tho? (after a beep)
<asciilifeform> urjaman: iirc it switches 'out of dev mode' and formats your disk.
<urjaman> nope, not the C201 atleast
<asciilifeform> and the beep is annoying.
<urjaman> it will wait 30 seconds, beep twice, and boot
<asciilifeform> i want the reformat thing 100% gone from my iron.
<urjaman> specifically to allow it to be racked unattended somewhere where nobody can see :P
<urjaman> but yeah i get that it would be annoying ...
<asciilifeform> i also like to stuff my kernels into boot rom and snip off the writeenable pin.
<asciilifeform> hence 'stock uboot' .
<Ke> asciilifeform: I don't even get the beep anymore
<urjaman> "snip off" sounds like something i wouldnt really want to do (not present a valid logic level), but snip from the board and wire to 3.3V i get
<Ke> definitely no formatting
<Ke> or not that I remember
<asciilifeform> urjaman: all the roms i've personally handled had internal pullup
<asciilifeform> Ke: half the appeal of this box, when i thought to buy it, is 'documented iron, can even built bootloader...' but in practice this is not trivial.
<Ke> asciilifeform: I think it is the big thing for everyone
<urjaman> and actually isnt it usually ~WP, so grounding would be the thing to do if you want to protect... anyhows i have stuff to do, bbl
<asciilifeform> Ke: theoretically yes, but seems like nobody's done it just yet.
<asciilifeform> Ke: i intend to try building the vendor's loader src, minus the objectionable parts. but so far not had time.
<asciilifeform> 8MB is plenty big enough for loader + kernel.
<Ke> asciilifeform: btw. do I need any of the partitions on the eMMC
<asciilifeform> ( and will be nice to have kernel load even when the internal ssd wears through )
<Ke> or can I just wipe it and use it as I like
<asciilifeform> Ke: if there were a working open source loader, would not even have to use the emmc
<asciilifeform> could boot straight off sd or usb3.
<asciilifeform> ( google's will boot off externals, but demands key presses )
<Ke> well the kernel boots from SD already, I am just wondering what all the mystery partitions are on the eMMC
<asciilifeform> there's a bunch of rubbish that's used in the reformat/restore feature
<Ke> but I don't brick, if I kill them?
<asciilifeform> and a number of items i haven't been able to make sense of, that their os demands
<asciilifeform> Ke: will only 'brick' in the sense where google's boot rom will not auto-restore to factory state, iirc
<asciilifeform> ( would have to restore manually backed up emmc image )
<Esmil> i haven't changed the bootloader, but I boot from a usb-stick that has the kernel with an initramfs which contains a luks header to unlock the sd card and bootfrom that. so the usb-stick works kind of like the key to my computer
<urjaman> their bootloader will not boot off the eMMC if the partitions have been re-organized too much
<asciilifeform> hm interesting
<asciilifeform> makes sense though
<urjaman> (atleast for C201...)
<Ke> urjaman: what's too much?
<urjaman> i think i tried to make the kernel partition some other number than what it is by default ...
<urjaman> anyways that's part of the verified boot thing, and since there's no signing for the partition table
<asciilifeform> i want the kernel in rom, or at the very least on a standard (e.g. ext3) partition a la ordinary pc, and without the signing rubbish, for mine.
<asciilifeform> but this is personal preference.
<asciilifeform> ( and would rather not use emmc for anything at all, it's soldered down and not replaceable when it gives out )
<Esmil> yeah, that's what I'm thinking, but I wonder if i miss out on some performance by not using it
<asciilifeform> granted the wear was not a problem if you use the box as vendor offered it (i.e. dumb terminal) but for civilized linux, will be problem.
<asciilifeform> Esmil: it is slightly faster than external sd, but i think about on par with the usb3
<Esmil> right
<urjaman> i'm using the C201s by booting them from uSD for my linux and letting chromeos have the eMMC, mostly for reliability (i can always boot something) and also that mainline kernel still doesnt always get the eMMC clock thing right, atleast at first on boot...
<asciilifeform> stuffing kernel in rom would theoretically give the 'always boots'
<asciilifeform> anyway i'ma bbl, gotta go.
<urjaman> well I'm dabbling with the kernel so it would give the inverse effect if i put it in ROM :P, also rootfs ... read-only chromeos in eMMC has been pretty reliable recovery system :P
<Ke> ok, now compiling with the actual patch, hoping to post the fix tomorrow
<Ke> also going to order that cable
<Ke> perhaps get into that fw hacking thing
adjtm has quit [Remote host closed the connection]
adjtm has joined #linux-rockchip
vicencb has joined #linux-rockchip
vicencb has quit [Client Quit]
vicencb has joined #linux-rockchip
vicencb has quit [Client Quit]
vicencb has joined #linux-rockchip
<sphalerite> What I'm doing currently is having a working kernel on the emmc instead of chromeos, but which is configured to boot off the SD card
<sphalerite> and I put the kernels I'm fiddling around with on the SD card
<sphalerite> asciilifeform: what's your opinion on signing a kernel which then chainloads one from a normal partition via kexec?
<asciilifeform> sphalerite: i'd much rather have box like ordinary pc, where 0 google tools and 100% source for everything on the box is rebuildable on same
<asciilifeform> sphalerite: was really the bulk of the appeal, for me, of the c101pa
<asciilifeform> ( vs intel iron )
<sphalerite> depthcharge is 100% from source as well no?
<asciilifeform> theoretically. but i have not yet succeeded in building it, needs entire dedicated box apparently with google's tooling
vagrantc has quit [Quit: leaving]
<adjtm> asciilifeform, I feel the same about the inconveniences of google's depthcharge
<adjtm> but about needing Ctrl+D is only needed if you boot linux from external sd, right? you can install linux on the internal emmc
<asciilifeform> adjtm: i'd be entirely ok with a patched depthcharge that 1) actually builds without any google custom tooling 2) loads straight unsigned kernels off ext3 mbr part or rom
<asciilifeform> adjtm: i'd prefer not to use emmc, it is not replaceable if it gives out
<adjtm> can be removed and solder a new emmc chip :)
<asciilifeform> not worth cost
<asciilifeform> ( reballing isn't free, nor 100% works )
<adjtm> I agree about google signed kernels, press <Space> for factory reset (aka your nephew wiped you laptop)...
<asciilifeform> it's intolerable, imho, even on a toy (not even speaking of a machine where work happens)
<adjtm> in my case (my wife wiped my laptop _and_ her laptop)
<asciilifeform> right, time bomb.
<adjtm> for someone that don't know about this, the reality is: "Google said that I had to do it"
<asciilifeform> adjtm: i bought a coupla c101pa specifically to see if i can get 100% of the googlism, off.
<asciilifeform> ( so far proved difficult )
<asciilifeform> it is cheaper than making a usable lappy from scratch.
<asciilifeform> at least, in theory.
<adjtm> asciilifeform, another advantage of running from sd (in addition to being replaceable) is that after pressing <Space> you only need to revert to dev mode and activating external boot
<adjtm> and not loosing everything of your system
<asciilifeform> i'd rather have a box with 0 'format yer hdd, haha' bomb in it.
<asciilifeform> even if possible to temporarily defuse it with duct tape.
vicencb has quit [Quit: Leaving.]