I created and compiled a DT overlay based on cape-bone-dvi-00A0.dts. I can load the overlay at runtime (echo cape-bone-sundvi > /sys/devices/bone_capemgr.9/slots), and it works). But when I try to get it installed automatically via capemgr.enable_partno the kernel refuses to load it.
The output of “dmesg | grep capemgr” after the overlay is installed. You can see that it was not loaded on startup, but no reason seems to be reported. It did load successfully when the system was fully operational. Here is the full dmesg.
I tried using the priority setting (capemgr.enable_partno=BB-UART1,cape-bone-sundvi:00A0:10), removing other overlays, etc to no avail. The HDMI drivers are disabled so there shouldn’t be a conflict. The stock DVI cape cape-bone-dvi-00A0.dtbo seems to autoload without any apparent problems).
What is really strange, even when I simply copy the original cape-bone-dvi-00A0.dtbo into another name (cape-bone-sundvi-00A0.dtbo), and specify this new name in the uEnv.txt, it no longer auto-loads! The very same binary file, only with another name. So the name of the dtbo seems to make a difference. I thought maybe the overlays must be listed in the main DT, in the list of capes. But I don’t see the BB-I2C1 or BB-UART1 listed anywhere, and they load with no problem.
I am sure it’s something simple that I missed, but I am really having a hard time seeing what it is.
I guess, I should have realized that the filesystems get mounted only after the DT overlays are loaded. So only the DT overlays linked directly into the kernel image (as part of the kernel build) are available at startup time. Well, this sucks, but at least I know what to do now.
Yeah, I was thinking about something like this. But since I am making a video controller overlay, it is better if it had been loaded at kernel initialization, and not as part of the init scripts. I’d like the display to be available to show some kernel startup. So I will either just overwrite the cape-bone-dvi-00A0.dts with my own stuff (and make a custom Sunhillo-only patch), or will add a new overlay to KERNEL/firmware/Makefile.
It seems that a lot of people got confused by this issue (long discussion here). The problem is, the available documentation for 3.8 kernel seems to imply that the /lib/firmware overlay files are available for startup load, so it would be helpful if qualification was added.
No, I definitely cannot afford any more bootup delay. I am already not meeting my 25 second startup requirement, and I have to figure out why. The dmesg is not much help, but it seems that the init scripts are too heavy.
I wish I could say the DVI overlay worked, but it doesn’t. It loads fine, and I get the login prompt at the monitor, so basically the tfp410 driver seems to work. But the X-Server unloads claiming it can find no acceptable modes. Here is the the Xorg.0.log.
[ 136.094] (II) modesetting(0): Supported detailed timing:
[ 136.094] (II) modesetting(0): clock: 108.0 MHz Image Size: 338 x 270 mm
[ 136.095] (II) modesetting(0): h_active: 1280 h_sync: 1328 h_sync_end 1440 h_blank_end 1688 h_border: 0
[ 136.095] (II) modesetting(0): v_active: 1024 v_sync: 1025 v_sync_end 1028 v_blanking: 1066 v_border: 0
[ 136.095] (II) modesetting(0): Ranges: V min: 56 V max: 75 Hz, H min: 31 H max: 81 kHz, PixClock max 145 MHz
[ 136.095] (II) modesetting(0): Monitor name: LCD175M
[ 136.096] (II) modesetting(0): Serial No: 3X556306NA
[ 136.096] (II) modesetting(0): EDID (in hex):
[ 136.096] (II) modesetting(0): 00ffffffffffff0038a3cb6701010101
[ 136.096] (II) modesetting(0): 2917010308221b78ea3095a6554b9a25
[ 136.096] (II) modesetting(0): 125054bfef80714f814f010101010101
[ 136.097] (II) modesetting(0): 010101010101302a009851002a403070
[ 136.097] (II) modesetting(0): 1300520e1100001e000000fd00384b1f
[ 136.097] (II) modesetting(0): 510e000a202020202020000000fc004c
[ 136.097] (II) modesetting(0): 43443137354d0a2020202020000000ff
[ 136.098] (II) modesetting(0): 0033583535363330364e410a2020000a
[ 136.098] (II) modesetting(0): No remaining probed modes for output DVI-0
[ 136.098] (II) modesetting(0): Output DVI-0 connected
[ 136.098] (WW) modesetting(0): Unable to find initial modes
[ 136.098] (EE) modesetting(0): Output DVI-0 enabled but has no modes
[ 136.099] (EE) modesetting(0): No modes.
[ 136.099] (II) UnloadModule: "modesetting"
[ 136.100] (EE) Screen(s) found, but none have a usable configuration.
[ 136.100] (EE)
Fatal server error:
[ 136.100] (EE) no screens found(EE)
[ 136.101] (EE)
Please consult the The X.Org Foundation support
at http://wiki.x.org
for help.
[ 136.101] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
[ 136.102] (EE)
[ 136.194] (EE) Server terminated with error (1). Closing log file.
Without the X server working the whole exercise seems pretty pointless…
Weirdly, if I don’t hook up the I2C1 (i.e. just use the included cape-bone-dvi-00A0.dts, I get somewhat better results. The X server starts up and stays up, but the default resolution of 1152x864 is not supported by my VGA monitors. I can xrandr -d :0 -s 1024x768 and get the picture. But it seems like the wrong way to go about it. xrandr offers a few options, but without I2C1 the EDID from the monitor is not read.
I also tried forcing resolution by specifying the LCD-cape-like tilcdc panel, but this would lock me into one particular type of monitor, so that’s not good either.
