[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#731345: flash-kernel: add support for DT based kernels on Sheeva Plug



On 12/05/2013 12:57 PM, Ian Campbell wrote:
> On Thu, 2013-12-05 at 12:46 +0100, Marc Kleine-Budde wrote:
>> On 12/05/2013 12:34 PM, Martin Michlmayr wrote:
>>> * Marc Kleine-Budde <mkl@blackshift.org> [2013-12-05 11:49]:
>>>> That's no option, as non DT Sheeva Plug support has been removed from
>>>> the kernel in ffbc50663b69462adc9d97b93b6b92c4fe74b94c:
>>>>
>>>> ffbc506 ARM: kirkwood: remove support for legacy booting of Sheevaplug
>>>
>>> Interesting.  I thought they promised not to remove non-DT support for
>>> existing devices.
>>
>> I personally don't mind, if it's removed once the DT works properly.
>>
>>> Anyway, Marc, so thanks for your patch.  I wonder if it makes sense to
>>> add a check to flash-kernel whether DT is required or not.  i.e. that
>>> flash-kernel would append the DT blob on 3.12+ kernels on SheevaPlug
>>> but not on previous kernels.
>>
>> Yes, sounds like the way to go. Otherwise you have to tie certain
>> flash-kernel versions to the non-DT and DT kernels. This will probably
>> not scale when more no-DT board are removed from the kernel.
>>
>> Where should this information go? What about adding another field to
>> all.db which limits an entry to certain kernel versions? Something like
>> this:
> 
> I think it would be sufficient to have a field marking the DTB as
> optional and have f-k only do the append if there is a dtb present in
> the DTS directory (/usr/lib/linux-X.Y/whatever) for the version it is
> handling. If the kernel needs a DTB but doesn't ship one, well ,that's a
> bug in the kernel (until we get to the point of burning DTBs into
> firmware, but lets not worry about that now!).

...or when the DT sources will be move into a separate repository.

> I take it from your original patches that the machine ID differs with DT
> vs non as well?

Yes, this is why the second patch adds another entry.

Marc

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: