D1337d has joined #linux-exynos
* D1337d is just going through the irc logs now
<D1337d> but apart fromt he devices not working on syspend, whats broken in 4.1?
<javier__> D1337d: that has been already fixed
<javier__> it didn't make it to 4.1 though
<D1337d> well if its in linux next and that version compiles i am more than happy
<D1337d> so wifi no loger blocks suspend then?
<javier__> D1337d: no, that has been fixed too
<javier__> D1337d: linux-next compiles but may be safer for you to cherry-pick those on top of 4.1
<javier__> since always a release is more stable
amitk has joined #linux-exynos
D1337d has quit [Quit: leaving]
dlan_ has quit [Ping timeout: 276 seconds]
dlan has joined #linux-exynos
dlan has quit [Read error: Connection reset by peer]
dlan has joined #linux-exynos
zombah has joined #linux-exynos
afaerber has joined #linux-exynos
<Gottox> so, I'm currently using a stock-kernel with exynos_defconfig and a stock u-boot with snow_defconfig.
<Gottox> I'm naivily loading the kernel with fatload mmc 1:2 0x40008000 /uimage and trying to boot with bootm 0x40008000
<Gottox> no further configuration.
<Gottox> the display shows "Starting kernel" but nothing more.
<Gottox> (switched to 4.1 in the meantime.)
<Gottox> what needs to be done to get boot messages?
<sjoerd> it may well be booting, it might jut nost show anything on the screen
<javier__> Gottox: this is a common confusion, you are using 40008000 which is the kernel load address as the address to where load the uImage
<Gottox> ok, so an offset needs to be added?
<javier__> Gottox: yes, since u-boot reallocates the zImage after removing the u-boot header so you should use something like 0x42000000
<javier__> Gottox: I'm assuming you are appending the FDT in the kernel image
<javier__> Gottox: btw, you can also just use a zImage by using bootz instead of bootm
<javier__> Gottox: and use 0x40008000 but then you need to enable u-boot XIP (Execution In Place) support, I've never tested the later
<javier__> sjoerd: got that right? ^
<javier__> I mean, did I get it correctly or XIP is not needed?
<sjoerd> is this peach or snow
<javier__> sjoerd: snow afaiu
<Gottox> I'm using snow here.
<sjoerd> 0x40008000 is where u-boot is loaded on that platfrom iirc
<sjoerd> maybe i'm misrembmering
<javier__> Gottox: mmm that guide has several issues
<sjoerd> anyway if you're using a uImage what counts is hw the uImage got seutp really
<Gottox> if i load the image to 0x42000000 the issue remains the same. the load address/entry point of the kernel is still at 40008000 though.
<sjoerd> how did you create the uImage ?
<sjoerd> When yu do bootm u-boot will relocate the content to the given load address in the uimage
<Gottox> ah, there comes the loadaddress from.
<sjoerd> yes
<javier__> Gottox: that's why you need to use a different (u-boot) load address than the kernel load address / entry point
<javier__> Gottox: I use 0x42000000 for example
<Gottox> aaaah.
<Gottox> but the build progress itself is okay?
<javier__> Gottox: it depends, I use an appended DTB while you are creating an uImage with no appended DTB
<javier__> so you need to also load the DT and pass it to bootm
<javier__> I didn't see that in the u-boot command that you shared
<Gottox> aah, so that's my mistake.
<javier__> Gottox: as I said, I would just use a zImage instead of a uImage
<javier__> but that is a separate thing
<Gottox> yea, but for tinkering around uImage is enough for now. Will change that later.
<Gottox> thanks guys, that was really helpful!
<javier__> Gottox: yw
<javier__> Gottox: btw, I see you are building a mainline 4.0.5 but you should really use 4.1
<javier__> Gottox: with 4.0.5 you won't have display and wifi working
<Gottox> javier__: yea, I already did that after reading the backlog, thanks :)
<javier__> nor Suspend-to-RAM, HDMI and there are several important bugs that were fixed too
<javier__> Gottox: great
<Gottox> kindof success: the device resets, but the screen flickers so I suspect the fb drivers get loaded.
<javier__> Gottox: which kernel version? 4.1?
<Gottox> 4.1
<Gottox> yes
<javier__> Gottox: and you are using a mainline u-boot?
<Gottox> both vanilla, uboot and kernel.
<javier__> and exynos_defconfi... mmm that should really work
<Gottox> yea, I suspect I made a mistake somewhere, will retry later.
<javier__> Gottox: ok
zombah has quit [Quit: Leaving]
amitk has quit [Quit: leaving]
afaerber has quit [Quit: Verlassend]
<john_f> any ideas on why sound doesn't work on snow? I get a too fast playback rate and can only hear the headphone amplifier turning on/off when mixer levels are high.
<john_f> using linus 4.1 kernel
<javier__> john_f: sound is the only peripheral that is not working correctly. I took a look a couple of times but didn't figure out what's missing
<javier__> john_f: there are reports of audio not working correctly on other Exynos machines due a bug in the pl330 dma driver
<si1v3r> javier__: Is the sound system the same for snow and peachpit? My sound works fine.
<javier__> john_f: you may try https://lkml.org/lkml/2015/6/10/177 that is reported to fix that issue, although I don't know if is the same
<si1v3r> I did have to do the whole right mixer speaker right on madness...
<javier__> si1v3r: same codec chip but different wiring at the board level
<si1v3r> Oh so I just lucked out then. :)
<javier__> si1v3r: yeah, I have some patches to add UCM profiles for Snow and Peach Pit/Pi but never posted...
<si1v3r> was the sleep resume patch merged in time for 4.1?
<si1v3r> if so I may build it.
<javier__> si1v3r: no it wasn't... unfortunately it was too late for the 4.1 -rc cycle
<si1v3r> too bad. Well 4.2 is looking hopeful then.
<si1v3r> I've got a exynos laptop with sound, sleep, wifi... life is good. :)
<javier__> si1v3r: about sound, I'm not completely sure what's missing. I had audio working on peach and snow at some point with some patches from Samsung that I re-posted
<javier__> but many people says that it does not work on Snow and I was able to reproduce one time but don't remember with what u-boot version, etc
<javier__> si1v3r: hehe, yeah is good that the exynos chromebooks work much better now with mainline
<si1v3r> Really wonderful. It's a real option for a non-x86 workstation now.
<si1v3r> You've preserved the hardware too, since upstream support from goosung is no longer required.
<si1v3r> Better than wintel was, but still... :)
<javier__> I still have ChromeOS on my emmc though
<javier__> I'll leave it until I have mali and proper 3d hw acceleration working :)
<si1v3r> fbdev is fine for me. I mostly text edit.
<javier__> es, fbdev works well indeed for that
<javier__> *yes
<javier__> si1v3r: IOMMU and CPUFreq are the two big things that are still missing
<javier__> probably the former is not too important for your use case but certainly the later is
<javier__> hopefully both could make it for 4.3 though since the patches have been in the list for months
<john_f> javier__: that dmaengine patch is in 4.1
<javier__> john_f: ok, then is not that