diff options
| -rw-r--r-- | wiki/Chat_log/20201217-core-chatlog | 114 |
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 |