- Devel - lists.sel4.systems

Re: [seL4] RISC-V port
by Jesse Millwood 11 Nov '19

11 Nov '19

I do believe you can use SiFive's toolchain: https://static.dev.sifive.com/dev-tools/riscv64-unknown-elf-gcc-8.3.0-2019.… Then you don't have to compile it. There is also Data61's Docker https://github.com/SEL4PROJ/seL4-CAmkES-L4v-dockerfiles If you look at the make file there are some targets for including the RISC-V toolchain. Jesse On 2019-11-11 1:58 a.m., Zhuang, Siwei (Data61, Kensington NSW) wrote: > Hi Jacob, > > You need to enable multilib when building "riscv-gnu-toolchain". > > ./configure --prefix=/path-to-install-toolchain --enable-multilib > then > make or make linux > > Running seL4 no longer requires RISC-V tools. In case you want to use Spike, > I'd suggest building the riscv-isa-sim separately to get the latest code. > > Regards, > Siwei > > On Sun, 2019-11-10 at 15:50 -0800, Jacob Yu wrote: >> Hi >> >> I am trying to build "seL4 tests" for "Spike" platform (the RISC-V >> simulator from UC Berkeley) on Ubuntu 18.04.3 LTS, a 64-bit system. >> >> First of all, I was able to build RISC-V tools with "build.sh" after >> manually installing "riscv-gnu-toolchain" from GitHub as well as additional >> python modules (future, ply, protobuf). I then kicked of "../init-build.sh >> -DPLATFORM=spike -DRISCV64=TRUE -DSIMULATION=1" from local build directory. >> >> After that, however, "ninja" command complained about "undefined reference >> to `__nedf2'". I understand there is no FPU support in "Spike" platform so >> a need for "soft-float" module. Where should I specify "-lsoft-fp"? >> >> Any suggestions? >> >> Thanks, >> >> >> Jacob >> _______________________________________________ >> Devel mailing list >> Devel(a)sel4.systems >> https://sel4.systems/lists/listinfo/devel > _______________________________________________ > Devel mailing list > Devel(a)sel4.systems > https://sel4.systems/lists/listinfo/devel

1 0

Rust ports on Genode/seL4
by guo minskey 11 Nov '19

11 Nov '19

Hi, guys, I am trying to build genode/sel4 on x86_64 platform and expect to get a GUI working. And so I enable this option in my build.conf : REPOSITORIES += $(GENODE_DIR)/repos/libports. Seems that rust support is broken (because rustc version ??). Which version of rustc should I use to build rust ports on genode ? Or how can I disable rust ports in build.conf configuration or somewhere else ? thanks, -Minskey

3 3

a letter for seeking help about sel4
by 李庚 08 Nov '19

08 Nov '19

Dear Sir or Madam, Very Sorry to brother you. We have get into trouble after compiling sel4 following the https://docs.sel4.systems/Docker.html,may I seek some advice from you? First,I attmpt to follow the https://docs.sel4.systems/Hardware/VMware/,however,error "Failed to allocate object of size xxxx" ara discovered in serial_output.txt . Second,we wanna to make a sel4 startup disk for x86_64,is there any useful Document ? Sorry again for this sudden interruption and I would be very grateful if receive your reply. Yours Sinerely, Andrew

2 1

Building seL4test x86_64 on Debian with the Docker image
by Jacob Yu 05 Nov '19

05 Nov '19

