Re: [fedora-arm] ARMv5 and atomic operations
by Chris Tyler
On Sun, 2012-04-22 at 18:16 -0700, Brendan Conoboy wrote:
> 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).
What are some examples of these?
> 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?
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.
> 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.
6. There is the kernel's "user space atomic helper" (kuser_cmpxchg64) at
0xffff0f60, 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?
-Chris
12 years
ARMv5 and atomic operations
by Brendan Conoboy
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. / blc(a)redhat.com
12 years
Re: [fedora-arm] ARM Primary FESCO discussion results, round 1
by Andrew Wafaa
Aloha,
On Mon, 2012-03-19 at 21:00 -0400, Chris Tyler wrote:
> > How do packagers test and resolve failures on ARM if they don't own an
> > ARM device?
>
> There are several solutions available:
>
> 1. They can use emulation. Fedora already includes a good-quality ARM
> emulator (qemu-system-arm) that provides decent performance; we can
> package ready-to-run ARM images for that emulator. (This emulator can
> provide Kirkwood execution speeds on a modern x86 PC).
>
> 2. ARM computers can be bought for as little as $35 (the Raspberry Pi).
>
> 3. Packagers can use Koji for remote scratch builds (just as someone who
> only has 32-bit x86 can use Koji for 64-bit x86 builds).
>
> 4. We could consider setting up remote access to ARM systems (though
> this doesn't provide a lot of benefit over option 1 in most cases).
>
Please excuse me if you feel I'm being somewhat cheeky with this, but I
genuinely think it could be of benefit to Fedora (and also openSUSE).
As some may know openSUSE uses the Open Build Service[0] for all its
packaging. It is similar to Koji but not quite the same. Our current
setup is to build using the public instance[1] which uses qemu for ARM
emulation, similar to what Chris is proposing. What we also have is a
small native ARM build farm (mostly pandaboards, with some efikas) that
verifies build failures on the OBS. We have found quite a few packages
fail under emulation vs native, and have subsequently submitted patches
upstream for both qemu and the respective packages.
So why am I suggesting Fedora consider the OBS? In a nutshell it means
that more of your community can chip in with an easy(ish) tool, without
having to have decent hardware to hand for running the emulator. I'm not
saying it is a perfect tool, but it does work and we (the openSUSE
community) would be more than happy to help where we can.
Just an option for your consideration :-)
Regards,
Andy
0 = http://en.opensuse.org/Portal:Build_Service
1 = https://build.opensuse.org/
--
Andrew Wafaa
IRC: FunkyPenguin
GPG: 0x3A36312F
12 years, 1 month
Re: [fedora-arm] ARM Primary FESCO discussion results, round 1
by Chris Tyler
First stab at a few answers--
On Mon, 2012-03-19 at 16:46 -0700, Brendan Conoboy wrote:
> How are ARM-specific issues such as legacy alignment problems to be
> addressed?
ARM v7 systems have hardware fixup for alignment issues, just as x86
does. ARM v5 systems can do fixup in software with a CPU trap at a small
performance cost. (Note: there is a performance cost for hardware fixup,
even on x86 systems)
> How do packagers test and resolve failures on ARM if they don't own an
> ARM device?
There are several solutions available:
1. They can use emulation. Fedora already includes a good-quality ARM
emulator (qemu-system-arm) that provides decent performance; we can
package ready-to-run ARM images for that emulator. (This emulator can
provide Kirkwood execution speeds on a modern x86 PC).
2. ARM computers can be bought for as little as $35 (the Raspberry Pi).
3. Packagers can use Koji for remote scratch builds (just as someone who
only has 32-bit x86 can use Koji for 64-bit x86 builds).
4. We could consider setting up remote access to ARM systems (though
this doesn't provide a lot of benefit over option 1 in most cases).
> When will server hardware be available?
Real Soon Now(tm)!
How about "We anticipate early availability of ARM server systems in the summer of 2012."
> Why isn't being a secondary architecture good enough?
1. The user base is expected to grow to substantial numbers quickly. It
is important to provide this user base with timely security updates and
fixes, which can happen much more readily in primary arch than in
secondary (which, even in the best case, lags behind PA).
2. As innovators in open source, we have an opportunity to take a
leadership position by providing first-class support for emerging
platforms such as the OLPC XO 1.75 and 3.0, the Raspberry Pi, and
upcoming very-environmentally-friendly enterprise-class server systems,
each of which supports an admirable goal.
3. The differences between ARM and x86 are not huge, and therefore cost
of supporting ARM as a primary arch is not very high. ARM is
little-endian (like x86), and nearly all of the libraries and languages
in Fedora now support ARM (very different from even a few releases ago).
(Needs strengthening)
> Why not wait for 64 bit ARM?
64 bit ARM is years away from general availability, let alone widespread
use. Fully supporting 32-bit ARM now puts us in a solid position to
support 64-bit enterprises systems as they appear.
> 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?
Rootfs composes will be automated in much the same way that x86 spin
composes are now automated. QE and installation will be different but
not vastly more complex than in the x86 realm.
(I think that we should explain the ARM install situation in terms of
live image spin composes, because these have the greatest similarity --
the package selection is preset and not alterable during installation,
for example).
> 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)
These include:
- setting up the partitioning
- (in some cases) setting up the network configuration
- setting the root password
- selecting the timezone
- selecting the locale and keyboard layout
- (package selection, which does not apply to x86 live images)
Several of these will need to move from Anaconda to firstboot (we're
already working firstboot modules for a few of these for the Raspberry
Pi).
> 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?
Question: do we need to do a fully-clean build for each ARM SoC variant?
Or can we do the machine and config changes for each and then make? The
difference in time could be huge.
> 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?
I think a better question is: Is this wise? This would mean that the
majority of the ARM kernels won't be built or tested by default.
(Also, do we mean "Koji flags" or do we mean "editing the spec file to
set macro values"?)
> 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.
This is what we're proposing.
>
> That's it for now- I'll reply later with my own thoughts on the above.
12 years, 1 month
Re: [fedora-arm] ARM and shipping of various binary firmware / boot bits
by Peter Robinson
On Thu, Mar 8, 2012 at 3:06 PM, Tom Callaway <tcallawa(a)redhat.com> wrote:
> On 03/08/2012 10:04 AM, Peter Robinson wrote:
>> On Thu, Mar 8, 2012 at 3:03 PM, Tom Callaway <tcallawa(a)redhat.com> wrote:
>>> On 03/08/2012 09:52 AM, Peter Robinson wrote:
>>>> On Thu, Mar 8, 2012 at 2:42 PM, Tom Callaway <tcallawa(a)redhat.com> wrote:
>>>>> On 03/07/2012 07:14 PM, Peter Robinson wrote:
>>>>>> Hey spot,
>>>>>>
>>>>>> On our weekly call today we discussed the always fun bit of binary
>>>>>> blobs. ARM has the usual wireless and associated blobs most of which i
>>>>>> think are already upstream (and already in Fedora).
>>>>>>
>>>>>> The bits that came up is uboot, MLO (X-Loader) [1] and what ever some
>>>>>> of the other devices use such as the Raspberry Pi. In the first
>>>>>> example the source code is available but forked from upstream, in the
>>>>>> later it's a binary blob not that dissimilar presumably to a wifi
>>>>>> firmware. For the binary blobs is the process the same as per wifi or
>>>>>> any other binary? What about the MLO/uboot, is it enough to package
>>>>>> the binaries and include details in COPYING/spec where the source code
>>>>>> is?
>>>>>>
>>>>>> I'm sure there's some other cases I've not thought of that you might
>>>>>> be aware of too. Can you advise of the best and easiest way for us to
>>>>>> deal with these?
>>>>>
>>>>> We need to review each of the binary firmware items individually. Just
>>>>> open review request tickets and block FE-Legal immediately.
>>>>>
>>>>> As for uboot, is there any good reason not to build from the available
>>>>> source code? And MLO? I'm not sure we can consider a bootloader to be
>>>>> firmware. That one might not be able to go into Fedora.
>>>>
>>>> Well we probably might well be able to but there's dozens of branches
>>>> and forks etc for initiated every different SOC in their millions of
>>>> different configurations, it's closer to a BIOS than a bootloader I
>>>> believe, Linaro is in the process of adding grub2 support for ARM so
>>>> grub will eventually run as a bootloader just like on x86.
>>>
>>> In that situation, will we still need the uboot/MLO stuff?
>>
>> Yes, I believe so.
>
> Okay, so I'm admittedly a bit lost here, because we don't normally ship
> BIOS code for any other platform (apart from qemu). Why is ARM different
> in that regard? Why don't the vendors deliver BIOS (or equivalent)?
In some cases they do and we don't need to worry about it, in other
cases like the PandaBoard they're likely just being too tight to put a
flash chip on the board to hold the FW/BIOS so you have to have a
small partition at the beginning of the SD to hold it and the SoC
basically searches for a location that is set by pin combinations for
the SoC boot code off serial/mmc/usb,
Peter
12 years, 1 month
Re: [fedora-arm] ARM and shipping of various binary firmware / boot bits
by Gordan Bobic
Tom Callaway wrote:
> On 03/08/2012 10:04 AM, Peter Robinson wrote:
>> On Thu, Mar 8, 2012 at 3:03 PM, Tom Callaway <tcallawa(a)redhat.com> wrote:
>>> On 03/08/2012 09:52 AM, Peter Robinson wrote:
>>>> On Thu, Mar 8, 2012 at 2:42 PM, Tom Callaway <tcallawa(a)redhat.com> wrote:
>>>>> On 03/07/2012 07:14 PM, Peter Robinson wrote:
>>>>>> Hey spot,
>>>>>>
>>>>>> On our weekly call today we discussed the always fun bit of binary
>>>>>> blobs. ARM has the usual wireless and associated blobs most of which i
>>>>>> think are already upstream (and already in Fedora).
>>>>>>
>>>>>> The bits that came up is uboot, MLO (X-Loader) [1] and what ever some
>>>>>> of the other devices use such as the Raspberry Pi. In the first
>>>>>> example the source code is available but forked from upstream, in the
>>>>>> later it's a binary blob not that dissimilar presumably to a wifi
>>>>>> firmware. For the binary blobs is the process the same as per wifi or
>>>>>> any other binary? What about the MLO/uboot, is it enough to package
>>>>>> the binaries and include details in COPYING/spec where the source code
>>>>>> is?
>>>>>>
>>>>>> I'm sure there's some other cases I've not thought of that you might
>>>>>> be aware of too. Can you advise of the best and easiest way for us to
>>>>>> deal with these?
>>>>> We need to review each of the binary firmware items individually. Just
>>>>> open review request tickets and block FE-Legal immediately.
>>>>>
>>>>> As for uboot, is there any good reason not to build from the available
>>>>> source code? And MLO? I'm not sure we can consider a bootloader to be
>>>>> firmware. That one might not be able to go into Fedora.
>>>> Well we probably might well be able to but there's dozens of branches
>>>> and forks etc for initiated every different SOC in their millions of
>>>> different configurations, it's closer to a BIOS than a bootloader I
>>>> believe, Linaro is in the process of adding grub2 support for ARM so
>>>> grub will eventually run as a bootloader just like on x86.
>>> In that situation, will we still need the uboot/MLO stuff?
>> Yes, I believe so.
>
> Okay, so I'm admittedly a bit lost here, because we don't normally ship
> BIOS code for any other platform (apart from qemu). Why is ARM different
> in that regard? Why don't the vendors deliver BIOS (or equivalent)?
ARM SoCs come from a completely different, unstandardised background,
unlike x86. This is the same reason why you cannot have a kernel for one
SoC booting on another (at least not at the moment).
Linaro are trying to converge the basic features toward a standard that
will allow a common kernel to boot on multiple SoCs, but this is not
going to happen overnight.
Gordan
12 years, 1 month
Re: [fedora-arm] ARM and shipping of various binary firmware / boot bits
by Tom Callaway
On 03/08/2012 10:04 AM, Peter Robinson wrote:
> On Thu, Mar 8, 2012 at 3:03 PM, Tom Callaway <tcallawa(a)redhat.com> wrote:
>> On 03/08/2012 09:52 AM, Peter Robinson wrote:
>>> On Thu, Mar 8, 2012 at 2:42 PM, Tom Callaway <tcallawa(a)redhat.com> wrote:
>>>> On 03/07/2012 07:14 PM, Peter Robinson wrote:
>>>>> Hey spot,
>>>>>
>>>>> On our weekly call today we discussed the always fun bit of binary
>>>>> blobs. ARM has the usual wireless and associated blobs most of which i
>>>>> think are already upstream (and already in Fedora).
>>>>>
>>>>> The bits that came up is uboot, MLO (X-Loader) [1] and what ever some
>>>>> of the other devices use such as the Raspberry Pi. In the first
>>>>> example the source code is available but forked from upstream, in the
>>>>> later it's a binary blob not that dissimilar presumably to a wifi
>>>>> firmware. For the binary blobs is the process the same as per wifi or
>>>>> any other binary? What about the MLO/uboot, is it enough to package
>>>>> the binaries and include details in COPYING/spec where the source code
>>>>> is?
>>>>>
>>>>> I'm sure there's some other cases I've not thought of that you might
>>>>> be aware of too. Can you advise of the best and easiest way for us to
>>>>> deal with these?
>>>>
>>>> We need to review each of the binary firmware items individually. Just
>>>> open review request tickets and block FE-Legal immediately.
>>>>
>>>> As for uboot, is there any good reason not to build from the available
>>>> source code? And MLO? I'm not sure we can consider a bootloader to be
>>>> firmware. That one might not be able to go into Fedora.
>>>
>>> Well we probably might well be able to but there's dozens of branches
>>> and forks etc for initiated every different SOC in their millions of
>>> different configurations, it's closer to a BIOS than a bootloader I
>>> believe, Linaro is in the process of adding grub2 support for ARM so
>>> grub will eventually run as a bootloader just like on x86.
>>
>> In that situation, will we still need the uboot/MLO stuff?
>
> Yes, I believe so.
Okay, so I'm admittedly a bit lost here, because we don't normally ship
BIOS code for any other platform (apart from qemu). Why is ARM different
in that regard? Why don't the vendors deliver BIOS (or equivalent)?
~tom
==
Fedora Project
12 years, 1 month
Re: [fedora-arm] ARM and shipping of various binary firmware / boot bits
by Peter Robinson
On Thu, Mar 8, 2012 at 3:03 PM, Tom Callaway <tcallawa(a)redhat.com> wrote:
> On 03/08/2012 09:52 AM, Peter Robinson wrote:
>> On Thu, Mar 8, 2012 at 2:42 PM, Tom Callaway <tcallawa(a)redhat.com> wrote:
>>> On 03/07/2012 07:14 PM, Peter Robinson wrote:
>>>> Hey spot,
>>>>
>>>> On our weekly call today we discussed the always fun bit of binary
>>>> blobs. ARM has the usual wireless and associated blobs most of which i
>>>> think are already upstream (and already in Fedora).
>>>>
>>>> The bits that came up is uboot, MLO (X-Loader) [1] and what ever some
>>>> of the other devices use such as the Raspberry Pi. In the first
>>>> example the source code is available but forked from upstream, in the
>>>> later it's a binary blob not that dissimilar presumably to a wifi
>>>> firmware. For the binary blobs is the process the same as per wifi or
>>>> any other binary? What about the MLO/uboot, is it enough to package
>>>> the binaries and include details in COPYING/spec where the source code
>>>> is?
>>>>
>>>> I'm sure there's some other cases I've not thought of that you might
>>>> be aware of too. Can you advise of the best and easiest way for us to
>>>> deal with these?
>>>
>>> We need to review each of the binary firmware items individually. Just
>>> open review request tickets and block FE-Legal immediately.
>>>
>>> As for uboot, is there any good reason not to build from the available
>>> source code? And MLO? I'm not sure we can consider a bootloader to be
>>> firmware. That one might not be able to go into Fedora.
>>
>> Well we probably might well be able to but there's dozens of branches
>> and forks etc for initiated every different SOC in their millions of
>> different configurations, it's closer to a BIOS than a bootloader I
>> believe, Linaro is in the process of adding grub2 support for ARM so
>> grub will eventually run as a bootloader just like on x86.
>
> In that situation, will we still need the uboot/MLO stuff?
Yes, I believe so.
Peter
12 years, 1 month
Re: [fedora-arm] Thought there might be some Interest. Rasperry Pi
by Peter Robinson
On Wed, Feb 29, 2012 at 1:07 PM, Gordan Bobic <gordan(a)bobich.net> wrote:
> Peter Robinson wrote:
>>
>> On Wed, Feb 29, 2012 at 12:33 PM, Gordan Bobic <gordan(a)bobich.net> wrote:
>>>
>>> Frank Murphy wrote:
>>>>
>>>> http://uk.rs-online.com/web/generalDisplay.html?id=raspberrypi
>>>
>>>
>>> Still only available for pre-order-interest-registration, though.
>>>
>>> The good news, however, is that the type A device (available some time
>>> later
>>> this year allegedly) looks like it will also ship with 256MB of RAM
>>> (instead
>>> of the originally planned 128MB), which elevates it from "useless" to
>>> "mostly useless" as far as running a current Linux distro is concerned.
>>
>>
>> Fedora at least runs just fine with 256Mb of RAM. I have a few devices
>> with such spec that will happy run a UX on them, the XO-1 is one
>> example.
>
>
> Define "runs just fine", please. Default desktop environment with some
> commonly used applications like Firefox and Thunderbird? My Thunderbird
> expands to over 150MB of RAM when it loads.
>
> And then there's LibreOffice...
>
> If "runs just fine" is intended to mean "average desktop use", I don't think
> the experience with 256MB of RAM fits the description.
It runs Firefox and LibreOffice just fine using gnome 3 in fall back
mode. You can't run a large amount of tabs but when I say just fine
it's exactly what I mean.
The Raspberry Pi or the XO are not devices aimed at "average desktop
use" and I'm sure anyone would be able to work that out but the fact
remains it does run it and runs it reasonably well given the specs on
the device. If you want a fast device that can do 100s of tabs and a
billion other things you need to go and spend more than $35. They're
both a completely different use case.
Peter
12 years, 2 months
Update On The Fedora ARM Image Installer
by Jonathan Chiappetta
Hey everyone,
I hope all is going well. I just wanted to post an update on my progress with the "easy-to-use"
Fedora Installer script. I decided to write it in Python (2 & 3 compatible) using QT4 GUI API.
I also realized that Windows isn't able to read/write EXT partitions so the format being used
for install images are block-level device copies (i.e. a raw dd image). We can use Chris's idea
of expanding the root FS partition size on first-boot so the user is able to re-gain any space left.
The script is able to read from a text file online which can then point to various dd image links
available for download so the script doesn't need to be updated constantly. I'm really trying hard
to get this out quickly and working so that it can be tested before the launch of the Raspberry
Pi allowing users to easily create bootable cards.
The last parts I have to "hook-up" are the actual commands to dd the data onto the device.
I have everything setup inside the script to do so, I'm just working out how to get information
from the dd command back into the script for the progress bar and text status. I find it funny
that the author of dd.exe for Windows at least included an option switch to make it print
the program's progress report to stdout where as the Linux dd command requires one to send a
"USR1 signal" to the process itself to spill some info. Anyway, it's almost a working script (assuming the image
files work) and I plan to test it fully on Tuesday when I'm at Work. In the mean time, here are some
screenshots below and a link to the source:
http://hongkong.proximity.on.ca/~jchiappetta/faii-nix.png
http://hongkong.proximity.on.ca/~jchiappetta/faii-win.png
http://git.fedorahosted.org/git/?p=arm.git;a=tree;f=faii;h=31398dc7342197...
http://git.fedorahosted.org/git?p=arm.git;a=snapshot;h=31398dc7342197f088...
Thanks for your time,
Jon Chiappetta
12 years, 2 months
