- Devel - lists.sel4.systems

CAmkES ARM VM boot on TK1
by SHI, Yao 15 Feb '17

15 Feb '17

Hi, I am trying to run CAmkES ARM VM on TK1. I downloaded built the image using: repo init -u https://github.com/SEL4PROJ/camkes-arm-vm-manifest repo sync make tk1_vm_defconfig make And then ran the image on the hardware. It stopped after loading seL4 in nonsecure HYP mode, Tegra124 (Jetson TK1) # bootelf CACHE: Misaligned operation at range [90000000, 90007408] CACHE: Misaligned operation at range [90007408, 9134c900] CACHE: Misaligned operation at range [9134c900, 9134c908] CACHE: Misaligned operation at range [91350000, 91360820] ## 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 Then I tried to build a monitor mode image and got this, Tegra124 (Jetson TK1) # bootelf CACHE: Misaligned operation at range [90000000, 90007250] CACHE: Misaligned operation at range [90007250, 9134c710] CACHE: Misaligned operation at range [91350000, 91360820] ## Starting application at 0x90000000 ... ELF loader: monitor mode init done Copy monitor mode vector from 90001000 to a7f00000 size 50 ELF-loader started on CPU: ARM Ltd. Cortex-A15 r3p3 paddr=[90000000..9136081f] ELF-loading image 'kernel' paddr=[80000000..80031fff] vaddr=[e0000000..e0031fff] virt_entry=e0000000 ELF-loading image 'capdl-loader-experimental' paddr=[80032000..8155bfff] vaddr=[10000..1539fff] virt_entry=17580 Enabling MMU and paging Jumping to kernel-image entry point... abort() called. Anyone may tell me the possible problem? Thank you very much. Yao

4 8

Coretex A15 periodic timer interrupts
by Wladislav Wiebe 14 Feb '17

14 Feb '17

Hello, I wonder if the generic timer https://github.com/seL4/util_libs/blob/master/libplatsupport/src/arch/arm/g… can be extended by timer->periodic timer->handle_irq to be able to run the sel4 testsuite which requires timer IRQ's such as https://github.com/seL4/sel4test/blob/master/apps/sel4test-tests/src/tests/… Right now I am able to get timer_get_time(env->timer->timer); by using the generic timer, but I am missing the periodic time and the irq handler for the Coretex A15 generic timer implementation. Some ideas if there is some tricky way to get it running? Thanks in advance! - Wladislav Wiebe

1 0

Re: [seL4] SDHC drivers (cont.)
by Norrathep Rattanavipanon 13 Feb '17

13 Feb '17

