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/20181018-core-chatlog | 272 ++++++++++++++++++++++++++++++++++++ 1 file changed, 272 insertions(+) create mode 100644 wiki/Chat_log/20181018-core-chatlog (limited to 'wiki/Chat_log/20181018-core-chatlog') diff --git a/wiki/Chat_log/20181018-core-chatlog b/wiki/Chat_log/20181018-core-chatlog new file mode 100644 index 0000000..c07db2b --- /dev/null +++ b/wiki/Chat_log/20181018-core-chatlog @@ -0,0 +1,272 @@ +Core-chat-meeting-2018-10-18 + +09:53 < geertu> Welcome to today's Core Group Chat! +09:53 < Marex> morimoto: sure :) +09:53 < geertu> Agenda: +09:53 < geertu> 1. Status Updates +09:53 < geertu> 2. Discussion Topics +09:53 < geertu> Topic 1. Status updates +09:53 < geertu> A) What have we done since last time: +09:53 < geertu> Jacopo reviewed RZ/A2 pinctrl, and joined the discussion on +09:53 < geertu> non-exclusive GPIOs. +09:53 < geertu> Kaneko-san posted D3 Thermal support. +09:53 < geertu> Marek handled Renesas feedback on U-Boot (incl. CPLD revival), +09:53 < geertu> worked on board compat string and FCNL node passing from ATF to +09:53 < geertu> U-Boot, and implemented PCIe SError recovery in ATF. +09:53 < geertu> Morimoto-san prepared images for the periperi and upport processes. +09:53 < geertu> Shimoda-san says Renesas Vietnam started testing LTSI v4.14, got an +09:53 < geertu> updated plan for the IPMMU driver from Magnus, and submitted usbhs +09:53 < geertu> patches (D3/E3 enablement + updates for other SoCs). +09:53 < geertu> Simon tested D3 Thermal support, posted periupport updates focussing on +09:53 < geertu> E3/D3, and looked for upstream/upporting tasks for Kaneko-san. +09:53 < geertu> Geert sent a pinctrl pull-request, an RFC to move SoC-specific ARCH_* +09:53 < geertu> symbols. He received an RSKRZA1 board, and has started digesting SYSC +09:53 < geertu> errata. +09:54 < morimoto> Marek: from BSP 3.8.0 (= next BSP), it will use U-Boot 2018.09 +09:54 < geertu> B) What we plan to do till next time: +09:54 < geertu> Kaneko-san will follow up on D3 Thermal support, and plans to enable +09:54 < geertu> E3 PMIC support. +09:54 < geertu> Marek will enjoy ELCE, PeriPeriCon, and the SDHI hackfest, and will +09:54 < geertu> continue discussing FCNL. +09:54 < geertu> Morimoto-san will finalize the process images, explain and discuss +09:54 < geertu> processes in Edinburgh, and confirm BSP review results to the BSP team. +09:54 < geertu> Shimoda-san will review the new IPMMU driver's plan, and says the RCV +09:54 < geertu> test team will continue testing LTSI v4.14 until Oct 24th. +09:54 < geertu> Simon will follow up on D3 thermal support, and update periupport +09:54 < geertu> updates using "make patch". +09:54 < geertu> Geert will attend ELC-E and the Automated Testing Summit, enjoy autumn +09:54 < geertu> holidays, and plans to continue digesting SYSC and PFC errata. +09:55 < geertu> C) Problems we have currently: +09:55 < geertu> Marek wonders if 0x47fe0000 is a reasonable address for parameter +09:55 < geertu> passing from ATF to U-Boot, and where to submit patches for Renesas' +09:55 < geertu> ATF? +09:55 < geertu> Morimoto-san thinks Laurent has a plan to create a sample format for BSP +09:55 < geertu> commits. +09:55 < geertu> Geert discovered the stock kernel doesn't work on RSKRZA1 (reboots +09:55 < geertu> immediately). +09:56 < geertu> Anything I missed? +09:56 < Marex> morimoto: awesome :-) +09:56 < Marex> morimoto: do you know if renesas is satisfied with the current state of U-Boot ? +09:56 < pinchartl> Marex: should we discuss ATF+U-Boot+FCNL now ? +09:57 < Marex> pinchartl: it's MM topic +09:57 < geertu> Topic 2. Discussion Topics +09:57 < geertu> FCNL itself is MM +09:57 < geertu> ATF+U-Boot is core +09:57 < patersonc> morimoto: BSP v3.8.0 = internal Yocto v3.13.0 release right? +09:58 < pinchartl> Marex: it's in-between :-) +09:58 < geertu> A. PeriPeriEdi Agenda +09:59 < geertu> I'll follow wsa, for core: +09:59 < geertu> - Overview +09:59 < geertu> - High level "what happened since last f2f meeting" +09:59 < geertu> - Is the group happy +09:59 < morimoto> Marex: I think so :) +09:59 < morimoto> patersonc: sorry, I'm not sure BSP <-> Yocto relationship +09:59 < geertu> I was also thinking about a (short) virtualization status? +10:00 < Marex> morimoto: whew, OK, thank you +10:00 < patersonc> morimoto: No worries. Yocto v3.13.0 is the release due out e/Oct +10:00 < geertu> And of course Morimoto-san's graphics skills: +10:00 < geertu> - PeriPeri "process" explanation and discussion. +10:00 < geertu> - "upport process" +10:00 -!- wsa_ is now known as wsa +10:01 < morimoto> :) +10:02 < wsa> geertu: no updates for virt from my side :( +10:03 < geertu> wsa: I meant for the PeriperiEdi agenda ;-) +10:03 < geertu> You have a few more days to change that ;-) +10:03 < Marex> morimoto: looks like I have a few bsp u-boot patches to review :) +10:03 < wsa> geertu: yeah :D +10:03 < patersonc> Marex: So u-boot 2018.09 supports all R-Car Gen2/3 boards? +10:04 < geertu> Any other topics for the PeriPeriEdi agenda? +10:04 < morimoto> I asked it to BSP team now. It seems they are happy, but want to have more feature. They said that shimoda-san is interface guy for it? I was asked to bring SD card for you in ELCE +10:05 < Marex> geertu: all Gen3 and about half of Gen2 (the ones which I have access to) +10:05 < Marex> patersonc: ^ +10:05 < Marex> patersonc: I still need to sort out the rest of Gen2 +10:06 < geertu> B. ATF+U-Boot+FCNL +10:06 < Marex> patersonc: it should be trivial, given that I have a Silk, Porter and Stout , so E2, M2W, H2 +10:06 < Marex> patersonc: porting Koelsch, Lager, Alt should be boring +10:06 < Marex> patersonc: Blanche might be challenging due to it's PNOR boot +10:06 < patersonc> Marex: Great +10:07 < patersonc> Marex: Thank you for the update +10:07 < Marex> morimoto: which features do they want ? +10:08 < Marex> patersonc: I'll probably do it next time I'm in Japan and can grab a few boards from damm -san's farm +10:08 < morimoto> Marex: it seems shimoda-san / goda-san will (?) post mail to you +10:08 < Marex> morimoto: got it :) +10:08 < horms> pinchartl: I pushed an update to periupport +10:09 < morimoto> Marex: when is that ? +10:09 < Marex> morimoto: the only grueling item for me is HS200 , it takes a lot of boot time to calibrate :( +10:09 < geertu> Marex: Anything to discuss about ATF+U-Boot+FCNL? +10:09 < Marex> morimoto: I'd like it to be next year for the first Jamboree that's gonna happen +10:09 < Marex> geertu: well, ATF, is the 0x47fe0000 good address for the DT ? +10:09 < morimoto> Marex: OK, looking forward to see you then +10:10 < pinchartl> horms: thank you +10:10 < Marex> morimoto: :-) +10:10 < Marex> morimoto: I'll make sure to submit some talk +10:10 < geertu> Marex: Do all R-Car Gen3 SoCs/boards have memory there? +10:10 < Marex> yeah +10:10 < Marex> geertu: all we know about +10:11 < Marex> geertu: plus the FCNL tables are at 0x47fd7000 , so I didn't pick the address at random +10:12 < wsa> Marex: i can give you my lager + alt in edi for a few days before the SDHI hackfest ;) +10:12 < geertu> That's part of the "first 128MB is reserved for secure area", right? +10:12 < Marex> wsa: I have a talk at E-ALE-E and two at YPDD, so I dont think I'll have time +10:12 < pinchartl> Marex: how about replacing the FCNL tables completely +10:13 < Marex> pinchartl: ABI ? +10:13 < wsa> Marex: ok +10:13 < Marex> wsa: but maybe in Dunbar ? +10:13 < geertu> And no suitable space in ICRAM? +10:14 < pinchartl> Marex: there's no upstream user of that ABI. BSPs can always revert the removal +10:14 < wsa> Marex: you mean if we run out of SDHI topics ;))) +10:14 < Marex> wsa: heh +10:14 < Marex> pinchartl: we can have both, it costs us nothing +10:15 < Marex> maybe a few instructions, but it's probably easier for renesas +10:15 < wsa> Marex: j/k, sure the boards will be in Dunbar, too +10:15 < pinchartl> Marex: code bloat ? +10:15 < Marex> not really +10:15 < Marex> wsa: :) +10:16 < Marex> wsa: should be quick too, so maybe a lunch topic +10:16 < Marex> pinchartl: the tables are generated while the FDT is generated, so that's really not adding much +10:17 < pinchartl> Marex: I won't work on it myself, but given that it's a BSP ABI, we don't neeed to care about it +10:17 < Marex> pinchartl: the real question is, what is the purpose of those tables and who is the user of those tables ? +10:17 < pinchartl> that's my opinion at least +10:17 < geertu> Agreed +10:17 < pinchartl> there's no upstream user +10:17 < pinchartl> FCNL isn't supported upstream +10:17 < geertu> yet? +10:18 < pinchartl> even enabling FCNL in ATF right now with upstream U-Boot + Linux will lead to a certain death +10:19 < Marex> so there's more than just parsing the tables in U-Boot +10:19 < Marex> U-Boot itself must not relocate itself into those areas +10:19 < Marex> so that's another item to add to the list +10:20 < pinchartl> data will be difficult to parse if it's overwritten, indeed :-) +10:20 < Marex> can someone put FCNL at 0x47000000 + 0x01000000 ? +10:20 < Marex> if so, then the FCNL tables would be in FCNL and it's all over +10:21 < damm> pinchartl: any reason why we cannot use dynamic FCNL handling? +10:21 < geertu> ICRAM would be safer for that... +10:21 < pinchartl> damm: what do you mean by dynamic ? +10:22 < damm> i meant that we can program the memory ranges for decoding on the fly +10:22 < damm> instead of using fixed reserved areas +10:22 < pinchartl> the memory ranges are programmed in the DRAM controller registers, and that's only available in secure mode :-( +10:22 < geertu> If ATF programs the security engine to allow that +10:23 < Marex> geertu: could be a security issue +10:23 < damm> pinchartl: isn't that a LifeC configuration issue? +10:23 < Marex> but allocating the FCNL dynamically would be indeed nice +10:24 < damm> i always thought we could use physical mirror addresses for the compression purpose +10:24 < damm> and statically configure the mirror addresses for de-compression purpose +10:24 < pinchartl> sa +10:24 < damm> and then let the linux-side just fiddle some physical bit to enable decompression +10:24 < pinchartl> damm: can LifeC allow access to only part of the DRAM controller registers in non-secure mode ? +10:25 < damm> pinchartl: not sure +10:25 < pinchartl> compression is handled by the FCP +10:25 < pinchartl> only decompression is done on the fly by the DRAM controller +10:25 < pinchartl> (amazing design, if you ask me...) +10:25 < damm> so i don't think the memory controller needs to be dynamically configured +10:25 < damm> just the use of physical addresses in linux needs to be dynamic +10:26 < geertu> pinchartl: decompression is simpler, and needs less resources, than compression +10:26 < pinchartl> geertu: I would have put everything in the FCP +10:26 < pinchartl> damm: I'm not sure to follow you +10:26 < damm> ok +10:26 < geertu> So if the DRAM is configured to do decompression on the whole shadow area, it'll work? +10:27 < damm> so right now we reserve a physical memory range for decompression +10:27 < damm> geertu: i think it should be considered at least +10:27 < geertu> pinchartl: Does the FCP do mem-to-mem decompression? That needs and extra memory buffer +10:27 < geertu> s/and/an/ +10:27 < pinchartl> geertu: no it doesn't, the FCP operates on the fly only, as a proxy for the VSP and other MM IP cores +10:28 < damm> i say we don't reserve a range and instead rely on the shadow area (that's the same as mirror i guess) +10:28 < pinchartl> right +10:28 < pinchartl> I got it +10:28 < pinchartl> it's not that simple +10:28 < pinchartl> as data can be stored in memory in different formats +10:29 < pinchartl> each FCNL area is configured for a specific format +10:29 < damm> i think with such solution we could enable compression per-buffer +10:29 < damm> so can we use multiple shadow areas? +10:29 < pinchartl> well, I suppose we could divide the shadow area, yes +10:29 < pinchartl> the division of the shadow area should still be passed from ATF all the way to Linux though +10:30 < damm> then just look at the physical address to determine format +10:30 < damm> yes +10:30 < pinchartl> so we would use the same mechanism +10:30 < damm> i'm not sure it would work but i think it is worth checking +10:30 < damm> right +10:30 < pinchartl> and use regular DRAM addresses or shadow addresses depending on whether we need to decompress or not +10:31 < damm> exactly +10:31 < pinchartl> this assumes that the shadow area won't be used for a different purpose, do we have any information about that ? +10:31 < damm> nope +10:31 < pinchartl> ok +10:31 < damm> sorry =) +10:31 < pinchartl> in any case, I expect that the mechanism for passing memory information from ATF to Linux to be the same +10:32 < pinchartl> it's just the Linux side that would be more dynamic +10:32 < pinchartl> it will be interesting to handle in combination with the IOMMU... +10:32 < damm> yes! +10:32 < pinchartl> interesting as in "get me out of here" :-) +10:33 < geertu> pinchartl: Depends on which memory region is set up for FCNL +10:33 < geertu> Again, can we use ICRAM to pass the info? +10:33 < pinchartl> geertu: to pass the FDT from ATF to U-Boot ? +10:33 < geertu> pinchartl: yes +10:33 < pinchartl> I have no issue with that +10:33 < Marex> geertu: that'd be perfect, but do we know what exactly renesas hides in ICRAM and where ? +10:33 < pinchartl> it's out of my scope :-) +10:34 < geertu> Marex: The first 16 KiB turns out to be inaccessible +10:34 < Marex> geertu: I need about 4 kiB of it +10:34 < geertu> It's used for secondary CPU bringup +10:34 < geertu> On Gen2 , that's Linux domain ;-) +10:34 < Marex> geertu: there's also the certheader +10:34 < Marex> geertu: we need to avoid overwriting that too +10:34 < Marex> geertu: and if we decide on using ICRAM, which address is "good" for renesas ? +10:34 < geertu> Marex: Can we (are we allowed) to overwrite that? +10:35 < Marex> geertu: I'd rather not, and it should be possible to avoid it +10:35 < geertu> Marex: Ehat happens if we overwrite that? +10:35 < geertu> s/Ehat/What/ +10:36 < Marex> geertu: I didn't try +10:36 < geertu> Marex: If it's critical, ATF should protect it +10:36 < Marex> geertu: heh +10:36 < geertu> "4 kiB should be enough for everyone"? +10:37 < Marex> morimoto: what does renesas think? Is there a 4 kiB space in ICRAM which we can use for the DT ? +10:37 < Marex> morimoto: and if so, which address would be preferred ? +10:37 < Marex> geertu: keep in mind there are systems with 128 kiB ICRAM (D3 and E3 I think), so they are a bit more size constrained +10:38 < Marex> geertu: and ... oh, BL2 is in ICRAM :/ +10:39 < Marex> geertu: but I wonder if BL2 can have a buffer at fixed location for this FDT in it +10:39 < Marex> geertu: then it'd be in ICRAM and in control of the compiler/linker +10:39 < morimoto> Marex: I don't know, I need to ask BSP team. please wait. +10:40 < Marex> morimoto: speaking of BSP team, I wonder if Yokoyama-san would be willing to hang out on this fine IRC ? :) +10:40 < geertu> Does it have to be a fixed address? Header with magic value? +10:40 < Marex> morimoto: would be nice to cooperate with him on U-Boot more +10:41 < Marex> geertu: it has to be fixed, since we thus far have no way to pass the FDT address from ATF to U-Boot +10:41 < Marex> geertu: that's only gonna happen in ATF 2.0 I think +10:42 < geertu> Marex: As I said, search for a magic header value in ICRAM? +10:42 < Marex> geertu: if I can put the buffer at a fixed address with simple linker magic, I'd go for that +10:43 < geertu> Marex: Sure, but if that's not possible on all SoCs... +10:43 < Marex> geertu: why wouldn't it be ? +10:43 < Marex> geertu: size constraints ? +10:43 < pinchartl> if the magic header can be searched on page boundaries it shouldn't be much of an overhead +10:44 < pinchartl> but if the address can also be fixed, it should be even less of an overhead :-) +10:44 < geertu> Marex: as you said, some SoCs have less ICRAM, and may use different parts for other purposes +10:46 < Marex> geertu: only D3 it seems +10:46 < geertu> Marex: Have you checked H3-N? +10:46 < Marex> I dont have minimon sources for H3N +10:46 < Marex> geertu: let's see the docs +10:46 < geertu> And the other unknown SoC being produced the day after tomorrow? +10:47 < Marex> geertu: silicon/next ? +10:47 < Marex> geertu: anyway, if we can put it into ICRAM, good +10:47 < damm> it can't be too difficult to read SoC version register (PRR?) and from there go for per-SoC base address if needed? +10:47 < Marex> geertu: then the question is, would renesas be willing to take the ATF patches ? +10:48 < Marex> damm: but unified == better +10:48 < damm> sure +10:48 < Marex> damm: I had this idea ... +10:48 < damm> we can be unified with what we have today, and special case upcoming stuff +10:48 < morimoto> Marex: I asked to BSP team, but it is implemented/using by 3rd party. So they don't know detail. If you can send me question mail, I can forward it to BSP/3rd party. +10:48 < Marex> damm: IFF ATF can pass board compatible string, U-Boot can select the right DT and then we can have single U-Boot for all Gen3 boards +10:48 < Marex> *gasp* +10:49 < Marex> morimoto: ATF ? +10:49 < damm> not bad +10:49 < Marex> geertu: the ICRAM is not documented in the datasheet, is it ? +10:50 < geertu> Marex: 21A System RAM? +10:51 < Marex> geertu: so D3/E3 could be an issue +10:51 < Marex> since I have ebisu, I can try +10:51 < morimoto> Marex: It was for 4kiB space in ICRAM +10:52 < morimoto> And it seems Yokoyama-san already go back to home today +10:52 < Marex> morimoto: sorry for keeping you here for so long +10:52 < morimoto> np +10:54 < geertu> Time to wrap up, and pass the torch^H^H^H^H^Hmic to pinchartl? +10:54 < Marex> geertu: well, let's try bundling the FDT into ICRAM then +10:54 < Marex> geertu: or, BL2 +10:55 < pinchartl> geertu: whenever you want +10:55 < pinchartl> we're only one hour late :-) +10:56 < geertu> And Niklas is still busy ;-) +10:56 < geertu> Let's fin(n)ish this ;-) +10:56 < geertu> Thanks for joining, and have a nice continued day! -- cgit v1.2.3