On Friday 09 January 2009, Narnakaje, Snehaprabha wrote: > Hi David, > > > > Using the dm9000 on the EVM for NFS root seems to work with > > some versions of UBL but not others. I don't know that anyone > > is looking at the problem there. > > I have started looking at this problem. It does fail for me and > I am using the UBL that came with the release. Do you happen to > know a UBL version with which dm9000 Ethernet works fine?
All I know is that it works for me and I have not touched the software that came with the board ... while it fails for Kevin, who has installed an updated UBL from TI. The issue might not be the UBL. Example, if you can boot from SD and then use the dm9000 with no problems (my situation!), but the same kernel can't boot from NFS, then something other than UBL is the issue. > > Using NAND on dm355 from mainline GIT is NOT advisable at the > > at the moment, at least with the EVM, because > > > > (a) the 2.6.10 kernel uses the 4-bit ECC hardware, as > > it most certainly should!!, but that's not yet > > supported in mainline, > > (b) more problematically (b1) it scatters that ECC > > data *inline* instead of storing it only in the > > OOB area, and (b2) expects U-Boot to do the same. > > > > The RBL uses that nonstandard ECC layout; but there's no real > > need for the UBL, U-Boot, or Linux to use it. > > The 2.6.10/2.6.18 (MV Pro 4.0/5.0) based releases use the > non-standard NAND layout which is similar to the RBL. We > are in the process of updating these releases to support > standard NAND layout (2048 + 64 vs. 512+16, 512+16, 512+16, > 512+16). Good to hear that! > It is a little tricky, due to the fact that the AEMIF > controller handles 4-bit HW ECC for every 512-byte read. Shouldn't be that hard; I looked at the Linux NAND code, and it seems there's an ECC chunking mechanism that will handle that automatically. Just say ECC is done in chunks of 512 bytes, and it looks like it'll call out to the ECC code as needed. (That might be new since the original 2.6.10 code; I didn't compare MTD stacks, but various updates to better support large block NAND have been merged since then.) The tricky part is needing to update all the code using NAND -- UBL, U-Boot and Linux -- ideally, with a simple update procedure that doesn't trash the old/"legacy" badblock tables. (I don't care about the filesystem data in the flash; that could be backed up over NFS or on SD card, when it matters.) Then it'd be easy to kick in UBIFS for rest of the NAND chip. > I am hoping, we do the standard layout on the GIT mainline, > instead of the non-standard (legacy) layout. As long as UBL > is written such that RBL can give control to it, we can have > the standard layout both in U-Boot and Kernel. Right. I have a hard time imagining that non-standard layout getting into mainline kernel *and* U-Boot repositories. - Dave _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
