I've been able to boot Fedora 19 on my Wandboard quad. It is very
rough - I basically cross-compiled uboot and the Freescale 3.0.35
kernel separately, and constructed an SD card image from that, plus
the rootfs from Fedora-KDE-armhfp-19-1-sda.raw.xz.
I naturally had to edit the fstab to match the partitions I created
on my SD card.
Anyway, a few pictures are here: http://www.sfalco.us/fedora
It's a start...
A long time ago (last December) I reported a problem with Dreamplug at
least 3.6.10 through to 3.7.5 suffering from the kernel reporting a soft
lockup when I doing a git pull when it was anything but a small update
over the network - see
https://bugzilla.redhat.com/show_bug.cgi?id=910593 . The advice then was
to upgrade to a 3.8 kernel, but due to the challenges of trying to get
my head around device tree it got pushed to the back of the drawer. Now,
I am trying to get Postfix working, and I am finding that it appears to
be causing the kernel to hang up too, so I need to get the upgrade done.
Although git, and probably Postfix, cause the lockup, I have not
experienced any other activity that does; ssh, ftp, yum update for
example all appear to work without a problem.
Over the last couple of days I have been working on upgrading to the
latest Fedora kernel available, so I have been using 3.10.10. Although
the kernel is no longer reporting a soft lockup, when I try doing a git
pull, just about the moment git reports that it is starting to transfer
data the kernel completely stops responding; there is no output on the
console, no output on the terminal where I am running git, and it won't
respond to any keyboard input or pings. After a minute, the watchdog
kicks in and reboots the dreamplug, and I have not managed to find any
entries in any logs that relate to the hangup.
I had previously assumed that this was a generic problem, but I have
tried a different kernel build, from
http://www.xilka.com/sheeva/kernel/3/ . I have tried both 3.10.9 and
3.11.1, i.e. kernels both before and after the Fedora kernel 3.10.10
kernel I was trying. Both of the xilka kernels work fine with git.
So it seems to me that the problem must be in the Fedora
What should I do from here? Simply filing it as a bug at this stage
probably isn't helpful, due to the lack of information. What can I do to
help track down the cause of the problem, and hence get a resolution?
I have tried booting a Dreamplug with the 3.10.10 kernel, but it fails
to boot successfully, and I would appreciate some guidance as to how to
work around the problem.
The symptoms are that it drops into dracut, reporting that it cannot
find the root filesystem on /dev/sdb3 (another Dreamplug with slightly
different config does exactly the same but with /dev/sda2).
I think the problem is that the ehci-orion driver is not being loaded.
On the Fedora kernel, I get the following messages at boot:
[ 18.767308] libphy: Fixed MDIO Bus: probed
[ 18.771637] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI)
[ 18.778214] ehci-pci: EHCI PCI platform driver
[ 18.782734] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[ 18.788992] uhci_hcd: USB Universal Host Controller Interface driver
[ 18.795633] usbcore: registered new interface driver usbserial
[ 18.801524] usbcore: registered new interface driver
[ 18.808129] usbserial: USB Serial support registered for generic
[ 18.814399] mousedev: PS/2 mouse device common for all mice
Booting with a kernel from http://www.xilka.com/sheeva/, I get
[ 6.911191] libphy: orion_mdio_bus: probed
[ 6.911386] mv643xx_eth: MV-643xx 10/100/1000 ethernet driver version
[ 6.912865] mv643xx_eth_port mv643xx_eth_port.0 eth0: port 0 with MAC
[ 6.914207] mv643xx_eth_port mv643xx_eth_port.1 eth1: port 0 with MAC
[ 6.914353] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI)
[ 6.914359] ehci-pci: EHCI PCI platform driver
[ 6.914506] ehci-orion: EHCI orion driver
[ 6.914597] orion-ehci f1050000.ehci: EHCI Host Controller
[ 6.914621] orion-ehci f1050000.ehci: new USB bus registered,
assigned bus number 1
[ 6.914754] orion-ehci f1050000.ehci: irq 19, io mem 0xf1050000
[ 6.934742] orion-ehci f1050000.ehci: USB 2.0 started, EHCI 1.00
[ 6.935444] hub 1-0:1.0: USB hub found
[ 6.935463] hub 1-0:1.0: 1 port detected
[ 6.936156] usbcore: registered new interface driver usb-storage
[ 6.936293] usbcore: registered new interface driver ums-cypress
[ 6.936436] usbcore: registered new interface driver ums-datafab
[ 6.936572] usbcore: registered new interface driver ums-freecom
[ 6.936708] usbcore: registered new interface driver ums-jumpshot
[ 6.936844] usbcore: registered new interface driver ums-sddr09
[ 6.936982] usbcore: registered new interface driver ums-sddr55
[ 6.937450] mousedev: PS/2 mouse device common for all mice
and it then successfully goes on to find the SD cards and USB attached
disc. (This kernel has other problems such as no console output, and
leaving the root filesystem mounted read-only, so using this isn't a
One difference relating to this is that the xilka kernel is built with
whereas the Fedora kernel is built with:
But I think the problem probably really lies in that there is no
usr/lib/modules/3.10.10-100.fc18.armv5tel.kirkwood/kernel/drivers/usb/host/ehci_orion.ko in my uinitrd-3.10.10-100.fc18.armv5tel.kirkwood, which I assume is related to ehci_orion having been moved to device tree support.
Is my diagnosis likely to be correct, and if so, is there a simple way
that I can fix it by rebuilding a uinitrd file (if so, what commands do
I need to do it)? Are there likely to be any other drivers that
ehci_orion.ko depends on that would also need to be included?
Finally, should a new kernel package be produced that does include the
ehci_orion driver? And if so, would it be helpful if I filed a bug.
Just to confirm, the kernel is picking up the Dreamplug device tree,
since I get the following message at the start of the boot sequence:
[ 0.000000] Machine: Marvell Kirkwood (Flattened Device Tree), model:
Globalscale Technologies Dreamplug
Good evening all,
Below is a summary of bugs encountered during Fedora 20 Alpha RC's and their
current status. If you've encountered an issue not mentioned here, please
file a BZ and respond to this thread on the list.
Bug Summary as of 2013-09-16 - Fedora 20 Alpha RC2
- BZ#1004505 - extlinux not included in TC3/4, resolved in TC5
- BZ#1004902 - KDE login fails
- not specific to ARM
- Fixed In Version: sddm-0.2.0-0.6.20130821gite707e229.fc20
- Accepted Blocker
- BZ# 979174 - initial-setup-text not run on console
- Fixed In Version: initial-setup-0.3.7-1
- Accepted Freeze Exception
- BZ#1005435 - Trimslice requires kernel-3.11.0-300.fc20 for network
in F20 Alpha
- Accepted Freeze Exception
- BZ#1006539 - konqueror segmentation fault when attempting form
- Fixed In Version: qtwebkit-2.3.2-3.fc20
- Accepted Freeze Exception
- BZ#1002737 - initial-setup-graphical.service does not run
- Fixed In Version: anaconda-20.16-1.fc20
- Accepted Blocker
- BZ# 985572 - Patch to fix password change requirement when no
- fixes BZ# 985569 which is an Accepted Freeze
- Fixed In Version: anaconda-20.16-1.fc20
Full list of Blocker Bugs
It might be uboot doesn't support bzip or zip that could account for the wrong image formt error.
You could be getting an illegal instruction error if you overwrote part of uboot with the kernel image ie the partitions won't hold the data. then you are calling for bits that you overwrote.
And the device tree stuff changes things too.
I ran into those issues with the pogoplugs.
I forgot the uboot commands off the top of my head but check the size of your partitions vs the size of what you are loading. Uboot will work even if you overwrote some of the bits if you don't call those sections of the code.
I ended up repartitoning and changing all of the memory addresses. Which is kind of a pain.
I hope that helps a little.
Steven Falco <stevenfalco(a)gmail.com> wrote:
On 09/16/2013 07:55 PM, Jonathan Masters wrote:
> If someone can capture a full backtrace then I will look. I will also aim to reproduce myself a few more times. I am told there is a JTAG option but have not looked further since the weekend yet.
I've tried, but I think what I've already posted is all the
backtrace I can get.
Here is the strange thing. It looks like this is happening
while still in u-boot, but it appears to be dependent on
the kernel being loaded.
I realize that that doesn't make much sense, but here are my
reasons for that conclusion.
1) One of the failure cases prints "Wrong Image Format for",
which comes from u-boot/common/cmd_bootm.c
2) If the boot sequence gets as far as printing:
Starting kernel ...
then it will always boot successfully (for me, anyway). That
message comes from u-boot/arch/arm/lib/bootm.c
3) Another failure case prints:
MAYBE you should read doc/README.arm-unaligned-accesses
That comes from u-boot/arch/arm/lib/interrupts.c
I cannot explain why the specific kernel matters, unless the
size of the kernel matters. The uImage from Tapani's tree is
around 2 MB, while the Fedora one is closer to 5 MB.
I don't know if this makes it any easier to track down, but it
is the best data I've got right now.
arm mailing list
Before anyone starts throwing bricks in my direction, yes, I know it is
not the Fedora way to apply ~200 patches to a stable kernel and release
Several people seem to have been trying the F20 Alpha on their
Wandboards, and there have been questions about the (lack of) hdmi
driver, etc. etc. I'm running a 3.11.1, built from a src.rpm with Robert
Nelsons patch set applied. (Or at least the Wandboard/IMX specific
patches.) Hopefully, the situation with "mainline" Wandboard support
will start to change with the 3.12 RC series, but until then, if you
want more driver support than the "stock" Fedora kernel is providing,
I've uploaded RPMS's and SRPM to the Community Squeeze repo. To use...
yum install \
yum --enablerepo=community-squeeze-testing install \
kernel-3.11.1-300.2.wandboard.fc19.armv7hl imx-sdma-firmware \
(Ignore the fc19 dist tag in the kernel package name. It should be fc20,
but I cross-compiled from a F19 x86_64 desktop, hence the fc19.)
After install and before reboot, you'll need to
edit /boot/extlinux/extlinux.conf and make sure the dtb file location is
correct. (For me it wasn't and would have used the dtb file from the
previous kernel install with the new kernel, which will result in no
more functionality than you had before with the "stock" Fedora kernel.)
ie. "fdt /dtb-3.11.1-300.2.wandboard.fc19.armv7hl/imx6q-wandboard.dtb"
I've not had a monitor/TV attached, but from dmesg it looks like hdmi
output should be working. On board sgtl5000 audio is working. Broadcom
wi-fi is working. CPU governor support is working. SPDIF output is not
currently working. (I think I saw a change in one of the "next" git
trees that is required, on top the the two RN patches, to get that
working, but I'm out of time.)
NB1. imx-sdma-firmware package contains a single firmware file. I still
don't think loading from ROM is working, so if you don't install the
firmware package, on-board sgtl5000 audio, (which depends on sdma),
might not be available.
$ rpm -ql imx-sdma-firmware
NB2. brcmfmac-sdio-firmware package contains the 2 firmware files you'll
need for the wi-fi driver to function.
$ rpm -ql brcmfmac-sdio-firmware
NB3. Bluetooth.... In the CS repo, there is a package,
$ rpm -ql brcm4329-bluetooth
Description=Broadcom Bluetooth bcm4329
ExecStart=/sbin/hciattach -n /dev/ttymxc2 any 921600
The brcm4329-bluetooth.service file, uses "ExecStartPre=..." to load the
firmware with brcm_patchram_plus. That appears to succeed. The
"ExecStart=/sbin/hciattach -n /dev/ttymxc2 any 921600" seems to be
failing. Not had time to look at it yet, but if anyone else has time to
jump in and took a look, please do.
NB4. Groans and moans for any breakages/regressions in my direction,
please. Praise and thanks for his work on making the mainline kernel as
functional as possible with the Wandboard at this early stage, to Robert
Clive Messer <clive.m.messer(a)gmail.com>