06:59 <javier__> obbrobbrio: awesome, I didn't know that!

09:15 <obbrobbrio> what i also find weird is that there is no acpi subsystem, but acpi_listen show power button and lid events, and on the other hand systemd is not able to detect/handle them, so in the end i'm still using acpid to run lid actions

10:59 <noob> hello

11:04 <Wizzup> hi

11:04 <Guest74246> h

11:04 <Guest74246> i

11:05 <Guest74246> anyone know where i can take my phone to get IMEI repaired?

16:33 <bmbeach> hello I'm trying to boot kernel-next20150216 and what I get is the screen going black and then a reboot

16:33 <Wizzup> What device, what u-boot

16:35 <bmbeach> snow nv_uboot-snow-simplefb

16:35 <Wizzup> simplefb should be disable in kernel and also use the non-simplefb u-boot

16:35 <Wizzup> but a reboot likely means something else is wrong -- like kernel not being loaded properly

16:36 <bmbeach> yes I was thinking about these 3 things. If I use the DTS from 3.17.8 I do get a boot

16:37 <Wizzup> that sounds like a bad idea, mixing dts

16:37 <Wizzup> I always append the dtb

16:38 <bmbeach> yes but anything is better than a totally blank screen. When you say append are you refering to a so call Fit thing?

16:39 <Wizzup> cat zImage dtb > zImage_dtb ; and then mkimage

16:39 <Wizzup> http://linux-exynos.org/wiki/Samsung_Chromebook_2_XE503C12/Mainline_Linux_Kernel this guide is not for snow

16:39 <Wizzup> but may still be helpfl

16:41 <bmbeach> Okay I'll try everything. I've seen the web page many times. What I had in mind for the DTS what to diff dts-3.17 and dts-next

16:41 <Wizzup> I booted linux-next on my snow a few days ago with succes

16:42 <Wizzup> javier__: did you figure out why the firmware loading for broken?

16:43 <bmbeach> Okay what is different about you'r system and mine? Is it the same for javier? (i.e) his system is also booting out of the box?

16:45 <Wizzup> the page I linked is pretty much exactly what I do

16:46 <bmbeach> what about you'r command line?

16:46 <Wizzup> and then in u-boot ext2load mmc 0:2 ${loadaddr} uImage ; setenv bootargs 'console=tty1 debug earlyprint' ; bootm ${loadaddr}

16:46 <Wizzup> ^

16:46 <Wizzup> earlyprintk*

16:46 <Wizzup> (btw I am just writing down what I remember, may have typos)

16:48 <bmbeach> I wonder if the fb stuff that I'm using on the command line and loader is causing the crash. You are using nv_uboot-snow for booting?

16:49 <Wizzup> I use nv-uboot, yes

16:50 <bmbeach> actually I'm booting off the USB.

16:50 <Wizzup> usb should work fine too

16:51 <bmbeach> yeah, but I wonder. I know that it is incredibly slow.

16:55 <bmbeach> i'm going to try your cat zImage dtb > zImage_ .... Maybe the DTB is getting overwritten the way I am doing it.

16:56 <Wizzup> yep; look at the wiki page

16:56 <Wizzup> it has working instructions

16:56 <bmbeach> Okay thanks I try it and get back to you

17:10 <obbrobbrio> Wizzup: what's the advantage in using nv u-boot? i guess i'm not using it, shoul i?

17:10 <obbrobbrio> *should

17:16 <si1v3r_> It's tweakable at boot time.

17:16 <si1v3r_> That's the biggest advantage.

17:18 <obbrobbrio> si1v3r_: such as which device to boot from etc.?

17:18 <si1v3r_> yeah and kernel options.

17:21 <obbrobbrio> oh ok indeed, it was a bit annoying when i had to generate again the kernel blob and dd it just to disable verbose and debug output...

17:33 <si1v3r_> I had to change my mount options on the kernel line too. slackware wants root to be ro when it finds it.

17:46 <obbrobbrio> so if the kernel loading is under nv-uboot control there is no longer need for a signed kernel?

17:50 <javier__> Wizzup: no, I'll go back to the wifi later. Now I'm trying to get sound working on Snow

17:50 <javier__> obbrobbrio: exactly, since nv-uboot is actually a signed FIT image but containing u-boot instead of a kernel

17:52 <obbrobbrio> javier__: nice, so one can dd the signed nv-uboot once for all, and play with the kernel as he likes without signign over and over again

17:53 <obbrobbrio> i think i'm going for this setup too

18:06 <javier__> obbrobbrio: yes, that's what I do on my chromebooks as well

18:06 <javier__> it allows me to test kernels easily by loading them over tftp for example

18:10 <obbrobbrio> chromebooks... how many do you have? :)

18:12 <daniels> more than is traditionally considered healthy

18:13 <obbrobbrio> lol

18:19 <javier__> obbrobbrio: what daniels said :)

18:20 <obbrobbrio> eheh i trust him

18:23 <afaerber> javier__, completely disabling the exynos iommu does fix my boot problem. I'm facing a non-backlit screen again now

18:30 <javier__> afaerber: cool, I had the same issue on today's next and posted https://lkml.org/lkml/2015/2/17/163 to disable it on exynos_defconfig

18:30 <afaerber> javier__, yeah, I saw your patch and that led to this feedback, thanks a lot!

18:31 <javier__> afaerber: great

18:31 <afaerber> javier__, are you close to one of your exynos Chromebooks?

18:31 <liquidAcid> javier__, you should add to the commit description that it only happens on specific models

18:31 <liquidAcid> javier__, e.g. it works properly on exynos4412 based hw

18:32 <daniels> liquidAcid: it's not specific models, it's specific configurations

18:32 <javier__> afaerber: yes, I'm

18:32 <javier__> how can I help you?

18:32 <daniels> liquidAcid: iirc in this particular case it was that the bootloader leaves the display enabled, scanning out of a buffer it's allocated

18:32 <daniels> liquidAcid: so when it flicks on the iommu with an empty page table - bang

18:32 <afaerber> javier__, do you see "exynos-dp 145b0000.dp-controller: unable to config video"?

18:32 <liquidAcid> daniels, i understand that

18:32 <afaerber> (address might differ obviously)

18:33 <liquidAcid> daniels, but it's still a problem specific to your model/setup

18:38 <javier__> liquidAcid: yes, I forgot to add in the commit msg on which machines I had this error as pointed out by Krzysztof already

18:38 <javier__> I usually do...

18:39 <javier__> afaerber: no, I don't have that error message

18:47 <javier__> afaerber: I guess is related to the fact that spring dp node has not been converted to the new dp video port / endpoints binding?

18:54 <afaerber> javier__, I do have a patch adding them, maybe something is wrong there...

18:57 <afaerber> https://github.com/afaerber/linux/commits/spring-test

18:58 <afaerber> (just updated from next-20150213, still compiling)

19:06 <javier__> afaerber: yeah, your patch looks good to me

19:06 <afaerber> it used to work with an earlier version of Ajay's series

19:09 <javier__> hrmm, the only difference I see is that snow defines the fet regulators that are power supplies for the panel and backlight but spring doesn't have the tps65090 pmu because is not in mainline due the special i2c support in the cros_ec

19:09 <javier__> but that shouldn't be an issue since your bootloader enables those regulators right?

19:10 <afaerber> well, it worked around 20141124 plus patches, and I haven't changed the bootloader

19:10 <javier__> afaerber: right, I have no idea what could be the issue then, sorry...