am335x: system doesn't reboot after flashing NAND

am335x: system doesn't reboot after flashing NAND

[Yegor Yefremov]

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?

Yegor

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

[Yegor Yefremov]

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?

Yegor

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

[Sekhar Nori]

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?

Thanks,
Sekhar

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

[Yegor Yefremov]

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.

I made another test: write to NAND and then make kexec. In this case I
can successfully execute "reboot" afterwards.

Yegor

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

[Roger Quadros]

Hi,

On 06/04/2014 11:25 AM, 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.

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.

cheers,
-roger

>>>
>>> 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.
> 
> I made another test: write to NAND and then make kexec. In this case I
> can successfully execute "reboot" afterwards.
> 
> Yegor
> 

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

[Yegor Yefremov]

On Wed, Jun 4, 2014 at 10:48 AM, Roger Quadros <rogerq@ti.com> wrote:
> Hi,
>
> On 06/04/2014 11:25 AM, 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.
>
> 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.

Yegor

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

[Sekhar Nori]

On Wednesday 04 June 2014 03:11 PM, Yegor Yefremov wrote:
> On Wed, Jun 4, 2014 at 10:48 AM, Roger Quadros <rogerq@ti.com> wrote:
>> Hi,
>>
>> On 06/04/2014 11:25 AM, 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.
>>
>> 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?

Thanks,
Sekhar

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

[Yegor Yefremov]

On Wed, Jun 4, 2014 at 12:20 PM, Sekhar Nori <nsekhar@ti.com> wrote:
> On Wednesday 04 June 2014 03:11 PM, Yegor Yefremov wrote:
>> On Wed, Jun 4, 2014 at 10:48 AM, Roger Quadros <rogerq@ti.com> wrote:
>>> Hi,
>>>
>>> On 06/04/2014 11:25 AM, 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.
>>>
>>> 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

And I can't change it via devmem afterwards.

Yegor

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

[Sekhar Nori]

On Wednesday 04 June 2014 04:00 PM, Yegor Yefremov wrote:
> On Wed, Jun 4, 2014 at 12:20 PM, Sekhar Nori <nsekhar@ti.com> wrote:
>> On Wednesday 04 June 2014 03:11 PM, Yegor Yefremov wrote:
>>> On Wed, Jun 4, 2014 at 10:48 AM, Roger Quadros <rogerq@ti.com> wrote:
>>>> Hi,
>>>>
>>>> On 06/04/2014 11:25 AM, 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.
>>>>
>>>> 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

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

[Gupta, Pekon]

>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

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

[Yegor Yefremov]

On Wed, Jun 4, 2014 at 1:49 PM, Gupta, Pekon <pekon@ti.com> wrote:
>>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)

