issoeocio has joined #linux-exynos
<issoeocio> ext2load usb 0:2 0x48000000 uImage and bootm 0x48000000. No way: black screen.
<si1v3r> simplefb uboot?
<si1v3r> That's a hack that now makes things break.
<issoeocio> a compiled u-boot or a "traditional" from google
<si1v3r> So it's loading a fit image?
<issoeocio> It loads the image, but after that give me a black screen
<si1v3r> Tenakwa I think got that working. You could check the logs.
<si1v3r> I used the nvuboot image from the chromium wiki
<issoeocio> It's from Tenakwa logs that I choose the 0x48....
<si1v3r> uh boy... he uh.... tried a lot of stuff.
<si1v3r> Was that number near something like "YAY IT WORKS!"
<si1v3r> ?
<issoeocio> 0x40008000
<issoeocio> He forgot one zero in the previous tries
<si1v3r> Are you loading from a uboot prompt or booting a fit image?
<issoeocio> this number came from the compilation of the kernel (LOADADDR=0x40008000 make uImage dtbs) I suppose
<si1v3r> oh make uImage doesn't really work
<si1v3r> I've had to make uimages by combining the dtb and the zImage
<issoeocio> I will try the zImage
<si1v3r> then running it thorugh mkimage
<issoeocio> ok... one moment...
<si1v3r> Sorry for dump...
<si1v3r> make zImage exynos5420-peach-pit.dtb modules -j 5
<si1v3r> sudo make modules_install
<si1v3r> cat arch/arm/boot/zImage arch/arm/boot/dts/exynos5420-peach-pit.dtb > zImage.dtb
<si1v3r> mkimage -A arm -O linux -T kernel -C none -a 0x40008000 -e 0x40008000 -n Linux -d zImage.dtb uImage
<si1v3r> That's for my peach pi, but other than the name it's the same for snow.
<si1v3r> then the uImage file gets loaded by uboot's extload
<issoeocio> I am cross compiling with archlinux... one moment
<issoeocio> For curiosity: what is the repository "default" for cloning the sources?
<si1v3r> I've been using linux-next
<si1v3r> git clone git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git -b master
<si1v3r> I think
<issoeocio> Black screen :/
<issoeocio> I will try the flag clk_ignore_unused as recommended here http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/284893.html
<si1v3r> That should no longer be needed.
<si1v3r> Is simplefb on in the kernel? That would break it too.
<issoeocio> You are right. I disabled that as the wiki recommends.
<issoeocio> What are the numbers 0x48000000 or 0x40008000?
<issoeocio> *and sorry for the newbie questions. I'm a philosopher, not a programmer.
<si1v3r> I think there is just an acceptable range, and those are both in it.
<si1v3r> They are where the kernel gets loaded to and then where the pointer jumps to
<issoeocio> They are necessary for compilation as pointed here http://www.reddit.com/r/exynos/comments/2cph69/notes_on_using_linux_316_on_a_samsung_chromebook/ ?
<si1v3r> Oh boy, I should update those.
<si1v3r> Yes that's one way of doing it, but It errored out for me often
<si1v3r> This makes a uimage and doesn't break as often in the build.
<issoeocio> Perfect! I will follow your instructions. I'm cloning the repository right now. Before I was using https://git.collabora.com/cgit/user/javier/linux.git/log/?h=wip%2Fexynos%2Fsound-snow
<john_f> does u-boot git use simplefb for snow? where would it be enabled?
<john_f> I cannot find an item for in u-boot config.
<john_f> I have u-boot git and linus' tree running ok, but with simplefb enabled in the kernel.
<issoeocio> You follow what instructions, john_f? The wiki for Snow recommends to disable simplefb
<issoeocio> Sorry, the recommendation for disable the simplefb are for the peach-pit.
<john_f> at least with the chromeium uboot tree, it needed to be enabled or disabled in both.
<john_f> mostly gathered from this channel log.
<john_f> issoeocio: arch needs extended fs attributes, and maybe cgroup options. which are not in the defconfig.
<issoeocio> You could send me the directions?
issoeocio_ has joined #linux-exynos
issoeocio has quit [Ping timeout: 246 seconds]
<si1v3r> simplefb is disabled on peach and snow.
<si1v3r> exynos DRM is now supported so the hack is no longer needed.
<javier__> issoeocio_: Snow should work well with linux-next or v4.1-rc8, no need to clone a random branch from my repo
<javier__> john_f: mainline u-boot does not have simplefb support neither ChromiumOS U-boot by default
<javier__> but that is not needed anymore as si1v3r said
<javier__> issoeocio_: are you booting a FIT image or chain loading a nv-uboot?
<javier__> issoeocio_: are you using exynos_defconfig or multi_v7_defconfig?
<issoeocio_> chain loading nv-uboot
<issoeocio_> exynos_defconfig
<issoeocio_> chain loading nv-uboot as far I can tell... I simply dd the .uboot image (from chromium and I try too a compiled image) to the sda1 partition of USB
<javier__> issoeocio_: that's not going to work, you need to create a uImage of the u-boot image and then signed it
<issoeocio_> Ok. I will research for how to do this.
<javier__> issoeocio_: http://hastebin.com/eyoyimorof.rb
<javier__> issoeocio_: then you can dd uboot.kpart to the sda1 partition
<javier__> issoeocio_: I'm assuming you already have dev_usb_boot=1, raise the priority in sda1 using cpgt, do Ctrl + U on boot, etc
<issoeocio_> Ok. the vbutil_kernel part I need to do in the ChromeOS?
<javier__> issoeocio_: not necessarily, there are packages for distros
<issoeocio_> Yes. I already do that.
<javier__> at least for debian and fedora iirc
<issoeocio_> Not for Arch... as far I search. Only outdate PACKAGE on the AUR.
<javier__> I see... I don't remember if ChromeOS rootfs has those utilities
<javier__> what I shared is what I execute on my debian machine
<javier__> issoeocio_: hold on, let me built for you
<issoeocio_> *Compiling the Kernel*
<issoeocio_> Thanks.
<javier__> issoeocio_: yw
<javier__> issoeocio_: also, are you appending a DTB, or loading the kernel and DTB separately?
<issoeocio_> appending
<javier__> issoeocio_: newer u-boot supports loading a zImage directly with bootz so there is no need to build a uImage anymore
<issoeocio_> 404 in the u-boot
<javier__> (without the - )
<issoeocio_> ok. Thanks
<steev> javier__: that u-boot is for.... snow/spring ?
<javier__> steev: is for Snow
<steev> ah, okay
<javier__> steev: well, at least for Snow. I'm not sure if it will boot a Spring since there isn't a spring_defconfig in mainline u-boot
<steev> i'm trying to remember what the difference was that required a different u-boot for them
<steev> also... it looks like, at least with peach-pi, chromeos has moved it to freon, and stablized it, so that's kinda cool i suppose
<javier__> steev: cool, is that only in dev-channel / test images or is also updated to normal users?
<steev> javier__: my pi is set to stable for it's chromeos install
<steev> i updated, and then checked the version because i was curious what had gone stable, and it changed from peach_pi to peach_pi-freon
<javier__> steev: Spring should be very similar to Snow but there are differences in the display / regulators so maybe Snow u-boot will boot but I don't expect it to enable the display
<steev> ah, right
<javier__> steev: so not too useful without a serial console but definitely a question for andreas faerber
<steev> i'm not sure who that is :)
<javier__> he usually is in the channel as afaerber, he is the one that did most of the Spring mainlining work
<issoeocio_> Panic. VFS: Unable to mount root fs
<javier__> issoeocio_: what's your kernel command line ?
<javier__> issoeocio_: so your kernel boot, it seems that you didn't provide the correct rootfs parameter
<steev> javier__: out of curiousity, i have a chromiumos checkout here, and when i switch it to peach_pi-freon, it still wants to build xorg, but i looked at the processes on peach and it's definitely running Chrome not using X
<steev> i wonder if some of the changes haven't trickled out of the goog
<javier__> steev: no idea tbh, I'm not that familiar with ChromiumOS. I do mostly kernel work and use a debian rootfs
<javier__> and also graphics is for sure not one of the areas I've more experience with :)
<javier__> IOW, I'm pretty ignorant about it
<steev> javier__: honestly, i do too, since i work on kali for a living, but i watch chromiumos pretty closely, have a few commits here and there to fix things that bugged me
<steev> and graphics is an area that i suck at too, and since debian is anti-anything closed source, it's kinda hard to get graphcis stuff working properly, especially on arm :P
<javier__> yeah, in theory should be easy to have mali support on Linux. Just built the out-of-tree driver, the ARM provided EGL libs and the -armsoc DDX
<javier__> but I have never tried...
<javier__> *use the ARM provided
<javier__> issoeocio_: gotta go now but double check your kernel command line params
<issoeocio_> setenv bootargs 'console=tty1 rw debug earlyprintk rootfstype=ext4 rootwait root=/dev/sda3"
<issoeocio_> and WORKS!
<javier__> issoeocio_: awesome
<javier__> bye!
<issoeocio_> Thanks!
issoeocio_ has quit [Ping timeout: 246 seconds]
<sjoerd> javier__: last time i set it up you still need some kernel patches to let the mali driver hook into th edisplay system
<javier__> sjoerd: I see, I should take a look to your tree to have a better idea of what is needed
<javier__> I'll love to have proper mali support on my peach pi
<Wizzup> or tamil, someday
<javier__> Wizzup: is that the open source driver whose source is not open?
<Wizzup> not yet :)
* javier__ finds that concept really funny
* Wizzup isn't in a flaming mood, but hopes stuff will work out
<javier__> hehe, fair enough. I'm not in a flaming mood either, just mentioned because is the first time I see such a thing
<Wizzup> javier__: any clue if the webcam works?
<Wizzup> I'll try turning on V4L and see what happens
liquidAcid has joined #linux-exynos
liquidAcid has quit [Quit: Leaving]
dlezcano has quit [Ping timeout: 272 seconds]
dlezcano has joined #linux-exynos
liquidAcid has joined #linux-exynos
<javier__> Wizzup: it does on peach pi at least, it should work on snow as well
<Wizzup> ack :)
<javier__> Wizzup: did work for you?
<Wizzup> Didn't try yet -- was a bit tired and suffering from a concussion
<Wizzup> silly me hit my head
liquidAcid has quit [Quit: Leaving]
<javier__> Wizzup: oh, hope you feel better now
<javier__> Wizzup: no worries, I was just courious. I should try it too
<Wizzup> is there a specific driver that I need?
carc has quit [Quit: QUIT]
<Wizzup> I didn't see it in lsusb
<javier__> Wizzup: no, uvc should be enough
<Wizzup> ack
<javier__> Wizzup: the camera is a built-in usb device so only a regulator has to be always on in order to be enumerated
<javier__> mmm, I remember now that there were issues on snow, I should take a look to that
<javier__> thanks for testing though
bzyx_ has joined #linux-exynos
<Wizzup> so should I test it or not? :)
<Wizzup> I'm confused
dlan_ has joined #linux-exynos
Zotan_ has joined #linux-exynos
<javier__> Wizzup: you already did :)
<Wizzup> by running lsusb you mean? :)
<javier__> yes, it should be enumerated there
<javier__> since is a built-in device and the chip is always powered on since the regulator is marked as always-on
<Wizzup> it only shows hubs
<javier__> right, so it is not being enumerated which means that is not working
<Wizzup> yes
<Wizzup> ack
<Wizzup> Just making sure ;)
<Wizzup> s/;)/:)/
<javier__> yes, thanks a lot
nashpa_ has joined #linux-exynos
bgamari| has joined #linux-exynos
dlan_ has quit [Remote host closed the connection]
dlan_ has joined #linux-exynos
Zotan has quit [*.net *.split]
dlan has quit [*.net *.split]
nashpa has quit [*.net *.split]
bgamari has quit [*.net *.split]
bzyx has quit [*.net *.split]
nashpa_ is now known as nashpa
bzyx_ is now known as bzyx
<Wizzup> javier__: if you need me to test other things let me know
meridion_ has joined #linux-exynos
sjoerd` has joined #linux-exynos
twitch153|znc has joined #linux-exynos
indy_ has joined #linux-exynos
indy has quit [*.net *.split]
meridion has quit [*.net *.split]
twitch153 has quit [*.net *.split]
sjoerd has quit [*.net *.split]
twitch153|znc is now known as twitch153
Zotan has joined #linux-exynos
arnd_ has joined #linux-exynos
Zotan_ has quit [*.net *.split]
pekka301 has quit [*.net *.split]
john_f has quit [*.net *.split]
arnd has quit [*.net *.split]
ojn has quit [*.net *.split]
steev has quit [*.net *.split]
Gottox_ has joined #linux-exynos
Gottox has quit [Ping timeout: 255 seconds]
Gottox_ is now known as Gottox
pekka30 has joined #linux-exynos
john_f has joined #linux-exynos
pekka301 has joined #linux-exynos
arnd_ has quit [*.net *.split]
chrs_ has quit [*.net *.split]
dne has quit [*.net *.split]
Swabbles_ has joined #linux-exynos
pekka30 has quit [Ping timeout: 244 seconds]
WarheadsSE has quit [Ping timeout: 244 seconds]
Swabbles has quit [Ping timeout: 244 seconds]
akbennett has quit [Ping timeout: 244 seconds]
bgamari| has quit [Ping timeout: 244 seconds]
bgamari- has joined #linux-exynos
WarheadsSE_ has joined #linux-exynos
ojn has joined #linux-exynos
WarheadsSE_ is now known as WarheadsSE
gladiac has quit [Ping timeout: 264 seconds]
gladiac has joined #linux-exynos
steev has joined #linux-exynos
Gottox_ has joined #linux-exynos
jnettlet has quit [Ping timeout: 264 seconds]
Gottox has quit [Ping timeout: 264 seconds]
libv has quit [Ping timeout: 264 seconds]
libv has joined #linux-exynos
_anomaly1 has joined #linux-exynos
WarheadsSE_ has joined #linux-exynos
_anomaly_ has quit [Ping timeout: 255 seconds]
WarheadsSE has quit [Ping timeout: 255 seconds]
akbennett has joined #linux-exynos