Hi Caglar, I got it working. Here's what I did. I re-program my device and write the UBL image from block 1 to block5 using DVFlasher. Then, I booted my device, call nanddump -n to get an image of each block and save it to a file.
Then, I can use nandwrite -n -o to write the image on the block. But, there's one rule to follow, the UBL image should be written to the correct destination block. For example, If the image came from block3, it should be written to block3, image4 should be on block4 and so on. Thanks, John > > Caglar, > > In sprue20c <http://www-s.ti.com/sc/techlit/sprue20.pdf> documentation, > discusses the 3 types of mode. One of them is the NAND Flash mode, which is > the mode to function the NAND Flash ECC generator. > > My question is, if the device is running linux, what mode does the NAND > is?. > > I am start playing to add some routines in nand drivers and see how far I > can go. But, need additional information and maybe you can help me. > > 1. Do you know how the ubl data laid out on the block?. > 2.The ubl image should not exist 0x3800 bytes and seems DVFlasher removes > some Srec. Do you know what was the reason?. > > > Best Regards, > > John > > > On Sat, May 1, 2010 at 11:52 PM, Caglar Akyuz <[email protected]> > wrote: > > > On Saturday 01 May 2010 01:19:56 am John Tobias wrote: > > > I've used the following commands and didn't get any success. > > > > > > 1. nanddump -n -f /ubl.bin /dev/mtd5 > > > Block size 16384, page size 512, OOB size 16 > > > Dumping data starting at 0x00000000 and ending at 0x00004000 > > > > > > 2. flash_erase /dev/mtd1 > > > > > > 3. nandwrite -n -o /dev/mtd1 /ubl.bin > > > > > > 4. flash_erase /dev/mtd5 > > > > > > Any more idea? > > > > > > > AFAIK, rbl/ubl pair uses different ECC layout than u-boot/Linux pair. For > > instance, I do not use u-boot in some cases and boot Linux directly from > > UBL > > in which I write Linux to NAND from userspace. In those cases, I read > Linux > > without any ECC in UBL. But you do not have any access to RBL so you > cannot > > program UBL from userspace without changing Linux ECC handling. > > > > Best Regards, > > Caglar > > > > > Thanks, > > > > > > John > > > > > > On Fri, Apr 30, 2010 at 2:57 PM, Siddharth Choudhuri > > <[email protected]>wrote: > > > > Does dd also take care of writing the OOB area along with the actual > > data > > > > ? The OOB layout where the ECC is written could be an issue IMO. You > > > > might want to look at nandwrite i.e., read using nanddump -> erase -> > > > > nandwrite to see if it works. Also, nanddump and nandwrite might have > > an > > > > option to read page data and/or OOB. > > > > > > > > -sid > > > > > > > > On Apr 30, 2010, at 1:15 PM, John Tobias wrote: > > > > > > > > Hi Mike, > > > > > > > > I've used this two commands to copy the image on block 5 then, copy > it > > > > over to block 1. > > > > > > > > dd if=/dev/mtd5 of=/ubl.bin bs=512 count=32 > > > > dd if=/ubl.bin of=/dev/mtd1 bs=512 count=32 > > > > (My NAND flash has 512 bytes per page with 32 pages per block or > > 16Kbytes > > > > in 1 block). > > > > > > > > In order to test the block 1 if it's working, I erased the block 5 > and > > > > boot my device but, it doesn't work. > > > > > > > > Any idea? > > > > > > > > Thanks, > > > > > > > > John > > > > > > > > On Fri, Apr 30, 2010 at 11:51 AM, John Tobias <[email protected]> > > wrote: > > > >> Hi Mike, > > > >> > > > >> Yes, that's my plan. I will expose the ubl blocks from linux > userspace > > > >> and become writable. > > > >> And, I like the idea of using dd so no need to worry about the CRC > > > >> issue. > > > >> > > > >> Thanks, > > > >> > > > >> John > > > >> > > > >> On Fri, Apr 30, 2010 at 11:34 AM, Mike Williamson < > > > >> > > > >> [email protected]> wrote: > > > >>> Hi John, > > > >>> > > > >>> In the past, we've used the /dev/mtd* devices to write data back to > > NOR > > > >>> (spi / parallel) devices for updating firmware using something > like: > > > >>> > > > >>> dd if=newimage.bin of=/dev/mtd0 > > > >>> > > > >>> Of course, you need to have your kernel configured to have the mtd > > > >>> drivers loaded and you need to make these areas writable (most > linux > > > >>> board packages set these to read-only, given the sizeable gun you > > have > > > >>> pointed at your shoes....) > > > >>> > > > >>> -Mike > > > >>> > > > >>> On Fri, Apr 30, 2010 at 2:14 PM, John Tobias <[email protected]> > > wrote: > > > >>>> Hi, > > > >>>> > > > >>>> Does anyone successfully written the UBL image in block 1/5 from > > linux > > > >>>> userspace? I need a way to write the ubl image for the firmware > > > >>>> upgrade and the only access that I have is the linux userspace. > > > >>>> > > > >>>> > > > >>>> Thanks, > > > >>>> > > > >>>> John > > > >>>> > > > >>>> _______________________________________________ > > > >>>> Davinci-linux-open-source mailing list > > > >>>> [email protected] > > > >>>> > > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > > > >>> > > > >>> -- > > > >>> Michael Williamson > > > >>> 315-425-4045x230 > > > >>> www.criticallink.com > > > > > > > > _______________________________________________ > > > > Davinci-linux-open-source mailing list > > > > [email protected] > > > > > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100504/150011b2/attachment-0001.html > > > > ------------------------------ > > Message: 4 > Date: Tue, 04 May 2010 20:03:46 -0700 > From: Jimmy Blair <[email protected]> > To: [email protected] > Subject: DM365 audio -- bad PLL setting in tlv320aic3x driver > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > 44100 Hz audio plays slightly fast on the DM365. > This is because the tlv320aic3x driver is calculating > invalid PLL parameters for the WCLK. The parameters > it calculates are: > > pll_p = 1, pll_r = 1, pll_j = 3, pll_d = 3450 > > According to the codec datasheet, the value of J > should be greater than 3. The datasheet is correct. > The WCLK signal is unstable, bouncing between 44200 and 44500 Hz. > > I recalculated the parameters by hand, setting P to 2 > and got the following values: > > pll_p = 2, pll_r = 1, pll_j = 6, pll_d = 6901 > > These values gave a clean 44100 WCLK. > > > ------------------------------ > > Message: 5 > Date: Wed, 5 May 2010 10:59:47 +0530 > From: "Nori, Sekhar" <[email protected]> > To: Raffaele Recalcati <[email protected]> > Cc: "Cobb, Jeff" <[email protected]>, davinci-linux-open-source > <[email protected]>, "Allred, > Daniel" > <[email protected]> > Subject: RE: UBL Question > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > Hi Raffaele, > > On Tue, May 04, 2010 at 14:32:31, Raffaele Recalcati wrote: > > Hi Nori, > > > > > > > > There is a sourceforge project for UBL and serial flashing > > tools: > > > > http://sourceforge.net/projects/dvflashutils/ > > > > You could join this project to contribute. > > > > Thanks, > > Sekhar > > > > > > > > Is this project good also for dm365? > > Hmm, right. I can only find DM355 files here. > DM365 seems missing. Not sure if the files > just aren't showing up or DM365 support is > yet to be added. Let me ask around. > > Thanks, > Sekhar > > > > ------------------------------ > > _______________________________________________ > Davinci-linux-open-source mailing list > [email protected] > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > > > End of Davinci-linux-open-source Digest, Vol 53, Issue 17 > ********************************************************* >
_______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