Hi I am building "seL4test" using the Docker image on Ubuntu 18.04.3 LTS, a 64-bit system. After entering "../init-build.sh -DPLATFORM=x86_64 -DSIMULATION=TRUE" in a build directory within Docker it complained "Could NOT find NANOPB (missing: PROTOBUF_PROTOC_EXECUTABLE)". I wonder should I manually download and install protocol buffer compiler, protoc? Please advise. Thank for your help. Jacob =============================================== loading initial cache file /host/projects/sel4test/settings.cmake correct_platform_strings: Attempting to correct PLATFORM: x86_64 to new valid KernelPlatform: pc99 KernelSel4Arch: x86_64 -- Found seL4: /host/kernel -- The C compiler identification is GNU 6.5.0 -- The CXX compiler identification is GNU 6.5.0 -- The ASM compiler identification is GNU -- Found assembler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: /usr/bin/g++ -- Check for working CXX compiler: /usr/bin/g++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Found elfloader-tool: /host/tools/seL4/elfloader-tool -- Found musllibc: /host/projects/musllibc -- Found util_libs: /host/projects/util_libs -- Found seL4_libs: /host/projects/seL4_libs -- Found sel4_projects_libs: /host/projects/sel4_projects_libs -- Found sel4runtime: /host/projects/sel4runtime -- Performing Test compiler_arch_test -- Performing Test compiler_arch_test - Success -- Found PythonInterp: /usr/bin/python (found version "2.7.15") -- Could NOT find NANOPB (missing: PROTOBUF_PROTOC_EXECUTABLE) -- CPIO test cpio_reproducible_flag PASSED -- Configuring done -- Generating done -- Build files have been written to: /host/build-x86

2 2

Re: [seL4] Devel Digest, Vol 65, Issue 24
by Mcleod, Kent (Data61, Kensington NSW) 04 Nov '19

04 Nov '19

> abdi@abdi-HP-P-PC:~/sel4-tutorials-manifest$ ./init --tut hello-world > loading initial cache file ../settings.cmake > CMake Error: Error: generator : Ninja > Does not match the generator used previously: Unix Makefiles > Either remove the CMakeCache.txt file and CMakeFiles directory or choose a different binary directory. These errors indicate that CMake already believes a project has been created in the target directory and that this project was a Makefile based project. Is there any CMakeCache.txt files located anywhere in the project structure that may be causing CMake to get confused? Otherwise you could reinitialise the tutorial project and try initialising hello-world again and that would also fix your problem.

1 0

Re: [seL4] Devel Digest, Vol 65, Issue 24
by abdi mahmud haji 31 Oct '19

31 Oct '19

