DM6446 Platform Development Issues

...Found Technical Reference version that matches my physical.  Don't know if it's MOST recent, but it is Rev E from March 2007.

http://c6000.spectrumdigital.com/davincievm/revf/files/DaVinciEVM_TechRef.pdf

Now for the software questions...

Hi Helmut,

1) Is your board Rev.E or Rev.F (It should be on the back of your board)? The schematic you included is Rev.F.

2) latest SW package can be found here: http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/dvsdk/DVSDK_2_00/latest/index_FDS.html. I believe you shouldn't encounter any problem on either Rev.

3) Currently the two more popular filesystem are harddrive FAT and network NFS. You can also burn your filesystem onto the NAND (JFFS2), but it is generally slower. What is your end application?

Paul,

Thanks for your response.

1) My board appears to be Rev H.  Slightly difficult to read, but I doubt an "M".  When *I* look at the tech ref link in my post, I see "Revision E" in the corner of the schematic.  perhaps you mis-typed.  Anyway, that still doesn't match my Rev H board.  Unless I find a Rev H schematic, I'll probably have to go with the assumption that nothing too critical changed.  Remember, I'll be making my own board from the schematic, then running the same software as I tested on Rev H.  So it's incompatibilities there that I'll have to watch for.  At a minimum, your comment has brought this to my attention as something to watch.  Thanks.

2) I'll keep your SW link and revisit it when I'm further down the road.  I've been off the project for a couple months.  Memory is coming back about Linux running on the ARM.

3) I need to have no fat -- [joke: either file system or dead weight].  No disk.  No this.  No that.  I need bare bones board.  I'm concerned about how to boot up, but I guess I'll learn that.  I'll keep in mind your NAND comment.

Perhaps you or someone else can help a little further with regard to the source code thing.  I'll explain my perspective.  On the third party software, all I did was write a [big, complicated] codec subroutine.  I'm not much on acronyms -- I think it was DMAI.  I installed that really pitiful excuse for a UI, Code Composer Studio (here, I have 30 yrs experience in the field and know it's pitiful).  I received a little bit of source code and lots of stuff to link in.  I downloaded it via J-Tag.

The slavemaster never allowed me enough time to figure out what was going on outside of the code I had to write.  

(A) I didn't know where the download was really putting stuff, although I know the third-party camera has no disk, so it must have been non-volatile memory.

(B) I never saw a Linux prompt

(C) Needing to make mods in the source I received, I deduced that some of that source was finding it's way to the DSP, and other to the ARM, but I never learned what settings of whatever caused which code to go where.

(D) I never got to figure out how the system was booting up, just that it was.

(E) I also wanted to, but never got the chance to make something appear using the OSD, which is probably akin to item (C) above.

With all that mentioned, I have been doing this kind of thing for a long time.  I will be able to figure each point out.  Suggestions by anyone to get me there quicker, is GREATLY appreciated.

Therefore I'm not sure WHICH level or type of software source code I even need!

Also, all those points leave a lot of blind spots.  That's why I'm concerned about investing the little time slavemaster [the boss] allows me, and then discovering a dead end.  My BIGGEST concern here is that, starting from what I have now and NOT purchasing $15K to $60K of "reference design', I need to end up with a software foundation that actually works, and will allow me to re-integrate and further develop our video analytics.  All this, WITHOUT the hard disk, WITHOUT an SD Card.  WITHOUT as many other things that we don't need that I can strip, such as USB, MSP430?, UART, a few of the GPIO's, etc.  Based on this concern, I envision having a hard time booting in general (but your NAND suggestion alays that fear somewhat), and also getting hung when some code somewhere tries to initialize something I've left off the board.

Without prior confidence, I'll just have to press forward and find out.  But if you or others on the forum can be so helpful as to confirm positive or negative some of these items, it would be great.

-Helmut

Helmut,

1) I meant Rev.F. Just checked with spectrum digital, Rev.E and Rev.F are pretty much identical. I am pinning them on whether rev.e,f,g,h are all the same or not.

