From owner-freebsd-arm@FreeBSD.ORG Sun Dec 9 03:07:48 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3A787B53 for ; Sun, 9 Dec 2012 03:07:48 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from smtp5.clear.net.nz (smtp5.clear.net.nz [203.97.33.68]) by mx1.freebsd.org (Postfix) with ESMTP id 888C68FC0C for ; Sun, 9 Dec 2012 03:07:46 +0000 (UTC) Received: from mxin3-orange.clear.net.nz (lb2-srcnat.clear.net.nz [203.97.32.237]) by smtp5.clear.net.nz (CLEAR Net Mail) with ESMTP id <0MEQ00E92U0J4350@smtp5.clear.net.nz> for freebsd-arm@freebsd.org; Sun, 09 Dec 2012 16:07:39 +1300 (NZDT) Received: from 202-0-48-19.paradise.net.nz (HELO localhost) ([202.0.48.19]) by smtpin32.paradise.net.nz with ESMTP; Sun, 09 Dec 2012 16:07:35 +1300 Date: Sun, 09 Dec 2012 16:07:21 +1300 From: Andrew Turner Subject: ARM EABI patch To: freebsd-arm@freebsd.org Message-id: <20121209160721.571186d8@fubar.geek.nz> MIME-version: 1.0 X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; i386-portbld-freebsd8.1) Content-type: multipart/mixed; boundary="MP_/7MVrwQO4FwHdxm_6EcPilkm" X-Pirate: Arrrr X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2012 03:07:48 -0000 --MP_/7MVrwQO4FwHdxm_6EcPilkm Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, I have attached a patch for testing and review to add support for the ARM EABI. After applying this patch you will need to update both the kernel and userland as the interface between them is slightly different. Most things should still work however there are known issues with GDB, syslog and devd. Also there may be parts of the base userland that fail to build if they have been updated recently as the wchar_t type has changed from a signed int to an unsigned int. Before merging this into HEAD I would like to move the __aeabi_{d,f} functions from libc to compiler-rt. There is a WITH/WITHOUT_ARM_EABI flag to switch the ABI. The default in the patch is to enable the EABI but it is intended to be disabled when Andrew --MP_/7MVrwQO4FwHdxm_6EcPilkm Content-Type: text/x-patch Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=eabi.diff Index: libexec/rtld-elf/Makefile =================================================================== --- libexec/rtld-elf/Makefile (.../head) (revision 243940) +++ libexec/rtld-elf/Makefile (.../projects/arm_eabi) (revision 243946) @@ -42,6 +42,16 @@ LDFLAGS+= -shared -Wl,-Bsymbolic DPADD= ${LIBC_PIC} LDADD= -lc_pic +.if ${MACHINE_CPUARCH} == "arm" +# Some of the required math functions (div & mod) are implemented in libgcc +# on ARM. The library also needs to be placed first to be correctly linked. +# As some of the functions are used before we have shared libraries. +DPADD+= ${LIBGCC} +LDADD+= -lgcc +.endif + + + .if ${MK_SYMVER} == "yes" LIBCDIR= ${TOPSRCDIR}/lib/libc VERSION_DEF= ${LIBCDIR}/Versions.def Index: sys/arm/arm/db_trace.c =================================================================== --- sys/arm/arm/db_trace.c (.../head) (revision 243940) +++ sys/arm/arm/db_trace.c (.../projects/arm_eabi) (revision 243946) @@ -50,6 +50,396 @@ __FBSDID("$FreeBSD$"); #include #include +#ifdef __ARM_EABI__ +/* + * Definitions for the instruction interpreter. + * + * The ARM EABI specifies how to perform the frame unwinding in the + * Exception Handling ABI for the ARM Architecture document. To perform + * the unwind we need to know the initial frame pointer, stack pointer, + * link register and program counter. We then find the entry within the + * index table that points to the function the program counter is within. + * This gives us either a list of three instructions to process, a 31-bit + * relative offset to a table of instructions, or a value telling us + * we can't unwind any further. + * + * When we have the instructions to process we need to decode them + * following table 4 in section 9.3. This describes a collection of bit + * patterns to encode that steps to take to update the stack pointer and + * link register to the correct values at the start of the function. + */ + +/* A special case when we are unable to unwind past this function */ +#define EXIDX_CANTUNWIND 1 + +/* The register names */ +#define FP 11 +#define SP 13 +#define LR 14 +#define PC 15 + +/* + * These are set in the linker script. Their addresses will be + * either the start or end of the exception table or index. + */ +extern int extab_start, extab_end, exidx_start, exidx_end; + +/* + * Entry types. + * These are the only entry types that have been seen in the kernel. + */ +#define ENTRY_MASK 0xff000000 +#define ENTRY_ARM_SU16 0x80000000 +#define ENTRY_ARM_LU16 0x81000000 + +/* Instruction masks. */ +#define INSN_VSP_MASK 0xc0 +#define INSN_VSP_SIZE_MASK 0x3f +#define INSN_STD_MASK 0xf0 +#define INSN_STD_DATA_MASK 0x0f +#define INSN_POP_TYPE_MASK 0x08 +#define INSN_POP_COUNT_MASK 0x07 +#define INSN_VSP_LARGE_INC_MASK 0xff + +/* Instruction definitions */ +#define INSN_VSP_INC 0x00 +#define INSN_VSP_DEC 0x40 +#define INSN_POP_MASKED 0x80 +#define INSN_VSP_REG 0x90 +#define INSN_POP_COUNT 0xa0 +#define INSN_FINISH 0xb0 +#define INSN_VSP_LARGE_INC 0xb2 + +/* An item in the exception index table */ +struct unwind_idx { + uint32_t offset; + uint32_t insn; +}; + +/* The state of the unwind process */ +struct unwind_state { + uint32_t registers[16]; + uint32_t start_pc; + uint32_t *insn; + u_int entries; + u_int byte; + uint16_t update_mask; +}; + +/* We need to provide these but never use them */ +void __aeabi_unwind_cpp_pr0(void); +void __aeabi_unwind_cpp_pr1(void); +void __aeabi_unwind_cpp_pr2(void); + +void +__aeabi_unwind_cpp_pr0(void) +{ + panic("__aeabi_unwind_cpp_pr0"); +} + +void +__aeabi_unwind_cpp_pr1(void) +{ + panic("__aeabi_unwind_cpp_pr1"); +} + +void +__aeabi_unwind_cpp_pr2(void) +{ + panic("__aeabi_unwind_cpp_pr2"); +} + +/* Expand a 31-bit signed value to a 32-bit signed value */ +static __inline int32_t +db_expand_prel31(uint32_t prel31) +{ + + return ((int32_t)(prel31 & 0x7fffffffu) << 1) / 2; +} + +/* + * Perform a binary search of the index table to find the function + * with the largest address that doesn't exceed addr. + */ +static struct unwind_idx * +db_find_index(uint32_t addr) +{ + unsigned int min, mid, max; + struct unwind_idx *start; + struct unwind_idx *item; + int32_t prel31_addr; + uint32_t func_addr; + + start = (struct unwind_idx *)&exidx_start; + + min = 0; + max = (&exidx_end - &exidx_start) / 2; + + /* XXX: This is likely broken for small addresses */ + while (min != max) { + mid = min + (max - min + 1) / 2; + + item = &start[mid]; + + prel31_addr = db_expand_prel31(item->offset); + func_addr = (uint32_t)&item->offset + prel31_addr; + + if (func_addr <= addr) { + min = mid; + } else { + max = mid - 1; + } + } + + return &start[min]; +} + +/* Reads the next byte from the instruction list */ +static uint8_t +db_unwind_exec_read_byte(struct unwind_state *state) +{ + uint8_t insn; + + /* Read the unwind instruction */ + insn = (*state->insn) >> (state->byte * 8); + + /* Update the location of the next instruction */ + if (state->byte == 0) { + state->byte = 3; + state->insn++; + state->entries--; + } else + state->byte--; + + return insn; +} + +/* Executes the next instruction on the list */ +static int +db_unwind_exec_insn(struct unwind_state *state) +{ + unsigned int insn; + uint32_t *vsp = (uint32_t *)state->registers[SP]; + int update_vsp = 0; + + /* This should never happen */ + if (state->entries == 0) + return 1; + + /* Read the next instruction */ + insn = db_unwind_exec_read_byte(state); + + if ((insn & INSN_VSP_MASK) == INSN_VSP_INC) { + state->registers[SP] += ((insn & INSN_VSP_SIZE_MASK) << 2) + 4; + + } else if ((insn & INSN_VSP_MASK) == INSN_VSP_DEC) { + state->registers[SP] -= ((insn & INSN_VSP_SIZE_MASK) << 2) + 4; + + } else if ((insn & INSN_STD_MASK) == INSN_POP_MASKED) { + unsigned int mask, reg; + + /* Load the mask */ + mask = db_unwind_exec_read_byte(state); + mask |= (insn & INSN_STD_DATA_MASK) << 8; + + /* We have a refuse to unwind instruction */ + if (mask == 0) + return 1; + + /* Update SP */ + update_vsp = 1; + + /* Load the registers */ + for (reg = 4; mask && reg < 16; mask >>= 1, reg++) { + if (mask & 1) { + state->registers[reg] = *vsp++; + state->update_mask |= 1 << reg; + + /* If we have updated SP kep its value */ + if (reg == SP) + update_vsp = 0; + } + } + + } else if ((insn & INSN_STD_MASK) == INSN_VSP_REG && + ((insn & INSN_STD_DATA_MASK) != 13) && + ((insn & INSN_STD_DATA_MASK) != 15)) { + /* sp = register */ + state->registers[SP] = + state->registers[insn & INSN_STD_DATA_MASK]; + + } else if ((insn & INSN_STD_MASK) == INSN_POP_COUNT) { + unsigned int count, reg; + + /* Read how many registers to load */ + count = insn & INSN_POP_COUNT_MASK; + + /* Update sp */ + update_vsp = 1; + + /* Pop the registers */ + for (reg = 4; reg <= 4 + count; reg++) { + state->registers[reg] = *vsp++; + state->update_mask |= 1 << reg; + } + + /* Check if we are in the pop r14 version */ + if ((insn & INSN_POP_TYPE_MASK) != 0) { + state->registers[14] = *vsp++; + } + + } else if (insn == INSN_FINISH) { + /* Stop processing */ + state->entries = 0; + + } else if ((insn & INSN_VSP_LARGE_INC_MASK) == INSN_VSP_LARGE_INC) { + unsigned int uleb128; + + /* Read the increment value */ + uleb128 = db_unwind_exec_read_byte(state); + + state->registers[SP] += 0x204 + (uleb128 << 2); + + } else { + /* We hit a new instruction that needs to be implemented */ + db_printf("Unhandled instruction %.2x\n", insn); + return 1; + } + + if (update_vsp) { + state->registers[SP] = (uint32_t)vsp; + } + +#if 0 + db_printf("fp = %08x, sp = %08x, lr = %08x, pc = %08x\n", + state->registers[FP], state->registers[SP], state->registers[LR], + state->registers[PC]); +#endif + + return 0; +} + +/* Performs the unwind of a function */ +static int +db_unwind_tab(struct unwind_state *state) +{ + uint32_t entry; + + /* Set PC to a known value */ + state->registers[PC] = 0; + + /* Read the personality */ + entry = *state->insn & ENTRY_MASK; + + if (entry == ENTRY_ARM_SU16) { + state->byte = 2; + state->entries = 1; + } else if (entry == ENTRY_ARM_LU16) { + state->byte = 1; + state->entries = ((*state->insn >> 16) & 0xFF) + 1; + } else { + db_printf("Unknown entry: %x\n", entry); + return 1; + } + + while (state->entries > 0) { + if (db_unwind_exec_insn(state) != 0) + return 1; + } + + /* + * The program counter was not updated, load it from the link register. + */ + if (state->registers[PC] == 0) + state->registers[PC] = state->registers[LR]; + + return 0; +} + +static void +db_stack_trace_cmd(struct unwind_state *state) +{ + struct unwind_idx *index; + const char *name; + db_expr_t value; + db_expr_t offset; + c_db_sym_t sym; + u_int reg, i; + char *sep; + + while (1) { + /* Reset the mask of updated registers */ + state->update_mask = 0; + + /* The pc value is correct and will be overwritten, save it */ + state->start_pc = state->registers[PC]; + + /* Find the item to run */ + index = db_find_index(state->start_pc); + + if (index->insn == EXIDX_CANTUNWIND) { + printf("Unable to unwind\n"); + break; + } else if (index->insn & (1 << 31)) { + /* The data is within the instruction */ + state->insn = &index->insn; + } else { + /* We have a prel31 offset to the unwind table */ + uint32_t prel31_tbl = db_expand_prel31(index->insn); + + state->insn = (uint32_t *)((uintptr_t)&index->insn + + prel31_tbl); + } + + /* Run the unwind function */ + if (db_unwind_tab(state) != 0) + break; + + /* This is not a kernel address, stop processing */ + if (state->registers[PC] < VM_MIN_KERNEL_ADDRESS) + break; + + /* Print the frame details */ + sym = db_search_symbol(state->start_pc, DB_STGY_ANY, &offset); + if (sym == C_DB_SYM_NULL) { + value = 0; + name = "(null)"; + } else + db_symbol_values(sym, &name, &value); + db_printf("%s() at ", name); + db_printsym(state->start_pc, DB_STGY_PROC); + db_printf("\n"); + db_printf("\t pc = 0x%08x lr = 0x%08x (", state->start_pc, + state->registers[LR]); + db_printsym(state->registers[LR], DB_STGY_PROC); + db_printf(")\n"); + db_printf("\t sp = 0x%08x fp = 0x%08x", + state->registers[SP], state->registers[FP]); + + /* Don't print the registers we have already printed */ + state->update_mask &= ~((1 << SP) | (1 << FP) | (1 << LR) | + (1 << PC)); + sep = "\n\t"; + for (i = 0, reg = 0; state->update_mask != 0; + state->update_mask >>= 1, reg++) { + if ((state->update_mask & 1) != 0) { + db_printf("%s%sr%d = 0x%08x", sep, + (reg < 10) ? " " : "", reg, + state->registers[reg]); + i++; + if (i == 2) { + sep = "\n\t"; + i = 0; + } else + sep = " "; + + } + } + db_printf("\n"); + } +} +#endif + /* * APCS stack frames are awkward beasts, so I don't think even trying to use * a structure to represent them is a good idea. @@ -78,6 +468,7 @@ __FBSDID("$FreeBSD$"); * fields are actually present. */ +#ifndef __ARM_EABI__ /* The frame format is differend in AAPCS */ static void db_stack_trace_cmd(db_expr_t addr, db_expr_t count, boolean_t kernel_only) { @@ -171,6 +562,7 @@ db_stack_trace_cmd(db_expr_t addr, db_ex } } } +#endif /* XXX stubs */ void @@ -193,11 +585,24 @@ db_md_set_watchpoint(db_expr_t addr, db_ int db_trace_thread(struct thread *thr, int count) { +#ifdef __ARM_EABI__ + struct unwind_state state; +#endif struct pcb *ctx; if (thr != curthread) { ctx = kdb_thr_ctx(thr); + +#ifdef __ARM_EABI__ + state.registers[FP] = ctx->un_32.pcb32_r11; + state.registers[SP] = ctx->un_32.pcb32_sp; + state.registers[LR] = ctx->un_32.pcb32_lr; + state.registers[PC] = ctx->un_32.pcb32_pc; + + db_stack_trace_cmd(&state); +#else db_stack_trace_cmd(ctx->un_32.pcb32_r11, -1, TRUE); +#endif } else db_trace_self(); return (0); @@ -206,8 +611,20 @@ db_trace_thread(struct thread *thr, int void db_trace_self(void) { +#ifdef __ARM_EABI__ + struct unwind_state state; + register uint32_t sp __asm__ ("sp"); + + state.registers[FP] = (uint32_t)__builtin_frame_address(0); + state.registers[SP] = (uint32_t)sp; + state.registers[LR] = (uint32_t)__builtin_return_address(0); + state.registers[PC] = (uint32_t)db_trace_self; + + db_stack_trace_cmd(&state); +#else db_addr_t addr; addr = (db_addr_t)__builtin_frame_address(0); db_stack_trace_cmd(addr, -1, FALSE); +#endif } Index: sys/arm/arm/vm_machdep.c =================================================================== --- sys/arm/arm/vm_machdep.c (.../head) (revision 243940) +++ sys/arm/arm/vm_machdep.c (.../projects/arm_eabi) (revision 243946) @@ -398,6 +398,8 @@ cpu_thread_alloc(struct thread *td) PAGE_SIZE) - 1; td->td_frame = (struct trapframe *) ((u_int)td->td_kstack + USPACE_SVC_STACK_TOP - sizeof(struct pcb)) - 1; + /* Ensure the frame is aligned to an 8 byte boundary */ + td->td_frame = (struct trapframe *)((u_int)td->td_frame & ~7); #ifdef __XSCALE__ #ifndef CPU_XSCALE_CORE3 pmap_use_minicache(td->td_kstack, td->td_kstack_pages * PAGE_SIZE); Index: sys/arm/arm/locore.S =================================================================== --- sys/arm/arm/locore.S (.../head) (revision 243940) +++ sys/arm/arm/locore.S (.../projects/arm_eabi) (revision 243946) @@ -484,12 +484,29 @@ ENTRY_NP(abort) ENTRY_NP(sigcode) mov r0, sp + + /* + * Call the sigreturn system call. + * + * We have to load r7 manually rather than using + * "ldr r7, =SYS_sigreturn" to ensure the value of szsigcode is + * correct. Using the alternative places esigcode at the address + * of the datra rather than the address one past the data. + */ + + ldr r7, [pc, #12] /* Load SYS_sigreturn */ swi SYS_sigreturn /* Well if that failed we better exit quick ! */ + ldr r7, [pc, #8] /* Load SYS_exit */ swi SYS_exit - b . - 8 + + /* Branch back to retry SYS_sigreturn */ + b . - 16 + + .word SYS_sigreturn + .word SYS_exit .align 0 .global _C_LABEL(esigcode) Index: sys/arm/arm/trap.c =================================================================== --- sys/arm/arm/trap.c (.../head) (revision 243940) +++ sys/arm/arm/trap.c (.../projects/arm_eabi) (revision 243946) @@ -866,7 +866,11 @@ cpu_fetch_syscall_args(struct thread *td register_t *ap; int error; +#ifdef __ARM_EABI__ + sa->code = td->td_frame->tf_r7; +#else sa->code = sa->insn & 0x000fffff; +#endif ap = &td->td_frame->tf_r0; if (sa->code == SYS_syscall) { sa->code = *ap++; @@ -906,15 +910,18 @@ syscall(struct thread *td, trapframe_t * int error; sa.insn = *(uint32_t *)(frame->tf_pc - INSN_SIZE); +#ifndef __ARM_EABI__ + /* TODO: Also add the above line when we don't need it in the EABI case */ switch (sa.insn & SWI_OS_MASK) { case 0: /* XXX: we need our own one. */ - sa.nap = 4; break; default: call_trapsignal(td, SIGILL, 0); userret(td, frame); return; } +#endif + sa.nap = 4; error = syscallenter(td, &sa); KASSERT(error != 0 || td->td_ar == NULL, Index: sys/arm/include/proc.h =================================================================== --- sys/arm/include/proc.h (.../head) (revision 243940) +++ sys/arm/include/proc.h (.../projects/arm_eabi) (revision 243946) @@ -60,7 +60,11 @@ struct mdproc { void *md_sigtramp; }; +#ifdef __ARM_EABI__ +#define KINFO_PROC_SIZE 816 +#else #define KINFO_PROC_SIZE 792 +#endif #define MAXARGS 8 struct syscall_args { Index: sys/conf/ldscript.arm =================================================================== --- sys/conf/ldscript.arm (.../head) (revision 243940) +++ sys/conf/ldscript.arm (.../projects/arm_eabi) (revision 243946) @@ -56,6 +56,18 @@ SECTIONS .init : { *(.init) } =0x9090 .plt : { *(.plt) } + _extab_start = .; + PROVIDE(extab_start = .); + .ARM.extab : { *(.ARM.extab) } + _extab.end = .; + PROVIDE(extab_end = .); + + _exidx_start = .; + PROVIDE(exidx_start = .); + .ARM.exidx : { *(.ARM.exidx) } + _exidx_end = .; + PROVIDE(exidx_end = .); + /* Adjust the address for the data segment. We want to adjust up to the same address within the page on the next page up. */ . = ALIGN(0x1000) + (. & (0x1000 - 1)) ; Index: sys/conf/Makefile.arm =================================================================== --- sys/conf/Makefile.arm (.../head) (revision 243940) +++ sys/conf/Makefile.arm (.../projects/arm_eabi) (revision 243946) @@ -41,6 +41,8 @@ STRIP_FLAGS = -S .if empty(DDB_ENABLED) CFLAGS += -mno-apcs-frame +.else +CFLAGS += -funwind-tables .endif SYSTEM_LD_ = ${LD} -Bdynamic -T ldscript.$M.noheader ${LDFLAGS} \ Index: sys/conf/files.arm =================================================================== --- sys/conf/files.arm (.../head) (revision 243940) +++ sys/conf/files.arm (.../projects/arm_eabi) (revision 243946) @@ -72,6 +75,8 @@ font.h optional sc \ kern/subr_dummy_vdso_tc.c standard libkern/arm/divsi3.S standard libkern/arm/ffs.S standard +libkern/arm/ldivmod.S standard +libkern/arm/ldivmod_helper.c standard libkern/arm/muldi3.c standard libkern/ashldi3.c standard libkern/ashrdi3.c standard Index: sys/boot/arm/uboot/Makefile =================================================================== --- sys/boot/arm/uboot/Makefile (.../head) (revision 243940) +++ sys/boot/arm/uboot/Makefile (.../projects/arm_eabi) (revision 243946) @@ -109,8 +109,8 @@ CFLAGS+= -I${.OBJDIR}/../../uboot/lib # where to get libstand from CFLAGS+= -I${.CURDIR}/../../../../lib/libstand/ -DPADD= ${LIBFICL} ${LIBUBOOT} ${LIBFDT} ${LIBSTAND} -LDADD= ${LIBFICL} ${LIBUBOOT} ${LIBFDT} -lstand +DPADD= ${LIBFICL} ${LIBUBOOT} ${LIBFDT} ${LIBSTAND} ${LIBGCC} +LDADD= ${LIBFICL} ${LIBUBOOT} ${LIBFDT} -lstand -lgcc vers.c: ${.CURDIR}/../../common/newvers.sh ${.CURDIR}/version sh ${.CURDIR}/../../common/newvers.sh ${.CURDIR}/version ${NEWVERSWHAT} Index: sys/libkern/arm/ldivmod_helper.c =================================================================== --- sys/libkern/arm/ldivmod_helper.c (.../head) (revision 0) +++ sys/libkern/arm/ldivmod_helper.c (.../projects/arm_eabi) (revision 243946) @@ -0,0 +1,50 @@ +/* + * Copyright (C) 2012 Andrew Turner + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + */ + +#include +__FBSDID("$FreeBSD$"); + +#include + +/* + * Helper for __aeabi_ldivmod. + * TODO: __divdi3 calls __qdivrem. We should do the same and use the + * remainder value rather than re-calculating it. + */ +long long __kern_ldivmod(long long, long long, long long *); + +long long +__kern_ldivmod(long long n, long long m, long long *rem) +{ + long long q; + + q = __divdi3(n, m); /* q = n / m */ + *rem = n - m * q; + + return q; +} + Index: sys/libkern/arm/ldivmod.S =================================================================== --- sys/libkern/arm/ldivmod.S (.../head) (revision 0) +++ sys/libkern/arm/ldivmod.S (.../projects/arm_eabi) (revision 243946) @@ -0,0 +1,63 @@ +/* + * Copyright (C) 2012 Andrew Turner + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + */ + +#include +__FBSDID("$FreeBSD$"); + +/* + * These calculate: + * q = n / m + * With a remainer r. + * + * They take n in {r0, r1} and m in {r2, r3} then pass them into the + * helper function. The hepler functions return q in {r0, r1} as + * required by the API spec however r is returned on the stack. The + * ABI required us to return r in {r2, r3}. + * + * We need to allocate 8 bytes on the stack to store r, the link + * register, and a pointer to the space where the helper function + * will write r to. After returning from the helper fuinction we load + * the old link register and r from the stack and return. + */ +ENTRY_NP(__aeabi_ldivmod) + sub sp, sp, #8 /* Space for the remainder */ + stmfd sp!, {sp, lr} /* Save a pointer to the above space and lr */ + bl PIC_SYM(_C_LABEL(__kern_ldivmod), PLT) + ldr lr, [sp, #4] /* Restore lr */ + add sp, sp, #8 /* Move sp to the remainder value */ + ldmfd sp!, {r2, r3} /* Load the remainder */ + RET + +ENTRY_NP(__aeabi_uldivmod) + sub sp, sp, #8 /* Space for the remainder */ + stmfd sp!, {sp, lr} /* Save a pointer to the above space and lr */ + bl PIC_SYM(_C_LABEL(__qdivrem), PLT) + ldr lr, [sp, #4] /* Restore lr */ + add sp, sp, #8 /* Move sp to the remainder value */ + ldmfd sp!, {r2, r3} /* Load the remainder */ + RET + Index: sys/libkern/arm/divsi3.S =================================================================== --- sys/libkern/arm/divsi3.S (.../head) (revision 243940) +++ sys/libkern/arm/divsi3.S (.../projects/arm_eabi) (revision 243946) @@ -49,6 +49,10 @@ ENTRY_NP(__modsi3) #endif RET +#ifdef __ARM_EABI__ +ENTRY_NP(__aeabi_uidiv) +ENTRY_NP(__aeabi_uidivmod) +#endif ENTRY_NP(__udivsi3) .L_udivide: /* r0 = r0 / r1; r1 = r0 % r1 */ eor r0, r1, r0 @@ -71,6 +75,10 @@ ENTRY_NP(__udivsi3) mov r1, #0 RET +#ifdef __ARM_EABI__ +ENTRY_NP(__aeabi_idiv) +ENTRY_NP(__aeabi_idivmod) +#endif ENTRY_NP(__divsi3) .L_divide: /* r0 = r0 / r1; r1 = r0 % r1 */ eor r0, r1, r0 Index: usr.bin/tr/tr.c =================================================================== --- usr.bin/tr/tr.c (.../head) (revision 243940) +++ usr.bin/tr/tr.c (.../projects/arm_eabi) (revision 243946) @@ -47,6 +47,7 @@ static const char sccsid[] = "@(#)tr.c 8 #include #include #include +#include #include #include #include @@ -267,7 +268,7 @@ endloop: */ s2.str = argv[1]; s2.state = NORMAL; - for (cnt = 0; cnt < WCHAR_MAX; cnt++) { + for (cnt = 0; cnt < WINT_MAX; cnt++) { if (Cflag && !iswrune(cnt)) continue; if (cmap_lookup(map, cnt) == OOBCH) { Index: usr.bin/ul/ul.c =================================================================== --- usr.bin/ul/ul.c (.../head) (revision 243940) +++ usr.bin/ul/ul.c (.../projects/arm_eabi) (revision 243946) @@ -280,7 +280,7 @@ filter(FILE *f) obuf[col].c_width = w; for (i = 1; i < w; i++) obuf[col + i].c_width = -1; - } else if (obuf[col].c_char == c) { + } else if ((wint_t)obuf[col].c_char == c) { for (i = 0; i < w; i++) obuf[col + i].c_mode |= BOLD|mode; } else { Index: gnu/lib/libgcc/Makefile =================================================================== --- gnu/lib/libgcc/Makefile (.../head) (revision 243940) +++ gnu/lib/libgcc/Makefile (.../projects/arm_eabi) (revision 243946) @@ -15,6 +15,10 @@ MK_SSP= no .include "${.CURDIR}/../../usr.bin/cc/Makefile.tgt" +.if ${TARGET_CPUARCH} == "arm" && ${MK_ARM_EABI} != "no" +CFLAGS+= -DTARGET_ARM_EABI +.endif + .if ${TARGET_CPUARCH} == "mips" LIB= gcc .endif @@ -52,10 +56,13 @@ LIB2FUNCS+= _fixuns${mode}si .endfor # Likewise double-word routines. +.if ${TARGET_CPUARCH} != "arm" && ${MK_ARM_EABI} != "no" +# These are implemented in an ARM specific file but will not be filtered out .for mode in sf df xf tf LIB2FUNCS+= _fix${mode}di _fixuns${mode}di LIB2FUNCS+= _floatdi${mode} _floatundi${mode} .endfor +.endif LIB2ADD = $(LIB2FUNCS_EXTRA) LIB2ADD_ST = $(LIB2FUNCS_STATIC_EXTRA) @@ -108,15 +115,14 @@ LIB2_DIVMOD_FUNCS = _divdi3 _moddi3 _udi CFLAGS+= -Dinhibit_libc -fno-inline LIB1ASMSRC = lib1funcs.asm LIB1ASMFUNCS = _dvmd_tls _bb_init_func -LIB2FUNCS_EXTRA = floatunsidf.c floatunsisf.c +.if ${MK_ARM_EABI} != "no" +LIB1ASMFUNCS+= _addsubdf3 _addsubsf3 _cmpdf2 _cmpsf2 _fixdfsi _fixsfsi \ + _fixunsdfsi _fixunsdfsi _muldivdf3 _muldivsf3 _udivsi3 -# Not now -#LIB1ASMFUNCS = _udivsi3 _divsi3 _umodsi3 _modsi3 _dvmd_tls _bb_init_func -#LIB1ASMFUNCS+= _call_via_rX _interwork_call_via_rX \ -# _lshrdi3 _ashrdi3 _ashldi3 \ -# _negdf2 _addsubdf3 _muldivdf3 _cmpdf2 _unorddf2 _fixdfsi _fixunsdfsi \ -# _truncdfsf2 _negsf2 _addsubsf3 _muldivsf3 _cmpsf2 _unordsf2 \ -# _fixsfsi _fixunssfsi _floatdidf _floatdisf +LIB2ADDEH = unwind-arm.c libunwind.S pr-support.c unwind-c.c +.else +LIB2FUNCS_EXTRA = floatunsidf.c floatunsisf.c +.endif .endif .if ${TARGET_CPUARCH} == mips @@ -322,6 +328,9 @@ CLEANFILES += cs-*.h option* SHLIB_MKMAP = ${GCCDIR}/mkmap-symver.awk SHLIB_MKMAP_OPTS = SHLIB_MAPFILES = ${GCCDIR}/libgcc-std.ver +.if ${TARGET_CPUARCH} == "arm" && ${MK_ARM_EABI} != "no" +SHLIB_MAPFILES += ${GCCDIR}/config/arm/libgcc-bpabi.ver +.endif VERSION_MAP = libgcc.map libgcc.map: ${SHLIB_MKMAP} ${SHLIB_MAPFILES} ${SOBJS} ${OBJS:R:S/$/.So/} Index: gnu/lib/libgcov/Makefile =================================================================== --- gnu/lib/libgcov/Makefile (.../head) (revision 243940) +++ gnu/lib/libgcov/Makefile (.../projects/arm_eabi) (revision 243946) @@ -15,6 +15,11 @@ CFLAGS+= -DIN_GCC -DIN_LIBGCC2 -D__GCC_F CFLAGS+= -D_PTHREADS -DGTHREAD_USE_WEAK CFLAGS+= -I${.CURDIR}/../../usr.bin/cc/cc_tools \ -I${GCCLIB}/include -I${GCCDIR}/config -I${GCCDIR} -I. + +.if ${TARGET_CPUARCH} == "arm" && ${MK_ARM_EABI} != "no" +CFLAGS+= -DTARGET_ARM_EABI +.endif + # # Library members defined in libgcov.c. # Defined in libgcov.c, included only in gcov library Index: gnu/lib/csu/Makefile =================================================================== --- gnu/lib/csu/Makefile (.../head) (revision 243940) +++ gnu/lib/csu/Makefile (.../projects/arm_eabi) (revision 243946) @@ -24,6 +24,10 @@ CFLAGS+= -I${GCCLIB}/include -I${GCCDIR} CRTS_CFLAGS= -DCRTSTUFFS_O -DSHARED ${PICFLAG} MKDEP= -DCRT_BEGIN +.if ${TARGET_CPUARCH} == "arm" && ${MK_ARM_EABI} != "no" +CFLAGS+= -DTARGET_ARM_EABI +.endif + .if ${MACHINE_CPUARCH} == "ia64" BEGINSRC= crtbegin.asm ENDSRC= crtend.asm Index: gnu/lib/libstdc++/Makefile =================================================================== --- gnu/lib/libstdc++/Makefile (.../head) (revision 243940) +++ gnu/lib/libstdc++/Makefile (.../projects/arm_eabi) (revision 243946) @@ -1,5 +1,7 @@ # $FreeBSD$ +.include + GCCVER= 4.2 GCCDIR= ${.CURDIR}/../../../contrib/gcc GCCLIB= ${.CURDIR}/../../../contrib/gcclibs @@ -14,7 +16,7 @@ LIB= stdc++ SHLIB_MAJOR= 6 CFLAGS+= -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -.if ${MACHINE_CPUARCH} == "arm" +.if ${MACHINE_CPUARCH} == "arm" && ${MK_ARM_EABI} == "no" CFLAGS+= -D_GLIBCXX_SJLJ_EXCEPTIONS=1 .endif CFLAGS+= -I${.CURDIR} -I${SUPDIR} -I${GCCDIR} -I${SRCDIR}/include @@ -594,7 +596,13 @@ gthr-default.h: ${GCCDIR}/gthr-posix.h CLEANFILES+= ${THRHDRS} +.if ${MACHINE_CPUARCH} == "arm" && ${MK_ARM_EABI} != "no" +unwind.h: ${GCCDIR}/config/arm/unwind-arm.h +.else unwind.h: ${GCCDIR}/unwind-generic.h +.endif + +unwind.h: ln -sf ${.ALLSRC} ${.TARGET} SRCS+= unwind.h Index: gnu/usr.bin/cc/c++filt/Makefile =================================================================== --- gnu/usr.bin/cc/c++filt/Makefile (.../head) (revision 243940) +++ gnu/usr.bin/cc/c++filt/Makefile (.../projects/arm_eabi) (revision 243946) @@ -1,5 +1,8 @@ # $FreeBSD$ +NO_MAN= +.include + .include "../Makefile.inc" .include "../Makefile.fe" @@ -7,7 +10,6 @@ PROG= c++filt SRCS= cp-demangle.c -NO_MAN= CFLAGS+= -DSTANDALONE_DEMANGLER -DVERSION=\"$(GCC_VERSION)\" Index: gnu/usr.bin/cc/libdecnumber/Makefile =================================================================== --- gnu/usr.bin/cc/libdecnumber/Makefile (.../head) (revision 243940) +++ gnu/usr.bin/cc/libdecnumber/Makefile (.../projects/arm_eabi) (revision 243946) @@ -1,5 +1,7 @@ # $FreeBSD$ +.include + # Use our headers in preference to ones from ../cc_tools. CFLAGS+= -I${.CURDIR} -I. Index: gnu/usr.bin/cc/gcov/Makefile =================================================================== --- gnu/usr.bin/cc/gcov/Makefile (.../head) (revision 243940) +++ gnu/usr.bin/cc/gcov/Makefile (.../projects/arm_eabi) (revision 243946) @@ -1,5 +1,7 @@ # $FreeBSD$ +.include + .include "../Makefile.inc" .include "../Makefile.ver" Index: gnu/usr.bin/cc/cc_int/Makefile =================================================================== --- gnu/usr.bin/cc/cc_int/Makefile (.../head) (revision 243940) +++ gnu/usr.bin/cc/cc_int/Makefile (.../projects/arm_eabi) (revision 243946) @@ -1,5 +1,7 @@ # $FreeBSD$ +.include + .include "../Makefile.inc" .include "../Makefile.ver" Index: gnu/usr.bin/cc/cc_tools/Makefile =================================================================== --- gnu/usr.bin/cc/cc_tools/Makefile (.../head) (revision 243940) +++ gnu/usr.bin/cc/cc_tools/Makefile (.../projects/arm_eabi) (revision 243946) @@ -51,6 +51,9 @@ TARGET_INC+= ${GCC_CPU}/elf.h .endif .if ${TARGET_CPUARCH} == "arm" TARGET_INC+= ${GCC_CPU}/aout.h +.if ${MK_ARM_EABI} != "no" +TARGET_INC+= ${GCC_CPU}/bpabi.h +.endif .endif .if ${TARGET_ARCH} == "powerpc64" TARGET_INC+= ${GCC_CPU}/biarch64.h @@ -349,7 +352,13 @@ gthr-default.h: ${GCCDIR}/gthr-posix.h GENSRCS+= gthr-default.h +.if ${TARGET_CPUARCH} == "arm" && ${MK_ARM_EABI} != "no" +unwind.h: ${GCCDIR}/config/arm/unwind-arm.h +.else unwind.h: ${GCCDIR}/unwind-generic.h +.endif + +unwind.h: ln -sf ${.ALLSRC} ${.TARGET} GENSRCS+= unwind.h Index: gnu/usr.bin/cc/doc/Makefile =================================================================== --- gnu/usr.bin/cc/doc/Makefile (.../head) (revision 243940) +++ gnu/usr.bin/cc/doc/Makefile (.../projects/arm_eabi) (revision 243946) @@ -1,5 +1,7 @@ # $FreeBSD$ +.include + .include "../Makefile.inc" .include "../Makefile.ver" Index: gnu/usr.bin/cc/cc1/Makefile =================================================================== --- gnu/usr.bin/cc/cc1/Makefile (.../head) (revision 243940) +++ gnu/usr.bin/cc/cc1/Makefile (.../projects/arm_eabi) (revision 243946) @@ -1,9 +1,10 @@ # $FreeBSD$ -.include "../Makefile.inc" NO_MAN= .include +.include "../Makefile.inc" + .PATH: ${GCCDIR} PROG= cc1 Index: gnu/usr.bin/cc/libcpp/Makefile =================================================================== --- gnu/usr.bin/cc/libcpp/Makefile (.../head) (revision 243940) +++ gnu/usr.bin/cc/libcpp/Makefile (.../projects/arm_eabi) (revision 243946) @@ -1,5 +1,7 @@ # $FreeBSD$ +.include + # Use our headers in preference to ones from ../cc_tools. CFLAGS+= -I${.CURDIR} -I. Index: gnu/usr.bin/cc/cc1plus/Makefile =================================================================== --- gnu/usr.bin/cc/cc1plus/Makefile (.../head) (revision 243940) +++ gnu/usr.bin/cc/cc1plus/Makefile (.../projects/arm_eabi) (revision 243946) @@ -1,9 +1,10 @@ # $FreeBSD$ -.include "../Makefile.inc" NO_MAN= .include +.include "../Makefile.inc" + .PATH: ${GCCDIR}/cp ${GCCDIR} PROG= cc1plus Index: gnu/usr.bin/cc/include/Makefile =================================================================== --- gnu/usr.bin/cc/include/Makefile (.../head) (revision 243940) +++ gnu/usr.bin/cc/include/Makefile (.../projects/arm_eabi) (revision 243946) @@ -1,5 +1,7 @@ # $FreeBSD$ +.include + .include "../Makefile.inc" INCSDIR=${INCLUDEDIR}/gcc/${GCCVER} Index: gnu/usr.bin/cc/libiberty/Makefile =================================================================== --- gnu/usr.bin/cc/libiberty/Makefile (.../head) (revision 243940) +++ gnu/usr.bin/cc/libiberty/Makefile (.../projects/arm_eabi) (revision 243946) @@ -1,5 +1,7 @@ # $FreeBSD$ +.include + # # Make sure we will pick up our config.h file first, not the one from # cc_tools. Index: gnu/usr.bin/cc/Makefile.inc =================================================================== --- gnu/usr.bin/cc/Makefile.inc (.../head) (revision 243940) +++ gnu/usr.bin/cc/Makefile.inc (.../projects/arm_eabi) (revision 243946) @@ -26,6 +26,10 @@ CSTD?= gnu89 CFLAGS+= -DCROSS_COMPILE .endif +.if ${TARGET_CPUARCH} == "arm" && ${MK_ARM_EABI} != "no" +CFLAGS+= -DTARGET_ARM_EABI +.endif + .if ${TARGET_ARCH} == "armeb" || ${TARGET_ARCH} == "armv6eb" CFLAGS += -DTARGET_ENDIAN_DEFAULT=MASK_BIG_END .endif Index: gnu/usr.bin/binutils/ld/armelfb_fbsd.sh =================================================================== --- gnu/usr.bin/binutils/ld/armelfb_fbsd.sh (.../head) (revision 243940) +++ gnu/usr.bin/binutils/ld/armelfb_fbsd.sh (.../projects/arm_eabi) (revision 243946) @@ -5,6 +5,7 @@ #OUTPUT_FORMAT="elf32-bigarm" . ${srcdir}/emulparams/armelf.sh . ${srcdir}/emulparams/elf_fbsd.sh +TARGET2_TYPE=got-rel MAXPAGESIZE=0x8000 GENERATE_PIE_SCRIPT=yes Index: gnu/usr.bin/binutils/ld/armelf_fbsd.sh =================================================================== --- gnu/usr.bin/binutils/ld/armelf_fbsd.sh (.../head) (revision 243940) +++ gnu/usr.bin/binutils/ld/armelf_fbsd.sh (.../projects/arm_eabi) (revision 243946) @@ -1,6 +1,7 @@ # $FreeBSD$ . ${srcdir}/emulparams/armelf.sh . ${srcdir}/emulparams/elf_fbsd.sh +TARGET2_TYPE=got-rel MAXPAGESIZE=0x8000 GENERATE_PIE_SCRIPT=yes Index: tools/build/options/WITHOUT_ARM_EABI =================================================================== --- tools/build/options/WITHOUT_ARM_EABI (.../head) (revision 0) +++ tools/build/options/WITHOUT_ARM_EABI (.../projects/arm_eabi) (revision 243946) @@ -0,0 +1,2 @@ +.\" $FreeBSD$ +Set the ARM ABI to EABI. Index: contrib/gcc/config/arm/freebsd.h =================================================================== --- contrib/gcc/config/arm/freebsd.h (.../head) (revision 243940) +++ contrib/gcc/config/arm/freebsd.h (.../projects/arm_eabi) (revision 243946) @@ -29,8 +29,13 @@ { "fbsd_dynamic_linker", FBSD_DYNAMIC_LINKER } #undef SUBTARGET_EXTRA_ASM_SPEC +#ifdef TARGET_ARM_EABI +#define SUBTARGET_EXTRA_ASM_SPEC \ + "%{mabi=apcs-gnu|mabi=atpcs:-meabi=gnu;:-meabi=4} %{fpic|fpie:-k} %{fPIC|fPIE:-k}" +#else #define SUBTARGET_EXTRA_ASM_SPEC \ "-matpcs %{fpic|fpie:-k} %{fPIC|fPIE:-k}" +#endif /* Default to full FPA if -mhard-float is specified. */ #undef SUBTARGET_ASM_FLOAT_SPEC @@ -56,11 +61,28 @@ /************************[ Target stuff ]***********************************/ - #ifndef TARGET_ENDIAN_DEFAULT #define TARGET_ENDIAN_DEFAULT 0 #endif +#ifdef TARGET_ARM_EABI +/* We default to a soft-float ABI so that binaries can run on all + target hardware. */ +#undef TARGET_DEFAULT_FLOAT_ABI +#define TARGET_DEFAULT_FLOAT_ABI ARM_FLOAT_ABI_SOFT + +#undef ARM_DEFAULT_ABI +#define ARM_DEFAULT_ABI ARM_ABI_AAPCS_LINUX + +#undef TARGET_OS_CPP_BUILTINS +#define TARGET_OS_CPP_BUILTINS() \ + do \ + { \ + FBSD_TARGET_OS_CPP_BUILTINS(); \ + TARGET_BPABI_CPP_BUILTINS(); \ + } \ + while (false) +#else /* Default it to use ATPCS with soft-VFP. */ #undef TARGET_DEFAULT #define TARGET_DEFAULT \ @@ -70,6 +92,10 @@ #undef ARM_DEFAULT_ABI #define ARM_DEFAULT_ABI ARM_ABI_ATPCS +#undef FPUTYPE_DEFAULT +#define FPUTYPE_DEFAULT FPUTYPE_VFP +#endif + /* Define the actual types of some ANSI-mandated types. Needs to agree with . GCC defaults come from c-decl.c, c-common.c, and config//.h. */ @@ -97,7 +123,7 @@ #define TARGET_VERSION fprintf (stderr, " (FreeBSD/armv6 ELF)"); #else #undef SUBTARGET_CPU_DEFAULT -#define SUBTARGET_CPU_DEFAULT TARGET_CPU_strongarm +#define SUBTARGET_CPU_DEFAULT TARGET_CPU_arm9 #undef TARGET_VERSION #define TARGET_VERSION fprintf (stderr, " (FreeBSD/StrongARM ELF)"); #endif @@ -134,5 +160,3 @@ do \ } \ while (0) -#undef FPUTYPE_DEFAULT -#define FPUTYPE_DEFAULT FPUTYPE_VFP Index: contrib/compiler-rt/lib/ucmpdi2.c =================================================================== --- contrib/compiler-rt/lib/ucmpdi2.c (.../head) (revision 243940) +++ contrib/compiler-rt/lib/ucmpdi2.c (.../projects/arm_eabi) (revision 243946) @@ -36,3 +36,13 @@ __ucmpdi2(du_int a, du_int b) return 2; return 1; } + +#ifdef __ARM_EABI__ +/* Returns (-1, 0, 1) for (<, ==, >) */ +COMPILER_RT_ABI si_int +__aeabi_ulcmp(di_int a, di_int b) +{ + return __ucmpdi2(a, b) - 1; +} +#endif + Index: contrib/compiler-rt/lib/int_lib.h =================================================================== --- contrib/compiler-rt/lib/int_lib.h (.../head) (revision 243940) +++ contrib/compiler-rt/lib/int_lib.h (.../projects/arm_eabi) (revision 243946) @@ -25,7 +25,14 @@ #if __ARM_EABI__ # define ARM_EABI_FNALIAS(aeabi_name, name) \ void __aeabi_##aeabi_name() __attribute__((alias("__" #name))); -# define COMPILER_RT_ABI __attribute__((pcs("aapcs"))) + +# if defined(__GNUC__) && (__GNUC__ < 4 || __GNUC__ == 4 && __GNUC_MINOR__ < 5) +/* The pcs attribute was introduced in GCC 4.5.0 */ +# define COMPILER_RT_ABI +# else +# define COMPILER_RT_ABI __attribute__((pcs("aapcs"))) +# endif + #else # define ARM_EABI_FNALIAS(aeabi_name, name) # define COMPILER_RT_ABI Index: contrib/compiler-rt/lib/fixsfdi.c =================================================================== --- contrib/compiler-rt/lib/fixsfdi.c (.../head) (revision 243940) +++ contrib/compiler-rt/lib/fixsfdi.c (.../projects/arm_eabi) (revision 243946) @@ -23,7 +23,7 @@ /* seee eeee emmm mmmm mmmm mmmm mmmm mmmm */ -ARM_EABI_FNALIAS(d2lz, fixsfdi) +ARM_EABI_FNALIAS(f2lz, fixsfdi) COMPILER_RT_ABI di_int __fixsfdi(float a) Index: contrib/compiler-rt/lib/cmpdi2.c =================================================================== --- contrib/compiler-rt/lib/cmpdi2.c (.../head) (revision 243940) +++ contrib/compiler-rt/lib/cmpdi2.c (.../projects/arm_eabi) (revision 243946) @@ -36,3 +36,13 @@ __cmpdi2(di_int a, di_int b) return 2; return 1; } + +#ifdef __ARM_EABI__ +/* Returns (-1, 0, 1) for (<, ==, >) */ +COMPILER_RT_ABI si_int +__aeabi_lcmp(di_int a, di_int b) +{ + return __cmpdi2(a, b) - 1; +} +#endif + Index: contrib/libstdc++/include/std/std_limits.h =================================================================== --- contrib/libstdc++/include/std/std_limits.h (.../head) (revision 243940) +++ contrib/libstdc++/include/std/std_limits.h (.../projects/arm_eabi) (revision 243946) @@ -134,10 +134,11 @@ #define __glibcxx_signed(T) ((T)(-1) < 0) #define __glibcxx_min(T) \ - (__glibcxx_signed (T) ? (T)1 << __glibcxx_digits (T) : (T)0) + (__glibcxx_signed (T) ? (((T)1 << (__glibcxx_digits (T) - 1)) << 1) : (T)0) #define __glibcxx_max(T) \ - (__glibcxx_signed (T) ? ((T)1 << __glibcxx_digits (T)) - 1 : ~(T)0) + (__glibcxx_signed (T) ? \ + (((((T)1 << (__glibcxx_digits (T) - 1)) - 1) << 1) + 1) : ~(T)0) #define __glibcxx_digits(T) \ (sizeof(T) * __CHAR_BIT__ - __glibcxx_signed (T)) Index: share/mk/bsd.own.mk =================================================================== --- share/mk/bsd.own.mk (.../head) (revision 243940) +++ share/mk/bsd.own.mk (.../projects/arm_eabi) (revision 243946) @@ -304,6 +304,7 @@ __DEFAULT_YES_OPTIONS = \ ACPI \ AMD \ APM \ + ARM_EABI \ ASSERT_DEBUG \ AT \ ATF \ Index: lib/libcompiler_rt/Makefile =================================================================== --- lib/libcompiler_rt/Makefile (.../head) (revision 243940) +++ lib/libcompiler_rt/Makefile (.../projects/arm_eabi) (revision 243946) @@ -132,18 +132,23 @@ SRCF+= adddf3 \ addsf3 \ divdf3 \ divsf3 \ - divsi3 \ extendsfdf2 \ fixdfsi \ fixsfsi \ floatsidf \ floatsisf \ - modsi3 \ muldf3 \ mulsf3 \ subdf3 \ subsf3 \ - truncdfsf2 \ + truncdfsf2 +.endif + +# TODO: Fix this logic for !mips, !arm oabi +.if ${MACHINE_CPUARCH} != "mips" && \ + (${MACHINE_CPUARCH} != "arm" || ${MK_ARM_EABI} != "no") +SRCF+= divsi3 \ + modsi3 \ udivsi3 \ umodsi3 .endif @@ -176,6 +181,13 @@ SRCS+= ${file}.c . endif .endfor +.if ${MACHINE_CPUARCH} == "arm" && ${MK_ARM_EABI} != "no" +SRCS+= aeabi_idivmod.S \ + aeabi_ldivmod.S \ + aeabi_uidivmod.S \ + aeabi_uldivmod.S +.endif + .if ${MACHINE_CPUARCH} != "mips" . if ${MK_INSTALLLIB} != "no" SYMLINKS+=libcompiler_rt.a ${LIBDIR}/libgcc.a Index: lib/libc/arm/Symbol.map =================================================================== --- lib/libc/arm/Symbol.map (.../head) (revision 243940) +++ lib/libc/arm/Symbol.map (.../projects/arm_eabi) (revision 243946) @@ -46,10 +46,6 @@ FBSDprivate_1.0 { _set_tp; __aeabi_read_tp; ___longjmp; - __umodsi3; - __modsi3; - __udivsi3; - __divsi3; __makecontext; __longjmp; signalcontext; Index: lib/libc/arm/aeabi/aeabi_unwind_cpp.c =================================================================== --- lib/libc/arm/aeabi/aeabi_unwind_cpp.c (.../head) (revision 0) +++ lib/libc/arm/aeabi/aeabi_unwind_cpp.c (.../projects/arm_eabi) (revision 243946) @@ -0,0 +1,61 @@ +/* + * Copyright (C) 2011 Andrew Turner + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + */ + +/* + * Provide an implementation of __aeabi_unwind_cpp_pr{0,1,2}. These are + * required by libc but are implemented in libgcc_eh.a which we don't link + * against. The libgcc_eh.a version will be called so we call abort to + * check this. + */ + +#include +__FBSDID("$FreeBSD$"); + +#include + +void __aeabi_unwind_cpp_pr0(void) __hidden; +void __aeabi_unwind_cpp_pr1(void) __hidden; +void __aeabi_unwind_cpp_pr2(void) __hidden; + +void +__aeabi_unwind_cpp_pr0(void) +{ + abort(); +} + +void +__aeabi_unwind_cpp_pr1(void) +{ + abort(); +} + +void +__aeabi_unwind_cpp_pr2(void) +{ + abort(); +} + Index: lib/libc/arm/aeabi/aeabi_double.c =================================================================== --- lib/libc/arm/aeabi/aeabi_double.c (.../head) (revision 0) +++ lib/libc/arm/aeabi/aeabi_double.c (.../projects/arm_eabi) (revision 243946) @@ -0,0 +1,101 @@ +/* + * Copyright (C) 2012 Andrew Turner + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + */ + +#include +__FBSDID("$FreeBSD$"); + +#include "softfloat-for-gcc.h" +#include "milieu.h" +#include "softfloat.h" + +flag __unorddf2(float64, float64); + +int __aeabi_dcmpeq(float64 a, float64 b) +{ + return float64_eq(a, b); +} + +int __aeabi_dcmplt(float64 a, float64 b) +{ + return float64_lt(a, b); +} + +int __aeabi_dcmple(float64 a, float64 b) +{ + return float64_le(a, b); +} + +int __aeabi_dcmpge(float64 a, float64 b) +{ + return float64_le(b, a); +} + +int __aeabi_dcmpgt(float64 a, float64 b) +{ + return float64_lt(b, a); +} + +int __aeabi_dcmpun(float64 a, float64 b) +{ + return __unorddf2(a, b); +} + +int __aeabi_d2iz(float64 a) +{ + return float64_to_int32_round_to_zero(a); +} + +float32 __aeabi_d2f(float64 a) +{ + return float64_to_float32(a); +} + +float64 __aeabi_i2d(int a) +{ + return int32_to_float64(a); +} + +float64 __aeabi_dadd(float64 a, float64 b) +{ + return float64_add(a, b); +} + +float64 __aeabi_ddiv(float64 a, float64 b) +{ + return float64_div(a, b); +} + +float64 __aeabi_dmul(float64 a, float64 b) +{ + return float64_mul(a, b); +} + +float64 __aeabi_dsub(float64 a, float64 b) +{ + return float64_sub(a, b); +} + Index: lib/libc/arm/aeabi/aeabi_atexit.c =================================================================== --- lib/libc/arm/aeabi/aeabi_atexit.c (.../head) (revision 0) +++ lib/libc/arm/aeabi/aeabi_atexit.c (.../projects/arm_eabi) (revision 243946) @@ -0,0 +1,38 @@ +/* + * Copyright (C) 2012 Andrew Turner + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + */ + +#include +__FBSDID("$FreeBSD$"); + +int __cxa_atexit(void (*)(void *), void *, void *); + +int +__aeabi_atexit(void *object, void (*func)(void*), void *dso) +{ + return __cxa_atexit(func, object, dso); +} + Index: lib/libc/arm/aeabi/Symbol.map =================================================================== --- lib/libc/arm/aeabi/Symbol.map (.../head) (revision 0) +++ lib/libc/arm/aeabi/Symbol.map (.../projects/arm_eabi) (revision 243946) @@ -0,0 +1,47 @@ +/* + * $FreeBSD: projects/arm_eabi/lib/libc/arm/Symbol.map 228591 2011-12-16 19:38:31Z andrew $ + */ + +/* + * This only needs to contain AEABI symbols that are not listed in + * symbol maps from other parts of libc (i.e., not found in + * stdlib/Symbol.map, string/Symbol.map, sys/Symbol.map, ...). + */ +FBSDprivate_1.0 { + __aeabi_atexit; + + __aeabi_dcmpeq; + __aeabi_dcmplt; + __aeabi_dcmple; + __aeabi_dcmpge; + __aeabi_dcmpgt; + __aeabi_dcmpun; + + __aeabi_d2iz; + __aeabi_d2f; + + __aeabi_dadd; + __aeabi_ddiv; + __aeabi_dmul; + __aeabi_dsub; + + + __aeabi_fcmpeq; + __aeabi_fcmplt; + __aeabi_fcmple; + __aeabi_fcmpge; + __aeabi_fcmpgt; + __aeabi_fcmpun; + + __aeabi_f2iz; + __aeabi_f2d; + + __aeabi_fadd; + __aeabi_fdiv; + __aeabi_fmul; + __aeabi_fsub; + + + __aeabi_i2d; + __aeabi_i2f; +}; Index: lib/libc/arm/aeabi/Makefile.inc =================================================================== --- lib/libc/arm/aeabi/Makefile.inc (.../head) (revision 0) +++ lib/libc/arm/aeabi/Makefile.inc (.../projects/arm_eabi) (revision 243946) @@ -0,0 +1,11 @@ +# $FreeBSD$ + +.PATH: ${.CURDIR}/arm/aeabi + +SRCS+= aeabi_atexit.c \ + aeabi_double.c \ + aeabi_float.c \ + aeabi_unwind_cpp.c + +SYM_MAPS+=${.CURDIR}/arm/aeabi/Symbol.map + Index: lib/libc/arm/aeabi/aeabi_float.c =================================================================== --- lib/libc/arm/aeabi/aeabi_float.c (.../head) (revision 0) +++ lib/libc/arm/aeabi/aeabi_float.c (.../projects/arm_eabi) (revision 243946) @@ -0,0 +1,101 @@ +/* + * Copyright (C) 2012 Andrew Turner + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + */ + +#include +__FBSDID("$FreeBSD$"); + +#include "softfloat-for-gcc.h" +#include "milieu.h" +#include "softfloat.h" + +flag __unordsf2(float32, float32); + +int __aeabi_fcmpeq(float32 a, float32 b) +{ + return float32_eq(a, b); +} + +int __aeabi_fcmplt(float32 a, float32 b) +{ + return float32_lt(a, b); +} + +int __aeabi_fcmple(float32 a, float32 b) +{ + return float32_le(a, b); +} + +int __aeabi_fcmpge(float32 a, float32 b) +{ + return float32_le(b, a); +} + +int __aeabi_fcmpgt(float32 a, float32 b) +{ + return float32_lt(b, a); +} + +int __aeabi_fcmpun(float32 a, float32 b) +{ + return __unordsf2(a, b); +} + +int __aeabi_f2iz(float32 a) +{ + return float32_to_int32_round_to_zero(a); +} + +float32 __aeabi_f2d(float32 a) +{ + return float32_to_float64(a); +} + +float32 __aeabi_i2f(int a) +{ + return int32_to_float32(a); +} + +float32 __aeabi_fadd(float32 a, float32 b) +{ + return float32_add(a, b); +} + +float32 __aeabi_fdiv(float32 a, float32 b) +{ + return float32_div(a, b); +} + +float32 __aeabi_fmul(float32 a, float32 b) +{ + return float32_mul(a, b); +} + +float32 __aeabi_fsub(float32 a, float32 b) +{ + return float32_sub(a, b); +} + Index: lib/libc/arm/SYS.h =================================================================== --- lib/libc/arm/SYS.h (.../head) (revision 243940) +++ lib/libc/arm/SYS.h (.../projects/arm_eabi) (revision 243946) @@ -39,7 +39,15 @@ #include #include +#ifdef __ARM_EABI__ +#define SYSTRAP(x) \ + mov ip, r7; \ + ldr r7, =SYS_ ## x; \ + swi 0 | SYS_ ## x; \ + mov r7, ip +#else #define SYSTRAP(x) swi 0 | SYS_ ## x +#endif #define CERROR _C_LABEL(cerror) #define CURBRK _C_LABEL(curbrk) Index: lib/libc/arm/Makefile.inc =================================================================== --- lib/libc/arm/Makefile.inc (.../head) (revision 243940) +++ lib/libc/arm/Makefile.inc (.../projects/arm_eabi) (revision 243946) @@ -8,3 +8,11 @@ SOFTFLOAT_BITS=32 # Long double is just double precision. MDSRCS+=machdep_ldisd.c SYM_MAPS+=${.CURDIR}/arm/Symbol.map + +.if ${MK_ARM_EABI} == "no" +# This contains the symbols that were removed when moving to the ARM EABI +SYM_MAPS+=${.CURDIR}/arm/Symbol_oabi.map +.else +.include "${.CURDIR}/arm/aeabi/Makefile.inc" +.endif + Index: lib/libc/arm/gen/Makefile.inc =================================================================== --- lib/libc/arm/gen/Makefile.inc (.../head) (revision 243940) +++ lib/libc/arm/gen/Makefile.inc (.../projects/arm_eabi) (revision 243946) @@ -3,4 +3,8 @@ SRCS+= _ctx_start.S _setjmp.S _set_tp.c alloca.S fabs.c \ getcontextx.c infinity.c ldexp.c makecontext.c \ - __aeabi_read_tp.S setjmp.S signalcontext.c sigsetjmp.S divsi3.S flt_rounds.c + __aeabi_read_tp.S setjmp.S signalcontext.c sigsetjmp.S flt_rounds.c + +.if ${MK_ARM_EABI} == "no" +SRCS+= divsi3.S +.endif Index: lib/libc/arm/Symbol_oabi.map =================================================================== --- lib/libc/arm/Symbol_oabi.map (.../head) (revision 0) +++ lib/libc/arm/Symbol_oabi.map (.../projects/arm_eabi) (revision 243946) @@ -0,0 +1,16 @@ +/* + * $FreeBSD: projects/arm_eabi/lib/libc/arm/Symbol.map 228591 2011-12-16 19:38:31Z andrew $ + */ + +/* + * This only needs to contain symbols that are not listed in + * symbol maps from other parts of libc (i.e., not found in + * stdlib/Symbol.map, string/Symbol.map, sys/Symbol.map, ...) + * and are not used in the ARM EABI. + */ +FBSDprivate_1.0 { + __umodsi3; + __modsi3; + __udivsi3; + __divsi3; +}; Index: lib/libc/quad/Makefile.inc =================================================================== --- lib/libc/quad/Makefile.inc (.../head) (revision 243940) +++ lib/libc/quad/Makefile.inc (.../projects/arm_eabi) (revision 243946) @@ -8,6 +8,10 @@ SRCS+= cmpdi2.c divdi3.c moddi3.c qdivrem.c ucmpdi2.c udivdi3.c umoddi3.c +.elif ${LIBC_ARCH} == "arm" && ${MK_ARM_EABI} != "no" + +SRCS+= adddi3.c anddi3.c floatunsdidf.c iordi3.c lshldi3.c notdi2.c \ + qdivrem.c subdi3.c xordi3.c .else SRCS+= adddi3.c anddi3.c ashldi3.c ashrdi3.c cmpdi2.c divdi3.c fixdfdi.c \ Index: bin/ls/util.c =================================================================== --- bin/ls/util.c (.../head) (revision 243940) +++ bin/ls/util.c (.../projects/arm_eabi) (revision 243946) @@ -184,7 +184,10 @@ prn_octal(const char *s) for (i = 0; i < (int)clen; i++) putchar((unsigned char)s[i]); len += wcwidth(wc); - } else if (goodchar && f_octal_escape && wc >= 0 && + } else if (goodchar && f_octal_escape && +#if WCHAR_MIN < 0 + wc >= 0 && +#endif wc <= (wchar_t)UCHAR_MAX && (p = strchr(esc, (char)wc)) != NULL) { putchar('\\'); --MP_/7MVrwQO4FwHdxm_6EcPilkm-- From owner-freebsd-arm@FreeBSD.ORG Sun Dec 9 18:18:31 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7377D882; Sun, 9 Dec 2012 18:18:31 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id E5AC38FC12; Sun, 9 Dec 2012 18:18:18 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qB9II553012970; Sun, 9 Dec 2012 11:18:11 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qB9IHfHu053325; Sun, 9 Dec 2012 11:17:41 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: Call for testing and review, busdma changes From: Ian Lepore To: Jeff Roberson In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Sun, 09 Dec 2012 11:17:41 -0700 Message-ID: <1355077061.87661.320.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 10 Dec 2012 00:18:15 +0000 Cc: powerpc@freebsd.org, marcel@freebsd.org, mips@freebsd.org, John Baldwin , mav@freebsd.org, scottl@freebsd.org, attilio@freebsd.org, kib@freebsd.org, sparc64@freebsd.org, arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2012 18:18:31 -0000 On Sat, 2012-12-08 at 08:51 -1000, Jeff Roberson wrote: > Hello, > > http://people.freebsd.org/~jeff/physbio.diff > > I have a relative large patch that reforms the busdma API so that new > types may be added without modifying every architecture's > busdma_machdep.c. It does this by unifying the bus_dmamap_load_buffer() > routines so that they may be called from MI code. The MD busdma is then > given a chance to do any final processing in the complete() callback. > This patch also contains cam changes to unify the bus_dmamap_load* > handling in cam drivers. > > The arm and mips implementations saw the largest changes since they have > to track virtual addresses for sync(). Previously this was done in a type > specific way. Now it is done in a generic way by recording the list of > virtuals in the map. > > I have verified that this patch passes make universe which includes > several kernel builds from each architecture. I suspect that if I broke > anything your machine simply won't boot or will throw I/O errors. There > is little subtlety, it is mostly refactoring. > Testing on armv4/v5 platforms, the patches applied and compiled cleanly, but fault-abort with a NULL deref on what appears to be the first call to bus_dmamap_load(). I'll dig deeper into debugging that after browsing the new code so I can figure out where to start debugging. Just from an initial quick browsing of the new code for armv4, I notice these things... The new routine __bus_dmamap_mayblock() does (*flags) |= BUS_DMA_WAITOK; which is a no-op because BUS_DMA_WAITOK is zero. I'm not sure what the intent was, but I think any modification of the WAIT-related flags would be conceptually wrong because it overrides the caller's instructions on whether or not to do a deferred load when resources aren't available. The way you've refactored the mbuf-related load routines, the MD code is no longer able to tell that it's an mbuf operation. This comes back to what I said a few days ago... when you look at the current code on various platforms you see a lot of false similarities. The code isn't nearly identical because it really all needs to be the same, it's because it was all copied from the same source, and it doesn't currently work correctly on arm and mips. With your changes, the ability to correct the implementation on those platforms is now gone. Perhaps this can be fixed easily by defining some new flags that the MI routines can OR-in to give the MD routines more info on what's happening. (Correcting the mbuf sync handling on arm and mips requires that we know at sync time that the buffers involved are mbufs, which means we need to know at map-load time so we can set a flag or a type code or something in the map that we can examine at sync time.) > The next step is to allow for dma loading of physical addresses. This > will permit unmapped I/O. Which is a significant performance optimization > targeted for 10.0. This sounds scary for arm and mips, or more specifically for VIVT cache platforms that can only do a sync based on virtual addresses. Can you talk some more about the plans for this? -- Ian From owner-freebsd-arm@FreeBSD.ORG Sun Dec 9 18:50:22 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E989C354 for ; Sun, 9 Dec 2012 18:50:22 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9EEC68FC19 for ; Sun, 9 Dec 2012 18:50:22 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id wz12so1412104pbc.13 for ; Sun, 09 Dec 2012 10:50:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version:content-type:x-gm-message-state; bh=5fWgylGiq8F/xIkEEo08py/KPhxFu2c4EOHYYrQz/mc=; b=IJ+jH1hjtFiGFDU2YWzfbEulbLvHEKAY+UyP/f3eUllYjpYxup/5Hfa0nDNRGdA16W 9/+ex7F3RkJp0uIguXBnB08mYWdDI3HLrU5d9wV3FDdAC6GdzaZ2zMzBjnCiV6DUysfS AjOvT/rSJNxWa3vY/Y9BKBW70k5xDRu3TbgiM+3lIGayeaA+fCuaJywO5N0Sx7visMm+ mOk9eWDdzfSal8TuwZXA7aZhLhOztfOrm9Z6lxyCR4YqAwouJCc4j4PA9KrkZAE4BiPD QKj4upTvFNe5mzdVPw5oKtq4WpXmB7823zXYlqFVaQUzlHY6BvbRkjDTJsyVYNeG/w8w +eFQ== Received: by 10.66.84.10 with SMTP id u10mr30029217pay.24.1355079021836; Sun, 09 Dec 2012 10:50:21 -0800 (PST) Received: from rrcs-66-91-135-210.west.biz.rr.com (rrcs-66-91-135-210.west.biz.rr.com. [66.91.135.210]) by mx.google.com with ESMTPS id m4sm10436372pav.17.2012.12.09.10.50.19 (version=SSLv3 cipher=OTHER); Sun, 09 Dec 2012 10:50:21 -0800 (PST) Date: Sun, 9 Dec 2012 08:48:51 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Ian Lepore Subject: Re: Call for testing and review, busdma changes In-Reply-To: <1355077061.87661.320.camel@revolution.hippie.lan> Message-ID: References: <1355077061.87661.320.camel@revolution.hippie.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Gm-Message-State: ALoCoQni++f7jsFluL5B5BUNPOZ8fGgxsydO95BOqdVyJza+RAtqT8YMEZrSXS49JxLxqcfcXTqf X-Mailman-Approved-At: Mon, 10 Dec 2012 00:18:29 +0000 Cc: powerpc@freebsd.org, marcel@freebsd.org, mips@freebsd.org, John Baldwin , mav@freebsd.org, scottl@freebsd.org, attilio@freebsd.org, kib@freebsd.org, sparc64@freebsd.org, arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2012 18:50:23 -0000 On Sun, 9 Dec 2012, Ian Lepore wrote: > On Sat, 2012-12-08 at 08:51 -1000, Jeff Roberson wrote: >> Hello, >> >> http://people.freebsd.org/~jeff/physbio.diff >> >> I have a relative large patch that reforms the busdma API so that new >> types may be added without modifying every architecture's >> busdma_machdep.c. It does this by unifying the bus_dmamap_load_buffer() >> routines so that they may be called from MI code. The MD busdma is then >> given a chance to do any final processing in the complete() callback. >> This patch also contains cam changes to unify the bus_dmamap_load* >> handling in cam drivers. >> >> The arm and mips implementations saw the largest changes since they have >> to track virtual addresses for sync(). Previously this was done in a type >> specific way. Now it is done in a generic way by recording the list of >> virtuals in the map. >> >> I have verified that this patch passes make universe which includes >> several kernel builds from each architecture. I suspect that if I broke >> anything your machine simply won't boot or will throw I/O errors. There >> is little subtlety, it is mostly refactoring. >> > > Testing on armv4/v5 platforms, the patches applied and compiled cleanly, > but fault-abort with a NULL deref on what appears to be the first call > to bus_dmamap_load(). I'll dig deeper into debugging that after > browsing the new code so I can figure out where to start debugging. Can you give me the file and line of the fault? > > Just from an initial quick browsing of the new code for armv4, I notice > these things... > > The new routine __bus_dmamap_mayblock() does (*flags) |= BUS_DMA_WAITOK; > which is a no-op because BUS_DMA_WAITOK is zero. I'm not sure what the > intent was, but I think any modification of the WAIT-related flags would > be conceptually wrong because it overrides the caller's instructions on > whether or not to do a deferred load when resources aren't available. The intent of the original load function seems to be that it is always blocking. Most architectures force the flag. The mbuf and uio load routines don't support blocking at all because the callback lacks the information needed to restart the operation. > > The way you've refactored the mbuf-related load routines, the MD code is > no longer able to tell that it's an mbuf operation. This comes back to > what I said a few days ago... when you look at the current code on > various platforms you see a lot of false similarities. The code isn't > nearly identical because it really all needs to be the same, it's > because it was all copied from the same source, and it doesn't currently > work correctly on arm and mips. With your changes, the ability to > correct the implementation on those platforms is now gone. Perhaps this > can be fixed easily by defining some new flags that the MI routines can > OR-in to give the MD routines more info on what's happening. (Correcting > the mbuf sync handling on arm and mips requires that we know at sync > time that the buffers involved are mbufs, which means we need to know at > map-load time so we can set a flag or a type code or something in the > map that we can examine at sync time.) Why do you need to know it is an mbuf if you have a record of the virtual addresses? The only type specific information was used to find the addresses. See how arm's busdma_machdep-v6 ws implemented. > >> The next step is to allow for dma loading of physical addresses. This >> will permit unmapped I/O. Which is a significant performance optimization >> targeted for 10.0. > > This sounds scary for arm and mips, or more specifically for VIVT cache > platforms that can only do a sync based on virtual addresses. Can you > talk some more about the plans for this? It will be for addresses which were never mapped into kva. To support unmaapped io. There will only be a need for bounce pages, no syncing. Jeff > > -- Ian > > From owner-freebsd-arm@FreeBSD.ORG Sun Dec 9 20:34:55 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1EEC849E; Sun, 9 Dec 2012 20:34:55 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id B46EA8FC13; Sun, 9 Dec 2012 20:34:42 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qB9KYZtS016544; Sun, 9 Dec 2012 13:34:41 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qB9KYAou053413; Sun, 9 Dec 2012 13:34:10 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: Call for testing and review, busdma changes From: Ian Lepore To: Jeff Roberson In-Reply-To: References: <1355077061.87661.320.camel@revolution.hippie.lan> Content-Type: multipart/mixed; boundary="=-jWdke4I5Nd/QjDc9IHG8" Date: Sun, 09 Dec 2012 13:34:10 -0700 Message-ID: <1355085250.87661.345.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-Mailman-Approved-At: Mon, 10 Dec 2012 00:18:48 +0000 Cc: powerpc@freebsd.org, marcel@freebsd.org, mips@freebsd.org, John Baldwin , mav@freebsd.org, scottl@freebsd.org, attilio@freebsd.org, kib@freebsd.org, sparc64@freebsd.org, arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2012 20:34:55 -0000 --=-jWdke4I5Nd/QjDc9IHG8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Sun, 2012-12-09 at 08:48 -1000, Jeff Roberson wrote: > > On Sun, 9 Dec 2012, Ian Lepore wrote: > > > On Sat, 2012-12-08 at 08:51 -1000, Jeff Roberson wrote: > >> Hello, > >> > >> http://people.freebsd.org/~jeff/physbio.diff > >> > >> I have a relative large patch that reforms the busdma API so that new > >> types may be added without modifying every architecture's > >> busdma_machdep.c. It does this by unifying the bus_dmamap_load_buffer() > >> routines so that they may be called from MI code. The MD busdma is then > >> given a chance to do any final processing in the complete() callback. > >> This patch also contains cam changes to unify the bus_dmamap_load* > >> handling in cam drivers. > >> > >> The arm and mips implementations saw the largest changes since they have > >> to track virtual addresses for sync(). Previously this was done in a type > >> specific way. Now it is done in a generic way by recording the list of > >> virtuals in the map. > >> > >> I have verified that this patch passes make universe which includes > >> several kernel builds from each architecture. I suspect that if I broke > >> anything your machine simply won't boot or will throw I/O errors. There > >> is little subtlety, it is mostly refactoring. > >> First an FYI, my replies to this thread aren't making it to the mailing lists, except when quoted by someone replying to them. They're being held for moderator approval because they're going to too many addresses. > > > > Testing on armv4/v5 platforms, the patches applied and compiled cleanly, > > but fault-abort with a NULL deref on what appears to be the first call > > to bus_dmamap_load(). I'll dig deeper into debugging that after > > browsing the new code so I can figure out where to start debugging. > > Can you give me the file and line of the fault? > Better than that, I can give you patches (attached). There were two little glitches... the allocated slist wasn't getting attached to the map, and when building the slist in _bus_dmamap_load_buffer() the slist needs to participate in the coalescing logic near the end of the loop. I'm not positive the attached quick-fix is perfect, but it allows one of my arm units here to boot and run and pass some basic IO smoke tests. I'll be trying it on other arm platforms later today. > > > > Just from an initial quick browsing of the new code for armv4, I notice > > these things... > > > > The new routine __bus_dmamap_mayblock() does (*flags) |= BUS_DMA_WAITOK; > > which is a no-op because BUS_DMA_WAITOK is zero. I'm not sure what the > > intent was, but I think any modification of the WAIT-related flags would > > be conceptually wrong because it overrides the caller's instructions on > > whether or not to do a deferred load when resources aren't available. > > The intent of the original load function seems to be that it is always > blocking. Most architectures force the flag. The mbuf and uio load > routines don't support blocking at all because the callback lacks the > information needed to restart the operation. > The manpage states that bus_dmamap_load() never blocks for any reason. The mbuf and uio flavors say they are variations of bus_dmapmap_load(); I take the implication of that to mean that they also are defined as never blocking. The docs then say that WAITOK vs. NOWAIT control the scheduling of a deferred load, and that NOWAIT is forced in the mbuf and uio cases. Your refactored code already handles that by adding NOWAIT to the caller-specified flags for mbufs and uio. So the code will do the right thing now (with your patches), but only because (*flags) |= BUS_DMA_WAITOK is a no-op. > > > > The way you've refactored the mbuf-related load routines, the MD code is > > no longer able to tell that it's an mbuf operation. This comes back to > > what I said a few days ago... when you look at the current code on > > various platforms you see a lot of false similarities. The code isn't > > nearly identical because it really all needs to be the same, it's > > because it was all copied from the same source, and it doesn't currently > > work correctly on arm and mips. With your changes, the ability to > > correct the implementation on those platforms is now gone. Perhaps this > > can be fixed easily by defining some new flags that the MI routines can > > OR-in to give the MD routines more info on what's happening. (Correcting > > the mbuf sync handling on arm and mips requires that we know at sync > > time that the buffers involved are mbufs, which means we need to know at > > map-load time so we can set a flag or a type code or something in the > > map that we can examine at sync time.) > > Why do you need to know it is an mbuf if you have a record of the virtual > addresses? The only type specific information was used to find the > addresses. See how arm's busdma_machdep-v6 ws implemented. > Because there is a special rule for mbufs on VIVT-cache architectures: the address of the data buffer is not aligned to a cacheline boundary, but the sync code is allowed to treat the buffer as if it is aligned and thus avoid invoking the partial cacheline flush algorithm. That algorithm was shown a few months ago to be fatally flawed, and we're on a path (albeit in super-slow-motion) to eliminate it. I have patches to fix the mbuf partial sync and other things related to partial sync problems, and my next step will be to try to rework them to fit in with what you've done. Based on what I've seen so far in your refactoring, I think just passing a flag to say it's an mbuf, from the MI to the MD mapping routine, will provide enough info. > > > >> The next step is to allow for dma loading of physical addresses. This > >> will permit unmapped I/O. Which is a significant performance optimization > >> targeted for 10.0. > > > > This sounds scary for arm and mips, or more specifically for VIVT cache > > platforms that can only do a sync based on virtual addresses. Can you > > talk some more about the plans for this? > > It will be for addresses which were never mapped into kva. To support > unmaapped io. There will only be a need for bounce pages, no syncing. > Can the pages be mapped into any non-kernel vmspaces? If they aren't mapped into any vmspace at all, then I think there'll be no implications for VIVT cache architectures. If they appear in any pmap at all then there may be problems. -- Ian --=-jWdke4I5Nd/QjDc9IHG8 Content-Disposition: inline; filename="physbio_armv4fix.diff" Content-Type: text/x-patch; name="physbio_armv4fix.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit diff -r bee560bf0159 sys/arm/arm/busdma_machdep.c --- a/sys/arm/arm/busdma_machdep.c Sun Dec 09 12:12:11 2012 -0700 +++ b/sys/arm/arm/busdma_machdep.c Sun Dec 09 13:01:12 2012 -0700 @@ -310,9 +310,10 @@ static __inline bus_dmamap_t map->flags = DMAMAP_ALLOCATED; } else map->flags = 0; - if (map != NULL) + if (map != NULL) { STAILQ_INIT(&map->bpages); - else + map->slist = slist; + } else free(slist, M_DEVBUF); return (map); } @@ -764,7 +765,6 @@ int { bus_size_t sgsize; bus_addr_t curaddr, baddr, bmask; - struct sync_list *sl; vm_offset_t vaddr = (vm_offset_t)buf; int seg; int error = 0; @@ -855,14 +855,6 @@ int if (((dmat->flags & BUS_DMA_COULD_BOUNCE) != 0) && map->pagesneeded != 0 && run_filter(dmat, curaddr)) { curaddr = add_bounce_page(dmat, map, vaddr, sgsize); - } else { - sl = &map->slist[map->sync_count]; - if (++map->sync_count > dmat->nsegments) - goto cleanup; - printf("sl %p count %d nseg %d\n", sl, map->sync_count, dmat->nsegments); - sl->vaddr = vaddr; - sl->datacount = sgsize; - sl->busaddr = curaddr; } if (dmat->ranges) { @@ -891,10 +883,15 @@ int (segs[seg].ds_addr & bmask) == (curaddr & bmask))) { segs[seg].ds_len += sgsize; + map->slist[seg].datacount += sgsize; goto segdone; } else { if (++seg >= dmat->nsegments) break; + ++map->sync_count; + map->slist[seg].vaddr = vaddr; + map->slist[seg].busaddr = curaddr; + map->slist[seg].datacount = sgsize; segs[seg].ds_addr = curaddr; segs[seg].ds_len = sgsize; } @@ -906,7 +903,6 @@ segdone: } *segp = seg; -cleanup: /* * Did we fit? */ --=-jWdke4I5Nd/QjDc9IHG8-- From owner-freebsd-arm@FreeBSD.ORG Mon Dec 10 00:54:18 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 57AFE2DA for ; Mon, 10 Dec 2012 00:54:18 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ia0-f181.google.com (mail-ia0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id 0ED688FC19 for ; Mon, 10 Dec 2012 00:54:17 +0000 (UTC) Received: by mail-ia0-f181.google.com with SMTP id s32so3234696iak.40 for ; Sun, 09 Dec 2012 16:54:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=NQ/SFUzHRS12x8NX6tNgjKotHD2QRO5QpoGfvtwLETk=; b=exiyWoucpZx+7FwoV2WYCVEOjXFwFQxcNcHGxQA4RysZQnDm+uDWSReZW1NafSPHcx 3Iwtm12g4AISXgBC5yCuokAriUTbhsDbdQ0/d9DnPL6vfec0se0SFUQ6Ax7Gwe64ZEO9 ijM2noVowrJOBbc8O80TYQIeNxk0JAP/RFZpP7A56AUW2JqASaGN7paFp0db9Xuk3B9Q 8OUKgQezEVGhfuM+fQVQKcHkGDbX4Ed0vW0U4kxbMebB1kE4j4MWl9Hgx3moxpDq/E21 nP6rLG3KipNOlCJmP7uGmQh/W+zOUyYWUxW29/oyWdAlfMS08N9FDkNhHO9b3Dnp7A8c Dj1g== Received: by 10.50.157.130 with SMTP id wm2mr7911478igb.0.1355100851225; Sun, 09 Dec 2012 16:54:11 -0800 (PST) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id l8sm5263808igo.13.2012.12.09.16.54.08 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 09 Dec 2012 16:54:10 -0800 (PST) Sender: Warner Losh Subject: Re: Call for testing and review, busdma changes Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sun, 9 Dec 2012 17:54:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1355077061.87661.320.camel@revolution.hippie.lan> To: Jeff Roberson X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnMTTWtpz7ZZ6OJSystw1tXpd9wkmLT8c9PNDhA9D4LOfw7c15K8ONFlksmZKSLjuTf6+yU X-Mailman-Approved-At: Mon, 10 Dec 2012 01:01:47 +0000 Cc: powerpc@freebsd.org, marcel@freebsd.org, mips@freebsd.org, John Baldwin , mav@freebsd.org, scottl@freebsd.org, attilio@freebsd.org, kib@freebsd.org, sparc64@freebsd.org, arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 00:54:18 -0000 [[ looks like Ian answered the other questions ]] On Dec 9, 2012, at 11:48 AM, Jeff Roberson wrote: >>> The next step is to allow for dma loading of physical addresses. = This >>> will permit unmapped I/O. Which is a significant performance = optimization >>> targeted for 10.0. >>=20 >> This sounds scary for arm and mips, or more specifically for VIVT = cache >> platforms that can only do a sync based on virtual addresses. Can = you >> talk some more about the plans for this? >=20 > It will be for addresses which were never mapped into kva. To support = unmaapped io. There will only be a need for bounce pages, no syncing. If there's a virtual mapping at all for the page (not just a kva), then = we need to flush/invalidate cache for those pages for safety unless we = know for sure there's nothing in the cache. It these are pages that = have never been mapped (say for zero copy between storage and network = controllers), then there won't be a problem. The whole reason for cache = jockeying is to make sure that any pending writes to the data are = flushed, and that any cached notion of the pages are invalidated once = the read is done. This is more important for mbuf operations, = operations with the USB stack or anything else that marshals data it = generates to be consumed by the stack/hardware. Warner From owner-freebsd-arm@FreeBSD.ORG Mon Dec 10 06:25:09 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AA060FFA for ; Mon, 10 Dec 2012 06:25:09 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [88.198.91.248]) by mx1.freebsd.org (Postfix) with ESMTP id 5606F8FC13 for ; Mon, 10 Dec 2012 06:25:08 +0000 (UTC) Received: from [207.6.254.8] (helo=[192.168.1.67]) by id.bluezbox.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ThwnU-000Bvx-4r for arm@freebsd.org; Sun, 09 Dec 2012 22:25:02 -0800 From: Oleksandr Tymoshenko Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Unsolved problem with WB caches on ARMv6 Message-Id: <37F24B3C-4600-4E57-96EB-98C91FCD2B72@bluezbox.com> Date: Sun, 9 Dec 2012 22:24:42 -0800 To: arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Hello, One of the long-time issues with FreeBSD/ARMv6 is that Write-Back cache mode does not work properly. On PandaBoard changing cache mode to WB from WT causesUSB glitches (starting from stalls to network packets corruption) and random memory corruptions that manifest themselves as a userland programs crashes. [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 06:25:09 -0000 Hello, One of the long-time issues with FreeBSD/ARMv6 is that Write-Back cache mode does not work properly. On PandaBoard changing cache mode to WB = from WT=20 causesUSB glitches (starting from stalls to network packets corruption) = and random=20 memory corruptions that manifest themselves as a userland programs = crashes. gber@ tracked down one of the bugs several month ago, but it's still = unusable at least on my setup.=20 I spent some time debugging through busdma and USB code but failed to = find anything fishy. PandaBoard's USB host controller is EHCI. QH and QTDs = are=20 flushed properly. Corruption pattern in packets is weird: it's not = cacheline-size it's like chunk of data is just missing from bulk transfer DMA buffer. = L2 cache is disabled.=20 The issue is not reproducible in QEMU.=20 Fix for arm/160431 applied to busdma-v6.c didn't help.=20 I'm out of ideas for now. May be Ian or Alan will have some suggestions = where to look? If you have setup with armv6 devices, I'd appreciate test results for = this patch: http://people.freebsd.org/~gonzo/patches/armv6-wb.diff Just wondering if results differ from platform to platform.=20= From owner-freebsd-arm@FreeBSD.ORG Mon Dec 10 11:06:40 2012 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B9F06EEC for ; Mon, 10 Dec 2012 11:06:40 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 9CE9F8FC1E for ; Mon, 10 Dec 2012 11:06:40 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qBAB6eqh064166 for ; Mon, 10 Dec 2012 11:06:40 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qBAB6etk064164 for freebsd-arm@FreeBSD.org; Mon, 10 Dec 2012 11:06:40 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 10 Dec 2012 11:06:40 GMT Message-Id: <201212101106.qBAB6etk064164@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arm@FreeBSD.org Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 11:06:40 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o arm/173617 arm Dreamplug exhibits eSATA file corruption using network o kern/171096 arm [arm][xscale][ixp]Allow 16bit access on PCI bus o arm/166256 arm build fail in pmap.c o arm/162159 arm [panic] USB errors leading to panic on DockStar 9.0-RC o arm/161110 arm /usr/src/sys/arm/include/signal.h is bad o arm/161044 arm devel/icu does not build on arm o arm/158950 arm arm/sheevaplug fails fsx when mmap operations are enab o arm/155894 arm [patch] Enable at91 booting from SDHC (high capacity) p arm/155214 arm [patch] MMC/SD IO slow on Atmel ARM with modern large o arm/154227 arm [geli] using GELI leads to panic on ARM o arm/153380 arm Panic / translation fault with wlan on ARM o arm/150581 arm [irq] Unknown error generates IRQ address decoding err o arm/149288 arm mail/dovecot causes panic during configure on Sheevapl o arm/134368 arm [patch] nslu2_led driver for the LEDs on the NSLU2 p arm/134338 arm [patch] Lock GPIO accesses on ixp425 15 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon Dec 10 14:21:57 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 14C88EF9 for ; Mon, 10 Dec 2012 14:21:57 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 7DC648FC08 for ; Mon, 10 Dec 2012 14:21:56 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qBAELs71045899 for ; Mon, 10 Dec 2012 07:21:54 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qBAELVhX054330; Mon, 10 Dec 2012 07:21:31 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: Unsolved problem with WB caches on ARMv6 From: Ian Lepore To: Oleksandr Tymoshenko In-Reply-To: <37F24B3C-4600-4E57-96EB-98C91FCD2B72@bluezbox.com> References: <37F24B3C-4600-4E57-96EB-98C91FCD2B72@bluezbox.com> Content-Type: text/plain; charset="us-ascii" Date: Mon, 10 Dec 2012 07:21:31 -0700 Message-ID: <1355149291.87661.362.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 14:21:57 -0000 On Sun, 2012-12-09 at 22:24 -0800, Oleksandr Tymoshenko wrote: > Hello, > > One of the long-time issues with FreeBSD/ARMv6 is that Write-Back cache > mode does not work properly. On PandaBoard changing cache mode to WB from WT > causesUSB glitches (starting from stalls to network packets corruption) and random > memory corruptions that manifest themselves as a userland programs crashes. > > gber@ tracked down one of the bugs several month ago, but it's still unusable > at least on my setup. > > I spent some time debugging through busdma and USB code but failed to find > anything fishy. PandaBoard's USB host controller is EHCI. QH and QTDs are > flushed properly. Corruption pattern in packets is weird: it's not cacheline-size > it's like chunk of data is just missing from bulk transfer DMA buffer. L2 cache > is disabled. > > The issue is not reproducible in QEMU. > > Fix for arm/160431 applied to busdma-v6.c didn't help. > > I'm out of ideas for now. May be Ian or Alan will have some suggestions where to look? > > If you have setup with armv6 devices, I'd appreciate test results for this patch: > http://people.freebsd.org/~gonzo/patches/armv6-wb.diff > Just wondering if results differ from platform to platform. I was exchanging some ideas in email with Olivier last week about the armv6 cache glitches, but we didn't come up with anything useful, just lots of "yep, tried that already" things. I ordered some test gear last week at adafruit and spent enough that they threw in a free R-pi, so I should have an armv6 to play with soon. -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue Dec 11 03:51:51 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3C0A89CA for ; Tue, 11 Dec 2012 03:51:51 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [88.198.91.248]) by mx1.freebsd.org (Postfix) with ESMTP id C68128FC08 for ; Tue, 11 Dec 2012 03:51:50 +0000 (UTC) Received: from [88.198.91.248] (helo=[IPv6:::1]) by id.bluezbox.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TiGsh-000PDi-UT; Mon, 10 Dec 2012 19:51:46 -0800 Message-ID: <50C6ADCF.2040202@bluezbox.com> Date: Mon, 10 Dec 2012 19:51:43 -0800 From: Oleksandr Tymoshenko User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Mats Mellstrand Subject: Re: FreeBSD on Raspberry Pi 512MB (with U-Boot + ubldr) References: <3988C1622A974F19A9D3888F0334FF10@ad.peach.ne.jp> <50B8058C.9030909@bluezbox.com> <18DB98C9-66D9-4B00-989A-156F21E9981C@bsdimp.com> <1354552432.1140.28.camel@revolution.hippie.lan> <797FC9C0D52846548418B1E8F70A0402@ad.peach.ne.jp> <640A8F330E574984A36EC46EE4AFC1E7@ad.peach.ne.jp> <5C057160F8AC4DF596E8D9D50240574A@ad.peach.ne.jp> <7696D208-9D8F-481A-B0F0-DFC7DA8A2F29@exmandato.se> In-Reply-To: <7696D208-9D8F-481A-B0F0-DFC7DA8A2F29@exmandato.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 12/7/2012 8:58 AM, Mats Mellstrand wrote: > Hi, > > I changed kernel in an image built from r243975 (head) to the one you suggest. > > Seems to work fine. I can even use vi(1) from a ssh attached terminal :) > > > /mm > > On 7 dec 2012, at 15:47, "Daisuke Aoyama" wrote: > >> Hi, >> >>> From time to time the network behaves as frozen and then I get: >>> smsc0: warning: Failed to read register 0x114 >>> smsc0: warning: MII read timeout >>> on the serial console >>> After that, the network works again >> It looks a problem of non-optimized kernel. >> Please try test kernel in the test directory: >> >> http://www.peach.ne.jp/archives/rpi/test/ >> >> This will become a next time's kernel. >> Because of some problems, the world build is not yet completed... >> [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 03:51:51 -0000 On 12/7/2012 8:58 AM, Mats Mellstrand wrote: > Hi, > > I changed kernel in an image built from r243975 (head) to the one you suggest. > > Seems to work fine. I can even use vi(1) from a ssh attached terminal :) > > > /mm > > On 7 dec 2012, at 15:47, "Daisuke Aoyama" wrote: > >> Hi, >> >>> From time to time the network behaves as frozen and then I get: >>> smsc0: warning: Failed to read register 0x114 >>> smsc0: warning: MII read timeout >>> on the serial console >>> After that, the network works again >> It looks a problem of non-optimized kernel. >> Please try test kernel in the test directory: >> >> http://www.peach.ne.jp/archives/rpi/test/ >> >> This will become a next time's kernel. >> Because of some problems, the world build is not yet completed... >> Daisuke, do you have fix for this smsc issue? Could you submit patch for it? Thanks! From owner-freebsd-arm@FreeBSD.ORG Tue Dec 11 03:57:30 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7EBB4A5C; Tue, 11 Dec 2012 03:57:30 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id 3DB148FC12; Tue, 11 Dec 2012 03:57:30 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id qBB3vTTX088791; Tue, 11 Dec 2012 03:57:29 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id qBB3vTut088786; Tue, 11 Dec 2012 03:57:29 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 11 Dec 2012 03:57:29 GMT Message-Id: <201212110357.qBB3vTut088786@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 03:57:30 -0000 TB --- 2012-12-11 03:23:48 - tinderbox 2.9 running on freebsd-stable.sentex.ca TB --- 2012-12-11 03:23:48 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2012-12-11 03:23:48 - starting RELENG_9 tinderbox run for arm/arm TB --- 2012-12-11 03:23:48 - cleaning the object tree TB --- 2012-12-11 03:23:48 - checking out /src from svn://svn.freebsd.org/base/stable/9 TB --- 2012-12-11 03:23:48 - cd /tinderbox/RELENG_9/arm/arm TB --- 2012-12-11 03:23:48 - /usr/local/bin/svn cleanup /src TB --- 2012-12-11 03:24:22 - /usr/local/bin/svn update /src TB --- 2012-12-11 03:24:33 - At svn revision 244108 TB --- 2012-12-11 03:24:34 - building world TB --- 2012-12-11 03:24:34 - CROSS_BUILD_TESTING=YES TB --- 2012-12-11 03:24:34 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-11 03:24:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-11 03:24:34 - SRCCONF=/dev/null TB --- 2012-12-11 03:24:34 - TARGET=arm TB --- 2012-12-11 03:24:34 - TARGET_ARCH=arm TB --- 2012-12-11 03:24:34 - TZ=UTC TB --- 2012-12-11 03:24:34 - __MAKE_CONF=/dev/null TB --- 2012-12-11 03:24:34 - cd /src TB --- 2012-12-11 03:24:34 - /usr/bin/make -B buildworld >>> World build started on Tue Dec 11 03:24:35 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] ===> bin/expr (all) cc -O -pipe -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c expr.c cc1: warnings being treated as errors /src/bin/expr/expr.y: In function 'main': /src/bin/expr/expr.y:291: warning: implicit declaration of function 'yyparse' /src/bin/expr/expr.y:291: warning: nested extern declaration of 'yyparse' expr.c: At top level: expr.c:813: warning: no previous prototype for 'yyparse' *** Error code 1 Stop in /src/bin/expr. *** Error code 1 Stop in /src/bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-12-11 03:57:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-12-11 03:57:29 - ERROR: failed to build world TB --- 2012-12-11 03:57:29 - 1497.01 user 348.71 system 2021.38 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Tue Dec 11 07:54:36 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 91F58478; Tue, 11 Dec 2012 07:54:36 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 558CF8FC13; Tue, 11 Dec 2012 07:54:36 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id qBB7sZ9W016312; Tue, 11 Dec 2012 02:54:35 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qBB7sZSL016311; Tue, 11 Dec 2012 07:54:35 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 11 Dec 2012 07:54:35 GMT Message-Id: <201212110754.qBB7sZSL016311@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 07:54:36 -0000 TB --- 2012-12-11 06:40:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-12-11 06:40:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-12-11 06:40:00 - starting HEAD tinderbox run for arm/arm TB --- 2012-12-11 06:40:00 - cleaning the object tree TB --- 2012-12-11 06:40:00 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-12-11 06:40:00 - cd /tinderbox/HEAD/arm/arm TB --- 2012-12-11 06:40:00 - /usr/local/bin/svn cleanup /src TB --- 2012-12-11 06:44:22 - /usr/local/bin/svn update /src TB --- 2012-12-11 06:44:33 - At svn revision 244111 TB --- 2012-12-11 06:44:34 - building world TB --- 2012-12-11 06:44:34 - CROSS_BUILD_TESTING=YES TB --- 2012-12-11 06:44:34 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-11 06:44:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-11 06:44:34 - SRCCONF=/dev/null TB --- 2012-12-11 06:44:34 - TARGET=arm TB --- 2012-12-11 06:44:34 - TARGET_ARCH=arm TB --- 2012-12-11 06:44:34 - TZ=UTC TB --- 2012-12-11 06:44:34 - __MAKE_CONF=/dev/null TB --- 2012-12-11 06:44:34 - cd /src TB --- 2012-12-11 06:44:34 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Dec 11 06:44:42 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Dec 11 07:44:11 UTC 2012 TB --- 2012-12-11 07:44:11 - generating LINT kernel config TB --- 2012-12-11 07:44:11 - cd /src/sys/arm/conf TB --- 2012-12-11 07:44:11 - /usr/bin/make -B LINT TB --- 2012-12-11 07:44:11 - cd /src/sys/arm/conf TB --- 2012-12-11 07:44:11 - /usr/sbin/config -m LINT TB --- 2012-12-11 07:44:11 - building LINT kernel TB --- 2012-12-11 07:44:11 - CROSS_BUILD_TESTING=YES TB --- 2012-12-11 07:44:11 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-11 07:44:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-11 07:44:11 - SRCCONF=/dev/null TB --- 2012-12-11 07:44:11 - TARGET=arm TB --- 2012-12-11 07:44:11 - TARGET_ARCH=arm TB --- 2012-12-11 07:44:11 - TZ=UTC TB --- 2012-12-11 07:44:11 - __MAKE_CONF=/dev/null TB --- 2012-12-11 07:44:11 - cd /src TB --- 2012-12-11 07:44:11 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Dec 11 07:44:12 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -ffreestanding -Werror /src/sys/kern/subr_turnstile.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -ffreestanding -Werror /src/sys/kern/subr_uio.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -ffreestanding -Werror /src/sys/kern/subr_unit.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -ffreestanding -Werror /src/sys/kern/subr_witness.c cc1: warnings being treated as errors /src/sys/kern/subr_witness.c: In function 'witness_unlock': /src/sys/kern/subr_witness.c:1517: warning: 'instance' may be used uninitialized in this function /src/sys/kern/subr_witness.c:1521: warning: 'i' may be used uninitialized in this function *** [subr_witness.o] Error code 1 Stop in /obj/arm.arm/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-12-11 07:54:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-12-11 07:54:35 - ERROR: failed to build LINT kernel TB --- 2012-12-11 07:54:35 - 3085.66 user 624.03 system 4474.44 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Tue Dec 11 13:45:45 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7F7AF5AA for ; Tue, 11 Dec 2012 13:45:45 +0000 (UTC) (envelope-from matthieu.kraus@s2008.tu-chemnitz.de) Received: from cora.hrz.tu-chemnitz.de (cora.hrz.tu-chemnitz.de [134.109.228.40]) by mx1.freebsd.org (Postfix) with ESMTP id 1E2048FC08 for ; Tue, 11 Dec 2012 13:45:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tu-chemnitz.de; s=dkim2010; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:To:From:Date:Message-ID; bh=gADm1iicvWspwt5FzLZGCX3GQi/ULjCQgy/+ghhCEXY=; b=A5BJKZgqStgjzJ2K0esKipuxY7iRus7uMkiiTFrlKpt5S/GLbBR9oywHyQDBTaJfYq4B67c/a3q4x0kkAkCdavpdkcF4W/+9B+/SPZ80t/jECg0RbrsWvSrBbOJvo2xIM/6TsbWbheWp3B5ZMDD+TENCJQQ5RbDH3n1KMzC2Pl4=; Received: from postman.hrz.tu-chemnitz.de ([134.109.133.5] helo=mailbox.hrz.tu-chemnitz.de) by cora.hrz.tu-chemnitz.de with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TiQ9Q-0002ft-Qz for freebsd-arm@freebsd.org; Tue, 11 Dec 2012 14:45:37 +0100 Received: from woogie.hrz.tu-chemnitz.de ([134.109.133.13] helo=localhost) by mailbox.hrz.tu-chemnitz.de with esmtp (Exim 4.80.1) (envelope-from ) id 1TiQ9Q-0000g9-Lm for freebsd-arm@freebsd.org; Tue, 11 Dec 2012 14:45:36 +0100 Received: from 77-64-176-181.dynamic.primacom.net (77-64-176-181.dynamic.primacom.net [77.64.176.181]) by mail.tu-chemnitz.de (Horde Framework) with HTTP; Tue, 11 Dec 2012 14:45:36 +0100 Message-ID: <20121211144536.70434wqonm247mdc@mail.tu-chemnitz.de> Date: Tue, 11 Dec 2012 14:45:36 +0100 From: Matthieu Kraus To: freebsd-arm@freebsd.org Subject: interrupt storm on Dreamplug for interrupts 12 and 16 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_wtrtszsquj48c" Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.9) X-Originating-IP: 77.64.176.181 X-Scan-AV: mailbox.hrz.tu-chemnitz.de; 2012-12-11 14:45:36; df67489e3438dc5d9cda227f662ebe83 X-purgate: clean X-purgate-type: clean X-purgate-ID: 154106::1355233536-00000CD1-6CFCD595/0-0/0-0 X-Scan-SA: cora.hrz.tu-chemnitz.de; 2012-12-11 14:45:37; 3e41f3ff31ba32d63e208af7985fa9c8 X-Spam-Score: -1.0 (-) X-Spam-Report: --- Textanalyse SpamAssassin 3.3.1 (-1.0 Punkte) Fragen an/questions to: Postmaster TU Chemnitz * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain --- Ende Textanalyse X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 13:45:45 -0000 This message is in MIME format. --=_wtrtszsquj48c Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit Greetings, I tried updating my kernel on my Dreamplug yesterday (been running r228127 so far which worked quite well), however I'm running into issues with the ethernet controllers after the update - namely I'm constantly getting interrupt storms on interrupts 12 and 16 which belong to mge0 and mge1 respecively rendering non-functional. does anyone have some pointers what may cause it? the diff I'm running with (old kernel used the same besides the USB option to fix the CAM issues) is attached: the patch for if_mge is pretty old and grabbed from this ML and helps against some awful watchdog timeouts I encountered very often, the one for cpuvar.h allows to build zfs (I have an external RAID controller attached via esata on which my zfs pool resides) the dts is mostly based off an ultimate-rd one with some adjustments based off the settings linux uses --=_wtrtszsquj48c Content-Type: text/x-patch; charset=ISO-8859-1; name="kernel.diff" Content-Disposition: attachment; filename="kernel.diff" Content-Transfer-Encoding: 7bit Index: sys/arm/conf/DREAMPLUG =================================================================== --- sys/arm/conf/DREAMPLUG (revision 0) +++ sys/arm/conf/DREAMPLUG (working copy) @@ -0,0 +1,141 @@ +# +# Custom kernel for GlobalScale Technologies Dreamplug (Kirkwood 88F6281). +# +# $FreeBSD: src/sys/arm/conf/DREAMPLUG,v 1.00 2011/11/17 11:49:30 rmacklem Exp $ +# + +ident DREAMPLUG +include "../mv/kirkwood/std.db88f6xxx" + +options SOC_MV_KIRKWOOD +makeoptions MODULES_OVERRIDE="zfs opensolaris zlib" + +#makeoptions DEBUG=-g +#makeoptions WERROR="-Werror" + +# Debugging +#options KDB +#options DDB + +# SCHEDULER +options SCHED_4BSD + +# InterNETworking +options INET +options INET6 + +# Filesystems +options FFS # Berkeley Fast Filesystem +options CD9660 # ISO 9660 Filesystem +options MSDOSFS +options PSEUDOFS + +# NFS +options NFSCL +options NFSD +options NFSLOCKD +options NFS_ROOT + +options ROOTDEVNAME=\"ufs:/dev/da1s3a\" + +# core options +options SYSVSHM #SYSV-style shared memory +options SYSVMSG #SYSV-style message queues +options SYSVSEM #SYSV-style semaphores +options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time extensions +options MUTEX_NOINLINE +options RWLOCK_NOINLINE +options NO_FFS_SNAPSHOT +options NO_SWAPPING + +# Pseudo devices +device loop +device md +device pty +device random +device firmware + +# PCI +device pci + +# I2C (TWSI) +device iic +device iicbus + +# crypto devices +#device cesa # Marvell security engine +device crypto +device cryptodev + +# Serial ports +device uart + +# Networking +device ether +device mii +device miibus +device mge # Marvell Gigabit Ethernet controller +device e1000phy +device bpf + +# Sound +device sound + +# USB +#options USB_DEBUG +device usb +option USB_HOST_ALIGN=32 # data cache line size on your platform +device ehci +device umass +device usfs +device cdce +device uhid +device snd_uaudio + +# CAM/SCSI +# options CAMDEBUG +device scbus +device da + +# SATA +device mvs +device ahci +device ada + +# MMC/SD +device mmc +device mmcsd +#device mv_sdio + +# WLAN +#device wlan # 802.11 support +#device wlan_wep # 802.11 WEP support +#device wlan_ccmp # 802.11 CCMP support +#device wlan_tkip # 802.11 TKIP support + +# Flattened Device Tree +options FDT +options FDT_DTB_STATIC +makeoptions FDT_DTS_FILE=dreamplug.dts + +# PF +device pf +device pflog + +# ALTQ +options ALTQ +options ALTQ_CBQ # Class Bases Queuing (CBQ) +options ALTQ_RED # Random Early Detection (RED) +options ALTQ_RIO # RED In/Out +options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC) +options ALTQ_PRIQ # Priority Queuing (PRIQ) + +# IPSEC +#options IPSEC +#options IPSEC_NAT_T + +# GEOM +options GEOM_PART_GPT +options GEOM_LABEL +options GEOM_ELI + Index: sys/boot/fdt/dts/dreamplug.dts =================================================================== --- sys/boot/fdt/dts/dreamplug.dts (revision 0) +++ sys/boot/fdt/dts/dreamplug.dts (working copy) @@ -0,0 +1,351 @@ +/* + * Copyright (c) 2010 The FreeBSD Foundation + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * Marvell DreamPlug Device Tree Source. + * + * $FreeBSD: head/sys/boot/fdt/dts/dreamplug.dts,v 1.1 2010/05/26 09:50:09 raj Exp $ + */ + +/dts-v1/; + +/ { + model = "mrvl,DreamPlug"; + compatible = "DreamPlug"; + #address-cells = <1>; + #size-cells = <1>; + + aliases { + ethernet0 = &enet0; + ethernet1 = &enet1; + mpp = &MPP; + serial0 = &serial0; + serial1 = &serial1; + soc = &SOC; + sram = &SRAM; + }; + + cpus { + #address-cells = <1>; + #size-cells = <0>; + + cpu@0 { + device_type = "cpu"; + compatible = "ARM,88FR131"; + reg = <0x0>; + d-cache-line-size = <32>; // 32 bytes + i-cache-line-size = <32>; // 32 bytes + d-cache-size = <0x4000>; // L1, 16K + i-cache-size = <0x4000>; // L1, 16K + timebase-frequency = <0>; + bus-frequency = <0>; + clock-frequency = <0>; + }; + }; + + memory { + device_type = "memory"; + reg = <0x0 0x20000000>; // 512M at 0x0 + }; + + localbus@f1000000 { + #address-cells = <2>; + #size-cells = <1>; + compatible = "mrvl,lbc"; + + /* This reflects CPU decode windows setup. */ + ranges = <0x0 0x0f 0xf9300000 0x00100000 + 0x1 0x1e 0xfa000000 0x00100000 + 0x2 0x1d 0xfa100000 0x02000000 + 0x3 0x1b 0xfc100000 0x00000400>; + + nor@0,0 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "cfi-flash"; + reg = <0x0 0x0 0x00100000>; + bank-width = <2>; + device-width = <1>; + }; + + led@1,0 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "led"; + reg = <0x1 0x0 0x00100000>; + }; + + nor@2,0 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "cfi-flash"; + reg = <0x2 0x0 0x02000000>; + bank-width = <2>; + device-width = <1>; + }; + + nand@3,0 { + #address-cells = <1>; + #size-cells = <1>; + reg = <0x3 0x0 0x00100000>; + bank-width = <2>; + device-width = <1>; + }; + }; + + SOC: soc88f6281@f1000000 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "simple-bus"; + ranges = <0x0 0xf1000000 0x00100000>; + bus-frequency = <0>; + + PIC: pic@20200 { + interrupt-controller; + #address-cells = <0>; + #interrupt-cells = <1>; + reg = <0x20200 0x3c>; + compatible = "mrvl,pic"; + }; + + timer@20300 { + compatible = "mrvl,timer"; + reg = <0x20300 0x30>; + interrupts = <1>; + interrupt-parent = <&PIC>; + mrvl,has-wdt; + }; + + MPP: mpp@10000 { + #pin-cells = <2>; + compatible = "mrvl,mpp"; + reg = <0x10000 0x34>; + pin-count = <50>; + pin-map = < + 0 1 /* MPP[0]: NF_IO[2] */ + 1 1 /* MPP[1]: NF_IO[3] */ + 2 1 /* MPP[2]: NF_IO[4] */ + 3 1 /* MPP[3]: NF_IO[5] */ + 4 5 /* MPP[4]: SATA1_ACTn */ + 5 5 /* MPP[5]: SATA0_ACTn */ + 6 1 /* MPP[6]: SYSRST_OUTn */ + 7 0 /* MPP[7]: GPO */ + 8 5 /* MPP[8]: SATA1_PRESENTn */ + 9 5 /* MPP[9]: SATA0_PRESENTn */ + 10 3 /* MPP[10]: UA0_TXD */ + 11 3 /* MPP[11]: UA0_RXD */ + 12 1 /* MPP[12]: SD_CLK */ + 13 1 /* MPP[13]: SD_CMD */ + 14 1 /* MPP[14]: SD_D[0] */ + 15 1 /* MPP[15]: SD_D[1] */ + 16 1 /* MPP[16]: SD_D[2] */ + 17 1 /* MPP[17]: SD_D[3] */ + 18 1 /* MPP[18]: NF_IO[0] */ + 19 1 /* MPP[19]: NF_IO[1] */ + 20 3 /* MPP[20]: GE1_TXD[0] */ + 21 3 /* MPP[21]: GE1_TXD[1] */ + 22 3 /* MPP[22]: GE1_TXD[2] */ + 23 3 /* MPP[23]: GE1_TXD[3] */ + 24 3 /* MPP[24]: GE1_RXD[0] */ + 25 3 /* MPP[25]: GE1_RXD[1] */ + 26 3 /* MPP[26]: GE1_RXD[2] */ + 27 3 /* MPP[27]: GE1_RXD[3] */ + 28 3 /* MPP[28]: GE1_COL */ + 29 3 /* MPP[29]: GE1_TCLK */ + 30 3 /* MPP[30]: GE1_RXCTL */ + 31 3 /* MPP[31]: GE1_RXCLK */ + 32 3 /* MPP[32]: GE1_TCLKOUT */ + 33 3 /* MPP[33]: GE1_TXCTL */ + 34 3 /* MPP[34]: GE1_TXEN */ + 35 3 /* MPP[35]: GE1_RXERR */ + 36 4 /* MPP[36]: SPDIF_I */ + 37 4 /* MPP[37]: SPDIF_O */ + 38 4 /* MPP[38]: SPDIF_RMCLK */ + 46 0 /* MPP[46]: GPIO[46] */ /* M_RLED */ + 47 0 /* MPP[46]: GPIO[46] */ /* M_GLED */ + 48 0 /* MPP[46]: GPIO[46] */ /* B_RLED */ + 49 0 >; /* MPP[46]: GPIO[46] */ /* B_GLED */ + }; + + GPIO: gpio@10100 { + #gpio-cells = <3>; + compatible = "mrvl,gpio"; + reg = <0x10100 0x20>; + gpio-controller; + interrupts = <35 36 37 38 39 40 41>; + interrupt-parent = <&PIC>; + }; + + /*dreamplug:red:health { + compatible = "gpio-led"; + gpios = <&gpio 46 2 1>; + }; + + dreamplug:green:health { + compatible = "gpio-led"; + gpios = <&gpio 47 2 1>; + }; + + dreamplug:red:wmode { + compatible = "gpio-led"; + gpios = <&gpio 48 2 1>; + }; + + dreamplug:green:wmode { + compatible = "gpio-led"; + gpios = <&gpio 49 2 1>; + };*/ + + rtc@10300 { + compatible = "mrvl,rtc"; + reg = <0x10300 0x08>; + }; + + twsi@11000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "mrvl,twsi"; + reg = <0x11000 0x20>; + interrupts = <43>; + interrupt-parent = <&PIC>; + }; + + mdio0: mdio@72000 { + device_type = "mdio"; + compatible = "mrvl,mdio"; + reg = <0x72000 0x20>; + #address-cells = <1>; + #size-cells = <0>; + + phy0: ethernet-phy@0 { + reg = <0>; + device_type = "ethernet-phy"; + }; + }; + + mdio1: mdio@76000 { + device_type = "mdio"; + compatible = "mrvl,mdio"; + reg = <0x76000 0x20>; + #address-cells = <1>; + #size-cells = <0>; + + phy1: ethernet-phy@0 { + reg = <1>; + device_type = "ethernet-phy"; + }; + }; + + enet0: ethernet@72000 { + #address-cells = <1>; + #size-cells = <1>; + model = "V2"; + compatible = "mrvl,ge"; + reg = <0x72000 0x2000>; + ranges = <0x0 0x72000 0x2000>; + local-mac-address = [ 00 00 00 00 00 00 ]; + interrupts = <12 13 14 11 46>; + interrupt-parent = <&PIC>; + phy-handle = <&phy0>; + }; + + enet1: ethernet@76000 { + #address-cells = <1>; + #size-cells = <1>; + model = "V2"; + compatible = "mrvl,ge"; + reg = <0x76000 0x2000>; + ranges = <0x0 0x76000 0x2000>; + local-mac-address = [ 00 00 00 00 00 00 ]; + interrupts = <16 17 18 15 47>; + interrupt-parent = <&PIC>; + phy-handle = <&phy1>; + }; + + serial0: serial@12000 { + compatible = "ns16550"; + reg = <0x12000 0x20>; + reg-shift = <2>; + clock-frequency = <0>; + interrupts = <33>; + interrupt-parent = <&PIC>; + }; + + serial1: serial@12100 { + compatible = "ns16550"; + reg = <0x12100 0x20>; + reg-shift = <2>; + clock-frequency = <0>; + interrupts = <34>; + interrupt-parent = <&PIC>; + }; + + crypto@30000 { + compatible = "mrvl,cesa"; + reg = <0x30000 0x10000>; + interrupts = <22>; + interrupt-parent = <&PIC>; + + sram-handle = <&SRAM>; + }; + + usb@50000 { + compatible = "mrvl,usb-ehci", "usb-ehci"; + reg = <0x50000 0x1000>; + interrupts = <48 19>; + interrupt-parent = <&PIC>; + }; + + xor@60000 { + compatible = "mrvl,xor"; + reg = <0x60000 0x1000>; + interrupts = <5 6 7 8>; + interrupt-parent = <&PIC>; + }; + + sata@80000 { + compatible = "mrvl,sata"; + reg = <0x80000 0x6000>; + interrupts = <21>; + interrupt-parent = <&PIC>; + }; + + sdio@90000 { + compatible = "mrvl,sdio"; + reg = <0x90000 0x400>; + interrupts = <28>; + interrupt-parent = <&PIC>; + }; + }; + + SRAM: sram@fd000000 { + compatible = "mrvl,cesa-sram"; + reg = <0xfd000000 0x00100000>; + }; + + chosen { + stdin = "serial0"; + stdout = "serial0"; + }; +}; Index: sys/cddl/compat/opensolaris/sys/cpuvar.h =================================================================== --- sys/cddl/compat/opensolaris/sys/cpuvar.h (revision 244033) +++ sys/cddl/compat/opensolaris/sys/cpuvar.h (working copy) @@ -50,6 +50,9 @@ /* Some code may choose to redefine this if pcpu_t would be more useful. */ #define cpu_t solaris_cpu_t +#ifdef cpu_id +#undef cpu_id +#endif #define cpu_id cpuid extern solaris_cpu_t solaris_cpu[]; Index: sys/dev/mge/if_mge.c =================================================================== --- sys/dev/mge/if_mge.c (revision 244033) +++ sys/dev/mge/if_mge.c (working copy) @@ -962,7 +962,7 @@ reg_val = MGE_READ(sc, MGE_PORT_SERIAL_CTRL); reg_val |= PORT_SERIAL_ENABLE; MGE_WRITE(sc, MGE_PORT_SERIAL_CTRL, reg_val); - count = 0x100000; + count = 0x10; for (;;) { reg_val = MGE_READ(sc, MGE_PORT_STATUS); if (reg_val & MGE_STATUS_LINKUP) @@ -1540,7 +1540,7 @@ MGE_TRANSMIT_LOCK_ASSERT(sc); if ((ifp->if_drv_flags & (IFF_DRV_RUNNING | IFF_DRV_OACTIVE)) != - IFF_DRV_RUNNING) + IFF_DRV_RUNNING || IFM_SUBTYPE(sc->mii->mii_media_active) == IFM_NONE) return; for (;;) { --=_wtrtszsquj48c-- From owner-freebsd-arm@FreeBSD.ORG Tue Dec 11 14:02:57 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C5E0AACA for ; Tue, 11 Dec 2012 14:02:57 +0000 (UTC) (envelope-from matthieu.kraus@s2008.tu-chemnitz.de) Received: from nick.hrz.tu-chemnitz.de (nick.hrz.tu-chemnitz.de [134.109.228.11]) by mx1.freebsd.org (Postfix) with ESMTP id 5C76E8FC12 for ; Tue, 11 Dec 2012 14:02:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tu-chemnitz.de; s=dkim2010; h=Content-Transfer-Encoding:Content-Type:MIME-Version:In-Reply-To:References:Subject:To:From:Date:Message-ID; bh=iMmcHEk2JN8J6u8HF54Gl6/qvUAMnWn7MEpVw+tBvgU=; b=WogY1HqSA20Raw86LXkh3RjUk4WUWJIGDt3iLl9gDSSPYp5zOhTIUtbff95uBjm+2qikg7WhkD1sgHVRa9fFCg2Lt33+raimZvLJ7VswlKNzhFhGrudpjmi9vUYqLhuJ7uDlt/XZsxSCo/7ywgIlBXPqvtFLUK/NlxKBg+jId24=; Received: from pat.hrz.tu-chemnitz.de ([134.109.133.4] helo=mailbox.hrz.tu-chemnitz.de) by nick.hrz.tu-chemnitz.de with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TiQAQ-0006QW-65 for freebsd-arm@freebsd.org; Tue, 11 Dec 2012 14:46:39 +0100 Received: from woogie.hrz.tu-chemnitz.de ([134.109.133.13] helo=localhost) by mailbox.hrz.tu-chemnitz.de with esmtp (Exim 4.80.1) (envelope-from ) id 1TiQAQ-0001CA-2M for freebsd-arm@freebsd.org; Tue, 11 Dec 2012 14:46:38 +0100 Received: from 77-64-176-181.dynamic.primacom.net (77-64-176-181.dynamic.primacom.net [77.64.176.181]) by mail.tu-chemnitz.de (Horde Framework) with HTTP; Tue, 11 Dec 2012 14:46:38 +0100 Message-ID: <20121211144638.18080b0r14oemczi@mail.tu-chemnitz.de> Date: Tue, 11 Dec 2012 14:46:38 +0100 From: Matthieu Kraus To: freebsd-arm@freebsd.org Subject: Re: interrupt storm on Dreamplug for interrupts 12 and 16 References: <20121211144536.70434wqonm247mdc@mail.tu-chemnitz.de> In-Reply-To: <20121211144536.70434wqonm247mdc@mail.tu-chemnitz.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_12ijyrb7jivgw" Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.9) X-Originating-IP: 77.64.176.181 X-Scan-AV: mailbox.hrz.tu-chemnitz.de; 2012-12-11 14:46:38; b33e40b53e0a49a4ce34c419f00b17ad X-purgate: clean X-purgate-type: clean X-purgate-ID: 154106::1355233598-00005597-3154ED8A/0-0/0-0 X-Scan-SA: nick.hrz.tu-chemnitz.de; 2012-12-11 14:46:39; f89b67c314c0eca5236d868802640c74 X-Spam-Score: -1.0 (-) X-Spam-Report: --- Textanalyse SpamAssassin 3.3.1 (-1.0 Punkte) Fragen an/questions to: Postmaster TU Chemnitz * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain --- Ende Textanalyse X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 14:02:57 -0000 This message is in MIME format. --=_12ijyrb7jivgw Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit sorry, forgot the attachment --=_12ijyrb7jivgw Content-Type: text/x-patch; charset=ISO-8859-1; name="kernel.diff" Content-Disposition: attachment; filename="kernel.diff" Content-Transfer-Encoding: 7bit Index: sys/arm/conf/DREAMPLUG =================================================================== --- sys/arm/conf/DREAMPLUG (revision 0) +++ sys/arm/conf/DREAMPLUG (working copy) @@ -0,0 +1,141 @@ +# +# Custom kernel for GlobalScale Technologies Dreamplug (Kirkwood 88F6281). +# +# $FreeBSD: src/sys/arm/conf/DREAMPLUG,v 1.00 2011/11/17 11:49:30 rmacklem Exp $ +# + +ident DREAMPLUG +include "../mv/kirkwood/std.db88f6xxx" + +options SOC_MV_KIRKWOOD +makeoptions MODULES_OVERRIDE="zfs opensolaris zlib" + +#makeoptions DEBUG=-g +#makeoptions WERROR="-Werror" + +# Debugging +#options KDB +#options DDB + +# SCHEDULER +options SCHED_4BSD + +# InterNETworking +options INET +options INET6 + +# Filesystems +options FFS # Berkeley Fast Filesystem +options CD9660 # ISO 9660 Filesystem +options MSDOSFS +options PSEUDOFS + +# NFS +options NFSCL +options NFSD +options NFSLOCKD +options NFS_ROOT + +options ROOTDEVNAME=\"ufs:/dev/da1s3a\" + +# core options +options SYSVSHM #SYSV-style shared memory +options SYSVMSG #SYSV-style message queues +options SYSVSEM #SYSV-style semaphores +options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time extensions +options MUTEX_NOINLINE +options RWLOCK_NOINLINE +options NO_FFS_SNAPSHOT +options NO_SWAPPING + +# Pseudo devices +device loop +device md +device pty +device random +device firmware + +# PCI +device pci + +# I2C (TWSI) +device iic +device iicbus + +# crypto devices +#device cesa # Marvell security engine +device crypto +device cryptodev + +# Serial ports +device uart + +# Networking +device ether +device mii +device miibus +device mge # Marvell Gigabit Ethernet controller +device e1000phy +device bpf + +# Sound +device sound + +# USB +#options USB_DEBUG +device usb +option USB_HOST_ALIGN=32 # data cache line size on your platform +device ehci +device umass +device usfs +device cdce +device uhid +device snd_uaudio + +# CAM/SCSI +# options CAMDEBUG +device scbus +device da + +# SATA +device mvs +device ahci +device ada + +# MMC/SD +device mmc +device mmcsd +#device mv_sdio + +# WLAN +#device wlan # 802.11 support +#device wlan_wep # 802.11 WEP support +#device wlan_ccmp # 802.11 CCMP support +#device wlan_tkip # 802.11 TKIP support + +# Flattened Device Tree +options FDT +options FDT_DTB_STATIC +makeoptions FDT_DTS_FILE=dreamplug.dts + +# PF +device pf +device pflog + +# ALTQ +options ALTQ +options ALTQ_CBQ # Class Bases Queuing (CBQ) +options ALTQ_RED # Random Early Detection (RED) +options ALTQ_RIO # RED In/Out +options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC) +options ALTQ_PRIQ # Priority Queuing (PRIQ) + +# IPSEC +#options IPSEC +#options IPSEC_NAT_T + +# GEOM +options GEOM_PART_GPT +options GEOM_LABEL +options GEOM_ELI + Index: sys/boot/fdt/dts/dreamplug.dts =================================================================== --- sys/boot/fdt/dts/dreamplug.dts (revision 0) +++ sys/boot/fdt/dts/dreamplug.dts (working copy) @@ -0,0 +1,351 @@ +/* + * Copyright (c) 2010 The FreeBSD Foundation + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * Marvell DreamPlug Device Tree Source. + * + * $FreeBSD: head/sys/boot/fdt/dts/dreamplug.dts,v 1.1 2010/05/26 09:50:09 raj Exp $ + */ + +/dts-v1/; + +/ { + model = "mrvl,DreamPlug"; + compatible = "DreamPlug"; + #address-cells = <1>; + #size-cells = <1>; + + aliases { + ethernet0 = &enet0; + ethernet1 = &enet1; + mpp = &MPP; + serial0 = &serial0; + serial1 = &serial1; + soc = &SOC; + sram = &SRAM; + }; + + cpus { + #address-cells = <1>; + #size-cells = <0>; + + cpu@0 { + device_type = "cpu"; + compatible = "ARM,88FR131"; + reg = <0x0>; + d-cache-line-size = <32>; // 32 bytes + i-cache-line-size = <32>; // 32 bytes + d-cache-size = <0x4000>; // L1, 16K + i-cache-size = <0x4000>; // L1, 16K + timebase-frequency = <0>; + bus-frequency = <0>; + clock-frequency = <0>; + }; + }; + + memory { + device_type = "memory"; + reg = <0x0 0x20000000>; // 512M at 0x0 + }; + + localbus@f1000000 { + #address-cells = <2>; + #size-cells = <1>; + compatible = "mrvl,lbc"; + + /* This reflects CPU decode windows setup. */ + ranges = <0x0 0x0f 0xf9300000 0x00100000 + 0x1 0x1e 0xfa000000 0x00100000 + 0x2 0x1d 0xfa100000 0x02000000 + 0x3 0x1b 0xfc100000 0x00000400>; + + nor@0,0 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "cfi-flash"; + reg = <0x0 0x0 0x00100000>; + bank-width = <2>; + device-width = <1>; + }; + + led@1,0 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "led"; + reg = <0x1 0x0 0x00100000>; + }; + + nor@2,0 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "cfi-flash"; + reg = <0x2 0x0 0x02000000>; + bank-width = <2>; + device-width = <1>; + }; + + nand@3,0 { + #address-cells = <1>; + #size-cells = <1>; + reg = <0x3 0x0 0x00100000>; + bank-width = <2>; + device-width = <1>; + }; + }; + + SOC: soc88f6281@f1000000 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "simple-bus"; + ranges = <0x0 0xf1000000 0x00100000>; + bus-frequency = <0>; + + PIC: pic@20200 { + interrupt-controller; + #address-cells = <0>; + #interrupt-cells = <1>; + reg = <0x20200 0x3c>; + compatible = "mrvl,pic"; + }; + + timer@20300 { + compatible = "mrvl,timer"; + reg = <0x20300 0x30>; + interrupts = <1>; + interrupt-parent = <&PIC>; + mrvl,has-wdt; + }; + + MPP: mpp@10000 { + #pin-cells = <2>; + compatible = "mrvl,mpp"; + reg = <0x10000 0x34>; + pin-count = <50>; + pin-map = < + 0 1 /* MPP[0]: NF_IO[2] */ + 1 1 /* MPP[1]: NF_IO[3] */ + 2 1 /* MPP[2]: NF_IO[4] */ + 3 1 /* MPP[3]: NF_IO[5] */ + 4 5 /* MPP[4]: SATA1_ACTn */ + 5 5 /* MPP[5]: SATA0_ACTn */ + 6 1 /* MPP[6]: SYSRST_OUTn */ + 7 0 /* MPP[7]: GPO */ + 8 5 /* MPP[8]: SATA1_PRESENTn */ + 9 5 /* MPP[9]: SATA0_PRESENTn */ + 10 3 /* MPP[10]: UA0_TXD */ + 11 3 /* MPP[11]: UA0_RXD */ + 12 1 /* MPP[12]: SD_CLK */ + 13 1 /* MPP[13]: SD_CMD */ + 14 1 /* MPP[14]: SD_D[0] */ + 15 1 /* MPP[15]: SD_D[1] */ + 16 1 /* MPP[16]: SD_D[2] */ + 17 1 /* MPP[17]: SD_D[3] */ + 18 1 /* MPP[18]: NF_IO[0] */ + 19 1 /* MPP[19]: NF_IO[1] */ + 20 3 /* MPP[20]: GE1_TXD[0] */ + 21 3 /* MPP[21]: GE1_TXD[1] */ + 22 3 /* MPP[22]: GE1_TXD[2] */ + 23 3 /* MPP[23]: GE1_TXD[3] */ + 24 3 /* MPP[24]: GE1_RXD[0] */ + 25 3 /* MPP[25]: GE1_RXD[1] */ + 26 3 /* MPP[26]: GE1_RXD[2] */ + 27 3 /* MPP[27]: GE1_RXD[3] */ + 28 3 /* MPP[28]: GE1_COL */ + 29 3 /* MPP[29]: GE1_TCLK */ + 30 3 /* MPP[30]: GE1_RXCTL */ + 31 3 /* MPP[31]: GE1_RXCLK */ + 32 3 /* MPP[32]: GE1_TCLKOUT */ + 33 3 /* MPP[33]: GE1_TXCTL */ + 34 3 /* MPP[34]: GE1_TXEN */ + 35 3 /* MPP[35]: GE1_RXERR */ + 36 4 /* MPP[36]: SPDIF_I */ + 37 4 /* MPP[37]: SPDIF_O */ + 38 4 /* MPP[38]: SPDIF_RMCLK */ + 46 0 /* MPP[46]: GPIO[46] */ /* M_RLED */ + 47 0 /* MPP[46]: GPIO[46] */ /* M_GLED */ + 48 0 /* MPP[46]: GPIO[46] */ /* B_RLED */ + 49 0 >; /* MPP[46]: GPIO[46] */ /* B_GLED */ + }; + + GPIO: gpio@10100 { + #gpio-cells = <3>; + compatible = "mrvl,gpio"; + reg = <0x10100 0x20>; + gpio-controller; + interrupts = <35 36 37 38 39 40 41>; + interrupt-parent = <&PIC>; + }; + + /*dreamplug:red:health { + compatible = "gpio-led"; + gpios = <&gpio 46 2 1>; + }; + + dreamplug:green:health { + compatible = "gpio-led"; + gpios = <&gpio 47 2 1>; + }; + + dreamplug:red:wmode { + compatible = "gpio-led"; + gpios = <&gpio 48 2 1>; + }; + + dreamplug:green:wmode { + compatible = "gpio-led"; + gpios = <&gpio 49 2 1>; + };*/ + + rtc@10300 { + compatible = "mrvl,rtc"; + reg = <0x10300 0x08>; + }; + + twsi@11000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "mrvl,twsi"; + reg = <0x11000 0x20>; + interrupts = <43>; + interrupt-parent = <&PIC>; + }; + + mdio0: mdio@72000 { + device_type = "mdio"; + compatible = "mrvl,mdio"; + reg = <0x72000 0x20>; + #address-cells = <1>; + #size-cells = <0>; + + phy0: ethernet-phy@0 { + reg = <0>; + device_type = "ethernet-phy"; + }; + }; + + mdio1: mdio@76000 { + device_type = "mdio"; + compatible = "mrvl,mdio"; + reg = <0x76000 0x20>; + #address-cells = <1>; + #size-cells = <0>; + + phy1: ethernet-phy@0 { + reg = <1>; + device_type = "ethernet-phy"; + }; + }; + + enet0: ethernet@72000 { + #address-cells = <1>; + #size-cells = <1>; + model = "V2"; + compatible = "mrvl,ge"; + reg = <0x72000 0x2000>; + ranges = <0x0 0x72000 0x2000>; + local-mac-address = [ 00 00 00 00 00 00 ]; + interrupts = <12 13 14 11 46>; + interrupt-parent = <&PIC>; + phy-handle = <&phy0>; + }; + + enet1: ethernet@76000 { + #address-cells = <1>; + #size-cells = <1>; + model = "V2"; + compatible = "mrvl,ge"; + reg = <0x76000 0x2000>; + ranges = <0x0 0x76000 0x2000>; + local-mac-address = [ 00 00 00 00 00 00 ]; + interrupts = <16 17 18 15 47>; + interrupt-parent = <&PIC>; + phy-handle = <&phy1>; + }; + + serial0: serial@12000 { + compatible = "ns16550"; + reg = <0x12000 0x20>; + reg-shift = <2>; + clock-frequency = <0>; + interrupts = <33>; + interrupt-parent = <&PIC>; + }; + + serial1: serial@12100 { + compatible = "ns16550"; + reg = <0x12100 0x20>; + reg-shift = <2>; + clock-frequency = <0>; + interrupts = <34>; + interrupt-parent = <&PIC>; + }; + + crypto@30000 { + compatible = "mrvl,cesa"; + reg = <0x30000 0x10000>; + interrupts = <22>; + interrupt-parent = <&PIC>; + + sram-handle = <&SRAM>; + }; + + usb@50000 { + compatible = "mrvl,usb-ehci", "usb-ehci"; + reg = <0x50000 0x1000>; + interrupts = <48 19>; + interrupt-parent = <&PIC>; + }; + + xor@60000 { + compatible = "mrvl,xor"; + reg = <0x60000 0x1000>; + interrupts = <5 6 7 8>; + interrupt-parent = <&PIC>; + }; + + sata@80000 { + compatible = "mrvl,sata"; + reg = <0x80000 0x6000>; + interrupts = <21>; + interrupt-parent = <&PIC>; + }; + + sdio@90000 { + compatible = "mrvl,sdio"; + reg = <0x90000 0x400>; + interrupts = <28>; + interrupt-parent = <&PIC>; + }; + }; + + SRAM: sram@fd000000 { + compatible = "mrvl,cesa-sram"; + reg = <0xfd000000 0x00100000>; + }; + + chosen { + stdin = "serial0"; + stdout = "serial0"; + }; +}; Index: sys/cddl/compat/opensolaris/sys/cpuvar.h =================================================================== --- sys/cddl/compat/opensolaris/sys/cpuvar.h (revision 244033) +++ sys/cddl/compat/opensolaris/sys/cpuvar.h (working copy) @@ -50,6 +50,9 @@ /* Some code may choose to redefine this if pcpu_t would be more useful. */ #define cpu_t solaris_cpu_t +#ifdef cpu_id +#undef cpu_id +#endif #define cpu_id cpuid extern solaris_cpu_t solaris_cpu[]; Index: sys/dev/mge/if_mge.c =================================================================== --- sys/dev/mge/if_mge.c (revision 244033) +++ sys/dev/mge/if_mge.c (working copy) @@ -962,7 +962,7 @@ reg_val = MGE_READ(sc, MGE_PORT_SERIAL_CTRL); reg_val |= PORT_SERIAL_ENABLE; MGE_WRITE(sc, MGE_PORT_SERIAL_CTRL, reg_val); - count = 0x100000; + count = 0x10; for (;;) { reg_val = MGE_READ(sc, MGE_PORT_STATUS); if (reg_val & MGE_STATUS_LINKUP) @@ -1540,7 +1540,7 @@ MGE_TRANSMIT_LOCK_ASSERT(sc); if ((ifp->if_drv_flags & (IFF_DRV_RUNNING | IFF_DRV_OACTIVE)) != - IFF_DRV_RUNNING) + IFF_DRV_RUNNING || IFM_SUBTYPE(sc->mii->mii_media_active) == IFM_NONE) return; for (;;) { --=_12ijyrb7jivgw-- From owner-freebsd-arm@FreeBSD.ORG Tue Dec 11 18:25:42 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BA6836FB for ; Tue, 11 Dec 2012 18:25:42 +0000 (UTC) (envelope-from aoyama@peach.ne.jp) Received: from moon.peach.ne.jp (moon.peach.ne.jp [203.141.148.98]) by mx1.freebsd.org (Postfix) with ESMTP id 81D108FC15 for ; Tue, 11 Dec 2012 18:25:41 +0000 (UTC) Received: from moon.peach.ne.jp (localhost [127.0.0.1]) by moon.peach.ne.jp (Postfix) with ESMTP id B6A3239D49; Wed, 12 Dec 2012 03:25:34 +0900 (JST) Received: from artemis (unknown [172.18.0.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by moon.peach.ne.jp (Postfix) with ESMTPSA id A253B39D46; Wed, 12 Dec 2012 03:25:34 +0900 (JST) Message-ID: <3DE6764415F645FCA29CD18BA51762F8@ad.peach.ne.jp> From: "Daisuke Aoyama" To: "Andrew Turner" , References: <20121209160721.571186d8@fubar.geek.nz> In-Reply-To: <20121209160721.571186d8@fubar.geek.nz> Subject: Re: ARM EABI patch Date: Wed, 12 Dec 2012 03:25:31 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 X-Virus-Scanned: ClamAV using ClamSMTP X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 18:25:42 -0000 Hi, I found cross-build problem of the EABI patch. I'm trying to use it for Raspberry Pi. According to machine/_types.h, wchar_t is unsigned int when EABI. This patch solve "error: array of inappropriate type initialized from string constant" when use L"foo". --- contrib/gcc/config/arm/freebsd.h (revision 244112) +++ contrib/gcc/config/arm/freebsd.h (working copy) @@ -84,6 +110,9 @@ /* We use the GCC defaults here. */ #undef WCHAR_TYPE +#if defined(TARGET_ARM_EABI) || defined(__ARM_EABI__) +#define WCHAR_TYPE "unsigned int" +#endif #if defined(FREEBSD_ARCH_armv6) #undef SUBTARGET_CPU_DEFAULT Please check. Thank you. -- Daisuke Aoyama From owner-freebsd-arm@FreeBSD.ORG Tue Dec 11 18:43:07 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AFD0EC39 for ; Tue, 11 Dec 2012 18:43:07 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 753C48FC12 for ; Tue, 11 Dec 2012 18:43:07 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi5so3162978pad.13 for ; Tue, 11 Dec 2012 10:43:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:x-priority :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=X2pSJb3JniuxaFysXqICnMKeft8cVxPRKoqKD/JoN1Q=; b=i3pGzoZB7bf6cBAq6hFkMiXuSQH118QhJks/4d/1trwaHOr4Gw9+kX9TpAzW12kiXG Jv537rS2kG1mqH1hYnwApwqIYSFISKZ4fUwerXIvGmlmFqvfWYrvh6+CrV13QuDkjvrJ q1E5S4FFs3rluL42j3tHYCQAa4DZopToq948Yc/9f8x4YV+0DGqV7yQ2fC2lldmWUy2j qDhFU2UO9Ido5i49BEKqzF9E5B4Wxr15vE4mif8laMoK2QZyJfUwyYiNrVx4GSWZbqGd QCZvUIjzhSgGYIRDyMuTWypi+fBS/qwZmADCbYtyYEHzlcwl5hpjiHgY38g74eYKAL4i cIKQ== Received: by 10.66.80.8 with SMTP id n8mr47403086pax.40.1355251382889; Tue, 11 Dec 2012 10:43:02 -0800 (PST) Received: from [10.0.0.53] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id ou3sm7345309pbb.46.2012.12.11.10.43.00 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 11 Dec 2012 10:43:01 -0800 (PST) Sender: Warner Losh Subject: Re: ARM EABI patch Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh X-Priority: 3 In-Reply-To: <3DE6764415F645FCA29CD18BA51762F8@ad.peach.ne.jp> Date: Tue, 11 Dec 2012 11:42:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <33581130-C882-43EC-BA61-056CDE9DB514@bsdimp.com> References: <20121209160721.571186d8@fubar.geek.nz> <3DE6764415F645FCA29CD18BA51762F8@ad.peach.ne.jp> To: "Daisuke Aoyama" X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQlwq/xGkjIsUd7OavHc6kiNnQMFwk20j94/G9CrwYbVSSL1V4GIRPDMRYWiDd2ipByoDhHB Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 18:43:07 -0000 Is __ARM_EABI__ only defined when building an arm EABI TARGET? Or is it = defined always on an ARM EABI host? Warner On Dec 11, 2012, at 11:25 AM, Daisuke Aoyama wrote: > Hi, >=20 > I found cross-build problem of the EABI patch. I'm trying to use it = for > Raspberry Pi. > According to machine/_types.h, wchar_t is unsigned int when EABI. > This patch solve "error: array of inappropriate type initialized from = string > constant" when use L"foo". >=20 > --- contrib/gcc/config/arm/freebsd.h (revision 244112) > +++ contrib/gcc/config/arm/freebsd.h (working copy) > @@ -84,6 +110,9 @@ >=20 > /* We use the GCC defaults here. */ > #undef WCHAR_TYPE > +#if defined(TARGET_ARM_EABI) || defined(__ARM_EABI__) > +#define WCHAR_TYPE "unsigned int" > +#endif >=20 > #if defined(FREEBSD_ARCH_armv6) > #undef SUBTARGET_CPU_DEFAULT >=20 >=20 > Please check. > Thank you. > --=20 > Daisuke Aoyama >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Tue Dec 11 19:03:10 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 407C3D2 for ; Tue, 11 Dec 2012 19:03:10 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 5374D8FC0C for ; Tue, 11 Dec 2012 19:03:08 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qBBF1CST088868 for ; Tue, 11 Dec 2012 08:01:13 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qBBF19Dq055587; Tue, 11 Dec 2012 08:01:09 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: interrupt storm on Dreamplug for interrupts 12 and 16 From: Ian Lepore To: Matthieu Kraus In-Reply-To: <20121211144536.70434wqonm247mdc@mail.tu-chemnitz.de> References: <20121211144536.70434wqonm247mdc@mail.tu-chemnitz.de> Content-Type: multipart/mixed; boundary="=-e0TG0Hb/8sJDKnXmaIex" Date: Tue, 11 Dec 2012 08:01:08 -0700 Message-ID: <1355238068.87661.408.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 19:03:10 -0000 --=-e0TG0Hb/8sJDKnXmaIex Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Tue, 2012-12-11 at 14:45 +0100, Matthieu Kraus wrote: > Greetings, > > I tried updating my kernel on my Dreamplug yesterday (been running > r228127 so far which worked quite well), however I'm running into > issues with the ethernet controllers after the update - namely I'm > constantly getting interrupt storms on interrupts 12 and 16 which > belong to mge0 and mge1 respecively rendering non-functional. > > does anyone have some pointers what may cause it? > > the diff I'm running with (old kernel used the same besides the USB > option to fix the CAM issues) is attached: > > the patch for if_mge is pretty old and grabbed from this ML and helps > against some awful watchdog timeouts I encountered very often, the one > for cpuvar.h allows to build zfs (I have an external RAID controller > attached via esata on which my zfs pool resides) > > the dts is mostly based off an ultimate-rd one with some adjustments > based off the settings linux uses Here are the dts files I've been using for the NOR (1001) and NAND (1001N) models of dreamplug; they look a bit different than yours. Also, I've got no patches in the mge driver these days, but I do live with the fact that I have to have cables plugged into both ports or there are annoyingly-long timeouts trying to DHCP at boot time. In fact, the only patches I'm using for dreamplug are the attached dts, and personal kernel config choices, plus the one I posted about a week ago to leave the cache allocate-on-write feature set the way the bootloader set it. I'm currently running -current @r243920 on dreamplug. -- Ian --=-e0TG0Hb/8sJDKnXmaIex Content-Disposition: attachment; filename="dreamplug_dts.diff" Content-Type: text/x-patch; name="dreamplug_dts.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit diff -r b3c4270c3840 -r fc76ae13d76c sys/boot/fdt/dts/dreamplug-1001.dts --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ sys/boot/fdt/dts/dreamplug-1001.dts Sun Aug 19 11:01:08 2012 -0600 @@ -0,0 +1,318 @@ +/* + * Copyright (c) 2010 The FreeBSD Foundation + * All rights reserved. + * + * This software was developed by Semihalf under sponsorship from + * the FreeBSD Foundation. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * GlobalScale Technologies DreamPlug Device Tree Source. + * + * This source is for version 10 revision 01 units with NOR SPI flash. + * These units are marked "1001" on the serial number label. + * + * $FreeBSD$ + */ + +/dts-v1/; + +/ { + model = "GlobalScale Technologies Dreamplug v1001"; + compatible = "globalscale,dreamplug-003-ds2001", "globalscale,dreamplug", "marvell,kirkwood-88f6281", "marvell,kirkwood"; + #address-cells = <1>; + #size-cells = <1>; + + aliases { + ethernet0 = &enet0; + ethernet1 = &enet1; + mpp = &MPP; + serial0 = &serial0; + serial1 = &serial1; + soc = &SOC; + sram = &SRAM; + }; + + cpus { + #address-cells = <1>; + #size-cells = <0>; + + cpu@0 { + device_type = "cpu"; + compatible = "ARM,88FR131"; + reg = <0x0>; + d-cache-line-size = <32>; // 32 bytes + i-cache-line-size = <32>; // 32 bytes + d-cache-size = <0x4000>; // L1, 16K + i-cache-size = <0x4000>; // L1, 16K + timebase-frequency = <0>; + bus-frequency = <0>; + clock-frequency = <0>; + }; + + }; + + memory { + device_type = "memory"; + reg = <0x0 0x20000000>; // 512M at 0x0 + }; + + localbus@0 { + #address-cells = <2>; + #size-cells = <1>; + compatible = "mrvl,lbc"; + bank-count = <1>; + + /* This reflects CPU decode windows setup. */ + ranges = <0x0 0x1e 0xfa000000 0x00100000>; + + nor@0,0 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "cfi-flash"; + reg = <0x0 0x0 0x00100000>; + bank-width = <2>; + device-width = <1>; + }; + }; + + SOC: soc88f6281@f1000000 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "simple-bus"; + ranges = <0x0 0xf1000000 0x00100000>; + bus-frequency = <0>; + + PIC: pic@20200 { + interrupt-controller; + #address-cells = <0>; + #interrupt-cells = <1>; + reg = <0x20200 0x3c>; + compatible = "mrvl,pic"; + }; + + timer@20300 { + compatible = "mrvl,timer"; + reg = <0x20300 0x30>; + interrupts = <1>; + interrupt-parent = <&PIC>; + mrvl,has-wdt; + }; + + MPP: mpp@10000 { + #pin-cells = <2>; + compatible = "mrvl,mpp"; + reg = <0x10000 0x34>; + pin-count = <50>; + pin-map = < + 0 2 /* MPP[ 0]: SPI_SCn */ + 1 2 /* MPP[ 1]: SPI_MOSI */ + 2 2 /* MPP[ 2]: SPI_SCK */ + 3 2 /* MPP[ 3]: SPI_MISO */ + 4 1 /* MPP[ 4]: NF_IO[6] */ + 5 1 /* MPP[ 5]: NF_IO[7] */ + 6 1 /* MPP[ 6]: SYSRST_OUTn */ + 7 0 /* MPP[ 7]: GPO[7] */ + 8 1 /* MPP[ 8]: TW_SDA */ + 9 1 /* MPP[ 9]: TW_SCK */ + 10 3 /* MPP[10]: UA0_TXD */ + 11 3 /* MPP[11]: US0_RXD */ + 12 1 /* MPP[12]: SD_CLK */ + 13 1 /* MPP[13]: SD_CMD */ + 14 1 /* MPP[14]: SD_D[0] */ + 15 1 /* MPP[15]: SD_D[1] */ + 16 1 /* MPP[16]: SD_D[2] */ + 17 1 /* MPP[17]: SD_D[3] */ + 18 1 /* MPP[18]: NF_IO[0] */ + 19 1 /* MPP[19]: NF_IO[1] */ + 20 3 /* MPP[20]: GE1[ 0] */ + 21 3 /* MPP[21]: GE1[ 1] */ + 22 3 /* MPP[22]: GE1[ 2] */ + 23 3 /* MPP[23]: GE1[ 3] */ + 24 3 /* MPP[24]: GE1[ 4] */ + 25 3 /* MPP[25]: GE1[ 5] */ + 26 3 /* MPP[26]: GE1[ 6] */ + 27 3 /* MPP[27]: GE1[ 7] */ + 28 3 /* MPP[28]: GE1[ 8] */ + 29 3 /* MPP[29]: GE1[ 9] */ + 30 3 /* MPP[30]: GE1[10] */ + 31 3 /* MPP[31]: GE1[11] */ + 32 3 /* MPP[32]: GE1[12] */ + 33 3 /* MPP[33]: GE1[13] */ + 34 3 /* MPP[34]: GE1[14] */ + 35 3 /* MPP[35]: GE1[15] */ + 36 0 /* MPP[36]: GPIO[36] */ + 37 0 /* MPP[37]: GPIO[37] */ + 38 0 /* MPP[38]: GPIO[38] */ + 39 0 /* MPP[39]: GPIO[39] */ + 40 2 /* MPP[40]: TDM_SPI_SCK */ + 41 2 /* MPP[41]: TDM_SPI_MISO */ + 42 2 /* MPP[42]: TDM_SPI_MOSI */ + 43 0 /* MPP[43]: GPIO[43] */ + 44 0 /* MPP[44]: GPIO[44] */ + 45 0 /* MPP[45]: GPIO[45] */ + 46 0 /* MPP[46]: GPIO[46] */ + 47 0 /* MPP[47]: GPIO[47] */ + 48 0 /* MPP[48]: GPIO[48] */ + 49 0 /* MPP[49]: GPIO[49] */ + >; + }; + + GPIO: gpio@10100 { + #gpio-cells = <3>; + compatible = "mrvl,gpio"; + reg = <0x10100 0x20>; + gpio-controller; + interrupts = <35 36 37 38 39 40 41>; + interrupt-parent = <&PIC>; + pin-count = <50>; + }; + + gpioled@0 { + compatible = "mrvl,gpioled"; + + gpios = <&GPIO 47 2 0 /* GPIO[47] BT LED: OUT */ + &GPIO 48 2 0 /* GPIO[48] WLAN LED: OUT */ + &GPIO 49 2 0>; /* GPIO[49] WLAN AP LED: OUT */ + }; + + rtc@10300 { + compatible = "mrvl,rtc"; + reg = <0x10300 0x08>; + }; + + twsi@11000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "mrvl,twsi"; + reg = <0x11000 0x20>; + interrupts = <43>; + interrupt-parent = <&PIC>; + }; + + enet0: ethernet@72000 { + #address-cells = <1>; + #size-cells = <1>; + model = "V2"; + compatible = "mrvl,ge"; + reg = <0x72000 0x2000>; + ranges = <0x0 0x72000 0x2000>; + local-mac-address = [ 00 00 00 00 00 00 ]; + interrupts = <12 13 14 11 46>; + interrupt-parent = <&PIC>; + phy-handle = <&phy0>; + + mdio@0 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "mrvl,mdio"; + + phy0: ethernet-phy@0 { + reg = <0x0>; + }; + + phy1: ethernet-phy@1 { + reg = <0x1>; + }; + }; + }; + + enet1: ethernet@76000 { + #address-cells = <1>; + #size-cells = <1>; + model = "V2"; + compatible = "mrvl,ge"; + reg = <0x76000 0x02000>; + ranges = <0x0 0x76000 0x2000>; + local-mac-address = [ 00 00 00 00 00 00 ]; + interrupts = <16 17 18 15 47>; + interrupt-parent = <&PIC>; + phy-handle = <&phy1>; + }; + + serial0: serial@12000 { + compatible = "ns16550"; + reg = <0x12000 0x20>; + reg-shift = <2>; + clock-frequency = <0>; + interrupts = <33>; + interrupt-parent = <&PIC>; + }; + + serial1: serial@12100 { + compatible = "ns16550"; + reg = <0x12100 0x20>; + reg-shift = <2>; + clock-frequency = <0>; + interrupts = <34>; + interrupt-parent = <&PIC>; + }; + + crypto@30000 { + compatible = "mrvl,cesa"; + reg = <0x30000 0x10000>; + interrupts = <22>; + interrupt-parent = <&PIC>; + + sram-handle = <&SRAM>; + }; + + usb@50000 { + compatible = "mrvl,usb-ehci", "usb-ehci"; + reg = <0x50000 0x1000>; + interrupts = <48 19>; + interrupt-parent = <&PIC>; + }; + + xor@60000 { + compatible = "mrvl,xor"; + reg = <0x60000 0x1000>; + interrupts = <5 6 7 8>; + interrupt-parent = <&PIC>; + }; + + sata@80000 { + compatible = "mrvl,sata"; + reg = <0x80000 0x6000>; + interrupts = <21>; + interrupt-parent = <&PIC>; + }; + + sdio@90000 { + compatible = "mrvl,sdio"; + reg = <0x90000 0x134>; + interrupts = <28>; + interrupt-parent = <&PIC>; + }; + }; + + SRAM: sram@fd000000 { + compatible = "mrvl,cesa-sram"; + reg = <0xfd000000 0x00100000>; + }; + + chosen { + stdin = "serial0"; + stdout = "serial0"; + }; + +}; diff -r b3c4270c3840 -r fc76ae13d76c sys/boot/fdt/dts/dreamplug-1001N.dts --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ sys/boot/fdt/dts/dreamplug-1001N.dts Sun Aug 19 11:01:08 2012 -0600 @@ -0,0 +1,339 @@ +/* + * Copyright (c) 2010 The FreeBSD Foundation + * All rights reserved. + * + * This software was developed by Semihalf under sponsorship from + * the FreeBSD Foundation. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * GlobalScale Technologies DreamPlug Device Tree Source. + * + * This source is for version 10 revision 01 units with NAND flash. + * These units are marked "1001N" on the serial number label. + * + * $FreeBSD$ + */ + +/dts-v1/; + +/ { + model = "GlobalScale Technologies Dreamplug v1001N"; + compatible = "globalscale,dreamplug-003-ds2001", "globalscale,dreamplug", "marvell,kirkwood-88f6281", "marvell,kirkwood"; + #address-cells = <1>; + #size-cells = <1>; + + aliases { + ethernet0 = &enet0; + ethernet1 = &enet1; + mpp = &MPP; + serial0 = &serial0; + serial1 = &serial1; + soc = &SOC; + sram = &SRAM; + }; + + cpus { + #address-cells = <1>; + #size-cells = <0>; + + cpu@0 { + device_type = "cpu"; + compatible = "ARM,88FR131"; + reg = <0x0>; + d-cache-line-size = <32>; // 32 bytes + i-cache-line-size = <32>; // 32 bytes + d-cache-size = <0x4000>; // L1, 16K + i-cache-size = <0x4000>; // L1, 16K + timebase-frequency = <0>; + bus-frequency = <0>; + clock-frequency = <0>; + }; + + }; + + memory { + device_type = "memory"; + reg = <0x0 0x20000000>; // 512M at 0x0 + }; + + localbus@0 { + #address-cells = <2>; + #size-cells = <1>; + compatible = "mrvl,lbc"; + bank-count = <1>; + + /* This reflects CPU decode windows setup. */ + ranges = <0x0 0x2f 0xf9300000 0x00100000>; + + nand@0,0 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "mrvl,nfc"; + reg = <0x0 0x0 0x00100000>; + bank-width = <2>; + device-width = <1>; + + // Slice info reported by builtin linux when it boots... + //[ 11.161328] 0x00000000-0x00100000 : "u-boot" + //[ 11.167431] 0x00100000-0x00500000 : "uImage" + //[ 11.173471] 0x00500000-0x20000000 : "root" + + slice@0 { + reg = <0x0 0x100000>; + label = "u-boot"; + read-only; + }; + + slice@200000 { + reg = <0x100000 0x40000>; + label = "uImage"; + }; + + slice@500000 { + reg = <0x500000 0x1FB00000>; + label = "root"; + }; + }; + }; + + SOC: soc88f6281@f1000000 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "simple-bus"; + ranges = <0x0 0xf1000000 0x00100000>; + bus-frequency = <0>; + + PIC: pic@20200 { + interrupt-controller; + #address-cells = <0>; + #interrupt-cells = <1>; + reg = <0x20200 0x3c>; + compatible = "mrvl,pic"; + }; + + timer@20300 { + compatible = "mrvl,timer"; + reg = <0x20300 0x30>; + interrupts = <1>; + interrupt-parent = <&PIC>; + mrvl,has-wdt; + }; + + MPP: mpp@10000 { + #pin-cells = <2>; + compatible = "mrvl,mpp"; + reg = <0x10000 0x34>; + pin-count = <50>; + pin-map = < + 0 1 /* MPP[ 0]: NF_IO[2] */ + 1 1 /* MPP[ 1]: NF_IO[3] */ + 2 1 /* MPP[ 2]: NF_IO[4] */ + 3 1 /* MPP[ 3]: NF_IO[5] */ + 4 1 /* MPP[ 4]: NF_IO[6] */ + 5 1 /* MPP[ 5]: NF_IO[7] */ + 6 1 /* MPP[ 6]: SYSRST_OUTn */ + 7 0 /* MPP[ 7]: GPO[7] */ + 8 1 /* MPP[ 8]: TW_SDA */ + 9 1 /* MPP[ 9]: TW_SCK */ + 10 3 /* MPP[10]: UA0_TXD */ + 11 3 /* MPP[11]: US0_RXD */ + 12 1 /* MPP[12]: SD_CLK */ + 13 1 /* MPP[13]: SD_CMD */ + 14 1 /* MPP[14]: SD_D[0] */ + 15 1 /* MPP[15]: SD_D[1] */ + 16 1 /* MPP[16]: SD_D[2] */ + 17 1 /* MPP[17]: SD_D[3] */ + 18 1 /* MPP[18]: NF_IO[0] */ + 19 1 /* MPP[19]: NF_IO[1] */ + 20 3 /* MPP[20]: GE1[ 0] */ + 21 3 /* MPP[21]: GE1[ 1] */ + 22 3 /* MPP[22]: GE1[ 2] */ + 23 3 /* MPP[23]: GE1[ 3] */ + 24 3 /* MPP[24]: GE1[ 4] */ + 25 3 /* MPP[25]: GE1[ 5] */ + 26 3 /* MPP[26]: GE1[ 6] */ + 27 3 /* MPP[27]: GE1[ 7] */ + 28 3 /* MPP[28]: GE1[ 8] */ + 29 3 /* MPP[29]: GE1[ 9] */ + 30 3 /* MPP[30]: GE1[10] */ + 31 3 /* MPP[31]: GE1[11] */ + 32 3 /* MPP[32]: GE1[12] */ + 33 3 /* MPP[33]: GE1[13] */ + 34 3 /* MPP[34]: GE1[14] */ + 35 3 /* MPP[35]: GE1[15] */ + 36 0 /* MPP[36]: GPIO[36] */ + 37 0 /* MPP[37]: GPIO[37] */ + 38 0 /* MPP[38]: GPIO[38] */ + 39 0 /* MPP[39]: GPIO[39] */ + 40 2 /* MPP[40]: TDM_SPI_SCK */ + 41 2 /* MPP[41]: TDM_SPI_MISO */ + 42 2 /* MPP[42]: TDM_SPI_MOSI */ + 43 0 /* MPP[43]: GPIO[43] */ + 44 0 /* MPP[44]: GPIO[44] */ + 45 0 /* MPP[45]: GPIO[45] */ + 46 0 /* MPP[46]: GPIO[46] */ + 47 0 /* MPP[47]: GPIO[47] */ + 48 0 /* MPP[48]: GPIO[48] */ + 49 0 /* MPP[49]: GPIO[49] */ + >; + }; + + GPIO: gpio@10100 { + #gpio-cells = <3>; + compatible = "mrvl,gpio"; + reg = <0x10100 0x20>; + gpio-controller; + interrupts = <35 36 37 38 39 40 41>; + interrupt-parent = <&PIC>; + pin-count = <50>; + }; + + gpioled@0 { + compatible = "mrvl,gpioled"; + + gpios = <&GPIO 47 2 0 /* GPIO[47] BT LED: OUT */ + &GPIO 48 2 0 /* GPIO[48] WLAN LED: OUT */ + &GPIO 49 2 0>; /* GPIO[49] WLAN AP LED: OUT */ + }; + + rtc@10300 { + compatible = "mrvl,rtc"; + reg = <0x10300 0x08>; + }; + + twsi@11000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "mrvl,twsi"; + reg = <0x11000 0x20>; + interrupts = <43>; + interrupt-parent = <&PIC>; + }; + + enet0: ethernet@72000 { + #address-cells = <1>; + #size-cells = <1>; + model = "V2"; + compatible = "mrvl,ge"; + reg = <0x72000 0x2000>; + ranges = <0x0 0x72000 0x2000>; + local-mac-address = [ 00 00 00 00 00 00 ]; + interrupts = <12 13 14 11 46>; + interrupt-parent = <&PIC>; + phy-handle = <&phy0>; + + mdio@0 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "mrvl,mdio"; + + phy0: ethernet-phy@0 { + reg = <0x0>; + }; + + phy1: ethernet-phy@1 { + reg = <0x1>; + }; + }; + }; + + enet1: ethernet@76000 { + #address-cells = <1>; + #size-cells = <1>; + model = "V2"; + compatible = "mrvl,ge"; + reg = <0x76000 0x02000>; + ranges = <0x0 0x76000 0x2000>; + local-mac-address = [ 00 00 00 00 00 00 ]; + interrupts = <16 17 18 15 47>; + interrupt-parent = <&PIC>; + phy-handle = <&phy1>; + }; + + serial0: serial@12000 { + compatible = "ns16550"; + reg = <0x12000 0x20>; + reg-shift = <2>; + clock-frequency = <0>; + interrupts = <33>; + interrupt-parent = <&PIC>; + }; + + serial1: serial@12100 { + compatible = "ns16550"; + reg = <0x12100 0x20>; + reg-shift = <2>; + clock-frequency = <0>; + interrupts = <34>; + interrupt-parent = <&PIC>; + }; + + crypto@30000 { + compatible = "mrvl,cesa"; + reg = <0x30000 0x10000>; + interrupts = <22>; + interrupt-parent = <&PIC>; + + sram-handle = <&SRAM>; + }; + + usb@50000 { + compatible = "mrvl,usb-ehci", "usb-ehci"; + reg = <0x50000 0x1000>; + interrupts = <48 19>; + interrupt-parent = <&PIC>; + }; + + xor@60000 { + compatible = "mrvl,xor"; + reg = <0x60000 0x1000>; + interrupts = <5 6 7 8>; + interrupt-parent = <&PIC>; + }; + + sata@80000 { + compatible = "mrvl,sata"; + reg = <0x80000 0x6000>; + interrupts = <21>; + interrupt-parent = <&PIC>; + }; + + sdio@90000 { + compatible = "mrvl,sdio"; + reg = <0x90000 0x134>; + interrupts = <28>; + interrupt-parent = <&PIC>; + }; + }; + + SRAM: sram@fd000000 { + compatible = "mrvl,cesa-sram"; + reg = <0xfd000000 0x00100000>; + }; + + chosen { + stdin = "serial0"; + stdout = "serial0"; + }; + +}; --=-e0TG0Hb/8sJDKnXmaIex-- From owner-freebsd-arm@FreeBSD.ORG Tue Dec 11 19:18:55 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A94F2412 for ; Tue, 11 Dec 2012 19:18:55 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from smtp5.clear.net.nz (smtp5.clear.net.nz [203.97.33.68]) by mx1.freebsd.org (Postfix) with ESMTP id 6597F8FC16 for ; Tue, 11 Dec 2012 19:18:54 +0000 (UTC) Received: from mxin1-orange.clear.net.nz (lb2-srcnat.clear.net.nz [203.97.32.237]) by smtp5.clear.net.nz (CLEAR Net Mail) with ESMTP id <0MEV0058ESBB4N20@smtp5.clear.net.nz> for freebsd-arm@freebsd.org; Wed, 12 Dec 2012 08:18:48 +1300 (NZDT) Received: from 202-0-48-19.paradise.net.nz (HELO localhost) ([202.0.48.19]) by smtpin1.paradise.net.nz with ESMTP; Wed, 12 Dec 2012 08:18:47 +1300 Date: Wed, 12 Dec 2012 08:18:33 +1300 From: Andrew Turner Subject: Re: ARM EABI patch In-reply-to: <3DE6764415F645FCA29CD18BA51762F8@ad.peach.ne.jp> To: Daisuke Aoyama Message-id: <20121212081833.47127fd0@fubar.geek.nz> MIME-version: 1.0 X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; i386-portbld-freebsd8.1) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Pirate: Arrrr References: <20121209160721.571186d8@fubar.geek.nz> <3DE6764415F645FCA29CD18BA51762F8@ad.peach.ne.jp> Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 19:18:55 -0000 On Wed, 12 Dec 2012 03:25:31 +0900 "Daisuke Aoyama" wrote: > Hi, > > I found cross-build problem of the EABI patch. I'm trying to use it > for Raspberry Pi. > According to machine/_types.h, wchar_t is unsigned int when EABI. > This patch solve "error: array of inappropriate type initialized from > string constant" when use L"foo". Can you send me a full log of the cross-build (off list is fine) that shows the failure. I haven't seen the issue so would like to find out how to trigger it. Andrew From owner-freebsd-arm@FreeBSD.ORG Tue Dec 11 19:19:39 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CBFE44E1 for ; Tue, 11 Dec 2012 19:19:39 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from smtp3.clear.net.nz (smtp3.clear.net.nz [203.97.33.64]) by mx1.freebsd.org (Postfix) with ESMTP id 88BED8FC0C for ; Tue, 11 Dec 2012 19:19:39 +0000 (UTC) Received: from mxin2-orange.clear.net.nz (lb2-srcnat.clear.net.nz [203.97.32.237]) by smtp3.clear.net.nz (CLEAR Net Mail) with ESMTP id <0MEV00I8RSCD6I50@smtp3.clear.net.nz> for freebsd-arm@freebsd.org; Wed, 12 Dec 2012 08:19:38 +1300 (NZDT) Received: from 202-0-48-19.paradise.net.nz (HELO localhost) ([202.0.48.19]) by smtpin2.paradise.net.nz with ESMTP; Wed, 12 Dec 2012 08:19:38 +1300 Date: Wed, 12 Dec 2012 08:19:24 +1300 From: Andrew Turner Subject: Re: ARM EABI patch In-reply-to: <33581130-C882-43EC-BA61-056CDE9DB514@bsdimp.com> To: Warner Losh Message-id: <20121212081924.491abd76@fubar.geek.nz> MIME-version: 1.0 X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; i386-portbld-freebsd8.1) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Pirate: Arrrr References: <20121209160721.571186d8@fubar.geek.nz> <3DE6764415F645FCA29CD18BA51762F8@ad.peach.ne.jp> <33581130-C882-43EC-BA61-056CDE9DB514@bsdimp.com> Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 19:19:40 -0000 On Tue, 11 Dec 2012 11:42:58 -0700 Warner Losh wrote: > Is __ARM_EABI__ only defined when building an arm EABI TARGET? Or is > it defined always on an ARM EABI host? > It is the former, i.e. only set when we are building for ARM EABI. Andrew From owner-freebsd-arm@FreeBSD.ORG Tue Dec 11 23:08:46 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DDEFF6B5 for ; Tue, 11 Dec 2012 23:08:46 +0000 (UTC) (envelope-from aoyama@peach.ne.jp) Received: from moon.peach.ne.jp (moon.peach.ne.jp [203.141.148.98]) by mx1.freebsd.org (Postfix) with ESMTP id A000B8FC1B for ; Tue, 11 Dec 2012 23:08:46 +0000 (UTC) Received: from moon.peach.ne.jp (localhost [127.0.0.1]) by moon.peach.ne.jp (Postfix) with ESMTP id 3904339D5E; Wed, 12 Dec 2012 08:08:45 +0900 (JST) Received: from artemis (unknown [172.18.0.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by moon.peach.ne.jp (Postfix) with ESMTPSA id 242E339D5B; Wed, 12 Dec 2012 08:08:45 +0900 (JST) Message-ID: <6D652C6AB162489E8C06D17141AF0178@ad.peach.ne.jp> From: "Daisuke Aoyama" To: "Andrew Turner" References: <20121209160721.571186d8@fubar.geek.nz> <3DE6764415F645FCA29CD18BA51762F8@ad.peach.ne.jp> <20121212081833.47127fd0@fubar.geek.nz> In-Reply-To: <20121212081833.47127fd0@fubar.geek.nz> Subject: Re: ARM EABI patch Date: Wed, 12 Dec 2012 08:08:30 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 23:08:46 -0000 >> I found cross-build problem of the EABI patch. I'm trying to use it >> for Raspberry Pi. >> According to machine/_types.h, wchar_t is unsigned int when EABI. >> This patch solve "error: array of inappropriate type initialized from >> string constant" when use L"foo". > > Can you send me a full log of the cross-build (off list is fine) that > shows the failure. I haven't seen the issue so would like to find out > how to trigger it. Sorry, I used modified source tree for RPI. If check out new one, it should be OK. I'm using following commands in amd64 2vCPU VM on ESXi5.1. export SRCROOT=/usr/src export TARGET_ARCH=armv6 export KERNCONF=RPI-B-testXXX make -C $SRCROOT kernel-toolchain make -C $SRCROOT KERNCONF=$KERNCONF WITH_FDT=yes buildkernel make -j4 -C $SRCROOT MALLOC_PRODUCTION=yes buildworld -- Daisuke Aoyama From owner-freebsd-arm@FreeBSD.ORG Wed Dec 12 10:16:36 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CA27015D for ; Wed, 12 Dec 2012 10:16:36 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from smtp4.clear.net.nz (smtp4.clear.net.nz [203.97.37.64]) by mx1.freebsd.org (Postfix) with ESMTP id 8A64F8FC08 for ; Wed, 12 Dec 2012 10:16:35 +0000 (UTC) Received: from mxin3-orange.clear.net.nz (lb2-srcnat.clear.net.nz [203.97.32.237]) by smtp4.clear.net.nz (CLEAR Net Mail) with ESMTP id <0MEW00GGXXVG9D40@smtp4.clear.net.nz> for freebsd-arm@freebsd.org; Wed, 12 Dec 2012 23:16:28 +1300 (NZDT) Received: from 202-0-48-19.paradise.net.nz (HELO localhost) ([202.0.48.19]) by smtpin32.paradise.net.nz with ESMTP; Wed, 12 Dec 2012 23:16:27 +1300 Date: Wed, 12 Dec 2012 23:16:14 +1300 From: Andrew Turner Subject: Re: ARM EABI patch In-reply-to: <6D652C6AB162489E8C06D17141AF0178@ad.peach.ne.jp> To: Daisuke Aoyama Message-id: <20121212231614.20c9a8f0@fubar.geek.nz> MIME-version: 1.0 X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; i386-portbld-freebsd8.1) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Pirate: Arrrr References: <20121209160721.571186d8@fubar.geek.nz> <3DE6764415F645FCA29CD18BA51762F8@ad.peach.ne.jp> <20121212081833.47127fd0@fubar.geek.nz> <6D652C6AB162489E8C06D17141AF0178@ad.peach.ne.jp> Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 10:16:36 -0000 On Wed, 12 Dec 2012 08:08:30 +0900 "Daisuke Aoyama" wrote: > >> I found cross-build problem of the EABI patch. I'm trying to use it > >> for Raspberry Pi. > >> According to machine/_types.h, wchar_t is unsigned int when EABI. > >> This patch solve "error: array of inappropriate type initialized > >> from string constant" when use L"foo". > > > > Can you send me a full log of the cross-build (off list is fine) > > that shows the failure. I haven't seen the issue so would like to > > find out how to trigger it. > > Sorry, I used modified source tree for RPI. > If check out new one, it should be OK. > I'm using following commands in amd64 2vCPU VM on ESXi5.1. > > export SRCROOT=/usr/src > export TARGET_ARCH=armv6 > export KERNCONF=RPI-B-testXXX > make -C $SRCROOT kernel-toolchain > make -C $SRCROOT KERNCONF=$KERNCONF WITH_FDT=yes buildkernel > make -j4 -C $SRCROOT MALLOC_PRODUCTION=yes buildworld > I tried this on a clean tree with just the patch applied. I didn't get the problem you're describing above. Can you check the patch applied cleanly. Can you run the failing command under script to get the build log? For example: $ script build.log make -j4 -C $SRCROOT MALLOC_PRODUCTION=yes buildworld will do a buildworld and save the output to the file build.log Andrew From owner-freebsd-arm@FreeBSD.ORG Wed Dec 12 17:08:57 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EF339352; Wed, 12 Dec 2012 17:08:56 +0000 (UTC) (envelope-from aoyama@peach.ne.jp) Received: from moon.peach.ne.jp (moon.peach.ne.jp [203.141.148.98]) by mx1.freebsd.org (Postfix) with ESMTP id 8B6178FC08; Wed, 12 Dec 2012 17:08:56 +0000 (UTC) Received: from moon.peach.ne.jp (localhost [127.0.0.1]) by moon.peach.ne.jp (Postfix) with ESMTP id E74A639D5B; Thu, 13 Dec 2012 02:08:54 +0900 (JST) Received: from artemis (unknown [172.18.0.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by moon.peach.ne.jp (Postfix) with ESMTPSA id E3BEC39D46; Thu, 13 Dec 2012 02:08:54 +0900 (JST) Message-ID: From: "Daisuke Aoyama" To: Subject: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) Date: Thu, 13 Dec 2012 02:08:50 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-2022-jp"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 17:08:57 -0000 Hi, I've created FreeBSD clang world for RPI based on svn 244112 + eabi.diff(NOT USE) + few NetBSD code. I didn't test with "-mfloat-abi=softfp" but it might work. The first version is released at my Japanese blog: http://shell.peach.ne.jp/aoyama/archives/2357 Thank you for many comments to previous versions. Thank you for adding RPI support to FreeBSD. Thank you for porting latest clang to head! It's very useful for RPI developing now. You can get the pre-build image from my archives: http://www.peach.ne.jp/archives/rpi/ (At this time, freebsd-pi-clang-20121213.img.gz is the latest version.) Download and decompress it, then write it to SD. This image requires SD 4GB or more. I'm using as headless server. So, you need a serial console for seeing the boot log. If you need to change the value on it, please mount the second partition (e.g. /dev/da0s2a). If you want the video out, please remove the line of "set console=comconsole" in /boot/loader.rc. Note: first time, it takes about 2 minutes for generating the SSH keys. This version includes axe(ASIX AX88x7x/760) driver because smsc is not stable. Now "cc" is "clang" instead of "gcc". If you want to use gcc, specify or edit /etc/make.conf. The initial setup code is taken from NetBSD. Using config is here: http://www.peach.ne.jp/archives/rpi/config/RPI-B-test8 Source and pacth is here: http://www.peach.ne.jp/archives/rpi/patch/ Pre-configured for: MEM 496MB/GPU 16MB/SWAP 512MB I/O: multi-console (primary serial) IP address: 192.168.1.240 Default router: 192.168.1.1 DNS: 192.168.1.1 sshd: enabled User: pi Password: raspberry Password(root): raspberry kernel section limit: TS=256MB, DS=1024MB, SS=256MB example of /etc/make.conf: ---------------------------------------------------------------------- WITHOUT_X11=yes WITH_CLANG=yes WITH_CLANG_IS_CC=yes # Now cc = clang is default #CC=clang #CXX=clang++ #CPP=clang-cpp # For clang NO_WERROR= WERROR= CFLAGS=-O2 -fno-strict-aliasing -pipe -march=armv6z -mtune=arm1176jzf-s -mfloat-abi=soft COPTFLAGS=-O1 -fno-strict-aliasing -pipe -march=armv6z -mtune=arm1176jzf-s -mfloat-abi=soft # For gcc #CC=gcc #CXX=g++ #CPP=cpp ---------------------------------------------------------------------- How to use GPT USB stick in RPI: (if you use something, delete/destory it before doing) # gpart delete -i NN da0 # gpart destroy -F da0 (create new partition and format) # gpart create -s gpt da0 # gpart add -t freebsd-ufs da0 # gpart show # newfs -U -j /dev/da0p1 (mount it) # mount /dev/da0p1 /mnt ---------------------------------------------------------------------- Known problems: o SD card is not configured correctly. (power on/off need if it's failed) o hang the system. (unknown reason) o smsc is not stable. o alignment/padding is not same as gcc. (temporary avoid strict alignment now) o call both IDCACHE_WBINV_ALL and DCACHE_WB_RANGE at switch. (can't work without both) o still depend on GNU as (gas syntax). TODO: o modify/replace bcm2835 drivers. o using "clang -integrated-as". o fix alignment with clang. o self build. o use EABI if possible. o create build script :-) Enjoy clang world in Raspberry Pi! Thank you. -- Daisuke Aoyama From owner-freebsd-arm@FreeBSD.ORG Wed Dec 12 22:43:05 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E835F41A for ; Wed, 12 Dec 2012 22:43:05 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from cpsmtpb-ews02.kpnxchange.com (cpsmtpb-ews02.kpnxchange.com [213.75.39.5]) by mx1.freebsd.org (Postfix) with ESMTP id 412908FC16 for ; Wed, 12 Dec 2012 22:43:04 +0000 (UTC) Received: from cpsps-ews03.kpnxchange.com ([10.94.84.170]) by cpsmtpb-ews02.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Wed, 12 Dec 2012 23:41:04 +0100 Received: from CPSMTPM-TLF104.kpnxchange.com ([195.121.3.7]) by cpsps-ews03.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Wed, 12 Dec 2012 23:41:04 +0100 Received: from sjakie.klop.ws ([212.182.167.131]) by CPSMTPM-TLF104.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Wed, 12 Dec 2012 23:41:57 +0100 Received: from 212-182-167-131.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id 87AAF2362 for ; Wed, 12 Dec 2012 23:41:56 +0100 (CET) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-arm@freebsd.org Date: Wed, 12 Dec 2012 23:41:56 +0100 Subject: sheevaplug nand type not recognized? MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: User-Agent: Opera Mail/12.11 (FreeBSD) X-OriginalArrivalTime: 12 Dec 2012 22:41:57.0265 (UTC) FILETIME=[E4321810:01CDD8B9] X-RcptDomain: freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 22:43:06 -0000 Hello, I just compiled a FreeBSD-10-current (src from 22 Nov.) kernel+world and installed it on a usb stick. It has NAND support compiled in, but I see no nand devices in /dev. Dmesg does not list a lnand0 device like the example in http://wiki.freebsd.org/NAND#NAND_Framework. Booting Debian finds this: ... NAND device: Manufacturer ID: 0xec, Chip ID: 0xdc (Samsung NAND 512MiB 3,3V 8-bit) Scanning device for bad blocks Bad eraseblock 168 at 0x000001500000 Bad eraseblock 169 at 0x000001520000 Bad eraseblock 1193 at 0x000009520000 2 cmdlinepart partitions found on MTD device orion_nand Creating 2 MTD partitions on "orion_nand": 0x000000100000-0x000000500000 : "uImage" 0x000000500000-0x000020000000 : "rootfs" UBI: attaching mtd1 to ubi0 ... I don't see this Samsung version in sys/dev/nand/nand_id.c. Would it be easy to add it? I understand the manufacturer id and chip id, but I don't know what I should change more. uname + bootinfo: FreeBSD sh10.klop.ws 10.0-CURRENT FreeBSD 10.0-CURRENT #1: Wed Dec 12 23:16:43 CET 2012 root@mailjail.klop.ws:/usr/obj/arm.arm/usr/src/sys/SHEEVAPLUG arm __ __ _ _ | \/ | __ _ _ ____ _____| | | | |\/| |/ _` | '__\ \ / / _ \ | | | | | | (_| | | \ V / __/ | | |_| |_|\__,_|_| \_/ \___|_|_| _ _ ____ _ | | | | | __ ) ___ ___ | |_ | | | |___| _ \ / _ \ / _ \| __| | |_| |___| |_) | (_) | (_) | |_ \___/ |____/ \___/ \___/ \__| ** MARVELL BOARD: SHEEVA PLUG LE U-Boot 1.1.4 (Jul 19 2009 - 16:03:28) Marvell version: 3.4.19 U-Boot code: 00600000 -> 0067FFF0 BSS: -> 006CFB00 Soc: 88F6281 A0 (DDR2) CPU running @ 1200Mhz L2 running @ 400Mhz SysClock = 400Mhz , TClock = 200Mhz DRAM CAS Latency = 5 tRP = 5 tRAS = 18 tRCD=6 DRAM CS[0] base 0x00000000 size 256MB DRAM CS[1] base 0x10000000 size 256MB DRAM Total size 512MB 16bit width Addresses 8M - 0M are saved for the U-Boot usage. Mem malloc Initialization (8M - 7M): Done NAND:512 MB Flash: 0 kB CPU : Marvell Feroceon (Rev 1) Streaming disabled Write allocate disabled USB 0: host mode PEX 0: interface detected no Link. Net: egiga0 [PRIME], egiga1 Hit any key to stop autoboot: 0 Marvell>> usb start; fatload usb 0:1 0x900000 kernel.bin; go 0x900000; (Re)start USB... USB: scanning bus for devices... 2 USB Device(s) found scanning bus for storage devices... 1 Storage Device(s) found reading kernel.bin ................................................................................................................................................................................................................................................................................................................................................... 3473528 bytes read ## Starting application at 0x00900000 ... KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #1: Wed Dec 12 23:16:43 CET 2012 root@mailjail.klop.ws:/usr/obj/arm.arm/usr/src/sys/SHEEVAPLUG arm CPU: Feroceon 88FR131 rev 1 (Marvell core) Little-endian DC enabled IC enabled WA disabled DC streaming enabled BTB disabled L2 enabled L2 prefetch enabled WB enabled EABT branch prediction enabled 16KB/32B 4-way instruction cache 16KB/32B 4-way write-back-locking-C data cache real memory = 536870912 (512 MB) avail memory = 519700480 (495 MB) SOC: Marvell 88F6281 rev A0, TClock 200MHz Instruction cache prefetch enabled, data cache prefetch enabled 256KB 4-way set-associative write-through unified L2 cache random device not loaded; using insecure entropy localbus0: on fdtbus0 nand0: mem 0xf9300000-0xf93fffff on localbus0 nandbus0: on nand0 simplebus0: on fdtbus0 ic0: mem 0xf1020200-0xf102023b on simplebus0 timer0: mem 0xf1020300-0xf102032f irq 1 on simplebus0 Event timer "CPUTimer0" frequency 200000000 Hz quality 1000 Timecounter "CPUTimer1" frequency 200000000 Hz quality 1000 gpio0: mem 0xf1010100-0xf101011f irq 35,36,37,38,39,40,41 on simplebus0 rtc0: mem 0xf1010300-0xf1010307 on simplebus0 mge0: mem 0xf1072000-0xf1073fff irq 12,13,14,11,46 on simplebus0 mge0: Ethernet address: 00:50:43:01:6d:4c miibus0: on mge0 e1000phy0: PHY 0 on miibus0 e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto uart0: <16550 or compatible> mem 0xf1012000-0xf101201f irq 33 on simplebus0 uart0: console (1066,n,8,1) uart1: <16550 or compatible> mem 0xf1012100-0xf101211f irq 34 on simplebus0 cesa0: mem 0xf1030000-0xf103ffff irq 22 on simplebus0 ehci0: mem 0xf1050000-0xf1050fff irq 48,19 on simplebus0 usbus0: EHCI version 1.0 usbus0: set host controller mode usbus0 on ehci0 cryptosoft0: Timecounters tick every 1.000 msec ipfw2 initialized, divert loadable, nat loadable, default to accept, logging disabled usbus0: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 uhub0: 1 port with 1 removable, self powered Root mount waiting for: usbus0 ugen0.2: at usbus0 umass0: on usbus0 umass0: SCSI over Bulk-Only; quirks = 0x4000 umass0:0:0:-1: Attached to scbus0 Trying to mount root from ufs:/dev/da0s2 []... mountroot: waiting for device /dev/da0s2 ... da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 3894MB (7975296 512 byte sectors: 255H 63S/T 496C) Regards, Ronald. From owner-freebsd-arm@FreeBSD.ORG Wed Dec 12 22:58:45 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CEAB3B0E for ; Wed, 12 Dec 2012 22:58:45 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 2F90A8FC18 for ; Wed, 12 Dec 2012 22:58:38 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qBCMwa1A042932 for ; Wed, 12 Dec 2012 15:58:37 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qBCMwO3r057011; Wed, 12 Dec 2012 15:58:24 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: sheevaplug nand type not recognized? From: Ian Lepore To: Ronald Klop In-Reply-To: References: Content-Type: multipart/mixed; boundary="=-Z/Sbi9iTNzcr0Cb0Nh7b" Date: Wed, 12 Dec 2012 15:58:24 -0700 Message-ID: <1355353104.87661.468.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 22:58:45 -0000 --=-Z/Sbi9iTNzcr0Cb0Nh7b Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Wed, 2012-12-12 at 23:41 +0100, Ronald Klop wrote: > Hello, > > I just compiled a FreeBSD-10-current (src from 22 Nov.) kernel+world and > installed it on a usb stick. > It has NAND support compiled in, but I see no nand devices in /dev. > Dmesg does not list a lnand0 device like the example in > http://wiki.freebsd.org/NAND#NAND_Framework. > > Booting Debian finds this: > ... > NAND device: Manufacturer ID: 0xec, Chip ID: 0xdc (Samsung NAND 512MiB > 3,3V 8-bit) > Scanning device for bad blocks > Bad eraseblock 168 at 0x000001500000 > Bad eraseblock 169 at 0x000001520000 > Bad eraseblock 1193 at 0x000009520000 > 2 cmdlinepart partitions found on MTD device orion_nand > Creating 2 MTD partitions on "orion_nand": > 0x000000100000-0x000000500000 : "uImage" > 0x000000500000-0x000020000000 : "rootfs" > UBI: attaching mtd1 to ubi0 > ... > > I don't see this Samsung version in sys/dev/nand/nand_id.c. > Would it be easy to add it? I understand the manufacturer id and chip id, > but I don't know what I should change more. That looks like the same chip that's in my DreamPlug 1001N, the attached diff should fix it for you. -- Ian --=-Z/Sbi9iTNzcr0Cb0Nh7b Content-Disposition: inline; filename="dreamplug_nand.diff" Content-Type: text/x-patch; name="dreamplug_nand.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit Index: sys/dev/nand/nand_id.c =================================================================== --- sys/dev/nand/nand_id.c (revision 243920) +++ sys/dev/nand/nand_id.c (working copy) @@ -37,6 +37,8 @@ 0x20, 0x200, 0x10, 0x20, 0 }, { { NAND_MAN_SAMSUNG, 0xd3 }, "Samsung NAND 1GiB 3,3V 8-bit", 0x400, 0x800, 0x40, 0x40, 0 }, + { { NAND_MAN_SAMSUNG, 0xdc }, "Samsung NAND 512MiB 3,3V 8-bit", + 0x200, 0x800, 0x40, 0x40, 0 }, { { NAND_MAN_HYNIX, 0x76 }, "Hynix NAND 64MiB 3,3V 8-bit", 0x40, 0x200, 0x10, 0x20, 0 }, { { NAND_MAN_HYNIX, 0xdc }, "Hynix NAND 512MiB 3,3V 8-bit", --=-Z/Sbi9iTNzcr0Cb0Nh7b-- From owner-freebsd-arm@FreeBSD.ORG Wed Dec 12 23:17:15 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5F6EEEDA for ; Wed, 12 Dec 2012 23:17:15 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from cpsmtpb-ews07.kpnxchange.com (cpsmtpb-ews07.kpnxchange.com [213.75.39.10]) by mx1.freebsd.org (Postfix) with ESMTP id A591B8FC12 for ; Wed, 12 Dec 2012 23:17:14 +0000 (UTC) Received: from cpsps-ews24.kpnxchange.com ([10.94.84.190]) by cpsmtpb-ews07.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Thu, 13 Dec 2012 00:15:14 +0100 Received: from CPSMTPM-TLF103.kpnxchange.com ([195.121.3.6]) by cpsps-ews24.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Thu, 13 Dec 2012 00:15:13 +0100 Received: from sjakie.klop.ws ([212.182.167.131]) by CPSMTPM-TLF103.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Thu, 13 Dec 2012 00:16:06 +0100 Received: from 212-182-167-131.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id 72A0D2381 for ; Thu, 13 Dec 2012 00:16:06 +0100 (CET) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-arm@freebsd.org Subject: Re: sheevaplug nand type not recognized? References: <1355353104.87661.468.camel@revolution.hippie.lan> Date: Thu, 13 Dec 2012 00:16:06 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: <1355353104.87661.468.camel@revolution.hippie.lan> User-Agent: Opera Mail/12.11 (FreeBSD) X-OriginalArrivalTime: 12 Dec 2012 23:16:07.0018 (UTC) FILETIME=[A9F194A0:01CDD8BE] X-RcptDomain: freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 23:17:15 -0000 On Wed, 12 Dec 2012 23:58:24 +0100, Ian Lepore wrote: > On Wed, 2012-12-12 at 23:41 +0100, Ronald Klop wrote: >> Hello, >> >> I just compiled a FreeBSD-10-current (src from 22 Nov.) kernel+world and >> installed it on a usb stick. >> It has NAND support compiled in, but I see no nand devices in /dev. >> Dmesg does not list a lnand0 device like the example in >> http://wiki.freebsd.org/NAND#NAND_Framework. >> >> Booting Debian finds this: >> ... >> NAND device: Manufacturer ID: 0xec, Chip ID: 0xdc (Samsung NAND 512MiB >> 3,3V 8-bit) >> Scanning device for bad blocks >> Bad eraseblock 168 at 0x000001500000 >> Bad eraseblock 169 at 0x000001520000 >> Bad eraseblock 1193 at 0x000009520000 >> 2 cmdlinepart partitions found on MTD device orion_nand >> Creating 2 MTD partitions on "orion_nand": >> 0x000000100000-0x000000500000 : "uImage" >> 0x000000500000-0x000020000000 : "rootfs" >> UBI: attaching mtd1 to ubi0 >> ... >> >> I don't see this Samsung version in sys/dev/nand/nand_id.c. >> Would it be easy to add it? I understand the manufacturer id and chip >> id, >> but I don't know what I should change more. > > That looks like the same chip that's in my DreamPlug 1001N, the attached > diff should fix it for you. > > -- Ian > Supernice! nand0: mem 0xf9300000-0xf93fffff on localbus0 nandbus0: on nand0 lnand0: on nandbus0 lnand0: No BBT found. Prescan chip... ##lnand0: Bad block(168) lnand0: Bad block(169) ##########lnand0: Bad block(1193) ############################# root@sh10:~ # ls -l /dev/*nand* crw-r----- 1 root operator 0x2f Dec 12 23:09 /dev/gnand.raw0 crw-r----- 1 root operator 0x33 Dec 12 23:09 /dev/gnand.raw0s.root crw-r----- 1 root operator 0x32 Dec 12 23:09 /dev/gnand.raw0s.u-boot crw-r----- 1 root operator 0x2e Dec 12 23:09 /dev/gnand0 crw-r----- 1 root operator 0x31 Dec 12 23:09 /dev/gnand0s.root crw-r----- 1 root operator 0x30 Dec 12 23:09 /dev/gnand0s.u-boot crw-rw-rw- 1 root wheel 0x19 Dec 12 23:09 /dev/nand0.0 Now I can't go to sleep without playing some more with it. :-) Cheers, Ronald. From owner-freebsd-arm@FreeBSD.ORG Wed Dec 12 23:37:15 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D5B4E6F6 for ; Wed, 12 Dec 2012 23:37:15 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 647958FC12 for ; Wed, 12 Dec 2012 23:37:15 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qBCNbEB2044152 for ; Wed, 12 Dec 2012 16:37:14 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qBCNbCO6057029; Wed, 12 Dec 2012 16:37:12 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: sheevaplug nand type not recognized? From: Ian Lepore To: Ronald Klop In-Reply-To: References: <1355353104.87661.468.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Wed, 12 Dec 2012 16:37:11 -0700 Message-ID: <1355355431.87661.472.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 23:37:15 -0000 On Thu, 2012-12-13 at 00:16 +0100, Ronald Klop wrote: > On Wed, 12 Dec 2012 23:58:24 +0100, Ian Lepore > wrote: > > > On Wed, 2012-12-12 at 23:41 +0100, Ronald Klop wrote: > >> Hello, > >> > >> I just compiled a FreeBSD-10-current (src from 22 Nov.) kernel+world and > >> installed it on a usb stick. > >> It has NAND support compiled in, but I see no nand devices in /dev. > >> Dmesg does not list a lnand0 device like the example in > >> http://wiki.freebsd.org/NAND#NAND_Framework. > >> > >> Booting Debian finds this: > >> ... > >> NAND device: Manufacturer ID: 0xec, Chip ID: 0xdc (Samsung NAND 512MiB > >> 3,3V 8-bit) > >> Scanning device for bad blocks > >> Bad eraseblock 168 at 0x000001500000 > >> Bad eraseblock 169 at 0x000001520000 > >> Bad eraseblock 1193 at 0x000009520000 > >> 2 cmdlinepart partitions found on MTD device orion_nand > >> Creating 2 MTD partitions on "orion_nand": > >> 0x000000100000-0x000000500000 : "uImage" > >> 0x000000500000-0x000020000000 : "rootfs" > >> UBI: attaching mtd1 to ubi0 > >> ... > >> > >> I don't see this Samsung version in sys/dev/nand/nand_id.c. > >> Would it be easy to add it? I understand the manufacturer id and chip > >> id, > >> but I don't know what I should change more. > > > > That looks like the same chip that's in my DreamPlug 1001N, the attached > > diff should fix it for you. > > > > -- Ian > > > > Supernice! > > nand0: mem 0xf9300000-0xf93fffff on localbus0 > nandbus0: on nand0 > lnand0: on nandbus0 > lnand0: No BBT found. Prescan chip... > ##lnand0: Bad block(168) > lnand0: Bad block(169) > ##########lnand0: Bad block(1193) > ############################# > > > root@sh10:~ # ls -l /dev/*nand* > crw-r----- 1 root operator 0x2f Dec 12 23:09 /dev/gnand.raw0 > crw-r----- 1 root operator 0x33 Dec 12 23:09 /dev/gnand.raw0s.root > crw-r----- 1 root operator 0x32 Dec 12 23:09 /dev/gnand.raw0s.u-boot > crw-r----- 1 root operator 0x2e Dec 12 23:09 /dev/gnand0 > crw-r----- 1 root operator 0x31 Dec 12 23:09 /dev/gnand0s.root > crw-r----- 1 root operator 0x30 Dec 12 23:09 /dev/gnand0s.u-boot > crw-rw-rw- 1 root wheel 0x19 Dec 12 23:09 /dev/nand0.0 > > Now I can't go to sleep without playing some more with it. :-) > > Cheers, > Ronald. Heh. Be careful. My dreamplug 1001N is a brick because I typed a command in the wrong window and wiped the nand on it, and I haven't had any success trying to use openocd to flash it (or even get it to boot as a one-shot). -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed Dec 12 23:57:09 2012 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 18676CEE; Wed, 12 Dec 2012 23:57:09 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1A4348FC08; Wed, 12 Dec 2012 23:57:07 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id go10so1242432lbb.13 for ; Wed, 12 Dec 2012 15:57:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=1jdblQG67XSZru5fqaWfedg6dDPaMOZ4d1Ob1LIyUdg=; b=S/3bkYGqPrLMAPLofBIMzdGeLJnU4n/imw/AO8DJ3lWbWZdjA4hr0TBm6vegfGw2d0 Y2yRA4bdnJ4ou58RY5q/1c2+IdyfX6S0+yvH0WG93hlFC3bSh9h6TeOn/x999EjlTjxI cn8hSqQqRKioZX+c2E1tYFYMhuvURXh7Zwu9wQWs4nRW/pm3pDV6xVepfVFkF2grt3V+ Hu5YMGxj2Cfd0/U9cO1CElp8RCnSfV7Pi0LBVaz731nxDzYWA2kj8OJUwnJY6gksaE+v wN8wEl/BW6PU/dNmDtcY+042V0xBC7mPwqMA8/7vx6wj9gPrL2C+fKX+LrBC1jVx6v1z Qdfw== MIME-Version: 1.0 Received: by 10.152.131.168 with SMTP id on8mr37930lab.38.1355356626240; Wed, 12 Dec 2012 15:57:06 -0800 (PST) Received: by 10.112.99.70 with HTTP; Wed, 12 Dec 2012 15:57:05 -0800 (PST) Date: Wed, 12 Dec 2012 15:57:05 -0800 Message-ID: Subject: RPC link error when WITH_OFED is set building PANDABOARD, but no errors from tinderbox? From: Garrett Cooper To: freebsd-arm@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Oleksandr Tymoshenko , Rick Macklem X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 23:57:09 -0000 Ran into a link error when trying to do make tinderbox like so with NFS, but make tinderbox isn't failing with CURRENT. BOOTP_NFSROOT is defined in GUMSTIX, but not PANDABOARD (and GUMSTIX passed). Ideas? Thanks! -Garrett $ make tinderbox -j4 SRCCONF=/dev/null __MAKECONF=/dev/null -DWITH_OFED -------------------------------------------------------------- >>> make universe started on Wed Dec 12 12:21:16 PST 2012 -------------------------------------------------------------- >> amd64 started on Wed Dec 12 12:21:16 PST 2012 >> arm started on Wed Dec 12 12:21:16 PST 2012 >> i386 started on Wed Dec 12 12:21:16 PST 2012 >> ia64 started on Wed Dec 12 12:21:16 PST 2012 >> mips started on Wed Dec 12 12:21:16 PST 2012 >> pc98 started on Wed Dec 12 12:21:16 PST 2012 >> powerpc started on Wed Dec 12 12:21:16 PST 2012 >> sparc64 started on Wed Dec 12 12:21:16 PST 2012 >> amd64.amd64 buildworld started on Wed Dec 12 12:21:16 PST 2012 >> arm.arm buildworld started on Wed Dec 12 12:21:16 PST 2012 >> arm.armeb buildworld started on Wed Dec 12 12:21:16 PST 2012 >> arm.armv6 buildworld started on Wed Dec 12 12:21:16 PST 2012 >> arm.armeb buildworld completed on Wed Dec 12 13:14:52 PST 2012 >> arm.arm buildworld completed on Wed Dec 12 13:14:55 PST 2012 >> arm.armv6eb buildworld started on Wed Dec 12 13:14:55 PST 2012 >> arm.armv6 buildworld completed on Wed Dec 12 13:14:55 PST 2012 >> i386.i386 buildworld started on Wed Dec 12 13:14:57 PST 2012 >> ia64.ia64 buildworld started on Wed Dec 12 13:24:22 PST 2012 >> arm.armv6eb buildworld completed on Wed Dec 12 14:05:27 PST 2012 >> ia64.ia64 buildworld completed on Wed Dec 12 14:41:45 PST 2012 >> ia64 completed on Wed Dec 12 15:28:12 PST 2012 arm PANDABOARD kernel failed, check _.arm.PANDABOARD for details >> amd64.amd64 buildworld completed on Wed Dec 12 15:36:22 PST 2012 ... $ uname -a FreeBSD forza.west.isilon.com 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0 r+2fd0a57: Mon Dec 3 12:02:18 PST 2012 gcooper@forza.west.isilon.com:/usr/obj/usr/src/sys/FORZA amd64 $ tail -n 20 _.arm.PANDABOARD cc -c -x assembler-with-cpp -DLOCORE -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/scratch/freebsd/head/sys -I/scratch/freebsd/head/sys/contrib/altq -I/scratch/freebsd/head/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -ffreestanding -Werror /scratch/freebsd/head/sys/arm/arm/support.S cc -c -x assembler-with-cpp -DLOCORE -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/scratch/freebsd/head/sys -I/scratch/freebsd/head/sys/contrib/altq -I/scratch/freebsd/head/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -ffreestanding -Werror /scratch/freebsd/head/sys/arm/arm/swtch.S cc -c -x assembler-with-cpp -DLOCORE -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/scratch/freebsd/head/sys -I/scratch/freebsd/head/sys/contrib/altq -I/scratch/freebsd/head/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -ffreestanding -Werror /scratch/freebsd/head/sys/arm/arm/irq_dispatch.S MAKE=make sh /scratch/freebsd/head/sys/conf/newvers.sh PANDABOARD cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/scratch/freebsd/head/sys -I/scratch/freebsd/head/sys/contrib/altq -I/scratch/freebsd/head/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -ffreestanding -Werror vers.c linking kernel.debug clnt_rc.o: In function `clnt_reconnect_destroy': /scratch/freebsd/head/sys/rpc/clnt_rc.c:501: undefined reference to `xprt_unregister' clnt_rc.o: In function `clnt_reconnect_control': /scratch/freebsd/head/sys/rpc/clnt_rc.c:455: undefined reference to `xprt_register' clnt_vc.o: In function `clnt_vc_destroy': /scratch/freebsd/head/sys/rpc/clnt_vc.c:804: undefined reference to `xprt_unregister' clnt_vc.o: In function `clnt_vc_soupcall': /scratch/freebsd/head/sys/rpc/clnt_vc.c:1018: undefined reference to `xprt_active' *** [kernel.debug] Error code 1 1 error *** [buildkernel] Error code 2 1 error *** [buildkernel] Error code 2 1 error From owner-freebsd-arm@FreeBSD.ORG Thu Dec 13 00:07:06 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0621CFC4; Thu, 13 Dec 2012 00:07:06 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [88.198.91.248]) by mx1.freebsd.org (Postfix) with ESMTP id 82DB88FC18; Thu, 13 Dec 2012 00:07:05 +0000 (UTC) Received: from [88.198.91.248] (helo=[IPv6:::1]) by id.bluezbox.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TiwKD-0008y7-8Y; Wed, 12 Dec 2012 16:06:56 -0800 Message-ID: <50C91C1B.4070301@bluezbox.com> Date: Wed, 12 Dec 2012 16:06:51 -0800 From: Oleksandr Tymoshenko User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Daisuke Aoyama Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 12/12/2012 9:08 AM, Daisuke Aoyama wrote: > Hi, > > I've created FreeBSD clang world for RPI based on svn 244112 + > eabi.diff(NOT USE) + few NetBSD code. > I didn't test with "-mfloat-abi=softfp" but it might work. > > The first version is released at my Japanese blog: > http://shell.peach.ne.jp/aoyama/archives/2357 > > Thank you for many comments to previous versions. > Thank you for adding RPI support to FreeBSD. > Thank you for porting latest clang to head! > It's very useful for RPI developing now. > > You can get the pre-build image from my archives: > > http://www.peach.ne.jp/archives/rpi/ > (At this time, freebsd-pi-clang-20121213.img.gz is the latest version.) > > Download and decompress it, then write it to SD. This image requires > SD 4GB or more. > I'm using as headless server. So, you need a serial console for seeing > the boot log. > If you need to change the value on it, please mount the second > partition (e.g. /dev/da0s2a). > If you want the video out, please remove the line of "set > console=comconsole" in /boot/loader.rc. > > Note: first time, it takes about 2 minutes for generating the SSH keys. > This version includes axe(ASIX AX88x7x/760) driver because smsc is not > stable. > Now "cc" is "clang" instead of "gcc". If you want to use gcc, specify > or edit /etc/make.conf. > The initial setup code is taken from NetBSD. > > Using config is here: > http://www.peach.ne.jp/archives/rpi/config/RPI-B-test8 > > Source and pacth is here: > http://www.peach.ne.jp/archives/rpi/patch/ > > > Pre-configured for: > > MEM 496MB/GPU 16MB/SWAP 512MB > I/O: multi-console (primary serial) > IP address: 192.168.1.240 > Default router: 192.168.1.1 > DNS: 192.168.1.1 > sshd: enabled > > User: pi > Password: raspberry > Password(root): raspberry > > kernel section limit: > TS=256MB, DS=1024MB, SS=256MB > > example of /etc/make.conf: > > WITHOUT_X11=yes > > WITH_CLANG=yes > WITH_CLANG_IS_CC=yes > > # Now cc = clang is default > #CC=clang > [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 00:07:06 -0000 On 12/12/2012 9:08 AM, Daisuke Aoyama wrote: > Hi, > > I've created FreeBSD clang world for RPI based on svn 244112 + > eabi.diff(NOT USE) + few NetBSD code. > I didn't test with "-mfloat-abi=softfp" but it might work. > > The first version is released at my Japanese blog: > http://shell.peach.ne.jp/aoyama/archives/2357 > > Thank you for many comments to previous versions. > Thank you for adding RPI support to FreeBSD. > Thank you for porting latest clang to head! > It's very useful for RPI developing now. > > You can get the pre-build image from my archives: > > http://www.peach.ne.jp/archives/rpi/ > (At this time, freebsd-pi-clang-20121213.img.gz is the latest version.) > > Download and decompress it, then write it to SD. This image requires > SD 4GB or more. > I'm using as headless server. So, you need a serial console for seeing > the boot log. > If you need to change the value on it, please mount the second > partition (e.g. /dev/da0s2a). > If you want the video out, please remove the line of "set > console=comconsole" in /boot/loader.rc. > > Note: first time, it takes about 2 minutes for generating the SSH keys. > This version includes axe(ASIX AX88x7x/760) driver because smsc is not > stable. > Now "cc" is "clang" instead of "gcc". If you want to use gcc, specify > or edit /etc/make.conf. > The initial setup code is taken from NetBSD. > > Using config is here: > http://www.peach.ne.jp/archives/rpi/config/RPI-B-test8 > > Source and pacth is here: > http://www.peach.ne.jp/archives/rpi/patch/ > > > Pre-configured for: > > MEM 496MB/GPU 16MB/SWAP 512MB > I/O: multi-console (primary serial) > IP address: 192.168.1.240 > Default router: 192.168.1.1 > DNS: 192.168.1.1 > sshd: enabled > > User: pi > Password: raspberry > Password(root): raspberry > > kernel section limit: > TS=256MB, DS=1024MB, SS=256MB > > example of /etc/make.conf: > ---------------------------------------------------------------------- > WITHOUT_X11=yes > > WITH_CLANG=yes > WITH_CLANG_IS_CC=yes > > # Now cc = clang is default > #CC=clang > #CXX=clang++ > #CPP=clang-cpp > > # For clang > NO_WERROR= > WERROR= > > CFLAGS=-O2 -fno-strict-aliasing -pipe -march=armv6z > -mtune=arm1176jzf-s -mfloat-abi=soft > COPTFLAGS=-O1 -fno-strict-aliasing -pipe -march=armv6z > -mtune=arm1176jzf-s -mfloat-abi=soft > > # For gcc > #CC=gcc > #CXX=g++ > #CPP=cpp > ---------------------------------------------------------------------- > How to use GPT USB stick in RPI: > > (if you use something, delete/destory it before doing) > # gpart delete -i NN da0 > # gpart destroy -F da0 > > (create new partition and format) > # gpart create -s gpt da0 > # gpart add -t freebsd-ufs da0 > # gpart show > # newfs -U -j /dev/da0p1 > > (mount it) > # mount /dev/da0p1 /mnt > ---------------------------------------------------------------------- > Known problems: > o SD card is not configured correctly. (power on/off need if it's failed) > o hang the system. (unknown reason) > o smsc is not stable. > o alignment/padding is not same as gcc. (temporary avoid strict > alignment now) > o call both IDCACHE_WBINV_ALL and DCACHE_WB_RANGE at switch. (can't > work without both) > o still depend on GNU as (gas syntax). > > TODO: > o modify/replace bcm2835 drivers. > o using "clang -integrated-as". > o fix alignment with clang. > o self build. > o use EABI if possible. > o create build script :-) > > Enjoy clang world in Raspberry Pi! Amazing! Thank you for working on it From owner-freebsd-arm@FreeBSD.ORG Thu Dec 13 00:26:04 2012 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9D34D6BE; Thu, 13 Dec 2012 00:26:04 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [88.198.91.248]) by mx1.freebsd.org (Postfix) with ESMTP id 416738FC14; Thu, 13 Dec 2012 00:26:04 +0000 (UTC) Received: from [88.198.91.248] (helo=[IPv6:::1]) by id.bluezbox.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Tiwcj-000HSI-Og; Wed, 12 Dec 2012 16:26:03 -0800 Message-ID: <50C92098.3070403@freebsd.org> Date: Wed, 12 Dec 2012 16:26:00 -0800 From: Oleksandr Tymoshenko User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Garrett Cooper Subject: Re: RPC link error when WITH_OFED is set building PANDABOARD, but no errors from tinderbox? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 12/12/2012 3:57 PM, Garrett Cooper wrote: > Ran into a link error when trying to do make tinderbox like so > with NFS, but make tinderbox isn't failing with CURRENT. BOOTP_NFSROOT > is defined in GUMSTIX, but not PANDABOARD (and GUMSTIX passed). Ideas? > Thanks! > -Garrett > [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: freebsd-arm@FreeBSD.org, Rick Macklem X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 00:26:04 -0000 On 12/12/2012 3:57 PM, Garrett Cooper wrote: > Ran into a link error when trying to do make tinderbox like so > with NFS, but make tinderbox isn't failing with CURRENT. BOOTP_NFSROOT > is defined in GUMSTIX, but not PANDABOARD (and GUMSTIX passed). Ideas? > Thanks! > -Garrett > Pandaboard config got only NFSCLIENT not NFSCL and it seems that rpc/svc.c is set as dependency only for NFSCL. And r244008 added reference to xprt_XXXX functions. Why tinderbox is silent - I don't know. From owner-freebsd-arm@FreeBSD.ORG Thu Dec 13 01:07:17 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D8A078A2 for ; Thu, 13 Dec 2012 01:07:17 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from cpsmtpb-ews01.kpnxchange.com (cpsmtpb-ews01.kpnxchange.com [213.75.39.4]) by mx1.freebsd.org (Postfix) with ESMTP id 5A9CB8FC0C for ; Thu, 13 Dec 2012 01:07:16 +0000 (UTC) Received: from cpsps-ews21.kpnxchange.com ([10.94.84.187]) by cpsmtpb-ews01.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Thu, 13 Dec 2012 02:05:16 +0100 Received: from CPSMTPM-TLF104.kpnxchange.com ([195.121.3.7]) by cpsps-ews21.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Thu, 13 Dec 2012 02:05:16 +0100 Received: from sjakie.klop.ws ([212.182.167.131]) by CPSMTPM-TLF104.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Thu, 13 Dec 2012 02:06:09 +0100 Received: from 212-182-167-131.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id 0FA2A23B4 for ; Thu, 13 Dec 2012 02:06:09 +0100 (CET) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-arm@freebsd.org Date: Thu, 13 Dec 2012 02:06:08 +0100 Subject: sheevaplug boot from nandfs hangs MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: User-Agent: Opera Mail/12.11 (FreeBSD) X-OriginalArrivalTime: 13 Dec 2012 01:06:09.0652 (UTC) FILETIME=[096B9340:01CDD8CE] X-RcptDomain: freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 01:07:18 -0000 Hello, I succeeded in installing and booting my kernel (SHEEVAPLUG 10-current from 22 nov.) from nandfs. I followed all the advise at http://wiki.freebsd.org/NAND. But the rootfs will not mount/start. The end of the bootinfo is this: cryptosoft0: Timecounters tick every 1.000 msec ipfw2 initialized, divert loadable, nat loadable, default to accept, logging disabled usbus0: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 uhub0: 1 port with 1 removable, self powered Root mount waiting for: usbus0 ugen0.2: at usbus0 umass0: on usbus0 umass0: SCSI over Bulk-Only; quirks = 0x4000 umass0:0:0:-1: Attached to scbus0 Trying to mount root from nandfs:/dev/gnand0s.root []... WARNING: NANDFS is considered to be a highly experimental feature in FreeBSD. (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (probe0:umass-sim0:0:0:0): Retrying command da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 3894MB (7975296 512 byte sectors: 255H 63S/T 496C) The kernel is responsive because if I remove or insert the usb stick it displays messages about it. (Not shown above) I'm connected via serial. What could be wrong? What information can I give more? I installed /dev/gnand0s.root by tarring the content of / on my usb stick to the mounted /dev/gnand0s.root. That looked ok. Regards, Ronald. From owner-freebsd-arm@FreeBSD.ORG Thu Dec 13 02:07:03 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8DDFDE8B for ; Thu, 13 Dec 2012 02:07:03 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 14E588FC0C for ; Thu, 13 Dec 2012 02:07:02 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qBD271x8048346 for ; Wed, 12 Dec 2012 19:07:01 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qBD26wkT057202; Wed, 12 Dec 2012 19:06:58 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: sheevaplug boot from nandfs hangs From: Ian Lepore To: Ronald Klop In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Wed, 12 Dec 2012 19:06:58 -0700 Message-ID: <1355364418.87661.489.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 02:07:03 -0000 On Thu, 2012-12-13 at 02:06 +0100, Ronald Klop wrote: > Hello, > > I succeeded in installing and booting my kernel (SHEEVAPLUG 10-current > from 22 nov.) from nandfs. I followed all the advise at > http://wiki.freebsd.org/NAND. But the rootfs will not mount/start. > > The end of the bootinfo is this: > cryptosoft0: > Timecounters tick every 1.000 msec > ipfw2 initialized, divert loadable, nat loadable, default to accept, > logging disabled > usbus0: 480Mbps High Speed USB v2.0 > ugen0.1: at usbus0 > uhub0: on usbus0 > uhub0: 1 port with 1 removable, self powered > Root mount waiting for: usbus0 > ugen0.2: at usbus0 > umass0: on > usbus0 > umass0: SCSI over Bulk-Only; quirks = 0x4000 > umass0:0:0:-1: Attached to scbus0 > Trying to mount root from nandfs:/dev/gnand0s.root []... > WARNING: NANDFS is considered to be a highly experimental feature in > FreeBSD. > (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 > (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error > (probe0:umass-sim0:0:0:0): Retrying command > da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > da0: Removable Direct Access SCSI-0 device > da0: 40.000MB/s transfers > da0: 3894MB (7975296 512 byte sectors: 255H 63S/T 496C) > > The kernel is responsive because if I remove or insert the usb stick it > displays messages about it. (Not shown above) > I'm connected via serial. What could be wrong? What information can I give > more? > I installed /dev/gnand0s.root by tarring the content of / on my usb stick > to the mounted /dev/gnand0s.root. That looked ok. > > Regards, > Ronald. Hmm, so the root mount happens, but init never gets started, or never gets far enough to show signs of being started. Mounting root is invoked from sys/kern/init_main.c, I guess what I'd do next is add some printfs in there to see if vfs_mountroot() is returning and if so how much farther it gets. Hmmm, if your kernel is built with ALT_BREAK_TO_DEBUGGER then on the serial console maybe you can CR ~ ^B and poke around. Hmmm, or maybe not, because I just tried that on my dreamplug and it just spewed this many times: root@dpcur:/root # ~KDB: enter: Break to debugger [ thread pid 10 tid 100002 ] Stopped at kdb_enter+0x48:panic: mtx_lock() by idle thread 0xc3593c00 on sleep mutex pmap @ /local/build/staging/freebsd/dp10/src/sys/arm/arm/pmap.c:3662 panic: mtx_lock() by idle thread 0xc3593c00 on sleep mutex eventhandler @ /local/build/staging/freebsd/dp10/src/sys/kern/subr_eventhandler.c:251 KDB: enter: panic and apparently recursed until it ran out of stack and locked up. So I guess it'll be printf-debugging to the rescue. :) I can confirm that this should be working. I've got a similar setup going on Atmel arm chips, although I haven't sync'd up with -current for a while, I'm at r241077 on that project. Right now I still load the kernel from sdcard but root gets mounted from the nand and the system runs. Performance is horrible (this is a low end arm, 180mhz), but it works. nand0: mem 0xe0000000-0xefffffff on atmelarm0 nandbus0: on nand0 onand0: on nandbus0 onand0: Found BBT table for chip Timecounters tick every 10.000 msec usbus0: 12Mbps Full Speed USB v1.0 ugen0.1: at usbus0 uhub0: on usbus0 mmcsd0: 1876MB at mmc0 22.5MHz/1bit/64-block Root mount waiting for: usbus0 uhub0: 2 ports with 2 removable, self powered Root mount waiting for: usbus0 ugen0.2: at usbus0 Root mount waiting for: usbus0 Root mount waiting for: usbus0 ugen0.3: at usbus0 (disconnected) Trying to mount root from nandfs:/dev/gnand0s.root []... WARNING: NANDFS is considered to be a highly experimental feature in FreeBSD. warning: no time-of-day clock registered, system time will not be set accurately Starting file system checks: -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Dec 13 09:32:00 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E71DC3F5; Thu, 13 Dec 2012 09:32:00 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from smtp3.clear.net.nz (smtp3.clear.net.nz [203.97.33.64]) by mx1.freebsd.org (Postfix) with ESMTP id A97B68FC0C; Thu, 13 Dec 2012 09:31:59 +0000 (UTC) Received: from mxin2-orange.clear.net.nz (lb2-srcnat.clear.net.nz [203.97.32.237]) by smtp3.clear.net.nz (CLEAR Net Mail) with ESMTP id <0MEY00EOBQG7OQ10@smtp3.clear.net.nz>; Thu, 13 Dec 2012 22:31:19 +1300 (NZDT) Received: from 202-0-48-19.paradise.net.nz (HELO localhost) ([202.0.48.19]) by smtpin2.paradise.net.nz with ESMTP; Thu, 13 Dec 2012 22:31:19 +1300 Date: Thu, 13 Dec 2012 22:31:05 +1300 From: Andrew Turner Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) In-reply-to: To: Daisuke Aoyama Message-id: <20121213223105.5a719efb@fubar.geek.nz> MIME-version: 1.0 X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; i386-portbld-freebsd8.1) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Pirate: Arrrr References: Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 09:32:01 -0000 On Thu, 13 Dec 2012 02:08:50 +0900 "Daisuke Aoyama" wrote: > Hi, > > I've created FreeBSD clang world for RPI based on svn 244112 + > eabi.diff(NOT USE) + few NetBSD code. > I didn't test with "-mfloat-abi=softfp" but it might work. If you haven't seen there is the start of FreeBSD ARM support in clang: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20121210/069693.html I'm testing this with the version of clang we have in head and hope to bring in support for clang and ARM soon. Andrew From owner-freebsd-arm@FreeBSD.ORG Thu Dec 13 10:00:49 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A4C19241; Thu, 13 Dec 2012 10:00:49 +0000 (UTC) (envelope-from aoyama@peach.ne.jp) Received: from moon.peach.ne.jp (moon.peach.ne.jp [203.141.148.98]) by mx1.freebsd.org (Postfix) with ESMTP id 6747A8FC17; Thu, 13 Dec 2012 10:00:48 +0000 (UTC) Received: from moon.peach.ne.jp (localhost [127.0.0.1]) by moon.peach.ne.jp (Postfix) with ESMTP id C981539D49; Thu, 13 Dec 2012 19:00:41 +0900 (JST) Received: from artemis (unknown [172.18.0.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by moon.peach.ne.jp (Postfix) with ESMTPSA id B4ABF39D46; Thu, 13 Dec 2012 19:00:41 +0900 (JST) Message-ID: From: "Daisuke Aoyama" To: "Andrew Turner" References: <20121213223105.5a719efb@fubar.geek.nz> In-Reply-To: <20121213223105.5a719efb@fubar.geek.nz> Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) Date: Thu, 13 Dec 2012 19:00:36 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 10:00:49 -0000 >> I've created FreeBSD clang world for RPI based on svn 244112 + >> eabi.diff(NOT USE) + few NetBSD code. >> I didn't test with "-mfloat-abi=softfp" but it might work. > > If you haven't seen there is the start of FreeBSD ARM support in clang: > http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20121210/069693.html > > I'm testing this with the version of clang we have in head and hope to > bring in support for clang and ARM soon. I didn't see this, but it's not enough. I already adjusted clang for your EABI patch, so the patched version of clang can be compiled for both OABI(apcs-gnu) and EABI(aapcs). Note that some world code is still broken for EABI w/clang. -- Daisuke Aoyama From owner-freebsd-arm@FreeBSD.ORG Thu Dec 13 17:31:47 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 098C4AFB for ; Thu, 13 Dec 2012 17:31:47 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 8EC188FC0C for ; Thu, 13 Dec 2012 17:31:46 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qBDHVejI074189 for ; Thu, 13 Dec 2012 10:31:40 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qBDHVbur058054; Thu, 13 Dec 2012 10:31:37 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: sheevaplug boot from nandfs hangs From: Ian Lepore To: Ronald Klop In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Thu, 13 Dec 2012 10:31:37 -0700 Message-ID: <1355419897.77832.20.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 17:31:47 -0000 On Thu, 2012-12-13 at 02:06 +0100, Ronald Klop wrote: > Hello, > > I succeeded in installing and booting my kernel (SHEEVAPLUG 10-current > from 22 nov.) from nandfs. I followed all the advise at > http://wiki.freebsd.org/NAND. But the rootfs will not mount/start. > > The end of the bootinfo is this: > cryptosoft0: > Timecounters tick every 1.000 msec > ipfw2 initialized, divert loadable, nat loadable, default to accept, > logging disabled > usbus0: 480Mbps High Speed USB v2.0 > ugen0.1: at usbus0 > uhub0: on usbus0 > uhub0: 1 port with 1 removable, self powered > Root mount waiting for: usbus0 > ugen0.2: at usbus0 > umass0: on > usbus0 > umass0: SCSI over Bulk-Only; quirks = 0x4000 > umass0:0:0:-1: Attached to scbus0 > Trying to mount root from nandfs:/dev/gnand0s.root []... > WARNING: NANDFS is considered to be a highly experimental feature in > FreeBSD. > (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 > (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error > (probe0:umass-sim0:0:0:0): Retrying command > da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > da0: Removable Direct Access SCSI-0 device > da0: 40.000MB/s transfers > da0: 3894MB (7975296 512 byte sectors: 255H 63S/T 496C) > > The kernel is responsive because if I remove or insert the usb stick it > displays messages about it. (Not shown above) > I'm connected via serial. What could be wrong? What information can I give > more? > I installed /dev/gnand0s.root by tarring the content of / on my usb stick > to the mounted /dev/gnand0s.root. That looked ok. > > Regards, > Ronald. FYI, you should take that WARNING: line *very* seriously at this point. Don't keep any vital data on that filesystem unless you back it up frequently and can afford to "drop everything and restore/recover now" at any moment. I'm finding it's pretty easy to lock up or panic the system while using nandfs, and on reboot this is what you see if you were writing to the filesystem when it locked up: Trying to mount root from nandfs:/dev/gnand0s.root []... WARNING: NANDFS is considered to be a highly experimental feature in FreeBSD. Cannot find valid SuperRoot Mounting from nandfs:/dev/gnand0s.root failed with error 22. This leaves me at a mountroot> prompt (at which I cannot type, but that's a general arm bug I've been living with for years). The only way I know of right now to recover from this is to boot from some other device, and reformat and restore/regenerate the nandfs filesystem. Most of the problems I've been seeing are related to writing to the nandfs filesystem; when populated once and then mounted readonly after that it seems pretty stable. I've also noticed that I absolutely cannot mount a unionfs over a readonly nandfs -- that's pretty much a g'teed panic related to locking. I also had trouble using nullfs and nandfs together, but I forget the details of that. Enabling WITNESS shows lots of nandfs locking troubles. -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Dec 13 20:01:39 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DF212B2E; Thu, 13 Dec 2012 20:01:39 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7CE688FC0C; Thu, 13 Dec 2012 20:01:39 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id 16so2532923obc.13 for ; Thu, 13 Dec 2012 12:01:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TA/FSphicWYNMS4HTBZ/KVimZHPuX/9IGvcKry5IYPY=; b=GVODPmoqkd8tdaM02EBXFRUxIJs+uAeIhIuQxKwKvetaJJ+fv+jGbcDKERFSWx5B1n uLjvWU9H/xmE5z+zxDQZ9bVw5tCFTW2jxt47QEaqmxY8CMeOz6BObHZebBJIsXflUoVQ 5/JGqIJpIuSfD4qDZiK8fMCT9lz4S72dazB9GNm5Z5ndPMQYUDyy7fiGsLWa1/2Lt3RZ 74kvC0fu9NahOhHWrFgCLqh04DYqGq81hhG3NKUdSzWpUwYJwI14T96HuL3ODlCgRm8S iJKy+UrfY9gi5K5A+xb9RcSa8/51yydwDQOV1ujoyhDzebiQ2M5bCxhNmW37eQ5Le7fd bVbg== MIME-Version: 1.0 Received: by 10.60.0.165 with SMTP id 5mr2592575oef.128.1355428898908; Thu, 13 Dec 2012 12:01:38 -0800 (PST) Received: by 10.76.143.33 with HTTP; Thu, 13 Dec 2012 12:01:38 -0800 (PST) In-Reply-To: <50C92098.3070403@freebsd.org> References: <50C92098.3070403@freebsd.org> Date: Thu, 13 Dec 2012 12:01:38 -0800 Message-ID: Subject: Re: RPC link error when WITH_OFED is set building PANDABOARD, but no errors from tinderbox? From: Garrett Cooper To: Oleksandr Tymoshenko Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arm@freebsd.org, Rick Macklem X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 20:01:39 -0000 On Wed, Dec 12, 2012 at 4:26 PM, Oleksandr Tymoshenko wrote: > On 12/12/2012 3:57 PM, Garrett Cooper wrote: >> >> Ran into a link error when trying to do make tinderbox like so >> with NFS, but make tinderbox isn't failing with CURRENT. BOOTP_NFSROOT >> is defined in GUMSTIX, but not PANDABOARD (and GUMSTIX passed). Ideas? > > Pandaboard config got only NFSCLIENT not NFSCL and it seems that rpc/svc.c > is set as dependency only for NFSCL. And r244008 added reference to > xprt_XXXX > functions. Why tinderbox is silent - I don't know. Seems like this should be fixed in NFS land then via sys/conf/files.*, etc. Rick? Thanks! -Garrett From owner-freebsd-arm@FreeBSD.ORG Fri Dec 14 08:02:03 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 34FF92BB for ; Fri, 14 Dec 2012 08:02:03 +0000 (UTC) (envelope-from dev@macdevshanghai.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id D04068FC17 for ; Fri, 14 Dec 2012 08:02:02 +0000 (UTC) Received: by mail-vb0-f54.google.com with SMTP id l1so3513793vba.13 for ; Fri, 14 Dec 2012 00:01:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=KnrxAO0wcKPKAGZ6UufllM/2h7Kbyo9YiPsHudaVn64=; b=UkZrl/bSPGOTPLhEmIJIVKjllA5qoYpkcgOWmH0imJ6qcVMuBRalV0Mh5tDAQU6sAp AzcSt/N61v+stJbqMOX9po2RKIeSZAGAR7Nix46YLwn7TNeLDJDOGyxp1L6WK2zWE7jD RsvfeA2K/JoSn/cwgJE9zpsTTmAo3hLTq1HmElx0O3/ZqnNCztuWbpEVWIdi4cqcMLVv jOSd9OFSnaWCtYq912bBawPz6XMk3TP/y+aAw5Mf9fIq23qmCN+CZ0EU/SMFVBleZfjZ 62sUlv2KY8NNgGB2w1tWf8fI9JiP+VJove3XKQ93oxQhwV6rOJbHUU+xkp/abG73BUpE OoOA== MIME-Version: 1.0 Received: by 10.58.145.161 with SMTP id sv1mr7847139veb.52.1355472114780; Fri, 14 Dec 2012 00:01:54 -0800 (PST) Received: by 10.58.88.134 with HTTP; Fri, 14 Dec 2012 00:01:54 -0800 (PST) X-Originating-IP: [140.206.116.178] Date: Fri, 14 Dec 2012 16:01:54 +0800 Message-ID: Subject: R244200 rpi-freebsd.sh build error From: "dev, dev" To: freebsd-arm@freebsd.org X-Gm-Message-State: ALoCoQkZNsjnWqs9+LmHebPandoDnFlctXNo7gZeH1Se2SxyIOODWaXzfLyf6xEjB6eCQFmk6ra3 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 08:02:03 -0000 use RPI-Bsc kernel config file run rpi-freebsd.sh build script, last error message: rm -f .newdep make -V CFILES_NOZFS -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/dev/ath -I/usr/src/sys/dev/ath/ath_hal -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -I/usr/src/sys/dev/cxgb -I/usr/src/sys/dev/cxgbe -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -ffreestanding /usr/src/sys/dev/random/probe.c:32:21: error: opt_cpu.h: No such file or directory /usr/src/sys/dev/random/probe.c:46:30: error: machine/cputypes.h: No such file or directory /usr/src/sys/dev/random/probe.c:48:32: error: machine/specialreg.h: No such file or directory /usr/src/sys/dev/syscons/schistory.c:49:32: error: machine/pc/display.h: No such file or directory /usr/src/sys/dev/syscons/syscons.c:69:32: error: machine/pc/display.h: No such file or directory /usr/src/sys/dev/syscons/scterm-teken.c:47:32: error: machine/pc/display.h: No such file or directory mkdep: compile failed *** [.depend] Error code 1 Stop in /usr/obj-rpi/arm.arm/usr/src/sys/RPI-Bsc. *** [buildkernel] Error code 1 Stop in /usr/src. *** [buildkernel] Error code 1 Stop in /usr/src. yarshure From owner-freebsd-arm@FreeBSD.ORG Fri Dec 14 20:54:36 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (unknown [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7428E1EED for ; Fri, 14 Dec 2012 20:54:36 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [88.198.91.248]) by mx1.freebsd.org (Postfix) with ESMTP id E573C8FC12 for ; Fri, 14 Dec 2012 20:54:35 +0000 (UTC) Received: from [88.198.91.248] (helo=[IPv6:::1]) by id.bluezbox.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TjcH3-000OFi-SF for freebsd-arm@freebsd.org; Fri, 14 Dec 2012 12:54:28 -0800 Message-ID: <50CB91FE.7050908@bluezbox.com> Date: Fri, 14 Dec 2012 12:54:22 -0800 From: Oleksandr Tymoshenko User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: Unsolved problem with WB caches on ARMv6 References: <37F24B3C-4600-4E57-96EB-98C91FCD2B72@bluezbox.com> In-Reply-To: <37F24B3C-4600-4E57-96EB-98C91FCD2B72@bluezbox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 12/9/2012 10:24 PM, Oleksandr Tymoshenko wrote: > Hello, > > One of the long-time issues with FreeBSD/ARMv6 is that Write-Back cache > mode does not work properly. On PandaBoard changing cache mode to WB from WT > causesUSB glitches (starting from stalls to network packets corruption) and random > memory corruptions that manifest themselves as a userland programs crashes. > > gber@ tracked down one of the bugs several month ago, but it's still unusable > at least on my setup. > > I spent some time debugging through busdma and USB code but failed to find > anything fishy. PandaBoard's USB host controller is EHCI. QH and QTDs are > flushed properly. Corruption pattern in packets is weird: it's not cacheline-size > it's like chunk of data is just missing from bulk transfer DMA buffer. L2 cache > is disabled. > > The issue is not reproducible in QEMU. > > Fix for arm/160431 applied to busdma-v6.c didn't help. > > I'm out of ideas for now. May be Ian or Alan will have some suggestions where to look? > > If you have setup with armv6 devices, I'd appreciate test results for this patch: > http://people.freebsd.org/~gonzo/patches/armv6-wb.diff > Just wondering if results differ from platform to platform. Following up on this one. [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 20:54:36 -0000 On 12/9/2012 10:24 PM, Oleksandr Tymoshenko wrote: > Hello, > > One of the long-time issues with FreeBSD/ARMv6 is that Write-Back cache > mode does not work properly. On PandaBoard changing cache mode to WB from WT > causesUSB glitches (starting from stalls to network packets corruption) and random > memory corruptions that manifest themselves as a userland programs crashes. > > gber@ tracked down one of the bugs several month ago, but it's still unusable > at least on my setup. > > I spent some time debugging through busdma and USB code but failed to find > anything fishy. PandaBoard's USB host controller is EHCI. QH and QTDs are > flushed properly. Corruption pattern in packets is weird: it's not cacheline-size > it's like chunk of data is just missing from bulk transfer DMA buffer. L2 cache > is disabled. > > The issue is not reproducible in QEMU. > > Fix for arm/160431 applied to busdma-v6.c didn't help. > > I'm out of ideas for now. May be Ian or Alan will have some suggestions where to look? > > If you have setup with armv6 devices, I'd appreciate test results for this patch: > http://people.freebsd.org/~gonzo/patches/armv6-wb.diff > Just wondering if results differ from platform to platform. Following up on this one. For pandaboard it seems to be a bunch of problems, actually, not just one: Issues with known fixes: - Some additional pmap flushes/syncs, andrew@ is working on it. - I-Cache should be synced in pmap_enter_locked (otherwise userland programs cash in random places) - PL310 errata workaround wasn't functioning properly because DEBUG and CONTROL registers are not available for direct access in secureboot mode. So when I told it was disabled - actually it wasn't. Still working on: - Switching from WT to WB cache mode somehow affects EHCI internal works so occasionally parts of bulk IN transfers are lost. Adding delay after setting IAAD flag cures corruption. It's definitely not DMA/cache problem per se. From owner-freebsd-arm@FreeBSD.ORG Fri Dec 14 21:26:21 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DB800C34 for ; Fri, 14 Dec 2012 21:26:21 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [88.198.91.248]) by mx1.freebsd.org (Postfix) with ESMTP id 67EF88FC12 for ; Fri, 14 Dec 2012 21:26:21 +0000 (UTC) Received: from [88.198.91.248] (helo=[IPv6:::1]) by id.bluezbox.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Tjclu-000OZa-FJ; Fri, 14 Dec 2012 13:26:20 -0800 Message-ID: <50CB9976.9000904@bluezbox.com> Date: Fri, 14 Dec 2012 13:26:14 -0800 From: Oleksandr Tymoshenko User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "dev, dev" Subject: Re: R244200 rpi-freebsd.sh build error References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 12/14/2012 12:01 AM, dev, dev wrote: > use RPI-Bsc kernel config file > run rpi-freebsd.sh build script, last error message: > > rm -f .newdep > make -V CFILES_NOZFS -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" > CC="cc" xargs mkdep -a -f .newdep -O -pipe -std=c99 -g -Wall > -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs > -fdiagnostics-show-option -nostdinc -I. -I/usr/src/sys > -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter > -I/usr/src/sys/dev/ath -I/usr/src/sys/dev/ath/ath_hal > -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -I/usr/src/sys/dev/cxgb > -I/usr/src/sys/dev/cxgbe -I/usr/src/sys/contrib/libfdt -D_KERNEL > -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common > -finline-limit=8000 --param inline-unit-growth=100 --param > large-function-growth=1000 -ffreestanding > /usr/src/sys/dev/random/probe.c:32:21: error: opt_cpu.h: No such file or > directory > /usr/src/sys/dev/random/probe.c:46:30: error: machine/cputypes.h: No such > file or directory > /usr/src/sys/dev/random/probe.c:48:32: error: machine/specialreg.h: No such > file or directory > /usr/src/sys/dev/syscons/schistory.c:49:32: error: machine/pc/display.h: No > such file or directory > /usr/src/sys/dev/syscons/syscons.c:69:32: error: machine/pc/display.h: No > such file or directory > /usr/src/sys/dev/syscons/scterm-teken.c:47:32: error: machine/pc/display.h: > No such file or directory > mkdep: compile failed > *** [.depend] Error code 1 > > Stop in /usr/obj-rpi/arm.arm/usr/src/sys/RPI-Bsc. > *** [buildkernel] Error code 1 > > Stop in /usr/src. > *** [buildkernel] Error code 1 > > Stop in /usr/src. [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 21:26:21 -0000 On 12/14/2012 12:01 AM, dev, dev wrote: > use RPI-Bsc kernel config file > run rpi-freebsd.sh build script, last error message: > > rm -f .newdep > make -V CFILES_NOZFS -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" > CC="cc" xargs mkdep -a -f .newdep -O -pipe -std=c99 -g -Wall > -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs > -fdiagnostics-show-option -nostdinc -I. -I/usr/src/sys > -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter > -I/usr/src/sys/dev/ath -I/usr/src/sys/dev/ath/ath_hal > -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -I/usr/src/sys/dev/cxgb > -I/usr/src/sys/dev/cxgbe -I/usr/src/sys/contrib/libfdt -D_KERNEL > -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common > -finline-limit=8000 --param inline-unit-growth=100 --param > large-function-growth=1000 -ffreestanding > /usr/src/sys/dev/random/probe.c:32:21: error: opt_cpu.h: No such file or > directory > /usr/src/sys/dev/random/probe.c:46:30: error: machine/cputypes.h: No such > file or directory > /usr/src/sys/dev/random/probe.c:48:32: error: machine/specialreg.h: No such > file or directory > /usr/src/sys/dev/syscons/schistory.c:49:32: error: machine/pc/display.h: No > such file or directory > /usr/src/sys/dev/syscons/syscons.c:69:32: error: machine/pc/display.h: No > such file or directory > /usr/src/sys/dev/syscons/scterm-teken.c:47:32: error: machine/pc/display.h: > No such file or directory > mkdep: compile failed > *** [.depend] Error code 1 > > Stop in /usr/obj-rpi/arm.arm/usr/src/sys/RPI-Bsc. > *** [buildkernel] Error code 1 > > Stop in /usr/src. > *** [buildkernel] Error code 1 > > Stop in /usr/src. Looks like kernel-toolchain hasn't been done before buildkernel. If you;re using script from this page: http://c32.no-ip.com/R-PI/ it seems to be obsolete. Please use newer script: http://people.freebsd.org/~gonzo/arm/rpi/build-pi-image.sh From owner-freebsd-arm@FreeBSD.ORG Sat Dec 15 16:40:42 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6682692C for ; Sat, 15 Dec 2012 16:40:42 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from cpsmtpb-ews05.kpnxchange.com (cpsmtpb-ews05.kpnxchange.com [213.75.39.8]) by mx1.freebsd.org (Postfix) with ESMTP id B7DF78FC0A for ; Sat, 15 Dec 2012 16:40:41 +0000 (UTC) Received: from cpsps-ews24.kpnxchange.com ([10.94.84.190]) by cpsmtpb-ews05.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Sat, 15 Dec 2012 17:38:38 +0100 Received: from CPSMTPM-TLF101.kpnxchange.com ([195.121.3.4]) by cpsps-ews24.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Sat, 15 Dec 2012 17:38:38 +0100 Received: from sjakie.klop.ws ([212.182.167.131]) by CPSMTPM-TLF101.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Sat, 15 Dec 2012 17:39:33 +0100 Received: from 212-182-167-131.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id EAC184235 for ; Sat, 15 Dec 2012 17:39:32 +0100 (CET) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-arm@freebsd.org Subject: Re: sheevaplug boot from nandfs hangs References: <1355364418.87661.489.camel@revolution.hippie.lan> Date: Sat, 15 Dec 2012 17:39:31 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: <1355364418.87661.489.camel@revolution.hippie.lan> User-Agent: Opera Mail/12.11 (FreeBSD) X-OriginalArrivalTime: 15 Dec 2012 16:39:33.0292 (UTC) FILETIME=[C3045EC0:01CDDAE2] X-RcptDomain: freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 16:40:42 -0000 On Thu, 13 Dec 2012 03:06:58 +0100, Ian Lepore wrote: > On Thu, 2012-12-13 at 02:06 +0100, Ronald Klop wrote: >> Hello, >> >> I succeeded in installing and booting my kernel (SHEEVAPLUG 10-current >> from 22 nov.) from nandfs. I followed all the advise at >> http://wiki.freebsd.org/NAND. But the rootfs will not mount/start. >> >> The end of the bootinfo is this: >> cryptosoft0: >> Timecounters tick every 1.000 msec >> ipfw2 initialized, divert loadable, nat loadable, default to accept, >> logging disabled >> usbus0: 480Mbps High Speed USB v2.0 >> ugen0.1: at usbus0 >> uhub0: on >> usbus0 >> uhub0: 1 port with 1 removable, self powered >> Root mount waiting for: usbus0 >> ugen0.2: at usbus0 >> umass0: on >> usbus0 >> umass0: SCSI over Bulk-Only; quirks = 0x4000 >> umass0:0:0:-1: Attached to scbus0 >> Trying to mount root from nandfs:/dev/gnand0s.root []... >> WARNING: NANDFS is considered to be a highly experimental feature in >> FreeBSD. >> (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 >> (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an >> error >> (probe0:umass-sim0:0:0:0): Retrying command >> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 >> da0: Removable Direct Access SCSI-0 >> device >> da0: 40.000MB/s transfers >> da0: 3894MB (7975296 512 byte sectors: 255H 63S/T 496C) >> >> The kernel is responsive because if I remove or insert the usb stick it >> displays messages about it. (Not shown above) >> I'm connected via serial. What could be wrong? What information can I >> give >> more? >> I installed /dev/gnand0s.root by tarring the content of / on my usb >> stick >> to the mounted /dev/gnand0s.root. That looked ok. >> >> Regards, >> Ronald. > > Hmm, so the root mount happens, but init never gets started, or never > gets far enough to show signs of being started. Mounting root is > invoked from sys/kern/init_main.c, I guess what I'd do next is add some > printfs in there to see if vfs_mountroot() is returning and if so how > much farther it gets. > > Hmmm, if your kernel is built with ALT_BREAK_TO_DEBUGGER then on the > serial console maybe you can CR ~ ^B and poke around. Hmmm, or maybe > not, because I just tried that on my dreamplug and it just spewed this > many times: > > root@dpcur:/root # ~KDB: enter: Break to debugger > [ thread pid 10 tid 100002 ] > Stopped at kdb_enter+0x48:panic: mtx_lock() by idle thread > 0xc3593c00 on sleep mutex pmap @ > /local/build/staging/freebsd/dp10/src/sys/arm/arm/pmap.c:3662 > panic: mtx_lock() by idle thread 0xc3593c00 on sleep mutex eventhandler > @ /local/build/staging/freebsd/dp10/src/sys/kern/subr_eventhandler.c:251 > KDB: enter: panic > > and apparently recursed until it ran out of stack and locked up. > > So I guess it'll be printf-debugging to the rescue. :) > > I can confirm that this should be working. I've got a similar setup > going on Atmel arm chips, although I haven't sync'd up with -current for > a while, I'm at r241077 on that project. Right now I still load the > kernel from sdcard but root gets mounted from the nand and the system > runs. Performance is horrible (this is a low end arm, 180mhz), but it > works. > > > nand0: mem 0xe0000000-0xefffffff on > atmelarm0 > nandbus0: on nand0 > onand0: on nandbus0 > onand0: Found BBT table for chip > Timecounters tick every 10.000 msec > usbus0: 12Mbps Full Speed USB v1.0 > ugen0.1: at usbus0 > uhub0: on usbus0 > mmcsd0: 1876MB at mmc0 > 22.5MHz/1bit/64-block > Root mount waiting for: usbus0 > uhub0: 2 ports with 2 removable, self powered > Root mount waiting for: usbus0 > ugen0.2: at usbus0 > Root mount waiting for: usbus0 > Root mount waiting for: usbus0 > ugen0.3: at usbus0 (disconnected) > Trying to mount root from nandfs:/dev/gnand0s.root []... > WARNING: NANDFS is considered to be a highly experimental feature in > FreeBSD. > warning: no time-of-day clock registered, system time will not be set > accurately > Starting file system checks: > > -- Ian Hi, Thanks for the hint. Compiling a new kernel with printf now. I saw bootverbose also prints more information. How do I enable that on ARM from the bootprompt? NB: break to debugger works on my Sheevaplug. But I am not familiar with its commands to see what it is doing. Can I force a coredump and would somebody be interested to look at it? Ronald. From owner-freebsd-arm@FreeBSD.ORG Sat Dec 15 17:52:33 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2BFDBCE5 for ; Sat, 15 Dec 2012 17:52:33 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from cpsmtpb-ews09.kpnxchange.com (cpsmtpb-ews09.kpnxchange.com [213.75.39.14]) by mx1.freebsd.org (Postfix) with ESMTP id 7CB4E8FC1B for ; Sat, 15 Dec 2012 17:52:31 +0000 (UTC) Received: from cpsps-ews25.kpnxchange.com ([10.94.84.191]) by cpsmtpb-ews09.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Sat, 15 Dec 2012 18:50:28 +0100 Received: from CPSMTPM-TLF103.kpnxchange.com ([195.121.3.6]) by cpsps-ews25.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Sat, 15 Dec 2012 18:50:28 +0100 Received: from sjakie.klop.ws ([212.182.167.131]) by CPSMTPM-TLF103.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Sat, 15 Dec 2012 18:51:24 +0100 Received: from 212-182-167-131.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id 8597E44AE for ; Sat, 15 Dec 2012 18:51:23 +0100 (CET) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-arm@freebsd.org Subject: Re: sheevaplug boot from nandfs hangs References: <1355364418.87661.489.camel@revolution.hippie.lan> Date: Sat, 15 Dec 2012 18:51:23 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.11 (FreeBSD) X-OriginalArrivalTime: 15 Dec 2012 17:51:24.0288 (UTC) FILETIME=[CC922800:01CDDAEC] X-RcptDomain: freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 17:52:33 -0000 On Sat, 15 Dec 2012 17:39:31 +0100, Ronald Klop wrote: > On Thu, 13 Dec 2012 03:06:58 +0100, Ian Lepore > wrote: > >> On Thu, 2012-12-13 at 02:06 +0100, Ronald Klop wrote: >>> Hello, >>> >>> I succeeded in installing and booting my kernel (SHEEVAPLUG 10-current >>> from 22 nov.) from nandfs. I followed all the advise at >>> http://wiki.freebsd.org/NAND. But the rootfs will not mount/start. >>> >>> The end of the bootinfo is this: >>> cryptosoft0: >>> Timecounters tick every 1.000 msec >>> ipfw2 initialized, divert loadable, nat loadable, default to accept, >>> logging disabled >>> usbus0: 480Mbps High Speed USB v2.0 >>> ugen0.1: at usbus0 >>> uhub0: on >>> usbus0 >>> uhub0: 1 port with 1 removable, self powered >>> Root mount waiting for: usbus0 >>> ugen0.2: at usbus0 >>> umass0: on >>> usbus0 >>> umass0: SCSI over Bulk-Only; quirks = 0x4000 >>> umass0:0:0:-1: Attached to scbus0 >>> Trying to mount root from nandfs:/dev/gnand0s.root []... >>> WARNING: NANDFS is considered to be a highly experimental feature in >>> FreeBSD. >>> (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 >>> (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an >>> error >>> (probe0:umass-sim0:0:0:0): Retrying command >>> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 >>> da0: Removable Direct Access SCSI-0 >>> device >>> da0: 40.000MB/s transfers >>> da0: 3894MB (7975296 512 byte sectors: 255H 63S/T 496C) >>> >>> The kernel is responsive because if I remove or insert the usb stick it >>> displays messages about it. (Not shown above) >>> I'm connected via serial. What could be wrong? What information can I >>> give >>> more? >>> I installed /dev/gnand0s.root by tarring the content of / on my usb >>> stick >>> to the mounted /dev/gnand0s.root. That looked ok. >>> >>> Regards, >>> Ronald. >> >> Hmm, so the root mount happens, but init never gets started, or never >> gets far enough to show signs of being started. Mounting root is >> invoked from sys/kern/init_main.c, I guess what I'd do next is add some >> printfs in there to see if vfs_mountroot() is returning and if so how >> much farther it gets. >> >> Hmmm, if your kernel is built with ALT_BREAK_TO_DEBUGGER then on the >> serial console maybe you can CR ~ ^B and poke around. Hmmm, or maybe >> not, because I just tried that on my dreamplug and it just spewed this >> many times: >> >> root@dpcur:/root # ~KDB: enter: Break to debugger >> [ thread pid 10 tid 100002 ] >> Stopped at kdb_enter+0x48:panic: mtx_lock() by idle thread >> 0xc3593c00 on sleep mutex pmap @ >> /local/build/staging/freebsd/dp10/src/sys/arm/arm/pmap.c:3662 >> panic: mtx_lock() by idle thread 0xc3593c00 on sleep mutex eventhandler >> @ /local/build/staging/freebsd/dp10/src/sys/kern/subr_eventhandler.c:251 >> KDB: enter: panic >> >> and apparently recursed until it ran out of stack and locked up. >> >> So I guess it'll be printf-debugging to the rescue. :) >> >> I can confirm that this should be working. I've got a similar setup >> going on Atmel arm chips, although I haven't sync'd up with -current for >> a while, I'm at r241077 on that project. Right now I still load the >> kernel from sdcard but root gets mounted from the nand and the system >> runs. Performance is horrible (this is a low end arm, 180mhz), but it >> works. >> >> >> nand0: mem 0xe0000000-0xefffffff on >> atmelarm0 >> nandbus0: on nand0 >> onand0: on nandbus0 >> onand0: Found BBT table for chip >> Timecounters tick every 10.000 msec >> usbus0: 12Mbps Full Speed USB v1.0 >> ugen0.1: at usbus0 >> uhub0: on usbus0 >> mmcsd0: 1876MB at mmc0 >> 22.5MHz/1bit/64-block >> Root mount waiting for: usbus0 >> uhub0: 2 ports with 2 removable, self powered >> Root mount waiting for: usbus0 >> ugen0.2: at usbus0 >> Root mount waiting for: usbus0 >> Root mount waiting for: usbus0 >> ugen0.3: at usbus0 (disconnected) >> Trying to mount root from nandfs:/dev/gnand0s.root []... >> WARNING: NANDFS is considered to be a highly experimental feature in >> FreeBSD. >> warning: no time-of-day clock registered, system time will not be set >> accurately >> Starting file system checks: >> >> -- Ian > > Hi, > > Thanks for the hint. Compiling a new kernel with printf now. I saw > bootverbose also prints more information. How do I enable that on ARM > from the bootprompt? > NB: break to debugger works on my Sheevaplug. But I am not familiar with > its commands to see what it is doing. Can I force a coredump and would > somebody be interested to look at it? > > Ronald. I also defaulted bootverbose to 1 in init_main.c. Now I get this. ipfw2 initialized, divert loadable, nat loadable, default to accept, logging disabled lo0: bpf attached GEOM: new disk gnand0 GEOM: new disk gnand.raw0 usbus0: 480Mbps High Speed USB v2.0 gnand0: slice 00000000-001fffff: u-boot (2047KB) gnand0: slice 00200000-007fffff: fbsd-boot (6143KB) gnand0: slice 00800000-1fffffff: root (516095KB) ugen0.1: at usbus0 uhub0: on usbus0 gnand.raw0: slice 00000000-001fffff: u-boot (2047KB) gnand.raw0: slice 00200000-007fffff: fbsd-boot (6143KB) gnand.raw0: slice 00800000-1fffffff: root (516095KB) uhub0: 1 port with 1 removable, self powered Trying to mount root from nandfs:/dev/gnand0s.root []... WARNING: NANDFS is considered to be a highly experimental feature in FreeBSD. mountroot: unable to remount devfs under /dev (error 2). mountroot: unable to unlink /dev/dev (error 2) after vfs_mountroot() start_init: trying /sbin/init The 'after vfs_mountroot()' is my own printf. I also verified sys_execve of /sbin/init returned 0. How do I go from here? Ronald. From owner-freebsd-arm@FreeBSD.ORG Sat Dec 15 18:19:17 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A8A56CD8 for ; Sat, 15 Dec 2012 18:19:17 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 5F6F68FC13 for ; Sat, 15 Dec 2012 18:19:17 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qBFIJ91c056253 for ; Sat, 15 Dec 2012 11:19:10 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qBFIIvvB060550; Sat, 15 Dec 2012 11:18:57 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: sheevaplug boot from nandfs hangs From: Ian Lepore To: Ronald Klop In-Reply-To: References: <1355364418.87661.489.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Sat, 15 Dec 2012 11:18:57 -0700 Message-ID: <1355595537.1198.72.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 18:19:17 -0000 On Sat, 2012-12-15 at 18:51 +0100, Ronald Klop wrote: > On Sat, 15 Dec 2012 17:39:31 +0100, Ronald Klop > wrote: > > > On Thu, 13 Dec 2012 03:06:58 +0100, Ian Lepore > > wrote: > > > >> On Thu, 2012-12-13 at 02:06 +0100, Ronald Klop wrote: > >>> Hello, > >>> > >>> I succeeded in installing and booting my kernel (SHEEVAPLUG 10-current > >>> from 22 nov.) from nandfs. I followed all the advise at > >>> http://wiki.freebsd.org/NAND. But the rootfs will not mount/start. > >>> > >>> The end of the bootinfo is this: > >>> cryptosoft0: > >>> Timecounters tick every 1.000 msec > >>> ipfw2 initialized, divert loadable, nat loadable, default to accept, > >>> logging disabled > >>> usbus0: 480Mbps High Speed USB v2.0 > >>> ugen0.1: at usbus0 > >>> uhub0: on > >>> usbus0 > >>> uhub0: 1 port with 1 removable, self powered > >>> Root mount waiting for: usbus0 > >>> ugen0.2: at usbus0 > >>> umass0: on > >>> usbus0 > >>> umass0: SCSI over Bulk-Only; quirks = 0x4000 > >>> umass0:0:0:-1: Attached to scbus0 > >>> Trying to mount root from nandfs:/dev/gnand0s.root []... > >>> WARNING: NANDFS is considered to be a highly experimental feature in > >>> FreeBSD. > >>> (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 > >>> (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an > >>> error > >>> (probe0:umass-sim0:0:0:0): Retrying command > >>> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > >>> da0: Removable Direct Access SCSI-0 > >>> device > >>> da0: 40.000MB/s transfers > >>> da0: 3894MB (7975296 512 byte sectors: 255H 63S/T 496C) > >>> > >>> The kernel is responsive because if I remove or insert the usb stick it > >>> displays messages about it. (Not shown above) > >>> I'm connected via serial. What could be wrong? What information can I > >>> give > >>> more? > >>> I installed /dev/gnand0s.root by tarring the content of / on my usb > >>> stick > >>> to the mounted /dev/gnand0s.root. That looked ok. > >>> > >>> Regards, > >>> Ronald. > >> > >> Hmm, so the root mount happens, but init never gets started, or never > >> gets far enough to show signs of being started. Mounting root is > >> invoked from sys/kern/init_main.c, I guess what I'd do next is add some > >> printfs in there to see if vfs_mountroot() is returning and if so how > >> much farther it gets. > >> > >> Hmmm, if your kernel is built with ALT_BREAK_TO_DEBUGGER then on the > >> serial console maybe you can CR ~ ^B and poke around. Hmmm, or maybe > >> not, because I just tried that on my dreamplug and it just spewed this > >> many times: > >> > >> root@dpcur:/root # ~KDB: enter: Break to debugger > >> [ thread pid 10 tid 100002 ] > >> Stopped at kdb_enter+0x48:panic: mtx_lock() by idle thread > >> 0xc3593c00 on sleep mutex pmap @ > >> /local/build/staging/freebsd/dp10/src/sys/arm/arm/pmap.c:3662 > >> panic: mtx_lock() by idle thread 0xc3593c00 on sleep mutex eventhandler > >> @ /local/build/staging/freebsd/dp10/src/sys/kern/subr_eventhandler.c:251 > >> KDB: enter: panic > >> > >> and apparently recursed until it ran out of stack and locked up. > >> > >> So I guess it'll be printf-debugging to the rescue. :) > >> > >> I can confirm that this should be working. I've got a similar setup > >> going on Atmel arm chips, although I haven't sync'd up with -current for > >> a while, I'm at r241077 on that project. Right now I still load the > >> kernel from sdcard but root gets mounted from the nand and the system > >> runs. Performance is horrible (this is a low end arm, 180mhz), but it > >> works. > >> > >> > >> nand0: mem 0xe0000000-0xefffffff on > >> atmelarm0 > >> nandbus0: on nand0 > >> onand0: on nandbus0 > >> onand0: Found BBT table for chip > >> Timecounters tick every 10.000 msec > >> usbus0: 12Mbps Full Speed USB v1.0 > >> ugen0.1: at usbus0 > >> uhub0: on usbus0 > >> mmcsd0: 1876MB at mmc0 > >> 22.5MHz/1bit/64-block > >> Root mount waiting for: usbus0 > >> uhub0: 2 ports with 2 removable, self powered > >> Root mount waiting for: usbus0 > >> ugen0.2: at usbus0 > >> Root mount waiting for: usbus0 > >> Root mount waiting for: usbus0 > >> ugen0.3: at usbus0 (disconnected) > >> Trying to mount root from nandfs:/dev/gnand0s.root []... > >> WARNING: NANDFS is considered to be a highly experimental feature in > >> FreeBSD. > >> warning: no time-of-day clock registered, system time will not be set > >> accurately > >> Starting file system checks: > >> > >> -- Ian > > > > Hi, > > > > Thanks for the hint. Compiling a new kernel with printf now. I saw > > bootverbose also prints more information. How do I enable that on ARM > > from the bootprompt? > > NB: break to debugger works on my Sheevaplug. But I am not familiar with > > its commands to see what it is doing. Can I force a coredump and would > > somebody be interested to look at it? > > > > Ronald. > > I also defaulted bootverbose to 1 in init_main.c. Now I get this. > > ipfw2 initialized, divert loadable, nat loadable, default to accept, > logging disabled > lo0: bpf attached > GEOM: new disk gnand0 > GEOM: new disk gnand.raw0 > usbus0: 480Mbps High Speed USB v2.0 > gnand0: slice 00000000-001fffff: u-boot (2047KB) > gnand0: slice 00200000-007fffff: fbsd-boot (6143KB) > gnand0: slice 00800000-1fffffff: root (516095KB) > ugen0.1: at usbus0 > uhub0: on usbus0 > gnand.raw0: slice 00000000-001fffff: u-boot (2047KB) > gnand.raw0: slice 00200000-007fffff: fbsd-boot (6143KB) > gnand.raw0: slice 00800000-1fffffff: root (516095KB) > uhub0: 1 port with 1 removable, self powered > Trying to mount root from nandfs:/dev/gnand0s.root []... > WARNING: NANDFS is considered to be a highly experimental feature in > FreeBSD. > mountroot: unable to remount devfs under /dev (error 2). > mountroot: unable to unlink /dev/dev (error 2) > after vfs_mountroot() > start_init: trying /sbin/init > > The 'after vfs_mountroot()' is my own printf. I also verified sys_execve > of /sbin/init returned 0. > How do I go from here? Wow, this is all very familiar. I had this exact situation a couple months ago as I was trying to get freebsd running on my pico-sam9g45 eval board. My printfs showed exactly the same thing, the execve returned 0, but I never got any indication that init was actually running, nor did it die as near as I could tell, the system just went comatose. I can't quite remember how I tracked down the problem from there. Oh hey, I just noticed in your verbose output, that "unable to remount devfs under /dev", that's significant. init has this annoying tendancy to silently lock up if it can't open devices such as serial lines that are mentioned in /etc/ttys (also, if /etc/ttys is missing). I'll bet you just need to create a /dev mountpoint in your nandfs and everything will get better. There may be other mountpoints (/tmp, /var, etc) that didn't get created properly too. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat Dec 15 19:08:13 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E3059A8F for ; Sat, 15 Dec 2012 19:08:13 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from cpsmtpb-ews04.kpnxchange.com (cpsmtpb-ews04.kpnxchange.com [213.75.39.7]) by mx1.freebsd.org (Postfix) with ESMTP id 2E0B98FC0A for ; Sat, 15 Dec 2012 19:08:12 +0000 (UTC) Received: from cpsps-ews22.kpnxchange.com ([10.94.84.188]) by cpsmtpb-ews04.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Sat, 15 Dec 2012 20:06:10 +0100 Received: from CPSMTPM-TLF104.kpnxchange.com ([195.121.3.7]) by cpsps-ews22.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Sat, 15 Dec 2012 20:06:10 +0100 Received: from sjakie.klop.ws ([212.182.167.131]) by CPSMTPM-TLF104.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Sat, 15 Dec 2012 20:07:05 +0100 Received: from 212-182-167-131.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id 7BFCB4524 for ; Sat, 15 Dec 2012 20:07:04 +0100 (CET) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-arm@freebsd.org Subject: Re: sheevaplug boot from nandfs hangs References: <1355364418.87661.489.camel@revolution.hippie.lan> <1355595537.1198.72.camel@revolution.hippie.lan> Date: Sat, 15 Dec 2012 20:07:02 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: <1355595537.1198.72.camel@revolution.hippie.lan> User-Agent: Opera Mail/12.11 (FreeBSD) X-OriginalArrivalTime: 15 Dec 2012 19:07:05.0604 (UTC) FILETIME=[5F67FC40:01CDDAF7] X-RcptDomain: freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 19:08:14 -0000 On Sat, 15 Dec 2012 19:18:57 +0100, Ian Lepore wrote: > On Sat, 2012-12-15 at 18:51 +0100, Ronald Klop wrote: >> On Sat, 15 Dec 2012 17:39:31 +0100, Ronald Klop >> wrote: >> >> > On Thu, 13 Dec 2012 03:06:58 +0100, Ian Lepore >> > wrote: >> > >> >> On Thu, 2012-12-13 at 02:06 +0100, Ronald Klop wrote: >> >>> Hello, >> >>> >> >>> I succeeded in installing and booting my kernel (SHEEVAPLUG >> 10-current >> >>> from 22 nov.) from nandfs. I followed all the advise at >> >>> http://wiki.freebsd.org/NAND. But the rootfs will not mount/start. >> >>> >> >>> The end of the bootinfo is this: >> >>> cryptosoft0: >> >>> Timecounters tick every 1.000 msec >> >>> ipfw2 initialized, divert loadable, nat loadable, default to accept, >> >>> logging disabled >> >>> usbus0: 480Mbps High Speed USB v2.0 >> >>> ugen0.1: at usbus0 >> >>> uhub0: on >> >>> usbus0 >> >>> uhub0: 1 port with 1 removable, self powered >> >>> Root mount waiting for: usbus0 >> >>> ugen0.2: at usbus0 >> >>> umass0: > 2> on >> >>> usbus0 >> >>> umass0: SCSI over Bulk-Only; quirks = 0x4000 >> >>> umass0:0:0:-1: Attached to scbus0 >> >>> Trying to mount root from nandfs:/dev/gnand0s.root []... >> >>> WARNING: NANDFS is considered to be a highly experimental feature in >> >>> FreeBSD. >> >>> (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 >> >>> (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an >> >>> error >> >>> (probe0:umass-sim0:0:0:0): Retrying command >> >>> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 >> >>> da0: Removable Direct Access SCSI-0 >> >>> device >> >>> da0: 40.000MB/s transfers >> >>> da0: 3894MB (7975296 512 byte sectors: 255H 63S/T 496C) >> >>> >> >>> The kernel is responsive because if I remove or insert the usb >> stick it >> >>> displays messages about it. (Not shown above) >> >>> I'm connected via serial. What could be wrong? What information can >> I >> >>> give >> >>> more? >> >>> I installed /dev/gnand0s.root by tarring the content of / on my usb >> >>> stick >> >>> to the mounted /dev/gnand0s.root. That looked ok. >> >>> >> >>> Regards, >> >>> Ronald. >> >> >> >> Hmm, so the root mount happens, but init never gets started, or never >> >> gets far enough to show signs of being started. Mounting root is >> >> invoked from sys/kern/init_main.c, I guess what I'd do next is add >> some >> >> printfs in there to see if vfs_mountroot() is returning and if so how >> >> much farther it gets. >> >> >> >> Hmmm, if your kernel is built with ALT_BREAK_TO_DEBUGGER then on the >> >> serial console maybe you can CR ~ ^B and poke around. Hmmm, or maybe >> >> not, because I just tried that on my dreamplug and it just spewed >> this >> >> many times: >> >> >> >> root@dpcur:/root # ~KDB: enter: Break to debugger >> >> [ thread pid 10 tid 100002 ] >> >> Stopped at kdb_enter+0x48:panic: mtx_lock() by idle thread >> >> 0xc3593c00 on sleep mutex pmap @ >> >> /local/build/staging/freebsd/dp10/src/sys/arm/arm/pmap.c:3662 >> >> panic: mtx_lock() by idle thread 0xc3593c00 on sleep mutex >> eventhandler >> >> @ >> /local/build/staging/freebsd/dp10/src/sys/kern/subr_eventhandler.c:251 >> >> KDB: enter: panic >> >> >> >> and apparently recursed until it ran out of stack and locked up. >> >> >> >> So I guess it'll be printf-debugging to the rescue. :) >> >> >> >> I can confirm that this should be working. I've got a similar setup >> >> going on Atmel arm chips, although I haven't sync'd up with -current >> for >> >> a while, I'm at r241077 on that project. Right now I still load the >> >> kernel from sdcard but root gets mounted from the nand and the system >> >> runs. Performance is horrible (this is a low end arm, 180mhz), but >> it >> >> works. >> >> >> >> >> >> nand0: mem 0xe0000000-0xefffffff on >> >> atmelarm0 >> >> nandbus0: on nand0 >> >> onand0: on nandbus0 >> >> onand0: Found BBT table for chip >> >> Timecounters tick every 10.000 msec >> >> usbus0: 12Mbps Full Speed USB v1.0 >> >> ugen0.1: at usbus0 >> >> uhub0: on >> usbus0 >> >> mmcsd0: 1876MB at mmc0 >> >> 22.5MHz/1bit/64-block >> >> Root mount waiting for: usbus0 >> >> uhub0: 2 ports with 2 removable, self powered >> >> Root mount waiting for: usbus0 >> >> ugen0.2: at usbus0 >> >> Root mount waiting for: usbus0 >> >> Root mount waiting for: usbus0 >> >> ugen0.3: at usbus0 (disconnected) >> >> Trying to mount root from nandfs:/dev/gnand0s.root []... >> >> WARNING: NANDFS is considered to be a highly experimental feature in >> >> FreeBSD. >> >> warning: no time-of-day clock registered, system time will not be set >> >> accurately >> >> Starting file system checks: >> >> >> >> -- Ian >> > >> > Hi, >> > >> > Thanks for the hint. Compiling a new kernel with printf now. I saw >> > bootverbose also prints more information. How do I enable that on ARM >> > from the bootprompt? >> > NB: break to debugger works on my Sheevaplug. But I am not familiar >> with >> > its commands to see what it is doing. Can I force a coredump and would >> > somebody be interested to look at it? >> > >> > Ronald. >> >> I also defaulted bootverbose to 1 in init_main.c. Now I get this. >> >> ipfw2 initialized, divert loadable, nat loadable, default to accept, >> logging disabled >> lo0: bpf attached >> GEOM: new disk gnand0 >> GEOM: new disk gnand.raw0 >> usbus0: 480Mbps High Speed USB v2.0 >> gnand0: slice 00000000-001fffff: u-boot (2047KB) >> gnand0: slice 00200000-007fffff: fbsd-boot (6143KB) >> gnand0: slice 00800000-1fffffff: root (516095KB) >> ugen0.1: at usbus0 >> uhub0: on >> usbus0 >> gnand.raw0: slice 00000000-001fffff: u-boot (2047KB) >> gnand.raw0: slice 00200000-007fffff: fbsd-boot (6143KB) >> gnand.raw0: slice 00800000-1fffffff: root (516095KB) >> uhub0: 1 port with 1 removable, self powered >> Trying to mount root from nandfs:/dev/gnand0s.root []... >> WARNING: NANDFS is considered to be a highly experimental feature in >> FreeBSD. >> mountroot: unable to remount devfs under /dev (error 2). >> mountroot: unable to unlink /dev/dev (error 2) >> after vfs_mountroot() >> start_init: trying /sbin/init >> >> The 'after vfs_mountroot()' is my own printf. I also verified sys_execve >> of /sbin/init returned 0. >> How do I go from here? > > Wow, this is all very familiar. I had this exact situation a couple > months ago as I was trying to get freebsd running on my pico-sam9g45 > eval board. My printfs showed exactly the same thing, the execve > returned 0, but I never got any indication that init was actually > running, nor did it die as near as I could tell, the system just went > comatose. > > I can't quite remember how I tracked down the problem from there. > > Oh hey, I just noticed in your verbose output, that "unable to remount > devfs under /dev", that's significant. init has this annoying tendancy > to silently lock up if it can't open devices such as serial lines that > are mentioned in /etc/ttys (also, if /etc/ttys is missing). > > I'll bet you just need to create a /dev mountpoint in your nandfs and > everything will get better. There may be other mountpoints (/tmp, /var, > etc) that didn't get created properly too. > > -- Ian Thank you for your sharp eyes! /dev was missing. When I did tar cf - | tar xf - to copy world from usb disk to nandfs I already had some kind of feeling I was overlooking something. root@sh10:~ # mount /dev/gnand0s.root on / (nandfs, local) devfs on /dev (devfs, local) Ronald. From owner-freebsd-arm@FreeBSD.ORG Sat Dec 15 20:00:00 2012 Return-Path: Delivered-To: freebsd-arm@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C669060D for ; Sat, 15 Dec 2012 20:00:00 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 92A648FC19 for ; Sat, 15 Dec 2012 20:00:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qBFK00cN096503 for ; Sat, 15 Dec 2012 20:00:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qBFK00Ke096502; Sat, 15 Dec 2012 20:00:00 GMT (envelope-from gnats) Resent-Date: Sat, 15 Dec 2012 20:00:00 GMT Resent-Message-Id: <201212152000.qBFK00Ke096502@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-arm@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Ian Lepore Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7D66B549 for ; Sat, 15 Dec 2012 19:57:43 +0000 (UTC) (envelope-from ilepore@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 49A2C8FC14 for ; Sat, 15 Dec 2012 19:57:42 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qBFJvfpn058813 for ; Sat, 15 Dec 2012 12:57:42 -0700 (MST) (envelope-from ilepore@damnhippie.dyndns.org) Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qBFJvdBX060592 for ; Sat, 15 Dec 2012 12:57:39 -0700 (MST) (envelope-from ilepore@damnhippie.dyndns.org) Received: (from ilepore@localhost) by revolution.hippie.lan (8.14.5/8.14.4/Submit) id qBFJvdUo044496; Sat, 15 Dec 2012 12:57:39 -0700 (MST) (envelope-from ilepore) Message-Id: <201212151957.qBFJvdUo044496@revolution.hippie.lan> Date: Sat, 15 Dec 2012 12:57:39 -0700 (MST) From: Ian Lepore To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Subject: arm/174461: [patch] Fix off-by-one in arm9/arm10 cache maintenance routines X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Ian Lepore List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 20:00:00 -0000 >Number: 174461 >Category: arm >Synopsis: [patch] Fix off-by-one in arm9/arm10 cache maintenance routines >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-arm >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Dec 15 20:00:00 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Ian Lepore >Release: FreeBSD 10.0-CURRENT arm >Organization: Symmetricom, Inc. >Environment: FreeBSD dpcur 10.0-CURRENT FreeBSD 10.0-CURRENT #23 r243920M: Sat Dec 15 11:31:47 MST 2012 ilepore@revolution.hippie.lan:/local/build/staging/freebsd/dp10/obj/arm.arm/local/build/staging/freebsd/dp10/src/sys/DP arm >Description: In all the routines that loop through a range of virtual addresses, the loop is controlled by subtracting the cache line size from the total length of the request. After the subtract, a 'bpl' instruction was used, which branches if the result of the subtraction is zero or greater, but we need to exit the loop when the count hits zero. Thus, all the bpl instructions in those loops have been changed to 'bhi' (branch if greater than zero). In addition, the two routines that walk through the cache using set-and-index were correct, but confusing. The loop control for those has been simplified, just so that it's easier to see by examination that the code is correct. Routines for other arm architectures and generations still have the bpl instruction, but compensate for the off-by-one situation by decrementing the count register by one before entering the loop. Just for the sake of consistancy, these should probably all be changed to remove the decrement and use the correct branch instruction. That would then make it easier to see what appears superficially to be lots of duplication in these routines, and some consolidation could happen. >How-To-Repeat: Build a kernel for Atmel ARM with INVARIANTS and INVARIANT_SUPPORT enabled. When it boots, the uart devices fail to instantiate. The reason was that the driver allocates a dma tag, then a dma buffer, and accidentally the tag ended up laid out in memory immediately after the buffer. When the driver did the bus_dmamap_sync(PREREAD) on the buffer, the off-by-one error caused the cache line immediately following that buffer (the first 32 bytes of the dma tag) to be erroniously invalidated. Because of INVARIANTS, the physical memory under that dirty cache line was full of 0xdeadc0de, so the invalidate operation corrupted the dma tag. When the driver then attempted to allocate another buffer using that tag it failed, because the 0xdeadc0de values in the tag led to insane allocation decisions that caused malloc() to fail. Without INVARIANTS, either things end up in different places in memory, or the values in underlying memory that become exposed after the bad invalidate are harmless; either way, it accidentally works right most of the time. >Fix: --- arm9_arm10_cacheops_offbyone_fix.diff begins here --- diff -r 0f2004466772 sys/arm/arm/cpufunc_asm_arm10.S --- sys/arm/arm/cpufunc_asm_arm10.S Thu Dec 06 08:24:00 2012 -0700 +++ sys/arm/arm/cpufunc_asm_arm10.S Sat Dec 15 11:30:41 2012 -0700 @@ -87,7 +87,7 @@ ENTRY_NP(arm10_icache_sync_range) mcr p15, 0, r0, c7, c10, 1 /* Clean D cache SE with VA */ add r0, r0, ip subs r1, r1, ip - bpl .Larm10_sync_next + bhi .Larm10_sync_next mcr p15, 0, r0, c7, c10, 4 /* drain the write buffer */ bx lr @@ -108,12 +108,10 @@ ENTRY_NP(arm10_icache_sync_all) orr ip, s_max, i_max .Lnext_index: mcr p15, 0, ip, c7, c10, 2 /* Clean D cache SE with Set/Index */ - sub ip, ip, i_inc - tst ip, i_max /* Index 0 is last one */ - bne .Lnext_index /* Next index */ - mcr p15, 0, ip, c7, c10, 2 /* Clean D cache SE with Set/Index */ + subs ip, ip, i_inc + bhs .Lnext_index /* Next index */ subs s_max, s_max, s_inc - bpl .Lnext_set /* Next set */ + bhs .Lnext_set /* Next set */ mcr p15, 0, r0, c7, c10, 4 /* drain the write buffer */ bx lr @@ -133,7 +131,7 @@ ENTRY(arm10_dcache_wb_range) mcr p15, 0, r0, c7, c10, 1 /* Clean D cache SE with VA */ add r0, r0, ip subs r1, r1, ip - bpl .Larm10_wb_next + bhi .Larm10_wb_next mcr p15, 0, r0, c7, c10, 4 /* drain the write buffer */ bx lr @@ -150,7 +148,7 @@ ENTRY(arm10_dcache_wbinv_range) mcr p15, 0, r0, c7, c14, 1 /* Purge D cache SE with VA */ add r0, r0, ip subs r1, r1, ip - bpl .Larm10_wbinv_next + bhi .Larm10_wbinv_next mcr p15, 0, r0, c7, c10, 4 /* drain the write buffer */ bx lr @@ -171,7 +169,7 @@ ENTRY(arm10_dcache_inv_range) mcr p15, 0, r0, c7, c6, 1 /* Invalidate D cache SE with VA */ add r0, r0, ip subs r1, r1, ip - bpl .Larm10_inv_next + bhi .Larm10_inv_next mcr p15, 0, r0, c7, c10, 4 /* drain the write buffer */ bx lr @@ -189,7 +187,7 @@ ENTRY(arm10_idcache_wbinv_range) mcr p15, 0, r0, c7, c14, 1 /* Purge D cache SE with VA */ add r0, r0, ip subs r1, r1, ip - bpl .Larm10_id_wbinv_next + bhi .Larm10_id_wbinv_next mcr p15, 0, r0, c7, c10, 4 /* drain the write buffer */ bx lr @@ -211,12 +209,10 @@ ENTRY(arm10_dcache_wbinv_all) orr ip, s_max, i_max .Lnext_index_inv: mcr p15, 0, ip, c7, c14, 2 /* Purge D cache SE with Set/Index */ - sub ip, ip, i_inc - tst ip, i_max /* Index 0 is last one */ - bne .Lnext_index_inv /* Next index */ - mcr p15, 0, ip, c7, c14, 2 /* Purge D cache SE with Set/Index */ + subs ip, ip, i_inc + bhs .Lnext_index_inv /* Next index */ subs s_max, s_max, s_inc - bpl .Lnext_set_inv /* Next set */ + bhs .Lnext_set_inv /* Next set */ mcr p15, 0, r0, c7, c10, 4 /* drain the write buffer */ bx lr diff -r 0f2004466772 sys/arm/arm/cpufunc_asm_arm9.S --- sys/arm/arm/cpufunc_asm_arm9.S Thu Dec 06 08:24:00 2012 -0700 +++ sys/arm/arm/cpufunc_asm_arm9.S Sat Dec 15 11:30:41 2012 -0700 @@ -81,7 +81,7 @@ ENTRY_NP(arm9_icache_sync_range) mcr p15, 0, r0, c7, c10, 1 /* Clean D cache SE with VA */ add r0, r0, ip subs r1, r1, ip - bpl .Larm9_sync_next + bhi .Larm9_sync_next mov pc, lr ENTRY_NP(arm9_icache_sync_all) @@ -101,12 +101,10 @@ ENTRY_NP(arm9_icache_sync_all) orr ip, s_max, i_max .Lnext_index: mcr p15, 0, ip, c7, c10, 2 /* Clean D cache SE with Set/Index */ - sub ip, ip, i_inc - tst ip, i_max /* Index 0 is last one */ - bne .Lnext_index /* Next index */ - mcr p15, 0, ip, c7, c10, 2 /* Clean D cache SE with Set/Index */ + subs ip, ip, i_inc + bhs .Lnext_index /* Next index */ subs s_max, s_max, s_inc - bpl .Lnext_set /* Next set */ + bhs .Lnext_set /* Next set */ mov pc, lr .Larm9_line_size: @@ -125,7 +123,7 @@ ENTRY(arm9_dcache_wb_range) mcr p15, 0, r0, c7, c10, 1 /* Clean D cache SE with VA */ add r0, r0, ip subs r1, r1, ip - bpl .Larm9_wb_next + bhi .Larm9_wb_next mov pc, lr ENTRY(arm9_dcache_wbinv_range) @@ -141,7 +139,7 @@ ENTRY(arm9_dcache_wbinv_range) mcr p15, 0, r0, c7, c14, 1 /* Purge D cache SE with VA */ add r0, r0, ip subs r1, r1, ip - bpl .Larm9_wbinv_next + bhi .Larm9_wbinv_next mov pc, lr /* @@ -161,7 +159,7 @@ ENTRY(arm9_dcache_inv_range) mcr p15, 0, r0, c7, c6, 1 /* Invalidate D cache SE with VA */ add r0, r0, ip subs r1, r1, ip - bpl .Larm9_inv_next + bhi .Larm9_inv_next mov pc, lr ENTRY(arm9_idcache_wbinv_range) @@ -178,7 +176,7 @@ ENTRY(arm9_idcache_wbinv_range) mcr p15, 0, r0, c7, c14, 1 /* Purge D cache SE with VA */ add r0, r0, ip subs r1, r1, ip - bpl .Larm9_id_wbinv_next + bhi .Larm9_id_wbinv_next mov pc, lr ENTRY_NP(arm9_idcache_wbinv_all) @@ -199,12 +197,10 @@ ENTRY(arm9_dcache_wbinv_all) orr ip, s_max, i_max .Lnext_index_inv: mcr p15, 0, ip, c7, c14, 2 /* Purge D cache SE with Set/Index */ - sub ip, ip, i_inc - tst ip, i_max /* Index 0 is last one */ - bne .Lnext_index_inv /* Next index */ - mcr p15, 0, ip, c7, c14, 2 /* Purge D cache SE with Set/Index */ + subs ip, ip, i_inc + bhs .Lnext_index_inv /* Next index */ subs s_max, s_max, s_inc - bpl .Lnext_set_inv /* Next set */ + bhs .Lnext_set_inv /* Next set */ mov pc, lr .Larm9_cache_data: --- arm9_arm10_cacheops_offbyone_fix.diff ends here --- >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-arm@FreeBSD.ORG Sat Dec 15 20:08:44 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BEEA57EB for ; Sat, 15 Dec 2012 20:08:44 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 488F88FC0C for ; Sat, 15 Dec 2012 20:08:43 +0000 (UTC) Received: by mail-wg0-f42.google.com with SMTP id dr1so1012426wgb.1 for ; Sat, 15 Dec 2012 12:08:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ijjyqSllfck+aegIheSEZkZZKJ4ZGIDjuPYhv5/WYQM=; b=Uw8IU6DK1EGk8KhZKfSAW2LBD8+uMMHPVA/X5R/KHi6BuKgmg5MrWfRvp6OR2oecOu qIjUUBdcR25rKiwFWHl5nEW7hW3Zj9HG0VCrTYITjhhD0GvTRR4zNbi5BNU/WzGZVA1i wwfFeLXVmXNbUZL2SVfb39wpj1ddYINaEXGlX0pewamJFF6NAJ+gz97/oMQ189E8Mxq4 keU+QLf0rpbMstl9mMJKA0o0xh1UlcYxZS1og4BygVyQVKQM5dHNNZ6h0P6RURyHU+VK ifICEfyzvYsOWtyhzxksryeKBOqi7ldMP4QDPZQPlndUIxpq30qDava8QifrV+Wpe54m m2Sg== MIME-Version: 1.0 Received: by 10.180.88.71 with SMTP id be7mr8550714wib.17.1355602123128; Sat, 15 Dec 2012 12:08:43 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Sat, 15 Dec 2012 12:08:43 -0800 (PST) In-Reply-To: <201212151957.qBFJvdUo044496@revolution.hippie.lan> References: <201212151957.qBFJvdUo044496@revolution.hippie.lan> Date: Sat, 15 Dec 2012 12:08:43 -0800 X-Google-Sender-Auth: xMVQktabTsthQIXMXBarYEQmoWQ Message-ID: Subject: Re: arm/174461: [patch] Fix off-by-one in arm9/arm10 cache maintenance routines From: Adrian Chadd To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 20:08:44 -0000 Wow, cool. What family CPU is in the pandaboard and r-pi? Would you be able to review the earlier ARM support and see if similar issues exist there? Thanks! Adrian On 15 December 2012 11:57, Ian Lepore wrote: > >>Number: 174461 >>Category: arm >>Synopsis: [patch] Fix off-by-one in arm9/arm10 cache maintenance routines >>Confidential: no >>Severity: serious >>Priority: medium >>Responsible: freebsd-arm >>State: open >>Quarter: >>Keywords: >>Date-Required: >>Class: sw-bug >>Submitter-Id: current-users >>Arrival-Date: Sat Dec 15 20:00:00 UTC 2012 >>Closed-Date: >>Last-Modified: >>Originator: Ian Lepore >>Release: FreeBSD 10.0-CURRENT arm >>Organization: > Symmetricom, Inc. >>Environment: > FreeBSD dpcur 10.0-CURRENT FreeBSD 10.0-CURRENT #23 r243920M: Sat Dec 15 11:31:47 MST 2012 ilepore@revolution.hippie.lan:/local/build/staging/freebsd/dp10/obj/arm.arm/local/build/staging/freebsd/dp10/src/sys/DP arm > >>Description: > In all the routines that loop through a range of virtual addresses, the loop > is controlled by subtracting the cache line size from the total length of the > request. After the subtract, a 'bpl' instruction was used, which branches if > the result of the subtraction is zero or greater, but we need to exit the > loop when the count hits zero. Thus, all the bpl instructions in those loops > have been changed to 'bhi' (branch if greater than zero). > > In addition, the two routines that walk through the cache using set-and-index > were correct, but confusing. The loop control for those has been simplified, > just so that it's easier to see by examination that the code is correct. > > Routines for other arm architectures and generations still have the bpl > instruction, but compensate for the off-by-one situation by decrementing > the count register by one before entering the loop. Just for the sake of > consistancy, these should probably all be changed to remove the decrement > and use the correct branch instruction. That would then make it easier to > see what appears superficially to be lots of duplication in these routines, > and some consolidation could happen. > >>How-To-Repeat: > Build a kernel for Atmel ARM with INVARIANTS and INVARIANT_SUPPORT enabled. > When it boots, the uart devices fail to instantiate. > > The reason was that the driver allocates a dma tag, then a dma buffer, > and accidentally the tag ended up laid out in memory immediately after the > buffer. When the driver did the bus_dmamap_sync(PREREAD) on the buffer, the > off-by-one error caused the cache line immediately following that buffer (the > first 32 bytes of the dma tag) to be erroniously invalidated. Because of > INVARIANTS, the physical memory under that dirty cache line was full of > 0xdeadc0de, so the invalidate operation corrupted the dma tag. When the > driver then attempted to allocate another buffer using that tag it failed, > because the 0xdeadc0de values in the tag led to insane allocation decisions > that caused malloc() to fail. > > Without INVARIANTS, either things end up in different places in memory, or > the values in underlying memory that become exposed after the bad invalidate > are harmless; either way, it accidentally works right most of the time. > >>Fix: > > --- arm9_arm10_cacheops_offbyone_fix.diff begins here --- > diff -r 0f2004466772 sys/arm/arm/cpufunc_asm_arm10.S > --- sys/arm/arm/cpufunc_asm_arm10.S Thu Dec 06 08:24:00 2012 -0700 > +++ sys/arm/arm/cpufunc_asm_arm10.S Sat Dec 15 11:30:41 2012 -0700 > @@ -87,7 +87,7 @@ ENTRY_NP(arm10_icache_sync_range) > mcr p15, 0, r0, c7, c10, 1 /* Clean D cache SE with VA */ > add r0, r0, ip > subs r1, r1, ip > - bpl .Larm10_sync_next > + bhi .Larm10_sync_next > mcr p15, 0, r0, c7, c10, 4 /* drain the write buffer */ > bx lr > > @@ -108,12 +108,10 @@ ENTRY_NP(arm10_icache_sync_all) > orr ip, s_max, i_max > .Lnext_index: > mcr p15, 0, ip, c7, c10, 2 /* Clean D cache SE with Set/Index */ > - sub ip, ip, i_inc > - tst ip, i_max /* Index 0 is last one */ > - bne .Lnext_index /* Next index */ > - mcr p15, 0, ip, c7, c10, 2 /* Clean D cache SE with Set/Index */ > + subs ip, ip, i_inc > + bhs .Lnext_index /* Next index */ > subs s_max, s_max, s_inc > - bpl .Lnext_set /* Next set */ > + bhs .Lnext_set /* Next set */ > mcr p15, 0, r0, c7, c10, 4 /* drain the write buffer */ > bx lr > > @@ -133,7 +131,7 @@ ENTRY(arm10_dcache_wb_range) > mcr p15, 0, r0, c7, c10, 1 /* Clean D cache SE with VA */ > add r0, r0, ip > subs r1, r1, ip > - bpl .Larm10_wb_next > + bhi .Larm10_wb_next > mcr p15, 0, r0, c7, c10, 4 /* drain the write buffer */ > bx lr > > @@ -150,7 +148,7 @@ ENTRY(arm10_dcache_wbinv_range) > mcr p15, 0, r0, c7, c14, 1 /* Purge D cache SE with VA */ > add r0, r0, ip > subs r1, r1, ip > - bpl .Larm10_wbinv_next > + bhi .Larm10_wbinv_next > mcr p15, 0, r0, c7, c10, 4 /* drain the write buffer */ > bx lr > > @@ -171,7 +169,7 @@ ENTRY(arm10_dcache_inv_range) > mcr p15, 0, r0, c7, c6, 1 /* Invalidate D cache SE with VA */ > add r0, r0, ip > subs r1, r1, ip > - bpl .Larm10_inv_next > + bhi .Larm10_inv_next > mcr p15, 0, r0, c7, c10, 4 /* drain the write buffer */ > bx lr > > @@ -189,7 +187,7 @@ ENTRY(arm10_idcache_wbinv_range) > mcr p15, 0, r0, c7, c14, 1 /* Purge D cache SE with VA */ > add r0, r0, ip > subs r1, r1, ip > - bpl .Larm10_id_wbinv_next > + bhi .Larm10_id_wbinv_next > mcr p15, 0, r0, c7, c10, 4 /* drain the write buffer */ > bx lr > > @@ -211,12 +209,10 @@ ENTRY(arm10_dcache_wbinv_all) > orr ip, s_max, i_max > .Lnext_index_inv: > mcr p15, 0, ip, c7, c14, 2 /* Purge D cache SE with Set/Index */ > - sub ip, ip, i_inc > - tst ip, i_max /* Index 0 is last one */ > - bne .Lnext_index_inv /* Next index */ > - mcr p15, 0, ip, c7, c14, 2 /* Purge D cache SE with Set/Index */ > + subs ip, ip, i_inc > + bhs .Lnext_index_inv /* Next index */ > subs s_max, s_max, s_inc > - bpl .Lnext_set_inv /* Next set */ > + bhs .Lnext_set_inv /* Next set */ > mcr p15, 0, r0, c7, c10, 4 /* drain the write buffer */ > bx lr > > diff -r 0f2004466772 sys/arm/arm/cpufunc_asm_arm9.S > --- sys/arm/arm/cpufunc_asm_arm9.S Thu Dec 06 08:24:00 2012 -0700 > +++ sys/arm/arm/cpufunc_asm_arm9.S Sat Dec 15 11:30:41 2012 -0700 > @@ -81,7 +81,7 @@ ENTRY_NP(arm9_icache_sync_range) > mcr p15, 0, r0, c7, c10, 1 /* Clean D cache SE with VA */ > add r0, r0, ip > subs r1, r1, ip > - bpl .Larm9_sync_next > + bhi .Larm9_sync_next > mov pc, lr > > ENTRY_NP(arm9_icache_sync_all) > @@ -101,12 +101,10 @@ ENTRY_NP(arm9_icache_sync_all) > orr ip, s_max, i_max > .Lnext_index: > mcr p15, 0, ip, c7, c10, 2 /* Clean D cache SE with Set/Index */ > - sub ip, ip, i_inc > - tst ip, i_max /* Index 0 is last one */ > - bne .Lnext_index /* Next index */ > - mcr p15, 0, ip, c7, c10, 2 /* Clean D cache SE with Set/Index */ > + subs ip, ip, i_inc > + bhs .Lnext_index /* Next index */ > subs s_max, s_max, s_inc > - bpl .Lnext_set /* Next set */ > + bhs .Lnext_set /* Next set */ > mov pc, lr > > .Larm9_line_size: > @@ -125,7 +123,7 @@ ENTRY(arm9_dcache_wb_range) > mcr p15, 0, r0, c7, c10, 1 /* Clean D cache SE with VA */ > add r0, r0, ip > subs r1, r1, ip > - bpl .Larm9_wb_next > + bhi .Larm9_wb_next > mov pc, lr > > ENTRY(arm9_dcache_wbinv_range) > @@ -141,7 +139,7 @@ ENTRY(arm9_dcache_wbinv_range) > mcr p15, 0, r0, c7, c14, 1 /* Purge D cache SE with VA */ > add r0, r0, ip > subs r1, r1, ip > - bpl .Larm9_wbinv_next > + bhi .Larm9_wbinv_next > mov pc, lr > > /* > @@ -161,7 +159,7 @@ ENTRY(arm9_dcache_inv_range) > mcr p15, 0, r0, c7, c6, 1 /* Invalidate D cache SE with VA */ > add r0, r0, ip > subs r1, r1, ip > - bpl .Larm9_inv_next > + bhi .Larm9_inv_next > mov pc, lr > > ENTRY(arm9_idcache_wbinv_range) > @@ -178,7 +176,7 @@ ENTRY(arm9_idcache_wbinv_range) > mcr p15, 0, r0, c7, c14, 1 /* Purge D cache SE with VA */ > add r0, r0, ip > subs r1, r1, ip > - bpl .Larm9_id_wbinv_next > + bhi .Larm9_id_wbinv_next > mov pc, lr > > ENTRY_NP(arm9_idcache_wbinv_all) > @@ -199,12 +197,10 @@ ENTRY(arm9_dcache_wbinv_all) > orr ip, s_max, i_max > .Lnext_index_inv: > mcr p15, 0, ip, c7, c14, 2 /* Purge D cache SE with Set/Index */ > - sub ip, ip, i_inc > - tst ip, i_max /* Index 0 is last one */ > - bne .Lnext_index_inv /* Next index */ > - mcr p15, 0, ip, c7, c14, 2 /* Purge D cache SE with Set/Index */ > + subs ip, ip, i_inc > + bhs .Lnext_index_inv /* Next index */ > subs s_max, s_max, s_inc > - bpl .Lnext_set_inv /* Next set */ > + bhs .Lnext_set_inv /* Next set */ > mov pc, lr > > .Larm9_cache_data: > --- arm9_arm10_cacheops_offbyone_fix.diff ends here --- > >>Release-Note: >>Audit-Trail: >>Unformatted: > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Sat Dec 15 20:21:11 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E0B74A15 for ; Sat, 15 Dec 2012 20:21:11 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id A79438FC0A for ; Sat, 15 Dec 2012 20:21:10 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qBFKL9jl059530 for ; Sat, 15 Dec 2012 13:21:10 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qBFKKldt060620 for ; Sat, 15 Dec 2012 13:20:47 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: arm cache fixes From: Ian Lepore To: freebsd-arm@freebsd.org Content-Type: text/plain; charset="us-ascii" Date: Sat, 15 Dec 2012 13:20:47 -0700 Message-ID: <1355602847.1198.83.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 20:21:11 -0000 Yes, I've submitted yet another patch for an arm cache maintenance bug. Just to be clear: it is NOT the fix for the arm v6/v7 writeback problem. It also doesn't apply to Marvell/Sheeva-based armv5 systems, because they have their own SoC-specific cache maintenance routines. It does apply to most other armv4 and v5 systems. Speaking of the armv6/v7 bug that happens with writeback enabled... I took a hard look at the low-level asm code for those, and nothing jumps out at me as wrong. But then, I've looked at the armv4 low level routines many times before, starting in 2009 when I first started fighting cache coherency problems, and I never noticed those incorrect 'bpl' instructions before. (I've been doing arm asm since 1993, and I'm still always tripped up by the branch mnemonics used with arm.) I've been calling it "the armv6/v7" problem, but do we know whether it's both of those architectures, or if it's v7-only? There's a huge difference between the cache maintenance schemes for the two. If it happens on both, we should probably focus on the busdma_machdep code. If it's v7 only, maybe it's low-level code (which looks reasonable on its face, but I need to study the ARM ARM for v7 stuff more). -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat Dec 15 20:25:23 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DA57BA73; Sat, 15 Dec 2012 20:25:23 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 9D1788FC0C; Sat, 15 Dec 2012 20:25:23 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qBFKPLQu059634; Sat, 15 Dec 2012 13:25:23 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qBFKOxNw060629; Sat, 15 Dec 2012 13:24:59 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: arm/174461: [patch] Fix off-by-one in arm9/arm10 cache maintenance routines From: Ian Lepore To: Adrian Chadd In-Reply-To: References: <201212151957.qBFJvdUo044496@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Sat, 15 Dec 2012 13:24:59 -0700 Message-ID: <1355603099.1198.87.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 20:25:23 -0000 On Sat, 2012-12-15 at 12:08 -0800, Adrian Chadd wrote: > Wow, cool. What family CPU is in the pandaboard and r-pi? > > Would you be able to review the earlier ARM support and see if similar > issues exist there? > > Thanks! > > > > Adrian > > > On 15 December 2012 11:57, Ian Lepore wrote: > > > >>Number: 174461 This *is* the earlier ARM support. The pandaboard and r-pi are arm v7. I have a brand new r-pi sitting right next to my keyboard here, just arrived a couple days ago. But I also have a to-do list that's crazy-long right now, and much of what's on it relates to $work. :sigh: I had a close look at the .S files for all the flavors in sys/arm/arm, and other than being rife with opportunities for consolidation and cleanup, I didn't see any other problems (doesn't mean there aren't any, of course; I have much to learn about v6 and v7 stuff). -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat Dec 15 20:49:08 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EB5EA140 for ; Sat, 15 Dec 2012 20:49:08 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [88.198.91.248]) by mx1.freebsd.org (Postfix) with ESMTP id 8205D8FC15 for ; Sat, 15 Dec 2012 20:49:08 +0000 (UTC) Received: from [207.6.254.8] (helo=[192.168.1.67]) by id.bluezbox.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TjyfQ-000CAl-Pq; Sat, 15 Dec 2012 12:49:06 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: arm cache fixes From: Oleksandr Tymoshenko In-Reply-To: <1355602847.1198.83.camel@revolution.hippie.lan> Date: Sat, 15 Dec 2012 12:48:46 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8A228489-9934-4B2F-94C5-882A61116F99@bluezbox.com> References: <1355602847.1198.83.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1499) Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 2012-12-15, at 12:20 PM, Ian Lepore wrote: > Yes, I've submitted yet another patch for an arm cache maintenance bug. > > Just to be clear: it is NOT the fix for the arm v6/v7 writeback problem. > > It also doesn't apply to Marvell/Sheeva-based armv5 systems, because > they have their own SoC-specific cache maintenance routines. > > It does apply to most other armv4 and v5 systems. > > Speaking of the armv6/v7 bug that happens with writeback enabled... I > took a hard look at the low-level asm code for those, and nothing jumps > out at me as wrong. But then, I've looked at the armv4 low level > routines many times before, starting in 2009 when I first started > fighting cache coherency problems, and I never noticed those incorrect > 'bpl' instructions before. (I've been doing arm asm since 1993, and I'm > still always tripped up by the branch mnemonics used with arm.) > > I've been calling it "the armv6/v7" problem, but do we know whether it's > both of those architectures, or if it's v7-only? There's a huge > difference between the cache maintenance schemes for the two. If it > happens on both, we should probably focus on the busdma_machdep code. > If it's v7 only, maybe it's low-level code (which looks reasonable on > its face, but I need to study the ARM ARM for v7 stuff more). [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 20:49:09 -0000 On 2012-12-15, at 12:20 PM, Ian Lepore = wrote: > Yes, I've submitted yet another patch for an arm cache maintenance = bug.=20 >=20 > Just to be clear: it is NOT the fix for the arm v6/v7 writeback = problem. >=20 > It also doesn't apply to Marvell/Sheeva-based armv5 systems, because > they have their own SoC-specific cache maintenance routines. >=20 > It does apply to most other armv4 and v5 systems. >=20 > Speaking of the armv6/v7 bug that happens with writeback enabled... I > took a hard look at the low-level asm code for those, and nothing = jumps > out at me as wrong. But then, I've looked at the armv4 low level > routines many times before, starting in 2009 when I first started > fighting cache coherency problems, and I never noticed those incorrect > 'bpl' instructions before. (I've been doing arm asm since 1993, and = I'm > still always tripped up by the branch mnemonics used with arm.) >=20 > I've been calling it "the armv6/v7" problem, but do we know whether = it's > both of those architectures, or if it's v7-only? There's a huge > difference between the cache maintenance schemes for the two. If it > happens on both, we should probably focus on the busdma_machdep code. > If it's v7 only, maybe it's low-level code (which looks reasonable on > its face, but I need to study the ARM ARM for v7 stuff more). I performed extensive testing only on armv7 platform. Now that the = problem has been split in several sub-problems (pmap module fixes, L2 cache driver bugs, = EHCI issue) I'm going to apply pmap fixes and perform tests on my Raspberry Pi to = gather more statistics. I'll get back with more information as soon as I have it.=20