Merge remote-tracking branch 'gitlab/wiki' into HEAD

1 files changed, 351 insertions, 0 deletions

diff --git a/wiki/Chat_log/20160830-core-chatlog b/wiki/Chat_log/20160830-core-chatlog
new file mode 100644
index 0000000..93e61f0
--- /dev/null
+++ b/wiki/Chat_log/20160830-core-chatlog
@@ -0,0 +1,351 @@
+Core-chat-meeting-2016-08-30
+
+10:08 < geertu> Welcome to today's Core Group Chat
+10:08 < geertu> Agenda:
+10:08 < geertu> 1. Status updates
+10:08 < geertu> 2. r8a7792/Wheat board is being/has been added to mainline
+10:08 < geertu> 3. r8a7795/H3ULCB board is pending: Cogent seems to have prioritised Wheat
+10:08 < geertu> 4. Renesas would like to know the kernel size issue on upstream.
+10:08 < geertu> Topic 1. Status updates
+10:08 < geertu> A) What have I done since last time
+10:08 < geertu> B) What I plan to do till next time
+10:08 < geertu> C) Problems I have currently
+10:08 < geertu> sort -R wants Simon to talk first
+10:11 < horms> Ok.
+10:11 < horms> A)
+10:11 < horms> * Verified Suspend-to-RAM appears to work the same with both UP and SMP
+10:11 < horms>   on H3/Salvator-X (M3-W/Salvator-X is UP in mainline)
+10:11 < horms>   Added test procedure
+10:11 < horms>   http://elinux.org/Tests:R-CAR-GEN3-Suspend-to-RAM
+10:11 < horms> B)
+10:11 < horms> * Finalise Suspend-to-RAM work by documenting hw/sw stack, writing report,
+10:11 < horms>   etc...
+10:11 < horms> * Begin work on kexec for M3-W.
+10:11 < horms> C) Problems I have currently
+10:11 < horms>                                                                                 
+10:12 < horms> * Kernel image size
+10:12 < horms> And some late breaking news:
+10:12 < horms> I have merged initial RSKRZA1 support
+10:12 < horms> And preliminarily verified that kexec functions on h3/salvator-x
+10:12 < horms> --- end ---
+10:13 < geertu> That's good news! No need to kick Geoff?
+10:13 < horms> Well, his userspace patches still haven't been merged (by me)
+10:13 < horms> because they are still recieving review
+10:14 < horms> but thats not a blocker for my work
+10:14 < horms> And I am also unsure if his patches do/should support running in a 32bit userspace
+10:14 < horms> Probably they should
+10:14 < horms> I will check that
+10:14 < horms> and engage with him if needed
+10:14 < horms> Then onwards to m3-w
+10:14 < horms> which is a little more tricky
+10:14 < horms> due to needing to use initrd
+10:14 < horms> but the board has sd cards in it now
+10:15 < horms> so i can probably make use of that somehow
+10:15 < horms> actually, the tricky part is no network
+10:15 < horms> so its a bit fun to transfer the second kernel image and kexec binary
+10:15 < horms> but I'm sure it can be done somehow
+10:16 < horms> --- enough on kexec? ---
+10:16 < geertu> Ravb should work on M3-W with a compatible update
+10:16 < horms> ok, that is also an option
+10:16 < horms> nicely moves m3-w integration forwards at the same time
+10:16 < geertu> Alternatively, you can ask Magnus to connect the second serial port.
+10:17 < horms> and use it for bulk transfers somehow?
+10:17 < geertu> Keep 64-bit RAM and IOMMU in mind before pushing it out ;-)
+10:17 < geertu> I used gzip and uuencode to transfer DT overlays to H3 before I had physical access
+10:17 < horms> yeah, i'm not convinced about the ordering we have decided on for integration. but given that we have decided on an order I'll try not to break it
+10:18 < horms> right, that could work too
+10:18 < geertu> (Magnus initrd does have uudecode)
+10:18 < horms> probably firing up ravb is nicer :)
+10:18 < horms> magnus inired is 32bit
+10:18 < geertu> yeah, then you can tftp the files from the management host
+10:19 < horms> if i have network, right?
+10:19 < horms> i.e. ravb
+10:19 < geertu> 32-bit userspace should work.
+10:19 < horms> as i mntioned above
+10:19 < geertu> But you're worried about the kexec binary?
+10:19 < horms> i'm unsure if kexec-tools works
+10:19 < horms> ys
+10:19 < horms> yes
+10:19 < horms> probably copiling for armel
+10:19 < horms> makes a binary that wants to operate on 32bit hosts
+10:19 < horms> just guessing
+10:19 < horms> as I mentioned above I plan to look into that
+10:20 < horms> but in any case I'd like to test 64bit userspace
+10:20 < geertu> You need to compile your own kexec-tools anyway, so just link it statically. The rest of the initrd can stay 32-bit.
+10:20 < horms> ok, i was wondering about that
+10:20 < horms> thanks for the info
+10:22 < geertu> Thanks Simon.
+10:23 < geertu> Next is Lurking Laurent (sounds like an Ubuntu release :-)? Anything to say?
+10:23 < pinchartl> nope, nothing to report
+10:24 < pinchartl> or maybe
+10:24 < pinchartl> I've been working before going on holidays on IPMMU + DU integration
+10:24 < pinchartl> (tested on Gen2 only as the H3 IPMMU is known to be buggy)
+10:24 < pinchartl> I've posted a patch series
+10:25 < pinchartl> which touches multimedia drivers and DT only, no change to the IPMMU driver or the IOMMU or DMA mapping layers
+10:25 < pinchartl> I'd appreciate feedback on them, but that might be a multimedia topic more than a core topic
+10:25 < pinchartl> although the issue at hand is quite generic
+10:25 < pinchartl> that's it for me
+10:26 < horms> pinchartl: Magnus may be looking into that
+10:26 < geertu> Thanks Laurent.
+10:26 < geertu> Next is myself
+10:26 < geertu> A) - completed MSIOF parent clock prototype,
+10:27 < geertu>    - Resumed MODEMR (APMU debug resource reset for secondary CPU boot), ...
+10:27 < geertu> B) Continue RST, MODEMR, ES-handling, ...
+10:27 < geertu> C) Nothing
+10:28 < geertu> So I posted a patch series to do APMU debug resource reset for secondary CPU boot
+10:28 < geertu> So far I didn't see any ill effects (running Koelsch with SW8-4 is off all the time)
+10:28 < geertu> Haven't tried JTAG yet
+10:29 < geertu> Unfortunately the issue it fixes is very hard to trigger.
+10:29 < geertu> But from a source code management point of view, one check less of the MODEMR pins.
+10:30 < geertu> EOT
+10:32 < geertu> Next is Shimoda-san
+10:32 < shimoda> yes
+10:32 < shimoda> A)
+10:32 < shimoda> I'm focus on Gen3 USB EHCI + IPMMU issue.
+10:32 < shimoda> So, nothing for core.
+10:32 < shimoda> B)
+10:32 < shimoda> I should describe an explanation of "Lossy" into eLinux...
+10:32 < shimoda> C)
+10:32 < shimoda> I would like to know whether the PFC bias setting I made for USB is correct or not.
+10:32 < shimoda> Please see the email of "RE: [periperi] About splitting the USB pins in r8a7795".
+10:33 < shimoda> The sent date is "Monday, August 22, 2016 10:48 AM" (JST).
+10:33 < geertu> I think it is (I did reply, right?)
+10:33 < geertu> My only comment was naming of the nodes
+10:34 < shimoda> oops, i missed your email...
+10:34 < shimoda> let me check...
+10:36 < shimoda> i found your email and i got it! thank you for comment!
+10:39 < geertu> Thanks Shimoda-san.
+10:39 < geertu> Next is Magnus, who hasn't reappeared on irc
+10:39 < geertu> Next is Ulrich.
+10:39 < uli___> a) resent m3-w pfc to universal approval
+10:40 < uli___> did a hardcore copy-and-paste job of sys-dmac integration on m3-w
+10:40 < uli___> b) test sys-dmac with my new board scheduled to arrive today
+10:40 < uli___> c) none
+10:40 < uli___> re-sent, not resent :)
+10:40 < uli___> that's it
+10:42 < geertu> I sent a pull request incl. your r8a7796 pfc changes
+10:42 < geertu> Unfortunately LinusW hasn't pulled it yet.
+10:42 < morimoto> Is it for v4.9 ? or v4.8 ?
+10:42 < geertu> v4.9
+10:42 < morimoto> OK, thanks
+10:43 < khiemnguyen> geertu: how much time is remained for v4.9 ?
+10:43 < geertu> As soon as LinusW has pulled it, Simom can pull it too, and start applying PFC patches to r8a7796-salvator-x.dts
+10:43 < geertu> We're at -rc4
+10:43 < geertu> s/Simom/Simon/
+10:43 < khiemnguyen> 3 weeks ?
+10:43 < geertu> Depending on the maintainer, you can submit patches for v4.9 until ca. -rc6
+10:45 < horms> I would like to finalise our submissions next week
+10:45 < horms> submissions to arm-soc that is
+10:45 < horms> so they arrive in their inbox before rc6
+10:45 < horms> which is their requirement
+10:46 < geertu> Thanks Ulrich.
+10:46 < geertu> Next is Morimoto-san
+10:46 < morimoto> OK
+10:46 < morimoto> Basically I have no special Core tasks.
+10:46 < morimoto> But, I have shipped M3 board to you guys, except Simon.
+10:46 < morimoto> I hope each EuroPeri's VAT number will works well on Europe side.
+10:46 < morimoto> I pushed M3's firmware on new page of our Wiki. And moved H3's firmware to it.
+10:46 < morimoto> Please check it if you have interresting
+10:47 < morimoto> horms: I'm waiting your feedback for it.
+10:47 < morimoto> I noticed that BSP's (?) CMT patch breaks NFS boot on latest renesas-drivers.
+10:47 < morimoto> I think it works correctly on previous kernel version.
+10:47 < morimoto> BSP team want to know kernel size issue, but this is next topics (?).
+10:47 < morimoto> that's all from me
+10:47 < geertu> FYI, my board is also scheduled to arrive today.
+10:47 < geertu> Hence a big thanks (or is that too early ;-)
+10:47 < horms> morimoto: thanks and sorry for the delay. I think there has been some progress. I will let you know when I know with some more certainty.
+10:48 < morimoto> horms: thanks. no problem.
+10:48 < horms> Oh, wiki feedback?
+10:48 < geertu> s/CMT/CMA/?
+10:48 < horms> or eori feedback?
+10:48 < morimoto> geertu: I hope your VAT number works well
+10:48 < morimoto> Oops CMA
+10:48 < geertu> morimoto: I think so, it's printed on the PDF docs I already received by email.
+10:49 < geertu> Those documents also mention 2.6% custom duty and 21% VAT, but it's not clear I'll have to pay that
+10:50 < morimoto> Oops ? you need to pay something ?
+10:50 < geertu> morimoto: I don't know. Last year I didn't. But Laurent had to?
+10:51 < morimoto> Shipping payment was controlled by Renesas side paper work. I think your side no need to pay
+10:51 < morimoto> I don't know Europe's tax pay...
+10:52 < morimoto> geertu: please let me know if you pay something
+10:53 < geertu> morimoto: The M3-W arrived 30 seconds ago, thanks!
+10:53 < geertu> So far nothing to pay...
+10:53 < morimoto> Wow !
+10:54 < morimoto> EuroPeri side have new world !
+10:55 < geertu> Thanks Morimoto-san.
+10:55 < geertu> Next is Niklas
+10:55 < neg> Easy for me this time, a) and b) Nothing for core c) Still waiting for RMK to review the IOMMU+DMAC patchset
+10:56 < morimoto> horms: sorry for late response. I need EORI or VAR number
+10:57 < geertu> RMK can be a PITA...
+10:57 < horms> morimoto: ok. i am on the case
+10:57 < geertu> morimoto: You didn't need an EORI for me?
+10:57 < morimoto> geertu: simon was special case
+10:58 < morimoto> According to shipping guy, basically VAT number is enough
+10:59 < geertu> AFAIK EORI is for the person who performs customs handling, i.e. the shipping company at the receiving end.
+10:59 < morimoto> But I'm happy if I can get your EORI number next time
+10:59 < geertu> I don't have one, and according to the Belgian government website, I only need if I want to do customs handling myself.
+11:00 < morimoto> The reason why simon need EORI is his VAT number was not yet registered (?)
+11:01 < horms> no
+11:01 < horms> the reason is a mystery
+11:01 < horms> I have a VAT number, which I supplied
+11:01 < horms> but I was told I also need an EORI number
+11:01 < horms> I asked, "really?". The answer was yet.
+11:01 < geertu> It can take a while for VAT numbers to appear in all databases...
+11:01 < horms> I asked, "really?". The answer was yes.
+11:02 < horms> right, that seems like the most likely explanation
+11:02 < horms> the magic web site now says my eori number is valid
+11:02 < horms> which is new
+11:02 < horms> so perhaps that is enough
+11:02 < horms> I am trying to confirm that
+11:03 < morimoto> horms: my email which from shipping guys said
+11:03 < morimoto> you didn't have "VAT deferment license", but if you have EORI you can receive
+11:03 < horms> ok
+11:04 < morimoto> Hmm.. mystery
+11:04 < morimoto> neg: sorry for interrupt your report
+11:05 < neg> morimoto: np, I did not have much to repoert anyhow and feel I got that out :-)
+11:06 < morimoto> your one will be forwarded from magnus
+11:06 < geertu> Thanks Niklas.
+11:07 < geertu> Finally, Khiem.
+11:07 < khiemnguyen> A) Nothing yet.
+11:07 < khiemnguyen> B) Try to catch the kernel v4.9 for CPUFreq.
+11:07 < khiemnguyen> I wonder how much time is remained, 2 weeks ?
+11:07 < khiemnguyen> C)
+11:08 < khiemnguyen> Some additional work are assigned.
+11:08 < khiemnguyen> I'm struggling to find time for upstream work.
+11:08 < khiemnguyen> That's all for now.
+11:09 < khiemnguyen> Please advice how much time is remained :)
+11:09 < geertu> Less than two weeks.
+11:09 < geertu> One week for changes to the dts(i)
+11:10 < khiemnguyen> geertu: I see. Let's me try to push the patches this week or early next week. It's my last chance, I think.
+11:10 < khiemnguyen> s/Let's/Let
+11:14 < horms> good plan
+11:15 < geertu> Yep.
+11:15 < geertu> Thanks Khiem!
+11:15 < geertu> Topic 2. r8a7792/Wheat board is being/has been added to mainline
+11:15 < geertu> I guess the recurring issue is board documentation?
+11:15 < geertu> and board access
+11:17 < geertu> horms: Anything particular you wanted to discuss?
+11:17 < horms> we have the boot size issue, but perhaps that is best discussed on the periperi ml
+11:17 < geertu> I mean about r8a7792/wheat
+11:18 < horms> no, not that i can think of
+11:18 < geertu> Topic 3. r8a7795/H3ULCB board is pending: Cogent seems to have prioritised
+11:18 < horms> documentation is always nice :)
+11:18 < geertu> Topic 3. r8a7795/H3ULCB board is pending: Cogent seems to have prioritised Wheat
+11:19 < horms> I guess thats their call
+11:19 < horms> they were on my case to move h3ulcb
+11:19 < horms> but about the same time that I got the green light from Renesas they moved onto something else
+11:20 < horms> so i guess its not going to appear in v4.9
+11:20 < morimoto> I think I sent ulcb info to EuroPeri ?
+11:20 < morimoto> I think we can have few ulcb board 9/E.
+11:21 < geertu> morimoto: Yes, I got the docs, thanks for that!
+11:21 < morimoto> geertu: np
+11:21 < morimoto> I will ask to Magnus for remove access.
+11:21 < morimoto> s/remove/remote/
+11:21 < geertu> Magnus said a while ago he already has a Blanche.
+11:22 < geertu> And I believe he also has an RSK?
+11:22 < morimoto> geertu: I don't know about his RSK
+11:23 < shimoda> horms: about h3ulcb, if renesas japan needs to merge it into v4.9, what we should do?
+11:24 < horms> shimoda: ok, if its important I think we have two options
+11:24 < horms> 1) rework the patches a bit ourselves
+11:24 < horms> 2) put some pressure on cogent, perhaps via artemi
+11:24 < horms> I have tried to encourage Sergei to do something but he is quite resistant to encouragement from me
+11:25 < horms> option 1 implies someone has access to a board for testing
+11:25 < shimoda> horms: ok. goda-san consider about this board to upstream. so, 3) goda-san (and munakata-san?) put some pressure on cogent too :)
+11:26 < morimoto> From munakata-san can be nice pressure :)
+11:26 < horms> Yes, that is what I meant by 2)
+11:26 < horms> I'm sure Cogent can do something if pressure is applied in the right place
+11:27 < horms> to be clear all I would like is for the patches to be split up (and of course re-tested)
+11:27 < horms> And I would like to merge the patches by next Wednesday. So probably they need to be posted a bit earlier than that to allow some review etc...
+11:28 < shimoda> horms: i got it. i prefer 2). so I will forward this infor to goda-san.
+11:28 < horms> ok. let me know if you need any support.
+11:29 < shimoda> horms: ok. thanks!
+11:29 < geertu> Topic 4. Renesas would like to know the kernel size issue on upstream.
+11:29 < geertu> You think this is best suited for the ML?
+11:31 < horms> We can cha here if you prefer
+11:31 < horms> But really I think we need a way to allow the mainline defconfig to keep working so we can test it
+11:31 < horms> That can be without inird if necessary, so we still have some space to play with
+11:32 < horms> But probably it will keep growing
+11:32 < horms> And unless other vendors, who actually use mainline, have a 16MB limit we will be carring a very heavy burden to try to keep the defconfig below that limit. e.g. using modules
+11:32 < horms> So I would like to know if it is practical to boot the kernel at a different location
+11:33 < geertu> If it's just about testing arm64 defconfig, to catch issues caused by the presence of foreign drivers, you can always boot using a smaller kernel, and kexec into the large one
+11:33 < horms> hmmm, good point
+11:34 < horms> but really is it too much to ask for things to work out of the box?
+11:34 < horms> perhaps it is
+11:34 < horms> kexec may be a good work-around
+11:34 < horms> as i understand things the limitatino we have is
+11:34 < horms> that the kernel is unpacked at 0x4800 0000
+11:35 < horms> and uboot us at 0x4900 0000
+11:35 < horms> so if the kernel is too big it overwrites u-boot
+11:35 < horms> presumably that is not a problem when kexecing as uboot is long out of the picture
+11:35 < horms> is that correct?
+11:36 < geertu> Yes
+11:36 < geertu> I've used kexec to boot multi_v7_defconfig on e.g. armadillo
+11:36 < horms> Ok, probably Magnus needs to be involved in this discussion.
+11:36 < horms> But it may be a good option.
+11:37 < geertu> Still, our downstream users will not use arm64 defconfig for products
+11:37 < geertu> So providing a renesas64_defconfig somewhere makes sense
+11:38 < geertu> A disadvantage is that it needs to be maintained
+11:38 < horms> I understand that
+11:38 < horms> but yes, i see the downside too
+11:38 < horms> and frankly its 1/2 a step away from upstream first
+11:38 < horms> Perhaps I am overreacting
+11:39 < geertu> Well, upstream first usually does't apply to defconfigs
+11:39 < geertu> Esp. not for embedded.
+11:40 < horms> ok, I'll just say that I think its nicer if it does. But perhaps its not practical if arm64 only has one defconfig. And I need to just move on.
+11:40 < horms> Certainly I think kexec could be a solution for testing the defconfig
+11:40 < horms> And we could consider maintaining renesas64_defconfig out of tree
+11:41 < horms> e.g. in the renesas tree but not mainline itself
+11:41 < horms> shimoda: how do you feel about this?
+11:42 < shimoda> horms: renesas64_defconfig is good to me
+11:42 < horms> ok, lets raise this with Magnus then
+11:43 < shimoda> but about kexec, it is complex to me :)
+11:44 < horms> yes, that is the down side
+11:44 < horms> and as a bonus booting will take evern longer remotely
+11:45 < horms> but I think the gernal idea would be to bake two kernels
+11:45 < horms> 1 small one, possibly with an initrd certainly with kexec
+11:45 < horms> boot into it, transfer the second image, say using tftp of something tcp based when operating remotely
+11:46 < horms> then kexec -l Image --dtb xyz.dtb; kexec -e
+11:46 < horms> More moving parts
+11:46 < horms> more things to go wrong
+11:46 < horms> but probably it could be made to work
+11:47 < geertu> For normal development, you can still use the small config
+11:47 < horms> for me my normal work is mostly testing mainline defconfig is still working
+11:47 < geertu> I usually use a per-board config anyway
+11:47 < geertu> But regularly test shmobile_defconfig on koelsch, and arm64 defconfig on salvator-x
+11:48 < horms> ok, i take your point
+11:48 < geertu> multi_v7_defconfig is just too big to boot on anything these days
+11:48 < horms> for actually development work that makes sense
+11:48 < horms> i regard that config as being of theoretical use to Arnd rather than practical use to anyone
+11:49 < horms> Anyway, I will see about looking into this as part of my existing work on kexec
+11:49 < horms> because I need to do something like this for that work anyway
+11:49 < geertu> And on arm64 we only have the config for theoretical use ;-)
+11:49 < horms> right, sadly I think I will have to agree with you there
+11:50 < horms> which would remove my main objection
+11:50 < geertu> BTW, do you need the --dtb option of kexec?
+11:50 < geertu> root@koelsch:~# cat $(type -p tftp-kexec )
+11:50 < geertu> #!/bin/bash
+11:50 < geertu> IMAGE=zImage
+11:50 < geertu> set -e
+11:50 < geertu> ( echo verbose; echo get $(hostname)/$IMAGE /tmp/$IMAGE ) | tftp ayla
+11:50 < geertu> kexec -l /tmp/$IMAGE --append="$(cat /proc/cmdline)"
+11:50 < geertu> kexec -e
+11:50 < geertu> root@koelsch:~# 
+11:51 < geertu> That's what I use
+11:51 < horms> Ok, good to know that works
+11:52 < horms> I'll see if it can be done on arm64 too
+11:52 < horms> does your image have the dtb appended?
+11:52 < geertu> No
+11:52 < horms> if not I guess its extracted from the running kernel somehow
+11:52 < geertu> Yes, that's what I thought, too
+11:53 < horms> I do see some value to explictly providing a dtb
+11:53 < horms> but I'll look into why what you have above works
+11:54 < geertu> IIRC, it doesn't work with the kexec binary in Magnus' initrd.
+11:54 < geertu> My userland is Debian NFS root
+11:54 < horms> me too
+11:54 < horms> i'm unsurprise that kexec binary doesn't work
+11:54 < horms> it must be ancient by now
+11:55 < geertu> I think it's time to conclude
+11:56 < geertu> (and unpack the M3-W ;-)
+11:56 < morimoto> :)
+11:56 < shimoda> good luck! :)
+11:57 < horms> enjoy + bye
+11:57 < geertu> Thanks for joining, and have a nice continued day!