Tenkawa has joined #linux-exynos
Tenkawa has quit [Changing host]
Tenkawa has joined #linux-exynos
<Tenkawa> greetings all
<Wizzup> Tenkawa: Did you see what javier__ wrote?
<Tenkawa> no
<Wizzup> check the logs :)
<Tenkawa> did i miss something obvious?
<Wizzup> He suggested a patch that might fix your issue
<Tenkawa> Oh...
<Tenkawa> ok.. will do
<Tenkawa> thank you
<Wizzup> welcome. it's about time I go to bed now.
<Tenkawa> javier__: and thank you
<Tenkawa> cheers
<Tenkawa> hmm...
<Tenkawa> I cant find the patch link though
nashpa has quit [Ping timeout: 250 seconds]
<Wizzup> 22:25 < javier__> if someone has issues booting a Snow or Peach Pit (basically a Chromebook with a eDP to LVDS panel bridge)
<Wizzup> 22:25 < javier__> can please test this patch? http://hastebin.com/kemubijaxo.md
<Wizzup> 22:26 < javier__> I believe that's the issue that was reported yesterday but that user is not online and I don't have a Snow to test the patch
<Tenkawa> yeah I tried loading that url and get a blank page
<Tenkawa> let me curl it
<Tenkawa> ahhh
<Tenkawa> thanks.. got it :)
<Tenkawa> time to setup a compile
<Tenkawa> heheheh
nashpa has joined #linux-exynos
nashpa has quit [Ping timeout: 240 seconds]
nashpa has joined #linux-exynos
<Tenkawa> ok time to test
nashpa_ has joined #linux-exynos
nashpa has quit [Ping timeout: 264 seconds]
nashpa has joined #linux-exynos
nashpa_ has quit [Ping timeout: 264 seconds]
nashpa has quit [Ping timeout: 264 seconds]
nashpa has joined #linux-exynos
<javier__> Tenkawa: please let me know if that fix your issue
nashpa has quit [Ping timeout: 250 seconds]
nashpa has joined #linux-exynos
nashpa has quit [Ping timeout: 264 seconds]
nashpa has joined #linux-exynos
zombah has quit [Quit: Leaving]
nashpa has quit [Ping timeout: 264 seconds]
nashpa has joined #linux-exynos
nashpa has quit [Client Quit]
<javier__> Tenkawa: did you test?
nashpa has joined #linux-exynos
nashpa has quit [Quit: Going away]
TheSeven has quit [Ping timeout: 250 seconds]
TheSeven has joined #linux-exynos
amitk has joined #linux-exynos
afaerber has quit [Quit: Ex-Chat]
zombah has joined #linux-exynos
Tenkawa has quit [Quit: leaving]
nashpa has joined #linux-exynos
Tenkawa has joined #linux-exynos
<Tenkawa> javier__: hey.. which kernel should that patch go against and which dtb should I copy when compiled?
<javier__> Tenkawa: v4.5-rc1 and use the snow dtb
<Tenkawa> hmm.. thats just a drm patch ot a dtb.. nm
<Tenkawa> ok..
<Tenkawa> let me give it another try
<Tenkawa> ok.. here we go...brb
Tenkawa has quit [Quit: leaving]
Tenkawa has joined #linux-exynos
<Tenkawa> javier__: success!!!!! thank you very much
<Tenkawa> so what was the cause in the end ?
<javier__> Tenkawa: cool that it worked, I also ran an automated test to confirm (thanks sjoerd!) but is nice to double check that you have actual display since I can only check that a DRM device was created
<Tenkawa> yeah its working great
<Tenkawa> this is awesome
<javier__> Tenkawa: the problem was that Inki introduced a bug when changing the logic to lookup what was connected to the DP (i.e: panel or bridge)
<Tenkawa> this is my main desktop/workstation so I like being able to keep it up to date
<Tenkawa> and this is great
<javier__> Tenkawa: cool
<Wizzup> :)
<Tenkawa> thanks to all of you. Hopefully I can help out at some point
<Tenkawa> I am determined to stay dedicated to working with ARM and MIPS now... I'm done with x86 for a while
<daniels> javier__: lava \o/
<javier__> daniels: yeah, I had forgotten how awesome this was :)
<daniels> javier__: mind you, https://git.collabora.com/cgit/user/daniels/lava-tests-gfx.git/tree/ is a good test to make sure everything actually has the display nodes it should (e.g. panel of specific resolution) :P
<javier__> daniels: cool, I thought that were already at https://git.collabora.com/cgit/singularity/qa/test-definitions.git :P
* javier__ runs
<Tenkawa> question for you samsung versed ones...
* daniels coughs
<Tenkawa> is the CB2 Octa a lot moere powerful?
<daniels> javier__: someone else was meant to do that, but never quite got htat far
<daniels> javier__: so i'm blaming them
<Tenkawa> or should I be fine using this box
<javier__> daniels: but seriously, I forgot about your test and wrote this naive one http://139.162.213.123/lava/testdrm.yaml
<javier__> yes, I had to setup a linode vps so lava could get my image, dtb and test definition
<daniels> javier__: i accept patches to add snow support :)
<Tenkawa> I've actually beem very happy with the snow hardware
<Wizzup> Tenkawa: peach-pi is faster than snow
<Wizzup> cpu wise for sure
<javier__> daniels: hehe, I should do that indeed
<Wizzup> graphics wise, without any accel, it's both just "meh"
<javier__> specially since I don't have access to a snow anymore
<Tenkawa> yeah however is it overall that much better of a box?
<daniels> Tenkawa: peach-pi has a _much_ better display as well
<Tenkawa> ahhhh
<sjoerd> overall build quality from the peach-pi seems a lot nicer tbh
<Tenkawa> I might try to pick up one. I want the 11.6" so it takes a little more to find around here
<sjoerd> that's the pit isn't it
<Tenkawa> brb... need to reapply some of the config settings i took out testing before
Tenkawa has quit [Quit: leaving]
<Wizzup> the smaller one is peach-pit
<daniels> yeah, peach-pit has the same display (1366x768 on lvds, vs. 1080p on edp)
<daniels> *same display as snow
Vasco_O is now known as Vasco
<sjoerd> it also seems a tad less loved upstream, but that might just be my perception
<daniels> sjoerd: never did get the one in cbg working
<javier__> sjoerd: it might be that I've a peach pi and not a pit :P
<javier__> but seriously, the Exynos5420 had some issues too that were fixed in Exynos5422/5800
Tenkawa has joined #linux-exynos
<Tenkawa> now to figure out what to tweak next :)
<javier__> now, I didn't notice any issues with Peach Pit in mainline at the time I had access to the Pit and worked in upstreaming
* Tenkawa backs up the setup to a bootable sd card now :)
<Tenkawa> yay
<sjoerd> javier__ah cool
<Wizzup> Tenkawa: 15:31 < Wizzup> the smaller one is peach-pit
<Tenkawa> smaller which?
<Tenkawa> arent all of the chromebook 2's peachpit?
<Wizzup> no
<Wizzup> peach-pi and peach-pit are different
<Wizzup> see our wiki
<Tenkawa> oh
<Tenkawa> link?
<Tenkawa> is it the second link in the topic?
<Wizzup> well... that's working out well :)
<Tenkawa> ahhh theres 2 cb2 core machines i see
<Tenkawa> yeah personally I'd be much more interested in the smaller unit
<Wizzup> it has a different exynos in there
<Wizzup> again, see what javier said in the logs
<Tenkawa> ok
<Tenkawa> nice though now the only workaround I need is my external usb sound card
<Tenkawa> x works well
<indy> hi all, is there way to update u-boot, when flashed to spi winbond chip?
<indy> seems that on https://wiki.archlinux.org/index.php/Samsung_Chromebook_%28ARM%29#How_to_flash_U-Boot how to compile uboot is still wip and no update
<Tenkawa> brb..
Tenkawa has quit [Quit: leaving]
<zombah> indy: you can compile newer version of this u-boot from chromium sources yourself
<indy> zombah, are we both talking about nv_image-snow.bin ?
<zombah> indy: yep
<javier__> indy: mainline u-boot also has snow support so no need to use vendor trees
<zombah> javier__: sure if you dont need chromeos anymore 8)
Tenkawa has joined #linux-exynos
<Tenkawa> now my backup is complete and boots properly :)
<indy> javier__, but i think nv_image-snow.bin has different structure compared to u-boot.bin build from upstream u-boot
<javier__> indy: what do you mean by structure?
<indy> yes, for flashing to spi
<indy> javier__, i mean u-boot.bin resides at some place in nv_image-snow.bin
<Tenkawa> interesting that my firmware lists itself as DAISY
<Tenkawa> hardware id rather
<Tenkawa> firmware does list as snow
<zombah> indy: both need to be packed with vboot_util to be suitable for flashing
<javier__> indy: I woldn't have thought that the image were different, I thought the only difference was that the vendor one had verified boot and supported the GTP extensions used by ChromeOS
<javier__> but is true that you can't use only mainline if you care about ChromeOS
<javier__> although I thought people that flashed a custom u-boot in SPI didn't care about that, otherwise I don't see why people wouldn't just chain load u-boot
<zombah> i also dont know what this newer version on downstream u-boot is for, maybe there were some reason why arch guys made it
<indy> i don't care about chromeos but with that archaic nv_image-snow.bin i can boot only prehistoric 3.4 kernel and with that current fedora doesn't work at all
<javier__> indy: but you were the one that brought ChromeOS when I suggested mainline u-boot :)
<javier__> ah, no sorry it was zombah
<javier__> hence my confusion
<zombah> 8) i made my suggestion after checking archlinux page
<indy> few months ago i tracked down all utils needed for dumping nv_uboot-snow.bin regions but it is lost somewhere in 1tb backup of previous laptop :/
<zombah> indy: you mean utils to create custom bootloader image?
* Tenkawa just continues to yse vbutil_kernel and mkimage
<Tenkawa> one script and done
<indy> zombah, no dump regions of image used for flashing nv_ubot-snow.bin
<indy> zombah, and how differs nv_uboot-snow.bin from archlinux compared to what is provided by google for fw update
<indy> zombah, my idea was to create distro agnostic work flow for update of uboot on chroomebook
<zombah> indy: i think archlinux one compiled from newer downstream sources, that only difference i noticed
<zombah> indy: arch use downstream kernel and fedora/suse use mainline, so you cant be that agnostic on snow yet
<indy> zombah, i can if i figure out how to update only exynos uboot part even with dd :)
<Tenkawa> indy: i thought you just use a straight dd and cgpt
<zombah> indy: there is crypto checksum, you cant update it with dd
<indy> zombah, problem is that nv_uboot-snow.bin contains also code for embedded controller which is some cortex-m0/3/4
<Tenkawa> zombah: cant you turn the crypto requirement off
<Tenkawa> or did they change that after snow?
<javier__> zombah, Tenkawa: you can if you disable the write protection for the SPI and flash u-boot there
<javier__> but risk to brick the device
<Tenkawa> ahh yess... that
<Tenkawa> thats why I'm just content with mkimage and vboot
<Tenkawa> it works fine for me
<indy> zombah, with servo board it should be easy
<javier__> indy: I think the best distro agnostic thing is to chain load a mainline u-boot since that support u-boot distro commands
<Tenkawa> javier__: this new kernel feels a lot snappier btw
<javier__> you just need to provide a Boot loader spec config file in a bootable media partition
<zombah> javier__: i can get rid of vboot stuff without write protection? that great i have protection disabled but still use vboot util to pack u-boot
<Tenkawa> whats so bad about vboot?
<zombah> Tenkawa: nothing, its chromeos dependency
<Tenkawa> zombah: I use it for my linux install just fine
<javier__> zombah: no, you can't get rid without write protection. By chain loading u-boot I meant to boot a signed u-boot
<Tenkawa> works great in debian
<zombah> chain load works fine with write protection and without, but flashing mainline u-boot into spi is other question
<Tenkawa> brb
Tenkawa has quit [Quit: leaving]
<javier__> zombah: nod, that's why I said that chain loading is the best option IMHO
<zombah> javier__: yes i know, i think same and i use it.
Tenkawa has joined #linux-exynos
<zombah> javier__: i just wondering how to put mainline u-boot into spi without vboot, if i understand you right
<Tenkawa> out of curiosity... is the mmc driver in the snow board not capablw of trim or is it a driver problem?
<Tenkawa> cant trim/discard the filesystem
<Tenkawa> er s/capablw/capable
<javier__> zombah: AFAIU you can if you disable write protection and write to the SPI flash
<javier__> since the vboot is in u-boot and not in the SPL
<Tenkawa> yes you can.. with hardware adjustment
<zombah> javier__: i see, i will try
<Tenkawa> however i've read its very touchy/risky
<javier__> zombah: but you risk to brick your device
<javier__> that's why I never tried :)
<Tenkawa> same here
<zombah> javier__: i can always reflash eeprom itself externaly from backup
<Tenkawa> I like this machine and dont want to risk breaking it since its not easy to find one of these anymore
<javier__> zombah: yeah, I guess is doable with a SPI bus pirate or something like that
<Tenkawa> zombah: its physically risky I've read
<Tenkawa> zombah: I think theysaid you can break the circuit
<javier__> but I don't have equipment here to do that
<Tenkawa> its very fragile
<zombah> javier__: yes, i already did that one time, with raspberry pi
<Tenkawa> the risky part is the write protect physical piece... not software
<Tenkawa> at least from what I read
<javier__> Tenkawa: it's just a screw
<javier__> so there isn't really risk in disabling that
<Tenkawa> javier__: yes... what I saw is that the screw can grab and pull part of the board apart
<Tenkawa> who knows if thats accurate though
<Tenkawa> I'm content as is hehehehe
<Tenkawa> now that you guys gave me a fix for the display I'm back in action to start a lot of stuff with this box again
<sjoerd> Tenkawa: i've removed the screws on both peach and snows before, it doesn't seem very risky
<sjoerd> the risky part is playing with the flash and screwing it up :)
<Tenkawa> I'm probably going to try to track down a spare unit just in case I need one
<sjoerd> (that said i also soldered serial cables on the boards, so maybe i'm not the right person to ask what's safe...)
<Tenkawa> sjoerd: true enough... I can't say I've tried.. just going by what I read
<Tenkawa> sjoerd: yeah I'm very bad at soldering (only can use one hand though)
<Tenkawa> I dont use those solder holders well
<javier__> Tenkawa: what sjoerd said
<Tenkawa> I've been lucky that I've never had a flash procedure go wrong in all these years
<Tenkawa> yay
* javier__ => lunch, bbl
<Tenkawa> yeah its almost that time here too
<zombah> the soldering pads inside snow is realy small, ive asked my local soldering guru to make console inside snow for me
<Tenkawa> ah
<Tenkawa> wow the internal nic really feels snappier now
<Tenkawa> getting much better throughput
<Tenkawa> less latency
<Tenkawa> bbiaf
Tenkawa has quit [Quit: leaving]
Tenkawa has joined #linux-exynos
<Tenkawa> so much better :)
<Tenkawa> heehee
Tenkawa has quit [Quit: leaving]
Tenkawa has joined #linux-exynos
Tenkawa has quit [Remote host closed the connection]
Tenkawa has joined #linux-exynos
dlezcano has quit [Ping timeout: 240 seconds]
Tenkawa has quit [Quit: leaving]
dlezcano has joined #linux-exynos
LiquidAcid has joined #linux-exynos
Tenkawa has joined #linux-exynos
<Tenkawa> well the chromebook is running the new kernel well
<Tenkawa> too bad no internal sound yet
Tenkawa has quit [Quit: leaving]
Tenkawa has joined #linux-exynos
Tenkawa has quit [Quit: leaving]