Bug 956767 - qemu-system-arm vexpress-* want CONFIG_FB_ARMCLCD=y
Summary: qemu-system-arm vexpress-* want CONFIG_FB_ARMCLCD=y
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 20
Hardware: arm
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: ARMTracker
TreeView+ depends on / blocked
 
Reported: 2013-04-25 15:07 UTC by Paul Whalen
Modified: 2014-02-24 15:31 UTC (History)
19 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-02-24 15:31:10 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
kernel-modules/module-setup.sh: add amba-clcd.ko on arm (1.21 KB, text/plain)
2013-10-10 21:12 UTC, Cole Robinson
no flags Details

Description Paul Whalen 2013-04-25 15:07:13 UTC
Description of problem:

When lauching qemu-system-arm with graphics, the display window opens with a black screen.  


Version-Release number of selected component (if applicable):

This is present in both qemu-system-arm-1.2.2-11.fc18.x86_64 and qemu-system-arm-1.4.0-9.fc19.x86_64 .


How reproducible:
All 3.8+ kernels, using a DTB.

Steps to Reproduce:
1. Download the vexpress image from: http://dl.fedoraproject.org/pub/fedora-secondary/releases/18/Images/armhfp/Fedora-18-vexpress-xfce-armhfp.tar.xz

2. Boot using the provided boot script and upgrade to a 3.8+ kernel, copy kernel, initramfs and dtb folder from '/boot' to your host machine, shutdown qemu. 


3. Launch the new kernel in qemu-system-arm with '--gui' option. 

  
Actual results:
 
Window opens with a black screen, no further output. 


Expected results:

Window opens with Fedora and XFCE. 

Additional info:

Command used in the bootscript:
No Graphic:
qemu-system-arm -machine vexpress-a9 -m 1024 -nographic -net nic -net user \
      -append "console=ttyAMA0,115200n8 rw root=/dev/mmcblk0p3 rootwait physmap.enabled=0" \
      -kernel "$KERN" \
      -initrd "$RAMFS" \
      -sd "$IMAGE" 
      -dtb $FDTARG
Graphics:
qemu-system-arm -machine vexpress-a9 -m 1024 -net nic -net user \
      -append "rw root=/dev/mmcblk0p3 rootwait physmap.enabled=0" \
      -kernel "$KERN" \
      -initrd "$RAMFS" \
      -sd  "$IMAGE" \
      -dtb $FDTARG

Comment 1 Cole Robinson 2013-08-18 19:33:02 UTC
Peter, Paul, do you guys know if this is an actual qemu issue or an upstream kernel issue?

This page mentions something about kernel reorg breaking display, but only when a device tree is explicitly passed in: 

https://fedoraproject.org/wiki/Architectures/ARM/F19/Installation#For_Versatile_Express_Emulation_with_QEMU

Unfortunately that's required to get virtio working.

I've tried qemu git with the stock F19 arm kernel, but nothing newer, and I can't get display to work regardless of passing in dtb. Any pointers? Maybe a thread to follow?

Comment 2 Peter Robinson 2013-08-19 11:16:00 UTC
> Peter, Paul, do you guys know if this is an actual qemu issue or an upstream
> kernel issue?

Unfortunately not. It works without a device tree, it doesn't work if you specify one. Who is at fault I'm not entirely certain.

> This page mentions something about kernel reorg breaking display, but only
> when a device tree is explicitly passed in: 
> 
> https://fedoraproject.org/wiki/Architectures/ARM/F19/
> Installation#For_Versatile_Express_Emulation_with_QEMU
> 
> Unfortunately that's required to get virtio working.

Is it possible to use a spice display with virtio instead of the other one (I don't remember off hand what we use to use) 

> I've tried qemu git with the stock F19 arm kernel, but nothing newer, and I
> can't get display to work regardless of passing in dtb. Any pointers? Maybe
> a thread to follow?

Paul will be able to spread more light on this.

Comment 3 Paul Whalen 2013-08-19 14:43:16 UTC
(In reply to Cole Robinson from comment #1)
> Peter, Paul, do you guys know if this is an actual qemu issue or an upstream
> kernel issue?

I believe I read something about the display implementation in the dtb still being worked on. I've CC'd Kyle who may have a better idea of whats happening. 


> I've tried qemu git with the stock F19 arm kernel, but nothing newer, and I
> can't get display to work regardless of passing in dtb. Any pointers? Maybe
> a thread to follow?

Nothing beyond whats documented on the wiki. The display should work with 3.9, 3.10 kernels without a dtb.

Comment 4 Fedora End Of Life 2013-09-16 13:39:18 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle.
Changing version to '20'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20

Comment 5 Cole Robinson 2013-10-10 19:06:00 UTC
Okay I poked into this a bit. I think this is just a Fedora kernel config issue: when the explicit config-arm-versatile was dropped, CONFIG_FB_ARMCLCD=y became CONFIG_FB_ARMCLCD=m. I confirmed that taking the current F20 arm config, building kernel 3.11 from git with only changing CONFIG_FB_ARMCLCD=y, qemu graphical output works as expected

Comment 6 Kyle McMartin 2013-10-10 19:07:37 UTC
This is an explicit decision... it should be in the dracut initrd so it's not pointlessly loaded on actual hardware.

--Kyle

Comment 7 Cole Robinson 2013-10-10 19:19:53 UTC
(In reply to Kyle McMartin from comment #6)
> This is an explicit decision... it should be in the dracut initrd so it's
> not pointlessly loaded on actual hardware.
> 

I'm ignorant here, but does that mean 'reassign', 'notabug', 'decision was deliberate but we need a fix somewhere else', or ... ?

Comment 8 Cole Robinson 2013-10-10 21:12:50 UTC
Created attachment 810777 [details]
kernel-modules/module-setup.sh: add amba-clcd.ko on arm

Kyle, I think this is what you meant. If so I'll forward it to upstream dracut

Comment 9 Peter Robinson 2013-10-11 08:02:47 UTC
ultimately if it's in the device tree it should be automatically detected/loaded and then just needs to be in the initrd to do so as early as possible

Comment 10 Justin M. Forbes 2014-02-24 13:57:06 UTC
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs.

Fedora 20 has now been rebased to 3.13.4-200.fc20.  Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.


Note You need to log in before you can comment on or make changes to this bug.