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 > > >
_______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
