1 files changed, 121 insertions, 0 deletions
diff --git a/wiki/Chat_log/20210617-core-chatlog b/wiki/Chat_log/20210617-core-chatlog
new file mode 100644
index 0000000..b66217f
--- /dev/null
+++ b/wiki/Chat_log/20210617-core-chatlog
@@ -0,0 +1,121 @@
+09:35 < geertu> Welcome to today's Core Group Chat Meeting, at a brand new location!
+09:35 < geertu> Agenda:
+09:35 < geertu> 1. Status Updates
+09:35 < geertu> 2. Discussion Topics
+09:35 < geertu> Topic 1. Status updates
+09:35 < geertu> A) What have we done since last time:
+09:35 < geertu> Marek worked on U-Boot (reserved memory node, bootparams allocation,
+09:35 < geertu> position-independent U-Boot on R-Car Gen3), CPLD (content dump on
+09:35 < geertu> Falcon), OpenOCD (R-Car V3U support), and CI (exploring gitlab CI).
+09:35 < geertu> Morimoto-san did Renesas work.
+09:35 < geertu> Shimoda-san got information about R-Car D3 PFC, and inspected the R-Car
+09:35 < geertu> V4H spec.
+09:35 < geertu> Unlrich wandered into international copyright law research.
+09:35 < geertu> Geert converted more DT bindings to json-schema, enabled INTC-EX on
+09:35 < geertu> R-Car M3-W+, reviewwed RZ/G2L patches, prototyped R-Car Gen3e on Gen3,
+09:35 < geertu> removed "renesas,shdma-mux", sent pull requests for v5.14, and added
+09:35 < geertu> generic support for "linux,elfcorehdr" for kdump.
+09:36 < geertu> B) What we plan to do till next time:
+09:36 < geertu> Marek wants to debug the boken Falcon, and continue on Gitlab CI.
+09:36 < geertu> Shimoda-san plans to follow up R-Car V3U IPMMU work and review the R-Car
+09:36 < geertu> Gen3e patches.
+09:36 < geertu> Geert plans to work on improving arm32 kdump, review more RZ/G2L
+09:36 < geertu> patches, handle the R-Car D3 PU{EN,D}_NF[RW]E# bit mismatch, and post more pinctrl
+09:36 < geertu> validation code.
+09:36 < geertu> C) Problems we have currently:
+09:36 < geertu> Marek is worried about his Falcon.
+09:36 < geertu> ---EOT---
+09:36 < geertu> Anything I missed?
+09:36 < geertu> marex: What happened to the Falcon?
+09:37 < marex> geertu: I need to measure the SoM power rails
+09:37 < wsa> marex: was there fire?
+09:37 < marex> wsa: nope, but if I was to speculate, the blower fan failed to spin up and it overheated
+09:38 < marex> it did happen a few times that I had to pinch the fan to start spinning and the som was real damn hot
+09:39 < geertu> Ugh
+09:39 < kbingham> marex, what are your plans with gitlab-ci ? I've installed a local gitlab instance here in my office recently too, with aims of getting a lot more automated builds
+09:39 < marex> kbingham: ssh into runner, build u-boot, scp it to magnus's lab, run u-boot pytest
+09:40 < marex> kbingham: with the abloader, it is possible to switch between two full copies of the ATF/OpTeeOS/U-Boot, so that whole stack can be tested automatically at least on S-XS and ULCB
+09:41 < geertu> marex: So gitlab gets access to Magnus' lab?
+09:41 < marex> kbingham: the dockers in dockers in dockers part of the whole gitlab setup and runners is overwhelming though -- did you set up local docker register yet ?
+09:41 < marex> geertu: no, my plan is to have self-hosted instance without internet access
+09:42 < marex> geertu: ideally something where you ssh with port forwarding
+09:42 < geertu> marex: ok
+09:42 < kbingham> no I haven't made a local registry yet - I was hoping to be able to use the host docker to store the images - but perhaps a registry might end up being needed... Haven't gone DIND yet.
+09:42 < marex> kbingham: I am rather considering the debian salsa kind of setup , to avoid the overdockering
+09:43 < wsa> dockers of dockers ... sounds like the holodeck episodes in StarTrek
+09:43 < kbingham> There are some interesting build scripts for making the docker images I came across (I think for building kernel ... build environments) so I'll share that link when I re-dig it out.
+09:43 < marex> kbingham: and in fact, I was even considering ephemeral containers with systemd-nspawn for the runners
+09:44 < marex> kbingham: just ssh to port, systemd spins up the container, build happens, test happens, container is discarded
+09:45 < kbingham> That's the general concept with docker too though right? (Except in my mind, I would mount a local folder for storing all the outputs, or selected build outputs)
+09:45 < marex> wsa: Docker Squared (tng 2x13)
+09:45 < kbingham> Anyway, nice to know you're looking into it - we can share tips later outside the meeting.
+09:46 < marex> kbingham: with docker, you have to deal with the bloat, and it somehow uses aufs (?)
+09:46 < marex> kbingham: systemd-nspawn is basically part of your init system, and it uses overlayfs which has less overhead as far as I know
+09:47 < kbingham> I've not used -nspawn - but perhaps worth a look. I'm not too worried about bloat. I bought a bloaty-mc-bloatface Ryzen PC to cope with it ;-)
+09:47 < marex> kbingham: I am happy user of nspawn for all things, including OE builds (that's where it really is awesome)
+09:47 < kbingham> (will regret saying that when my 6tb is full, and 32 cores and 128GB ram is no longer enough)
+09:47 < geertu> 128 GB RAM, yummy
+09:48 < geertu> 6 TB SSD?
+09:48 < kbingham> 2 TB SSD 2x2TB HD
+09:48 < marex> kbingham: TNGen4x4 ?
+09:48 < wsa> since I have to leave shortly after 10, can we discuss next meeting now if there are no other topics?
+09:49 < wsa> and maybe share when people are away due to holiday?
+09:49 < geertu> shimoday: So R-Car V4H will be based on V3U? Any estimate when hardware will be available?
+09:50 < geertu> July 15?
+09:50 < wsa> I am away on July 15th
+09:50 < wsa> Actually, my preference would by July 29th
+09:50 < wsa> 22th might be possible, too, though
+09:50 < pinchartl> any of those options work for me
+09:51 < wsa> but if people are on holiday 6 weeks might not be too bad?
+09:51 < moriperi> same here
+09:51 < geertu> I don't have visibility on my holidays yet.  covid rulez :-(
+09:52 < wsa> but if it is just me, then we could have email-only updates this time
+09:52 < moriperi> July 22nd is not good for PeriJapan
+09:52 < wsa> I am away from 5th to 19th definately, and up to 26th likely
+09:52 < geertu> Olympics?
+09:52 < shimoday> geertu: yes. and we will have 2022 Q2 ;)
+09:52 < wsa> so, let's take the 29th?
+09:52 < geertu> OK, I can always delegate the hosting, if needed.
+09:53 < wsa> ok, then let's take the 29th. Thank you!
+09:56 < geertu> Do we have anything else to discuss?
+09:57 < pinchartl> geertu: I'd like to briefly discuss overlays
+09:57 < pinchartl> now that overlay support has landed upstream
+09:58 < kbingham> Oh finally!
+09:58 < pinchartl> should we try to move support for some of the add-ons we have to overlays ?
+09:58 < pinchartl> kbingham: don't rejoice too fast, it may not be what you expect :-)
+09:58 < geertu> That's definitely a good idea.
+09:58 < kbingham>  ... :S
+09:58 < pinchartl> I'm thinking about panels for instance, cameras (for GMSL), ...
+09:58 < geertu> However, the upstream still calls them .dts
+09:58 < pinchartl> that's just a naming issue
+09:59 < pinchartl> kbingham: upstream now has support to compile overlays, but they have to be applied externally
+09:59 < geertu> There are plans to use .dtso instead
+09:59 < pinchartl> by the boot loader for instance
+09:59 < geertu> pinchartl: No, they are applied during the build process
+09:59 < pinchartl> they can be applied by u-boot
+10:00 < pinchartl> I do that
+10:00 < geertu> OK, you can also apply them yourself.
+10:00 < pinchartl> but there's not standard solution for the "DT connector" problem AFAIK
+10:02 < geertu> But we can create the ulcb+kf dts from a base ulcb.dtb and a kf overlay now
+10:02 < geertu> During the Linux build
+10:02 < kbingham> if we can apply at build, we should at least be doing that instead of the awkward '#includes' we've been doing for GMSL overlays.
+10:02 < geertu> s/ulcb+kf dts/ulcb+kf dtb/
+10:02 < pinchartl> is there a standard workflow for merging the overlays at build time ?
+10:04 < geertu> pinchartl: You mean a rule to build a .dtb from a base .dtb and overlay files?
+10:04 < pinchartl> yes
+10:05 < geertu> 15d16d6dadf6947a ("kbuild: Add generic rule to apply fdtoverlay")
+10:05 < geertu> v5.13-rc1+
+10:05 < pinchartl> that doesn't support passing parameters to overlays, right ?
+10:05 < geertu> Nope
+10:06 < pinchartl> for instance an overlay that adds a camera, and would be applied multiple times, attached to a different GMSL port
+10:06 < pinchartl> is there any standard solution for that, even if not in the kernel tree ?
+10:07 < geertu> Not yet, AFAIK
+10:07 < geertu> https://www.raspberrypi.org/documentation/configuration/device-tree.md
+10:07 < pinchartl> that's exactly what I was thinking about
+10:07 < pinchartl> it's all implemented in their closed-source boot loader
+10:09 < pinchartl> well, in any case, for things that don't need parameters, we can start already
+10:09 < pinchartl> for the rest, it may be too early
+10:10 < geertu> Time to moe to MM?
+10:10 < geertu> s/moe/move/
+10:10 < pinchartl> sure
+10:11 < geertu> Thanks for joining, and have a nice continued day!