From: Julien Grall <julien.grall@linaro.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel@lists.xenproject.org, stefano.stabellini@eu.citrix.com,
tim@xen.org, patches@linaro.org
Subject: Re: [RFC 6/6] xen/arm: Replace early_printk call to printk call
Date: Thu, 20 Feb 2014 11:37:29 +0000 [thread overview]
Message-ID: <5305E8F9.1020704@linaro.org> (raw)
In-Reply-To: <1392895205.23342.28.camel@kazak.uk.xensource.com>
On 20/02/14 11:20, Ian Campbell wrote:
> On Thu, 2014-02-20 at 11:14 +0000, Julien Grall wrote:
>>
>> On 20/02/14 11:05, Ian Campbell wrote:
>>> On Thu, 2014-02-20 at 11:01 +0000, Julien Grall wrote:
>>>>
>>>> On 20/02/14 09:04, Ian Campbell wrote:
>>>>> I was actually thinking more along the lines of a .word at a defined
>>>>> offset which you could hex edit to a specific value to activate a
>>>>> particular flavour of early printk handling. That would be sufficient
>>>>> e.g. for osstest to activate the appropriate stuff for the specific
>>>>> platform.
>>>>
>>>> I don't see useful use case to have a such early printk implementation
>>>> in Xen. When the board is fully supported, failed at early stage (e.g
>>>> before console is initialized) is very unlikely. At least if you don't
>>>> play with memory.
>>>
>>> a) there are boards which aren't fully supported, getting some debug out
>>> of a distro package might be useful
>>
>> Few months ago we have decided to allow early printk only when Xen is
>> compiled with debug enabled. It seems a big mistake to ship distro with
>> debug enabled :).
>
> This was because earlyprintk only supports a static single configuration
> at compile time. If that restriction was lifted then there would be no
> reason to limit earlyprintk to debug builds.
>
>>> b) even for boards which are fully supported there may still be bugs
>>> which only appear under particular circumstances.
>>
>> I understand this use case. If I understand your previous mail the
>> solution would me "Hex editing manually the Xen binary to set the early
>> printk", right? If so, you are assuming that the distro (or anything
>> else) is proving the zImage. Otherwise the developper has to:
>> - unpack from the uImage
>> - editing the zImage
>> - recreate the uImage
>
> No distro would ship the actual uImage, it's too machine specific.
>
> I would expect this to be used by running:
> xen-enable-early-printk /boot/xen midway
>
> where xen-enable-early-printk is a simple tool we provide.
And a similar one to disable, I guess.
>
> Then if a uIamge is then required then this would be generated by
> whatever distro tooling would have generated it in the non-early-printk
> case, by rerunning that tool.
Sounds good. Do you plan to work on it?
It would be nice to have this item on the ARM todo page.
--
Julien Grall
next prev parent reply other threads:[~2014-02-20 11:37 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-05 21:26 [RFC 0/6] xen/arm: Merge early_printk function in console code Julien Grall
2014-01-05 21:26 ` [RFC 1/6] xen/arm: earlyprintk: move early_flush in early_puts Julien Grall
2014-02-19 11:13 ` Ian Campbell
2014-01-05 21:26 ` [RFC 2/6] xen/arm: earlyprintk: export early_puts Julien Grall
2014-02-19 11:14 ` Ian Campbell
2014-01-05 21:26 ` [RFC 3/6] xen/arm: Rename EARLY_PRINTK compile option to CONFIG_EARLY_PRINTK Julien Grall
2014-02-19 11:16 ` Ian Campbell
2014-01-05 21:26 ` [RFC 4/6] xen/console: Add support for early printk Julien Grall
2014-02-19 11:19 ` Ian Campbell
2014-02-20 16:38 ` Julien Grall
2014-01-05 21:26 ` [RFC 5/6] xen/console: Add noreturn attribute to panic function Julien Grall
2014-01-05 22:44 ` Andrew Cooper
2014-01-06 11:39 ` Julien Grall
2014-01-06 11:42 ` Andrew Cooper
2014-01-06 11:46 ` Julien Grall
2014-01-05 21:26 ` [RFC 6/6] xen/arm: Replace early_printk call to printk call Julien Grall
2014-02-19 11:20 ` Ian Campbell
2014-02-19 17:56 ` Julien Grall
2014-02-20 9:04 ` Ian Campbell
2014-02-20 11:01 ` Julien Grall
2014-02-20 11:05 ` Ian Campbell
2014-02-20 11:14 ` Julien Grall
2014-02-20 11:20 ` Ian Campbell
2014-02-20 11:37 ` Julien Grall [this message]
2014-02-20 13:02 ` Ian Campbell
2014-02-19 12:33 ` Ian Campbell
2014-03-05 7:53 ` Julien Grall
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5305E8F9.1020704@linaro.org \
--to=julien.grall@linaro.org \
--cc=Ian.Campbell@citrix.com \
--cc=patches@linaro.org \
--cc=stefano.stabellini@eu.citrix.com \
--cc=tim@xen.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).