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 [off-list ref] wrote:

quoted

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:

quoted

$ 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.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel