No DVI after pacman -Syu

[kmihelich]

The proliferation of ARM platforms is definitely a huge problem from a distribution development standpoint. As of now, we have eight different kernels we package for eight distinct ARM architectures, across two different repos. I don't spend much time on the older plug platforms anymore except for keeping packages built and up to date. Their lack of horsepower and connectivity options limits how much you can really do with them, so worrying about getting XBMC built is a complete waste of time. Nearly all of my development time is spent on armv7h to support Cortex-A boards, of which I own a Beagleboard-XM, Pandaboard, and Trimslice. At the beginning of next year I'm looking at adding the Origen board with the Samsung EXYNOS Cortex-A9 chipset and MALI GPU.

I also only focus on dev boards since they are by far the easiest to work with, and in the case of beagle/panda impossible to brick. We have some work going on for the HP Touchpad, but I haven't dived into that yet. The best case to be made for consumer/retail devices is that you're getting some top-notch kit at a serious discount. Find almost any dev board that is the same system as a tablet, for example, and you're looking at some outrageous price inflation. That's also why I never invested in those touchscreen add-on kits for these boards, I simply can't justify that expense. But if you can break into a retail touchscreen device that costs only a fraction of the dev board equivalent, you're in business and on the cheap.

Though while I do spend most of my time on v7 boards, like I said the majority of that is just getting software built and packaged. In a way I've slowly been migrating to a stance as a facilitator for others to expand the board capabilities with the software we provide, as opposed to a device developer/debugger that figures out the tough questions to get every feature on the boards working optimally. I work on the core device features to get interfaces exposed or functionality enabled, but when it comes to the "extra stuff" like audio and video I just haven't had the time. Beagle and Panda are themselves particular issues in the video segment, since PowerVR and/or TI has not made any move toward providing hard-float binary drivers for the SGX GPU that is on the boards. But the hard-float transition is sweeping the entire ARM distro world, with Debian, Fedora, and MeeGo (RIP) maintaining hard-float ports, and with Ubuntu slowly getting on board. Eventually I predict that the upstream manufacturers or NDA-strapped devs will be pressured to start releasing hard-float drivers alongside the standard softfp variants.

[android]

Another minor status update,

Modifying the DVI resolution didn't change anything (hey, it was a long shot)

