path: root/wiki/Chat_log/20160830-core-chatlog

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!