pekka30 has joined #linux-exynos
EmilMedve has joined #linux-exynos
EmilMedve has quit [Quit: Leaving.]
EmilMedve has joined #linux-exynos
EmilMedve has quit [Quit: Leaving.]
steev has joined #linux-exynos
gordan has joined #linux-exynos
EmilMedve has joined #linux-exynos
<bgamari> javier__, the CCI being configured in secure mode by the odroid bootloader is the Cache Coherent Interconnect, right?
<bgamari> javier__, and if so, is the register being incorrectly set the SAR register?
<bgamari> e.g. http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0470j/index.html
<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: try thic patch https://lkml.org/lkml/2015/8/28/137
<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
<arnd> at some point the s5p line got renamed to exynos: s5pc110 became exynos 3 (though we left the old name in Linux) and S5PV310 became exynos4
<arnd> the naming is often arbitrary and some parts go under different names, but it's more likely that exynos 4415 and s5p4418 are a bit different
<steev> i'm guessing the "easiest" way is to read the trms ?
<arnd> so either you need a new .dtsi file, or some actual minor source changes
<steev> compare not read
<arnd> I would try reading the source code that comes with this board
<steev> that's the nanopi
<steev> not the nanopi2
<steev> nanopi2 uses a 3.4 kernel
<arnd> oh
<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
<steev> ah yeah you are
<arnd> and synopsys MMC
<arnd> Samsung has their own implementations of the above that they use in all their other designs
<steev> oh, i get what you're saying now, yeah
<arnd> so my best guess is that this came into samsung as part of some company aquisition, and got renamed to fit somewhere into their portfolio
<steev> did sammy acquire nxp? i thought nxp/freescale merged
<arnd> reminds me of some STmicroelectronics or NXP chips, but the components are really generic, so anyone could do that
<steev> it's definitely nxp chips
<steev> ir was?
<arnd> NXP had tons of spinoffs that ended up in other companies
<arnd> ST-ericsson for instance had chips from both NXP and Ericsson
<arnd> and now they are part of ST
<arnd> I saw NXP mentioned in the source code, but that could also refer to "nexell", the company that wrote the Linux code for s5p4418
<steev> nexell
<steev> actually i think that's what it means
<arnd> ah, and there is a MALI_T6XX, which was conveniently left out of the kernel tree
<arnd> ah, wait. it's there
<steev> i don't think they actually use it
<arnd> I was thinking this might be related to PNX847x, but that went from NXP to Trident and then to Sigma, and it contains an imagination GPU
<steev> a mali gpu i mean
<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
<arnd> and there we go, this was apparently an earlier version: http://www.nexell.co.kr/chi/pro/pro01.html
<arnd> nexell is apparently a fabless SoC maker, not just the company that made the Linux port as I thought
<arnd> Nexell s5p6818 is based on Cortex-A53 but running a 32-bit kernel
<arnd> very similar source code