Date: Thu, 09 Oct 2014 11:46:03 +0900 From: Jaemin Yoo <zaemin.yoo@gmail.com> To: Andrew Turner <andrew@fubar.geek.nz> Cc: freebsd-arm@freebsd.org Subject: Re: Q: linking method for armv8 kernel build Message-ID: <5435F6EB.1080605@gmail.com> In-Reply-To: <20141007175133.6a26bcc5@bender.lan> References: <5432A1B5.30406@gmail.com> <20141006154314.1b909772@bender.lan> <5433DD2E.1050807@gmail.com> <20141007175133.6a26bcc5@bender.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
2014-10-08 AM 1:51에 Andrew Turner wrote: > On Tue, 07 Oct 2014 21:31:42 +0900 > Jaemin Yoo <zaemin.yoo@gmail.com> wrote: > >> 2014-10-06 PM 11:43, Andrew Turner wrote: >>> On Mon, 06 Oct 2014 23:05:41 +0900 >>> Jaemin Yoo <zaemin.yoo@gmail.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5435F6EB.1080605>