What about writing a linux utility that reads and saves the current flash contents to disk/MMC/etc., and then reformats, writes the new bootloader and then optionally restores the other partitions.
I'm not sure if legacy support is as important as a clean transition. Kevin "Narnakaje, Snehaprabha" <[email protected]> writes: > Dave, > > Does it bring up the need to support legacy layout in the git, for existing > devices? > > What is your opinion on supporting the legacy layout on git, for existing > dm355 devices? > > Basically some of davinci-nand 4-bit APIs need to be rewritten to support the > legacy layout. Then the question is how are we going to let the user choose > between legacy vs. standard layouts - kconfig? I'm not sure, if we can check > this at run-time. > > Thanks > Sneha > >> -----Original Message----- >> From: [email protected] >> [mailto:[email protected]] On Behalf >> Of Narnakaje, Snehaprabha >> Sent: Thursday, March 19, 2009 5:41 PM >> To: David Brownell >> Cc: [email protected] >> Subject: RE: [PATCH 0/3] DaVinci NAND: Add support for 4-bit ECC on DM355 >> EVM >> >> 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 > _______________________________________________ > 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
