On Mon, Mar 12, 2012 at 5:35 PM, Nicolas Pitre <nicolas.pi...@linaro.org> wrote: > On Mon, 12 Mar 2012, jonsm...@gmail.com wrote: > >> On Mon, Mar 12, 2012 at 4:18 PM, Nicolas Pitre <nicolas.pi...@linaro.org> >> wrote: >> > On Mon, 12 Mar 2012, jonsm...@gmail.com wrote: >> > >> >> I'm working on getting out of tree support for the NXP LPC31xx >> >> ARM926EJS based CPUs ready for submission. Everything was working fine >> >> on v3.2 but I lost the ability to boot with v3.3. The boot failure is >> >> very early in the boot process. I did a bisect and came up with: >> >> >> >> [6ee723a6570a897208b76ab3e9a495e9106b2f8c] ARM: simplify __iounmap() >> >> when dealing with section based mapping >> >> >> >> I tried to revert it but there have been a bunch of edits in this >> >> file. Not sure how to go about debugging this. >> > >> > The first thing to look for is any overlap in the virtual memory ranges >> > used in your struct map_desc array. No overlap is allowed anymore. >> >> There appear to be overlaps. I'll have to study things for a while to >> figure out how to eliminate them. This is from a three year old NXP >> BSP. We have a product based on the CPU and want to use a more recent >> kernel. >> >> They've defined multiple large peripheral regions... >> >> /* APB4 address range*/ >> #define IO_APB4_PHYS (0x17000000) >> #define IO_APB4_SIZE (0x00001000) >> >> { >> .virtual = io_p2v(IO_APB4_PHYS), >> .pfn = __phys_to_pfn(IO_APB4_PHYS), >> .length = IO_APB4_SIZE, >> .type = MT_DEVICE >> }, >> >> and then declared various devices inside of them... >> >> /* DMA registers address range*/ >> #define DMA_PHYS (0x17000000) >> #define IO_DMA_REG_PHYS (DMA_PHYS) >> #define IO_DMA_REG_SIZE (0x0000800) >> >> { >> .virtual = io_p2v(IO_DMA_REG_PHYS), >> .pfn = __phys_to_pfn(IO_DMA_REG_PHYS), >> .length = IO_DMA_REG_SIZE, >> .type = MT_DEVICE >> }, > > Just get rid of the map_desc entryes corresponding to subsets of a > larger entry that already covers them and you should be fine.
Thanks, that fixed it. Now I'm booting up to the point where I have printk which makes things a lot easier. > > > Nicolas -- Jon Smirl jonsm...@gmail.com _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev