[fedora-arm] 4.0 final, 4.1 merge window, and us
Hi All, The 4.0 final release is in rawhide and submitted for an update for Fedora 22 now. Given the release schedules for 4.1 and F22, we're going to stick with 4.0 for F22 GA. Please stick to fixes for F22 and we'll no longer keep that branch in sync with rawhide. The 4.1 merge window is open and active upstream as well. I'll be rebasing rawhide to those kernels likely later today or tomorrow. If you have things that are landing in 4.1 that you'd like enabled, please let us know. The only major feature I'm aware of that might land is kdbus, but the jury is still out on that one. Thanks. josh ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] 4.0 final, 4.1 merge window, and us
On Tue, Apr 14, 2015 at 8:05 AM, Peter Robinson wrote: > On Tue, Apr 14, 2015 at 12:51 PM, Josh Boyer > wrote: >> Hi All, >> >> The 4.0 final release is in rawhide and submitted for an update for >> Fedora 22 now. Given the release schedules for 4.1 and F22, we're >> going to stick with 4.0 for F22 GA. Please stick to fixes for F22 and >> we'll no longer keep that branch in sync with rawhide. >> >> The 4.1 merge window is open and active upstream as well. I'll be >> rebasing rawhide to those kernels likely later today or tomorrow. If >> you have things that are landing in 4.1 that you'd like enabled, >> please let us know. The only major feature I'm aware of that might >> land is kdbus, but the jury is still out on that one. > > The ACPI 5.1 patch set I believe is on it's way in for this cycle so > we'd like that for aarch64 in F-23 (possibly not in F-22 but 4.1 for > that is a while out) but I'm unsure of the impact there on x86 too, > I'd assume nothing, but happy to coordinate with you as appropriate > there. Good to know. As far as I'm aware, new ACPI code drops just go into the tree and are picked up automatically on all architectures that use them and have it enabled. I'll keep an eye out for this on aarch64 but I don't expect any impacts on x86 beyond the normal code drop kind of issues. josh ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fedora ARM dinner at Flock
On Wed, Jul 22, 2015 at 12:52 AM, Brendan Conoboy wrote: > Hi folks, > > I'm putting together a Fedora ARM dinner at Flock, If you would like to > join please drop me a note so I can get an approximate headcount and any > food allergies/preferences. Once we have a Flock schedule I will mail those > who have expressed interest directly with proposed restaurant/times. The planned Flock events are Thursday and Friday evening. Avoid those. Most teams are planning their activities for Tuesday or Wednesday. josh ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fedora 23 for aarch64 is here!
On Wed, Nov 4, 2015 at 9:11 AM, Clive Messer wrote: > On Wed, 2015-11-04 at 09:44 +, Peter Robinson wrote: > >> Yet you com in very confrontational about it, > > I am sorry if you see it that way. Blunt and to the point, yes, but I > wasn't trying to be confrontational, just trying to make a point, that > I do not understand the concept of a community based distribution being > released, only officially supporting big $, business class, > enterprise solutions, rather than the consumer level boards which are > already available. Your email seem to imply that the community somehow excludes enterprise level contributors. That's not the case at all. The community around ARM is just as diverse as it is around x86, where you have contributors from all different areas. You might not have intended it to imply that, but it's the message those enterprise contributors see. It's really hard to encourage more of them to participate when people constantly question their validity in our community. Your message would have been better served by simply asking if there are plans around supporting the 96Board stuff. josh ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] Re: Submitted a F24 change request on BBC micro:bit
On Sun, Jan 17, 2016 at 8:45 AM, Kushal Das wrote: > Hi all, > > I have submitted a change request [1] for F24 on BBC micro:bit. This > will be mostly packaging work, and helping out the upstream developers > with patches :) > > [1] https://fedoraproject.org/wiki/Changes/Micro_Bit With my FESCo hat on, there is almost no information in this Change at all. It doesn't say what work needs to be done, who is going to do it, what, if any, impacts this will have on anyone. This Change is not ready. Please provide more information. At the very least, please tell us what is missing and needs to be packaged, what patches you foresee being needed, etc. josh ___ arm mailing list arm@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/arm@lists.fedoraproject.org
Re: [fedora-arm] Fedora ARM status meeting minutes 2012-06-20
On Wed, Jun 20, 2012 at 5:44 PM, Paul Whalen wrote: > Good day all, > > Thanks to those who were able to join us for the weekly status meeting today. > For those that were unable, the minutes are posted below: Just wanted to thank the ARM team for adopting the weekly online meetings and minutes publishing. It makes things much easier to follow in ARM land. josh ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] Kernel rebases
Howdy, Just a quick update on kernel rebases. Justin rebased Rawhide to the 3.6 merge window git tree last week and I'm continuing on with that until the merge window closes. Then we'll pick up the RC kernels throughout, as usual. If there is a feature or option you have been waiting for in 3.6, now is the time to speak up and make sure it's set as you want. F17 was rebased to the 3.5 kernel last week as well. The initial builds are done and submitted to updates-testing today. F16 will likely follow suit after 3.5.1 is out. For both Rawhide and F17, the ARM configs could use some serious looking at. We continue to have a lot of config options pop up when we do stable rebases. Getting them set in Rawhide during the merge window kernels is going to be the best bet to ensure things are working as expected. If you have questions/comments, feel free to let us know. josh ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Kernel rebases
On Thu, Aug 02, 2012 at 12:03:06AM +0100, Peter Robinson wrote: > Hey Josh, > > On Tue, Jul 31, 2012 at 12:47 AM, Josh Boyer wrote: > > Howdy, > > > > Just a quick update on kernel rebases. > > > > Justin rebased Rawhide to the 3.6 merge window git tree last week and > > I'm continuing on with that until the merge window closes. Then we'll > > pick up the RC kernels throughout, as usual. If there is a feature or > > option you have been waiting for in 3.6, now is the time to speak up > > and make sure it's set as you want. > > I've been looking at that already, some of the platforms are broken at > the moment unfortunately but I think the config options seem to be OK > at the mometn OK. Note that nobody (to my knowledge) has explicitly changed any of the ARM config options for the 3.6 merge window kernels, so they should be whatever they default to. > > For both Rawhide and F17, the ARM configs could use some serious looking > > at. We continue to have a lot of config options pop up when we do > > stable rebases. Getting them set in Rawhide during the merge window > > kernels is going to be the best bet to ensure things are working as > > expected. > > For rawhide we did seriously look at the ARM configs and you'll notice > they are significantly different from what is currently in F-17. I > would like some further feedback and suggestions as to how they could > be improved. I did notice, yes. > In terms of setting the config options for 3.5 there were set in > rawhide and had 3.5 kernels compiling through out the entire process. > Is there a process in how those options get merged back to stable > releases? Is that something I should be handling? Again would like > some details as to how I can improve the process to make it easier for > you there as well. So this is the somewhat confusing part. The config-arm-* _fragments_ in rawhide are much better set up than in F17. Or at least they appear to be to my somewhat untrained eye. And I have noticed that they're starting to move more towards the expected "inherit from config-generic, only override if necessary" model rather than the "config-arm- is a full .config" model. That is nice to see. Oddly, when we did the 3.4 and 3.5 rebases, the options that should have been set for those base kernels in rawhide didn't seem to be explicitly set. Whether it's the different config-arm* setup in F17, or something else, I don't know. All I know is that Justin and I both had to fill in a bunch of ARM options that popped up, and they're likely 80% OK and 20% wrong, with that 20% being something that breaks the world. Fortunately, we won't have this problem with the F16 3.5 rebase since I killed ARM entirely on that branch. As for the process, really getting the config-arm-* fragments in a somewhat consistent is going to be the best start. Then the kernel team can gladly ping whomever is interested or feels responsible for the ARM configs when we start a rebase. On my side of things, I'll try and pay attention to any config option changes that get set by the ARM team in rawhide as well. Hopefully this is just a growing pain that we'll eventually get over as things stablize. Mostly, I'm glad you replied and I appreciate the willingness to work through this. Thanks. josh ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] New Fedora-ARM Kernel Built -- Check it out and test it!
On Thu, Oct 4, 2012 at 12:29 PM, wrote: > [ http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=94494 > kernel-3.6.0-0.rc6.git0.2.fc18 ] Erm... that's older than the kernel you posted about yesterday. Why was it built only now, and why are you asking people to test it? josh ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Just in case you don't read Slashdot :)
On Fri, Oct 5, 2012 at 3:50 AM, Peter Robinson wrote: > For Fedora 18 with 3.7 it should (whether it works out in time or we > start with F-19 and roll it back) mean we can support more devices > with a couple of less kernels. The mvebu platform is the Marvell F18 is going to GA with 3.6.x. We'll rebase to 3.7 at some point, but it won't be until after the release. If you're wanting to do this on a release boundary, F19 would be your target. If you're OK with rolling it out as an update, then F18 is doable. Just an FYI. josh ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Just in case you don't read Slashdot :)
On Fri, Oct 5, 2012 at 7:43 AM, Peter Robinson wrote: > On Fri, Oct 5, 2012 at 12:34 PM, Josh Boyer wrote: >> On Fri, Oct 5, 2012 at 3:50 AM, Peter Robinson wrote: >>> For Fedora 18 with 3.7 it should (whether it works out in time or we >>> start with F-19 and roll it back) mean we can support more devices >>> with a couple of less kernels. The mvebu platform is the Marvell >> >> F18 is going to GA with 3.6.x. We'll rebase to 3.7 at some point, but >> it won't be until after the release. If you're wanting to do this on a >> release boundary, F19 would be your target. If you're OK with rolling >> it out as an update, then F18 is doable. Just an FYI. > > I figured as much given that it's usually ~3 months for a kernel dev > cycle and F-18 has already been delayed more than enough :-D > > I presume you'll start pushing 3.7 to rawhide at some point? Yep. Justin is on rawhide duty. I know he's uploaded some of the merge window code to the lookaside, but I haven't seen a commit to the kernel to switch it over yet. I would think that will happen fairly soon. josh ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] F17 3.6 kernel rebase
I've commited the 3.6.x rebase to the F17 branch in Fedora git. The ARM configs and patches definitely need a looking over. I haven't kicked off a build yet so that ARM can get adjusted for the rebase. Please look it over and let me know when you have things squared away. I'd like to get a build done later today or tomorrow. josh ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARM kernel moving forward 3.7+
On Tue, Dec 4, 2012 at 11:07 AM, Mark Langsdorf wrote: > On 12/01/2012 03:33 AM, Peter Robinson wrote: >> Hi Mark, >> >> Would love feedback on the 3.7-rc7 unified kernel on Calxeda HW. >> >> http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=102860 > > I installed kernel, kernel-tools, kernel-tools-libs, and > kernel-modules-extra. The boot started, which was nice, and proceeded You shouldn't need kernel-modules-extra or kernel-tools. Just an FYI. > through driver probing. When it came time to find the hard drive, though: > > [3.223097] uart-pl011 fff36000.serial: no DMA platform data > [3.293171] loop: module loaded > [3.304994] libphy: Fixed MDIO Bus: probed > [3.312008] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver > [3.320476] usbcore: registered new interface driver usbserial > [3.326778] usbcore: registered new interface driver usbserial_generic > [3.334087] usbserial: USB Serial support registered for generic > [3.343052] mousedev: PS/2 mouse device common for all mice > [3.357270] rtc-pl031 fff35000.rtc: rtc core: registered pl031 as rtc0 > [3.372647] device-mapper: uevent: version 1.0.3 > [3.382934] device-mapper: ioctl: 4.23.0-ioctl (2012-07-25) > initialised: dm-de...@redhat.com > [3.398526] cpuidle: using governor ladder > [3.402673] cpuidle: using governor menu > [3.415758] usbcore: registered new interface driver usbhid > [3.421367] usbhid: USB HID core driver > [3.427469] drop_monitor: Initializing network drop monitor service > [3.436043] ip_tables: (C) 2000-2006 Netfilter Core Team > [3.442094] TCP: cubic registered > [3.445452] Initializing XFRM netlink socket > [3.460771] NET: Registered protocol family 10 > [3.479839] mip6: Mobile IPv6 > [3.482861] NET: Registered protocol family 17 > [3.488783] Key type dns_resolver registered > [3.493269] VFP support v0.3: implementor 41 architecture 3 part 30 > variant 9 rev 4 > [3.501052] ThumbEE CPU extension supported. > [3.505441] Registering SWP/SWPB emulation handler > [3.516209] registered taskstats version 1 > [3.529645] rtc-pl031 fff35000.rtc: setting system clock to > 2012-12-04 11:54:39 UTC (1354622079) > [3.543436] md: Waiting for all devices to be available before autodetect > [3.550225] md: If you don't use raid, use raid=noautodetect > [3.568496] md: Autodetecting RAID arrays. > [3.572649] md: Scanned 0 and added 0 devices. > [3.577091] md: autorun ... > [3.579884] md: ... autorun DONE. > [3.584812] Waiting for root device LABEL=rootfs... That looks more like "I didn't use an initramfs" or "my initramfs didn't load" than anything. What was the full cmdline passed and do you see messages earlier in the boot about the initramfs? > it should look more like: > [1.782285] Freeing init memory: 320K > [1.941240] dracut: dracut-018-105.git20120927.fc17 initramfs ^ josh ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Kernel 3.8 plans
On Mon, Jan 7, 2013 at 7:53 AM, Peter Robinson wrote: > Hi All, > > Just thought I would ping the list about my current plans for kernel > 3.8 in rawhide so people are aware of what's going on. > > I'm breaking it down into a couple of phases to make the change less > of a problem (with luck): > > 1) phase 1 is basically a basic 3.7 -> 3.8 jump and will include the > following: > * drop separate imx kernel. Currently doesn't support the previous HW > we supported with the imx kernel. It's now buildable as a unified > kernel > * deal with new kernel config options we need to actually build the config. When you're dropping separate kernels, dealing with new kconfig options, or shuffling around config-arm* files, please keep in mind that the older Fedora releases get rebased as well. Right now, F18 is at 3.7 in updates-testing, but it will eventually move to the 3.8 kernel and F17 likely will a bit after that. If a platform is dropped in rawhide but not the older releases, you'll still wind up having to deal with it there. I'm not sure there's much that can be done, but it is something that does come up every time we do a kernel rebase. josh ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] arm software floating point support going forward
On Fri, Jan 25, 2013 at 11:22 AM, Dennis Gilmore wrote: > Hi all, > > I wanted to kick off a discussion, I think that with the work that > Seneca is doing for armv6hl to support the Raspberry Pi most of the > need for building sfp has gone away. I would like us to drop support > for sfp in F19 that means that anyone running a kirkwood based system > would get supported software updates for approximately 13 months from > now. with cubie boards and other devices coming around that are cheap > and more powerful and similar options I think there is little benefit > to continuing to support sfp. I'm not overly familiar with arm, but from a kernel standpoint you might be able to enable floating point emulation. That would let you run the hardfp binaries on the boards without an FPU. It would be a performance hit for things doing FP heavy computation, but you could continue supporting those boards that way. josh ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] arm software floating point support going forward
On Fri, Jan 25, 2013 at 1:10 PM, Nicolas Pitre wrote: > On Fri, 25 Jan 2013, Josh Boyer wrote: > >> On Fri, Jan 25, 2013 at 11:22 AM, Dennis Gilmore wrote: >> > Hi all, >> > >> > I wanted to kick off a discussion, I think that with the work that >> > Seneca is doing for armv6hl to support the Raspberry Pi most of the >> > need for building sfp has gone away. I would like us to drop support >> > for sfp in F19 that means that anyone running a kirkwood based system >> > would get supported software updates for approximately 13 months from >> > now. with cubie boards and other devices coming around that are cheap >> > and more powerful and similar options I think there is little benefit >> > to continuing to support sfp. >> >> I'm not overly familiar with arm, but from a kernel standpoint you might >> be able to enable floating point emulation. That would let you run the >> hardfp binaries on the boards without an FPU. > > No, you can't. OK. > The only FP emulation the ARM kernel provide is for the antique FPA > instruction set that almost never got implemented in hardware, except > for a few exceptions that Linux never supported anyway. Ah. See, that would be where I point back to me knowning almost nothing about ARM ;). > All modern EABI compliant binaries are using the VFP instruction set, > and the only thing the kernel implements is the processing of > exceptions for them. To have a full VFP emulation support in the > kernel, significant development effort would be needed. I find this slightly interesting to be honest. In the embedded powerpc world, math emulation is used as a last ditch effort but it does exist. I would have thought the proliferation of ARM devices would generate some amount of interest in getting similar support in-kernel, but apparently not. Anyway, I'm not opposed to dropping a kernel variant at all. Makes some things simpler. josh ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] 3.9 merge window kernels
Just a quick heads up that the 3.9 merge window kernels are being built in rawhide now. I've tried to at least test boot kernels on my machine before submitting them to koji, but testers beware. Merge window kernels can be tricky. ARM people: the -git4 kernel build has the big ARM merge contained in it. I've tried to go through and make a reasonable estimation of what all the ARM related config options should be set to, but you really need to look those over. Also... the config file setup is confusing, particularly config-armv7. That seems to be used by only kernel-armv7/kernel-armv7hl but not by the omap and tegra armv7 configs. I think that is leading to some duplication of config settings. Anyway, look it over please. PPC/S390x people: You're set. Your architectures are apparently boring and predictable, so there were no config file changes needed. josh ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] 3.10 ARM kernel configs
So. When trying to do the latest merge, this is what I get on a prep for the -tegra config: + mv kernel-3.10.0-armv7hl-tegra.config .config ++ head -1 .config ++ cut -b 3- + Arch=arm + make ARCH=arm listnewconfig + grep -E '^CONFIG_' warning: (VIRTIO_PCI && VIRTIO_MMIO && REMOTEPROC && RPMSG) selects VIRTIO which has unmet direct dependencies (VIRTUALIZATION) + '[' -s .newoptions ']' + cat .newoptions CONFIG_ARCH_MULTI_V6 CONFIG_ARCH_MULTI_V7 CONFIG_ARCH_MVEBU CONFIG_ARCH_BCM CONFIG_ARCH_HIGHBANK CONFIG_ARCH_MXC CONFIG_ARCH_OMAP2PLUS CONFIG_ARCH_SOCFPGA CONFIG_PLAT_SPEAR CONFIG_ARCH_SUNXI CONFIG_ARCH_SIRF CONFIG_ARCH_U8500 CONFIG_ARCH_VEXPRESS_CORTEX_A5_A9_ERRATA CONFIG_ARCH_VEXPRESS_CA9X4 CONFIG_ARCH_VIRT CONFIG_ARCH_WM8850 CONFIG_ARCH_ZYNQ + exit 1 error: Bad exit status from /var/tmp/rpm-tmp.JpdsWj (%prep) Now, looking at the various ARM config files, almost all of those are set in config-armv7. None of them are set in config-armv7-generic or config-armv7-tegra. The questions I have are: 1) What is config-armv7 and why is it different from config-armv7-generic? 2) Why does tegra (and the other boards) not inherit config-armv7 at all and only inherits from temp-armv7-generic (config-armv7-generic + config-generic)? As it stands right now, either config-armv7-generic needs to inherit all the settings from config-armv7 or they need to be explicitly set in config-armv7-tegra. Explicitly setting them is feasible, but that's a lot of duplication. I've no clue what the setup here is, nor which option is correct. Can you please tell me which to do so I can continue with this merge? I'd like to get -git12 fixed up and pushed out today. josh ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] 3.10 ARM kernel configs
On Thu, May 02, 2013 at 06:49:00PM +0100, Peter Robinson wrote:
> On Thu, May 2, 2013 at 6:43 PM, Josh Boyer wrote:
> > So. When trying to do the latest merge, this is what I get on a prep
> > for the -tegra config:
> >
> > + mv kernel-3.10.0-armv7hl-tegra.config .config
> > ++ head -1 .config
> > ++ cut -b 3-
> > + Arch=arm
> > + make ARCH=arm listnewconfig
> > + grep -E '^CONFIG_'
> > warning: (VIRTIO_PCI && VIRTIO_MMIO && REMOTEPROC && RPMSG) selects
> > VIRTIO which has unmet direct dependencies (VIRTUALIZATION)
> > + '[' -s .newoptions ']'
> > + cat .newoptions
> > CONFIG_ARCH_MULTI_V6
> > CONFIG_ARCH_MULTI_V7
> > CONFIG_ARCH_MVEBU
> > CONFIG_ARCH_BCM
> > CONFIG_ARCH_HIGHBANK
> > CONFIG_ARCH_MXC
> > CONFIG_ARCH_OMAP2PLUS
> > CONFIG_ARCH_SOCFPGA
> > CONFIG_PLAT_SPEAR
> > CONFIG_ARCH_SUNXI
> > CONFIG_ARCH_SIRF
> > CONFIG_ARCH_U8500
> > CONFIG_ARCH_VEXPRESS_CORTEX_A5_A9_ERRATA
> > CONFIG_ARCH_VEXPRESS_CA9X4
> > CONFIG_ARCH_VIRT
> > CONFIG_ARCH_WM8850
> > CONFIG_ARCH_ZYNQ
> > + exit 1
> > error: Bad exit status from /var/tmp/rpm-tmp.JpdsWj (%prep)
> >
> >
> > Now, looking at the various ARM config files, almost all of those are
> > set in config-armv7. None of them are set in config-armv7-generic or
> > config-armv7-tegra. The questions I have are:
> >
> > 1) What is config-armv7 and why is it different from
> > config-armv7-generic?
>
> It's non pae vs pae. I did it the same as x86.
Er... similar I guess. Not the same. x86 has "PAE" in the PAE config
:). You do have a config-armv7-lpae, but that is inheriting from
config-armv7-generic.
> > 2) Why does tegra (and the other boards) not inherit config-armv7 at all
> > and only inherits from temp-armv7-generic (config-armv7-generic +
> > config-generic)?
>
> Because generic is inherited by the other 3.
What other 3? There's only 3 kernels total right now: armv7hl
(config-armv7), armv7hl-lpae (config-armv7-generic), and tegra
(config-armv7-generic but not any of the lpae configs).
>
> > As it stands right now, either config-armv7-generic needs to inherit all
> > the settings from config-armv7 or they need to be explicitly set in
> > config-armv7-tegra. Explicitly setting them is feasible, but that's a
> > lot of duplication. I've no clue what the setup here is, nor which
> > option is correct.
>
> Tegra will disappear with 3.10 (at least that's the plans) and the
> other two are different because they need to be. armv7-generic is the
> shared bits between the two.
Oh. Good.
> > Can you please tell me which to do so I can continue with this merge?
> > I'd like to get -git12 fixed up and pushed out today.
>
> If you can push the changes you have I can fix the issues now.
I would feel extremely bad if I pushed something to git that didn't even
pass 'make prep'. As a compromise, I added this line in kernel.spec:
@@ -1451,6 +1451,8 @@ mkdir configs
rm -f kernel-%{version}-*debug.config
%endif
+rm -f kernel-%{version}-arm*.config
+
# now run oldconfig over all the config files
So the ARM configs won't be included in the prep run. That lets things
progress on all the other arches for now. Just remove that line, fix
things up, and push out.
I'll hold off on doing the build for a bit. Thanks for the quick reply.
josh
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] 3.10 ARM kernel configs
On Mon, May 6, 2013 at 4:26 PM, Dave Jones wrote:
> On Mon, May 06, 2013 at 09:13:30PM +0100, Peter Robinson wrote:
> > On Mon, May 6, 2013 at 9:07 PM, Dave Jones wrote:
> > > On Thu, May 02, 2013 at 02:02:12PM -0400, Josh Boyer wrote:
> > > > I would feel extremely bad if I pushed something to git that didn't
> even
> > > > pass 'make prep'. As a compromise, I added this line in kernel.spec:
> > > >
> > > > @@ -1451,6 +1451,8 @@ mkdir configs
> > > > rm -f kernel-%{version}-*debug.config
> > > > %endif
> > > >
> > > > +rm -f kernel-%{version}-arm*.config
> > > > +
> > > > # now run oldconfig over all the config files
> > > >
> > > > So the ARM configs won't be included in the prep run. That lets
> things
> > > > progress on all the other arches for now. Just remove that line, fix
> > > > things up, and push out.
> > >
> > > FYI, I've just done the same thing in f18 during the 3.9 rebase.
> > > I don't see us pushing this out until 3.9.1 lands, but please sort out
> the
> > > config options there too.
> >
> > Thanks, I'll look at it now, for <= F-18 we still support v5tel so I
> > need to deal with that.
> >
> > Any idea on eta for 3.9.1?
>
> Probably sometime this week I would guess. There's already over a hundred
> patches queued on Linux-stable for 3.9
>
> Greg typically seems to wait until Linus tags rc1, so whenever the merge
> window closes, you can probably expect 3.9.1 to land pretty soon afterwards.
I'm kinda hesitant on that plan. We seem to always pull in some
patches from -rc1 that wind up being broken and fixed with a later RC,
or reverted outright. Of course, there isn't a great answer there but
maybe we can bump the karma requirement up when the update is filed?
josh
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] KUSER_HELPERS kernel config
Hi All, ARM introduced a new kernel config option called KUSER_HELPERS. It seems it allows one to turn something that has always been built-in off. I've left it on with today's rawhide kernel build, but please review and change if necessary. josh ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARM related talks at FLOCK!
On Wed, Aug 7, 2013 at 2:49 PM, Chris Tyler wrote: > On Wed, 2013-08-07 at 14:42 -0400, Paul Whalen wrote: >> >> Good afternoon all, >> >> Below is a list of ARM related talks at FLOCK beginning this Friday, August >> 9th. >> If your talk is not listed and related to ARM please send it to the list. >> >> For further details on these exciting talks and the full schedule visit: >> >> http://flocktofedora.org/schedule/ >> >> >> Friday, August 9 >> >> 11:00am >> Porting Fedora to 64-bit ARM - Jon Masters >> >> 12:00pm >> ARM Architecture 101 - Jon Masters >> Future of the Data Center - Dennis Gilmore >> >> 2:00pm >> How do I use ARM computers in the "Real World"? - Peter Robinson >> >> >> Saturday, August 10 >> >> Virtualization on ARM - John Dulaney >> 4:00pm >> How to bring up a new ARM board with Fedora - Peter Robinson > Plus... > > Sunday > Hyperscale Cloud Management with Open Stack - Chris Tyler > 10:00 am Curiously enough, all of the talks above still haven't sent slides to the Flock organizers. Sure would be nice to get them. josh ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARM related talks at FLOCK!
On Wed, Aug 7, 2013 at 3:23 PM, Jared K. Smith wrote: > On Wed, Aug 7, 2013 at 2:54 PM, Josh Boyer wrote: >> >> Curiously enough, all of the talks above still haven't sent slides to >> the Flock organizers. >> >> Sure would be nice to get them. > > > I have no slides for the docs hackfest. I think I mentioned that to you in > an earlier email, but just in case I spaced it, now you know. You did mention it. That's why I trimmed that particular talk out of the list of talks I quoted, so that you didn't have to email me again. josh ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARM related talks at FLOCK!
On Wed, Aug 7, 2013 at 4:01 PM, Richard W.M. Jones wrote: > On Wed, Aug 07, 2013 at 02:42:45PM -0400, Paul Whalen wrote: >> >> >> Good afternoon all, >> >> Below is a list of ARM related talks at FLOCK beginning this Friday, August >> 9th. >> If your talk is not listed and related to ARM please send it to the list. >> >> For further details on these exciting talks and the full schedule visit: >> >> http://flocktofedora.org/schedule/ > > Are any of these talks going to be broadcast over the internet / > available to download later? Some of them will be broadcast via google hangout. I believe those are archived. We'll have volunteers transcribing the talks in the room IRC channels as well. josh ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] vexpress on F20
On Sun, Sep 15, 2013 at 3:16 AM, Jon Masters wrote: > Hi Folks, > > Quick question. Has anyone been able to successfully boot the F20 > composes on a vexpress QEMU model? I've re-tested a kernel that was > listed as working, but it does not work on my local system. I am > interested in getting some data. Can I confirm that everyone is > experiencing a hang while the kernel waits to locate the rootfs? https://bugzilla.redhat.com/show_bug.cgi?id=1007911 josh ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Improved support for BeagleBone (Black) for Fedora 20
On Thu, Oct 10, 2013 at 12:58 PM, Jason Kridner wrote: > Did you know that BeagleBone Black is *true* open hardware? This means > that people can readily take the design and make their own custom > changes to it even prototyping it in low quantities, such as being > supported for the upcoming Arduino TRE. The same can't be said for > some other boards in the same price range also looking to get Linux in > the hands of more people. > > It is also $35 to distributors and those including it in other open > hardware projects. > > OK, it might not have been best for me to start with a sales pitch, > but it seems to me a lot of people aren't aware. People are aware. There have been several dozen handed out at various Fedora events. > I'd like to figure out who has interest in improving Fedora support on > BeagleBone Black and what I can do to help them. We have a running > image of Fedora... Peter Robinson and Kyle McMartin have been poking at getting it booting recently. > First and foremost, support needs to be in the Fedora mainline, not on > a remix. I'd be very happy if I was copied on any blocking issues in > that regard so that I can help get them addressed. Getting all the relevant kernel patches upstream would go a long way towards getting everything in Fedora mainline. Particularly in a multiboard fashion. josh ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] 3.13 kernel rebase
Hi All, I'll be starting the 3.13 rebase on Monday in rawhide. As previously discussed, we'll keep rawhide-nodebug on 3.12 in the stabilization branch and use that as the base for rolling 3.12 back to F20 and older releases. If you have questions/comments please let me know. josh ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] interesting uptime...
On Thu, Mar 27, 2014 at 8:46 PM, DJ Delorie wrote: > > Brendan though the list would find this interesting. This is one of > the first armv7hl builds (F15) we did for fedora, well over a year > ago. The server (a trimslice) is still up, still running, and still > being used. > > $ uptime > 20:42:48 up 518 days, 1:23, 1 user, load average: 0.01, 0.02, 0.05 > > $ uname -a > Linux geda-project.org 2.6.41.6-1.fc15.armv7hl.tegra #1 SMP PREEMPT Sat Dec > 24 17:30:09 UTC 2011 armv7l armv7l armv7l GNU/Linux That 2.6.41 makes my eyes bleed. I hope your using this as a honeypot if it's publicly accessible... the number of CVEs fixed in the kernel since then is rather long. josh ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] F21 system GCC changed to 4.9.0 prerelease
On Thu, Apr 10, 2014 at 6:23 AM, Jakub Jelinek wrote: > Hi! > > FYI, gcc in rawhide has been upgraded to 4.9.0 prerelease, > please visit http://gcc.gnu.org/gcc-4.9/porting_to.html if your > package no longer builds. To investigate runtime rather than compile time > issues, please consider using temporarily -fsanitize=undefined and/or > -fsanitize=address to look for undefined behavior in the packages > you own. Hm. So the kernel I tried to build this morning failed on ARM: http://koji.fedoraproject.org/koji/getfile?taskID=6723963&name=build.log That cross-built locally (gcc 4.8.1) here fine before I sent it to koji. Anyone have any ideas on that? josh ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] F21 system GCC changed to 4.9.0 prerelease
On Thu, Apr 10, 2014 at 10:06 AM, Josh Boyer wrote: > On Thu, Apr 10, 2014 at 6:23 AM, Jakub Jelinek wrote: >> Hi! >> >> FYI, gcc in rawhide has been upgraded to 4.9.0 prerelease, >> please visit http://gcc.gnu.org/gcc-4.9/porting_to.html if your >> package no longer builds. To investigate runtime rather than compile time >> issues, please consider using temporarily -fsanitize=undefined and/or >> -fsanitize=address to look for undefined behavior in the packages >> you own. > > Hm. So the kernel I tried to build this morning failed on ARM: > > http://koji.fedoraproject.org/koji/getfile?taskID=6723963&name=build.log > > That cross-built locally (gcc 4.8.1) here fine before I sent it to > koji. Anyone have any ideas on that? An f20 scratch build of the same SRPM has progressed past the failure point above. I suppose I'll dig into what changed in this regard and see if there's a fix that works for both. In the meantime, if anyone knows what might have changed in gcc 4.9 to cause this, please speak up. http://koji.fedoraproject.org/koji/taskinfo?taskID=6724145 josh ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] 3.16 merge window kernels
Hi All, Likely later today I'll commit the first 3.16 merge window kernel to rawhide. This is unfortunately going to be a rather large jump from 3.15, as the upstream merge window was open during the final 3.15 development. Our scripts for producing git snapshots (and our RPM versioning) aren't able to really cope with pre 3.16 stuff being done on top of 3.15-rc8 instead of 3.15 final. So we have 7000+ commits landing in the first -git1 snapshot. As usual, please review the config settings and such when the commit is pushed. I'll be doing much smaller git snapshots from here on out. josh ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] RFE: Enable CONFIG_R8188EU (from staging) in Fedora (ARM) kernels
On Thu, Apr 2, 2015 at 9:10 AM, Hans de Goede wrote: > Hi, > > The usb wifi modules supported by CONFIG_R8188EU (from staging) > are used on quite a few Allwinner ARM boards which we now support, > can the (staging) driver for these be enabled please? > > If not in general, then at least for ARM? Sure, we can do this for ARM. Which releases? josh ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] Re: Fedora on Odroid XU4 with Cloudshell LCD
On Tue, Aug 16, 2016 at 3:59 AM, wrote: > Hi there, > I've managed (with a lot of help from Stewart Samuels) to get Fedora 24 on > my Odroid XU4. This board is part of the Cloudshell with USB3-SATA (128GB > SSD-Disc) and a 2.2“ TFT LCD with a 320×240 resolution. There is a need of > following kernel modules: > > spi-s3c64xx -> found > fbtft_device -> not found > gpio-ir-recv -> found > gpioplug-ir-recv -> not found > > The driver homepage https://github.com/notro/fbtft "The FBTFT drivers are > now in the Linux kernel staging tree". Where can I find the kernel staging? > dnf didn't found kernel-staging or kmod-staging Fedora doesn't build the majority of the staging drivers. If you need some of them and can find someone willing to be on the hook for bug reports against them, then you can open a bug requesting they be enabled. josh ___ arm mailing list arm@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/arm@lists.fedoraproject.org
[fedora-arm] Re: Fedora on Odroid XU4 with Cloudshell LCD
On Tue, Aug 16, 2016 at 9:52 AM, wrote: > Am 2016-08-16 13:22, schrieb Josh Boyer: >> >> On Tue, Aug 16, 2016 at 3:59 AM, wrote: >>> >>> Hi there, >>> I've managed (with a lot of help from Stewart Samuels) to get Fedora 24 >>> on >>> my Odroid XU4. This board is part of the Cloudshell with USB3-SATA (128GB >>> SSD-Disc) and a 2.2“ TFT LCD with a 320×240 resolution. There is a need >>> of >>> following kernel modules: >>> >>> spi-s3c64xx -> found >>> fbtft_device -> not found >>> gpio-ir-recv -> found >>> gpioplug-ir-recv -> not found >>> >>> The driver homepage https://github.com/notro/fbtft "The FBTFT drivers are >>> now in the Linux kernel staging tree". Where can I find the kernel >>> staging? >>> dnf didn't found kernel-staging or kmod-staging >> >> >> Fedora doesn't build the majority of the staging drivers. If you need >> some of them and can find someone willing to be on the hook for bug >> reports against them, then you can open a bug requesting they be >> enabled. > > > At the last few years there were (at least for i386, x86_64) additional rpm > packages like kernel-staging or kmod-staging from Fedora or RPMFusion. Since > FC23 or FC24 they're missing. Those aren't from Fedora. Maybe RPMFusion, I don't know. > I've created a bug request. That's fine, but the hurdle is finding someone willing to deal with the modules. josh ___ arm mailing list arm@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/arm@lists.fedoraproject.org
[fedora-arm] Re: 48-bit support in F26?
On Wed, Sep 14, 2016 at 3:55 PM, Jon Masters wrote: > Hi Jeremy, all, > > I was just catching up with some folks and we discussed the status of > 48-bit VA support. It seems to me that it would make most sense to have > an official coordination effort between those vendors/community members > who are interested, to ensure that they help with the necessary package > updates ahead of the kernel, and work with a test kernel to identify any > additional packages or issues that need resolving. I believe it would > make most sense to have a Fedora feature page (or something less grand, > but similar in concept) tracking this for F26, with the deps. I would very much advocate for the full Feature page. It will get the change the appropriate attention technically, and it will raise awareness of Aarch64 within Fedora from a general sense. josh ___ arm mailing list arm@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/arm@lists.fedoraproject.org
[fedora-arm] Re: missing ax25.ko in kernel-modules-extra
On Tue, Feb 21, 2017 at 7:56 PM, wrote: > Hello, > I'm running Fedora 25 arm on a RPi3. I'm mainly using this particular RPi for > ham stuff. Previous versions of Fedora for RPi had the ax25.ko module > available, but it appears to be missing from the 'modules-extra' kernel > package in the official F25 arm build. The module IS available in the x86-64 > build. > > Is there a reason the ax25 module is not available in the arm build? Is there > any chance it will be added soon? It depends on CONFIG_HAMRADIO, which is disabled. If you would like to see it enabled, please send a patch to the Fedora kernel list or open a bug with relevant information. josh ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@lists.fedoraproject.org
