readme: gem5 and docker getting started make awesomer

Author: cirosantilli

README.adoc

@@ -339,9 +339,9 @@ For the most part, if you just add the `--gem5` option or `*-gem5` suffix to all
 
 ....
 ./configure -g && \
-  ./build-gem5 --arch aarch64 && \
-  ./build-buildroot --arch aarch64 --gem5 && \
-  ./run --arch aarch64 --gem5 &&\
+  ./build-gem5 && \
+  ./build-buildroot --gem5 && \
+  ./run --gem5 &&\
 :;
 ....
 
@@ -356,7 +356,7 @@ To get a terminal, either open a new shell and run:
 or if you are inside tmux, which I highly recommend, just run gem5 with:
 
 ....
-./run --tmux
+./run --gem5 --tmux
 ....
 
 This will open up a split terminal by default so that you can see both the gem5 stdout and the terminal. See also: <<tmux-gem5>>
@@ -380,7 +380,7 @@ More information at: <<gem5>>
 [[docker]]
 === QEMU Buildroot setup inside Docker
 
-This is the same as the native <<qemu-buildroot-setup>>, but run from inside a Docker on the host.
+This is the same as the native <<qemu-buildroot-setup>>, but run from inside a link:https://en.wikipedia.org/wiki/Docker_(software)[Docker] on the host.
 
 This is a good option if you are on a Linux host, but the native setup failed due to your weird host distribution, and you have better things to do with your life than to debug it.
 
@@ -412,7 +412,7 @@ The host git top level directory is mounted inside the guest, which means for ex
 
 Just don't forget that if you nuke that directory on the guest, then it gets nuked on the host as well!
 
-Trying to run the output from Docker from host won't however, I think the main reason is that the absolute paths inside Docker are will be different than the host ones, but even if we fix that there will likely be other problems.
+Trying to run the output from Docker from host won't however, I think the main reason is that the absolute paths inside Docker are different than the host ones, but even if we fix that there will likely be other problems.
 
 TODO make files created inside Docker be owned by the current user in host instead of `root`: https://stackoverflow.com/questions/23544282/what-is-the-best-way-to-manage-permissions-for-docker-shared-volumes
 
@@ -560,7 +560,7 @@ It has however severe limitations, and you will soon see that the compilation ti
 ** your disk could get erased. Yes, this can also happen with `sudo` from userland. But you should not use `sudo` when developing newbie programs. And for the kernel you don't have the choice not to use `sudo`.
 ** even more subtle system corruption such as https://unix.stackexchange.com/questions/78858/cannot-remove-or-reinsert-kernel-module-after-error-while-inserting-it-without-r[not being able to rmmod]
 * can't control which hardware is used, notably the CPU architecture
-* can't step debug it with <<gdb,GDB>> easily. The alternatives are JTAG or <<kgdb>>, but those are less reliable, and JTAG requires extra hardware.
+* can't step debug it with <<gdb,GDB>> easily. The alternatives are link:https://en.wikipedia.org/wiki/JTAG[JTAG] or <<kgdb>>, but those are less reliable, and require extra hardware.
 
 Still interested?