Messages in this thread | | | Date | Thu, 30 Dec 2010 16:51:05 -0800 | From | "H. Peter Anvin" <> | Subject | Re: [sodaville] [PATCH 02/11] x86: Add device tree support |
| |
On 12/30/2010 12:26 AM, Grant Likely wrote: > > Since Linux on x86 has pretty much always depended on a two stage boot > (firmware boots a bootloader like grub which in turn boots the > kernel), then what is the use case for pursuing an in-kernel dtb > linkage? simpleimage was used on powerpc for the use-case where there > is no 2nd stage bootloader, but instead only the kernel which is > booted from some firmware that is non-upgradeable (or at least too > risky to upgrade). Same with the cuImages. The wrapper is > effectively a 2nd stage bootloader to adapt from what older u-boot > provides and what the kernel needs. > > What is the boot sequence for the embedded x86 platforms? Is there > still a bootloader? If so, what prevents always depending on the > bootloader to pass in the device tree blob? If the bootloader is > software (not firmware) then it should be something we have control > over when shipping a distribution. > > BTW, don't take microblaze as the example to be emulated. Some of > the things it does for device tree support is not scalable, like > linking the .dtbs directly into the kernel. > > John Bonesio has also prototyped doing a similar zImage bootwrapper on > arm which allows a dtb to be concatenated to the kernel image and > updated before passing it to the kernel. As it stands, there are no > plans to use in-kernel .dtb linking on ARM. > > I know it's not very fair to bring up these issues again right before > the merge window opens. I got myself overcommitted and dropped the > ball over the last 1.5 months and I beg forgiveness. However, I do > want to make sure that the right decision is made and I'd be happier > if a consistent scheme is used for passing the .dtb on all > architectures. >
There are a number of different boot loader solutions in use on embedded platforms, as much as we would like to avoid it.
However, the ability to link in the dtb will provide a architecture-neutral option of last resort. I'm not saying it's a good option, but it's better than random ad hoc stuff, and if that means that it will only ever be used during in-lab platform bringup, *that is still a huge win*.
-hpa
| |