i am working on sel4-tutorials for the first time .i setup my machine accordingly and then when i trying to generate the tutorials like this "./init --tut hello-world" i keep getting an error message and dont know what to do or how to fix it . the error was like bellowing =================================================== abdi@abdi-HP-P-PC:~/sel4-tutorials-manifest$ ./init --tut hello-world loading initial cache file ../settings.cmake CMake Error: Error: generator : Ninja Does not match the generator used previously: Unix Makefiles Either remove the CMakeCache.txt file and CMakeFiles directory or choose a different binary directory. Traceback (most recent call last): File "./init", line 96, in <module> File "./init", line 85, in main File "/home/abdi/sel4-tutorials-manifest/projects/sel4-tutorials/common.py", line 107, in init_directories return _init_build_directory(config, initialised, build_directory, tute_directory, output, config_dict=config_dict) File "/home/abdi/sel4-tutorials-manifest/projects/sel4-tutorials/common.py", line 75, in _init_build_directory return sh.cmake(args + ['..'], _cwd=directory, _out=output, _err=output) File "/home/abdi/.local/lib/python3.6/site-packages/sh.py", line 1427, in __call__ return RunningCommand(cmd, call_args, stdin, stdout, stderr) File "/home/abdi/.local/lib/python3.6/site-packages/sh.py", line 774, in __init__ self.wait() File "/home/abdi/.local/lib/python3.6/site-packages/sh.py", line 792, in wait self.handle_command_exit_code(exit_code) File "/home/abdi/.local/lib/python3.6/site-packages/sh.py", line 815, in handle_command_exit_code raise exc sh.ErrorReturnCode_1: RAN: /home/abdi/.local/bin/cmake -DCMAKE_TOOLCHAIN_FILE=../kernel/gcc.cmake -G Ninja -DTUT_BOARD=pc -DTUT_ARCH=x86_64 -DTUTORIAL_DIR=hello-world82varrcf -C ../settings.cmake .. STDOUT: STDERR: ====================================================================== is there someone who suggests what i should do please. thanks On Sun, Oct 27, 2019 at 4:00 AM <devel-request(a)sel4.systems> wrote: > Send Devel mailing list submissions to > devel(a)sel4.systems > > To subscribe or unsubscribe via the World Wide Web, visit > https://sel4.systems/lists/listinfo/devel > or, via email, send a message with subject or body 'help' to > devel-request(a)sel4.systems > > You can reach the person managing the list at > devel-owner(a)sel4.systems > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Devel digest..." > > > Today's Topics: > > 1. Re: releasing confidentiality > (Heiser, Gernot (Data61, Kensington NSW)) > 2. Fwd: port sel4 to RK3308(quad cortex-a35) (Yun Zhou) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 26 Oct 2019 03:07:23 +0000 > From: "Heiser, Gernot (Data61, Kensington NSW)" > <Gernot.Heiser(a)data61.csiro.au> > To: "devel(a)sel4.systems" <devel(a)sel4.systems> > Subject: Re: [seL4] releasing confidentiality > Message-ID: <5FEA58C5-9011-49B7-9790-28B4B54849EF(a)data61.csiro.au> > Content-Type: text/plain; charset="utf-8" > > On 26 Oct 2019, at 08:00, Michael Neises <neisesmichael(a)gmail.com> wrote: > > > > Hi, > > > > I know that seL4 provides confidentiality, which is described as a > property that "means that data cannot be read without permission." Given > this wording, I wonder if it is not possible to revoke those permissions in > certain cases. In particular, I would like for one camkes component to be > able to perform runtime measurements, such as heap analysis, on another > component. Or even better, I would like for a component to be able to > perform runtime measurements on a program running within the camkes linux > vm. Is such a feat possible? > > Hi Michael > > seL4’s confidentiality (and other security) enforcement means that the > kernel guarantees that you can only access objects to which you have been > given explicit permission (in the form of a capability). How those > permissions are allocated is a matter of policy, the kernel doesn’t care, > it only enforces. > > In particular, it is totally possible in seL4 to give one component access > to another component’s address space, that’s for the user-level policy > framework to decide. > > Whether the present CAmkES framework supports this is a different > question, which I’ll leave to someone who’s more up to date with CAmkES > details. > > Gernot > > > ------------------------------ > > Message: 2 > Date: Sat, 26 Oct 2019 10:35:50 +0800 > From: Yun Zhou <shiny725829(a)gmail.com> > To: devel(a)sel4.systems > Subject: [seL4] Fwd: port sel4 to RK3308(quad cortex-a35) > Message-ID: > <CAHNKqcxb7ws3MD=- > nwJka6HKEcA4hXZipJv0vdsStetJjxP-yg(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > ---------- Forwarded message --------- > 发件人： Yun Zhou <shiny725829(a)gmail.com> > Date: 2019年10月25日周五下午9:52 > Subject: port sel4 to RK3308(quad cortex-a35) > To: <devel-owner(a)sel4.systems> > > > Dear sel4 Experts > How are you > I found some information about sel4, and sel4 is great microkernel OS, i > want port sel4 to RK3308(quad cortex-a35, GICv2) for real time audio signal > processing. Form the Tutorials I found sel4 just support cortex-a53, I > would like to ask does sel4 support cortex-a35 SMP mode. and because our > application is real time audio processing so system delay must lower than > 3ms and hard real-time determinism. > Will sel4 support real-time signal processing? > Looking forward to your reply > > Thanks &Kind regards > Yun >

1 0

The seL4 Foundation is coming!
by Heiser, Gernot (Data61, Kensington NSW) 25 Oct '19

25 Oct '19

