<javier__>
si1v3r, Wizzup: yes, rc6 + disabling CONFIG_EXYNOS_IOMMU was enought for me to have display working on the peach pit/pi
<javier__>
*enough
<javier__>
si1v3r, Wizzup: can you share your boot log?
<steev>
javier__: can you share your kernel config?
<javier__>
steev: is just exynos_defconfig + CONFIG_EXYNOS_IOMMU disabled
<steev>
javier__: alrighty, i'll give it a shot
<sjoerd>
javier__: is this properly fixed in -rc7 ooi ?
<javier__>
sjoerd: no, I pinged kukjin several times and never sent it as a -rc fix but as a patch for 4.1
<sjoerd>
ah well
<javier__>
so I mentioned that he did that and told me that now that he sent it as 4.1 it couldn't be a -rc fix so will send it as a stable fix :-/
<sjoerd>
heh
<sjoerd>
that's very weird rationale
<javier__>
yeah but at that point I just got tired of arguing and give up
<sjoerd>
sure
<Wizzup>
stupid question: how do I get you a boot log without having a working screen / being able to log in? Are there kernel options to write it to a certain place? network seems a bit hard since there is only wifi
<steev>
Wizzup: install syslog-ng, boot... take sdcard out?
<steev>
well, power off, and then take it out, but still
<Wizzup>
right, if it manages to boot
<Wizzup>
I have metalog installed so I can try to check.
<steev>
sure, but if it doesn't, you'll see
<Wizzup>
ack
<steev>
because the logs won't grow :P
<steev>
this image build needs ot hurry up
<Wizzup>
hehe
<javier__>
Wizzup: well I was thinking of network, I have an USB eth dongle for example
<steev>
it takes ~40 minutes to run, and that's on a very fast ssd :/
<steev>
stupid qemu being slow as molasses :(
<Wizzup>
I compile from arm devices typically
<sjoerd>
heh if one thing is easy to cross-build it's the kernel
<steev>
if i ever got some free time to get my mustang boards up and running (and if debian would fix their damned arm64 docs to build)
<javier__>
Wizzup: you can also try to log in blindly and running dmesg > log
<steev>
it's been broken for literally months
<javier__>
I'm building a -rc7 kernel now just to be sure but -rc6 worked for me for sure
<steev>
javier__: sure... except you don't know how long it takes to boot :P
<sjoerd>
turn on persistend logging in journald and be done ? :)
<steev>
can you read those logs on another machine?
<steev>
but *shrug* everyone else seems to think it's awesome. couldn't possibly learn from the mistakes of window's binary logger
<javier__>
steev: nod
<javier__>
steev: about the 5 seconds, not journalctl :)
<steev>
that said, image compressing
<steev>
javier__: i figured :P
<steev>
i don't expect others to share my hatred of systemd :)
* javier__
actually likes systemd a lot
<steev>
i like the idea behind it
<steev>
the developers and implementation leave a lot to be desired
<steev>
i refuse to touch it, until i'm forced to (soon), based on an interaction with a developer who was extremely racist and sexist in their irc channel - and yes, he's a core dev and contributor
<sjoerd>
If you look at the implementation details of the journald binary format and the rationale behind it, it is actaully awesome
<steev>
no.
<Wizzup>
too bad they will not fix the corruption issues
<javier__>
steev, Wizzup: sorry are you booting a peach pit or peach pi?
<steev>
javier__: pi
<Wizzup>
javier__: peach-pi
<steev>
the 13"
<steev>
i don't have the 11" (yet)
<steev>
i need to ask my boss to ship me one
<steev>
"i need dis <url> ship to me plz"
<steev>
javier__: although supposedly my image should work with both (which is kinda why i need to get a pit, so i can test that it actually does)
<steev>
ugh
<steev>
can we please turn off the legacy bsd pty support?
<steev>
no one needs that shit anymore
<Wizzup>
hehe
* Wizzup
will probably test with his snow in a bit
<steev>
all it does is litter /dev
<Wizzup>
peach-pi is main working machine, so it's a bit hard to test with it when working
<sjoerd>
Wizzup: and you think text files handle corruptions? The core thing is being able to still retreive data after a corruption happened which you can do with both text and journald's format
<steev>
Wizzup: use an sdcard to test bruh
<Wizzup>
steev: right, I have a few, but it still requires a reboot of my current working machine ;)
<steev>
true
<javier__>
Wizzup: snow is not going to work since is missing the DTS bits for the drm bridge
<javier__>
linux-next should though
<steev>
dat snow
<javier__>
steev: supporting both peach pi and pit is possible, you only need different u-boot and load the correct fdt
<Wizzup>
javier__: ack
<javier__>
steev: yes, I mentioned because Wizzup said that he will test it on snow
<javier__>
-rc7 finish to build, let me boot that on peach pit and pi
<Wizzup>
I also made testing a bit troublesome for myself by having an encrypted rootfs
<Wizzup>
wait, I should just put something on the sd card ... hurrr :)
<javier__>
Wizzup, steev: ok I booted -rc7 on my peach pi and the display is indeed off
<javier__>
Wizzup: btw, I don't have a serial console on my peach so I got that log by blindly typing my user and pass
<Wizzup>
ah...
<javier__>
I think what is the issue though
<javier__>
*think I know
<Wizzup>
:)
<steev>
dat recursive fault
<steev>
javier__: also, ugh, so rc6 works, rc7 is broke?
<Wizzup>
I had similar problems with rc6
<Wizzup>
but cannot say it's the same problem necessarily
<steev>
well i'll give this a whirl, worst case i don't get display either
<steev>
and then i go crash, i've been up for almost 24 hours
<steev>
and i did a whole lot of driving today
<steev>
one of my best friends lives about an hour away (well okay it's an hour and a half, but with the way i drive it's about 45-50 minutes), so i drove up there, hung out, came back down to go to dinner, and then went back up to hang some more, and then finally came home, and saw the channel was lively
<Wizzup>
:)
<Wizzup>
as soon as I get a config to work on my peach pi I will update the wiki with instructions, perhaps a working image
<steev>
and tegra in mainline is also a bit of a mess wrt display so i figured if display was working on peach....
<javier__>
Wizzup, steev: we have found a lot of issues between the interactions of the FIMD, MIXER and HDMI modules, power domain, async-bridge and peripherals clocks, etc
<Wizzup>
It would be good to just say: Try 4.0
<javier__>
for both exynos5420 and exynos5250, all that is fixed in linux-next
<Wizzup>
ah
<steev>
javier__: what about 5800? :P
<Wizzup>
I think 5420 is the 5800
<Wizzup>
isn't it?
<Wizzup>
Some silly rebranding
<steev>
Wizzup: i dunno, peach-pit is listed as 5420, peach pi is listed as 5800 *shrug*
<steev>
maybe 5800 because 8 cores?
<Wizzup>
ah, wait
<Wizzup>
you're right
<javier__>
Wizzup: when I say 5420 I meant 5420/5422/5800 unless I make a distinction :)
<javier__>
5422 is a fixup or 5420 and it seems 5800 is a fixup of 5422 unless that difference is less clear
<javier__>
anyway, now I was not able to reproduce the issue anymore on 10 boots
<steev>
so no display the first time, but display after?
<javier__>
with exynos_defconfig + iommu disable on -rc7 I've the display working
<javier__>
steev: exactly
<steev>
okay well if i don't get display, i'll try rebooting :)
<javier__>
so it seems related to what I say about that not all the clocks were defined for the power domains
<steev>
Wizzup: oh, that reminds me... something funky is happening here with the u-boot and all that - i figured out what, not sure the best way to go about fixing - it doesn't generate the root= line properly - i pass it one, but when regen_all runs, it generates it's own
<javier__>
I'll wait for 4.1 since both the LCD and HDMI has been fixed for snow and peach there
<steev>
again, and overrides mine :/
<Wizzup>
Does linux-next have a lot of extra commits compared to 4.0-rc7? If you can list them, if it not a lot of work, I prefer doing 4.0+patches probably
<steev>
javier__: maybe i'll give linux-next a shot on peach then
<steev>
Wizzup: yes, it has tons of them
<javier__>
Wizzup: it does but I don't have time to dig which ones are needed tbh
<steev>
Wizzup: there's a lot there that isn't really.... needed
<Wizzup>
yep.
<javier__>
Wizzup: linux-next has other sort of problems since is an integration tree and things keep breaking on other subsystems
<javier__>
but I hope that 4.1 will be the first kernel where everything just works (tm) for exynos chromebooks
<Wizzup>
ah, I see...
<steev>
javier__: i got display on first boot :)
<Wizzup>
!
<sjoerd>
Wizzup: those load addresses are wrong for peach boards btw
<Wizzup>
so it may be good to postpone some tests for a week and then test 4.1-rc1
<javier__>
4.0 is a lost cause anyways since the DTS bits for snow and peach pit didn't made and the only supported chromebook (peach pi) does not work due the exynos iommu issue
<Wizzup>
sjoerd: yes, I think so too
<javier__>
steev: cool
<Wizzup>
I alot of this was written when we only had a snow I think
<sjoerd>
but then again none of what's document there shouod be used with an upstream u-boot
twitch153 has joined #linux-exynos
<javier__>
steev: now I wonder if I made a mistake on my first kernel built or what since I'm not able to reproduce the blank display anymore with -rc7
<steev>
javier__: disclaimer: i'm using the cros u-boot
<steev>
and doing the old vbutil_kernel line
<Wizzup>
sjoerd: I'll add that remark
<javier__>
steev: I see, I'm using chain nv-u-boot loading using mainline u-boot
<steev>
i will at some point revisit, but at the moment, i'm doing release engineering, so..... can't really focus on the brokenness. this is my "free time" after
<javier__>
but anyway, since to be working well. What a pity that kukjin didn't push the iommu disable patch for the -rc cycle
<steev>
might try again on thursday
<steev>
javier__: so. uh, wifi......
<steev>
still broken?
<steev>
or just need to enable the mwifiex stuff
<Wizzup>
Enable, is one
<Wizzup>
and you may need the userspace helper fallback for loading fw
<steev>
will see, i'll try building image with it enabled first
<javier__>
steev: no, the WiFi DTS bits are not in 4.0 either
<steev>
oh
<steev>
well blah
<Wizzup>
ah
<steev>
javier__: 4.1? 4.3?
<steev>
2*
<javier__>
steev: 4.1
<Wizzup>
09:45 < javier__> but I hope that 4.1 will be the first kernel where everything just works (tm) for exynos chromebooks
<steev>
cool, i'll give linux-next a go
<Wizzup>
:)
<steev>
javier__: so with -next, no need to disable IOMMU?
<javier__>
steev: no, that is already there
<javier__>
steev: when I tried WiFi a couple of weeks ago on linux-next I had to revert https://lkml.org/lkml/2015/1/12/503 and enable CONFIG_FW_LOADER_USER_HELPER_FALLBACK though
<javier__>
since the in-kernel fw loader was not working, have to check if both issues were solved now...
<steev>
i'll give it a go
<javier__>
ok
<steev>
well, i'll give a whirl as in, kick off the build, won't test til tomorrow morning... or after noon.... it's 3am here
<steev>
except it's gonna sit because i attempt to patch the mwifiex and that's already applied and my script is very brittle, heh
<daniels>
javier__: fwiw, android trees i've found refer to the 5422 as 5422 r1.0, and 5800 as 5422 r1.1
<daniels>
javier__: the only substantial difference i've seen is a slightly different pll configuration, but whether that's actually hw, or just google working out different values, i have no idea
<sjoerd>
daniels: When i prodded into the chipid stuff on Samsung Soc they were exactly the same on xu3 and peach pi btw
<sjoerd>
with no indication of being different revisions
<sjoerd>
There is a fun issue in u-boot atm where it will work out the xu3's fdt file with the wrong naming as it asumed the 0x5422 chipid meand exynos5800.... </random thought that came up in my mind>
* sjoerd
hopes to get round to patching u-boot to get the linux fdt name out of the u-boot fdt instead of trying to generating it based on chip/board id's
<daniels>
sjoerd: hrm, fun - what about if you compare the entirety of S5P_VA_CPUID (i.e. s5p_cpu_id + s5p_cpu_rev) rather than just the id itself?
<sjoerd>
same iirc
<sjoerd>
I'll recheck it again at some point
<steev>
javier__: vdd_1v8: operation not permitted
<daniels>
sjoerd: sigh
<steev>
not allowed*
<steev>
anyway, off to bed now
<sjoerd>
daniels: But i'd prefer it if the boards dt file in u-boot just has a u-boot,linux-fdt = "exynos5422-odroidxu3" so all the heuristics can just go away unless you do have one dtb that supports multiple boards (like in the odroid x2/u2 case)
<javier__>
steev: I thought you were already sleeping :)
<javier__>
steev: I had to do this on today's -next: 02349bb7287e Revert "regulator: Defer lookup of supply to regulator_get"
<javier__>
had the same issue
<daniels>
sjoerd: right - and for the 5800 case, you'll always need a separate image anyway since they were only ever in chromebooks, and they have a different loadaddr, right?
<daniels>
sjoerd: (unless you replace spl)
<sjoerd>
daniels: well the dtb are quite different on the various exynos5 boards as they're not hooked up in 99% the same way ;)
<sjoerd>
daniels: You also need one image per board if you need a different dtb in uboot for now
<sjoerd>
daniels: the load address are different because the dram physical base id different afaui so probably unrelated to the SPL (but i really don't know enough about that part of the hardware)
<daniels>
sjoerd: nod
steev has quit [Ping timeout: 256 seconds]
steev has joined #linux-exynos
Dhole has joined #linux-exynos
Dhole_ has quit [Ping timeout: 256 seconds]
zombah has joined #linux-exynos
afaerber has joined #linux-exynos
<si1v3r>
linux-next 20150407 said it was rc7, and it lights up the display again with only exynos_defconfig. it gets stuck in a loop doing something with the wifi though.