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!