Resending due to rmk's vacation. On 05/24/13 15:05, Stephen Boyd wrote: > I've noticed another problem now that our caches are used. On MSM > we have TEXT_OFFSET set to at least 0x208000 if we've built-in > support for MSM8x60/8960. If I boot a kernel with the MSM code > built-in that requires the higher text offset, but I load my > compressed kernel below that address (such as 0x0) the > decompression fails. > > This happens because the page tables are written into the > compressed data region before we relocate ourself to a higher > location. > > Here's some ascii art to show the problem > > We start off at 0x0 > > 0x000000 +---------+ > | | > | zImage | > 0x208000 |---------| <- r4 (zreladdr) > | zImage | > 0x300000 +---------+ <- _edata > > Then we run far enough to call cache_on which goes ahead and > calls __setup_mmu and sets up our page tables. > > 0x008000 +---------+ > | | > | zImage | > | | > 0x204000 |---------| > | pgdir | > 0x208000 |---------| <- r4 (zreladdr) > | | > | zImage | > | | > 0x300000 +---------+ <- _edata > > This is bad because we just wrote our page tables into the > compressed data. Nobody notices though and we finish relocating > ourselves and then we call decompress_kernel() which fails > randomly. (BTW, why does error() sit in a while loop forever? We > can't get any information about why the decompression failed if > we have debug_ll enabled. I had to patch the error() routine to > not while loop forever to get that print after do_decompress to > be useful.) > > I see a few solutions. > > 1) Relocate with caches off and then turn on caches after we're > running in a location where we won't overwrite ourselves. > > 2) Have temporary page tables for the relocation phase that live > just below the location we're going to relocate to. > > 3) Force bootloaders loading these types of images to load the > zImage at least as high as the TEXT_OFFSET is compiled to. > > I don't think we can convince everyone that #3 is ok to do. I'm > leaning towards #2 since we get all the benefits of the cache > during the relocation phase but #1 is the obviously simple fix. > -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
