diff options
author | Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> | 2019-12-09 15:29:52 +0900 |
---|---|---|
committer | Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> | 2019-12-09 16:23:07 +0900 |
commit | 55e3b2f45880faaf06f3c660ca9e8a6d9aa14bce (patch) | |
tree | 6392fd201a51ff0f6dc0e474803e6f3b20919504 /wiki/Chat_log/20180419-core-chatlog | |
parent | 5d9e1b983faf7645ddc3d45d28e612d2ac4179c0 (diff) |
wiki: Porting wiki: Porting Chat Log
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Diffstat (limited to 'wiki/Chat_log/20180419-core-chatlog')
-rw-r--r-- | wiki/Chat_log/20180419-core-chatlog | 187 |
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! |