> -----Original Message----- > From: > [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] labs.org] On Behalf Of John Williams > Sent: Tuesday, November 27, 2007 4:53 PM > To: Stephen Neuendorffer > Cc: Michal Simek; linuxppc-embedded > Subject: Re: Xilinx devicetrees > > Stephen Neuendorffer wrote: > > >>From: John Williams [mailto:[EMAIL PROTECTED] > > >>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. > > > > I think the userspace is actually much more critical than > the kernel for > > most of these things (with the exception of msrset/msrclr, and the > > barrel shifter perhaps). Unfortunately, even if you implement an > > alternatives-style mechanism for the kernel, you're still hosed for > > userspace. > > I haven't benchmarks each option on the kernel - you are right that > shift is a big one, but mul I think is also important, given > that every > array access generates an integer multiply,
Good point. > > Once I a big enough system, it's just unfeasible to > > recompile everything anyway. I think this is where > autoconfig starts to > > break down. > > I'm not sure I agree, here, given that most people building > MicroBlaze > systems are doing so with uClinux-dist (or PetaLinux), you > can do a full > rebuilt, kernel libs apps, in a couple of minutes. Much shorter than > sythnesis and P&R, that's for sure (and runtime is linear in size, > unlike P&R :) Let's not bash the P&R guys too much... You try working on a problem that is known to be insolvable, and where no matter how many people you make happier, you'll always get bashed by the guy whose design no longer meets timing. :) > > It's not nice, I agree. I think the key principle should be that I > > should be able to get a system working as quickly as possible, and I > > might optimize things later. One thing that device trees > will allow is > > for *all* the drivers to get compiled in to the kernel, and > only as a > > late stage operation does a designer need to start throwing > things away. > > Using traps I can easily start with a 'kitchen sink' > design, and start > > discarding processor features, relying on the traps. When I get low > > enough down on the performance curve, I can uas an autoconfig-type > > mechanism to regain a little of what I lost by optimizing > away the trap > > overhead. > > OK, but now we have a kernel dependent on *3* files - a DTS, a > Kconfig.auto, and (indirectly) the bitstream itself. The kernel might be generated from them, but it is not *dependent* on them. The same kernel can run on other hardware, with other dts's. If there was a traps mechanism (or alternatives), then it could also run on other designs with different processor features. > Another thing I suggested to Michal recently, perhaps we need > kernel/lib/libof to store common OF / DT handling code. Much better > than duplicating it accross microblaze and PPC, and maybe > other arch's > would also see the light.. That would also add a claim for > the DTC to > go in scripts/ There's some shared code in 2.6.24-rc in drivers/of. Now that things are settling down in terms of bugs, I'll probably transition to pushing a 2.6.24-rc branch soon. However, the few brief conversations I've had suggest that what microblaze might need or want has very little influence until it is visible in mainline. Once that happens, I think it will be easy to justify putting code like libfdt and some of the kernel of/dt code in a common place. So, John: would you care to make a goal (for say 2.6.25 or 26) of working with me to get the microblaze into mainline? I think the community exists to keep things maintained, but I'm guessing that it would help to have an existing LKMLer or two take a look over the code. Given the move towards device trees, getting someone from powerpc would seem to be natural. Anybody interested? Steve _______________________________________________ Linuxppc-embedded mailing list [email protected] https://ozlabs.org/mailman/listinfo/linuxppc-embedded
