[PATCH v5 01/44] dt-bindings: clock: Add new bindings for TI Davinci PLL clocks

Thu Jan 11 10:50:42 PST 2018

On Thu, Jan 11, 2018 at 12:29 PM, David Lechner <david at lechnology.com> wrote:
> On 01/11/2018 12:09 PM, Adam Ford wrote:
>>
>> On Thu, Jan 11, 2018 at 11:22 AM, David Lechner <david at lechnology.com>
>> wrote:
>>>
>>> On 01/11/2018 06:45 AM, Adam Ford wrote:
>>>>
>>>>
>>>> On Wed, Jan 10, 2018 at 8:50 PM, David Lechner <david at lechnology.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> On 01/10/2018 04:24 PM, Adam Ford wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I am available tomorrow to build and test patches against the
>>>>>> da850-evm.  I just need to know which version(s) to test.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Great. As per the cover letter:
>>>>>
>>>>> You can find a working branch with everything included in the
>>>>> "common-clk-v5"
>>>>> branch of https://github.com/dlech/ev3dev-kernel.git.
>>>>
>>>>
>>>>
>>>> I wasn't sure if things had changed after some of the dialog about the
>>>> bindings and device tree.
>>>
>>>
>>>
>>> Not yet. ;-)
>>>
>>>>
>>>> Here is my log with DEBUG_LL and CONFIG_EARLY_PRINTK set :
>>>>
>>>> Starting kernel ...
>>>>
>>>> Uncompressing Linux... done, booting the kernel.
>>>> Booting Linux on physical CPU 0x0
>>>> Linux version 4.15.0-rc4-g8564e0f (aford at ubuntu16) (gcc version 7.2.0
>>>> (Buildroot 2017.11.1-00021-g7b43660)) #2 PREEMPT Thu Jan 11 06:35:29
>>>> CST 2018
>>>> CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f
>>>> CPU: VIVT data cache, VIVT instruction cache
>>>> OF: fdt: Machine model: DA850/AM1808/OMAP-L138 EVM
>>>
>>>
>>>
>>> OK, using device tree...
>>
>>
>> Sorry, I thought I was supposed to. I retested using the board file,
>> but it also resulted in a hang.
>
>
> This was just intended as a note to self. But we do need to test both.
> Let's stick with the device tree boot first.
>
>>
>>>
>>>
>> [snip]
>>>
>>>
>>>
>>> If you are getting to this point, you probably don't need DEBUG_LL.
>>> It looks like "earlyprint" is not being passed to the command line
>>> anyway, so CONFIG_EARLY_PRINTK is not actually doing anything.
>>>
>>>> brd: module loaded
>>>> libphy: Fixed MDIO Bus: probed
>>>> davinci_mdio 1e24000.mdio: failed to get device clock
>>>> davinci_mdio: probe of 1e24000.mdio failed with error -2
>>>
>>>
>>>
>>> It looks like this needs a clock-names property in the device tree.
>>> Please make this change and try again:
>>>
>>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>>> index 08a9817..fd3e316 100644
>>> --- a/arch/arm/boot/dts/da850.dtsi
>>> +++ b/arch/arm/boot/dts/da850.dtsi
>>> @@ -713,6 +713,7 @@
>>>                          #size-cells = <0>;
>>>                          reg = <0x224000 0x1000>;
>>>                          clocks = <&psc1 5>;
>>> +                       clock-names = "fck";
>>>                          status = "disabled";
>>>                  };
>>>                  eth0: ethernet at 220000 {
>>>
>>>
>> [snip]
>>
>> I added your copy-names entry to my device tree and we get a login prompt.
>> :-)
>
>
> OK, great! It sounds like device tree is working after this change. I guess
> we can move on to non-device-tree.
>
>
>>
>>> I'm not sure why there is an error here. I'm using I2C0 on my board,
>>> so I am fairly confident that it is not a problem introduced by this
>>> series.
>>>
>>>> console [netcon0] enabled
>>>> netconsole: network logging started
>>>> davinci_emac 1e20000.ethernet: incompatible machine/device type for
>>>> reading mac address
>>>> hctosys: unable to open rtc device (rtc0)
>>>>
>>>
>>> What is normally the next line after this in a working boot?
>>>
>>> Also please try passing "clk_ignore_unused" to the kernel command line.
>>
>>
>> Here is the log.  There seems to be some garbled characters that don't
>> seem to appear.  I'm going to double check those against the stock
>> kernel.
>>
>>

[snip]

>
>
> If removing the "clk_ignore_unused" option causes the board to not boot,
> then we still have problems that need to be fixed, so please also test
> without this option.

Without this option, it still does not boot.  Without device tree it
hangs after:

[snip]

NET: Registered protocol family 17
Loading compiled-in X.509 certificates
console [netcon0] enabled
netconsole: network logging started
davinci_emac davinci_emac.1: using random MAC addr: 5e:38:1a:1f:4f:77
mmc0: host does not support reading read-only switch, assuming write-enable
hctosys: unable to open rtc device (rtc0)
mmc0: new high speed SDHC card at address b368

With device tree it hangs after:

[snip]
mmc0: host does not support reading read-only switch, assuming write-enable
mmc0: new high speed SDHC card at address b368
mmcblk0: mmc0:b368 00000 3.75 GiB
 mmcblk0: p1 p2
pca953x 0-0020: 0-0020 supply vcc not found, using dummy regulator
pca953x 0-0020: failed reading register
pca953x: probe of 0-0020 failed with error -121
console [netcon0] enabled
netconsole: network logging started
davinci_emac 1e20000.ethernet: incompatible machine/device type for
reading mac address
hctosys: unable to open rtc device (rtc0)

>
>> vbat: disabling
>> EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts:
>> (null)
>> VFS: Mounted root (ext4 filesystem) on device 179:2.
>> devtmpfs: mounted
>> Freeing unused kernel memory: 232K
>> This architecture does not have kernel memory protection.
>> EXT4-fs (mmcblk0p2): re-mounted. Opts: data=ordered
>> Starting logging: OK
>> Initializing random number generator... done.
>> Starting network: OK
>>
>> Welcome to Buildroot
>> buildroot login:
>>
>>
>>>
>>
>> However, I get a reboot failure:
>>
>> umount: devtmpfs busy - remounted read-only
>> EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
>> The system is going down NOW!
>> Sent SIGTERM to all processes
>> Sent SIGKILL to all processes
>> Requesting system reboot
>>
>> reboot: Restarting system
>> Reboot failed -- System halted
>>
>> I'll run more tests on a stock kernel to look at the reboot failure
>> and the uart noise.
>>
>> adam
>>
>
> The reboot failure probably has to do with the watchdog patches that
> are dependencies of this series.
>
>
> Also, see the cover letter about how to avoid garbled output. Either
> disable low level debugging or disable switching the parent of the
> async3 clock.

Disabling the low-level debugging eliminated the garbage.

If/when you have more to me to test, feel free to e-mail me. I am
available today and tomorrow to test.
>