On 13 January 2017 at 14:19, Mark Rutland mark.rutland@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@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.