Re: Design doc of adding ACPI support for arm64 on Xen - version 2

[Andrew Turner <andrew@fubar.geek.nz>]

On Wed, 12 Aug 2015 10:21:55 +0100
Julien Grall <julien.grall@citrix.com> wrote:

> Hi,
> 
> (Cc Andrew Turner who worked on the ACPI port for FreeBSD ARM64)
> 
> On 12/08/2015 09:52, Ian Campbell wrote:
> > On Wed, 2015-08-12 at 11:04 +0800, Shannon Zhao wrote:
> >> Hi Julien,
> >>
> >> On 2015/8/12 0:19, Julien Grall wrote:
> >>> Hi Shannon,
> >>>
> >>> On 07/08/15 03:11, Shannon Zhao wrote:
> >>>> 2. Create minimal DT to pass required information to Dom0
> >>>> ----------------------------------------------------------
> >>>> The minimal DT mainly passes Dom0 bootargs, address and size of
> >>>> initrd
> >>>> (if available), address and size of uefi system table, address
> >>>> and size
> >>>> of uefi memory table, uefi-mmap-desc-size and uefi-mmap-desc-ver.
> >>>>
> >>>> An example of the minimal DT:
> >>>> / {
> >>>>      #address-cells = <2>;
> >>>>      #size-cells = <1>;
> >>>>      chosen {
> >>>>          bootargs = "kernel=Image console=hvc0
> >>>> earlycon=pl011,0x1c090000
> >>>> root=/dev/vda2 rw rootfstype=ext4 init=/bin/sh acpi=force";
> >>>>          linux,initrd-start = <0xXXXXXXXX>;
> >>>>          linux,initrd-end = <0xXXXXXXXX>;
> >>>>          linux,uefi-system-table = <0xXXXXXXXX>;
> >>>>          linux,uefi-mmap-start = <0xXXXXXXXX>;
> >>>>          linux,uefi-mmap-size = <0xXXXXXXXX>;
> >>>>          linux,uefi-mmap-desc-size = <0xXXXXXXXX>;
> >>>>          linux,uefi-mmap-desc-ver = <0xXXXXXXXX>;
> >>>>      };

Would it be possible to add a stdout property and node for the hvc0
device? It would help FreeBSD as we use this to find the kernel
console. We check for the stdout-path, linux,stdout-path, stdout,
stdin-path, and stdin properties, in that order, with the first
property selected as the console. If none are found we fall back to
searching for a serial0 device. You can see how we find the device at
[1].

> >>>> };
> >>>>
> >>>> For details loook at
> >>>> https://github.com/torvalds/linux/blob/master/Documentation/arm/uefi.
> >>>> txt
> >>>
> >>> AFAICT, the device tree properties in this documentation are only
> >>> used in order to communicate between the UEFI stub and Linux.
> >>>
> >>> This means that those properties are not standardize and can
> >>> change at any time by Linux folks. They don't even live in
> >>> Documentation/devicetree/
> >>>
> >>> I would also expect to see the same needs for FreeBSD running as
> >>> DOM0 with ACPI.
> >>>
> >> I'm not very clear about how FreeBSD communicates with UEFI. And
> >> when booting with DT, how does FreeBSD communicate with UEFI? Not
> >> through these properties?

FreeBSD has a tool called loader.efi. It gets loaded by UEFI, and knows
how to communicate with it. It then loads the kernel and reads any
important data the kernel may need. Finally it puts this data into a
format the kernel understands, exits the boot services, and boots the
kernel. The kernel never communicates with UEFI, we have loaded any
data we need (however this may change in the future).

In the case of the memory may loader.efi calls GetMemoryMap from
EFI_BOOT_SERVICES. It then passes this data directly to the kernel for
the kernel to parse in the early boot code.

> >
> > These properties are in effect a Linux internal interface defined
> > between the "Linux UEFI stub" and the "Linux kernel proper". The
> > stub and the kernel are notionally separate entities, although they
> > are in the same tree etc there is a well defined transition/entry
> > point between the two. Since they are in the same tree even though
> > they are in theory "separate" I expect they will tend to co-evolve.
> >
> > IIRC we discussed with some of the maintainers (at Connect?) making
> > this a more formal interface, i.e. exposing the entry point to
> > "Linux kernel proper" which understands these properties to other
> > than just the "Linux UEFI stub" specifically to external entities
> > such as Xen.
> >
> > Probably part of this work needs to formalise that, such as by
> > moving this binding into the proper external bindings dir.
> >
> > At which point BSD can (hopefully!) choose to support the same
> > interface.

What are the advantages of these bindings over the existing UEFI calls
to get the memory map?

Andrew

[1]
https://svnweb.freebsd.org/base/head/sys/dev/uart/uart_cpu_fdt.c?revision=281438&view=markup#l127

-- 
ABT Systems Ltd
Unit 11, Hove Business Centre, Fonthill Road, Hove, BN3 6HA
Registered in England and Wales, No. 9285513