- Devel - lists.sel4.systems

some confuse about Camkes and AOS sel4
by yadong.li 25 Mar '21

25 Mar '21

hi: I am try to understand the designing philosophy of seL4 kernel base on CAmkES, I didn't find a global memory server in this system But the AOS may be have memory server,even though I am not familiar with AOS now, I have three question: 1. what is the purpose of the existing of CAmkES and AOS meanwhile ? (static and dynamic ) 2. which one (AOS or CAmkES) will be vigorously developed by the seL4 community and fund later. 3. Is a good idea to provide global memory server in CAmkES system? I found usually CAmkES alloc untyped pool Statically for componet in .camkes file. Thank you very much

1 0

Pull requests now directly merged on GitHub
by Gerwin Klein 25 Mar '21

25 Mar '21

The next step in the making contributions easier is now complete: Pull requests for repositories in the seL4 GitHub org can now be merged on GitHub directly, without the loop thought Data61's CI infrastructure. Hopefully this will make merging pull requests faster and less painful. The exception for now are repositories with manifests (such as sel4test-manifest), because parts of these manifests are generated automatically. We're working on moving these as well. The testing and verification regime is the same as before, including extensive hardware tests and proofs, but the results and logs should now be visible directly on GitHub. Happy merging :-) Cheers, Gerwin

1 0

AMD-V Support
by ndaughety13＠gmail.com 23 Mar '21

23 Mar '21

I found "Your host machine has to have a CPU that supports Vt-x virtualization (for Intel CPUs), or AMD-V (for AMD CPUs, but that wasn’t tested)" at https://docs.sel4.systems/projects/camkes-vm/. In context, my understanding is that seL4 should work with AMD-V but it doesn't work on my AMD system. I also do not see any mention of it anywhere else -- not even in the source (could not find amd-v counter part to vtx in grep search of source). Noting that it has not been tested, could this be a build configuration problem or has support not actually been implemented? ...or am I missing something?

1 0

Introduction Ben Fiedler
by Ben Fiedler 19 Mar '21

19 Mar '21

Hello seL4-devs, I'm currently working on a CS MSc thesis at ETH Zurich supervised by David Cock, working on verified low-level system components using seL4 and CAmkES, which I'll be doing until August. I haven't worked with seL4 or CAmkES before, but I have some rudimentary Isabelle/ITP experience from my BSc thesis (mainly typing sledgehammer ;) ). During the course of my thesis I will probably have some questions which I'll post here, and hopefully I can contribute to improving the tooling around seL4+CAmkES verification. Nice to meet you all! Cheers, Ben

2 1

Re: Creating process from not root process
by Seo Yeon Hwang 05 Mar '21

05 Mar '21

Hello, Sorry for bringing this old post up, but could anyone let me know the answer of this post? I’m quite new to seL4 and I’ve been following tutorials and modifying it, and I have the exact same question as this post. Basically, how can I create a process from non-root process? Thanks a lot! Seoyeon Hwang

2 1

Picotcp and Lwip issues on OdroidC2
by ogosinkem＠gmail.com 03 Mar '21

03 Mar '21

Hi, I'm currently trying to include either the picotcp or lwip library into an application in order to connect to or show a connection to a network. As such I have added some lines to some of my files. CMakeLists.txt: DeclareCAmkESComponent(Client SOURCES components/Client/src/main.c LIBS lwip picotcp) hello_world.camkes: component Client{ uses Ethdriver eth_drv; has mutex lwip; control;} When trying to build I get a long error message which boils down to: /usr/lib/gcc-cross/aarch64-linux-gnu/7/../../../../aarch64-linux-gnu/bin/ld: cannot find -llwip /usr/lib/gcc-cross/aarch64-linux-gnu/7/../../../../aarch64-linux-gnu/bin/ld: cannot find -lpicotcp collect2: error: ld returned 1 exit status [258/316] Building C object CMakeFiles/ethdriver.instance.bin.dir/ethdriver/seL4SingleThreadedComponent.template.c.obj ninja: build stopped: subcommand failed. How to I go about solving this issue? Thanks, Nkem

1 0

Ethernet device module for odroidc2
by ogosinkem＠gmail.com 24 Feb '21

24 Feb '21

I have been trying to use the ethernet driver for the UNSW Asdvanced Operating Systems course but I still get these messages: find_compatible_driver_module@io.c:434 No suitable driver was found for path /soc/ethernet@c9410000, ignoring server_init@ethdriver.c:382 Unable to find an ethernet device I thought that I had to copy the driver to the utils lib folder and provide a preprocessor macro as someone else had suggested but I may be missing a few other things. Best, Nkem

