On 03/18/2013 12:04 PM, Pavel Machek wrote:
On Mon 2013-03-18 17:57:46, Russell King - ARM Linux wrote:
On Mon, Mar 18, 2013 at 06:49:32PM +0100, Pavel Machek wrote:
What I wanted to say is that kernel build traditionaly produced
something useful, something bootloader can actually boot.
On Mon, Mar 18, 2013 at 05:36:53PM +0100, Pavel Machek wrote:
On Fri 2013-02-22 08:00:44, Olof Johansson wrote:
On Wed, Feb 20, 2013 at 07:37:10PM -0600, Joel A Fernandes wrote:
Any comments on this approach? Is it better to merge mkfitsrc.sh with
mkuboot.sh?
I know this was
Dear Stephen,
In message 51475997.2060...@wwwdotorg.org you wrote:
Raw zImage /is/ the useful format that should be adopted.
This one size fits all approch does fit everywhere. There are a
number of users (including _big_ commercial ones, with _large_ numebrs
of systems in the field) that
On Fri, Feb 22, 2013 at 02:56:33AM -0500, Jason Kridner wrote:
The desired FPGA use case is DT updates after booting the kernel. This
has nothing to do with FIT images. And if the FPGA tools generate the
DTB, then it is certainly not tied to the kernel.
Completely unrelated, but do you
On 02/21/2013 05:39 PM, Russell King - ARM Linux wrote:
On Thu, Feb 21, 2013 at 05:10:36PM -0700, Stephen Warren wrote:
On 02/21/2013 02:18 PM, Nicolas Pitre wrote:
...
Someone will want to use a previously unsupported feature of some HW and
then write the DT bindings for that feature for the
On Thu, 21 Feb 2013, Tom Rini wrote:
FIT isn't required. FIT is just trying to offer a nice usability
thing to folks.
Usability is often counter-balanced by maintenance costs.
A point of device trees is a single image works in a
lot of places. FIT gives you a single file works in a lot of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/21/2013 12:25 PM, Nicolas Pitre wrote:
On Thu, 21 Feb 2013, Tom Rini wrote:
[snip]
uboot dug _itself_ into this hole. It's uboot's problem.
A whole lot of people dug this particular hole. Joel is trying
to offer up a solution that maybe
On Thu, Feb 21, 2013 at 12:25:21PM -0500, Nicolas Pitre wrote:
So let's stop kidding ourselves and be coherent please: either we move
device specifics away from the kernel, or we keep them together. In
other words, the DT should ideally come preinstalled with the bootloader
on a given
On Thu, Feb 21, 2013 at 11:27:24AM -0700, Jason Gunthorpe wrote:
On Thu, Feb 21, 2013 at 12:25:21PM -0500, Nicolas Pitre wrote:
So let's stop kidding ourselves and be coherent please: either we move
device specifics away from the kernel, or we keep them together. In
other words, the DT
On Thu, 21 Feb 2013, Tom Rini wrote:
On 02/21/2013 12:25 PM, Nicolas Pitre wrote:
On Thu, 21 Feb 2013, Tom Rini wrote:
[snip]
uboot dug _itself_ into this hole. It's uboot's problem.
A whole lot of people dug this particular hole. Joel is trying
to offer up a solution that maybe
On 02/21/2013 12:21 PM, Nicolas Pitre wrote:
On Thu, 21 Feb 2013, Tom Rini wrote:
On 02/21/2013 12:25 PM, Nicolas Pitre wrote:
On Thu, 21 Feb 2013, Tom Rini wrote:
[snip]
uboot dug _itself_ into this hole. It's uboot's problem.
A whole lot of people dug this particular hole. Joel is
On Thu, 21 Feb 2013, Jason Gunthorpe wrote:
On Thu, Feb 21, 2013 at 12:25:21PM -0500, Nicolas Pitre wrote:
So let's stop kidding ourselves and be coherent please: either we move
device specifics away from the kernel, or we keep them together. In
other words, the DT should ideally come
Dear Stephen,
In message 5126778a.4040...@wwwdotorg.org you wrote:
If U-Boot always searched a disk for e.g. /boot/boot.scr or similar and
just executed that, and there was a standard boot.scr that worked on all
boards by use of e.g. bootz, ${soc}, ${board}, then that could be
On 02/21/2013 12:57 PM, Wolfgang Denk wrote:
Dear Stephen,
In message 5126778a.4040...@wwwdotorg.org you wrote:
If U-Boot always searched a disk for e.g. /boot/boot.scr or similar and
just executed that, and there was a standard boot.scr that worked on all
boards by use of e.g. bootz,
On Thu, Feb 21, 2013 at 07:08:20PM +, Russell King - ARM Linux wrote:
We've been using DT on production embedded stuff sice about 2.6.20ish
on PPC and now ARM. We treat the dtb as a kernel version specific
file, much like an initrd and ensure that the kernel only ever boots
with its
Dear Stephen,
In message 51267e0a.3060...@wwwdotorg.org you wrote:
so. Just consider the typical diskless system that boots over the
network, using DHCP + TFTP, where the server will provide a single
file only.
I use TFTP routinely to boot my boards, and load separate zImage and DTB
Jason == Jason Gunthorpe jguntho...@obsidianresearch.com writes:
Hi,
Jason We've been using DT on production embedded stuff sice about 2.6.20ish
Jason on PPC and now ARM. We treat the dtb as a kernel version specific
Jason file, much like an initrd and ensure that the kernel only ever boots
On Thu, Feb 21, 2013 at 02:57:46PM -0500, Nicolas Pitre wrote:
On Thu, 21 Feb 2013, Jason Gunthorpe wrote:
On Thu, Feb 21, 2013 at 12:25:21PM -0500, Nicolas Pitre wrote:
So let's stop kidding ourselves and be coherent please: either we move
device specifics away from the kernel, or
On Thu, 21 Feb 2013, Stephen Warren wrote:
On 02/21/2013 12:21 PM, Nicolas Pitre wrote:
DT installation must be outside of the distribution's responsibilities.
It should be the OEM's responsibility, just like BIOS updates for PCs
which don't come from Fedora/Debian/Ubuntu. Obviously,
On Thu, 21 Feb 2013, Jason Gunthorpe wrote:
On Thu, Feb 21, 2013 at 02:57:46PM -0500, Nicolas Pitre wrote:
For embedded appliance product you may do as you wish. Nobody will
interfere in the way you develop and support your own products (as long
as you honor the applicable licenses of
On Thu, Feb 21, 2013 at 05:05:54PM -0500, Nicolas Pitre wrote:
On Thu, 21 Feb 2013, Jason Gunthorpe wrote:
On Thu, Feb 21, 2013 at 02:57:46PM -0500, Nicolas Pitre wrote:
For embedded appliance product you may do as you wish. Nobody will
interfere in the way you develop and support
Dear Nicolas,
In message alpine.lfd.2.03.1302211624561.6...@syhkavp.arg you wrote:
No it is not. FIT is about bundling a multi-platform kernel with a
bunch of DTBs together in a single file. I don't think you need that
Actually this is neither the only, nor even the primary purpose of
On Fri, Feb 22, 2013 at 12:18:48AM +0100, Wolfgang Denk wrote:
The DT is meant to describe hardware. As far as I know, the hardware I
own seems to be rather static and stable, and unlike software there is
no way I can change it (soldering irons don't count).
There is other hardware
On 02/21/2013 03:05 PM, Nicolas Pitre wrote:
On Thu, 21 Feb 2013, Jason Gunthorpe wrote:
...
Distros already ship huge kernels with modules for every hardware out
there. Shipping all the DTs as well doesn't seem like a problem.
But it is! Even shipping multiple kernels _is_ a problem for
On 02/21/2013 04:11 PM, Jason Gunthorpe wrote:
On Thu, Feb 21, 2013 at 05:05:54PM -0500, Nicolas Pitre wrote:
...
The DT is meant to describe hardware. As far as I know, the hardware I
own seems to be rather static and stable, and unlike software there is
no way I can change it (soldering
On 02/21/2013 02:18 PM, Nicolas Pitre wrote:
On Thu, 21 Feb 2013, Stephen Warren wrote:
On 02/21/2013 12:21 PM, Nicolas Pitre wrote:
DT installation must be outside of the distribution's responsibilities.
It should be the OEM's responsibility, just like BIOS updates for PCs
which don't
On 02/21/2013 05:28 PM, Jason Gunthorpe wrote:
On Fri, Feb 22, 2013 at 12:18:48AM +0100, Wolfgang Denk wrote:
The DT is meant to describe hardware. As far as I know, the hardware I
own seems to be rather static and stable, and unlike software there is
no way I can change it (soldering
On 02/21/2013 05:11:06 PM, Jason Gunthorpe wrote:
On Thu, Feb 21, 2013 at 05:05:54PM -0500, Nicolas Pitre wrote:
No it is not. FIT is about bundling a multi-platform kernel with a
bunch of DTBs together in a single file. I don't think you need
that
for your embedded system. The wrong
On Thu, Feb 21, 2013 at 04:11:06PM -0700, Jason Gunthorpe wrote:
On Thu, Feb 21, 2013 at 05:05:54PM -0500, Nicolas Pitre wrote:
No it is not. FIT is about bundling a multi-platform kernel with a
bunch of DTBs together in a single file. I don't think you need that
for your embedded
On Thu, Feb 21, 2013 at 04:45:37PM -0700, Stephen Warren wrote:
Well they ship x86 CPU firmware updates according to the boot log on one
of my systems at least...
Correction: CPU microcode updates. That's updating the microcode in the
CPU which runs the x86 instruction set. It's done to fix
On Thu, Feb 21, 2013 at 05:10:36PM -0700, Stephen Warren wrote:
On 02/21/2013 02:18 PM, Nicolas Pitre wrote:
Where were such guidance given?
IIRC, it's been discussed a number of times on the Linux ARM kernel
mailing list and at the various ARM workshops at kernel summit and/or
Linaro
And I'm just about to set my mailer up to automatically drop the uboot
mailing list from future replies.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Feb 22, 2013 at 12:27:18AM +, Russell King - ARM Linux wrote:
Actually we do this on PPC, the boot kernel image runs on three
similar hardware platforms, the image has three DTBs built into it and
the right one is selected at runtime. The kernel boot image does this
(call it a
On Thu, Feb 21, 2013 at 06:19:05PM -0600, Rob Herring wrote:
The desired FPGA use case is DT updates after booting the kernel. This
has nothing to do with FIT images. And if the FPGA tools generate the
DTB, then it is certainly not tied to the kernel.
Completely unrelated, but do you have any
On Thu, Feb 21, 2013 at 06:19:15PM -0600, Scott Wood wrote:
While embedded focused PPC stuff seems to tend to keep the kernel and
DT together.
At least on the Freescale side of embedded focused PPC stuff, we
have not kept the kernel and DT together. It's actually U-Boot that
the dts files
On 02/21/2013 08:22 PM, Jason Gunthorpe wrote:
On Thu, Feb 21, 2013 at 06:19:05PM -0600, Rob Herring wrote:
The desired FPGA use case is DT updates after booting the kernel. This
has nothing to do with FIT images. And if the FPGA tools generate the
DTB, then it is certainly not tied to the
Dear Jason,
In message 20130221232821.ga2...@obsidianresearch.com you wrote:
own seems to be rather static and stable, and unlike software there is
no way I can change it (soldering irons don't count).
There is other hardware available (for example FPGA based) where this
does not
On Thu, Feb 21, 2013 at 9:22 PM, Jason Gunthorpe
jguntho...@obsidianresearch.com wrote:
On Thu, Feb 21, 2013 at 06:19:05PM -0600, Rob Herring wrote:
The desired FPGA use case is DT updates after booting the kernel. This
has nothing to do with FIT images. And if the FPGA tools generate the
38 matches
Mail list logo
