1 files changed, 123 insertions, 0 deletions
diff --git a/wiki/Chat_log/20190509-core-chatlog b/wiki/Chat_log/20190509-core-chatlog
new file mode 100644
index 0000000..418365b
--- /dev/null
+++ b/wiki/Chat_log/20190509-core-chatlog
@@ -0,0 +1,123 @@
+09:26 < Marex> so I can probably ask now ... does anyone still care about retaining SH2/SH3 in U-Boot ? I'd like to remove those and only keep SH4/SH4A, since the SH2/SH3 were not updated for years
+09:26 < wsa> thanks for the IO meeting!
+09:26 < geertu> wsa: thx!
+09:26 < wsa> Marex: is it in the way somehow?
+09:27 < Marex> wsa: they were not converted to any of the modern frameworks and spew warnings in the build, which are unlikely to be ever fixed
+09:28 < wsa> Marex: okay, i see, still using old frameworks is "in the way"
+09:28 < damm> how much is a j-core board?
+09:29 < Marex> damm: you can probably put it into an FPGA
+09:29 < damm> ok sure, i was just hoping something turn-key existed
+09:29 < Marex> damm: but I'd much rather reduce the number of boards and CPUs we support first, get the small(er) code into shape and only then add new boards
+09:29 < damm> i recall they were doing sh2
+09:29 < morimoto> Marex: I talked it with Goda-san this morning. Renesas BSP is using UBoot from many years ago, but when "SH Generation
+09:30 < morimoto> Oops
+09:30 < damm> Marex: if you prefer to rip stuff out then that's fine with me
+09:31 < Marex> damm: I do, the SH2 CPU part is small and can be re-added easily if anyone cares
+09:31 < morimoto> when "SH Generation" BSP, it is of course using Uboot, but very BSP-UBoot. We tried to upstream, but not super match. Renesas user still using these old board today, but there are using BSP-U-boot, not upstream-U-boot.
+09:31 < Marex> damm: the bulk of the stuff I plan to nuke are boards, which I doubt anyone tested since forever
+09:32 < Marex> morimoto: well ... what shall we do ?
+09:32 < morimoto> It means, "up to you" :)
+09:33 < damm> morimoto: do you have a list of SH-based boards that are in-use?
+09:33 < Marex> morimoto: I saw iwamatsu-san did a great job on those SH platforms, but that was years ago :(
+09:33 < geertu> Marex: Have you asked Iwamatsu-san?
+09:33 < morimoto> Renesas side doesn't get damage if SH2/SH3 were removed, I mean
+09:33 < shimoda> http://oss.renesas.com/ ?
+09:33 < Marex> it seems debian is still using some SH4 boards
+09:33 < geertu> He may have a more educated opinion
+09:33 < shimoda> it seems sh4 base only
+09:34 < Marex> shimoda: ah, so if we keep SH4, it should be OK ?
+09:34 < kbingham> damm, I have a numato which runs the SH2 (J2)
+09:35 < Marex> kbingham: great, would you like to upstream it ? :)
+09:35 < geertu> J2 is DT based, so all modern?
+09:35 < Marex> geertu: mimas v2 is, which is J2
+09:36 < Marex> geertu: the only DT-based SH board I think
+09:36 < shimoda> Marex: i think so
+09:36 < geertu> http://oss.renesas.com/Documentations/Kernel_TODO_List.pdf
+09:36 < kbingham> I believe there is kernel support upstream for J2, Rich Felker upstreamed it I think ...
+09:36 < Marex> shimoda: OK, let's do that
+09:37 < damm> kbingham: can you use JTAG on that somehow?
+09:37 < Marex> shimoda: and since I can start code on the SH4A core in R-Car Gen2 , I might add some of those boards as SH4A targets too, which in turn would help us retain SH4A in for a bit longer
+09:39 < geertu> Let's start the Core meeting after the first Core question ;-)
+09:39 < geertu> Welcome to Today's Core Group Chat!
+09:39 < geertu> Agenda:
+09:39 < geertu> 1. Status Updates
+09:39 < geertu> 2. Discussion Topics
+09:39 < geertu> Topic 1. Status updates
+09:39 < geertu> A) What have we done since last time:
+09:39 < geertu> Marek worked on ATF (BSP v2.0.3 upstreaming), OpenOCD (RPC HF and SH
+09:39 < geertu> QSPI), and U-Boot (GPIO, PFC, GR-Peach, SH2/SH3 removal).
+09:39 < geertu> Morimoto-san fought with Renesas about our budget.
+09:39 < geertu> Niklas updated copyright in rcar-dmac.
+09:39 < geertu> Geert sent clock and pin control pull requests for v5.2, enjoyed
+09:39 < geertu> holidays, posted IPMMU suspend/resume and PFC validation patches, wrote
+09:39 < geertu> a driver for the RZ/A1 IRQC, and enabled TPU pin groups on R-Car
+09:39 < geertu> H3/M3-W/M3-N.
+09:39 < kbingham> damm, on the Numato board? Hrm ... not sure. I thnik the the fpga is programmed over jtag - not sure what happens after that :)
+09:40 < Marex> kbingham: can you JTAG the SH2 core ? Maybe ask in #j-core ;-)
+09:40 < Marex> kbingham: or at least read the backlog
+09:40 < kbingham> Marex, Can the SH4a be set up with rproc framework?
+09:40 < damm> kbingham: ok, thanks =)
+09:40 < kbingham> (sorry - I'll let geertu continue now)
+09:42 < geertu> kbingham: https://marc.info/?l=linux-sh&m=130034400711357
+09:42 < geertu> B) What we plan to do till next time:
+09:42 < geertu> Marek plans to submit SH2/SH3 removal patches for U-Boot.
+09:42 < geertu> Geert wants to finish on-going sh-pfc non-GPIO-pin cleanup.
+09:43 < geertu> C) Problems we have currently:
+09:43 < geertu> Marek wonders if anyone still cares about SH2/SH3 and SH4/SH4A boards in
+09:43 < geertu> U-Boot.
+09:43 < geertu> Morimoto-san was shocked by Magnus hurting his leg.
+09:43 < geertu> EOT
+09:43 < geertu> Anything I missed?
+09:43 < Marex> kbingham: didn't we discuss that somewhere yet ? maybe it was something I discussed with damm -san . Yep, for starters, remoteproc in U-Boot would be good to bootstrap U-Boot on that SH4A core ; remoteproc in Linux, hum, maybe ; but once the U-Boot is in decent shape, I'd like to boot it natively by flipping MD7
+09:44 < Marex> geertu: I worked on ATF ? :)
+09:45 < Marex> geertu: I dont see it in my current report from yesterday
+09:45 < geertu> Marex: Since last meeting, i.e. 2019-04-04
+09:45 < geertu> So I combined with the 2019-04-18 report, when there was no meeting
+09:46 < Marex> geertu: ah, OK
+09:47 < geertu> Topic 2. Discussion Topics
+09:47 < geertu> Looks like SH* removal from U-BOot has received some discussion already 
+09:48 < geertu> Anything to be added?
+09:48 < Marex> ah
+09:48 < shimoda> i have a question about coresight as I sent an email.
+09:48 < Marex> morimoto: shimoda: are r-car gen2 or r-car gen3 BSDL files (for boundary scan testing) available somewhere ?
+09:49 < shimoda> do you know how to use the linux coresight framework? maybe no? :)
+09:49 < kbingham> Marex, haha bootloader guys "We'll boot the core in the bootloader" : Linux guys "We'll boot the core in linux" :D
+09:49 < Marex> shimoda: I had a vague look into it as some point, what do you plan to do with it ?
+09:50 < geertu> I haven't used the linux coresight framework yet
+09:50 < Marex> geertu: i did on socfpga, it can do way too many things and is convoluted as heck
+09:52 < geertu> I'm also wondering if "Chapter 85. Debug and Trace" contains sufficient information to describe everything in DT, as per Documentation/devicetree/bindings/arm/coresight.txt
+09:54 < shimoda> Marex: i searched the internal sharepoint and then i found r8a7796 bsdl file. But, I don't know I can export it to you.
+09:57 < Marex> shimoda: ah, all right, does it contain the MD pins on the IO chain ? :)
+09:57 < Marex> shimoda: I wonder if we could somehow use BST to simulate toggling MD pins over JTAG
+09:58 < geertu> Marex: The MD pins are sampled ay reset time
+09:58 < Marex> shimoda: then we won't need any of those remote-setup MD-pin toggling contraptions, but only a JTAG probe
+09:58 < Marex> geertu: reset time of what ? the CPU core ?
+09:58 < geertu> But you mean their internal state may be accessable on the chain?
+09:58 < Marex> geertu: hold the CPU in reset, do your BST setup, EXTEST, release CPU from reset
+09:58 < geertu> System reset time
+09:59 < geertu> Which CPU core? There are many ;-)
+09:59 < wsa> shimoda: no coresight experience here, I am sorry
+09:59 < Marex> geertu: the boot CPU
+10:00 < Marex> geertu: some of the MD pins are sampled either by the bootrom or only be the ATF, so I dont think they are necessarily all used at _system_ reset time
+10:00 < geertu> Marex: "[MODEMR] register is initialized only by PRESET#"
+10:00 < Marex> geertu: the ones which are used to select boot mode are probably sampled by bootrom, so if you can flip them via JTAG, you can put the CPU into SCIF loader mode and then use that to unblock RPC access and reflash the board
+10:01 < shimoda> Marex: i greped "MD" and "MODE" in the bsdl file but it doesn't seems to contain them
+10:02 < geertu> shimoda: For now, I'll add CoreSight as a task to periject
+10:02 < Marex> shimoda: hum :(
+10:02 < damm> shimoda: i think you should grep for something else. the MD pins are shared with data or address lines, so A or D would make more sense
+10:02 < Marex> shimoda: I wonder what lauterbach does in their debug probe to unlock the RPC
+10:03 < Marex> shimoda: it would seem that the ADIT people somehow use the lauterbach probe to unlock RPC and reflash the ATF/U-Boot on the Gen3 boards and that it just works (TM)
+10:03 < Marex> shimoda: maybe there's some sort of a trick to it
+10:04 < shimoda> Marex: geertu: wsa: about coresight, thank you for the reply. just i would like to know who have some experience for it. now i will reply to BSP team that upstream team have never tried the coresight framework for now
+10:05 < Marex> shimoda: I tried the CTI, on a different SoC, but not more than that
+10:06 < geertu> OK
+10:07 < geertu> Anything else to discuss? We've entered the MultiMedia space/time continuum
+10:07 < pinchartl> geertu: next meeting date ?
+10:08 < Marex> geertu: the final frontier ?
+10:08 < geertu> pinchartl: wsa: In 2 weeks? Or 4 weeks? (3 weeks is public holiday in most of EU)
+10:09 < pinchartl> 2 weeks seems good to me
+10:09 < pinchartl> in 3 weeks I won't be available
+10:10 < wsa> 2 weeks
+10:10 < geertu> 2 weeks is fine for me
+10:10 < geertu> All set?
+10:10 < geertu> Thanks for joining, and have a nice continued day!