3 6

Sporadic Server Implementation Details
by msudvarg＠wustl.edu 11 Feb '21

11 Feb '21

Hi all, I hope this is the right forum to be posting this question. I've reached out to Anna Lyons, the first author on the EuroSys 2018 "Scheduling Context Capabilities" paper (https://ts.data61.csiro.au/publications/csiro_full_text//Lyons_MAH_18.pdf) but I do not know if her listed email address is still active. I want to ask for more clarification on the sporadic server implementation in seL4. My interpretation of how the Lyons et al. paper describes the implementation is different than my understanding of the sporadic server definition as described by Sprunt et al. in 1989 (https://link.springer.com/article/10.1007/BF02341920) However, looking at the seL4 kernel source code, it seems that the actual implementation follows very closely with the improved POSIX sporadic server mechanism described by Stanovic et al. in 2010 (https://www.cs.fsu.edu/~awang/papers/rtas2010.pdf) In particular, the Lyons et al. paper states that when a thread is preempted at time t, a replenishment is scheduled for time t + T. My understanding of the sporadic server is that if a thread becomes active at time t, the replenishment is scheduled for time t + T. In other words, the replenishment is scheduled one period from when the thread begins execution, not when it ends execution. Further, a thread becomes active when it becomes unblocked (i.e. returns from a blocking system call, or is activated by the release of an aperiodic task that it handles). In other words, a thread that is preempted by a higher-priority thread is not considered to have become inactive, according to the sporadic server definition. This seems to be the case in both the Sprunt and Stanovic papers. I think the distinction is significant in a system (like seL4) where only a finite number of replenishments are tracked. Determining what number of replenishments each thread’s server must track is much easier if only voluntary yielding of the processor, and not preemption by higher-priority threads, triggers a replenishment. Can somebody explain to me in more detail how the sporadic server has been implemented in seL4? Like I said, from my reading of the kernel source, it seems that it has been implemented according to the improved POSIX sporadic server detailed by Stanovic, but I’m not certain that I’ve identified all conditions that cause a replenishment to be scheduled.

3 2

Use sel4 and mmc for storage but sdhc driver wait for SDHC_PRES_STATE_CIHB | SDHC_PRES_STATE_CDIHB
by MOHAMAD REZA SHAFIEI 10 Feb '21

10 Feb '21

