From owner-freebsd-arm@FreeBSD.ORG Sun Sep 28 16:36:47 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C1A69D27; Sun, 28 Sep 2014 16:36:47 +0000 (UTC) Received: from st11p02mm-asmtp002.mac.com (st11p02mm-asmtp002.mac.com [17.172.220.237]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (Client CN "smtp.me.com", Issuer "VeriSign Class 3 Extended Validation SSL SGC CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 968349EC; Sun, 28 Sep 2014 16:36:47 +0000 (UTC) Received: from fukuyama.hsd1.ca.comcast.net (unknown [73.162.13.215]) by st11p02mm-asmtp002.mac.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0NCM00NCQE4R1P50@st11p02mm-asmtp002.mac.com>; Sun, 28 Sep 2014 16:36:29 +0000 (GMT) Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 8.0 \(1985.4\)) Subject: Re: Digi CCWMX53 From: Rui Paulo In-reply-to: <1411917685.66615.309.camel@revolution.hippie.lan> Date: Sun, 28 Sep 2014 09:36:27 -0700 Content-transfer-encoding: quoted-printable Message-id: <44EB751E-E53F-46C8-809C-655002C57BC6@me.com> References: <42B4958F-21B2-4ABB-82C9-3F0B328EFED0@me.com> <1411917685.66615.309.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1985.4) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.28,0.0.0000 definitions=2014-09-28_03:2014-09-26,2014-09-28,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1409280187 Cc: freebsd-arm@freebsd.org, Russell Haley X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 16:36:47 -0000 On Sep 28, 2014, at 08:21, Ian Lepore wrote: > We can use bootelf on ubldr, but not on the kernel, because our kernel > linker script doesn't fill in the physical load address properly in = the > elf header (it would try to load the virtual address). >=20 > So the two options for launching the kernel directly are: >=20 > load kernel; go > load kernel.bin; go >=20 > The standard no-suffix kernel file is an elf binary with the wrong = load > address in the header, and the header is 0x100 bytes, so the entry = point > is immediately after that. The kernel.bin file is exactly the same as > kernel, but with the elf header stripped off, so the entry point is at > an offset of zero. >=20 > An interesting thing about our kernel is that it can be loaded at any > 1MB boundary in physical memory, not just the address it was linked = at. > There's no way to represent that in an elf header. This is true of = both > kernel and kernel.bin. Ah, I think I made it work once when I set the KERNPHYS (or KERNVIRT?) = to match the load address. -- Rui Paulo