- Devel - lists.sel4.systems

experiences running sel4 test on beagleboard
by Tim Newsham 07 Aug '14

07 Aug '14

Here is my experience building and running seL4 on the BeagleBoard (original, redboard, revision D). I'm hoping the notes will be helpful for others who arent very experience with this platform, like myself. Start with a BeagleBoard, a 5volt power supply (or the USB cable for power), a SDCard and an RS232 serial connector. Note: the BeagleBoard uses RS232 serial levels, not TTL levels, so you'll need some kind of RS232 connector. I used a USB<->RS232 (9-pin D-connector) cable. The beagle board has serial on header P9, which is a 2x5 header. P9 pin 2 (RX) <--> D-connector pin 3 (TX) P9 pin 3 (TX) <--> D-connector pin 2 (RX) P9 pin 5 (GND) <--> D-connector pin 5 (GND) I use "screen" or "cu" from linux to connect to the serial line with one of the following commands (note: I'm in linux and my account has permissions on /dev/ttyUSB0): $ cu -l /dev/ttyUSB0 -s 115200 $ screen /dev/ttyUSB0 115200 Verify that when you power on the device (no SDCard necessary yet) you get the u-boot bootloader in your terminal. Next get and build your seL4 image for the beagleboard. I'm running the sel4 test project in a debug build. You'll need to have the proper prerequisites, as covered in the sel4 build notes. $ mkdir sel4/beagle $ cd sel4/beagle $ repo init -u https://github.com/seL4/sel4test-manifest.git $ repo sync $ make beagle_debug_xml_defconfig $ make menuconfig # at this point I adjusted the tools prefix to # "arm-none-eabi-" to match the arm toolchain I have $ make At this point you've got an ELF image in the images dir. It has one section at 0x82000000 starting at offset 0x8000 in the file, and the start address is 0x82000000. Mount an SDCard with a FAT filesystem and nothing else on it and copy the image to your sdcard $ cp images/sel4test-driver-image-arm-omap3 /media/SDCARD/ $ umount /media/SDCARD now power off the beagle board, move the SDCard to the beagleboard, power it on and interrupt the u-boot sequence to get a boot loader prompt. Enter the following commands to boot the image. They will load the file so that offset 0x8000 is at 0x82000000 (by loading the entire file 0x8000 bytes before 0x82000000). Then it will jump to the entry point and run the sel4 loader, kernel and tests. mmc rescan 0 fatload mmc 0 0x81ff8000 sel4test-driver-image-arm-omap3 go 0x82000000 At this point sel4 is up and running and the test program is running through its tests! The full output of the tests can be seen at http://pastebin.com/cC0FTuqM There are some errors printed during the test, but happily the test ends with: 136/136 tests passed. All is well in the universe. Tim

2 1

dma and sel4
by Tim Newsham 06 Aug '14

06 Aug '14

Does the use of DMA invalidate security guarantees in the ARM ports (and KZM in particular) currently? -- Tim Newsham | www.thenewsh.com/~newsham | @newshtwit | thenewsh.blogspot.com

4 3

Thanks for seL4, plus a digital Random Bit Generator
by TAG AUTO REPLY 06 Aug '14

06 Aug '14

I would like to thank the development teams and sponsoring institutions for releasing this amazing work into the public domain. It may be some time before the importance of this is fully understood by the software industry, but I believe we finally have a reference platform for how software is to be correctly engineered. You have raised the bar for all of us. I would also like to share with you a POSIX C implementation of a non-deterministic Digital Random Bit Generator for your evaluation. It can be downloaded from http://www.tag.md/public/ Kind regards, -MK

1 0

[PATCH] Use usr/bin/env for all python bangpaths to enable virtualenv
by Max R.D. Parmer 05 Aug '14

05 Aug '14

This patch targets the core "seL4" repo. I idly submitted a PR on github before reading anything at all really (beyond checking to see if the issue was made more consistent in subsequent commits). Apologies if this is/was inconvenient. I saw some prior github discussion on whether "python2" or "python" is best'; IMHO, "python" is best as virtualenv allows the desired binary to be specified at env creation time. CLA forthcoming, I'm quite a long way from printers/scanners and all those sorts of things. -- @maximus_freeman 0x7D964D3361142ACF

3 2

seL4 boot issue
by Jorge Ventura 05 Aug '14

05 Aug '14

I am trying to boot seL4 on beaglebone white. I have an initial code just to configure the DDR2 memory at range 0x80000000-0xbfffffff. As we can see below, the start address is the virtual address 0xf0000000 but at this point I have no MMU configured. I was thinking that the segment .boot should be the code to prepare all details about MMU/D-CACHE/I-CACHE but it's not what gdb is understanding based in the elf header. Someone could explain to me how is the kernel boot; what do I have to consider. I guess that beaglebone is not supported but this is exactly my goal, to make seL4 boot on beaglebone. Any help or suggestion is very welcome. Sincerely, Jorge Ventura (gdb) load kernel.elf > Loading section .boot, size 0x10000 lma 0x80000000 > Loading section .text, size 0xf1ec lma 0x80010000 > Loading section .text.unlikely, size 0xd98 lma 0x8001f1ec > Loading section .rodata, size 0x4170 lma 0x8001ff84 > Loading section .data, size 0x8 lma 0x800240f4 > Start address 0xf0000000, load size 147708 > Transfer rate: 319 KB/sec, 3787 bytes/write. > (gdb) monitor poll background polling: on TAP: am335x.dap (enabled) target state: halted target halted in ARM state due to debug-request, current mode: System cpsr: 0x6000019f pc: 0xf0000000 MMU: disabled, D-Cache: disabled, I-Cache: disabled

1 1

active development and verification
by Tim Newsham 05 Aug '14

05 Aug '14

A question I had about how the sel4 project is run internally: What is your process of developing ongoing changes and how does verification fit into it? Do you maintain the proofs with kernel modifications on an ongoing basis? On a semi-regular basis? Is the "experimental" branch verified? When time slices are no longer global, will those changes be verified? etc... Tim

2 2

ArchLinux/Manjaro development
by stercor 03 Aug '14

03 Aug '14

Has there been any seL4 development effort for the ArchLinux or Manjaro platforms? -- GPG/PGP public key: B07F9AAE

2 1

signing git commits
by HW42 01 Aug '14

01 Aug '14

Hi, I really like to see big formally verified software. But it seems your provide no way to verify the downloads from your repositories. I think you should use signed git tags and also ensure that repo verify those. HW42

2 1

run_tests needs mlton-compiler gcc-arm-none-eabi
by Harry Butterworth 01 Aug '14

01 Aug '14

On Ubuntu 14.04, after attempting to follow the instructions, I found I needed to add two extra packages. I needed mlton-complier for CParserTools and gcc-arm-none-eabi for CBaseRefine. gcc-arm-linux-gnueabi is a documented dependency for 14.04 and was already installed when the CBaseRefine test was failing. After installing those two packages and the documented latex extras all 31 regression tests passed.

2 1

AM335X (BeagleBone) support?
by Tim Newsham 31 Jul '14

31 Jul '14

What is the state of "AM335X (BeagleBone)" support in the main and experimental branches? Tim

2 1