* 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: 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 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 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: 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: 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: 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: 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: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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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:25 UTC (permalink / raw)
To: Mitch Bradley
Cc: Nicolas Pitre, devicetree-discuss, linuxppc-dev,
microblaze-uclinux, Olof Johansson, Dan Malek, Jeremy Kerr,
linux-arm-kernel
In-Reply-To: <4C15DE2E.1050905@firmworks.com>
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?
^ permalink raw reply
* Re: Port Linux to ML510
From: srikanth krishnakar @ 2010-06-14 8:56 UTC (permalink / raw)
To: kostas padarnitsas; +Cc: linuxppc-dev
In-Reply-To: <BAY152-w58B66B551376FF621F6E4DBCD80@phx.gbl>
[-- Attachment #1: Type: text/plain, Size: 2354 bytes --]
If any changes w.r.t board then John Linn (XILINX) should be able to provide
some pointers.
2010/6/11 kostas padarnitsas <kpada84@hotmail.com>
> Hi Srikant,
>
> Thanks for your help. I checked the driver versions and they seem ok. The
> problem is that when I download the linux image the program counter is not
> set to the address of boot sector of linux kernel, so linux doesn't boot. On
> the other hand with the ML507 everything works perfectly. Any idea??
>
> Thanks in advance,
> Kostas
>
> ------------------------------
> Date: Thu, 10 Jun 2010 12:34:56 +0530
> Subject: Re: Port Linux to ML510
> From: skrishnakar@gmail.com
> To: kpada84@hotmail.com
> CC: linuxppc-dev@lists.ozlabs.org
>
>
> Hi kostas,
>
> You need to verify that the driver version of serial and Ethernet (probably
> X-LLTEMAC) provided in the virtex440.dts matches version used in kernel.
> Look for "compatible = <version>" in the drivers. You can probably use EDK
> 11.2 as it is the latest from Xilinx.
>
> Have you generated your own DTS and Bitstream (download.bit) files ?
>
> If not then you should look for suitable download.bit for you kernel.
>
> -Srikant
>
> 2010/6/10 kostas padarnitsas <kpada84@hotmail.com>
>
> Hello,
>
> I am trying to port Linux to PowerPC on the ML510 Xilinx board. I am using
> EDK 10.1.3 to build the hardware and also device tree generator and the
> linux kernel from xilinx git. I followed the tutorial from
> http://xilinx.wikidot.com/powerpc-linux but I have no output. I have
> attached my .mhs file and the .dts. Any ideas what may cause this problem
> because I did the same thing with ML507 and it was working perfectly?
>
> Thanks in advance,
> Kostas
>
> ------------------------------
> Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. Sign up
> now. <https://signup.live.com/signup.aspx?id=60969>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
>
>
>
> --
> "The Good You Do, The Best You GET"
>
> Regards
> Srikanth Krishnakar
> **********************
>
> ------------------------------
> Hotmail: Free, trusted and rich email service. Get it now.<https://signup.live.com/signup.aspx?id=60969>
>
--
"The Good You Do, The Best You GET"
Regards
Srikanth Krishnakar
**********************
[-- Attachment #2: Type: text/html, Size: 3537 bytes --]
^ permalink raw reply
* Re: Request review of device tree documentation
From: Russell King - ARM Linux @ 2010-06-14 7:38 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: <AANLkTinwL0XtMNG13inr_1UliOlqZkyr4dlvG-ZGL9JT@mail.gmail.com>
On Sun, Jun 13, 2010 at 11:23:45PM -0600, Grant Likely wrote:
> >> Or perhaps the MMU and caches can be turned off for the duration of the
> >> callback.
> >> I don't have the details of ARM MMUs and caches reloaded into my head
> >> yet. Maybe next week...
We've had these kinds of questions in the past. Doing what you're asking
above is not really an option - it requires:
1. disable all IRQs
2. setup 1:1 MMU mappings for code to turn off MMU
(requires new page table)
3. disable imprecise exceptions
4. flush caches and TLBS
5. jump to 1:1 mapping area for code to disable MMU
6. disable caches and mmu
7. call function
8. flush caches and TLBs
9. re-enable caches and mmu
10. re-enable imprecise exceptions
11. switch back to original MMU mappings
12. re-enable all IRQs
This is fine if you don't care at all about interrupt latency.
Unfortunately, most people do care about interrupt latency because
that directly affects interactivity and system performance. The
called function could not enable interrupts or exceptions - as the
CPU vectors are in virtual space, disabling the MMU effectively
makes them disappear.
Moreover, with the MMU and caches disabled, the CPU performance is
extremely poor, so the called function will run slowly.
So, disabling the MMU isn't really viable.
Now, if the external code was fully PIC, we could then run it with
the MMU enabled. However, this wouldn't really help - the external
code could not access any devices without knowledge of how the kernel
setup the V:P translations.
So you'd need to pass some kind of data structure giving locations of
devices to the called code - but then what if the kernel doesn't have
the device mapped?
^ permalink raw reply
* Re: Request review of device tree documentation
From: Mitch Bradley @ 2010-06-14 7:45 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Nicolas Pitre, devicetree-discuss, linuxppc-dev,
microblaze-uclinux, Olof Johansson, Dan Malek, Jeremy Kerr,
linux-arm-kernel
In-Reply-To: <20100614073828.GA6095@n2100.arm.linux.org.uk>
Russell King - ARM Linux wrote:
> On Sun, Jun 13, 2010 at 11:23:45PM -0600, Grant Likely wrote:
>
>>>> Or perhaps the MMU and caches can be turned off for the duration of the
>>>> callback.
>>>> I don't have the details of ARM MMUs and caches reloaded into my head
>>>> yet. Maybe next week...
>>>>
>
> We've had these kinds of questions in the past. Doing what you're asking
> above is not really an option - it requires:
>
> 1. disable all IRQs
> 2. setup 1:1 MMU mappings for code to turn off MMU
> (requires new page table)
> 3. disable imprecise exceptions
> 4. flush caches and TLBS
> 5. jump to 1:1 mapping area for code to disable MMU
> 6. disable caches and mmu
> 7. call function
> 8. flush caches and TLBs
> 9. re-enable caches and mmu
> 10. re-enable imprecise exceptions
> 11. switch back to original MMU mappings
> 12. re-enable all IRQs
>
> This is fine if you don't care at all about interrupt latency.
> Unfortunately, most people do care about interrupt latency because
> that directly affects interactivity and system performance. The
> called function could not enable interrupts or exceptions - as the
> CPU vectors are in virtual space, disabling the MMU effectively
> makes them disappear.
>
> Moreover, with the MMU and caches disabled, the CPU performance is
> extremely poor, so the called function will run slowly.
>
> So, disabling the MMU isn't really viable.
>
None of this is a deal-breaker for the kind of debugging tasks that are
the primary use case for the callback.
> Now, if the external code was fully PIC, we could then run it with
> the MMU enabled. However, this wouldn't really help - the external
> code could not access any devices without knowledge of how the kernel
> setup the V:P translations.
>
> So you'd need to pass some kind of data structure giving locations of
> devices to the called code - but then what if the kernel doesn't have
> the device mapped?
>
>
^ permalink raw reply
* Re: Request review of device tree documentation
From: Mitch Bradley @ 2010-06-14 6:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Nicolas Pitre, microblaze-uclinux, devicetree-discuss,
linuxppc-dev, Olof Johansson, Dan Malek, Jeremy Kerr,
linux-arm-kernel
In-Reply-To: <1276495772.2552.22.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Sun, 2010-06-13 at 23:13 -0600, Grant Likely wrote:
>
>>> We use that to suck the device-tree, which we flatten, and then
>>>
>> re-enter
>>
>>> the kernel with the "common" entry interface.
>>>
>> I don't think I want to do the same on ARM. I'd rather have the
>> prom_init stuff in a boot wrapper, or have OFW itself generate the
>> flat representation before booting the kernel.
>>
>
> But then it's no longer OF. IE. A compliant OF implementation provides a
> client interface API :-)
>
> This is going to be especially important if Mitch wants to keep OF
> alive.
>
> I suppose it could be done via a wrapper like prom_init, which flattens
> the tree, and sticks somewhere in a property the address of the OF
> client interface callback though it's a tad awkward. If well defined, I
> suppose Mitch might even be able to make his OF natively boot kernels
> that way but that's of course up to him.
>
I'm willing to create a flattened tree. I can provide both a client
interface and a flattened tree. The kernel probably won't use the
client interface to any significant extent.
Way back in the misty annals of history, I dreamed of having a common
interface between firmware and OSs. That didn't happen. Every OS
insisted on defining its own interface and creating a custom bootloader,
or in some cases a half dozen of them.
>
>> I'm trying to constrain the number of things that could go wrong by
>> defining only one way for getting the device tree data into the
>> kernel.
>>
>
> I understand, and the flattened method is the most versatile, I'm just
> pointing out the situation here :-)
>
>
>> Right. We don't need to use OFW/RTAS to handle this use case.
>>
>
> Definitely not. It will depend on whatever hypervisor interface is
> implemented in a given environment. Though I do like the idea of passing
> precompiled bits of .dtb around for hotplug :-) We could make that a
> standard way of KVM to do things in embedded space.
>
> Cheers,
> Ben.
>
>
>
^ permalink raw reply
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