Most of the (ARM) distros are currently working on or in the transition to
hardfp, but until now most GPU's in de ARM Cortex SOCs don't have any
hardfp drivers yet.
To be able to have a ARM hardfp compiled X Window desktop system/notebook
with 3D support we need hardfp compiled drivers.
I was thinking it might be more efficient is all Linux distro's work
together to get these drivers as it's equally important for all distro
that wants to move to a hardfp distro.
What do you all think, who wants to work together to get full hardfp
support for as most as possible ARM SOC GPUs?
It would be great if we can in the end even have OSS drivers.
Can you share the setup procedure for those interested?
Jon Masters <jcm(a)redhat.com> schrieb:
>In case anyone is interested, I have Fedora running on the AC100U now.
>Unlike some of the other hacks I've seen I wanted to actually use the
>storage efficiently with device mapper presenting it as a contig. block
>device. Unfortunately, some of the block discard support seems to be
>tripping that up. If you try an AC100 with dm, make sure you specify "-E
>nodiscard" to mkfs.ext4 during filesystem creation.
>I'm trying to get a Fedora 15 ARM netbook with a builtin eMMC (looks
>like an SSD, it's not really) working at the moment. If you're
>interested, is a Toshiba AC100U that originally comes with Android and a
>very weird partition table layout used by Android that is both custom,
>not replaceable (bootloader restores it always on reset to the 14
>different partitions that it would like there to be, and several of them
>are unwriteable and not seen by the kernel, etc. etc.), etc. So I'm
>stuck with a couple of small partitions and one big one. A natural case
>where I might aswell use dm to present one backing device for ext4.
>Blah blah blah. Anyway. Long story short, I can make a filesystem on
>this, but only if I specifically disable discard during mkfs. If I let
>that happen, we sit in 100% CPU waiting on that ioctl that never
>completes. Before I dig into this for curiosity, I noticed that you had
>spoken about this a while back, so I wonder if you have some pointers.
>It's an older kernel (currently 2.6.38 but there should be something
>newer soon, so clearly this is not something I'd want to generally worry
>about for upstream) but after the dm discard stuff got merged. Do we try
>to detect whether to call for BLKDISCARD or is this always done now?
>Any thoughts? I'm sorry I'm not a block layer debug expert but I'll
>otherwise put this to one side until there's a more recent kernel.
>arm mailing list
In case anyone is interested, I have Fedora running on the AC100U now.
Unlike some of the other hacks I've seen I wanted to actually use the
storage efficiently with device mapper presenting it as a contig. block
device. Unfortunately, some of the block discard support seems to be
tripping that up. If you try an AC100 with dm, make sure you specify "-E
nodiscard" to mkfs.ext4 during filesystem creation.
I picked up another external usb/sata hard drive since the first one
seems to be so useful. This time, it's an enclosed 2.5" drive instead
of the 3.5" docked drive. In case anyone is thinking about an
external drive and wants to avoid risk, here's what I got...
Western Digital Scorpio Blue WD2500BEVT 250GB 5400 RPM 8MB Cache 2.5" SATA 3.0Gb/s
Rosewill RX81U-AT-25A Rigid aluminum 2.5" SATA to USB 2.0 Ext. Enclosure
Total cost was just under $60 with shipping, a bit higher than the
"combo" drives but this way I know which drive I'm getting :-)
Tested (lightly) on x86-64, trimslice, panda, and olpc - they all
worked just fine with a single USB A plugged in, although the provided
cable was a Y cable in case you needed more power (i.e. two USB A
The x86-64 showed an easily sustainable 37 MB/s streaming read, which
I think is the USB2 upper limit. The trimslice showed a sustained 25
MB/s, panda 23-25 MB/s (that internal hub is shared with ethernet) and
the OLPC 10-25 MB/s (not sure what else it was doing). They all
peaked at 25 MB/s which is the most I've ever seen an ARM board do.
The OLPC even mounted it automatically (I had fdisk'd it earlier).
The drive is a snug fit in the enclosure - no internal screws to hold
it in place, but the case required a slight squeeze to close, so there
must be something flexible in there pressing the drive into the
connector. No rattles.
The enclosure has a separate DC power jack but does not come with a
wall wart. The USB chip does tell the host that it's self powered,
though, which is obviously a lie when you only have the USB plugged
Been a rather intense discussion regarding U-Boot on IRC today, and time
for some reflections and a little decision to be taken.
In stage3 we do have an u-boot package which provides uboot images for
pandaboard, trimslice, beagleboard and some more. The pandaboard
requires u-boot on the boot media, while on trimslice the vendor
provided u-boot is in reality quite sufficient and stored separately in
a nor flash chip.
Several (myself included) thinks it would be good if Fedora fully
supported some boards, with both kernel & up to date bootloader
(u-boot). But u-boot is not a fedora package today and will require both
willing maintainers and package review to happen.
So time for some questions.
Should Fedora for ARM officially support for some well known boards?
Do you think Fedora should provide the bootloader for well known boards
where the required board support is merged mainline?
Do you know anyone who would be willing to help maintain u-boot within
Should u-boot images then also be provided for boards without a trivial
recovery mechanism in case an u-boot update fails? Where there is a risk
of creating bricks if the user do not have jtag access to their board.
Note: Supporting u-boot on boards without mainline u-boot support is not