Dave, Thanks for thinking through different test scenarios.
> -----Original Message----- > From: David Brownell [mailto:[email protected]] > Sent: Thursday, March 19, 2009 4:58 PM > To: Narnakaje, Snehaprabha > Cc: [email protected] > Subject: Re: [PATCH 0/3] DaVinci NAND: Add support for 4-bit ECC on DM355 > EVM > > I've barely glanced at this so far ... but one question is > how to test this with an existing DM355. (Some of the code > can be reviewed without testing, of course.) > > My understanding is that if I run a kernel with these patches, > they'll want a "new style" badblock table, incompatible with > the one understood by current u-boot. So switching to this > code would be a one-way migration (except see option D below). You are right, if you have the u-boot 1.2.0 from the release (or flashed when it was shipped), you will have this compatibility issue between u-boot and kernel. U-Boot would write the BBT in the old legacy format and Kernel would try to read it in the new format and would not find the BBT. So the kernel goes through a scanning process and overwrites the BBT in the new format. When rebooted, the U-Boot will have this problem, so it goes through a scanning process and writes the BBT. So you will see both u-boot ad kernel scanning for the bad blocks and writing the BBT on each reboot. This could probably delay the boot up, but it should not stop us from testing the NAND driver in the kernel. (In fact, I have tested it this way, on one of the boards). The Kernel may detect and mark the UBL, U-Boot blocks as bad blocks while scanning through all blocks. > > Which means that testing will pretty much involve not using > the current NAND boot framework. Thus either > > (a) loading kernels via JTAG ... CCS only for now, though > maybe there's been progress on the OpenOCD front > > (b) or boot from UART or MMC/SD card, sort of awkward ... > > (c) new u-boot, replacing old one ... ideally 2009.01 > version, ready for mainline u-boot :) We have an updated u-boot version 1.2.0 as well as 1.3.4 with the support for new layout. We had started on a version for 2009.01. We will also work on posting dm355 patches on u-boot mailing list (denx tree), hopefully they will make it to the 2009.05 mainline u-boot. > > (d) put a different NAND chip in the socket, use that > with (c) ... but supports backward migration, by > putting the old chip there. The UBL might need to > be taught about this different NAND chip. In this case, the NAND programmer should program the UBL in old legacy format, so that the RBL (silicon Bootloader) can give control to UBL. The NAND programmer can program u-boot in either format. Writing it in the legacy format does not require changes to NAND programmer and UBL, where as to write it in the new standard format requires changes in both NAND programmer and UBL. If we do write U-Boot in the legacy format, we will not be able to update u-boot from u-boot. > > Is that correct? > > - Dave Thanks Sneha _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
