On Wed, Jul 2, 2014 at 5:45 PM, Yegor Yefremov <yegorslists@xxxxxxxxxxxxxx> wrote: > On Fri, Jun 6, 2014 at 11:33 AM, Roger Quadros <rogerq@xxxxxx> wrote: >> On 06/05/2014 01:07 PM, Yegor Yefremov wrote: >>> On Thu, Jun 5, 2014 at 12:02 PM, Roger Quadros <rogerq@xxxxxx> wrote: >>>> 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(); >>> >>> I've found the stuff in bootloader and mapped NAND to 0x09000000, but >>> it didn't help. >>> >> >> Not sure why it didn't work. Was the CSVALID bit in GPMC_CONFIG7_0 register set? >> >> If you are daring enough ;), you could try out the cleaned up GPMC code where remapping >> should work. I still need to do some final touches before I can post it to mailing list. >> >> git@xxxxxxxxxx:rogerq/linux.git gpmc-3.16-temp >> >> There are some subtle changes you need to do to the GPMC/Nand node. e.g. adding compatible_id, >> 2nd register space and interrupts. For a working example, please see omap3-beagle.dts. >> >> And finally you need to enable CONFIG_TI_GPMC, which is a new kernel config option. > > Have attached my BDI2000 to the am335x and found out, that ROM boot > stops at 0x00020084. AFAIK it can be wrong address exception. Need to > debug further. Unfortunately I cannot use OpenOCD and my Jtagkey > debugger :-( > > Have also tried 3.16-rc3 without using flash and it freezes during > reboot from time time, but I can reboot via reset button. With 3.15 > and NAND reset button doesn't help. Btw how can I debug the kernel via JTAG? I've read, that one must activate JTAG clock or something like this. What is the proper way to do this in 3.15 - 3.16? 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