Bad kernel checksum

It could be an issue with your particular flash setup, recently we have been seeing customers with flash burning issues related to the socket on their EVM being loose, so that may be worth a look though I would imagine that the write would give failures as well.

I think you are right.

It's probably because of my NAND flash. I ordered some flash memory samples to verify this point.

Thank you for your help.

I believe the issue Bernie was referring to had more to do with the EVM socket than the flash part itself.  This is usually alliviated by adding some pressure on socket.  It is worth a try.

Hi,

I didn't have time this last 2 months to deal with this problem.

But now, I have some new samples of 512Mo NAND Flash. And the problem persists.

The other operations, flashing file system, uImage with U-Boot commands... works perfectly. No need of pressure on socket.

Only flashing uImage file, using Linux commands, doesn't work.

I think there is a problem with 'nandwrite' function.

Regards,

It is possible that there is some problem using nandwrite in that way, I have only been writing uImage files to the flash using U-Boot as opoosed to from within Linux.

I am curious why you would want to use the Linux commands instead of doing this operation from U-Boot?

I am using this method because "it's possible". When it is possible, it should work. [:$]

More seriously, I prefer using Linux commands because it's more simple. You just need to call device name (/dev/mtdx..) instead of memory addresses.

And one day, maybe I will update the uImage File or the file system by an application running on Linux. This is not possible using U-Boot.

Regards,

Stéphane.

Stéphane

I just tried this myself on my DM355 EVM and it worked for me.  I did the following

On target EVM Linux prompt:

  >flash_eraseall -j /dev/mtd2
  >nandwrite -p /dev/mtd2 uImage

On target EVM u-boot prompt:

  DM355 EVM # setenv bootcmd 'nboot 0x80700000 0 0x400000;bootm'

this seemed to work fine.  I am using the latest DVSDK (1.30.00.41).

Hi Juan,

Thank you for your help.

I tried the same command but I have always the same result :  ..."Verifying Checksum ... Bad Data CRC"

With or without (-j) parameter, for flash_eraseall function, it's the same result.

My "bootcmd" environment variable has the same parameters.

But I don't have the latest DVSDK version (1.30.00.40)!!

I'm sure it's because of that, don't you think?

How can I retrieve this new DVSDK version?

Regards,

Once you register your board (www.ti.com/davinciregistration ), you will get access to our software update site where you can get the latest DVSDK software (www.ti.com/davincisoftwareupdates ).

That is probrably the reason; if I recall correctly, there were some minor bugs in NAND driver in earlier releases which may explain this behaviour.

Juan,

I have registered my board, I already have an account, but I can't access to the update web page:

https://www-a.ti.com/extranet/cm/product/dvevmsw/dspswext/general/dm355_dvevm.shtml

I only see an empty white page.

Do you know another method to download the new DVSDK version?

Regards,

That is strange, I just accessed the page just fine.

I do know some countries such as china have sites blocked by the government; in that case, we advice that customers submit a ticket via www.ti.com/support and local support teams serving those regions have been trained to handle such cases.  You can try submitting a request via www.ti.com/support and see if your regional support team can help.  Another thing you could try is acessing this site from outside your corporate firewall to see if that helps. 

I received an email from TI that asked me to complete my registration. I did it. But it has not solved my access problem to the DVEVM update web page.

I have submited a ticket to the local support teams. I hope they will solve this problem.

Thank you Juan and Bernie for your precious help.

I will send you backup, for my situation.

Regards,

Stephane.

Hi Juan, Bernie,

I did not receive response from the support team, yet.

But, by searching another information, I found other web page to retrieve DVSDK updates.

https://www-a.ti.com/downloads/sds_support/targetcontent/dvsdk/mv_dvsdk/v1_30/index.html

I can access it without any problem, and I downloaded the DVSDK update V1.30.01.41!!

Now I will install this update and try again Linux commands for flashing a kernel.

Another point :

I saw a new version of MVL V5.0 with new LSP V2.0.... and new DVSDK V2.0....

Can I update my MVL V4.0.1 and LSP V1.20... with my DM355 DVEVM board?

Regards,

Stephane.

I tried with this file system "dm355_flash_image_1_30_01_41.tar", using Linux commands for flashing uImage file, but it's always the same problem!!

I don't understand why there is a bad CRC.

Never mind, it's not so important. I can do it with NFS file system and with U-Boot commands.

Thank you for your help.

-------------------------------------------------------------------------------------------------------------------------------------------------------

I've just compared the "flash_eraseall" & "nandwrite" functions of the 2 versions of DVSDK (..00.40 ; ..01.41) file system. There are the same!!  [:(]

Stéphane said:

Another point :

I saw a new version of MVL V5.0 with new LSP V2.0.... and new DVSDK V2.0....

Can I update my MVL V4.0.1 and LSP V1.20... with my DM355 DVEVM board?

I would not recommend updating to DVSDK 2.0 quite yet; this is an EA release and not very well supported yet; when DVSDK 2.0 finally releases to our official software update site, it will likely be different than what the EA version currently posted.

I will have to give this a try myself with then newer DVSDK, I have done this in the past with older releases.  In the mean time looks like NFS may be a solution for you...  Thank you for the update.