On 06/04/2014 10:45 PM, Yegor Yefremov wrote: > 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. Well it doesn't. It just uses whatever was setup by the bootloader or randomly allocated by gpmc_cs_request(). I'm working on fixing this up. I should be posting v2 of the GPMC refactor series by this week and you should be able to map the CS region as specified in the DT. Till then, maybe you can pre-configure CS0 in the bootloader to wherever you want or alternatively call gpmc_cs_remap() after the gpmc_cs_request() in gpmc_nand_init(); cheers, -roger -- 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
