>On Wednesday 04 June 2014 04:00 PM, Yegor Yefremov wrote:
[...]
>>> 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.
>
I'm not sure, if a NAND device is connected as CS0 how is ROM code
detecting it as NOR and proceeding for an XIP read.
As its mentioned in XIP boot process in AM335x TRM that if an invalid
boot image is found then ROM code falls back to next boot device
which is in this case MMC boot. A hung code here mean
- XIP boot is not failing OR
- ROM code is waiting on GPMC_WAIT0 pin a part of XIP read access.
So please check if the GPMC:
(1) This may happen because GPMC pins are shared for both NOR and
NAND so plz check conflicting pins as given in
AM335x TRM: Table 26-9. Pins Used for Non-Muxed NOR Boot
(Please see that GPMC_WAIT0 and GPMC_WAIT1 are pulled high on the board)
(2) Some SYSBOOT configuration might also be confusing ROM code.
If you are using x8 NAND device, then please try with setting
SYSBOOT[8] = 1
SYSBOOT[11: 10] == 01 or 11 (reserved values)
This should fail XIP boot and make the ROM code fall back
to next boot device which is MMC in this case.
with regards, pekon
��.n��������+%������w��{.n�����{�������ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
