[fedora-arm] F18 ARM Final plan from this morning's hackfest discussion

[Sean Omalley]

> From: Jon <jdisnard at gmail.com>
>To: arm at lists.fedoraproject.org 
>Sent: Monday, January 21, 2013 11:02 PM
>Subject: Re: [fedora-arm] F18 ARM Final plan from this morning's hackfest discussion
> 
>
>
>
>
>On Mon, Jan 21, 2013 at 5:56 PM, Peter Robinson <pbrobinson at gmail.com> wrote:
>
>On Mon, Jan 21, 2013 at 6:55 PM, Peter Robinson <pbrobinson at gmail.com> wrote:
>>> On Mon, Jan 21, 2013 at 6:51 PM, Brendan Conoboy <blc at redhat.com> wrote:
>>>> On 01/21/2013 03:38 PM, Peter Robinson wrote:
>>>>>
>>>>> On Sun, Jan 20, 2013 at 8:09 PM, Brendan Conoboy <blc at redhat.com> wrote:
>>>>>>
>>>>>> Slight correction: plan is to add a kernel sub package in 3.7 that
>>>>>> includes dtbs.  This won't go in the rc since the rc will be 3.6 based.
>>>>>
>>>>>
>>>>> Why a kernel sub package? Why don't we add the dtb files for the
>>>>> platforms that will work to the kernels that support it. We will
>>>>> support half a dozen omap devices (and maybe include a few others that
>>>>> might work) but there's no point shipping 100s of dtb files for
>>>>> devices that we don't even enable the SoC for.
>>>>
>>>>
>>>> I don't have a firm opinion on this except that we should make a sustainable
>>>> decision.  In my book all that really matters is that upgrading the kernel
>>>> from 3.6 to 3.7 allows the systems we support to continue booting (and 3.7
>>>> to 3.8, etc).  In my book that means the kernel provides the dtb (or
>>>> requires a subpackage that contains the dtb).  And the boot script knows to
>>>> load the dtb if it's available.  Wwe might as well do it the way we mean to
>>>> keep on doing it, so picking good paths for these dtbs makes sense.  There
>>>> will presumably be quite a few of these files with kernel unification.
>>>
>>> I think then it should be as part of the kernel. We can make a better
>>> decision and they are small so I don't see splitting it into another
>>> file makes sense. The directory should be default like the firmwares
>>> do but again we should be going with an upstream standard.
>>
>>Not sure why the list got removed but re-adding.
>>
>>Peter
>>
>>
>>
>
>
>
>
>ok so if the kernel were to install many .dtb files that work with the soc, then it makes sense to have them organized into their own folder.
>Maybe /boot/dtb/*.dtb ??
>
>
>What about grubby support?
>When the new kernel is installed we need the right thing to happen to the boot.cmd.
>I suppose grubby will need to be aware that it's operating on a specific board: panda versus beagle versus beagle bone, etc...
>Perhaps we should start considering what changes need to happen to grubby, and what load addr's need to be chosen for the .dtb files.
>
>
>I'm keen on the idea (at least initially) of having both a .dtb file loaded from u-boot, and in parallel have an appended kernel present in /boot.
>That way if for whatever reason the loading of the .dtb fails the end-user may simply mount the sdcard and swap the boot.scr for the one that specifies the appended kernel.
>I realize in a perfect world we would never use an appended kernel, but it's wise to plan for the worst, and hope for the best.
>In my testing some boards only work with appending, so perhaps we might want to consider a way to have some boards always boot one way or another.
>For our initial support it might be best to use the appended mode for the sake of simplifying things, and later we can convert over to loading .dtb files.


Why not just add the device tree to uboot? Then when the system gets to uboot, it already has a device tree, and you just have to map it to the os? Then you don't have to ship 1000 dtb files and probe the 32 different revs of the same named board. You leave it up to the user to get the right file. You merely just map the device tree in uboot to the OS. Or is that what you are saying? :)