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!