15:00:16 <pwhalen> #startmeeting Fedora ARM and AArch64 Status Meeting
15:00:16 <zodbot> Meeting started Tue Apr 25 15:00:16 2017 UTC.  The chair is pwhalen. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:16 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:16 <zodbot> The meeting name has been set to 'fedora_arm_and_aarch64_status_meeting'
15:00:16 <pwhalen> #chair pwhalen pbrobinson dgilmore hrw dmarlin yselkowitz jonmasters ahs3 msalter
15:00:16 <zodbot> Current chairs: ahs3 dgilmore dmarlin hrw jonmasters msalter pbrobinson pwhalen yselkowitz
15:00:48 * pbrobinson o/
15:01:02 * rric o/
15:01:15 <pwhalen> howdy rric, how goes?
15:01:24 <rric> Hi, not too bad :)
15:02:00 * pwhalen waits a minute for others
15:03:28 <pwhalen> ok, lets get started ..
15:03:29 <pwhalen> #topic 1) ==== Userspace Status  ====
15:03:58 <pwhalen> anyone hitting any userspace issues? build or usage?
15:04:43 <pbrobinson> nothing from my PoV
15:06:11 <pbrobinson> jlinton: you about?
15:06:32 <pwhalen> #info Bug 1443415 - Upgrade f25 to f26 get stuck on Cleanup krb5-libs
15:06:53 <pbrobinson> pwhalen: that would be a all arches wide issue?
15:07:05 <pwhalen> this is preventing upgrades from f24/5 -> f26 .. affects armhfp and aarch64. .will file as a blocker.
15:07:13 <pwhalen> pbrobinson, x86 seems to be ok
15:08:08 <pwhalen> #info Bug 1440875 - Docker image fails to run when selinux is enforcing on aarch64
15:09:39 <pwhalen> #info Bug 1444928 - UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe8 in position 17: invalid continuation byte
15:09:57 <pwhalen> last one is on the trimslice when doing graphical installs, text works ok
15:11:02 <pwhalen> ok, moving on to the kernel..
15:11:07 <pwhalen> #topic 2) ==== Kernel Status ====
15:11:07 <pwhalen> #info Latest - kernel-4.11.0-0.rc8.git0.1.fc26.aarch64.rpm
15:11:07 <pwhalen> #link https://koji.fedoraproject.org/koji/buildinfo?buildID=882852
15:11:26 <pwhalen> very new, I've not had a chance to test
15:11:49 <rric> pbrobinson, since the page size switched to 4k, there will be a problem with gicv3-its table allocation
15:11:51 <pbrobinson> I don't imagine huge changes over rc7
15:12:06 <pbrobinson> rric: can you tell me more?
15:12:22 <rric> this is due to max_order
15:12:32 <rric> its tables need 16M
15:12:49 <rric> with a zone order set to 12 i think 8M is the maximum
15:13:03 <rric> there exists 2 solutions
15:13:06 <pbrobinson> rric: so can we adjust another Kconfig to fix that up?
15:13:15 <rric> this need to be patched
15:13:26 <rric> it is not adjustable
15:13:55 <rric> the 2nd approach is my patch set with cma allocation
15:14:12 <rric> but it's not yet upstream, I need to resend an update
15:14:25 <rric> would suggest to just increase the order
15:14:41 <rric> I could open a bz and provide a patch for this
15:15:09 <rric> I haven't had the time to test the latest kernel yet
15:15:10 <pbrobinson> rric: what do the other distros do (suse/ubuntu and I think Debian all use 4K)
15:15:20 <jlinton> pbrobinson: I'm here just late.
15:15:33 <rric> it's the zone order increase
15:15:53 <rric> ... for all of them
15:16:39 * jonmasters is on
15:17:12 <pbrobinson> rric: OK, so it's patch zone order or a non upstream patch (can you reference the patch on a ML)?
15:17:24 <rric> 1sec
15:17:25 <jonmasters> pbrobinson: the former I think
15:17:53 <jonmasters> BUT changing that is nasty. Using CMA or similar is a better solution
15:18:31 <rric> https://marc.info/?l=linux-arm-kernel&m=148880578815410&w=2
15:18:44 <jonmasters> looking
15:18:45 * pbrobinson bangs head against the desk
15:21:05 <rric> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
15:21:05 <rric> index 871f21783866..0d973da474bc 100644
15:21:06 <rric> --- a/arch/arm64/Kconfig
15:21:06 <rric> +++ b/arch/arm64/Kconfig
15:21:06 <rric> @@ -571,6 +571,7 @@ config FORCE_MAX_ZONEORDER
15:21:06 <rric> int
15:21:06 <rric> default "14" if (ARM64_64K_PAGES && TRANSPARENT_HUGEPAGE)
15:21:07 <rric> default "12" if (ARM64_16K_PAGES && TRANSPARENT_HUGEPAGE)
15:21:07 <rric> +       default "13" if (ARCH_THUNDER && !ARM64_64K_PAGES)
15:21:08 <rric> default "11"
15:21:08 <rric> help
15:21:09 <rric> The kernel memory allocator divides physically contiguous memory
15:21:14 <rric> this is the alternative
15:21:51 <rric> 4M is the max allocation size without it
15:22:05 <pbrobinson> rric: have you got a link to your patch and the discussion?
15:22:12 <jonmasters> rric: that one you posted above is nasty. The list post is ok
15:22:15 <rric> see above
15:22:28 <jonmasters> HOWEVER please note that ARMv8 allows SPIs to be MSIs
15:22:32 <pbrobinson> rric: sorry, missed it :)
15:22:56 <rric> jonmasters, yes, this needs an update
15:22:58 <jonmasters> and I wonder if deferring MSI setup might break anyone
15:23:10 <pbrobinson> jonmasters: I presume you don't mean Serial Peripheral Interface
15:23:18 <jonmasters> pbrobinson: Shared Peripheral Interrupts
15:23:31 <jonmasters> pbrobinson: one of 4 interrupt types on ARMv8
15:23:52 <jonmasters> checking something
15:23:55 <rric> the rework to struct dev support was requested by Marc
15:24:10 <rric> the is the most of the change
15:25:51 <jonmasters> Just remember this please:
15:25:53 <jonmasters> 4.2.7 Peripheral Subsystems
15:25:53 <jonmasters> For the purpose of system development and bring up, the base server system shall include a Generic UART. The
15:25:53 <jonmasters> Generic UART is specified in Appendix B. The UARTINTR interrupt output is connected to the GIC as an SPI.
15:25:54 <jlinton> To add to Jon, LPI is actually what MSI's are called on gicv3
15:26:03 <rric> for the FORCE_MAX_ZONEORDER patch, see also: https://lists.gt.net/linux/kernel/2164260
15:26:37 <jonmasters> So as long as your patch accounts for the fact that a future platform might exist where my UART is wired up using MSIs and you don't break that by deferring setup too long, I'm happy
15:27:19 <jonmasters> To add to Jeremy ;) LPIs are the main MSI HOWEVER SPIs can also be MSIs. It's allowed by the GICv3 spec. It only requires LPIs be MSIs
15:27:47 <jlinton> Yah, v2m is basically MSI->SPI
15:27:48 <jonmasters> just noting for the record, so that when someone breaks my UARTs later, I can say told ya so
15:28:15 <jlinton> so that is the default case for MSI when !gicv3
15:28:28 <jonmasters> pbrobinson: let's move on
15:29:11 <pbrobinson> well by the look of it the proposed fix needs some more work so we should likely watch it and juse use the FORCE_MAX_ZONEORDER in the short term as that's what other distros are doing?
15:30:30 <pbrobinson> jonmasters: ^^
15:32:11 <jonmasters> it won't explode the universe
15:32:19 <jonmasters> and you'll need a solution in the interim
15:32:20 <jonmasters> so...
15:32:41 <jonmasters> but that's definitely a HACK DONOTUPSTREAM patch
15:32:51 <pbrobinson> of courses
15:33:11 <pbrobinson> rric: can you let me know when you post your next rev, I'll take a note and do some reading
15:33:19 <pbrobinson> pwhalen: next! ;-)
15:33:24 <rric> pbrobinson, ok
15:33:37 <pbrobinson> rric: thx
15:34:00 <pwhalen> #topic 3) ==== Bootloader Status ====
15:34:12 <rric> pbrobinson, are you going to pick the patch up from ml?
15:34:25 <rric> I mean the order fix
15:34:42 <pbrobinson> rric: going to take the "default "13" if (ARCH_THUNDER && !ARM64_64K_PAGES)" or equiv in the short term
15:34:52 <rric> ok, thanks
15:35:21 <pbrobinson> so bootloaders
15:35:25 <pwhalen> I dont think anythings changed here. we have a new uboot building for f27, once successful it'll be built in f26. Anything to add to that?
15:35:44 <pbrobinson> I've packaged up arm-trusted-firmware as it's needed for some of the SBCs
15:36:01 <pwhalen> awesome
15:36:03 <pbrobinson> with that I can build a u-boot that supports the Pine64
15:37:19 <pbrobinson> and apart from a few minor details to sort out going from u-boot(uEFI) -> grub2 -> kernel I have it booting an unmodified Fedora disk image
15:38:11 <pbrobinson> so that's good and means we should have a handful of aarch64 SBCs supported in time for Beta
15:38:35 <pwhalen> \o/
15:39:06 <pwhalen> ok, moving to beta
15:39:10 <pwhalen> #topic 4) ==== F26 Beta ====
15:39:24 <pwhalen> #info Latest nominated compose - Fedora_26_Branched_20170420.n.0
15:39:24 <pwhalen> #link https://fedoraproject.org/wiki/Test_Results:Fedora_26_Branched_20170420.n.0_Installation
15:39:24 <pwhalen> #link https://fedoraproject.org/wiki/Architectures/AArch64/QA/Fedora-26-20170420.n.0
15:39:30 <pwhalen> #info Full list of blockers: https://qa.fedoraproject.org/blockerbugs/milestone/26/beta/buglist
15:40:31 <pwhalen> for arm, we have the initial-setup bug. If the upgrade bug still exists, I will propose that one as well.
15:40:46 <pbrobinson> so for F-26+ we have nightly disk images. They're not currently for the faint of heart and need some tweaks but are useful for testing if people want to do bootloader/kernel testing of SBCs and the like
15:42:22 <pwhalen> #info AArch64 disk images added to the F26 nightly composes. These currently need some tweaks and not yet recommended for most people.
15:42:44 <pbrobinson> initially we'll have Minimal/Server/Workstation images, can look at adding other Spins if there's a need
15:43:06 <pbrobinson> #info Minimal/Server/Workstation images will be the initial ones produced for F-26
15:43:33 <jonmasters> rric: on a tangent, I  think you're ok with subsys initcall time - should be before the con_init for the console switch happens
15:43:50 <jonmasters> rric: but please check that you don't break SPIs later - and copy me on the next patch
15:44:22 <rric> jonmasters, ok
15:44:25 <jonmasters> tnx
15:44:30 <pwhalen> any other beta issues/concerns?
15:44:46 <jonmasters> need to do more testing on this end, sorry
15:45:10 <pwhalen> np jonmasters :)
15:45:17 <pwhalen> #topic 5) == Open Floor ==
15:46:17 <jlinton> Looks like there is movement on the mozjs38 packrunner patches.
15:46:59 <jlinton> I'm also going to post a v2 of the dracut patches tomorrow (or thats the plan)
15:47:50 <jlinton> the dracut patches are the last loose end for the HiKey with respect to fedora if the TI firmware config file gets sourced from another project.
15:48:31 <pbrobinson> jlinton: cool
15:49:01 <pwhalen> jlinton, pretty sure I bricked my hikey, no longer shows up when in recovery.. any recovery options I might try?
15:49:08 <pbrobinson> jlinton: the TI Wifi that's the same chip works for me on the BBOne Wireless with the firmware in linux-firmware (I think)
15:49:20 <jlinton> ? It doesn't really show up anywhere in recovery mode,
15:49:33 <jlinton> if you have a USB cable plugged into the micro USB port on the board
15:49:41 <pwhalen> jlinton, yea, not anymore
15:49:42 <jlinton> that should show up on a PC as a serial port
15:50:15 <jlinton> then you have to push that l-loader stub
15:50:21 <jlinton> from there you can talk to it with fastboot
15:50:27 <jlinton> does it show up as a serial port?
15:50:50 <jlinton> do you have jumpers 1-2 and 2-3 set, but not 4-5?
15:50:56 <pwhalen> jlinton, right. that all worked.. showed up with fastboot.. then.. nothing..
15:51:33 <jlinton> Yah from fastboot, you can flash the ptable (I have a fedora specific one now) and the firmware image, then remove the 2-3 jumper, the USB cable and reset it.
15:51:47 <jlinton> if fastboot works the Hikey is functional
15:52:28 <jlinton> it doesn't light any of the LEDs (IIRC) until linux starts, which makes it seem dead...
15:52:35 <pwhalen> right. ok, i got all that working.. then it stopped. tried recovery again, wont show up as a serial
15:53:10 <jlinton> Well I had problems with the seedstudio ones being "unreliable" and part of the problem was the inductor on the bottom next to the power supply jack which needed to be resoldered
15:54:31 <pwhalen> ok, I'll try it again.. hopefully different result today. it seemed to get really hot, then stop working
15:54:37 <jlinton> The OTG port is also particular about the USB cable, IIRC
15:54:52 <jlinton> shorter is better...
15:55:24 <pwhalen> ok.
15:55:29 <jlinton> Oh, I have a big heatsink on mine, but I wondered early on if the thermals were right on it
15:55:30 <pwhalen> sorry, anything else for open floor?
15:55:48 <jlinton> because when I first got it, it went into thermal "shutdown" but didn't actually reduce the current draw.
15:57:09 <pwhalen> #endmeeting