hi there ... i'm working on mmc in sel4 for storage memory. i port your code for i.mx7 (modify registers and all need for that). so when i init mmc with calling mmc_init, sdhc driver wait at sdhc.c@249 and in this line: while (readl(host->base + PRES_STATE) & (SDHC_PRES_STATE_CIHB | SDHC_PRES_STATE_CDIHB)); indeed sdhc driver send function (sdhc_next_cmd(..)) send first command in mmc_reset (): which is : struct mmc_cmd cmd = {.data = NULL}; cmd.index = MMC_GO_IDLE_STATE; cmd.arg = 0; cmd.rsp_type = MMC_RSP_TYPE_NONE; printf("2-1\n"); host_send_command(card, &cmd, NULL, NULL); and status= 65 returned whicm means this command sent completely. so when program continue to send another command (still in mmc_reset) which is : /* TODO: review this command. */ struct mmc_cmd cmd2 = {.data = NULL}; ps_mdelay(10); cmd2.index = MMC_SEND_EXT_CSD; cmd2.arg = 0x1AA; cmd2.rsp_type = MMC_RSP_TYPE_R1; printf("2-2\n"); host_send_command(card, &cmd2, NULL, NULL); status which returned with sdhc send command in sdhc driver is 0. but this worked too. and when program execution continue to call mmc_voltage_validation(..) sdhc driver wait in while (readl(host->base + PRES_STATE) & (SDHC_PRES_STATE_CIHB | SDHC_PRES_STATE_CDIHB)); ... I don't have any idea why this happened .. can you help me? I didn't modify any code in sdhc.c or mmc.c ... my app for using mmc is here: #include <autoconf.h> #include <camkes.h> #include <camkes/io.h> #include <camkes/sync.h> #include <stdio.h> #include <utils/util.h> #include "string.h" //sdio test #include <sdhc/mmc.h> #include <sdhc/plat/sdio.h> #include <sdhc/sdio.h> #define max(x, y) (((x) >= (y)) ? (x) : (y)) //build config // #define TEST_FILESYSTEM 0 #ifdef CONFIG_64BIT #define BITS_PER_LONG 64 #else #define BITS_PER_LONG 32 #endif /* CONFIG_64BIT */ #define IMX7_GPIO1_BASE_ADDR ((uint32_t)NULL) #define IMX7_GPIO4_BASE_ADDR ((uint32_t)NULL) #define IMX7_SPI_BASE_ADDR ((uint32_t)NULL) #define IMX7_CTL_MUX_BASE_ADDR ((uint32_t)NULL) /** * we have two keyboard driver () */ bool STDKBD = true; #define IMX7_CTL_MUX_GPIO1_09 (0x18) seL4_CPtr timer_notification(void); seL4_CPtr notification; static void delay(uint64_t ms) { seL4_Word badge; /* test a relative timeout */ uint64_t t1 = timer_time(); // printf("Cur time: %"PRIu64"\n", t1); timer_oneshot_relative(0, ms * NS_IN_MS); seL4_Wait(notification, &badge); // printf("Badge: %x\n", badge); t1 = timer_time(); // printf("Cur time: %"PRIu64"\n", t1); } /* * Required for the camkes_sys_clock_gettime() in sys_clock.c of libsel4camkes. */ int clk_get_time(void) { uint64_t time_in_ms = timer_time() / NS_IN_MS; return (time_in_ms & 0xFFFFFFFF); } static int count = 0; ps_io_ops_t io_ops = {0}; struct netif* net_if; mmc_card_t mmc_card = 0; sdio_host_dev_t sdio_host_dev; int mmc_found = 0; void mmc_irq_handle(ps_irq_t* irq) { printf("mmc irq handle .... \n"); if(!mmc_found){ // printf("mmc not found yet :)\n"); // mmc_init handle this self // sdio_host_dev.handle_irq(&sdio_host_dev,irq->irq.number); mmc_irq_acknowledge(irq); return ; } // sdio_host.handle_irq(&sdio_host, irq); mmc_handle_irq(mmc_card,irq->irq.number); mmc_irq_acknowledge(irq); } int run(void) { notification = timer_notification(); int err = camkes_io_ops(&io_ops); if (err != 0) { ZF_LOGF("Can not init ops : %d\n", err); }; printf("initialize sdhc1 ...\n"); err = sdio_init(SDHC1, &io_ops, &sdio_host_dev); // while card not present check while(sdio_host_dev.reset(&sdio_host_dev) == -1){ delay(1000); } printf("before mmc_init\n"); mmc_init(&sdio_host_dev, &io_ops, &mmc_card); mmc_found = 1; printf("after mmc_init\n"); if (!err) { printf("SDHC1 inited successfully.\n"); // sdhc_ls(); } else { printf("SDHC1 initizatino failed!: %d", err); } // sdio_host_dev.reset(&sdio_host_dev); // mmc_init(&sdio_host_dev, &io_ops, mmc_card); // sdio_host_dev.handle_irq =mmc_handle_irq_func; while (true) { printf(".\n"); delay(1000); } return 0; } best regards.. shafie -- This email was Anti Virus checked by Security Gateway.

1 0

Public seL4 TSC meeting on Fri, 12 Feb
by Gerwin Klein 08 Feb '21

08 Feb '21

The Technical Steering Committee (TSC) of the seL4 Foundation will hold its next public meting on: Fri 12 Feb 2021 15:30-17:00 Sydney time (5:30am in Berlin, 8:30pm in San Francisco). This is the continuation of the meeting last week. The meeting is by Zoom, and you can register here: https://unsw.zoom.us/meeting/register/tZcqf--prz8jGNdE-zpwZXIBsbdYlN3fQn1Y Anyone interested can join the meeting and listen to the discussion and request to speak, which will be granted if time permits. Only TSC members can vote. The seL4 code of conduct applies to the meeting [1]. The agenda for the meeting so far is: Discussion points - when/how should Committer/Admin role change for people who have left D61 and had the role based on org membership - endorsement process for training and products Vote on: - Platform Owner proposal Discuss, potentially vote on RFC proposals: - https://sel4.atlassian.net/browse/RFC-6 - https://sel4.atlassian.net/browse/RFC-5 - https://sel4.atlassian.net/browse/RFC-4 If there are other items that I missed or you think should be on the agenda, please let me know. If we can't get to an item this time, we can still schedule another meeting. Cheers, Gerwin (TSC chair) [1]: https://docs.sel4.systems/processes/conduct.htmld

1 0