ssvb has joined #linux-exynos
mturquette has quit [Quit: ZNC -]
indy has quit [Ping timeout: 255 seconds]
amitk has joined #linux-exynos
D1337d has quit [Ping timeout: 245 seconds]
D1337d has joined #linux-exynos
amitk has quit [Ping timeout: 255 seconds]
amitk has joined #linux-exynos
WarheadsSE has quit [Ping timeout: 244 seconds]
amitk has quit [Ping timeout: 265 seconds]
amitk has joined #linux-exynos
WarheadsSE has joined #linux-exynos
WarheadsSE has quit [Ping timeout: 244 seconds]
<javier__> amitk: hi, did you have time to take a look to the wifi support for peach pi/pit?
WarheadsSE has joined #linux-exynos
<D1337d> does anyone have a copy of thier .bash_history from the time they compile a kernel (chromeos 3.8) or mainline up to when they boot it on the device
* D1337d would like to compare notes to see if i am making a stupid mistake preventing me from booting anythign on the peach-pit
<javier__> D1337d: don't have it on my .bash_history since I don't build a chromiumos kernel in a while but I can tell you what I remember I was doing back then
<javier__> D1337d: creating a FIT or with nv-uboot?
<D1337d> just tried both
<D1337d> i would prefer nv-uboot
<D1337d> i woudl start off with a exynos_defconfig
<D1337d> then a LOADADDR=0x42000000 make uImage dtbs
<D1337d> then copy the uimage and dtb to /boot
<D1337d> then boot them
<javier__> D1337d: $ ./chromeos/scripts/prepareconfig chromeos-exynos5 && make -j4 bzImage modules dtbs
<javier__> to build the kernel and to create the FIT image:
<javier__> $ mkimage -f ../kernel.its.peach kernel.itb.peach
<javier__> $ vbutil_kernel --version 1 --arch arm --keyblock /usr/share/vboot/devkeys/kernel.keyblock --signprivate /usr/share/vboot/devkeys/kernel_data_key.vbprivk --vmlinuz kernel.itb.peach --config ../config.peach.$1 --pack kernel.kpart.peach
* D1337d gives that a whirl
<D1337d> the its file is the same as the one on the wiki?
<javier__> D1337d: my config.peach is: console=ttySAC3,115200 debug earlyprintk root=/dev/mmcblk1p4 rootwait rw no_console_suspend
<D1337d> what is the no_console_suspend for?
* D1337d looks it up
<D1337d> ah
<javier__> D1337d: and my kernel.its.peach
<javier__> D1337d: I don't think that exynos_defconfig has all the kconfig symbols enabled that you need for the chromiumos 3.8
* D1337d is just trying to get somthign to boot so i can swap over from the snow
<javier__> why you don't want to use chromeos-exynos5.flavour.config?
<D1337d> may give that a go
<D1337d> at the moment uboot boots up, screen scrolls, screen goes black and thats it
<D1337d> both with 3.18 and chromeos kernel i ahve compiled
* D1337d belives i am making a mistake somewhere
<javier__> D1337d: dunno what's the .its file on the wiki
<D1337d> near identical
<D1337d> just diffrent paths
<javier__> yeah, those paths are from my dev environment, it shouldn't necessarily match yours
<javier__> D1337d: do you have a peach pit (the 11" one) or a peach pi (13") ?
<D1337d> 11"
<D1337d> found a typo in my kernel.its
<D1337d> that was silently accepted
* sjoerd found it much less error-prone to just chainload a u-boot and let that load the kernel
<D1337d> thats how i have been operating rather than the FIT image method
<javier__> D1337d: I agree with sjoerd, that's why I also moved quickly to nv-uboot when I started working on these devices :)
<javier__> and also allows you to test kernels easily by loading them over tftp
<D1337d> yup, as i mentioend above i have a full nv-uboot setup with /boot at /dev/mmcblk1p3
<javier__> D1337d: so my suggestion is to reduce the possible points of failures so if you test the chromeos 3.8 kernel, use the chromeos kernel config and only use exynos_defconfig if you test mainline
<D1337d> yup last thing i see on screen is 'uncomrpressing kernel' then black screen
<javier__> D1337d: just 3.18 won't give you a working display btw, you need and
* D1337d is compiling against yout dp-integ branch
<D1337d> i assume your build process for 3.18 is simmilar
<D1337d> make exynos-defconfig
<D1337d> then LOADADDR=42000000 uImage dtbs
<D1337d> for nv-uboot
<javier__> D1337d: not quite, I build a plain zImage and then create an uImage with mkimage
* D1337d has been under the impression that LOADADDR can go nearly anywhere as long as its non overlapping
<D1337d> ah ok
<javier__> I also append the DTB to the image before creating the uImage since I had been bitten many times by the DTB overwritting the kernel image in memory
<javier__> D1337d: so my steps are basically:
<javier__> $ export ARCH=arm CROSS_COMPILE="arm-linux-gnueabihf-"
<javier__> $ make exynos_defconfig
<javier__> $ make -j4 bzImage exynos5800-peach-pi.dtb
<javier__> $ cat arch/arm/boot/zImage arch/arm/boot/dts/exynos5800-peach-pi.dtb > zImage.dtb
<javier__> $ mkimage -A arm -O linux -T kernel -C none -a 0x40008000 -e 0x40008000 -n Linux -d zImage.dtb uImage
* D1337d kicks that off
<D1337d> only diffrence is i like to build on the device itself
<D1337d> ======== note to self on IRC logs: this is what you want
<javier__> D1337d: there is also a difference in the load and entry point addresses, you are using 0x42000000 while I'm using 0x40008000
<javier__> D1337d: note that the loadaddr is not the same as the u-boot loadaddr
<javier__> in fact for uImage it has to be difference since u-boot realocates the kernel in memory after removing the u-boot header
<D1337d> ah right, i am partially aware of that but still not fully congnative of it
<javier__> *different
<D1337d> the 0x42xxx was chosen as i lifeted it from the uboot config
<D1337d> ok this may explain the behavior i am seeing then
* sjoerd so happy he can just boot zImages :p
<sjoerd> javier__: you can turn on execute in place for u-boot to it doesn't relocate
* D1337d is very tempted to get a minimal workign kernel then port over petiteboot and use linux as a bootloader for everything else
<sjoerd> D1337d: you can use upstream u-boot as well fwiw
<D1337d> ah nice, it does nto require patches anymore?
* D1337d wants to blow away the RO firmware
* sjoerd did not touch the RO firmware
<javier__> sjoerd: interesting, I didn't know that
<sjoerd> javier__: that's what i'm running on my snow and pi
<sjoerd> pit has been possible for a while longer
<javier__> sjoerd: no, I meant the execute in place option
<D1337d> can you still do verified boot with upstream?
<D1337d> or is that a google uboot only thing?
<javier__> sjoerd: I know you have been using mainline u-boot on all your exynos devices :)
<sjoerd> D1337d: verified boot is a google uboot thing
<javier__> tbh, the only reason why I'm still using google u-boot is because I'm too lazy to package a new FIT image :P
<sjoerd> there is something iffy with the emmc access from upstream u0-boot though, it's very slow for some reason
<javier__> yeah, I kept the chromeos on the eMMC and use the SD for my debian rootfs so that shouldn't be an issue for my workflow
<D1337d> \o/
<D1337d> i see 4 penguins on the screen
<D1337d> so it was the load and boot addrs
<D1337d> thanks a lot for the above
<D1337d> i suspect i may ahve to do a write up of this for a couple of people
<javier__> D1337d: great
<sjoerd> javier__: fwiw mkimage -x will do that
<sjoerd> but booting zimages is far nicer
<javier__> cool, I didn't know about -x
<javier__> but yes, booting zImages is nicer indeed
<amitk> javier__: I haven't had a chance and Ulf was on holidays too
<javier__> amitk: ok, just asked since Ulf posted a series to add an infrastructure for power sequencing mmc/sdio devices so I'll see if I have time this week to try adding the wifi power on support on top of that
<amitk> javier__: yes, he's been working on it for a while now
<javier__> nod
<D1337d> do i still have to disable the tps65090 regulator driver on the dp-integ tree or does it no longer do things to the display
<D1337d> and i just discovered i do not
<D1337d> and that i should read lkml carefully next time
dlezcano has quit [Ping timeout: 244 seconds]
dlezcano has joined #linux-exynos
<Wizzup> D1337d: write ups are welcome
amitk has quit [Quit: leaving]
<si1v3r> javier__: I have compiled googles 3.8 branch for peachpit with the instructions on the linux-exynos wiki, but after loading the kernel with the nv-uboot image there and running bootm, it just flashes some text for a moment and then appears stuck with a blank screen. Any suggestion on where to poke to fix it, or is that expected?
afaerber_ has joined #linux-exynos
afaerber has quit [Ping timeout: 264 seconds]
indy has joined #linux-exynos
liquidAcid has joined #linux-exynos
D1337d has quit [Ping timeout: 255 seconds]
dlezcano has quit [Ping timeout: 265 seconds]
dlezcano has joined #linux-exynos
D1337d has joined #linux-exynos
liquidAcid has quit [Quit: Leaving]
<D1337d> Wizzup: more than happy to update the wiki, do i see you for an account?
<Wizzup> yep!
<Wizzup> I just need a preferred username + email
steev has quit [*.net *.split]
libv has quit [*.net *.split]
steev has joined #linux-exynos
<D1337d> will type somthing up tonight while working on my talk
<D1337d> Wizzup: PM'd
<Wizzup> (done)
<D1337d> thanks
<Wizzup> very interested in snow and peach-pi stuffs
<Wizzup> working on the odroid pages atm myself now
* D1337d is very close oto purchasing one of those
<D1337d> very very close
<Wizzup> what one?
<D1337d> XU3
<Wizzup> can't say I am a huge fan btw
<Wizzup> prefer the ifc6410 (not exynos based) and probably the tegra k1 too
<Wizzup> (but I don't have the tegra - yet)
<D1337d> not a fan of the tegra
<D1337d> had a toshiba tegra based laptop
<D1337d> nvidia refused to release info ont he hardware for a long time
<Wizzup> well, the main use I've found so far for the odroid with no proper 2d/3d accel was a build machine
<Wizzup> the ifc does some nicer things
* D1337d runs without x11 on my primary machines
<D1337d> framebuffer only
<D1337d> if you see an elinks user on the wiki thats me
<Wizzup> ;)
daniels has quit [Read error: Connection reset by peer]
daniels has joined #linux-exynos
libv has joined #linux-exynos
bzyx has quit [Read error: Connection reset by peer]
bzyx has joined #linux-exynos
daniels has quit [Ping timeout: 250 seconds]
daniels has joined #linux-exynos