diff options
Diffstat (limited to 'wiki/Chat_log/20160830-core-chatlog')
| -rw-r--r-- | wiki/Chat_log/20160830-core-chatlog | 351 |
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! |