<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
<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 :)
<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