09:05 < wsa> so, welcome to the IO-meeting
09:05 -!- moriperi [~user@fs76eeeb6d.tkyc601.ap.nuro.jp] has joined #periperi
09:05 < wsa> here are the collected status updates:
09:05 < wsa> Status updates
09:05 < wsa> ==============
09:05 < wsa> A - what have I done since last time
09:05 < wsa> ------------------------------------
09:05 < wsa> Geert
09:05 < wsa> : reviewed more RZ/G2L patches, worked on fixing Ethernet after kexec/rebind on all boards
09:05 < wsa> Kieran
09:05 < wsa> : assisted Wolfram with remote access and wiring for the V3U
09:05 < wsa> Marek
09:05 < wsa> : sent next version of Gen2 PCIe L1 mode fix and got it applied now
09:05 < wsa> Niklas
09:05 < wsa> : added support for thermal trip points
09:05 < wsa> Shimoda-san
09:05 < wsa> : refactored the probe function of the SDHI driver to avoid whitelisting, fixed a USB issue with firmware loading, continued to improve R-Car S4 Ethernet driver, investigated an issue where the sh_eth driver on V3H triggered NETDEV WATCHDOG, discussed how to abort tuning for SD card, investigated a regression when loading the USB audio gadget with v5.14-rc1
09:05 < wsa> Ulrich
09:05 < wsa> : sent a patch to fix break and SysRq handling for SCIF
09:05 < wsa> Wolfram
09:05 < wsa> : got stale MMC patches discussed or applied, fixed SDHI regression on some Gen2 instances caused by the new hard reset mechanism, started internal and external discussion how to abort tuning for SD card, sketched design of an upstream compatible way to fix the critical RPC-IF bug, sent out new version of the sloppy GPIO logic analyzer, updated my scripts to support differently working
09:05 < wsa>  remote labs, enabled TPU on M3-W+ and V3U, patch review
09:05 < wsa> B - what I want to do until next time
09:05 < wsa> -------------------------------------
09:05 < wsa> Geert
09:05 < wsa> : wants to continue fixing Ethernet after kexec/rebind on all boards
09:05 < wsa> Shimoda-san
09:05 < wsa> : wants to continue to investigate the issue of sh_eth on V3H, continue to improve R-Car S4 Ethernet driver, continue to make more eLinux articles
09:05 < wsa> Ulrich
09:05 < wsa> : wants to upport CAN driver additions and enable it for V3U
09:05 < wsa> Wolfram
09:05 < wsa> : wants to test Uli's SCIF patch for SysRq, create a safe test case for the RPC-IF bug, implement and send out the proper bugfix for RPC-IF, handle responses to the GPIO logic analyzer, pick up "seperate SDHn clock" again
09:05 < wsa> C - problems I currently have
09:05 < wsa> -----------------------------
09:05 < wsa> none reported
09:06 < wsa> please let me know any mistakes or missed items
09:06 < wsa> geertu: the ethernet fixes are still WIP? I was looking for patches but couldn't find one, or did I just miss them?
09:08 < wsa> uli_: the break fixes you sent, do they fix it with DMA, or were they needed even for non-DMA transfers?
09:08 < geertu> wsa: They're still WIP
09:08 < uli_> it was broken in both cases
09:09 < geertu> -WTOOMANYBOARDS ;-)
09:09 < geertu> W.r.t. that, I should be receving schematics for the Beacon boards soon.
09:09 < wsa> uli_: I assumed so. And are the patches enough to enable SysRq with DMA now, or do we still need to re-enable interrupts with DMA
09:10 < uli_> error interrupts are not disabled with dma
09:10 < uli_> don't know where that came from
09:10 < wsa> geertu: why does it need to be fixed per board?
09:10 < geertu> wsa: The fix involves adding compatible values to identify all Ethernet PHYs
09:11 < wsa> geertu: Uh, I see
09:11 < wsa> uli_: so the task is done now?
09:11 < uli_> i would say so
09:12 < geertu> The issue is that if no compatible values are present, the MDIO core reads the PHY ID from the PHY, which fails if reset is still asserted.
09:12 < wsa> uli_: cool
09:12 < geertu> You could say that's a bug in the Linux MDIO/PHY code, but the PHY people don't want to fix it, and recommended using compatible values instead.
09:12 < wsa> geertu: and we can't deassert the reset before reading?
09:13 < geertu> wsa: in theory we can. People posted patches to do that before, which were rejected.
09:13 < wsa> moriperi: you just wrote "Add new board for Renesas Remote Access System" Is this a Renesas internal system or also accesible for, let's say, EuroPeri? ;)
09:13 < wsa> geertu: with a valid reason?
09:14 < wsa> damm: by any chance, any news about the Condor board which failed last time we wanted to access it?
09:14 < geertu> wsa: I think it broke something else.
09:14 < marex> geertu: compatible = "ethernet-phy-id0007.c0f0", "ethernet-phy-ieee802.3-c22"; does not work ?
09:15 < damm> wsa: sorry i did not proceed looking into that. will do next time i visit the remote access location. you did get eagle going at least right?
09:15 < geertu> marex: that's exactly what I'm doing ;)
09:15 < marex> geertu: ok
09:15 < marex> geertu: yep, that issue is nasty
09:16 < damm> marex: i guess "c0f0" is the CRC?
09:16 < marex> nope
09:16 < marex> lan8710 PHY ID
09:16 < wsa> damm: yes, eagle worked and this will help enough already. condor might be nice for better testing, but it is not essential
09:16 < damm> sorry for poor joke. but i'm not sure if that is any better.
09:16 < geertu> damm: two 16-bits values separated by dot
09:16 < marex> that's where you fill in the two PHY ID register values of your PHY instead
09:17 < damm> haha
09:17 < damm> now the only thing missing is some sort of JIT machine interpreting opcodes
09:17 < marex> geertu: they could've just used the dot product (heh)
09:18 < geertu> marex: network people like separates (dots, colons, ...)
09:18 < geertu> separators
09:18 < marex> damm: like lua in dt ?
09:18 < wsa> okay, i have no more questions
09:18 < wsa> anything from your side?
09:19 < wsa> but I still want to get out some sparkling wine
09:19 < damm> which group would OpenOCD be assigned to?
09:19 < geertu> wsa: and the Renesas Remote Access System?
09:19 < wsa> for the first useful remote scoping of the GPIO logic analyzer \o/
09:19 < geertu> damm: core
09:20 < wsa> geertu: I'm sure moriperi will answer it once he gets back to IRC
09:20 < wsa> he is probably still busy understanding Renesas problems ;)
09:21 < geertu> wsa: congrats, and cheers!
09:22 < damm> wsa: are the latest SDHI fixed included in renesas-drivers?
09:22 < wsa> uli_: for enabling PWM on V3U, I will probably need to use your "sample-the-GPIO-input-register" approach. Already looking forward to that :D
09:22 < uli_> always happy to help with a horrible hack :)
09:23 < damm> wsa: i remember running into some issue and i want to retest on some kernel version but i'm not sure which
09:23 < wsa> damm: The lastest one not. Usually they come back via linux-next because Ulf applies them kinda fast
09:23 < wsa> but the latest one is only Gen2, with non SDR104 instances
09:23 < kbingham> wsa, Are there any pictures of the scope traces?
09:23 < geertu> damm: and one Ulf has applied them, they'll end uo in next renesas-drivers automagically.
09:23 < damm> wsa: can you let me know when we have a supposedly fixed kernel that i can test?
09:23 < geertu> s/one/once/
09:24 < damm> so i guess next renesas-drivers release then perhaps?
09:24 < kbingham> Was the data visibly noisy/lossy from tracing on the same CPU? or was the resolution such that it didn't matter?
09:24 < wsa> kbingham: not from the TPU yesterday, but from I2C which I scoped for testing: https://elinux.org/Kernel_GPIO_Logic_analyzer
09:25 < wsa> damm: let me check latest renesas-drivers. My gut feeling is that it is good to go on non-Gen2
09:25 < damm> wsa: no need, i think i saw the issue on Gen2 actually
09:25 < damm> probably Koelsch
09:26 < moriperi> was: sorry for my late response. I'm now e-meeting with Renesas too :(
09:26 < wsa> then it is likely fixed by the patch Ulf still needs to apply
09:26 < damm> ok cool. thanks.
09:26 < moriperi> Sorry, Renesas Remote System is only for Renesas member, it needs to access Renesas internal net.
09:26 < wsa> kbingham: I measured 1 and 2kHz with a sampling speed of 1MHz.
09:27 < kbingham> wsa, Oh ... plenty of excess there then ;-)
09:27 < moriperi> s/was/wsa/
09:27 < wsa> kbingham: the V3U with non-SMP gave me a maximum speed of 1.4MHz. M3-N with an isolated bigCore gave 3.8Mhz.
09:27 < geertu> wsa: Nyquist and Shannon will be happy to improve on that ;-)
09:27 < marex> wsa: I hate to be a FS, but ... did you consider wiring the cortexR to the JTAG port of the RCar3 and using BST to precisely sample your pins without any GPIO nonsense involved in it ?
09:28 < marex> wsa: that works even for debugging DDR2/3 DRAM on certain chips
09:28 < marex> the CA5x will suffer from horrid jitter between samples
09:28 < wsa> marex: nope. The aim is here a simple setup
09:29 < marex> well if it doesn't return reliable results, what's the point
09:29 < kbingham> marex, It showed that the device was operating....
09:29 < wsa> I had a 4% error rate. Of course, I can't say if it is my analyzer or the TPU driver using this approach
09:30 < wsa> But for finding out that the PWM is in the 1kHz or 2kHz range, it is good enough
09:30 < damm> it is cool that you can hook it up to sigrok. i think the saleae logic devices are supposed to be supported there too, but i have not yet tested.
09:30 < marex> wsa: yeah, that's why you use FPGA for logic analyzers, with precise sample spacing implemented in hardware
09:30 < kbingham> wsa, If you need an accurate pulse measurement, I can hook the scope up and get some timings
09:30 < wsa> damm: yep, they are. They are even recommended by sigrok devs
09:30 < wsa> kbingham: I don't need accurate
09:30 < wsa> I could do this locally
09:31 < wsa> I just wanted to know if enabling TPU on V3U worked
09:31 < geertu> marex: yep, "does it blink slow or fast?" is sometimes good enough.
09:31 < wsa> marex: come on, we had this before. I don't need "precise" for this task
09:31 < marex> geertu: the report here would be "yeah, it kinda blinks every once in a while, the interval is a bit wobbly though"
09:31 < wsa> marex: I am fully aware of the limitations
09:32 < wsa> marex: and all for you, I named it "sloppy" everywhere :)
09:32 < damm> if anyone needs it i can probably hook up a saleae logig 16 or 8 via USBIP for remote access
09:32 < marex> damm: is that cypress based or fpga based ?
09:33 < damm> not sure but it works out of the box
09:33 < marex> I think they did use cypress cortexM in it , with USB and custom firmware
09:33 < damm> the logic 8 pro is nicer than the 16 that i bought many years ago. it also has support for analogue channels which i don't really neeed.
09:33 < geertu> wsa: Is PWM clocked by a spread spectrum source?
09:34 < marex> https://www.asix.net/dbg_sigma.htm works with sigrok just fine, FPGA based
09:34 < wsa> It is clocked by S1D8
09:34 < marex> triggers need work
09:34 < wsa> that is all i know
09:35 < damm> marex: looks nice, but the peeing contest with respect to sampling rate is won by logic 8 with 500 MS/s
09:36 < wsa> can we switch to core now?
09:36 < wsa> geertu: you ready?
09:37 < geertu> wsa: I am
09:37 < damm> wsa: any chance the logic analyzer will work with sharing GPIOs with other devices somehow? =)
09:37 < wsa> damm: that might actually be possible, but probably so hacky that I can't upstream it :D
09:37 < wsa> geertu: have fun!