Q: linking method for armv8 kernel build

[Jaemin Yoo]

2014-10-08 AM 1:51에 Andrew Turner wrote:
> On Tue, 07 Oct 2014 21:31:42 +0900
> Jaemin Yoo <zaemin.yoo at 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 at 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