uEnv.txt is now set to:
$this->bbcode_second_pass_code('', '[root@beagle johnea]# cat /mnt/uEnv.txt
vram=24M
mmcroot=/dev/sda2 rw
dvimode=800x480MR-16@60 omapfb.vram=0:8M,1:6M,2:6M,nolock')

This yields a kernel command line of:
$this->bbcode_second_pass_code('', '[root@beagle johnea]# cat /proc/cmdline
console=ttyO2,115200n8 mpurate=auto buddy=none camera=none vram=24M omapfb.mode=dvi:800x480MR-16@60 omapfb.vram=0:8M,1:6M,2:6M,nolock omapdss.def_disp=dvi root=/dev/sda2 rw rootfstype=ext3 rootwait')

Still getting during boot (from dmesg):
$this->bbcode_second_pass_code('', '...
[ 0.087738] Unable to get DVI reset GPIO
...
[ 2.827209] omapfb omapfb: no driver for display
[ 2.832031] omapfb omapfb: no driver for display
[ 2.837249] omapfb omapfb: failed to setup omapfb
...')

Regarding OMAP DSS and some features built into kernel versus modules (from dmesg):
$this->bbcode_second_pass_code('', '...
[ 0.490234] omap_device: omapdss_dss.-1: new worst case activate latency 0: 30517
[ 0.490264] OMAP DSS rev 2.0
...')

from kernel config:
$this->bbcode_second_pass_code('', '...
CONFIG_FB_OMAP2=y
CONFIG_FB_OMAP2_DEBUG_SUPPORT=y
...
CONFIG_OMAP2_DSS=y
CONFIG_OMAP2_DSS_DEBUG_SUPPORT=y')

So the DSS 2.0 and FB drivers do appear to be built in.

I'm now enabling: omapdss.debug=y and omapfb.debug=y in the bootargs.

from dmesg:
$this->bbcode_second_pass_code('', '...
[ 2.827270] OMAPFB: omapfb_init
[ 2.827545] OMAPFB: omapfb_probe
[ 2.827575] omapfb omapfb: no driver for display
[ 2.832397] omapfb omapfb: no driver for display
[ 2.837615] OMAPFB: free_resources
[ 2.837615] OMAPFB: free all fbmem
[ 2.837646] omapfb omapfb: failed to setup omapfb')

I'm seeking clues now in the kernel source.

Comments from anyone with insight into the new omapfb/omapdss drivers would be very welcome...

johnea

[FlySnake]

I've just installed Debian Squeeze, uname -a:
$this->bbcode_second_pass_code('', 'Linux beagleboard-xm 3.1.3-x4 #1 SMP Sun Nov 27 10:25:10 UTC 2011 armv7l GNU/Linux')
And it works "out of the box"!
This is /proc/cmdline:
$this->bbcode_second_pass_code('', 'console=ttyO2,115200n8 console=tty0 mpurate=auto buddy=none buddy2=none camera=none vram=12M omapfb.mode=dvi:1280x720MR-16@60 omapdss.def_disp=dvi root=/dev/mmcblk0p2 ro rootfstype=ext3 rootwait fixrtc
')
It seems like omaplfb is compiled into image, not module.
I attach /proc/config from Debian, maybe it will be helpful. I don't have much experience yet to solve this problem on Arch.

[kmihelich]

They're using the next version that I haven't compiled for omap, but that -x4 signifies they're using the same patchset that I do. I'll do a kernel build of 3.1.3 after updates finish building and see if that helps anything.

$this->bbcode_second_pass_quote('kmihelich', '.').. I own a Beagleboard-XM, Pandaboard, and Trimslice. At the beginning of next year I'm looking at adding the Origen board with the Samsung EXYNOS Cortex-A9 chipset and MALI GPU.
...since PowerVR and/or TI has not made any move toward providing hard-float binary drivers for the SGX GPU that is on the boards. But the hard-float transition is sweeping the entire ARM distro world, with Debian, Fedora, and MeeGo (RIP) maintaining hard-float ports, and with Ubuntu slowly getting on board. Eventually I predict that the upstream manufacturers or NDA-strapped devs will be pressured to start releasing hard-float drivers alongside the standard softfp variants.

[android]

$this->bbcode_second_pass_quote('FlySnake', 'I')'ve just installed Debian Squeeze, uname -a:
$this->bbcode_second_pass_code('', 'Linux beagleboard-xm 3.1.3-x4 #1 SMP Sun Nov 27 10:25:10 UTC 2011 armv7l GNU/Linux')
And it works "out of the box"!
This is /proc/cmdline:
$this->bbcode_second_pass_code('', 'console=ttyO2,115200n8 console=tty0 mpurate=auto buddy=none buddy2=none camera=none vram=12M omapfb.mode=dvi:1280x720MR-16@60 omapdss.def_disp=dvi root=/dev/mmcblk0p2 ro rootfstype=ext3 rootwait fixrtc
')
It seems like omaplfb is compiled into image, not module.
I attach /proc/config from Debian, maybe it will be helpful. I don't have much experience yet to solve this problem on Arch.

$this->bbcode_second_pass_quote('android', 'W')ith the Debian, are you getting this during boot (ir in dmesg):
$this->bbcode_second_pass_code('', '[ 0.088073] Unable to get DVI reset GPIO')

[android]

$this->bbcode_second_pass_quote('FlySnake', '
')...Since we have the same reset error in Debian, I doubt whether this is a cause.

[android]

$this->bbcode_second_pass_quote('android', '.')..
So I just restarted (the kernel build) using the patch-3.1.3.bz2, for a 3.1.3 kernel, and the debian config. It's building now. In 4 or 5 hours I should have a debian configured 3.1.3 kernel package to test.
...

[android]

The short answer: It works!!!

The kernel built with the debian config doesn't give the "omapfb omapfb: no driver for display" or the "omapfb omapfb: failed to setup omapfb" errors on boot.

The penguin is displayed on the DVI output during kernel init and then a console which allows login.

Regarding the kernel build interruption mentioned above: I edited the linux-omap PKGBUILD and commented out all of the build() lines, except the 'make ${MAKEFLAGS} uImage modules'. I enabled the swap partition with 'swapon /dev/sda1' and then I restarted the kernel build with 'makepkg -e'.

It picked up where it had left off, compressed the kernel, created uImage, linked the modules and created the kernel and kernel headers packages.

This brings the DVI issue down to discovering which difference between the debian config and the arch config are causing the framebuffer to fail.

More soon...

johnea