IPNC dm368 sdk 2.60 upgrade ubl/u-boot file in kernel-space (user-level).

Hi,

There is upgrade.cgi available in ipnc_app\utils folder. Please check if this helps.

This is used to upgrade the mtd section via GUI. We use this to update cramfs and uImage.

Please check if you can extend this to UBL and uboot

Regards,

Raghu

Thank for your answer Raghu.

-----------------------------------------------------
1)
Appro sdk kernel/root update example.
-----------------------------------------------------
i)
I see  IPNC Sdk 2.6.0 example
only kernel/root

ipnc_app/utils/update/update.c
#define KERNELBLOCK  "/dev/mtd2"
#define FILESYSBLOCK "/dev/mtd3"
int DoRootFileSysUpdate(FileInfo* pFile)
int DoKernelUpdate(FileInfo* pFile)

ii)
so I extend to mtd0, mtd1
but only failed .

iii)
Appro-Engineer Can give example code ubl,u-boot in kernel space?
likely upgrade example.

example)
#define UBL_UBOOT  "/dev/mtd0"
int DoUblUbootUpdate(FileInfo* pFile)
...

--------------------------------------------------------
2)
Is need patch in appro-sdk(2.6.0) ecc-data source code,
likely ti-evm sdk ?
*  http://processors.wiki.ti.com/index.php/DM365_Nand_ECC_layout
--------------------------------------------------------
i)
Is it no probleam
---
linux Kernel flash tool '/usr/sbin/nandwrite' write u-boot.bin to /dev/mtd0,
---
(reboot board)
---
,(Previous CCS Tool written)UBL code can read re-written(in kernel space) u-boot correctly ?
 
ii)
example)
nanddump -o -f /mnt/mmc/mtd0.bin /dev/mtd0
flash_eraseall /dev/mtd0
nandwrite /dev/mtd0 /mnt/mmc/mtd0.bin
nandwrite -p -s 0x160000 /dev/mtd0  /mnt/mmc/u-boot-1.3.4-dm368_ipnc.bin

iii)
* I tested
  Same board is correctly booted,
  but other board(nand bad table not same) is not correctly booted.

Thank you and best regards,

I have encountered the same problem. Update ubl and uboot from linux is really urgent need

This is an important method to restore firmware of the davinci system. Is anybody success to flash ubl and uboot in linux user space?

It is not possible to flash the UBL and u-boot image from user space. UBL needs a header with a magic number, the file size etc.. to be written. Also UBL again checks for similar header from u-boot binary as well. Currently this is all performed by NAND writer program. If you need to upgrade the image from user space, some amount code has to be written.

Hi all,

I recognize this thread is a bit dated... 

I have a need to update the UBL on a bunch of DM368 based cameras due to a periodic boot hang problem (fix has been verified in the UBL). We have ~30k deployed cameras which need to have their UBL updated without using JTAG.

I'm attempting to write a Linux command line utility that does exactly what is described above. I can see in the nandwriter source where the UBL header is written with the magic number, etc....

I've taken the nandwriter source code (came with the v5.1 IPNC code drop) as a starting place & mapped the physical addresses to user space via mmap().  I'm able to talk to the NAND device & blow away the flash blocks where the OS is located... yea... However, there seems to be something blocking the erase on block1... where UBL & UBOOT reside.

Is there perhaps a dependency on the JTAG device setting some registers that's outside of the nandwriter code?

I've intentionally commented out the device_init() section that sets the PLL's, etc... since it will already have been set to get to the Linux command prompt... I can see the flash_unlock() function being called... but it seems to have no effect on block1...

I'm happy to share the code with anyone.

Regards,

Edwin Bland

Hi Edwin,

If you would have followed whatever Renjith told in the above post and still you were not able to write to the NAND then it could be a permission issue.Flashing UBL and u-boot with JTAG marks the blocks of NAND as ReadOnly. So you have to mark them as R/W. I faced this same issue with a NOR Flash. Probably it would be the same with NAND also so try it out.

Regards

Haran

Hi Haran,

Perhaps you're referring to the LOCK/UNLOCK mode of the NAND flash part?  The nandwriter application code talks directly to the NAND EAMIF registers via mmap()...  It issues commands to unlock the blocks of flash we're attempting to write/read back from.  Which permissions were you referring to?

