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

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!