[Gta04-owner] Kernel 3.14-rc5 for GTA04

Belisko Marek marek.belisko at gmail.com
Fri Mar 7 20:27:20 CET 2014

On Fri, Mar 7, 2014 at 8:22 PM, Dr. H. Nikolaus Schaller
<hns at goldelico.com> wrote:
> Am 07.03.2014 um 20:14 schrieb Belisko Marek:
>> On Fri, Mar 7, 2014 at 6:00 PM, Dr. H. Nikolaus Schaller
>> <hns at goldelico.com> wrote:
>>> Am 07.03.2014 um 17:41 schrieb mx4812 at arcor.de:
>>>>>> Did you check if the delay loop is correctly calibrated?
>>>>>> Somewhere the kernel says: "Calibrating delay loop" and prints out
>>>>>> some value: lpj=11969856
>>>>> here is the 3.14 kernel
>>>>> [    0.001495] Calibrating delay loop... 594.73 BogoMIPS (lpj=2973696)
>>>>> and here the 3.12 kernel
>>>>> [    0.000274] Calibrating delay loop... 319.48 BogoMIPS (lpj=1597440)
>>> And the SD card with the 3.12 kernel on the board where I did test the 3.14:
>>> [    0.000305] Calibrating delay loop... 334.23 BogoMIPS (lpj=1671168)
>>> So there is a small difference - as expected. But not the factor 2.
>>>> I remember from previous notebooks that I used that such timings also had the tendency
>>>> to get messed up after resume events (slugishness and slooweerr soouunnd aaoouutpuut).
>>> Interesting!
>>> It may also explain why the OTG port is detecting a cable but not working. If some clock
>>> is not initialized correctly it is simply not running the USB protocols correctly.
>>> What makes me wonder a lot is why it is different at all.
>>> It is the same hardware and the same message right at the beginning of a fresh boot (not
>>> even a resume).
>>> And I have not found a significant patch or diff to 3.12.7 - where it works.
>>> The only difference is that we now boot with device tree and have no board file
>>> (well, we use the board-generic.c instead of board-gta04.c).
>> I don't think it's caused by bogomips. Booting with sme devicetree
>> work fine on linux-next (without our
>> changes).
> Well, it may indeed not be the bogo mips but something in the device tree which
> makes a clock difference. Maybe one of our patches conflicts with something fixed
> differently in mainline linux-next.
If I took all our DT patches and apply them in linux-next it will boot
and works fine.
> So are you able to boot linux-next w/o our changes?
> Then, we should be able to do sort of bisect/rebase/cherry-pick our patches and find
> out which one breaks things. It may not work with standard git bisect.
Yes this could be really hard to track which commit is causing it. But
maybe we can get our changes (in patches)
apply them one by one on top of linux-next and check which cause troubles.
> BR,
> Nikolaus
> _______________________________________________
> Gta04-owner mailing list
> Gta04-owner at goldelico.com
> http://lists.goldelico.com/mailman/listinfo/gta04-owner



as simple and primitive as possible
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com

More information about the Gta04-owner mailing list