Dear Mike Frysinger,
In message <201105241422.41948.vap...@gentoo.org> you wrote:
>
> > What prevents you to continue this project as you like if I should
> > decide something that appears to be unacceptable to the community?
>
> yours will be "Das U-Boot" while mine will be an uppity fork
If yo
On Tuesday, May 24, 2011 03:18:00 Wolfgang Denk wrote:
> Mike Frysinger wrote:
> > Ultimately, Wolfgang gets final word regardless of anything else.
>
> Do I? That's news for me.
>
> What prevents you to continue this project as you like if I should
> decide something that appears to be unaccept
Dear Mike Frysinger,
In message <201105232255.58602.vap...@gentoo.org> you wrote:
>
> Ultimately, Wolfgang gets final word regardless of anything else.
Do I? That's news for me.
What prevents you to continue this project as you like if I should
decide something that appears to be unacceptable t
On Monday, May 23, 2011 11:22:18 Detlev Zundel wrote:
> >>> I believe I have covered this ground very thoroughly and would like
> >>
> >>> advice please on what to do next. The options I can see are:
> >> As Graeme points out, you got enough positive feedback that I encourage
> >> you to continue
Hi Simon,
[...]
>>> I believe I have covered this ground very thoroughly and would like
>>> advice please on what to do next. The options I can see are:
>>
>> As Graeme points out, you got enough positive feedback that I encourage
>> you to continue and address the comments.
>
> OK, it would be n
>
> Anyway, my point is, if the timer API wasa fixed, all the boot logging API
> needs to do is call get_timer() and your done - instant millisecond
make that microsecond ;)
> timestamp - No fallbacks - Each arch just needs to implement get_timer()
> correctly
>
__
On Fri, May 20, 2011 at 11:48 AM, Simon Glass wrote:
> On Thu, May 19, 2011 at 1:36 AM, Detlev Zundel wrote:
>> Hi Simon,
>>
>> [...]
>>
>>> I believe I have covered this ground very thoroughly and would like
>>> advice please on what to do next. The options I can see are:
>>
>> As Graeme points
On Thu, May 19, 2011 at 1:36 AM, Detlev Zundel wrote:
> Hi Simon,
>
> [...]
>
>> I believe I have covered this ground very thoroughly and would like
>> advice please on what to do next. The options I can see are:
>
> As Graeme points out, you got enough positive feedback that I encourage
> you to
Hi Simon,
[...]
> I believe I have covered this ground very thoroughly and would like
> advice please on what to do next. The options I can see are:
As Graeme points out, you got enough positive feedback that I encourage
you to continue and address the comments.
> - change the code to use a fal
Hi Simon,
>
> Hi Detlev and Wolfgang,
>
> Thanks for your comments. I understand a little bit of healthy inertia
> and do appreciate the constraints.
>
> I believe I have covered this ground very thoroughly and would like
> advice please on what to do next. The options I can see are:
>
> - change
On Tue, May 17, 2011 at 1:20 AM, Detlev Zundel wrote:
> Hi Simon and Wolfgang,
>
> [...]
>
>> In terms of all this discussion I can see your point :-) I did have
>> expressions of interest from two people including one I thought was at your
>> company, which I why I went to the effort to clean up
Hi Simon and Wolfgang,
[...]
> In terms of all this discussion I can see your point :-) I did have
> expressions of interest from two people including one I thought was at your
> company, which I why I went to the effort to clean up and submit this. At
> that time I didn't realise it would be suc
On Mon, May 16, 2011 at 9:40 PM, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message you wrote:
>>
>> > As we can trivially use regular expressions, the effort to implement a
>> > "timing parser" can be ignored. And it is independet of what sort of
>> > boot device we are using.
>>
>> Fine if
On Mon, May 16, 2011 at 11:32 AM, Wolfgang Denk wrote:
> Dear Simon Glass,
>...
>> Yes we do, and in fact they do improve boot performance slightly when the
>> console is muted.
>
> Do you have an explanation how that works? When there is no output on
> the console, the use of a FIFO in tx direct
Dear Simon Glass,
In message you wrote:
>
> Such a lot of text about such a small patch. It is clear to me that you are
> used to doing things one way, and this is a different approach. As I said
You can tell many things about me, but this one certainly is not the
case.
> > I don't see that we
On Mon, 16 May 2011 13:40:20 +0200
Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message you wrote:
> >
> > > As we can trivially use regular expressions, the effort to implement a
> > > "timing parser" can be ignored. And it is independet of what sort of
> > > boot device we are using.
> >
Hi Wolfgang,
Such a lot of text about such a small patch. It is clear to me that you are
used to doing things one way, and this is a different approach. As I said
there is more than one way to skin this cat and I think there are advantages
to having internal self-contained timing. I will try to ad
> -Original Message-
> From: u-boot-boun...@lists.denx.de
> [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Graeme Russ
> Sent: Monday, May 16, 2011 11:54 AM
> To: Wolfgang Denk
> Cc: U-Boot Mailing List; Simon Schwarz
> Subject: Re: [U-Boot] [PATCH 0/4] Accurate
Dear Graeme Russ,
In message you wrote:
>
> > As we can trivially use regular expressions, the effort to implement a
> > "timing parser" can be ignored. And it is independet of what sort of
> > boot device we are using.
>
> Fine if your running Linux - What if the only tool tyou have is
> Hypert
Dear Graeme Russ,
In message you wrote:
>
> > time-stamping console output is not restricted to the serial port. It
> > works as well with tty over USB, or netconsole, or even netconsole
> > over USB.
>
> My point is, if the device reboots in the field, you cannot recover the
> boot timing analy
On Mon, May 16, 2011 at 3:48 PM, Wolfgang Denk wrote:
> Dear Simon Glass,
>
> In message you wrote:
>>
>> This is 100us which is pretty good although you are assuming that there is
>> no FIFO holding things. Also on modern ARM CPUs the 'processing' part of
>
> I don't see that we use any FIFOs in
On Mon, May 16, 2011 at 3:55 PM, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message you wrote:
>>
>> But at 9600 baud it is over 1ms - 9600 is still considered the lowest
>> common denominator for serial comms for diagnostic output for a lot of
>> devices such as industrial PLCs etc.
>
> I t
On Mon, May 16, 2011 at 3:56 PM, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message you wrote:
>>
>> I've thought of a 'better' approach:
>> - Do no modify the parameters of show_boot_progress()
>> - Create a new struct:
>> struct boot_progress_msg {
>> int boot_progress_id;
>>
Dear Graeme Russ,
In message you wrote:
>
> I've thought of a 'better' approach:
> - Do no modify the parameters of show_boot_progress()
> - Create a new struct:
> struct boot_progress_msg {
> int boot_progress_id;
> const char *message;
> {
Where do you store this data _
Dear Graeme Russ,
In message you wrote:
>
> But at 9600 baud it is over 1ms - 9600 is still considered the lowest
> common denominator for serial comms for diagnostic output for a lot of
> devices such as industrial PLCs etc.
I think in the last 5 years I have seen but 2 devices using 9600 bps.
Dear Simon Glass,
In message you wrote:
>
> This is 100us which is pretty good although you are assuming that there is
> no FIFO holding things. Also on modern ARM CPUs the 'processing' part of
I don't see that we use any FIFOs in the output direction.
> U-Boot (where it is not just waiting on
serial debug statements might work as a "poor mans" timing implementation, but
i think it makes sense to have a binary framework for this.
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.de
On Mon, May 16, 2011 at 7:34 AM, Simon Glass wrote:
> On Sun, May 15, 2011 at 3:03 AM, Graeme Russ wrote:
>>
>> Couple of thoughts:
>> - Macro the definition of show_boot_progress() so it accepts a (const
>> char *) argument if CONFIG_BOOTSTAGE is defined
>> - Change BOOTSTAGE_COUNT to CONFI
On Mon, May 16, 2011 at 7:58 AM, Simon Glass wrote:
> On Sun, May 15, 2011 at 4:53 AM, Wolfgang Denk wrote:
>
>> Dear Simon Glass,
>>
>> In message <1305319923-9477-1-git-send-email-...@chromium.org> you wrote:
>> > This defines the basics of a new boot time measurement feature. This
>> allows
>>
On Sun, May 15, 2011 at 4:53 AM, Wolfgang Denk wrote:
> Dear Simon Glass,
>
> In message <1305319923-9477-1-git-send-email-...@chromium.org> you wrote:
> > This defines the basics of a new boot time measurement feature. This
> allows
> > logging of very accurate time measurements as the boot proc
On Sun, May 15, 2011 at 3:03 AM, Graeme Russ wrote:
> Couple of thoughts:
> - Macro the definition of show_boot_progress() so it accepts a (const
>char *) argument if CONFIG_BOOTSTAGE is defined
> - Change BOOTSTAGE_COUNT to CONFIG_MAX_BOOTSTAGE_RECORDS
> - Any call to show_boot_progress()
Dear Simon Glass,
In message <1305319923-9477-1-git-send-email-...@chromium.org> you wrote:
> This defines the basics of a new boot time measurement feature. This allows
> logging of very accurate time measurements as the boot proceeds, by using
> an available microsecond counter.
Well, as long a
On 15/05/11 03:32, Simon Glass wrote:
> On Sat, May 14, 2011 at 4:34 AM, Mike Frysinger wrote:
>
>> On Friday, May 13, 2011 16:51:59 Simon Glass wrote:
>>> This defines the basics of a new boot time measurement feature. This
>> allows
>>> logging of very accurate time measurements as the boot pro
On Sat, May 14, 2011 at 4:34 AM, Mike Frysinger wrote:
> On Friday, May 13, 2011 16:51:59 Simon Glass wrote:
> > This defines the basics of a new boot time measurement feature. This
> allows
> > logging of very accurate time measurements as the boot proceeds, by using
> > an available microsecond
On Friday, May 13, 2011 16:51:59 Simon Glass wrote:
> This defines the basics of a new boot time measurement feature. This allows
> logging of very accurate time measurements as the boot proceeds, by using
> an available microsecond counter.
>
> To enable the feature, define CONFIG_BOOTSTAGE in yo
This defines the basics of a new boot time measurement feature. This allows
logging of very accurate time measurements as the boot proceeds, by using
an available microsecond counter.
To enable the feature, define CONFIG_BOOTSTAGE in your board config file.
Also available is CONFIG_BOOTSTAGE_REPOR
36 matches
Mail list logo
