<javier__>
bgamari: yes, that's the CCI we were talking about and I don't know about the SAR register
<bgamari>
javier__, what precisely is misconfigured
<bgamari>
It's not clear to me nor the Odroid people
<bgamari>
Also, is the need for a signed bootloader determined by the hardware?
<javier__>
bgamari: I don't know what exacly is misconfigured, I only know that MCPM (Multi cluter Power Management) can't access the CCI registers and the board hang when CPUidle is enabled
<bgamari>
e.g. is there a software mechanism for disabling bootloader signature verification?
<javier__>
bgamari: my understanding is that is determined by the TZ blob that they use but I could be wrong tbh
<bgamari>
TZ?
<javier__>
Trust Zone
<bgamari>
ahh
afaerber_ has joined #linux-exynos
* bgamari
is quite ignorant of the exynos boot process
afaerber has quit [Ping timeout: 250 seconds]
<javier__>
bgamari: is not clear to me what SW component is leaving things in a state that don't allow the kernel to enter the CPU into low-power C states
<javier__>
but you can tell HK folks to try enabling the arm b.L CPUidle driver and see what happen :)
<javier__>
it works pretty well in the Exynos5420/5800 Chromebooks for example
<bgamari>
it may even be in the tz blob I suppose?
<javier__>
bgamari: it could, I don't really know tbh
<bgamari>
it seems that the odriod-specific u-boot changes are just one massive commit
<bgamari>
I'll looking over it right now
<javier__>
bgamari: Ok
steev has quit []
steev has joined #linux-exynos
EmilMedve has quit [Quit: Leaving.]
afaerber_ is now known as afaerber
<javier__>
bgamari: where do you talk with HK folks btw? is in an open channel or?
gordan has left #linux-exynos ["Konversation terminated!"]
masta has joined #linux-exynos
<steev>
is the s5p 4418 considered something different from the exynos?
<arnd>
steev: I would guess that it's closely related to Exynos4
<steev>
arnd: right, i just don't see anything in the mainline kernel for 4418, closest is 4415, so i was wondering if there was a channel where people are working on it
<steev>
i made the same mistake initially when i looked into it :)
<arnd>
the 3.4 source code is useless
<steev>
"duh" ;)
<steev>
that's why i figured find the 4415 trm and compare to the 4418 trm
<arnd>
it has a mach-s5p4418 directory with code that looks nothing like any of the other platforms
<steev>
yeah, it's pretty bad
<arnd>
steev: ok, after looking at the source code a bit more, I suppose that the hardware is also completely unrelated to the s3c/s5p/exynos family we know
<steev>
i hope not
<arnd>
it has a pl011 UART and a pl022 SPI controller
<steev>
arnd: are you looking at the s5p4418-nanopi2 branch or the android stuff
<arnd>
if there is Android user space, that probably has Mali drivers, but not if they ship a regular Linux user space
<steev>
ah
<arnd>
steev: so overall, it looks like someone took the standard ARM reference designs (versatile/realview/vexpress) and built on top of that.
<arnd>
some of the stuff in there is from the older platforms, so it's probably not designed from scratch but built on an older design that came from versatile or integrator rather than realview or vexpress
<arnd>
I don't recognize the i2c controller at all, it looks like a distant cousin of some Renesas part, but that could be coincidence (there are only so many ways to do i2c)
<arnd>
basic functionality can probably be brought up with a mainline kernel without too many problems, but you'd need to write clk and pinctrl drivers from scratch at least
genpaku has joined #linux-exynos
<arnd>
some some of the less important things (crypto, mpeg, ...) might need drivers to be ported from the old kernel, but I haven't look at that at all