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!