<pokazef>
I wonder why it took me so long. I guess it was all the reading about u-boot and stuff
<pokazef>
Also, I used the kernel by Tobias Jakobi, as described on the X2 page.
isaque has quit [Quit: isaque]
<pokazef>
I really need to figure out what his patch-set is for
<pokazef>
I'd rather use mainline, if it works for me
<pokazef>
I believe the reason I used the X2 page as a guide instead of the U2 page is simply because it looked "better"...
<pokazef>
It contains a bit more information and is more up-to-date
<pokazef>
The added info is mostly about the u-boot environment
<pokazef>
But your page is a clear and correct outline of the procedure. It just needs to be fleshed out a bit.
<pokazef>
Is the fan supposed to work, btw? I couldn't find it in /sys...
Vasco_O is now known as Vasco
Vasco is now known as Vasco_O
Vasco_O is now known as Vasco
LiquidAcid has joined #linux-exynos
dlan has quit [Ping timeout: 246 seconds]
amitk has quit [Quit: leaving]
dlan has joined #linux-exynos
<Wizzup>
pokazef: Just to clarfy - do you have a U2 or X2
<Wizzup>
You said U2, but you seem to refer to X2 a lot
<Wizzup>
pokazef: Please do work on improving the U2 page - I can give you an account.
<Wizzup>
If you want to, anyway.
<LiquidAcid>
Wizzup, one can probably copy the x2 entry and just change some details (dtb and config, enabling fan support e.g.)
<pokazef>
Wizzup: I have two U2s, two U3s and a X2.
<pokazef>
LiquidAcid: Wouldn't it be better to factor the doc between the U2/3 and X2?
<pokazef>
The main difference is what dtb to use, so it's not much.
<pokazef>
Wizzup: I'd be glad to work on the wiki. I don't have much experience with ARM kernels but I have a strong incentive to maintain my odroids.
<pokazef>
I was delighted to see low-latency audio working out of the box, BTW.
<LiquidAcid>
pokazef, what do you mean by "factor"?
<pokazef>
That was the main problem that kept me from switching to Hardkernel's 3.8.y
<pokazef>
LiquidAcid: not duplicate the doc?
<pokazef>
I should have said "factorize", sorry.
<LiquidAcid>
pokazef, a bit more specific please, "not duplicating" also doesn't tell me anything, you want to merge them?
<pokazef>
OK: right now, the U2 and X2 pages are distinct and the U3 points to the U2.
<pokazef>
Why not keep one central page about Odroids based on Exynos 4412 prime?
<LiquidAcid>
pokazef, maybe just start with copying everything, and then decide later (after modification) how much can be shared and depending on the amount IF sharing makes sense at all
<pokazef>
LiquidAcid: ok, that works too
<LiquidAcid>
pokazef, also i can't test anything else apart from X2, so if i update the X2 guide, i don't want to modify the U2/U3 guide at the same time
<pokazef>
LiquidAcid: well I can test on all three, if needed
<LiquidAcid>
pokazef, i usually bump the kernel in the X2 guide once i've fixed all the remaining bugs on my todo, i just don't want to do the same for u2/u3
<pokazef>
LiquidAcid: I understand, and maybe I could help you with that. By the way, what is the purpose of "fdtfile=exynos4412-odroidx2.dtb" in your u-boot env?
<pokazef>
I don't think it's used for anything, so I didn't change it for the U2
<LiquidAcid>
pokazef, you mean here: "Check the u-boot env by using fw_printenv. It should look something like this."
<pokazef>
yes
<LiquidAcid>
pokazef, the variable is built-in, it always shows up when you exec fw_printenv from u-boot
<LiquidAcid>
pokazef, if you clean the env from within u-boot you're always going to see it, hence i left it in there
<LiquidAcid>
pokazef, so that people don't try to remove it (which doesn't work)
<LiquidAcid>
well, you could probably remove it from the shell script
<pokazef>
That's what I was guessing
<LiquidAcid>
yeah, it should be redundant
<pokazef>
BTW, having a custom u-boot env is kind of a PITA when working on eMMC
<LiquidAcid>
pokazef, why is that?
<pokazef>
... because all boot blocks are in the boot partition, but the u-boot env needs to be in the user partition, according to the u-boot odroid README
<LiquidAcid>
so, why does that pose a problem?
<LiquidAcid>
you only set the u-boot env once, the rest is in the script
<pokazef>
Yes, it's only relevant when updating u-boot
<LiquidAcid>
pokazef, which you have to do anyway if you plan to use an upstream kernel
<pokazef>
It's that eMMC boot partition thing that's actually a pain
<pokazef>
It's much simpler on SD card
<LiquidAcid>
well, i've never used a emmc, so i can't tell
<pokazef>
It has extra partition, and you can't access them through the SD adapter.
<pokazef>
So if you mess up, it's harder to recover.
<LiquidAcid>
pokazef, yeah, that much i know
<LiquidAcid>
you always need a prior system to bootstrap from
<pokazef>
LiquidAcid: Thanks a bunch for the doc and the rest, BTW. It was really helpful.
<LiquidAcid>
i use gentoo, so i never saw a big problem with that :)
<LiquidAcid>
i used arch to bootstrap my system, hehe
<pokazef>
I used debbootstrap :)
<LiquidAcid>
last time i used debian must have been 10yrs ago
<pokazef>
last time i used redhat was 10 years ago
<pokazef>
Debian is a great improvement, but I should really try gentoo
<LiquidAcid>
javier__, do you have a exynos4 system with fimd?
<LiquidAcid>
(in the sense that fimd is actually connected to something)
<javier__>
LiquidAcid: sorry, I wasn't online
<javier__>
LiquidAcid: no exynos4, I only have exynos5 boards here (Odroid XU4 and Peach Pi Chomebook)
<LiquidAcid>
javier__, ah, i guess the chromebook uses fimd for it's internal display?
<LiquidAcid>
or is it this DECON thing?
<javier__>
LiquidAcid: not so sure, the internal display is hooked to the eDP (drivers/gpu/drm/exynos/exynos_dp.c / compatible "samsung,exynos5-dp")
<LiquidAcid>
javier__, hmm, not sure which block that one drives
<LiquidAcid>
just asking around since i'm seeing two issues with fimd on my system, one div-by-zero and one pagefault
<javier__>
but I don't know if the fimd is used somehow for that... I see that the fimd block has status "okay" in the DTS
<javier__>
LiquidAcid: I see
<javier__>
LiquidAcid: no idea sorry...
<LiquidAcid>
javier__, could you check if runtime_status of the device?
<javier__>
LiquidAcid: yes, just give me some minutes because my SD broke and I've to dd an image to a new one
<LiquidAcid>
javier__, sure, take your time
afaerber has quit [Quit: Ex-Chat]
<javier__>
LiquidAcid: sorry, I got busy with another task
<javier__>
LiquidAcid: you are right, the peach pi uses fimd
<javier__>
# dmesg | grep -i fimd
<javier__>
[ 1.027016] [drm] Exynos DRM: using 14400000.fimd device for DMA mapping operations
<javier__>
LiquidAcid: with what kernel version are you having those issues? also, are you enabling IOMMU or not?
<LiquidAcid>
javier__, 4.5.2, iommu is enabled
<javier__>
LiquidAcid: hrm, I'm not able to boot the peach pi with IOMMU enabled. I remember there was an issue with the bootloader but can't remember the details nor if that was ever fixed
<javier__>
maybe the boot hang I get with IOMMU enabled is caused by the issues you mention
<javier__>
I don't have a serial console on this machine
<LiquidAcid>
0x20100000 is the old dma_addr the fimd was scanning out from
<LiquidAcid>
my guess is that fimd_update_plane() doesn't update the registers, but only writes to the shadow ones
<LiquidAcid>
the update then supposedly happens on the next vblank, but there doesn't seem to be one between plane updating and drm core freeing the buffer
<LiquidAcid>
well, i'm sure that there is no vblank (i've put a prinkt in the handler)
<javier__>
LiquidAcid: interesting, I assume this used to work so probably makes sense to do a git bisect to find the offending commit
<javier__>
I also had a iommu fault today on the XU4 when enabled iommu support but that was caused by the s5p-mfc driver not having iommu support: http://hastebin.com/aboqihidec.xml
<LiquidAcid>
javier__, i'm not sure i'm just seeing this since i don't have anything attached to the fimd port
<javier__>
LiquidAcid: I see, I should really find some time to solder a USB to ttl cable to the chromebook uart pins...
<javier__>
it's hard to know what's causing the machine to not boot when iommu is enabled
<javier__>
s/find some time/get enough courage since my soldering skills are pretty bad :)
<javier__>
LiquidAcid: yes, I meant that one. I didn't remember if there was a fix or not in mainline but it seems that never landed?
<LiquidAcid>
javier__, no, i don't think anyone picked them up
<javier__>
LiquidAcid: yeah, it seems to be part of a very big series (25 patches) but Robin Murphy didn't like the approach
<LiquidAcid>
the usual situation, someone doesn't like it, and it stays broken for another 2 yrs *sigh*
<javier__>
LiquidAcid: yeah... in fact Marek said in the last email of that thread:
<javier__>
"I would really like to have something working soon, it's been a lot of discussion but still very little of code that actually implements anything..."
<javier__>
and that was a year ago, sigh indeed
<javier__>
LiquidAcid: I'm leaving for today, I think your best bet now is to do a git bisect if that issue was not present on older kernels
<LiquidAcid>
javier__, actually i have no idea
<LiquidAcid>
javier__, first time using fimd
<LiquidAcid>
or rather, using it blind
<javier__>
LiquidAcid: I see
<javier__>
LiquidAcid: sorry that I couldn't be of any help...