Hi, On Wed, Aug 28, 2019 at 03:02:36PM +0200, Arnd Bergmann wrote: > On Tue, Aug 27, 2019 at 9:05 PM Aaro Koskinen <aaro.koskinen@xxxxxx> wrote: > > On Tue, Aug 27, 2019 at 06:33:01PM +0200, Arnd Bergmann wrote: > > > On Fri, Aug 16, 2019 at 10:34 AM Aaro Koskinen <aaro.koskinen@xxxxxx> wrote: > > > > However with earlyprintk it seems to hang as soon as kernel tries to print > > > > something. So something goes wrong with early DEBUG_LL mapping code when > > > > CONFIG_DEBUG_UART_VIRT=0xff000000 is used? > > > > > > I just redid the calculation and came out with the same address, so I > > > don't think I put the wrong one there. The address also does not > > > conflict with the PCI mapping, and the address is the same one that > > > is installed later, so that should also be fine. > > > > > > Are you sure you used the correct address in the .config file? If you > > > ran 'make oldconfig', the virtual address would not be changed here > > > as I just modify the default for a fresh 'make omap1_defconfig' > > > run or similar. > > > > Yes... You should be able to try this out also in QEMU to see the hang: > > Haven't tried yet, but I took a look at the dump: > > > $ qemu-system-arm -M sx1 -kernel sx1-zImage -nographic > > > > [ Hangs silently, press Ctrl-a c to enter monitor. ] > > > > QEMU 4.1.0 monitor - type 'help' for more information > > (qemu) info registers > > R00=c0379de1 R01=0000005b R02=00000000 R03=ff000000 > > R04=00000000 R05=00000031 R06=c038f119 R07=00000000 > > R08=00000000 R09=c038f50e R10=600001d3 R11=00000001 > > R12=00000010 R13=c0379de0 R14=c000e07c R15=c000dfcc > > PSR=000001d3 ---- A svc32 > > FPSCR: 00000000 > > > > from System.map: > > c000df7c T printascii > > c000dfe0 T printch > > Ok, that is clearly the "busyloop" macro in > arch/arm/include/debug/8250.S, checking if the data got sent. > > The 'r2' register contains zero, so UART_LSR_TEMT and > UART_LSR_THRE are not set, but presumably the mapping > was installed right since you did not get a page fault. > > I assume you checked that the uart output wasn't already broken > by one of the earlier patches, right? Correct, it's only with the mapping change patch it hangs. > Also, looking at arch/arm/mach-omap1/include/mach/uncompress.h > it seems that SX1 normally uses UART3, not UART1. > Is that different in qemu? In QEMU all uarts can be used, trying with UART3 as early console hangs as well. (It prints Uncompressing... done. but I guess that's done with the physical address.) A.
