Re: am335x: system doesn't reboot after flashing NAND

[Roger Quadros <rogerq@ti.com>]

On 06/04/2014 01:07 PM, Yegor Yefremov wrote:
> On Wed, Jun 4, 2014 at 11:49 AM, Roger Quadros <rogerq@ti.com> wrote:
>> On 06/04/2014 12:39 PM, Yegor Yefremov wrote:
>>> On Wed, Jun 4, 2014 at 10:54 AM, Sekhar Nori <nsekhar@ti.com> wrote:
>>>> On Wednesday 04 June 2014 01:55 PM, Yegor Yefremov wrote:
>>>>> On Wed, Jun 4, 2014 at 8:40 AM, Sekhar Nori <nsekhar@ti.com> wrote:
>>>>>> On Tuesday 03 June 2014 04:18 PM, Yegor Yefremov wrote:
>>>>>>> On Tue, Jun 3, 2014 at 9:57 AM, Yegor Yefremov
>>>>>>> <yegorslists@googlemail.com> 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.
>>>>>>>
>>>>>>> If I just mount ubifs partition as rootfs and change some files, I
>>>>>>> still can perform reboot and boot from MMC again. The issue seems to
>>>>>>> occur only, if I write to /dev/mtdblock directly. What can affect ROM
>>>>>>> boot so that it doesn't follow the boot sequence?
>>>>>>
>>>>>> Writing to sysboot bits in control_status register will make ROM change
>>>>>> boot sequence. Not sure why NAND driver should be changing these values.
>>>>>> Can you please verify that this register is indeed modified after the
>>>>>> NAND write?
>>>>>
>>>>> Can I read this register from userspace via debugfs? I can't find such
>>>>> entry so far.
>>>>
>>>> If not debugfs you can use devmem2[1] to read from userspace. You need
>>>> to provide physical address of the register.
>>>>
>>>>> I made another test: write to NAND and then make kexec. In this case I
>>>>> can successfully execute "reboot" afterwards.
>>>>
>>>> Okay. We need to monitor how sysboot values are changing between these
>>>> steps.
>>>
>>> devmem from busybox seems to work better. At least it delivers real
>>> values and not 0x0 as devmem2 does. Anyway the value doesn't change
>>> and looks as configured via resistors:
>>>
>>> # devmem 0x44E10040 32
>>> 0x00400304
>>>
>>> I wonder, where can I issue NAND reset from userspace? This is one of
>>> the commands the kernel does during the initialization.
>>
>> I'm not sure about external NAND chip, does it have a RESET via GPIO?
> 
> No.

OK. it seems the NAND chip can only be reset via the RESET command.

e.g. from the driver.
	nand_chip->cmdfunc(mtd, NAND_CMD_RESET, -1, -1);

but still it is unclear what really is the difference between
direct write to /dev/mtdblock vs filesystem write to rootfs.

does doing a sync before the reboot help? Just to make sure there are no
pending operations when the reboot happens.

cheers,
-roger

> 
>> However, you can reset the whole GPMC module via the
>> GPMC_SYSCONFIG. You could try to do that in the driver .shutdown path.
> 
> devmem 0x50000010 32 0x00000002
> 
> doesn't help.
> 
>> I'm not sure how this will help the hardreset case as hardware should reset
>> the GPMC module during a hardreset.
>>
>> Note that in the hwmod config, (mach-omap2/omap_hwmod_3xxx_data.c)
>> we set HWMOD_INIT_NO_RESET. it means that the kernel will never reset
>> the GPMC module during boot up to prevent loss of GPMC configuration
>> set up by the bootloader.
> 
> O.K.
>