Message-ID: <9cf43bbe-898f-4b29-bd85-04f5320bce77@landley.net>
Date: Fri, 28 Feb 2025 16:19:12 -0600
From: Rob Landley <rob@...dley.net>
To: John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>,
 Artur Rojek <contact@...ur-rojek.eu>,
 Yoshinori Sato <ysato@...rs.sourceforge.jp>, Rich Felker <dalias@...c.org>,
 Daniel Lezcano <daniel.lezcano@...aro.org>,
 Thomas Gleixner <tglx@...utronix.de>, Uros Bizjak <ubizjak@...il.com>
Cc: Geert Uytterhoeven <geert+renesas@...der.be>,
 "D . Jeff Dionne" <jeff@...esemi.io>, linux-sh@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] J2 Turtle Board fixes

On 2/28/25 02:34, John Paul Adrian Glaubitz wrote:
> Hi Rob,
> 
> On Thu, 2025-02-27 at 21:03 -0600, Rob Landley wrote:
>> On 2/27/25 01:52, John Paul Adrian Glaubitz wrote:
>>> Hi Artur,
>>>
>>> On Sun, 2025-02-16 at 18:55 +0100, Artur Rojek wrote:
>>>> this series fixes boot issues and allows J2 Turtle Board to boot
>>>> upstream Linux again.
>>>>
>>>> Patch [1/2] enforces 8-byte alignment for the dtb offset.
>>>>
>>>> Patch [2/2] resolves a problem with PIT interrupts failing to register.
>>>
>>> I can confirm that this series makes my J2 Turtle Board boot again!
>>>
>>>> Even with the above fixes, Turtle Board is prone to occasional freezes
>>>> related to clock source transition from periodic to hrtimers. I however
>>>> decided to send those two patches ahead and debug the third issue at a
>>>> later time.
>>>
>>> Yep, it just got stuck for me right after these messages at my first boot attempt:
>>>
>>> clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
>>> futex hash table entries: 512 (order: 1, 8192 bytes, linear)
>>> NET: Registered PF_NETLINK/PF_ROUTE protocol family
>>> clocksource: Switched to clocksource jcore_pit_cs
>>>
>>> It boots past these messages on second attempt, although it's now stuck trying to start
>>> /init. However, it's still echoing <RETURN> strokes, so it might be an issue with Toybox.
>>
>> Which was fixed a year ago, which is why I told you to use the new
>> toolchain with a current musl-libc:
>>
>> http://lists.landley.net/pipermail/toybox-landley.net/2024-February/030040.html
>>
>> Unless you're hitting the OTHER issue I fixed last year...
>>
>> https://github.com/landley/toybox/commit/0b2d5c2bb3f1
> 
> I just downloaded the latest toolchain from:
> 
> https://landley.net/bin/toolchains/latest/sh2eb-linux-muslfdpic-cross.tar.xz
> 
> and the issue still persists.
> 
> Am I missing anything?

The march 2024 rebuild was in response to that Feb 2024 bugfix, so it 
_should_ have the fix? (I'm waiting for another musl release to rebuild 
them again...)

I just downloaded the toolchain currently at that URL and built mkroot 
and it worked for me:

Run /init as init process
sntp: time.google.com:123: Try again
Type exit when done.
$ cat /proc/version
Linux version 6.14.0-rc3 (landley@...ftwood) (sh2eb-linux-muslfdpic-cc 
(GCC) 11.2.0, GNU ld (GNU Binutils) 2.33.1) #1 SMP Fri Feb 28 15:47:36 
CST 2025

And the failure _without_ the fix was deterministic rather than 
intermittent, so...

Keep in mind the init script has a 3 second timeout trying to call sntp 
to set the clock, which will fail if the ethernet isn't connected (or no 
driver, or no internet...)

Rob

P.S. Speaking of intermittent, I hit that hang after "clocksource: 
Switched to clocksource jcore_pit_cs" on one attempt just now. I should 
sit down with the engineers next time I'm in japan and try to root cause 
it. The scheduler fires reliably, so it's _probably_ not a hardware 
issue? We've had Linux uptime of over a year, not just idle but running 
an energy monitoring app, so it's pretty stable in our systems...

Powered by blists - more mailing lists