wiki: Add Core chatlog for 2020-12-17

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>

1 files changed, 114 insertions, 0 deletions

diff --git a/wiki/Chat_log/20201217-core-chatlog b/wiki/Chat_log/20201217-core-chatlog
new file mode 100644
index 0000000..908f00e
--- /dev/null
+++ b/wiki/Chat_log/20201217-core-chatlog
@@ -0,0 +1,114 @@
+09:30 < geertu> Welcome to today's Core Group Chat Meeting!
+09:30 < geertu> Agenda:
+09:30 < geertu> 1. Status Updates
+09:30 < geertu> 2. Discussion Topics
+09:30 < geertu> Topic 1. Status updates
+09:30 < geertu> A) What have we done since last time:
+09:30 < geertu> Marek worked on Linux (PCIe L1 link state and 32bit MSI fixes) and OpTee
+09:30 < geertu> (CPU core count auto-detection, DRAM layout passing).
+09:30 < geertu> Morimoto-san continued V3U-Falcon shipping paper work.
+09:30 < geertu> Niklas submitted R-Car Gen3 TMU and V3U thermal clock patches.
+09:30 < geertu> Shimoda-san attended OSSJ and ALS2020, and submitted BD9574MWF support.
+09:30 < geertu> Ulrich worked on PFC for R-Car V3U version 2.
+09:30 < geertu> Geert sent the second batch of pull requests for v5.11, reviewed the
+09:30 < geertu> R-Car V3U pinctrl driver, worked on obtaining the start of physical
+09:30 < geertu> memory from DTB, and fixed CMT1 on APE6-EVM.
+09:31 < geertu> B) What we plan to do till next time:
+09:31 < geertu> Marek plans to work on Linux (PCIe follow-up) and OpTee (updates).
+09:31 < geertu> Morimoto-san plans to enjoy vacation, and suffer paperwork.
+09:31 < geertu> Niklas plans to enjoy vacation.
+09:31 < geertu> Shimoda-sa plans to enjoy vacation, collect more information about R-Car
+09:31 < geertu> Gen3e, and continue BD9574 work.
+09:31 < geertu> Ulrich plans to finish PFC for R-Car V3U version 2.
+09:31 < geertu> Geert plans to enjoy holidays, repost R-Car V3U gpio, upport R-Car V3U
+09:31 < geertu> SYS-DMAC support, and finish obtaining the start of physical memory from
+09:31 < geertu> DTB.
+09:31 < geertu> C) Problems we have currently:
+09:31 < geertu> Morimoto-san is looking for socially-accepted ways to improve paperwork
+09:31 < geertu> progress.
+09:31 < geertu> Shimoda-san is worried about not getting further Gen3e information.
+09:31 < geertu> Ulrich is suffering from conflicts in the R-Car V3U PFC documentation.
+09:32 < geertu> ---EOT---
+09:32 < geertu> Anything I missed?
+09:32 < geertu> s/-sa/-san/
+09:32 < geertu> Topic 2. Discussion Topics
+09:33 < wsa> status of the PFC driver?
+09:33 < geertu> Do we already know what causes the QSPI ROM breakage?
+09:33 < wsa> V3U PFC
+09:33 < geertu> It seems to work, if I add my own pfc node.
+09:33 < geertu> uli__: ?
+09:34 < uli__> working on it, there are numerous little issues, but should all be sorted out soon
+09:34 < wsa> i'd like to start with V3U IO testing soon, so if there was a branch/patches to pull in, I'd be thankful
+09:36 < uli__> probably before christmas for version 2
+09:36 < uli__> but v1 is rumored to work reasonably well :)
+09:37 < wsa> uli__: ok, then i'll use this one and see how it goes...
+09:37 < wsa> uli__: when (== which daytime) do you use the board mostly?
+09:37 < shimoday> geertu: according to investigating team,
+09:37 < uli__> wsa: late afternoon, i guess
+09:38 < shimoday> qspi will be written as protect mode into one time program register
+09:38 < shimoday> also will be write wrong data into sector 0 or like that by linux kernel
+09:38 < shimoday> if linux uses both qspi and mmc driver, the issue happened.
+09:39 < shimoday> but, we use either qspi or mmc, the issue didn't happen
+09:39 < shimoday> this is the current report from the team i heard
+09:40 < shimoday> we don't know why using both qspi and mmc causes this issue yet though
+09:40 < geertu> shimoday: OK, so the upstream kernel is fine ;-)
+09:40 < shimoday> geertu: yes :)
+09:41 < moriperi> shimoday: 1st written is by uboot, 2nd is linux, correct ?
+09:41 < wsa> uli__: will fit nicely. I think it will be morning hours and early afternoon for me
+09:41 < moriperi> s/uboot/non linux/
+09:41 < geertu> wsa: uli__: And we have the channel falcon lock...
+09:42 < wsa> sure
+09:42 < shimoday> moriperi: sorry, what is "1st written"?
+09:43 < moriperi> Oops, 100% linux issue ?
+09:43 < wsa> but good scheduling helps lock contention :)
+09:43 < moriperi> I thought uboot vs linux mismatch
+09:44 < shimoday> moriperi: linux causes this issue, yes. but, we don't know the root cause. (SW or SoC or Board)
+09:45 < moriperi> OK, I see. thanks
+09:45 < moriperi> uboot and/or IPL is not related ?
+09:46 < shimoday> moriperi: from the report, we don't know whether these are related for now :)
+09:47 < moriperi> OK. my understanding is that it happen on *latest* BSP. and we are using *old* BSP base uboot/IPL.
+09:47 < damm> using SCIF D/L mode should always work right?
+09:47 < damm> independently of fried on-board memory fsck-up
+09:48 < shimoday> damm: i think so
+09:48 < shimoday> even if qspi is protected by one time program register, we can modify the register after power on
+09:49 < damm> not so fun if soldered storage has fuses blown though
+09:49 < damm> but if otp can be overriden then no biggie
+09:49 < marex> shimoday: by otp, dont you rather mean "non-volatile register" ? :)
+09:51 < shimoday> marex: you're correct. it seems non-volatile register.
+09:52 < damm> good. then i guess the potential issue can be fixed somehow at least.
+09:53 < geertu> moriperi: Since you say we are bot using the latest BSP, rcar-4.1.0.rc4 is not the latest BSP? Or what do you mean?
+09:53 < geertu> s/bot/not/
+09:53 < geertu> Which version should we not boot on Falcon?
+09:53 < moriperi> let me check
+09:55 < moriperi> NG: BSP v4.1.0-rc1
+09:56 < moriperi> OK: BSP v4.0.1-rc1
+09:56 < moriperi> we are using v4.0.1-rc1
+09:56 < geertu> which is v5.4-based
+09:56 < geertu> while the bad one is v5.4.72-based
+09:56 < moriperi> Magnus's current one, and I'm trying to ship one
+09:57 < shimoday> according to the bsp report, v4.1.0.rc3 is also OK because it disables QSPI by dts
+09:58 < moriperi> BSP v4.1.0-rc1 = v5.4.72
+09:58 < moriperi> BSP v4.0.1-rc1 = v5.4.0
+10:00 < geertu> OK
+10:00 < geertu> Anything else to discuss?
+10:00 < marex> is there any documentation for the rcar3 TRNG in CCREE ?
+10:00 < marex> it would be useful to have an RNG in optee, so we can enable ASLR
+10:01 < kbingham> I have a maybe core question about V3U: I've seen reference to V3U-AD is that the part / soc name ?
+10:02 < kbingham> "Figure 32.24 shows node value of all sub modules implemented in all VSPs of R-Car V3U-AD"
+10:04 < pinchartl> another question, when should the next meeting take place ?
+10:05 < geertu> Jan 14?
+10:05 < geertu> or is that too early?
+10:05 < wsa> sounds good to me
+10:06 < shimoday> sounds good to me
+10:06 < moriperi> sounds good to me, but maybe noting to report :)
+10:06 < shimoday> marex: i checked a documentation roughly, but i could not find TRNG
+10:06 < shimoday> marex: so, i'll ask charge of person later
+10:06 < marex> shimoday: I know, that's why I'm asking ; geertu suggested its part of the cryptocell
+10:07 < marex> shimoday: thank you
+10:07 < wsa> moriperi: maybe you get a shotgun for XMas, then you can report something
+10:07 < geertu> marex: s/cryptocell/Secure Engine/
+10:07 < moriperi> wsa: :)
+10:07 < geertu> cryptocell \in Secure Engine
+10:08 < geertu> Thanks for joining, and have a nice continued day!
+10:08 < shimoday> marex: ah, "a documentation" meant internal secret secure engine manual :)
+10:08 < shimoday> not hardware manual