NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

port-evbarm/52010: Regression: Gumstix Verdex is hanging in enabling cache + KASSERT ram_size

>Number:         52010
>Category:       port-evbarm
>Synopsis:       Regression: Gumstix Verdex is hanging in enabling cache + KASSERT ram_size
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    port-evbarm-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Feb 27 17:50:00 +0000 2017
>Originator:     Stephan Meisinger
>Release:        7.0 and higher
Gumstix Verdex (very likely every XSCALE Gumstix) is hanging after enabling cache code, because no cache clean address is set.

Additionally a KASSERT is triggered, which is afaik only for a __HAVE_MM_MD_DIRECT_MAPPED_PHYS setup.

Please see patch below. The regression was introduced with the switch to arm32_bootmem_init code
boot GUMSTIX Verdex with NetBSD 7 or higher
Index: sys/arch/evbarm/gumstix/gumstix_machdep.c
RCS file: /cvsroot/src/sys/arch/evbarm/gumstix/gumstix_machdep.c,v
retrieving revision 1.57
diff -u -r1.57 gumstix_machdep.c
--- sys/arch/evbarm/gumstix/gumstix_machdep.c	20 Oct 2016 09:53:08 -0000	1.57
+++ sys/arch/evbarm/gumstix/gumstix_machdep.c	27 Feb 2017 17:31:28 -0000
@@ -456,6 +456,9 @@
 initarm(void *arg)
+#if defined(CPU_XSCALE)
+	extern vaddr_t xscale_cache_clean_addr;
 	extern char KERNEL_BASE_phys[];
 	extern uint32_t *u_boot_args[];
 	extern uint32_t ram_size;
@@ -594,7 +597,11 @@
 	bootconfig.dram[0].address = SDRAM_START;
 	bootconfig.dram[0].pages = ram_size / PAGE_SIZE;
+#if defined(CPU_XSCALE)
+	xscale_cache_clean_addr = 0xff000000U;
 	arm32_bootmem_init(bootconfig.dram[0].address, ram_size,
 	    (uintptr_t) KERNEL_BASE_phys);

Home | Main Index | Thread Index | Old Index