From owner-freebsd-arm@FreeBSD.ORG Mon Nov 24 11:07:09 2008 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 400FB1065672 for ; Mon, 24 Nov 2008 11:07:09 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2EFEF8FC1C for ; Mon, 24 Nov 2008 11:07:09 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mAOB79PA019847 for ; Mon, 24 Nov 2008 11:07:09 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mAOB78Pk019843 for freebsd-arm@FreeBSD.org; Mon, 24 Nov 2008 11:07:08 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 24 Nov 2008 11:07:08 GMT Message-Id: <200811241107.mAOB78Pk019843@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 Cc: Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Nov 2008 11:07:09 -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/128987 arm [patch] Fix at91_mci and use 1-bit mode. o arm/128897 arm [PATCH] Failture to build arm kernel with "options KTR o arm/128891 arm [PATCH] Fix for spelling error in arm machdep code 3 problems total. From owner-freebsd-arm@FreeBSD.ORG Tue Nov 25 10:26:09 2008 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 317DC1065675 for ; Tue, 25 Nov 2008 10:26:09 +0000 (UTC) (envelope-from PublicServicePartnershipLtd_769894@dotmailer.co.uk) Received: from mta21.mta.dotmailer.co.uk (mta21.mta.dotmailer.co.uk [80.87.10.21]) by mx1.freebsd.org (Postfix) with ESMTP id D958E8FC19 for ; Tue, 25 Nov 2008 10:26:08 +0000 (UTC) (envelope-from PublicServicePartnershipLtd_769894@dotmailer.co.uk) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=gen-key1; d=dotmailer.co.uk; h=From:To:Date:Subject:MIME-Version:Content-Type:List-Unsubscribe:Message-ID; i=PublicServicePartnershipLtd_769894@dotmailer.co.uk; bh=Lw/xlmdNpHU8JXsC84U3RStdvRU=; b=Uf/MU54yu5IJ1lkItd9sWJTJj70Nt0ourglbVsLmLlmamNVn8cl2su74ngJjDWJqppUyGcjemJlw ZRyiCulHbw== DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=gen-key1; d=dotmailer.co.uk; b=jbACN5xi7WlzW41kHZF+Ec3dsXnXhBwvoewdIJcsfWSlmqQB/tD4Oj+1lRCywHy9HI2SbKCfB69f 8GjSEaom7A==; Received: from CHEWBACCA (80.87.6.5) by mta21.mta.dotmailer.co.uk (PowerMTA(TM) v3.5r10) id h5f9c80k80ku for ; Tue, 25 Nov 2008 09:51:21 +0000 (envelope-from ) From: "Mike Cross" To: "freebsd-arm@freebsd.org" Date: Tue, 25 Nov 2008 09:51:22 +0000 MIME-Version: 1.0 X-Mailer: dotMailer X-EMdotMailDroidID: 7 X-EMdotMailID: 443872180 Message-ID: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Emailing to the Public Sector Made Easy X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Nov 2008 10:26:09 -0000 From owner-freebsd-arm@FreeBSD.ORG Tue Nov 25 17:45:11 2008 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D951C1065670 for ; Tue, 25 Nov 2008 17:45:11 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id CA9BE8FC08 for ; Tue, 25 Nov 2008 17:45:10 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id mAPHhMv1060778 for ; Tue, 25 Nov 2008 10:43:23 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 25 Nov 2008 10:44:52 -0700 (MST) Message-Id: <20081125.104452.535842403.imp@bsdimp.com> To: arm@FreeBSD.org From: "M. Warner Losh" X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Tue_Nov_25_10_44_52_2008_250)--" Content-Transfer-Encoding: 7bit Cc: Subject: Code review request: boards on AT91 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Nov 2008 17:45:11 -0000 ----Next_Part(Tue_Nov_25_10_44_52_2008_250)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit I'm trying a little experiment. I'm moving the board support for the different sets of boards we support to their own file. This is the first step in moving to supporting multiple boards more easily. There's a number of gross hacks to make this work now in at91 land, and I'd like to clean them up. The mv port is much cleaner, but we still likely need some way to identify boards and get the right board support code called. In Linux land, all ARM boot loaders are expected to pass in a machine type, which is used to do the multiplexing. Something similar in FreeBSD would be useful (and not just for ARM). Eventually, I'd like to see more common code between the different arm variants. This will ease porting efforts as well as make the code more robust. If anybody wants me to write up where I'm going with this, or answer any question, please feel free to ask. Also, comments would be nice. Warner ----Next_Part(Tue_Nov_25_10_44_52_2008_250)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="at91-board.diff" Index: at91/files.kb920x =================================================================== --- at91/files.kb920x (revision 185243) +++ at91/files.kb920x (working copy) @@ -1,2 +0,0 @@ -#$FreeBSD$ -arm/at91/kb920x_machdep.c standard Index: at91/kb920x_machdep.c =================================================================== --- at91/kb920x_machdep.c (revision 185243) +++ at91/kb920x_machdep.c (working copy) @@ -1,443 +0,0 @@ -/*- - * Copyright (c) 1994-1998 Mark Brinicombe. - * Copyright (c) 1994 Brini. - * All rights reserved. - * - * This code is derived from software written for Brini by Mark Brinicombe - * - * 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. - * 3. All advertising materials mentioning features or use of this software - * must display the following acknowledgement: - * This product includes software developed by Brini. - * 4. The name of the company nor the name of the author may be used to - * endorse or promote products derived from this software without specific - * prior written permission. - * - * THIS SOFTWARE IS PROVIDED BY BRINI ``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 BRINI 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. - * - * RiscBSD kernel project - * - * machdep.c - * - * Machine dependant functions for kernel setup - * - * This file needs a lot of work. - * - * Created : 17/09/94 - */ - -#include "opt_msgbuf.h" -#include "opt_at91.h" - -#include -__FBSDID("$FreeBSD$"); - -#define _ARM32_BUS_DMA_PRIVATE -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include - -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include - -#include -#include -#include - -#define KERNEL_PT_SYS 0 /* Page table for mapping proc0 zero page */ -#define KERNEL_PT_KERN 1 -#define KERNEL_PT_KERN_NUM 22 -#define KERNEL_PT_AFKERNEL KERNEL_PT_KERN + KERNEL_PT_KERN_NUM /* L2 table for mapping after kernel */ -#define KERNEL_PT_AFKERNEL_NUM 5 - -/* this should be evenly divisable by PAGE_SIZE / L2_TABLE_SIZE_REAL (or 4) */ -#define NUM_KERNEL_PTS (KERNEL_PT_AFKERNEL + KERNEL_PT_AFKERNEL_NUM) - -/* Define various stack sizes in pages */ -#define IRQ_STACK_SIZE 1 -#define ABT_STACK_SIZE 1 -#define UND_STACK_SIZE 1 - -extern u_int data_abort_handler_address; -extern u_int prefetch_abort_handler_address; -extern u_int undefined_handler_address; - -struct pv_addr kernel_pt_table[NUM_KERNEL_PTS]; - -extern void *_end; - -extern int *end; - -struct pcpu __pcpu; -struct pcpu *pcpup = &__pcpu; - -/* Physical and virtual addresses for some global pages */ - -vm_paddr_t phys_avail[10]; -vm_paddr_t dump_avail[4]; -vm_offset_t physical_pages; - -struct pv_addr systempage; -struct pv_addr msgbufpv; -struct pv_addr irqstack; -struct pv_addr undstack; -struct pv_addr abtstack; -struct pv_addr kernelstack; - -static void *boot_arg1; -static void *boot_arg2; - -static struct trapframe proc0_tf; - -/* Static device mappings. */ -static const struct pmap_devmap kb920x_devmap[] = { - /* - * Map the on-board devices VA == PA so that we can access them - * with the MMU on or off. - */ - { - /* - * This at least maps the interrupt controller, the UART - * and the timer. Other devices should use newbus to - * map their memory anyway. - */ - 0xdff00000, - 0xfff00000, - 0x100000, - VM_PROT_READ|VM_PROT_WRITE, - PTE_NOCACHE, - }, - /* - * We can't just map the OHCI registers VA == PA, because - * AT91RM92_OHCI_BASE belongs to the userland address space. - * We could just choose a different virtual address, but a better - * solution would probably be to just use pmap_mapdev() to allocate - * KVA, as we don't need the OHCI controller before the vm - * initialization is done. However, the AT91 resource allocation - * system doesn't know how to use pmap_mapdev() yet. - */ - { - /* - * Add the ohci controller, and anything else that might be - * on this chip select for a VA/PA mapping. - */ - AT91RM92_OHCI_BASE, - AT91RM92_OHCI_PA_BASE, - AT91RM92_OHCI_SIZE, - VM_PROT_READ|VM_PROT_WRITE, - PTE_NOCACHE, - }, - { - 0, - 0, - 0, - 0, - 0, - } -}; - -static long -ramsize(void) -{ - uint32_t *SDRAMC = (uint32_t *)(AT91RM92_BASE + AT91RM92_SDRAMC_BASE); - uint32_t cr, mr; - int banks, rows, cols, bw; - - cr = SDRAMC[AT91RM92_SDRAMC_CR / 4]; - mr = SDRAMC[AT91RM92_SDRAMC_MR / 4]; - bw = (mr & AT91RM92_SDRAMC_MR_DBW_16) ? 1 : 2; - banks = (cr & AT91RM92_SDRAMC_CR_NB_4) ? 2 : 1; - rows = ((cr & AT91RM92_SDRAMC_CR_NR_MASK) >> 2) + 11; - cols = (cr & AT91RM92_SDRAMC_CR_NC_MASK) + 8; - return (1 << (cols + rows + banks + bw)); -} - -static long -board_init(void) -{ - /* - * Since the USART supports RS-485 multidrop mode, it allows the - * TX pins to float. However, for RS-232 operations, we don't want - * these pins to float. Instead, they should be pulled up to avoid - * mismatches. Linux does something similar when it configures the - * TX lines. This implies that we also allow the RX lines to float - * rather than be in the state they are left in by the boot loader. - * Since they are input pins, I think that this is the right thing - * to do. - */ - - /* PIOA's A periph: Turn USART 0 and 2's TX/RX pins */ - at91_pio_use_periph_a(AT91RM92_PIOA_BASE, - AT91C_PA18_RXD0 | AT91C_PA22_RXD2, 0); - at91_pio_use_periph_a(AT91RM92_PIOA_BASE, - AT91C_PA17_TXD0 | AT91C_PA23_TXD2, 1); - /* PIOA's B periph: Turn USART 3's TX/RX pins */ - at91_pio_use_periph_b(AT91RM92_PIOA_BASE, AT91C_PA6_RXD3, 0); - at91_pio_use_periph_b(AT91RM92_PIOA_BASE, AT91C_PA5_TXD3, 1); -#ifdef AT91_TSC - /* We're using TC0's A1 and A2 input */ - at91_pio_use_periph_b(AT91RM92_PIOA_BASE, - AT91C_PA19_TIOA1 | AT91C_PA21_TIOA2, 0); -#endif - /* PIOB's A periph: Turn USART 1's TX/RX pins */ - at91_pio_use_periph_a(AT91RM92_PIOB_BASE, AT91C_PB21_RXD1, 0); - at91_pio_use_periph_a(AT91RM92_PIOB_BASE, AT91C_PB20_TXD1, 1); - - /* Pin assignment */ -#ifdef AT91_TSC - /* Assert PA24 low -- talk to rubidium */ - at91_pio_use_gpio(AT91RM92_PIOA_BASE, AT91C_PIO_PA24); - at91_pio_gpio_output(AT91RM92_PIOA_BASE, AT91C_PIO_PA24, 0); - at91_pio_gpio_clear(AT91RM92_PIOA_BASE, AT91C_PIO_PA24); - at91_pio_use_gpio(AT91RM92_PIOB_BASE, - AT91C_PIO_PB16 | AT91C_PIO_PB17 | AT91C_PIO_PB18 | AT91C_PIO_PB19); -#endif - - return (ramsize()); -} - -void * -initarm(void *arg, void *arg2) -{ - struct pv_addr kernel_l1pt; - int loop, i; - u_int l1pagetable; - vm_offset_t freemempos; - vm_offset_t afterkern; - uint32_t memsize; - vm_offset_t lastaddr; - - boot_arg1 = arg; - boot_arg2 = arg2; - set_cpufuncs(); - lastaddr = fake_preload_metadata(); - pcpu_init(pcpup, 0, sizeof(struct pcpu)); - PCPU_SET(curthread, &thread0); - - freemempos = (lastaddr + PAGE_MASK) & ~PAGE_MASK; - /* Define a macro to simplify memory allocation */ -#define valloc_pages(var, np) \ - alloc_pages((var).pv_va, (np)); \ - (var).pv_pa = (var).pv_va + (KERNPHYSADDR - KERNVIRTADDR); - -#define alloc_pages(var, np) \ - (var) = freemempos; \ - freemempos += (np * PAGE_SIZE); \ - memset((char *)(var), 0, ((np) * PAGE_SIZE)); - - while (((freemempos - L1_TABLE_SIZE) & (L1_TABLE_SIZE - 1)) != 0) - freemempos += PAGE_SIZE; - valloc_pages(kernel_l1pt, L1_TABLE_SIZE / PAGE_SIZE); - for (loop = 0; loop < NUM_KERNEL_PTS; ++loop) { - if (!(loop % (PAGE_SIZE / L2_TABLE_SIZE_REAL))) { - valloc_pages(kernel_pt_table[loop], - L2_TABLE_SIZE / PAGE_SIZE); - } else { - kernel_pt_table[loop].pv_va = freemempos - - (loop % (PAGE_SIZE / L2_TABLE_SIZE_REAL)) * - L2_TABLE_SIZE_REAL; - kernel_pt_table[loop].pv_pa = - kernel_pt_table[loop].pv_va - KERNVIRTADDR + - KERNPHYSADDR; - } - i++; - } - /* - * Allocate a page for the system page mapped to V0x00000000 - * This page will just contain the system vectors and can be - * shared by all processes. - */ - valloc_pages(systempage, 1); - - /* Allocate stacks for all modes */ - valloc_pages(irqstack, IRQ_STACK_SIZE); - valloc_pages(abtstack, ABT_STACK_SIZE); - valloc_pages(undstack, UND_STACK_SIZE); - valloc_pages(kernelstack, KSTACK_PAGES); - valloc_pages(msgbufpv, round_page(MSGBUF_SIZE) / PAGE_SIZE); - - /* - * Now we start construction of the L1 page table - * We start by mapping the L2 page tables into the L1. - * This means that we can replace L1 mappings later on if necessary - */ - l1pagetable = kernel_l1pt.pv_va; - - /* Map the L2 pages tables in the L1 page table */ - pmap_link_l2pt(l1pagetable, ARM_VECTORS_HIGH, - &kernel_pt_table[KERNEL_PT_SYS]); - for (i = 0; i < KERNEL_PT_KERN_NUM; i++) - pmap_link_l2pt(l1pagetable, KERNBASE + i * L1_S_SIZE, - &kernel_pt_table[KERNEL_PT_KERN + i]); - pmap_map_chunk(l1pagetable, KERNBASE, PHYSADDR, - (((uint32_t)lastaddr - KERNBASE) + PAGE_SIZE) & ~(PAGE_SIZE - 1), - VM_PROT_READ|VM_PROT_WRITE, PTE_CACHE); - afterkern = round_page((lastaddr + L1_S_SIZE) & ~(L1_S_SIZE - 1)); - for (i = 0; i < KERNEL_PT_AFKERNEL_NUM; i++) { - pmap_link_l2pt(l1pagetable, afterkern + i * L1_S_SIZE, - &kernel_pt_table[KERNEL_PT_AFKERNEL + i]); - } - - /* Map the vector page. */ - pmap_map_entry(l1pagetable, ARM_VECTORS_HIGH, systempage.pv_pa, - VM_PROT_READ|VM_PROT_WRITE, PTE_CACHE); - /* Map the stack pages */ - pmap_map_chunk(l1pagetable, irqstack.pv_va, irqstack.pv_pa, - IRQ_STACK_SIZE * PAGE_SIZE, VM_PROT_READ|VM_PROT_WRITE, PTE_CACHE); - pmap_map_chunk(l1pagetable, abtstack.pv_va, abtstack.pv_pa, - ABT_STACK_SIZE * PAGE_SIZE, VM_PROT_READ|VM_PROT_WRITE, PTE_CACHE); - pmap_map_chunk(l1pagetable, undstack.pv_va, undstack.pv_pa, - UND_STACK_SIZE * PAGE_SIZE, VM_PROT_READ|VM_PROT_WRITE, PTE_CACHE); - pmap_map_chunk(l1pagetable, kernelstack.pv_va, kernelstack.pv_pa, - KSTACK_PAGES * PAGE_SIZE, VM_PROT_READ|VM_PROT_WRITE, PTE_CACHE); - - pmap_map_chunk(l1pagetable, kernel_l1pt.pv_va, kernel_l1pt.pv_pa, - L1_TABLE_SIZE, VM_PROT_READ|VM_PROT_WRITE, PTE_PAGETABLE); - pmap_map_chunk(l1pagetable, msgbufpv.pv_va, msgbufpv.pv_pa, - MSGBUF_SIZE, VM_PROT_READ|VM_PROT_WRITE, PTE_CACHE); - - for (loop = 0; loop < NUM_KERNEL_PTS; ++loop) { - pmap_map_chunk(l1pagetable, kernel_pt_table[loop].pv_va, - kernel_pt_table[loop].pv_pa, L2_TABLE_SIZE, - VM_PROT_READ|VM_PROT_WRITE, PTE_PAGETABLE); - } - - pmap_devmap_bootstrap(l1pagetable, kb920x_devmap); - cpu_domains((DOMAIN_CLIENT << (PMAP_DOMAIN_KERNEL*2)) | DOMAIN_CLIENT); - setttb(kernel_l1pt.pv_pa); - cpu_tlb_flushID(); - cpu_domains(DOMAIN_CLIENT << (PMAP_DOMAIN_KERNEL*2)); - cninit(); - memsize = board_init(); - physmem = memsize / PAGE_SIZE; - - /* - * Pages were allocated during the secondary bootstrap for the - * stacks for different CPU modes. - * We must now set the r13 registers in the different CPU modes to - * point to these stacks. - * Since the ARM stacks use STMFD etc. we must set r13 to the top end - * of the stack memory. - */ - cpu_control(CPU_CONTROL_MMU_ENABLE, CPU_CONTROL_MMU_ENABLE); - set_stackptr(PSR_IRQ32_MODE, - irqstack.pv_va + IRQ_STACK_SIZE * PAGE_SIZE); - set_stackptr(PSR_ABT32_MODE, - abtstack.pv_va + ABT_STACK_SIZE * PAGE_SIZE); - set_stackptr(PSR_UND32_MODE, - undstack.pv_va + UND_STACK_SIZE * PAGE_SIZE); - - /* - * We must now clean the cache again.... - * Cleaning may be done by reading new data to displace any - * dirty data in the cache. This will have happened in setttb() - * but since we are boot strapping the addresses used for the read - * may have just been remapped and thus the cache could be out - * of sync. A re-clean after the switch will cure this. - * After booting there are no gross reloations of the kernel thus - * this problem will not occur after initarm(). - */ - cpu_idcache_wbinv_all(); - - /* Set stack for exception handlers */ - - data_abort_handler_address = (u_int)data_abort_handler; - prefetch_abort_handler_address = (u_int)prefetch_abort_handler; - undefined_handler_address = (u_int)undefinedinstruction_bounce; - undefined_init(); - - proc_linkup0(&proc0, &thread0); - thread0.td_kstack = kernelstack.pv_va; - thread0.td_pcb = (struct pcb *) - (thread0.td_kstack + KSTACK_PAGES * PAGE_SIZE) - 1; - thread0.td_pcb->pcb_flags = 0; - thread0.td_frame = &proc0_tf; - pcpup->pc_curpcb = thread0.td_pcb; - - arm_vector_init(ARM_VECTORS_HIGH, ARM_VEC_ALL); - - pmap_curmaxkvaddr = afterkern + L1_S_SIZE * (KERNEL_PT_KERN_NUM - 1); - - /* - * ARM_USE_SMALL_ALLOC uses dump_avail, so it must be filled before - * calling pmap_bootstrap. - */ - dump_avail[0] = PHYSADDR; - dump_avail[1] = PHYSADDR + memsize; - dump_avail[2] = 0; - dump_avail[3] = 0; - - pmap_bootstrap(freemempos, - KERNVIRTADDR + 3 * memsize, - &kernel_l1pt); - msgbufp = (void*)msgbufpv.pv_va; - msgbufinit(msgbufp, MSGBUF_SIZE); - mutex_init(); - - i = 0; -#if PHYSADDR != KERNPHYSADDR - phys_avail[i++] = PHYSADDR; - phys_avail[i++] = KERNPHYSADDR; -#endif - phys_avail[i++] = virtual_avail - KERNVIRTADDR + KERNPHYSADDR; - phys_avail[i++] = PHYSADDR + memsize; - phys_avail[i++] = 0; - phys_avail[i++] = 0; - /* Do basic tuning, hz etc */ - init_param1(); - init_param2(physmem); - kdb_init(); - return ((void *)(kernelstack.pv_va + USPACE_SVC_STACK_TOP - - sizeof(struct pcb))); -} Index: at91/at91var.h =================================================================== --- at91/at91var.h (revision 185265) +++ at91/at91var.h (working copy) @@ -43,5 +43,14 @@ struct resource_list resources; }; +/* + * These routines are used by board init routines + */ +long at91_ramsize(void); +/* + * These routines are expected to be provided by the board files. + */ +long board_init(void); + #endif /* _AT91VAR_H_ */ Index: at91/files.at91 =================================================================== --- at91/files.at91 (revision 185243) +++ at91/files.at91 (working copy) @@ -1,6 +1,7 @@ # $FreeBSD$ arm/arm/cpufunc_asm_arm9.S standard arm/arm/irq_dispatch.S standard +arm/at91/at91_machdep.c standard arm/at91/at91.c standard arm/at91/at91_st.c standard arm/at91/at91_mci.c optional at91_mci @@ -18,3 +19,8 @@ arm/at91/uart_bus_at91usart.c optional uart arm/at91/uart_cpu_at91rm9200usart.c optional uart arm/at91/uart_dev_at91usart.c optional uart +# +# All the boards we support +# +arm/at91/board_kb920x.c optional at91_board_kb920x +arm/at91/board_tsc4370.c optional at91_board_tsc4370 Index: at91/at91_machdep.c =================================================================== --- at91/at91_machdep.c (revision 185243) +++ at91/at91_machdep.c (working copy) @@ -91,6 +91,7 @@ #include #include +#include #include #include #include @@ -141,7 +142,7 @@ static struct trapframe proc0_tf; /* Static device mappings. */ -static const struct pmap_devmap kb920x_devmap[] = { +static const struct pmap_devmap at91rm9200_devmap[] = { /* * Map the on-board devices VA == PA so that we can access them * with the MMU on or off. @@ -187,8 +188,8 @@ } }; -static long -ramsize(void) +long +at91_ramsize(void) { uint32_t *SDRAMC = (uint32_t *)(AT91RM92_BASE + AT91RM92_SDRAMC_BASE); uint32_t cr, mr; @@ -203,50 +204,6 @@ return (1 << (cols + rows + banks + bw)); } -static long -board_init(void) -{ - /* - * Since the USART supports RS-485 multidrop mode, it allows the - * TX pins to float. However, for RS-232 operations, we don't want - * these pins to float. Instead, they should be pulled up to avoid - * mismatches. Linux does something similar when it configures the - * TX lines. This implies that we also allow the RX lines to float - * rather than be in the state they are left in by the boot loader. - * Since they are input pins, I think that this is the right thing - * to do. - */ - - /* PIOA's A periph: Turn USART 0 and 2's TX/RX pins */ - at91_pio_use_periph_a(AT91RM92_PIOA_BASE, - AT91C_PA18_RXD0 | AT91C_PA22_RXD2, 0); - at91_pio_use_periph_a(AT91RM92_PIOA_BASE, - AT91C_PA17_TXD0 | AT91C_PA23_TXD2, 1); - /* PIOA's B periph: Turn USART 3's TX/RX pins */ - at91_pio_use_periph_b(AT91RM92_PIOA_BASE, AT91C_PA6_RXD3, 0); - at91_pio_use_periph_b(AT91RM92_PIOA_BASE, AT91C_PA5_TXD3, 1); -#ifdef AT91_TSC - /* We're using TC0's A1 and A2 input */ - at91_pio_use_periph_b(AT91RM92_PIOA_BASE, - AT91C_PA19_TIOA1 | AT91C_PA21_TIOA2, 0); -#endif - /* PIOB's A periph: Turn USART 1's TX/RX pins */ - at91_pio_use_periph_a(AT91RM92_PIOB_BASE, AT91C_PB21_RXD1, 0); - at91_pio_use_periph_a(AT91RM92_PIOB_BASE, AT91C_PB20_TXD1, 1); - - /* Pin assignment */ -#ifdef AT91_TSC - /* Assert PA24 low -- talk to rubidium */ - at91_pio_use_gpio(AT91RM92_PIOA_BASE, AT91C_PIO_PA24); - at91_pio_gpio_output(AT91RM92_PIOA_BASE, AT91C_PIO_PA24, 0); - at91_pio_gpio_clear(AT91RM92_PIOA_BASE, AT91C_PIO_PA24); - at91_pio_use_gpio(AT91RM92_PIOB_BASE, - AT91C_PIO_PB16 | AT91C_PIO_PB17 | AT91C_PIO_PB18 | AT91C_PIO_PB19); -#endif - - return (ramsize()); -} - void * initarm(void *arg, void *arg2) { @@ -353,7 +310,7 @@ VM_PROT_READ|VM_PROT_WRITE, PTE_PAGETABLE); } - pmap_devmap_bootstrap(l1pagetable, kb920x_devmap); + pmap_devmap_bootstrap(l1pagetable, at91rm9200_devmap); cpu_domains((DOMAIN_CLIENT << (PMAP_DOMAIN_KERNEL*2)) | DOMAIN_CLIENT); setttb(kernel_l1pt.pv_pa); cpu_tlb_flushID(); Property changes on: at91/at91_machdep.c ___________________________________________________________________ Added: svn:mergeinfo Index: at91/board_kb920x.c =================================================================== --- at91/board_kb920x.c (revision 185243) +++ at91/board_kb920x.c (working copy) @@ -1,10 +1,7 @@ /*- - * Copyright (c) 1994-1998 Mark Brinicombe. - * Copyright (c) 1994 Brini. - * All rights reserved. + * Copyright (c) 2005-2008 Olivier Houchard. All rights reserved. + * Copyright (c) 2005-2008 Warner Losh. All rights reserved. * - * This code is derived from software written for Brini by Mark Brinicombe - * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: @@ -13,197 +10,33 @@ * 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. - * 3. All advertising materials mentioning features or use of this software - * must display the following acknowledgement: - * This product includes software developed by Brini. - * 4. The name of the company nor the name of the author may be used to - * endorse or promote products derived from this software without specific - * prior written permission. * - * THIS SOFTWARE IS PROVIDED BY BRINI ``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 BRINI 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) + * THIS SOFTWARE IS PROVIDED BY 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 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. - * - * RiscBSD kernel project - * - * machdep.c - * - * Machine dependant functions for kernel setup - * - * This file needs a lot of work. - * - * Created : 17/09/94 */ -#include "opt_msgbuf.h" #include "opt_at91.h" #include __FBSDID("$FreeBSD$"); - -#define _ARM32_BUS_DMA_PRIVATE #include #include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include - +#include #include #include #include -#define KERNEL_PT_SYS 0 /* Page table for mapping proc0 zero page */ -#define KERNEL_PT_KERN 1 -#define KERNEL_PT_KERN_NUM 22 -#define KERNEL_PT_AFKERNEL KERNEL_PT_KERN + KERNEL_PT_KERN_NUM /* L2 table for mapping after kernel */ -#define KERNEL_PT_AFKERNEL_NUM 5 - -/* this should be evenly divisable by PAGE_SIZE / L2_TABLE_SIZE_REAL (or 4) */ -#define NUM_KERNEL_PTS (KERNEL_PT_AFKERNEL + KERNEL_PT_AFKERNEL_NUM) - -/* Define various stack sizes in pages */ -#define IRQ_STACK_SIZE 1 -#define ABT_STACK_SIZE 1 -#define UND_STACK_SIZE 1 - -extern u_int data_abort_handler_address; -extern u_int prefetch_abort_handler_address; -extern u_int undefined_handler_address; - -struct pv_addr kernel_pt_table[NUM_KERNEL_PTS]; - -extern void *_end; - -extern int *end; - -struct pcpu __pcpu; -struct pcpu *pcpup = &__pcpu; - -/* Physical and virtual addresses for some global pages */ - -vm_paddr_t phys_avail[10]; -vm_paddr_t dump_avail[4]; -vm_offset_t physical_pages; - -struct pv_addr systempage; -struct pv_addr msgbufpv; -struct pv_addr irqstack; -struct pv_addr undstack; -struct pv_addr abtstack; -struct pv_addr kernelstack; - -static void *boot_arg1; -static void *boot_arg2; - -static struct trapframe proc0_tf; - -/* Static device mappings. */ -static const struct pmap_devmap kb920x_devmap[] = { - /* - * Map the on-board devices VA == PA so that we can access them - * with the MMU on or off. - */ - { - /* - * This at least maps the interrupt controller, the UART - * and the timer. Other devices should use newbus to - * map their memory anyway. - */ - 0xdff00000, - 0xfff00000, - 0x100000, - VM_PROT_READ|VM_PROT_WRITE, - PTE_NOCACHE, - }, - /* - * We can't just map the OHCI registers VA == PA, because - * AT91RM92_OHCI_BASE belongs to the userland address space. - * We could just choose a different virtual address, but a better - * solution would probably be to just use pmap_mapdev() to allocate - * KVA, as we don't need the OHCI controller before the vm - * initialization is done. However, the AT91 resource allocation - * system doesn't know how to use pmap_mapdev() yet. - */ - { - /* - * Add the ohci controller, and anything else that might be - * on this chip select for a VA/PA mapping. - */ - AT91RM92_OHCI_BASE, - AT91RM92_OHCI_PA_BASE, - AT91RM92_OHCI_SIZE, - VM_PROT_READ|VM_PROT_WRITE, - PTE_NOCACHE, - }, - { - 0, - 0, - 0, - 0, - 0, - } -}; - -static long -ramsize(void) -{ - uint32_t *SDRAMC = (uint32_t *)(AT91RM92_BASE + AT91RM92_SDRAMC_BASE); - uint32_t cr, mr; - int banks, rows, cols, bw; - - cr = SDRAMC[AT91RM92_SDRAMC_CR / 4]; - mr = SDRAMC[AT91RM92_SDRAMC_MR / 4]; - bw = (mr & AT91RM92_SDRAMC_MR_DBW_16) ? 1 : 2; - banks = (cr & AT91RM92_SDRAMC_CR_NB_4) ? 2 : 1; - rows = ((cr & AT91RM92_SDRAMC_CR_NR_MASK) >> 2) + 11; - cols = (cr & AT91RM92_SDRAMC_CR_NC_MASK) + 8; - return (1 << (cols + rows + banks + bw)); -} - -static long +long board_init(void) { /* @@ -244,200 +77,5 @@ AT91C_PIO_PB16 | AT91C_PIO_PB17 | AT91C_PIO_PB18 | AT91C_PIO_PB19); #endif - return (ramsize()); + return (at91_ramsize()); } - -void * -initarm(void *arg, void *arg2) -{ - struct pv_addr kernel_l1pt; - int loop, i; - u_int l1pagetable; - vm_offset_t freemempos; - vm_offset_t afterkern; - uint32_t memsize; - vm_offset_t lastaddr; - - boot_arg1 = arg; - boot_arg2 = arg2; - set_cpufuncs(); - lastaddr = fake_preload_metadata(); - pcpu_init(pcpup, 0, sizeof(struct pcpu)); - PCPU_SET(curthread, &thread0); - - freemempos = (lastaddr + PAGE_MASK) & ~PAGE_MASK; - /* Define a macro to simplify memory allocation */ -#define valloc_pages(var, np) \ - alloc_pages((var).pv_va, (np)); \ - (var).pv_pa = (var).pv_va + (KERNPHYSADDR - KERNVIRTADDR); - -#define alloc_pages(var, np) \ - (var) = freemempos; \ - freemempos += (np * PAGE_SIZE); \ - memset((char *)(var), 0, ((np) * PAGE_SIZE)); - - while (((freemempos - L1_TABLE_SIZE) & (L1_TABLE_SIZE - 1)) != 0) - freemempos += PAGE_SIZE; - valloc_pages(kernel_l1pt, L1_TABLE_SIZE / PAGE_SIZE); - for (loop = 0; loop < NUM_KERNEL_PTS; ++loop) { - if (!(loop % (PAGE_SIZE / L2_TABLE_SIZE_REAL))) { - valloc_pages(kernel_pt_table[loop], - L2_TABLE_SIZE / PAGE_SIZE); - } else { - kernel_pt_table[loop].pv_va = freemempos - - (loop % (PAGE_SIZE / L2_TABLE_SIZE_REAL)) * - L2_TABLE_SIZE_REAL; - kernel_pt_table[loop].pv_pa = - kernel_pt_table[loop].pv_va - KERNVIRTADDR + - KERNPHYSADDR; - } - i++; - } - /* - * Allocate a page for the system page mapped to V0x00000000 - * This page will just contain the system vectors and can be - * shared by all processes. - */ - valloc_pages(systempage, 1); - - /* Allocate stacks for all modes */ - valloc_pages(irqstack, IRQ_STACK_SIZE); - valloc_pages(abtstack, ABT_STACK_SIZE); - valloc_pages(undstack, UND_STACK_SIZE); - valloc_pages(kernelstack, KSTACK_PAGES); - valloc_pages(msgbufpv, round_page(MSGBUF_SIZE) / PAGE_SIZE); - - /* - * Now we start construction of the L1 page table - * We start by mapping the L2 page tables into the L1. - * This means that we can replace L1 mappings later on if necessary - */ - l1pagetable = kernel_l1pt.pv_va; - - /* Map the L2 pages tables in the L1 page table */ - pmap_link_l2pt(l1pagetable, ARM_VECTORS_HIGH, - &kernel_pt_table[KERNEL_PT_SYS]); - for (i = 0; i < KERNEL_PT_KERN_NUM; i++) - pmap_link_l2pt(l1pagetable, KERNBASE + i * L1_S_SIZE, - &kernel_pt_table[KERNEL_PT_KERN + i]); - pmap_map_chunk(l1pagetable, KERNBASE, PHYSADDR, - (((uint32_t)lastaddr - KERNBASE) + PAGE_SIZE) & ~(PAGE_SIZE - 1), - VM_PROT_READ|VM_PROT_WRITE, PTE_CACHE); - afterkern = round_page((lastaddr + L1_S_SIZE) & ~(L1_S_SIZE - 1)); - for (i = 0; i < KERNEL_PT_AFKERNEL_NUM; i++) { - pmap_link_l2pt(l1pagetable, afterkern + i * L1_S_SIZE, - &kernel_pt_table[KERNEL_PT_AFKERNEL + i]); - } - - /* Map the vector page. */ - pmap_map_entry(l1pagetable, ARM_VECTORS_HIGH, systempage.pv_pa, - VM_PROT_READ|VM_PROT_WRITE, PTE_CACHE); - /* Map the stack pages */ - pmap_map_chunk(l1pagetable, irqstack.pv_va, irqstack.pv_pa, - IRQ_STACK_SIZE * PAGE_SIZE, VM_PROT_READ|VM_PROT_WRITE, PTE_CACHE); - pmap_map_chunk(l1pagetable, abtstack.pv_va, abtstack.pv_pa, - ABT_STACK_SIZE * PAGE_SIZE, VM_PROT_READ|VM_PROT_WRITE, PTE_CACHE); - pmap_map_chunk(l1pagetable, undstack.pv_va, undstack.pv_pa, - UND_STACK_SIZE * PAGE_SIZE, VM_PROT_READ|VM_PROT_WRITE, PTE_CACHE); - pmap_map_chunk(l1pagetable, kernelstack.pv_va, kernelstack.pv_pa, - KSTACK_PAGES * PAGE_SIZE, VM_PROT_READ|VM_PROT_WRITE, PTE_CACHE); - - pmap_map_chunk(l1pagetable, kernel_l1pt.pv_va, kernel_l1pt.pv_pa, - L1_TABLE_SIZE, VM_PROT_READ|VM_PROT_WRITE, PTE_PAGETABLE); - pmap_map_chunk(l1pagetable, msgbufpv.pv_va, msgbufpv.pv_pa, - MSGBUF_SIZE, VM_PROT_READ|VM_PROT_WRITE, PTE_CACHE); - - for (loop = 0; loop < NUM_KERNEL_PTS; ++loop) { - pmap_map_chunk(l1pagetable, kernel_pt_table[loop].pv_va, - kernel_pt_table[loop].pv_pa, L2_TABLE_SIZE, - VM_PROT_READ|VM_PROT_WRITE, PTE_PAGETABLE); - } - - pmap_devmap_bootstrap(l1pagetable, kb920x_devmap); - cpu_domains((DOMAIN_CLIENT << (PMAP_DOMAIN_KERNEL*2)) | DOMAIN_CLIENT); - setttb(kernel_l1pt.pv_pa); - cpu_tlb_flushID(); - cpu_domains(DOMAIN_CLIENT << (PMAP_DOMAIN_KERNEL*2)); - cninit(); - memsize = board_init(); - physmem = memsize / PAGE_SIZE; - - /* - * Pages were allocated during the secondary bootstrap for the - * stacks for different CPU modes. - * We must now set the r13 registers in the different CPU modes to - * point to these stacks. - * Since the ARM stacks use STMFD etc. we must set r13 to the top end - * of the stack memory. - */ - cpu_control(CPU_CONTROL_MMU_ENABLE, CPU_CONTROL_MMU_ENABLE); - set_stackptr(PSR_IRQ32_MODE, - irqstack.pv_va + IRQ_STACK_SIZE * PAGE_SIZE); - set_stackptr(PSR_ABT32_MODE, - abtstack.pv_va + ABT_STACK_SIZE * PAGE_SIZE); - set_stackptr(PSR_UND32_MODE, - undstack.pv_va + UND_STACK_SIZE * PAGE_SIZE); - - /* - * We must now clean the cache again.... - * Cleaning may be done by reading new data to displace any - * dirty data in the cache. This will have happened in setttb() - * but since we are boot strapping the addresses used for the read - * may have just been remapped and thus the cache could be out - * of sync. A re-clean after the switch will cure this. - * After booting there are no gross reloations of the kernel thus - * this problem will not occur after initarm(). - */ - cpu_idcache_wbinv_all(); - - /* Set stack for exception handlers */ - - data_abort_handler_address = (u_int)data_abort_handler; - prefetch_abort_handler_address = (u_int)prefetch_abort_handler; - undefined_handler_address = (u_int)undefinedinstruction_bounce; - undefined_init(); - - proc_linkup0(&proc0, &thread0); - thread0.td_kstack = kernelstack.pv_va; - thread0.td_pcb = (struct pcb *) - (thread0.td_kstack + KSTACK_PAGES * PAGE_SIZE) - 1; - thread0.td_pcb->pcb_flags = 0; - thread0.td_frame = &proc0_tf; - pcpup->pc_curpcb = thread0.td_pcb; - - arm_vector_init(ARM_VECTORS_HIGH, ARM_VEC_ALL); - - pmap_curmaxkvaddr = afterkern + L1_S_SIZE * (KERNEL_PT_KERN_NUM - 1); - - /* - * ARM_USE_SMALL_ALLOC uses dump_avail, so it must be filled before - * calling pmap_bootstrap. - */ - dump_avail[0] = PHYSADDR; - dump_avail[1] = PHYSADDR + memsize; - dump_avail[2] = 0; - dump_avail[3] = 0; - - pmap_bootstrap(freemempos, - KERNVIRTADDR + 3 * memsize, - &kernel_l1pt); - msgbufp = (void*)msgbufpv.pv_va; - msgbufinit(msgbufp, MSGBUF_SIZE); - mutex_init(); - - i = 0; -#if PHYSADDR != KERNPHYSADDR - phys_avail[i++] = PHYSADDR; - phys_avail[i++] = KERNPHYSADDR; -#endif - phys_avail[i++] = virtual_avail - KERNVIRTADDR + KERNPHYSADDR; - phys_avail[i++] = PHYSADDR + memsize; - phys_avail[i++] = 0; - phys_avail[i++] = 0; - /* Do basic tuning, hz etc */ - init_param1(); - init_param2(physmem); - kdb_init(); - return ((void *)(kernelstack.pv_va + USPACE_SVC_STACK_TOP - - sizeof(struct pcb))); -} Property changes on: at91/board_kb920x.c ___________________________________________________________________ Added: svn:mergeinfo Index: at91/std.kb920x =================================================================== --- at91/std.kb920x (revision 185243) +++ at91/std.kb920x (working copy) @@ -1,9 +1,11 @@ #$FreeBSD$ include "../at91/std.at91" -files "../at91/files.kb920x" options STARTUP_PAGETABLE_ADDR=0x20800000 makeoptions KERNPHYSADDR=0x20000000 makeoptions KERNVIRTADDR=0xc0000000 options KERNPHYSADDR=0x20000000 options KERNVIRTADDR=0xc0000000 + +#options AT91_BOARD_KB920X +device at91_board_kb920x ----Next_Part(Tue_Nov_25_10_44_52_2008_250)---- From owner-freebsd-arm@FreeBSD.ORG Tue Nov 25 18:36:28 2008 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6A491065675; Tue, 25 Nov 2008 18:36:28 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id AB14F8FC22; Tue, 25 Nov 2008 18:36:28 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id mAPIZIHp061459; Tue, 25 Nov 2008 11:35:18 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 25 Nov 2008 11:36:47 -0700 (MST) Message-Id: <20081125.113647.1346821827.imp@bsdimp.com> To: stas@freebsd.org From: "M. Warner Losh" In-Reply-To: <20081125212409.3dab8178.stas@FreeBSD.org> References: <20081125.104452.535842403.imp@bsdimp.com> <20081125212409.3dab8178.stas@FreeBSD.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arm@freebsd.org Subject: Re: Code review request: boards on AT91 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Nov 2008 18:36:29 -0000 In message: <20081125212409.3dab8178.stas@FreeBSD.org> Stanislav Sedov writes: : -----BEGIN PGP SIGNED MESSAGE----- : Hash: SHA1 : : On Tue, 25 Nov 2008 10:44:52 -0700 (MST) : "M. Warner Losh" mentioned: : : > I'm trying a little experiment. I'm moving the board support for the : > different sets of boards we support to their own file. This is the : > first step in moving to supporting multiple boards more easily. : > There's a number of gross hacks to make this work now in at91 land, : > and I'd like to clean them up. The mv port is much cleaner, but we : > still likely need some way to identify boards and get the right board : > support code called. In Linux land, all ARM boot loaders are expected : > to pass in a machine type, which is used to do the multiplexing. : > Something similar in FreeBSD would be useful (and not just for ARM). : > : > Eventually, I'd like to see more common code between the different arm : > variants. This will ease porting efforts as well as make the code : > more robust. : : I think we could pass the board type via a special kenv variable : for now. I think it will work fine and applicable to all supported : architectures. We could probably reuse board type constants that Linux : kernel uses. Right now that's passed in from uboot and other loaders in I think r3, but I'd have to go look at some other code to be sure. : > If anybody wants me to write up where I'm going with this, or answer : > any question, please feel free to ask. Also, comments would be nice. : > : > Warner : > : : The code looks OK to me. I have only one question: why you have added : a commented out AT91_BOARD_KB920X option to the default kernel config? : Is it just a leftover? Leftover. Forgot the basics of kernel config for a moment. Warner : - -- : Stanislav Sedov : ST4096-RIPE : -----BEGIN PGP SIGNATURE----- : : iEYEARECAAYFAkksQs0ACgkQK/VZk+smlYFntwCfbHv6JJmTjzI6GL5Ra1k4nA2a : nGAAn06uoskVCyZ2E5eFkTtQQ7eXnmz0 : =xuFv : -----END PGP SIGNATURE----- : : From owner-freebsd-arm@FreeBSD.ORG Tue Nov 25 18:59:19 2008 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DDD61065672; Tue, 25 Nov 2008 18:59:19 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from smtp.ht-systems.ru (mr0.ht-systems.ru [78.110.50.55]) by mx1.freebsd.org (Postfix) with ESMTP id 53A608FC12; Tue, 25 Nov 2008 18:59:19 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from [85.21.245.235] (helo=orion.SpringDaemons.com) by smtp.ht-systems.ru with esmtpa (Exim 4.62) (envelope-from ) id 1L537x-0000sF-Bf; Tue, 25 Nov 2008 21:59:15 +0300 Received: from orion (localhost [127.0.0.1]) by orion.SpringDaemons.com (Postfix) with SMTP id C15C8398F3; Tue, 25 Nov 2008 22:00:40 +0300 (MSK) Date: Tue, 25 Nov 2008 22:00:40 +0300 From: Stanislav Sedov To: "M. Warner Losh" Message-Id: <20081125220040.c8996e0b.stas@FreeBSD.org> In-Reply-To: <20081125.113647.1346821827.imp@bsdimp.com> References: <20081125.104452.535842403.imp@bsdimp.com> <20081125212409.3dab8178.stas@FreeBSD.org> <20081125.113647.1346821827.imp@bsdimp.com> Organization: The FreeBSD Project X-XMPP: ssedov@jabber.ru X-Voice: +7 916 849 20 23 X-PGP-Fingerprint: F21E D6CC 5626 9609 6CE2 A385 2BF5 5993 EB26 9581 X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: arm@freebsd.org Subject: Re: Code review request: boards on AT91 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Nov 2008 18:59:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 25 Nov 2008 11:36:47 -0700 (MST) "M. Warner Losh" mentioned: > : > : I think we could pass the board type via a special kenv variable > : for now. I think it will work fine and applicable to all supported > : architectures. We could probably reuse board type constants that Linux > : kernel uses. > > Right now that's passed in from uboot and other loaders in I think r3, > but I'd have to go look at some other code to be sure. > Well, I don't think we want to follow The Linux kernel argument passing paradigm... But using a simple kenv variable would be just fine. We have a patch ready for kenv/hints support in u-boot and in our arm port, and our loader could be used on arm with Rafal's u-boot API. - -- Stanislav Sedov ST4096-RIPE -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAkksS1gACgkQK/VZk+smlYFbXgCeIjnGNdYD6bdCxCSQFR4hVrdr NxQAn20bqjk7Ln+XjScOlEiaoJ1NNBbQ =UT0L -----END PGP SIGNATURE----- From owner-freebsd-arm@FreeBSD.ORG Tue Nov 25 19:01:32 2008 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A78C51065670 for ; Tue, 25 Nov 2008 19:01:32 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from smtp.ht-systems.ru (mr0.ht-systems.ru [78.110.50.55]) by mx1.freebsd.org (Postfix) with ESMTP id 5F09A8FC1B for ; Tue, 25 Nov 2008 19:01:32 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from [85.21.245.235] (helo=orion.SpringDaemons.com) by smtp.ht-systems.ru with esmtpa (Exim 4.62) (envelope-from ) id 1L52hJ-0000K3-Dr; Tue, 25 Nov 2008 21:31:41 +0300 Received: from orion (localhost [127.0.0.1]) by orion.SpringDaemons.com (Postfix) with SMTP id 09955398F3; Tue, 25 Nov 2008 21:24:14 +0300 (MSK) Date: Tue, 25 Nov 2008 21:24:09 +0300 From: Stanislav Sedov To: "M. Warner Losh" Message-Id: <20081125212409.3dab8178.stas@FreeBSD.org> In-Reply-To: <20081125.104452.535842403.imp@bsdimp.com> References: <20081125.104452.535842403.imp@bsdimp.com> Organization: The FreeBSD Project X-XMPP: ssedov@jabber.ru X-Voice: +7 916 849 20 23 X-PGP-Fingerprint: F21E D6CC 5626 9609 6CE2 A385 2BF5 5993 EB26 9581 X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: arm@FreeBSD.org Subject: Re: Code review request: boards on AT91 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Nov 2008 19:01:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 25 Nov 2008 10:44:52 -0700 (MST) "M. Warner Losh" mentioned: > I'm trying a little experiment. I'm moving the board support for the > different sets of boards we support to their own file. This is the > first step in moving to supporting multiple boards more easily. > There's a number of gross hacks to make this work now in at91 land, > and I'd like to clean them up. The mv port is much cleaner, but we > still likely need some way to identify boards and get the right board > support code called. In Linux land, all ARM boot loaders are expected > to pass in a machine type, which is used to do the multiplexing. > Something similar in FreeBSD would be useful (and not just for ARM). > > Eventually, I'd like to see more common code between the different arm > variants. This will ease porting efforts as well as make the code > more robust. I think we could pass the board type via a special kenv variable for now. I think it will work fine and applicable to all supported architectures. We could probably reuse board type constants that Linux kernel uses. > > If anybody wants me to write up where I'm going with this, or answer > any question, please feel free to ask. Also, comments would be nice. > > Warner > The code looks OK to me. I have only one question: why you have added a commented out AT91_BOARD_KB920X option to the default kernel config? Is it just a leftover? - -- Stanislav Sedov ST4096-RIPE -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAkksQs0ACgkQK/VZk+smlYFntwCfbHv6JJmTjzI6GL5Ra1k4nA2a nGAAn06uoskVCyZ2E5eFkTtQQ7eXnmz0 =xuFv -----END PGP SIGNATURE----- From owner-freebsd-arm@FreeBSD.ORG Tue Nov 25 19:06:18 2008 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC0AC1065670; Tue, 25 Nov 2008 19:06:18 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id AE94E8FC19; Tue, 25 Nov 2008 19:06:18 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id mAPJ3r55061842; Tue, 25 Nov 2008 12:03:53 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 25 Nov 2008 12:05:23 -0700 (MST) Message-Id: <20081125.120523.-201316873.imp@bsdimp.com> To: stas@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20081125220040.c8996e0b.stas@FreeBSD.org> References: <20081125212409.3dab8178.stas@FreeBSD.org> <20081125.113647.1346821827.imp@bsdimp.com> <20081125220040.c8996e0b.stas@FreeBSD.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arm@FreeBSD.org Subject: Re: Code review request: boards on AT91 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Nov 2008 19:06:19 -0000 In message: <20081125220040.c8996e0b.stas@FreeBSD.org> Stanislav Sedov writes: : -----BEGIN PGP SIGNED MESSAGE----- : Hash: SHA1 : : On Tue, 25 Nov 2008 11:36:47 -0700 (MST) : "M. Warner Losh" mentioned: : : > : : > : I think we could pass the board type via a special kenv variable : > : for now. I think it will work fine and applicable to all supported : > : architectures. We could probably reuse board type constants that Linux : > : kernel uses. : > : > Right now that's passed in from uboot and other loaders in I think r3, : > but I'd have to go look at some other code to be sure. : > : : Well, I don't think we want to follow The Linux kernel argument passing : paradigm... But using a simple kenv variable would be just fine. : We have a patch ready for kenv/hints support in u-boot and in : our arm port, and our loader could be used on arm with Rafal's : u-boot API. You are assuming that /boot/loader is always used. In the cases where it isn't, we need that value from r3. when it is, a kenv could be used. This switching likely also needs to be configurable more easily than it is now. Warner From owner-freebsd-arm@FreeBSD.ORG Tue Nov 25 19:21:34 2008 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19FA51065673 for ; Tue, 25 Nov 2008 19:21:34 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from smtp.ht-systems.ru (mr0.ht-systems.ru [78.110.50.55]) by mx1.freebsd.org (Postfix) with ESMTP id 8C0898FC1A for ; Tue, 25 Nov 2008 19:21:33 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from [85.21.245.235] (helo=orion.SpringDaemons.com) by smtp.ht-systems.ru with esmtpa (Exim 4.62) (envelope-from ) id 1L53TV-0001S9-DS; Tue, 25 Nov 2008 22:21:30 +0300 Received: from orion (localhost [127.0.0.1]) by orion.SpringDaemons.com (Postfix) with SMTP id 052D1398F3; Tue, 25 Nov 2008 22:22:59 +0300 (MSK) Date: Tue, 25 Nov 2008 22:22:58 +0300 From: Stanislav Sedov To: "M. Warner Losh" Message-Id: <20081125222258.8db7b61e.stas@FreeBSD.org> In-Reply-To: <20081125.120523.-201316873.imp@bsdimp.com> References: <20081125212409.3dab8178.stas@FreeBSD.org> <20081125.113647.1346821827.imp@bsdimp.com> <20081125220040.c8996e0b.stas@FreeBSD.org> <20081125.120523.-201316873.imp@bsdimp.com> Organization: The FreeBSD Project X-XMPP: ssedov@jabber.ru X-Voice: +7 916 849 20 23 X-PGP-Fingerprint: F21E D6CC 5626 9609 6CE2 A385 2BF5 5993 EB26 9581 X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: arm@FreeBSD.org Subject: Re: Code review request: boards on AT91 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Nov 2008 19:21:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 25 Nov 2008 12:05:23 -0700 (MST) "M. Warner Losh" mentioned: > In message: <20081125220040.c8996e0b.stas@FreeBSD.org> > Stanislav Sedov writes: > : -----BEGIN PGP SIGNED MESSAGE----- > : Hash: SHA1 > : > : On Tue, 25 Nov 2008 11:36:47 -0700 (MST) > : "M. Warner Losh" mentioned: > : > : > : > : > : I think we could pass the board type via a special kenv variable > : > : for now. I think it will work fine and applicable to all supported > : > : architectures. We could probably reuse board type constants that Linux > : > : kernel uses. > : > > : > Right now that's passed in from uboot and other loaders in I think r3, > : > but I'd have to go look at some other code to be sure. > : > > : > : Well, I don't think we want to follow The Linux kernel argument passing > : paradigm... But using a simple kenv variable would be just fine. > : We have a patch ready for kenv/hints support in u-boot and in > : our arm port, and our loader could be used on arm with Rafal's > : u-boot API. > > You are assuming that /boot/loader is always used. In the cases where > it isn't, we need that value from r3. when it is, a kenv could be > used. This switching likely also needs to be configurable more easily > than it is now. We can't support all bootloaders on the Earth, and I think it's the job of bootloader to support the kernel it booting. Linux also mandates it's own argument passing mechanism method should be used, and doesn't support anything else. As we're using kenv for this task, and no well-accepted generic multiplatform method yet available, I think we could stick with kenv for now. I don't see the reason to complicate our kernel code more to support several argument passing methods. - -- Stanislav Sedov ST4096-RIPE -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAkksUJIACgkQK/VZk+smlYEH0QCfe0HJmSsT1BMw3PTpHP8Ypp5R 2yQAn2A35phywDjk/Wzy0ur92DYQhOCe =eMzh -----END PGP SIGNATURE----- From owner-freebsd-arm@FreeBSD.ORG Tue Nov 25 19:33:09 2008 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 057A91065675; Tue, 25 Nov 2008 19:33:09 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 910E18FC1B; Tue, 25 Nov 2008 19:33:08 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id mAPJVpNh062225; Tue, 25 Nov 2008 12:31:51 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 25 Nov 2008 12:33:21 -0700 (MST) Message-Id: <20081125.123321.-1435626397.imp@bsdimp.com> To: stas@freebsd.org From: "M. Warner Losh" In-Reply-To: <20081125222258.8db7b61e.stas@FreeBSD.org> References: <20081125220040.c8996e0b.stas@FreeBSD.org> <20081125.120523.-201316873.imp@bsdimp.com> <20081125222258.8db7b61e.stas@FreeBSD.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arm@freebsd.org Subject: Re: Code review request: boards on AT91 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Nov 2008 19:33:09 -0000 In message: <20081125222258.8db7b61e.stas@FreeBSD.org> Stanislav Sedov writes: : -----BEGIN PGP SIGNED MESSAGE----- : Hash: SHA1 : : On Tue, 25 Nov 2008 12:05:23 -0700 (MST) : "M. Warner Losh" mentioned: : : > In message: <20081125220040.c8996e0b.stas@FreeBSD.org> : > Stanislav Sedov writes: : > : -----BEGIN PGP SIGNED MESSAGE----- : > : Hash: SHA1 : > : : > : On Tue, 25 Nov 2008 11:36:47 -0700 (MST) : > : "M. Warner Losh" mentioned: : > : : > : > : : > : > : I think we could pass the board type via a special kenv variable : > : > : for now. I think it will work fine and applicable to all supported : > : > : architectures. We could probably reuse board type constants that Linux : > : > : kernel uses. : > : > : > : > Right now that's passed in from uboot and other loaders in I think r3, : > : > but I'd have to go look at some other code to be sure. : > : > : > : : > : Well, I don't think we want to follow The Linux kernel argument passing : > : paradigm... But using a simple kenv variable would be just fine. : > : We have a patch ready for kenv/hints support in u-boot and in : > : our arm port, and our loader could be used on arm with Rafal's : > : u-boot API. : > : > You are assuming that /boot/loader is always used. In the cases where : > it isn't, we need that value from r3. when it is, a kenv could be : > used. This switching likely also needs to be configurable more easily : > than it is now. : : We can't support all bootloaders on the Earth, and I think it's the job : of bootloader to support the kernel it booting. Linux also mandates it's : own argument passing mechanism method should be used, and doesn't support : anything else. Actually, Linux supports a bunch of different argument passing mechanisms. redboot differs from uboot differs from a number of other, platform specific boot loaders. They have a generic way to support boot loaders, and I think we should at least investigate it. : As we're using kenv for this task, and no well-accepted : generic multiplatform method yet available, I think we could stick with : kenv for now. I don't see the reason to complicate our kernel code more : to support several argument passing methods. We don't universally use it. It is used in the mv code, but not in the at91 code. The at91 boot loader just passes one variable in now, but there's a fair number of different boot loaders today for FreeBSD/arm. While it would be nice to mandate all the world use uboot + /boot/loader, that's not likely going to happen. There's too many boards out there that have redboot or some custom boot loader that will be hard to replace... I guess what I'm trying to say is that the current mechanisms we're using are all over the map, and we need to clean it up so that it is easy to swap different types of boot loaders in. Warner From owner-freebsd-arm@FreeBSD.ORG Tue Nov 25 19:44:04 2008 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31717106567A; Tue, 25 Nov 2008 19:44:04 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from smtp.ht-systems.ru (mr0.ht-systems.ru [78.110.50.55]) by mx1.freebsd.org (Postfix) with ESMTP id D7A328FC0A; Tue, 25 Nov 2008 19:44:03 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from [85.21.245.235] (helo=orion.SpringDaemons.com) by smtp.ht-systems.ru with esmtpa (Exim 4.62) (envelope-from ) id 1L53pH-0001sI-8P; Tue, 25 Nov 2008 22:43:59 +0300 Received: from orion (localhost [127.0.0.1]) by orion.SpringDaemons.com (Postfix) with SMTP id C29AB398F3; Tue, 25 Nov 2008 22:45:28 +0300 (MSK) Date: Tue, 25 Nov 2008 22:45:28 +0300 From: Stanislav Sedov To: "M. Warner Losh" Message-Id: <20081125224528.4395ff7e.stas@FreeBSD.org> In-Reply-To: <20081125.123321.-1435626397.imp@bsdimp.com> References: <20081125220040.c8996e0b.stas@FreeBSD.org> <20081125.120523.-201316873.imp@bsdimp.com> <20081125222258.8db7b61e.stas@FreeBSD.org> <20081125.123321.-1435626397.imp@bsdimp.com> Organization: The FreeBSD Project X-XMPP: ssedov@jabber.ru X-Voice: +7 916 849 20 23 X-PGP-Fingerprint: F21E D6CC 5626 9609 6CE2 A385 2BF5 5993 EB26 9581 X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: arm@freebsd.org Subject: Re: Code review request: boards on AT91 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Nov 2008 19:44:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 25 Nov 2008 12:33:21 -0700 (MST) "M. Warner Losh" mentioned: > We don't universally use it. It is used in the mv code, but not in > the at91 code. The at91 boot loader just passes one variable in now, Just a matter of time:-) As I said we have the patch almost ready, and it works for us with u-boot. I'll commit it shortly. > but there's a fair number of different boot loaders today for > FreeBSD/arm. While it would be nice to mandate all the world use > uboot + /boot/loader, that's not likely going to happen. There's too > many boards out there that have redboot or some custom boot loader > that will be hard to replace... In that cases loader(8) could be used. > I guess what I'm trying to say is that the current mechanisms we're > using are all over the map, and we need to clean it up so that it is > easy to swap different types of boot loaders in. Agree. At least, for some architectures the kernel config option could be added to switch between bootloader support. It'd be hard to make this in the platform independent code... - -- Stanislav Sedov ST4096-RIPE -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAkksVdgACgkQK/VZk+smlYHoCwCaAiPD78tzIsVJVvNnmPIabGpg 6I0AnjZZ/Ayl2ehUsil/U6J/HfdtpI/7 =lFD4 -----END PGP SIGNATURE----- From owner-freebsd-arm@FreeBSD.ORG Tue Nov 25 20:00:14 2008 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E29F11065676; Tue, 25 Nov 2008 20:00:13 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 8F2AA8FC19; Tue, 25 Nov 2008 20:00:13 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id mAPJwpg0062522; Tue, 25 Nov 2008 12:58:52 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 25 Nov 2008 13:00:21 -0700 (MST) Message-Id: <20081125.130021.1210474290.imp@bsdimp.com> To: stas@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20081125224528.4395ff7e.stas@FreeBSD.org> References: <20081125222258.8db7b61e.stas@FreeBSD.org> <20081125.123321.-1435626397.imp@bsdimp.com> <20081125224528.4395ff7e.stas@FreeBSD.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arm@FreeBSD.org Subject: Re: Code review request: boards on AT91 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Nov 2008 20:00:14 -0000 In message: <20081125224528.4395ff7e.stas@FreeBSD.org> Stanislav Sedov writes: : -----BEGIN PGP SIGNED MESSAGE----- : Hash: SHA1 : : On Tue, 25 Nov 2008 12:33:21 -0700 (MST) : "M. Warner Losh" mentioned: : : : > We don't universally use it. It is used in the mv code, but not in : > the at91 code. The at91 boot loader just passes one variable in now, : : Just a matter of time:-) As I said we have the patch almost ready, : and it works for us with u-boot. I'll commit it shortly. So long as it is optional. The KB9202 boards that I have don't have room for uboot or redboot. You have 16kb of space, which boot2 fits nicely into right now (clocking in at about 9.5k). : > but there's a fair number of different boot loaders today for : > FreeBSD/arm. While it would be nice to mandate all the world use : > uboot + /boot/loader, that's not likely going to happen. There's too : > many boards out there that have redboot or some custom boot loader : > that will be hard to replace... : : In that cases loader(8) could be used. Not always. That's the point that I keep coming back to. There's no easy way to make loader read things from disks, over the network, etc in the embedded space. Right now for some uboot based systems, this can be done, but for redboot systems, you are basically out of luck. There's no way that loader(8) can load additional sections without a lot of board specific code. : > I guess what I'm trying to say is that the current mechanisms we're : > using are all over the map, and we need to clean it up so that it is : > easy to swap different types of boot loaders in. : : Agree. At least, for some architectures the kernel config option could : be added to switch between bootloader support. It'd be hard to make : this in the platform independent code... Yes. There's some things that can be common, but there will always be machine dependent code. uboot, redboot and cfe all are multiplatform. Warner From owner-freebsd-arm@FreeBSD.ORG Tue Nov 25 20:45:32 2008 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 117951065676 for ; Tue, 25 Nov 2008 20:45:32 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from smtp.ht-systems.ru (mr0.ht-systems.ru [78.110.50.55]) by mx1.freebsd.org (Postfix) with ESMTP id BA4A58FC1C for ; Tue, 25 Nov 2008 20:45:31 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from [85.21.245.235] (helo=orion.SpringDaemons.com) by smtp.ht-systems.ru with esmtpa (Exim 4.62) (envelope-from ) id 1L54ml-0003Me-8r; Tue, 25 Nov 2008 23:45:27 +0300 Received: from orion (localhost [127.0.0.1]) by orion.SpringDaemons.com (Postfix) with SMTP id 83CAA398F3; Tue, 25 Nov 2008 23:46:56 +0300 (MSK) Date: Tue, 25 Nov 2008 23:46:56 +0300 From: Stanislav Sedov To: "M. Warner Losh" Message-Id: <20081125234656.e1820a12.stas@FreeBSD.org> In-Reply-To: <20081125.130021.1210474290.imp@bsdimp.com> References: <20081125222258.8db7b61e.stas@FreeBSD.org> <20081125.123321.-1435626397.imp@bsdimp.com> <20081125224528.4395ff7e.stas@FreeBSD.org> <20081125.130021.1210474290.imp@bsdimp.com> Organization: The FreeBSD Project X-XMPP: ssedov@jabber.ru X-Voice: +7 916 849 20 23 X-PGP-Fingerprint: F21E D6CC 5626 9609 6CE2 A385 2BF5 5993 EB26 9581 X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: arm@FreeBSD.org Subject: Re: Code review request: boards on AT91 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Nov 2008 20:45:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 25 Nov 2008 13:00:21 -0700 (MST) "M. Warner Losh" mentioned: > > So long as it is optional. The KB9202 boards that I have don't have > room for uboot or redboot. You have 16kb of space, which boot2 fits > nicely into right now (clocking in at about 9.5k). > Have it got parallel or SPI flash? My board boots u-boot directly from parallel flash on start. > : > but there's a fair number of different boot loaders today for > : > FreeBSD/arm. While it would be nice to mandate all the world use > : > uboot + /boot/loader, that's not likely going to happen. There's too > : > many boards out there that have redboot or some custom boot loader > : > that will be hard to replace... > : > : In that cases loader(8) could be used. > > Not always. That's the point that I keep coming back to. There's no > easy way to make loader read things from disks, over the network, etc > in the embedded space. Right now for some uboot based systems, this > can be done, but for redboot systems, you are basically out of luck. > There's no way that loader(8) can load additional sections without a > lot of board specific code. > I see your point. If there's no room for extending/replacing you have to live with what the board has:-( - -- Stanislav Sedov ST4096-RIPE -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAkksZEAACgkQK/VZk+smlYG6qQCfbl3UpJRGLLtRjeeDQ/jquqqL 1iIAnRmJSqbS54rCLmr8j8/AzRfCfiZF =QIya -----END PGP SIGNATURE----- From owner-freebsd-arm@FreeBSD.ORG Tue Nov 25 21:20:39 2008 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9757106567D for ; Tue, 25 Nov 2008 21:20:39 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 7F3B28FC12 for ; Tue, 25 Nov 2008 21:20:39 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id mAPLITYE063502; Tue, 25 Nov 2008 14:18:29 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 25 Nov 2008 14:19:57 -0700 (MST) Message-Id: <20081125.141957.1723235268.imp@bsdimp.com> To: raj@semihalf.com From: "M. Warner Losh" In-Reply-To: <04BDAB4F-CF02-4CE6-90D8-E03EDC1CC8CC@semihalf.com> References: <20081125.104452.535842403.imp@bsdimp.com> <04BDAB4F-CF02-4CE6-90D8-E03EDC1CC8CC@semihalf.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable Cc: arm@FreeBSD.org Subject: Re: Code review request: boards on AT91 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Nov 2008 21:20:39 -0000 In message: <04BDAB4F-CF02-4CE6-90D8-E03EDC1CC8CC@semihalf.com> Rafa=B3_Jaworowski writes: : On 2008-11-25, at 18:44, M. Warner Losh wrote: : = : > I'm trying a little experiment. I'm moving the board support for t= he : > different sets of boards we support to their own file. This is the= : > first step in moving to supporting multiple boards more easily. : > There's a number of gross hacks to make this work now in at91 land,= : > and I'd like to clean them up. The mv port is much cleaner, but we= : > still likely need some way to identify boards and get the right boa= rd : > support code called. In Linux land, all ARM boot loaders are expec= ted : > to pass in a machine type, which is used to do the multiplexing. : > Something similar in FreeBSD would be useful (and not just for ARM)= .= : = : Hi Warner, : While I understand your point about systems with simplistic = : bootloaders, which cannot provide enough config data to kernel, we = : should not see the machine ID model as a final solution for more = : capable environments. I guess we all agree that for those more capabl= e = : systems we need some really extensible mechanism (device tree type), = = : as discussed previously :-) Yes. Agreed. My point was more to make sure that we didn't require the loader to provide freebsd-specific kenv. : > If anybody wants me to write up where I'm going with this, or answe= r : > any question, please feel free to ask. Also, comments would be nic= e. : = : I was dreaming once about all-generic initarm() that would have KOBJ-= = : based dispatcher, but am not sure this wouldn't cause some chicken-an= d- = : egg issues as some parts of the infrastructure might not be available= = : at such early stages, but didn't investigate this too close, any = : thoughts? But anyways, even a simple scheme with common logic and = : function ptrs, which each platform variation would implement their ow= n = : routines (or use generic), would improve the ARM init code = : significantly. Yes. There's much duplication of code now, and I'd love to work towards ways of coping with less duplication. I'd also like to see the ability to compile code either for multi-board support, or just a single board support. For the moment, I'd like to take the first step and get to have the latter... The Marvell/Orion stuff has a much better separation, but still needs some tweaks for board level support. I think I'm going to write up what I've done and put it on a wiki and then ask if you could review it and see if your experience with the Marvell implementation could help refine it. Warner From owner-freebsd-arm@FreeBSD.ORG Tue Nov 25 21:24:31 2008 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF4F11065675; Tue, 25 Nov 2008 21:24:31 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 8FF978FC0A; Tue, 25 Nov 2008 21:24:31 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id mAPLL3wD063556; Tue, 25 Nov 2008 14:21:04 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 25 Nov 2008 14:22:32 -0700 (MST) Message-Id: <20081125.142232.-1573945294.imp@bsdimp.com> To: stas@freebsd.org From: "M. Warner Losh" In-Reply-To: <20081125234656.e1820a12.stas@FreeBSD.org> References: <20081125224528.4395ff7e.stas@FreeBSD.org> <20081125.130021.1210474290.imp@bsdimp.com> <20081125234656.e1820a12.stas@FreeBSD.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arm@freebsd.org Subject: Re: Code review request: boards on AT91 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Nov 2008 21:24:31 -0000 In message: <20081125234656.e1820a12.stas@FreeBSD.org> Stanislav Sedov writes: : -----BEGIN PGP SIGNED MESSAGE----- : Hash: SHA1 : : On Tue, 25 Nov 2008 13:00:21 -0700 (MST) : "M. Warner Losh" mentioned: : > : > So long as it is optional. The KB9202 boards that I have don't have : > room for uboot or redboot. You have 16kb of space, which boot2 fits : > nicely into right now (clocking in at about 9.5k). : > : : Have it got parallel or SPI flash? My board boots u-boot directly : from parallel flash on start. Not really. While the Kwikbyte board I have does, the board that was developed for my last company doesn't really have it on there. I believe it was cost reduced off the board since we didn't need it: the iic boot loader could load the kernel directly off of the SD card. : > : > but there's a fair number of different boot loaders today for : > : > FreeBSD/arm. While it would be nice to mandate all the world use : > : > uboot + /boot/loader, that's not likely going to happen. There's too : > : > many boards out there that have redboot or some custom boot loader : > : > that will be hard to replace... : > : : > : In that cases loader(8) could be used. : > : > Not always. That's the point that I keep coming back to. There's no : > easy way to make loader read things from disks, over the network, etc : > in the embedded space. Right now for some uboot based systems, this : > can be done, but for redboot systems, you are basically out of luck. : > There's no way that loader(8) can load additional sections without a : > lot of board specific code. : > : : I see your point. If there's no room for extending/replacing you : have to live with what the board has:-( Yes. Sadly, we're not in a position of saying you must have boatloader X. I wish we were... Warner From owner-freebsd-arm@FreeBSD.ORG Tue Nov 25 21:30:07 2008 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE47F1065674 for ; Tue, 25 Nov 2008 21:30:07 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from semihalf.com (semihalf.com [206.130.101.55]) by mx1.freebsd.org (Postfix) with ESMTP id 98E8E8FC0C for ; Tue, 25 Nov 2008 21:30:07 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from mail.semihalf.com (mail.semihalf.com [83.15.139.206]) by semihalf.com (8.13.1/8.13.1) with ESMTP id mAPKxw9Y026739; Tue, 25 Nov 2008 13:59:59 -0700 Received: from apn-77-112-253-159.gprs.plus.pl (apn-77-112-253-159.gprs.plus.pl [77.112.253.159]) by mail.semihalf.com (Postfix) with ESMTP id AA15A14857; Tue, 25 Nov 2008 22:15:45 +0100 (CET) Message-Id: <04BDAB4F-CF02-4CE6-90D8-E03EDC1CC8CC@semihalf.com> From: =?ISO-8859-2?Q?Rafa=B3_Jaworowski?= To: "M.Warner Losh" In-Reply-To: <20081125.104452.535842403.imp@bsdimp.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 25 Nov 2008 21:59:28 +0100 References: <20081125.104452.535842403.imp@bsdimp.com> X-Mailer: Apple Mail (2.929.2) Cc: arm@FreeBSD.org Subject: Re: Code review request: boards on AT91 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Nov 2008 21:30:07 -0000 On 2008-11-25, at 18:44, M. Warner Losh wrote: > I'm trying a little experiment. I'm moving the board support for the > different sets of boards we support to their own file. This is the > first step in moving to supporting multiple boards more easily. > There's a number of gross hacks to make this work now in at91 land, > and I'd like to clean them up. The mv port is much cleaner, but we > still likely need some way to identify boards and get the right board > support code called. In Linux land, all ARM boot loaders are expected > to pass in a machine type, which is used to do the multiplexing. > Something similar in FreeBSD would be useful (and not just for ARM). Hi Warner, While I understand your point about systems with simplistic bootloaders, which cannot provide enough config data to kernel, we should not see the machine ID model as a final solution for more capable environments. I guess we all agree that for those more capable systems we need some really extensible mechanism (device tree type), as discussed previously :-) > If anybody wants me to write up where I'm going with this, or answer > any question, please feel free to ask. Also, comments would be nice. I was dreaming once about all-generic initarm() that would have KOBJ- based dispatcher, but am not sure this wouldn't cause some chicken-and- egg issues as some parts of the infrastructure might not be available at such early stages, but didn't investigate this too close, any thoughts? But anyways, even a simple scheme with common logic and function ptrs, which each platform variation would implement their own routines (or use generic), would improve the ARM init code significantly. Rafal From owner-freebsd-arm@FreeBSD.ORG Tue Nov 25 21:39:13 2008 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4ECC81065673 for ; Tue, 25 Nov 2008 21:39:13 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from semihalf.com (semihalf.com [206.130.101.55]) by mx1.freebsd.org (Postfix) with ESMTP id 294938FC0C for ; Tue, 25 Nov 2008 21:39:12 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from mail.semihalf.com (mail.semihalf.com [83.15.139.206]) by semihalf.com (8.13.1/8.13.1) with ESMTP id mAPLd9Km014642; Tue, 25 Nov 2008 14:39:10 -0700 Received: from apn-77-112-253-159.gprs.plus.pl (apn-77-112-253-159.gprs.plus.pl [77.112.253.159]) by mail.semihalf.com (Postfix) with ESMTP id 42ED714CD1; Tue, 25 Nov 2008 22:55:00 +0100 (CET) Message-Id: <835D3399-80D0-4AAA-BA85-FC922DEB6E7B@semihalf.com> From: =?ISO-8859-2?Q?Rafa=B3_Jaworowski?= To: "M. Warner Losh" In-Reply-To: <20081125.141957.1723235268.imp@bsdimp.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 25 Nov 2008 22:38:50 +0100 References: <20081125.104452.535842403.imp@bsdimp.com> <04BDAB4F-CF02-4CE6-90D8-E03EDC1CC8CC@semihalf.com> <20081125.141957.1723235268.imp@bsdimp.com> X-Mailer: Apple Mail (2.929.2) Cc: arm@FreeBSD.org Subject: Re: Code review request: boards on AT91 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Nov 2008 21:39:13 -0000 On 2008-11-25, at 22:19, M. Warner Losh wrote: > : > If anybody wants me to write up where I'm going with this, or > answer > : > any question, please feel free to ask. Also, comments would be > nice. > : > : I was dreaming once about all-generic initarm() that would have > KOBJ- > : based dispatcher, but am not sure this wouldn't cause some chicken- > and- > : egg issues as some parts of the infrastructure might not be > available > : at such early stages, but didn't investigate this too close, any > : thoughts? But anyways, even a simple scheme with common logic and > : function ptrs, which each platform variation would implement their > own > : routines (or use generic), would improve the ARM init code > : significantly. > > Yes. There's much duplication of code now, and I'd love to work > towards ways of coping with less duplication. I'd also like to see > the ability to compile code either for multi-board support, or just a > single board support. For the moment, I'd like to take the first step > and get to have the latter... > > The Marvell/Orion stuff has a much better separation, but still needs > some tweaks for board level support. I think I'm going to write up > what I've done and put it on a wiki and then ask if you could review > it and see if your experience with the Marvell implementation could > help refine it. Great, let me know when you got something in the wiki. Rafal From owner-freebsd-arm@FreeBSD.ORG Tue Nov 25 22:07:36 2008 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 493821065673 for ; Tue, 25 Nov 2008 22:07:36 +0000 (UTC) (envelope-from bahamasfranks@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by mx1.freebsd.org (Postfix) with ESMTP id F33028FC12 for ; Tue, 25 Nov 2008 22:07:35 +0000 (UTC) (envelope-from bahamasfranks@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so110965yxb.13 for ; Tue, 25 Nov 2008 14:07:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :sender:to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=1CpjYWGu18xYdu3W2ychULP7Ta1EvTvpAQp3M/xZ6Ko=; b=S26sTdjXo06mUPr5whQl9LwPqjFk2v2tz1oCdvEgEmgHurJtdFwL+P878Qa8hbr+ti MWF6+RKKwiJM/KRI12xz89ISVKwgqxiiVvRqUtis3lOCq+e30FSTvVkmlTLqVXxVwx4X 8KSa6foKPXzuhPajn/zt8KmvGQbgvHeO8bL+A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:sender:to:subject:cc:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:references:x-google-sender-auth; b=l7Z5ew9Kmt88uompvCntrKe32IhSAtGGzXio/9eQ/yaZPKFDdB+xlIPdg+aldD99+G 9hSreRz9zPq6iJGx/K60KUFEKdtJKuVQYl7FjKujKMdNthmmqqMHRtOeCxfdaJiJFyfP Y17ZKcwUu7v5BuARLeeyij6DlDxzgUEet6F2A= Received: by 10.100.125.9 with SMTP id x9mr2592643anc.139.1227649514244; Tue, 25 Nov 2008 13:45:14 -0800 (PST) Received: by 10.100.253.13 with HTTP; Tue, 25 Nov 2008 13:45:14 -0800 (PST) Message-ID: <539c60b90811251345i6c864442vebe71ee8654fd3fc@mail.gmail.com> Date: Tue, 25 Nov 2008 14:45:14 -0700 From: "Steve Franks" Sender: bahamasfranks@gmail.com To: "M. Warner Losh" In-Reply-To: <20081125.104452.535842403.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20081125.104452.535842403.imp@bsdimp.com> X-Google-Sender-Auth: ff1b08355900550b Cc: arm@freebsd.org Subject: Re: Code review request: boards on AT91 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stevefranks@ieee.org List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2008 22:07:36 -0000 > I'm trying a little experiment. I'm moving the board support for the > different sets of boards we support to their own file. This is the > first step in moving to supporting multiple boards more easily. > There's a number of gross hacks to make this work now in at91 land, > and I'd like to clean them up. The mv port is much cleaner, but we > still likely need some way to identify boards and get the right board > support code called. In Linux land, all ARM boot loaders are expected > to pass in a machine type, which is used to do the multiplexing. > Something similar in FreeBSD would be useful (and not just for ARM). > > Eventually, I'd like to see more common code between the different arm > variants. This will ease porting efforts as well as make the code > more robust. > > If anybody wants me to write up where I'm going with this, or answer > any question, please feel free to ask. Also, comments would be nice. I sure like where you're headed. Were it ever to become possible, I'd love a nano-bsd like environment on my NXP LPC2138 ARM7 processor. It's got 512k flash & 32k ram embedded and it's 60MHz, so it might be a bit anemic, but hey, they can run uClinux, and I hate to let those linux guys have the last laugh ;) A "beagleboard" is something I've got lying around with alot more horsepower, but I seem to recall the ARM Cortex M8 variant of our gcc wasn't exactly ready for primetime at the moment. The beagleboard sure runs enlightenment linux a heck of a lot better than my phone runs wince though, and I'd love to get there with BSD one day. Steve From owner-freebsd-arm@FreeBSD.ORG Tue Nov 25 22:16:38 2008 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C3D6106564A; Tue, 25 Nov 2008 22:16:38 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from semihalf.com (semihalf.com [206.130.101.55]) by mx1.freebsd.org (Postfix) with ESMTP id 16D728FC0A; Tue, 25 Nov 2008 22:16:38 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from mail.semihalf.com (mail.semihalf.com [83.15.139.206]) by semihalf.com (8.13.1/8.13.1) with ESMTP id mAPMGZ8O029755; Tue, 25 Nov 2008 15:16:36 -0700 Received: from apn-77-112-253-159.gprs.plus.pl (apn-77-112-253-159.gprs.plus.pl [77.112.253.159]) by mail.semihalf.com (Postfix) with ESMTP id 10DD71435F; Tue, 25 Nov 2008 23:32:21 +0100 (CET) Message-Id: <20EB52EA-EA95-42A4-9319-7838F0128447@semihalf.com> From: =?ISO-8859-2?Q?Rafa=B3_Jaworowski?= To: Nathan Whitehorn In-Reply-To: <492C74CE.4090808@freebsd.org> Content-Type: text/plain; charset=ISO-8859-2; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 25 Nov 2008 23:16:07 +0100 References: <20081125.104452.535842403.imp@bsdimp.com> <04BDAB4F-CF02-4CE6-90D8-E03EDC1CC8CC@semihalf.com> <492C74CE.4090808@freebsd.org> X-Mailer: Apple Mail (2.929.2) Cc: arm@FreeBSD.org Subject: Re: Code review request: boards on AT91 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Nov 2008 22:16:38 -0000 On 2008-11-25, at 22:57, Nathan Whitehorn wrote: > Rafa=B3 Jaworowski wrote: >> On 2008-11-25, at 18:44, M. Warner Losh wrote: >> >> >>> If anybody wants me to write up where I'm going with this, or answer >>> any question, please feel free to ask. Also, comments would be =20 >>> nice. >> >> I was dreaming once about all-generic initarm() that would have =20 >> KOBJ-based dispatcher, but am not sure this wouldn't cause some =20 >> chicken-and-egg issues as some parts of the infrastructure might =20 >> not be available at such early stages, but didn't investigate this =20= >> too close, any thoughts? But anyways, even a simple scheme with =20 >> common logic and function ptrs, which each platform variation would =20= >> implement their own routines (or use generic), would improve the =20 >> ARM init code significantly. > I am about to commit a patch in order to provide Open Firmware =20 > modularization using KOBJ (coincidentally, this should make =20 > supporting FDTs much easier). In order to this, I had to make KOBJ =20 > behave itself when invoked almost at the very beginning of the boot =20= > process on both PowerPC and SPARC, so you shouldn't have any trouble =20= > putting this in very early boot on ARM either once this hits the tree. Oh, very interesting news, thanks a lot -- I'll definitely look at =20 your code. Rafal= From owner-freebsd-arm@FreeBSD.ORG Tue Nov 25 22:24:07 2008 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C14C106564A for ; Tue, 25 Nov 2008 22:24:07 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 604718FC0C for ; Tue, 25 Nov 2008 22:24:07 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id mAPMKoHd064212; Tue, 25 Nov 2008 15:20:50 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 25 Nov 2008 15:22:18 -0700 (MST) Message-Id: <20081125.152218.756907300.imp@bsdimp.com> To: raj@semihalf.com From: "M. Warner Losh" In-Reply-To: <835D3399-80D0-4AAA-BA85-FC922DEB6E7B@semihalf.com> References: <04BDAB4F-CF02-4CE6-90D8-E03EDC1CC8CC@semihalf.com> <20081125.141957.1723235268.imp@bsdimp.com> <835D3399-80D0-4AAA-BA85-FC922DEB6E7B@semihalf.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable Cc: arm@FreeBSD.org Subject: Re: Code review request: boards on AT91 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Nov 2008 22:24:07 -0000 In message: <835D3399-80D0-4AAA-BA85-FC922DEB6E7B@semihalf.com> Rafa=B3_Jaworowski writes: : On 2008-11-25, at 22:19, M. Warner Losh wrote: : > : > If anybody wants me to write up where I'm going with this, or = : > answer : > : > any question, please feel free to ask. Also, comments would be= = : > nice. : > : : > : I was dreaming once about all-generic initarm() that would have = : > KOBJ- : > : based dispatcher, but am not sure this wouldn't cause some chicke= n- = : > and- : > : egg issues as some parts of the infrastructure might not be = : > available : > : at such early stages, but didn't investigate this too close, any : > : thoughts? But anyways, even a simple scheme with common logic and= : > : function ptrs, which each platform variation would implement thei= r = : > own : > : routines (or use generic), would improve the ARM init code : > : significantly. : > : > Yes. There's much duplication of code now, and I'd love to work : > towards ways of coping with less duplication. I'd also like to see= : > the ability to compile code either for multi-board support, or just= a : > single board support. For the moment, I'd like to take the first s= tep : > and get to have the latter... : > : > The Marvell/Orion stuff has a much better separation, but still nee= ds : > some tweaks for board level support. I think I'm going to write up= : > what I've done and put it on a wiki and then ask if you could revie= w : > it and see if your experience with the Marvell implementation could= : > help refine it. : = : Great, let me know when you got something in the wiki. There's a fairly lame version up now: http://wiki.freebsd.org/FreeBSDArmBoards We likely need a much less lame version :) Warner From owner-freebsd-arm@FreeBSD.ORG Tue Nov 25 22:29:29 2008 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1451106567A for ; Tue, 25 Nov 2008 22:29:29 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from smtp.ht-systems.ru (mr0.ht-systems.ru [78.110.50.55]) by mx1.freebsd.org (Postfix) with ESMTP id 8B33F8FC0A for ; Tue, 25 Nov 2008 22:29:29 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from [85.21.245.235] (helo=orion.SpringDaemons.com) by smtp.ht-systems.ru with esmtpa (Exim 4.62) (envelope-from ) id 1L56PK-0005Yc-TX; Wed, 26 Nov 2008 01:29:23 +0300 Received: from orion (localhost [127.0.0.1]) by orion.SpringDaemons.com (Postfix) with SMTP id 3085F398F3; Wed, 26 Nov 2008 01:30:52 +0300 (MSK) Date: Wed, 26 Nov 2008 01:30:47 +0300 From: Stanislav Sedov To: stevefranks@ieee.org Message-Id: <20081126013047.e91ccbdd.stas@FreeBSD.org> In-Reply-To: <539c60b90811251345i6c864442vebe71ee8654fd3fc@mail.gmail.com> References: <20081125.104452.535842403.imp@bsdimp.com> <539c60b90811251345i6c864442vebe71ee8654fd3fc@mail.gmail.com> Organization: The FreeBSD Project X-XMPP: ssedov@jabber.ru X-Voice: +7 916 849 20 23 X-PGP-Fingerprint: F21E D6CC 5626 9609 6CE2 A385 2BF5 5993 EB26 9581 X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: arm@freebsd.org Subject: Re: Code review request: boards on AT91 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Nov 2008 22:29:29 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 25 Nov 2008 14:45:14 -0700 "Steve Franks" mentioned: > I sure like where you're headed. Were it ever to become possible, I'd > love a nano-bsd like environment on my NXP LPC2138 ARM7 processor. > It's got 512k flash & 32k ram embedded and it's 60MHz, so it might be > a bit anemic, but hey, they can run uClinux, and I hate to let those > linux guys have the last laugh ;) I don't think it's possible. This CPU lacks MMU and MPU, thus no memory space separation at all. uClinux is not the Linux, after all. - -- Stanislav Sedov ST4096-RIPE -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAkksfJwACgkQK/VZk+smlYETcQCdEbsZBC2Z+tsA6e99nYO2LH3e lHcAnRtBPn+EdSRFYysVAjXejrsXVArv =6FiJ -----END PGP SIGNATURE----- From owner-freebsd-arm@FreeBSD.ORG Tue Nov 25 22:53:40 2008 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B622E106564A for ; Tue, 25 Nov 2008 22:53:40 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from adsum.doit.wisc.edu (adsum.doit.wisc.edu [144.92.197.210]) by mx1.freebsd.org (Postfix) with ESMTP id 90E418FC12 for ; Tue, 25 Nov 2008 22:53:40 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=UTF-8; format=flowed Received: from avs-daemon.smtpauth1.wiscmail.wisc.edu by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) id <0KAW00L00STGYT00@smtpauth1.wiscmail.wisc.edu> for arm@FreeBSD.org; Tue, 25 Nov 2008 15:53:40 -0600 (CST) Received: from sark.icecube.wisc.edu ([128.104.34.126]) by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) with ESMTPSA id <0KAW00HY8ST6EN30@smtpauth1.wiscmail.wisc.edu>; Tue, 25 Nov 2008 15:53:32 -0600 (CST) Date: Tue, 25 Nov 2008 15:57:34 -0600 From: Nathan Whitehorn In-reply-to: <04BDAB4F-CF02-4CE6-90D8-E03EDC1CC8CC@semihalf.com> To: =?UTF-8?B?UmFmYcWCIEphd29yb3dza2k=?= Message-id: <492C74CE.4090808@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=128.104.34.126 X-Spam-PmxInfo: Server=avs-11, Version=5.4.1.325704, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2008.11.25.214326, SenderIP=128.104.34.126 References: <20081125.104452.535842403.imp@bsdimp.com> <04BDAB4F-CF02-4CE6-90D8-E03EDC1CC8CC@semihalf.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080211) Cc: arm@FreeBSD.org Subject: Re: Code review request: boards on AT91 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Nov 2008 22:53:40 -0000 Rafał Jaworowski wrote: > On 2008-11-25, at 18:44, M. Warner Losh wrote: > > >> If anybody wants me to write up where I'm going with this, or answer >> any question, please feel free to ask. Also, comments would be nice. > > I was dreaming once about all-generic initarm() that would have > KOBJ-based dispatcher, but am not sure this wouldn't cause some > chicken-and-egg issues as some parts of the infrastructure might not > be available at such early stages, but didn't investigate this too > close, any thoughts? But anyways, even a simple scheme with common > logic and function ptrs, which each platform variation would implement > their own routines (or use generic), would improve the ARM init code > significantly. I am about to commit a patch in order to provide Open Firmware modularization using KOBJ (coincidentally, this should make supporting FDTs much easier). In order to this, I had to make KOBJ behave itself when invoked almost at the very beginning of the boot process on both PowerPC and SPARC, so you shouldn't have any trouble putting this in very early boot on ARM either once this hits the tree. -Nathan