New dm6467T (dm6467) board, [EDIT] ISSUES regarding with and without T

Srirami,

Acknowledge item 2 (dm6467 without T).

FYI, using wrong ubl/u-boot (for dm6467T) I have bi-directional communication with u-boot over RS232 working.  

I'm tempted to move forward with wrong ones (for dm6467T), but I guess I'll back up, search web for correct ones (for dm6467), and reprogram with those.

Note that as soon as I get the evm kernel working, I'll likely have to put my own kernel in anyway, to support my NTSC I/O, which includes ADV7171.  I'm pretty sure that's not in the evm kernel, but I have already found the driver in "git" folder tree and in the config (invoked with CONFIG_VIDEO_ADV7170).

Hmmm... Now I have some questions.  Let's see if I can get this correct.

I find in git/arch/arm/configs folder both davinci_dm646x_1ghz_defconfig and davinci_dm646x_defconfig.  I've built a kernel with the former already (davinci_dm646x_1ghz_defconfig), but it seems I'm going to need to build one with the latter now (davinci_dm646x_defconfig).  I find CONFIG_VIDEO_ADV7170 available in both.  So I believe I can just make a kernel with each config, the latter to be used now and the former to be used when I have actual DM6467T chips.  correct?

Next, I have a custom codec and application compiled already under dvsdk_3_10_00_11.  It was a real pain to get the makefiles working.  I guess I'll try a wholesale copy of my folders from here to a similar place under a DVSDK2.x folder.  Then rebuild and hope for the best.  If that works, it should be what I need.  correct?

Then, back on ubl and u-boot, use the non-T versions.  Thus in total, I have non-T versions of ubl, u-boot, uImage (kernel), application & codec.

[EDIT] NOTE: I FIND http://arago-project.org/files/releases/davinci-psp_3.x.0.0-r37/images/dm6467-evm/ WITH JUNE 2010 DATES.  I THINK THIS LOOKS LIKE A GOOD SOURCE.

FYI, I've retitled this thread to "New dm6467T (dm6467) board, [EDIT] ISSUES regarding with and without T" so that my most recent post becomes germane to the thread title. This thread may be valuable to others who also solder a dm6467 to a board really intended for dm6467T, just because of chip availability.  Note there's a migration guide somewhere called SPRAB44.  (Well, I don't find it on a TI website, but I do find it at http://www.embeddeddesignindia.co.in/STATIC/PDF/201003/EDIOL_2010MAR19_ESL_AN_01.pdf?SOURCES=DOWNLOAD )

Srirami et al.:

I'm having trouble getting CCS to connect properly again.  This could be deterioration in my JTAG pinout fixup wiring, or something else.  I'm also looking at a BIG demo deadline coming up.

This is something I can perhaps address AFTER the demo.  Right now, UBL and U-Boot for the DM6467T appear to be working sufficiently on my T-intended board with non-T DM6467 soldered to it.  In fact, the non-T intended UBL or U-Boot mentions a slower ARM speed.  But my serial port is working correctly, and I don't recall a separate baud clock. Without spending the time to look further, it might even be the case that what I have is correct anyway.

Regardless, it seems that once the kernel begins loading, neither UBL nor U-Boot matter anymore.  Furthermore, the kernel and my NAND-based file system should come over via an Internet connection, not through CCS.  Therefore, I'm thinking I could count my blessings, forget about CCS for now, and move on to testing the Internet circuitry and connection, plus further programming the NAND with kernel and FS.

Furthermore, I've analyzed the kernel configs for davinci_dm646x_1ghz_defconfig and davinci_dm646x_defconfig.  There difference is trivial, being constrained to 8 or 9 lines that deal with video encoder [decoder] selection and USB configuration.  I have but don't need USB yet.  I'll be replacing the video encoder selection stuff anyway, to support my NTSC I/O. Therefore, it actually doesn't matter which of those configs I start with.  So I'll stick with davinci_dm646x_1ghz_defconfig, that's I've worked with already, and then go make my video encoder [decoder] selection modifications.

THEREFORE, I think I'm just going to press on forward.  That is, test Internet, program to NAND kernel and FS.  Redo this a few times to get my kernel correct and my application properly prepared for dealing with NTSC rather than the DM6467T EVM's high def, and then go demo.

Please tell me if you see any problems with this plan.

Thanks,

Helmut

FYI, using wrong UBL/U-boot (with T) working so far.  Have bi-dir serial comm.  Have network working.  Have kernel in NAND as well via network and tftpboot.  Kernel not yet finding file system...  So it seems using the wrong UBL/U-boot in the context of this thread is OK.

Helmut,

Some one from our Linux team will respond to your questions.

Regards, Srirami.

FYI, just a few minutes ago I got my custom board running Linux successfully with NFS over on a Ubuntu/VMware host.  All with the "wrong" with-T UBL and U-Boot.  Oh, also with a with-T Kernel.  (I already knew the kernel config difference was trivial and not germane to my task.) (((YIPPIE)))

Curiosity and knowledge for future complications, of course, lead me to still want to get other answers.  And good for other readers, too.

Srirami,

I tried to mark both your and my reponse as answers, but only yours shows near the top right now.  Perhaps you can edit your response to point out that the other UBL/U-boot/kernel turned out to not be necessary, in at least my case.  This may help others skimming but not closely reading.

Regardless, thanks very much for your help.

-Helmut

Helmut,

Thanks for the update. I am waiting for the comments from Linux team.

Regards, Srirami.

Srirami,

UBL, U-Boot and Linux kernel from T version can be used on a non-T version but we have to see the frequency at which ARM and DDR will be running. Because on a non-T version EVM, oscillator frequency is 27MHz, where as on a T version EVM, it is 33MHz.

Regards, Sudhakar

Sudhakar, please explain what you mean by "we have to see the frequency".  You must have some concerns in your mind when you say this, but the phrase itself at surface value doesn't mean much.

I was worried all along about this frequency difference.  However, it no effect that impacted me.  The 115,200 baud serial output is correct.  The network timing, if there is any, is correct.  And internally generated video timing must be correct, because by the time it comes out my ADV7171, it's all correct.   I don't see anything incorrectly running at 82% the speed it should.  Of course, the overall horsepower of the system is surely down by this amount, which was a known going into the situation in the beginning.  (My best guess is that some code somewhere is automagically noticing the difference and compensating at a very basic level, or perhaps there's a natural compensation within the core chip hardware designs such that the same fundamental time base is revealed on one chip at one speed and the other chip at the other speed.  It doesn't really matter to me, since it works.)

Bottom line, since the DM6467T was nearly impossible to get, I was able to get all the way to a fully working system using the TMS320DM6467ZUT7 and strictly the changes in that sprab44.pdf.

...oh, wait a minute.  I'm not thinking straight.  I'm thinking 1GHz processor, rather than 1GHz DSP with ???MHz ARM.  I believe it's only the ARM speed that matters on most of these I/O timings, not the DSP.  I think the DM6467T at 1GHz is the DSP speed, and the DM6467ZUT7 has a 729MHz DSP speed.  Neither of these are ARM speed.  When I boot up, a message says 495MHz ARM speed.  Perhaps the ARM speed is the same for both of these procs, which is why all the timing works.  WHY the ARM speeds are the same, after a crystal change from 33MHz to 27MHz, I can't say...   I need to move on to productive items.  All I know is this worked for me!

Helmut,

ARM speed = 1/2 of DSP speed.

On 1GHz DM6467T, DSP = 1GHz & ARM = 500MHz

On ZUT7, DSP  = 729MHz and ARM = 364.5MHz

When you boot up, the message you see is not correct. For correct speed display, you need to set "clkref" to 27MHz (default is 33MHz) as follows at U-Boot prompt:

u-boot> setenv clkref "27000000"

u-boot> saveenv

After above commands, power cycle the board and you should see correct ARM speed displayed. Note that, the "clkref" varaible is used only to display correct speeds. It not used for any PLL configuration,...etc.

When you use "T" version of U-boot, the problem will be as follows:

DM6467T U-boot sets DSP speed (PLL0) to 33MHz * 30 (PLLM) = 990MHz (i.e. ARM speed = 1/2 of DSp = 445MHz) and DDR2 speed (PLL1) to 33MHz * 24 (PLLM) = 792MHz/2 = 396MHz.

If you use "T" U-boot for non-T DM6467, the math changes as follows because U-boot applies the same PLL multipliers as with 33MHz input. It doesn't know about 27MHz input.

DSP speed (PLL0) to 27MHz * 30 (PLLM) = 810MHz (i.e. ARM speed = 1/2 of DSp = 405MHz) and DDR2 speed (PLL1) to 33MHz * 24 (PLLM) = 648MHz/2 = 324MHz, which are totally different frequencies. You can confirm this by probing the clock on your board.

Use the following non-T version of pre-build binaries (u-Boot, uImage) to use DVSDK3.10 with DM6467

http://processors.wiki.ti.com/index.php/DM6467_platform_in_DVSDK_3.10

Regards, Srirami.

Srirami,

Thanks for the info.  It makes perfect sense.  But this info remains in my "does not matter" column for the moment.

Can you please connect the dots between this recent info and the serial port baud rate?  If I never did what you suggest, why is my baud rate correctly 115,200?

How about also connecting the dots to the internally generated video timing?  What I mean by this is in the following context.  I have a much stripped down version of the encodedecode demo that does not have a capture.c or video.c, and never opens a channel on the video input chip, and never calls the codec engine.  All that's left is display.c.  Within display.c, it hard codes the buffer going to the display driver in order to show, for example, color bars.  When I run this program, I see color bars on the display.  I use a scope to look at the video output timing and it is correct.  It is *not* incorrect by a factor of 27/33.  All the video data is being generated from inside the ARM.  This video data goes out the [channel 2] port to the display chip, an ADV7171 in my case.  This data is in DB.656 format, which means it includes embedded timing codes.  These timing codes are also being generated by the ARM.  The overall timing for all of this should be coming from the ARM, and should NOT be coming from anything external, such as the capture driver or chip.  Therefore, if the ARM were running at 27/33 speed and DID NOT KNOW IT was doing so, I would think the video timing would be off by 27/33.  But it's not.  The video timing is correct.

So why is the video timing correct?

I'm not saying you're wrong, by any means.  I'm just saying it doesn't seem to matter.  I would like to understand when and where it WOULD matter, so that I can pay attention to this in the future, and so that others reading can know as well.

Thanks,

Helmut

Helmut,

Duplication of the the following post. Delete this post.

http://e2e.ti.com/support/embedded/f/354/t/96267.aspx

Regards, Srirami.

Helmut,

How are you generating Video port clocks on your board. If you notice, on DM6467T EVM, the VP clocks are generated by CDCE949 chip. I guess, that might be the reason for not seeing any display effect with ARM running  at 27/33MHz speed.

Also, let us see what Sudhakar comments on this.

Regards, Srirami.

Ah yes, you're right.  The cpu is using VPIF_CLKIN2 to drive VPIF_CLKOUT2, where VPIF_CLKIN2 comes from the CDCE949 chip, that has its own 27MHz crystal.  Therefore, this speed is independent of the cpu's choice of 27 or 33 MHz.  This explains the video being correct.  That still leaves the serial baud rate.  It also still leaves the fact that I still haven't found any reason to care about using the non-T ubl/u-boot.  Please realize this lack of care, from a professional point of view, is the same as saying I'm still looking for the reason it is required or confirmation that, at least in my situation, it's not!

-Helmut

srirami said:

Helmut,

Duplication of the the following post. Delete this post.

http://e2e.ti.com/support/embedded/f/354/t/96267.aspx

Regards, Srirami.

Srirami, I'm not sure what's up regarding duplication.  When I follow the link you gave, I believe it sends me to this same thread.  I've developed the impression that the #####.aspx ending to these URLs can refer to individual posts on a thread, and so one thread may have multiple URLs, one per post on the thread.  If I have two of the same post on one thread, I see no harm.  If it's actually two threads, I am unable to see that and need clarification.

And btw, thanks very much for your help on the technical stuff!

-Helmut