The system has only 8-bit NAND

        nandflash_pins_s0: nandflash_pins_s0 {
                pinctrl-single,pins = <
                        0x0 (PIN_INPUT_PULLUP | MUX_MODE0)      /*
gpmc_ad0.gpmc_ad0 */
                        0x4 (PIN_INPUT_PULLUP | MUX_MODE0)      /*
gpmc_ad1.gpmc_ad1 */
                        0x8 (PIN_INPUT_PULLUP | MUX_MODE0)      /*
gpmc_ad2.gpmc_ad2 */
                        0xc (PIN_INPUT_PULLUP | MUX_MODE0)      /*
gpmc_ad3.gpmc_ad3 */
                        0x10 (PIN_INPUT_PULLUP | MUX_MODE0)     /*
gpmc_ad4.gpmc_ad4 */
                        0x14 (PIN_INPUT_PULLUP | MUX_MODE0)     /*
gpmc_ad5.gpmc_ad5 */
                        0x18 (PIN_INPUT_PULLUP | MUX_MODE0)     /*
gpmc_ad6.gpmc_ad6 */
                        0x1c (PIN_INPUT_PULLUP | MUX_MODE0)     /*
gpmc_ad7.gpmc_ad7 */
                        0x70 (PIN_INPUT_PULLUP | MUX_MODE0)     /*
gpmc_wait0.gpmc_wait0 */
                        0x74 (PIN_INPUT_PULLUP | MUX_MODE0)     /*
gpmc_wpn.gpmc_wpn */
                        0x7c (PIN_OUTPUT | MUX_MODE0)           /*
gpmc_csn0.gpmc_csn0  */
                        0x90 (PIN_OUTPUT | MUX_MODE0)           /*
gpmc_advn_ale.gpmc_advn_ale */
                        0x94 (PIN_OUTPUT | MUX_MODE0)           /*
gpmc_oen_ren.gpmc_oen_ren */
                        0x98 (PIN_OUTPUT | MUX_MODE0)           /*
gpmc_wen.gpmc_wen */
                        0x9c (PIN_OUTPUT | MUX_MODE0)           /*
gpmc_be0n_cle.gpmc_be0n_cle */
                >;
&elm {
        status = "okay";
};

&gpmc {
        pinctrl-names = "default";
        pinctrl-0 = <&nandflash_pins_s0>;
        ranges = <0 0 0x08000000 0x10000000>;   /* CS0: NAND */
        status = "okay";

        nand@0,0 {
                reg = <0 0 0>; /* CS0, offset 0 */
                nand-bus-width = <8>;
                ti,nand-ecc-opt = "bch8";
                ti,nand-xfer-type = "polled";

                gpmc,device-nand = "true";
                gpmc,device-width = <1>;
                gpmc,sync-clk-ps = <0>;
                gpmc,cs-on-ns = <0>;
                gpmc,cs-rd-off-ns = <44>;
                gpmc,cs-wr-off-ns = <44>;
                gpmc,adv-on-ns = <6>;
                gpmc,adv-rd-off-ns = <34>;
                gpmc,adv-wr-off-ns = <44>;
                gpmc,we-on-ns = <0>;
                gpmc,we-off-ns = <40>;
                gpmc,oe-on-ns = <0>;
                gpmc,oe-off-ns = <54>;
                gpmc,access-ns = <64>;
                gpmc,rd-cycle-ns = <82>;
                gpmc,wr-cycle-ns = <82>;
                gpmc,wait-on-read = "true";
                gpmc,wait-on-write = "true";
                gpmc,bus-turnaround-ns = <0>;
                gpmc,cycle2cycle-delay-ns = <0>;
                gpmc,clk-activation-ns = <0>;
                gpmc,wait-monitoring-ns = <0>;
                gpmc,wr-access-ns = <40>;
                gpmc,wr-data-mux-bus-ns = <0>;

                #address-cells = <1>;
                #size-cells = <1>;
                elm_id = <&elm>;

                /* MTD partition table */
                partition@0 {
                       label = "MLO";
                        reg = <0x00000000 0x000020000>;
                };

                partition@1 {
                        label = "U-boot";
                        reg = <0x00020000 0x001e0000>;
                };

                partition@2 {
                        label = "DTB";
                        reg = <0x00200000 0x000020000>;
                };

                partition@3 {
                        label = "environment";
                        reg = <0x00220000 0x000020000>;
                };

                partition@4 {
                        label = "Kernel";
                        reg = <0x00240000 0x00600000>;
                };

                partition@5 {
                        label = "File-System";
                        reg = <0x00840000 0x0C360000>;
                };
        };
};

GPMC_WAIT0 has a pull-up and when I measured it, the signal was high i.e. ready.

> (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.

The stuff is soldered. I'll see, what I can do.

Yegor

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

[Yegor Yefremov]

On Wed, Jun 4, 2014 at 12:52 PM, Sekhar Nori <nsekhar@ti.com> wrote:
> On Wednesday 04 June 2014 04:00 PM, Yegor Yefremov wrote:
>> On Wed, Jun 4, 2014 at 12:20 PM, Sekhar Nori <nsekhar@ti.com> wrote:
>>> On Wednesday 04 June 2014 03:11 PM, Yegor Yefremov wrote:
>>>> On Wed, Jun 4, 2014 at 10:48 AM, Roger Quadros <rogerq@ti.com> wrote:
>>>>> Hi,
>>>>>
>>>>> On 06/04/2014 11:25 AM, 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.
>>>>>
>>>>> 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.

Yegor

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

[Roger Quadros]

On 06/04/2014 10:45 PM, Yegor Yefremov wrote:
> On Wed, Jun 4, 2014 at 12:52 PM, Sekhar Nori <nsekhar@ti.com> wrote:
>> On Wednesday 04 June 2014 04:00 PM, Yegor Yefremov wrote:
>>> On Wed, Jun 4, 2014 at 12:20 PM, Sekhar Nori <nsekhar@ti.com> wrote:
>>>> On Wednesday 04 June 2014 03:11 PM, Yegor Yefremov wrote:
>>>>> On Wed, Jun 4, 2014 at 10:48 AM, Roger Quadros <rogerq@ti.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 06/04/2014 11:25 AM, 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.
>>>>>>
>>>>>> 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

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

[Yegor Yefremov]

On Thu, Jun 5, 2014 at 12:02 PM, Roger Quadros <rogerq@ti.com> wrote:
> On 06/04/2014 10:45 PM, Yegor Yefremov wrote:
>> On Wed, Jun 4, 2014 at 12:52 PM, Sekhar Nori <nsekhar@ti.com> wrote:
>>> On Wednesday 04 June 2014 04:00 PM, Yegor Yefremov wrote:
>>>> On Wed, Jun 4, 2014 at 12:20 PM, Sekhar Nori <nsekhar@ti.com> wrote:
>>>>> On Wednesday 04 June 2014 03:11 PM, Yegor Yefremov wrote:
>>>>>> On Wed, Jun 4, 2014 at 10:48 AM, Roger Quadros <rogerq@ti.com> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 06/04/2014 11:25 AM, 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.
>>>>>>>
>>>>>>> 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.

Yegor

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

[Roger Quadros]

On 06/05/2014 01:07 PM, Yegor Yefremov wrote:
> On Thu, Jun 5, 2014 at 12:02 PM, Roger Quadros <rogerq@ti.com> wrote:
>> On 06/04/2014 10:45 PM, Yegor Yefremov wrote:
>>> On Wed, Jun 4, 2014 at 12:52 PM, Sekhar Nori <nsekhar@ti.com> wrote:
>>>> On Wednesday 04 June 2014 04:00 PM, Yegor Yefremov wrote:
>>>>> On Wed, Jun 4, 2014 at 12:20 PM, Sekhar Nori <nsekhar@ti.com> wrote:
>>>>>> On Wednesday 04 June 2014 03:11 PM, Yegor Yefremov wrote:
>>>>>>> On Wed, Jun 4, 2014 at 10:48 AM, Roger Quadros <rogerq@ti.com> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On 06/04/2014 11:25 AM, 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.
>>>>>>>>
>>>>>>>> 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@github.com: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.

cheers,
-roger

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

[jean-philippe francois]

2014-06-06 11:33 GMT+02:00 Roger Quadros <rogerq@ti.com>:
> On 06/05/2014 01:07 PM, Yegor Yefremov wrote:
>> On Thu, Jun 5, 2014 at 12:02 PM, Roger Quadros <rogerq@ti.com> wrote:
>>> On 06/04/2014 10:45 PM, Yegor Yefremov wrote:
>>>> On Wed, Jun 4, 2014 at 12:52 PM, Sekhar Nori <nsekhar@ti.com> wrote:
>>>>> On Wednesday 04 June 2014 04:00 PM, Yegor Yefremov wrote:
>>>>>> On Wed, Jun 4, 2014 at 12:20 PM, Sekhar Nori <nsekhar@ti.com> wrote:
>>>>>>> On Wednesday 04 June 2014 03:11 PM, Yegor Yefremov wrote:
>>>>>>>> On Wed, Jun 4, 2014 at 10:48 AM, Roger Quadros <rogerq@ti.com> wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> On 06/04/2014 11:25 AM, 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?

What is your nand partitioning ?
Modifying the mapping in linux won't change anything when you reboot.
If you write to some mtdx and another mtdx is modified, you
effectively are in trouble.


>>>>>>>>>>>>
>>>>>>>>>>>> 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@github.com: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.
>
> cheers,
> -roger
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Yegor Yefremov]

On Fri, Jun 6, 2014 at 11:33 AM, Roger Quadros <rogerq@ti.com> wrote:
> On 06/05/2014 01:07 PM, Yegor Yefremov wrote:
>> On Thu, Jun 5, 2014 at 12:02 PM, Roger Quadros <rogerq@ti.com> wrote:
>>> On 06/04/2014 10:45 PM, Yegor Yefremov wrote:
>>>> On Wed, Jun 4, 2014 at 12:52 PM, Sekhar Nori <nsekhar@ti.com> wrote:
>>>>> On Wednesday 04 June 2014 04:00 PM, Yegor Yefremov wrote:
>>>>>> On Wed, Jun 4, 2014 at 12:20 PM, Sekhar Nori <nsekhar@ti.com> wrote:
>>>>>>> On Wednesday 04 June 2014 03:11 PM, Yegor Yefremov wrote:
>>>>>>>> On Wed, Jun 4, 2014 at 10:48 AM, Roger Quadros <rogerq@ti.com> wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> On 06/04/2014 11:25 AM, 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.
>>>>>>>>>
>>>>>>>>> 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@github.com: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.

Yegor

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

[Yegor Yefremov]

On Wed, Jul 2, 2014 at 5:45 PM, Yegor Yefremov
<yegorslists@googlemail.com> wrote:
> On Fri, Jun 6, 2014 at 11:33 AM, Roger Quadros <rogerq@ti.com> wrote:
>> On 06/05/2014 01:07 PM, Yegor Yefremov wrote:
>>> On Thu, Jun 5, 2014 at 12:02 PM, Roger Quadros <rogerq@ti.com> wrote:
>>>> On 06/04/2014 10:45 PM, Yegor Yefremov wrote:
>>>>> On Wed, Jun 4, 2014 at 12:52 PM, Sekhar Nori <nsekhar@ti.com> wrote:
>>>>>> On Wednesday 04 June 2014 04:00 PM, Yegor Yefremov wrote:
>>>>>>> On Wed, Jun 4, 2014 at 12:20 PM, Sekhar Nori <nsekhar@ti.com> wrote:
>>>>>>>> On Wednesday 04 June 2014 03:11 PM, Yegor Yefremov wrote:
>>>>>>>>> On Wed, Jun 4, 2014 at 10:48 AM, Roger Quadros <rogerq@ti.com> wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> On 06/04/2014 11:25 AM, 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.
>>>>>>>>>>
>>>>>>>>>> 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@github.com: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

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

[Sekhar Nori]

On Thursday 03 July 2014 02:45 AM, Yegor Yefremov wrote:
> 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?

Please try with Lokesh's patch here:

http://www.spinics.net/lists/arm-kernel/msg320801.html

Thanks,
Sekhar

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

[Roger Quadros]

+ Nishant.

On 07/02/2014 06:45 PM, Yegor Yefremov wrote:
> On Fri, Jun 6, 2014 at 11:33 AM, Roger Quadros <rogerq@ti.com> wrote:
>> On 06/05/2014 01:07 PM, Yegor Yefremov wrote:
>>> On Thu, Jun 5, 2014 at 12:02 PM, Roger Quadros <rogerq@ti.com> wrote:
>>>> On 06/04/2014 10:45 PM, Yegor Yefremov wrote:
>>>>> On Wed, Jun 4, 2014 at 12:52 PM, Sekhar Nori <nsekhar@ti.com> wrote:
>>>>>> On Wednesday 04 June 2014 04:00 PM, Yegor Yefremov wrote:
>>>>>>> On Wed, Jun 4, 2014 at 12:20 PM, Sekhar Nori <nsekhar@ti.com> wrote:
>>>>>>>> On Wednesday 04 June 2014 03:11 PM, Yegor Yefremov wrote:
>>>>>>>>> On Wed, Jun 4, 2014 at 10:48 AM, Roger Quadros <rogerq@ti.com> wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> On 06/04/2014 11:25 AM, 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.
>>>>>>>>>>
>>>>>>>>>> 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@github.com: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.

OK, so it is not NAND related but more soft reboot related.

Have you checked that all power supplies are stable when you soft reboot?

cheers,
-roger

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

[Gupta, Pekon]

Hi Roger, Yegor,

>From: Quadros, Roger
>>On 06/04/2014 10:45 PM, Yegor Yefremov wrote:
[...]

>>
>> 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

I had a fix for this gpmc_cs_remap issue, it worked for beaglebone NOR,
but havn't checked on other devices. So please see if it works for you.

However, I don't suspect XIP boot here because even if CPU is detecting
garbage data while reading from 0x80000000 it won't find a valid image
header there, and so XIP boot should have failed, and boot sequence
should fall back to MMC. It shouldn't have hung.

Still you can try below patch for gpmc_cs_remap().

---------------

From: Pekon Gupta <pekon@ti.com>
Date: Fri, 9 May 2014 15:17:32 +0530
Subject: [PATCH 12/14] ARM: OMAP2+: fix gpmc_cs_remap: re-allocating
 chip-select address space based on DT

Each GPMC chip-select needs to be configured for (base-address,CS-size) so that
GPMC understands the address-space allocated to device connected externally.
These chip-select configurations (base-address, CS-size) follow some basic
mapping rules like:
- The CS size is programmable from 256 MBytes to 16 MBytes (must be a power of 2)
  and is defined by the mask field. Attached memory smaller than the programmed
  CS region size is accessed through the entire CS region (aliasing).
- The programmed 'base-address' must be aligned to the 'CS-size' boundary and
  be a power of 2.
- Valid CS-size values are {256MB(max), 128MB, 64MB, 32MB and 16MB (min)}
  Any intermediate values creates holes in the chip-select memory-map.

This patch adds above checks in gpmc_cs_remap() so that any invalid value
passed by DT <reg> property can be filtered before actually allocating the
address space.

Signed-off-by: Pekon Gupta <pekon@ti.com>
---
 arch/arm/mach-omap2/gpmc.c | 42 +++++++++++++++++++++++++++++-------------
 1 file changed, 29 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 4fc4963..224550e 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -521,26 +521,42 @@ static int gpmc_cs_delete_mem(int cs)
  * "base". Returns 0 on success and appropriate negative error code
  * on failure.
  */
-static int gpmc_cs_remap(int cs, u32 base)
+static int gpmc_cs_remap(int cs, u32 base, u32 size)
 {
 	int ret;
-	u32 old_base, size;
 
 	if (cs > gpmc_cs_num) {
 		pr_err("%s: requested chip-select is disabled\n", __func__);
 		return -ENODEV;
 	}
 
-	/*
-	 * Make sure we ignore any device offsets from the GPMC partition
-	 * allocated for the chip select and that the new base confirms
-	 * to the GPMC 16MB minimum granularity.
-	 */ 
-	base &= ~(SZ_16M - 1);
-
-	gpmc_cs_get_memconf(cs, &old_base, &size);
-	if (base == old_base)
-		return 0;
+	/* allocate enough address-space under GPMC chip-select to device */
+	if (size > SZ_256M) {
+		pr_err("%s: memory device > 256MB not supported\n", __func__);
+		return -ENODEV;
+	} else if (size > SZ_128M) {
+		WARN((size != SZ_256M), "cs=%d: allocating 256MB\n", cs);
+		size = SZ_256M;
+	} else if (size > SZ_64M) {
+		WARN((size != SZ_128M), "cs=%d: allocating 128MB\n", cs);
+		size = SZ_128M;
+	} else if (size > SZ_32M) {
+		WARN((size != SZ_64M), "cs=%d: allocating 64MB\n", cs);
+		size = SZ_64M;
+	} else if (size > SZ_16M) {
+		WARN((size != SZ_32M), "cs=%d: allocating 64MB\n", cs);
+		size = SZ_32M;
+	} else {
+		WARN((size != SZ_16M), "cs=%d: allocating 64MB\n", cs);
+		size = SZ_16M;
+	}
+
+	/* base address should be aligned with address-space size */
+	if (base & (size - 1)) {
+		pr_err("base-addr=%x should be aligned to size=%x", base, size);
+		return -EINVAL;
+	}
+
 	gpmc_cs_disable_mem(cs);
 	ret = gpmc_cs_delete_mem(cs);
 	if (ret < 0)
@@ -1551,7 +1567,7 @@ static int gpmc_probe_generic_child(struct platform_device *pdev,
 	 * CS to this location. Once DT migration is complete should
 	 * just make gpmc_cs_request() map a specific address.
 	 */
-	ret = gpmc_cs_remap(cs, res.start);
+	ret = gpmc_cs_remap(cs, res.start, resource_size(&res));
 	if (ret < 0) {
 		dev_err(&pdev->dev, "cannot remap GPMC CS %d to %pa\n",
 			cs, &res.start);
-- 
1.8.5.1.163.gd7aced9

------------


with regards, pekon

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

[Gupta, Pekon]

Hi Yegor,

>From: Gupta, Pekon
>
>However, I don't suspect XIP boot here because even if CPU is detecting
>garbage data while reading from 0x80000000 it won't find a valid image
>header there, and so XIP boot should have failed, and boot sequence
>should fall back to MMC. It shouldn't have hung.
>
I checked with Sekhar on this, and my understanding was incorrect here.
There is no image verification (or marker) check done for XIP boot.
As mentioned by Sekhar earlier, XIP boot just checks for non-0x0 and
non-0xFF data on 0x80000000. And it treats any value as valid code image
and starts executing it.
So, please ignore my above statement.


with regards, pekon

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

[Sekhar Nori]

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.

Thanks,
Sekhar

[1] www.lartmaker.nl/lartware/port/devmem2.c

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

[Yegor Yefremov]

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.

Yegor

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

[Roger Quadros]

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?
However, you can reset the whole GPMC module via the
GPMC_SYSCONFIG. You could try to do that in the driver .shutdown path.

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.

cheers,
-roger

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

[Yegor Yefremov]

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.

> 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.

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

[Roger Quadros]

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.
> 

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

[Yegor Yefremov]

On Wed, Jun 4, 2014 at 12:21 PM, Roger Quadros <rogerq@ti.com> wrote:
> 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.

No. sync returns immediately and reboot still fails.

Yegor