Which /dev/videoN and other things

Attached is a console log of booting and other things.  This will help you see some stuff during boot.  The debug output near the bottom is slightly obsolete vs my post above.

Hi,

It looks like Video device node is not created for the display driver. I looked in the log and it says that subdev registration in failed. I think you will require to add your device in supported sub device for the display driver. Please go through LinuxKernel/arch/arm/mach-davinci/board-dm646x-evm.c to get the adea about how to add a new sub device for the display?

Thanks,

Brijesh Jadav

Thanks, Brijesh.  I'm looking into your advice now.

At the same time, I discover two things.  Having learned about "dmesg", here's a snippet of its output:

Linux video capture interface: v2.00
vpif_display vpif_display: channel=ce173000,channel->video_dev=ce173000
vpif_display vpif_display: channel=ce173400,channel->video_dev=ce173400
ths7303 1-002c: chip found @ 0x58 (DaVinci I2C adapter)
ths7303 1-002c: ths7303 write failed
ths7303: probe of 1-002c failed with error -121
vpif_display vpif_display: Error registering v4l2 subdevice
vpif_display vpif_display: VPIF IRQ request failed
tvp514x 1-005d: tvp514x 1-005d decoder driver registered !!
vpif_capture vpif_capture: registered sub device tvp514x-0
tvp514x 1-005c: tvp514x 1-005c decoder driver registered !!
vpif_capture vpif_capture: registered sub device tvp514x-1
vpif_capture vpif_capture: DM646x VPIF Capture driver initialized

First, I see no mention of the ADV7171 (ADV7170 driver).  I also see the error related to V4L2.

Second, it's trying to handle a THS7303.  There is no such chip on my board.  It lies when it says it found it at I2C address 0x58.  Nothing on my board uses that address.  Furthermore, when I make the Kernel, somebody somewhere is insisting on configuring IN this THS7303.  Specifically, I've cloned davinci_dm646x_1ghz_defconfig and REMOVED the THS7303 and other drivers, while ADDING the ADV7170 and TVP514X drivers.  I then run "make ARCH=arm davinci_dm646x_1ghz_defconfig".  This says it creates .config.  I look at .config in the git folder.  Sure enough, ADV7170 has been added.  But so has THS7303.  Who is insisting on this?  I edit that .config and then run "make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- uImage".  The .config gets rewritten and the THS7303 has returned.

How do I get rid of this THS7303?  Or, alternatively, where is it coming from such that I need a different "top end entry point" for my edits?  Note ncurses not running.

...and I'll now follow up with your advice in parallel, Brijesh.

Brijesh et al.,

A quick search for "subdev" in my boot log reveals that this is also referring to the non-existent THS7303.  So getting rid of the THS7303 inclusion should eliminate this error.  How do I get rid of the THS7303 inclusion?

At the same time, note I was unaware of the existence of board-dm646x-evm.c, and certainly unaware of its purpose.  I thought I could just modify the config and the ADV7170 driver for the ADV7171 chip would get included in the kernel.  I'm wondering if now I need to do something with board-dm646x-evm.c (actually, with a renamed clone of it) in order to do what I need.  In fact, I believe this is what you meant when you wrote "to get the adea about how to add a new sub device for the display".  So, please give me some added context.  For example, when is this code executed, at kernel build time or at kernel load time or at some other time?  Also, where does the file name get referenced, so that I can make my kernel build use my alternate file name -- after all, my board is NOT the dm6467x evm, it's something else.  So I ought to have a board-myboard.c file or such.  How do I make my kernel build use board-myboard.c instead?  

[EDIT:] I see in board-dm646x-evm.c that the THS7303 reference is missing the surrounding "#if defined(CONFIG_VIDEO_THS7303)" that I infer should be there.  This could be why the THS7303 won't go away. [[EDIT: nope]]  I'm adding the ifdef now to board-myboard.c, but don't yet know how to make the make use my .c instead of the other.  I also see the I2C address, which is surely important for me to provide to the Kernel SOMEWHERE!  (Hey, it could have been assuming one of only two possibles for the chip.)

[EDIT:] Note I backed up and modified board-dm646x-evm.c, then rebuilt the kernel.  board-dm646x-evm.o got a new date, so I think it got included in the process.  Installed kernel in my NAND memory.  Booted.  boot log didn't really change.  It still mentions THS7303 because .config still has it and I can't figure out how to get rid of it.  Also, board-dm646x-evm.c now has code for the ADV7170.  However, the boot log showed no reference to ADV7170.  I would think that it would, if the kernel were built correctly...

[Look back at forum for continued edits to this particular post.  Trust that the email copy you may receive is out of date]

Thanks,

Helmut

Our design is based on the DM365 EVM and I had to make a new kernel machine configuration for our board.  Some of the chips we didn't put on our board are still being used by the DM365EVM regardless of what you enable/disable in the configuration.  The only way to get rid of code talking to the chips was to create a new machine type for our board and cull out the chips we didn't use.

John A

Thanks, John.  I'll try to avoid following your good but complex advice as long as I can :) !  It may be OK to "fail" configuring the THS7303.  I'm still worried about getting it to even TRY the ADV7170.  Do you think I have to create a new machine type for that, to ADD a chip, as well?

With that said, any links or advice you can provide on what "create a new machine type" entails?

Thanks again,

Helmut

I posted a thread on it....

http://e2e.ti.com/support/embedded/f/354/p/63857/229924.aspx#229924