The gdb trace seems to indicate it's throwing up on the ECC portion.  I've added the dummy read referenced in Advisory 1.2.4 (SPRZ316B - April 2010, Revised July 2011) on v1.1 DM368 hardware.   This didn't seem to have any effect.

  if ((corrState == 1) || (corrState > 3))
  {
    Errata_Advisory_1_2_4 = AEMIF->NANDERRADD1;            //Fix for ECC issue Errata 1.2.4
    return E_FAIL;
  }
  else if (corrState == 0)
  {
    Errata_Advisory_1_2_4 = AEMIF->NANDERRADD1;            //Fix for ECC issue Errata 1.2.4
    return E_PASS;

What seemed strange to me is that the Advisory reports this fix is required for the DM368 v1.1 hardware... however, it's not included in the latest V5.1 IPNC drop.  This seems strange since the Advisory came out a few years prior to the latest release.... I would have expected the fix to be within the latest drop.

offending source code is :flash_utils_dm36x/Common/drivers/src/nand.c:  // Routine to read a page from NAND

Uint32 NAND_readPage(NAND_InfoHandle hNandInfo, Uint32 block, Uint32 page, Uint8 *dest)

I've pasted in the target gdb debug trace where it fails:

305        LOCAL_flashWriteData(hNandInfo, DEVICE_NAND_CLE_OFFSET, NAND_READ_30H);
(gdb)
309      if(LOCAL_flashWaitForRdy(NAND_TIMEOUT) != E_PASS)
(gdb)
313      (*hNandInfo->hEccInfo->fxnDisable)(hNandInfo);
(gdb)
316      for (i=0; i < hNandInfo->numOpsPerPage; i++)
(gdb) l
311   
312      // Clear the ECC hardware before starting
313      (*hNandInfo->hEccInfo->fxnDisable)(hNandInfo);
314     
315      // Read data bytes with ECC enabled
316      for (i=0; i < hNandInfo->numOpsPerPage; i++)
317      {
318        (*hNandInfo->hEccInfo->fxnEnable)(hNandInfo);
319           
320        LOCAL_flashReadBytes(hNandInfo, (volatile Uint32)&dest[hNandInfo->dataBytesPerOp*i], hNandInfo->dataBytesPerOp);
(gdb) print *hNandInfo
$20 = {flashBase = 1075097600, busWidth = 1 '\001', manfID = 44 ',', devID = 44 ',', numBlocks = 8192, pagesPerBlock = 256, dataBytesPerPage = 1024,
  spareBytesPerPage = 32, dataBytesPerOp = 512, spareBytesPerOp = 16, numOpsPerPage = 2 '\002', numColAddrBytes = 2 '\002', numRowAddrBytes = 3 '\003', CSOffset = 0 '\0',
  isLargePage = 1, isONFI = 0, currBlock = -1, isBlockGood = 0, hPageLayout = 0xee40, hEccInfo = 0xee14, hBbInfo = 0xee34, hChipInfo = 0xee98}
(gdb) n
318        (*hNandInfo->hEccInfo->fxnEnable)(hNandInfo);
(gdb)
320        LOCAL_flashReadBytes(hNandInfo, (volatile Uint32)&dest[hNandInfo->dataBytesPerOp*i], hNandInfo->dataBytesPerOp);
(gdb)
322        (*hNandInfo->hEccInfo->fxnDisable)(hNandInfo);
(gdb)
325        (*hNandInfo->hEccInfo->fxnRead)(hNandInfo, spareBytes, i, readECC);
(gdb)
326        if ((*hNandInfo->hEccInfo->fxnCorrect)(hNandInfo,&dest[hNandInfo->dataBytesPerOp*i],readECC) != E_PASS)
(gdb) n
328          return E_FAIL;

I'll retrace my steps... I would have expected some failures earlier if it were a permissions problem... e.g. ERASE failure, WRITE failure, etc...  It seems to come back to how block1 is handled.

Taking another approach... I've been able to manually populate the UBL header in RAM & then load the UBL into RAM... then flashing this RAM image back to NAND.... It successfully boots to UBL/UBOOT/OS...

Here's the basic NAND/FLASH layout:

UBL Header: 0x20000 (Magic #, etc... tells it to jump to UBL)

DM365 EVM :>nand dump 0x20000 1024
Page 00020000 dump:
        00 ed ac a1 00 01 00 00  0a 00 00 00 01 00 00 00
        01 00 00 00 00 00 00 00  ff ff ff ff ff ff ff ff
        ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
        ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff

UBL: 0x20800

DM365 EVM :>nand dump 0x20800
Page 00020800 dump:
        31 0f 19 ee 01 00 a0 e3  31 0f 09 ee 11 0f 19 ee
        38 00 9f e5 1d 00 80 e3  11 0f 09 ee 34 00 9f e5
        34 10 9f e5 34 20 9f e5  00 00 52 e1 05 00 00 9a

This provides one path forward... but I'd like to understand what the real issue is with the above approach... it's essentially the same source code as the nandwriter which is done over JTAG....

Regards,

Edwin

Hi Edwin,

I would like to give your code a try on my DM36x based system, there is a chance I can find out something else about your issue. Would you mind to share it with me?

Best Regards,

-Marco

Hi Marco,

I've attached the test code.

I've not previously used the mmap() approach to talk directly to device registers... I believe it should be a valid method, however.

Since I've found an alternative viable deployment method I can't justify additional work time on this approach.  However, I'm happy to spend personal time on it to understand why the approach doesn't work.

What I've learned is that the FlashClear doesn't work.  However, the return values from stepping through the code indicate no failures... However, when I power cycle the device the original UBL is still on the device... so I know the Clear didn't work.

Feel free to email me directly: ebland_us AT yahoo DOT com.6505.flashwriter_payload_NotWorking.tar.gz

Edwin & Marco,

I kind of lost context of the thread. Are you still stuck the same problem? If so, can you describe the problem fresh with more data/logs?

Hi Renjith,

Thanks for your response. I just wanted to help Edwin with his issue, however I have been pulled to some urgent projects and I haven't been able to give it a try. I will try to provide some feedback once I can test the code.

Best Regards,

-Marco

Hi guys,

The crux of the matter is the need to have a user space application which flashes the UBL & its header.  The existing Linux user space utility will write the UBL.. however, it doesn't generate the required UBL header/magic #... and since the UBL & UBL header are in the same flash block both are blown away with the clear.  One workaround would be to have the writer application read the first 0x800 bytes & then tack this onto the front end of the UBL for the write.  It would be nice to have a user space application which has the same functionality as the JTAG flashwriter program.

The JTAG flash writer application code generates this UBL header data.  In this case it required a fair amount of code study & the dumping of the flash memory to understand the required UBL header data.  Many users really aren't interested in the details of a header/magic #... they just need a method to update the UBL... for already deployed applications (i.e. cannot use JTAG).  This is a straightforward task... I just can't justify additional work time on it... now that I have a viable deployment solution (required a manual generation of the UBL header data).  This was a known bug in the TI UBL for the DM368.

Regards,

Edwin

From Edwin's post:

> I have a need to update the UBL on a bunch of DM368 based cameras due to a periodic boot hang problem (fix has been verified in the UBL). We have ~30k deployed cameras which need to have their UBL updated without using JTAG.

Glad to know that we're not going crazy. We encountered the same issue with occasional UBL boot hang problem on our deployed DM368 cameras.

So there are 2 problems:

1) what is the actual patch or fix to UBL source code that is needed to avoid this occasional boot hang issue

2) how to best fix this on cameras that are in the field, without access to JTAG

Looks like Edwin Bland found the fix to the UBL. Is this something officially released by TI or Appro ? If not, wouldn't it make sense for TI or Appro to develop the official fix ?

Or does everybody who actually builds DM368 based cameras have to devote time & resources to re-invent this ?

Hi Tek4,

The UBL source code fix was included in the TI source code released for the DM36x based IPNC devices.  It took a bit of study through the release notes... to understand it was contained within.   As I recall the issue was a bug in how some of the PLL's were setup.  It resulted in a ~250x reduction in boothangs for this particular device on our hardware.

The frustration was having to manually create an image to flash the UBL using the existing command line flash utils.  You aren't just able to pass the compiled UBL image to the command line flash utility.  You are required to manually generate the UBL header ... with the correct magic #, etc... and prepend this to the compiled UBL image... or else the RBL (Rom boot loader) won't recognize it as a valid UBL image... and it will hang. I'm not in the office today... but if you like I can send a few more details when I return to the office.

At the time I had discussed the matter with our local TI rep and they seemed receptive to adding a utility for generating the final UBL flash image useable by the existing command line flash tools. 

Regards,  Edwin

Edwin,

Thanks so much for your reply. There could possibly be multiple problems.

We will double check it but we believe we were already using the UBL version with the PLL fix.

But we still see occasional hangs.

By adding lots of debug print statements and observing a number of cameras during the boot cycle, the problem appears to originate in the NAND_open() routine.

Our cameras tend to be installed on oil rigs or on top of mountains or various other inaccessible sites with unreliable power. Any hang during the startup phase would be considered a product defect, so we are trying to find the remaining causes of UBL or uBoot startup failures.

Once we have that, we can then proceed to the fun part of updating the UBL of cameras that are already in the field.

Regards,

Tek4

Hi Tek4,

Our application was occasionally storing items in the UBOOT parameter storage space.  This was problematic. Ours are also in an environment that has intermittent power.  I ended up modifying UBOOT to have double buffered parameter areas, both with CRC protection (i.e. always keep a valid copy of the parameters).  This also reduced the boot hangs substantially.  We previously had some units returned where some of the parameters had been blown away or garbled... and in some cases bootargs... :(.   Try quantifying your hang rate... e.g. 1 in 10 ... 1 in 1000, etc... Feel free to send a note to ebland underscore us AT yahoo DOT com.  I can likely share a bit more data (hang rates).  I ended up writing a test application which sends a message to the camera to know if it booted fully & the application launched...   The power control was on a simple relay board... with 12 cameras being tested simultaneously.... We felt we were able to get a decent sampling with the setup.  I needed this type of setup to confirm the changes had made a quantifiable improvement....:)

Regards,

Edwin