On 14.06.2018 21:21, David R. Piegdon wrote: > > Two question for anybody using the serial console on Tegra2 based systems: > > Do you have a early-boot console on it? > > Do you use the 8250 driver or the hsuart driver? > I'm not using UART for the console on a real HW, but early console works fine in the emulator. Hence the software part should be okay, unless it is something very specific to Tegra which isn't properly emulated. > If the hsuart driver: how did you configure it so that early boot > really gets shown? This currently does now work for me and might be a > workaround here. > The DMA driver isn't available during of early boot, hence the hsuart driver can't be used for the early console. For early console you don't need a full-blown driver. In your case the early console could be activated by appending kernels cmdline with "earlycon=uart8250,mmio32,0x70006000". Kernel will switch to a proper serial driver once it is available, so you should be able to have earlycon + hsuart. > > > > And also a follow-up on what I found so far on the interrupt-controller > side: > > The UART1 block is connected to the secondary interrupt controller > (LIC). which is in turn connected to the CPUs GIC. I traced the whole > thing by now and here is a collection of what I found in the error case: > > * GIC gets interrupt > * gic_handle_irq() gets called and reads 0x44 as the triggering > interrupt. 0x44 = 68 = 32 + 32 + 4. where 32 = cpu-internal ints, 32 = > primary int. controller, 4 = UARTA interrupt of secondary interrupt > controller. so the UARTA interrupt is seen. > * the UARTA handler kicks in and reads the IIR of the UARTA block, which > is 0xC1, where the lower four bits = 0b0001 mean: no interrupt. I've taken a bit closer look at the UART doc and realized that I already completely forgot everything about it. So yes, IIR shows here that there is no interrupt. > * UARTA handler leaves and tegra_eoi gets called, which writes > 0x00000010 to the acknowledge-register of the secondary interrupt The LIC acknowledgement here should have no effect because it clears the "forced interrupt" bit which is only relevant if kernel performs an IRQ re-trigger. > register, thus trying to acknowledge the UARTA interrupt anyways. > * interrupt handler leaves > * interrupt handler gets called again immediately with the same outcome. > The interrupt-controller part looks okay to me. > I traced *all* register accesses to the UART. So I am sure that there is > no interrupt shown in the IIR. > This means that either the secondary interrupt controller gets stuck > somehow, or that the UARTA is triggering interrupts but not showing them > in the IIR. > > > > > There is one interesting thing about the events that lead up to the > situation. As i have been tracing all the register accesses, it seems > that it (pretty much) always looks like this: > > * interrupts are all ok, everything is working fine. > > * when the TX queue is empty: > * UARTA.IER := 0x15. I.e. We enable interrupts RHR (received data), RXS > (receiver line status) and RX_TIMEOUT. > > * at some point a character needs to be written, so we enable the > interrupt for an empty TX queue: > * UARTA.IER := 0x17. I.e. we add the "transmitter holding register > empty" interrupt > > * we almost immediately get an interrupt, as the queue has been empty > for a while: > * UARTA.IIR == 0xC2 > > * now we write the char (in interrupt context) > * UARTA.TX := some char > > * still inside the ISR, we see that the kernel-side tx queue is empty, > so we disable the interrupt again: > * UARTA.IER := 0x15. > > * interrupt gets triggered again immediately after that, but no > interrupt is set: > * UARTA.IIR == 0xC1 > > and again. > and again... > You could try to reset UARTA HW here, will be interesting to see whether that stops the IRQ. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
