Re: [seL4] UEFI support for x86

[Edward Sandberg]

One more data point, ethernet also seems to be working.  I compiled a
UEFI image from the tcp_terminal example in the gems repo.  I can now
happily recommend the UP hardware (Atom) as an embedded platform for
seL4 with driver support courtesy of Genode.

-- 
Edward Sandberg
Adventium Labs
111 3rd Avenue S. Suite #100
Minneapolis, MN 55401

___
Devel mailing list
Devel@sel4.systems
https://sel4.systems/lists/listinfo/devel

Re: [seL4] UEFI support for x86

[Edward Sandberg]

Hey Alexander,

Thanks to your suggestion I now have the UP board booting via UEFI and
USB input is working as expected.  Thanks for your help.  I am happy to
help test any UEFI modifications you make in future releases.  For
anyone who is interested in reproducing this I will summarize what I did
to get a working demo built.

I created a build dir that specifies the sel4 kernel.  This option is
listed as deprecated but it still works.

$ ./tool/create_builddir sel4_x86_32 build_sel4

I modified the build.conf file to build a UEFI image rather than and iso
for qemu and I enabled the libports and dde_linux repos.  I pasted the
full text of my build.conf below.

I then modified the demo.run file to:
* remove ps2_drv
* remove fb_drv
* add fb_boot_drv
* add usb_drv

The usb_drv sections were copied from repos/dde_linux/run/usb_hid.run
but I removed the portions that referred to capslock, numlock and
scrlock as they were causing errors that interfered with the boot
process.  I pasted the full text of my modified demo.run below.

Then all I had to do was prepare the dde_linux port and build my image:

$ ./tool/ports/prepare_port dde_linux
$ make run/demo

### etc/build.conf ###
GENODE_DIR  := /home/esandberg/projects/embedded/genode-17.11/genode-17.11
BASE_DIR:= $(GENODE_DIR)/repos/base
CONTRIB_DIR := $(GENODE_DIR)/contrib

MAKE += -j4

KERNEL ?= sel4
KERNEL_RUN_OPT(sel4)  := --include image/uefi

RUN_OPT += ${KERNEL_RUN_OPT(${KERNEL})} --include boot_dir/$(KERNEL)
REPOSITORIES += $(GENODE_DIR)/repos/base-$(KERNEL)
REPOSITORIES += $(GENODE_DIR)/repos/base
REPOSITORIES += $(GENODE_DIR)/repos/os
REPOSITORIES += $(GENODE_DIR)/repos/demo
REPOSITORIES += $(GENODE_DIR)/repos/libports
REPOSITORIES += $(GENODE_DIR)/repos/dde_linux

### repos/os/run/demo.run ###
#
# Build
#

if {[have_spec odroid_xu]} {
puts "Run script does not support this platform."
exit 0
}

set build_components {
core init
drivers/timer
server/nitpicker app/pointer app/status_bar app/global_keys_handler
app/nit_focus
server/liquid_framebuffer app/launchpad app/scout
test/nitpicker server/nitlog
drivers/framebuffer drivers/input
server/report_rom server/rom_filter
drivers/usb
}

proc gpio_drv { } { if {[have_spec rpi] && [have_spec hw]}  { return
hw_gpio_drv }
if {[have_spec rpi] && [have_spec foc]} { return
foc_gpio_drv }
return gpio_drv }

source ${genode_dir}/repos/base/run/platform_drv.inc

lappend_if [need_usb_hid]   build_components drivers/usb
lappend_if [have_spec gpio] build_components drivers/gpio

append_platform_drv_build_components

build $build_components

create_boot_directory

#
# Generate config
#

append config {












   

}

append config {







  
  
   
  
   
  
  
  
  

 }

append_if [have_spec sdl] config {






}

append_platform_drv_config

append_if [have_spec framebuffer] config {



}

append_if [have_spec gpio] config "




"

append_if [have_spec imx53] config {




 }

