Merge pull request #71 from dkohlbre/dev-removebusybear

Completely removed all busybear files, references, scripts, and docs

.gitmodules

@@ -1,9 +1,6 @@
 [submodule "riscv-gnu-toolchain"]
 	path = riscv-gnu-toolchain
 	url = https://github.com/riscv/riscv-gnu-toolchain
-[submodule "busybear-linux"]
-	path = busybear-linux
-	url = https://github.com/keystone-enclave/busybear-linux
 [submodule "riscv-linux"]
 	path = riscv-linux
 	url = https://github.com/riscv/riscv-linux

CONTRIBUTING.md

@@ -2,7 +2,7 @@
 
 ### Submodules
 
-You are recommended to *fork* the submodules to your own GitHub account, modify the code, 
+You are recommended to *fork* the submodules to your own GitHub account, modify the code,
 and send Pull Request (PR) into `master` branch. The admin will review the code before merging.
 
 ### `keystone` repo
@@ -51,21 +51,21 @@ Ideally `dev` should not stay unhealthy more than a few days.
 ### Rules for Submodules (`sdk` and `runtime`)
 
 For `sdk` and `runtime`, `<submodule>:master` means the `master` branch of each submodule.
-For `riscv-pk` and `busybear-linux`, use `keystone` instead of `master` as the master branch.
+For `riscv-pk` use `keystone` instead of `master` as the master branch.
 This is because those repositories are the mirrors of some upstream repos.
 We want to keep `master` clean so that we can pull the upstream changes into `master`.
 
 1. The submodules in `keystone:master` and `keystone:dev` should always point to the commits on `<submodule>:master`.
 2. `master` of submodules should be always healthy (it compiles well and passes some basic tests).
-3. The submodules can also have `dev-<name of task>` branch for each open task. 
+3. The submodules can also have `dev-<name of task>` branch for each open task.
 These kind of branches should be deleted right after merge
 
 # How to Release
 
 ### Version Number
 
 A version number consists of two positive integers: `major` and `minor`. For example, `1.14` means that the major is 1 and the minor is 14.
-The numbers increase on each *major release* or *minor release* respectively. 
+The numbers increase on each *major release* or *minor release* respectively.
 
 ### Releasing
 
@@ -99,4 +99,3 @@ Any other contributions are very welcomed.
 4. More use-case applications
 
 For potential collaboration or large suggestions, please feel free to create an issue or contact us (keystone-leads@googlegroups.com).
-

Makefile

@@ -13,9 +13,6 @@ all: hifive
 qemu:
 	./scripts/run-qemu.sh
 
-.PHONY: busybear-qemu
-busybear-qemu: $(BOOTROM) $(QEMU) sdk
-	$(MAKE) -f busybear.mk
 
 .PHONY: hifive
 hifive: sdk $(QEMU) $(BOOTROM)
@@ -35,10 +32,5 @@ $(QEMU):
 $(BOOTROM):
 	cd bootrom; make; cd ..
 
-busybear-clean:
-	$(MAKE) -f busybear.mk clean
-
 clean:
 	$(MAKE) -f hifive.mk clean
-
-clean-all: busybear-clean clean

docs/source/Getting-Started/Guide-to-Components.rst

@@ -16,14 +16,6 @@ Link: `<https://github.com/keystone-enclave/buildroot>`_
 
 Linux buildroot. Builds a minimal working Linux image for our test platforms.
 
-busybear-linux
---------------
-
-Link: `<https://github.com/keystone-enclave/busybear-linux>`_
-
-Unmodified busybear Linux, supporting riscv. Deprecated. Soon to be
-removed.
-
 docs
 ----
 

docs/source/Getting-Started/Running-Keystone-with-QEMU.rst

@@ -29,7 +29,7 @@ Ubuntu
     Some of the utilities also use ``expect`` so we recommend that you install that as well though it is not strictly necessary.
     ::
       sudo apt install expect
-  
+
 Quick Setup
 ----------------------------
 
@@ -58,10 +58,6 @@ Build All
 
 If you want to build all, simply run ``make``.
 
-(You may run ``make busybear`` which will build a Busybear based
-qemu-only image, this is in the process of being deprecated and
-eventually will be removed)
-
 ``PATH`` must include the RISC-V tool path.
 
 ::
