1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
|
# StarFive VisionFive2
## Booting
Ideally I would fork StarFive's u-boot fork and add 'native' support for my
kernel, but it turns out that their fork is at the time of writing borked and
I wasn't able to get anything to boot with it. As such, we'll use their prebuilt
bootloader and boot in a more generic way. I've used the binaries downloadable
from https://github.com/starfive-tech/VisionFive2/releases/tag/VF2_v3.0.4,
although newer versions seem to work as well.
The following is how to boot with an SD card. The board seems to support
serial and ethernet booting, but I haven't looked into how they work.
The SD card should have an empty GPT table, you can create one with
`fdisk /dev/sdX/`.
1. Build `kmi` with `GENERIC_UBOOT=1`.
2. Create three partitions on an SD card of your choice:
```
sudo sgdisk \
--new=1:4096:8191 --change-name=1:"spl" --typecode=1:2E54B353-1271-4842-806F-E436D6AF6985 \
--new=2:8192:16383 --change-name=2:"uboot" --typecode=2:5B193300-FC78-40CD-8002-E86C45580B47 \
--new=3:16384:0 --change-name=3:"data" \
/dev/sdX
```
3. Prepare partitions with data from the GitHub release:
```
sudo dd if=u-boot-spl.bin.normal.out of=/dev/sdX1
sudo dd if=visionfive2_fw_payload.img of=/dev/sdX2
sudo mkfs.ext2 /dev/sdX3
```
4. Copy `kmi.bin` and `initrd` to SD card:
```
sudo mount /dev/sdX3 /mnt/sdcard # or wherever
sudo cp kmi.bin arch/riscv64/conf/initrd /mnt/sdcard
sudo umount /mnt/sdcar
sync
```
With the SD card ready to go, reset the device and manually run these commands:
0. `fdt set /cpus/cpu@0 status "disabled"`
1. `fdt move ${fdtaddr} ${fdt_addr_r}`
2. `load mmc 1:3 0x47000000 kmi.bin`
3. `load mmc 1:3 0x48000000 initrd`
4. `fdt chosen 0x48000000 0x48001200`
5. `go 0x47000000 ${fdt_addr_r}`
Disabling `cpu@0` is necessary because it's a control core, and as such doesn't
actually participate in booting, but for whatever reason the device tree that
U-Boot comes with doesn't mark it as such in any way, shape of form. From what I
can tell, Linux and *BSD seem to use their own FDTs with that core disabled.
Might be a good idea.
These commands are pretty hard coded and might not work in the future. At least
currently `${fdt_addr_r}` is `0x46000000`, so you can probably see where the
other addresses come from. Also, the `/chosen` node has to reflect the size of
the `initrd`. Ideally I would like `u-boot` to figure it out itself, but haven't
managed to do so at least yet.
Other things to note:
U-boot likes to skip the `0x` prefix for
hexadecimal values, which can confuse my string converter.
Check that the strings you pass to `go` have their correct prefixes.
Depending on the u-boot version, the `fdt chosen` command either takes
the end address or the size of the `initrd`.
It should be possible to add the above commands to a script to run
automatically, though I haven't personally done this yet.
## Note about running benchmarks on real hardware
Currently there's only a single Big Kernel Lock, which is taken by cores when
they are brought up. This means that if you run a benchmark from `benchmarks/`
'directly' (`START()` needs some extra accomodations to properly handle the
extra threads), the benchmark will spend a lot of its time waiting for other
cores to start running, which has a significant impact on the results. I would
suggest (for now) to just comment out `smp_bringup` in `main`.
|
