07:26 <PabloPL> mszyprow_: Got boot mainline kernel on exynos7580 with logs - problem was with sboot. Even though it uses a device tree it looks like it's not passing fdt correctly to kernel (or it's passing something different)

07:27 <mszyprow_> PabloPL: nice

07:27 <PabloPL> mszyprow_: Had to use appended dtb (like on s5pv210) for arm64 ...

07:27 <PabloPL> mszyprow_: Now it fails on ioream for gic interrupt-controller....

07:29 <PabloPL> mszyprow_: Looking at oops it fails at check "Don't allow RAM to be mapped" in ioremap

07:47 <PabloPL> fixed, wrong setup of memory node...

09:03 <PabloPL> exynos7580 has 8 cores, but in some devices only 4 of them are enabled (for example A3 2016 - SM-A310F). How should this be handled in base dtsi? (not sure if for example all cores on those devices are fully working etc)

10:53 <krzk> Hi Pablo

10:56 <krzk> PabloPL: hi!

10:56 <krzk> Cool news

10:56 <krzk> for the 4 cores

10:56 <krzk> There are few ways how this can be done. First of all SM-A310F does not have 7580 but 7578

10:57 <krzk> and in such case it should be probably different DTSI, sharing common part

10:58 <krzk> Exynos5420/5422/5800 have something like this already - share a lot, but CPU configuration is separate.

11:00 <PabloPL> ok, so maybe 7578 are just 7580 where second group of cores is not working correctly (for example didn't passed tests etc). in kernel source it's named 7580 and also bootloader is saying the same

11:01 <krzk> PabloPL: that's interesting... I wonder what revision does it have (report)

11:03 <PabloPL> i can check in vendor kernel , there was some addition to chipid driver

11:03 <PabloPL> krzk: for now i'm stuck with this https://gist.github.com/PabloPL/db7b75afc6e009c2f38a183fc4f7cf57

11:04 <krzk> PabloPL: disable arch timer and use only exynos mct (or bump exynos mct clocksource higher to be the main timer)

11:05 <krzk> there are known issues with Arch timer on Exynos - it is tightly coupled with MCT (or even the same block physically) so certain hacks are needed to make it running

11:05 <PabloPL> ok, in vendor there are some "magic" going in timers (for example disabling only half of it, if some flag in dts is set and "use it as clocksource only")

11:06 <PabloPL> i hope that my clk driver is working...i want to run dwmmc now

11:07 <krzk> mszyprow_ was sending some patches necessary for ARMv8 Exynos for its timer - you can pick them up for your tests

11:08 <mszyprow_> PabloPL: this will fix timer inconsistency: https://patchwork.kernel.org/patch/10630653/ https://patchwork.kernel.org/patch/10630651/

11:08 <krzk> https://patchwork.kernel.org/project/linux-samsung-soc/list/?series=32371&state=*

11:09 <PabloPL> ok, will check this. thanks

11:14 <PabloPL> krzk: about id in vendor sources i've only found EXYNOS7580_SOC_ID 0xE7580000

11:22 <PabloPL> will try to boot all 8 cores, we'll see what it is

11:25 <krzk> I mean, what the SoC reports

11:25 <krzk> I guess that in such case it repotrs 0xE7580000...

11:25 <krzk> you can also dump the other regs from chip id (the bin etc)

11:26 <PabloPL> [ 0.314105] smp: Brought up 1 node, 8 CPUs

11:26 <PabloPL> [ 0.369420] SMP: Total of 8 processors activated.

11:26 <krzk> see https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git/commit/?h=for-next&id=40d8aff614f71ab3cab20785b4f213e3802d4e87

11:27 <krzk> PabloPL: ok, but do you have 7580 or this 7578 (4 cores officially)?

11:28 <PabloPL> krzk: in vendor it's all named 7580, sboot also returns this information. There are 2 7580.dtsi files in vendor sources - in one there are just 4 cores cut from it (also some minimal pinctrl changes)

11:28 <krzk> PabloPL: I mean, the device you have

11:28 <krzk> what do you have?

11:28 <PabloPL> krzk: Also saw some time ago that on xda developers people did found and tested it with 8 cores

11:28 <PabloPL> krzk: A3-2016

11:29 <PabloPL> it should have 4 cores officially

11:30 <PabloPL> EXYNOS7580 EVT 0.2 (Base on ARM CortexA53)

11:30 <PabloPL> from bootloader

11:30 <krzk> then either the difference is be stored in the other chipid registers, or this is pure bollocks :)

11:30 <krzk> anyway, it is well known behavior from all chip manufacturers - develop actually one hardware :)

11:31 <PabloPL> good that they didn't used fuses for it

11:31 <krzk> but probably you should not mainline it as 7580 (8 core) - some people might be affected

11:31 <PabloPL> that's why i've asked about it

11:31 <PabloPL> saw some reports on xda where people enabled 8 cores and had some problems with stability

11:32 <PabloPL> question is, should this stay as 7580 or change to 7578, but i'll think about this when pushing patches to mainline

11:33 <PabloPL> for now mmc/sdcard and wifi later, to put some normal os on it...

11:35 <mszyprow_> PabloPL: maybe it easily overheats if 8 core are running

11:37 <PabloPL> mszyprow_: and battery drains probably fast. for now it'll stay as 4 cores

11:40 <krzk> Then DTSI should be 7578...

12:02 <PabloPL> mrzyprow_: Tested those patches, now that error is gone. Thanks!

12:07 <PabloPL> hm...now got that error/similar again

12:07 <PabloPL> after a while

15:44 <PabloPL> krzk: Are You there?

15:48 <PabloPL> krzk: i had problem with patch https://patchwork.kernel.org/patch/10646937/ . with mct and arch timer in dts (where mct is first), i was getting kernel panic "Unable to initialise architected timer" which looks like arch_timer_get_rate returned 0 (but i got in dts clock-frequency set for timer)

15:48 <PabloPL> krzk: after removing that patch but having both mct and arch timer (in this order, the same like it's done for 5433), there is no error and no kernel panic