09:31 < geertu> Welcome to today's Core Group Chat Meeting! 09:31 < geertu> Agenda: 09:31 < geertu> 1. Status Updates 09:31 < geertu> 2. Discussion Topics 09:31 < geertu> Topic 1. Status updates 09:31 < geertu> A) What have we done since last time: 09:31 < geertu> Kaneko-san posted DRIF and TMU PFC support for E3 and M3-N. 09:31 < geertu> Marek worked on U-Boot (SDHI, multi-DTB, Gen2 conversion, PSCI), ATF 09:31 < geertu> (reset BAR and PCIe), and Linux (eMMC, thermal, TDSEL, GPIO regulator 09:31 < geertu> regressions). 09:31 < geertu> Morimoto-san forwarded a deadlock issue, and worked on the PeriJect 09:31 < geertu> viewer. 09:31 < geertu> Niklas attended the face-to-face periperi Core meeting. 09:31 < geertu> Simon worked on Z2 clock support and CPUfreq for E3 and derivatives, and 09:31 < geertu> discussed about CPUidle. 09:31 < geertu> Ulrich reviewed PFC patches and resubmitted R-Car H1 HSCIF PFC support. 09:31 < geertu> Geert worked on PFC table validation, upgraded firmware, enabled the 09:31 < geertu> GPIO expander on Ebisu, and added suspend/resume support to IPMMU. 09:33 < geertu> B) What we plan to do till next time: 09:33 < geertu> Kaneko-san plans to upport temperature calculation fixes for R-Car Gen3 09:33 < geertu> and RZ/G2 SoCs. 09:33 < geertu> Marek plans to continue helping Goda-san with U-Boot SDHI, and improve 09:33 < geertu> ATF reset address handling. 09:33 < geertu> Morimoto-san plans to continue work on the PeriJect viewer. 09:33 < geertu> Simon plans to add ZG clock support, and follow-up R-Car E3 PMIC 09:33 < geertu> enablement and thermal zone IPA. 09:33 < geertu> Geert will investigate the reported deadlock, and plans to flush his 09:33 < geertu> pinctrl backlog. 09:34 < geertu> C) Problems we have currently: 09:34 < geertu> Morimoto-san is suffering from delayed email off his island. 09:34 < geertu> Simon needs to upgrade firmware on Ebisu. 09:34 < geertu> Geert wonders about the IPMM driver using the same context for all uTLBs 09:34 < geertu> on the same IPMMU instance, requiring e.g. SATA and PCIe to be assigned 09:34 < geertu> together to host or (the same) guest. 09:35 < geertu> --- 09:35 < geertu> Anything I missed? 09:37 < pinchartl> what is this delayed e-mails issue ? 09:37 < geertu> Perhaps also applicable to irc? 09:37 < Marex> pinchartl: what issue , care to elaborate ? 09:37 < geertu> Vger or Google delaying emails from JP? 09:38 < neg> geertu: I'm just curious if you saved the binaries you produced to update the fw on all your boards so they can be reused ? :-) 09:38 < pinchartl> Marex: I'm referring to Morimoto-san's reported problem 09:39 < geertu> neg: Of course I have ;-) 09:39 < Marex> pinchartl: oh 09:39 < geertu> Now, where to put them, to avoid a GPL class action lawsuit ;-) 09:39 < Marex> geertu: ATF is BSD 09:40 < Marex> sadly 09:40 < geertu> Topic 2. Discussion Topics 09:40 < neg> I'm sure there are no licensing issues in the osdr wiki... maybe... 09:41 < Marex> neg: or just build the binaries yourself ? 09:42 < geertu> My firmware images are not perfect, they don't work with current mainline Linux due to HS400 09:43 < geertu> And given Marex' track record, firmware images become obsolete, soon 09:43 < Marex> geertu: same could be said about Linux 09:43 < Marex> bugs just get fixed 09:44 < geertu> Yes, that's why we don't upload Linux kernel binaries to the osdr wiki 09:45 < Marex> geertu: well, technically we could use travis to upload ATF and U-Boot binaries to some github repo, but they would only be compile-tested 09:45 < neg> Marex: I tried at some point, but digging in bitbake recipes to decode ancient hieroglyphs to learn the secret of what options is needed for each board was not my definition of a fun time 09:45 < Marex> geertu: essentially build on push and deliver somewhere 09:45 < Marex> neg: clone mbedtls, then MBEDTLS_DIR=/path/to/mbedtls/ make -j9 bl2 bl31 rcar PLAT=rcar LSI=M3N MACHINE=salvator-x SPD=opteed RCAR_BL33_EXECUTION_EL=1 LOG_LEVEL=50 DEBUG=0 RCAR_RPC_HYPERFLASH_LOCKED=0 09:45 < Marex> neg: that's about it for 77965 S-XS 09:46 < wsa> didn't we agree in Brussels to have a wiki page for the build instructions? 09:46 < geertu> IMHO we need proper config files, like for Linux and U-Boot, instead of all these FOO=BAR options 09:46 < geertu> wsa: Yes! 09:46 -!- morimoto [~user@relprex2.renesas.com] has joined #periperi 09:47 < pinchartl> wsa: I'd really like that 09:47 < morimoto> sorry for my delay 09:47 < Marex> geertu: well we can add it to elinux wiki 09:47 < geertu> morimoto: You're forgiven 09:47 < Marex> geertu: basically a transcript of the CI yaml https://travis-ci.org/marex/arm-trusted-firmware-1/builds/496068832/config 09:47 < geertu> Marex: Good, are you "we"? 09:47 < morimoto> geertu: thanks. I was under Renesas talk 09:48 < Marex> morimoto: おはようございます 09:48 < morimoto> Marex: good morning :) 09:48 < Marex> maybe not ... ^_^' 09:48 < Marex> good evening :) 09:48 < morimoto> Ahh, OK (^ ^); 09:49 < geertu> morimoto: How's Renesas doing? 09:49 < neg> There are already fw tarballs in the osdr wiki so I thought it could be nice if new ones where added so they where easier to consume and all not interested in fw hacking could run the same binaries and hopefully share the bug discovery process. No big deal, build instructions on a wiki are also fine with me 09:49 < Marex> geertu: "we" ? 09:50 < morimoto> geertu: I will have meeting with Magnus next week. about its topic 09:50 < geertu> Marex: "we can add it to elinux wiki" 09:50 < wsa> hi morimoto-san! 09:50 < morimoto> wsa: Hi 09:50 < pinchartl> neg: I think it would be best to ease the firmware build instead, and making it as easy as downloading the binaries from the wiki. that way we'll ensure we always run up-to-date firmwares 09:52 < geertu> pinchartl: +1 09:53 < Marex> pinchartl: and who would put those binaries on the wiki ? 09:53 < Marex> pinchartl: the travis CI tool can put them on github automatically 09:53 < pinchartl> Marex: you got me wrong, I don't think we should have binaries in the wiki 09:53 < geertu> Marex: No one, we go for the one-click-build-from-source(TM) 09:54 < Marex> pinchartl: I need another coffee 09:54 < pinchartl> we should have a documented build procedure that makes building firmwares for a board as easy (or easier) than downloading a binary from the wiki 09:54 < Marex> pinchartl: I just added an item into taskwarrior about documenting the ATF build on elinux wiki 09:55 < pinchartl> Marex: thank you 09:55 < pinchartl> should we have per-board instructions ? 09:55 < Marex> a website like the u-boot for gen3 one would be preferred 09:55 < pinchartl> would it make sense to have a git tree with scripts to build the firmware for each board ? 09:55 < Marex> most of the stuff is the same for all boards, it's just parameters that differ 09:56 < pinchartl> not only ATF, but building minimon would be useful too 09:56 < pinchartl> I struggled with that 09:57 < neg> I agree that making the build easier would remove the need for binaries and build instructions. All I'm saying is that everytime I had some time and wanted to update fw I stopped after spending too much time trying to figure out what to build and how for each board 09:57 < geertu> minimon is not public, is it? 09:57 < Marex> pinchartl: speaking of monimon ... 09:57 < Marex> morimoto: is there source of monimon 5.x available somewhere ? :) 09:58 < pinchartl> geertu: no, but https://github.com/renesas-rcar/flash_writer is and I've had some success using it for a few boards 09:58 < pinchartl> so we could standardize our instructions on that 09:58 < pinchartl> or get minimon released 09:58 < morimoto> Marex: monimon ? minimon ? 09:58 < pinchartl> neg: last time I wanted to update the Draak firmware it took me a whole day 09:59 < Marex> morimoto: jupp, the piece of software that you start from SCIF loader and use to update the flash on Gen3 09:59 < pinchartl> unlike other boards, there's no minimon binary for Draak in the wiki, that didn't help 09:59 < Marex> pinchartl: the draak in Magnus's vlab supports 'fitupd' from U-Boot 10:00 < Marex> pinchartl: wait until I get physical access to it, then I'll push proper ATF port upstream and then you can unlock HF and update via U-Boot 10:00 < pinchartl> Marex: mine doesn't :-) 10:00 < pinchartl> and to update u-boot I needed a flash writer 10:00 < Marex> pinchartl: the current ATF port is kinda meh, it's better than what it came with, but still downstream 10:00 < Marex> pinchartl: well, only once ... 10:00 < pinchartl> sure 10:00 < Marex> pinchartl: soon you'll be able to use U-Boot SPL on some platforms ... 10:01 < Marex> pinchartl: that's kinda work in progress 10:01 < pinchartl> but until then, flash-writer is needed 10:01 < wsa> you need a can-opener once :) 10:01 < pinchartl> in any case, we need a solution for the current problems. if we can improve the situation even more in the future, I'll be very happy 10:02 < pinchartl> Marex: will U-Boot SPL support being loaded over SCIF ? 10:02 < geertu> And you need to make ATF builds point-and-click once ;-) 10:02 < Marex> pinchartl: already does, although it's a bit hacky, which is why it needs cleanup first 10:02 < pinchartl> ok 10:04 < pinchartl> in the meantime, I think a canonical source of instructions on how to retrieve a working minimon binary for each board, or build flash-writer, would be very useful too 10:04 < pinchartl> the expect scripts shouldn't be in the wiki, they should be in a git tree 10:04 < Marex> pinchartl: feel free to take that one up, and put it on the OSDR (!) wiki 10:04 < Marex> pinchartl: this stuff is not public 10:04 < pinchartl> we can have a private git tree for that 10:05 < Marex> pinchartl: btw are we still in the core meeting ? 10:05 < pinchartl> I won't have time to take this one up I'm afraid 10:05 < pinchartl> I believe we are, this doesn't sound like multimedia to me :-) 10:05 < Marex> pinchartl: I have no interest in minimon, except for extracting knowledge burried in it's sources 10:05 < Marex> pinchartl: U-Boot has some sound support, FYI 10:07 < geertu> Let's start with the other parts 10:07 < pinchartl> Marex: oh ? what is sound used for in u-boot ? 10:07 < neg> Marex: wake me up when it supports VIN ;-P 10:07 < kbingham> beep() :D 10:08 < Marex> pinchartl: dunno, x86 people use it for something ... 10:08 < Marex> pinchartl: maybe the nice blurpy sound apple does on boot ... 10:08 < geertu> Can we (you) start with the actual firmware parts, thus not including minimon? 10:10 < Marex> morimoto: btw. updated minimon sources are super-low prio , I think you'd have to go through export paperwork and all other kind of hassle , so don't worry about it too much 10:10 < morimoto> Marex: OK, thanks :) 10:10 < Marex> geertu: didn't I say I added item to my TW to document it on elinux wiki ? 10:10 < geertu> As all the actual firmware parts are FLOSS, there's no issue here 10:11 < geertu> Marex: Good! 10:11 < geertu> Thanks! 10:11 < geertu> Any other topics to discuss for core? 10:11 < morimoto> geertu 10:11 < geertu> Periject path forward? 10:11 < Marex> morimoto: I still owe you a reply to that "updated android patchset" email, I am working toward that, I didn't forget 10:11 < morimoto> I think I sent deadlock email to you 10:11 < morimoto> is it arrived 10:11 < morimoto> ? 10:12 < geertu> morimoto: Yes, I received it. 10:13 < morimoto> Marex: OK, no problem 10:13 < morimoto> geertu: OK, nice to know 10:13 < geertu> morimoto: Thanks! 10:13 < morimoto> in these days, Renesas email seems strange 10:13 < geertu> (cfr. my B) Investigate clk/genpd deadlock reported by Jiada) 10:14 < morimoto> It is not only Renesas problem, I think 10:14 < morimoto> But, I'm not sure 10:15 < Marex> morimoto: I think pareto principle applies here, now it's only the hard bugs :) 10:15 < geertu> I think it's time to conclude the core meeting 10:17 < geertu> Thanks for joining, and have a nice continued day!