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!