Hi Siwei, So, I tried the code using Kingston microSDHC but it still couldnt read the card. However, the code works perfectly when loaded from the SD slot (with microSD to SD adapter), instead of the microSD slot. I also found that for some reasons, if mmc dev 1 is used in u-boot, the program wouldnt be able to read/write the micro-sd card. I'm kind of good for now but still curious about that. Do you have any idea what might have caused this? Best, Oak On Mon, Jan 23, 2017 at 11:07 AM, Norrathep Rattanavipanon <nrattana(a)uci.edu > wrote: > Thanks Siwei. I really appreciate your help. > Yeah so I tried your image with three different micro-sd cards and none of > them works (still stuck after printing the card's capacity). > I'll buy Kingston microsdhc class 4 and try on that, will let you know if > it works or not. > > Best, > Oak > > On Mon, Jan 23, 2017 at 12:03 AM, <Siwei.Zhuang(a)data61.csiro.au> wrote: > >> Hi Oak, >> >> >> Here is what exactly I did, >> >> >> $ mkdir sel4-sdcard >> >> $ cd sel4-sdcard >> >> $ repo init -u https://github.com/SEL4PROJ/sel4-tutorials-manifest.git >> -m sel4-tutorials-master.xml >> >> $ repo sync >> >> $ cd projects >> >> $ git clone https://github.com/SEL4PROJ/projects_libs.git >> >> $ cd ../libs >> >> $ ln -sf ../projects/projects_libs/libsdhcdrivers libsdhcdrivers >> >> $ ln -sf ../projects/seL4_libs/libsel4sync libsel4sync >> >> >> Then, I copied my sdcard app into sel4-sdcard/apps. >> >> The sdcard app directory has Kconfig, Kbuild, Makefile and src/main.c >> >> >> ------------ Kconfig ---------------- >> menuconfig APP_SDCARD >> bool "SD card" >> default y >> depends on HAVE_LIBC >> depends on LIB_SEL4_PLAT_SUPPORT >> depends on LIB_SEL4_VKA >> depends on LIB_SEL4_UTILS >> depends on LIB_UTILS >> depends on LIB_CPIO >> depends on LIB_SEL4 >> depends on LIB_ELF >> help >> SD card app. >> >> >> >> ------------ Kbuild ----------------- >> apps-$(CONFIG_APP_SDCARD) += sdcard >> >> sdcard: common libsel4utils libutils libsel4 libmuslc libsel4muslcsys \ >> libsel4vka libsel4allocman libsel4vspace libsel4simple >> libsel4simple-default \ >> libsel4platsupport libsel4platsupport libcpio libelf \ >> libsel4sync libsdhcdrivers libsel4debug >> >> ------------ Makefile --------------- >> # Targets >> TARGETS := sdcard.bin >> >> ENTRY_POINT := _sel4_start >> >> # Source files required to build the target >> CFILES := $(patsubst $(SOURCE_DIR)/%,%,$(wildcard >> $(SOURCE_DIR)/src/*.c)) >> ASMFILES := $(patsubst $(SOURCE_DIR)/%,%,$(wildcard >> $(SOURCE_DIR)/src/*.S)) >> OFILES := archive.o >> >> # Libraries required to build the target >> LIBS = c sel4 sel4muslcsys sel4vka sel4allocman \ >> platsupport sel4platsupport sel4vspace elf \ >> sel4utils sel4simple utils sel4simple-default cpio \ >> sel4sync sdhcdrivers sel4debug >> #CFLAGS += -Werror >> >> include $(SEL4_COMMON)/common.mk >> >> archive.o: ${COMPONENTS} >> $(Q)mkdir -p $(dir $@) >> ${COMMON_PATH}/files_to_obj.sh $@ _cpio_archive $^ >> >> >> I also edited sel4-sdcard/Kconfig, added the following to the related >> menus, >> >> source "apps/sdcard/Kconfig" >> >> source "libs/libsdhcdrivers/Kconfig" >> >> source "libs/libsel4sync/Kconfig" >> >> >> I've attached the config file, copy it to configs directory, then do >> "make sdcard_defconfig". >> >> I've also attached the binary image that I compiled. >> >> >> Since the u-boot command works, it doesn't seem that the controller is >> disabled. Also try another card if possible, my card is Kingston micro SDHC >> class 4. The driver only implements very basic single block read/write. I'm >> not surprised that it doesn't work for some cards. >> >> >> - Siwei >> >> >> ------------------------------ >> *From:* Norrathep Rattanavipanon <nrattana(a)uci.edu> >> *Sent:* Monday, 23 January 2017 4:59 PM >> *To:* Zhuang, Siwei (Data61, Kensington NSW) >> >> *Subject:* Re: [seL4] SDHC drivers (cont.) >> >> Hi Siwei, >> >> Thank you for helping me out. I am still unable to get it to work even if >> using your code with the latest kernel (4.0) and latest libraries >> (downloaded from https://github.com/SEL4PROJ/sel4-tutorials-manifest >> master branch) >> >> I also tried calling mmc read command in u-boot and it was able to read >> data from the card just fine. >> I'm not really sure how I can check if the host controller works >> properly. Do you mean I can do it in seL4? >> >> Also, is it possible if you can upload the binary image file (and the >> build config) so that I can test on my board really quick? I suspect that >> either I miss something for the build or my micro-sd is not working. >> >> Thank you again for your help, >> Oak >> >> On Thu, Jan 19, 2017 at 11:12 AM, Norrathep Rattanavipanon < >> nrattana(a)uci.edu> wrote: >> >>> Hi Siwei, >>> >>> Yes, I believe mmc_card_capacity returns the correct value (4026531840 >>> <(402)%20653-1840> - my microsd is 4GB). >>> >>> And my code does not do any interrupt handling. In fact, that's all the >>> code in the root userspace process (besides initializing vka, vspace and >>> simple objects) and there is no other process. >>> >>> I also tried using a callback as mmc_block_read's argument, instead of >>> using NULL, but it also does not work. >>> >>> On Wed, Jan 18, 2017 at 8:41 PM, <Siwei.Zhuang(a)data61.csiro.au> wrote: >>> >>>> Hi Oak, >>>> >>>> >>>> Do you get the correct card capacity by calling mmc_card_capacity? If >>>> you don't, you'd need to check if the hardware is enabled in your >>>> bootloader. >>>> >>>> >>>> Are you doing any interrupt handling? As you don't supply a callback >>>> function to mmc_block_read, the read function would block until the >>>> hardware responses. In this case, mmc_block_read handles the interrupt >>>> itself. It would trigger a dead lock if you also handles the interrupt. >>>> >>>> >>>> - Siwei >>>> >>>> >>>> ------------------------------ >>>> *From:* Devel <devel-bounces(a)sel4.systems> on behalf of Norrathep >>>> Rattanavipanon <nrattana(a)uci.edu> >>>> *Sent:* Thursday, 19 January 2017 9:54 AM >>>> *To:* Danis, Adrian (Data61, Kensington NSW) >>>> *Cc:* devel(a)sel4.systems; GTS >>>> *Subject:* Re: [seL4] SDHC drivers (cont.) >>>> >>>> Hi Adrian, >>>> >>>> Thank you for the reply. I fix it according to what you suggest but it >>>> still does not solve the problem (still hang at the same place. Do you have >>>> any other suggestions on what I should fix or how I should look into >>>> debugging it? >>>> >>>> Best, >>>> Oak >>>> >>>> On Tue, Jan 17, 2017 at 8:58 PM, <Adrian.Danis(a)data61.csiro.au> wrote: >>>> >>>>> Hi Oak, >>>>> >>>>> I don't know much about SD cards or this driver but it seems to me >>>>> like passing it a physical address of 0 isn't what you want, and whilst I >>>>> know nothing about the mmc hardware it seems reasonable to me that it might >>>>> hang trying to DMA to memory that doesn't exist. There is also the >>>>> additional problem that even if paddr was correct for the first page, there >>>>> is no guarantee that the 5 pages you have allocated are contiguously >>>>> physically even though they will be mapped contiguous virtually. >>>>> >>>>> My recommendation is to use the page dma allocator in >>>>> seL4_libs/libsel4utils/include/sel4utils/page_dma.h, this will >>>>> provide you an easy way to allocate/map pages for the purposes of DMA. So >>>>> instead of >>>>> >>>>> void *vaddr = vspace_new_pages(&vspace, seL4_AllRights, 5, seL4_PageBits); >>>>> uintptr_t paddr = 0; >>>>> >>>>> You would have >>>>> >>>>> ps_dma_man_t dma_man; >>>>> error = sel4utils_new_page_dma_alloc(&vka, &vspace, &dma_man); >>>>> void *vaddr = ps_dma_alloc(&dma_man, 5 * PAGE_SIZE_4K, PAGE_SIZE_4K, >>>>> 0, PS_MEM_NORMAL); >>>>> uintptr_t paddr = ps_dma_pin(&dma_man, vaddr, 5 * PAGE_SIZE_4K); >>>>> >>>>> As I said at the start, I don't know if this will actually fix your >>>>> current problem, but it's still something you will need to fix. >>>>> >>>>> Adrian >>>>> >>>>> >>>>> On Wed 18-Jan-2017 6:31 AM, Norrathep Rattanavipanon wrote: >>>>> >>>>> My apology that I have to continue the discussion from the old thread: >>>>> (http://sel4.systems/pipermail/devel/2016-October/001056.html) >>>>> My goal is to read and write data from/to micro sd in SabreLite >>>>> platform. >>>>> I tried both Adrain and Anna's suggestions in that thread and they >>>>> dont seem to fix the problem. Nothing returns error and I also changed >>>>> cacheable parameter in sel4utils_new_pages_at_vaddr to 0 (I believe this is >>>>> what Anna meant instead of setting 3rd argument of vspace_new_pages). >>>>> >>>>> The code's still stuck inside mmc_block_read function. I tracked it >>>>> down and it seems like BRR and BWR interrupt statuses are never set to 1 >>>>> I add my code below, please let me know if anything is wrong with my >>>>> code. >>>>> >>>>> ps_io_mapper_t io_mapper = {0}; >>>>> error = sel4platsupport_new_io_mapper(simple, vspace, vka, &io_mapper); >>>>> assert(error == 0); >>>>> >>>>> ps_io_ops_t io_ops = { >>>>> .io_mapper = io_mapper >>>>> }; >>>>> >>>>> sdio_host_dev_t* dev = (sdio_host_dev_t*) malloc(sizeof(*dev)); >>>>> assert(dev != NULL); >>>>> memset(dev, 0, sizeof(*dev)); >>>>> >>>>> enum sdio_id id = sdio_default_id(); // return id=3 >>>>> error = sdio_init(id, &io_ops, dev); >>>>> assert(error == 0); >>>>> >>>>> mmc_card_t* mmc_card = (mmc_card_t*) malloc(sizeof(*mmc_card)); >>>>> error = mmc_init(dev, &io_ops, mmc_card); >>>>> assert(error == 0 && mmc_card != NULL); >>>>> >>>>> void *vaddr = vspace_new_pages(&vspace, seL4_AllRights, 5, seL4_PageBits); >>>>> assert(vaddr != NULL); >>>>> >>>>> uintptr_t paddr = 0; >>>>> printf("mmc card capacity %llu bytes\n", mmc_card_capacity(*mmc_card)); >>>>> long read_len = mmc_block_read(*mmc_card, 0x50000, 1, vaddr, paddr, NULL, NULL); // Stuck here >>>>> printf("read %lu bytes\n", read_len); >>>>> >>>>> >>>>> >>>>> Thanks >>>>> Oak >>>>> >>>>> >>>>> >>>>> -- >>>>> Norrathep (Oak) Rattanavipanon >>>>> M.S. in Computer Science >>>>> University of California - Irvine >>>>> >>>>> >>>>> _______________________________________________ >>>>> Devel mailing listDevel@sel4.systemshttps://sel4.systems/lists/listinfo/devel >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Norrathep (Oak) Rattanavipanon >>>> M.S. in Computer Science >>>> University of California - Irvine >>>> >>> >>> >>> >>> -- >>> Norrathep (Oak) Rattanavipanon >>> M.S. in Computer Science >>> University of California - Irvine >>> >> >> >> >> -- >> Norrathep (Oak) Rattanavipanon >> M.S. in Computer Science >> University of California - Irvine >> > > > > -- > Norrathep (Oak) Rattanavipanon > M.S. in Computer Science > University of California - Irvine > -- Norrathep (Oak) Rattanavipanon M.S. in Computer Science University of California - Irvine

2 1

seL4 on Zedboard
by Brandon, Jeffrey - 0553 - MITLL 01 Feb '17

01 Feb '17

Hi, I've been trying to get seL4 running on a Zedboard and I was wondering if there was any documentation on how to boot sle4 from an SD card. I've read http://sel4.systems/pipermail/devel/2016-December/001160.html and https://sel4.systems/Info/Hardware/General/ which mentions using ${loadaddr} but that doesn't seem to be defined on the Zedboard's u-boot. So far I've compiled the image targeting the zynq7000 and used the mkimage command from the general hardware page to try u-boot's fastboot, but fastboot doesn't seem to be available on the zynq either. I am a bit of a novice here. I worry that the solution may be simple but I am currently taking shots in the dark. I wanted to ask this list for any resources you may be aware of for getting sel4 test cases running on the Zed. Thanks for the help, Jeff Brandon 05-53 Secure Resilient Systems and Technology

2 3

arm_data_abort_exception
by Wladislav Wiebe 31 Jan '17

31 Jan '17

Hello, has somebody experience with running into arm_data_abort_exception after enabling the MMU/paging and jumping to the kernel image: .. ELF-loader started on CPU: ARM Ltd. Cortex-A15 r2p4 paddr=[90000000..904b041f] ELF-loading image 'kernel' paddr=[80000000..80033fff] vaddr=[f0000000..f0033fff] virt_entry=f0000000 ELF-loading image 'sel4test-driver' paddr=[80034000..8042dfff] vaddr=[10000..409fff] virt_entry=1e924 Enabling MMU and paging Jumping to kernel-image entry point... check_data_abort_exception() DFAR = 0xfff01014 DFSR = 0x7 ADFSR = 0x0 abort() called. I've dumped the DFAR/DFSR register -- Relevant config parts about the setup: CONFIG_ARCH_ARM_V7A=y CONFIG_ARCH_ARM=y CONFIG_ARCH_AARCH32=y CONFIG_ARM_CORTEX_A15=y CONFIG_PLAT_KEYSTONE=y Thanks in advance! -- WBR, Wladislav WIebe

2 12

Exposing ticks to the rt API
by Corey Richardson 30 Jan '17

30 Jan '17

Hi Anna, While analyzing some time related APIs, I've noticed that the x86 rt kernel assumes that the tsc frequency is constant and well represented by the measurement made at init by comparing against the PIT. It also exposes only microseconds and uses the internal calibration to convert that to/from ticks. I'm concerned about this behavior. The tsc can have up to 200ppm error if uncalibrated and not temperature controlled, from what I'm able to determine. I'd rather have all the public APIs take ticks and allow user space to determine how their timing requirements best correspond to ticks. This came up when wanting to measure how much running time a process/thread has used. Ideally, it's kept as a running count of ticks. In the current API, one can only observe microseconds consumed, converted by a potentially lossy ticksToUs (lossy when the rate isn't exactly known or tick->us conversion isn't an exact integer multiplication). It'd be more useful for me to have tick count directly. I'm also somewhat concerned with using the PIT to estimate the TSC rate, as I can't find anything about expected error of the PIT, and any slop there will influence all future kernel behaviors until reboot. One potential alternative is the ACPI PM timer or the HPET. Those run at higher frequencies, which would help reduce the error bounds on the rate estimation. Let me know what you think! If it's useful at all, I've written up some stuff about the work that inspired these thoughts: https://gitlab.com/robigalia/meta/blob/master/blog/_drafts/2016-12-23-what-… Merry Christmas, -- cmr http://octayn.net/

4 4

strange code in thread.c
by Berkus 30 Jan '17

30 Jan '17

Hi! Details here https://github.com/seL4/seL4/issues/57 do you guys keep an eye on github activity actually or it’s a bad medium for communcation?

2 1

I2C Driver for BeagleBone (AM335x) for CAmkES
by Richard Habeeb 25 Jan '17

25 Jan '17

Hey all, Has anyone setup I2C on a Beaglebone CAmkES application? Is the code in libplatsupport all that's needed? The i2d_id enum doesn't seem to include all the i2c modules ( https://github.com/seL4/libplatsupport/blob/master/plat_include/am335x/plat…) I didn't see an init function for the i2c_bus for am335x; for example, exynos uses the exynos_i2c_init. Any help is appreciated. Thanks, Richard -- Richard Habeeb Research Assistant, Computer Science, USF PGP: https://goo.gl/VhmGGu https://habeebr.bitbucket.io/

1 0

ARM LPAE?
by Wladislav Wiebe 21 Jan '17

21 Jan '17

Hello, I am trying to integrate TI Keystone 2 platform to seL4. What I have done so far is basically an initial port of the Kernel/libs/elfloader/Platform components and introducing a new keystone defconfig. Relevant config parts about the setup: CONFIG_ARCH_ARM_V7A=y CONFIG_ARCH_ARM=y CONFIG_ARCH_AARCH32=y CONFIG_ARM_CORTEX_A15=y CONFIG_PLAT_KEYSTONE=y At the end I am able to generate an image which looks like: $ arm-cortexa15-linux-gnueabihf-readelf -e images/sel4test-driver-image-arm-keystone ELF Header: Class: ELF32 .. Entry point address: 0xc0008000 .. (I am using the same entry point as Linux use it) So far, it stops booting in the elfloader -- output log: .. [ 29.705] ## Starting application at 0xc0008000 ... ELF-loader started on CPU: ARM Ltd. Cortex-A15 r2p4 paddr=[c0008000..c032841f] -> Stop here <- Seems it stops loading @ elf_getMemoryBounds(). I suppose it is related to fact that the physical start address starts @ 0x840000000 which is beyond 32 Bit - so, LPAE support is required. The physical RAM setup looks like: bank 0: addr: 0x840000000 size: 0x17ec5000 (382 MB) bank 1: addr: 0x880000000 size: 0x80000000 (2048 MB) Do you have an idea if this is supposed to be supported on seL4? What should be the "physBase" and the "kernelBase" for such a setup? How should the "static const p_region_t BOOT_RODATA avail_p_regs" looks like? Thanks in advance! -- WBR, Wladislav WIebe

3 10

Re: [seL4] SDHC drivers (cont.)
by Siwei.Zhuang＠data61.csiro.au 20 Jan '17

20 Jan '17

Hi Oak, I tried your code. It works for me except that it seems that you are using old versions of seL4 kernel and libraries. Attached is the code I'm using, I merely add some initialization code to your code. It should work on the latest version of seL4 kernel and related libraries. If the code doesn't work for you. I would suggest, 1. If you are using u-boot, try its mmc command, see if you can access the card. 2. Have a look at the imx6 reference manual, chapter 67.2 and 67.3, check if the host controller is enabled properly. - Siwei ________________________________ From: Norrathep Rattanavipanon <nrattana(a)uci.edu> Sent: Friday, 20 January 2017 6:12 AM To: Zhuang, Siwei (Data61, Kensington NSW) Subject: Re: [seL4] SDHC drivers (cont.) Hi Siwei, Yes, I believe mmc_card_capacity returns the correct value (4026531840 - my microsd is 4GB). And my code does not do any interrupt handling. In fact, that's all the code in the root userspace process (besides initializing vka, vspace and simple objects) and there is no other process. I also tried using a callback as mmc_block_read's argument, instead of using NULL, but it also does not work. On Wed, Jan 18, 2017 at 8:41 PM, <Siwei.Zhuang(a)data61.csiro.au<mailto:Siwei.Zhuang@data61.csiro.au>> wrote: Hi Oak, Do you get the correct card capacity by calling mmc_card_capacity? If you don't, you'd need to check if the hardware is enabled in your bootloader. Are you doing any interrupt handling? As you don't supply a callback function to mmc_block_read, the read function would block until the hardware responses. In this case, mmc_block_read handles the interrupt itself. It would trigger a dead lock if you also handles the interrupt. - Siwei ________________________________ From: Devel <devel-bounces(a)sel4.systems> on behalf of Norrathep Rattanavipanon <nrattana(a)uci.edu<mailto:nrattana@uci.edu>> Sent: Thursday, 19 January 2017 9:54 AM To: Danis, Adrian (Data61, Kensington NSW) Cc: devel(a)sel4.systems; GTS Subject: Re: [seL4] SDHC drivers (cont.) Hi Adrian, Thank you for the reply. I fix it according to what you suggest but it still does not solve the problem (still hang at the same place. Do you have any other suggestions on what I should fix or how I should look into debugging it? Best, Oak On Tue, Jan 17, 2017 at 8:58 PM, <Adrian.Danis(a)data61.csiro.au<mailto:Adrian.Danis@data61.csiro.au>> wrote: Hi Oak, I don't know much about SD cards or this driver but it seems to me like passing it a physical address of 0 isn't what you want, and whilst I know nothing about the mmc hardware it seems reasonable to me that it might hang trying to DMA to memory that doesn't exist. There is also the additional problem that even if paddr was correct for the first page, there is no guarantee that the 5 pages you have allocated are contiguously physically even though they will be mapped contiguous virtually. My recommendation is to use the page dma allocator in seL4_libs/libsel4utils/include/sel4utils/page_dma.h, this will provide you an easy way to allocate/map pages for the purposes of DMA. So instead of void *vaddr = vspace_new_pages(&vspace, seL4_AllRights, 5, seL4_PageBits); uintptr_t paddr = 0; You would have ps_dma_man_t dma_man; error = sel4utils_new_page_dma_alloc(&vka, &vspace, &dma_man); void *vaddr = ps_dma_alloc(&dma_man, 5 * PAGE_SIZE_4K, PAGE_SIZE_4K, 0, PS_MEM_NORMAL); uintptr_t paddr = ps_dma_pin(&dma_man, vaddr, 5 * PAGE_SIZE_4K); As I said at the start, I don't know if this will actually fix your current problem, but it's still something you will need to fix. Adrian On Wed 18-Jan-2017 6:31 AM, Norrathep Rattanavipanon wrote: My apology that I have to continue the discussion from the old thread: (http://sel4.systems/pipermail/devel/2016-October/001056.html) My goal is to read and write data from/to micro sd in SabreLite platform. I tried both Adrain and Anna's suggestions in that thread and they dont seem to fix the problem. Nothing returns error and I also changed cacheable parameter in sel4utils_new_pages_at_vaddr to 0 (I believe this is what Anna meant instead of setting 3rd argument of vspace_new_pages). The code's still stuck inside mmc_block_read function. I tracked it down and it seems like BRR and BWR interrupt statuses are never set to 1 I add my code below, please let me know if anything is wrong with my code. ps_io_mapper_t io_mapper = {0}; error = sel4platsupport_new_io_mapper(simple, vspace, vka, &io_mapper); assert(error == 0); ps_io_ops_t io_ops = { .io_mapper = io_mapper }; sdio_host_dev_t* dev = (sdio_host_dev_t*) malloc(sizeof(*dev)); assert(dev != NULL); memset(dev, 0, sizeof(*dev)); enum sdio_id id = sdio_default_id(); // return id=3 error = sdio_init(id, &io_ops, dev); assert(error == 0); mmc_card_t* mmc_card = (mmc_card_t*) malloc(sizeof(*mmc_card)); error = mmc_init(dev, &io_ops, mmc_card); assert(error == 0 && mmc_card != NULL); void *vaddr = vspace_new_pages(&vspace, seL4_AllRights, 5, seL4_PageBits); assert(vaddr != NULL); uintptr_t paddr = 0; printf("mmc card capacity %llu bytes\n", mmc_card_capacity(*mmc_card)); long read_len = mmc_block_read(*mmc_card, 0x50000, 1, vaddr, paddr, NULL, NULL); // Stuck here printf("read %lu bytes\n", read_len); Thanks Oak -- Norrathep (Oak) Rattanavipanon M.S. in Computer Science University of California - Irvine _______________________________________________ Devel mailing list Devel(a)sel4.systems<mailto:Devel@sel4.systems> https://sel4.systems/lists/listinfo/devel -- Norrathep (Oak) Rattanavipanon M.S. in Computer Science University of California - Irvine -- Norrathep (Oak) Rattanavipanon M.S. in Computer Science University of California - Irvine

1 0