lkml.org 
[lkml]   [2012]   [Jul]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [08/36] AArch64: Kernel booting and initialisation
    On Tue, Jul 24, 2012 at 07:53:16PM +0100, Arnd Bergmann wrote:
    > On Tuesday 24 July 2012, Catalin Marinas wrote:
    > > On Mon, Jul 23, 2012 at 09:52:22PM +0100, Christopher Covington wrote:
    > > > Catalin Marinas - July 8, 2012, 9:18 a.m.
    > > > > On Fri, Jul 06, 2012 at 10:32:54PM +0100, Stephen Warren wrote:
    > > > >
    > > > >> Also, on Tegra at least and perhaps OMAP too, there are a few parts
    > > > >> of earlyprintk serial port setup (i.e. port selection) which happen
    > > > >> as part of the decompressor rather than the main kernel image, so
    > > > >> we'd have to re-jig that too.
    > > > >
    > > > > Whatever we did on AArch32, if it was useful and we want to follow a
    > > > > similar model it needs porting given that the code cannot be shared. So
    > > > > there is nothing to re-jig but rather implement.
    > > > >
    > > > > As for earlyprintk, you can initialise it in the decompressed kernel
    > > > > anyway. But even though it's a useful debugging tool, it goes against
    > > > > the single Image aim (at least the current printascii/addruart
    > > > > implementation). I don't have a proper implementation yet.
    > > >
    > > > Would DCC [1] be a reasonably commonly available early printk mechanism
    > > > for the single image to provide?
    > >
    > > Yes, this can be implemented but I think it has its own restrictions,
    > > requiring a JTAG connection.
    >
    > Right, which means that it's not generic and we still need to make
    > a decision for a how we want to solve the underlying problem. The
    > options I see are:
    >
    > 1. Have no earlyprintk before loading the console drivers

    It may be a long time and wouldn't help with early bugs.

    > 2. Make the series from Domenico architecture independent code

    I haven't seen this yet.

    > 3. Reimplement a layer like that, differently

    Any of the two above would be fine.

    > 4. Make it a compile-time option and allow this only for
    > low level debugging purposes but disable it in distro kernels.

    That's what I currently have (though not included in this post) but I
    don't particularly the approach. There are advantages in being able to
    call printascii from assembly early on but if we don't have a standard
    UART than it goes against single Image file.

    My proposal is to allow DCC very early on for development kernels
    (possibly called from assembly) with a timeout if there is no JTAG
    connection. Immediately after setup_machine_fdt() switch to a UART early
    console if there is one. But we retrieve this information from the FDT.

    I would say the early_printk console should not bother with UART
    initialisation (done by the boot loader) but just the actual character
    sending. It should also be placed somewhere under drivers/ as it may
    be shared by other architectures (it's just specific to the UART chip).

    --
    Catalin


    \
     
     \ /
      Last update: 2012-07-25 11:21    [W:5.215 / U:0.792 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site