On 2 October 2014 15:27, jonsmirl@xxxxxxxxx <jonsmirl@xxxxxxxxx> wrote: > On Thu, Oct 2, 2014 at 9:14 AM, Hans de Goede <hdegoede@xxxxxxxxxx> wrote: >> Hi, >> >> On 10/02/2014 02:56 PM, jonsmirl@xxxxxxxxx wrote: >>> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede <hdegoede@xxxxxxxxxx> wrote: >>>> Hi, >>>> >>>> On 10/02/2014 02:22 PM, jonsmirl@xxxxxxxxx wrote: >>>>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@xxxxxxxxxx> wrote: >>>>> >>>>> You need both. >>>>> >>>>> 1) temporary early boot console -- this is nothing but an address in >>>>> RAM and the x/y layout. The character set from framebuffer is built >>>>> into the kernel. The parallel to this is early-printk and how it uses >>>>> the UARTs without interrupts. This console vaporizes late in the boot >>>>> process -- the same thing happens with the early printk UART driver. >>>>> EARLYPRINTK on the command line enables this. >>>>> >>>>> 2) a device specific driver -- this sits on initrd and it loaded as >>>>> soon as possible. The same thing happens with the real UART driver for >>>>> the console. CONSOLE= on the command line causes the transition. There >>>>> is an API in the kernel to do this transition, I believe it is called >>>>> set_console() but it's been a while. >>>> >>>> Eventually we need both, yes. But 1) should stay working until 2) loads, >>>> not until some phase of the bootup is completed, but simply until 2) loads. >>> >>> No, that is where you get into trouble. The device specific driver has >>> to go onto initrd where it can be loaded as early in the boot process >>> as possible. >> >> This is an argument in the "you cannot do that" / "your use case is not valid" >> category, IOW this is not a technical argument. You say I cannot do that I >> say I can, deadlock. > > It is certainly possible to extend an earlyframebuffer to be able to > run as a user space console. It is just going to turn into a > Frankenmonster driver with piles of device specific, special case code > in it. What is device specific about code that reads a list of clocks and just asks tells kernel it uses them all? That's been discussed to death in this thread already. > > I think that device specific code belongs in a device specific driver > and earlyframebuffer should handoff to it as soon as possible. Even it that case it needs to tell the kernel it needs the clocks so that they are not shut of until that handoff happens. > >> >> I've already explained that we not only can do that (we already have working >> code proving that), but also that this is something which we absolutely need: >> >>>> One example why this is necessary is e.g. to debug things where the problem >>>> is that the right module is not included in the initrd. > > A generic earlyframebuffer would show this error. > > Just use earlyprintk as a guideline, if earlyprintk shows the error > earlyframebuffer would also show it. > It does not. It hands off to an uart driver built into the kernel. The handoff is broken on sunxi and the earlyprintk continues to work indefinitely replicating all kernel messages twice on the serial console unless something happens to reconfigure the uart used for earlyprink later on. When that does happen the early console can fail very early, even way before the time you would load an initrd. It just happens to work most of the time because when you use earlyprintk most of the time you also use serial console with the same parameters on the same pins. Thanks Michal -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
