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 to
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 unacceptable to
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 you have the
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 nice to have a
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 and address the
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
On Thu, May 19, 2011 at 1:36 AM, Detlev Zundel d...@denx.de 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
On Fri, May 20, 2011 at 11:48 AM, Simon Glass s...@chromium.org wrote:
On Thu, May 19, 2011 at 1:36 AM, Detlev Zundel d...@denx.de 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
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
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 such a
On Tue, May 17, 2011 at 1:20 AM, Detlev Zundel d...@denx.de 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
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 the code
On Mon, May 16, 2011 at 3:56 PM, Wolfgang Denk w...@denx.de wrote:
Dear Graeme Russ,
In message banlktinsypvnpg06uolze65t-fcqdn_...@mail.gmail.com you wrote:
I've thought of a 'better' approach:
- Do no modify the parameters of show_boot_progress()
- Create a new struct:
struct
On Mon, May 16, 2011 at 3:55 PM, Wolfgang Denk w...@denx.de wrote:
Dear Graeme Russ,
In message BANLkTim7=-rza_l-dy0b-+adqv4ngol...@mail.gmail.com 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
On Mon, May 16, 2011 at 3:48 PM, Wolfgang Denk w...@denx.de wrote:
Dear Simon Glass,
In message BANLkTi=0ijj7dnlsjovo-3eqjmw+rso...@mail.gmail.com 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
Dear Graeme Russ,
In message banlktim55mvfj-fdekea3gsbvqnnaic...@mail.gmail.com 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,
Dear Graeme Russ,
In message BANLkTi=u4gj+ci8hpfv95m8nynyedhg...@mail.gmail.com 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 -
-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 boot time measurement
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
On Mon, 16 May 2011 13:40:20 +0200
Wolfgang Denk w...@denx.de wrote:
Dear Graeme Russ,
In message BANLkTi=u4gj+ci8hpfv95m8nynyedhg...@mail.gmail.com you wrote:
As we can trivially use regular expressions, the effort to implement a
timing parser can be ignored. And it is independet of
Dear Simon Glass,
In message BANLkTi=wdddekljobfroncqzxjn9ugn...@mail.gmail.com 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
On Mon, May 16, 2011 at 11:32 AM, Wolfgang Denk w...@denx.de 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
On Mon, May 16, 2011 at 9:40 PM, Wolfgang Denk w...@denx.de wrote:
Dear Graeme Russ,
In message BANLkTi=u4gj+ci8hpfv95m8nynyedhg...@mail.gmail.com 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
On Sun, May 15, 2011 at 3:03 AM, Graeme Russ graeme.r...@gmail.com 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
On Sun, May 15, 2011 at 4:53 AM, Wolfgang Denk w...@denx.de 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
On Mon, May 16, 2011 at 7:58 AM, Simon Glass s...@chromium.org wrote:
On Sun, May 15, 2011 at 4:53 AM, Wolfgang Denk w...@denx.de 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.
On Mon, May 16, 2011 at 7:34 AM, Simon Glass s...@chromium.org wrote:
On Sun, May 15, 2011 at 3:03 AM, Graeme Russ graeme.r...@gmail.com wrote:
Couple of thoughts:
- Macro the definition of show_boot_progress() so it accepts a (const
char *) argument if CONFIG_BOOTSTAGE is defined
-
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
Dear Simon Glass,
In message BANLkTi=0ijj7dnlsjovo-3eqjmw+rso...@mail.gmail.com 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
Dear Graeme Russ,
In message BANLkTim7=-rza_l-dy0b-+adqv4ngol...@mail.gmail.com 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
Dear Graeme Russ,
In message banlktinsypvnpg06uolze65t-fcqdn_...@mail.gmail.com 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
On 15/05/11 03:32, Simon Glass wrote:
On Sat, May 14, 2011 at 4:34 AM, Mike Frysinger vap...@gentoo.org 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
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 as we
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 your
On Sat, May 14, 2011 at 4:34 AM, Mike Frysinger vap...@gentoo.org 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
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
36 matches
Mail list logo