@@ -71,22 +67,6 @@ eventually will be removed)
 If you want to manually build each individual component, please follow the instructions below.
 Otherwise, skip to :ref:`LaunchQEMU`.
 
-.. attention::
-
-  Currently, ``make busybear`` requires sudo previlege to build Busybear image.
-
-Build Busybear
-################################
-
-See `Busybear repo <https://github.com/michaeljclark/busybear-linux>`_ for more information.
-
-We are in the process of deprecating all busybear based builds.
-
-::
-
-  cd busybear-linux
-  make
-  cd ..
 
 Build RISC-V QEMU
 ##################
@@ -104,31 +84,17 @@ You should apply patches before building the QEMU.
 Build Linux Kernel
 ################################################
 
-::
-
-  cd riscv-linux
-  cp ../busybear-linux/conf/linux.config .config
-  make ARCH=riscv olddefconfig
-  make ARCH=riscv vmlinux
-  cd ..
+This is handled as part of the top-level make, see ``hifive.mk`` for
+details.
 
 Build Berkeley Bootloader (BBL) with Keystone Security Monitor
 ##############################################################
 
-Make sure to add ``--enable-sm`` when you run ``configure`` so that the security monitor is included in the bbl.
+This is handled as part of the top-level make, see ``hifive.mk`` for
+details.
 
-::
-
-  cd riscv-pk
-  mkdir build
-  cd build
-  ../configure \
-      --enable-logo \
-      --host=riscv64-unknown-elf \
-      --with-payload=../../riscv-linux/vmlinux \
-      --enable-sm
-  make
-  cd ../..
+Optionally, add ``--with-target-platform=PLATFORM`` if you have a
+platform specific set of files for the security monitor (defined in ``riscv-pk/
 
 Build Root-of-Trust Boot ROM
 ###############################
@@ -146,19 +112,17 @@ Build Keystone Driver
 
   cd linux-keystone-driver
   make
-  make copy
   cd ..
 
 Build Keystone SDK
 #############################
 
-Keystone SDK includes sample enclave programs and some useful libraries. To run sample programs, you should compile SDK library and apps, and copy all of them into the disk image. Following commands will compile the sdk, and copy sample binaries into the ``busybear.bin`` disk image.
+Keystone SDK includes sample enclave programs and some useful libraries. To run sample programs, you should compile SDK library and apps, and copy all of them into the disk image. This is done automatically during the top-level build. If you have modified the applications, simply re-run the top-level ``make``.
 
 ::
 
   cd sdk
   make
-  make copy-tests
   cd ..
 
 
@@ -179,15 +143,6 @@ The root of trust then jumps to the SM, and the SM boots Linux!
 Login as ``root`` with the password ``sifive``.
 
 
-Or if you want to run the busy-bear based image
-
-::
-
-   sudo chmod og+w busybear-linux/busybear.bin
-   /scripts/run-busybear-qemu.sh
-
-Login as ``root`` with the password ``busybear``.
-
 You can exit QEMU by ``ctrl-a``+``x`` or using ``poweroff`` command
 
 Note that the launch scripts for QEMU will start ssh on a random

scripts/run-busybear-qemu.sh → scripts/gdb.sh

@@ -5,13 +5,12 @@ HOST_PORT=${HOST_PORT:="$((3000 + RANDOM % 3000))"}
 echo "**** Running QEMU SSH on port ${HOST_PORT} ****\n"
 
 ./riscv-qemu/riscv64-softmmu/qemu-system-riscv64 \
+    -S -s \
     -D debug.log \
     -m 4G \
     -bios bootrom/bootrom.elf \
     -nographic \
-    -machine virt\
-    -kernel riscv-pk/build/bbl -append "root=/dev/vda ro console=ttyS0" \
-    -drive file=busybear-linux/busybear.bin,format=raw,id=hd0 \
-    -device virtio-blk-device,drive=hd0 \
+    -machine virt \
+    -kernel hifive-work/riscv-pk/bbl \
     -netdev user,id=net0,net=192.168.100.1/24,dhcpstart=192.168.100.128,hostfwd=tcp::${HOST_PORT}-:22 \
     -device virtio-net-device,netdev=net0