20:59 <hexdump> hello, i'm currently trying to make a samsung xe303c12 (snow) chromebook useable with linux - so far i have it working well with the latest 3.8 chromeos kernel with everything working, i have as well 4.4, 4.9 and 4.12 mainline kernels working with sound and suspend issues, which seem to be well known and i build u-boot (2016.01 and 2017.07)

21:01 <hexdump> i'm able to boot the 4.x kernels using those u-boots chain loaded and very flexible via extlinux.conf, but when i try to boot the 3.8 kernel (zImage and snow dtb from my chromeos build) i only get a black / blank screen and the machine seems to hang.

21:03 <hexdump> does anyone maybe has an idea what is going wrong here? is it some load address different for the chromeos kernel, is it related to the framebuffer (maybe because its kind of pre-initialized by u-boot), is it somehow related to the compiled format of the kernel? any suggestion is welcome - i would really like to be able to multi-boot the different kernels via u-boot and extlinux menu

21:03 <hexdump> and while i

21:04 <hexdump> am at asking: is there anything known, what are the problems of the non working snow audio and suspend? i.e. in which direction to search when trying to address this?

21:05 <hexdump> a lot of thanks in advance, and please also respond, when i'm offline - i'm reading the irc logs, so will not miss your response

22:00 <LiquidAcid> hexdump, which exynos soc is that?

22:09 <hexdump> 5250

22:10 <LiquidAcid> i remember there being some issues with fimd and iommu on mainline, but i guess your problem is not with mainline?

22:11 <hexdump> no mainline works, just has audio and suspend issues - the 3.8 chromeos kernel gets black with u-boot mainline

22:12 <LiquidAcid> "so far i have it working well with the latest 3.8 chromeos kernel with everything working" <- didn't you say otherwise?

22:14 <hexdump> it works well if its booted the chromeos way, i.e. fit kernel create with vbuild tools, but it does not boot with mainline u-boot

22:14 <LiquidAcid> ah, so you're using different u-boot builds then?

22:15 <LiquidAcid> like vendor u-boot vs. mainline u-boot

22:15 <hexdump> while i'm speaking with you: do you plan to get the changes in your github tree (on which the x2 i'm typing this on is running) back into the mainline tree, so that exynos works out of the box there (i.e. including working hdmi)?

22:16 <LiquidAcid> hdmi should be working in mainline, i have no patches in my tree that would fix anything hdmi related

22:16 <hexdump> no its very special on those chromebooks: they have a vendor u-boot in ro flash and you can fake a self-build mainline u-boot as kernel, which it then boots and you have all the comfort of a contemporary u-boot

22:17 <hexdump> for me with 4.9/4.10 the screen always stayed black (i.e. no signal) on the x2 (and u3 as well), but with your 4.9y tree it works fine

22:18 <LiquidAcid> hmm, that's strange

22:19 <hexdump> does mainline work for you with a monitor on your x2?

22:19 <LiquidAcid> i think the only patches with respect to hdmi are the some timing patches and the timing hacks to enable some more resolutions

22:19 <LiquidAcid> yes, mainline works, panel is a iiyama 1080p

22:19 <hexdump> maybe those are it - my monitor is 1280x1024, so no native hdmi

22:20 <LiquidAcid> well, that might be the reason then, i don't think the current timings in mainline support this mode

22:20 <LiquidAcid> let me check...

22:21 <LiquidAcid> https://github.com/tobiasjakobi/linux-odroid-public/commit/3b154d54d05edc3a3a2859597f89b228b412f15e

22:24 <LiquidAcid> anyway, i would like to upstream more changes to exynos/drm, but it takes months before anything happens from the maintainer side

22:28 <hexdump> thx for the patch - i'll give it a try against mainline with my monitor in the next days ... do you have another link to the discussion, which lead to it as the gmane link given in the github commit does not seem to work anymore?

22:34 <hexdump> ah and another thing i noticed with your kernel: there seems to be some confusion with the console output if the framebuffer and a serial console are used at the same time - as soon as a serial console is defined as well on the kernel cmdline the fb console is no longer the primary output, even if it is the second console argument

22:37 <hexdump> i looked a bit at the code and the only strange reason i could imagine, is that the serial console name on exynos is not the normal ttyS0 but ttySAC1, but i'm not sure if this could be really the cause

22:59 <LiquidAcid> hexdump, here's the corresponding commit from the 4.13.y branch, i have updated the links since then: https://github.com/tobiasjakobi/linux-odroid-public/commit/fca05ad12f0b625580b822236f48472e12f24422

23:01 <LiquidAcid> hexdump, by primary output you mean that kernel messages don't appear on it?