[fedora-arm] Fedora ARM dinner at Flock
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. Thanks! -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fedora ARM dinner at Flock
On 07/22/2015 04:23 AM, Josh Boyer wrote: 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. Thanks Josh! Since many aren't arriving until late Tuesday we'll tentatively go with Wednesday. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fedora ARM dinner at Flock
On 07/24/2015 07:10 AM, Troy Dawson wrote:
I know I'm more of a lurker on the mailing list and IRC, but I'd love
to join ya'll at the dinner.
I have no dietary restrictions. I'll be arriving Tuesday evening.
Cool, thanks Troy.
Currently looking like Wednesday evening.
Troy Dawson
On Thu, Jul 23, 2015 at 2:13 AM, Brendan Conoboy mailto:b...@redhat.com>> wrote:
On 07/22/2015 04:23 AM, Josh Boyer wrote:
On Wed, Jul 22, 2015 at 12:52 AM, Brendan Conoboy
mailto:b...@redhat.com>> 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.
Thanks Josh!
Since many aren't arriving until late Tuesday we'll tentatively go
with Wednesday.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
<mailto:b...@redhat.com>
___
arm mailing list
arm@lists.fedoraproject.org <mailto:arm@lists.fedoraproject.org>
https://admin.fedoraproject.org/mailman/listinfo/arm
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fedora 23 for aarch64 is here!
On 11/04/2015 01:13 PM, Gerald Henriksen wrote: The problem is ARM and partners aren't delivering what was expected (promised?). I recall a presentation from a Red Hat employee where ARM had agreed that aarch64 needed a standard boot process so this craziness of needing custom boot software for every board could be a thing of the past. Hasn't happened, hence the problems supporting the hardware that is available. There were also supposed to be standard sized motherboards with regular memory slots, etc. available by now, and they have failed. We are now in to November and nothing has been announced, leaving me to conclude that nothing will ship this year. AArch64 semiconductors who conform to the SBSA and SBBR specifications and get their kernel patches upstream tend to work with Fedora. Today that means many Applied Micro X-Gene and AMD Seattle parts work correctly with Fedora. Semiconductors who haven't put their code upstream or haven't conformed to the hardware and boot specifications are going to require remixes at best. Other semis are in process of upstreaming, we may see Cavium support get in place in time for F24 for instance. -- Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc. ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] rawhide status update
On 01/20/2012 08:37 AM, Ilyes Gouta wrote: Awesome! Are we targeting hardfp as ABI for armv7? For Cortex A8 or A9 - like class SoCs? For Fedora purposes hardfp refers to the triplet armv7hl-redhat-linux-gnueabi. Specifically, gcc is configured with the following flags: --with-cpu=cortex-a8 --with-tune=cortex-a8 --with-arch=armv7-a \ --with-float=hard --with-fpu=vfpv3-d16 --with-abi=aapcs-linux -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] Primary architecture proposal alpha draft
It's a little disjoint and out of order, but the first draft of the primary architecture proposal is available for some serious editing at: https://fedoraproject.org/wiki/Architectures/ARM/Planning/Primary This is based on notes from FUDcon and a couple cell phone shots of chalk boards. If I've missed anything feel free to add, or send me additional chalk board jpegs containing the areas that I missed :-) -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Possible File Formats for a Fedora ARM release
On 02/02/2012 02:41 PM, Gordan Bobic wrote: Not going to happen, sadly. The rootfs is common across all the devices (armv5tel for soft-float, armv7hl for hard-float). Hold up, there's a middle ground that we can shoot for here, even prior to everybody getting onboard with FDT. Kernels are SoC specific. Not quite as narrowly specialized as device specific, but it's still not going to be a one-size-fits all, at least not any time soon (probably years). What it really comes down to is getting the bootloader (typically uboot) to load a kernel and initramfs. Maybe it's an OMAP or a Tegra kernel, maybe it's Kirkwood or Highbank or Armada or or or... but you can squeeze all that onto one tarball. The support grid is really just 2x2: You're either armv5tel or armv7hl. You either need a separate partition for bootloader bits (omap, etc scenario) or you don't (tegra scenario). Putting together tarball that has everything a person needs for most systems is doable. A couple paragraphs per board type for how to get the specific board type is all it will take in the way of specialized documentation. In most cases it will simply be a matter of a couple setenv commands. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] Impromptu Fedora-ARM VFAD in 35 minutes.
The denizens of #fedora-arm have decided to have a catchup call in 35 minutes. That's 2PM Pacific, 5PM Eastern, 22:00 UTC/GMT. Conference code: 617-759-1337 (no passcode required) Toll Free Dial-In Number (US & Canada): (800) 451-8679 International Dial-In Number: +1-(212) 729-5016 Also join #fedora-arm on Freenode Sorry for the late notice! Hope all interested parties can make join in. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Possible File Formats for a Fedora ARM release
A little late replying, but hopefully people are still up for the discussion On 02/06/2012 08:33 PM, Chris Tyler wrote: Can we really reduce this to 2x2?... Partitioning: - one partition (tegra)(kirkwood) - two partitions (omap)(happy kirkwood)(raspi) - three partitions or more (jcm ;-) - non-partitioned bootloader area plus two partitions (ecafe) Let me throw a different perspective at this: What if we waste some space? I mean, just because tegra only needs one partition doesn't mean the standard image we produce can't have 3, right? It's a little wasteful, but the idea is that we're optimizing for simple distribution rather than for optimal installation. Perhaps we make a stock image with 3 partitions leaving some space where the non-partitioned bootloader would go. What is the widest-common-denominator we can get to in a single partition layout? Lets shoot for that. Kernel format: - uImage - uImage plus prepended headers (raspi) That just means we need the files to have different names, no? Bootloader configuration: - boot.scr - nand - cmdline.txt Trickier, probably calling for documentation rather than a just-works configuration. Then again, if we target the most popular device for each standard filename we go a long way toward satisfying the widest possible audience. Then document those target devices that aren't covered by the defaults. Bootloader binary: - MLO in partition 1 (omap) - gpu firmware in partition 1 (raspi) Can we put mlo and gpu firmware in the same partition? If their filenames are distinct it's just a small loss of space to support both. - in nand (plug computers) Documentation for this, alas. ...etc. It's that etc that's getting me. Even though all these boards have different requirements, they aren't all conflicting, they're just different and cause some bloat to support from a single image. A single image that handles most of the use cases is possible, even if it isn't space optimal. At least, that's my theory. Perhaps somebody who has more of the hardware in question can comment. But back to the original question: what's the optimal way to package an installable image? I see several valid options: (1)- Per-platform image with MBR plus one or more partitions, with the last partition shipped as minimal length and resizable to fill the device (either at installation or firstboot). (2)- Per-platform tarball, including a tarball for a boot partition (if applicable) plus a tarball of the rootfs, plus some sort of layout config file (XML? script?) that configures how the partitioning is set up. (3)- Generic per-arch (armv5tel/armv7hl) rootfs tarball plus per-platform boot tarball, separately downloaded. (Nice to cache the rootfs if installing into multiple, different devices, but messy as far as RPM knowledge of what's on the boot partition). (4) One tarball with a firstboot script that resizes / to fill the remainder of space then resize2fses itself :-) Really though, whoever does the work to make something happen gets to be right for the time being. I think having an easy installer is ultimately more important than which format we use. To get tens of thousands of people running Fedora on Raspis in the next six months, for example, we need a tool that's friendly, dirt-simple to use, and ideally runs on Windows as well as Fedora. Agree the an installer is definitely called for, but I'd like to continue working on a native installer, while granting that a non-arm image installer is also called for (Certainly it's the only way you're going to get an optimal rootfs out of the box). -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] heavybuilders
On 02/27/2012 02:25 PM, Dennis Gilmore wrote:
[snip]
I wanted to get others thoughs before i went and made the change
Just to be clear, these two systems are the same machines:
hsv-trimslice-9-v5telN N0.0/2.0 arm -
hsv-trimslice-9-v7hl Y N2.0/2.0 armhfp
2012-02-27 22:04:45
We just provision them as v5 or v7 according to what it looks like is
needed. That's the idea anyway- we aren't doing enough builds at once
that we've had to balance anything.
FYI, the HSV pandas also have dedicated sata disks on them and are
roughly the performance equivalent of the trimslices because of it. The
actual tally of heavybuilders (defined as having dedicated usb-sata
storage) is:
hsv-panda-1-v5tel
hsv-panda-2-v5tel
hsv-panda-3-v5tel
hsv-panda-5-v5tel
hsv-panda-6-v5tel
hsv-panda-8-v5tel
cdot-trimslice-13-1
cdot-trimslice-14-1-v7hl
hsv-trimslice-10-{v5tel,v7hl}
hsv-trimslice-9-{v5tel,v7hl}
hsv-trimslice-8-{v5tel,v7hl}
hsv-trimslice-7-{v5tel,v7hl}
hsv-trimslice-6-{v5tel,v7hl}
We can make all the HSV trimslices into v7 builders and that will give
us a 6/6 split, which seems reasonable.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] F17 runtime issue web page
Hi folks, If you're thinking about taking the F17 alpha1 rootfs for a test drive this message is for you. A few weeks ago Peter added a section to the Fedora ARM page that detailed important packages that were failing to build. Today the majority of those build failures marked as "FIXED" so this has been working quite well. So well, infact, that Peter was able to make a root filesystem exclusively using Fedora 17 packages, a major milestone. The next thing to be addressed are runtime failures that people are running into as they try out the alpha1 rootfs. If IRC and the mailing list are any indication, we've all hit a few issues with F17 ARM alpha, though generally after a couple changes it's been working *really* well for me. Peter and I talked about it and the logical conclusion was to add a runtime issue section to the problem page, which I've done. Thus, if you're trying out the F17 ARM alpha 1 and run into any trouble, please visit: https://fedoraproject.org/wiki/Architectures/ARM/Fedora17_rawhide If you don't see your problem, please add it to the list. If you do see your problem and know the solution, please make sure the solution is in the list. We'll do our best to keep the list current and get the status of every item to "FIXED" And while you're there, if you happen to see a broken package you'd like to work on, please do! Thanks everybody. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Primary Architecture - VFAD proposal for tomorrow (Wed Mar 14th 2012 afternoon EST)
On 03/13/2012 12:02 PM, Jon Masters wrote: Hi Folks, I would like to propose that we have a VFAD tomorrow to get the Primary Architecture stuff moving forward, prior to our status phone call, and rolling on into it. What say you? Yes please. Any time after 1900 UTC is good for me. For those who would like to take part please have a look at: https://fedoraproject.org/wiki/Features/FedoraARM The "How To Test", "User Experience", and so forth sections need plumping. The rest needs trimming :-) -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Primary Architecture - VFAD proposal for tomorrow (Wed Mar 14th 2012 afternoon EST)
On 03/13/2012 12:02 PM, Jon Masters wrote: Hi Folks, I would like to propose that we have a VFAD tomorrow to get the Primary Architecture stuff moving forward, prior to our status phone call, and rolling on into it. What say you? Let's go with 20:00 UTC (1PM Pacific, 4PM Eastern). Please join #fedora-arm and if possible dial in at: Toll Free Dial-In Number (US & Canada): (800) 451-8679 International Dial-In Number: +1-(212) 729-5016 Conference code: 617-759-1337 Thanks! -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Primary Architecture - VFAD proposal for tomorrow (Wed Mar 14th 2012 afternoon EST)
On 03/14/2012 10:26 AM, Chris Tyler wrote: $0.02 Added- thanks! -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] ARM Primary Feature page updated
Hi folks, I have made further updates to the ARM Primary Feature page and think it is now good enough for FESCO. If you would like to give it a look before it is reviewed, now is the time. https://fedoraproject.org/wiki/Features/FedoraARM -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] ARM Primary FESCO discussion results, round 1
Hi everybody. FESCO took its first official look at the ARM Primary feature proposal today. There were a lot of great questions, valid concerns, and otherwise very useful feedback. The end result is that we've been asked to engage more parts of the Fedora organization due to the massive scale of our request affecting so many portions of the community, then go through it all again next Monday. Specifically we'll have to talk to Rel-Eng, QE, Kernel and Infrastructure groups to make sure they know what we're planning and have their potential concerns seen to. We've done this casually on an individual basis previously, so this is a more formal inquiry, IE, an email thread to each of the groups' lists. In addition, we'll have to address fedora-devel, but I'd like to delay doing that by a day until we've reached out to the previous 4 groups to get their feedback. If anybody has time to do so in say, the next 24 hours, and would like to volunteer to address one of the groups that would be great. Otherwise Jon or myself will do so. Below are some details from the meeting for your comment and consideration. Many of the FESCO members really want to see ARM succeed in PA- you can tell because they're asking the hard questions! Lets talk these out on the list, update the proposal, and get the other groups involved. Questions from the meeting: How are ARM-specific issues such as legacy alignment problems to be addressed? How do packagers test and resolve failures on ARM if they don't own an ARM device? When will server hardware be available? Why isn't being a secondary architecture good enough? Why not wait for 64 bit ARM? With there being so many different kernel variants, how will a kernel build complete in a reasonable period of time? The builds being done in Koji are great, but what is the plan for composes, QE and installation? If Anaconda isn't used to do installations, what will be doing the things Anaconda does which just installing a bunch of packages doesn't? (I don't know what these are) Will there be extra patches in the kernel to enable new vendors' ARM processors or will upstream continue to be the way? What does the kernel team think about the the time required to build kernels on ARM? How will it affect their workflow? The proposal suggests building just a versatile express kernel by default (to save time), then using koji flags to support alternate kernels. Is this possible? In the event that kernels are built separately per the above, what mechanism will be used to keep the kernels in sync? Assertions from the meeting: There must be a commitment of hardware both for build systems and test systems for PA. Being a PA carries the obligation that all packages in Fedora will be available. The proposed avenue of making broken packages temporarily excludearch is questionable and needs work. FTBFS issues should simply be fixed (That's not an ARM problem, but we're definitely impacted by it). The changes to QE, particularly because of Anaconda, will be substantial. This is not addressed in the proposal. Installability doesn't necessarily mean Anaconda (See EC2), but it does mean something. A real plan is called for. All PA kernels must be derived from the same source rpm. That's it for now- I'll reply later with my own thoughts on the above. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARM Primary FESCO discussion results, round 1
On 03/19/2012 09:30 PM, Brendan Conoboy wrote: Being a PA carries the obligation that all packages in Fedora will be available. The proposed avenue of making broken packages temporarily excludearch is questionable and needs work. The thing that worries me about the excludearch is that there is no mechanism forcing ultimate resolution on packages which could be made to work on ARM. Right now the goal of PA is a strong motivator for fixing packages. If we make it to PA, how will we stay motivated? We're only ever going to asymptotically approach the complete x86 package set so we're going to have to strike a middle ground. What that is is open for discussion, but basically it breaks down into 3 categories: 1. Packages that are truly x86 specific do not need to be made to work on ARM. And the packages that depend upon them hopefully don't either, but there's going to be some issues there. 2. Packages that FTBFS on x86 do not need to be made to work on ARM until they're also made to work on x86. 3. Anything left can and should be made to work on ARM. How many packages are in this set? If it's down to a few dozen let's just fix them up and be done with it. If it's a few hundred we need a plan that involves getting to primary before we're at 100%. So, basically, we need data. What packages fit where in the above 3 categories? How close are we? -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARM Primary FESCO discussion results, round 1
On 03/19/2012 04:46 PM, Brendan Conoboy wrote: How do packagers test and resolve failures on ARM if they don't own an ARM device? I like Chris's suggestion of the simulator- that's good coverage. I'd also support providing login hosts to... somewhere. Seneca? Spare systems in PHX? I'm not sure, but it seems like a good idea to me. When will server hardware be available? During the discussion I said 2-5 months. Notting said 2 was good, 5 was bad. I'll just extrapolate that 3 is not as good and 4 isn't as bad, but ultimately it's going to be when the hardware is available. Hopefully it'll be closer to the 2 than the 5. Why isn't being a secondary architecture good enough? Greater stability in PHX, faster infrastructure, wider mirror selection, greater credibility as a distribution. Why not wait for 64 bit ARM? The mainstay of 64 bit ARM hardware won't be available for a couple years. Incredible ARM systems will be available in the interim that Fedora can run on with comparatively little effort. Additionally, much of what's needed on 64 bit ARM can be done in the 32 bit space (Virtualization support for instance). With there being so many different kernel variants, how will a kernel build complete in a reasonable period of time? Beats me- every proposal is a bit hackish. The builds being done in Koji are great, but what is the plan for composes, QE and installation? This part of the plan really needs some work. Even our discussions about how to compose images isn't quite the same as how to handle QE when it comes time to do an alpha/beta/rc/etc. If Anaconda isn't used to do installations, what will be doing the things Anaconda does which just installing a bunch of packages doesn't? (I don't know what these are) I would hope the standard image builders handle this sort of thing, but do not know. Will there be extra patches in the kernel to enable new vendors' ARM processors or will upstream continue to be the way? Jon answered that it will be upstream only. I agree. Same policy as x86. What does the kernel team think about the the time required to build kernels on ARM? How will it affect their workflow? I suspect Jon is going to discuss with kernel@. The proposal suggests building just a versatile express kernel by default (to save time), then using koji flags to support alternate kernels. Is this possible? According to Dennis: No. So, let's figure out how to get reasonable build times and good breadth on kernel builds. In the event that kernels are built separately per the above, what mechanism will be used to keep the kernels in sync? We may need to have a less ambitious list of kernels. Perhaps keep omap, tegra, highbank, but drop IMX, armada, etc. We'll see where this goes. Assertions from the meeting: There must be a commitment of hardware both for build systems and test systems for PA. In light of qemu+versatile the general test systems might be optional, but in principle if we have systems to spare and appropriate access mechanisms I don't see why not. Being a PA carries the obligation that all packages in Fedora will be available. The proposed avenue of making broken packages temporarily excludearch is questionable and needs work. The thing that worries me about the excludearch is that there is no mechanism forcing ultimate resolution on packages which could be made to work on ARM. Right now the goal of PA is a strong motivator for fixing packages. If we make it to PA, how will we stay motivated? FTBFS issues should simply be fixed (That's not an ARM problem, but we're definitely impacted by it). Suggest presenting the FTBFS list and subtracting it from the list of packages we need for ARM task list. The changes to QE, particularly because of Anaconda, will be substantial. This is not addressed in the proposal. Agree. Help! Installability doesn't necessarily mean Anaconda (See EC2), but it does mean something. A real plan is called for. We just need to formalize our plan for image generation using standard tools (Hopefully whatever was used for EC2 is valid here). All PA kernels must be derived from the same source rpm. Yes. ... Regarding mail to the 4 groups, What do we want to ask each of them? Releng: Do you have any concerns about moving ARM to PA? What are the things you need to see in place? What do you not want to own? Infrastructure: Do we have the hardware/budget ready? What do you need in place that isn't now? What do you not want to own? QE: What do you need to do proper QE on arm? How much load will this add? How can we help? Kernel: ARM will introduce build time delays, but x86 builds will still finish as fast as ever. Is this sufficient? What do you need to see to be okay with ARM on PA? -- Brendan Conoboy / Red Hat, I
Re: [fedora-arm] ARM Primary FESCO discussion results, round 1
On 03/20/2012 02:48 AM, Gordan Bobic wrote: Are alignment problems not considered bugs? It's not just that this will break code on ARM < v7 and IIRC SPARC, but alignment issues also cause cache line straddling which has a performance impact. I took this question to be a case of knowing-just-enough-about-ARM-to-be-harmful. It's really a non-issue, particularly since later ARM chips don't have the problem. Is there any actual reason why Anaconda cannot be used? What is to stop booting a suitable installation kernel for the target platform and having that fetch/mount an installation rootfs that takes over, same as it does in x86? Granted the amount of RAM is an issue, but that's just a case of dieting the installer back to a saner size (de-lobotomizing the text mode installer back to how it was before F11, for example). Anaconda isn't *quite* ready to go yet. And you don't actually gain much by using Anaconda for many devices- you still have to write an image to a removal storage device. Which you then run boot... and it writes a new image to a storage device. You've just made more work for yourself when you could have installed a working image directly. On the server side, PXE abilities mean there's more to be said about Anaconda support. The only issue is, they don't exist yet :-P I found that if the kernel has support for the right SoC, it is simply a case of adding a suitable SoC merge config file and plumbing it in for the build based on a build flag. I have somewhere a 2.6.32-220. kernel src.rpm that builds for both x86 and Marvell Kirkwood, and it was reasonably straightforward to achieve (even if it did require fixing a few bugs that were introduced by upstream vendor patches that didn't manifest on the primary arch). Yes, using one kernel source rpm is working fine for us. It's the long build time which needs to be overcome. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARM Primary FESCO discussion results, round 1
On 03/21/2012 05:22 AM, Chris Tyler wrote: https://bugzilla.redhat.com/show_bug.cgi?id=673691 Agreed, alignment fixups must be enabled early. Ah, I thought this was already resolved. So, er, we just need to followup on this BZ until it's resolved in rawhide? I see it's already in ARMTracker. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] (late notice) Fedora-ARM weekly call on in 15 minutes
Hi folks, Let's get together on the phone and/or online and have a chat. There's been a lot of activity in the last couple weeks and it'd be good to discuss next steps, strategy, etc. Conference code: 617-759-1337 (no passcode required) Toll Free Dial-In Number (US & Canada): (800) 451-8679 International Dial-In Number: +1-(212) 729-5016 Also join #fedora-arm on Freenode -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] Soliciting feedback on Fedora ARM primary arch proposal
Hi everybody. This Monday FESCo did an initial review of the ARM team's ARM PA Feature proposal. As part of that review, they requested we get in touch with affected groups including releng. While Dennis Gilmore has some specific plans in mind and was even involved in creating the feature page, I'd like to solicit your (including Dennis) feedback on what's been written and what still needs to be written as it pertains to release engineering. The feature page in question is: https://fedoraproject.org/wiki/Features/FedoraARM As you might have already ready on fedora-devel, this is a work in progress and has some known deficits (EG, That multiple-kernel koji-flag thing is going away). We'll keep updating it based on the feedback we receive until we have a plan that works for all the stakeholders. If you have some feedback that you haven't already shared on fedora-devel, or that you want to share again because it's really important and releng related please reply to this message and let us know. Thanks! -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] F17 ARM Build Error Stats
On 03/21/2012 05:43 PM, Jonathan Chiappetta wrote: Number of unbuilt/cancelled/building pkgs = 469 Can you describe this one a little better? Is that unique packages or if there are two versions of a single package built does it add 2 to the number? Is it just a count of the latest in arm.koji.fp.o vs PA? Just some temporary stats for F17 thus far! Thanks as always, This is great by the way- would love to see it on a nightly basis. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] F17 Build Times For All Pkgs Built By Trimslices (x86 vs x64 vs sfp vs hfp)
On 03/22/2012 11:45 AM, Jonathan Chiappetta wrote: So I'm sorry if some of the columns are blank, I'm not sure why some of the x86 and x64 columns are missing as they should have all their logs. Maybe its my script and curl is failing somewhere? I'm sorry about the formatting here but if there are is anyone out there who was a data analyzer in a past life maybe someone could help average out our total times vs theirs? Anyway, I'm sure someone might find something useful in the data below assuming all my numbers are correct... It looks like we only have data for sfp or hfp, but never both. Can you check that? Also, if you could put this on the wiki and send a pointer to the list that'd be great. Thanks! -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] (late notice) Fedora-ARM weekly call on in 15 minutes
On 03/22/2012 04:43 AM, Peter Robinson wrote: Did someone take meeting notes for those of us that couldn't attend? Yes, then my system overheated. I recently found where the .swp file was hiding, so here you are: Big take-away: The proposal needs work. Please read and modify. If you don't feel comfortable modifying the text, put something in the Talk tab and ask others to review. If you have reservations, disagree, or see a shortcoming, please edit directly or put in the talk section. This is how we'll get a unified opinion into the document. The proposal needs to: Establish why staying the course as a secondary architecture isn't good enough. 1. The things Peter mentioned in fedora-devel about spending all our time trying to stay caught up. 2. Technology leadership- ARM is the future, Fedora is where development takes place, it's natural that ARM should be represented as being important. Provide ARM 101, including niggling issues that we already have internal consensus on, but have not communicated: LE only. Alignment issue stance. What armv5tel, v7hl, v8 are, and that v8 is not part of the proposal. Other foundation stuff. Provide data based on our F17 experience. 1. How many packages are built in F17? How many of the missing packages are FTBS in PA? This goes to the ExcldudeArch aspect of the proposal. 2. How long do builds take on ARM? How fast will they be on the server grade hardware? Roughly stated we expect up to a 2.5x speedup from server hardware vs *trimslice* builds, so we can extrapolate this information. Do more to discuss how developers may be affected. Slower builds, fedora-devel-list tells us, wil result in QE and Security delays. Chainbuilds will be impacted particularly. Hardware access is needed for packagers who do not have ARM systems, propose resolutions. 1. Redo documentation for QEMU+Virtual Express solution so anybody with a PA x86 system can use. 2. Contemplate who/how to provide ARM test systems to people with FAS accounts. Todos: FESCo specifically asked the ARM team to contact rel-eng, infrastructure, testing, and kernel groups to solicit feedback. rel-eng: bconoboy infrastructure: dgilmore kernel: jonmasters test: pwhalen (?) We will revisit the proposal with FESCo next Monday to get incremental feedback and direction. Please try to have all edits in before this time. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] F17 snapshot images
Hi folks, I've put together a script to create up-to-date F17 snapshot images and am storing the result on my people page. These are based on Peter's F17 alpha1 images with the following changes: There is a tarball without any kernels included. There is a tarball with uBoot-wrapped kernels included (should have everything you need without messy mkimage commands). The armhfp version includes tegra, omap and imx kernels. The arm version includes kirkwood. There are bzcat+dd images for Tegra and OMAP- no partitioning necessary to get started. These decompress to 8GB- if you have a larger storage device resize2fs is your friend. The files are currently uploading and will be entirely there in a few more minutes. You can get the latest at: http://blc.fedorapeople.org/fedora-arm/f17/ This is very much a work in progress, completely unofficial, largely untested, but hopefully useful. Feel free to send me feedback. Enjoy, -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] F17 snapshot images
On 03/29/2012 11:20 PM, Brendan Conoboy wrote: There is a tarball with uBoot-wrapped kernels included (should have everything you need without messy mkimage commands). The armhfp version includes tegra, omap and imx kernels. The arm version includes kirkwood. Oh, and the kernels are 2.6.4x.fc15 kernels which are known to work. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] F17 snapshot images
On 03/30/2012 05:35 PM, "Andy Green (林安廸)" wrote: It's great that you're doing this, but I don't think dding partition + filesystems is a good idea. It's definitely tricky to get right. The number of possible configurations makes it tricky to do an efficient selection of images. I may end up doing a combination tegra+omap+etc image to cut down the waste. We found that various "8GB" SD cards have different absolute numbers of available sectors, it can lead to eventual filesystem corruption if your image is slightly large than someone else's card. Well, the image is being created out of a sparse file with 8000 1048576 byte sectors. If that proves too many it would be little trouble to drop it down to 7900 or something. We'll see how it goes in practice. If someone's going to try this they're probably OK running fdisk and using tarballs. Yeah, the uboot enabled kernel tarball will probably be the most universally useful. I personally had plenty of trouble marking working uboot files so leveraging David Marlin's work on grubby will hopefully spare others that trouble. Meanwhile, a number of people have asked for images they can dd, so I'm trying to fulfill both needs. I've been using Peter's F17 alpha1 image and following progress with updates, it's been very good. It's stuck as of last week with gnome-shell problems though. But generally package completeness has been increasing really well last few weeks, great job. What are the gnome-shell problems? Perhaps they're well known but I'm not acquainted with them. If we're missing a package that will help things out let me know and I'll put it in the next snapshot. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] F17 snapshot images
On 03/31/2012 08:10 AM, Chris Tyler wrote: On the Raspberry Pi Fedora Remix I'm shrinking the image as much as possible by shortening the last (root) partition. The partition is resized to fill the SD card on first boot (fdisk, reboot, resize2fs). This results in a small image size, minimizes unnecessary writes to the SD card, works on any card size, and lets you take full advantage of the space on the card. Perhaps we should adopt that approach for the images? Would be happy to add this- with that sort of functionality I'd have no reservation about creating a 1.990GB image. Send me a pointer to how you're doing this during the first boot and I'll integrate it into the rootfs image generator. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Quick update on prelink
On 04/04/2012 02:24 AM, Jon Masters wrote: Try this trivial patch to src/get.c that educates prelink about our linker (so it won't try to prelink the linker itself). This will then pass the testsuite. On the one hand, if this is all it is it's almost annoying that I went to the lengths to understand how it works before looking at it in detail, but on the other Jakub has told me there's not a lot of good data on prelink-on-arm so I need to do more code review /anyway/. Please try this patch and see what happens. I've installed the prelink package from arm.koji on an armv5tel rootfs, let prelink run its cron job, and the resulting system appears to be working normally. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] F17 snapshot images
Hi everybody, Based on the feedback on these images I've gone through a few more iterations of the build scripts and they've had some testing (thanks dmarlin, pbrobinson and smooge!). There are now images for: Trimslice (hard float, mmc and sda) Panda (hard float, mmc, and sda) Beagle (hard/soft, mmc) To install the image a command just use a command like: xzcat f17arm-latest-armhfp-trimslice-mmcblk0.img.xz > /dev/device For reasons I'm not acquainted with using dd with a large bs value sometimes results in bad writes, so if you use dd keep bs small. Each image decompresses to 1900MB. Upon first boot it will begin the process of auto-resize the / partition to its full capacity. A second boot will complete the process (This is done using a modified version of Chris Tyler's raspberry pi remix resize script). All scripts used to generate the images is included in the same directory. Next up will likely be a unified trimslice/panda image. Fun! -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] ARMv5 and atomic operations
As we get closer to having 100% package coverage in F17-ARM we're running into harder build failures due to the limitations of the chips we're building for. The problem I've noticed on many of the recent failures is due to the lack of atomic operations (These didn't arrive until ARMv6). How do we want to handle this? I see a few options: 1. Abandon armv5 and move to armv6 where some of the operations we need are available. This will still support the raspberry pi- what about kirkwood *plugs? 2. Excludearch armv5tel from the affected packages since they'll never work atomically. 3. Accept that these packages simply won't be available to 32 bit Fedora systems (this is the result of inaction). 4. Pretend operations are atomic when they are not. 5. Create magic patch that implements atomic operations through software. Would appreciate feedback, especially if one of these options is a terrible idea that would impact you or the way you use Fedora adversely. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARMv5 and atomic operations
On 04/22/2012 07:34 PM, Chris Tyler wrote:
What are some examples of these?
First is jemalloc which now has a not-entirely satisfactory patch in
place. The one provoking this email is openmpi. It's wanting, but
missing, dmb, ldrex{,d}, strex{,d}. There are others. Basically when
you see a package working on armv7hl but failing on armv5tel there's a
good chance it's due to missing instructions.
That would kill the older plugs -- anything below a d2plug.
However: do we care? Much? Going to v6 would let us optimize better for
the Raspi, which will have greater market penetration than the plugs
when existing orders are filled. Otoh, it's a whole 'nuther rebuild.
Yeah, it's the "do we care?" question I'd like to hear back on. This
may be a case of famous last words but... I don't think an armv6tel
rebuild would bad terribly hard to do, assuming rpm is setup to handle
it. It's the same ABI, we just get some additional opcodes. Old
packages will continue to work.
6. There is the kernel's "user space atomic helper" (kuser_cmpxchg64) at
0x0f60, see Documentation/arm/kernel_user_helpers.txt. The kernel
puts an instruction sequence here tuned for the current arch that can be
called by userland to provide an atomic compare/exchange -- if it can be
done natively, the instruction sequence does that, otherwise it does a
syscall (with IRQ protection etc). Would this solve the problems you've
identified?
Perhaps somebody with more ARM experience can comment on this.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARMv5 and atomic operations
On 04/23/2012 08:06 AM, Dan Horák wrote: the main problem no only in ARM land is that many software developers like to develop their own atomic ops implementations in their project instead of using some standard one eg. from GCC :-( I fight with this problem again and again on s390 ... Are the fixes you're introducing s390 specific? Would love to reuse existing solutions if they're not already in use. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Some comments on bconoboy's trimslice images
On 04/27/2012 05:51 AM, Richard W.M. Jones wrote: In general pretty good - they work well. However there are a few problems I encountered: Hey, thanks for taking them for a test drive! (1) There's no source for the boot scripts. I think you should put the source along side the binaries, in /boot/uboot. I ended up using 'strings' and reconstructing them. Yeah, I end up using strings a lot myself. Next update I'll throw the generator/boot.cmd template into /boot/uboot for easier tinkering. Long term goal is to move to uEnv.txt, but that won't help systems with built-in uboots that don't support it (trimslice). (2) The sda boot script works fine, however the mmc boot script fails. 'fatload mmc 0:1 ...' should be 'fatload mmc 1:1 ...' (in both places). As mentioned elsewhere in the followups this is because there are two sd readers on a trimslice and you're using the mmc1 location. Perhaps for trimslice there should be an mmc0 and mmc1 image? Once I merge trimslice/panda images that might follow. (3) If you have both images installed, then it boots one of them at random, because it boots from 'root=LABEL=rootfs' which picks one of the labelled root devices at random. Earlier images used root=/dev/someplace, but using root=LABEL=rootfs means fewer boot.scrs are (and less editing is) necessary. The right answer probably is a randomly generated UUID per image. I'll consider adding this next, unless David Marlin gets his lorax images all set before I get to it. They're the real plan. Thanks again! -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Updated Fedora ARM qemu images?
On 04/28/2012 08:21 AM, Richard W.M. Jones wrote: I still can't get any Fedora 17 kernel (soft or hard FP) to boot on qemu-system-arm, on either F17/x86_64 or F17/arm host. On x86-64 it just consumes 100% of CPU, no console, no video, never touches the disk image. On ARM host, qemu-system-arm crashes in TCG. In fact, I have never once got qemu-system-arm to do anything useful, despite trying over many years. Peter is currently cleaning up the kernel configurey which will ultimately result in a versatile express kernel. We'll be testing with it and use it with qemu for producing a new image, documentation, etc. Suggest waiting a few days while this gets worked out. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Pixie Case, - Was ARMv5 and atomic operations
On 04/27/2012 04:38 AM, Nicolas Chauvet wrote: For the record, Pixie is an image renderer engine and requires massive CPU load which worth to have optim enabled. This is also a 'Final component' so it will not be triggered by something that could run on a armv5 only CPU. So my question is how can I opt-out armv5tel to force armv7l compilation instead ? There isn't really an opt-out. We build packages for both armv5tel and armv7hl. If it can't possibly be made to work for armv5tel you can excludearch it. If it can be made to work with some help let's do that. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Debugging our kernels under qemu + gdb
On 05/11/2012 01:04 PM, Richard W.M. Jones wrote: Has anyone tried to debug our Fedora/arm kernels under qemu-system-arm? (In this case, the host is also arm, but I don't think that matters.) Richard, FYI, we as of a few hours ago have nearly-official F17-beta images for versatile express on the following page: http://scotland.proximity.on.ca/arm-nightlies/ There's a link for vexpress and vexpress+x rootfs images. A second link provides a kernel, initramfs, and script for starting qemu. Note that vexpress is much faster than versatile and allows more ram (1GB). Recommend you try this out! -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Debugging our kernels under qemu + gdb
On 05/11/2012 01:50 PM, Richard W.M. Jones wrote: Thanks, I will. Are these going to replace the current Fedora kernel config at some point? Yes, in a few days I would expect the default Fedora ARM kernel to be vexpress oriented. We're still working on integrating the necessary vexpress configuration options. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fedora ARM VFAD - May 11th - 12pm (EDT)
On 05/09/2012 03:32 PM, Paul Whalen wrote: As per our meeting today, we would like to have a VFAD on Friday May 11th at 12pm (EDT) to run through the modified Fedora ARM release criteria (http://etherpad.proximity.on.ca:9001/p/k8c7SAPEhA ) in preparation for the Fedora 17 ARM Beta release. Please take a moment before the VFAD to review the release criteria and provide feedback in #fedora-arm rather then editing the document directly. Hi Everybody, Thanks to everybody who took part testing images during today's VFAD! Here is a summary of what was covered: The following images (At http://scotland.proximity.on.ca/arm-nightlies/) are booting and operating correctly: Trimslice for serial console with SD Card Trimslice for serial console with USB Sata Raspberry Pi for serial console with SD Card (Non-F17 kernel) Raspberry Pi for X console with SD Card (Non-F17 kernel) Versatile Express for serial console with qemu-system-arm (Non-F17 kernel Versatile Express for X with qemu-system-arm (Non-F17 kernel) The following images did boot successfully, but some people observed network issues: Beagleboard XM for serial console with SD Card (Hard Float) Beagleboard XM for serial console with SD Card (Soft Float) I'm rebuilding the Beagle XM images now with a new uboot and an old (known good) kernel. We'll be looking for testers on these- let me know if you plan on trying out either configuration and I will let you know when the new image is in place. The following images did not boot successfully: Pandaboard for serial console with SD Card Pandaboard for serial console with USB SATA The Pandas had problems with the uboot environment (It had never been tested), as well as a kernel panic during boot. Like the Beagle XMs, these are being regenerated. Let me know if you plan on retesting. Additionally, the USB SATA image will require a companion SD image to provide MLO/UBoot. This is not currently provided. The following image was not tested: iMX51 for serial console with SD Card. This image might work with an Efika smarttop (?), but nobody had a chance to test it out. Please note if you're planning on testing this, this is not going to give you a groovy Efika F17 GUI experience- they're still working on the kernel drivers, as I understand it. It's a serial console only image. With regard to release criteria: Alpha Release Criteria: o Each image is accompanied by an MD5 sum. o No known file conflicts exist. o Firstboot: Is not currently operable, but the images do automatically resize and a guest account is available for the X images. Todo. o Virtual consoles: Unknown. Todo. o Default web browser: A web browser is not installed in any image. Suggestions for a suitable browser welcome. Todo. o Update status: Images are up-to-date at generation time. Yum update works. o Graphics: Base X, XFCE Desktop are installed and provide artwork. Graphical bootloader was not tested (rhgb?). Graphical login and xfce work. o Syslog: Is installed, functional. o Shutdown: Reboot reboots or halts, halt halts. Beta Release Criteria: o Alpha release criteria met? Not quite, see above. o Bugs in beta tracker were not checked today. o All images are under 4G in size when uncompressed. X images are 3800MB. Serial images are 1900MB. o Unaware of virtual console testing. Todo. o Unaware of any audio testing performed. Todo. o Desktop testing was minimal but breadth is incomplete (no web browser). Todo. o Removable media was not automatically mounted (or detected) on at least 1 Trimslice. Todo. o Default update manager testing indicates gnome-packagekit is needed. New X images will include this package. o Desktop reboot/shutdown/suspend untested. Plans for what's next: o jonmasters to track down the OMAP (Panda/Beagle) issue. o bconoboy to regenerate images with OMAP workarounds and other VFAD feedback fixes. o pbrobinson to integrate Versatile Express kernel configuration into official kernel-3.3.x.fc17 tree. o Much more testing (It's happening even now). Thanks to jcapik, pbrobinson, dmarlin, dgilmore, pwhalen, pbrobinson, jskarvad, djdelorie, jonmasters, jsmith, jmontleon, ctyler, maxam, and the rest of the Seneca crew for testing images, providing feedback, and making today a great success. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fedora ARM VFAD - May 11th - 12pm (EDT)
On 05/11/2012 04:54 PM, DJ Delorie wrote: I did install and test firefox, it worked fine, including installing add-ons, downloading files, and logging in to FAS. Right- followup question: Is Firefox what we want in the X images? o Desktop reboot/shutdown/suspend untested. I tested this in qemu, it worked. Great! -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Network not working on Devkit8000
On 05/14/2012 03:19 PM, Robert Nelson wrote: What "issue" are you seeing with bconoby's F17-hardfp image? (theres no dm9000 on the beagle xm) If I understand correctly, the Beagleboard XM's ethernet interface is not working with the official FC17 kernel-omap (3.3.4). It's visible, but does not pass traffic. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fedora 17 GA blocker
On 05/15/2012 01:05 PM, Jon Masters wrote: Hi Folks, Not a beta blocker, but please make sure we add "new linker path" to the final requirements before GA. Since we'll have a compat symlink there will not be any impact to users. What's left to be done on this? Do we need a glibc update? -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Unable to boot 3.3.6-3.fc17.armv5tel with qemu-system-arm
On 05/22/2012 12:54 PM, Alex Villacís Lasso wrote: If I specify -M vexpress-a9, I can sort of boot the kernel. However no block device matching the disk image appears anywhere, so the boot process drops to an debug shell, like this: The 3.3.6 kernels are exclussively versatile express so you must use -M vexpress-a9 [snip] [ 50.760153] dracut Warning: Unable to process initqueue dracut Warning: Unable to process initqueue [ 50.773711] dracut Warning: /dev/disk/by-label/rootfs does not exist dracut Warning: /dev/disk/by-label/rootfs does not exist This is because your initramfs does not contain the mmci driver. There is a workaround installed in the current set of images being generated right now. I just booted and tested this one: http://scotland.proximity.on.ca/arm-nightlies/vault/f17arm-20120522-192910-armhfp-vexpress-mmcblk0.img.xz You might find the 'boot-vexpress' and 'boot-vexpress+x' scripts, not to mention the prebuilt initramfs in this archive to be helpful: http://scotland.proximity.on.ca/arm-nightlies/vault/f17arm-20120522-192910-armhfp-vexpress-mmcblk0-kernel.tar.xz -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fedora 17 ARM Beta Release
On 05/23/2012 10:53 PM, rihowa...@gmail.com wrote: http://fedoraproject.org/wiki/Architectures/ARM/Fedora_17_Beta I do not see any files listed with kirkwood kernels. What happened to the files that came with kirkwood kernels? We didn't do image testing on kirkwood devices (dreamplug, guruplug) for the final beta spin, so it was not included. We are generating them every night though, so if you'd like to try a *completely untested* Kirkwood image, you'll find one at the following location: http://scotland.proximity.on.ca/arm-nightlies/ -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] TI Pandaboard ES
On 05/28/2012 02:59 PM, Peter Robinson wrote: The release with the "issue" works fine, I'm using it on my PandaBoard ES. The issue is that we're having to ship a F-15 kernel because the F-17 kernel crashes on boot. I doubt either Debian or Ubuntu ship a 3.3 kernel yet. Other than the older kernel it works fine although it doesn't yet work with X although we're working to get that resolved too. The image with the F15 kernel that Peter refers to can be retrieved from the following location: http://scotland.proximity.on.ca/arm-nightlies/ -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Discussion - F17 GA release for ARM
On 05/30/2012 11:52 AM, Paul Whalen wrote: http://fedoraproject.org/wiki/Architectures/ARM/Quality_Assurance/Final_Release_Criteria Let's begin the discussion on the list - What do you foresee blocking us from our final release of F17? There's one addition I would like to see to the final release criteria: Updated linker path in gcc and glibc. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Discussion - F17 GA release for ARM
On 05/31/2012 01:03 AM, Steve McIntyre wrote: 2 reasons: * it would be nice if people using Fedora create binaries using the right path for the future * the compat symlink on its own isn't enough, changing the filename means the soname has changed too. There's a (quick and very dirty) glibc patch to make things work regardless - see [1] In addition to the glibc and gcc patches we will likely need to update prelink as well. It has some hard-coded strings for what to avoid mangling. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] [PATCH] arm: fixes for Calxeda ECX-1000 from testing
On 06/01/2012 11:26 AM, Mark Langsdorf wrote: I'll submit a 3.4 and a 3.5 patch later today or Monday, then. Hi Mark, To be explicit, what we'd like to see is the 3.4 patch concurrent with an upstream submission. Once you've submitted the patch to upstream we'll carry it in the Fedora kernel until such time as it's accepted upstream and filters down again. Thanks! -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Agreed linker path changes still not in Fedora
On 06/08/2012 09:51 AM, Steve McIntyre wrote: Since then, distros have done the work necessary to use the linker path that was agreed, making changes in gcc and glibc packages. Some people went with the initial patches that were proposed for the sake of urgency, e.g. Ubuntu built using these initial patches for their 12.04 release. Given the all-party agreement on the meat of the problem (the linker path itself), the finer details of the final patches didn't matter so much. Others (Fedora) wanted to wait for the patches to be accepted upstream before accepting them. That's also understandable and reasonable. However, those patches have been upstream for several weeks now and it seems nobody has cared enough to pull them into Fedora yet. Steve, We pulled in the glibc as soon as it went upstream, but for some reason the glibc patch did not actually activate. We're looking into it. FYI, if you support prelink it is likely you will need to add a patch there as well. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] kernel BUG at drivers/mtd/maps/physmap.c:158!
On 06/13/2012 11:19 AM, Alex Villacís Lasso wrote: I am getting the following BUG when trying to boot 3.4.1-1.fc17.armv5tel with qemu-system-arm -M vexpress-a9 , and then boot hangs. I could previously successfully boot with 3.3.6-3.fc17.armv5tel. FYI, I see this too. It appears to be fixed in 3.4.2-3. It'll be in the next nightly after 3.4.2-3 gets pushed out. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] Fedora 17 ARM Release Candidate VFAD happening now
If you would like to take part RC testing please join #fedora-arm in freenode and visit the following URL: https://fedoraproject.org/wiki/Architectures/ARM/Quality_Assurance/2012-06-15-VFAD-Fedora_17_Test_Day -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] kernel BUG at drivers/mtd/maps/physmap.c:158!
On 06/15/2012 10:06 AM, Alex Villacís Lasso wrote: Still present in 3.4.2-3.fc17.armv5tel: Jon Masters tracked this down. For the time being add the following to the kernel command line (IE, the append=...): physmap.enabled=0 -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fedora 17 ARM Release Candidate VFAD results - Follow up VFAD on Monday June 18th
On 06/15/2012 05:25 PM, Paul Whalen wrote: New images for RC2 are being created now! Due to the overwhelming success of today, we are holding another VFAD next week: Fedora 17 - RC2 image validation VFAD Monday June 18th - 12pm EDT #fedora-arm on Freenode If anybody wants to get a jump on Monday's testing the latest nightlies have fixes for all blockers from yesterday's RC1. The images can be retrieved from: http://scotland.proximity.on.ca/arm-nightlies/ Cheers, -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] beaglebone?
On 07/12/2012 08:08 AM, Dr. Michael J. Chudobiak wrote: Hi all, Is a ready-to-go F17 image available for testing the BeagleBone yet? Is there an ETA? I am making an experimental image right now. I will send a followup email when it is ready for testing. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] beaglebone?
On 07/12/2012 04:25 PM, Brendan Conoboy wrote: I am making an experimental image right now. I will send a followup email when it is ready for testing. Update: The image is done, but evidently not going to work. While we have an upstream MLO/uboot solution, some of the necessary pieces for a beaglebone kernel are not yet upstream. Since we don't pull random kernel trees this isn't going to work out of the box. People with beaglebones should grab an alternate kernel and use it with the F17 GA tarball until this support lands upstream. Once it's in the upstream kernel tree we'll have working images. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ 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 09/13/2012 07:04 PM, jon.chiappe...@senecacollege.ca wrote: [ http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=93466 kernel-3.6.0-0.rc4.git2.1.fc18 ] Boots with some soft lockups on my trimslice using sda, original uboot and modified (higher up) uInitramfs load address. Full log: http://fpaste.org/pQaq/ Boot commands: setenv bootargs mem=384M@0M mem=512M@512M nvmem=128M@384M vmalloc=248M video=tegrafb console=ttyS0,115200n8 ro root=/dev/sda2 nohdparm rootwait earlyprintk ext2load usb 0:1 408 uImage-tegra ext2load usb 0:1 840 uInitrd-tegra bootm 408 840 -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] fedora 17 image with Xorg, but without XFCE
On 09/17/2012 07:48 AM, Алексей Любимов wrote: Some months ago, I can see three version F17 tarballs - minimal, xfce and minimal+xorg. Now I see only minimal and XFCE images. Were I can get minimal F17 tarball with Xorg? You're the first person to notice :-) Best to install the minimal set then add the X package set after the fact. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fedora hangs on my TrimSlice
On 09/21/2012 09:23 AM, Petr Machata wrote: Anyone has seen this sort of error? Any ideas how to resolve it? Are you using the latest uboot? We've had trouble with F17 GA on the recently released uboot. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fedora hangs on my TrimSlice
On 09/21/2012 09:42 AM, Petr Machata wrote: I don't think I meddled with this at all. The machine is at least a year old, so the firmware is more likely to be obsolete than too recent. There have been reports that changing the bootargs root= to directly identify the root device instead of using a volume label works with the newer uboot. Perhaps you'll get a similar benefit? Something like this: setenv bootargs console=ttyS0,115200n8 ro root=/dev/mmcblk0p2 rootwait ext2load mmc 0:1 408 uImage-tegra ext2load mmc 0:1 840 uInitrd-tegra bootm 408 840 -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Who's using Kirkwood?
On 10/06/2012 06:50 AM, Peter Robinson wrote: Of course none of this is set in stone, it's a discussion and just me putting my ideas into words. FWIW, I likewise think we should shoot for promotion of armv7hl to primary, leaving armv5 (or armv6) secondary. Numerous packages with atomics issues magically begin working this way. Additionally, in the timeframe we're talking about v7 is going to be the overwhelming majority of systems out there. One extra thought: If we move from armv5tel to armv6hl for the Pi's sake, there's still a big gain: A single koji builder can be used for both armv7hl and armv6hl builds. Supporting armv5tel means we need to provide separate builders for the alternate ABI, raising the overall number of builders required. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ 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 10/06/2012 07:19 AM, Peter Robinson wrote: We're planning on a 3.7 update in F18. The thing is that this is likely to be a disruptive upgrade as certain platforms (even without a unified kernel) will need to have a working device tree. Hence, the moment there is an -rc1 to poke at, we'll make sure this is lined up. We will when mainline goes to 3.7 as mentioned in the thread. In the interim we'll be building at testing the 3.7 kernel in rawhide. Depending upon how far behind we are releasing F18 ARM GA we might just include 3.7 from the start. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Who's using Kirkwood?
On 10/10/2012 10:47 AM, Derek Atkins wrote: Sure, but we're a decade later. Kirkwood devices were just released what? 3 years ago? I certainly got mine more recently than that. I admit I've been running F12 on it, but that's only because there hadn't been another fedora release until F17. The comparison to i686 isn't really very apt. Kirkwood is more like i386, but even that's stretching the simile. There several problems with armv5tel support over the long term. 1. It's not self hosting. We have to use armv7 hosts to build most of the armv5 packages because only they have enough RAM, enough CPU time, fast enough swap. Building UP packages on SMP systems causes issues for a number of multithreaded packages. Transient failures, "bugs" that aren't really bugs, just packages written in the belief that armv5 code will be built and run on armv5 hosts. This problem gets worse with every release. 2. The different ABI requires as much as 2 times the number of build hosts to support both hard and soft float ABIs. 3. Certain features such as atomic operations aren't available on armv5, reducing the number of packages that can be built for ARM in total: If it fails on armv5 but works on armv7, we still don't get it for armv7. 4. The contributors who do most of the Fedora ARM work are focused specifically on armv7, so the energy spent fixing armv5 specific build problems is time taken away from their interest. 5. On the whole, it's not a popular Fedora ARM target. Raspberry pi, OMAP, highbank, this is where most (not all) of our known users have hardware and interest. There are some Kirkwood users, clearly, but there are a lot more users of everything else. We should get some updated download stats on this to demonstrate, but last I saw kirkwood was maybe 3% of usage. Where does this leave us? Dropping armv5tel anytime soon isn't being proposed- we'll certainly do F18. Probably F19, too (We're already building for it). But when we do logistics for moving koji services to PHX, most of the interested parties are thinking of just moving armv7hl. The armv5tel builds can continue as they are, assuming Seneca wants to continue hosting them. We're all volunteers here, so if you want to volunteer some time to keep armv5tel viable please do! Nothing is written in stone or decided, but now is definitely the time to have the conversation. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Who's using Kirkwood?
On 10/11/2012 03:10 AM, Gordan Bobic wrote: Just out of interest, which packages are you referring to? I am assuming it is LibreOffice + a small subset of whatever is in Fedora that isn't in EL; mainly because I had no RAM/swap/CPU issues building any the 2000 or so packages that overlap. Takes about 3-4 weeks on a _single_ SheevaPlug. You're building 2000 packages, we're building 12000. Libreoffice is definitely one one of the problem packages where an armv7hl builder is called for. The koji server has a special 'heavybuilder' group which handles such packages. Are you using USB storage on your sheevaplug? It surprises me that you can get through even 2000 in 3 weeks unless half of them are noarch ;-) 3. Certain features such as atomic operations aren't available on armv5, reducing the number of packages that can be built for ARM in total: If it fails on armv5 but works on armv7, we still don't get it for armv7. In _most_ packages that require this, there are patches that address it. According to http://fedoraproject.org/wiki/Architectures/ARM/Fedora17_rawhide openmpi, pixie, mongodb are all currently broken due to atomics. This blocks condor, iwhd, perl-MongoDB, netcdf*, espresso, gdl, gdal, gromacs, ScientificPython, towhee, pypar, orsa, R-RScaLAPACK, nco, which in turn blocks even more packages. This is not an exhaustive list. This also doesn't consider that some package builds are transiently successful and transiently fail due to thread-safe issues which aren't coded for in armv5tel. With 12000 packages you never known when an armv5tel build is going to hit an SMP builder and expose such a bug. It happens all the time, but koji-shadow just reissues these builds so they work on a subsequent build... sometimes. Or they block hundreds of packages because of a transient failure. 5. On the whole, it's not a popular Fedora ARM target. Raspberry pi, OMAP, highbank, this is where most (not all) of our known users have hardware and interest. There are some Kirkwood users, clearly, but there are a lot more users of everything else. We should get some updated download stats on this to demonstrate, but last I saw kirkwood was maybe 3% of usage. Perhaps a poll might be a good way to ascertain this, rather than a discussion? Feel free to organize one, but what will you do with the resulting data? Regardless of the result, the bottom line is that the people who volunteer to do the work get to set the direction. The plug devices are perfectly useful, still in production, but there just isn't enough manpower interested and capable of supporting them over the long term. The way to keep kirkwood alive isn't to justify its existence, it's to do the work to keep it running. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fedora ARM VFAD - Help test Fedora 18 ARM TC1, kernels and device tree! - 2012-10-15
On 10/16/2012 04:25 AM, Peter Robinson wrote: One notable breakthrough was being able to boot the trimslice with the latest version of u-boot. (had to change boot.cmd to have root=/dev/mmcblk0p3) OK, interesting to see why labels don't work. I think it's a red herring. Booting with root=/dev/sda2 does *not* work. What we can say for sure is that mmc is working, but usb sata is not. Perhaps somebody booting off mmc could try using a label to confirm? My trimslice h's bootlog is here, using the new uboot: http://fpaste.org/iz1r/ Note this boot succeeds when the old uboot is installed- and device tree is active. Appended dtb in both cases. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] BUG: scheduling while atomic: swapper/0/0/0x40000100
On 10/25/2012 04:10 PM, Jon Masters wrote: Here's the upstream ACK: http://lists.infradead.org/pipermail/linux-arm-kernel/2012-October/127317.html The patch in question: http://lists.infradead.org/pipermail/linux-arm-kernel/2012-October/124041.html -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] building F18 Kirkwood images
On 11/01/2012 10:21 AM, Quentin Armitage wrote: Would the guys at Seneca College have anything useful to help with this, since I see that the nightly composes of images started again yesterday? That's me playing with the old nightly generation tools. Best to stick with official media. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Regarding Seneca Issues
On 11/28/2012 12:45 PM, Jon Chiappetta wrote: - repo issues (the generally perl based build failures due to repo issues). I reported I thought I had found the offending host but the issue appears to have come back. Was the host re-enabled, what testing has Seneca done? * Could you please provide the specific task links as examples or names of hosts that are causing the problem so we could diagnose the problem and look into resolving it? - builder issues, seeing issues with things like the disk space on the large builders without a resolution, or a resolution being reported. What is the status, is it fixed? * What are the problems with the large builders? Are there RAM issues, permission issues, low space issues? Which builders need to be looked at specifically because it's hard to solve this without the needed info. There's a common theme here: Issues are coming up and there isn't an obvious way to report them, track them, or otherwise make sure they're resolved, much less documented. We need to fix that. - Some people have remote access to the builders via a ssh key but it appears that not all build hosts are configured for this. What's the steps to resolution so that people can support the platform? * We specifically setup bcfg2 across all builders which helps to distribute our keys to them. If you would like access as you are describing then please contact one of us and we can generate an ssh key on hongkong so that you can login to the builders without a password. I believe this option was offered by one of my co-workers but was denied by a certain person so ya. :/ Don't really understand this. I'm sorry if it seems like I'm not following along here in close detail but our team has various other projects that we are working on simultaneously and sometimes we don't have time to monitor in close detail what exactly is happening in the farm. If you're able to point out specific examples of something failing and highlight all of our names in channel, I will at least definitely be able to see who it is and what is happening, hopefully. This doesn't scale well. The contact names change on a somewhat regular basis and #fedora-arm and #seneca are not support trackers- they're chat channels running 24/7, hours we do not any of us keep. What's needed is a consistent point of contact, whether it be a bot, a web tracker, a separate mailing list, or some other mechanism. Suggestions welcome! -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Issue Tracker for Seneca Infra/RPFR
On 11/29/2012 12:14 PM, Jordan Cwang wrote: I've set up a trac instance at Seneca for people to file issues with our Koji, infrastructure, or any other problems that may arise. You can check it out at http://trac.proximity.on.ca/projects/fedoraarm Additonally, I've set up a RPFR Trac instance as well. That is at http://trac.proximity.on.ca/projects/rpfr. If you have any questions, comments or suggestions regarding these instances, let me know. Please put links to this on the Fedora ARM wiki. Thanks! -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fedora 17 v6hl First Compose Image
On 12/07/2012 12:57 PM, Kevin Fenzi wrote: On Wed, 5 Dec 2012 18:20:20 + Jon Chiappetta wrote: Hey everyone, I was finally able to create an initial image for the rasp pi v6hl. It's by no means ready but I'm trying to release early and release often so I'm sending this out now. I was wondering if anyone out there who had two Raspberry Pi's (with the same RAM count) could do a side-by-side comparison of our two Fedora 17 images (v5 vs v6)? Any feedback would greatly help us out. I installed this on my pi here... seems to work. ;) I've not done much pounding on it however, just light xfce running... If you could run a few benchmarks between the v6 and v5 spins we'd all be *very* interested to know the difference in performance. Even simple stuff like time to bzip2 a cached file would be informative. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fedora 17 v6hl First Compose Image
On 12/10/2012 10:31 AM, Jon Chiappetta wrote: I realize that these numbers seem very minor but I did notice a much faster drawing performance when firstboot was started compared to the v5 version of Fedora. Also, it takes away any excuses or doubt that we're slower than raspian because we're not v6hl. In addition, if v7hl gets moved over to primary one day, then Seneca can still run a farm that has v5 and v6 releases of Fedora. Thanks for your time and testing, I appreciate it as always. It looks like only bzip2 ran for long enough to make a valid comparison. I'd be interested in reproducing any of the benchmarks used here: http://www.memetic.org/raspbian-benchmarking-armel-vs-armhf/ The above shows the difference between armv4 soft float vs armv6 hard float. Presumably armv5 soft float to armv6 hard float will end up somewhere in-between these two points. The big question is where will it end up? If armv6 hard float is substantially similar to armv5 soft float that tells us that the raspbian benchmarks primarily benefited from the move off of armv4. If on the other hand we get significant benefit from armv6 hard float, we know either the hard float or the v5->v6 move was very important. Appreciate all the hard work you've put into bringing armv6hl online. We're just on the cusp of knowing how important it is to continue its pursuit. Keep going! -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] F18 ARM Beta Test Candidate 2
On 12/13/2012 07:40 AM, Peter Robinson wrote: No Beagle? Or is blc doing them later today? It's unofficial, but try: http://scotland.proximity.on.ca/arm-nightlies/vault/tmp/beagle.img.bz2 I'm about to get on a plane but will resume beagle dev upon my return Monday. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fwd: Re: Soft-float chroot on hard-float distro and vice versa
On 12/17/2012 07:57 PM, Jon Masters wrote:
Bind mount /proc, /dev, /sys, and then it'll work just fine. You need
cpuinfo visible for e.g. rpm to determine you are on a hard float system.
Here's some handy shell script to do everything you'll need:
bindmount()
{
mount --bind /dev $1/dev
mount --bind /dev/pts $1/dev/pts
mount --bind /dev/shm $1/dev/shm
mount --bind /proc $1/proc
mount --bind /sys $1/sys
}
bindumount()
{
umount "$1/dev/pts"
umount "$1/dev/shm"
umount "$1/dev"
umount "$1/proc"
umount "$1/sys"
}
This will let you "bindmount /someroot; chroot /someroot; bindumount
/someroot" with ease.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Working on Fedora-arm "port" for Allwinner A10 based devices
On 12/20/2012 02:40 AM, Hans de Goede wrote: My work is based on: -f18arm-latest-armhfp-xfce.tar.xz This is probably the source of your /var/run vs /run problem. The f18arm-latest tarball is based on a series of yum upgrades from f17, meaning there was plenty of room for things to go wrong with the /usr move. I'd suggest working from the latest F18 Versatile Express image instead- pull the rootfs out of it as a foundation. For these "latest" builds I'll be dumping the old scripts and starting over properly with David Marlin's kickstarts and lorax work. It should produce more reliable builds and provide a better foundation. Meanwhile, go with the TC3 image we're doing a VFAD on today: http://scotland.proximity.on.ca/arm-nightlies/vault/f18-beta-tc3/F18-vexpress-xfce-20121218.tar.xz Very cool that you're doing this BTW! -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fedora ARM F18 Beta VFAD - Test Images posted
On 01/04/2013 07:01 AM, Lukas Zapletal wrote: Pardon my ignorance, but where can I find the kernel images? These are just root systems, right? I'd love to try Kirkwood on NSA-310. If you want to test the kernel used in the F18 ARM Beta release candidate the best option is to download the kirkwood image then extract the kernel and initramfs. Here's a link to the image: http://scotland.proximity.on.ca/arm-nightlies/vault/f18-beta-rc1/F18-kirkwood-20121220.img.xz Ucompress and as root use kpartx to expose the partitions as loopback devices: xz -d F18-kirkwood-20121220.img.xz kpartx -av F18-kirkwood-20121220.img From here you can mount the partition with the files you need. I'm not sure which one it is so you'll have to experiment: mount /dev/mapper/loop0p1 /somewhere Good luck, and don't forget to umount and kpartx -d that image when you're done. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] How to increase contributions from new members of the SIG?
On 01/03/2013 10:14 AM, Jared K. Smith wrote: Are there "janitor level" tasks that folks can start on to get their feet wet and start contributing? Is there specific documentation that needs to be written? Tools that need to be tested? Scripts that need to be written? Thanks for starting this thread! There are basically 3 things that we really need help with (off the top of my head): 1. Democratizing ARM support. Right now we have a relatively small set of supported targets in the ocean of ARM devices. The raspberry pi is one example where non-core contributors are making this unsupported platform viable, if only in remix format. The chromebook is the next stellar example. And the allwinner-a10 devices. We need to make the Fedora ARM tent bigger, if it means remixes due to upstream issues. As kernels are unified and drivers are sent upstream the effort that goes into these remixes can then be made mainstream in Fedora. 2. New architecture bootstrap support. We'll be in a position where many hands make light work in aarch64 soon. Likewise, Seneca is proceeding with armv6hl, perhaps they could use a hand? 3. Anything that advances ARM's promotion to Primary Architecture status. As a reminder, the FESCo guidance for this is at: https://fedoraproject.org/w/index.php?title=Secondary_Architecture_Promotion_Requirements Item #10 is is great need of attention: We really need to merge as much as possible with the main Fedora wiki pages. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] How to increase contributions from new members of the SIG?
On 01/09/2013 10:34 AM, Tom Callaway wrote: On 01/08/2013 07:32 PM, Brendan Conoboy wrote: 2. New architecture bootstrap support. We'll be in a position where many hands make light work in aarch64 soon. Likewise, Seneca is proceeding with armv6hl, perhaps they could use a hand? Is there a current status on this? This was a very popular item in my recent Reddit "What should Fedora do in 2013" post. Assume you mean the Pi/armv6hl question- expect this will be a topic discussed at FUDCon extensively. We have the future of armv[5678] to discuss! -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fedora ARM weekly status meeting 2013-01-16 (Results)
Hi everybody, Thank you for joining today's meeting. Here are links to its minutes and log: Minutes: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-01-16/fedora-meeting-1.2013-01-16-21.00.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2013-01-16/fedora-meeting-1.2013-01-16-21.00.txt Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-01-16/fedora-meeting-1.2013-01-16-21.00.log.html -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] F18 ARM Final plan from this morning's hackfest discussion
F18 ARM Final - Will use 3.6 kernel (3.7 will appear as an update) - Blockers for F18-ARM Final - Summarized in BZ #901840 o Graphical updates not working on XFCE desktop - js is broken, this may be the only issue. - hack fest should fix this afternoon - other possible issues? o Eclipse not building - BZ #863801 - Assigned to kdaniel - latest update is that it's building again - Does an arm.koji.fp.o build simply need to be kicked off? - build resubmitted (prior build failed due to bad mock gid) o GHC not building - Was on Peter Robinson's todo list. No status. o V5 images: We will add armv5tel versatile express and panda for final. - Plan is to fix blockers, make RC1 - target ship date is Jan 29. - Seneca to make unofficial ARM tarballs of F18 GA for Remix purposes -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] Fedora ARM Roadmap from this morning's hackfest discussion
During this morning's hackfest we discussed and agreed to a tentative road-map for armv5, v6, v7, and v8. Part of this is in the context of moving build infrastucture to the PHX colocation facility. Part of this is in the context of pushing ARM to Primary architecture status. The following is a summary of what we agreed to: Any release we do as part of Fedora ARM will be supported according to PA life cycle (IE, end of life between PA and SA ARM release will be the same day). Any release we do as a secondary architecture will continue to be supported by the secondary architecture koji instance, even if later releases are done as a primary architecture. For example, F18-ARM will always be secondary because it was built on the secondary koji hub. In a couple weeks' time we will have 96 Calxeda Highbank servers in PHX. There is already a new koji hub and database in PHX ready to take over. Once the ARM systems are running smoothly we will migrate armv5tel and armv7hl builds to these machines. Dennis Gilmore will take the lead in migrating koji to the new systems. Here is the plan on an architecture-by-architecture basis: armv5: F19 will be the last release we build on armv5tel. We will continue to support F19 armv5tel throughout the supported lifecycle of F19. This means packages in f19-testing, f19-updates, etc will continue until they're shut down in prmiary. armv6: Seneca will continue their development of armv6hl on the hardware at Seneca college. The systems currently working on armv5tel and armvhl will be redirected to this effort once those architectures are migrated to PHX- allowing them to make faster progress. armv7: The goal is to push armv7hl as a primary architecture in the Fedora 20 or 21 timeframe. Once accepted some of the builders in PHX will be moved to the primary network infrastructure, but a sufficient number will be left as secondary builders to continue support for F19 and earlier throughout their lifecycles. armv8: The aarch64 bootstrap effort continues to progress and is now at the early portion of stage 3: Rebuilding packages natively with rpmbuild. To follow will be a prolonged stage 4 in which most packages are built with mock. When we bootstrapped armv7hl stage 4 was a significant group effort and will hopefully be so again. It is likely we will reach stage stage 4 before v8 hardware is generally available, so every person's assistance will be especially welcome. The hope is to have v8 support in koji as a secondary architecture shortly after hardware becomes available. Our educated guess is that we will be somewhere between F20 and F21 development when v8 is ready to be guided by koji as an official secondary architecture. That's it! -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Issues on Trimslice with F18 beta
On 01/21/2013 03:39 AM, Peter Robinson wrote: Has anyone else seen issues booting on the Trimslice? Basically it boots through but seems unable to fine the rootfs so just hangs. http://www.fpaste.org/itUt/ I've seen this when booting a trimslice with usb sata and updated firmware. Works fine with mmc, just not usb sata. The root= thing is a red herring. Am hoping 3.7 with an updated dtb will work. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ 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 01/25/2013 08: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've been thinking the same thing. This still gives people on kirkwood plugs over a year of active support, and Pi users will continue to have support via armv6hl. Another added benefit is that this will free up rawhide build systems which can be used by other Fedora communities who want to run projects on the ARM boxes (COPR, infra, etc). Ive put in a request to get numbers of people using the arm and armhfp portions of mirrormanager to get some idea of the number of users out there, though i suspect most arm are raspberry pi and people building in mock. That'll be some great information to have. It would be interesting to know Seneca's Pi download stats, too. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Distributing DTB's for Fedora 18 RC1
On 01/27/2013 08:51 AM, Peter Robinson wrote:
Basically when you do a "make dtbs" it makes the dtbs that match the
kernel config. So we end up with the following with the 3.7.x kernels
that we have in F-18 and they're in /boot/dtb-%{uname}. Note this
scheme can be tweaked but I figured getting something there to start
with was better than nothing.
Note: This will require changes to grubby's new-kernel-pkg similar to
what was necessary to run mkimage for uboot. The principle benefit of
having a separate package is that the dtbs land somewhere with a
consistent name, enabling grubby, boot.scr and uEnv.txt to remain static.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
___
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 01/31/2013 07:21 AM, Quentin Armitage wrote: I guess it's too late now, but I got a few days behind on my list emails. I use 2 * Sheevaplugs and 2 * Dreamplugs with Fedora, and would be very disappointed to see support for them being dropped from Fedora. For me, I still see quite a lifetime in them for what they are doing. Remember the plugs will be supported throughout the F18 lifecycle, so you still have over a year of support. Others are welcome to pick up the torch and run an armv5tel koji server/builds. We're all volunteers on this project, pursuing our individual interests. If v5 is yours, feel free to chip in. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Update on F18 RC?
On 02/02/2013 09:04 AM, Jonathan Masters wrote: Hi folks, Any update on RC images? Working their way to the mirrors as final. Announcement Tuesday as planned. Let's discuss release-notes Monday in #fedora-arm. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Yum offers kernel-3.7.3-101.fc17.armv7l.rpm for armv5tel F17 install, does not boot on qemu vexpress-a9
On 02/08/2013 10:19 AM, Alex Villacís Lasso wrote: A few days ago, I updated my qemu virtual machine, which runs F17 with -M vexpress-a9. The yum update installed kernel-3.7.3-101.fc17.armv7l.rpm . Today I got around to rebooting the machine with the provided vmlinuz and initramfs. However, the boot process stalls with no messages. Not even "Uncompressing Linux...". I reverted to the previous kernel, kernel-3.5.6-1.fc17.armv5tel . What am I doing wrong? Should I use a different qemu emulation? The strange thing is that the vexpress-a9 emulation reports armv7l, so the instruction set is supposed to be OK. You need to use a device tree blob with the 3.7 kernels on versatile express. The latest f18 3.7 kernel includes the device tree you need under /boot. Not sure about f17. Don't worry about the armv7l bit, that's the right arch for armv5tel on versatile express. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Yum offers kernel-3.7.3-101.fc17.armv7l.rpm for armv5tel F17 install, does not boot on qemu vexpress-a9
On 02/08/2013 12:00 PM, Alex Villacís Lasso wrote: [root@rpmbuild-arm var]# rpm -ql kernel-3.7.3-101.fc17.armv7l | grep boot /boot/.vmlinuz-3.7.3-101.fc17.armv7l.hmac /boot/System.map-3.7.3-101.fc17.armv7l /boot/config-3.7.3-101.fc17.armv7l /boot/initramfs-3.7.3-101.fc17.armv7l.img /boot/vmlinuz-3.7.3-101.fc17.armv7l Appears it's not in the F17 3.7 kernel, just F18. I see it on 3.7.5-201.fc18 for instance. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] supporting boot configuration for 32 bit arm
Thanks for sending this- some comments below. On 02/27/2013 12:47 PM, Dennis Gilmore wrote: ** Resending with the right lists ** after talking at devconf with David Cantrell about the best way to support setting up uboot on arm devices in anaconda, the best approach going forward is pretty clear, ill get to it in a bit first i want to describe things as I see them. Unified kernel while solving many issues introduces some. platform detection was kinda simple with separate kernels. unified kernel means that while we dont need to worry about having the right kernel, we do need to worry about loading the right dtb. Yes, though during the transition we have to worry about both! This includes loading a device specific kernel at the start of a release, but loading a unified kernel during the support cycle of the same release. As an example, we have kernel-highbank-3.6.x in Fedora 18 GA, but it's a unified kernel in 3.8. platform detection is also needed to know where in ram we should load the kernel and offsets for initramfs and dtb to be loaded. anaconda can tell us the filesystem and device that we are installing to, but depending on the exact way support is done in uboot we may need to put in different values, SCSI vs SATA vs USB etc we also need to ensure we use the right dtb file. for instance a pandaboard ES can use a pandaboard dtb but will be 1ghz vs the 1.2ghz its capable of. some systems like the highbank ones have the dtb in their uboot. while others need to load an external file. It's important that anaconda have this information, but this data needs to be available outside of anaconda as well, suggesting a library so as i see it we need a library that anaconda can import and use to work out the right values for the system we are installing to. probably the library should write out the uboot template and run mkconfig on it. we could then reuse the library in a tool to say setup a boot sdcard to run the installer on a system. we have an issue where it is really not possible to make the equivilent of a boot.iso that will be bootable everywhere. Agree. As I mentioned in private emails, I favor in-uboot auto-detection with hush scripts in a combined /etc/uboot.d, but this might be too limited to support some eccentricities (Your panda vs panda-es example is tricky). If you do most of the dirty work inside uboot itself you have a better chance of making a unified Fedora image. Do you see this library as a new package or an extension to an existing package? Right now we have some uboot information embedded in grubby in a not-entirely-satisfactory way. I think a new package that grubby and anaconda require on arm on would be preferable. I think we should take this up to the cross distro list at linaro and ideally have the distros work on a database at the least of platforms and the values and types needed. if not the whole library that can be used in different places to set things up. The Ubuntu guys have (had?) flash-kernel (https://launchpad.net/flash-kernel), but it's not entirely satisfactory IMHO. Seems a bit dated though- perhaps they've moved on to some other db. this is only needed for 32 bit arm, 64 bit will have UEFI, ACPI and grub2. potentially we also want to consider if we can implement http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec since we need to implement something anyway. Agree. One other thought I've been kicking around is to get grub2 configuration management up and running (without actually installing the bootloader), then reparse the grub.cfg to create a viable boot.scr. This would make transitioning to UEFI easier. The goals for this endeavor that I can see: 1. Seamless handling of kernel updates on ARM for any Fedora release. The end user should be able to update (or remove) a released kernel and have their system continue to function assuming at least 1 kernel is installed. 2. Ship a single unified prebuilt image for the widest range of systems possible: In Fedora 19, provide a single prebuilt image that supports vexpress, highbank, trimslice and panda, with and without X (Subject to kernel support for X of course). Beagle* would require manual MLO replacement. If MVEBU (Armada XP) support lands in time that'd be nice too. 3. Ship a single unified prebuilt anaconda installer image: In Fedora 19, provide a single prebuilt anaconda installer image to support anaconda-style installations on Highbank, Trimslice, and MVEBU (if kernel support lands in time). -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] Patching aarch64 support into Fedora
Hi everybody, Fedora 19 has many of the enablers for native aarch64 in core packages such as glibc and gcc. Many more packages would compile if config.guess and config.sub recognized aarch64 as a valid architecture, but only the latest version of autoconf knows about aarch64. At last week's fedora-arm meeting we talked about the viability of automatically patching such packages. The outcome of that discussion was that we should first identify how many packages need such a patch, then decide what to do based on that number. Red Hat's Al Stone has written a script which automatically generates patches for each package that needs it (And updates its spec file). After a complete run we can say that ~1850 packages need such a patch. The number may be larger, but it is definitely not smaller, as his only considers autoconf-using packages. If another auto configuration system is in use by a number of packages it too many need updating (cmake?). Now that we have this number, what do we want to do? I see a few options: 1. Do nothing, trip over this issue at least 1850 times during bootstrap. 2. Mail all package owners asking for action. 3. Proven packager commits the patches, package owners take them out once unnecessary. 4. Run autoconf during build, incurring wrath of any packager whose package isn't compatible with the latest autoconf. 5. Your much more sensible idea goes here. What say you? -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] 3.8.x. kernel for F-18/17
On 03/05/2013 12:37 PM, Peter Robinson wrote:
* Trimslice - DTS tested working with uboot v2012.04-1.01 [3] (the one
with half the RAM)
Boots okay with a Fedora 18 rootfs, but there is an issue: Trying to run
mock build results in an out of memory error. This works fine with the
3.7 series.
Mock Version: 1.1.28
INFO: Mock Version: 1.1.28
INFO: calling preinit hooks
INFO: enabled root cache
Start: unpacking root cache
ERROR: Exception(/home/blc/fedpkg/grubby/grubby-8.22-3.fc19.src.rpm)
Config(fedora-rawhide-armhfp) 0 minutes 0 seconds
INFO: Results and/or logs in: /var/lib/mock/fedora-rawhide-armhfp/result
Traceback (most recent call last):
File "/usr/sbin/mock", line 539, in
def do_buildsrpm(config_opts, chroot, options, args):
File "/usr/sbin/mock", line 856, in main
do_rebuild(config_opts, chroot, args)
File "0x01A71930>", line 3, in do_rebuild
File "/usr/lib/python2.7/site-packages/mockbuild/trace_decorator.py",
line 70, in trace
result = func(*args, **kw)
File "/usr/sbin/mock", line 510, in do_rebuild
chroot.init()
File "0x01A68230>", line 3, in init
File "/usr/lib/python2.7/site-packages/mockbuild/trace_decorator.py",
line 70, in trace
result = func(*args, **kw)
File "/usr/lib/python2.7/site-packages/mockbuild/backend.py", line
279, in init
self._init()
File "at 0x01A684B0>", line 3, in _init
File "/usr/lib/python2.7/site-packages/mockbuild/trace_decorator.py",
line 70, in trace
result = func(*args, **kw)
File "/usr/lib/python2.7/site-packages/mockbuild/backend.py", line
316, in _init
self._callHooks('preinit')
File "mockbuild.backend._callHooks at 0x01A66AF0>", line 3, in _callHooks
File "/usr/lib/python2.7/site-packages/mockbuild/trace_decorator.py",
line 70, in trace
result = func(*args, **kw)
File "/usr/lib/python2.7/site-packages/mockbuild/backend.py", line
843, in _callHooks
hook()
File "root_cache._rootCachePreInitHook at 0x01A68070>", line 3, in
_rootCachePreInitHook
File "/usr/lib/python2.7/site-packages/mockbuild/trace_decorator.py",
line 70, in trace
result = func(*args, **kw)
File
"/usr/lib/python2.7/site-packages/mockbuild/plugins/root_cache.py", line
108, in _rootCachePreInitHook
shell=False
File "0x01A40770>", line 3, in do
File "/usr/lib/python2.7/site-packages/mockbuild/trace_decorator.py",
line 70, in trace
result = func(*args, **kw)
File "/usr/lib/python2.7/site-packages/mockbuild/util.py", line 323,
in do
preexec_fn = preexec,
File "/usr/lib/python2.7/subprocess.py", line 679, in __init__
errread, errwrite)
File "/usr/lib/python2.7/subprocess.py", line 1143, in _execute_child
self.pid = os.fork()
OSError: [Errno 12] Cannot allocate memory
Would the people testing the kernel on other devices also try a mock
build to see if this occurs on other devices?
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] 3.8.x. kernel for F-18/17
On 03/05/2013 02:04 PM, Brendan Conoboy wrote: On 03/05/2013 12:37 PM, Peter Robinson wrote: * Trimslice - DTS tested working with uboot v2012.04-1.01 [3] (the one with half the RAM) Boots okay with a Fedora 18 rootfs, but there is an issue: Trying to run mock build results in an out of memory error. This works fine with the 3.7 series. Appears to be an issue with mock 1.2.28. Updating the 1.2.29 (in updates testing) resolves the issue. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Patching aarch64 support into Fedora
On 03/06/2013 06:37 AM, Dennis Gilmore wrote: I say we need the list of packages effected. then we can evaluate how critical it is that we take action. Here is the initial list: http://people.fedoraproject.org/~blc/fedora-arm/patchify/configure.pkgs I think it may actually be much larger. Al and I are going back and forth on fixing up patchify to identify more cases. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Patching aarch64 support into Fedora
On 03/06/2013 07:24 PM, Dennis Gilmore wrote: Talking with the X guys they run autoreconf in %build so all of their packages are false positives. Good catch. Al is updating patchify to also scan %build for such occurrences. We'll have an updated list tomorrow. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] F-18 trimslice images are DOA
On 03/17/2013 02:59 PM, Hans de Goede wrote: [long story about trimslice support nightmware] So is this all a bit mysterious yes, still could we've done better? yes! Yes, please join the thread on how to handle dtbs and the transition. The situation in F18 isn't very good, but we can do much better in F19 if we act now. I had already updated to the dtb capable firmware before I begun, Which is your problem. The shipped image only works with the 2010 firmware. Once you move to a newer firmware you need to move to a newer kernel (new firmware plus old kernel prevents usb sata disks from being detected. so if the dtbs/tegra20-trimslice.dtb file would have been in the image as it should have been, everything would have worked in one go. Adding an appropriate dtbs symlink is documented on the wiki, in conjunction with updating the kernel. That would have helped me, but not users who have not updated the firmware. The wiki-page says that the firmware update is needed when you do a kernel update, IOW it implies that the GA images will work with old firmware, which they don't, since the initrd seems to not get loaded, which breaks even mmc booting, because we specify root by UUID which requires an initrd. The 2010 firmware works with the GA image. The 2012 firmware (512MB) works with the 3.7 and 3.8 kernels after creating the dtbs symlink. The boot.scr doesn't work with the 3.6 kernel on the 2012 firmware though- you have to use uboot 2010 + kernel 3.6 or uboot 2012 + kernel 3.7+dtb symlink. Assuming we're going with the wiki instructions, for sdcard users we've 2 options: 1) Treat them the same as usb-disk users, see below 2) Provide an updated boot.cmd.mmc0 and boot.scr.mmc0 for them, which removes the use of the dtb, and specifies root as root=/dev/mmcblk0p3. Idem with mmc1 for micro-sd users (needs to be tested). For usb users we need the initrd, which for some reason is not working when not loading the dtb ??? And loading the dtb means new firmware. So we need to add instructions for usb-disk users to *first* upgrade the firmware, and also to add the missing dtb file to the image before trying to boot it. The right solution for F19 is to make an auto-detecting boot.scr which loads the right combination of files. F18 is shipped and works as expected (Though it seems the old kernel + new uboot incompatibility is not well explained). -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Help configuring a serial port on an ARM device running Fedora 17
On 03/26/2013 02:57 PM, Alex Villacís Lasso wrote: So I am at a loss about why ttyS2 works and ttyS1 does not. As far as I can tell with strace, both instances receive the username and the password correctly. What can I do to diagnose this further? Do I need to modify something else to enable the second login tty? Check /var/log/messages and /var/log/secure. Assuming you typed the right password, it's probably an issue with root logging into an "unsecure" tty or some pam issue. Are you logging in as root or as an unprivileged user? This doesn't seem arm specific. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] F19: uImage load addresses with unified kernel
Through Fedora 18 GA we've had a one-to-one mapping between the SoC and the kernel rpm. Likewise, we produced a different filesystem image for each SoC (EG, a highbank image, a panda image, a trimslice image, etc). Since then the unified kernel in 3.7 and beyond has introduced the ability to use a single kernel for multiple SoCs. This introduces the pleasant prospect of having a single filesystem image that boots on multiple ARM platforms. In fact, the standard unified kernel for F19 (3.9) may support highbank, omap, and versatile express all from the same vmlinuz. Doing this still requires loading the right dbt, but I have a plan for that. Doing this also requires creating a uImage with the right load address, IE: mkimage -A arm -O linux -T kernel -C none -a $ubootAddress The trouble is, there is no unified $ubootAddress available. The pandaboard uses 0x80008000, highbank and tegra use 0x8000, a10 and exynos5 use 0x40008000, and so forth. Not sure about beaglebone. If we want to realize the dream of having a unified F19 release we need a solution to this problem. I see three options: 1. Use the 0x8000 address for highbank/tegra, demand bootz support for everybody else. Since we control the panda/beagle/beaglebone uboots they would be covered. Not clear on what this means for exynos5, but exynos5 will use an LPAE kernel so that's a separate uimage already. 2. Generate multiple uImage files from a single kernel, then load the appropriate uImage on boot. 3. Split up images to cope. All 3 are viable, none are desirable. Is there a 4th option? If not, what do want to go with? -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] F19: uImage load addresses with unified kernel
On 03/26/2013 04:49 PM, Graeme Russ wrote: 4. Relocatable kernel (like x86) If I understand correctly it already is relocatable. This is simply the address that uboot is instructed to load the kernel into memory at. 5. Have U-Boot process uImage to adjust for load location (U-Boot already does a similar thing for itself) Likewise, this is the address uboot is instructed to load the kernel at. My naive understanding is that uboot loads the header, analyzes it, then loads the rest of the file based on the content of that header. If the header instructs uboot to load the kernel into non-existent memory it not operate correctly. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] F19: uImage load addresses with unified kernel
On 03/26/2013 05:04 PM, Graeme Russ wrote: Hi Brendan, On Wed, Mar 27, 2013 at 10:54 AM, Brendan Conoboy wrote: On 03/26/2013 04:49 PM, Graeme Russ wrote: 4. Relocatable kernel (like x86) If I understand correctly it already is relocatable. This is simply the address that uboot is instructed to load the kernel into memory at. So why worry? Just have the load address in the U-Boot environment. Because uboot's bootm does not handling the relocation? Not 100% sure the mechanics of U-Boot loading an ARM kernel but I think it just loads it blindly where it is told to (i.e. does not analyse the header) That would make more sense (This was my understanding as well, actually), but we're still having an issue: The uImage header, stored in RAM, has a load address that is wrong for some platforms. Unless we're going to change that with an in-uboot memory editor, bootm will honor the address in that header and the boot will fail. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] F19: uImage load addresses with unified kernel
On 03/26/2013 05:26 PM, Graeme Russ wrote: I just realised I got this a bit wrong - mkimage make a U-Boot image with a header which contains the kernel load address. Not sure what mkimage does to the Linux kernel binary itself The kernel binary is left intact. Only a 64 byte header is prefixed. That would make more sense (This was my understanding as well, actually), but we're still having an issue: The uImage header, stored in RAM, has a load address that is wrong for some platforms. Unless we're going to change that with an in-uboot memory editor, bootm will honor the address in that header and the boot will fail. I think this is worth raising on the U-Boot ML Perhaps so. Meanwhile, your message did get me thinking. Here is a hypothetical mkimage command line: mkimage -A arm -O linux -T kernel -C none -a 11223344 -e 55667788 -n VERSION -d vmlinuz-3.9.0-0.rc3.git1.4.fc19.armv7hl uKernel Running hexdump on the kernel shows the uboot header: hexdump -C < uKernel | head 27 05 19 56 97 0b b9 5e 51 52 3c 77 00 47 e8 f0 |'..V...^QR0010 11 22 33 44 55 66 77 88 f2 d9 f3 9c 05 02 02 00 |."3DUfw.| 0020 56 45 52 53 49 4f 4e 00 00 00 00 00 00 00 00 00 |VERSION.| 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || 17-20: The value from -a 21-24: The value from -e (Typically we use the same -a and -e) 32-64: The value from -n We could create a number of uboot headers. Then after loading the default uImage, load a separate uboot header overwriting the first 64 bytes of RAM. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] F19: uImage load addresses with unified kernel
On 03/26/2013 06:09 PM, Graeme Russ wrote: I've had a quick glance at the U-Boot source and I think the newer 'FIT' image may be a better path to follow. In common/image.c you will find fit_image_get_load() and in common/cmd_bootm.c you will find bootm_start() and bootm_load_os(). Teasing apart these functions, it looks like fit_image_get_load() looks for a "load" property (FIT_LOAD_PROP) in the FDT first, then in the FIT image (if the FDT returns a NULL load address). Now you can set properties in the FDT in U-Boot (fdt set []) So have a common FIT image with a common FDT and use U-Boot to tweak the FDT properties such as the kernel load address I'd love to, but we don't ship uboot for a number of our boards. We are limited to the functionality provided by the firmware provided. FIT is not universal. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