John A

Thx.  I read thru it and will work on it tomorrow.  

In the mean time, I notice item #4 provides a folder but seems to be missing the filename.

Also, I don't actually see how this relates to including or excluding any chips, aside from making edits to board-myboard.c instead of, in my case, board-dm646x-evm.c.  Am I missing something?

The missing filename is Makefile.

Yes, you're right that it mostly relates to editing up "board-myboard.c", but there are items in there that relate to chips that aren't on our board.  You're using a completely different platform so I can't say if it's the same for you.  But if you do want to make a kernel type specifically for your board, it's a useful starting point.  You can also get a machine type number assigned to your board.

John A

John,

I'm still trying to get going.  I haven't made a custom machine, because I'm sure things ought to work [at least tentatively] by modifying the existing machine.  But I still can't get the kernel to output boot log info regarding my ADV7171 chip or ADV7170 driver.  

I'm wondering if I need to modify u-boot for this.  The post to which you referred earlier mentioned updating u-boot.  How do you do this?

Related posts: 

http://e2e.ti.com/support/embedded/f/354/p/96975/338570.aspx#338570

http://e2e.ti.com/support/embedded/f/354/p/96970/338556.aspx#338556

Thanks,

Helmut

You probably don't need to modify u-boot.  I needed to because I created my own machine code number to go with the kernel machine type for my board.  I also had to modify u-boot to set the PLLs for the DM368.  And we are using a different ethernet phy, so I had to make a change there.

U-boot is located in the psp directory for dvsdk 4 and can be made from the top level make.

I noticed in your link that you had trouble with ncurses on ubuntu.  I can't remember if I had the same problem or not.  I know I've installed a lot of required stuff and sometimes it's a pain where it keeps saying it needs more stuff.  I use "make xconfig" to setup my config file.  You could try that as an alternative.

John A

Thanks, John, but I still can't get there.  I'm using DVSDK 3 and have a folder called dvsdk_3_10_00_11.  Beneath it, I find no folder with "psp" in the name.  Am I looking in the wrong place?

[EDIT:] Searching all of dvsdk (includes ver 2 also), there's not a single file with 'psp' in it.

Unfortunately, I can't help you with that one.  That's why I always put what version dvsdk I'm using in my posts.  I worked a little with version 2 and then jumped past 3 to 4.  And I didn't get around to the board specific stuff until I got to 4.

John A

Helmut,

I just checked DVSK 4.01 is not supported for dm6467t.  Just FYI http://processors.wiki.ti.com/index.php/DVSDK_4.x_FAQ

I can never find the PSP references either (using same part and dvsdk as you...)

John,

I found u-boot source (ref http://e2e.ti.com/support/embedded/f/354/p/96389/338638.aspx#338638)

But I don't see where I might CAUSE my configured ADV7170 driver to actually get used by the kernel.  Do you mind looking at your source and see if you see if u-boot is at all responsible for causing a kernel driver to be used?  The more I think about it, it seems u-boot ought to only decompress and then invoke the kernel.  It should be the kernel itself that's in charge of deciding what drivers it has and what to do with them.  In this case, trying to modify u-boot is simply barking up the wrong tree.  Remember, I configured ADV7170 driver, but kernel boot log doesn't mention it.  Is it quiet, or is something wrong?

-Helmut

I don't think that the video output would be configured in u-boot.  I only mentioned u-boot wrt loading a machine type specific to your custom board.  But you are not even at that point now.

There is a tool called i2cdetect that can scan the i2c bus and reports responsive addresses.  You can cross compile 12c-tools to get it.  At least you can talk to the chip and make sure the board is designed correctly and working.  So far it sounds like you've done the things you are supposed to do.  But I'm in the same boat as you.  I have to do a lot of code searching and experimentation to figure out how to get things to work.  Hope you have a good file search tool.:)

John A

Thanks very much, John.  I'll keep in mind the i2cdetect thing.  With all the backtracking and installing, it's always a judgement call about whether or not a particular avenue is worth the effort.

Right now, regardless of whether or not my board is working, I've established pretty much for sure that I need to break the "THS7303 Conspiracy".  If you're interested (please), take a look at my last post to http://e2e.ti.com/support/embedded/f/354/p/96975/338680.aspx#338680.  I feel that I *MUST* resolve this regardless.  If I can and suddenly my video output works, then I will have not needed to spend the time on i2cdetect.  If I can and suddenly my video output doesn't work, then I'll very likely need to spend time on i2cdetect.  If I can no [break the THS7303 Conspiracy", then I may be looking for a new job...

-Helmut

Brandy, thanks.  No longer germane.  Please see http://e2e.ti.com/support/embedded/f/354/p/96975/338680.aspx#338680

Brandy, you're using the same part and DVSDK as me?  We should keep in touch and help each other.  Maybe the way to do that is as "friends" on this forum, a feature I've never used before.  I have pretty much all my coding done, with boards designed and in hand.  Now I'm fighting the linux kernel config demon to get it to talk to my ADV7171 chip.

-Helmut

Resolved which /dev/videoN = /dev/video2

Ref http://e2e.ti.com/support/embedded/f/354/p/97229/339787.aspx#339787

This was AFTER hard coding some kernel files to get around the THS7303 conspiracy, still unresolved.  (ref http://e2e.ti.com/support/embedded/f/354/p/97004/338846.aspx#338846 )