1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
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
|
