From be2ddad83742b87fde65bf2e016aaed6b90b4fe1 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Thu, 7 Oct 2021 10:16:22 +0200 Subject: wiki: Add Core chatlog for 2021-10-07 Signed-off-by: Geert Uytterhoeven --- wiki/Chat_log/20211007-core-chatlog | 103 ++++++++++++++++++++++++++++++++++++ 1 file changed, 103 insertions(+) create mode 100644 wiki/Chat_log/20211007-core-chatlog (limited to 'wiki/Chat_log/20211007-core-chatlog') 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! -- cgit v1.2.3