On 8 August 2013 12:05, Andy Green wrote:
> I can see how to get it from the flat device tree by adding properties
> to chosen { } and riding on early_init_dt_scan_chosen() easily enough.
> From the results I have already I know on this platform that's ~500us
> after where we set it up at the mom
On 8 August 2013 18:50, Peter Maydell wrote:
> On 8 August 2013 11:23, Andy Green wrote:
>> On 8 August 2013 17:35, Peter Maydell wrote
>>> Can't you put the relevant information into the device tree
>>> so that it works on multiplatform kernels? That's the way
>>> the kernel's chosen to store i
On 8 August 2013 11:23, Andy Green wrote:
> On 8 August 2013 17:35, Peter Maydell wrote
>> Can't you put the relevant information into the device tree
>> so that it works on multiplatform kernels? That's the way
>> the kernel's chosen to store its "this is the config for
>> this platform" data, a
On 8 August 2013 17:35, Peter Maydell wrote:
> On 8 August 2013 03:44, Andy Green wrote:
>> These patches give accurate, monotonic timestamps from the very first log
>> entry allowing insight into where the time is going during the whole of
>> the boot process.
>>
>> It's a debug feature like DEB
On 8 August 2013 03:44, Andy Green wrote:
> These patches give accurate, monotonic timestamps from the very first log
> entry allowing insight into where the time is going during the whole of
> the boot process.
>
> It's a debug feature like DEBUG_LL, it does not cooperate with
> ARCH_MULTIPLATFOR
The following patches introduce a debug feature, accurate timestamps
on all kernel logs during boot.
At the moment until time is set up in the kernel, all logs are timestamped
[0.00] giving the impression these early boot activities have no duration.
That's far from the case.
These patches gi
