Re: [PATCH/RFC] Add Alternative Log Buffer Support for printk Messages

From: "Matt Sealey" <matt@genesi-usa.com>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: Bill Gatliff <bgat@billgatliff.com>, Wolfgang Denx <wd@denx.de>,
	linux-embedded@vger.kernel.org, linuxppc-dev@ozlabs.org,
	Stefan Roese <sr@denx.de>,
	Grant Erickson <gerickson@nuovations.com>
Subject: Re: [PATCH/RFC] Add Alternative Log Buffer Support for printk Messages
Date: Tue, 25 Nov 2008 14:46:45 -0600	[thread overview]
Message-ID: <b5e2fc790811251246r201a9f4anad308e9a8ff7960d@mail.gmail.com> (raw)
In-Reply-To: <fa686aa40811251217g6dcbef77u29e3d6ee6ad6d99f@mail.gmail.com>

[-- Attachment #1.1: Type: text/plain, Size: 2602 bytes --]

On Tue, Nov 25, 2008 at 2:17 PM, Grant Likely <grant.likely@secretlab.ca>wrote:

> On Tue, Nov 25, 2008 at 1:07 PM, Matt Sealey <matt@genesi-usa.com> wrote:
>
> > But here's the real question; why do you need an opensource
> implementation?
> > Curiosity?
>
> Umm, so that it can be ported to new boards perhaps?  So that
> developers can work with it?
>

You can port closed-source firmwares to new boards just as easily as with
open source ones.

For companies who have larger production requirements than Bill Gatliff,
porting an open source firmware may not be a task they want to get into.
Linux support is a big enough moving target without adding firmware
development to it and tying up programmers implementing the same drivers
twice (even if it is practically copy&paste in U-Boot).

In this case they may just buy one in. If everything had to be open source
and freely downloadable there would be no industry at all. And if paying for
someone else to write code for you is the issue, then we wouldn't have asked
you for a quote last week, and you certainly wouldn't have given us a price
:D

Bill, as for ARM etc. support, you can imagine that most of the guts of the
firmware are fairly well abstracted. Vast portions of the same code work on
most platforms with the same peripherals - USB, Ethernet controllers & PHYs,
PCI, SDIO, etc. The device tree is how hardware designers (note; not OS
designers) are meant to abstract the differences in hardware and programming
model so that an OS can load the right drivers and Do The Right Thing. It
doesn't matter if the device tree was generated as a flattened
representation, or by an open-source firmware or closed-source firmware.

However the IEEE 1275 standard is not as big a moving target as U-Boot. It
has an ABI and a client interface which hasn't been moved around or modified
since 1994. And when your board doesn't provide a device tree entry for
something, well, you just write some Forth and can edit entries in the
device tree in-place (no recompiles required). If you're so inclined you can
even write things like scsi host controller drivers in Forth and present
them such that they are then working - no reboots or recompiles required,
just load the script - and ready to use to boot the system. You can poke
around in the FirmWorks code for how powerful this can be, or poke around
http://www.powerdeveloper.org/platforms/efika/devicetree for how mundane and
simple it can be just fixing up some entries and making sure the chip is
configured right..

-- 
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations

[-- Attachment #1.2: Type: text/html, Size: 3185 bytes --]

[-- Attachment #2: Type: text/plain, Size: 146 bytes --]

_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev