[lkml]   [2010]   [Dec]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [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*.


     \ /
      Last update: 2010-12-31 01:53    [W:0.021 / U:33.844 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site