Hi there! I just set up my UDOO using the minimal version of UDOObuntu v2.2.0. In the documentation, I see it is possible to disable HDMI and go headless using the web control panel or via the terminal: https://www.udoo.org/docs/Cookbook_Linux/Set_video_output.html When I try this it says: The parameter <screentype> can be: hdmi, lvds7, lvds15. Is it possible to disable HDMI, so I will have a lower energy consumption and more memory available? Thanks,
Hmm looks like some function has disappeared. Perhaps it is possible through the webcontrol page (if available on minimal Udobuntu) https://www.udoo.org/docs/Basic_Setup/Web_Control_Panel.html Else you have to search in the github repository of udooboard to recover an old version an map it to your version. https://github.com/UDOOboard?tab=repositories
The newer 3.14.56 kernel, at least, appears to watch the HDMI hot-plug sensing pin, and automatically disables HDMI output when no monitor is connected. This should save a small amount of power from the HDMI serializer circuitry not having to run, and hopefully avoiding framebuffer raster readout from the DDR RAM as well, without having to reconfigure anything. I ran a quick and dirty memory bandwidth test (dd if=/dev/zero of=/rw/256M bs=1M count=256, averaging across 20 tries while throwing out anomalously-low outlier readings) from an Udoo with and without the HDMI output enabled, and did measure a small different of about 1MByte/s between when (236.5MB/s vs 237.6MB/s, possibly too little to be outside the statistical margin of error... individual runs were in the 235-241MB/s range). This was at a low resolution and color depth, also, only 720x400x16bpp - higher-res and 32bpp should increase the overhead from video output read cycles sharing system RAM. To disable the frame-buffer device permanently, you can always manually edit your device-tree file, e.g. /boot/dts/imx6q-udoo-hdmi.dtb or /boot/dts-overlay/imx6q-udoo-hdmi.dtb (check uEnv.txt for a line reading "use_custom_dtb=true" to see which one's active - if that line's present, it looks to dts-overlay first... or watch the initial boot process via serial console for a line reading Device-Tree Go to to whichever directory under boot is being used, edit the corresponding .dts file (imx6q-udoo-hdmi.dts instead of imx6q-udoo-hdmi.dtb) and change the "status" line within the "fb@0" block towards the very end (fb = framebuffer) from status = "okay" to status = "disabled". e.g. Code: fb@0 { compatible = "fsl,mxc_sdc_fb"; disp_dev = "hdmi"; interface_pix_fmt = "RGB24"; mode_str = "720x400M@70"; default_bpp = <0x20>; int_clk = <0x0>; late_init = <0x0>; status = "disabled"; // rather than "okay" }; Then do Code: dtc -I dts -O dtb imx6q-udoo-hdmi.dts >imx6q-udoo-hdmi.dtb to rebuild the .dtb (binary) version of this file. I'd make backups of both the .dts and .dtb first (stored outside of /boot), just in case something gets messed up. This effectively disables the video console, but doesn't prevent 8 to 16MB of RAM from being allocated for it, if you check the discrepancy in "free" between the amount shown (1031988 for me) vs. 1024*1024=1048576 for a full 1GB. I think this is due to the frame buffer being initialized within the U-Boot bootloader -- this is when the full-screen UDOO logo appears, at a hardcoded 1024x768 resolution -- before the kernel if even loaded, or has a chance to read your .dtb device tree. It should be possible to deactivate framebuffer initialization within U-Boot to recover that memory, but I haven't yet discovered how.
I forgot to mention that in the 'dd' memory-bandwidth test above, of course /rw is mounted as a ramdisk (tmpfs).
