Winter is coming [LWN.net]

Winter is coming

Posted May 11, 2012 13:53 UTC (Fri) by Aissen (subscriber, #59976)
Parent article: Supporting multi-platform ARM kernels

And by Winter, I mean Windows 8 on ARM:
http://blogs.msdn.com/b/b8/archive/2012/02/09/building-windows-for-the-arm-processor-architecture.aspx (now named, confusingly for us, Windows RT)

It will be very interesting to compare the different approaches both OSes will use to support multiple SoCs families in one binary kernel. Microsoft is already planning to use ~~device trees~~ system tables, so it's a very similar solution to the one chosen by the Linux kernel community.

It's also interesting, that for once positions are reversed: Linux is the leading OS on ARM devices, and Windows is the challenger. The net result is that Microsoft has the opportunity to start from a clean plate and have a clean implementation. It also means that Microsoft might have the opportunity to be the first to ship products with multi-platform support.

Linux, on the other side has the burden to continue supporting the dozens of different SoC families, and thousands of different boards. That's why I believe that Arnd's proposal to only support multi-platform booting with machines that have DT support is very reasonnable. It's a new feature after all, so there's no possible regression.

It's great that after starting this years ago (DT is not exactly new), the ARM Linux community, Linaro and distributors are finally taking on this problem at full speed. But who will win the race to the multi-platform graal ?

(Log in to post comments)

Winter is coming

Posted May 16, 2012 22:30 UTC (Wed) by mwsealey (guest, #71282) [Link]

The interesting part will be when embedded systems start coming with UEFI and the whole device tree concept is given a companion for ARM in favor of those system tables. It would be rather stupid to take a hard, fast stand against system tables in favor of device trees when an industry standard firmware simply doesn't supply them (or force UEFI firmware implementations to implement device tree just to support Linux..)

After all, ARM (as in the company) are pushing UEFI not just as a way to boot Windows, but as a better, more unified and standardized bootloader which U-Boot and many other "alternatives" simply cannot do (since on every SoC there tend to be different ways of handling precisely the same thing in U-Boot unfortunately).

Personally I would rather we did away with the device tree concept as SoCs are painful to implement in a device tree - what usually happens is Linux drivers are written then a device tree spec is written for that device, which includes values which should never need to be put in a device tree. What is missing from the device tree is usually hardcoded into the driver, and usually that's stuff you may actually want to be 'dynamic' in a device tree. It worked great for m68k, SPARC and PowerPC but those implementations really WERE dynamic, and supplied by the bootloader (OpenPROM or later OpenFirmware) based on a real-time introspection of the hardware at hand, not preconfigured and unchanging except for a few notable hacky bits which some bootloaders can shove values into. Static device trees built at kernel build time rarely, if ever, match the exact board design, and the usual theme from China is you get a board, write a device tree and 3 weeks later a new board is out which needs a different device tree. Plugging in a single kernel with 10 device trees on flash or disk, to select in the bootloader depending on board revision, is quite a painful concept.

We have an opinion round here at work that the device tree should be written by the board designer - not the SoC vendor (although they should be involved) and certainly not the driver author. The board designer is the only one who knows what is connected and what information is truly, truly important. The board designers knows what he WILL change later. And worse, the current specification of pinmux details in the device tree is truly, truly moronic from an electronics design point of view. The vast majority of hardware designers would rip a hole in spacetime if you told them you are going to make them wait 15 seconds to configure I/O direction and pad configuration. This is stuff that should be configured at a very low level right as the chip is powered on, not at Linux kernel init time.. the restriction this puts on hardware designers to only use the "default" pin configurations until some late time in boot for fear of driving an output pin on the SoC to an output pin on a peripheral chip where this is not electrically sound, is not a fun thing to have to work out. The device tree SHOULD report the CURRENT configuration of the harware, not dictate what the configuration SHOULD be in order for everything to work.. in supplying configuration data for changing the operation of the chip, the flattened device tree concept has essentially proven that it is completely flouting the very concept that made device trees (as a specification of running hardware and API) such a great idea in the first place.