summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--wiki/Chat_log/20201105-io-chatlog129
1 files changed, 129 insertions, 0 deletions
diff --git a/wiki/Chat_log/20201105-io-chatlog b/wiki/Chat_log/20201105-io-chatlog
new file mode 100644
index 0000000..e1b397f
--- /dev/null
+++ b/wiki/Chat_log/20201105-io-chatlog
@@ -0,0 +1,129 @@
+09:05 < wsa> so, welcome to this IO meeting
+09:05 < wsa> I hope you are all healthy!
+09:05 < morimoto> Thanks
+09:05 < neg> So does this mean we will decommission #periperi and move here?
+09:05 < wsa> first status updates, then questions
+09:06 < wsa> neg: i'd think only for meetings?
+09:06 < wsa> Status updates
+09:06 < wsa> ==============
+09:06 < wsa> A - what have I done since last time
+09:06 < wsa> ------------------------------------
+09:06 < wsa> Geert
+09:06 < wsa> : enabled and tested MSIOF on R-Car M3-W+ and marked i2c-sh_mobile adapter suspended during suspend
+09:06 < wsa> Marek
+09:06 < wsa> : sent V2 of L1 link state recovery for Gen2 PCIe, sent a patch allocating PCI MSI address in 32bit space
+09:06 < wsa> Niklas
+09:06 < wsa> : did initial experimentation with CMT and TMU timers
+09:06 < wsa> Shimoda-san
+09:06 < wsa> : converted PCI host binding to JSON, improved power off notification in the MMC core, developed R-Car S4 Ethernet driver for Linux
+09:06 < wsa> Wolfram
+09:06 < wsa> : enjoyed two weeks of holiday and attended virtual ELCE, researched V3U differences of IO devices, created and discussed tasks for V3U enablement, fixed SD card re-insertion regression and other issues reported by Shimoda-san, debugged another stalled SCC issue when reading EXT_CSD occasionally fails on his H3 ES2.0, retested and applied Uli's IIC patch for atomic transfers, sent
+09:06 < wsa> RFC to fix scheduling while atomic in WDT driver
+09:06 < wsa> B - what I want to do until next time
+09:06 < wsa> -------------------------------------
+09:06 < wsa> Geert
+09:06 < wsa> : wants to enable and test MSIOF on R-Car V3U
+09:06 < wsa> Shimoda-san
+09:06 < wsa> : wants to collect more information about R-Car Gen3e, continue to develop R-Car S4 Ethernet driver
+09:06 < wsa> Wolfram
+09:06 < wsa> : wants to enable and test V3U IO devices, send out the SDHI TAP_EN series after all known issues are fixed, work on further SDHI issues (max_busy_timeout), guide increase of I2C_M_RECV_LEN length to 255 and upstream R-Car support for it, resend WDT patch to fix scheduling while atomic
+09:06 < wsa> C - problems I currently have
+09:06 < wsa> -----------------------------
+09:06 < wsa> None
+09:07 < wsa> so, geert just answered my question what "S4" is in this mail a minute ago
+09:08 < wsa> shimoda: I still wonder what "Gen3e" is? also, new SoCs?
+09:08 <@geertu> wsa: Nah, Google did
+09:08 < wsa> neg: in your B) section, shouldn't there be timers as well? ;)
+09:08 < neg> wsa: Yes it should ;-)
+09:09 < shimoda> wsa: like RZ/G2 SoCs, just re-modeling SoCs of R-Car Gen3
+09:09 < wsa> uli___: do you still work on atomic patches for i2c-rcar? or is your base time all eaten up?
+09:10 < wsa> shimoda: so, except for new DTS files, not much enablement expected?
+09:10 < shimoda> it's improving bussiness area, but technical area especiialy linux / dt seems to be complex...
+09:10 -!- kbingham [~kbingham@core.do.nakedgeek.co.uk] has joined #periperi-ng
+09:10 < uli___> wsa: yes, it's still on the list. i basically left that aside while the sh variety is still in progress. since that has been merged now, i'll go ahead with rcar
+09:11 <@geertu> shimoda: basically it extends the RZ/G2 CPU operating points to the R-Car Gen3 range?
+09:11 < wsa> shimoda: okay, let's wait until you have more information
+09:11 -!- jmondi [~jmondi@250.ip-164-132-57.eu] has joined #periperi-ng
+09:11 < shimoda> wsa: in theory of device tree bindings, if we have a new SoC part number, we have to make new bindings
+09:11 < wsa> uli___: great, thanks!
+09:12 < wsa> shimoda: yes. although most IP cores have a generic "gen3" binding, or? So, we mainly need to update to bindings documentation and not so much the drivers
+09:12 < shimoda> @geertu: yes, V3H and V3M are out-of-scope of Gen3e
+09:13 < wsa> so, that's it from my side for the status infos...
+09:13 < wsa> the big question I have is obviously about V3U in Magnus' lab :)
+09:14 < shimoda> wsa: you're right. however, Gen3e plans overclock. So, we may need to modify cpg driver for Gen3e
+09:14 < wsa> any news on that?
+09:14 < wsa> shimoda: ah, okay.
+09:15 < damm> did someone say Falcon?
+09:15 < morimoto> V3U is now under paper work process for shipping :)
+09:15 < shimoda> wsa: ah, I got information from magnus-san about v3u remote lab, but I don't try yet
+09:15 < wsa> morimoto, the export paper work warrior strikes back!
+09:16 < damm> I suspect it is broken because it does not make any sound
+09:16 < morimoto> wsa: :)
+09:17 < damm> just power switch relays clicking
+09:17 <@geertu> damm: is the fan an add-on board?
+09:17 < wsa> damm: no LEDs?
+09:18 < morimoto> geertu: very big FAN is added
+09:18 <@geertu> damm: Do you need to talk to the RL78 to power it on?
+09:19 < marex> computer, turn on the falcon ... unable to comply ?
+09:19 < damm> everything seems fine what i can tell
+09:20 < kbingham> marex, don't forget to use 'sudo'
+09:20 < damm> i got a list of users from Renesas side
+09:20 < damm> so the ssh permissions are already adjusted
+09:20 < damm> exactly how to time share it is a different question
+09:21 < wsa> morimoto: https://thumbs.dreamstime.com/z/superhero-long-cloak-mask-business-character-vector-illustration-guy-holds-hands-large-paper-piles-superhero-long-180946696.jpg
+09:22 <@geertu> wsa: Please don't demotivate morimoto-san, or we'll never get boards ;-)
+09:22 < damm> morimoto-san and shimoda-san, may I disclose the port number?
+09:22 < wsa> well, once the upstream kernel runs, first thing would be PFC?
+09:22 < wsa> geertu: morimoto is hero, he will manage
+09:22 < morimoto> wsa: yeah, superhero :)
+09:23 <@geertu> wsa: right, he is supermanager, and will superhero ;-)
+09:24 <@geertu> wsa: and GPIO? Both are a bit tied together
+09:24 < shimoda> damm: yes, please
+09:24 < wsa> geertu: sure
+09:24 < damm> 9018
+09:24 < shimoda> now I'm trying to use the remote Falcon board
+09:25 <@geertu> damm: What happened to the Alix on that port?
+09:25 < wsa> from IO side, I will wait with testing until you give me a go with initial PFC and GPIO
+09:26 < morimoto> If you have chance to access "physical" Falcon access, some information abiout V3U from me is that 1) CPU FAN will start works if the degree was over 90. 2) USB debug serial will indicate 2 ttyUSBx.
+09:26 < shimoda> and, my kernel image could run on the v3u. magnus-san, thank you very much for your support!
+09:26 < wsa> damm: did you also get breakout connectors? so we can wire some lines together on EXIOx?
+09:27 <@geertu> shimoda: Great!
+09:28 < marex> I guess I'll let the kernel people do their business first, then start on the bootloader work on falcon ?
+09:28 < marex> meanwhile, there is plenty of rzg2 patches coming in for review ... heh
+09:28 < morimoto> I had updated PeriJect for Falcon
+09:29 -!- pinchartl [~laurent@perceval.ideasonboard.com] has joined #periperi-ng
+09:30 < shimoda> marex: i intend to ship a board to you in Q4. so you are able to develop a boot loader on physical board
+09:30 < marex> shimoda: ooooh, thank you
+09:31 <@geertu> wsa: Aren't the EXIOx connectors used to connect the different parts of the Falcon board stack?
+09:32 < wsa> but can't we wire them if there is no further stack?
+09:32 <@geertu> We do have GPIO CN and the MSIOF[12] PIN HEADERs
+09:32 < damm> sorry guys no breakout connectors
+09:32 < damm> there are some pins exposed to regular pin headers
+09:32 <@geertu> damm: Can you wire MSIOF1 RXD to TXD (CN5 pin 5 to 6)? These are 2.54mm headers, according to the schematics
+09:34 <@geertu> GPIO CN is 1.27mm
+09:34 <@geertu> damm: BTW, do you have a picture of the Falcon?
+09:35 < wsa> are there other IO related questions?
+09:35 < wsa> otherwise I suggest to move to core
+09:35 < marex> wsa: well, PCI
+09:35 < damm> Falcon is a bit confusing because CPU board and break out board use same CN names
+09:36 < damm> for different purposes
+09:36 <@geertu> damm: I meant on the Breakout board
+09:36 < damm> CN5 on the break out board - let me try to find it
+09:36 <@geertu> CN6 is fine, too (that's MSIOF2)
+09:36 < wsa> marex: shoot
+09:36 < damm> yeah I can do it right away if you need to
+09:37 < marex> wsa: just curious what the news are
+09:37 <@geertu> damm: It's not urgent.
+09:37 < wsa> marex: you mean PCI on V3U?
+09:37 < marex> yep
+09:37 < shimoda> geertu: i have pictures board team took. I'll send to periperi ML
+09:38 < wsa> marex: I haven't heard anything new, so I still consider it broken
+09:38 <@geertu> shimoda: thank you
+09:38 < wsa> maybe JapaPERI knows more?
+09:39 < shimoda> wsa: marex: hardware team prepared workaround and BSP team is trying to implement it. But, I don't know the current status
+09:39 < shimoda> I'll ask BSP team later
+09:39 < damm> where can i find the pin out of CN5 and CN6? I've browsed the board docs and information is quite sparse
+09:39 < marex> shimoda: nice
+09:39 <@geertu> damm: R-CARV3U_BREAKOUTBOARD_REV100.pdf p9
+09:40 < wsa> then, let's move to core?
+09:40 <@geertu> fine for me