Helmut Forren said:

Perhaps you or someone else can help a little further with regard to the source code thing.  I'll explain my perspective.  On the third party software, all I did was write a [big, complicated] codec subroutine.  I'm not much on acronyms -- I think it was DMAI.  I installed that really pitiful excuse for a UI, Code Composer Studio (here, I have 30 yrs experience in the field and know it's pitiful).  I received a little bit of source code and lots of stuff to link in.  I downloaded it via J-Tag.

The slavemaster never allowed me enough time to figure out what was going on outside of the code I had to write.  

(A) I didn't know where the download was really putting stuff, although I know the third-party camera has no disk, so it must have been non-volatile memory.

(B) I never saw a Linux prompt

(C) Needing to make mods in the source I received, I deduced that some of that source was finding it's way to the DSP, and other to the ARM, but I never learned what settings of whatever caused which code to go where.

(D) I never got to figure out how the system was booting up, just that it was.

(E) I also wanted to, but never got the chance to make something appear using the OSD, which is probably akin to item (C) above.

With all that mentioned, I have been doing this kind of thing for a long time.  I will be able to figure each point out.  Suggestions by anyone to get me there quicker, is GREATLY appreciated.

Therefore I'm not sure WHICH level or type of software source code I even need!

Also, all those points leave a lot of blind spots.  That's why I'm concerned about investing the little time slavemaster [the boss] allows me, and then discovering a dead end.  My BIGGEST concern here is that, starting from what I have now and NOT purchasing $15K to $60K of "reference design', I need to end up with a software foundation that actually works, and will allow me to re-integrate and further develop our video analytics.  All this, WITHOUT the hard disk, WITHOUT an SD Card.  WITHOUT as many other things that we don't need that I can strip, such as USB, MSP430?, UART, a few of the GPIO's, etc.  Based on this concern, I envision having a hard time booting in general (but your NAND suggestion alays that fear somewhat), and also getting hung when some code somewhere tries to initialize something I've left off the board.

Without prior confidence, I'll just have to press forward and find out.  But if you or others on the forum can be so helpful as to confirm positive or negative some of these items, it would be great.

I am actually not sure what you are asking in this section. I would like to suggest you to first bring up Linux following the user guide in the link I sent you and bring up a standard demo (i.e. decode and display), doing so, you should at least understand how our software stack works. This should not take you very long, I was able to get a NFS based decode demo running in half a day. After that, you can think about which packages in the DVSDK you can get rid of.

I am not sure why you need CCS here (except possiblying reburing UBL and uboot).

BTW, Do you have a regional support currently?

We also have a Linux forum, if you have concise and specific question, you can post it there too.

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

Paul,

Thanks again.  Note I'm temporarily off this project after tomorrow, then back on after the 20th of Sept.  So I'll be quiet during that time, but still dreaming about it at night.

Regarding CCS, I didn't see a disk in the TI dev kit, and saw something else in green.  So, yes, hopefully I don't need CCS.  

Also, I revealed just now I haven't even stuck in a CD or powered anything up yet.  Right now, I'm just cranking up on this aspect of the project, while finishing up another one in parallel.  As you said, I need to get ahead and at least *begin*.  Then things will clear up rapidly.

I still "get the willies" (fear expression) when I hear "Linux".  I've used Linux plenty and don't have a problem with it myself.  It just makes me think "hard disk".  Oh, but you already said NAND flash...  Just can't help it!!!

[[[You wrote "pinning" spectrum digital.  I understand your meaning, but don't know the word "pinning".  Did you mean "pinging"?  Or else define "pinning" to further educate me.  Thx.]]]

Thanks,

Helmut

typo. :) pinging.

Do you have any regional support (TI sales & FAE) helping your company?

(I didn't get an alert that you posted, so this response is late)

I am not aware of any regional support.  Might you tell me how to get it?  Please note that the company offices are in Virginia south of DC, but my office is in Georgia, north of Atlanta.   Please note also that I'm about to post another question, that I believe should be answerable on this forum, but might be answered by an FAE.

Thanks,

Helmut

Helmut,

Most likely, your management team would know if TI has assigned FAE to help your company. We have multiple support models here in TI. Please email me your company/group name and project title, and I will find out the support model for your project.

Paul.Yin said:

3) Currently the two more popular filesystem are harddrive FAT and network NFS. You can also burn your filesystem onto the NAND (JFFS2), but it is generally slower. What is your end application?

=== A ===

I would like to pick up on this question.  Remember, I need to design a product that has no hard disk at all.  I want to implement proof-of-concept of this using the DM6467T EVM (aka HD1080P EVM).

My end application is simply video pass-through but with custom video analytics in the middle, under XDAIS.  I won't be recording to or playing back video from the file system.  I don't think I'll be using the file system at all if I can help it -- well, perhaps I have to have my application loaded from it.  

My big concern is that while NAND flash can be used for bootloading, things then move over to read more stuff from the hard disk.  I can't have this.

Now I am about to *guess* how things might work in my case.  Please correct me where I'm wrong...

I'll put my file system into NAND and boot from there.  This means that the ARM will boot from NAND flash.  This booting will include loading Linux, and in turn my application.  ALL of these must be fit within the NAND flash.  Somewhere along the way, the ARM facilitates the DSP boot, and I assume this is another file in the filesystem coming from the NAND flash.  Now both ARM and DSP are running my code.  From there, I'm home free.

In contrast, do I want to chuck Linux altogether, and just write code so the ARM boots my own application, and then helps the DSP boot?

(((I've done many microprocessor solutions over two decades, and I always "boot" by simply running my program.  I've worked with PC's, and I've worked with Linux on PC's.  I haven't done any embedded Linux, however, and I don't know how "embedded" (aka small) it gets!)))

=== B ===

Of course, I'm looking for the shortest development path, leveraging as much source code as I can get without having to write it myself.

I can imagine (hope for?) source code for the ARM that runs a simple video pass through.  I would take this source code and make only minor tweaks, such as consulting GPIO for some configuration info from the user.  If the ARM is the correct place, I might also note a GPIO button and thus write an image frame capture to a FAT file system on an SD card.  Meanwhile, I can imagine (hope for?) source code for the DSP that implements XDAIS.  Then my own video analytics fit in as a codec.  I might not need source code for the high level part on the DSP.  I only need source code for a codec shell, that I modify for my video analytics.  

I've already done all this once already for a CiS VCC-V90S camera, which uses a DM6446.  So I've already got the video analytics written in XDAIS compliant form.  With the CiS VCC-V90S, however, I got some source code but not all.  I got enough source code to be able to modify some codec code to make my video analytics.  And I got enough source code to see the video info being passed from the ARM to the DSP (I think), where I made some configuration mods.  (At the time, I didn't have time to study too closely.  I believe this code was running on the DSP and ARM, respectively.)

So now I'm just wondering if the similarly inviting platform is available on the HD1080P EVM.

(((I realize I started out asking about booting, and moved on to a question of source code.  Sorry.  It's all related from my point of view!)))

Helmut,

I am not sure what exactly you want us to comment on. Here is what I suggest you do.

1. Make your question as concise as possible. It's difficult to figure out key takeaways from your message.

2. Since this is almost a new subject, please just create a new thread in the Linux forum (http://e2e.ti.com/support/embedded/f/354.aspx). It's not recommended to discuss too many different subjects in one thread.

3. In general, please use this sub-forum when you have a device related issue. Not all questions are suitable in this sub-forum.

Paul,

Respectfully, this is almost finger pointing at this point.  That is, this forum points a finger to put it in the other forum, but the other forum would point a finger to put it in this forum. I apologize for seeming brusk, but I'm very frustrated with this situation.

More specifically, I don't think the linux forum is appropriate.  I'd rather not run linux at all.  I don't care about linux.  I just want to be able to run the DM6467T without a hard disk anywhere in site.  My section ==== A ==== question asked about that.  It allowed for the possibility of no linux at all.

I'll break it down into pieces here.  Here's the first piece.

1. Can I run a DM6467T without linux at all?  If so, can I run the DM6467T without linux at all?  If so, is there reference design source code for being able to do this?

Thanks,

Helmut

P.S. If get a "no" to any of the above, I'll repost over in the Linux forum.

Helmut,

First of all, please review the README thread on top when you get a chance for future reference.

Secondly, we never move posts back and forth between forums. In TI, we always work together to solve the customer's problems. The only reason we move a post is if it cannot be answered in its current forum or there are more expertise in another forum.

As I was saying. There was a lot of information in your message, it is difficult to figure out exactly what were are asking. Regarindg your first piece,

As far as I know, it's either Linux or WinCE, as buffer management, multithreading, and scheduling really require an OS. There might be customers that's doing their own thing, but that's proprietary and we will not be able to tell. If you were thinking about writing a CCS program, it might take you a long time doing so. Besides, I think UBL and uboot are for Linux, That said, I would still recommend Linux w/ NANDFS.

Paul,

I'm dropping the subject of your first three paragraphs, and chalking everything up to miscommunication.  No problem.  No need to dwell on it.

Regarding your last paragraph, my comments at http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/99/p/66464/240624.aspx#240624 are germane.

Regarding Linux w/ NANDFS, I've heard that before and am keeping it in mind.

QUESTION: If I'm wrong about not needing Linux, can I indeed run it ALL from NAND flash, with no hard disk or PCI or network connection or anything?  That's just the NAND flash (I believe to hold my file system), and no other peripherals.  (Please feel free to direct me to an answer over in the Linux forum.  I just wasn't able to find an answer to this over there, because it seems all the posts over their start from the baseline assumption that you already have Linux running, and I'm still trying to make that first knowledge step from the hardware to the OS.)

Thanks again,

Helmut

Helmut,

By NANDFS, I was suggesting that both kernel and filesystem are on NAND. You will not need ATA, EMAC, USB, or PCI. I've done a project using NAND FS, however it is internal. There is only one thing you need to keep in mind, NAND access is not very fast. So you might also need tmpfs in DDR.

I am not sure if anybody has asked this question on the forum before, but I am sure you will get some answer if you post a new message in the Linux forum. You will also get information on tmpfs in the Linux forum (if there is no post, please start one).

Helmut,

We will have someone look into the new thread you just posted.

regarding your questions on Sep 8, do you still need answers? If so:

1. are you looking for DM6446 EVM schematic? if so, it is available on spectrum digital website: http://c6000.spectrumdigital.com/davincievm/revf/

2. no HDD, you will need NFS. the DVSDk getting started guide shows the options. http://www.ti.com/litv/pdf/sprue66e

3. again, all SW related issues, please check with the linux forum.

regards,

Paul

Paul,

Thanks very much for thinking to follow up on my original question.

1. I found the DM6467T EVM schematic long ago and I have been using it.  For others, note  Spectrum Digital uses the name HD1080p EVM at http://support.spectrumdigital.com/boards/evmdm6467t/revb/

2. Seeing the DM6446 EVM getting started guide you referenced, I'll check out the one for the DM6467T.  Recall, my boss mandates I finish the board before playing with the EVM.  Yes, I know...  Anyway, I'll peek at the guide to see if it offers help with the hardware design.

3. Yes, SW in the linux forum.  But two things about that.  I know there are software solutions that aren't linux.  And also you have to have the proper hardware to run the software, and so sometimes it seems a hardware forum is more appropriate.  It sometimes seems the folks over on the linux forum have tunnel vision and aren't able to think outside the box, the box being vanilla hardware running linux.  (Please excuse my harping on this.  Also, note my use of the wiggle words "sometimes" and "seems".)

Thanks again,

Helmut