[RFC PATCH] ARM: add fixmap based earlycon support

[Ard Biesheuvel]

On 2 June 2015 at 01:31, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> On Mon, Jun 01, 2015 at 06:26:14PM -0500, Rob Herring wrote:
>> On Mon, Jun 1, 2015 at 3:26 AM, Ard Biesheuvel
>> <ard.biesheuvel at linaro.org> wrote:
>> > (thread is here: http://thread.gmane.org/gmane.linux.ports.arm.kernel/409329)
>> >
>> > On 2 May 2015 at 10:37, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
>> >> On 1 May 2015 at 18:18, Russell King - ARM Linux <linux at arm.linux.org.uk> wrote:
>> >>> On Wed, Apr 29, 2015 at 03:51:48PM +0200, Ard Biesheuvel wrote:
>> >>>> This adds support for fixmap based earlycon by moving the fixmap
>> >>>> initialization to an earlier stage and introducing the Kconfig symbol
>> >>>> that wires up the existing code.
>> >>>
>> >>> I don't see the patches for this fixmap based earlycon.  What's the
>> >>> status of those, and how are they getting into mainline?
>> >>>
>> >>
>> >> They are already /in/ mainline. This single patch is all that is
>> >> required to wire it up for ARM.
>> >>
>> >> However, I did notice after sending this that another implementation
>> >> had been proposed already:
>> >> http://lkml.iu.edu/hypermail/linux/kernel/1412.3/00855.html
>> >>
>> >> I am not sure which one is more correct, but the general idea is the
>> >> same, i.e., to allocate the fixmap PTEs from bss rather than the heap.
>> >
>> > Anyone else care to comment on this?
>>
>> You need to re-write the page table entries because the pte and pmd
>> flags get adjusted during boot. For example SMP related flags get
>> configured. I believe Stefan's version (based on mine which was based
>> on Mark Salter's) did this. In fact, I'm surprised this works after
>> paging_init, but I may have missed something.
>
> Any changes to PMD flags for things like SMP related flags must be
> done via a remove-the-mapping, flush-tlb, add-new-mapping sequence.
>

OK, thanks for pointing that out. At the time I sent it, I was aware
there were probably some architectural details I hadn't taken into
account, and I hadn't seen Stefan's patch.

So Stefan, could you please send that v2 so that we can get the ball
rolling on this again?

Thanks,
Ard.


>> > DT based earlycon is a *really* useful thing to have if you are
>> > working on early kernel code.
>> > With many of the DTs now having been extended with a
>> > /chosen/stdout-path property, it really only takes a simple 'earlycon'
>> > command line parameter (without any arguments) to get console output
>> > as soon as the early DT scan is concluded. I suppose this is also a
>> > useful thing for multi platform kernels?
>>
>> Certainly, that's the whole point. IMO, we should rip out most of
>> DEBUG_LL when this is merged.
>
> If you think that, you're wrong.  DEBUG_LL exists to be able to debug
> stuff well before the kernel gets anywhere near the C code.  It has
> to stay.  It fills the gap where no C code can do any debugging.
>
> --
> FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
> according to speedtest.net.