Re-post from announce(a)sel4.systems<mailto:announce@sel4.systems> regarding the seL4 Foundation. We’ll start recruiting members soon. Gernot Begin forwarded message: From: Announcements about seL4 -- low volume list <announce(a)sel4.systems<mailto:announce@sel4.systems>> Subject: [seL4 Announce] The seL4 Foundation is coming! Date: 25 October 2019 at 17:09:30 AEDT To: "announce(a)sel4.systems<mailto:announce@sel4.systems>" <announce(a)sel4.systems<mailto:announce@sel4.systems>> Reply-To: <announce(a)sel4.systems<mailto:announce@sel4.systems>> Dear seL4 community, With great excitement we announce that we are in the process of setting up an seL4 Foundation, similar to foundations for other open-source projects, such as Linux and RISC-V. This will form an open, transparent and neutral organisation tasked with growing the seL4 ecosystem. It will bring together developers of the seL4 kernel, developers of seL4-based components and frameworks, and those deploying seL4-based systems. Its focus will be on coordinating, directing and standardising development of the seL4 ecosystem in order to reduce barriers to adoption, raising funds for accelerating development, and ensuring clarity of verification claims. This was originally announced at the seL4 Summit in the US last month. I apologise for the delay in this posting (side-tracked with various issues). Gernot on behalf of the Trustworthy Systems team _______________________________________________ Announce mailing list Announce(a)sel4.systems<mailto:Announce@sel4.systems> https://sel4.systems/lists/listinfo/announce

1 0

Upcoming release planned
by Mcleod, Kent (Data61, Kensington NSW) 23 Oct '19

23 Oct '19

Hi all, I'm announcing that we are planning a new versioned release of seL4, capDL and CAmkES in about 3 weeks - around 11 November. We want to provide an opportunity for people to report issues or provide patches that can be fixed/incorporated for the versioned release. The last versioned release occurred almost 12 months ago and we plan on returning to a shorter release cycle of several weeks per cycle. Feel free to raise new issues across our GitHub repositories and we will also try to address any currently outstanding issues that have been neglected. Here is a highlight list of what changes are going to be in the upcoming versioned release: ## seL4 - Add GrantReply access right for endpoint capabilities. `seL4_Call` is permitted on endpoints with either the Grant or the GrantReply access rights. Capabilities can only be transferred in a reply message if receiver's endpoint capability has the Grant right. The GrantReply access right allows endpoints to be configured for two-way communication without also providing the right to transfer authority via capability transfer. - Merging of the mixed-criticality scheduling (MCS) branch into master. Previously the MCS branch only received versioned releases. Merging it into master under a build configuration (KernelIsMCS) makes it easier to keep up to date with changes to master and other tooling/libraries in-between versioned releases. Verification work is still on-going. - Continued development of the newly added RISC-V platform to support in-progress verification. - Auto-generation of Arm and RISC-V kernel platform definitions from a provided devicetree as well as support for passing a devicetree to the root task via the seL4_BootInfo structure. Interrupt controllers, timers and other devices required by the kernel can also be selected in the devicetree provided that the kernel already has a compatible driver. - Support for AArch64 hypervisors is in active development with initial support for Cortex-A53 and Cortex-A57 cores - De-duplicating kernel platform configurations and code in order to reduce the effort required to support additional platforms. - New platforms added: BeagleBone Blue, Hardkernel ODROID-C2, Freescale i.MX8M, i.MX8M Mini, Arm FVP (based on foundation-v8-gicv3.dts), QEMU ARM virt platform (with 3 CPUs: cortex-A15, cortex-A53 and cortex-A57) and possibly PINE64 ROCKPro64. - Implement RFC-3: Cross-platform thread-local storage (TLS) support. https://sel4.atlassian.net/browse/RFC-3. This provides a way for a thread to access or modify a thread-specific pointer without requiring a capability to itself. On architectures that don't provide unprivileged write access to this pointer a new syscall `seL4_SetTLSBase` is added that performs this operation. The kernel no longer reserves a register for holding a thread's IPC buffer and it is the thread's responsibility for managing this. `libsel4` declares a pointer to a thread's IPC buffer using a `__thread` keyword and a new user-level library `sel4runtime` can be used to provide a minimal supporting runtime. Additionally, the IPC buffer's userData field is no longer used for holding a pointer to the IPC buffer. - Better SMP Arm IRQ handling: Support is added for creating IRQ handler capabilities for core-local interrupts (PPIs) for each core and for also specifying a target core for global interrupts (SPIs) via the new invocation `IRQControl_GetTriggerCore`. - Merge ARCH_Page_Remap functionality into ARCH_Page_Map. Remap was used for updating the mapping attributes of a page without changing its virtual address. Now ARCH_Page_Map can be performed on an existing mapping to achieve the same result. The ARCH_Page_Remap invocation has been removed from all configurations. - Support for compiling the kernel with Clang. For a more complete list see the CHANGES file in the seL4 repository. ## CAmkES - Support for the new seL4 Endpoint GrantReply access right for CAmkES connector types. This allows multi-sender/single-receiver connectors such as `seL4RPCCall` that don't also provide the ability for arbitrary capability transfer from sender to receiver. Previously the `seL4RPC` connector was used instead of `seL4RPCCall` to create an Endpoint without a Grant right. This used a combination of `seL4_Send` and `seL4_Wait` to communicate without the ability for capability transfer, however this only supports a single sender and single receiver. - Better support for configuring components with a provided devicetree. This support includes adding a seL4DTBHardware connector that can be used instead of seL4HardwareMMIO and seL4HardwareInterrupt and can be used to extract IRQs and MMIO register information out of the devicetree node rather than specifying the info directly. This connector can also be used to access a devicetree within a component at for querying further device information. There is also a connector seL4VMDTBPassthrough that can be used for specifying devices to pass through to a `camkes-arm-vm` VM component. - CapDL Refinement framework. These are generated Isabelle proof scripts to prove that the generated capDL respects the isolation properties expected from its CAmkES system specification. Only the AARCH32 platform is supported. The generated capDL is a specification of seL4 objects and capabilities that will implement the CAmkES system specification. This specification is then given to a system initialiser to create the objects and capabilities and load the system. - Support for RISC-V systems. ## capDL capDL refers to the capability distribution language and tools contained in https://github.com/seL4/capdl. CAmkES uses these tools for generating a capDL specification and then uses the `capdl-loader-app` as it's seL4 root task for initialising the system. As we are in the process of developing additional loaders we are going to start providing versioned releases of the capDL set of tools. Changes since the last seL4 release: - Support for the new seL4 Endpoint GrantReply access rights in the CapDL spec. Endpoint capabilities in the capDL spec can now have Read, Write, Grant and GrantReply rights. - Static Untyped allocation of spec objects. This is support for performing offline pre-allocation of spec objects to the Untyped objects that are expected to be provided in the seL4_BootInfo by the kernel. Having a static allocation of spec objects to Untypeds allows for more simple loaders that do not have to perform resource allocation during initialisation. This feature is optional and a spec is still valid if objects aren't allocated from Untyped objects. - Support for loading RISC-V systems.

1 0

CAmkES languages
by Michael Neises 21 Oct '19

21 Oct '19

Hi, I have an application written in CakeML that I would like to include in a CAmkES component, but all the documentation I can find only uses C code. Is it possible to use a non-C language as source for a CAmkES component? If so, how can I accomplish this? Best, Michael Neises

2 1

Zynq UltraScale+ locks up after hours running
by Leonid Meyerovich 05 Oct '19

05 Oct '19

Hello, We are running seL4 microkernel on 4 cores Zynq UltraScale+ (zcu102 board). The implementation includes multiple processes, hypervisor and virtual machine running on dedicated core. After several hours running (it could be 2 or even 8 hours) the whole microkernel locks up. After some investigation I have found that no interrupts generated anymore - at least there is no interrupts coming to ISR. Inside ISR I have monitored PL2 Physical Timer Control register, which feeds a scheduler and didn't find any problems - it stays enabled and not masked. I will appreciate any idea/direction for approaching this problem. Thank you, Leonid ________________________________ 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.

5 24