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 =)