Hi,
Am 30.09.2014 um 11:29 schrieb Tomi Valkeinen:
On 30/09/14 11:03, Dr. H. Nikolaus Schaller wrote:
The same kernel/bootargs should work on a BeagleBoard.
No, they shouldn't. Bootargs are device specific.
Yes, they are - but having them device specific only makes trouble... The problem is if the boot loader is in flash memory updating the kernel (on a SD card) to do something special means reflashing.
Our concept is to try to keep the boot-loader stable and have no assumptions about the kernel. So that we can even swap SD cards between different devices.
But the same kernel binary should work on both devices, of course.
The best long-term solution is IMHO to get rid of all bootargs and rely on the device-specific DT which is more or less equivalent of a big bootarg string.
Well, where does the DT blob come from? It must be device specific. You can either get the bootargs from the same place where the DT blob is, or you can use "bootargs" property in the DT blob itself to define device specific bootargs.
Yes, that is how it could work. But why have it duplicated at all? I.e. loading two device specific files into the kernel where one would suffice.
That is the reason why I think we should reduce the boot args to a minimum (that ideally is completely device independent).
But this is a fundamental question we all here on this list won't solve :)
Well, it could be possible that the boot loader fetches device-specific boot-args from SD card but that would duplicate the mechanism that is already used for loading device specific device trees.
Anyways this seems to work.
Perhaps, but it may fail at any time. There's no reason for the kernel to allow bad bootargs.
The patch wasn't accepted by Tony, as he wants a DT based solution, and I have not been able to come up with a way to implement such a solution. And as there's been no DSI based boards in the mainline, it has been on low priority.
It works!!! Many thanks!
If the Pyra is finished we will have a DSI based board in the mainline.
So we will help to get it there :)
Ok. I actually have a work-in-progress branch that uses syscon to do the DSI muxing, which is probably acceptable for Tony. But it's still quite ugly, and I haven't had time to finalize it.
No need to hurry... We still have too much work for getting the hardware done in time. Anyways, I am already quite happy how close to mainline we already are (not only for display but all drivers). That has improved tremendously since DT has become standard for ARM.
BR, Nikolaus