From: John Williams <jwilliams@itee•uq.edu.au>
To: Stephen Neuendorffer <stephen.neuendorffer@xilinx•com>
Cc: Michal Simek <simekm2@fel•cvut.cz>,
linuxppc-embedded <linuxppc-embedded@ozlabs•org>
Subject: Re: Xilinx devicetrees
Date: Wed, 28 Nov 2007 09:55:28 +1000 [thread overview]
Message-ID: <474CAE70.3030005@itee.uq.edu.au> (raw)
In-Reply-To: <20071125181506.EE2041BA004F@mail141-cpk.bigfish.com>
Hi folks,
Stephen Neuendorffer wrote:
> > Binding it to a kernel, is a non-starter for us.
>
> I agree that this is not the best way of leveraging the power of device
> trees. The point is that by using a device tree, you haven't lost
> anything you can do currently. In the future we might have one kernel
> which supports all versions of all our IP, along with all flavors of
> microblaze and powerpc... You would only ever need to recompile this
> kernel as a final optimization, if at all.
I strongly support the OF / device tree work being done, from its own
perspective and also as a path to MicroBlaze/PPC unification, however
there is one critical difference that I have not seen adequately
addressed yet.
MicroBlaze is a highly configurable CPU in terms of its instruction set,
features and so on. To make use of this, it is essential that each
kernel image be compiled to match the CPU configuration. While a
generic kernel, making use of no features (MUL, DIV, Shift, MSR ops etc)
would run on any CPU, performance would be abysmal.
In my view it's not acceptable to present these as options for the user
to select at kernel config time. With N yes/no parameters, there is 1
correct configuration, and 2^N-1 incorrect ones. The odds of the user
falling upon a configuration that at worst fails to boot, or at best is
not optimally matched to the hardware, are high.
This same issue also applies to C libraries and apps - they must be
compiled with prior knowledge of the CPU. This is why our
microblaze-uclinux-gcc toolchain, with multilib'd uClibc, is almost 400meg!
Wrapping every mul, div, shift etc in a function call is clearly not
feasible. Things like the msrset/msrclr ops have a modest but
measurable impact on kernel code size and performance - it's just not
reasonable to add any level of indirection in there.
I have thought about dynamic (boot-time) code re-writing as one
possibility here, but it very quickly gets nasty. All of the
"optimised" opcodes (MUL/DIV/Shift etc) are smaller than their emulated
counterparts, so in principle we could re-write the text segment with
the optimised opcode, then NOP pad, but that's still inefficient. As
soon as we start talking about dynamic code relocation, re-writing
relative offsets in loops, ... yuck.. We'd be putting half of mb-ld
into the arch early boot code (or bootloader...)
The opposite approach, to build with all instructions enabled and
install exception handlers to deal with the fixups, is also pretty awful.
I find myself asking the question - for what use cases does the current
static approach used in MicroBlaze (with the PetaLinux BSP /
Kconfig.auto) *not* work?
One compromise approach might be to have a script in
arch/microblaze/scripts, called by the arch Makefile, that cracks open
the DT at build time and extracts appropriate cpu flags.
Finally, what is the LKML position on DT files going into the kernel
source tree?
Regards,
John
next prev parent reply other threads:[~2007-11-28 0:12 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-24 11:37 Xilinx devicetrees David H. Lynch Jr.
2007-11-24 17:12 ` Grant Likely
2007-11-25 5:24 ` Stephen Neuendorffer
2007-11-25 9:37 ` David H. Lynch Jr.
2007-11-25 18:15 ` Stephen Neuendorffer
2007-11-27 23:55 ` John Williams [this message]
2007-11-28 0:27 ` Grant Likely
2007-11-28 0:28 ` Stephen Neuendorffer
2007-11-28 0:52 ` John Williams
2007-11-28 14:33 ` Jon Loeliger
2007-11-28 17:28 ` Stephen Neuendorffer
2007-11-28 18:12 ` Grant Likely
2007-11-29 10:56 ` David H. Lynch Jr.
2007-11-25 9:15 ` David H. Lynch Jr.
2007-11-25 22:21 ` Grant Likely
2007-11-25 22:55 ` David H. Lynch Jr.
2007-11-25 23:58 ` Stephen Neuendorffer
2007-11-26 21:36 ` David H. Lynch Jr.
2007-12-13 2:40 ` Koss, Mike (Mission Systems)
2007-11-26 16:30 ` Grant Likely
2007-11-26 20:28 ` David H. Lynch Jr.
2007-11-26 21:16 ` David H. Lynch Jr.
2007-11-26 21:55 ` Stephen Neuendorffer
2007-11-26 22:09 ` Grant Likely
2007-11-26 22:19 ` Koss, Mike (Mission Systems)
2007-12-13 4:52 ` Stephen Neuendorffer
2007-12-13 13:49 ` Koss, Mike (Mission Systems)
2007-12-13 17:36 ` Stephen Neuendorffer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=474CAE70.3030005@itee.uq.edu.au \
--to=jwilliams@itee$(echo .)uq.edu.au \
--cc=linuxppc-embedded@ozlabs$(echo .)org \
--cc=simekm2@fel$(echo .)cvut.cz \
--cc=stephen.neuendorffer@xilinx$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox