path: root/wiki/Chat_log/20190221-core-chatlog

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!