From owner-freebsd-arm@FreeBSD.ORG Sun May 6 17:43:13 2012 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 83DAD1065670; Sun, 6 May 2012 17:43:13 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh7.mail.rice.edu (mh7.mail.rice.edu [128.42.199.46]) by mx1.freebsd.org (Postfix) with ESMTP id 566048FC08; Sun, 6 May 2012 17:43:13 +0000 (UTC) Received: from mh7.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh7.mail.rice.edu (Postfix) with ESMTP id E4528292131; Sun, 6 May 2012 12:35:34 -0500 (CDT) Received: from mh7.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh7.mail.rice.edu (Postfix) with ESMTP id D035A292170; Sun, 6 May 2012 12:35:34 -0500 (CDT) X-Virus-Scanned: by amavis-2.6.4 at mh7.mail.rice.edu, auth channel Received: from mh7.mail.rice.edu ([127.0.0.1]) by mh7.mail.rice.edu (mh7.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id TAjvZiKXT2Ne; Sun, 6 May 2012 12:35:34 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh7.mail.rice.edu (Postfix) with ESMTPSA id 3A637292131; Sun, 6 May 2012 12:35:34 -0500 (CDT) Message-ID: <4FA6B665.1040709@rice.edu> Date: Sun, 06 May 2012 12:35:33 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:8.0) Gecko/20111113 Thunderbird/8.0 MIME-Version: 1.0 To: Warner Losh References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "arm@freebsd.org" , Alan Cox Subject: Re: Review needed 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: Sun, 06 May 2012 17:43:13 -0000 On 05/05/2012 01:45, Warner Losh wrote: > I just tried to bring up an old Gateworks AVILA board that I'd acquired a long time ago.... > > After fighting through a few bugs in the nanobsd build, I managed to get an image. > > That image failed to boot. When it harvested entropy, it just started printing pmap_mincore() over and over again until I hit ^T enough to let the rest of the boot process continue. Sure enough, arm's pmap_mincore() returns 0 after printing this. > > So, I cobbled together the following after looking at mips and amd64's pmap_mincore() functions. > > I've just cut and pasted it here since I think that might be easier to review than a diff, but I've also uploaded that as well to http://people.freebsd.org/~imp/arm-pmap_mincore.diff > > Comments? > > Warner > > /* > * perform the pmap work for mincore > */ > int > pmap_mincore(pmap_t pmap, vm_offset_t addr, vm_paddr_t *locked_pa) > { > struct l2_bucket *l2b; > pt_entry_t *ptep, pte; > vm_paddr_t pa; > vm_page_t m; > int val; > boolean_t managed; > > PMAP_LOCK(pmap); > retry: > l2b = pmap_get_l2_bucket(pmap, addr); > if (l2b == NULL) { > val = 0; > goto out; > } > ptep =&l2b->l2b_kva[l2pte_index(addr)]; > pte = (ptep != NULL) ? *ptep : 0; > if (!l2pte_valid(pte)) { > val = 0; > goto out; > } > val = MINCORE_INCORE; > if (pte& L2_S_PROT_W) > val |= MINCORE_MODIFIED | MINCORE_MODIFIED_OTHER; > managed = false; > pa = l2pte_pa(pte); > m = PHYS_TO_VM_PAGE(pa); > if (m != NULL&& !(m->oflags& VPO_UNMANAGED)) > managed = true; > if (managed) { > /* > * This may falsely report the given address as > * MINCORE_REFERENCED. Unfortunately, due to the lack of > * per-PTE reference information, it is impossible to > * determine if the address is MINCORE_REFERENCED. > */ > if ((m->aflags& PGA_REFERENCED) != 0) I believe that you want to use "if ((m->md.pvh_attrs & PVF_REF) != 0)" here instead. Strictly speaking, the ARM pmap tries to maintain a per-mapping reference bit. The trouble is that it's kept in the PV entry, not the PTE, so it's costly to access here. You would need to acquire the page queues lock, call pmap_find_pv(), and introduce a custom version of vm_page_pa_tryrelock() that releases and reacquires the page queues lock. In the end, I doubt it's worthwhile. However, it would make sense for the comment to mention this. > val |= MINCORE_REFERENCED | MINCORE_REFERENCED_OTHER; > } > if ((val& (MINCORE_MODIFIED_OTHER | MINCORE_REFERENCED_OTHER)) != > (MINCORE_MODIFIED_OTHER | MINCORE_REFERENCED_OTHER)&& managed) { > /* Ensure that "PHYS_TO_VM_PAGE(pa)->object" doesn't change. */ > if (vm_page_pa_tryrelock(pmap, pa, locked_pa)) > goto retry; > } else > out: > PA_UNLOCK_COND(*locked_pa); > PMAP_UNLOCK(pmap); > return (val); > } > > From owner-freebsd-arm@FreeBSD.ORG Sun May 6 18:47:26 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A25DC106566B for ; Sun, 6 May 2012 18:47:26 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id 732E68FC16 for ; Sun, 6 May 2012 18:47:26 +0000 (UTC) Received: by dacx6 with SMTP id x6so8314937dac.17 for ; Sun, 06 May 2012 11:47:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:from:content-type:content-transfer-encoding:subject:date :message-id:to:mime-version:x-mailer:x-gm-message-state; bh=mRQEiYoOXYPZKej4MVjpikfHaGfykzhRkPyWxPereWs=; b=lxuU0Gnd0ESoNTBYr4g1f41fg2pl2oaCGhzxVCWmq1x2yCj6oebejogOloDM/ncIuX rgXQVcJp1ssfQhvMploKYrvh2hFRw6NxOOiC2HkSrz/bNB/H6IrH5O4xCXvUhezJAvp7 kTfMB39fLMG5YZkSwdUaY4WleqSHQrtGJmWLBz+CzzbpRW4xN6PqVdtOyp8QWpSZJLHK 7g+opOYcxi6C7ugVhTrUaOtuILiTjf4HhNzlTIauEpKWWyTxZQWftk4U60aP0Sjwnkq6 mAbllFQxO9rQqaKRO+fH3i6Fo2GWXbtSRoV0uH3rCd+0GYtvoZUJTNT7LQsQuUQWhrwu tX9g== Received: by 10.68.233.103 with SMTP id tv7mr19896261pbc.97.1336330045978; Sun, 06 May 2012 11:47:25 -0700 (PDT) Received: from [192.168.1.69] (99-74-169-43.lightspeed.sntcca.sbcglobal.net. [99.74.169.43]) by mx.google.com with ESMTPS id tx5sm629661pbc.51.2012.05.06.11.47.22 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 06 May 2012 11:47:24 -0700 (PDT) Sender: Tim Kientzle From: Tim Kientzle Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 6 May 2012 11:47:21 -0700 Message-Id: <445DEE92-0A38-429C-B628-E272111964F2@freebsd.org> To: arm@freebsd.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQnXAWgljr0xGR4o1zUPopASY6/FFKKfboKk2B4Qtjq/jLWhEBtdK+GY8k1YOTU+13ojTClk Cc: Subject: Armv6 build failures 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: Sun, 06 May 2012 18:47:26 -0000 Updated my armv6 tree a couple of hours ago and am now seeing these: $ make TARGET_ARCH=3Darm TARGET_CPUTYPE=3Darmv6 buildworld=20 cc -O -pipe -march=3Darmv6 -DARM_ARCH_6=3D1 = -I/usr/home/tim/projects/beaglebsd/src-armv6/lib/libc/include = -I/usr/home/tim/projects/beaglebsd/src-armv6/lib/libc/../../include = -I/usr/home/tim/projects/beaglebsd/src-armv6/lib/libc/arm -DNLS = -D__DBINTERFACE_PRIVATE = -I/usr/home/tim/projects/beaglebsd/src-armv6/lib/libc/../../contrib/gdtoa = -DINET6 = -I/usr/obj/arm.arm/usr/home/tim/projects/beaglebsd/src-armv6/lib/libc = -I/usr/home/tim/projects/beaglebsd/src-armv6/lib/libc/resolv = -D_ACL_PRIVATE -DPOSIX_MISTAKE = -I/usr/home/tim/projects/beaglebsd/src-armv6/lib/libc/../../contrib/jemall= oc/include = -I/usr/home/tim/projects/beaglebsd/src-armv6/lib/libc/../../contrib/tzcode= /stdtime -I/usr/home/tim/projects/beaglebsd/src-armv6/lib/libc/stdtime = -I/usr/home/tim/projects/beaglebsd/src-armv6/lib/libc/locale = -DBROKEN_DES -DPORTMAP -DDES_BUILTIN = -I/usr/home/tim/projects/beaglebsd/src-armv6/lib/libc/rpc = -I/usr/home/tim/projects/beaglebsd/src-armv6/lib/libc/arm/softfloat = -I/usr/home/tim/projects/beaglebsd/src-armv6/lib/libc/softfloat = -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 = -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized = -Wno-pointer-sign -c = /usr/home/tim/projects/beaglebsd/src-armv6/lib/libc/arm/gen/_set_tp.c -o = _set_tp.o /usr/home/tim/projects/beaglebsd/src-armv6/lib/libc/arm/gen/_set_tp.c: = In function '_set_tp': = /usr/home/tim/projects/beaglebsd/src-armv6/lib/libc/arm/gen/_set_tp.c:38: = error: 'ARM_TP_ADDRESS' undeclared (first use in this function) = /usr/home/tim/projects/beaglebsd/src-armv6/lib/libc/arm/gen/_set_tp.c:38: = error: (Each undeclared identifier is reported only once = /usr/home/tim/projects/beaglebsd/src-armv6/lib/libc/arm/gen/_set_tp.c:38: = error: for each function it appears in.) *** Error code 1 $ make TARGET_ARCH=3Darm KERNCONF=3DBEAGLEBONE buildkernel cc -mlittle-endian -c -O -pipe -std=3Dc99 -g -Wall -Wredundant-decls = -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes = -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign = -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option = -nostdinc -I. -I/usr/home/tim/projects/beaglebsd/src-armv6/sys = -I/usr/home/tim/projects/beaglebsd/src-armv6/sys/contrib/altq = -I/usr/home/tim/projects/beaglebsd/src-armv6/sys/contrib/libfdt = -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common = -finline-limit=3D8000 --param inline-unit-growth=3D100 --param = large-function-growth=3D1000 -D_ARM_ARCH_6 -ffreestanding -Werror = /usr/home/tim/projects/beaglebsd/src-armv6/sys/arm/ti/cpsw/if_cpsw.c cc1: warnings being treated as errors /usr/home/tim/projects/beaglebsd/src-armv6/sys/arm/ti/cpsw/if_cpsw.c: In = function 'cpsw_attach': = /usr/home/tim/projects/beaglebsd/src-armv6/sys/arm/ti/cpsw/if_cpsw.c:234: = warning: passing argument 2 of 'fdt_get_phyaddr' from incompatible = pointer type = /usr/home/tim/projects/beaglebsd/src-armv6/sys/arm/ti/cpsw/if_cpsw.c:234: = error: too few arguments to function 'fdt_get_phyaddr' *** Error code 1 For the latter, it looks like this might fix it? (Copied without = understanding from other places where fdt_get_phyaddr is called.) Index: if_cpsw.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- if_cpsw.c (revision 235097) +++ if_cpsw.c (working copy) @@ -231,7 +231,7 @@ cpsw_sc =3D sc; =20 /* Get phy address from fdt */ - if (fdt_get_phyaddr(sc->node, &phy) !=3D 0) { + if (fdt_get_phyaddr(sc->node, sc->dev, &phy, (void = **)&sc->phy_sc) !=3D 0) { device_printf(dev, "failed to get PHY address from = FDT\n"); return (ENXIO); } From owner-freebsd-arm@FreeBSD.ORG Sun May 6 23:05:51 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 23FD2106564A; Sun, 6 May 2012 23:05:51 +0000 (UTC) (envelope-from damjan.marion@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 745938FC08; Sun, 6 May 2012 23:05:50 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so964633wgb.31 for ; Sun, 06 May 2012 16:05:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=CWvJDB9/VJPCJJOWEj74/tGdIqzwgB+ry3P+4pN468I=; b=piRKFT8CiAZcyx0Vk20u/os0PkkZrbl0zSloV3Vo920QjgV4Y5b5EbN5P0TWjCRa5I 590u4X0WdOa9R9zON3WYjoGRYLIlx0yIID1sNTvo8ubABwPnUmuI9ZT4b8nn0c9iNmPg BavdRisD51p8tealM2LZkH0JXs8Oq3vwnw7Egl2lfY06JJ7gbEReRj2am2O/OtIzLpmV 2hjdnVJSNd36xyibNo9T0cBfQNp3ykYRIhRcNjnuU9E+iZVOuqKlzqo/D0nGfKCDqaoJ 6bsUWyBfJGaTbGHdWQNWPbA+cWCaj0y65QY7dKkReGAuSGFyKDXVDSNj2l2BGA7u0JBl ewWw== Received: by 10.180.89.9 with SMTP id bk9mr30021882wib.11.1336345549419; Sun, 06 May 2012 16:05:49 -0700 (PDT) Received: from damarion-mac.home (cpe-109-60-74-41.zg3.cable.xnet.hr. [109.60.74.41]) by mx.google.com with ESMTPS id h5sm27235718wiy.3.2012.05.06.16.05.48 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 06 May 2012 16:05:48 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Damjan Marion In-Reply-To: <445DEE92-0A38-429C-B628-E272111964F2@freebsd.org> Date: Mon, 7 May 2012 01:05:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <445DEE92-0A38-429C-B628-E272111964F2@freebsd.org> To: Tim Kientzle X-Mailer: Apple Mail (2.1257) Cc: arm@freebsd.org Subject: Re: Armv6 build failures 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: Sun, 06 May 2012 23:05:51 -0000 On May 6, 2012, at 8:47 PM, Tim Kientzle wrote: > For the latter, it looks like this might fix it? (Copied without = understanding from other places where fdt_get_phyaddr is called.) I noticed the same yesterday and commited fix few mins ago (r235113). Damjan= From owner-freebsd-arm@FreeBSD.ORG Mon May 7 11:07:08 2012 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 8544C1065674 for ; Mon, 7 May 2012 11:07:08 +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 6F2668FC1E for ; Mon, 7 May 2012 11:07:08 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q47B78nW072310 for ; Mon, 7 May 2012 11:07:08 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q47B777h072308 for freebsd-arm@FreeBSD.org; Mon, 7 May 2012 11:07:07 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 7 May 2012 11:07:07 GMT Message-Id: <201205071107.q47B777h072308@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, 07 May 2012 11:07:08 -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/166256 arm build fail in pmap.c o arm/162159 arm [panic] USB errors leading to panic on DockStar 9.0-RC o arm/161110 arm /usr/src/sys/arm/include/signal.h is bad o arm/161044 arm devel/icu does not build on arm o arm/160431 arm [busdma] [patch] Disable interrupts during busdma cach o arm/158950 arm arm/sheevaplug fails fsx when mmap operations are enab o arm/156814 arm OpenRD Ultimate does not boot on DB-88F6XXX or SHEEVAP o arm/156496 arm [patch] Minor bugfixes and enhancements to mmc and mmc o arm/155894 arm [patch] Enable at91 booting from SDHC (high capacity) o arm/155214 arm [patch] MMC/SD IO slow on Atmel ARM with modern large o arm/154227 arm [geli] using GELI leads to panic on ARM o arm/154189 arm lang/perl5.12 doesn't build on arm o arm/153380 arm Panic / translation fault with wlan on ARM o arm/150581 arm [irq] Unknown error generates IRQ address decoding err o arm/149288 arm mail/dovecot causes panic during configure on Sheevapl o arm/134368 arm [patch] nslu2_led driver for the LEDs on the NSLU2 p arm/134338 arm [patch] Lock GPIO accesses on ixp425 17 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon May 7 12:20:12 2012 Return-Path: Delivered-To: freebsd-arm@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F003710657FA for ; Mon, 7 May 2012 12:20:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BAA508FC15 for ; Mon, 7 May 2012 12:20:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q47CKCkP043986 for ; Mon, 7 May 2012 12:20:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q47CKC3G043985; Mon, 7 May 2012 12:20:12 GMT (envelope-from gnats) Date: Mon, 7 May 2012 12:20:12 GMT Message-Id: <201205071220.q47CKC3G043985@freefall.freebsd.org> To: freebsd-arm@FreeBSD.org From: Kristof Provost Cc: Subject: arm/158950: arm/sheevaplug fails fsx when mmap operations are enabled X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Kristof Provost List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 12:20:13 -0000 The following reply was made to PR arm/158950; it has been noted by GNATS. From: Kristof Provost To: bug-followup@FreeBSD.org Cc: Subject: arm/158950: arm/sheevaplug fails fsx when mmap operations are enabled Date: Mon, 7 May 2012 14:15:51 +0200 Based on a suggestion from Ian Lepore I switched the data cache from write-back to write-through mode. In that case the problem doesn't occur. Ian suggested this might indicate a problem in the busdma cacheline flush code, but unfortunately I'm somewhat out of my depth there. From owner-freebsd-arm@FreeBSD.ORG Mon May 7 14:05:31 2012 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 344B41065673; Mon, 7 May 2012 14:05:31 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0A2B78FC12; Mon, 7 May 2012 14:05:31 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6CD6BB95D; Mon, 7 May 2012 10:05:30 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Mon, 7 May 2012 09:57:03 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <3B2A320B-3ADE-4F48-B94E-4F0886178251@freebsd.org> In-Reply-To: <3B2A320B-3ADE-4F48-B94E-4F0886178251@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201205070957.03842.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 07 May 2012 10:05:30 -0400 (EDT) Cc: arm@freebsd.org Subject: Re: How does loader(8) decide where to load the kernel? 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, 07 May 2012 14:05:31 -0000 On Saturday, May 05, 2012 1:06:13 am Tim Kientzle wrote: > I have ubldr loading the ELF kernel on BeagleBone and am now > trying to untangle some of the hacks I used to get this working. > > Unfortunately, there's one area of the common loader(8) code > that I really don't understand: How does sys/boot/common/load_elf.c > determine the physical address at which to load the kernel? > > __elfN(loadfile) has the following comment: > > [The file] will be stored at (dest). > > But that's not really true. For starters, loadfile maps dest > through archsw.arch_loadaddr. (This mechanism seems > to only be used on ia64 and pc98, though the result is > later discarded on those platforms.) > > Loadfile then passes the value to loadimage which does > very strange things: > > On i386, amd64, powerpc, and arm, loadimage subtracts > the dest value from the address declared in the actual ELF > headers so that the kernel always gets loaded into low memory. > (there's some intermediate bit-twiddling I'm glossing over, but > this is the general idea). The bit twiddling is supposed to be the equivalent of subtracting KERNBASE from the load address. On both i386 and amd64, there is a direct mapping of the kernel text such that KERNBASE maps address 0, etc. By default on i386 KERNBASE is 0xc0000000. -- John Baldwin From owner-freebsd-arm@FreeBSD.ORG Tue May 8 05:32:17 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1CA0F1065673 for ; Tue, 8 May 2012 05:32:17 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id DA5268FC0C for ; Tue, 8 May 2012 05:32:16 +0000 (UTC) Received: by dadv36 with SMTP id v36so1921196dad.13 for ; Mon, 07 May 2012 22:32:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=MX9zryC2Cu3MwYSe7jN0diR8YVnYnN0lg9vrajHAHhI=; b=EIEW1Q+Y6RJt9G+aMxs3Bcx30CIjXOuuUAVWDrhVw/jL/YS3zuQjZptF/QbVPadfSf ZFbsvUayxyFW0C73mX2eCNFVnYOaet0R+Yo+HlvLXcSwlNG9cixwvUnmoy3YcghZk+Xa ibyFcLN1Hw/qjipssHt9GjHGSAQ22PP727oAvo5dOJWl7UAWB/meFNUrdLIJPBaOvuF/ 8NctMfd4Lsmg84bpbmv1b8eJ1Au2oKNYPSBKKvEWlZJhIf7xUWpKzZe1tIwY6Y5MwMek sIF9WSu5ez449agPdIWoMBusYF/GFORyriIfhlLNuaQTBhUjMCKMgTruI4uw+xun/Smc c0PQ== Received: by 10.68.212.197 with SMTP id nm5mr4267947pbc.110.1336455136349; Mon, 07 May 2012 22:32:16 -0700 (PDT) Received: from [192.168.1.69] (99-74-169-43.lightspeed.sntcca.sbcglobal.net. [99.74.169.43]) by mx.google.com with ESMTPS id d6sm1185045pbi.23.2012.05.07.22.32.12 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 May 2012 22:32:13 -0700 (PDT) Sender: Tim Kientzle Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Tim Kientzle In-Reply-To: <201205070957.03842.jhb@freebsd.org> Date: Mon, 7 May 2012 22:32:10 -0700 Content-Transfer-Encoding: 7bit Message-Id: <8B01DF29-747A-449C-A762-E852F57C6380@freebsd.org> References: <3B2A320B-3ADE-4F48-B94E-4F0886178251@freebsd.org> <201205070957.03842.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQnFzfqESf93qrxE2Ev6eJdXbNwkCskZxZb61H09aOsWYkLC2CUgJgyiCUMxI3vy5XpXBDmv Cc: arm@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: How does loader(8) decide where to load the kernel? 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, 08 May 2012 05:32:17 -0000 On May 7, 2012, at 6:57 AM, John Baldwin wrote: > On Saturday, May 05, 2012 1:06:13 am Tim Kientzle wrote: >> I have ubldr loading the ELF kernel on BeagleBone and am now >> trying to untangle some of the hacks I used to get this working. >> >> Unfortunately, there's one area of the common loader(8) code >> that I really don't understand: How does sys/boot/common/load_elf.c >> determine the physical address at which to load the kernel? >> >> __elfN(loadfile) has the following comment: >> >> [The file] will be stored at (dest). >> >> But that's not really true. For starters, loadfile maps dest >> through archsw.arch_loadaddr. (This mechanism seems >> to only be used on ia64 and pc98, though the result is >> later discarded on those platforms.) >> >> Loadfile then passes the value to loadimage which does >> very strange things: >> >> On i386, amd64, powerpc, and arm, loadimage subtracts >> the dest value from the address declared in the actual ELF >> headers so that the kernel always gets loaded into low memory. >> (there's some intermediate bit-twiddling I'm glossing over, but >> this is the general idea). > > The bit twiddling is supposed to be the equivalent of subtracting > KERNBASE from the load address. On both i386 and amd64, there is > a direct mapping of the kernel text such that KERNBASE maps address > 0, etc. By default on i386 KERNBASE is 0xc0000000. Exactly my problem. This all assumes that you're loading the kernel into low memory. On the AM3358, the DRAM starts at 0x8000 0000 on boot, so I'm trying to find a clean way to convince the loader's ELF code to put the kernel there. Tim From owner-freebsd-arm@FreeBSD.ORG Tue May 8 09:41:25 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0D7D71065679; Tue, 8 May 2012 09:41:25 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from mailfilter12.ihug.co.nz (mailfilter12.ihug.co.nz [203.109.136.12]) by mx1.freebsd.org (Postfix) with ESMTP id 444478FC1C; Tue, 8 May 2012 09:41:24 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.0 c=1 a=2LU9hpEdpD8A:10 a=kj9zAlcOel0A:10 a=6ftCXtrV6KU8V8Uh/wkvUw==:17 a=6I5d2MoRAAAA:8 a=RAuyRO8aAAAA:8 a=Z99owlsjL6tQOCPQm5YA:9 a=QGwn88ynb5q_FL5o2zQA:7 a=CjuIK1q_8ugA:10 a=SV7veod9ZcQA:10 a=vyoC9CF5tf3hooPs:21 a=_nHp_P4zyDSC04mO:21 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAF7pqE/LrZVI/2dsb2JhbABEsySBCIIMAQEEATocIxAIAxguOR4GE4gJBAy7KYsDhgkElX0BgRGNVIFdgn4 X-IronPort-AV: E=Sophos;i="4.75,549,1330858800"; d="scan'208";a="104511305" Received: from 203-173-149-72.dsl.dyn.ihug.co.nz (HELO localhost) ([203.173.149.72]) by cust.filter2.content.vf.net.nz with SMTP; 08 May 2012 21:40:14 +1200 Date: Tue, 8 May 2012 21:39:54 +1200 From: Andrew Turner To: Tim Kientzle Message-ID: <20120508213954.3c4a0c0e@fubar.geek.nz> In-Reply-To: <8B01DF29-747A-449C-A762-E852F57C6380@freebsd.org> References: <3B2A320B-3ADE-4F48-B94E-4F0886178251@freebsd.org> <201205070957.03842.jhb@freebsd.org> <8B01DF29-747A-449C-A762-E852F57C6380@freebsd.org> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; i386-portbld-freebsd8.0) X-Pirate: Arrrr Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: arm@freebsd.org, freebsd-hackers@freebsd.org, John Baldwin Subject: Re: How does loader(8) decide where to load the kernel? 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, 08 May 2012 09:41:25 -0000 On Mon, 7 May 2012 22:32:10 -0700 Tim Kientzle wrote: > > On May 7, 2012, at 6:57 AM, John Baldwin wrote: > > > On Saturday, May 05, 2012 1:06:13 am Tim Kientzle wrote: > >> I have ubldr loading the ELF kernel on BeagleBone and am now > >> trying to untangle some of the hacks I used to get this working. > >> > >> Unfortunately, there's one area of the common loader(8) code > >> that I really don't understand: How does > >> sys/boot/common/load_elf.c determine the physical address at which > >> to load the kernel? > >> > >> __elfN(loadfile) has the following comment: > >> > >> [The file] will be stored at (dest). > >> > >> But that's not really true. For starters, loadfile maps dest > >> through archsw.arch_loadaddr. (This mechanism seems > >> to only be used on ia64 and pc98, though the result is > >> later discarded on those platforms.) > >> > >> Loadfile then passes the value to loadimage which does > >> very strange things: > >> > >> On i386, amd64, powerpc, and arm, loadimage subtracts > >> the dest value from the address declared in the actual ELF > >> headers so that the kernel always gets loaded into low memory. > >> (there's some intermediate bit-twiddling I'm glossing over, but > >> this is the general idea). > > > > The bit twiddling is supposed to be the equivalent of subtracting > > KERNBASE from the load address. On both i386 and amd64, there is > > a direct mapping of the kernel text such that KERNBASE maps address > > 0, etc. By default on i386 KERNBASE is 0xc0000000. > > Exactly my problem. This all assumes that you're loading > the kernel into low memory. > > On the AM3358, the DRAM starts at 0x8000 0000 > on boot, so I'm trying to find a clean way to convince > the loader's ELF code to put the kernel there. I have a script at [1] that builds an image to load the kernel directly from U-Boot. It figures out where to tell U-Boot to load a kernel by using readelf to find the value of physaddr and kernbase to use to calculate what physical addresses to use to load the kernel to and where the first instruction to execute is. Andrew [1] http://fubar.geek.nz/files/freebsd/omap/build_beagle.sh From owner-freebsd-arm@FreeBSD.ORG Tue May 8 15:45:59 2012 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 D26D2106566B for ; Tue, 8 May 2012 15:45:59 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9B1D68FC0A for ; Tue, 8 May 2012 15:45:59 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so9216228pbb.13 for ; Tue, 08 May 2012 08:45:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=PnQau39BPOU03qvZh4c9KpezY7gUldVOJjAlS39vsOY=; b=dQYBPbgUhZFYZMPB/IJ3NaZnxk1S6brBhtSdnrx+eiZv7Yk95SKJc//6Ly8RFYB3QT IvYKkcyaVYnrSUpdYvHdvJiPxAJ/5zfLDwnX01a3HHi3G5wnKPT1zSaOEbpwo0Cba3wt j3ZSW4e/rCi2RXpbbFHRjBGaHVPQuf0e1r2hzB4K12P3U8dMYgPdrSbMuhX7PWYLKbHM aIHw6phZbQsRorzfWi2Ynq+05reKBi47hQ18V84JOaDAL3Xhrh5jFK7/s8FtauCuQ/Jq yuk23X1/BovN33AwoGttoAvyqWVoq1U+awyoGoEuTtsNCCFKm8PWfHIexGcHnBidsPky OjAA== Received: by 10.68.213.162 with SMTP id nt2mr1916383pbc.31.1336491959135; Tue, 08 May 2012 08:45:59 -0700 (PDT) Received: from [192.168.1.69] (99-74-169-43.lightspeed.sntcca.sbcglobal.net. [99.74.169.43]) by mx.google.com with ESMTPS id py6sm2761479pbc.13.2012.05.08.08.45.55 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 May 2012 08:45:57 -0700 (PDT) Sender: Tim Kientzle Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <20120508213954.3c4a0c0e@fubar.geek.nz> Date: Tue, 8 May 2012 08:45:53 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <3B2A320B-3ADE-4F48-B94E-4F0886178251@freebsd.org> <201205070957.03842.jhb@freebsd.org> <8B01DF29-747A-449C-A762-E852F57C6380@freebsd.org> <20120508213954.3c4a0c0e@fubar.geek.nz> To: Andrew Turner X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQlW/2nV9AdbH6b2TW4HRNQVOtxE2CE4qNMuY3s3b8YPPkX0ayZkQMUPHb3pYpkEi48YgANt Cc: arm@freebsd.org, freebsd-hackers@freebsd.org, John Baldwin Subject: Re: How does loader(8) decide where to load the kernel? 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, 08 May 2012 15:45:59 -0000 On May 8, 2012, at 2:39 AM, Andrew Turner wrote: > On Mon, 7 May 2012 22:32:10 -0700 > Tim Kientzle wrote: > >> >> On May 7, 2012, at 6:57 AM, John Baldwin wrote: >>> >>> The bit twiddling is supposed to be the equivalent of subtracting >>> KERNBASE from the load address. On both i386 and amd64, there is >>> a direct mapping of the kernel text such that KERNBASE maps address >>> 0, etc. By default on i386 KERNBASE is 0xc0000000. >> >> Exactly my problem. This all assumes that you're loading >> the kernel into low memory. >> >> On the AM3358, the DRAM starts at 0x8000 0000 >> on boot, so I'm trying to find a clean way to convince >> the loader's ELF code to put the kernel there. > > I have a script at [1] that builds an image to load the kernel directly > from U-Boot. It figures out where to tell U-Boot to load a kernel by > using readelf to find the value of physaddr and kernbase to use to > calculate what physical addresses to use to load the kernel to and > where the first instruction to execute is. I have a script at [2] that builds a FreeBSD image for BeagleBone that chain loads U-Boot, then ubldr, then loads the ELF kernel from UFS. Works very well, but it relies on some hacks to the common load_elf code that I'd like to find a clean way to generalize. [2] https://github.com/kientzle/freebsd-beaglebone From owner-freebsd-arm@FreeBSD.ORG Thu May 10 12:32:37 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2D332106566C; Thu, 10 May 2012 12:32:37 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id E9A208FC0A; Thu, 10 May 2012 12:32:36 +0000 (UTC) Received: from sa-nc-cs-39.static.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q4ACWSvP075253 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 10 May 2012 05:32:35 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Marcel Moolenaar In-Reply-To: <8B01DF29-747A-449C-A762-E852F57C6380@freebsd.org> Date: Thu, 10 May 2012 08:32:23 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <3B2A320B-3ADE-4F48-B94E-4F0886178251@freebsd.org> <201205070957.03842.jhb@freebsd.org> <8B01DF29-747A-449C-A762-E852F57C6380@freebsd.org> To: Tim Kientzle X-Mailer: Apple Mail (2.1278) Cc: arm@freebsd.org, freebsd-hackers@freebsd.org, John Baldwin Subject: Re: How does loader(8) decide where to load the kernel? 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: Thu, 10 May 2012 12:32:37 -0000 On May 8, 2012, at 1:32 AM, Tim Kientzle wrote: >>> On i386, amd64, powerpc, and arm, loadimage subtracts >>> the dest value from the address declared in the actual ELF >>> headers so that the kernel always gets loaded into low memory. >>> (there's some intermediate bit-twiddling I'm glossing over, but >>> this is the general idea). >> >> The bit twiddling is supposed to be the equivalent of subtracting >> KERNBASE from the load address. On both i386 and amd64, there is >> a direct mapping of the kernel text such that KERNBASE maps address >> 0, etc. By default on i386 KERNBASE is 0xc0000000. > > Exactly my problem. This all assumes that you're loading > the kernel into low memory. > > On the AM3358, the DRAM starts at 0x8000 0000 > on boot, so I'm trying to find a clean way to convince > the loader's ELF code to put the kernel there. Look at what I did for ia64. All that frobbing should be done in the machine specific implementation of arch_copyin, arch_copyout and arch_readin. It's a kluge to do it in elf_loadimage. FYI, -- Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-arm@FreeBSD.ORG Fri May 11 18:09:52 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C3E54106566C for ; Fri, 11 May 2012 18:09:52 +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 7036B8FC1F for ; Fri, 11 May 2012 18:09:52 +0000 (UTC) Received: from [172.24.128.81] ([192.75.139.248]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id q4BI5ieM015535 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO) for ; Fri, 11 May 2012 12:05:47 -0600 (MDT) (envelope-from IMP@bsdimp.com) From: Warner Losh Content-Type: multipart/mixed; boundary=Apple-Mail-3--177430528 Date: Fri, 11 May 2012 14:05:38 -0400 Message-Id: To: "arm@freebsd.org" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Fri, 11 May 2012 12:05:48 -0600 (MDT) Cc: Subject: Changes to locore.S needing review 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: Fri, 11 May 2012 18:09:52 -0000 --Apple-Mail-3--177430528 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I'd like to get a review on the locore.S part of the changes that I'm = making to support booting from a Linux boot loader directly for the = kernel. My arm assembler knowledge is somewhat weak, so I hope I = haven't botched anything. The changes conditionally save r0, r1 and r2 away for the early boot, = then put them in a structure to pass to board_init(). It also tries to = clean up the register usage a bit so I can save away these values in = registers and I don't have to worry about storing values. Please let me know what you think. Warner --Apple-Mail-3--177430528 Content-Disposition: attachment; filename=1 Content-Type: application/octet-stream; x-unix-mode=0664; name="1" Content-Transfer-Encoding: 7bit Index: arm/locore.S =================================================================== --- arm/locore.S (revision 235278) +++ arm/locore.S (working copy) @@ -37,6 +37,8 @@ #include #include #include +#include + __FBSDID("$FreeBSD$"); /* What size should this really be ? It is only used by initarm() */ @@ -61,15 +63,26 @@ .globl physaddr .set physaddr,PHYSADDR -ENTRY_NP(btext) - /* - * On entry: + * On entry for FreeBSD boot ABI: * r0 - metadata pointer or 0 * r1 - if (r0 == 0) then metadata pointer + * initarm gets passed this metadata as arg1 with 0 as arg2. + * On entry for Linux boot ABI: + * r0 - 0 + * r1 - machine type (passed as arg2 to initarm) + * r2 - Pointer to a tagged list or dtb image (phys addr) (passed as arg1 initarm) */ +ENTRY_NP(btext) ASENTRY_NP(_start) +#ifdef LINUX_BOOT_ABI + /* Maybe we should just always do this and let the boards sort it out */ + mov r9, r0 /* 0 or boot mode from boot2 */ + mov r8, r1 /* Save Machine type */ + mov ip, r2 /* Save meta data */ + mov fp, r3 /* Save r3 */ +#else /* Move metadata ptr to r12 (ip) */ mov ip, r0 ldr r0, =0 @@ -77,6 +90,7 @@ bne 1f mov ip, r1 1: +#endif /* Make sure interrupts are disabled. */ mrs r7, cpsr orr r7, r7, #(I32_bit|F32_bit) @@ -91,25 +105,25 @@ */ mrc p15, 0, r2, c1, c0, 0 ands r2, r2, #CPU_CONTROL_MMU_ENABLE - ldreq r8, =PHYSADDR - ldrne r8, =LOADERRAMADDR - cmp r7, r8 + ldreq r6, =PHYSADDR + ldrne r6, =LOADERRAMADDR + cmp r7, r6 bls flash_lower cmp r7, pc bhi from_ram b do_copy flash_lower: - cmp r8, pc + cmp r6, pc bls from_ram do_copy: - ldr r9, =KERNBASE + ldr r7, =KERNBASE adr r1, _start ldr r0, Lreal_start ldr r2, Lend sub r2, r2, r0 - sub r0, r0, r9 - add r0, r0, r8 + sub r0, r0, r7 + add r0, r0, r6 mov r4, r0 bl memcpy ldr r0, Lram_offset @@ -186,7 +200,19 @@ ldr pc, .Lvirt_done virt_done: +#ifdef LINUX_BOOT_ABI + mov r0, sp + adds sp, sp, #20 + str r9, [r0] /* Store r0 from boot loader usually 0 */ + str r8, [r0, #4] /* Store r1 from boot loader machine type */ + str ip, [r0, #8] /* store r2 from boot loader meta data atag or dtb */ + str fp, [r0, #12] /* store r3 from boot loader */ + ld r1, =ARM_FBSDBOOT_MAGIC + str r1, [r0, #16] +#else mov r0, ip /* Load argument: metadata ptr */ + mov r1, #0 /* No machine type passed from boot loader */ +#endif mov fp, #0 /* trace back starts here */ bl _C_LABEL(initarm) /* Off we go */ Index: include/md_var.h =================================================================== --- include/md_var.h (revision 235107) +++ include/md_var.h (working copy) @@ -33,6 +33,7 @@ #ifndef _MACHINE_MD_VAR_H_ #define _MACHINE_MD_VAR_H_ +#ifndef __ASSEMBLER__ extern char sigcode[]; extern int szsigcode; extern uint32_t *vm_page_dump; @@ -69,11 +70,22 @@ }; extern enum cpu_class cpu_class; +struct arm_boot_params { + uintptr_t r0; + uintptr_t r1; + uintptr_t r2; + uintptr_t r3; + uintptr_t magic; +}; + struct dumperinfo; extern int busdma_swi_pending; void busdma_swi(void); void dump_add_page(vm_paddr_t); void dump_drop_page(vm_paddr_t); void minidumpsys(struct dumperinfo *); +#endif +#define ARM_FBSDBOOT_MAGIC 0x46425344 + #endif /* !_MACHINE_MD_VAR_H_ */ --Apple-Mail-3--177430528-- From owner-freebsd-arm@FreeBSD.ORG Sat May 12 23:36:10 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 599FA1065672 for ; Sat, 12 May 2012 23:36:10 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 25C598FC16 for ; Sat, 12 May 2012 23:36:10 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so5322730pbb.13 for ; Sat, 12 May 2012 16:36:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=3BG1cp2NgfU7Z3mjVr4LsHHt72h2Oz7E2VNmQfvNRqM=; b=PWX3av3fPYCQ3oNn5UMAG9gbW8joPmwQXrpdG+TK0q+wZTiSgTwwUkdk7l+4qHoz37 YwRWUfj8kw3eZj7GXcTkWmUtkUkBoEspyJ3o4l8edzOQi1If5KOBsof1Zu+gDuE9U1wF +TZRemNKLG4iAEsdgA0wmkK540xW+nQADiuvzxFPHE4nA5fH7Z9wU6XLOvMax6eLZlC6 rUNnk2jRuh6gkxinPRPaSPY4AjejO6SBuH1F1xKDbnPMniKBTl3CoRXw2v1WQV94CvkP RD4HSZGXcgoZCZt0lc0tbvbXIjISE842mxi9FjRIT4XRRvTecDPUL3SFsRZxmGQpzyIY bQzg== Received: by 10.68.231.164 with SMTP id th4mr8550692pbc.97.1336865769634; Sat, 12 May 2012 16:36:09 -0700 (PDT) Received: from [192.168.1.69] (99-74-169-43.lightspeed.sntcca.sbcglobal.net. [99.74.169.43]) by mx.google.com with ESMTPS id nv2sm17283070pbb.6.2012.05.12.16.36.06 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 12 May 2012 16:36:08 -0700 (PDT) Sender: Tim Kientzle Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Tim Kientzle In-Reply-To: Date: Sat, 12 May 2012 16:36:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3B2A320B-3ADE-4F48-B94E-4F0886178251@freebsd.org> <201205070957.03842.jhb@freebsd.org> <8B01DF29-747A-449C-A762-E852F57C6380@freebsd.org> To: Marcel Moolenaar X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQkVM01dUiXG6/KiirjGLoF2iJj74zikYh/Ogsu1IbJBKUOI8jWDQBpmTOUnD6l/GcZtDFvQ Cc: arm@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: How does loader(8) decide where to load the kernel? 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: Sat, 12 May 2012 23:36:10 -0000 On May 10, 2012, at 5:32 AM, Marcel Moolenaar wrote: >=20 > On May 8, 2012, at 1:32 AM, Tim Kientzle wrote: >>>> On i386, amd64, powerpc, and arm, loadimage subtracts >>>> the dest value from the address declared in the actual ELF >>>> headers so that the kernel always gets loaded into low memory. >>>> (there's some intermediate bit-twiddling I'm glossing over, but >>>> this is the general idea). >>>=20 >>> The bit twiddling is supposed to be the equivalent of subtracting >>> KERNBASE from the load address. On both i386 and amd64, there is >>> a direct mapping of the kernel text such that KERNBASE maps address >>> 0, etc. By default on i386 KERNBASE is 0xc0000000. >>=20 >> Exactly my problem. This all assumes that you're loading >> the kernel into low memory. >>=20 >> On the AM3358, the DRAM starts at 0x8000 0000 >> on boot, so I'm trying to find a clean way to convince >> the loader's ELF code to put the kernel there. >=20 > Look at what I did for ia64. All that frobbing should be done > in the machine specific implementation of arch_copyin, arch_copyout > and arch_readin. It's a kluge to do it in elf_loadimage. That sounds like a reasonable approach. I've started working down that path=85 but it looks like I'll have to fix a lot of the FDT code along the way. Tim