Re: [PATCH 0/2] Early printk support for virtio console devices.

From: Grant Likely
Date: Thu May 09 2013 - 06:39:48 EST


On Wed, May 8, 2013 at 3:17 PM, Catalin Marinas <catalin.marinas@xxxxxxx> wrote:
> On Tue, May 07, 2013 at 04:58:23PM +0100, Peter Maydell wrote:
>> On 7 May 2013 16:52, Christopher Covington <cov@xxxxxxxxxxxxxx> wrote:
>> This mixes up "information that the user provides to the
>> kernel" (ie configuration) with "information that QEMU or
>> kvmtool should provide to the kernel" (ie hardware
>> description), and would require QEMU/kvmtool to parse
>> the user's commandline tool to figure out if they
>> needed to override it or edit it (or alternatively,
>> would require the user to know internal details of
>> QEMU/kvmtool's address map for the guest). I think it
>> would be nicer to keep them separate.
>
> I'm not sure it's worth it, the earlyprintk is meant for debugging the
> early kernel booting code, not for general use (you have the normal
> console for this). Someone doing platform port should know the address
> of the uart and pass the right information on the kernel command line to
> help debug early booting issues.
>
> But if someone comes up with some bindings, I won't reject the patch.

Nicolas and I have tossed back and forth the idea of having a trivial
binding in the DT which specifies a couple of physical addresses and a
mask; one write register, one status register, and the mask to say
which bit to care about in the status. Basically the bare minimum to
say "here is something that will output to an already set up serial
device" without any reference to what it actually is. Something like
that would theoretically work with any device that implements or
emulates a UART write register. The thinking is that if it is trivial
to parse then it becomes more useful as an early printk target and
usable by the zImage wrapper (arm32 bit of course). Neither of us ever
followed up on it though.

g.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/