* Re: Request review of device tree documentation
From: Benjamin Herrenschmidt @ 2010-06-14 9:36 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Nicolas Pitre, microblaze-uclinux, devicetree-discuss,
Olof Johansson, linuxppc-dev, Mitch Bradley, Dan Malek,
Jeremy Kerr, linux-arm-kernel
In-Reply-To: <20100614092559.GA7881@n2100.arm.linux.org.uk>
On Mon, 2010-06-14 at 10:25 +0100, Russell King - ARM Linux wrote:
> On Sun, Jun 13, 2010 at 09:45:50PM -1000, Mitch Bradley wrote:
> > None of this is a deal-breaker for the kind of debugging tasks that are
> > the primary use case for the callback.
>
> Would you mind explaining what kind of tasks these callbacks will
> be used for?
That's one of the thing I'm "touching" on in my previous reply...
(For those who didn't quite follow, the discussion here is about
allowing a real Open Firmware implementation on ARM with the feature of
leaving OF alive while the OS is up, which is something sparc does but
we never supported on ppc).
Ideally, if you keep open firmware alive, you can drop into it when the
kernel crashes for example, or in some other circumstances.
However, there's a lot of room for abuse here and I'm worried that if it
becomes widespread, we'll start seeing vendors use that as a way to do
some kind of HAL and hide various platform methods in there (clock
control, nvram, etc...).
Another option Mitch mentioned is to have the f-code interpreter (f-code
is OF tokenized forth format) in the kernel, but that doesn't completely
solve the problem of providing it with appropriate virtual mappings,
arbitrating access to HW resources, etc etc etc
OF as a FW/bootloader is great. OF alive along with the OS can be a nice
debugging tool under some circumstances but I am a bit more dubious as
to whether that's going to work out in practice. But I'd like to -not-
see it abused as some kind of HAL.
Cheers,
Ben.
^ permalink raw reply
* Re: Request review of device tree documentation
From: Russell King - ARM Linux @ 2010-06-14 9:47 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Nicolas Pitre, microblaze-uclinux, devicetree-discuss,
Olof Johansson, linuxppc-dev, Mitch Bradley, Dan Malek,
Jeremy Kerr, linux-arm-kernel
In-Reply-To: <1276508170.2552.43.camel@pasglop>
On Mon, Jun 14, 2010 at 07:36:10PM +1000, Benjamin Herrenschmidt wrote:
> However, there's a lot of room for abuse here and I'm worried that if it
> becomes widespread, we'll start seeing vendors use that as a way to do
> some kind of HAL and hide various platform methods in there (clock
> control, nvram, etc...).
This is what I'm worried about too.
As I said in my first reply in this thread, calling out from the kernel
will kill performance due to the time taken to shut down the caches and
MMU, which can only be done safely with all exceptions turned off.
The only time that it can be seriously considered is if you're calling
out to reboot, shutdown or kexec.
^ permalink raw reply
* Re: Request review of device tree documentation
From: David Gibson @ 2010-06-14 12:44 UTC (permalink / raw)
To: Grant Likely
Cc: Nicolas Pitre, microblaze-uclinux, devicetree-discuss,
linuxppc-dev, Mitch Bradley, Dan Malek, Jeremy Kerr,
linux-arm-kernel
In-Reply-To: <AANLkTikls3hjXOmKFqG2D_9GaJSjOXNuuRXPlanAjo5E@mail.gmail.com>
On Sun, Jun 13, 2010 at 11:02:15PM -0600, Grant Likely wrote:
[sni]
> > That's sort of a self-fulfilling prophecy. If the OS doesn't trust the
> > firmware, there is no pressure for the firmware to "get it right".
>
> Firmware will not get it right. Period. There will always be
> something wrong. It is never right on PCs. It will never be right on
> the other architectures.
Yes, yes, yes. And there is a great deal of empirical evidence to
back that assertion.
> That goes for OSes too, but upgrading an OS
> isn't as risky as upgrading firmware. That isn't to say that it can't
> be close, but every firmware feature that the OS depends on is a
> feature that could force a risky firmware upgrade when the bug in it
> is discovered.
Indeed. In fact, the general rule of thumb is really "put as much as
possible into the most easily replaced layer of the stack". This is,
incidentally, why I've always been dubious about simple firmwares
supplying a flattened device tree rather than including the device
tree template in the kernel, cuboot style.
> I'm also convinced that the economics are all wrong for "getting it
> right" when talking about firmware. Manufactures don't care about
> firmware; they care about selling boxes. Customers don't care about
> firmware, they care about the operating system (well, that's not true
> either, they care about applications). For manufactures, once it can
> boot the real operating system, there is little to no incentive to
> spend any more money on firmware when the money can be better spent on
> either the next product or the adding features to the operating system
> of the existing product. In fact, spending money on firmware is
> actually *more risky* one a product ships, because if a firmware
> upgrade goes bad, then that means product returned for repair at the
> factory.
A good analysis. The other side of this, is that for an OS, if you
rely on the firmware to do X, it will work when the firmware gets it
right. If you do X yourself, it will work whether or not the firmware
gets it right. This means that if there's even one firmware you have
to deal with out there that gets X wrong, you have to do it yourself
and then there is little to no incentive to rely on firmware even in
the cases where it does get it right. In fact there's a disincentive,
because then you have two different code paths to test and maintain.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: Request review of device tree documentation
From: Jamie Lokier @ 2010-06-14 14:29 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Mitch Bradley, Nicolas Pitre, devicetree-discuss, linuxppc-dev,
microblaze-uclinux, Olof Johansson, Dan Malek, Jeremy Kerr,
linux-arm-kernel
In-Reply-To: <20100614094740.GB7881@n2100.arm.linux.org.uk>
Russell King - ARM Linux wrote:
> On Mon, Jun 14, 2010 at 07:36:10PM +1000, Benjamin Herrenschmidt wrote:
> > However, there's a lot of room for abuse here and I'm worried that if it
> > becomes widespread, we'll start seeing vendors use that as a way to do
> > some kind of HAL and hide various platform methods in there (clock
> > control, nvram, etc...).
>
> This is what I'm worried about too.
>
> As I said in my first reply in this thread, calling out from the kernel
> will kill performance due to the time taken to shut down the caches and
> MMU, which can only be done safely with all exceptions turned off.
Some applications use ARM (or other "embedded"-ish CPU) as opposed to
x86 PCs, to get predictable and reasonable interrupt latency.
x86 PCs sometimes have unpredictable interrupt latency due to those
mystery interrupts that the BIOS handles and the OS can't see or
block. It's a different cause, but let's not duplicate the symptom
where it isn't wanted.
Even if opaque firmware callouts were fast, it would be an issue with
real-time kernels if they couldn't depend on that as an auditable fact.
-- Jamie
^ permalink raw reply
* Re: Request review of device tree documentation
From: Nicolas Pitre @ 2010-06-14 13:51 UTC (permalink / raw)
To: Grant Likely
Cc: linuxppc-dev, devicetree-discuss, Olof Johansson,
microblaze-uclinux, Mitch Bradley, Dan Malek, Jeremy Kerr,
linux-arm-kernel
In-Reply-To: <AANLkTinwL0XtMNG13inr_1UliOlqZkyr4dlvG-ZGL9JT@mail.gmail.com>
On Sun, 13 Jun 2010, Grant Likely wrote:
> [cc'ing linux-arm-kernel]
>
> On Sat, Jun 12, 2010 at 11:59 PM, Benjamin Herrenschmidt
> > BTW. I notice no ARM list is CCed on this discussion ... maybe we should
> > fix that ?
>
> cc'ing linux-arm-kernel in all my replies
I'm afraid this won't be enough.
I'm seeing a stream of frightening crazy talk involving ARM and some
other stuff I still can't make head and tail of. So, before you get a
wholesale NAK on everything from me, please I'd suggest you guys rewind
a bit now that the ARM list is in CC and just explain what this is all
about and why we should feel concerned. Then maybe the ARM savvy people
amongst us could suggest more appropriate approaches?
Thank you.
Nicolas
^ permalink raw reply
* Re: Request review of device tree documentation
From: Nicolas Pitre @ 2010-06-14 14:59 UTC (permalink / raw)
To: David Gibson
Cc: microblaze-uclinux, devicetree-discuss, linuxppc-dev,
Mitch Bradley, Dan Malek, Jeremy Kerr, linux-arm-kernel
In-Reply-To: <20100614124438.GF9323@yookeroo>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3352 bytes --]
On Mon, 14 Jun 2010, David Gibson wrote:
> On Sun, Jun 13, 2010 at 11:02:15PM -0600, Grant Likely wrote:
> [sni]
> > > That's sort of a self-fulfilling prophecy. If the OS doesn't trust the
> > > firmware, there is no pressure for the firmware to "get it right".
> >
> > Firmware will not get it right. Period. There will always be
> > something wrong. It is never right on PCs. It will never be right on
> > the other architectures.
>
> Yes, yes, yes. And there is a great deal of empirical evidence to
> back that assertion.
>
> > That goes for OSes too, but upgrading an OS
> > isn't as risky as upgrading firmware. That isn't to say that it can't
> > be close, but every firmware feature that the OS depends on is a
> > feature that could force a risky firmware upgrade when the bug in it
> > is discovered.
>
> Indeed. In fact, the general rule of thumb is really "put as much as
> possible into the most easily replaced layer of the stack". This is,
> incidentally, why I've always been dubious about simple firmwares
> supplying a flattened device tree rather than including the device
> tree template in the kernel, cuboot style.
The biggest advantage, IMHO, for adding DT to ARM, is actually to
decouple the hardware config information and the kernel. If in the end
the DT has to be shipped in the kernel then we're losing all this
advantage over the current state of things on ARM which still works
pretty well otherwise.
In the best case, the simple firmware simply has to retrieve the
flattened device tree from flash, and pass it to the kernel just like
some anonymous blob. And the simple firmware only needs to provide a
way for that DT blob to be updatable, like through an upload of a
replacement blob that was prepared offline. Just like a ramdisk image
or the like.
That doesn't need to be fancier than that, and the goal of having the DT
data tied to the hardware instead of the kernel is achieved.
> > I'm also convinced that the economics are all wrong for "getting it
> > right" when talking about firmware. Manufactures don't care about
> > firmware; they care about selling boxes. Customers don't care about
> > firmware, they care about the operating system (well, that's not true
> > either, they care about applications). For manufactures, once it can
> > boot the real operating system, there is little to no incentive to
> > spend any more money on firmware when the money can be better spent on
> > either the next product or the adding features to the operating system
> > of the existing product. In fact, spending money on firmware is
> > actually *more risky* one a product ships, because if a firmware
> > upgrade goes bad, then that means product returned for repair at the
> > factory.
>
> A good analysis. The other side of this, is that for an OS, if you
> rely on the firmware to do X, it will work when the firmware gets it
> right. If you do X yourself, it will work whether or not the firmware
> gets it right. This means that if there's even one firmware you have
> to deal with out there that gets X wrong, you have to do it yourself
> and then there is little to no incentive to rely on firmware even in
> the cases where it does get it right. In fact there's a disincentive,
> because then you have two different code paths to test and maintain.
Amen.
Nicolas
^ permalink raw reply
* Re: Request review of device tree documentation
From: Grant Likely @ 2010-06-14 15:08 UTC (permalink / raw)
To: Nicolas Pitre
Cc: microblaze-uclinux, devicetree-discuss, linuxppc-dev,
Mitch Bradley, Dan Malek, Jeremy Kerr, linux-arm-kernel,
David Gibson
In-Reply-To: <alpine.LFD.2.00.1006141044510.13427@xanadu.home>
On Mon, Jun 14, 2010 at 8:59 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
> On Mon, 14 Jun 2010, David Gibson wrote:
>
>> On Sun, Jun 13, 2010 at 11:02:15PM -0600, Grant Likely wrote:
>> Indeed. =A0In fact, the general rule of thumb is really "put as much as
>> possible into the most easily replaced layer of the stack". =A0This is,
>> incidentally, why I've always been dubious about simple firmwares
>> supplying a flattened device tree rather than including the device
>> tree template in the kernel, cuboot style.
>
> The biggest advantage, IMHO, for adding DT to ARM, is actually to
> decouple the hardware config information and the kernel. =A0If in the end
> the DT has to be shipped in the kernel then we're losing all this
> advantage over the current state of things on ARM which still works
> pretty well otherwise.
>
> In the best case, the simple firmware simply has to retrieve the
> flattened device tree from flash, and pass it to the kernel just like
> some anonymous blob. =A0And the simple firmware only needs to provide a
> way for that DT blob to be updatable, like through an upload of a
> replacement blob that was prepared offline. =A0Just like a ramdisk image
> or the like.
>
> That doesn't need to be fancier than that, and the goal of having the DT
> data tied to the hardware instead of the kernel is achieved.
exactly right.
g.
^ permalink raw reply
* Re: Request review of device tree documentation
From: Grant Likely @ 2010-06-14 15:35 UTC (permalink / raw)
To: Nicolas Pitre
Cc: linuxppc-dev, devicetree-discuss, Olof Johansson,
microblaze-uclinux, Mitch Bradley, Dan Malek, Jeremy Kerr,
linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1006140943350.13427@xanadu.home>
On Mon, Jun 14, 2010 at 7:51 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
> On Sun, 13 Jun 2010, Grant Likely wrote:
>
>> [cc'ing linux-arm-kernel]
>>
>> On Sat, Jun 12, 2010 at 11:59 PM, Benjamin Herrenschmidt
>> > BTW. I notice no ARM list is CCed on this discussion ... maybe we shou=
ld
>> > fix that ?
>>
>> cc'ing linux-arm-kernel in all my replies
>
> I'm afraid this won't be enough.
>
> I'm seeing a stream of frightening crazy talk involving ARM and some
> other stuff I still can't make head and tail of. =A0So, before you get a
> wholesale NAK on everything from me, please I'd suggest you guys rewind
> a bit now that the ARM list is in CC and just explain what this is all
> about and why we should feel concerned. =A0Then maybe the ARM savvy peopl=
e
> amongst us could suggest more appropriate approaches?
The discussion *started* with a request to review this document:
http://devicetree.org/Device_Tree_Usage
Which is in early draft form (which is why the arm list wasn't
initially cc'd. I was soliciting feedback from the current device tree
users. A second request for review will go out after rework is done
to the document).
In one of the reply threads Mitch stated that he is working on an ARM
project that will use Open Firmware as the bootloader, and that he'd
like the ability to keep OFW available after the kernel is booted
which is something currently done on both Sparc and OLPC x86. Mitch
will correct me if I'm made any misrepresentations here.
Conceptually I'm not opposed to allowing OFW to stay resident
providing that it does not impose new requirements on the boot
interface (the kernel would still need to be handed the flattened
representation of the device tree) and that the code to do so is well
contained in the kernel. The devil is of course in the details on how
feasible it is to accomplish. ARM machines with Open Firmware are
going to be the minority, so I'm not interested in doing anything
special or out of the ordinary specifically to support it.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Request review of device tree documentation
From: Nicolas Pitre @ 2010-06-14 15:58 UTC (permalink / raw)
To: Grant Likely
Cc: linuxppc-dev, devicetree-discuss, Olof Johansson,
microblaze-uclinux, Mitch Bradley, Dan Malek, Jeremy Kerr,
linux-arm-kernel
In-Reply-To: <AANLkTim1mYpaxe-_OGbOF3AaZ6m5_SVUXLbeyKnAyvjs@mail.gmail.com>
On Mon, 14 Jun 2010, Grant Likely wrote:
> The discussion *started* with a request to review this document:
>
> http://devicetree.org/Device_Tree_Usage
>
> Which is in early draft form (which is why the arm list wasn't
> initially cc'd. I was soliciting feedback from the current device tree
> users. A second request for review will go out after rework is done
> to the document).
I'm therefore assuming I can safely ignore it for now then.
> In one of the reply threads Mitch stated that he is working on an ARM
> project that will use Open Firmware as the bootloader, and that he'd
> like the ability to keep OFW available after the kernel is booted
> which is something currently done on both Sparc and OLPC x86. Mitch
> will correct me if I'm made any misrepresentations here.
OK... but what does "keep OFW available" mean? And what for?
> Conceptually I'm not opposed to allowing OFW to stay resident
> providing that it does not impose new requirements on the boot
> interface (the kernel would still need to be handed the flattened
> representation of the device tree) and that the code to do so is well
> contained in the kernel. The devil is of course in the details on how
> feasible it is to accomplish.
Well, you'd need to tell the kernel about what memory area not to touch
(given that memory is not in some area the kernel will touch anyway when
it is in its early boot stage and still not smart enough to avoid it).
Then you'll need special code to perform those steps RMK already
mentioned. This is a bit like the low-level code for suspend/resume
support is doing. This is of course if I'm still guessing right about
the whole purpose of this.
> ARM machines with Open Firmware are
> going to be the minority, so I'm not interested in doing anything
> special or out of the ordinary specifically to support it.
This certainly doesn't have to involve the core kernel. A special
module may even be sufficient to keep the complexity localized. Just
like low-level suspend/resume code is per SOC already anyway.
But again, what for?
Nicolas
^ permalink raw reply
* Re: Request review of device tree documentation
From: Jamie Lokier @ 2010-06-14 16:02 UTC (permalink / raw)
To: Nicolas Pitre
Cc: microblaze-uclinux, devicetree-discuss, linuxppc-dev,
Mitch Bradley, Dan Malek, Jeremy Kerr, linux-arm-kernel,
David Gibson
In-Reply-To: <alpine.LFD.2.00.1006141044510.13427@xanadu.home>
Nicolas Pitre wrote:
> On Mon, 14 Jun 2010, David Gibson wrote:
>
> > On Sun, Jun 13, 2010 at 11:02:15PM -0600, Grant Likely wrote:
> > [sni]
> > > > That's sort of a self-fulfilling prophecy. If the OS doesn't trust the
> > > > firmware, there is no pressure for the firmware to "get it right".
> > >
> > > Firmware will not get it right. Period. There will always be
> > > something wrong. It is never right on PCs. It will never be right on
> > > the other architectures.
> >
> > Yes, yes, yes. And there is a great deal of empirical evidence to
> > back that assertion.
> >
> > > That goes for OSes too, but upgrading an OS
> > > isn't as risky as upgrading firmware. That isn't to say that it can't
> > > be close, but every firmware feature that the OS depends on is a
> > > feature that could force a risky firmware upgrade when the bug in it
> > > is discovered.
> >
> > Indeed. In fact, the general rule of thumb is really "put as much as
> > possible into the most easily replaced layer of the stack". This is,
> > incidentally, why I've always been dubious about simple firmwares
> > supplying a flattened device tree rather than including the device
> > tree template in the kernel, cuboot style.
>
> The biggest advantage, IMHO, for adding DT to ARM, is actually to
> decouple the hardware config information and the kernel. If in the end
> the DT has to be shipped in the kernel then we're losing all this
> advantage over the current state of things on ARM which still works
> pretty well otherwise.
>
> In the best case, the simple firmware simply has to retrieve the
> flattened device tree from flash, and pass it to the kernel just like
> some anonymous blob. And the simple firmware only needs to provide a
> way for that DT blob to be updatable, like through an upload of a
> replacement blob that was prepared offline. Just like a ramdisk image
> or the like.
>
> That doesn't need to be fancier than that, and the goal of having the DT
> data tied to the hardware instead of the kernel is achieved.
Imho that puts the DT in a similar category as initrd/initramfs, from
the bootloader's point of view. It's another blob whose address is
passed to the kernel, just like initrd.
Some bootloaders can't update blobs independently for technical
reasons, or to be minimal.
A device I'm using does kernel updates by updating the whole romfs
boot image, which contains the kernel and other auxiliary blobs used
for booting (splash screen, early irq handlers etc.) as well as the
root filesystem.
It is done that way to pack everything together in the small flash,
and because the NOR flash eraseblocks are too large relative to the
whole flash size to use separate partitions for kernel, boot
filesystem and other blobs for booting.
Dedicating a 64kiB eraseblock out of 2MB just for a small DT would be
quite wasteful. Dedicating two to make it powerfail-safe would be
even worse.
So requiring that a bootloader can update the DT _independently_ of
everything else is a bit much for some devices.
But requiring that it's generally treated like other separate blob,
i.e. in a similar way to initrd, and the kernel image itself, seems
not unreasonable.
Like initrd, some people will find they need to compile it in to the
kernel image to fit some bootloader they can't change, or daren't risk
changing in already rolled out devices that they want to update to a
DT-using kernel.
I won't be surprised if I see some vendor SDK containing a kernel
patch to early-parse the bootloader-supplied ROMFS image to extract
"devicetree.bin.gz" at some point :-)
We can discourage that sort of thing (but not prevent it) by ensuring
the open source bootloaders support a DT blob as easily as possible.
-- Jamie
^ permalink raw reply
* Re: Request review of device tree documentation
From: M. Warner Losh @ 2010-06-14 15:51 UTC (permalink / raw)
To: david
Cc: nico, microblaze-uclinux, devicetree-discuss, linuxppc-dev,
ppc6dev, jeremy.kerr, linux-arm-kernel
In-Reply-To: <20100614124438.GF9323@yookeroo>
In message: <20100614124438.GF9323@yookeroo>
David Gibson <david@gibson.dropbear.id.au> writes:
: On Sun, Jun 13, 2010 at 11:02:15PM -0600, Grant Likely wrote:
: [sni]
: > > That's sort of a self-fulfilling prophecy. =A0If the OS doesn't t=
rust the
: > > firmware, there is no pressure for the firmware to "get it right"=
.=
: > =
: > Firmware will not get it right. Period. There will always be
: > something wrong. It is never right on PCs. It will never be right=
on
: > the other architectures.
: =
: Yes, yes, yes. And there is a great deal of empirical evidence to
: back that assertion.
While I'll be the first to agree with that, there's also a great deal
of empirical evidence to suggest that they get it right enough often
enough. Otherwise nothing would boot and everything would be broken.
: > That goes for OSes too, but upgrading an OS
: > isn't as risky as upgrading firmware. That isn't to say that it ca=
n't
: > be close, but every firmware feature that the OS depends on is a
: > feature that could force a risky firmware upgrade when the bug in i=
t
: > is discovered.
: =
: Indeed. In fact, the general rule of thumb is really "put as much as=
: possible into the most easily replaced layer of the stack". This is,=
: incidentally, why I've always been dubious about simple firmwares
: supplying a flattened device tree rather than including the device
: tree template in the kernel, cuboot style.
The down side of cuboot style is that your kernel will boot on fewer
boards. The firmware enables more generic kernels.
: > I'm also convinced that the economics are all wrong for "getting it=
: > right" when talking about firmware. Manufactures don't care about
: > firmware; they care about selling boxes. Customers don't care abou=
t
: > firmware, they care about the operating system (well, that's not tr=
ue
: > either, they care about applications). For manufactures, once it c=
an
: > boot the real operating system, there is little to no incentive to
: > spend any more money on firmware when the money can be better spent=
on
: > either the next product or the adding features to the operating sys=
tem
: > of the existing product. In fact, spending money on firmware is
: > actually *more risky* one a product ships, because if a firmware
: > upgrade goes bad, then that means product returned for repair at th=
e
: > factory.
: =
: A good analysis. The other side of this, is that for an OS, if you
: rely on the firmware to do X, it will work when the firmware gets it
: right. If you do X yourself, it will work whether or not the firmwar=
e
: gets it right. This means that if there's even one firmware you have=
: to deal with out there that gets X wrong, you have to do it yourself
: and then there is little to no incentive to rely on firmware even in
: the cases where it does get it right. In fact there's a disincentive=
,
: because then you have two different code paths to test and maintain.
Two comments: (1) You are assuming that you are in a position to do
'X' right which isn't always possible (in this case, it is impossible
to do generically, but can be done specifically for a given board if
you know enough about the board) and (2) In this case, the wrapped fdt
path uses the same path as the get the fdt from the firmware.
Warner
^ permalink raw reply
* Re: Request review of device tree documentation
From: Grant Likely @ 2010-06-14 16:16 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Mitch Bradley, microblaze-uclinux, devicetree-discuss,
linuxppc-dev, Olof Johansson, Dan Malek, Jeremy Kerr,
linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1006141143480.13427@xanadu.home>
On Mon, Jun 14, 2010 at 9:58 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
> On Mon, 14 Jun 2010, Grant Likely wrote:
>
>> The discussion *started* with a request to review this document:
>>
>> http://devicetree.org/Device_Tree_Usage
>>
>> Which is in early draft form (which is why the arm list wasn't
>> initially cc'd. I was soliciting feedback from the current device tree
>> users. =A0A second request for review will go out after rework is done
>> to the document).
>
> I'm therefore assuming I can safely ignore it for now then.
Correct.
I'll let Mitch answer the rest of your questions.
g.
^ permalink raw reply
* Re: Request review of device tree documentation
From: Nicolas Pitre @ 2010-06-14 16:23 UTC (permalink / raw)
To: Jamie Lokier
Cc: microblaze-uclinux, devicetree-discuss, linuxppc-dev,
Mitch Bradley, Dan Malek, Jeremy Kerr, linux-arm-kernel,
David Gibson
In-Reply-To: <20100614160201.GD9550@shareable.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 4461 bytes --]
On Mon, 14 Jun 2010, Jamie Lokier wrote:
> Nicolas Pitre wrote:
> > On Mon, 14 Jun 2010, David Gibson wrote:
> >
> > > On Sun, Jun 13, 2010 at 11:02:15PM -0600, Grant Likely wrote:
> > > [sni]
> > > > > That's sort of a self-fulfilling prophecy. If the OS doesn't trust the
> > > > > firmware, there is no pressure for the firmware to "get it right".
> > > >
> > > > Firmware will not get it right. Period. There will always be
> > > > something wrong. It is never right on PCs. It will never be right on
> > > > the other architectures.
> > >
> > > Yes, yes, yes. And there is a great deal of empirical evidence to
> > > back that assertion.
> > >
> > > > That goes for OSes too, but upgrading an OS
> > > > isn't as risky as upgrading firmware. That isn't to say that it can't
> > > > be close, but every firmware feature that the OS depends on is a
> > > > feature that could force a risky firmware upgrade when the bug in it
> > > > is discovered.
> > >
> > > Indeed. In fact, the general rule of thumb is really "put as much as
> > > possible into the most easily replaced layer of the stack". This is,
> > > incidentally, why I've always been dubious about simple firmwares
> > > supplying a flattened device tree rather than including the device
> > > tree template in the kernel, cuboot style.
> >
> > The biggest advantage, IMHO, for adding DT to ARM, is actually to
> > decouple the hardware config information and the kernel. If in the end
> > the DT has to be shipped in the kernel then we're losing all this
> > advantage over the current state of things on ARM which still works
> > pretty well otherwise.
> >
> > In the best case, the simple firmware simply has to retrieve the
> > flattened device tree from flash, and pass it to the kernel just like
> > some anonymous blob. And the simple firmware only needs to provide a
> > way for that DT blob to be updatable, like through an upload of a
> > replacement blob that was prepared offline. Just like a ramdisk image
> > or the like.
> >
> > That doesn't need to be fancier than that, and the goal of having the DT
> > data tied to the hardware instead of the kernel is achieved.
>
> Imho that puts the DT in a similar category as initrd/initramfs, from
> the bootloader's point of view. It's another blob whose address is
> passed to the kernel, just like initrd.
Exact.
> Some bootloaders can't update blobs independently for technical
> reasons, or to be minimal.
>
> A device I'm using does kernel updates by updating the whole romfs
> boot image, which contains the kernel and other auxiliary blobs used
> for booting (splash screen, early irq handlers etc.) as well as the
> root filesystem.
>
> It is done that way to pack everything together in the small flash,
> and because the NOR flash eraseblocks are too large relative to the
> whole flash size to use separate partitions for kernel, boot
> filesystem and other blobs for booting.
If you already have to update everything at once already anyway, then
the DT blob just has to be in that update. No need to do otherwise if
you can't do better than that for the kernel alone.
> Dedicating a 64kiB eraseblock out of 2MB just for a small DT would be
> quite wasteful. Dedicating two to make it powerfail-safe would be
> even worse.
I hardly see how you can be power fail safe with your
update-everything-at-once condition above anyway.
Furthermore, if the DT is updated by the bootloader, then that means
you're not running a live system at that point. If power fails during
the DT update, then you simply have to re-update it when power is back
to allow a successful boot of the kernel afterwards.
> So requiring that a bootloader can update the DT _independently_ of
> everything else is a bit much for some devices.
In my opinion, this use case you're illustrating above simply could
continue to _not_ use DT at all. If your NOR flash is so small that you
cannot spare some extra erase blocks, then this is a deeply embedded
profile the current DT-on-ARM push is not really meant for. You would
be much better with a minimally configured kernel with all the hardware
info statically compiled into the kernel and get away without all the DT
parsing code altogether, like you're already doing today.
While I think DT for ARM has advantages, I don't see us dropping the
legacy ARM methods anytime soon, especially for existing or extremely
constrained targets.
Nicolas
^ permalink raw reply
* Re: Request review of device tree documentation
From: Grant Likely @ 2010-06-14 16:28 UTC (permalink / raw)
To: Jamie Lokier
Cc: Nicolas Pitre, microblaze-uclinux, devicetree-discuss,
linuxppc-dev, Mitch Bradley, Dan Malek, Jeremy Kerr,
linux-arm-kernel, David Gibson
In-Reply-To: <20100614160201.GD9550@shareable.org>
On Mon, Jun 14, 2010 at 10:02 AM, Jamie Lokier <jamie@shareable.org> wrote:
> Nicolas Pitre wrote:
>> On Mon, 14 Jun 2010, David Gibson wrote:
>>
>> > On Sun, Jun 13, 2010 at 11:02:15PM -0600, Grant Likely wrote:
>> > [sni]
>> > > > That's sort of a self-fulfilling prophecy. =A0If the OS doesn't tr=
ust the
>> > > > firmware, there is no pressure for the firmware to "get it right".
>> > >
>> > > Firmware will not get it right. =A0Period. =A0There will always be
>> > > something wrong. =A0It is never right on PCs. =A0It will never be ri=
ght on
>> > > the other architectures.
>> >
>> > Yes, yes, yes. =A0And there is a great deal of empirical evidence to
>> > back that assertion.
>> >
>> > > =A0That goes for OSes too, but upgrading an OS
>> > > isn't as risky as upgrading firmware. =A0That isn't to say that it c=
an't
>> > > be close, but every firmware feature that the OS depends on is a
>> > > feature that could force a risky firmware upgrade when the bug in it
>> > > is discovered.
>> >
>> > Indeed. =A0In fact, the general rule of thumb is really "put as much a=
s
>> > possible into the most easily replaced layer of the stack". =A0This is=
,
>> > incidentally, why I've always been dubious about simple firmwares
>> > supplying a flattened device tree rather than including the device
>> > tree template in the kernel, cuboot style.
>>
>> The biggest advantage, IMHO, for adding DT to ARM, is actually to
>> decouple the hardware config information and the kernel. =A0If in the en=
d
>> the DT has to be shipped in the kernel then we're losing all this
>> advantage over the current state of things on ARM which still works
>> pretty well otherwise.
>>
>> In the best case, the simple firmware simply has to retrieve the
>> flattened device tree from flash, and pass it to the kernel just like
>> some anonymous blob. =A0And the simple firmware only needs to provide a
>> way for that DT blob to be updatable, like through an upload of a
>> replacement blob that was prepared offline. =A0Just like a ramdisk image
>> or the like.
>>
>> That doesn't need to be fancier than that, and the goal of having the DT
>> data tied to the hardware instead of the kernel is achieved.
>
> Imho that puts the DT in a similar category as initrd/initramfs, from
> the bootloader's point of view. =A0It's another blob whose address is
> passed to the kernel, just like initrd.
>
> Some bootloaders can't update blobs independently for technical
> reasons, or to be minimal.
>
> A device I'm using does kernel updates by updating the whole romfs
> boot image, which contains the kernel and other auxiliary blobs used
> for booting (splash screen, early irq handlers etc.) as well as the
> root filesystem.
>
> It is done that way to pack everything together in the small flash,
> and because the NOR flash eraseblocks are too large relative to the
> whole flash size to use separate partitions for kernel, boot
> filesystem and other blobs for booting.
This is totally fine. I've got no problem with a specific firmware
requiring everything (kernel,dt,rootfs) packed into a single image
file. Packing the image can be done at OS install time (instead of
prebuilding it) if the system builder want to retain the independent
hardware configuration aspects of using the device tree.
> Dedicating a 64kiB eraseblock out of 2MB just for a small DT would be
> quite wasteful. =A0Dedicating two to make it powerfail-safe would be
> even worse.
>
> So requiring that a bootloader can update the DT _independently_ of
> everything else is a bit much for some devices.
Independent update of the DT is a useful feature, but it is certainly
not a hard requirement. It's a far more likely use-case if the kernel
and DT is stored on a filesystem instead of bare NOR flash.
> But requiring that it's generally treated like other separate blob,
> i.e. in a similar way to initrd, and the kernel image itself, seems
> not unreasonable.
>
> Like initrd, some people will find they need to compile it in to the
> kernel image to fit some bootloader they can't change, or daren't risk
> changing in already rolled out devices that they want to update to a
> DT-using kernel.
Yes, I fully expect that. Fortunately the situation is better than it
was with powerpc. Since the machine id is being retained, a
DT-enabled kernel can continue to support non-DT systems. There will
not be a flag day to cut everything over to a new boot interface.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Request review of device tree documentation
From: Grant Likely @ 2010-06-14 16:29 UTC (permalink / raw)
To: Nicolas Pitre
Cc: microblaze-uclinux, devicetree-discuss, Jamie Lokier,
linuxppc-dev, Mitch Bradley, Dan Malek, Jeremy Kerr,
linux-arm-kernel, David Gibson
In-Reply-To: <alpine.LFD.2.00.1006141206110.13427@xanadu.home>
On Mon, Jun 14, 2010 at 10:23 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
> On Mon, 14 Jun 2010, Jamie Lokier wrote:
>> So requiring that a bootloader can update the DT _independently_ of
>> everything else is a bit much for some devices.
>
> In my opinion, this use case you're illustrating above simply could
> continue to _not_ use DT at all. =A0If your NOR flash is so small that yo=
u
> cannot spare some extra erase blocks, then this is a deeply embedded
> profile the current DT-on-ARM push is not really meant for. =A0You would
> be much better with a minimally configured kernel with all the hardware
> info statically compiled into the kernel and get away without all the DT
> parsing code altogether, like you're already doing today.
>
> While I think DT for ARM has advantages, I don't see us dropping the
> legacy ARM methods anytime soon, especially for existing or extremely
> constrained targets.
I completely agree.
g.
^ permalink raw reply
* Re: Request review of device tree documentation
From: Jamie Lokier @ 2010-06-14 16:33 UTC (permalink / raw)
To: Grant Likely
Cc: Nicolas Pitre, microblaze-uclinux, devicetree-discuss,
linuxppc-dev, Mitch Bradley, Dan Malek, Jeremy Kerr,
linux-arm-kernel, David Gibson
In-Reply-To: <AANLkTilZuMKzFN1hD1k4Q067jSkryPuWA2bhW0Y3GJTg@mail.gmail.com>
Grant Likely wrote:
> > Like initrd, some people will find they need to compile it in to the
> > kernel image to fit some bootloader they can't change, or daren't risk
> > changing in already rolled out devices that they want to update to a
> > DT-using kernel.
>
> Yes, I fully expect that. Fortunately the situation is better than it
> was with powerpc. Since the machine id is being retained, a
> DT-enabled kernel can continue to support non-DT systems. There will
> not be a flag day to cut everything over to a new boot interface.
That's excellent, thank you. I was a bit unsure about how that was going.
-- Jamie
^ permalink raw reply
* Re: Request review of device tree documentation
From: Mitch Bradley @ 2010-06-14 16:58 UTC (permalink / raw)
To: Jamie Lokier
Cc: Nicolas Pitre, microblaze-uclinux, devicetree-discuss,
linuxppc-dev, Dan Malek, Jeremy Kerr, linux-arm-kernel,
David Gibson
In-Reply-To: <20100614160201.GD9550@shareable.org>
I shall try to clarify this discussion.
There are actually two different things being discussed. The first is,
I hope, not too controversial. The second is so controversial as to be
a hopeless cause.
First, the primary use case for "keeping OFW alive" is for debugging
purposes. OFW remains resident in memory so that, if the OS is set to
allow it (not the default), a hot-key freezes the OS and enters OFW,
where a human can inspect the state of devices and OS data structures. A
high skill level is required, so it's okay if some fiddling is necessary
to find or establish virtual addresses or do similar magic . In my
career of working closely with hardware manufacturers, I and others have
found this feature to be extremely helpful. Often it has resulted in
the resolution of difficult problems that were blocking the ability to
ship the product - problems that resisted other kernel debugging techniques.
The second topic is the hypothetical use of OFW as a HAL. That will not
happen for several reasons. The opposition to the idea is widespread
and deeply held, and there are good arguments to support that
opposition. Furthermore, the economic conditions necessary for the
creation of such a HAL do not exist in the ARM world, nor indeed in the
Linux world in general. (The necessary condition is the ability for one
company to impose a substantial change by fiat - essentially a monopoly
position.)
Shall we agree, then, that any further discussion of the HAL issue is
"just for fun", and that nobody needs to feel threatened that it would
actually happen?
The potential for "vendors breaking out of the debugging use case and
turning it into a HAL" is miniscule, because
a) The callback is disabled by default
b) The technical challenges of the callback interface limit its
applicability to specific "wizard user" scenarios
c) OFW is unlikely to achieve sufficient market penetration for the HAL
thing to be worth doing
^ permalink raw reply
* Re: Request review of device tree documentation
From: Nicolas Pitre @ 2010-06-14 17:26 UTC (permalink / raw)
To: Mitch Bradley
Cc: microblaze-uclinux, devicetree-discuss, Jamie Lokier,
linuxppc-dev, Dan Malek, Jeremy Kerr, linux-arm-kernel,
David Gibson
In-Reply-To: <4C165FD1.6080505@firmworks.com>
On Mon, 14 Jun 2010, Mitch Bradley wrote:
> First, the primary use case for "keeping OFW alive" is for debugging purposes.
> OFW remains resident in memory so that, if the OS is set to allow it (not the
> default), a hot-key freezes the OS and enters OFW, where a human can inspect
> the state of devices and OS data structures. A high skill level is required,
> so it's okay if some fiddling is necessary to find or establish virtual
> addresses or do similar magic .
Why would you impose such pain on yourself in order to try to make OFW a
viable debugging tool on ARM for live kernels, while you can achieve the
same and more much less intrusively and so much more safely with a JTAG
based debugger?
If the cost of a JTAG solution is a concern, you can order USB based
JTAG dongles on the net for less than $30 and use them with OpenOCD[1].
Otherwise, what's wrong with already supported kgdb, or even kdb?
[1] http://openocd.berlios.de/web/
Nicolas
^ permalink raw reply
* Re: Request review of device tree documentation
From: Mitch Bradley @ 2010-06-14 18:20 UTC (permalink / raw)
To: Nicolas Pitre
Cc: microblaze-uclinux, devicetree-discuss, Jamie Lokier,
linuxppc-dev, Dan Malek, Jeremy Kerr, linux-arm-kernel,
David Gibson
In-Reply-To: <alpine.LFD.2.00.1006141311580.13427@xanadu.home>
Nicolas Pitre wrote:
> On Mon, 14 Jun 2010, Mitch Bradley wrote:
>
>
>> First, the primary use case for "keeping OFW alive" is for debugging purposes.
>> OFW remains resident in memory so that, if the OS is set to allow it (not the
>> default), a hot-key freezes the OS and enters OFW, where a human can inspect
>> the state of devices and OS data structures. A high skill level is required,
>> so it's okay if some fiddling is necessary to find or establish virtual
>> addresses or do similar magic .
>>
>
> Why would you impose such pain on yourself in order to try to make OFW a
> viable debugging tool on ARM for live kernels, while you can achieve the
> same and more much less intrusively and so much more safely with a JTAG
> based debugger?
>
> If the cost of a JTAG solution is a concern, you can order USB based
> JTAG dongles on the net for less than $30 and use them with OpenOCD[1].
>
If OFW is present on the machine, when a customer reports a problem I
can tell them
to do x and y and z and tell me what they see. In this manner, I have
often solved
difficult problems in minutes or hours.
Arranging for a JTAG dongle to appear at the customer site, then getting
it set up and
the necessary software installed and configured on a suitable host
system, typically
requires several days at best, plus potentially a lot of fiddling
depending on what
sort of host system the customer happens to have.
The phrase "impose such pain on yourself" presupposes that the technical
challenges
are much harder than they actually are. In fact, most of the pain comes
from dealing
with the "yuck, why would you ever want to do that" argument. I first
experienced
that argument in 1982, when Tom Lyon - Sun's Unix driver expert at the
time - threatened
to "scratch my disk" if I ported Forth to the Sun 1 machine. Tom later
recanted and
said that he was very glad that I had done so, after I used it to solve
several stop-ship
problems that came close to killing the company.
> Otherwise, what's wrong with already supported kgdb, or even kdb?
>
> [1] http://openocd.berlios.de/web/
>
Requires setup. The power of "it's just there, flip a switch to turn it
on" has to be
experienced in the heat of battle to be appreciated.
The other difference is that conventional debuggers focus on the problem of
inspecting and controlling the execution of preexisting programs, instead of
on the problem of constructing quick tests to test hypotheses. While it is
possible to use them to "poke around", it quickly becomes cumbersome if you
need to do anything more complicated than just looking. OFW's built-in
programming language is particularly well suited for making little test
loops
on-the-fly. Also, OFW has drivers for most of all of the system's
hardware, and
those drivers are independently developed from the Linux drivers. That
often
serves as a valuable "second opinion" to help discover the root cause of
hardware
misbehavior.
>
> Nicolas
>
>
^ permalink raw reply
* Re: Request review of device tree documentation
From: Nicolas Pitre @ 2010-06-14 19:40 UTC (permalink / raw)
To: Mitch Bradley
Cc: microblaze-uclinux, devicetree-discuss, Jamie Lokier,
linuxppc-dev, Dan Malek, Jeremy Kerr, linux-arm-kernel,
David Gibson
In-Reply-To: <4C1672FF.3060407@firmworks.com>
On Mon, 14 Jun 2010, Mitch Bradley wrote:
> Nicolas Pitre wrote:
> > On Mon, 14 Jun 2010, Mitch Bradley wrote:
> >
> >
> > > First, the primary use case for "keeping OFW alive" is for debugging
> > > purposes.
> > > OFW remains resident in memory so that, if the OS is set to allow it (not
> > > the
> > > default), a hot-key freezes the OS and enters OFW, where a human can
> > > inspect
> > > the state of devices and OS data structures. A high skill level is
> > > required,
> > > so it's okay if some fiddling is necessary to find or establish virtual
> > > addresses or do similar magic .
> >
> > Why would you impose such pain on yourself in order to try to make OFW a
> > viable debugging tool on ARM for live kernels, while you can achieve the
> > same and more much less intrusively and so much more safely with a JTAG
> > based debugger?
> >
> > If the cost of a JTAG solution is a concern, you can order USB based JTAG
> > dongles on the net for less than $30 and use them with OpenOCD[1].
> >
>
> If OFW is present on the machine, when a customer reports a problem I
> can tell them to do x and y and z and tell me what they see. In this
> manner, I have often solved difficult problems in minutes or hours.
That's assuming OFW is still intact somewhere and unaffected by said
problem.
> Arranging for a JTAG dongle to appear at the customer site, then
> getting it set up and the necessary software installed and configured
> on a suitable host system, typically requires several days at best,
> plus potentially a lot of fiddling depending on what sort of host
> system the customer happens to have.
Well, if I may use the SheevaPlug as an example, the actual FT2232 chip
currently used in most of those USB-JTAG dongle was provided directly on
the board. So you have this standard mini-B type USB connector on the
side of the device from which you get both a serial console and a JTAG
interface. All you need is a standard USB cable, just like the one you
get with a MP3 player or a digital camera, so there are plenty of those
around.
Software wise, people have provided self contained packages containing
OpenOCD, the necessary recovery binary images, and a script to bind it
all into a nice debricking utility for when you blow your flash content
away.
Oh and OpenOCD runs on Linux, Mac OS as well as Windows.
So there are ways to customize things and make this really straight
forward to users. But in the SheevaPlug case this ease of use was also
planned further by integrating easy JTAG access into the hardware
design. And a couple other ARM boards out there are doing the same
thing too.
> The phrase "impose such pain on yourself" presupposes that the
> technical challenges are much harder than they actually are. In fact,
> most of the pain comes from dealing with the "yuck, why would you ever
> want to do that" argument. I first experienced that argument in 1982,
> when Tom Lyon - Sun's Unix driver expert at the time - threatened to
> "scratch my disk" if I ported Forth to the Sun 1 machine. Tom later
> recanted and said that he was very glad that I had done so, after I
> used it to solve several stop-ship problems that came close to killing
> the company.
Sure. Pioneering solutions to save your life is always worth the pain.
But in this case some solutions were already developed and in use today.
So all you'll be doing here is sort of reinventing the wheel with the
only major benefit that it is a wheel that you're familiar with, while
the rest of the crowd is using another one already.
> > Otherwise, what's wrong with already supported kgdb, or even kdb?
> >
> > [1] http://openocd.berlios.de/web/
> >
>
> Requires setup. The power of "it's just there, flip a switch to turn
> it on" has to be experienced in the heat of battle to be appreciated.
Sure... when 1) the switch does still work even after damage was
incurred, and 2) you have someone on-site with the appropriate knowledge
for it.
> The other difference is that conventional debuggers focus on the problem of
> inspecting and controlling the execution of preexisting programs, instead of
> on the problem of constructing quick tests to test hypotheses. While it is
> possible to use them to "poke around", it quickly becomes cumbersome if you
> need to do anything more complicated than just looking. OFW's built-in
> programming language is particularly well suited for making little test loops
> on-the-fly.
Just for completeness, OpenOCD is not itself a debugger. It is a mean
to provide a GDB remote debugging interface amongst other things. It
has its own interface that can be used autonomously, and if I'm not
mistaken there is even a web interface to it. And OpenOCD can be
scripted (it contains a TCL interpreter). So you can do all sorts of
things with it. The most popular usage is to reflash a hosed system.
I even saw someone use a modified OpenOCD version to wait until the CPU
entered a particular function, have it single-stepped, and get
statistics on cache hits and misses on a per assembly instruction
granularity. You just can't get that sort of info with software
solutions running on the target as that screws up the results, nor with
an emulator as it is usually too slow to emulate some real life
situations.
> Also, OFW has drivers for most of all of the system's hardware, and
> those drivers are independently developed from the Linux drivers.
> That often serves as a valuable "second opinion" to help discover the
> root cause of hardware misbehavior.
Sure. I think this is a valid case, although it is quite a stretch to
have a duplicate set of drivers there "just in case" and expect them to
take over _live_ without skewed results. You usually want to reboot
into that other environment to perform your validation test, not to
hijack the hardware from under the running OS, fiddle with it, and give
it back to the OS hoping that everything will continue to go well.
Furthermore, those independently developed drivers are not the best
utilization of resources. You will hardly find people willing to
re-implement something that already exists out there. And if they have
to do it once, they'll do it for Linux directly. That's why ideas such
as using Linux as a bootloader to boot Linux are becoming more popular.
Even U-Boot is leveraging Linux for a lot of driver code. Otherwise
those duplicated drivers are simple versions for bootloader purposes
with no similar concerns about concurrency and performance you typically
find in a full fledged OS.
There is even a trend amongst hardware vendors to converge around
"standardized" hardware interfaces for many class of devices, so they
even don't have any, or very little, driver development to do.
So yes, in theory, this "second opinion" from independently developed
drivers would be quite useful. But in practice this is rarely
affordable.
Nicolas
^ permalink raw reply
* Re: Request review of device tree documentation
From: Ben Dooks @ 2010-06-14 20:00 UTC (permalink / raw)
To: Grant Likely
Cc: Mitch Bradley, Nicolas Pitre, devicetree-discuss, linuxppc-dev,
microblaze-uclinux, Olof Johansson, Dan Malek, Jeremy Kerr,
linux-arm-kernel
In-Reply-To: <AANLkTimc12G-YYTd4yQiviY-ijvJ9TzVEmxxaoF43xVR@mail.gmail.com>
On Sun, Jun 13, 2010 at 11:36:57PM -0600, Grant Likely wrote:
> On Sun, Jun 13, 2010 at 2:29 AM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> > On Sat, 2010-06-12 at 20:45 -1000, Mitch Bradley wrote:
> >
> >> Either fought or embraced. To the extent that it is possible to focus
> >> solely on Linux and ARM, one could image doing a good HAL.
> >
> > That will come with a huge amount of comunity resistance sadly, but I
> > can imagine distros liking it.
> >
> > In general, I much prefer having all the necessary native drivers in the
> > kernel, and the device-tree to provide the right representation, and
> > avoid trying to abstract "methods" via a HAL. It's the Linux philosophy
> > as much as possible (even when defeated by ACPI).
> >
> > But if we're going to be forced by vendors into HALs, we can also make
> > sure that whatever they come up with is half reasonable :-)
>
> I think there is more to be concerned about regarding binary blobs
> than HALs. Many of the new SoCs require closed binaries to use all
> the hardware right now (graphics cores in particular).
>
> Board vendors seem to be taking the plunge and modifying the kernel
> rather than trying to create a HAL for driving board specific
> features.
In my view HALs are a bad idea, they constrain you to one calling method
and make it difficult to evolve support in the kernel. I belive it is
part of the reason that we've always tried to avoid a standardised
kernel driver interface.
--
Ben
Q: What's a light-year?
A: One-third less calories than a regular year.
^ permalink raw reply
* Re: Request review of device tree documentation
From: Mark Brown @ 2010-06-14 20:08 UTC (permalink / raw)
To: Nicolas Pitre
Cc: microblaze-uclinux, devicetree-discuss, Jamie Lokier,
linuxppc-dev, Mitch Bradley, Dan Malek, Jeremy Kerr,
linux-arm-kernel, David Gibson
In-Reply-To: <alpine.LFD.2.00.1006141432530.13427@xanadu.home>
On Mon, Jun 14, 2010 at 03:40:19PM -0400, Nicolas Pitre wrote:
> On Mon, 14 Jun 2010, Mitch Bradley wrote:
> > Arranging for a JTAG dongle to appear at the customer site, then
> > getting it set up and the necessary software installed and configured
> > on a suitable host system, typically requires several days at best,
> > plus potentially a lot of fiddling depending on what sort of host
> > system the customer happens to have.
> Well, if I may use the SheevaPlug as an example, the actual FT2232 chip
> currently used in most of those USB-JTAG dongle was provided directly on
> the board. So you have this standard mini-B type USB connector on the
> side of the device from which you get both a serial console and a JTAG
> interface. All you need is a standard USB cable, just like the one you
> get with a MP3 player or a digital camera, so there are plenty of those
> around.
The other thing here is of course that if JTAG is a problem serial or
other console access is likely to also be a problem - it's likely to not
be physically present and at least as painful to set up as JTAG.
^ permalink raw reply
* [PATCH 0/2 v2] mpc5200 ac97 gpio reset
From: Eric Millbrandt @ 2010-06-14 21:55 UTC (permalink / raw)
To: Grant Likely; +Cc: Mark Brown, linuxppc-dev
These patches reimplement the reset fuction in the ac97 to use gpio pins
instead of using the mpc5200 ac97 reset functionality in the psc. This
avoids a problem in which attached ac97 devices go into "test" mode appear
unresponsive.
These patches were tested on a pcm030 baseboard and on custom hardware with
a wm9715 audio codec/touchscreen controller.
Eric Millbrandt
---
changes since v1
- Refactored to manipulate port_config and gpio pins internally instead of
exporting an API.
- Amended commit message with comments from Mark Brown
- Refactored to move the port_config manipulation to platform code.
- Remove the gpio pins from the device-tree
Eric Millbrandt (2):
powerpc/5200: add mpc5200_psc_ac97_gpio_reset
sound/soc: mpc5200_psc_ac97: Use gpio pins for cold reset
arch/powerpc/include/asm/mpc52xx.h | 1 +
arch/powerpc/platforms/52xx/mpc52xx_common.c | 103 ++++++++++++++++++++++=
++++
sound/soc/fsl/mpc5200_psc_ac97.c | 33 +++++++-
3 files changed, 133 insertions(+), 4 deletions(-)
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-
This e-mail and the information, including any attachments, it contains are=
intended to be a confidential communication only to the person or entity t=
o whom it is addressed and may contain information that is privileged. If t=
he reader of this message is not the intended recipient, you are hereby not=
ified that any dissemination, distribution or copying of this communication=
is strictly prohibited. If you have received this communication in error, =
please immediately notify the sender and destroy the original message.
Thank you.
Please consider the environment before printing this email.
^ permalink raw reply
* [PATCH 1/2 v2] powerpc/5200: add mpc5200_psc_ac97_gpio_reset
From: Eric Millbrandt @ 2010-06-14 21:55 UTC (permalink / raw)
To: Grant Likely; +Cc: Mark Brown, linuxppc-dev, Eric Millbrandt
In-Reply-To: <1276552518-11441-1-git-send-email-emillbrandt@dekaresearch.com>
Work around a silicon bug in the ac97 reset functionality of the
mpc5200(b). The implementation of the ac97 "cold" reset is flawed.
If the sync and output lines are high when reset is asserted the
attached ac97 device may go into test mode. Avoid this by
reconfiguring the psc to gpio mode and generating the reset manually.
>From MPC5200B User's Manual:
"Some AC97 devices goes to a test mode, if the Sync line is high
during the Res line is low (reset phase). To avoid this behavior the
Sync line must be also forced to zero during the reset phase. To do
that, the pin muxing should switch to GPIO mode and the GPIO control
register should be used to control the output lines."
Signed-off-by: Eric Millbrandt <emillbrandt@dekaresearch.com>
---
changes since v1
- Refactored to manipulate port_config and gpio pins internally instead of
exporting an API.
arch/powerpc/include/asm/mpc52xx.h | 1 +
arch/powerpc/platforms/52xx/mpc52xx_common.c | 103 ++++++++++++++++++++++=
++++
2 files changed, 104 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/mpc52xx.h b/arch/powerpc/include/asm/=
mpc52xx.h
index b664ce7..1f41382 100644
--- a/arch/powerpc/include/asm/mpc52xx.h
+++ b/arch/powerpc/include/asm/mpc52xx.h
@@ -271,6 +271,7 @@ struct mpc52xx_intr {
/* mpc52xx_common.c */
extern void mpc5200_setup_xlb_arbiter(void);
extern void mpc52xx_declare_of_platform_devices(void);
+extern int mpc5200_psc_ac97_gpio_reset(int psc_number);
extern void mpc52xx_map_common_devices(void);
extern int mpc52xx_set_psc_clkdiv(int psc_id, int clkdiv);
extern unsigned int mpc52xx_get_xtal_freq(struct device_node *node);
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_common.c b/arch/powerpc/pl=
atforms/52xx/mpc52xx_common.c
index a46bad0..a9866fa 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_common.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_common.c
@@ -12,9 +12,11 @@
#undef DEBUG
+#include <linux/gpio.h>
#include <linux/kernel.h>
#include <linux/spinlock.h>
#include <linux/of_platform.h>
+#include <linux/of_gpio.h>
#include <asm/io.h>
#include <asm/prom.h>
#include <asm/mpc52xx.h>
@@ -37,6 +39,11 @@ static struct of_device_id mpc52xx_bus_ids[] __initdata =
=3D {
{}
};
+static struct of_device_id mpc52xx_gpio_simple[] =3D {
+ { .compatible =3D "fsl,mpc5200-gpio", },
+ {}
+};
+
/*
* This variable is mapped in mpc52xx_map_wdt() and used in mpc52xx_restar=
t().
* Permanent mapping is required because mpc52xx_restart() can be called
@@ -82,6 +89,13 @@ mpc5200_setup_xlb_arbiter(void)
iounmap(xlb);
}
+/*
+ * This variable is mapped in mpc52xx_write_port_config() and
+ * mpc52xx_read_port_config().
+ */
+DEFINE_SPINLOCK(mpc52xx_gpio_lock);
+static u32 __iomem *port_config;
+
/**
* mpc52xx_declare_of_platform_devices: register internal devices and chil=
dren
* of the localplus bus to the of_plat=
form
@@ -117,6 +131,7 @@ void __init
mpc52xx_map_common_devices(void)
{
struct device_node *np;
+ const u32 *regaddr;
/* mpc52xx_wdt is mapped here and used in mpc52xx_restart,
* possibly from a interrupt context. wdt is only implement
@@ -135,6 +150,13 @@ mpc52xx_map_common_devices(void)
np =3D of_find_matching_node(NULL, mpc52xx_cdm_ids);
mpc52xx_cdm =3D of_iomap(np, 0);
of_node_put(np);
+
+ /* port_config register */
+ np =3D of_find_matching_node(NULL, mpc52xx_gpio_simple);
+ regaddr =3D of_get_address(np, 0, NULL, NULL);
+ port_config =3D ioremap((u32) of_translate_address(np, regaddr), 0x=
4);
+
+ of_node_put(np);
}
/**
@@ -233,3 +255,84 @@ mpc52xx_restart(char *cmd)
while (1);
}
+
+#define PSC1_RESET 254
+#define PSC1_SYNC 244
+#define PSC1_SDATA_OUT 246
+#define PSC2_RESET 253
+#define PSC2_SYNC 240
+#define PSC2_SDATA_OUT 242
+#define MPC52xx_GPIO_PSC1_MASK 0x7
+#define MPC52xx_GPIO_PSC2_MASK (0x7<<4)
+
+/**
+ * mpc5200_psc_ac97_gpio_reset: Use gpio pins to reset the ac97 bus
+ *
+ * @psc: psc number to reset (only psc 1 and 2 support ac97)
+ */
+int mpc5200_psc_ac97_gpio_reset(int psc_number)
+{
+ unsigned long flags;
+ u32 gpio;
+ u32 mux;
+ int out;
+ int reset;
+ int sync;
+
+ if (!port_config)
+ return -ENODEV;
+
+ switch (psc_number) {
+ case 0:
+ reset =3D PSC1_RESET; /* AC97_1_RES */
+ sync =3D PSC1_SYNC; /* AC97_1_SYNC */
+ out =3D PSC1_SDATA_OUT; /* AC97_1_SDATA_OUT */
+ gpio =3D MPC52xx_GPIO_PSC1_MASK;
+ break;
+ case 1:
+ reset =3D PSC2_RESET; /* AC97_2_RES */
+ sync =3D PSC2_SYNC; /* AC97_2_SYNC */
+ out =3D PSC2_SDATA_OUT; /* AC97_2_SDATA_OUT */
+ gpio =3D MPC52xx_GPIO_PSC2_MASK;
+ break;
+ default:
+ printk(KERN_ERR __FILE__ ": "
+ "Unable to determine PSC, no ac97 cold-reset will be =
"
+ "performed\n");
+ return -ENODEV;
+ }
+
+ gpio_request(reset, "reset");
+ gpio_request(sync, "sync");
+ gpio_request(out, "out");
+
+ spin_lock_irqsave(&mpc52xx_gpio_lock, flags);
+
+ mux =3D in_be32(port_config);
+
+ /* Reconfiure pin-muxing to gpio */
+ out_be32(port_config, mux & (~gpio));
+
+ /* Assert cold reset */
+ gpio_direction_output(sync, 0);
+ gpio_direction_output(out, 0);
+ gpio_direction_output(reset, 0);
+
+ /* wait at lease 1 us */
+ udelay(2);
+
+ /* Deassert reset */
+ gpio_direction_output(reset, 1);
+
+ /* Restore pin-muxing */
+ out_be32(port_config, mux);
+
+ spin_unlock_irqrestore(&mpc52xx_gpio_lock, flags);
+
+ gpio_free(out);
+ gpio_free(sync);
+ gpio_free(reset);
+
+ return 0;
+}
+EXPORT_SYMBOL(mpc5200_psc_ac97_gpio_reset);
--
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-
1.6.3.1
This e-mail and the information, including any attachments, it contains are=
intended to be a confidential communication only to the person or entity t=
o whom it is addressed and may contain information that is privileged. If t=
he reader of this message is not the intended recipient, you are hereby not=
ified that any dissemination, distribution or copying of this communication=
is strictly prohibited. If you have received this communication in error, =
please immediately notify the sender and destroy the original message.
Thank you.
Please consider the environment before printing this email.
^ permalink raw reply related
* [PATCH 2/2 v3] sound/soc: mpc5200_psc_ac97: Use gpio pins for cold reset
From: Eric Millbrandt @ 2010-06-14 21:55 UTC (permalink / raw)
To: Grant Likely; +Cc: Mark Brown, linuxppc-dev, Eric Millbrandt
In-Reply-To: <1276552518-11441-2-git-send-email-emillbrandt@dekaresearch.com>
Call the gpio reset platform function instead of using the flawed
ac97 functionality of the MPC5200(b)
>From MPC5200B User's Manual:
"Some AC97 devices goes to a test mode, if the Sync line is high
during the Res line is low (reset phase). To avoid this behavior the
Sync line must be also forced to zero during the reset phase. To do
that, the pin muxing should switch to GPIO mode and the GPIO control
register should be used to control the output lines."
Signed-off-by: Eric Millbrandt <emillbrandt@dekaresearch.com>
---
changes since v1
- Amended with comments from Mark Brown
- Fall back to the original reset implementation if no gpio pins are define=
d
in the device tree
changes since v2
- Refactored to move the port_config manipulation to platform code.
- Remove the gpio pins from the device-tree
sound/soc/fsl/mpc5200_psc_ac97.c | 33 +++++++++++++++++++++++++++++----
1 files changed, 29 insertions(+), 4 deletions(-)
diff --git a/sound/soc/fsl/mpc5200_psc_ac97.c b/sound/soc/fsl/mpc5200_psc_a=
c97.c
index e2ee220..380a127 100644
--- a/sound/soc/fsl/mpc5200_psc_ac97.c
+++ b/sound/soc/fsl/mpc5200_psc_ac97.c
@@ -20,6 +20,7 @@
#include <asm/time.h>
#include <asm/delay.h>
+#include <asm/mpc52xx.h>
#include <asm/mpc52xx_psc.h>
#include "mpc5200_dma.h"
@@ -100,19 +101,43 @@ static void psc_ac97_warm_reset(struct snd_ac97 *ac97=
)
{
struct mpc52xx_psc __iomem *regs =3D psc_dma->psc_regs;
+ mutex_lock(&psc_dma->mutex);
+
out_be32(®s->sicr, psc_dma->sicr | MPC52xx_PSC_SICR_AWR);
udelay(3);
out_be32(®s->sicr, psc_dma->sicr);
+
+ mutex_unlock(&psc_dma->mutex);
}
+#define MPC52xx_PSC_SICR_ACRB (0x8 << 24)
static void psc_ac97_cold_reset(struct snd_ac97 *ac97)
{
struct mpc52xx_psc __iomem *regs =3D psc_dma->psc_regs;
- /* Do a cold reset */
- out_8(®s->op1, MPC52xx_PSC_OP_RES);
- udelay(10);
- out_8(®s->op0, MPC52xx_PSC_OP_RES);
+ mutex_lock(&psc_dma->mutex);
+
+ switch (psc_dma->id) {
+ case 0:
+ case 1:
+ mpc5200_psc_ac97_gpio_reset(psc_dma->id);
+ dev_info(psc_dma->dev, "cold reset\n");
+
+ /* Notify the PSC that a reset has occurred */
+ out_be32(®s->sicr, psc_dma->sicr | MPC52xx_PSC_SICR_ACRB=
);
+
+ /* Re-enable RX and TX */
+ out_8(®s->command, MPC52xx_PSC_TX_ENABLE | MPC52xx_PSC_R=
X_ENABLE);
+
+ break;
+ default:
+ dev_err(psc_dma->dev,
+ "Unable to determine PSC, no cold-reset will be "
+ "performed\n");
+ }
+
+ mutex_unlock(&psc_dma->mutex);
+
msleep(1);
psc_ac97_warm_reset(ac97);
}
--
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-
1.6.3.1
This e-mail and the information, including any attachments, it contains are=
intended to be a confidential communication only to the person or entity t=
o whom it is addressed and may contain information that is privileged. If t=
he reader of this message is not the intended recipient, you are hereby not=
ified that any dissemination, distribution or copying of this communication=
is strictly prohibited. If you have received this communication in error, =
please immediately notify the sender and destroy the original message.
Thank you.
Please consider the environment before printing this email.
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox