On 12/29/2013 06:32 AM, Peter Robinson wrote:
On Sun, Dec 22, 2013 at 2:34 PM, Steve Underwood <steveu@xxxxxxxxxxx> wrote:
On 12/22/2013 08:59 PM, Adrian wrote:
I see vfat images dated this month, however still indicating the serial
console requirement.
When will we get to a bootable image, with usb/hdmi support please?
Adrian ... vk4tux
This month's VFAT image for the Beaglebone Black is badly broken. If you
want something workable use an older
image.Fedora-Minimal-VFAT-armhfp-20-1-sda.raw.xz
<http://ftp.jaist.ac.jp/pub/Linux/Fedora/releases/20/Images/armhfp/Fedora-Minimal-VFAT-armhfp-20-1-sda.raw.xz>
contains a kernel which keep oops'ing on certain operations, like an
outbound slogin attempt. I reported that and the response was kernel RPM
3.12.5-302 which results in a board which will not boot at all.
What do you mean by "this months image". The release image does have
some known and documented limitations but it's relatively stable for
the documented use case.
If you try to slogin to another box from the release image you get an
oops. That's a severe enough kernel problem to make the image pretty
useless for most people.
It looks like kernel-3.12.5-302 fixes various things for x86_64 machines, so
it is an improvement for them, yet it really wrecks an ARM installation. I
guess we can expect ARM to always be a secondary architecture, with anything
that benefits x86_64 users being pushed, regardless of its effects on other
users.
That's not exactly true. Firstly whether it be x86 or ARM no one
particularly device blocks a kernel release. If there's an issue with
a particular piece of HW it's then fixed in a later release. In the
case of the BB Black the 3.12.x kernel massively improves a number of
things such as usb, hdmi and other things. There was one known
regression which is the ethernet, which while it works isn't the most
stable. I've today pushed a patch that should fix this for the next
kernel build and I've put up a scratch kernel [1] for those that wish
to try it while we wait for the Fedora kernel devs to push a new
kernel.
No single piece of *new* hardware holds up a kernel, but they are very
reluctant to break things that were working. Its rare that a "yum
update" on a working x86_64 machine has a negative effect. "yum update"
is still an adventure on an ARM machine.
The 3.12.x kernel apparently does a lot of good things. However,
updating to the 3.12.5 RPM results in a BeagleBone Black which will not
boot. I feel that's a serious drawback. If you look at
https://bugzilla.redhat.com/show_bug.cgi?id=1043033 you will see the
issue is marked as closed a while after I reported that the "fix" bricks
boards. I'm sure a report that the RPM brocks x86_64 boards would have
been taken more seriously. With that approach to updates "yum update" is
going to remain an adventure. Remember that 3.12.5 is an update to a
release. We aren't talking about betas.
We the Fedora ARM kernel people and wider testers are doing our best
with limited time and many devices to support with a greatly moving
target that is the upstream kernel. We do our best but there's many
combinations of hardware which people use in many different ways and
we do try our hardest to support all the many different ways and means
that people want to use Fedora on ARM.
Unless there is a change of course you are fighting a loosing battle.
Ubuntu are less strict about how they put things together, and have had
a satisfactory installer for the BeagleBone Black pretty much from its
release date. That means almost all BeagleBone users are using Ubuntu,
and only a handful of determined Fedora users like me are even testing
Fedora on this hardware. A small pool of testers is not a recipe for
success.
As a software development platform (mostly for me to try using NEON to
accelerate some of my DSP code on ARMs) the betas of Fedora 20 work very
well. However, all I really need are the SD card and Ethernet port
working. :-\
Peter
[1] http://pbrobinson.fedorapeople.org/arm-kernel/kernel-devel-3.12.6-300.fc20.armv7hl.rpm
Regards,
Steve
_______________________________________________
arm mailing list
arm@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/arm
