Re: 5.2-rc1 boot on Unleashed

From: Troy Benjegerdes <troy.benjegerdes@sifive.com>
To: Atish Patra <atish.patra@wdc.com>
Cc: "Anup Patel" <Anup.Patel@wdc.com>,
	"Björn Töpel" <bjorn.topel@gmail.com>,
	"linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>,
	"Palmer Dabbelt" <palmer@sifive.com>,
	"Paul Walmsley" <paul.walmsley@sifive.com>
Subject: Re: 5.2-rc1 boot on Unleashed
Date: Fri, 24 May 2019 09:46:41 -0500	[thread overview]
Message-ID: <2818D3E3-3BDB-442B-822D-0FD221BCCA05@sifive.com> (raw)
In-Reply-To: <aac8c9b2-1b8d-e87d-88a5-f13222004a88@wdc.com>

> On May 23, 2019, at 10:59 PM, Atish Patra <atish.patra@wdc.com> wrote:
> 
> On 5/23/19 5:23 PM, Troy Benjegerdes wrote:
>>> On May 22, 2019, at 3:43 PM, Paul Walmsley <paul.walmsley@sifive.com> wrote:
>>> 
>>> + Anup, Troy
>>> 
>>> On Wed, 22 May 2019, Atish Patra wrote:
>>> 
>>>> On 5/22/19 9:42 AM, Paul Walmsley wrote:
>>>>> Am checking on this now and hope to have some conclusion on it this week.
>>>> 
>>>> Thanks. Any chance you can take a look at the U-Boot clock driver to patch it
>>>> as per the DT changes ?
>>> 
>>> I probably won't have the chance to get to it for a while.  Looks like
>>> Anup was the one who posted the clock driver to U-Boot - can he take a
>>> look at it?
>>> 
>>> We've also asked Troy to look at upstream U-boot related issues, but
>>> I'm unsure when patches will start flowing upstream.
>>> 
>>> 
>>> - Paul
>> I’d prefer to hold off on any changes to U-boot until we have a more complete patch set. GPIO and ethernet entries are missing from those device trees, and we have a working U-boot device tree now. If the kernel needs something different we can load the device tree the kernel needs for awhile.
> 
> I don't think that's a good idea. It will unnecessarily block everybody's setup that is supposed to work with U-Boot. I prefer if we can patch U-Boot and unblock everybody sooner than later.
> 
>> The U-boot device tree is going to have some things in it the kernel doesn’t care about anyway, so we’ve already got divergence between the two. Ideally the U-boot version is a superset of the kernel version. We already had one disruptive change with the clock driver, so what is to prevent there to be more disruptive changes in the ethernet/GPIO device tree entries that go in the kernel unless we have a draft of what those entries should look like that is acceptable?
> IIRC, current U-Boot S mode port doesn't need a GPIO driver and ethernet driver is provided by the common macb driver. If there are any DT changes suggested by kernel, we can always patch U-Boot.

The M-mode port will need a GPIO driver, as the macb driver needs proper a proper GPIO driver to reset the phy.

I have no issues updating the PRCI driver DT format if we also have the rest of the DT entries needed to boot a working system, I just have not seen an example of that other than what I have at https://github.com/sifive/HiFive_U-Boot/blob/regression/arch/riscv/dts/hifive_u540.dts
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv