diff --git a/src/case_studies/TiogaPass.md b/src/case_studies/TiogaPass.md index 4d4b464..a105879 100644 --- a/src/case_studies/TiogaPass.md +++ b/src/case_studies/TiogaPass.md @@ -14,15 +14,15 @@ Corporation](http://www.wiwynn.com/english). It contains following sections: -* [Quick Start](#Quick-Start) -* [Details](#Details) - * [How to build](#How-to-build) - * [How to operate](#How-to-operate) - * [Platform info](#Platform-info) -* [Support](#Support) - * [Hardware support](#Hardware-support) - * [Community support](#Community-support) - * [Professional support](#Professional-support) +* [Quick Start](#quick-start) +* [Details](#details) + * [How to build](#how-to-build) + * [How to operate](#how-to-operate) + * [Platform info](#platform-info) +* [Support](#support) + * [Hardware support](#hardware-support) + * [Community support](#community-support) + * [Professional support](#professional-support) ## Quick Start @@ -33,11 +33,14 @@ It contains following sections: * Flash the firmware. * Copy the downloaded firmware to OpenBMC. * From OpenBMC + ``` fw-util mb --update bios --force ./ ``` + * Boot and enjoy. * From OpenBMC + ``` power-util mb reset sol-util mb @@ -47,7 +50,7 @@ It contains following sections: ### How to build -Follow [Build Details](#Build-Details) for details on how to get the source +Follow [Build Details](#build-details) for details on how to get the source code, and how to build. Boot flow of the current firmware solution is: Power on → minimized UEFI → @@ -59,15 +62,19 @@ target OS. #### Build Details * Download the code from [linuxboot github](https://github.com/linuxboot/linuxboot) + ``` git clone https://github.com/linuxboot/linuxboot.git ``` + * You need to apply Wiwiynn's linuxboot patch for now + ``` cd linuxboot wget -O TiogaPass.patch https://github.com/johnnylinwiwynn/linuxboot/commit/28ae8450b3b05c6e6b8c74e29d0974ccf711d5e6.patch git am TiogaPass.patch ``` + * Build the kernel bzImage (has embedded initramfs) for linuxboot, please reference [Building u-root](https://github.com/linuxboot/book/tree/master/coreboot.u-root.systemboot#building-u-root) and [Building a suitable Linux kernel](https://github.com/linuxboot/book/tree/master/coreboot.u-root.systemboot#building-a-suitable-linux-kernel) @@ -77,12 +84,14 @@ target OS. * Place the tioga.rom into linuxboot/boards/tioga which is provided from Wiwynn after ordering, and also put your bzImage to the root folder of linuxboot, and then make + ``` cp path/to/tioga.rom linuxboot/boards/tioga cp path/to/bzImage linuxboot cd linuxboot BOARD=tioga make ``` + * You should see the built image at build/tioga/linuxboot.rom. ### How to operate @@ -122,4 +131,4 @@ IRC channel, a mailing list and regular meetings. Following companies provides professional support services: -** TBD ** +**TBD** diff --git a/src/coreboot.u-root.systemboot/index.md b/src/coreboot.u-root.systemboot/index.md index 6d2232d..a85c84e 100644 --- a/src/coreboot.u-root.systemboot/index.md +++ b/src/coreboot.u-root.systemboot/index.md @@ -78,7 +78,7 @@ path with `-o`. Run `u-root -h` for additional command line parameters. Note: the above command will include only pure-Go commands from `u-root`. If you need to include other files or non-Go binaries, use the `-file` option in `u-root`. For example, you may want to include static builds of `kexec` or -`flashrom`, that we build on https://github.com/systemboot/binaries . +`flashrom`, that we build on . Then, the initramfs has to be compressed. This step is necessary to embed the initramfs in the kernel as explained below, in order to maintain the image size @@ -143,7 +143,7 @@ make tinyconfig ``` Some more information about tiny configs can be found at -https://tiny.wiki.kernel.org (last checked 2018-12-01). + (last checked 2018-12-01). ### A few fundamental features @@ -184,7 +184,7 @@ In menuconfig: → `Enable eventpoll support` Additional information about Go's minimum requirements can be found at -https://github.com/golang/go/wiki/MinimumRequirements (last checked + (last checked 2018-12-01). ### Enable devtmpfs @@ -302,7 +302,7 @@ The image will be located under `arch/${ARCH}/boot/bzImage` if your architecture supports bzImage (e.g. x86). For more details on how to build a kernel, see -https://kernelnewbies.org/KernelBuild (last checked 2018-12-01). + (last checked 2018-12-01). ## Building coreboot diff --git a/src/utilities/UEFI_Tool_Kit.md b/src/utilities/UEFI_Tool_Kit.md index 25a8218..120da83 100644 --- a/src/utilities/UEFI_Tool_Kit.md +++ b/src/utilities/UEFI_Tool_Kit.md @@ -422,8 +422,8 @@ Visitor pattern means decoupling the structure from the operations. Good resources: -1. https://sourcemaking.com/design_patterns/visitor -2. https://en.wikipedia.org/wiki/Visitor_pattern +1. +2. A good visitor still works when new Firmware are introduced. A good Firmware still works when a new visitor is introduced. diff --git a/src/utilities/cpu.md b/src/utilities/cpu.md index dba4567..caafa22 100644 --- a/src/utilities/cpu.md +++ b/src/utilities/cpu.md @@ -574,7 +574,7 @@ Even though the binaries themselves are running on the remote ARM system. #### cpu and virtiofs -While 9p is very general, because it is *transport-independent*, there are +While 9p is very general, because it is _transport-independent_, there are cases where we can get much better performance by using a less general file system. One such case is with virtofs. @@ -633,7 +633,7 @@ There are thus several choices for setting up the mounts * 9p support by the cpu client * 9p supported by the cpu client, with additional mounts via -fstab or -namespace -* 9p *without* any bind mounts, i.e. -9p=false -namespace "", in which case, on +* 9p _without_ any bind mounts, i.e. -9p=false -namespace "", in which case, on the remote machine, files from the client are visible in /tmp/cpu, but no bind mounts are done; with additional mounts provided by fstab mounts are provided diff --git a/src/utilities/dut.md b/src/utilities/dut.md index 38a63c4..ed79f3a 100644 --- a/src/utilities/dut.md +++ b/src/utilities/dut.md @@ -1,4 +1,4 @@ -# DUT, a simple Device Under Test utility. +# DUT, a simple Device Under Test utility Points of contact: [Ron Minnich](https://github.com/rminnich) @@ -19,6 +19,7 @@ This chapter describes how we build and use DUT. ## Components DUT is intended to be built into a u-root image. First one must fetch it: + ``` go get github.com/linuxboot/dut # ignore the warning message. @@ -27,17 +28,20 @@ go get github.com/linuxboot/dut DUT source tree is structured such that a program called uinit is produced. This is convenient for u-root usage. Building it into a u-root image is easy: + ``` go run $(GOPATH)/src/github.com/u-root/u-root -build=bb minimal github.com/linuxboot/dut/uinit ``` I almost always add an sshd to u-root; it's just too handy. U-root sshd does not support passwords, so you have to supply the public key: + ``` go run $(GOPATH)/src/github.com/u-root/u-root -build=bb -files key.pub minimal github.com/linuxboot/dut/uinit github.com/u-root/u-root/xcmds/sshd ``` ### DUT on the device + On boot, the standard init program will find dut, and run it. The standard mode on a device is device mode, and dut will bring up the ethernet, currently using 192.168.0.2, and assuming the tester is 192.168.0.1 (this should be fixed ...). @@ -45,13 +49,16 @@ It will then attempt to connect to a uinit running in 'tester' mode on 192.168.0 as a server and waits for requests. ### DUT on the controller + Running on the controller is easy: + ``` uinit -m tester ``` On the controller, the program waits for a connection and then starts issuing commands to the device. The controller has the option of calling the following RPC functions: + ``` RPCWelcome - return a welcome message RPCExit - exit the testing mode @@ -61,6 +68,7 @@ RPCSsh - start the sshd ``` Each of these RPCs takes arguments and returns a result, with Welcome being the most fun: + ``` ______________ < welcome to DUT >