diff options
| -rw-r--r-- | wiki/Chat_log/20210617-core-chatlog | 121 |
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! |