Merge remote-tracking branch 'gitlab/wiki' into HEAD

1 files changed, 127 insertions, 0 deletions

diff --git a/wiki/Chat_log/20180322-core-chatlog b/wiki/Chat_log/20180322-core-chatlog
new file mode 100644
index 0000000..38af15d
--- /dev/null
+++ b/wiki/Chat_log/20180322-core-chatlog
@@ -0,0 +1,127 @@
+Core-chat-meeting-2018-03-22
+
+09:40 < geertu> Welcome to today's Core Group Meeting!
+09:41 < geertu> Laurent and Marek are excused
+09:41 < geertu> Everybody else seems to be here
+09:41 < geertu> Agenda:
+09:41 < geertu> 1. Status Updates
+09:41 < geertu> 2. Discussion Topics
+09:41 < geertu> Topic 1. Status updates
+09:42 < geertu> A) What have we done since last time:
+09:42 < geertu> Marek added M3N support to mainline u-boot, revisited PCIe upports, and
+09:42 < geertu> presented 4 talks about U-Boot in the US.
+09:42 < geertu> Shimoda-san submitted M3-N usb related DTS patches, discussed about 4/8
+09:42 < geertu> GiB support for R-Car H3 ES3.0, and prepared IPMMU workarounds for R-Car 
+09:42 < geertu> H3 ES3.0.
+09:42 < geertu> Ulrich sent fix-ups for VIN4 pin definitions.
+09:42 < geertu> Geert sent the first clk and pfc pull request for v4.17, sanitized 
+09:42 < geertu> EtherAVB pin groups, sent V2 of in-kernel BD9571MWV DDR backup mode, and
+09:42 < geertu> annotated upport items.
+09:42 < geertu> (so I have received Simon's and Uli's emails in the mean time. Anything else I missed/still in email flight?)
+09:43 < wsa_> except for discussion, no new updates arrived on my side
+09:43 < jmondi> geertu: no updates for Core
+09:43 < geertu> B) What we plan to do till next time:
+09:43 < geertu> Shimoda-san will submit PWM PFC patches for R-Car M3-N, and
+09:43 < geertu> discuss with Magnus a plan to improve the IPMMU driver, and will try to
+09:43 < geertu> port initial code for R-Car E3 Ebisu.
+09:43 < geertu> Simon will probably do more DTS cleanup work (soc node and sorting).
+09:43 < geertu> Geert will send the second clk and pfc pull request for v4.17, and
+09:43 < geertu> revisit vfio and qemu patches.
+09:43 < geertu> jmondi: thx
+09:44 < geertu> C) Problems we have currently:
+09:44 < geertu> None (hmm)
+09:45 < geertu> dammsan is playing with old boards? ;-)
+09:46 < geertu> Topic 2. Discussion Topics
+09:46 < dammsan> geertu: wait when you get to see the SH board collection =)
+09:46 < geertu> We still sort of have the 4/8 GiB support for R-Car H3 ES3.0
+09:47 < geertu> dammsan: Do they boot renesas-drivers?
+09:47 < geertu> Unfortunately Marek U-Boot is not here
+09:48 < geertu> horms: What's your stake?
+09:49 < Marex> geertu: I kinda am
+09:49 < horms> Ok, so the problem is we have different memory available but no good way to handle that with out current DT arrangement?
+09:49 < dammsan> geertu: they currently collect dust
+09:50 < Marex> geertu: what's up ?
+09:51 < geertu> Marex: Where do you get memory size from on Gen3? DTS?
+09:51 < Marex> geertu: yes
+09:52 < geertu> H3 ES3.0 SiP may come with either 4 or 8 GiB
+09:52 < geertu> E3 SiP may come with either 1, 2, or 4 GiB of RAM
+09:52 < Marex> joy
+09:52 < horms> ok, nice and complex
+09:52 < horms> I guess we have no nice way to handle this at run-time
+09:52 < Marex> geertu: is there a way to probe/detect that ?
+09:52 < shimoda> geertu: E3 is not SiP, that will be 3 boards :)
+09:52 < Marex> geertu: U-Boot has the ability to check for memory mirrors, but that's about that
+09:54 < geertu> shimoda: Sorry, E3 board (as long as we don't have SiP .dtsis, board or SiP doesn't matter ;-)
+09:54 < wsa_> Marex: BTW is there Gen3 WDT support in U-Boot?
+09:55 < Marex> wsa_: no, is it needed ?
+09:55 < Marex> wsa_: I am collecting requests for stuff to make people's life easier
+09:55 < shimoda> geertu: ;)
+09:55 < wsa_> Marex: well, kinda. We want to fix an issue in the WDT driver but can't sell it to the maintainers as is. We could sell it if we implement WDT handover from the bootloader :/
+09:56 < wsa_> However, that might be a customer use case, too, so it is not that bad...
+09:57 < Marex> wsa_: wdt handover ? how would that work ?
+09:57 < Marex> wsa_: ha
+09:57 < Marex> wsa_: U-Boot will just leave the WDT on and the kernel/userspace should continue poking it, to prevent reset
+09:58 < wsa_> Marex: I haven't looked into the details, but probably the driver needs to check if the WDT is already running and tell the Linux WDT core
+09:58 < shimoda> horms: geertu: since we have no nice way for memory map configuration automaticaly, may I reply to BSP team about this? This means BSP team will create several DTS files :)
+09:58 < geertu> Marex: 
+09:58 < horms> shimoda: i think that is the best option at this time
+09:59 < shimoda> horms: i got it. thanks!
+09:59 < geertu> Marex: If U-Boot could check if all memory banks exist, it could do probe of memory size
+09:59 < dammsan> exactly
+09:59 < wsa_> Marex: but however it works, a way to start the WDT in U-Boot will be needed ;)
+09:59 < geertu> Looks like md doesn't handle > 32-bit addresses?
+09:59 < geertu> Or is it not mapped?
+09:59 < dammsan> checking the ddr controller settings must be possible?
+09:59 < geertu> md = U-Boot md command
+10:00 < shimoda> horms: i have one more question. when bsp team creates 2 types of DTS, one of dts file can include another one?
+10:00 < geertu> dammsan: ATF is responsible for programming the DDR ctrlr, right?
+10:00 < dammsan> most likely
+10:01 < dammsan> but determining the setting during runtime from u-boot might be possible?
+10:01 < dammsan> other platforms must have the same issue
+10:01 < geertu> shimoda: Yes, the sample 8-gb dts you had, including the 4-gb .dts and overriding it, looks fine to me (if we go the route of multiple dts)
+10:02 < geertu> But I'd like to avoid the proliferation of DTSes
+10:02 < dammsan> geertu: me too
+10:02 < shimoda> geertu: I got it, thanks! I will forward this information to BSP team
+10:02 < geertu> So if U-Boot can autodetect, that would be great
+10:03 < dammsan> indeed
+10:04 < geertu> We can e.g. compare DDR register between M3/Salvator-X and M3ULCB (4 GiB vs. 2 GiB)
+10:05 < horms> shimoda: yes, i think there is an example of that for the RZ/G1 DT
+10:07 < dammsan> geertu: or do a simple write-read test for mirroring
+10:07 < shimoda> horms: thanks for the RZ/G1 info. I'll look that
+10:08 < geertu> dammsan: If it shows up as a mirror copy of the existing RAM. It may go buserr, too.
+10:08 < dammsan> but which areas that are mapped can probably be determined by DDR controller settings or similar
+10:08 < geertu> yes
+10:09 < dammsan> to see if it is safe to access them or not
+10:09 < geertu> If U-Boot can access the registers (you never know with ATF)
+10:09 < dammsan> true
+10:10 < Marex> geertu: can't you do SVC call into the ATF to determine the memory size ?
+10:10 < Marex> geertu: but then again, Id like to have one set of blobs per SoC (or even per family)
+10:11 < dammsan> that would make sense
+10:11 < geertu> On your M3ULCB, the non-existing memory at 80000000 reads back zeroes
+10:11 < Marex> geertu: so being able to detect the DRAM size would be very welcome
+10:11 < geertu> Marex: AFAIK there's no memory size API in the ATF
+10:11 < geertu> Writing to 80000000 works (= does not crash), still reads back zeroes afterwards
+10:11 < Marex> (I want to complain about ATF being sub-optimal, but I guess everyone knows my opinion on it)
+10:11 < dammsan> worst case we can use spectre/meltdown to determine memory size without bothering ATF =)
+10:12 < geertu> On M3/Salvator-X, I can read/write at 80000000 fine
+10:12  * pinchartl is back
+10:12 < shimoda> dammsan: sorry for the delay, about write-read test for mirroring is not good because the hw might caure deadlock.
+10:13 < geertu> If H3 ES3 and E3 behave the same, we can probe that way
+10:13 < geertu> shimoda: Yeah, that was my worry too, but it seems to work on M3-W SiP ;-)
+10:13 < dammsan> shimoda: it would have to be probed in a certain safe order for it to be useful
+10:14 < dammsan> shimoda: do you think it is impossible? =)
+10:15 < shimoda> dammsan: BSP team asked hw guys about the this topic, and then hw guys rejected this approauch because this way is possible to cause deadlock
+10:15 < geertu> Hmm, e6790000 reads back as zeroes
+10:15 < geertu> so DBSC4 is protected?
+10:17 < shimoda> geertu: I guess DBSC4 reg area is in secure world
+10:18 < geertu> shimoda: So we cannot read the DBSC4 regs, but can cause deadlock by reading non-existent memory? ;-)
+10:18 < dammsan> shimoda: thanks for explaining =)
+10:19 < shimoda> geertu: yes :)
+10:19 < geertu> shimoda: Then IMHO ATF should provide the information we need...
+10:19 < shimoda> dammsan: I should have descriped such information on my report though...
+10:20 < geertu> I think the time has come to conclude the meeting
+10:20 < geertu> Annything else to discuss?
+10:21 < shimoda> nothing from me
+10:21 < geertu> OK
+10:21 < geertu> Thanks for joining, and have a nice continued day!
+10:22 < dammsan> geertu: AXI bus section has details about memory protection areas =)