Re: [PATCH 14/22] ARM: omap1: use pci_ioremap_io() for omap_cf
From: Arnd Bergmann <arnd@arndb.de>
Date: 2019-08-28 13:02:56
Also in:
linux-omap, lkml
On Tue, Aug 27, 2019 at 9:05 PM Aaro Koskinen [off-list ref] wrote:
On Tue, Aug 27, 2019 at 06:33:01PM +0200, Arnd Bergmann wrote:quoted
On Fri, Aug 16, 2019 at 10:34 AM Aaro Koskinen [off-list ref] wrote:quoted
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?
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?
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel