On Thursday 19 March 2009, Narnakaje, Snehaprabha wrote: > > 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.
So when you want folk to actually use this, you should post some binaries (with matching sources) that will work with this. And say how to install it. > 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. That's good news. I detect that TI is getting more active about getting such support into community development trees ... applause! :) > > (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. So the ideal case would be a UBL written in the legacy format required by the RBL, but updated to expect the new format for the third stage loader (ABL/u-boot) and maybe recognize more NAND chips. - Dave _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
