Before I run “make … zImage” I opened the .config file and enabled LVDS as the above post suggests (set CONFIG_TEGRA_LVDS=y and comment out CONFIG_TEGRA_DP). But I got an error in the build process.
The error is the following:
In file included from /home/filippos/Downloads/kernel/drivers/video/tegra/dc/dc_priv_defs.h:26:0,
from /home/filippos/Downloads/kernel/drivers/video/tegra/dc/dc_priv.h:23,
from /home/filippos/Downloads/kernel/drivers/video/tegra/dc/lvds.c:23:
/home/filippos/Downloads/kernel/include/linux/clk.h:345:20: warning: conflicting types for ‘clk_disable_unprepare’ [enabled by default]
static inline void clk_disable_unprepare(struct clk *clk)
^
/home/filippos/Downloads/kernel/include/linux/clk.h:345:20: error: static declaration of ‘clk_disable_unprepare’ follows non-static declaration
In file included from /home/filippos/Downloads/kernel/drivers/video/tegra/dc/lvds.h:20:0,
from /home/filippos/Downloads/kernel/drivers/video/tegra/dc/lvds.c:22:
/home/filippos/Downloads/kernel/drivers/video/tegra/dc/sor.h:185:2: note: previous implicit declaration of ‘clk_disable_unprepare’ was here
clk_disable_unprepare(sor->sor_clk);
I am guessing I am missing some other option I need to enable in the config file??? I really don’t know…
By the way I have gone through all the Makefiles in the kernel src directory and removed the -Werror option so its not those warnings that cause the error.
Any help would be greatly appreciated. If needed I can post the config file too.
This may or may not be related, but often changing one kernel config requires alterations in others. Editing “.config” directly could cause issues. Using apps designed for configuration editing (such as “make menuconfig”) would guarantee that you are not missing related edits.
Additionally, the article is cross compiling, which complicates things. Try compiling on Jetson itself without cross compiling (make menuconfig requires package libncurses5-dev, otherwise Jetson already has everything it needs to build the kernel). If you still have an error after that, the error messages will be more significant.
I run “make menuconfig” as you suggested but couldn’t find anything obvious there. Then I did a search for “TEGRA_LVDS” in menuconfig and it found the option which it claims is in “Device drivers->Graphics Support” but again, I couldnt find anything obvious there either.
According to the search result in menuconfig again, the option TEGRA_LVDS depends on HAS_IOMEM=y and ARCH_TEGRA=n.
So I went and edited the .config file manually again and set LVDS to yes and the above dependencies to what is suggested in menuconfig. Setting ARCH_TEGRA to no though, looks like its breaking a LOT of thing that depend on this option being set to yes…
This is getting a bit frustrating and its first time I actually try to mess with kernels.
Perhaps it is a typo, but I see in menuconfig TEGRA_LVDS depends on ARCH_TEGRA=y, but you mention it as “n”. I’m in menuconfig “Device Drivers/Graphics support/Enable LVDS panel” help. Option “Enable LVDS panel” is off by default, “Enable eDP panel” is on by default.
To test, I started with the /proc/config.gz of a running, unmodified stock R21.4 kernel. I used menuconfig to set “Enable LVDS panel” to “y”, and used menuconfig to turn off “Enable eDP panel”. I changed “Local version” to “-gdacac96_lvds” (avoids module overwrites of the install I’m trying to avoid actually touching). The following was run on native Jetson compile:
make mrproper
cp /proc/config.gz .
gunzip config.gz
mv config.gz .config
# In make menuconfig:
# First step in make menuconfig was to load .config
# Update Local version
# Disable eDP
# Enable LVDS
make menuconfig
make -j4
Compile is verified as failed. I’ll see what I can find out about this issue.
EDIT: Confirmed option change to CONFIG_TEGRA_DP (eDP) is unrelated. Enable of CONFIG_TEGRA_LVDS triggers the issue.
Needs to be confirmed, but it looks like the fix is to edit:
drivers/video/tegra/dc/sor.h
// Insert into line 21:
#include <linux/clk.h>
Note that this compiles and boots, but I have no eDP nor LVDS hardware. Boot edit included using the dts file from here, renamed to not overwrite the default version:
Thanks for the reply linuxdev. I did everything you mention but now I’m getting another error… I’ve tried building on the board itself as well as cross compiling on my linux host and I get the same errors in both. The error is this:
drivers/built-in.o: In function `nvhost_syncpt_deinit_timeline':
/home/filippos/Downloads/kernel/drivers/video/tegra/host/nvhost_syncpt.c:1045: undefined reference to `sync_timeline_destroy'
/home/filippos/Downloads/kernel/drivers/video/tegra/host/nvhost_syncpt.c:1052: undefined reference to `sync_timeline_destroy'
drivers/built-in.o: In function `add_sync_waits':
/home/filippos/Downloads/kernel/drivers/video/tegra/host/host1x/host1x_channel.c:139: undefined reference to `sync_fence_put'
drivers/built-in.o: In function `nvhost_sync_fdget':
/home/filippos/Downloads/kernel/drivers/video/tegra/host/nvhost_sync.c:286: undefined reference to `sync_fence_fdget'
/home/filippos/Downloads/kernel/drivers/video/tegra/host/nvhost_sync.c:298: undefined reference to `sync_fence_put'
drivers/built-in.o: In function `nvhost_sync_pt_dup_inst':
/home/filippos/Downloads/kernel/drivers/video/tegra/host/nvhost_sync.c:167: undefined reference to `sync_pt_create'
drivers/built-in.o: In function `nvhost_sync_fence_set_name':
/home/filippos/Downloads/kernel/drivers/video/tegra/host/nvhost_sync.c:384: undefined reference to `sync_fence_put'
drivers/built-in.o: In function `nvhost_sync_create_fence':
/home/filippos/Downloads/kernel/drivers/video/tegra/host/nvhost_sync.c:458: undefined reference to `sync_fence_merge'
/home/filippos/Downloads/kernel/drivers/video/tegra/host/nvhost_sync.c:459: undefined reference to `sync_fence_put'
/home/filippos/Downloads/kernel/drivers/video/tegra/host/nvhost_sync.c:460: undefined reference to `sync_fence_put'
drivers/built-in.o: In function `nvhost_sync_pt_create_inst':
/home/filippos/Downloads/kernel/drivers/video/tegra/host/nvhost_sync.c:142: undefined reference to `sync_pt_create'
drivers/built-in.o: In function `nvhost_sync_create_fence':
/home/filippos/Downloads/kernel/drivers/video/tegra/host/nvhost_sync.c:448: undefined reference to `sync_fence_create'
drivers/built-in.o: In function `nvhost_sync_pt_create_inst':
/home/filippos/Downloads/kernel/drivers/video/tegra/host/nvhost_sync.c:149: undefined reference to `sync_pt_free'
drivers/built-in.o: In function `nvhost_sync_create_fence':
/home/filippos/Downloads/kernel/drivers/video/tegra/host/nvhost_sync.c:478: undefined reference to `sync_fence_put'
/home/filippos/Downloads/kernel/drivers/video/tegra/host/nvhost_sync.c:450: undefined reference to `sync_pt_free'
drivers/built-in.o: In function `nvhost_sync_create_fence_fd':
/home/filippos/Downloads/kernel/drivers/video/tegra/host/nvhost_sync.c:416: undefined reference to `sync_fence_put'
/home/filippos/Downloads/kernel/drivers/video/tegra/host/nvhost_sync.c:411: undefined reference to `sync_fence_install'
drivers/built-in.o: In function `nvhost_sync_timeline_create':
/home/filippos/Downloads/kernel/drivers/video/tegra/host/nvhost_sync.c:351: undefined reference to `sync_timeline_create'
drivers/built-in.o: In function `nvhost_sync_pt_signal':
/home/filippos/Downloads/kernel/drivers/video/tegra/host/nvhost_sync.c:375: undefined reference to `sync_timeline_signal'
/home/filippos/Downloads/kernel/drivers/video/tegra/host/nvhost_sync.c:375: undefined reference to `sync_timeline_signal'
drivers/built-in.o: In function `tegra_dc_ext_pin_windows':
/home/filippos/Downloads/kernel/drivers/video/tegra/dc/ext/dev.c:790: undefined reference to `sync_fence_fdget'
drivers/built-in.o: In function `tegra_dc_ext_set_windowattr':
/home/filippos/Downloads/kernel/drivers/video/tegra/dc/ext/dev.c:414: undefined reference to `sync_fence_wait'
/home/filippos/Downloads/kernel/drivers/video/tegra/dc/ext/dev.c:415: undefined reference to `sync_fence_put'
drivers/built-in.o: In function `gk20a_channel_syncpt_wait_fd':
/home/filippos/Downloads/kernel/drivers/gpu/nvgpu/gk20a/channel_sync_gk20a.c:127: undefined reference to `sync_fence_put'
/home/filippos/Downloads/kernel/drivers/gpu/nvgpu/gk20a/channel_sync_gk20a.c:158: undefined reference to `sync_fence_put'
/home/filippos/Downloads/kernel/drivers/gpu/nvgpu/gk20a/channel_sync_gk20a.c:137: undefined reference to `sync_fence_put'
make: *** [vmlinux] Error 1
Undefined references… I then grep’d those undefined and found that they re actually defined in ./drivers/staging/android/sync.c which looks weird to me cause I am not building for android. Again, I did exactly the steps you suggested, same order, edited the code in that file but nah… no luck.
Do you have a list of kernel config option differences between what the errors are from and what an unmodified kernel has? This would allow me to reproduce the error.
FYI, there’s a lot of code which is shared between all kinds of hardware and variants. References to other boards such as android or ardbeg are common.
OK I got it building. I went and set the ANDROID option to ‘yes’ in menuconfig and it built.
Now to flash it…
I copied the produced zImage file into JetPackTK1-1.2/Linux_for_Tegra/kernel and then run ./flash.sh -k 6 jetson-tk1 mmcblk0p1 but that failed (I think…) with the following error:
RCM communication completed
downloading bootloader -- load address: 0x83d88000 entry point: 0x83d88000
sending file: fastboot.bin
- 594363/594363 bytes sent
fastboot.bin sent successfully
waiting for bootloader to initialize
bootloader downloaded successfully
file not found: boot.img
failed executing command 2147483647 NvError 0x4
partition download failed
Failed to flash ardbeg.
So I read a few things here and there and saw that depending on the bootloader you are using you’d have to do this differently. So I saw that R21.4 uses u-boot apparently which just needs the zImage and dtb file copied in /boot and that’s all. Can you confirm that linuxdev?
So I did copy zImage and dtb file in /boot, rebooted the board, got the ubuntu desktop on my HDMI screen and voila!.. LVDS still doesn’t work :(
I’m guessing it is running the kernel I built manually since I renamed the old zImage and dtb files that were in /boot, and copied mine in there…
U-boot looks for a file directly in /boot, so it is generally sufficient to just copy zImage to /boot. There are generally other recommendations to preserve the original zImage and related files with a combination of renaming files after “uname -r” and setting of CONFIG_LOCALVERSION with some custom name. Regardless of using fastboot or u-boot you still need “make modules_install”…if CONFIG_LOCALVERSION is used/edited this preserves the previous module directory.
For reference, the default kernel in R21.4 is version 3.10.40, with CONFIG_LOCALVERSION set to “-gdacac96”, causing “uname -r” to respond as “3.10.40-gdacac96”. This places modules in “/lib/modules/3.10.40-gdacac96” (incidentally, the “extras” subdirectory there is added from the “apply_binaries.sh” script).
An example CONFIG_LOCALVERSION to preserve things in R21.4 would be “-gdacac96_1”, which would place modules in “/lib/modules/3.10.40-gdacac96_1”. In that example you might rename zImage and the dtb with “3.10.40-gdacac96_1” in their names, e.g., “zImage-3.10.40-gdacac96_1”. An alternate entry can then have this name in /boot/extlinux/extlinux.conf and leave the original in place. The original “/lib/modules/3.10.40-gdacac96/extras” could be copied into the 3.10.40-gdacac96_1 variant.
uname -r returns 3.10.40-gdacac96_lvds so I guess that verifies that its installed it properly. Also I’m getting a weird freeze every few minutes, which I wasn’t getting before, so I guess that’s another indication that I’m using a custom kernel.
I copied my kernel sources to the board and did a make modules and make modules_install too just to be sure.
I still get nothing on the LVDS screen though… I don’t know what else to do. Could it be that my hardware is dodgy? I’ll check that next.
So far as LVDS goes, I’m not sure what all of the requirements are. It would probably help to post the model/specs of the actual hardware being used, as well as whether there is anything on the HDMI.
The LVDS monitor model is this: G185XW01 from AU Optronics. Our hardware department guys wired it up for me according to the schematic found here: 602-7R375-0000-D00.Schematics.Rev.4.02.pdf.
I have a monitor connected to HDMI too, which works fine of course. Is that related in any way?
I’m not certain of everything which by default is shared between HDMI display and other displays, but some of the difficulties people have had in the past were tied to having two displays where some limitation of one display prevented the other display from working correctly. I’m not saying that this is what is happening to you, but it is a possibility that if all settings of both displays are the same then odds of success would go up (then you could work on details of which parameter fails).
I’m still struggling here with this. I followed your instructions about the extlinux.conf file and added another label in there. But I’m not getting any options on boot-up to choose from. Still managed to boot the custom kernel though by making it the primary label in that file.
I have been building it on the target board these days cause for some reason I only get all tegra related options in menuconfig when I build it on the target board (regardless of whether I copy the config.gz to the host or not). So I just stick to building it natively.
So what I do is:
make -j4
make modules
make modules_install
Which installs the modules in the /lib/modules/my_custom_version folder. I then copy the “extra” folder in there from the original modules folder and boot and it all looks good.
The question is though, since I choose “enable lvds” in the menuconfig and it is supposed to be a driver, why am I not seeing anything related in the modules folder?
I mean if I cd into /lib/modules/my_version/kernel/drivers/video all I can see is a folder called “tegra/host/vi” and in there just one file called nvhost-vi.ko. Shouldn’t there be something related to lvds in there? I would expect a .ko file in there but can’t find anything related? Am I totally wrong in this?
Serial console is required to see and select u-boot options (regular video monitor and keyboard can’t do this), and continues boot just a few seconds after the option is offered unless you interrupt by hitting a key. Using serial console vastly simplifies boot loader size, as it doesn’t require video support to do this.
Here’s an example of what one of my custom u-boot menus looks like:
U-Boot 2014.10-rc2-00002-g105d2f3 (Jun 25 2015 - 15:19:50)
TEGRA124
Board: NVIDIA Jetson TK1
I2C: ready
DRAM: 2 GiB
MMC: Tegra SD/MMC: 0, Tegra SD/MMC: 1
*** Warning - bad CRC, using default environment
tegra-pcie: PCI regions:
tegra-pcie: I/O: 0x12000000-0x12010000
tegra-pcie: non-prefetchable memory: 0x13000000-0x20000000
tegra-pcie: prefetchable memory: 0x20000000-0x40000000
tegra-pcie: 2x1, 1x1 configuration
��Ʌ�������ɽ��������с�b�ͥ����b����5R�tegra-pcie: link 0 down, retrying
tegra-pcie: link 0 down, retrying
tegra-pcie: link 0 down, retrying
tegra-pcie: link 0 down, ignoring
tegra-pcie: probing port 1, using 1 lanes
In: serial
Out: serial
Err: serial
Net: RTL8169#0
Warning: RTL8169#0 using MAC address from net device
Hit any key to stop autoboot: 0
MMC: no card present
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
4607 bytes read in 98 ms (45.9 KiB/s)
Jetson-TK1 eMMC boot options
1: primary kernel
2: debug1
3: noEDP_plusLVDS
4: SD Card
5: read-only primary kernel
6: usb3
Enter choice: 2
2: debug1
Retrieving file: /boot/zImage-3.10.40-gdacac96_dbg1
5884712 bytes read in 196 ms (28.6 MiB/s)
If you hit a key too early, you can continue by entering “boot”. Once you see the numbered kernel selection items, a number can be used to pick the correct one. In the above example hitting the “3” key picks “noEDP_plusLVDS” which I used for testing.
FYI, not all kernel options are built as modules. Most are built in and live in the kernel image itself (zImage), not in a module. In make menuconfig the “*” means it is built into the kernel, “M” means it is a module. Some features also have module names which don’t match the menuconfig item; some features are a subset of a module and exist in the module and the module is named after the parent feature. LVDS is only available integrated into the kernel and does not have the ability to be installed as a module.
Depending on settings, there is a limit to how much module memory can be used, so it is a good idea to conserve and integrate into the kernel anyway. On ARMv7 (such as Jetson) module space plus initrd space cannot exceed 32MB. That 32MB max is subdivided, depending on options, as either 24MB module + 8MB initrd, or 16MB module + 16MB initrd. Default for L4T is to allow 16MB of module space and 16MB of initrd.