public inbox for linux-riscv@lists.infradead.org
 help / color / mirror / Atom feed
From: Samuel Holland <samuel.holland@sifive.com>
To: Emil Renner Berthing <emil.renner.berthing@canonical.com>,
	Anup Patel <apatel@ventanamicro.com>,
	Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Daniel Lezcano <daniel.lezcano@linaro.org>
Subject: Re: [PATCH v1 0/9] Fix Allwinner D1 boot regression
Date: Thu, 15 Aug 2024 10:59:37 -0500	[thread overview]
Message-ID: <085c8332-d7f1-41df-8854-bee06291ba83@sifive.com> (raw)
In-Reply-To: <CAJM55Z9kKqs-kMubsGsRkS6E2Y4ur1MmwD+1XFvGP=UVNrJvRg@mail.gmail.com>

Hi Emil,

On 2024-08-15 10:07 AM, Emil Renner Berthing wrote:
> Samuel Holland wrote:
>> On 2024-08-15 9:16 AM, Anup Patel wrote:
>>> On Thu, Aug 15, 2024 at 7:41 PM Thomas Gleixner <tglx@linutronix.de> wrote:
>>>>
>>>> On Thu, Aug 15 2024 at 08:32, Samuel Holland wrote:
>>>>> On 2024-08-15 8:16 AM, Thomas Gleixner wrote:
>>>>>> Yes. So the riscv timer is not working on this thing or it stops
>>>>>> somehow.
>>>>>
>>>>> That's correct. With the (firmware) devicetree that Emil is using, the OpenSBI
>>>>> firmware does not have a timer device, so it does not expose the (optional[1])
>>>>> SBI time extension, and sbi_set_timer() does nothing.
>>>>
>>>> Sigh. Does RISCV really have to repeat all mistakes which have been made
>>>> by x86, ARM and others before? It's known for decades that the kernel
>>>> relies on a working timer...
>>>
>>> My apologies for the delay in finding a fix for this issue.
>>>
>>> Almost all RISC-V platforms (except this one) have SBI Timer always
>>> available and Linux uses a better timer or Sstc extension whenever
>>> it is available.
>>
>> So this is the immediate solution: add the CLINT to the firmware devicetree so
>> that the SBI time extension works, and Linux will boot without any code changes,
>> albeit with a higher-overhead clockevent device.
> 
> But this will mean that you can't update your kernel to v6.9 or newer without
> reflashing OpenSBI and u-boot. That's still a regression right?

I suppose that depends on if you think the SBI time extension is (or should have
been) mandatory for platforms without Sstc. If the SBI time extension is
mandatory, then this is a firmware bug, and not really Linux's responsibility to
work around.

If the SBI time extension is not mandatory, then Linux needs to be able to
handle platforms where the S-mode visible timer is attached to an external
interrupt controller (PLIC or APLIC), so the irqchip driver needs to be loaded
before time_init() (timer_probe()). So in that case, the bug is a Linux
regression, and we would need to revert the platform driver conversion.

Regards,
Samuel


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2024-08-15 15:59 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-14 14:56 [PATCH v1 0/9] Fix Allwinner D1 boot regression Emil Renner Berthing
2024-08-14 14:56 ` [PATCH v1 1/9] Revert "irqchip/sifive-plic: Chain to parent IRQ after handlers are ready" Emil Renner Berthing
2024-08-14 14:56 ` [PATCH v1 2/9] Revert "irqchip/sifive-plic: Avoid explicit cpumask allocation on stack" Emil Renner Berthing
2024-08-14 14:56 ` [PATCH v1 3/9] Revert "irqchip/sifive-plic: Improve locking safety by using irqsave/irqrestore" Emil Renner Berthing
2024-08-14 14:56 ` [PATCH v1 4/9] Revert "irqchip/sifive-plic: Parse number of interrupts and contexts early in plic_probe()" Emil Renner Berthing
2024-08-14 14:56 ` [PATCH v1 5/9] Revert "irqchip/sifive-plic: Cleanup PLIC contexts upon irqdomain creation failure" Emil Renner Berthing
2024-08-14 14:56 ` [PATCH v1 6/9] Revert "irqchip/sifive-plic: Use riscv_get_intc_hwnode() to get parent fwnode" Emil Renner Berthing
2024-08-14 14:56 ` [PATCH v1 7/9] Revert "irqchip/sifive-plic: Use devm_xyz() for managed allocation" Emil Renner Berthing
2024-08-14 14:56 ` [PATCH v1 8/9] Revert "irqchip/sifive-plic: Use dev_xyz() in-place of pr_xyz()" Emil Renner Berthing
2024-08-14 14:56 ` [PATCH v1 9/9] Revert "irqchip/sifive-plic: Convert PLIC driver into a platform driver" Emil Renner Berthing
2024-08-14 17:30 ` [PATCH v1 0/9] Fix Allwinner D1 boot regression Thomas Gleixner
2024-08-15 10:29   ` Emil Renner Berthing
2024-08-15 11:44     ` Thomas Gleixner
2024-08-15 12:04       ` Emil Renner Berthing
2024-08-15 12:14         ` Emil Renner Berthing
2024-08-15 13:16           ` Thomas Gleixner
2024-08-15 13:32             ` Samuel Holland
2024-08-15 14:11               ` Thomas Gleixner
2024-08-15 14:16                 ` Anup Patel
2024-08-15 14:41                   ` Samuel Holland
2024-08-15 15:07                     ` Emil Renner Berthing
2024-08-15 15:59                       ` Samuel Holland [this message]
2024-08-15 17:51                         ` Palmer Dabbelt
2024-08-15 18:04                           ` Thomas Gleixner
2024-08-16  6:13                           ` Icenowy Zheng
2024-08-15 15:14                     ` Thomas Gleixner
2024-08-15 14:30               ` Anup Patel
2024-08-15 15:03                 ` Samuel Holland
2024-08-15 15:53                   ` Anup Patel
2024-08-16  6:09                 ` Icenowy Zheng
2024-08-15 13:35             ` Emil Renner Berthing
2024-08-15 17:51   ` Palmer Dabbelt
2024-08-15 18:10     ` Thomas Gleixner
2024-08-15 23:04       ` Palmer Dabbelt
2024-08-16  6:15     ` Icenowy Zheng
2024-08-18 14:47 ` Palmer Dabbelt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=085c8332-d7f1-41df-8854-bee06291ba83@sifive.com \
    --to=samuel.holland@sifive.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=apatel@ventanamicro.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=emil.renner.berthing@canonical.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox