summaryrefslogtreecommitdiff
path: root/wiki
diff options
context:
space:
mode:
authorGeert Uytterhoeven <geert+renesas@glider.be>2021-10-07 10:16:22 +0200
committerGeert Uytterhoeven <geert+renesas@glider.be>2021-10-12 15:55:56 +0200
commitbe2ddad83742b87fde65bf2e016aaed6b90b4fe1 (patch)
tree189c733ebbfadc4ae238acdb771775964bbd65b3 /wiki
parentda3bd413869d2f1111e086733676e46d49f842b2 (diff)
wiki: Add Core chatlog for 2021-10-07
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Diffstat (limited to 'wiki')
-rw-r--r--wiki/Chat_log/20211007-core-chatlog103
1 files changed, 103 insertions, 0 deletions
diff --git a/wiki/Chat_log/20211007-core-chatlog b/wiki/Chat_log/20211007-core-chatlog
new file mode 100644
index 0000000..6825e44
--- /dev/null
+++ b/wiki/Chat_log/20211007-core-chatlog
@@ -0,0 +1,103 @@
+09:34 < geertu> Welcome to today's Core Group Chat Meeting!
+09:34 < geertu> Agenda:
+09:34 < geertu> 1. Status Updates
+09:34 < geertu> 2. Discussion Topics
+09:34 < geertu> Topic 1. Status updates
+09:34 < geertu> A) What have we done since last time:
+09:34 < geertu> Kieran tested R-Car V3u INTC-EX and enabled the SW46-49 GPIO-keys on
+09:34 < geertu> Falcon.
+09:34 < geertu> Marek upstreamed the LMB patchset for U-Boot and Gen3 patches for ATF,
+09:34 < geertu> and made the gitlab-ci runner build all artifacts.
+09:34 < geertu> Morimoto-san did Renesas Work.
+09:34 < geertu> Shimoda-san submitted v2 of IPMMU support for R-Car V3U.
+09:34 < geertu> Geert attended virtual conferences (Kangrejos, LPC, ELC), added
+09:34 < geertu> interrupt support to the gpio-aggregator, sent pull requests for v5.16,
+09:34 < geertu> resubmitted arm/kdump DT support for kexec-tools, and reviewed more
+09:34 < geertu> RZ/G2L patches.
+09:35 < geertu> B) What we plan to do till next time:
+09:35 < geertu> Kieran plans to retest INT-EX on R-Car V3U.
+09:35 < geertu> Marek plans to work on U-Boot (LMB board-specific oddities), ATF (more
+09:35 < geertu> upstreaming), and CI (tie into Magnus's lab).
+09:35 < geertu> Morimoto-san plans to continue doing Renesas Work.
+09:35 < geertu> Shimoda-san plans to pepare initial R-Car S4 support.
+09:35 < geertu> Geert plans to send more pull requests for v5.16, review more RZ/G2L
+09:35 < geertu> patches, and post more pinctrl validation code.
+09:36 < geertu> C) Problems we have currently:
+09:36 < geertu> Morimoto-san is sufficering from broken NFS re-export in Ubuntu.
+09:36 < geertu> Geert feels there were too many conferences in September.
+09:36 < geertu> ---EOT---
+09:36 < geertu> Anything I missed?
+09:36 < geertu> shimoday: I'm looking forward to S4 support ;-)
+09:36 < geertu> G4MH is yet another v850 derivative?
+09:37 < shimoday> geertu: yes :)
+09:38 < geertu> Looks like it's gonna outlive SH by a few decennia
+09:39 < shimoday> geertu: i think so (v850, today's name is RH850)
+09:40 < geertu> Topic 2. Discussion Topics
+09:40 < geertu> Any suggestions for topics to discuss?
+09:41 < damm> Opinions on HF RPC locking / unlocking?
+09:41 < marex> platform security, so locked :(
+09:42 < damm> but where does this come from? it seems to me that someone is confusing a final product with a development system
+09:42 < wsa> for development, unlock. for customers, upstream: lock?
+09:42 < wsa> and maybe for remote-labs: also lock ;)
+09:43 < damm> i thought we wanted to be able to upgrade the entire boot stack even on remote systems?
+09:43 < wsa> that would be great, but maybe it should be opt-in?
+09:44 < damm> so how are we supposed to update the boot stack?
+09:44 < damm> not? =)
+09:45 < damm> i would call it extremely inconvenient at this point
+09:45 < damm> the default
+09:45 < marex> that
+09:45 < marex> I just unlock it on all the systems on first update
+09:46 < marex> but that requires manual work and isnt what renesas ships by default
+09:46 < damm> sure, but it means we effectively are using a fork
+09:46 < damm> is the behaviour the same on ULCB and Salvator-X?
+09:47 < marex> yes and yes
+09:47 < geertu> damm: It depends what you want to develop: a system that resembles the final product, or a system where you develop core parts
+09:47 < damm> that's right
+09:48 < damm> anyway, i guess i'm the only one being annoyed by the default setting
+09:49 < marex> some flip switch might be a nice compromise
+09:49 < marex> like one of the MD pin flip switches
+09:49 < damm> some code components are performing run time checks of MD pin settings already, right?
+09:50 < damm> so if we could change the behavior of the HF RPC lock mechanism to be run time then that might make the default slightly more convenient?
+09:51 < damm> what would the drawback be of such solution i wonder?
+09:52 < marex> if you made it configurable such that you can select at compile time from on/off/use-a-switch , nothing
+09:52 < marex> renesas wanted it to be locked by default due to some sort of policy
+09:52 < marex> the policy might need to be revisited
+09:52 < pinchartl> what would be the drawback of unlocking it by default, and only locking it when we need to test something in a situation where it's locked ? how often would that need arise ? this all sounds a bit like mental masturbation to me
+09:52 < marex> which reminds me
+09:53 < marex> pinchartl: policy (TM)
+09:53 < pinchartl> (I'm talking about our own development boards and our remote labs, not the default form Renesas)
+09:53 < pinchartl> s/form/from/
+09:53 < marex> pinchartl: if you want to test blobs from renesas, you would want them to be unlocked by default too
+09:53 < damm> marex mentions that renesas wanted it to be locked by default
+09:54 < damm> but when we communicated about that perhaps we did not consider the possibility or asking to adjust the policy
+09:54 < geertu> marex: configurable such that you can select at compile time from on/off/use-a-switch is not that different from what we have now?
+09:54 < geertu> currently we have configurable such that you can select at compile time from on/off
+09:54 < geertu> and the default (and all build instructions) are lockd
+09:54 < geertu> locked
+09:54 < pinchartl> for what it's worth, my experience with similar features in product development timeline is that they only get enabled by default in later development stages, not in the beginning
+09:55 < damm> i wish we should have a single sane setting that would allow run time selection
+09:55 < marex> like an OTP fuse ?
+09:55 < damm> that might be something
+09:58 < damm> what is MD5 used for again?
+09:59 < geertu> damm: calculating a hash
+10:00 < geertu> for obsolete authentication
+10:00 < damm> if we calculate a hash then we also want RPC HF locked?
+10:00 < geertu> Oops, wrong MD5 ;-)
+10:00 < damm> hehe
+10:01 < damm> otherwise we are considered insecure anyway
+10:01 < damm> no need to add security to an insecure system?
+10:01 < geertu> MD5: 0 Setting prohibited, 1 Normal boot
+10:01 < damm> anyway, sorry for taking too much of your time
+10:01 < damm> i just wish we could have a better default configuration
+10:02 < damm> somehow
+10:03 < damm> next topic =)
+10:03 < geertu> Next meeting?
+10:03 < geertu> or anything else?
+10:03 < pinchartl> 4th of November ?
+10:03 < geertu> Fine for me (11th is a holiday)
+10:04 < wsa> Nov 4th is good for me, too
+10:04 < shimoday> 4th is good for me, too
+10:04 < neg> Works for me
+10:04 < geertu> critical mass reached
+10:04 < wsa> heh
+10:05 < geertu> Thanks for joining, and have a nice continued day!