1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
|
09:43 <@geertu> Welcome to today's Core Group Chat Meeting!
09:43 <@geertu> Agenda:
09:43 <@geertu> 1. Status Updates
09:43 <@geertu> 2. Discussion Topics
09:43 <@geertu> Topic 1. Status updates
09:44 <@geertu> A) What have we done since last time:
09:44 <@geertu> Marek worked on U-Boot (late clock drivers removal) and TFA (BL31
09:44 <@geertu> logging fix).
09:44 <@geertu> Morimoto-san continued V3U-Falcon shipping paper work.
09:44 <@geertu> Niklas posted VIN "g8" pin control patches.
09:44 <@geertu> Shimoda-san submitted the rcar-usb2-clock-sel json-schema conversion.
09:44 <@geertu> Ulrich finished porting V3U pin control from the BSP.
09:44 <@geertu> Geert tested GPIO on R-Car V3U, fixed R and OSC clocks on R-Car V3U,
09:44 <@geertu> removed static I/O mappings from mach-shmobile, sent first batch of pull
09:44 <@geertu> requests for v5.11, and studied the early ARM compressed boot flow,
09:44 <@geertu> fixing large kernels on Koelsch.
09:44 <@geertu> B) What we plan to do till next time:
09:44 <@geertu> Marek is considering to revisit the U-Boot PSCI implementation.
09:44 <@geertu> Morimoto-san plans to continue doing V3U-Falcon paperwork, and do
09:44 <@geertu> Renesas work.
09:44 <@geertu> Shimoda-san plans to collect more information about R-Car Gen3e,
09:44 <@geertu> add BD9574 support for Ebisu-4D board (depending on hardware
09:44 <@geertu> availability), and attend OSSJ + ALS2020.
09:44 <@geertu> Ulrich plans to post V3U pin control support.
09:44 <@geertu> Geert plans to send the second batch of pull requests for v5.11,
09:44 <@geertu> complete R-Car V3U gpio-pinctrl integration, and develop v10 of
09:44 <@geertu> obtaining the start of physical memory from DTB.
09:44 <@geertu> C) Problems we have currently:
09:44 <@geertu> None.
09:45 <@geertu> ---EOT---
09:45 <@geertu> Anything I missed?
09:45 <@geertu> Looks like we're on track regarding R-Car v3U support?
09:46 < wsa> uli__: when do you plan to post the PFC driver?
09:46 < uli__> i'll try to do it today. tomorrow at the latest.
09:48 <@geertu> shimoday: Given you already did preparatory work for V3U SYS-DMAC in July 2019, do you plan to upstream support for it?
09:48 <@geertu> uli__: thx!
09:49 < wsa> uli__: cool!
09:50 < shimoday> @geertu: i don't have any plan for now.
09:51 <@geertu> shimoday: OK. So we'll have to tackle it once we have some I/O devices working that can make use of it.
09:51 <@geertu> Topic 2. Discussion Topics
09:51 <@geertu> A) KVM/Qemu situation.
09:51 < shimoday> @geertu: yes. thanks!
09:51 <@geertu> Morimoto-san reported that Munakata-san wants to know the KVM/Qemu situation.
09:52 < moriperi> Yes. it seems KVM/Qemu is/will important
09:52 < moriperi> for TOYOTA and/or Android
09:52 < moriperi> So he want to know plan and/or your opinion
09:52 <@geertu> The initial work we did, and which is documented on the elinux wiki, was basically an investigation and prototyping phase.
09:52 <@geertu> No confidential information was "opened".
09:53 < moriperi> OK
09:53 <@geertu> AFAIK, we have no further plans.
09:53 <@geertu> Before we reply to Morimoto-san's email, I think it would be good to have an ida of the planned use cases and expectations from Renesas.
09:53 <@geertu> s/ida/idea/
09:54 <@geertu> Looks like the request is mostly tiggered by what Google wants to do on Android?
09:54 < moriperi> I'm not good at KVM, but he said that virt I/O, virt Video (?), virt Sound (?) virt USB (?), etc, etc will be needed.
09:55 < moriperi> for Android, he said.
09:55 < moriperi> and TOYOTA is having interresting about it.
09:55 <@geertu> https://lwn.net/Articles/836693/ KVM for Android
09:56 < moriperi> Renesas side have not concrete idea/plann so far.
09:56 < moriperi> That is the reason why he want to know your side opinition.
09:56 < shimoday> moriperi: virt USB means usb gadget? or host? perhaps gadget for android?
09:56 <@geertu> I may be mistaken, but I think all of this virt I/O, virt Video, virt Sound, and virt USB is platform-independent?
09:57 < wsa> yes, but it needs to be done
09:57 <@geertu> wsa: "it"?
09:57 < wsa> some people sent virt-io for I2C patches just the last weeks
09:58 < wsa> probably because of exactly the effort morimoto-san mentions
09:58 <@geertu> wsa: Yeah, if you see weird things appearing these days, it's usually triggered by some Google Android push
09:59 < damm> i wonder if the next logical step after GPIO virtualization would be UART?
10:00 < damm> with whatever in-kernel UART consumer interface it might be possible to arrange something not too ugly looking?
10:00 <@geertu> damm: Doesn't that exist already? Serial console, disk, and net were the first I/O devices supported
10:00 < wsa> so, I guess something to tell Munakata-san is that we generally favor KVM over Xen?
10:00 < damm> sure, but we are talking both guest-virtio side and host backing driver too?
10:00 < wsa> and he would probably like to see KVM running on R-Car?
10:00 <@geertu> Now, this "KVM for Android" seems to be the inverse of what people usually do: they want to protect the guest against the host, not vice vera
10:01 < damm> i'm wondering if host backing side can be connected to physical uart
10:01 <@geertu> damm: (1st hit) https://stackoverflow.com/questions/39373236/redirect-multiple-uarts-in-qemu
10:03 <@geertu> KVM already works on R-Car Gen3 (like on other arm64 SoCs)
10:03 < damm> with uarts and QEMU a lot of magic is possible. but i wonder if actual hardware configuration settings will be propagated to the physical port
10:04 < damm> it is just speculation from my side though
10:04 <@geertu> damm: I think so, as the QEMU invocation does not specify e.g. baud
10:04 < damm> on my remote access system i use socat with the host side pty
10:04 < damm> which does not work with hardware settings
10:05 < damm> but physical device might work better
10:05 < damm> anyway
10:05 < damm> nice to see renewed interest in KVM
10:06 <@geertu> I don't think it makes much sense to start talking about "how long" and "cost" if the goal is unclear
10:06 < moriperi> geertu: Yes, indeed.
10:06 < moriperi> So, as 1st I will ask to Munakata-san about Renesas side plan.
10:06 < moriperi> Is it OK for you ?
10:07 <@geertu> Given Google's focus on GKI and making as much as possible platform-independent...
10:07 < damm> if needed we can try to bridge the gap and make use case proposals
10:07 < moriperi> Maybe Renesas will think about 202X budget for it.
10:08 <@geertu> moriperi: That's a valid point. So we need as many wild ideas as possible, to secure budget? ;-)
10:08 < damm> how about gRPC over virtIO uart to a coprocessor?
10:09 < moriperi> geertu: sounds nice :)
10:09 < moriperi> (joke)
10:09 < moriperi> 1 things he said was that Laurent indicated virt Video related things at elinux.
10:10 < moriperi> He and TOYOTA had interested about it.
10:10 <@geertu> I'm indeed not familiar with video virtualization
10:10 < moriperi> Maybe we need more ping-pong about it over email :)
10:11 <@geertu> moriperi: Please let laurent recover from 100 to 200% ;)
10:12 < moriperi> :)
10:12 < pinchartl> I don't plan to go back to an unsustainable schedule :-)
10:12 <@geertu> Anything else to discuss?
10:12 <@geertu> Next meeting?
10:12 <@geertu> In 3 weeks, is Dec 17. 4 weeks is Dec 24 (Xmas eve)
10:13 < wsa> 17th
10:13 <@geertu> So Dec 17 might be better, also considering Jinzai reporting schedule?
10:14 < wsa> xmas eve is a good reason for 17th, too ;)
10:14 < shimoday> 17th is ok to me
10:14 <@geertu> OK
10:14 <@geertu> Thanks for joining, and have a nice continued day!
|
