[U-Boot] [RFC PATCH] arm: bootm: Boot kernel with U-Boot's FDT blob

[Ryan Harkin]

On 13 January 2017 at 14:19, Mark Rutland <mark.rutland at arm.com> wrote:
> On Thu, Jan 12, 2017 at 01:47:32PM +0000, Ryan Harkin wrote:
>> On 12 January 2017 at 12:25, Mark Rutland <mark.rutland at arm.com> wrote:
>> > On Tue, Jan 10, 2017 at 06:50:19PM +0000, Jon Medhurst (Tixy) wrote:
>> >> On Tue, 2017-01-10 at 18:34 +0000, Mark Rutland wrote:
>> >> > Looking at the git log for arch/arm64/boot/dts/arm, most updates are
>> >> > simply adding new descriptions, so a DTB from a year ago should work
>> >> > just fine with mainline (modulo the Juno PCI window issue, which was a
>> >> > DTB bug). Upgrading kernel shouldn't require a DTB upgrade to see
>> >> > equivalent functionality.
>
>> > The key point is that it is possible to provide a baseline DTB that is
>> > good enough for most users, and will work with future kernels.
>> >
>> > We're unlikely to get to a state where DTBs are perfect and complete
>> > from day one. We can have something that remains usable.
>>
>> I hope it stays that way. Most of my users are either on 3.18 or 4.4.
>> And they are incompatible with each other w.r.t. DTBs to the point
>> where one won't even post a banner message with the other's DTB.
>
> Interesting. Just to check, do you mean v3.19? There was no upstream
> Juno DT in v3.18.
>
> Unfortunately, I can't spot any DT changes between v3.19 and v4.4 that
> would obviously break compatibility such that serial wouldn't work.
>
> If you have those kernels && DTBs to hand, are you able to take a look
> if passing "earlycon=pl011,0x7ff80000"?
>
> I know that the ARM Software linux repo shipped a broken DT, along with
> some kernel modifications which bodge around that (specifically, they
> exposed a broken MMIO timer as functional). IIRC, Poking that would
> bring down the kernel, before the serial wa up.
>
> Is your v3.18 DT the old ARM Software repo's Juno DT?
>

I don't have any of the data points any more, but it wasn't due to the
ARMLT tree, which tends to be stable/reliable. It was mostly debian vs
upstream.


> Thanks,
> Mark.