[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190412054952.GA26672@infradead.org>
Date: Thu, 11 Apr 2019 22:49:52 -0700
From: Christoph Hellwig <hch@...radead.org>
To: Paul Walmsley <paul.walmsley@...ive.com>
Cc: Atish Patra <atish.patra@....com>,
Christoph Hellwig <hch@...radead.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
Paul Walmsley <paul@...an.com>,
Albert Ou <aou@...s.berkeley.edu>,
Palmer Dabbelt <palmer@...ive.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>
Subject: Re: [PATCH 1/6] arch: riscv: add support for building DTB files from
DT source data
On Thu, Apr 11, 2019 at 05:08:11PM -0700, Paul Walmsley wrote:
> However: the vast majority of users -- even embedded users -- will not use
> a kernel with a bundled DTB. This is because it irrevocably ties that
> kernel binary to one specific board type. I hope it is obvious why this
> would be a non-starter for Linux distributions, and, more generally,
> anyone who wants their kernels to be usable on multiple boards. Those
> distributors would need to ship one kernel binary per board, or bloat
> their kernels with DTBs and come up with some new mechanism to select one.
Yes, that is the point why the DTB usually comes with the firmware.
In my case I need it because by nommu M-mode Linux port targeted to
the Kendrye _is_ the firmware and there is nothing else running on that
tiny system.
But why are you submitting the DTB files if there is not ways use them
from the kernel? That is what I was wondering about.
Powered by blists - more mailing lists