Thread (59 messages) 59 messages, 11 authors, 2019-08-28

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help