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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

Thanks,
Sekhar
--
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




[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux