paulk-leonov has quit [Remote host closed the connection]
paulk-leonov has joined #linux-exynos
prahal has joined #linux-exynos
paulk-leonov has quit [Ping timeout: 250 seconds]
nashpa has quit [Quit: Going away]
nashpa has joined #linux-exynos
masta has joined #linux-exynos
prahal has quit [Ping timeout: 260 seconds]
prahal has joined #linux-exynos
afaerber has quit [Quit: Ex-Chat]
afaerber has joined #linux-exynos
afaerber has quit [Ping timeout: 250 seconds]
masta has quit [Ping timeout: 260 seconds]
paulk-leonov has joined #linux-exynos
Vasco_O is now known as Vasco
afaerber has joined #linux-exynos
prahal has quit [Quit: prahal]
prahal has joined #linux-exynos
masta has joined #linux-exynos
gordan has joined #linux-exynos
isaque has quit [Remote host closed the connection]
isaque has joined #linux-exynos
gordan has left #linux-exynos ["Konversation terminated!"]
wwilly has joined #linux-exynos
masta has quit [Ping timeout: 250 seconds]
paulk-leonov has quit [Ping timeout: 240 seconds]
krzk_ has joined #linux-exynos
masta has joined #linux-exynos
paulk-collins has joined #linux-exynos
prahal has quit [Remote host closed the connection]
prahal has joined #linux-exynos
prahal has quit [Quit: prahal]
<wwilly>
hi, when you cross compile, all the tools and script producing an ELF binary are compiled for the target, or for the source?
<wwilly>
I cross compile my kernel for arm, but I get an error "-bash: ./dtc: cannot execute binary file: Exec format error" when I launch it one the board
<krzk_>
wwilly: scripts not, they stay at host format
<wwilly>
I cross compile from a x86_64 computer
<krzk_>
so your dtc is for host
<wwilly>
uhm ok
<krzk_>
wwilly: tools... I don't remember, they are not compiled by default
<wwilly>
I want to add pmc counter for the 5422, they are not present for now
<wwilly>
or I do mistake?
<krzk_>
PMC? eh? You mean performance management counter?
<wwilly>
yes
<wwilly>
monitor
<wwilly>
to use by perf tools
<krzk_>
I got it. For dtc - what does the 'file' say?
<wwilly>
nothing for now, I need to recompile the tool
<krzk_>
eh? There is no need...
<wwilly>
I suppose I should compile one the board to overload>
<krzk_>
dtc is in many linux distros
<wwilly>
?
<wwilly>
ah yeah ok
<krzk_>
And usually you run DTC on the host, when building kernel (make; make dtbs; etc)
<krzk_>
it is uncommon to launch it on the board itself
<wwilly>
uhm ok
<wwilly>
I want to know, for having a good setup to trick the kernel
<wwilly>
when you change a dts, you test your thing on the board?
<krzk_>
wwilly: Yes. Whenever I change kernel or dts I build everything (on the host) and deliver it to the board. When changing DTS you don't have to rebuild the kernel (unless DTB is appended to the kernel but it is not so common).
<wwilly>
if I understand well, device tree is the way to describe a hardware, instead of change a small thing and booting your new kernel on the target hardware, you can overload the description in live
<krzk_>
wwilly: no, not entirely. You could do this with overlays for DTS, but not with new DTS
<krzk_>
and actually this is for adding new stuff (like shields on Arduino) not for replacing existing DTB/DTS.
<krzk_>
The drivers already probed from existing DTB so replacing it won't affect anything (you would have to unbind/rebind)... that is quite unusual approach :)
<krzk_>
so in general: you have to reboot :)
<wwilly>
uhm ok
<wwilly>
is not what I've understand from "overloading"
<wwilly>
what I've understand is that you can change any entry of a dtb/dts in live, so you can change something, add new stuff or something
<krzk_>
Probably the overloading here (I don't know where you got it) means to overload some DT nodes from some source by another source... like inheritance/overload in C++. But then you compile everything
<wwilly>
like PMC in my case
<krzk_>
and flat structure is produced
<wwilly>
uhm ok
<krzk_>
in your case you should get the sources (kernel+DTS are in the same place), change them and build new thing
<wwilly>
also I don't read it as a book, I simply read too much in diagonal for now
<wwilly>
and then reboot with new kernel
<wwilly>
?
<wwilly>
pfiou quite long to tweak this small thing :/
<krzk_>
Yes. Usually new kernel and new DTB... but the kernel does not have to be new. But you still have to restart system so it will boot from new DTB.
<wwilly>
I see something about kexec, I never tried it, nor read a documentation properly, you can't use that to change a kernel in live, with its DTB?
<krzk_>
if you have everything ready (like sources of existing kernel) this is small thing: just change DTS, make dtbs, upload new dtb to device, reboot
<wwilly>
yeah I have everything on the board now, just want to add PMC, an odroidxu3 with exynos5422 (a7 and a15)
<krzk_>
Oh, that would be interesting. In some aspects it might work... but in other aspects it probably won't. Kernel drivers expect to initialize the hardware... but the hardware was initialized but existing (already running) kernel...
<wwilly>
and it don't work correctly, one of the cluster don't boot
<wwilly>
just at the first search, maybe I completely don't understand the thing
<javier__>
wwilly: the interrupts used are SoC specific
<javier__>
so you can't just take the node from another board
<wwilly>
ok, it will not be funny without that :)
<wwilly>
and in which sense it is buggy the patch from hardkernel?
LiquidAcid has joined #linux-exynos
<javier__>
wwilly: there is a contract/interface between the kernel and the DTS, those are known as DT bindings and are documented in Documentation/devicetree/bindings/
<javier__>
that's an ABI so new kernels should always work with an old DTB
<javier__>
wwilly: but a vendor is free to change that interface at will so you can't trust that a downstream DTS will work with a mainline kernel
<javier__>
wwilly: I also wonder if perf counters will work in b.L systems at all
<javier__>
since the problem is not only related to the switcher, nothing prevents a process to migrate from between big and LITTLE cores
<wwilly>
it is the scheduler who decide that, and we can force the id core to run on
<javier__>
wwilly: yes, you can use for example sched_setaffinity() from user-space to define that policy but I mean in general
<wwilly>
yes ok
<javier__>
I remember that was an issue in the past at least but I don't know if that was fixed in the meantime
<javier__>
wwilly: not wanting to discourage you but just pointing out some possible issues ;)
<wwilly>
ok
<wwilly>
I suppose at the begnning I can just take this patch, or with only small change
<wwilly>
because I just want this pmc for my project
<wwilly>
but the interrupts used are SoC specific you said, so it will not change regarding the kernel version
<ndufresne>
javier__: I've just rebase on final 4.6 now (I was at rc5 iirc), so it might be an rc regression, but otherwise this could easily be a bug on v4l side
<ndufresne>
I mean still have to test final 4.6
<ndufresne>
javier__: I think I'll check what params we pass to the map functions too
<javier__>
ndufresne: that error doesn't ring a bell to me, better to ask in #v4l
<ndufresne>
ok
<javier__>
wwilly: yes, it won't change but it can change how you address the interrupts
<javier__>
for example, if <0 192 4> really maps to the HW interrupt you want since the GIC DT binding can be different in hardkernel and mainline
<javier__>
I haven't checked, just mentioning why you can't blindly trust a downstream DTS
<javier__>
wwilly: the A15 IRQs seems to be correct, the A7 no AFAICT should be:
<javier__>
wwilly: but if you look at your 2 examples, you can see that the the .dtsi only has A7's core
<javier__>
IOW, those are not b.L systems
<wwilly>
ok, <javier__> IOW, those are not b.L systems; you mean that I should disable b.L systems? this is ok
<javier__>
wwilly: no, I meant that the examples you have shown are for SoC whose cores are all the same
<LiquidAcid>
ndufresne, i see you're making progress :)
<javier__>
wwilly: you can't disable b.L (unless you remove the A15 or A7 cpu nodes from the DT), what you can enable or disable is the b.L switcher that groups different cores as a virtual CPU
<wwilly>
this patch is intended to work under the 3.10 with HMP scheduler support, and this scheduler don't use b.L switcher if I understand well
<javier__>
wwilly: my point is that you should check if perf counters are expected to work on b.L systems at all or not before attempting to enable in your board
<javier__>
the patch is for the hardkernel 3.10 branch, but I don't know what they could have on top of mainline 3.10
<wwilly>
:(
<wwilly>
quite depressive...
<wwilly>
where do you find this information? interrupts = <0 160 IRQ_TYPE_LEVEL_HIGH>, <0 161 IRQ_TYPE_LEVEL_HIGH>, <0 162 IRQ_TYPE_LEVEL_HIGH>, <0 163 IRQ_TYPE_LEVEL_HIGH>;
<javier__>
wwilly: I checked in the documentation I've access to
<wwilly>
and I could have access to or is it private?
<ndufresne>
LiquidAcid: yes, I'm re-implemented everything using the modifiers now, implement support for that in exynos_drm and lifted the restrictions in the core drm code
<ndufresne>
works if I allocate dummy buffer, but crashes when I pass dmabufs
<javier__>
wwilly: sorry, is not public
<wwilly>
... ok
<ndufresne>
LiquidAcid: the crash seems unrelated to my code though
<LiquidAcid>
ndufresne, you mean when you import dmabufs in the drm?
<ndufresne>
That makes me think, I can use vivid to check that
<wwilly>
so is like I'm kind of fucked up to have PMC working for this board?
<ndufresne>
LiquidAcid: yes, then the exynos_drm maps the dmabuf, it crash, the backtrace only contains core code, so it's hard to figure-out what is wrong
<wwilly>
or just waiting for you to implement it for me?
<LiquidAcid>
ndufresne, and does it work the other way round? creating a buffer with the drm, exporting and importing it into v4l?
<ndufresne>
the HW decoder does not support the importer role
<LiquidAcid>
hmm, wasn't there a patch for this somewhere?
<javier__>
wwilly: I don't know if is possible currently in mainline or not, that's why I told you to check the state of PMU for b.L
<ndufresne>
and it's not implemented by the gstreamer kmssink atm
<javier__>
wwilly: I've in my TODO to look at this but honestly I don't think I'll have time in the short term
<javier__>
wwilly: sorry, too busy with other stuff
<LiquidAcid>
ndufresne, i was thinking of that one, not sure if it does what i think it does
<wwilly>
:'(
<ndufresne>
LiquidAcid: that will make it worst, since with iommu, the 4412 does not even boot
<LiquidAcid>
ndufresne, hmm strange, my 4412 boots fine with iommu
<ndufresne>
actually, the patch properly compile it out without iommu
<ndufresne>
LiquidAcid: with 4.6 ?
<LiquidAcid>
ndufresne, haven't checked 4.6 yet, but it does with 4.5
<ndufresne>
it remains that it should work without that
<LiquidAcid>
ndufresne, so you getting a iommu pagefault early?
<ndufresne>
no, iommu isn't used, the memory is from a reserved cma region
<LiquidAcid>
ndufresne, sure, but i suspect that nobody ever tested that you can import a "foreign" dmabuf into the drm
<ndufresne>
that's why a page fault is strange
<LiquidAcid>
ndufresne, and it's not the fimd/bootloader issue?
<ndufresne>
LiquidAcid: I'm sure daniels tested that on older kernels
afaerber has quit [Quit: Ex-Chat]
<ndufresne>
since on Wayland you can only do that
<ndufresne>
and with GL it is the same, though that goes through the mali driver
<ndufresne>
LiquidAcid: how would that be related ? (fimd/bootloader)
<LiquidAcid>
ndufresne, i don't thin dmabuf importing works for the mali in the 4412
<LiquidAcid>
*think
<ndufresne>
it does now
<LiquidAcid>
which driver version is that?
<daniels>
ndufresne: never on a 4412 ... :\
<ndufresne>
daniels: but it could, I don't think it was related to the 4412 as much as the broken driver
<LiquidAcid>
daniels, yeah, never on utgard i think
<LiquidAcid>
ndufresne, iirc it was first implemented for mitgard
<ndufresne>
anyway, it's implemented, we should fix it then
<daniels>
ndufresne: i also haven't tried exynos at all in months tbh - the driver has had a lot of changes since then, and i got tired of fixing the constant breakage
<ndufresne>
It's a CMA buffer that is being passed, it's the simpliest thing that can be imported
<LiquidAcid>
ndufresne, the kernel driver however can in principle import dmabufs, but the userspace blob doesn't export the functionality through its GL impl
* ndufresne
is a bit frustrated to ear that, since so much energy was put to encourage us to focus on sending dmabuf to GFX and not doing the opposite
<LiquidAcid>
ndufresne, in fact i've spend some time on patching the r5p0 fbdev blob provided by hardkernel to allow dmabuf importing via userspace