dlezcano has quit [Ping timeout: 272 seconds]
dlezcano has joined #linux-exynos
afaerber has quit [Quit: Verlassend]
liquidAcid has quit [Quit: Leaving]
Tenkawa has joined #linux-exynos
<libv> magnificent. on the 3.8 kernel, using planes results in a nice kernel panic...
<libv> memcpy to fbdev it is :(
<libv> javier__ his tree would be pointless anyway as i first would need to get the mali kernel space going on it, and -ENOTIME for that before FOSDEM
opuk has quit [Ping timeout: 240 seconds]
R0b0t1 has joined #linux-exynos
<Tenkawa> brb
Tenkawa has quit [Quit: leaving]
<R0b0t1> any idea what it would take to adapt hardkernel's u-boot to the mainline u-boot? I noticed there was some restructuring
<libv> R0b0t1: try it
<R0b0t1> well I mean this is me trying it
<R0b0t1> do what, just copy everything over and move the config?
<libv> wow, is that how you approach problems like this?
Tenkawa has joined #linux-exynos
<R0b0t1> no, this is me gathering information
<Tenkawa> ugggh
<Tenkawa> I've got to be missing something simple
<libv> R0b0t1: they are both git trees with a communal basis, right?
<R0b0t1> I'm going to check the directory structure again, but I really don't think that fact helps me based on what I noticed...
<R0b0t1> (otherwise, yes, the solution would be rather braindead)
<Tenkawa> what would you all say is the most likely culprit if I dd a signed kernel to a partition and i get nothing but a black screen on boot (not even the white screen and boot)
<Tenkawa> goback to the internal one and no problem
<Tenkawa> I pulled down the tree. ran exynos_defconfig, make, vuilt.. dd to kern partition.. reboot and just black screen if I hit ctrl u
<Tenkawa> er built
<libv> R0b0t1: no, working off the git trees is also non-trivial, but it makes it a lot easier as it gives you direct points of comparison, so you can turn the odroid tree increasingly more in the u-boot tree
<R0b0t1> yes
<libv> what other pointers would you expect from an irc channel?
<R0b0t1> oh yeah whoops I'm not sure what I convinced myself of earlier
<libv> R0b0t1: did you expect someone else to have done this and explain in detail how to do this, without just putting the code online?
<R0b0t1> ... no, which is really what pissed me off about your reply. I never actually asked anyone to do it for me. I asked if anyone had knowledge of u-boot w.r.t. hardkernel's boards.
<libv> R0b0t1: to me, your question was quite wrong, as if you really expected people to have done what i just described
opuk has joined #linux-exynos
<libv> you should've asked "is anyone working on bringing the odroid uboot tree in line with mainline"
<Tenkawa> DOH
<Tenkawa> I think I migh know what I did
<R0b0t1> no, that is still the wrong question - most people consider it done with the inclusion of hardkernel's xu3 configuration. I looked, yes. I'm working with an older board which most people seem to be uninterested in. They seem uninterested because there's nothing about merging the xu configuration into mainline, just a bunch of orphaned repos.
<Tenkawa> I might have not copied the dtb to boot
<Tenkawa> does the cat the dtb to the end of uImage work?
<Tenkawa> lets see
<R0b0t1> there is an option for it, I believe, otherwise you specify it separately in the boot command.
<Tenkawa> brb.. i hope
Tenkawa has quit [Quit: leaving]
<R0b0t1> must not have ended well
si1v3r_ has joined #linux-exynos
si1v3r has quit [Ping timeout: 264 seconds]
ssvb has quit [Ping timeout: 256 seconds]
ssvb has joined #linux-exynos
<R0b0t1> afaik doing everything properly, boot hangs at "Starting kernel..."
<R0b0t1> I mean. Not too properly. I expect it to fail when it can't find a root filesystem.
<sjoerd> There are loads of different odroid trees, really depends on what boards you're using for uboot/kernel
<sjoerd> libv: If you want the mali kernel space, we've got kernel trees with those as well
<sjoerd> R0b0t1: fwiw X2/U2/U3/XU3 work with upstream u-boot & kernel, not sure what happend with the XU, that board seems less popular
<R0b0t1> yeah might just ditch it
<R0b0t1> I have a frankenkernel and loader and all I've got to show for it is some instability
<sjoerd> I know some folks are booting that board with a mainline kernel using the exynos5410-smdk5410 dtb
<sjoerd> So if you care enough to do the work, taking that dts and correcting it for the XU shouldn't be that tricky
<R0b0t1> https://github.com/afaerber/u-boot/tree/odroid-hardkernel-v2012.07 - guy got ethernet in the bootloader working, and has a kernel fork and was/is working on mainlining some stuff? but I'm basically at the point where I don't know why the kernel isn't decompressing
<Wizzup> XU should do ok in 3.20 no?
<sjoerd> My XU3 dts got merged for 3.20, didn't think the XU was
<R0b0t1> sjoerd: yeah I don't mind doing the work but I think I effectively just did all there is to do.
<sjoerd> R0b0t1: typically because the dtb you added was wrong
<sjoerd> Or that's often what i have noobed if the kernel doesn't want to talk to me :)
<R0b0t1> I see... I used exynos5410-smdk5410.dtb
<R0b0t1> from odroid-13.y
<sjoerd> With what kernel tree?
<R0b0t1> w/ odroid-3.13.y, 3.17.7-hardened-r1, and https://github.com/afaerber/linux/tree/odroidxu
<R0b0t1> if you have a rough sketch of the steps I need to do, I will try it again in a bit
<sjoerd> heh, but afaebers tree has a dts for the odroid specifically
<sjoerd> mixing odroid-3.13.y and afaebers tree sounds like a pretty bad idea
<sjoerd> I don't know what your end-goal is :)
<sjoerd> but i'd start with just afaebers tree or with upstreamer master, pick up the dts from afeaber and slowly start adding on the things you need
<R0b0t1> yes, but I didn't have many options to start with
<sjoerd> fwiw in my experience, to get things rulling, it's best to get a dts upstream as soon as you have even the most basic support
<sjoerd> otherwise you'll keep the random trees issue which always leads to issues
<R0b0t1> yeah this wasn't intended to be long-term
<sjoerd> fwiw the hardkernel odroid kernels tend to be quite heavily hacked kernels based on some samsung vendor trees/bsp. So mixing those with anything mainline will quite likely result in total disaster
<R0b0t1> yeah wasn't my first option, but was the closest thing to a "known" "working" that I had
<R0b0t1> I wish the disasters were louder
opuk has quit [Changing host]
opuk has joined #linux-exynos
jnettlet has quit [Remote host closed the connection]
jnettlet has joined #linux-exynos
<R0b0t1> sjoerd: thanks got it
ssvb has quit [Ping timeout: 240 seconds]
afaerber has joined #linux-exynos
ssvb has joined #linux-exynos
afaerber has quit [Quit: Verlassend]
R0b0t1 has quit [Ping timeout: 245 seconds]
R0b0t1 has joined #linux-exynos
<libv> sjoerd: i am going to make do with memcpy for now
<libv> but thanks
dlezcano has quit [Ping timeout: 272 seconds]
dlezcano has joined #linux-exynos
amitk has quit [Quit: leaving]
liquidAcid has joined #linux-exynos