<swabbles> Wut.
<swabbles> I have been able to compile u-boot for peach pi.
<swabbles> Time to test whether this is capable of booting that one kernel I built.
<swabbles> Wizzup: I have come a bit closer now.
<swabbles> I can build u-boot as described in the wiki page (last section), but when booting you'll end up with a limited shell.
<swabbles> :)
<swabbles> OK, enabled a full shell now.
<swabbles> \o/
<swabbles> Can't boot the kernel I built, but at least I can reproduce the u-boot binaries in a simple manner.
<Wizzup> swabbles: yes!
<Wizzup> ah, I think it says trucate
<Wizzup> swabbles: $ git clone https://chromium.googlesource.com/chromiumos/platform/vboot_reference -b release-R35.5712.B
<Wizzup> Cloning into 'vboot_reference'...
<Wizzup> fatal: Remote branch release-R35.5712.B not found in upstream origin
<Wizzup> let me see if I can fix that
<Wizzup> swabbles: it's also not clear to me where the serial part needs to be added @ dtsi, I thought the order matters? but it's early...
* Wizzup yawns
<Wizzup> also, I think your guide misses a make chromeos-peach_config or something
<Wizzup> e.g. chromeos_peach_config
<Wizzup> ah nvm.
<Wizzup> lol
<Wizzup> I ran into btrfs fs full issues
<Wizzup> That took me well over an hour to figure out.
<Wizzup> and a bit more to fix.
<Wizzup> balances that would not stop, that would start immediately on boot ,etc ...
<Wizzup> should try the newer kernels sometime
<Wizzup> swabbles: also, I am getting the following in your guide:
<Wizzup> (export rc=$? && cat /home/merlijn/chromeos/u-boot/build/dts/exynos5420-peach-pit.dtb.errmsg >&2 && exit $rc)
<Wizzup> DTC: dts->dtb on file "/home/merlijn/chromeos/u-boot/build/dts/exynos5420-peach-pit.dts.in"
<Wizzup> FATAL ERROR: Couldn't open "exynos54xx.dtsi": No such file or directory
<Wizzup> make[1]: *** [/home/merlijn/chromeos/u-boot/build/dts/exynos5420-peach-pit.dtb] Error 1
Wizzup has quit [Quit: bbl]
Wizzup has joined #linux-exynos
<swabbles> Wizzup: branch should be firmware. truncate is used to pad the binary up to 640K (I am not sure if it is needed, but it is what the cros_bundle_firmware util does as well).
<swabbles> And I am not sure why you get that error exactly.
<swabbles> Because I don't get it on my snow chromebook, I do get it on peach (using a Gentoo chroot).
<swabbles> Wizzup: I think you need =sys-apps/dtc-1.4.0 (instead of 1.3.0).
<Wizzup> swabbles: I am doing this on my chromebook as well
<Wizzup> swabbles: aaah.......
<Wizzup> swabbles: What didn't work wrt kernel?
<Wizzup> You said ``kernel didn't work yet''
<swabbles> Same issue when booting it, black screen.
<Wizzup> No trace?
<swabbles> Nothing at all.
<Wizzup> but you do have u-boot shell on the screen?
<Wizzup> (before loading kernel)
<swabbles> Yes.
<Wizzup> wouldn't a serial be nice ;-)
<Wizzup> and you're sure your u-boot is not simplefb enabled?
<swabbles> I use like ext2load mmc 1:3 0x42000000 /uImage; ext2load mmc 1:3 0x43000000 /exynos5422-peach-pi.dtb; bootm 0x42000000 - 0x43000000
<swabbles> I don't even know how to enable/disable simplefb atm.
<Wizzup> dtc-1.4.0 fixes is.
liquidAcid has joined #linux-exynos
<Wizzup> \o/ got a kernel to boot with normal u-boot + cmdline force
<Wizzup> WarheadsSE: ^
<liquidAcid> tfiga, thanks for the update on the PD situation
<liquidAcid> i haven't found time yet to test the patch by inki, the 'drm/exynos: hdmi: fix power order issue' one
<tfiga> liquidAcid: np
<tfiga> we need to test it too
<tfiga> but it might be solving the second problem
<swabbles> WarheadsSE: well, using verified boot, and forcing the bootargs atm.
<tfiga> although the patch is a bit strange, as it might look like the dpms off might be called twice...
<swabbles> Something in nv u-boot seems to be broken/missing.
<liquidAcid> tfiga, it sure looks a bit hacky
<liquidAcid> but i won't jump to conclusions yet, still have to see if it really fixes the issue for me
<tfiga> yep
<tfiga> as for the dependency on LCD0 power domain, we have two solutions in mind
<tfiga> either disable VP for now or make it a separate device in LCD0 domain
<tfiga> the only use case for it right now is support for NV12 and NV12MT formats directly
<liquidAcid> ah, ok, that's one thing i wanted to ask -- from your description it looked that the vp didn't have any function at all
<tfiga> this might be useful for hardware overlay in future, though
<tfiga> as the MFC outputs NV12MT
<liquidAcid> would be indeed be useful to have something that detiles the format in hw
<liquidAcid> i think the g3d/mali at least can't natively cope with that format
<tfiga> hmm
ssvb has quit [Ping timeout: 252 seconds]
<tfiga> liquidAcid: you might be able to resort to two-pass processing using fimc if I'm not mistaken
<tfiga> yep, it seems to support NV12MT in mem-to-mem mode
<liquidAcid> i think that is what most video players that use the mfc do atm
<liquidAcid> xbmc and gstreamer afaik
<liquidAcid> does someone know if vin-supply properties in the dts also allow for multiple regulators? so something like vmmc-supply = <&ldo4_reg &ldo5_reg>; ?
ssvb has joined #linux-exynos
ssvb has quit [Ping timeout: 255 seconds]
<Wizzup> wifi works too
* Wizzup reads the mfw discussion
<Wizzup> mfc*
Wizzup has quit [Ping timeout: 240 seconds]
Wizzup__ has joined #linux-exynos
<Wizzup__> swabbles: also see http://linux-exynos.org/wiki/User:Wizzup/XE303C12/Kernel (mostly for disable cc_stackprotector)
<Wizzup__> idk whaats up with my home network
<Wizzup__> what is*
Wizzup has joined #linux-exynos
Wizzup__ has quit [Quit: leaving]
<WarheadsSE> Wizzup: \o/
<swabbles> Or well minus the #Linux_kernel
<swabbles> Still figuring out a few things.
<swabbles> Wizzup: what did you put in your boot.txt? (Mine doesn't seem to override the root path)
<Wizzup> swabbles: give me 5 mins
<Wizzup> well,15.
<Wizzup> need to walk to the train
<Wizzup> swabbles: hey
<Wizzup> I just set root=/dev/mmcblk1p3 rootwait debug earlyprintk console=tty1 rootwait rw
<Wizzup> (note that I got rid of the {devpart} thing
<Wizzup> )
<Wizzup> swabbles: did you select append, override or force?
<Wizzup> ( for cmdline )
<swabbles> override.
<Wizzup> let me check
<Wizzup> so CONFIG_CMDLINE_FROM_BOOTLOADER=y
<Wizzup> hm, I see I also had the CMDLINE set to p3 in my config, still... I think I set it to p4 to test. But maybe I forgot (which may mean that p12 doesn't work for config - but I think it should just work)
<swabbles> Yes @ CONFIG_CMDLINE_FROM_BOOTLOADER=y
<Wizzup> do you have a CMDLINE set?
<Wizzup> I'll be home in an hour or so, btw.
<swabbles> Yes, I do.
<Wizzup> set to?
<Wizzup> Or rather, how are you testing overriding the root path?
<swabbles> I am not trying to get it to work with CMDLINE, I am trying to get it to work with the script.
<Wizzup> And did you create boot.scr.uimg?
<swabbles> I have.
<Wizzup> It doesn't work directly on boot.txt
<Wizzup> yes, I got that @ get to work with
<swabbles> boot.txt currently contains:
<swabbles> setenv bootargs console=tty1 debug earlyprintk root=/dev/mmcblk1p3 rootwait rw
<swabbles> Before that I had some of the regen stuff, but that didn't seem to work either.
<Wizzup> uhm
<Wizzup> Take the one from http://bpaste.net/raw/139643/
<Wizzup> replace the devname and bootpart stuff
<Wizzup> I hardcoded root=/dev/mmcblk1p3 instead of root=\${rootpart}etc
<Wizzup> that's all I changed, I think
<Wizzup> *maybe* I removed the setenv bootpart 3, but I don't think I did that even.
<Wizzup> again - using FIT images, so didn't have to change /vmlinux'