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

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!