Re: [PATCH] ARM: dts: Add am335x mcasp with l3 data port ranges

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

 




On 10/12/2018 17.12, Tero Kristo wrote:
> On 10/12/2018 16:50, Tony Lindgren wrote:
>> * Peter Ujfalusi <peter.ujfalusi@xxxxxx> [181210 13:45]:
>>> On 10/12/2018 11.53, Peter Ujfalusi wrote:
>>>> On 10/12/2018 9.05, Peter Ujfalusi wrote:
>>>> when looking for the non booting of am335x-evm-sk (nothing printed on
>>>> serial after stating kernel).
>>>>
>>>> However there is another issue: the kernel boots, but ethernet is not
>>>> working in the kernel. That is pointing to:
>>>> Author: Tero Kristo <t-kristo@xxxxxx>
>>>> 69fd70c7ff31d3f00833c472c3994a02bb0ab287
>>>> ARM: dts: am33xx: convert to use new clkctrl layout
>>>>
>>>> any idea what might causes these?
>>>
>>> Things definitely go wrong at 69fd70c7ff31d3f00833c472c3994a02bb0ab287:
>>>
>>> git checkout -b blah 69fd70c7ff31d3f00833c472c3994a02bb0ab287
>>> # can not mount the rootfs via nfs
>>>
>>> git revert 69fd70c7ff31d3f00833c472c3994a02bb0ab287
>>> # boots up via nfs rootfs.
>>>
>>> At commit 69fd70c7ff31d3f00833c472c3994a02bb0ab287 the bbb is not
>>> booting via nfs rootfs either.
>>>
>>> Can not find where the ethernet started to work after these on bbb, but
>>> it does work on top of next-20181207.
>>
>> Tero do you have any ideas on this one? Maybe a missing optional clock
>> somewhere?
> 
> No initial ideas, do we have any error logs for this?
> 
> Did you bisect the issue to 69fd70c7ff31d3?

Yep, I did.

> It is possible this is
> actually caused by something else, as there are some interesting
> dependencies between the patches that are being queued at the same point
> to the kernel now.

Could be, but:
git checkout -b blah 69fd70c7ff31d3f00833c472c3994a02bb0ab287
# can not mount the rootfs via nfs
git revert 69fd70c7ff31d3f00833c472c3994a02bb0ab287
# boots up via nfs rootfs.

When my HEAD is 69fd70c7ff31d3 and I revert only the topmost commit
(69fd70c7ff31d3), the board boots.

It could be that the ethernet not working is just a side effect of
something else going wrong, but this is the indication I have.

Nothing special in the logs, I can share the two bootlogs:
1. HEAD at 69fd70c7ff31d3
2. HEAD at 69fd70c7ff31d3 and reverting 69fd70c7ff31d3

But only tomorrow.

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux