wiki: Porting wiki: Porting Chat Log

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

1 files changed, 272 insertions, 0 deletions

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!