From owner-freebsd-arm@FreeBSD.ORG Thu Oct 9 02:46:12 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DABC3559 for ; Thu, 9 Oct 2014 02:46:12 +0000 (UTC) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A1FE7263 for ; Thu, 9 Oct 2014 02:46:12 +0000 (UTC) Received: by mail-oi0-f47.google.com with SMTP id a141so830967oig.20 for ; Wed, 08 Oct 2014 19:46:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=C2+xPJ73i9MnkEH1cBoe06BRpoDw0uSe9lVLR5P7TBw=; b=XtZeRc1ENwbAWXhNHL/QKjCTCbPjszjHPxJIJwxAQlBwGv1+FOaXHSbah91S6UUMQb 3n2W8QjCV9yT44eqLLeO47lercoAkWZd2lrd9O2NlzuCNmC/CpTwP7TK8njaHN+GiZg2 wFkzAVSRY3pTxtyE7nd3Whts52TVlYdhTLGXKBOgVe9Y1TqIaK04UczLkv7QqZEIggQm 9oJPKHiA4F2QysFLoVDF1t7GVThBzyRzgbwCzjrn0dzg7rLk2o1IBIGsCDJd6ylJa+yk JxHIILxN15mYMBSxa3E4zlR/+WEodBlmcatvDkeK+EOwK2LNox0V62t07uoCfTcq0T8i 2+vw== X-Received: by 10.60.158.199 with SMTP id ww7mr16875846oeb.76.1412822772017; Wed, 08 Oct 2014 19:46:12 -0700 (PDT) Received: from [172.30.1.14] ([112.168.75.52]) by mx.google.com with ESMTPSA id ix8sm1808350obc.11.2014.10.08.19.46.10 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Oct 2014 19:46:11 -0700 (PDT) Message-ID: <5435F6EB.1080605@gmail.com> Date: Thu, 09 Oct 2014 11:46:03 +0900 From: Jaemin Yoo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Andrew Turner Subject: Re: Q: linking method for armv8 kernel build References: <5432A1B5.30406@gmail.com> <20141006154314.1b909772@bender.lan> <5433DD2E.1050807@gmail.com> <20141007175133.6a26bcc5@bender.lan> In-Reply-To: <20141007175133.6a26bcc5@bender.lan> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-arm@freebsd.org 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: Thu, 09 Oct 2014 02:46:12 -0000 2014-10-08 AM 1:51에 Andrew Turner wrote: > On Tue, 07 Oct 2014 21:31:42 +0900 > Jaemin Yoo wrote: > >> 2014-10-06 PM 11:43, Andrew Turner wrote: >>> On Mon, 06 Oct 2014 23:05:41 +0900 >>> Jaemin Yoo wrote: >>> >>>> Hello, I just began to download and build kernel for armv8 >>>> according to the following howto page. >>>> (https://wiki.freebsd.org/arm64) >>>> >>>> I could create the kernel image without problem. But 'file' says >>>> it's dynamically linked. I expected statically linked image to load >>>> it on dram using uboot. >>>> >>>> Is it meant to be? or am I missing some configuration? >>> >>> All examples of the FreeBSD kernel I've looked at say they are >>> dynamically linked. The requirement is the kernel needs to be >>> loaded at a 2MiB aligned address for the VA->PA translation to >>> work. It will create the page table so the kernel base points to >>> the load address. >>> >>> You may have problems loading it with U-Boot. It expects to be >>> loaded by the loader as it passes in the device tree. U-Boot has >>> been found to be difficult to support on 32-bit arm. Is there a >>> reason to prefer it over UEFI? >>> >>> Andrew >>> >> >> Thanks. I'm doing most work at linux and vmlinux is mostly(?) >> statically linked. So I thought same goes for freebsd too. There are >> some 'UND' functions in kernel but I guess it's okay if they are not >> used. > > The only undefined data I get in my arm64 kernel is for uart data. > These are specifically set up like this to simplify the code. > >> I got a 64bit arm board which runs linux from APM. It came with binary >> and source codes of u-boot. So I planned to enable bootelf and load >> kernel on dram after adding uart driver for the board. I just want to >> see freebsd kernel boot on arm64 with minimal changes. > > You will have issues as the kernel expects to read the dtb from the > data provided by the loader. In the short term you could use a static > DTB in the kernel however the code to do so has not been written as the > kernel should work on all supported hardware. If you go down this route > you don't need to use the bootelf command, instead you can either > create a U-Boot image using mkimage, or have U-Boot jump to the > entry point directly using the go command. Note that the go command may > leave the d-cache on causing issues. > > In the long term the loader should be ported to work on U-Boot. Some of > the existing work to have it run on 32-bit ARM can be reused. > I found uefi code and binary runs on x-gene board. I'll use it to leverage for booting freebsd. > You will also need to change the early putc function in > arm64/arm64/machdep.c. It appears from [1] and [2] the UART is mapped at > 0x1c020000. This is within the range set up for the Foundation Model so > you should only need up update the early_putc function. It's written > for a pl011 with the assumption we will never overflow the fifo. You > will need to change this as the APM SoC appears to have an ns16550. > So, putc is like early_printk of linux? Wondered how it works but it looks bootloader enables uart and early_putc just put char on output register. Hope to see boot log soon! :) > At this point you should start to get kernel messages on the serial > port, this includes any panic messages if something got missed. > > Andrew > > [1] > https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/apm-mustang.dts > [2] > https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/apm-storm.dtsi > Thanks, Jaemin