append config {







   
















 
















  

Re: [seL4] UEFI support for x86

[Alexander Boettcher]

Hello,

On 08.12.2017 17:19, Edward Sandberg wrote:
> I tried your suggestion and increased the memory for the framebuffer.The
> UP board booted all the way to the graphical interface, very
> exciting!

nice.

> Unfortunately the usb keyboard and mouse do not work.  The
> Minnowboard still does not give any graphical output.  The logs for both
> are below.
> 
> I have found that on some hardware the OS does not know where to find
> the RSDP value when booting via multiboot and UEFI and as a result USB
> peripherals do not work.  This is not just a problem with sel4 I have
> seen it with xen as well.  That may be the problem here.  I attempted to
> fix the problem by editing the sel4 source code.  I added:
> 
> #define UPBOARD_RSDP   0x5B161000
> 
> to
> ./contrib/sel4-097171f475bff21223783e130445b9be6b3d1bb4/src/kernel/sel4/include/plat/pc99/plat/machine/acpi.h.
> Then I replaced the function acpi_get_rsdp in
> ./contrib/sel4-097171f475bff21223783e130445b9be6b3d1bb4/src/kernel/sel4/src/plat/pc99/machine/acpi.c
> with:
> 
> acpi_get_rsdp(void)
> {
> return (acpi_rsdp_t*)UPBOARD_RSDP;
> }
> 
> But either my intuition about the problem is wrong or I am attempting to
> fix it incorrectly.  I get exactly the same logs with or without the
> above fixes.

acpi_get_rsdp is not called for Multiboot2(MBI2)/UEFI case. The RSDP
information is expected to be part of MBI2.

The function try_boot_sys_mbi2 in

contrib/sel4-097171f475bff21223783e130445b9be6b3d1bb4/src/kernel/sel4/src/arch/x86/kernel/boot_sys.c

looks up the information and copies it to boot_state.acpi_rsdp.



> 
> Do you have any suggestions on the keyboard and mouse?


Yes, if you look at the lines about the boot modules

> boot module 'acpi_drv' (96740 bytes)
> ...

you will miss a line about the usb driver.

In the demo run scenario the usb driver is not started for x86, instead
the ps2 driver is taken. You would need to adjust the demo scenario to
use the usb driver instead of the ps2 driver. (Or at best use both
drivers and add a input multiplexer, e.g. [0], which takes both drivers
as input sources).

Beforehand you may just try the usb_hid [1] scenario to actual test
whether usb in general work on your machine(s).

[0] repos/os/src/server/input_merger/README
[1] repos/dde_linux/run/usb_hid.run

-- 
Alexander Boettcher
Genode Labs

http://www.genode-labs.com - http://www.genode.org

Genode Labs GmbH - Amtsgericht Dresden - HRB 28424 - Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

___
Devel mailing list
Devel@sel4.systems
https://sel4.systems/lists/listinfo/devel

Re: [seL4] UEFI support for x86

[Edward Sandberg]

I tried your suggestion and increased the memory for the framebuffer.The
UP board booted all the way to the graphical interface, very
exciting!  Unfortunately the usb keyboard and mouse do not work.  The
Minnowboard still does not give any graphical output.  The logs for both
are below.

I have found that on some hardware the OS does not know where to find
the RSDP value when booting via multiboot and UEFI and as a result USB
peripherals do not work.  This is not just a problem with sel4 I have
seen it with xen as well.  That may be the problem here.  I attempted to
fix the problem by editing the sel4 source code.  I added:

#define UPBOARD_RSDP   0x5B161000

to
./contrib/sel4-097171f475bff21223783e130445b9be6b3d1bb4/src/kernel/sel4/include/plat/pc99/plat/machine/acpi.h.
Then I replaced the function acpi_get_rsdp in
./contrib/sel4-097171f475bff21223783e130445b9be6b3d1bb4/src/kernel/sel4/src/plat/pc99/machine/acpi.c
with:

acpi_get_rsdp(void)
{
return (acpi_rsdp_t*)UPBOARD_RSDP;
}

But either my intuition about the problem is wrong or I am attempting to
fix it incorrectly.  I get exactly the same logs with or without the
above fixes.

Do you have any suggestions on the keyboard and mouse?

* UP board ***
WARNING: no console will be available to OS
Bender: Hello World.
framebuffer at [8000+808ca000) 1920x1200@32
framebuffer at [8000+808ca000) 1920x1200@32

Boot config: parsing cmdline 'sel4 disable_iommu'
Boot config: console_port = 0x3f8
Boot config: debug_port = 0x3f8
Boot config: disable_iommu = true
  module #0: start=0xf9b8000 end=0x228 size=0x647228 name='image.elf'
Physical Memory Region from 0 size 8f000 type 1
Physical Memory Region from 8f000 size 1000 type 4
Physical Memory Region from 9 size e000 type 1
Physical Memory Region from 9e000 size 2000 type 2
Physical Memory Region from 10 size 1ef0 type 1
Adding physical memory region 0x10-0x1f00
Physical Memory Region from 1f00 size 120 type 2
Physical Memory Region from 2020 size 3af29000 type 1
Physical Memory Region from 5b129000 size 3 type 2
Physical Memory Region from 5b159000 size 25000 type 3
Physical Memory Region from 5b17e000 size 5d2000 type 4
Physical Memory Region from 5b75 size 2b9000 type 2
Physical Memory Region from 5ba09000 size 79000 type 20
Physical Memory Region from 5ba82000 size 57e000 type 1
Physical Memory Region from e000 size 400 type 2
Physical Memory Region from fea0 size 10 type 2
Physical Memory Region from fec0 size 1000 type 2
Physical Memory Region from fed01000 size 1000 type 2
Physical Memory Region from fed03000 size 1000 type 2
Physical Memory Region from fed06000 size 1000 type 2
Physical Memory Region from fed08000 size 2000 type 2
Physical Memory Region from fed1c000 size 1000 type 2
Physical Memory Region from fed8 size 4 type 2
Physical Memory Region from fee0 size 1000 type 2
Physical Memory Region from ffc0 size 40 type 2
Got framebuffer info in multiboot2. Current video mode is at physical
address=8000 pitch=7680 resolution=1920x1200@32 type=1
Detected 1 boot module(s):

Kernel loaded to: start=0x20 end=0x27e000 size=0x7e000 entry=0x20007e
ACPI: RSDT paddr=0x5b161028
ACPI: RSDT vaddr=0xdfd61028
ACPI: FADT paddr=0x5b1611a8
ACPI: FADT vaddr=0xdfd611a8
ACPI: FADT flags=0x421
ACPI: MADT paddr=0x5b177380
ACPI: MADT vaddr=0xdfd77380
ACPI: MADT apic_addr=0xfee0
ACPI: MADT flags=0x1
ACPI: MADT_APIC apic_id=0x0
ACPI: MADT_APIC apic_id=0x2
ACPI: MADT_APIC apic_id=0x4
ACPI: MADT_APIC apic_id=0x6
ACPI: MADT_IOAPIC ioapic_id=1 ioapic_addr=0xfec0 gsib=0
ACPI: MADT_ISO bus=0 source=0 gsi=2 flags=0x0
ACPI: MADT_ISO bus=0 source=9 gsi=9 flags=0xd
ACPI: 4 CPU(s) detected
ELF-loading userland images from boot modules:
size=0xd88000 v_entry=0x200 v_start=0x200 v_end=0x2d88000
p_start=0x1000 p_end=0x10d88000
Moving loaded userland images to final location: from=0x1000
to=0x27e000 size=0xd88000
Starting node #0 with APIC ID 0

Starting node #1 with APIC ID 2
Starting node #2 with APIC ID 4
Starting node #3 with APIC ID 6
Booting all finished, dropped to user space
virtual address layout of core:
 overall[2000,c000)
 core image [0200,02d88000)
 ipc buffer [02d88000,02d89000)
 boot_info  [02d89000,02d8b000)
 stack area [4000,5000)
Warning: need physical memory, but Platform object not constructed yet
Warning: need physical memory, but Platform object not constructed yet
Warning: need physical memory, but Platform object not constructed yet
Warning: need physical memory, but Platform object not constructed yet
:phys_alloc:   Allocator 0x2804018 dump:
 Block: [0020,00201000) size=4K avail=0 max_avail=0
 Block: [00201000,00202000) size=4K avail=0 max_ava

Re: [seL4] UEFI support for x86

[Alexander Boettcher]

Hello,

On 04.12.2017 18:15, Edward Sandberg wrote:
> I modified the demo.run file to use fb_boot_drv and built the uefi
> image.  I tested it on an UP board, a Minnowboard Turbot, a Dell M3800
> laptop, and a Dell Precision 5810 desktop.  I was unable to get
> graphical output on any of them.  I have pasted the logs for all (except
> the laptop which has no serial port) below.

> * UP BOARD 
> WARNING: no console will be available to OS
> Bender: Hello World.
> framebuffer at [8000+808ca000) 1920x1200@32
> framebuffer at [8000+808ca000) 1920x1200@32

good

> [init -> fb_boot_drv] Framebuffer with 1920x1200x32 @ 0x8000 type=1 
> pitch=7680
> [init] child "report_rom" announces service "Report"
> [init -> fb_boot_drv] resource_request: ram_quota=4612096

If you see such a message, the driver or component in general will not
continue.

The specified memory for the driver seems to be too low, try to increase
it. It should be something above 9.2M (7680 Byte * 1200 = 9.2 M + some
memory for the driver). Maybe 10-11M should suffice.



> * MinnowBoard ***
> framebuffer at [8000+808ca000) 1920x1200@32
> framebuffer at [8000+808ca000) 1920x1200@32

good

> [init -> fb_boot_drv] Framebuffer with 1920x1200x32 @ 0x8000 type=1 
> pitch=7680
> [init -> fb_boot_drv] resource_request: ram_quota=4612096

Same here, try increase the memory for the framebuffer.


> * Dell Precision 5810 **
> Bender: Hello World.
> framebuffer at [f100+f130) 1024x768@32
> framebuffer at [f100+f130) 1024x768@32

good

> 
> Boot config: parsing cmdline 'sel4 disable_iommu'
> Boot config: console_port = 0x3f8
>  Boot config: debug_port = 0x3f8
> Boot config: disable_iommu = true
>   module #0: start=0xf9b8000 end=0x228 size=0x647228 name='image.elf'
> Physical Memory Region from 0 size a type 1
> Physical Memory Region from 10 size 997ae000 type 1
> Adding physical memory region 0x10-0x1f80
> Physical Memory Region from 998ae000 size 9ac000 type 2
> Physical Memory Region from 9a25a000 size 49000 type 3
> Physical Memory Region from 9a2a3000 size c71000 type 4
> Physical Memory Region from 9af14000 size 492000 type 2
> Physical Memory Region from 9b3a6000 size 65000 type 20
> Physical Memory Region from 9b40b000 size 1000 type 1
> Physical Memory Region from 9b40c000 size e000 type 2
> Physical Memory Region from 9b41a000 size 1be6000 type 1
> Physical Memory Region from a000 size 1000 type 2
> Physical Memory Region from fed1c000 size 4000 type 2
> Physical Memory Region from ff00 size 100 type 2
> Physical Memory Region from 10 size 176000 type 1
> Physical memory region not addressable
> Adding physical memory region 0x0-0x1f80
> seL4 failed assertion '!p_region_overlaps(reg)' at 
> /home/esandberg/projects/embedded/genode-17.11/genode-17.11/contrib/sel4-097171f475bff21223783e130445b9be6b3d1bb4/src/kernel/sel4/src/arn
> halting...

This is a assertion in the seL4 kernel. Probably it complains about that
region overlap due to following lines

> Adding physical memory region 0x10-0x1f80
> Adding physical memory region 0x0-0x1f80

I'm not sure, whether here the Multiboot 2 information is incorrect or
the parsing by the kernel is too strict. Here one would require some
more investigation in the Multiboot 2 spec (overlapping regions are
valid or not?) and on the target machine in grub2/uefi, potentially
bender and the sel4 kernel.


Thanks for testing and the infos.

-- 
Alexander Boettcher
Genode Labs

http://www.genode-labs.com - http://www.genode.org

Genode Labs GmbH - Amtsgericht Dresden - HRB 28424 - Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth





signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@sel4.systems
https://sel4.systems/lists/listinfo/devel

Re: [seL4] UEFI support for x86

[Edward Sandberg]

I modified the demo.run file to use fb_boot_drv and built the uefi
image.  I tested it on an UP board, a Minnowboard Turbot, a Dell M3800
laptop, and a Dell Precision 5810 desktop.  I was unable to get
graphical output on any of them.  I have pasted the logs for all (except
the laptop which has no serial port) below.

Perhaps I need to make more modifications to the run file than I did.
Here is the diff of demo.run:

69c69
<   
---
>   
286c286
< lappend_if [have_spec framebuffer] boot_modules fb_drv
---
> lappend_if [have_spec framebuffer] boot_modules fb_boot_drv

Do you have recommendations for building that might yield better
results?
What systems have you tested the new changes on?

Thanks!
Edward

* UP BOARD 
WARNING: no console will be available to OS
Bender: Hello World.
framebuffer at [8000+808ca000) 1920x1200@32
framebuffer at [8000+808ca000) 1920x1200@32

Boot config: parsing cmdline 'sel4 disable_iommu'
Boot config: console_port = 0x3f8
Boot config: debug_port = 0x3f8
Boot config: disable_iommu = true
  module #0: start=0xf9b8000 end=0x228 size=0x647228 name='image.elf'
Physical Memory Region from 0 size 8f000 type 1
Physical Memory Region from 8f000 size 1000 type 4
Physical Memory Region from 9 size e000 type 1
Physical Memory Region from 9e000 size 2000 type 2
Physical Memory Region from 10 size 1ef0 type 1
Adding physical memory region 0x10-0x1f00
Physical Memory Region from 1f00 size 120 type 2
Physical Memory Region from 2020 size 3af29000 type 1
Physical Memory Region from 5b129000 size 3 type 2
Physical Memory Region from 5b159000 size 25000 type 3
Physical Memory Region from 5b17e000 size 5d2000 type 4
Physical Memory Region from 5b75 size 2b9000 type 2
Physical Memory Region from 5ba09000 size 79000 type 20
Physical Memory Region from 5ba82000 size 57e000 type 1
Physical Memory Region from e000 size 400 type 2
Physical Memory Region from fea0 size 10 type 2
Physical Memory Region from fec0 size 1000 type 2
Physical Memory Region from fed01000 size 1000 type 2
Physical Memory Region from fed03000 size 1000 type 2
Physical Memory Region from fed06000 size 1000 type 2
Physical Memory Region from fed08000 size 2000 type 2
Physical Memory Region from fed1c000 size 1000 type 2
Physical Memory Region from fed8 size 4 type 2
Physical Memory Region from fee0 size 1000 type 2
Physical Memory Region from ffc0 size 40 type 2
Got framebuffer info in multiboot2. Current video mode is at physical 
address=8000 pitch=7680 resolution=1920x1200@32 type=1
Detected 1 boot module(s):
Kernel loaded to: start=0x20 end=0x27e000 size=0x7e000 entry=0x20007e
ACPI: RSDT paddr=0x5b161028
ACPI: RSDT vaddr=0xdfd61028
ACPI: FADT paddr=0x5b1611a8
ACPI: FADT vaddr=0xdfd611a8
ACPI: FADT flags=0x421
ACPI: MADT paddr=0x5b177380
ACPI: MADT vaddr=0xdfd77380
ACPI: MADT apic_addr=0xfee0
ACPI: MADT flags=0x1
ACPI: MADT_APIC apic_id=0x0
ACPI: MADT_APIC apic_id=0x2
ACPI: MADT_APIC apic_id=0x4
ACPI: MADT_APIC apic_id=0x6
ACPI: MADT_IOAPIC ioapic_id=1 ioapic_addr=0xfec0 gsib=0
ACPI: MADT_ISO bus=0 source=0 gsi=2 flags=0x0
ACPI: MADT_ISO bus=0 source=9 gsi=9 flags=0xd
ACPI: 4 CPU(s) detected
ELF-loading userland images from boot modules:
size=0xd88000 v_entry=0x200 v_start=0x200 v_end=0x2d88000 
p_start=0x1000 p_end=0x10d88000
Moving loaded userland images to final location: from=0x1000 to=0x27e000 
size=0xd88000
Starting node #0 with APIC ID 0
Starting node #1 with APIC ID 2
Starting node #2 with APIC ID 4
Starting node #3 with APIC ID 6
Booting all finished, dropped to user space
virtual address layout of core:
 overall[2000,c000)
 core image [0200,02d88000)
 ipc buffer [02d88000,02d89000)
 boot_info  [02d89000,02d8b000)
 stack area [4000,5000)
Warning: need physical memory, but Platform object not constructed yet
Warning: need physical memory, but Platform object not constructed yet
Warning: need physical memory, but Platform object not constructed yet
Warning: need physical memory, but Platform object not constructed yet
:phys_alloc:   Allocator 0x2804018 dump:
 Block: [0020,00201000) size=4K avail=0 max_avail=0
 Block: [00201000,00202000) size=4K avail=0 max_avail=0
 Block: [00202000,00203000) size=4K avail=0 max_avail=0
 Block: [00203000,00204000) size=4K avail=0 max_avail=0
 Block: [00204000,00205000) size=4K avail=0 max_avail=0
 Block: [00205000,00206000) size=4K avail=0 max_avail=0
 Block: [00206000,00207000) size=4K avail=0 max_avail=0
 Block: [00207000,00208000) size=4K avail=0 max_avail=0
 Block: [00208000,00209000) size=4K avail=0 max_avail=0
 Block: [00209000,0020a000) size=4K avail=0 max_avail=0
 Block: [0020a000,0020b000) size=4K avai

Re: [seL4] UEFI support for x86

[Alexander Boettcher]

Hello,

On 02.10.2017 11:05, Alexander Boettcher wrote:
> The fb_boot_drv component could work with seL4 in UEFI mode (it does
> with Genode/NOVA), but unfortunately the information about the
> framebuffer location, size, color depth etc. are not propagated through
> the seL4 kernel to the roottask (and from there to the fb_boot_drv
> component).

we changed the 'could work' to 'supposed to work' (for me personally
'does work') with today's Genode 17.11 release [0]. We extended the seL4
kernel to propagate the framebuffer information provided by GRUB2@UEFI
via Multiboot2 to user-land. On Genode now our simple fb_boot_drv
framebuffer driver can make use it. The seL4 kernel patch got already
pushed for review and inclusion if appropriate [2].

Edward, maybe you can give the new Genode release a spin regarding seL4
& UEFI and graphical output on your available machines using the
fb_boot_drv driver.

Thanks,

Alex.

[0] https://genode.org/documentation/release-notes/17.11
[1] https://github.com/seL4/seL4/pull/77

> 
> 
> Alex.
> 
> 
> On 29.09.2017 18:07, Edward Sandberg wrote:
>> Hello,
>>
>> I built Genode 17.08 with run option "image/uefi" and platform option
>> "sel4_x86_32". I have tried booting the resulting image on a variety of
>> machines but am not getting the behavior I expect.  The machines I have
>> tried are:
>>
>> * Up board (a Windows compatible Atom-based system)
>> * Dell M3800 laptop
>> * Dell Latitude 7280 laptop
>> * HP ProLiant DL380 Gen9 Server
>> * Dell Optoplex 990
>> * Asus P9X79 WS Motherboard with Intel Core i7-3930K
>>
>> The furthest I have gotten was on the UP board, which only supports UEFI
>> boot:
>>
>> https://www.intel.com/content/www/us/en/support/emerging-technologies/intel-realsense-technology/22699.html
>>
>> I saw serial output but no graphical output (see below).  The other
>> machines I tried to boot on didn't even give me serial output.  The
>> serial output seems to indicate that an attempt to create a framebuffer
>> failed.
>>
>> Is this the correct build procedure?
>> What hardware have you used to test UEFI boot?
>> Does the trace below suggest any experiments to try?
>>
>> *
>>
>> WARNING: no console will be available to OS
>> Bender: Hello World.
>>
>> Boot config: parsing cmdline ''
>> Boot config: console_port = 0x3f8
>> Boot config: debug_port = 0x3f8
>> Boot config: disable_iommu = false
>>
>> Boot config: parsing cmdline 'sel4 disable_iommu'
>> Boot config: console_port = 0x3f8
>> Boot config: debug_port = 0x3f8
>> Boot config: disable_iommu = true
>>   module #0: start=0xeaba000 end=0xf0ff968 size=0x645968 name='image.elf'
>> Physical Memory Region from 0 size 8f000 type 1
>> Physical Memory Region from 8f000 size 1000 type 4
>> Physical Memory Region from 9 size e000 type 1
>> Physical Memory Region from 9e000 size 2000 type 2
>> Physical Memory Region from 10 size 1ef0 type 1
>> Adding physical memory region 0x10-0x1f00
>> Physical Memory Region from 1f00 size 120 type 2
>> Physical Memory Region from 2020 size 3af29000 type 1
>> Physical Memory Region from 5b129000 size 3 type 2
>> Physical Memory Region from 5b159000 size 25000 type 3
>> Physical Memory Region from 5b17e000 size 5d2000 type 4
>> Physical Memory Region from 5b75 size 2b9000 type 2
>> Physical Memory Region from 5ba09000 size 79000 type 20
>> Physical Memory Region from 5ba82000 size 57e000 type 1
>> Physical Memory Region from e000 size 400 type 2
>> Physical Memory Region from fea0 size 10 type 2
>> Physical Memory Region from fec0 size 1000 type 2
>> Physical Memory Region from fed01000 size 1000 type 2
>> Physical Memory Region from fed03000 size 1000 type 2
>> Physical Memory Region from fed06000 size 1000 type 2
>> Physical Memory Region from fed08000 size 2000 type 2
>> Physical Memory Region from fed1c000 size 1000 type 2
>> Physical Memory Region from fed8 size 4 type 2
>> Physical Memory Region from fee0 size 1000 type 2
>> Physical Memory Region from ffc0 size 40 type 2
>> Kernel loaded to: start=0x20 end=0x281000 size=0x81000 entry=0x20007e
>> ACPI: RSDP paddr=0x3c490
>> ACPI: RSDP vaddr=0xdfc3c490
>> ACPI: RSDT paddr=0x5b161028
>> ACPI: RSDT vaddr=0xdfd61028
>> ACPI: FADT paddr=0x5b1611a8
>> ACPI: FADT vaddr=0xdfd611a8
>> ACPI: FADT flags=0x421
>> ACPI: MADT paddr=0x5b177380
>> ACPI: MADT vaddr=0xdfd77380
>> ACPI: MADT apic_addr=0xfee0
>> ACPI: MADT flags=0x1
>> ACPI: MADT_APIC apic_id=0x0
>> ACPI: MADT_APIC apic_id=0x2
>> ACPI: MADT_APIC apic_id=0x4
>> ACPI: MADT_APIC apic_id=0x6
>> ACPI: MADT_IOAPIC ioapic_id=1 ioapic_addr=0xfec0 gsib=0
>> ACPI: MADT_ISO bus=0 source=0 gsi=2 flags=0x0
>> ACPI: MADT_ISO bus=0 source=9 gsi=9 fla

Re: [seL4] UEFI support for x86

[Raymond Jennings]

I think that UEFI would involve the bootloader that the BIOS starts.  I
don't know if the bootstrap part of UEFI would be handled by seL4 itself or
by something like grub/grub2.

My wild-ass guess is that anything after seL4 takes over would be handled
by a driver process that has the required capabilities to interface with
the corresponding hardware.

On Fri, Sep 29, 2017 at 9:07 AM, Edward Sandberg <
ed.sandb...@adventiumlabs.com> wrote:

> Hello,
>
> I built Genode 17.08 with run option "image/uefi" and platform option
> "sel4_x86_32". I have tried booting the resulting image on a variety of
> machines but am not getting the behavior I expect.  The machines I have
> tried are:
>
> * Up board (a Windows compatible Atom-based system)
> * Dell M3800 laptop
> * Dell Latitude 7280 laptop
> * HP ProLiant DL380 Gen9 Server
> * Dell Optoplex 990
> * Asus P9X79 WS Motherboard with Intel Core i7-3930K
>
> The furthest I have gotten was on the UP board, which only supports UEFI
> boot:
>
> https://www.intel.com/content/www/us/en/support/emerging-
> technologies/intel-realsense-technology/22699.html
>
> I saw serial output but no graphical output (see below).  The other
> machines I tried to boot on didn't even give me serial output.  The
> serial output seems to indicate that an attempt to create a framebuffer
> failed.
>
> Is this the correct build procedure?
> What hardware have you used to test UEFI boot?
> Does the trace below suggest any experiments to try?
>
> *
>
> WARNING: no console will be available to OS
> Bender: Hello World.
>
> Boot config: parsing cmdline ''
> Boot config: console_port = 0x3f8
> Boot config: debug_port = 0x3f8
> Boot config: disable_iommu = false
>
> Boot config: parsing cmdline 'sel4 disable_iommu'
> Boot config: console_port = 0x3f8
> Boot config: debug_port = 0x3f8
> Boot config: disable_iommu = true
>   module #0: start=0xeaba000 end=0xf0ff968 size=0x645968 name='image.elf'
> Physical Memory Region from 0 size 8f000 type 1
> Physical Memory Region from 8f000 size 1000 type 4
> Physical Memory Region from 9 size e000 type 1
> Physical Memory Region from 9e000 size 2000 type 2
> Physical Memory Region from 10 size 1ef0 type 1
> Adding physical memory region 0x10-0x1f00
> Physical Memory Region from 1f00 size 120 type 2
> Physical Memory Region from 2020 size 3af29000 type 1
> Physical Memory Region from 5b129000 size 3 type 2
> Physical Memory Region from 5b159000 size 25000 type 3
> Physical Memory Region from 5b17e000 size 5d2000 type 4
> Physical Memory Region from 5b75 size 2b9000 type 2
> Physical Memory Region from 5ba09000 size 79000 type 20
> Physical Memory Region from 5ba82000 size 57e000 type 1
> Physical Memory Region from e000 size 400 type 2
> Physical Memory Region from fea0 size 10 type 2
> Physical Memory Region from fec0 size 1000 type 2
> Physical Memory Region from fed01000 size 1000 type 2
> Physical Memory Region from fed03000 size 1000 type 2
> Physical Memory Region from fed06000 size 1000 type 2
> Physical Memory Region from fed08000 size 2000 type 2
> Physical Memory Region from fed1c000 size 1000 type 2
> Physical Memory Region from fed8 size 4 type 2
> Physical Memory Region from fee0 size 1000 type 2
> Physical Memory Region from ffc0 size 40 type 2
> Kernel loaded to: start=0x20 end=0x281000 size=0x81000 entry=0x20007e
> ACPI: RSDP paddr=0x3c490
> ACPI: RSDP vaddr=0xdfc3c490
> ACPI: RSDT paddr=0x5b161028
> ACPI: RSDT vaddr=0xdfd61028
> ACPI: FADT paddr=0x5b1611a8
> ACPI: FADT vaddr=0xdfd611a8
> ACPI: FADT flags=0x421
> ACPI: MADT paddr=0x5b177380
> ACPI: MADT vaddr=0xdfd77380
> ACPI: MADT apic_addr=0xfee0
> ACPI: MADT flags=0x1
> ACPI: MADT_APIC apic_id=0x0
> ACPI: MADT_APIC apic_id=0x2
> ACPI: MADT_APIC apic_id=0x4
> ACPI: MADT_APIC apic_id=0x6
> ACPI: MADT_IOAPIC ioapic_id=1 ioapic_addr=0xfec0 gsib=0
> ACPI: MADT_ISO bus=0 source=0 gsi=2 flags=0x0
> ACPI: MADT_ISO bus=0 source=9 gsi=9 flags=0xd
> ACPI: 4 CPU(s) detected
> Detected 1 boot module(s):
> ELF-loading userland images from boot modules:
> size=0xd87000 v_entry=0x200 v_start=0x200 v_end=0x2d87000
> p_start=0xf10 p_end=0xfe87000
> Moving loaded userland images to final location: from=0xf10
> to=0x281000 size=0xd87000
> Starting node #0 with APIC ID 0
>
> Starting node #1 with APIC ID 2
> Starting node #2 with APIC ID 4
> Starting node #3 with APIC ID 6
> Booting all finished, dropped to user space
> virtual address layout of core:
>  overall[2000,c000)
>  core image [0200,02d87000)
>  ipc buffer [02d87000,02d88000)
>  boot_info  [02d88000,02d8a000)
>  stack area [4000,5000)
> Warning: need physical memory, 

Re: [seL4] UEFI support for x86

[Alexander Boettcher]

Hello,

I answered the question on the Genode mailing list.
(https://sourceforge.net/p/genode/mailman/message/36060224)

Just in short:

On Genode we have 3 framebuffer options:

fb_drv - using VESA BIOS to initialize the graphic device
fb_boot_drv - reusing a already initialized graphic card (e.g. by UEFI
and Grub2)
intel_fb_drv - native graphic driver for Intel embedded graphic devices

With UEFI boot, only the Intel driver will work for Genode/seL4, if you
have the right hardware.

The fb_drv is not known to work in UEFI mode (but does in BIOS/legacy mode).

The fb_boot_drv component could work with seL4 in UEFI mode (it does
with Genode/NOVA), but unfortunately the information about the
framebuffer location, size, color depth etc. are not propagated through
the seL4 kernel to the roottask (and from there to the fb_boot_drv
component).


Alex.


On 29.09.2017 18:07, Edward Sandberg wrote:
> Hello,
> 
> I built Genode 17.08 with run option "image/uefi" and platform option
> "sel4_x86_32". I have tried booting the resulting image on a variety of
> machines but am not getting the behavior I expect.  The machines I have
> tried are:
> 
> * Up board (a Windows compatible Atom-based system)
> * Dell M3800 laptop
> * Dell Latitude 7280 laptop
> * HP ProLiant DL380 Gen9 Server
> * Dell Optoplex 990
> * Asus P9X79 WS Motherboard with Intel Core i7-3930K
> 
> The furthest I have gotten was on the UP board, which only supports UEFI
> boot:
> 
> https://www.intel.com/content/www/us/en/support/emerging-technologies/intel-realsense-technology/22699.html
> 
> I saw serial output but no graphical output (see below).  The other
> machines I tried to boot on didn't even give me serial output.  The
> serial output seems to indicate that an attempt to create a framebuffer
> failed.
> 
> Is this the correct build procedure?
> What hardware have you used to test UEFI boot?
> Does the trace below suggest any experiments to try?
> 
> *
> 
> WARNING: no console will be available to OS
> Bender: Hello World.
> 
> Boot config: parsing cmdline ''
> Boot config: console_port = 0x3f8
> Boot config: debug_port = 0x3f8
> Boot config: disable_iommu = false
> 
> Boot config: parsing cmdline 'sel4 disable_iommu'
> Boot config: console_port = 0x3f8
> Boot config: debug_port = 0x3f8
> Boot config: disable_iommu = true
>   module #0: start=0xeaba000 end=0xf0ff968 size=0x645968 name='image.elf'
> Physical Memory Region from 0 size 8f000 type 1
> Physical Memory Region from 8f000 size 1000 type 4
> Physical Memory Region from 9 size e000 type 1
> Physical Memory Region from 9e000 size 2000 type 2
> Physical Memory Region from 10 size 1ef0 type 1
> Adding physical memory region 0x10-0x1f00
> Physical Memory Region from 1f00 size 120 type 2
> Physical Memory Region from 2020 size 3af29000 type 1
> Physical Memory Region from 5b129000 size 3 type 2
> Physical Memory Region from 5b159000 size 25000 type 3
> Physical Memory Region from 5b17e000 size 5d2000 type 4
> Physical Memory Region from 5b75 size 2b9000 type 2
> Physical Memory Region from 5ba09000 size 79000 type 20
> Physical Memory Region from 5ba82000 size 57e000 type 1
> Physical Memory Region from e000 size 400 type 2
> Physical Memory Region from fea0 size 10 type 2
> Physical Memory Region from fec0 size 1000 type 2
> Physical Memory Region from fed01000 size 1000 type 2
> Physical Memory Region from fed03000 size 1000 type 2
> Physical Memory Region from fed06000 size 1000 type 2
> Physical Memory Region from fed08000 size 2000 type 2
> Physical Memory Region from fed1c000 size 1000 type 2
> Physical Memory Region from fed8 size 4 type 2
> Physical Memory Region from fee0 size 1000 type 2
> Physical Memory Region from ffc0 size 40 type 2
> Kernel loaded to: start=0x20 end=0x281000 size=0x81000 entry=0x20007e
> ACPI: RSDP paddr=0x3c490
> ACPI: RSDP vaddr=0xdfc3c490
> ACPI: RSDT paddr=0x5b161028
> ACPI: RSDT vaddr=0xdfd61028
> ACPI: FADT paddr=0x5b1611a8
> ACPI: FADT vaddr=0xdfd611a8
> ACPI: FADT flags=0x421
> ACPI: MADT paddr=0x5b177380
> ACPI: MADT vaddr=0xdfd77380
> ACPI: MADT apic_addr=0xfee0
> ACPI: MADT flags=0x1
> ACPI: MADT_APIC apic_id=0x0
> ACPI: MADT_APIC apic_id=0x2
> ACPI: MADT_APIC apic_id=0x4
> ACPI: MADT_APIC apic_id=0x6
> ACPI: MADT_IOAPIC ioapic_id=1 ioapic_addr=0xfec0 gsib=0
> ACPI: MADT_ISO bus=0 source=0 gsi=2 flags=0x0
> ACPI: MADT_ISO bus=0 source=9 gsi=9 flags=0xd
> ACPI: 4 CPU(s) detected
> Detected 1 boot module(s):
> ELF-loading userland images from boot modules:
> size=0xd87000 v_entry=0x200 v_start=0x200 v_end=0x2d87000
> p_start=0xf10 p_end=0xfe87000
> Moving loaded userland images to final locatio

Re: [seL4] UEFI support for x86

[Raymond Jennings]

I think that UEFI would involve the bootloader that the BIOS starts.  I
don't know if the bootstrap part of UEFI would be handled by seL4 itself or
by something like grub/grub2.

My wild-ass guess is that anything after seL4 takes over would be handled
by a driver process that has the required capabilities to interface with
the corresponding hardware.
___
Devel mailing list
Devel@sel4.systems
https://sel4.systems/lists/listinfo/devel

Re: [seL4] UEFI support for x86

[Edward Sandberg]

Hello,

I built Genode 17.08 with run option "image/uefi" and platform option
"sel4_x86_32". I have tried booting the resulting image on a variety of
machines but am not getting the behavior I expect.  The machines I have
tried are:

* Up board (a Windows compatible Atom-based system)
* Dell M3800 laptop
* Dell Latitude 7280 laptop
* HP ProLiant DL380 Gen9 Server
* Dell Optoplex 990
* Asus P9X79 WS Motherboard with Intel Core i7-3930K

The furthest I have gotten was on the UP board, which only supports UEFI
boot:

https://www.intel.com/content/www/us/en/support/emerging-technologies/intel-realsense-technology/22699.html

I saw serial output but no graphical output (see below).  The other
machines I tried to boot on didn't even give me serial output.  The
serial output seems to indicate that an attempt to create a framebuffer
failed.

Is this the correct build procedure?
What hardware have you used to test UEFI boot?
Does the trace below suggest any experiments to try?

*

WARNING: no console will be available to OS
Bender: Hello World.

Boot config: parsing cmdline ''
Boot config: console_port = 0x3f8
Boot config: debug_port = 0x3f8
Boot config: disable_iommu = false

Boot config: parsing cmdline 'sel4 disable_iommu'
Boot config: console_port = 0x3f8
Boot config: debug_port = 0x3f8
Boot config: disable_iommu = true
  module #0: start=0xeaba000 end=0xf0ff968 size=0x645968 name='image.elf'
Physical Memory Region from 0 size 8f000 type 1
Physical Memory Region from 8f000 size 1000 type 4
Physical Memory Region from 9 size e000 type 1
Physical Memory Region from 9e000 size 2000 type 2
Physical Memory Region from 10 size 1ef0 type 1
Adding physical memory region 0x10-0x1f00
Physical Memory Region from 1f00 size 120 type 2
Physical Memory Region from 2020 size 3af29000 type 1
Physical Memory Region from 5b129000 size 3 type 2
Physical Memory Region from 5b159000 size 25000 type 3
Physical Memory Region from 5b17e000 size 5d2000 type 4
Physical Memory Region from 5b75 size 2b9000 type 2
Physical Memory Region from 5ba09000 size 79000 type 20
Physical Memory Region from 5ba82000 size 57e000 type 1
Physical Memory Region from e000 size 400 type 2
Physical Memory Region from fea0 size 10 type 2
Physical Memory Region from fec0 size 1000 type 2
Physical Memory Region from fed01000 size 1000 type 2
Physical Memory Region from fed03000 size 1000 type 2
Physical Memory Region from fed06000 size 1000 type 2
Physical Memory Region from fed08000 size 2000 type 2
Physical Memory Region from fed1c000 size 1000 type 2
Physical Memory Region from fed8 size 4 type 2
Physical Memory Region from fee0 size 1000 type 2
Physical Memory Region from ffc0 size 40 type 2
Kernel loaded to: start=0x20 end=0x281000 size=0x81000 entry=0x20007e
ACPI: RSDP paddr=0x3c490
ACPI: RSDP vaddr=0xdfc3c490
ACPI: RSDT paddr=0x5b161028
ACPI: RSDT vaddr=0xdfd61028
ACPI: FADT paddr=0x5b1611a8
ACPI: FADT vaddr=0xdfd611a8
ACPI: FADT flags=0x421
ACPI: MADT paddr=0x5b177380
ACPI: MADT vaddr=0xdfd77380
ACPI: MADT apic_addr=0xfee0
ACPI: MADT flags=0x1
ACPI: MADT_APIC apic_id=0x0
ACPI: MADT_APIC apic_id=0x2
ACPI: MADT_APIC apic_id=0x4
ACPI: MADT_APIC apic_id=0x6
ACPI: MADT_IOAPIC ioapic_id=1 ioapic_addr=0xfec0 gsib=0
ACPI: MADT_ISO bus=0 source=0 gsi=2 flags=0x0
ACPI: MADT_ISO bus=0 source=9 gsi=9 flags=0xd
ACPI: 4 CPU(s) detected
Detected 1 boot module(s):
ELF-loading userland images from boot modules:
size=0xd87000 v_entry=0x200 v_start=0x200 v_end=0x2d87000
p_start=0xf10 p_end=0xfe87000
Moving loaded userland images to final location: from=0xf10
to=0x281000 size=0xd87000
Starting node #0 with APIC ID 0

Starting node #1 with APIC ID 2
Starting node #2 with APIC ID 4
Starting node #3 with APIC ID 6
Booting all finished, dropped to user space
virtual address layout of core:
 overall[2000,c000)
 core image [0200,02d87000)
 ipc buffer [02d87000,02d88000)
 boot_info  [02d88000,02d8a000)
 stack area [4000,5000)
Warning: need physical memory, but Platform object not constructed yet
Warning: need physical memory, but Platform object not constructed yet
Warning: need physical memory, but Platform object not constructed yet
Warning: need physical memory, but Platform object not constructed yet
:phys_alloc:   Allocator 0x2800df8 dump:
 Block: [0020,00201000) size=4K avail=0 max_avail=0
 Block: [00201000,00202000) size=4K avail=0 max_avail=0
 Block: [00202000,00203000) size=4K avail=0 max_avail=0
 Block: [00203000,00204000) size=4K avail=0 max_avail=0
 Block: [00204000,00205000) size=4K avail=0 max_avail=0
 Block: [00205000,00206000) size=4K avail=0 max_avail=0
 Block: [00206000

Re: [seL4] UEFI support for x86

[Alexander Boettcher]

Hi Adrian,

On 28.08.2017 02:53, adrian.da...@data61.csiro.au wrote:
> Hi Alex,
> 
> I think this is a good direction to move in, and supporting MBI2 definitely 
> makes sense. In an ideal world, yes we would try and cut out grub2 and be 
> pure UEFI booted, but given current resources I cannot see that happening any 
> time soon, and so I see no reason not to welcome MBI2 support.
> 
> As you point out some of the code itself is not perfect, but what it's 
> actually doing seems fairly simple and non-controversial to me. Quite 
> possibly you did this just to get it working as a proof of concept, but I 
> would discourage adding more architecture information to the raw 
> seL4_Bootinfo (the archInfo word is an old hack), and instead use the 
> additional headers 
> (https://github.com/seL4/seL4/blob/master/libsel4/include/sel4/bootinfo_types.h#L83).
>  Aside from that, as you say the code needs some deduplication etc, but I'm 
> happy to continue on github and get this in.

ok, created a github issue at https://github.com/seL4/seL4/issues/67

-- 
Alexander Boettcher
Genode Labs

http://www.genode-labs.com - http://www.genode.org

Genode Labs GmbH - Amtsgericht Dresden - HRB 28424 - Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

___
Devel mailing list
Devel@sel4.systems
https://sel4.systems/lists/listinfo/devel

Re: [seL4] UEFI support for x86

[Adrian.Danis]

Hi Alex,

I think this is a good direction to move in, and supporting MBI2 definitely 
makes sense. In an ideal world, yes we would try and cut out grub2 and be pure 
UEFI booted, but given current resources I cannot see that happening any time 
soon, and so I see no reason not to welcome MBI2 support.

As you point out some of the code itself is not perfect, but what it's actually 
doing seems fairly simple and non-controversial to me. Quite possibly you did 
this just to get it working as a proof of concept, but I would discourage 
adding more architecture information to the raw seL4_Bootinfo (the archInfo 
word is an old hack), and instead use the additional headers 
(https://github.com/seL4/seL4/blob/master/libsel4/include/sel4/bootinfo_types.h#L83).
 Aside from that, as you say the code needs some deduplication etc, but I'm 
happy to continue on github and get this in.

Adrian

On Fri 25-Aug-2017 11:31 PM, Alexander Boettcher wrote:

Hello,

since last week we successful added UEFI support to Genode/seL4 for x86.

In this course we extended the seL4 6.0 kernel (beside the NOVA kernel
and our own kernel - Genode/hw) to be also a Multiboot2 (MBI2) kernel.
The MBI2 specification [3] provides to the kernel the ACPI RSDP
information, which was the main reason to add MBI2 support. Together
with GRUB2 (as UEFI capable bootloader) we were able to get our setups
running on various native x86 machines and on Qemu.

Additionally we extended the 3 kernels to propagate the ACPI RSDP
information further to the user-land, since there the ACPI driver also
failed to lookup the ACPI RSDP information.

The patch for the seL4 kernel are currently on our staging branch (our
automatically tested branch) and will show up in the upcoming release
next week eventually.

Currently, the patches are tight to Genode, but I can open up a feature
issue on seL4 github if you are fine with the general direction - so
adding MBI2 support in general. Or you would rather go in another
direction like writing an own UEFI boot loader, which maybe is more
minimal compared to GRUB2 etc etc.

I have to admit, that the code addition to the seL4 kernel is far from
being optimal - amount of code because of redundant MBI 1 vs 2 code,
correctness of code (I'm not super familiar with the internals of the
seL4 kernel), missing framebuffer information etc - but this we may
discuss in more detail on github, if wanted.


Cheers,

Alex.

[0]
https://github.com/genodelabs/genode/commit/b9aa16eb3e671a7e3c1474b076a244c7c97e5dea
"sel4: kernel patch to get ACPI information"
[1]
https://github.com/genodelabs/genode/commit/c09783eed9a52ad72e8a1a986b832303574612ba
"sel4: add uefi boot support via mbi2"
[3]
http://git.savannah.gnu.org/cgit/grub.git/tree/doc/multiboot.texi?h=multiboot2

On 10.08.2017 16:50, 
adrian.da...@data61.csiro.au wrote:


Hi Edward,

In the near future? Unfortunately not. UEFI support is definitely something 
that we talk about every so often, but just never makes it high enough up the 
priority list for us internally.

A configuration option for overriding the RSDP search doesn't so too 
unreasonable in cases where there isn't a BIOS region to search. At least until 
we can retrieve the address from the UEFI runtime.

It is entirely possible that any number of tables and initialization needs to 
happen before the timer, or other hardware, will work. Currently the ACPI 
tables here are just being used to find the base address of the HPET, and it is 
assumed that it is in a working state and no further setup needs to be done.

As for the IRQ numbers in seL4 you are seeing the local CPU vector delivery 
number, not the source I/O APIC interrupt number or GSI. To determine the IRQ 
source you could check the x86KSIRQState for the local CPU vector (in this case 
125), unpack the x86_irq_state_t type, and see where it came from.

The user code though is first trying to use the HPET and then if it cannot find 
that (i.e. it's not in the ACPI tables) then it falls back to the PIT. If it 
finds a HPET then it will try and use FSB (i.e. MSI) delivery, and failing that 
fall back to I/O APIC delivery. If you want to work out which of these its 
using you could either infer from the x86KSIRQState as mentioned above or 
instrument 
https://github.com/seL4/util_libs/blob/fff76a36a02b8ccef3aa0b201751c57b62ac3621/libplatsupport/src/plat/pc99/ltimer.c#L225
 and 
https://github.com/seL4/util_libs/blob/fff76a36a02b8ccef3aa0b201751c57b62ac3621/libplatsupport/src/plat/pc99/ltimer.c#L306
 to see what exactly it is doing.

Adrian

On Thu 10-Aug-2017 4:56 AM, Edward Sandberg wrote:

Is there a plan to add UEFI support in seL4 for x86 hardware in the near
future?  Newer x86 boards are frequently UEFI only.  It is possible to
get around the lack of UEFI support, as I have done with the UP board:

https://up-community.org/wiki/Hardware_Specification

but I am hitting problems which I will detail below.

When I compile using ia32_d

Re: [seL4] UEFI support for x86

[Alexander Boettcher]

Hello,

since last week we successful added UEFI support to Genode/seL4 for x86.

In this course we extended the seL4 6.0 kernel (beside the NOVA kernel
and our own kernel - Genode/hw) to be also a Multiboot2 (MBI2) kernel.
The MBI2 specification [3] provides to the kernel the ACPI RSDP
information, which was the main reason to add MBI2 support. Together
with GRUB2 (as UEFI capable bootloader) we were able to get our setups
running on various native x86 machines and on Qemu.

Additionally we extended the 3 kernels to propagate the ACPI RSDP
information further to the user-land, since there the ACPI driver also
failed to lookup the ACPI RSDP information.

The patch for the seL4 kernel are currently on our staging branch (our
automatically tested branch) and will show up in the upcoming release
next week eventually.

Currently, the patches are tight to Genode, but I can open up a feature
issue on seL4 github if you are fine with the general direction - so
adding MBI2 support in general. Or you would rather go in another
direction like writing an own UEFI boot loader, which maybe is more
minimal compared to GRUB2 etc etc.

I have to admit, that the code addition to the seL4 kernel is far from
being optimal - amount of code because of redundant MBI 1 vs 2 code,
correctness of code (I'm not super familiar with the internals of the
seL4 kernel), missing framebuffer information etc - but this we may
discuss in more detail on github, if wanted.


Cheers,

Alex.

[0]
https://github.com/genodelabs/genode/commit/b9aa16eb3e671a7e3c1474b076a244c7c97e5dea
"sel4: kernel patch to get ACPI information"
[1]
https://github.com/genodelabs/genode/commit/c09783eed9a52ad72e8a1a986b832303574612ba
"sel4: add uefi boot support via mbi2"
[3]
http://git.savannah.gnu.org/cgit/grub.git/tree/doc/multiboot.texi?h=multiboot2

On 10.08.2017 16:50, adrian.da...@data61.csiro.au wrote:
> Hi Edward,
> 
> In the near future? Unfortunately not. UEFI support is definitely something 
> that we talk about every so often, but just never makes it high enough up the 
> priority list for us internally.
> 
> A configuration option for overriding the RSDP search doesn't so too 
> unreasonable in cases where there isn't a BIOS region to search. At least 
> until we can retrieve the address from the UEFI runtime.
> 
> It is entirely possible that any number of tables and initialization needs to 
> happen before the timer, or other hardware, will work. Currently the ACPI 
> tables here are just being used to find the base address of the HPET, and it 
> is assumed that it is in a working state and no further setup needs to be 
> done.
> 
> As for the IRQ numbers in seL4 you are seeing the local CPU vector delivery 
> number, not the source I/O APIC interrupt number or GSI. To determine the IRQ 
> source you could check the x86KSIRQState for the local CPU vector (in this 
> case 125), unpack the x86_irq_state_t type, and see where it came from.
> 
> The user code though is first trying to use the HPET and then if it cannot 
> find that (i.e. it's not in the ACPI tables) then it falls back to the PIT. 
> If it finds a HPET then it will try and use FSB (i.e. MSI) delivery, and 
> failing that fall back to I/O APIC delivery. If you want to work out which of 
> these its using you could either infer from the x86KSIRQState as mentioned 
> above or instrument 
> https://github.com/seL4/util_libs/blob/fff76a36a02b8ccef3aa0b201751c57b62ac3621/libplatsupport/src/plat/pc99/ltimer.c#L225
>  and 
> https://github.com/seL4/util_libs/blob/fff76a36a02b8ccef3aa0b201751c57b62ac3621/libplatsupport/src/plat/pc99/ltimer.c#L306
>  to see what exactly it is doing.
> 
> Adrian
> 
> On Thu 10-Aug-2017 4:56 AM, Edward Sandberg wrote:
> 
> Is there a plan to add UEFI support in seL4 for x86 hardware in the near
> future?  Newer x86 boards are frequently UEFI only.  It is possible to
> get around the lack of UEFI support, as I have done with the UP board:
> 
> https://up-community.org/wiki/Hardware_Specification
> 
> but I am hitting problems which I will detail below.
> 
> When I compile using ia32_debug_xml_defconfig and boot using the
> resulting images the board fails to find the RSDP location.  To fix this
> I had to modify the source code a bit:
> 
> 
> * seL4test/projects/util_libs/libplatsupport/src/plat/pc99/acpi/acpi.h
> 
> +#define UPBOARD_RSDP   0x5B161000
> 
> * seL4test/projects/util_libs/libplatsupport/src/plat/pc99/acpi/acpi.c
> 
> -acpi->rsdp = acpi_sig_search(acpi, ACPI_SIG_RSDP,
> strlen(ACPI_SIG_RSDP),
> - (void *) BIOS_PADDR_START, (void *)
> BIOS_PADDR_END);
> +acpi->rsdp = (void *)UPBOARD_RSDP;
> 
> * seL4test/kernel/src/plat/pc99/machine/acpi.c
> 
> -for (addr = (char*)BIOS_PADDR_START; addr < (char*)BIOS_PADDR_END;
> addr += 16) {
> +for (addr = (char*)0; addr < (char*)PPTR_BASE; addr += 16) {
> 
> It would be handy to have this as a kernel parameter to cover cases
> where it is not successfully discovered aut

Re: [seL4] UEFI support for x86

[Adrian.Danis]

Hi Edward,

In the near future? Unfortunately not. UEFI support is definitely something 
that we talk about every so often, but just never makes it high enough up the 
priority list for us internally.

A configuration option for overriding the RSDP search doesn't so too 
unreasonable in cases where there isn't a BIOS region to search. At least until 
we can retrieve the address from the UEFI runtime.

It is entirely possible that any number of tables and initialization needs to 
happen before the timer, or other hardware, will work. Currently the ACPI 
tables here are just being used to find the base address of the HPET, and it is 
assumed that it is in a working state and no further setup needs to be done.

As for the IRQ numbers in seL4 you are seeing the local CPU vector delivery 
number, not the source I/O APIC interrupt number or GSI. To determine the IRQ 
source you could check the x86KSIRQState for the local CPU vector (in this case 
125), unpack the x86_irq_state_t type, and see where it came from.

The user code though is first trying to use the HPET and then if it cannot find 
that (i.e. it's not in the ACPI tables) then it falls back to the PIT. If it 
finds a HPET then it will try and use FSB (i.e. MSI) delivery, and failing that 
fall back to I/O APIC delivery. If you want to work out which of these its 
using you could either infer from the x86KSIRQState as mentioned above or 
instrument 
https://github.com/seL4/util_libs/blob/fff76a36a02b8ccef3aa0b201751c57b62ac3621/libplatsupport/src/plat/pc99/ltimer.c#L225
 and 
https://github.com/seL4/util_libs/blob/fff76a36a02b8ccef3aa0b201751c57b62ac3621/libplatsupport/src/plat/pc99/ltimer.c#L306
 to see what exactly it is doing.

Adrian

On Thu 10-Aug-2017 4:56 AM, Edward Sandberg wrote:

Is there a plan to add UEFI support in seL4 for x86 hardware in the near
future?  Newer x86 boards are frequently UEFI only.  It is possible to
get around the lack of UEFI support, as I have done with the UP board:

https://up-community.org/wiki/Hardware_Specification

but I am hitting problems which I will detail below.

When I compile using ia32_debug_xml_defconfig and boot using the
resulting images the board fails to find the RSDP location.  To fix this
I had to modify the source code a bit:


* seL4test/projects/util_libs/libplatsupport/src/plat/pc99/acpi/acpi.h

+#define UPBOARD_RSDP   0x5B161000

* seL4test/projects/util_libs/libplatsupport/src/plat/pc99/acpi/acpi.c

-acpi->rsdp = acpi_sig_search(acpi, ACPI_SIG_RSDP,
strlen(ACPI_SIG_RSDP),
- (void *) BIOS_PADDR_START, (void *)
BIOS_PADDR_END);
+acpi->rsdp = (void *)UPBOARD_RSDP;

* seL4test/kernel/src/plat/pc99/machine/acpi.c

-for (addr = (char*)BIOS_PADDR_START; addr < (char*)BIOS_PADDR_END;
addr += 16) {
+for (addr = (char*)0; addr < (char*)PPTR_BASE; addr += 16) {

It would be handy to have this as a kernel parameter to cover cases
where it is not successfully discovered automatically.  With these
changes I can boot the board and several tests pass but then I get stuck
on INTERRUPT0001 (Test interrupts with timer).  I don't get a test
failure or an error the board just sits and makes no more progress.
Someone had that test fail in this post:

https://sel4.systems/pipermail/devel/2017-February/001328.html

and the first recommendation was to check if the irq of the timer was
correctly found. I booted the board into linux to find the correct irq
which was listed as 0 in /proc/interupts.  I added a printf to
handleInterrupt in the kernel source, recompiled and when I booted seL4
I found that the irq reported to handleInterrupt is 125 (which sel4
reports as the max interrupt value) every time that function is called.
Adding this printf also showed me that when the test hangs the board
hasn't crashed or locked up as calls to handleInterrupt are made
continuously.

At this point I noticed that before any tests started to run several
ACPI tables are not recognized:

Parsing ACPI tables
Skipping table FPDTD, unknown
Skipping table FIDT<9c>, unknown
Skipping table UEFIB, unknown
Skipping table TPM24, unknown
Skipping table LPIT^D^A, unknown
Skipping table BCFG9^A, unknown
Skipping table PRAM0, unknown
Skipping table CSRTL^A, unknown
Skipping table BCFG9^A, unknown
Skipping table OEM0<84>, unknown
Skipping table OEM1@, unknown
Skipping table PIDVÜ, unknown
Skipping table RSCI,, unknown
Skipping table WDAT^D^A, unknown
Warning: skipping table ACPI XSDT

Maybe one or more of those tables needs to be loaded to handle
interrupts properly. The LPIT table is conspicuous in the case of the
timer test but I think other tests are likely to depend on the other tables.

Any suggestions about porting this type of hardware?



___
Devel mailing list
Devel@sel4.systems
https://sel4.systems/lists/listinfo/devel