1 files changed, 187 insertions, 0 deletions
diff --git a/wiki/Chat_log/20180419-core-chatlog b/wiki/Chat_log/20180419-core-chatlog
new file mode 100644
index 0000000..696bb19
--- /dev/null
+++ b/wiki/Chat_log/20180419-core-chatlog
@@ -0,0 +1,187 @@
+Core-chat-meeting-2018-04-19
+
+09:36 < geertu> Welcome to today's Core Group Chat
+09:36 < geertu> Agenda:
+09:36 < geertu> 1. Status Updates
+09:36 < geertu> 2. Discussion Topics
+09:36 < geertu> Topic 1. Status updates
+09:37 < geertu> A) What have we done since last time:
+09:37 < geertu> Jacopo fixed regressions on SuperH, and updated DTS bindings for M3-N.
+09:37 < geertu> Kaneko-san posted patches to sort DT nodes on R-Car Gen3.
+09:37 < geertu> Marek worked on U-Boot (SDHI, SPL, QSPI, RPC, DM/DT conversion), OpenOCD
+09:37 < geertu> for R-Car H2 and M2-W, QEMU, and Linux (PCIe).
+09:37 < geertu> Morimoto-san used his ninja-skills to provide SoC and board
+09:37 < geertu> documentation.
+09:37 < geertu> Niklas troubleshot dual core issues after v4.16.
+09:37 < geertu> Shimoda-san submmited patches for initial base R-Car E3 support.
+09:37 < geertu> Ulrich is enjoying holidays.
+09:37 < geertu> Geert enjoyed some Easter holidays, revisited vfio and qemu patches,
+09:37 < geertu> added PM Domain handling to vfio-platform, reviewed lots of new SoC
+09:37 < geertu> support, and updated periupport for v4.17-rc1.
+09:38 < geertu> B) What we plan to do till next time:
+09:38 < geertu> Kaneko-san will address review comments for his patches.
+09:38 < geertu> Marek will keep working on U-Boot (DM/DT conversion, CI setup).
+09:38 < geertu> Morimoto-san will prepare for OSSJ and side events.
+09:38 < geertu> Niklas will keep working with Vincent to fix the dual core problem.
+09:38 < geertu> Shimoda-san will update his R-Car E3 patches, add USB2.0 ch3 to H3 ES2.0
+09:38 < geertu> DTS, and pave the way forward for IPMMU.
+09:38 < geertu> Simon will cleanup more DTS files.
+09:38 < geertu> Geert will prototype interrupts on qemu+kvm, do more periupport
+09:38 < geertu> analysis, and handle CPG/MSSR and SYSC errata.
+09:38 < geertu> C) Problems we have currently:
+09:38 < geertu> Kaneko-san is looking for small tasks.
+09:38 < geertu> Marek needs access to a Koelsch with R-Car M2-W ES2.0 or newer.
+09:39 < geertu> Anything I missed?
+09:39 < geertu> vaishali: You're working on watchdog under the I/O umbrella, right?
+09:40 < vaishali> geertu: Yes
+09:40 < geertu> OK
+09:40 < geertu> Topic 2. Discussion Topics
+09:42 < geertu> Anyone who has a core topic to discuss?
+09:42 < geertu> Anyone who has a Koelsch with M2-W ES2.0, for Marek?
+09:44 < wsa_> Is there an issue with WDT on U-Boot?
+09:44 < wsa_> I keep asking but there is no reply
+09:45 < Marex> wsa_: first time I hear that question
+09:45 < Marex> wsa_: by the looks of it, not supported
+09:46 < Marex> wsa_: adding a driver should be trivial I guess ?
+09:46 < wsa_> I replied to your status mail yesterday :D
+09:46 < wsa_> and I am quite sure I can dig up one or two more logfiles / mails
+09:46 < wsa_> but that's not the issue
+09:46 < wsa_> yes, it should be trivial and we need it to implement WDT handover in Linux
+09:47 < Marex> oh that topic
+09:47 < Marex> WDT handoff from U-Boot to Linux, that sounds more familiar
+09:47 < wsa_> that could be more a task for Vaishali
+09:47 < wsa_> we will see about that
+09:48 < wsa_> in any case, we need it in U-Boot first
+09:48 < Marex> wsa_: did the requirement for this handoff crystalize better first ?
+09:48 < Marex> s/first//
+09:49 < wsa_> "crystalize"?
+09:49 < Marex> wsa_: what is it we are aiming for, getting the WDT running ASAP and throughout the whole boot process ?
+09:50 < Marex> wsa_: if so, then you also need to consider when you turn it on , in U-Boot ? In SPL ? earlier ... in bootrom maybe ?
+09:50 < wsa_> not ASAP
+09:50 < wsa_> it is research
+09:50 < Marex> but then what is the point ? the system can hand before WDT is active
+09:50 < Marex> *hang
+09:50 < geertu> There's also the secure WDT
+09:50 < geertu> to be handled by ATF?
+09:50 < Marex> geertu: Gen3 only I guess ?
+09:51 < geertu> Marex: Gen2 also has SWDT hardware block
+09:51 < wsa_> can we just have it for research reasons?
+09:51 < Marex> wsa_: what are you attempting to learn from this research ?
+09:52 < wsa_> U-Boot <-> Linux handover
+09:52 < geertu> FTR, "git grep -i swdt plat/renesas/rcar" reveals ATF has SWDT support
+09:52 < Marex> wsa_: anything in particular ? that just seems a bit vague
+09:53 < wsa_> it is not
+09:53 < wsa_> it is what i want to research
+09:53 < Marex> wsa_: well, adding a driver to u-boot is certainly possible
+09:54 < Marex> wsa_: and I guess real easy
+09:54 < wsa_> either we agree on "sure, let's try" or we agree on "no, we do only full solutions"
+09:54 < Marex> wsa_: well said
+09:54 < dammsan> but whats the purpose?
+09:54 < dammsan> (sorry if i'm being slow)
+09:54 < dammsan> cover the entire boot process from as early as possible?
+09:55 < wsa_> We need to implement the handover first to get other changes upstream
+09:55 < Marex> if that was the case, see my remark about TPL ... and on Gen3, that'd mean handoff from ATF to U-Boot and U-Boot to Linux
+09:56 < wsa_> and i thought we could do that since the U-Boot driver would be trivial to add
+09:56 < Marex> wsa_: what "other patches" ?
+09:56 < Marex> *other changes
+09:56 < dammsan> ok, but u-boot is rather late in the boot process
+09:56 < dammsan> perhaps the ATF -> U-Boot thingie is similar to the DDR memory topic?
+09:57 < dammsan> we need to pass state in both cases
+09:57 < wsa_> Marex: proper timer initialization according to documentation
+09:58 < geertu> The "receiving" side can easily read the WDT registers to find out if the RWDT is enabled and running.
+09:58 < wsa_> upstream rejected the patch as unneeded because we don't handle takeover yet
+09:59 < dammsan> so why do we need to block on u-boot then if it is just a matter of reading registers?
+09:59 < geertu> wsa_: Which patch was rejected? Do you have a link?
+09:59 < wsa_> so i thought we could add that to get the patch upstream and learn about it to get one step closer to having proper WDT support when booting
+09:59 < wsa_> but I am about to just give up on that
+09:59 < Marex> geertu: was about to ask the same thing , might make it more obvious what the issue is, you were faster
+09:59 < dammsan> wsa_: dont give up =)
+10:00 < wsa_> [PATCH] watchdog: renesas_wdt: adapt timer setup to recommended procedure
+10:01  * Marex reads the discussion there
+10:01 < wsa_> but I need to go to the workshop now
+10:01 < geertu> wsa_: Thx
+10:02 < geertu> Ah, that patch.
+10:02 < geertu> IMHO it has only a vague dependency on handover support.
+10:02 < geertu> "The only exception I can think of is if the watchdog is 
+10:02 < geertu> already running during boot, but that situation isn't handled
+10:02 < geertu> anyway.
+10:02 < geertu> "
+10:03 < geertu> Does fixing that need watchdog core support? Or just driver changes?
+10:03 < wsa_> That's what I wanted to investigate
+10:03 < geertu> ATF SW executive summary: void bl2_swdt_exec() { ... ; panic(); }
+10:04 < geertu> s/SW/SWDT/
+10:04 < Marex> looks like a more general issue to me
+10:04 < geertu> Well done, ATF!
+10:04 < geertu> Sorry, forgot to quote the comment:
+10:04 < dammsan> "As expected by The Firmware"
+10:04 < geertu> void bl2_swdt_exec() { ... ; /* Endless loop */ panic; }
+10:05 < Marex> good thing U-Boot is not firmware , no matter what other people claim
+10:05 < Marex> wsa_: so your plan is to fix the WDT core to handle the handoff case proper, right ?
+10:05 < Marex> wsa_: and for that you need someone to enable WDT before Linux boots ?
+10:05 < wsa_> yes
+10:05 < Marex> wsa_: can't you simulate that by poking the WDT registers on the U-Boot command line for now ?
+10:06 < geertu> Or in early kernel startup
+10:06 < wsa_> sure
+10:06 < dammsan> geertu: do we need to preserve clocks during init too?
+10:06 < Marex> wsa_: in the boot command even ... setenv bootcmd run wdt boot_linux
+10:06 < wsa_> I thought the driver was trivial and U-Boot commands would be easiert to use
+10:06 < geertu> dammsan: watchdog needs the clock running.
+10:06 < dammsan> or i guess it is always-on 32khz clock that is needed
+10:06 < wsa_> If I had foreseen this discussio, I'd surely have gone with poking registers
+10:07 < Marex> wsa_: there are no commands for WDT, it just gets poked during U-Boot just like it does during Linux
+10:07 < Marex> wsa_: the driver is trivial, sure
+10:07 < wsa_> i see
+10:07 < Marex> wsa_: but if you just need to fire up the WDT, it is probably trivial-er to just poke the registers
+10:07 < wsa_> I agree
+10:07 < Marex> but if there is interest in adding the WDT support to U-Boot, that can be done too :)
+10:08 < wsa_> so, good outcome of the discussion after all :)
+10:08 < Marex> wsa_: indeed!
+10:08 < Marex> wsa_: and we untangled the confusion, which is nice
+10:08 < wsa_> Yes
+10:08 < geertu> dammsan: for RWDT, there's an MSTP bit
+10:08 < wsa_> I guess I got a little grumpy because I'll be late for the workshop
+10:08 < geertu> for SWDT, there isn't, it runs directly for external OSCCLK
+10:09 < wsa_> my apologies for getting grumpy
+10:09 < Marex> wsa_: sorry for being a little slow !
+10:09  * geertu has faint memories of an SWDT MSTP bit in an older datasheet
+10:11 < geertu> Unless someone has something (short) else to discuss, I think we're finished?
+10:11 < geertu> wsa_: Thx, and now run!
+10:11 < pinchartl> wsa_: before you run
+10:11 < pinchartl> next meeting ?
+10:11 < pinchartl> two weeks from now ?
+10:12 < wsa_> gotta ack
+10:12 < pinchartl> I will be unavailable I'm afraid, but that shouldn't stop anyone from meeting
+10:12 < wsa_> ack
+10:12 < geertu> pinchartl: Fine for me (for Core)
+10:12 < wsa_> 3 weeks would also be fine with me
+10:12 < dammsan> 3rd is holiday in japan
+10:13 < wsa_> 10th then?
+10:13 < dammsan> 10th is not holiday
+10:13 < geertu> 10th is a holiday in Belgium
+10:13 < dammsan> haha
+10:13 -!- shimoda [~shimoda@relprex2.renesas.com] has quit [Read error: Connection reset by peer]
+10:14 < pinchartl> I'll be unavailable from 29/04 to 14/05 so please ignore me :-)
+10:14 < geertu> horms: Same in NL
+10:14 -!- shimoda [~shimoda@relprex2.renesas.com] has joined #periperi
+10:14 < wsa_> ok, i am fine with both options, so let me know
+10:14 < wsa_> cya!
+10:14 -!- wsa_ [~wsa@46.189.28.194] has quit [Quit: ...]
+10:15 < geertu> And in DE, too ;-)
+10:16 < pinchartl> so ?
+10:16 < pinchartl> we can also move it to a different day than Thursday
+10:16 < dammsan> might be a good idea
+10:16 < pinchartl> again I have no preference as I'll be away for two weeks
+10:17 < horms> My mornings are typically open these days
+10:17 < dammsan> 8th or 9th?
+10:17 < shimoda> 8th or 9th is good to me
+10:17 < morimoto> me too
+10:18 < dammsan> i would vote for 9th myself
+10:18 < pinchartl> dammsan: so you want to avoid the whole golden week, not just 憲法記念日 and みどりの日 ? :-)
+10:18 < dammsan> i want to avoid forever
+10:18 < dammsan> =)
+10:18 < pinchartl> :-)
+10:18 < dammsan> renesas office is empty the entire week
+10:19 < pinchartl> I propose the 9th then
+10:19 < geertu> 9th is fine for me
+10:20 < morimoto> +1
+10:20 < geertu> So thanks for joining, and have a nice continued day!