On Wed, Jun 4, 2014 at 12:52 PM, Sekhar Nori <nsekhar@xxxxxx> wrote: > On Wednesday 04 June 2014 04:00 PM, Yegor Yefremov wrote: >> On Wed, Jun 4, 2014 at 12:20 PM, Sekhar Nori <nsekhar@xxxxxx> wrote: >>> On Wednesday 04 June 2014 03:11 PM, Yegor Yefremov wrote: >>>> On Wed, Jun 4, 2014 at 10:48 AM, Roger Quadros <rogerq@xxxxxx> wrote: >>>>> Hi, >>>>> >>>>> On 06/04/2014 11:25 AM, Yegor Yefremov wrote: >>>>>> On Wed, Jun 4, 2014 at 8:40 AM, Sekhar Nori <nsekhar@xxxxxx> wrote: >>>>>>> On Tuesday 03 June 2014 04:18 PM, Yegor Yefremov wrote: >>>>>>>> On Tue, Jun 3, 2014 at 9:57 AM, Yegor Yefremov >>>>>>>> <yegorslists@xxxxxxxxxxxxxx> wrote: >>>>>>>>> Kernel: 3.14, 3.15 (I haven't tried another kernels) >>>>>>>>> >>>>>>>>> As soon as I write something to my NAND flash (via cat image > >>>>>>>>> /dev/mtdblockx or ubiupdatevol) and make reboot or press a reset >>>>>>>>> button, I see only CCCCC and nothing happens before I make a power >>>>>>>>> cycle. Any idea? >>>>>>>> >>>>>>>> Just forgot to mention, that I was actually booting from MMC (mmc1). >>>>>>>> The boot sequence is UART0...XIP...MMC0...NAND. >>>>> >>>>> Can you try to get XIP out of the boot sequence and see if it works? >>>>> Maybe try to boot from mmc directly? >>>>> >>>>> This would prove that NAND/GPMC driver is leaving some state that doesn't >>>>> go well with the bootROM XIP. >>>> >>>> This configuration is soldered. It won't be easy to change. >>> >>> Most likely XIP is the issue if sysboot has not changed. >>> >>> The way ROM works for XIP boot is: >>> >>> 1) Set chip select 0 base address to 0x0800'0000 >>> 2) Read memory at 0x0800'0000 >>> 3) If something else other than 0x0 or ~0x0 is found, jump to >>> 0x0800'0000 and start executing. >>> >>> Can you check to see the contents of 0x0800'0000 before and after nand >>> write using mtdblock? >> >> Before writing: >> >> # devmem 0x08000000 32 >> 0xFFFFFFFF >> >> After writing: >> >> # devmem 0x08000000 32 >> 0xE0E0E0E0 > > Okay, so this is the cause of failure to boot. I am not sure what > operation by NAND driver causes this value to change. Perhaps you could > bisect a bit by dumping this address at various points during the write > operation? > > If you have a debugger it will become easy to do this. The 0x80000000 address seems to be the beginning of NAND region: ranges = <0 0 0x08000000 0x10000000>; /* CS0: NAND */ I've taken this example from am335x_evm.dts. I have tried to change the mapping to 0x90000000, but kernel still uses 0x80000000, Where in the kernel will "ranges" be evaluated? I'm digging thorugh arch/arm/mach-omap2/gpmc.c and gpmc-nand.c, but didn't really found the place. Yegor -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
