From 55e3b2f45880faaf06f3c660ca9e8a6d9aa14bce Mon Sep 17 00:00:00 2001 From: Kuninori Morimoto Date: Mon, 9 Dec 2019 15:29:52 +0900 Subject: wiki: Porting wiki: Porting Chat Log Signed-off-by: Kuninori Morimoto --- wiki/Chat_log/20180322-core-chatlog | 127 ++++++++++++++++++++++++++++++++++++ 1 file changed, 127 insertions(+) create mode 100644 wiki/Chat_log/20180322-core-chatlog (limited to 'wiki/Chat_log/20180322-core-chatlog') 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 =) -- cgit v1.2.3