On 17:30 Fri 01 Apr , Detlef Vollmann wrote: > On 04/01/11 16:59, Arnd Bergmann wrote: > >On Friday 01 April 2011, Detlef Vollmann wrote: > >>On 04/01/11 15:54, Arnd Bergmann wrote: > > > >>>9. All interesting work is going into a handful of platforms, all of which > >>> are ARMv7 based. > >>Define interesting. > > > >The ones that are causing the churn that we're talking about. > >Platforms that have been working forever and only need to get > >the occasional bug fix are boring, i.e. not the problem. > In the ARM tree I only know mach-at91. > Atmel still introduces new SOCs based on ARM926EJ-S, and that makes > perfect sense for lots of applications. > And if they add support for a new SOC, they just copy an existing one, > change some GPIOs, and submit it as new files (sorry, I'm over- > simplifying here). at SoC level quite a lot as we do the necessarly to factorise as much as we can you can take a look when we add the g20, g10 of g45, etc... > And if you happen to wire your board a bit differently than they do, > you have to patch theur generic file (in addidtion to add your own > board file). > And though I only know the mach-at91 closely, I'm pretty sure quite > a number of other mach-* are not better. > So this is actually why the ARM tree has such a bad reputation: > lot's of code repetition, and still more of that. On AT91 it's not anymore the case now we do start reduce the number of machine and we not allow this anymore > > >>>12. Supporting many different boards with a single kernel binary is a > >>> useful goal. > >>Generally not for embedded systems (for me, a mobile PDA/phone is just a > >>small computer with a crappy keyboard, but not an embedded system). > > > >True. For embedded, this would not be an important thing to do, but > >also not hurt. > It costs you flash space. I disagree have a single kernel with mutliple board is very usefull as it can allow you to have one firmware for multiple version of product. It will really simplify the maintanance And it's also allow to simplify kernel maintanance > > >>>* Strictly no crap > >>> * No board files > >>Where do you put code that needs to run very early (e.g. pinging the > >>watchdog)? > > > >Don't know. I'd hope we can get fast enough to the phase where device > >drivers get initialized. > Nope, never happened for me :-( > (Watchdog timeouts are often 1s or less.) you can do a lot in 1s you start the board dowload the code from nfs and jump in the kernel as I do on at91sam9261ek with barebox > > >>>* All board specific information must come from a device tree and > >>> be run-time detected. > >>What do you mean by "run-time detected"? > >>For powerpc, we currently have the device tree as DTS in the kernel > >>and compile and bundle it together with the kernel. > >>As you wrote above: "Discoverable hardware [...] is not going to happen" > > > >I mean writing > > > > if (device_is_compatible(dev, SOMETHING)) > > do_something(); > > > >instead of > > > >#ifdef CONFIG_SOMETHING > > do_something(); > >#endif > > > >The run-time information could come from anywhere (device tree, hardware > >registers, today one might use the board number), the important point is > >not to assume that hardware is present just because someone enabled > >a Kconfig option. > Understood and I agree. > > >I believe that rule is generally accepted today, but we don't always > >enforce it. > Without device tree, Kconfig option is the only way that really > works today (no runtime HW detection, and same board ID with different > setups). you can do it already today with system_rev DTS will allow to make it more generic and pass more information and on at91 we could easly have only few boards. Except for few case such as really short boottime requirement this will not impact the system on contrary Best Regards, J. > Device tree in my world is just one big Kconfig option instead of > many small... > > Detlef > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@xxxxxxxxxxxxxxxxxxx > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
