No DVI after pacman -Syu

[FlySnake]

Hi everyone!
I've just installed Arch on my BB-xM, as written in the tutorial http://archlinuxarm.org/platforms/armv7 ... tform_tabs and I have the same problem with DVI. Serial console and SSH works OK.
Rootfs : archlinuxarm.org/os/ArchLinuxARM-omap-smp-latest.tar.gz
$this->bbcode_second_pass_code('', '[root@alarm ~]# uname -a
Linux alarm 3.1.0-1-ARCH #1 SMP PREEMPT Wed Oct 26 00:49:16 UTC 2011 armv7l ARMv7 Processor rev 2 (v7l) OMAP3 Beagle Board GNU/Linux')


Probably this kernel has a bug, but I cannot downgrade it because I didn't update anything. Is there any solution? Or which kernel version should I build in order to get working DVI ?
Thx in advance!

[android]

Thanks kmihelich! I had forgotten the xf86-video-omapfb.

However I'm still getting both error messages mentioned earlier:

at boot: omapfb omapfb: no driver for display

and when starting X: missing /dev/fb0

I'm running linux-omap-3.1.2-1, which is the current kernel.

Some have indicated a kernel downgrade corrected the missing fb driver issue. I'm trying that now (I have 3.1.1 in /var/cache/pacman)

But it seems this issue goes back to at least Sept, I'm not sure if a downgrade to 3.1.1 is going to be enough.

I've spent quite a bit of time scroogling for this one with very little result. Lack of this issue on other distros leads me to believe that this is another consequence of arch's role as beta tester to the free software world.

The world needs a beta tester, so this is a very valuable service, but it does make life difficult for arch users who need to craft production systems. I'm an embedded systems developer and have been running arch daily since 2003, this has always been an issue. Hopefully the current landslide of arm linux devices being developed, and archlinux's many advantages in deploying small cutting edge systems will help this stability issue get the attention it has always deserved.

But i digress

On the issue of "missing driver" for the fb:
$this->bbcode_second_pass_code('', '[root@beagle johnea]# find /lib/modules/3.1.2-1-ARCH/kernel/ -name "*fb\.*"
/lib/modules/3.1.2-1-ARCH/kernel/drivers/staging/omap3-sgx/services4/3rdparty/dc_omap3430_linux/omaplfb.ko.gz
/lib/modules/3.1.2-1-ARCH/kernel/drivers/video/udlfb.ko.gz
/lib/modules/3.1.2-1-ARCH/kernel/drivers/net/ifb.ko.gz
')

Is omaplfb the kernel framebuffer driver that is missing?

$this->bbcode_second_pass_code('', '[root@beagle johnea]# modprobe omaplfb
FATAL: Error inserting omaplfb (/lib/modules/3.1.2-1-ARCH/kernel/drivers/staging/omap3-sgx/services4/3rdparty/dc_omap3430_linux/omaplfb.ko.gz): No such device')

$this->bbcode_second_pass_code('', '[root@beagle johnea]# dmesg | tail -n 2
[ 4635.661468] omaplfb: module is from the staging directory, the quality is unknown, you have been warned.
[ 4635.666076] omaplfb: OMAPLFB_Init: OMAPLFBInit failed')

from: $this->bbcode_second_pass_code('', 'http://processors.wiki.ti.com/index.php/SGXDbg#SGX_Driver_Failure_Modes_.28Installation.29')

I find this advice:
$this->bbcode_second_pass_code('', '4. If the display driver (omaplfb.ko) does not load, most likely it is because of insufficient memory allocated to the frame buffer for the required resolution and FLIP mode, or there is a real problem with registering the VSync interrupts on the platform. Post it on the E2E forum with the output of the gfx_check.sh script linked in earlier section. ')

Could this be related to vmem parameter specified at boot time?

Thanks again for help on this frame buffer issue...

johnea

[FlySnake]

Hi, android
Did you solve the problem? It seems like I have exact same issue:
$this->bbcode_second_pass_code('', 'Uncompressing Linux... done, booting the kernel.
[ 0.000000] dpll3_m2_clk rate change failed: -22
[ 0.096588] Unable to get DVI reset GPIO
[ 0.208679] _omap_mux_init_gpio: Could not set gpio192
[ 2.745483] omap_sham_mod_init: Unsupported cpu
[ 2.750396] omap_aes_mod_init: Unsupported cpu
[ 2.851196] omapfb omapfb: no driver for display
[ 2.856262] omapfb omapfb: failed to setup omapfb')
$this->bbcode_second_pass_code('', 'modprobe omaplfb
FATAL: Error inserting omaplfb (/lib/modules/3.1.0-1-ARCH/kernel/drivers/staging/omap3-sgx/services4/3rdparty/dc_omapfb3_linux/omaplfb.ko.gz): No such device')
$this->bbcode_second_pass_code('', '[ 189.060272] omaplfb: module is from the staging directory, the quality is unknown, you have been warned.
[ 189.063934] omaplfb: OMAPLFB_Init: OMAPLFBInit failed')

[kmihelich]

It could be that not enough memory is allocated to video, have you tried changing how much goes to it in your boot.scr?

[FlySnake]

I tried to add this: omapfb.vram=0:4M,1:4M,2:4M,nolock
taken here http://e2e.ti.com/support/dsp/omap_appl ... spx#226235
But without result

[android]

OK, I tried the omapfb.vram parameters FlySnake mentioned, and also increased vram to 24M prior to boot, still broken.

kmihelich: It seems that with the u-boot contained in the latest bootloader tarball the boot.scr is ignored and only uEnv.txt is read. I've been breaking out to the u-boot command prompt and tweeking parameters by hand. I need to find out if _all_ parameters need to be in the uEnv.txt, or only ones that I care to override. Also unclear on whether format of uEnv.txt should follow: "setenv var value" format as on u-boot command line, or whether it should be: "var=value" format output by printenv command.

So, at the u-boot prompt I set vram and include omapfb.vram in bootargs:
$this->bbcode_second_pass_code('', 'setenv vram 24M
setenv mmcargs 'setenv bootargs console=${console} ${optargs} mpurate=${mpurate} buddy=${buddy} camera=${camera} vram=${vram} omapfb.mode=dvi:${dvimode} omapdss.def_disp=${defaultdisplay} omapfb.vram=0:6M,1:6M,2:6M,nolock root=${mmcroot} rootfstype=${mmcrootfstype}')

I can confirm these with:
$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:1024x768MR-16@60 omapdss.def_disp=dvi omapfb.vram=0:4M,1:4M,2:4M,nolock root=/dev/sda2 rw rootfstype=ext3 rootwait')

This still yielded the: omapfb omapfb: no driver for display

I also found in the kernel source docs linux-3.1/Documentation/arm/OMAP/DSS Dated Oct 24th 2011:
$this->bbcode_second_pass_code('', '
This is an almost total rewrite of the OMAP FB driver in drivers/video/omap
(let's call it DSS1). The main differences between DSS1 and DSS2 are DSI,
TV-out and multiple display support, but there are lots of small improvements
also.

The DSS2 driver (omapdss module) is in arch/arm/plat-omap/dss/, and the FB,
panel and controller drivers are in drivers/video/omap2/. DSS1 and DSS2 live
currently side by side, you can choose which one to use.
')

This document seems to indicate that the driver omapdss needs to be loaded prior to omapfb.

I find no omapdss.ko file in the /lib/modules/ subdirectories.

I also find source files for omapfb in the drivers/video/omap2/ directory of the kernel source, but there is no module of that name in the binaries either.

It seems like a fairly major shift occurred in the driver structure, but somehow the 3.1 kernel build isn't producing the new modules.

The default parameter line passed by u-boot also includes "omapdss"

So info on OMAP bootparams here:
$this->bbcode_second_pass_code('', 'http://omappedia.org/wiki/Bootargs_for_enabling_display')

Still trying various combinations...

johnea

[kmihelich]

A lot of the omap-specific stuff isn't modularized, it's built in. You can check the kernel config through /proc/config.gz or in github. I also patch in the big rcn-ee cumulative patch for omap that adds in support for a lot of things that haven't made it to mainline yet.

uEnv.txt is the newer way to do u-boot args over boot.scr. I'm still running the older u-boot images, so I should probably double-check what I put in the bootloader packages and correct instructions appropriately. The bootloader files come from angstrom, since that's the most accessible central repository for it all (and they're the validation image for the boards), so you might find more pointers in their archives as far as boot args go, or for any special formatting for uEnv.txt.

3.1 has done a lot of big shifts, and unfortunately I just don't have enough free time in the day to get around to each and every issue on every platform. Just getting software compiled and packaged, and fixing issues with broken packages is nearly a full-time job in itself. I don't have a lot of input off-hand to the current issues here, but if one or two of you guys could "adopt" the issue to get things working, I'd really appreciate it.. and so would others finding themselves in the same situation. We don't get enough people coming by with the willingness or technical knowledge to tackle problems.

[android]

I did get uEnv.txt working.

Format matches printenv output:
$this->bbcode_second_pass_code('', '[root@beagle johnea]# cat /mnt/uEnv.txt
vram=24M
mmcroot=/dev/sda2 rw
mmcargs=setenv bootargs console=${console} ${optargs} mpurate=${mpurate} buddy=${buddy} camera=${camera} vram=${vram} omapfb.mode=dvi:${dvimode} omapdss.def_disp=${defaultdisplay} omapfb.vram=0:5M,1:5M,2:5M,nolock root=${mmcroot} rootfstype=${mmcrootfstype}')

With paramters confirmed after boot with:
$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:1024x768MR-16@60 omapdss.def_disp=dvi omapfb.vram=0:5M,1:5M,2:5M,nolock root=/dev/sda2 rw rootfstype=ext3 rootwait')

However even with the vram=24M and the omapfb.vram=0:5M,1:5M,2:5M,nolock the error at boot still persists: omapfb no driver for display.

Now I just realized, the display I have attached is only a 800x480 embedded DVI device, perhaps the default resolution is screwing things up.

I'll dig into this...

johnea

[android]

$this->bbcode_second_pass_quote('kmihelich', 'A') lot of the omap-specific stuff isn't modularized, it's built in. You can check the kernel config through /proc/config.gz or in github. I also patch in the big rcn-ee cumulative patch for omap that adds in support for a lot of things that haven't made it to mainline yet.

uEnv.txt is the newer way to do u-boot args over boot.scr. I'm still running the older u-boot images, so I should probably double-check what I put in the bootloader packages and correct instructions appropriately. The bootloader files come from angstrom, since that's the most accessible central repository for it all (and they're the validation image for the boards), so you might find more pointers in their archives as far as boot args go, or for any special formatting for uEnv.txt.

3.1 has done a lot of big shifts, and unfortunately I just don't have enough free time in the day to get around to each and every issue on every platform. Just getting software compiled and packaged, and fixing issues with broken packages is nearly a full-time job in itself. I don't have a lot of input off-hand to the current issues here, but if one or two of you guys could "adopt" the issue to get things working, I'd really appreciate it.. and so would others finding themselves in the same situation. We don't get enough people coming by with the willingness or technical knowledge to tackle problems.

[WarheadsSE]

Welcome to the ARMs' race. It might look like we're only looking at the consumer boards, but that is mostly what our users have... We get few hands on the development systems, and thanks to the market disparity in manufacturers... Oy.