Hi all,
I was able to compile the camkes-arm-vm and run it on a TK1-SOM board. I wonder if it is possible to run a Linux distribution as the guest OS, such as Ubuntu, Fedora, etc.? If so how can we do that?
Best Regards
-Daniel Wang
Hi Kent and Peter,
Thank you so much for your response. I do not know what exactly caused the issue. But I upgraded my toolchain and recompiled the image again and it loaded this time. The GCC version is version 7.2.1 (before it was 4.6).
Although I still see the misaligned information like this:
CACHE: Misaligned operation at range [90000000, 90000014]
CACHE: Misaligned operation at range [90001000, 900091c4]
CACHE: Misaligned operation at range [900091c4, 900098d8]
CACHE: Misaligned …
[View More]operation at range [900198d8, 900198e0]
CACHE: Misaligned operation at range [900198e0, 91392ae0]
CACHE: Misaligned operation at range [91394000, 913a4820]
CACHE: Misaligned operation at range [913a4820, 913a8000]
Another thing I found is that U-boot for TK1-SOM cannot detect ethernet, but I was able to copy the image into MMC and load from there.
There are two things I want to do with the seL4 ARM VMM platform. First, I want to incorporate the secure boot from U-boot to seL4 and then using seL4 to verified signed Linux. Second, I want to build a PoC native application and allow the communication between the native app to communication with App running in Linux. I’m wondering if anyone did those two things before that can give me some advice? I implemented the the second scenario before using L4re with a paravirtualized L4Linux. But I’m exactly sure how to do it with seL4 yet.
Best Regards
-Daniel Wang
> On Mar 1, 2018, at 8:00 PM, <Kent.Mcleod(a)data61.csiro.au> <Kent.Mcleod(a)data61.csiro.au> wrote:
>
> Hi Daniel,
>
> Two things to try:
>
> First is to confirm that CONFIG_PRINTING is enabled to distinguish if the kernel is successfully starting its init process.
>
> Second is to check what ${loadaddr} is set to. Yours seems correct, ours seems to be 0x81000000, but that is for the tk1 jetson dev board.
>
> You could also try editing the elfloader to print out the contents of the kernel entrypoint before it jumps there to confirm that it is the correct instructions in the stage/arm/tk1/kernel.elf binary.
>
> Below is what I see when I boot the project on our devboard.
>
> Kind regards,
> Kent.
>
> ----
> U-Boot SPL 2015.10-rc5-00002-gf861f51-dirty (Oct 13 2015 - 13:44:41)
>
>
> U-Boot 2015.10-rc5-00002-gf861f51-dirty (Oct 13 2015 - 13:44:41 +1100)
>
> TEGRA124
> Model: NVIDIA Jetson TK1
> Board: NVIDIA Jetson TK1
> DRAM: 2 GiB
> MMC: Tegra SD/MMC: 0, Tegra SD/MMC: 1
> tegra-pcie: PCI regions:
> tegra-pcie: I/O: 0x12000000-0x12010000
> tegra-pcie: non-prefetchable memory: 0x13000000-0x20000000
> tegra-pcie: prefetchable memory: 0x20000000-0x40000000
> tegra-pcie: 2x1, 1x1 configur��K����Ʌ�pcie: probing port 0, using 2 lanes
> tegra-pcie: link 0 down, retrying
> tegra-pcie: link 0 down, retrying
> tegra-pcie: link 0 down, retrying
> tegra-pcie: link 0 down, ignoring
> tegra-pcie: probing port 1, using 1 lanes
> In: serial
> Out: serial
> Err: serial
> Net: RTL8169#0
> Hit any key to stop autoboot: 2
> 0
> Tegra124 (Jetson TK1) # setenv autoload no && dhcp && tftpboot 0x81000000 jetson1/sel4-image
> setenv autoload no && dhcp && tftpboot 0x81000000 jetson1/sel4-image
> BOOTP broadcast 1
> BOOTP broadcast 2
> BOOTP broadcast 3
> BOOTP broadcast 4
> DHCP client bound to address 10.13.1.172 (2929 ms)
> Using RTL8169#0 device
> TFTP from server 10.13.0.130; our IP address is 10.13.1.172
> Filename 'jetson1/sel4-image'.
> Load address: 0x81000000
> Loading: #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> ################################
> 3.8 MiB/s
> done
> Bytes transferred = 20493516 (138b4cc hex)
> Tegra124 (Jetson TK1) # bootelf 0x81000000
> bootelf 0x81000000
> ## Starting application at 0x90000000 ...
> ELF loader: monitor mode init done
> Copy monitor mode vector from 90001000 to a7f00000 size 50
> Number of IRQs: 192
> Load seL4 in nonsecure HYP mode 600001da
> ELF-loader started on CPU: ARM Ltd. Cortex-A15 r3p3
> paddr=[90000000..9139ffff]
> ELF-loading image 'kernel'
> paddr=[80000000..8003cfff]
> vaddr=[e0000000..e003cfff]
> virt_entry=e0000000
> ELF-loading image 'capdl-loader-experimental'
> paddr=[8003d000..8158dfff]
> vaddr=[10000..1560fff]
> virt_entry=18484
> Enabling hypervisor MMU and paging
> Jumping to kernel-image entry point...
>
> Bootstrapping kernel
> Total 28 IOASID set up
> Region [c to 28) for SMMU caps
> Booting all finished, dropped to user space
>
>
>
> From: Devel <devel-bounces(a)sel4.systems> on behalf of Daniel Wang <danielwang.ksu(a)gmail.com>
> Sent: Friday, March 2, 2018 7:47 AM
> To: devel(a)sel4.systems
> Subject: [seL4] seL4 VMM Hangs during loading time
>
> Hi all,
>
> I’m trying to run seL as a microvisor following the CAMKES-ARM-VM. My development board is TK1-SOM from ColoradoEngineering. I was able to flash the U-boot to to load seL4 HYP mode. However when I try to load the kernel. The system just hangs. I got stuck here any help would be appreciated thank you!
>
> I built the capdl-loader-experimental-image-arm-tk1
> and can copied it to the TK1 MMC storage, then I followed the wiki to setup env bootm_boot_mode to nonsec. Attachment is the printout:
>
> -------------------------------------------------------------------------------------------
> U-Boot 2018.03-rc3-00090-g3990c9d (Mar 01 2018 - 14:33:40 -0500)
>
> TEGRA124
> Model: Colorado Engineering TK1-SOM
> Board: CEI tk1-som
> DRAM: 2 GiB
> MMC: sdhci@700b0400: 1, sdhci@700b0600: 0
> Loading Environment from MMC... OK
> In:
> serial
> Out: serial
> Err: serial
> Net: No ethernet found.
> Hit any key to stop autoboot: 0
> Tegra124 (TK1-SOM) # setenv bootm_boot_mode nonsec
> Tegra124 (TK1-SOM) # saveenv
> Saving Environment to MMC... Writing to MMC(0)... OK
> Tegra124 (TK1-SOM) # ext2ls mmc 0
> <DIR>
> 4096 .
> <DIR>
> 4096 ..
> <DIR>
> 16384 lost+found
> <DIR>
> 4096 boot
> <DIR>
> 4096 bin
> <DIR>
> 4096 dev
> <DIR>
> 12288 etc
> <DIR>
> 4096 home
> <DIR>
> 4096 lib
> <DIR>
> 4096 media
> <DIR>
> 4096 mnt
> <DIR>
> 4096 opt
> <DIR>
> 4096 proc
>
> 62 README.txt
> <DIR>
> 4096 root
> <DIR>
> 4096 run
> <DIR>
> 12288 sbin
> <DIR>
> 4096 srv
> <DIR>
> 4096 sys
> <DIR>
> 4096 tmp
> <DIR>
> 4096 usr
> <DIR>
> 4096 var
>
> 150994944 testfile
>
> 20524388 capdl-loader-experimental-image-arm-tk1
> Tegra124 (TK1-SOM) # ext2load mmc 0 ${loadaddr} capdl-loader-experimental-image-arm-tk1
> 20524388 bytes read in 593 ms (33 MiB/s)
> Tegra124 (TK1-SOM) # bootelf ${loadaddr}
> CACHE: Misaligned operation at range [90000000, 90000014]
> CACHE: Misaligned operation at range [90001000, 900091c4]
> CACHE: Misaligned operation at range [900091c4, 900098d8]
> CACHE: Misaligned operation at range [900198d8, 900198e0]
> CACHE: Misaligned operation at range [900198e0, 91392ae0]
> CACHE: Misaligned operation at range [91394000, 913a4820]
> CACHE: Misaligned operation at range [913a4820, 913a8000]
> ## Starting application at 0x90000000 ...
> ELF loader: monitor mode init done
> Copy monitor mode vector from 90001000 to a7f00000 size 50
> Number of IRQs: 192
> Load seL4 in nonsecure HYP mode 600001da
> ELF-loader started on CPU: ARM Ltd. Cortex-A15 r3p3
> paddr=[90000000..913a7fff]
> ELF-loading image 'kernel'
> paddr=[60000000..6003cfff]
> vaddr=[e0000000..e003cfff]
> virt_entry=e0000000
>
> -------------------------------------------------------------------------------------------
>
> Best Regards
> -Daniel Wang
>
>
>
>
[View Less]
Hi all,
I’m trying to run seL as a microvisor following the CAMKES-ARM-VM. My development board is TK1-SOM from ColoradoEngineering. I was able to flash the U-boot to to load seL4 HYP mode. However when I try to load the kernel. The system just hangs. I got stuck here any help would be appreciated thank you!
I built the capdl-loader-experimental-image-arm-tk1 and can copied it to the TK1 MMC storage, then I followed the wiki to setup env bootm_boot_mode to nonsec. Attachment is the printout:
…
[View More]-------------------------------------------------------------------------------------------
U-Boot 2018.03-rc3-00090-g3990c9d (Mar 01 2018 - 14:33:40 -0500)
TEGRA124
Model: Colorado Engineering TK1-SOM
Board: CEI tk1-som
DRAM: 2 GiB
MMC: sdhci@700b0400: 1, sdhci@700b0600: 0
Loading Environment from MMC... OK
In: serial
Out: serial
Err: serial
Net: No ethernet found.
Hit any key to stop autoboot: 0
Tegra124 (TK1-SOM) # setenv bootm_boot_mode nonsec
Tegra124 (TK1-SOM) # saveenv
Saving Environment to MMC... Writing to MMC(0)... OK
Tegra124 (TK1-SOM) # ext2ls mmc 0
<DIR> 4096 .
<DIR> 4096 ..
<DIR> 16384 lost+found
<DIR> 4096 boot
<DIR> 4096 bin
<DIR> 4096 dev
<DIR> 12288 etc
<DIR> 4096 home
<DIR> 4096 lib
<DIR> 4096 media
<DIR> 4096 mnt
<DIR> 4096 opt
<DIR> 4096 proc
62 README.txt
<DIR> 4096 root
<DIR> 4096 run
<DIR> 12288 sbin
<DIR> 4096 srv
<DIR> 4096 sys
<DIR> 4096 tmp
<DIR> 4096 usr
<DIR> 4096 var
150994944 testfile
20524388 capdl-loader-experimental-image-arm-tk1
Tegra124 (TK1-SOM) # ext2load mmc 0 ${loadaddr} capdl-loader-experimental-image-arm-tk1
20524388 bytes read in 593 ms (33 MiB/s)
Tegra124 (TK1-SOM) # bootelf ${loadaddr}
CACHE: Misaligned operation at range [90000000, 90000014]
CACHE: Misaligned operation at range [90001000, 900091c4]
CACHE: Misaligned operation at range [900091c4, 900098d8]
CACHE: Misaligned operation at range [900198d8, 900198e0]
CACHE: Misaligned operation at range [900198e0, 91392ae0]
CACHE: Misaligned operation at range [91394000, 913a4820]
CACHE: Misaligned operation at range [913a4820, 913a8000]
## Starting application at 0x90000000 ...
ELF loader: monitor mode init done
Copy monitor mode vector from 90001000 to a7f00000 size 50
Number of IRQs: 192
Load seL4 in nonsecure HYP mode 600001da
ELF-loader started on CPU: ARM Ltd. Cortex-A15 r3p3
paddr=[90000000..913a7fff]
ELF-loading image 'kernel'
paddr=[60000000..6003cfff]
vaddr=[e0000000..e003cfff]
virt_entry=e0000000
-------------------------------------------------------------------------------------------
Best Regards
-Daniel Wang
[View Less]
The article “Mixed-criticality support in seL4” at https://lwn.net/Articles/745946/ says seL4's solution to the problem of CPU budget exhaustion while in a non-reentrant shared data-structure server is timeout exceptions. The server might time out by chance, through no fault of its own.
A more robust solution is to simply disallow calling any such server that advertises a WCET longer than the client's per-period CPU budget, and when a call is made, have the kernel check whether the client's …
[View More]remaining CPU budget ≥ server's WCET. If it is, then proceed with the call as normal. If it isn't, then verify that the client's per-period CPU budget ≥ server's WCET. If that verification succeeds, then terminate the budget for the client's current period early, and actually enter the server at the beginning of the client's _next_ period. (If the verification fails, then the kernel tells the client that the call is disallowed.)
If the server fails to return before exhausting the client's CPU budget, then the server has violated its own WCET, which is a bug. Thus, a non-buggy server will never time out, so timeout exception handlers handle only bugs, not routine system operation.
If the server's actual WCET is W, then from the client's point of view, the server's apparent WCET is almost 2W, because the client might make the call with remaining CPU budget X such that X is just barely less than W, in which case the kernel will terminate the client's current budget early (so the client loses X) and enter the server at the beginning of the next period, and the server might then take W to return, making the client wait X+W altogether (plus, of course, the remainder of the period, during which other VMs run). But with seL4's current solution, the server's apparent WCET is even longer than 2W, because the server could run for X, time out, be restarted (taking time R), then run for W, making the client wait X+R+W altogether.
[View Less]
Hi,
I like the Camkes (3) tool and believe it is essential for making seL4
accessible for developers. However, I have noticed some unexpected
limitations that I believe are either bugs or incomplete features.
Issue A:
A hierarchical component cannot have a dataport with a custom data type.
(However, a non-hierarchical component can have a dataport with a custom
data type. Also, a hierarchical component can have a dataport with a
built-in data type such as Buf.)
Issue B:
A dataport provided …
[View More]by a sub-component cannot be exported as a dataport
belonging to the hierarchical component that contains it. (However, the
export of event notifications from sub-components works just fine.)
Attached is the relevant code that demonstrates both issues, which is a
contrived example to highlight the issues without other stuff getting in
the way. Please note that the code as is compiles just fine, however if you
comment and uncomment a few lines of code (as instructed in Duck.camkes,
Duckherd.camkes and Duckling.camkes), the issues can be demonstrated
(separately) as compile failures.
There may be other issues with hierarchical components that I am not yet
aware of, as the above issues (unfortunately) have prevented me from
experimenting with them further.
Could you please acknowledge if these are issues that you are aware of, and
if there is likely to be a fix in a future Camkes 4 release?
Regards,
Dr Samuel Chenoweth
Cyber Security Researcher
DST Group
Note: I would have sent this email from my work email address (
samuel.chenoweth(a)dst.defence.gov.au) however I sent it from my personal
address instead because of issues to do with our email gateway. All the
contents of this email are UNCLASSIFIED and non-sensitive.
[View Less]
This is email is me being kinda lazy. Does anyone know how challenging this
would actually be to pull off? I'm interested in looking into it, but can't for a while.
I feel like it makes sense to bootload some little stub that sets up seL4 as the only
enclave in the system. I don't see any reason to have multiple enclaves when
using seL4. But, from this, it should be possible to get a good static root of trust
remote attestation on Google Cloud.
(And also, can finally implement https://www.…
[View More]blackhat.com/docs/us-17/thursday/us-17-Swami-SGX-Remote-Attesta…)
--
cmr
http://octayn.net/
+16038524272
[View Less]
Hi Kent,
I did a fresh
*repo init -u https://github.com/seL4/camkes-vm-manifest
<https://github.com/seL4/camkes-vm-manifest> *
so I am using the latest default.xml
Now I can get a bit further - although still not all the way - here is the
full output: https://gist.github.com/podhrmic/bc86178e60fad64ab870ff1fa19992
e3
and then the system as far as I can tell hangs - no serial or VGA output.
What could be the cause?
Regards
M
On Mon, Feb 19, 2018 at 4:07 PM, <Kent.Mcleod(a)…
[View More]data61.csiro.au> wrote:
> Hi Michal,
>
>
> Which revision of default.xml are you using? Adrian thinks it could be
> potentially related to, and fixed by, this commit[1] if you don't have it
> yet.
>
>
> Kent
>
>
> [1] https://github.com/seL4/seL4/commit/3d6f4f9bb7bfe42628df
> a555601401fa4efcdf2d
>
>
>
> ------------------------------
> *From:* Devel <devel-bounces(a)sel4.systems> on behalf of Michal Podhradsky
> <mpodhradsky(a)galois.com>
> *Sent:* Tuesday, February 20, 2018 9:37 AM
> *To:* devel(a)sel4.systems
> *Subject:* [seL4] CamkesVM CMA34CR_centos app
>
> Hi all,
>
> I have a CM34CR CPU module <https://wiki.sel4.systems/CMA34DBMC> and I am
> trying to run the related camkes app on it.
>
> I choose the centos app: https://github.com/seL4/camkes
> -vm/blob/master/apps/vm/cma34cr_centos.camkes
>
> I am using default camkes vm manifest from https://github.com/seL4/camkes
> -vm-manifest.
>
> Compile with:
>
> *make clean *
>
> *make cma34cr_centos_defcondig *
>
> *make silentoldconfig *
> *make*
>
> And then I create a bootable USB following instructions here
> <https://wiki.sel4.systems/Hardware/IA32>.
>
> Then after I load the kernel and capdl image, I get the following output
> on serial:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *Boot config: parsing cmdline 'sel4kernel' Boot config: console_port =
> 0x3f8 Boot config: debug_port = 0x3f8 Boot config: disable_iommu = false
> Detected 1 boot module(s): module #0: start=0xd34000 end=0x3b387e8
> size=0x2e047e8 name='rootserver' Parsing GRUB physical memory map
> Physical Memory Region from 0 size 9d400 type 1 Physical Memory Region
> from 9d400 size 2c00 type 2 Physical Memory Region from e0000 size
> 20000 type 2 Physical Memory Region from 100000 size 1ff00000 type 1
> Adding physical memory region 0x100000-0x20000000 Physical Memory
> Region from 20000000 size 200000 type 2 Physical Memory Region from
> 20200000 size 1fe04000 type 1 Adding physical memory region
> 0x20200000-0x40004000 Physical Memory Region from 40004000 size 1000
> type 2 Physical Memory Region from 40005000 size 64bab000 type 1 Adding
> physical memory region 0x40005000-0xa4bb0000 Physical Memory Region
> from a4bb0000 size 1400000 type 2 Physical Memory Region from a5fb0000
> size 4a0f000 type 1 Adding physical memory region 0xa5fb0000-0xaa9bf000
> Physical Memory Region from aa9bf000 size 500000 type 2 Physical Memory
> Region from aaebf000 size 100000 type 4 Physical Memory Region from
> aafbf000 size 40000 type 3 Physical Memory Region from aafff000 size
> 1000 type 1 Adding physical memory region 0xaafff000-0xab000000
> Physical Memory Region from ab000000 size 4a00000 type 2 Physical
> Memory Region from f0000000 size 4000000 type 2 Physical Memory Region
> from feb00000 size 4000 type 2 Physical Memory Region from fec00000
> size 1000 type 2 Physical Memory Region from fed10000 size a000 type 2
> Physical Memory Region from fed1c000 size 4000 type 2 Physical
> Memory Region from fee00000 size 1000 type 2 Physical Memory Region
> from ffc00000 size 400000 type 2 Physical Memory Region from 100000000
> size 14f600000 type 1 Adding physical memory region 0x100000000-0x24f600000
> Got VBE info in multiboot. Current video mode is 16767 ACPI: RSDP
> paddr=0xfe020 ACPI: RSDP vaddr=0xfe020 ACPI: RSDT paddr=0xaafda0c4 ACPI:
> RSDT vaddr=0xaafda0c4 Kernel loaded to: start=0x100000 end=0xc17000
> size=0xb17000 entry=0x101269 ACPI: RSDT paddr=0xaafda0c4 ACPI: RSDT
> vaddr=0xaafda0c4 ACPI: FADT paddr=0xaaffb000 ACPI: FADT vaddr=0xaaffb000
> ACPI: FADT flags=0x3c6a5 ACPI: DMAR paddr=0xaafde000 ACPI: DMAR
> vaddr=0xaafde000 ACPI: IOMMU host address width: 36 ACPI: registering
> RMRR entry for region for device: bus=0x0 dev=0x1d fun=0x0 ACPI:
> registering RMRR entry for region for device: bus=0x0 dev=0x1a fun=0x0
> ACPI: registering RMRR entry for region for device: bus=0x0 dev=0x14
> fun=0x0 ACPI: registering RMRR entry for region for device: bus=0x0
> dev=0x2 fun=0x0 ACPI: 2 IOMMUs detected ACPI: MADT paddr=0xaaff9000 ACPI:
> MADT vaddr=0xaaff9000 ACPI: MADT apic_addr=0xfee00000 ACPI: MADT flags=0x1
> ACPI: MADT_APIC apic_id=0x0 ACPI: MADT_APIC apic_id=0x1 ACPI: MADT_APIC
> apic_id=0x2 ACPI: Not recording this APIC, only support 2 ACPI: MADT_APIC
> apic_id=0x3 ACPI: Not recording this APIC, only support 2 ACPI: MADT_IOAPIC
> ioapic_id=0 ioapic_addr=0xfec00000 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: 2
> CPU(s) detected ELF-loading userland images from boot modules:
> size=0x41fc000 v_entry=0x409000 v_start=0x400000 v_end=0x45fc000
> p_start=0x3b39000 p_end=0x7d35000 Moving loaded userland images to final
> location: from=0x3b39000 to=0xc17000 size=0x41fc000 Starting node #0 with
> APIC ID 0 Mapping kernel window is done ========== KERNEL EXCEPTION
> ========== Vector: 0xd ErrCode: 0x0 IP: 0xffffffff80115c04 SP:
> 0xffffffff80a0bfa0 FLAGS: 0x10046 CR0: 0x80010013 CR2: 0x0
> (page-fault address) CR3: 0xa12000 (page-directory physical address)
> CR4: 0x110668 Stack Dump: *0xffffffff80a0bfa0 == 0x0
> *0xffffffff80a0bfa8 == 0x0 *0xffffffff80a0bfb0 == 0x3b39000
> *0xffffffff80a0bfb8 == 0xffffffff80116b80 *0xffffffff80a0bfc0 == 0x0
> *0xffffffff80a0bfc8 == 0x22a8 *0xffffffff80a0bfd0 == 0x0
> *0xffffffff80a0bfd8 == 0x0 *0xffffffff80a0bfe0 == 0xffffffff80000000
> *0xffffffff80a0bfe8 == 0x7e000 *0xffffffff80a0bff0 == 0xaa24c70c
> *0xffffffff80a0bff8 == 0x1f *0xffffffff80a0c000 == 0xfffffffff000ba86
> *0xffffffff80a0c008 == 0xffffffff8081f0c0 *0xffffffff80a0c010 == 0x0
> *0xffffffff80a0c018 == 0x0 *0xffffffff80a0c020 == 0x0 *0xffffffff80a0c028
> == 0x0 *0xffffffff80a0c030 == 0x0 *0xffffffff80a0c038 == 0x0 Halting...
> halting... Kernel entry via Interrupt, irq 0 *
>
> Any pointers at what is the cause of error here? The machien runs normally
> with vanilla CentOS so I don't think it is a hardware issue. Also, I am
> assuming the CMA34CR is identical to the one you have on your side (at
> least checking the lspci output against the camkes description the memory
> regions etc seem to match).
>
> Thanks in advance.
> M
>
[View Less]
Hi!
What is this error and how might I go about tracking down the cause?
<<seL4(CPU 0) [decodeUntypedInvocation/167 T0xe0792100 "csm-threads" @3a98c]: Untyped Retype: Slot #15 in destination window non-empty.>>
_refill_pool@split.c:177 Failed to retype untyped, error 8
vka_alloc_object_at_maybe_dev@object.h:59 Failed to allocate object of size 4096, error 1
alloc_and_map@bootstrap.c:103 Failed to allocate bootstrap frame, error: 1
What I've done, is taken over the usual sel4test …
[View More]process and turned it into a little process that starts a few others.
This error occurs at near the beginning of the main process, after it has allocated some untyped space for a secondary process,
and just started it running. There is tons of memory available everywhere, and I do not understand why this is failing.... clues?
Thanks!
Richard H. Clark
________________________________
This message and all attachments are PRIVATE, and contain information that is PROPRIETARY to Intelligent Automation, Inc. You are not authorized to transmit or otherwise disclose this message or any attachments to any third party whatsoever without the express written consent of Intelligent Automation, Inc. If you received this message in error or you are not willing to view this message or any attachments on a confidential basis, please immediately delete this email and any attachments and notify Intelligent Automation, Inc.
[View Less]
Hi all,
I have a CM34CR CPU module <https://wiki.sel4.systems/CMA34DBMC> and I am
trying to run the related camkes app on it.
I choose the centos app:
https://github.com/seL4/camkes-vm/blob/master/apps/vm/cma34cr_centos.camkes
I am using default camkes vm manifest from
https://github.com/seL4/camkes-vm-manifest.
Compile with:
*make clean*
*make cma34cr_centos_defcondig*
*make silentoldconfig*
*make*
And then I create a bootable USB following instructions here
<https://wiki.sel4.…
[View More]systems/Hardware/IA32>.
Then after I load the kernel and capdl image, I get the following output on
serial:
*Boot config: parsing cmdline 'sel4kernel'Boot config: console_port =
0x3f8Boot config: debug_port = 0x3f8Boot config: disable_iommu =
falseDetected 1 boot module(s): module #0: start=0xd34000 end=0x3b387e8
size=0x2e047e8 name='rootserver'Parsing GRUB physical memory map
Physical Memory Region from 0 size 9d400 type 1 Physical Memory Region
from 9d400 size 2c00 type 2 Physical Memory Region from e0000 size 20000
type 2 Physical Memory Region from 100000 size 1ff00000 type 1Adding
physical memory region 0x100000-0x20000000 Physical Memory Region from
20000000 size 200000 type 2 Physical Memory Region from 20200000 size
1fe04000 type 1Adding physical memory region 0x20200000-0x40004000
Physical Memory Region from 40004000 size 1000 type 2 Physical Memory
Region from 40005000 size 64bab000 type 1Adding physical memory region
0x40005000-0xa4bb0000 Physical Memory Region from a4bb0000 size 1400000
type 2 Physical Memory Region from a5fb0000 size 4a0f000 type 1Adding
physical memory region 0xa5fb0000-0xaa9bf000 Physical Memory Region from
aa9bf000 size 500000 type 2 Physical Memory Region from aaebf000 size
100000 type 4 Physical Memory Region from aafbf000 size 40000 type 3
Physical Memory Region from aafff000 size 1000 type 1Adding physical memory
region 0xaafff000-0xab000000 Physical Memory Region from ab000000 size
4a00000 type 2 Physical Memory Region from f0000000 size 4000000 type
2 Physical Memory Region from feb00000 size 4000 type 2 Physical
Memory Region from fec00000 size 1000 type 2 Physical Memory Region from
fed10000 size a000 type 2 Physical Memory Region from fed1c000 size 4000
type 2 Physical Memory Region from fee00000 size 1000 type 2 Physical
Memory Region from ffc00000 size 400000 type 2 Physical Memory Region
from 100000000 size 14f600000 type 1Adding physical memory region
0x100000000-0x24f600000Got VBE info in multiboot. Current video mode is
16767ACPI: RSDP paddr=0xfe020ACPI: RSDP vaddr=0xfe020ACPI: RSDT
paddr=0xaafda0c4ACPI: RSDT vaddr=0xaafda0c4Kernel loaded to: start=0x100000
end=0xc17000 size=0xb17000 entry=0x101269ACPI: RSDT paddr=0xaafda0c4ACPI:
RSDT vaddr=0xaafda0c4ACPI: FADT paddr=0xaaffb000ACPI: FADT
vaddr=0xaaffb000ACPI: FADT flags=0x3c6a5ACPI: DMAR paddr=0xaafde000ACPI:
DMAR vaddr=0xaafde000ACPI: IOMMU host address width: 36 ACPI:
registering RMRR entry for region for device: bus=0x0 dev=0x1d fun=0x0
ACPI: registering RMRR entry for region for device: bus=0x0 dev=0x1a
fun=0x0 ACPI: registering RMRR entry for region for device: bus=0x0
dev=0x14 fun=0x0 ACPI: registering RMRR entry for region for device:
bus=0x0 dev=0x2 fun=0x0ACPI: 2 IOMMUs detectedACPI: MADT
paddr=0xaaff9000ACPI: MADT vaddr=0xaaff9000ACPI: MADT
apic_addr=0xfee00000ACPI: MADT flags=0x1ACPI: MADT_APIC apic_id=0x0ACPI:
MADT_APIC apic_id=0x1ACPI: MADT_APIC apic_id=0x2ACPI: Not recording this
APIC, only support 2ACPI: MADT_APIC apic_id=0x3ACPI: Not recording this
APIC, only support 2ACPI: MADT_IOAPIC ioapic_id=0 ioapic_addr=0xfec00000
gsib=0ACPI: MADT_ISO bus=0 source=0 gsi=2 flags=0x0ACPI: MADT_ISO bus=0
source=9 gsi=9 flags=0xdACPI: 2 CPU(s) detectedELF-loading userland images
from boot modules:size=0x41fc000 v_entry=0x409000 v_start=0x400000
v_end=0x45fc000 p_start=0x3b39000 p_end=0x7d35000Moving loaded userland
images to final location: from=0x3b39000 to=0xc17000 size=0x41fc000Starting
node #0 with APIC ID 0Mapping kernel window is done========== KERNEL
EXCEPTION ==========Vector: 0xdErrCode: 0x0IP:
0xffffffff80115c04SP: 0xffffffff80a0bfa0FLAGS: 0x10046CR0:
0x80010013CR2: 0x0 (page-fault address)CR3: 0xa12000
(page-directory physical address)CR4: 0x110668Stack
Dump:*0xffffffff80a0bfa0 == 0x0*0xffffffff80a0bfa8 ==
0x0*0xffffffff80a0bfb0 == 0x3b39000*0xffffffff80a0bfb8 ==
0xffffffff80116b80*0xffffffff80a0bfc0 == 0x0*0xffffffff80a0bfc8 ==
0x22a8*0xffffffff80a0bfd0 == 0x0*0xffffffff80a0bfd8 ==
0x0*0xffffffff80a0bfe0 == 0xffffffff80000000*0xffffffff80a0bfe8 ==
0x7e000*0xffffffff80a0bff0 == 0xaa24c70c*0xffffffff80a0bff8 ==
0x1f*0xffffffff80a0c000 == 0xfffffffff000ba86*0xffffffff80a0c008 ==
0xffffffff8081f0c0*0xffffffff80a0c010 == 0x0*0xffffffff80a0c018 ==
0x0*0xffffffff80a0c020 == 0x0*0xffffffff80a0c028 == 0x0*0xffffffff80a0c030
== 0x0*0xffffffff80a0c038 == 0x0Halting...halting...Kernel entry via
Interrupt, irq 0*
Any pointers at what is the cause of error here? The machien runs normally
with vanilla CentOS so I don't think it is a hardware issue. Also, I am
assuming the CMA34CR is identical to the one you have on your side (at
least checking the lspci output against the camkes description the memory
regions etc seem to match).
Thanks in advance.
M
[View Less]