renesas/periject.git - Renesas periject clone

diff options

author	Geert Uytterhoeven <geert+renesas@glider.be>	2020-02-27 09:44:57 +0100
committer	Geert Uytterhoeven <geert+renesas@glider.be>	2020-02-27 09:45:19 +0100
commit	f511d9f94d9861a80d40f38ffb17e9c64c5f710a (patch)
tree	304c9c4caa31a3cb00bda4da001962b35dbb6c67 /wiki/Chat_log/20150819-core-chatlog
parent	1a18ed21ddadebd60e94acb95475b69fb8f6030d (diff)

wiki: Add Core chatlog for 2020-02-27

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>

Diffstat (limited to 'wiki/Chat_log/20150819-core-chatlog')

0 files changed, 0 insertions, 0 deletions

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" :-)


context:
space:
mode: