[PATCH v4 0/7] riscv: Switch to use generic platform fw_dynamic type opensbi bios images

[PATCH v4 0/7] riscv: Switch to use generic platform fw_dynamic type opensbi bios images

[Bin Meng]

From: Bin Meng <bin.meng@windriver.com>

The RISC-V generic platform is a flattened device tree (FDT) based
platform where all platform specific functionality is provided based
on FDT passed by previous booting stage. The support was added in
the upstream OpenSBI v0.8 release recently.

This series updates QEMU to switch to use generic platform of opensbi
bios images. With the recent fw_dynamic image support, let's replace
the fw_jump images with fw_dynamic ones too.

The patch emails do not contain binary bits, please grab all updates
at https://github.com/lbmeng/qemu.git bios branch.

Changes in v4:
- Remove old binaries in the Makefile for `make install` bisection

Changes in v3:
- Change fw_jump to fw_dynamic in the make rules
- Change to fw_dynamic.bin for virt & sifive_u
- Change to fw_dynamic.elf for Spike
- Generate fw_dynamic images in the artifacts
- change fw_jump to fw_dynamic in the Makefile

Changes in v2:
- new patch: configure: Create symbolic links for pc-bios/*.elf files
- Upgrade OpenSBI to v0.8 release
- Copy the ELF images too in the make rules
- Include ELF images in the artifacts
- new patch: Makefile: Ship the generic platform bios images for RISC-V

Bin Meng (7):
  configure: Create symbolic links for pc-bios/*.elf files
  roms/opensbi: Upgrade from v0.7 to v0.8
  roms/Makefile: Build the generic platform for RISC-V OpenSBI firmware
  hw/riscv: Use pre-built bios image of generic platform for virt &
    sifive_u
  hw/riscv: spike: Change the default bios to use generic platform image
  gitlab-ci/opensbi: Update GitLab CI to build generic platform
  Makefile: Ship the generic platform bios images for RISC-V

 .gitlab-ci.d/opensbi.yml                       |  28 ++++++++--------------
 Makefile                                       |   4 ++--
 configure                                      |   1 +
 hw/riscv/sifive_u.c                            |   4 ++--
 hw/riscv/spike.c                               |   9 +++++--
 hw/riscv/virt.c                                |   4 ++--
 pc-bios/opensbi-riscv32-generic-fw_dynamic.bin | Bin 0 -> 62144 bytes
 pc-bios/opensbi-riscv32-generic-fw_dynamic.elf | Bin 0 -> 558668 bytes
 pc-bios/opensbi-riscv32-sifive_u-fw_jump.bin   | Bin 49520 -> 0 bytes
 pc-bios/opensbi-riscv32-virt-fw_jump.bin       | Bin 49504 -> 0 bytes
 pc-bios/opensbi-riscv64-generic-fw_dynamic.bin | Bin 0 -> 70792 bytes
 pc-bios/opensbi-riscv64-generic-fw_dynamic.elf | Bin 0 -> 620424 bytes
 pc-bios/opensbi-riscv64-sifive_u-fw_jump.bin   | Bin 57936 -> 0 bytes
 pc-bios/opensbi-riscv64-virt-fw_jump.bin       | Bin 57920 -> 0 bytes
 roms/Makefile                                  |  32 ++++++++-----------------
 roms/opensbi                                   |   2 +-
 16 files changed, 35 insertions(+), 49 deletions(-)
 create mode 100644 pc-bios/opensbi-riscv32-generic-fw_dynamic.bin
 create mode 100644 pc-bios/opensbi-riscv32-generic-fw_dynamic.elf
 delete mode 100644 pc-bios/opensbi-riscv32-sifive_u-fw_jump.bin
 delete mode 100644 pc-bios/opensbi-riscv32-virt-fw_jump.bin
 create mode 100644 pc-bios/opensbi-riscv64-generic-fw_dynamic.bin
 create mode 100644 pc-bios/opensbi-riscv64-generic-fw_dynamic.elf
 delete mode 100644 pc-bios/opensbi-riscv64-sifive_u-fw_jump.bin
 delete mode 100644 pc-bios/opensbi-riscv64-virt-fw_jump.bin

-- 
2.7.4

[PATCH v4 1/7] configure: Create symbolic links for pc-bios/*.elf files

[Bin Meng]

From: Bin Meng <bin.meng@windriver.com>

Now we need to ship the OpenSBI fw_dynamic.elf image for the
RISC-V Spike machine, it requires us to create symbolic links
for pc-bios/*.elf files.

Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>

---

(no changes since v2)

Changes in v2:
- new patch: configure: Create symbolic links for pc-bios/*.elf files

 configure | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configure b/configure
index ee6c3c6..36ffe82 100755
--- a/configure
+++ b/configure
@@ -8539,6 +8539,7 @@ LINKS="$LINKS tests/qemu-iotests/check"
 LINKS="$LINKS python"
 for bios_file in \
     $source_path/pc-bios/*.bin \
+    $source_path/pc-bios/*.elf \
     $source_path/pc-bios/*.lid \
     $source_path/pc-bios/*.rom \
     $source_path/pc-bios/*.dtb \
-- 
2.7.4

[PATCH v4 2/7] roms/opensbi: Upgrade from v0.7 to v0.8

[Bin Meng]

From: Bin Meng <bin.meng@windriver.com>

Upgrade OpenSBI from v0.7 to v0.8.

The v0.8 release includes the following commits:

1bb00ab lib: No need to provide default PMP region using platform callbacks
a9eac67 include: sbi_platform: Combine reboot and shutdown into one callback
6585fab lib: utils: Add SiFive test device
4781545 platform: Add Nuclei UX600 platform
3a326af scripts: adapt binary archive script for Nuclei UX600
5bdf022 firmware: fw_base: Remove CSR_MTVEC update check
e6c1345 lib: utils/serial: Skip baudrate config if input frequency is zero
01a8c8e lib: utils: Improve fdt_parse_uart8250() API
0a0093b lib: utils: Add fdt_parse_uart8250_node() function
243b0d0 lib: utils: Remove redundant clint_ipi_sync() declaration
e3ad7c1 lib: utils: Rename fdt_parse_clint() to fdt_parse_compat_addr()
a39cd6f lib: utils: Add FDT match table based node lookup
dd33b9e lib: utils: Make fdt_get_node_addr_size() public function
66185b3 lib: utils: Add fdt_parse_sifive_uart_node() function
19e966b lib: utils: Add fdt_parse_hart_id() function
44dd7be lib: utils: Add fdt_parse_max_hart_id() API
f0eb503 lib: utils: Add fdt_parse_plic_node() function
1ac794c include: Add array_size() macro
8ff2b94 lib: utils: Add simple FDT timer framework
76f0f81 lib: utils: Add simple FDT ipi framework
75322a6 lib: utils: Add simple FDT irqchip framework
76a8940 lib: utils: Add simple FDT serial framework
7cc6fa4 lib: utils: Add simple FDT reset framework
4d06353 firmware: fw_base: Introduce optional fw_platform_init()
f1aa9e5 platform: Add generic FDT based platform support
1f21b99 lib: sbi: Print platform hart count at boot time
2ba7087 scripts: Add generic platform to create-binary-archive.sh
4f18c6e platform: generic: Add Sifive FU540 TLB flush range limit override
13717a8 platform: Remove qemu/virt directory
65c06b0 platform: Remove spike directory
d626037 docs: Add missing links in platform.md
7993ca2 include: sbi: Remove redundant page table related defines
5338679 lib: sbi_tlb: Fix remote TLB HFENCE VVMA implementation
dc38929 lib: sbi: Improve misa_string() implementation
433bac7 docs: platform/generic: Add details about stdout-path DT property
b4efa70 docs: platform/generic: Add details about IPI and timer expectations
dfd9dd6 docs: Add platform requirements document
c2286b6 docs: Fix ordering of pages in table of contents
7be75f5 docs: Don't use italic text in page title
63a513e lib: Rename unprivileged trap handler
aef9a60 lib: Add csr detect support
13ca20d lib: Create a separate math helper function file
79d0fad lib: utils: Update reserved memory fdt node even if PMP is not present
6a053f6 lib: Add support for hart specific features
b2df751 platform: Move platform features to hart
4938024 platform: fpga: Remove redundant platform specific features
ec0d2a7 lib: timer: Provide a hart based timer feature
1f235ec lib: Add platform features in boot time print
22c4334 lib: Add hart features in boot time print
36833ab lib: Optimize inline assembly for unprivilege access functions
38a4b54 firmware: Correct spelling mistakes
28b4052 lib: sbi: detect features before everything else in sbi_hart_init()
4984183 lib: sbi: Improve get_feature_str() implementation and usage
3aa1036 lib: sbi: Remove extra spaces from boot time prints
3a8fc81 lib: sbi: Print platform HART count just before boot HART id
63b0f5f include: sbi: Use scratch pointer as parmeter in HART feature APIs
2966510 lib: sbi: Few cosmetic improvements to HART feature detection
a38bea9 lib: sbi_hart: Detect number of supported PMP regions
89ba634 include: sbi: Add firmware extension constants
73d6ef3 lib: utils: Remove redundant parameters from PLIC init functions
446a9c6 lib: utils: Allow PLIC functions to be used for multiple PLICs
2c685c2 lib: utils: Extend fdt_find_match() Implementation
d30bb68 lib: utils/irqchip: Initialize all matching irqchip DT nodes
a9a9751 lib: utils: Allow CLINT functions to be used for multiple CLINTs
569dd64 lib: utils: Add fdt_parse_clint_node() function
6956e83 lib: utils/ipi: Initialize all matching ipi DT nodes
a63f05f lib: utils/timer: Initialize all matching timer DT nodes
30b6040 Makefile: Fix builtin DTB compilation for out-of-tree platforms
64f1408 firmware: fw_base: Make builtin DTB available to fw_platform_init()
4ce6b7a firmware: fw_base: Don't OR forced FW_OPTIONS
86ec534 firmware: Allow fw_platform_init() to return updated FDT location
c6c65ee Makefile: Preprocess builtin DTS
4e3876d Makefile: Add mechanism for platforms to have multiple builtin DTBs
72019ee platform: kendryte/k210: Use new mechanism of builtin DTB
51f0e4a firmware: Remove FW_PAYLOAD_FDT and related documentation
1b8c012 lib: Add RISC-V hypervisor v0.6.1 support
79bfd67 docs: Use doxygen config to mark the main page
106b888 docs: Remove redundant documentation about combined payload use case
9802906 platform: Add AE350 platform specific SBI handler
32f87e5 platform: Add AE350 cache control SBIs
e2c3f01 lib: Fix __sbi_hfence_gvma_vmid_gpa() and __sbi_hfence_vvma_asid_va()
6966ad0 platform/lib: Allow the OS to map the regions that are protected by PMP
518e85c platform: Update Nuclei ux600 platform support
d5725c2 lib: Don't print delegation CSRs if there is no S-Mode
637b348 lib: Fix the SBI_HART_HAS_MCOUNTEREN feature check
db56ef3 platform: Add support for Shakti C-class SoC from IIT-M
9bd5f8f lib: sbi: Fix 32/64 bits variable compatibility
2314101 lib: Don't return any invalid error from SBI ecall
a98258d include: Bump-up version to 0.8

Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Anup Patel <anup@brainfault.org>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>

---

(no changes since v2)

Changes in v2:
- Upgrade OpenSBI to v0.8 release

 roms/opensbi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/roms/opensbi b/roms/opensbi
index 9f1b72c..a98258d 160000
--- a/roms/opensbi
+++ b/roms/opensbi
@@ -1 +1 @@
-Subproject commit 9f1b72ce66d659e91013b358939e832fb27223f5
+Subproject commit a98258d0b537a295f517bbc8d813007336731fa9
-- 
2.7.4

[PATCH v4 3/7] roms/Makefile: Build the generic platform for RISC-V OpenSBI firmware

[Bin Meng]

From: Bin Meng <bin.meng@windriver.com>

The RISC-V generic platform is a flattened device tree (FDT) based
platform where all platform specific functionality is provided based
on FDT passed by previous booting stage. The support was added in
the upstream OpenSBI v0.8 release recently.

Update our Makefile to build the generic platform instead of building
virt and sifive_u separately for RISC-V OpenSBI firmware, and change
to use fw_dynamic type images as well.

Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Anup Patel <anup@brainfault.org>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>

---

(no changes since v3)

Changes in v3:
- Change fw_jump to fw_dynamic in the make rules

Changes in v2:
- Copy the ELF images too in the make rules

 roms/Makefile | 32 ++++++++++----------------------
 1 file changed, 10 insertions(+), 22 deletions(-)

diff --git a/roms/Makefile b/roms/Makefile
index f9acf39..5d9f15b 100644
--- a/roms/Makefile
+++ b/roms/Makefile
@@ -64,10 +64,8 @@ default help:
 	@echo "  u-boot.e500        -- update u-boot.e500"
 	@echo "  u-boot.sam460      -- update u-boot.sam460"
 	@echo "  efi                -- update UEFI (edk2) platform firmware"
-	@echo "  opensbi32-virt     -- update OpenSBI for 32-bit virt machine"
-	@echo "  opensbi64-virt     -- update OpenSBI for 64-bit virt machine"
-	@echo "  opensbi32-sifive_u -- update OpenSBI for 32-bit sifive_u machine"
-	@echo "  opensbi64-sifive_u -- update OpenSBI for 64-bit sifive_u machine"
+	@echo "  opensbi32-generic  -- update OpenSBI for 32-bit generic machine"
+	@echo "  opensbi64-generic  -- update OpenSBI for 64-bit generic machine"
 	@echo "  bios-microvm       -- update bios-microvm.bin (qboot)"
 	@echo "  clean              -- delete the files generated by the previous" \
 	                              "build targets"
@@ -170,29 +168,19 @@ skiboot:
 efi: edk2-basetools
 	$(MAKE) -f Makefile.edk2
 
-opensbi32-virt:
+opensbi32-generic:
 	$(MAKE) -C opensbi \
 		CROSS_COMPILE=$(riscv32_cross_prefix) \
-		PLATFORM="qemu/virt"
-	cp opensbi/build/platform/qemu/virt/firmware/fw_jump.bin ../pc-bios/opensbi-riscv32-virt-fw_jump.bin
+		PLATFORM="generic"
+	cp opensbi/build/platform/generic/firmware/fw_dynamic.bin ../pc-bios/opensbi-riscv32-generic-fw_dynamic.bin
+	cp opensbi/build/platform/generic/firmware/fw_dynamic.elf ../pc-bios/opensbi-riscv32-generic-fw_dynamic.elf
 
-opensbi64-virt:
+opensbi64-generic:
 	$(MAKE) -C opensbi \
 		CROSS_COMPILE=$(riscv64_cross_prefix) \
-		PLATFORM="qemu/virt"
-	cp opensbi/build/platform/qemu/virt/firmware/fw_jump.bin ../pc-bios/opensbi-riscv64-virt-fw_jump.bin
-
-opensbi32-sifive_u:
-	$(MAKE) -C opensbi \
-		CROSS_COMPILE=$(riscv32_cross_prefix) \
-		PLATFORM="sifive/fu540"
-	cp opensbi/build/platform/sifive/fu540/firmware/fw_jump.bin ../pc-bios/opensbi-riscv32-sifive_u-fw_jump.bin
-
-opensbi64-sifive_u:
-	$(MAKE) -C opensbi \
-		CROSS_COMPILE=$(riscv64_cross_prefix) \
-		PLATFORM="sifive/fu540"
-	cp opensbi/build/platform/sifive/fu540/firmware/fw_jump.bin ../pc-bios/opensbi-riscv64-sifive_u-fw_jump.bin
+		PLATFORM="generic"
+	cp opensbi/build/platform/generic/firmware/fw_dynamic.bin ../pc-bios/opensbi-riscv64-generic-fw_dynamic.bin
+	cp opensbi/build/platform/generic/firmware/fw_dynamic.elf ../pc-bios/opensbi-riscv64-generic-fw_dynamic.elf
 
 bios-microvm:
 	$(MAKE) -C qboot
-- 
2.7.4

[PATCH v4 4/7] hw/riscv: Use pre-built bios image of generic platform for virt & sifive_u

[Bin Meng]

From: Bin Meng <bin.meng@windriver.com>

Update virt and sifive_u machines to use the opensbi fw_dynamic bios
image built for the generic FDT platform.

Remove the out-of-date no longer used bios images.

Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Anup Patel <anup@brainfault.org>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>

---

Changes in v4:
- Remove old binaries in the Makefile for `make install` bisection

Changes in v3:
- Change to fw_dynamic.bin for virt & sifive_u

 Makefile                                       |   4 +---
 hw/riscv/sifive_u.c                            |   4 ++--
 hw/riscv/virt.c                                |   4 ++--
 pc-bios/opensbi-riscv32-generic-fw_dynamic.bin | Bin 0 -> 62144 bytes
 pc-bios/opensbi-riscv32-sifive_u-fw_jump.bin   | Bin 49520 -> 0 bytes
 pc-bios/opensbi-riscv32-virt-fw_jump.bin       | Bin 49504 -> 0 bytes
 pc-bios/opensbi-riscv64-generic-fw_dynamic.bin | Bin 0 -> 70792 bytes
 pc-bios/opensbi-riscv64-sifive_u-fw_jump.bin   | Bin 57936 -> 0 bytes
 pc-bios/opensbi-riscv64-virt-fw_jump.bin       | Bin 57920 -> 0 bytes
 9 files changed, 5 insertions(+), 7 deletions(-)
 create mode 100644 pc-bios/opensbi-riscv32-generic-fw_dynamic.bin
 delete mode 100644 pc-bios/opensbi-riscv32-sifive_u-fw_jump.bin
 delete mode 100644 pc-bios/opensbi-riscv32-virt-fw_jump.bin
 create mode 100644 pc-bios/opensbi-riscv64-generic-fw_dynamic.bin
 delete mode 100644 pc-bios/opensbi-riscv64-sifive_u-fw_jump.bin
 delete mode 100644 pc-bios/opensbi-riscv64-virt-fw_jump.bin

diff --git a/Makefile b/Makefile
index b1b8a5a..f06b3ae 100644
--- a/Makefile
+++ b/Makefile
@@ -840,9 +840,7 @@ palcode-clipper \
 u-boot.e500 u-boot-sam460-20100605.bin \
 qemu_vga.ndrv \
 edk2-licenses.txt \
-hppa-firmware.img \
-opensbi-riscv32-sifive_u-fw_jump.bin opensbi-riscv32-virt-fw_jump.bin \
-opensbi-riscv64-sifive_u-fw_jump.bin opensbi-riscv64-virt-fw_jump.bin
+hppa-firmware.img
 
 
 DESCS=50-edk2-i386-secure.json 50-edk2-x86_64-secure.json \
diff --git a/hw/riscv/sifive_u.c b/hw/riscv/sifive_u.c
index b434fd3..dc46f64 100644
--- a/hw/riscv/sifive_u.c
+++ b/hw/riscv/sifive_u.c
@@ -60,9 +60,9 @@
 #include <libfdt.h>
 
 #if defined(TARGET_RISCV32)
-# define BIOS_FILENAME "opensbi-riscv32-sifive_u-fw_jump.bin"
+# define BIOS_FILENAME "opensbi-riscv32-generic-fw_dynamic.bin"
 #else
-# define BIOS_FILENAME "opensbi-riscv64-sifive_u-fw_jump.bin"
+# define BIOS_FILENAME "opensbi-riscv64-generic-fw_dynamic.bin"
 #endif
 
 static const struct MemmapEntry {
diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
index 85e17fe..5ca49c5 100644
--- a/hw/riscv/virt.c
+++ b/hw/riscv/virt.c
@@ -43,9 +43,9 @@
 #include "hw/pci-host/gpex.h"
 
 #if defined(TARGET_RISCV32)
-# define BIOS_FILENAME "opensbi-riscv32-virt-fw_jump.bin"
+# define BIOS_FILENAME "opensbi-riscv32-generic-fw_dynamic.bin"
 #else
-# define BIOS_FILENAME "opensbi-riscv64-virt-fw_jump.bin"
+# define BIOS_FILENAME "opensbi-riscv64-generic-fw_dynamic.bin"
 #endif
 
 static const struct MemmapEntry {
diff --git a/pc-bios/opensbi-riscv32-generic-fw_dynamic.bin b/pc-bios/opensbi-riscv32-generic-fw_dynamic.bin
new file mode 100644
index 0000000..23b4dfb
Binary files /dev/null and b/pc-bios/opensbi-riscv32-generic-fw_dynamic.bin differ
diff --git a/pc-bios/opensbi-riscv32-sifive_u-fw_jump.bin b/pc-bios/opensbi-riscv32-sifive_u-fw_jump.bin
deleted file mode 100644
index 3e0da54..0000000
Binary files a/pc-bios/opensbi-riscv32-sifive_u-fw_jump.bin and /dev/null differ
diff --git a/pc-bios/opensbi-riscv32-virt-fw_jump.bin b/pc-bios/opensbi-riscv32-virt-fw_jump.bin
deleted file mode 100644
index bc56ed6..0000000
Binary files a/pc-bios/opensbi-riscv32-virt-fw_jump.bin and /dev/null differ
diff --git a/pc-bios/opensbi-riscv64-generic-fw_dynamic.bin b/pc-bios/opensbi-riscv64-generic-fw_dynamic.bin
new file mode 100644
index 0000000..16c0cf4
Binary files /dev/null and b/pc-bios/opensbi-riscv64-generic-fw_dynamic.bin differ
diff --git a/pc-bios/opensbi-riscv64-sifive_u-fw_jump.bin b/pc-bios/opensbi-riscv64-sifive_u-fw_jump.bin
deleted file mode 100644
index 1acee86..0000000
Binary files a/pc-bios/opensbi-riscv64-sifive_u-fw_jump.bin and /dev/null differ
diff --git a/pc-bios/opensbi-riscv64-virt-fw_jump.bin b/pc-bios/opensbi-riscv64-virt-fw_jump.bin
deleted file mode 100644
index c62f2b4..0000000
Binary files a/pc-bios/opensbi-riscv64-virt-fw_jump.bin and /dev/null differ
-- 
2.7.4

[PATCH v4 5/7] hw/riscv: spike: Change the default bios to use generic platform image

[Bin Meng]

From: Bin Meng <bin.meng@windriver.com>

To keep sync with other RISC-V machines, change the default bios to
use generic platform fw_dynamic.elf image.

While we are here, add some comments to mention that using ELF files
for the Spike machine was intentional.

Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Anup Patel <anup@brainfault.org>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>

---

(no changes since v3)

Changes in v3:
- Change to fw_dynamic.elf for Spike

 hw/riscv/spike.c                               |   9 +++++++--
 pc-bios/opensbi-riscv32-generic-fw_dynamic.elf | Bin 0 -> 558668 bytes
 pc-bios/opensbi-riscv64-generic-fw_dynamic.elf | Bin 0 -> 620424 bytes
 3 files changed, 7 insertions(+), 2 deletions(-)
 create mode 100644 pc-bios/opensbi-riscv32-generic-fw_dynamic.elf
 create mode 100644 pc-bios/opensbi-riscv64-generic-fw_dynamic.elf

diff --git a/hw/riscv/spike.c b/hw/riscv/spike.c
index b295a43..a187aa3 100644
--- a/hw/riscv/spike.c
+++ b/hw/riscv/spike.c
@@ -42,10 +42,15 @@
 #include "sysemu/qtest.h"
 #include "sysemu/sysemu.h"
 
+/*
+ * Not like other RISC-V machines that use plain binary bios images,
+ * keeping ELF files here was intentional because BIN files don't work
+ * for the Spike machine as HTIF emulation depends on ELF parsing.
+ */
 #if defined(TARGET_RISCV32)
-# define BIOS_FILENAME "opensbi-riscv32-spike-fw_jump.elf"
+# define BIOS_FILENAME "opensbi-riscv32-generic-fw_dynamic.elf"
 #else
-# define BIOS_FILENAME "opensbi-riscv64-spike-fw_jump.elf"
+# define BIOS_FILENAME "opensbi-riscv64-generic-fw_dynamic.elf"
 #endif
 
 static const struct MemmapEntry {
diff --git a/pc-bios/opensbi-riscv32-generic-fw_dynamic.elf b/pc-bios/opensbi-riscv32-generic-fw_dynamic.elf
new file mode 100644
index 0000000..eb9ebf5
Binary files /dev/null and b/pc-bios/opensbi-riscv32-generic-fw_dynamic.elf differ
diff --git a/pc-bios/opensbi-riscv64-generic-fw_dynamic.elf b/pc-bios/opensbi-riscv64-generic-fw_dynamic.elf
new file mode 100644
index 0000000..642a64e
Binary files /dev/null and b/pc-bios/opensbi-riscv64-generic-fw_dynamic.elf differ
-- 
2.7.4

[PATCH v4 6/7] gitlab-ci/opensbi: Update GitLab CI to build generic platform

[Bin Meng]

From: Bin Meng <bin.meng@windriver.com>

This updates the GitLab CI opensbi job to build opensbi bios images
for the generic platform.

Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Anup Patel <anup@brainfault.org>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>

---

(no changes since v3)

Changes in v3:
- Generate fw_dynamic images in the artifacts

Changes in v2:
- Include ELF images in the artifacts

 .gitlab-ci.d/opensbi.yml | 28 ++++++++++------------------
 1 file changed, 10 insertions(+), 18 deletions(-)

diff --git a/.gitlab-ci.d/opensbi.yml b/.gitlab-ci.d/opensbi.yml
index dd051c0..fd9eed4 100644
--- a/.gitlab-ci.d/opensbi.yml
+++ b/.gitlab-ci.d/opensbi.yml
@@ -34,18 +34,14 @@ build-opensbi:
    when: always
  artifacts:
    paths: # 'artifacts.zip' will contains the following files:
-   - pc-bios/opensbi-riscv32-sifive_u-fw_jump.bin
-   - pc-bios/opensbi-riscv32-virt-fw_jump.bin
-   - pc-bios/opensbi-riscv64-sifive_u-fw_jump.bin
-   - pc-bios/opensbi-riscv64-virt-fw_jump.bin
-   - opensbi32-virt-stdout.log
-   - opensbi32-virt-stderr.log
-   - opensbi64-virt-stdout.log
-   - opensbi64-virt-stderr.log
-   - opensbi32-sifive_u-stdout.log
-   - opensbi32-sifive_u-stderr.log
-   - opensbi64-sifive_u-stdout.log
-   - opensbi64-sifive_u-stderr.log
+   - pc-bios/opensbi-riscv32-generic-fw_dynamic.bin
+   - pc-bios/opensbi-riscv32-generic-fw_dynamic.elf
+   - pc-bios/opensbi-riscv64-generic-fw_dynamic.bin
+   - pc-bios/opensbi-riscv64-generic-fw_dynamic.elf
+   - opensbi32-generic-stdout.log
+   - opensbi32-generic-stderr.log
+   - opensbi64-generic-stdout.log
+   - opensbi64-generic-stderr.log
  image: $CI_REGISTRY_IMAGE:opensbi-cross-build
  variables:
    GIT_DEPTH: 3
@@ -54,10 +50,6 @@ build-opensbi:
  - export JOBS=$(($(getconf _NPROCESSORS_ONLN) + 1))
  - echo "=== Using ${JOBS} simultaneous jobs ==="
  - make -j${JOBS} -C roms/opensbi clean
- - make -j${JOBS} -C roms opensbi32-virt 2>&1 1>opensbi32-virt-stdout.log | tee -a opensbi32-virt-stderr.log >&2
+ - make -j${JOBS} -C roms opensbi32-generic 2>&1 1>opensbi32-generic-stdout.log | tee -a opensbi32-generic-stderr.log >&2
  - make -j${JOBS} -C roms/opensbi clean
- - make -j${JOBS} -C roms opensbi64-virt 2>&1 1>opensbi64-virt-stdout.log | tee -a opensbi64-virt-stderr.log >&2
- - make -j${JOBS} -C roms/opensbi clean
- - make -j${JOBS} -C roms opensbi32-sifive_u 2>&1 1>opensbi32-sifive_u-stdout.log | tee -a opensbi32-sifive_u-stderr.log >&2
- - make -j${JOBS} -C roms/opensbi clean
- - make -j${JOBS} -C roms opensbi64-sifive_u 2>&1 1>opensbi64-sifive_u-stdout.log | tee -a opensbi64-sifive_u-stderr.log >&2
+ - make -j${JOBS} -C roms opensbi64-generic 2>&1 1>opensbi64-generic-stdout.log | tee -a opensbi64-generic-stderr.log >&2
-- 
2.7.4

[PATCH v4 7/7] Makefile: Ship the generic platform bios images for RISC-V

[Bin Meng]

From: Bin Meng <bin.meng@windriver.com>

Update the install blob list to include the generic platform
fw_dynamic bios images.

Signed-off-by: Bin Meng <bin.meng@windriver.com>

---

(no changes since v3)

Changes in v3:
- change fw_jump to fw_dynamic in the Makefile

Changes in v2:
- new patch: Makefile: Ship the generic platform bios images for RISC-V

 Makefile | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index f06b3ae..05e05bb 100644
--- a/Makefile
+++ b/Makefile
@@ -840,7 +840,9 @@ palcode-clipper \
 u-boot.e500 u-boot-sam460-20100605.bin \
 qemu_vga.ndrv \
 edk2-licenses.txt \
-hppa-firmware.img
+hppa-firmware.img \
+opensbi-riscv32-generic-fw_dynamic.bin opensbi-riscv32-generic-fw_dynamic.elf \
+opensbi-riscv64-generic-fw_dynamic.bin opensbi-riscv64-generic-fw_dynamic.elf
 
 
 DESCS=50-edk2-i386-secure.json 50-edk2-x86_64-secure.json \
-- 
2.7.4

Re: [PATCH v4 7/7] Makefile: Ship the generic platform bios images for RISC-V

[Alistair Francis]

On Thu, Jul 9, 2020 at 10:11 PM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> From: Bin Meng <bin.meng@windriver.com>
>
> Update the install blob list to include the generic platform
> fw_dynamic bios images.
>
> Signed-off-by: Bin Meng <bin.meng@windriver.com>

You didn't address the comments in v3.

Thinking about this more though it looks like we currently don't
install anything, so this is an improvement.

Reviewed-by: Alistair Francis <alistair.francis@wdc.com>

Alistair

>
> ---
>
> (no changes since v3)
>
> Changes in v3:
> - change fw_jump to fw_dynamic in the Makefile
>
> Changes in v2:
> - new patch: Makefile: Ship the generic platform bios images for RISC-V
>
>  Makefile | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index f06b3ae..05e05bb 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -840,7 +840,9 @@ palcode-clipper \
>  u-boot.e500 u-boot-sam460-20100605.bin \
>  qemu_vga.ndrv \
>  edk2-licenses.txt \
> -hppa-firmware.img
> +hppa-firmware.img \
> +opensbi-riscv32-generic-fw_dynamic.bin opensbi-riscv32-generic-fw_dynamic.elf \
> +opensbi-riscv64-generic-fw_dynamic.bin opensbi-riscv64-generic-fw_dynamic.elf
>
>
>  DESCS=50-edk2-i386-secure.json 50-edk2-x86_64-secure.json \
> --
> 2.7.4
>
>

Re: [PATCH v4 7/7] Makefile: Ship the generic platform bios images for RISC-V

[Alistair Francis]

On Thu, Jul 9, 2020 at 10:11 PM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> From: Bin Meng <bin.meng@windriver.com>
>
> Update the install blob list to include the generic platform
> fw_dynamic bios images.
>
> Signed-off-by: Bin Meng <bin.meng@windriver.com>

You didn't address the comments in v3.

Thinking about this more though it looks like we currently don't
install anything, so this is an improvement.

Reviewed-by: Alistair Francis <alistair.francis@wdc.com>

Alistair

>
> ---
>
> (no changes since v3)
>
> Changes in v3:
> - change fw_jump to fw_dynamic in the Makefile
>
> Changes in v2:
> - new patch: Makefile: Ship the generic platform bios images for RISC-V
>
>  Makefile | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index f06b3ae..05e05bb 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -840,7 +840,9 @@ palcode-clipper \
>  u-boot.e500 u-boot-sam460-20100605.bin \
>  qemu_vga.ndrv \
>  edk2-licenses.txt \
> -hppa-firmware.img
> +hppa-firmware.img \
> +opensbi-riscv32-generic-fw_dynamic.bin opensbi-riscv32-generic-fw_dynamic.elf \
> +opensbi-riscv64-generic-fw_dynamic.bin opensbi-riscv64-generic-fw_dynamic.elf
>
>
>  DESCS=50-edk2-i386-secure.json 50-edk2-x86_64-secure.json \
> --
> 2.7.4
>
>

Re: [PATCH v4 0/7] riscv: Switch to use generic platform fw_dynamic type opensbi bios images

[Alistair Francis]

On Thu, Jul 9, 2020 at 10:05 PM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> From: Bin Meng <bin.meng@windriver.com>
>
> The RISC-V generic platform is a flattened device tree (FDT) based
> platform where all platform specific functionality is provided based
> on FDT passed by previous booting stage. The support was added in
> the upstream OpenSBI v0.8 release recently.
>
> This series updates QEMU to switch to use generic platform of opensbi
> bios images. With the recent fw_dynamic image support, let's replace
> the fw_jump images with fw_dynamic ones too.
>
> The patch emails do not contain binary bits, please grab all updates
> at https://github.com/lbmeng/qemu.git bios branch.
>
> Changes in v4:
> - Remove old binaries in the Makefile for `make install` bisection
>
> Changes in v3:
> - Change fw_jump to fw_dynamic in the make rules
> - Change to fw_dynamic.bin for virt & sifive_u
> - Change to fw_dynamic.elf for Spike
> - Generate fw_dynamic images in the artifacts
> - change fw_jump to fw_dynamic in the Makefile
>
> Changes in v2:
> - new patch: configure: Create symbolic links for pc-bios/*.elf files
> - Upgrade OpenSBI to v0.8 release
> - Copy the ELF images too in the make rules
> - Include ELF images in the artifacts
> - new patch: Makefile: Ship the generic platform bios images for RISC-V
>
> Bin Meng (7):
>   configure: Create symbolic links for pc-bios/*.elf files
>   roms/opensbi: Upgrade from v0.7 to v0.8
>   roms/Makefile: Build the generic platform for RISC-V OpenSBI firmware
>   hw/riscv: Use pre-built bios image of generic platform for virt &
>     sifive_u
>   hw/riscv: spike: Change the default bios to use generic platform image
>   gitlab-ci/opensbi: Update GitLab CI to build generic platform
>   Makefile: Ship the generic platform bios images for RISC-V

Reviewed-by: Alistair Francis <alistair.francis@wdc.com>

Alistair

>
>  .gitlab-ci.d/opensbi.yml                       |  28 ++++++++--------------
>  Makefile                                       |   4 ++--
>  configure                                      |   1 +
>  hw/riscv/sifive_u.c                            |   4 ++--
>  hw/riscv/spike.c                               |   9 +++++--
>  hw/riscv/virt.c                                |   4 ++--
>  pc-bios/opensbi-riscv32-generic-fw_dynamic.bin | Bin 0 -> 62144 bytes
>  pc-bios/opensbi-riscv32-generic-fw_dynamic.elf | Bin 0 -> 558668 bytes
>  pc-bios/opensbi-riscv32-sifive_u-fw_jump.bin   | Bin 49520 -> 0 bytes
>  pc-bios/opensbi-riscv32-virt-fw_jump.bin       | Bin 49504 -> 0 bytes
>  pc-bios/opensbi-riscv64-generic-fw_dynamic.bin | Bin 0 -> 70792 bytes
>  pc-bios/opensbi-riscv64-generic-fw_dynamic.elf | Bin 0 -> 620424 bytes
>  pc-bios/opensbi-riscv64-sifive_u-fw_jump.bin   | Bin 57936 -> 0 bytes
>  pc-bios/opensbi-riscv64-virt-fw_jump.bin       | Bin 57920 -> 0 bytes
>  roms/Makefile                                  |  32 ++++++++-----------------
>  roms/opensbi                                   |   2 +-
>  16 files changed, 35 insertions(+), 49 deletions(-)
>  create mode 100644 pc-bios/opensbi-riscv32-generic-fw_dynamic.bin
>  create mode 100644 pc-bios/opensbi-riscv32-generic-fw_dynamic.elf
>  delete mode 100644 pc-bios/opensbi-riscv32-sifive_u-fw_jump.bin
>  delete mode 100644 pc-bios/opensbi-riscv32-virt-fw_jump.bin
>  create mode 100644 pc-bios/opensbi-riscv64-generic-fw_dynamic.bin
>  create mode 100644 pc-bios/opensbi-riscv64-generic-fw_dynamic.elf
>  delete mode 100644 pc-bios/opensbi-riscv64-sifive_u-fw_jump.bin
>  delete mode 100644 pc-bios/opensbi-riscv64-virt-fw_jump.bin
>
> --
> 2.7.4
>
>

Re: [PATCH v4 0/7] riscv: Switch to use generic platform fw_dynamic type opensbi bios images

[Alistair Francis]

On Thu, Jul 9, 2020 at 10:05 PM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> From: Bin Meng <bin.meng@windriver.com>
>
> The RISC-V generic platform is a flattened device tree (FDT) based
> platform where all platform specific functionality is provided based
> on FDT passed by previous booting stage. The support was added in
> the upstream OpenSBI v0.8 release recently.
>
> This series updates QEMU to switch to use generic platform of opensbi
> bios images. With the recent fw_dynamic image support, let's replace
> the fw_jump images with fw_dynamic ones too.
>
> The patch emails do not contain binary bits, please grab all updates
> at https://github.com/lbmeng/qemu.git bios branch.
>
> Changes in v4:
> - Remove old binaries in the Makefile for `make install` bisection
>
> Changes in v3:
> - Change fw_jump to fw_dynamic in the make rules
> - Change to fw_dynamic.bin for virt & sifive_u
> - Change to fw_dynamic.elf for Spike
> - Generate fw_dynamic images in the artifacts
> - change fw_jump to fw_dynamic in the Makefile
>
> Changes in v2:
> - new patch: configure: Create symbolic links for pc-bios/*.elf files
> - Upgrade OpenSBI to v0.8 release
> - Copy the ELF images too in the make rules
> - Include ELF images in the artifacts
> - new patch: Makefile: Ship the generic platform bios images for RISC-V
>
> Bin Meng (7):
>   configure: Create symbolic links for pc-bios/*.elf files
>   roms/opensbi: Upgrade from v0.7 to v0.8
>   roms/Makefile: Build the generic platform for RISC-V OpenSBI firmware
>   hw/riscv: Use pre-built bios image of generic platform for virt &
>     sifive_u
>   hw/riscv: spike: Change the default bios to use generic platform image
>   gitlab-ci/opensbi: Update GitLab CI to build generic platform
>   Makefile: Ship the generic platform bios images for RISC-V

Reviewed-by: Alistair Francis <alistair.francis@wdc.com>

Alistair

>
>  .gitlab-ci.d/opensbi.yml                       |  28 ++++++++--------------
>  Makefile                                       |   4 ++--
>  configure                                      |   1 +
>  hw/riscv/sifive_u.c                            |   4 ++--
>  hw/riscv/spike.c                               |   9 +++++--
>  hw/riscv/virt.c                                |   4 ++--
>  pc-bios/opensbi-riscv32-generic-fw_dynamic.bin | Bin 0 -> 62144 bytes
>  pc-bios/opensbi-riscv32-generic-fw_dynamic.elf | Bin 0 -> 558668 bytes
>  pc-bios/opensbi-riscv32-sifive_u-fw_jump.bin   | Bin 49520 -> 0 bytes
>  pc-bios/opensbi-riscv32-virt-fw_jump.bin       | Bin 49504 -> 0 bytes
>  pc-bios/opensbi-riscv64-generic-fw_dynamic.bin | Bin 0 -> 70792 bytes
>  pc-bios/opensbi-riscv64-generic-fw_dynamic.elf | Bin 0 -> 620424 bytes
>  pc-bios/opensbi-riscv64-sifive_u-fw_jump.bin   | Bin 57936 -> 0 bytes
>  pc-bios/opensbi-riscv64-virt-fw_jump.bin       | Bin 57920 -> 0 bytes
>  roms/Makefile                                  |  32 ++++++++-----------------
>  roms/opensbi                                   |   2 +-
>  16 files changed, 35 insertions(+), 49 deletions(-)
>  create mode 100644 pc-bios/opensbi-riscv32-generic-fw_dynamic.bin
>  create mode 100644 pc-bios/opensbi-riscv32-generic-fw_dynamic.elf
>  delete mode 100644 pc-bios/opensbi-riscv32-sifive_u-fw_jump.bin
>  delete mode 100644 pc-bios/opensbi-riscv32-virt-fw_jump.bin
>  create mode 100644 pc-bios/opensbi-riscv64-generic-fw_dynamic.bin
>  create mode 100644 pc-bios/opensbi-riscv64-generic-fw_dynamic.elf
>  delete mode 100644 pc-bios/opensbi-riscv64-sifive_u-fw_jump.bin
>  delete mode 100644 pc-bios/opensbi-riscv64-virt-fw_jump.bin
>
> --
> 2.7.4
>
>

Re: [PATCH v4 0/7] riscv: Switch to use generic platform fw_dynamic type opensbi bios images

[Alistair Francis]

On Fri, Jul 10, 2020 at 11:59 AM Alistair Francis <alistair23@gmail.com> wrote:
>
> On Thu, Jul 9, 2020 at 10:05 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > From: Bin Meng <bin.meng@windriver.com>
> >
> > The RISC-V generic platform is a flattened device tree (FDT) based
> > platform where all platform specific functionality is provided based
> > on FDT passed by previous booting stage. The support was added in
> > the upstream OpenSBI v0.8 release recently.
> >
> > This series updates QEMU to switch to use generic platform of opensbi
> > bios images. With the recent fw_dynamic image support, let's replace
> > the fw_jump images with fw_dynamic ones too.
> >
> > The patch emails do not contain binary bits, please grab all updates
> > at https://github.com/lbmeng/qemu.git bios branch.
> >
> > Changes in v4:
> > - Remove old binaries in the Makefile for `make install` bisection
> >
> > Changes in v3:
> > - Change fw_jump to fw_dynamic in the make rules
> > - Change to fw_dynamic.bin for virt & sifive_u
> > - Change to fw_dynamic.elf for Spike
> > - Generate fw_dynamic images in the artifacts
> > - change fw_jump to fw_dynamic in the Makefile
> >
> > Changes in v2:
> > - new patch: configure: Create symbolic links for pc-bios/*.elf files
> > - Upgrade OpenSBI to v0.8 release
> > - Copy the ELF images too in the make rules
> > - Include ELF images in the artifacts
> > - new patch: Makefile: Ship the generic platform bios images for RISC-V
> >
> > Bin Meng (7):
> >   configure: Create symbolic links for pc-bios/*.elf files
> >   roms/opensbi: Upgrade from v0.7 to v0.8
> >   roms/Makefile: Build the generic platform for RISC-V OpenSBI firmware
> >   hw/riscv: Use pre-built bios image of generic platform for virt &
> >     sifive_u
> >   hw/riscv: spike: Change the default bios to use generic platform image
> >   gitlab-ci/opensbi: Update GitLab CI to build generic platform
> >   Makefile: Ship the generic platform bios images for RISC-V
>
> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>

Whoops, wrong canned response.

Thanks!

Applied to riscv-to-apply.next

Alistair

>
> Alistair
>
> >
> >  .gitlab-ci.d/opensbi.yml                       |  28 ++++++++--------------
> >  Makefile                                       |   4 ++--
> >  configure                                      |   1 +
> >  hw/riscv/sifive_u.c                            |   4 ++--
> >  hw/riscv/spike.c                               |   9 +++++--
> >  hw/riscv/virt.c                                |   4 ++--
> >  pc-bios/opensbi-riscv32-generic-fw_dynamic.bin | Bin 0 -> 62144 bytes
> >  pc-bios/opensbi-riscv32-generic-fw_dynamic.elf | Bin 0 -> 558668 bytes
> >  pc-bios/opensbi-riscv32-sifive_u-fw_jump.bin   | Bin 49520 -> 0 bytes
> >  pc-bios/opensbi-riscv32-virt-fw_jump.bin       | Bin 49504 -> 0 bytes
> >  pc-bios/opensbi-riscv64-generic-fw_dynamic.bin | Bin 0 -> 70792 bytes
> >  pc-bios/opensbi-riscv64-generic-fw_dynamic.elf | Bin 0 -> 620424 bytes
> >  pc-bios/opensbi-riscv64-sifive_u-fw_jump.bin   | Bin 57936 -> 0 bytes
> >  pc-bios/opensbi-riscv64-virt-fw_jump.bin       | Bin 57920 -> 0 bytes
> >  roms/Makefile                                  |  32 ++++++++-----------------
> >  roms/opensbi                                   |   2 +-
> >  16 files changed, 35 insertions(+), 49 deletions(-)
> >  create mode 100644 pc-bios/opensbi-riscv32-generic-fw_dynamic.bin
> >  create mode 100644 pc-bios/opensbi-riscv32-generic-fw_dynamic.elf
> >  delete mode 100644 pc-bios/opensbi-riscv32-sifive_u-fw_jump.bin
> >  delete mode 100644 pc-bios/opensbi-riscv32-virt-fw_jump.bin
> >  create mode 100644 pc-bios/opensbi-riscv64-generic-fw_dynamic.bin
> >  create mode 100644 pc-bios/opensbi-riscv64-generic-fw_dynamic.elf
> >  delete mode 100644 pc-bios/opensbi-riscv64-sifive_u-fw_jump.bin
> >  delete mode 100644 pc-bios/opensbi-riscv64-virt-fw_jump.bin
> >
> > --
> > 2.7.4
> >
> >

Re: [PATCH v4 0/7] riscv: Switch to use generic platform fw_dynamic type opensbi bios images

[Alistair Francis]

On Fri, Jul 10, 2020 at 11:59 AM Alistair Francis <alistair23@gmail.com> wrote:
>
> On Thu, Jul 9, 2020 at 10:05 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > From: Bin Meng <bin.meng@windriver.com>
> >
> > The RISC-V generic platform is a flattened device tree (FDT) based
> > platform where all platform specific functionality is provided based
> > on FDT passed by previous booting stage. The support was added in
> > the upstream OpenSBI v0.8 release recently.
> >
> > This series updates QEMU to switch to use generic platform of opensbi
> > bios images. With the recent fw_dynamic image support, let's replace
> > the fw_jump images with fw_dynamic ones too.
> >
> > The patch emails do not contain binary bits, please grab all updates
> > at https://github.com/lbmeng/qemu.git bios branch.
> >
> > Changes in v4:
> > - Remove old binaries in the Makefile for `make install` bisection
> >
> > Changes in v3:
> > - Change fw_jump to fw_dynamic in the make rules
> > - Change to fw_dynamic.bin for virt & sifive_u
> > - Change to fw_dynamic.elf for Spike
> > - Generate fw_dynamic images in the artifacts
> > - change fw_jump to fw_dynamic in the Makefile
> >
> > Changes in v2:
> > - new patch: configure: Create symbolic links for pc-bios/*.elf files
> > - Upgrade OpenSBI to v0.8 release
> > - Copy the ELF images too in the make rules
> > - Include ELF images in the artifacts
> > - new patch: Makefile: Ship the generic platform bios images for RISC-V
> >
> > Bin Meng (7):
> >   configure: Create symbolic links for pc-bios/*.elf files
> >   roms/opensbi: Upgrade from v0.7 to v0.8
> >   roms/Makefile: Build the generic platform for RISC-V OpenSBI firmware
> >   hw/riscv: Use pre-built bios image of generic platform for virt &
> >     sifive_u
> >   hw/riscv: spike: Change the default bios to use generic platform image
> >   gitlab-ci/opensbi: Update GitLab CI to build generic platform
> >   Makefile: Ship the generic platform bios images for RISC-V
>
> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>

Whoops, wrong canned response.

Thanks!

Applied to riscv-to-apply.next

Alistair

>
> Alistair
>
> >
> >  .gitlab-ci.d/opensbi.yml                       |  28 ++++++++--------------
> >  Makefile                                       |   4 ++--
> >  configure                                      |   1 +
> >  hw/riscv/sifive_u.c                            |   4 ++--
> >  hw/riscv/spike.c                               |   9 +++++--
> >  hw/riscv/virt.c                                |   4 ++--
> >  pc-bios/opensbi-riscv32-generic-fw_dynamic.bin | Bin 0 -> 62144 bytes
> >  pc-bios/opensbi-riscv32-generic-fw_dynamic.elf | Bin 0 -> 558668 bytes
> >  pc-bios/opensbi-riscv32-sifive_u-fw_jump.bin   | Bin 49520 -> 0 bytes
> >  pc-bios/opensbi-riscv32-virt-fw_jump.bin       | Bin 49504 -> 0 bytes
> >  pc-bios/opensbi-riscv64-generic-fw_dynamic.bin | Bin 0 -> 70792 bytes
> >  pc-bios/opensbi-riscv64-generic-fw_dynamic.elf | Bin 0 -> 620424 bytes
> >  pc-bios/opensbi-riscv64-sifive_u-fw_jump.bin   | Bin 57936 -> 0 bytes
> >  pc-bios/opensbi-riscv64-virt-fw_jump.bin       | Bin 57920 -> 0 bytes
> >  roms/Makefile                                  |  32 ++++++++-----------------
> >  roms/opensbi                                   |   2 +-
> >  16 files changed, 35 insertions(+), 49 deletions(-)
> >  create mode 100644 pc-bios/opensbi-riscv32-generic-fw_dynamic.bin
> >  create mode 100644 pc-bios/opensbi-riscv32-generic-fw_dynamic.elf
> >  delete mode 100644 pc-bios/opensbi-riscv32-sifive_u-fw_jump.bin
> >  delete mode 100644 pc-bios/opensbi-riscv32-virt-fw_jump.bin
> >  create mode 100644 pc-bios/opensbi-riscv64-generic-fw_dynamic.bin
> >  create mode 100644 pc-bios/opensbi-riscv64-generic-fw_dynamic.elf
> >  delete mode 100644 pc-bios/opensbi-riscv64-sifive_u-fw_jump.bin
> >  delete mode 100644 pc-bios/opensbi-riscv64-virt-fw_jump.bin
> >
> > --
> > 2.7.4
> >
> >

Re: [PATCH v4 7/7] Makefile: Ship the generic platform bios images for RISC-V

[Alistair Francis]

On Fri, Jul 10, 2020 at 11:36 AM Alistair Francis <alistair23@gmail.com> wrote:
>
> On Thu, Jul 9, 2020 at 10:11 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > From: Bin Meng <bin.meng@windriver.com>
> >
> > Update the install blob list to include the generic platform
> > fw_dynamic bios images.
> >
> > Signed-off-by: Bin Meng <bin.meng@windriver.com>
>
> You didn't address the comments in v3.
>
> Thinking about this more though it looks like we currently don't
> install anything, so this is an improvement.
>
> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>

Nope, I was wrong. This should be squashed into patch 4 where you
remove the installed binaries.

Alistair

>
> Alistair
>
> >
> > ---
> >
> > (no changes since v3)
> >
> > Changes in v3:
> > - change fw_jump to fw_dynamic in the Makefile
> >
> > Changes in v2:
> > - new patch: Makefile: Ship the generic platform bios images for RISC-V
> >
> >  Makefile | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/Makefile b/Makefile
> > index f06b3ae..05e05bb 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -840,7 +840,9 @@ palcode-clipper \
> >  u-boot.e500 u-boot-sam460-20100605.bin \
> >  qemu_vga.ndrv \
> >  edk2-licenses.txt \
> > -hppa-firmware.img
> > +hppa-firmware.img \
> > +opensbi-riscv32-generic-fw_dynamic.bin opensbi-riscv32-generic-fw_dynamic.elf \
> > +opensbi-riscv64-generic-fw_dynamic.bin opensbi-riscv64-generic-fw_dynamic.elf
> >
> >
> >  DESCS=50-edk2-i386-secure.json 50-edk2-x86_64-secure.json \
> > --
> > 2.7.4
> >
> >

Re: [PATCH v4 7/7] Makefile: Ship the generic platform bios images for RISC-V

[Alistair Francis]

On Fri, Jul 10, 2020 at 11:36 AM Alistair Francis <alistair23@gmail.com> wrote:
>
> On Thu, Jul 9, 2020 at 10:11 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > From: Bin Meng <bin.meng@windriver.com>
> >
> > Update the install blob list to include the generic platform
> > fw_dynamic bios images.
> >
> > Signed-off-by: Bin Meng <bin.meng@windriver.com>
>
> You didn't address the comments in v3.
>
> Thinking about this more though it looks like we currently don't
> install anything, so this is an improvement.
>
> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>

Nope, I was wrong. This should be squashed into patch 4 where you
remove the installed binaries.

Alistair

>
> Alistair
>
> >
> > ---
> >
> > (no changes since v3)
> >
> > Changes in v3:
> > - change fw_jump to fw_dynamic in the Makefile
> >
> > Changes in v2:
> > - new patch: Makefile: Ship the generic platform bios images for RISC-V
> >
> >  Makefile | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/Makefile b/Makefile
> > index f06b3ae..05e05bb 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -840,7 +840,9 @@ palcode-clipper \
> >  u-boot.e500 u-boot-sam460-20100605.bin \
> >  qemu_vga.ndrv \
> >  edk2-licenses.txt \
> > -hppa-firmware.img
> > +hppa-firmware.img \
> > +opensbi-riscv32-generic-fw_dynamic.bin opensbi-riscv32-generic-fw_dynamic.elf \
> > +opensbi-riscv64-generic-fw_dynamic.bin opensbi-riscv64-generic-fw_dynamic.elf
> >
> >
> >  DESCS=50-edk2-i386-secure.json 50-edk2-x86_64-secure.json \
> > --
> > 2.7.4
> >
> >

Re: [PATCH v4 4/7] hw/riscv: Use pre-built bios image of generic platform for virt & sifive_u

[Alistair Francis]

On Thu, Jul 9, 2020 at 10:07 PM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> From: Bin Meng <bin.meng@windriver.com>
>
> Update virt and sifive_u machines to use the opensbi fw_dynamic bios
> image built for the generic FDT platform.
>
> Remove the out-of-date no longer used bios images.
>
> Signed-off-by: Bin Meng <bin.meng@windriver.com>
> Reviewed-by: Anup Patel <anup@brainfault.org>
> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>

This patch seems to break 32-bit Linux boots on the sifive_u and virt machines.

Alistair

>
> ---
>
> Changes in v4:
> - Remove old binaries in the Makefile for `make install` bisection
>
> Changes in v3:
> - Change to fw_dynamic.bin for virt & sifive_u
>
>  Makefile                                       |   4 +---
>  hw/riscv/sifive_u.c                            |   4 ++--
>  hw/riscv/virt.c                                |   4 ++--
>  pc-bios/opensbi-riscv32-generic-fw_dynamic.bin | Bin 0 -> 62144 bytes
>  pc-bios/opensbi-riscv32-sifive_u-fw_jump.bin   | Bin 49520 -> 0 bytes
>  pc-bios/opensbi-riscv32-virt-fw_jump.bin       | Bin 49504 -> 0 bytes
>  pc-bios/opensbi-riscv64-generic-fw_dynamic.bin | Bin 0 -> 70792 bytes
>  pc-bios/opensbi-riscv64-sifive_u-fw_jump.bin   | Bin 57936 -> 0 bytes
>  pc-bios/opensbi-riscv64-virt-fw_jump.bin       | Bin 57920 -> 0 bytes
>  9 files changed, 5 insertions(+), 7 deletions(-)
>  create mode 100644 pc-bios/opensbi-riscv32-generic-fw_dynamic.bin
>  delete mode 100644 pc-bios/opensbi-riscv32-sifive_u-fw_jump.bin
>  delete mode 100644 pc-bios/opensbi-riscv32-virt-fw_jump.bin
>  create mode 100644 pc-bios/opensbi-riscv64-generic-fw_dynamic.bin
>  delete mode 100644 pc-bios/opensbi-riscv64-sifive_u-fw_jump.bin
>  delete mode 100644 pc-bios/opensbi-riscv64-virt-fw_jump.bin
>
> diff --git a/Makefile b/Makefile
> index b1b8a5a..f06b3ae 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -840,9 +840,7 @@ palcode-clipper \
>  u-boot.e500 u-boot-sam460-20100605.bin \
>  qemu_vga.ndrv \
>  edk2-licenses.txt \
> -hppa-firmware.img \
> -opensbi-riscv32-sifive_u-fw_jump.bin opensbi-riscv32-virt-fw_jump.bin \
> -opensbi-riscv64-sifive_u-fw_jump.bin opensbi-riscv64-virt-fw_jump.bin
> +hppa-firmware.img
>
>
>  DESCS=50-edk2-i386-secure.json 50-edk2-x86_64-secure.json \
> diff --git a/hw/riscv/sifive_u.c b/hw/riscv/sifive_u.c
> index b434fd3..dc46f64 100644
> --- a/hw/riscv/sifive_u.c
> +++ b/hw/riscv/sifive_u.c
> @@ -60,9 +60,9 @@
>  #include <libfdt.h>
>
>  #if defined(TARGET_RISCV32)
> -# define BIOS_FILENAME "opensbi-riscv32-sifive_u-fw_jump.bin"
> +# define BIOS_FILENAME "opensbi-riscv32-generic-fw_dynamic.bin"
>  #else
> -# define BIOS_FILENAME "opensbi-riscv64-sifive_u-fw_jump.bin"
> +# define BIOS_FILENAME "opensbi-riscv64-generic-fw_dynamic.bin"
>  #endif
>
>  static const struct MemmapEntry {
> diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
> index 85e17fe..5ca49c5 100644
> --- a/hw/riscv/virt.c
> +++ b/hw/riscv/virt.c
> @@ -43,9 +43,9 @@
>  #include "hw/pci-host/gpex.h"
>
>  #if defined(TARGET_RISCV32)
> -# define BIOS_FILENAME "opensbi-riscv32-virt-fw_jump.bin"
> +# define BIOS_FILENAME "opensbi-riscv32-generic-fw_dynamic.bin"
>  #else
> -# define BIOS_FILENAME "opensbi-riscv64-virt-fw_jump.bin"
> +# define BIOS_FILENAME "opensbi-riscv64-generic-fw_dynamic.bin"
>  #endif
>
>  static const struct MemmapEntry {
> diff --git a/pc-bios/opensbi-riscv32-generic-fw_dynamic.bin b/pc-bios/opensbi-riscv32-generic-fw_dynamic.bin
> new file mode 100644
> index 0000000..23b4dfb
> Binary files /dev/null and b/pc-bios/opensbi-riscv32-generic-fw_dynamic.bin differ
> diff --git a/pc-bios/opensbi-riscv32-sifive_u-fw_jump.bin b/pc-bios/opensbi-riscv32-sifive_u-fw_jump.bin
> deleted file mode 100644
> index 3e0da54..0000000
> Binary files a/pc-bios/opensbi-riscv32-sifive_u-fw_jump.bin and /dev/null differ
> diff --git a/pc-bios/opensbi-riscv32-virt-fw_jump.bin b/pc-bios/opensbi-riscv32-virt-fw_jump.bin
> deleted file mode 100644
> index bc56ed6..0000000
> Binary files a/pc-bios/opensbi-riscv32-virt-fw_jump.bin and /dev/null differ
> diff --git a/pc-bios/opensbi-riscv64-generic-fw_dynamic.bin b/pc-bios/opensbi-riscv64-generic-fw_dynamic.bin
> new file mode 100644
> index 0000000..16c0cf4
> Binary files /dev/null and b/pc-bios/opensbi-riscv64-generic-fw_dynamic.bin differ
> diff --git a/pc-bios/opensbi-riscv64-sifive_u-fw_jump.bin b/pc-bios/opensbi-riscv64-sifive_u-fw_jump.bin
> deleted file mode 100644
> index 1acee86..0000000
> Binary files a/pc-bios/opensbi-riscv64-sifive_u-fw_jump.bin and /dev/null differ
> diff --git a/pc-bios/opensbi-riscv64-virt-fw_jump.bin b/pc-bios/opensbi-riscv64-virt-fw_jump.bin
> deleted file mode 100644
> index c62f2b4..0000000
> Binary files a/pc-bios/opensbi-riscv64-virt-fw_jump.bin and /dev/null differ
> --
> 2.7.4
>
>

Re: [PATCH v4 4/7] hw/riscv: Use pre-built bios image of generic platform for virt & sifive_u

[Alistair Francis]

On Thu, Jul 9, 2020 at 10:07 PM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> From: Bin Meng <bin.meng@windriver.com>
>
> Update virt and sifive_u machines to use the opensbi fw_dynamic bios
> image built for the generic FDT platform.
>
> Remove the out-of-date no longer used bios images.
>
> Signed-off-by: Bin Meng <bin.meng@windriver.com>
> Reviewed-by: Anup Patel <anup@brainfault.org>
> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>

This patch seems to break 32-bit Linux boots on the sifive_u and virt machines.

Alistair

>
> ---
>
> Changes in v4:
> - Remove old binaries in the Makefile for `make install` bisection
>
> Changes in v3:
> - Change to fw_dynamic.bin for virt & sifive_u
>
>  Makefile                                       |   4 +---
>  hw/riscv/sifive_u.c                            |   4 ++--
>  hw/riscv/virt.c                                |   4 ++--
>  pc-bios/opensbi-riscv32-generic-fw_dynamic.bin | Bin 0 -> 62144 bytes
>  pc-bios/opensbi-riscv32-sifive_u-fw_jump.bin   | Bin 49520 -> 0 bytes
>  pc-bios/opensbi-riscv32-virt-fw_jump.bin       | Bin 49504 -> 0 bytes
>  pc-bios/opensbi-riscv64-generic-fw_dynamic.bin | Bin 0 -> 70792 bytes
>  pc-bios/opensbi-riscv64-sifive_u-fw_jump.bin   | Bin 57936 -> 0 bytes
>  pc-bios/opensbi-riscv64-virt-fw_jump.bin       | Bin 57920 -> 0 bytes
>  9 files changed, 5 insertions(+), 7 deletions(-)
>  create mode 100644 pc-bios/opensbi-riscv32-generic-fw_dynamic.bin
>  delete mode 100644 pc-bios/opensbi-riscv32-sifive_u-fw_jump.bin
>  delete mode 100644 pc-bios/opensbi-riscv32-virt-fw_jump.bin
>  create mode 100644 pc-bios/opensbi-riscv64-generic-fw_dynamic.bin
>  delete mode 100644 pc-bios/opensbi-riscv64-sifive_u-fw_jump.bin
>  delete mode 100644 pc-bios/opensbi-riscv64-virt-fw_jump.bin
>
> diff --git a/Makefile b/Makefile
> index b1b8a5a..f06b3ae 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -840,9 +840,7 @@ palcode-clipper \
>  u-boot.e500 u-boot-sam460-20100605.bin \
>  qemu_vga.ndrv \
>  edk2-licenses.txt \
> -hppa-firmware.img \
> -opensbi-riscv32-sifive_u-fw_jump.bin opensbi-riscv32-virt-fw_jump.bin \
> -opensbi-riscv64-sifive_u-fw_jump.bin opensbi-riscv64-virt-fw_jump.bin
> +hppa-firmware.img
>
>
>  DESCS=50-edk2-i386-secure.json 50-edk2-x86_64-secure.json \
> diff --git a/hw/riscv/sifive_u.c b/hw/riscv/sifive_u.c
> index b434fd3..dc46f64 100644
> --- a/hw/riscv/sifive_u.c
> +++ b/hw/riscv/sifive_u.c
> @@ -60,9 +60,9 @@
>  #include <libfdt.h>
>
>  #if defined(TARGET_RISCV32)
> -# define BIOS_FILENAME "opensbi-riscv32-sifive_u-fw_jump.bin"
> +# define BIOS_FILENAME "opensbi-riscv32-generic-fw_dynamic.bin"
>  #else
> -# define BIOS_FILENAME "opensbi-riscv64-sifive_u-fw_jump.bin"
> +# define BIOS_FILENAME "opensbi-riscv64-generic-fw_dynamic.bin"
>  #endif
>
>  static const struct MemmapEntry {
> diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
> index 85e17fe..5ca49c5 100644
> --- a/hw/riscv/virt.c
> +++ b/hw/riscv/virt.c
> @@ -43,9 +43,9 @@
>  #include "hw/pci-host/gpex.h"
>
>  #if defined(TARGET_RISCV32)
> -# define BIOS_FILENAME "opensbi-riscv32-virt-fw_jump.bin"
> +# define BIOS_FILENAME "opensbi-riscv32-generic-fw_dynamic.bin"
>  #else
> -# define BIOS_FILENAME "opensbi-riscv64-virt-fw_jump.bin"
> +# define BIOS_FILENAME "opensbi-riscv64-generic-fw_dynamic.bin"
>  #endif
>
>  static const struct MemmapEntry {
> diff --git a/pc-bios/opensbi-riscv32-generic-fw_dynamic.bin b/pc-bios/opensbi-riscv32-generic-fw_dynamic.bin
> new file mode 100644
> index 0000000..23b4dfb
> Binary files /dev/null and b/pc-bios/opensbi-riscv32-generic-fw_dynamic.bin differ
> diff --git a/pc-bios/opensbi-riscv32-sifive_u-fw_jump.bin b/pc-bios/opensbi-riscv32-sifive_u-fw_jump.bin
> deleted file mode 100644
> index 3e0da54..0000000
> Binary files a/pc-bios/opensbi-riscv32-sifive_u-fw_jump.bin and /dev/null differ
> diff --git a/pc-bios/opensbi-riscv32-virt-fw_jump.bin b/pc-bios/opensbi-riscv32-virt-fw_jump.bin
> deleted file mode 100644
> index bc56ed6..0000000
> Binary files a/pc-bios/opensbi-riscv32-virt-fw_jump.bin and /dev/null differ
> diff --git a/pc-bios/opensbi-riscv64-generic-fw_dynamic.bin b/pc-bios/opensbi-riscv64-generic-fw_dynamic.bin
> new file mode 100644
> index 0000000..16c0cf4
> Binary files /dev/null and b/pc-bios/opensbi-riscv64-generic-fw_dynamic.bin differ
> diff --git a/pc-bios/opensbi-riscv64-sifive_u-fw_jump.bin b/pc-bios/opensbi-riscv64-sifive_u-fw_jump.bin
> deleted file mode 100644
> index 1acee86..0000000
> Binary files a/pc-bios/opensbi-riscv64-sifive_u-fw_jump.bin and /dev/null differ
> diff --git a/pc-bios/opensbi-riscv64-virt-fw_jump.bin b/pc-bios/opensbi-riscv64-virt-fw_jump.bin
> deleted file mode 100644
> index c62f2b4..0000000
> Binary files a/pc-bios/opensbi-riscv64-virt-fw_jump.bin and /dev/null differ
> --
> 2.7.4
>
>

Re: [PATCH v4 7/7] Makefile: Ship the generic platform bios images for RISC-V

[Bin Meng]

On Sun, Jul 12, 2020 at 1:28 AM Alistair Francis <alistair23@gmail.com> wrote:
>
> On Fri, Jul 10, 2020 at 11:36 AM Alistair Francis <alistair23@gmail.com> wrote:
> >
> > On Thu, Jul 9, 2020 at 10:11 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > >
> > > From: Bin Meng <bin.meng@windriver.com>
> > >
> > > Update the install blob list to include the generic platform
> > > fw_dynamic bios images.
> > >
> > > Signed-off-by: Bin Meng <bin.meng@windriver.com>
> >
> > You didn't address the comments in v3.
> >
> > Thinking about this more though it looks like we currently don't
> > install anything, so this is an improvement.
> >
> > Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
>
> Nope, I was wrong. This should be squashed into patch 4 where you
> remove the installed binaries.

Not entirely correct. The .bin changes should go to patch 4, and .elf
changes should remain in this patch I think.

Regards,
Bin

Re: [PATCH v4 7/7] Makefile: Ship the generic platform bios images for RISC-V

[Bin Meng]

On Sun, Jul 12, 2020 at 1:28 AM Alistair Francis <alistair23@gmail.com> wrote:
>
> On Fri, Jul 10, 2020 at 11:36 AM Alistair Francis <alistair23@gmail.com> wrote:
> >
> > On Thu, Jul 9, 2020 at 10:11 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > >
> > > From: Bin Meng <bin.meng@windriver.com>
> > >
> > > Update the install blob list to include the generic platform
> > > fw_dynamic bios images.
> > >
> > > Signed-off-by: Bin Meng <bin.meng@windriver.com>
> >
> > You didn't address the comments in v3.
> >
> > Thinking about this more though it looks like we currently don't
> > install anything, so this is an improvement.
> >
> > Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
>
> Nope, I was wrong. This should be squashed into patch 4 where you
> remove the installed binaries.

Not entirely correct. The .bin changes should go to patch 4, and .elf
changes should remain in this patch I think.

Regards,
Bin

Re: [PATCH v4 4/7] hw/riscv: Use pre-built bios image of generic platform for virt & sifive_u

[Bin Meng]

On Sun, Jul 12, 2020 at 1:34 AM Alistair Francis <alistair23@gmail.com> wrote:
>
> On Thu, Jul 9, 2020 at 10:07 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > From: Bin Meng <bin.meng@windriver.com>
> >
> > Update virt and sifive_u machines to use the opensbi fw_dynamic bios
> > image built for the generic FDT platform.
> >
> > Remove the out-of-date no longer used bios images.
> >
> > Signed-off-by: Bin Meng <bin.meng@windriver.com>
> > Reviewed-by: Anup Patel <anup@brainfault.org>
> > Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
>
> This patch seems to break 32-bit Linux boots on the sifive_u and virt machines.
>

It looks only Linux boot on sifive_u is broken. On our side, we have
been using VxWorks to test 32-bit OpenSBI on sifive_u so this issue
gets unnoticed. I will take a look.

Regards,
Bin

Re: [PATCH v4 4/7] hw/riscv: Use pre-built bios image of generic platform for virt & sifive_u

[Bin Meng]

On Sun, Jul 12, 2020 at 1:34 AM Alistair Francis <alistair23@gmail.com> wrote:
>
> On Thu, Jul 9, 2020 at 10:07 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > From: Bin Meng <bin.meng@windriver.com>
> >
> > Update virt and sifive_u machines to use the opensbi fw_dynamic bios
> > image built for the generic FDT platform.
> >
> > Remove the out-of-date no longer used bios images.
> >
> > Signed-off-by: Bin Meng <bin.meng@windriver.com>
> > Reviewed-by: Anup Patel <anup@brainfault.org>
> > Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
>
> This patch seems to break 32-bit Linux boots on the sifive_u and virt machines.
>

It looks only Linux boot on sifive_u is broken. On our side, we have
been using VxWorks to test 32-bit OpenSBI on sifive_u so this issue
gets unnoticed. I will take a look.

Regards,
Bin

Re: [PATCH v4 4/7] hw/riscv: Use pre-built bios image of generic platform for virt & sifive_u

[Bin Meng]

Hi Alistair,

On Mon, Jul 13, 2020 at 9:53 AM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> On Sun, Jul 12, 2020 at 1:34 AM Alistair Francis <alistair23@gmail.com> wrote:
> >
> > On Thu, Jul 9, 2020 at 10:07 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > >
> > > From: Bin Meng <bin.meng@windriver.com>
> > >
> > > Update virt and sifive_u machines to use the opensbi fw_dynamic bios
> > > image built for the generic FDT platform.
> > >
> > > Remove the out-of-date no longer used bios images.
> > >
> > > Signed-off-by: Bin Meng <bin.meng@windriver.com>
> > > Reviewed-by: Anup Patel <anup@brainfault.org>
> > > Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
> >
> > This patch seems to break 32-bit Linux boots on the sifive_u and virt machines.
> >
>
> It looks only Linux boot on sifive_u is broken. On our side, we have
> been using VxWorks to test 32-bit OpenSBI on sifive_u so this issue
> gets unnoticed. I will take a look.

I've figured out the issue of 32-bit Linux booting failure on
sifive_u. A patch has been sent to Linux upstream:
http://lists.infradead.org/pipermail/linux-riscv/2020-July/001213.html

Regards,
Bin

Re: [PATCH v4 4/7] hw/riscv: Use pre-built bios image of generic platform for virt & sifive_u

[Bin Meng]

Hi Alistair,

On Mon, Jul 13, 2020 at 9:53 AM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> On Sun, Jul 12, 2020 at 1:34 AM Alistair Francis <alistair23@gmail.com> wrote:
> >
> > On Thu, Jul 9, 2020 at 10:07 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > >
> > > From: Bin Meng <bin.meng@windriver.com>
> > >
> > > Update virt and sifive_u machines to use the opensbi fw_dynamic bios
> > > image built for the generic FDT platform.
> > >
> > > Remove the out-of-date no longer used bios images.
> > >
> > > Signed-off-by: Bin Meng <bin.meng@windriver.com>
> > > Reviewed-by: Anup Patel <anup@brainfault.org>
> > > Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
> >
> > This patch seems to break 32-bit Linux boots on the sifive_u and virt machines.
> >
>
> It looks only Linux boot on sifive_u is broken. On our side, we have
> been using VxWorks to test 32-bit OpenSBI on sifive_u so this issue
> gets unnoticed. I will take a look.

I've figured out the issue of 32-bit Linux booting failure on
sifive_u. A patch has been sent to Linux upstream:
http://lists.infradead.org/pipermail/linux-riscv/2020-July/001213.html

Regards,
Bin

Re: [PATCH v4 4/7] hw/riscv: Use pre-built bios image of generic platform for virt & sifive_u

[Alistair Francis]

On Wed, Jul 15, 2020 at 9:55 PM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> Hi Alistair,
>
> On Mon, Jul 13, 2020 at 9:53 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > On Sun, Jul 12, 2020 at 1:34 AM Alistair Francis <alistair23@gmail.com> wrote:
> > >
> > > On Thu, Jul 9, 2020 at 10:07 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > >
> > > > From: Bin Meng <bin.meng@windriver.com>
> > > >
> > > > Update virt and sifive_u machines to use the opensbi fw_dynamic bios
> > > > image built for the generic FDT platform.
> > > >
> > > > Remove the out-of-date no longer used bios images.
> > > >
> > > > Signed-off-by: Bin Meng <bin.meng@windriver.com>
> > > > Reviewed-by: Anup Patel <anup@brainfault.org>
> > > > Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
> > >
> > > This patch seems to break 32-bit Linux boots on the sifive_u and virt machines.
> > >
> >
> > It looks only Linux boot on sifive_u is broken. On our side, we have
> > been using VxWorks to test 32-bit OpenSBI on sifive_u so this issue
> > gets unnoticed. I will take a look.
>
> I've figured out the issue of 32-bit Linux booting failure on
> sifive_u. A patch has been sent to Linux upstream:
> http://lists.infradead.org/pipermail/linux-riscv/2020-July/001213.html

Thanks for that. What change in QEMU causes this failure though?

There are lots of people not running the latest Linux from master that
this will cause breakages for.

Alistair

>
> Regards,
> Bin

Re: [PATCH v4 4/7] hw/riscv: Use pre-built bios image of generic platform for virt & sifive_u

[Alistair Francis]

On Wed, Jul 15, 2020 at 9:55 PM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> Hi Alistair,
>
> On Mon, Jul 13, 2020 at 9:53 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > On Sun, Jul 12, 2020 at 1:34 AM Alistair Francis <alistair23@gmail.com> wrote:
> > >
> > > On Thu, Jul 9, 2020 at 10:07 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > >
> > > > From: Bin Meng <bin.meng@windriver.com>
> > > >
> > > > Update virt and sifive_u machines to use the opensbi fw_dynamic bios
> > > > image built for the generic FDT platform.
> > > >
> > > > Remove the out-of-date no longer used bios images.
> > > >
> > > > Signed-off-by: Bin Meng <bin.meng@windriver.com>
> > > > Reviewed-by: Anup Patel <anup@brainfault.org>
> > > > Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
> > >
> > > This patch seems to break 32-bit Linux boots on the sifive_u and virt machines.
> > >
> >
> > It looks only Linux boot on sifive_u is broken. On our side, we have
> > been using VxWorks to test 32-bit OpenSBI on sifive_u so this issue
> > gets unnoticed. I will take a look.
>
> I've figured out the issue of 32-bit Linux booting failure on
> sifive_u. A patch has been sent to Linux upstream:
> http://lists.infradead.org/pipermail/linux-riscv/2020-July/001213.html

Thanks for that. What change in QEMU causes this failure though?

There are lots of people not running the latest Linux from master that
this will cause breakages for.

Alistair

>
> Regards,
> Bin

Re: [PATCH v4 4/7] hw/riscv: Use pre-built bios image of generic platform for virt & sifive_u

[Bin Meng]

Hi Alistair,

On Tue, Jul 28, 2020 at 11:39 PM Alistair Francis <alistair23@gmail.com> wrote:
>
> On Wed, Jul 15, 2020 at 9:55 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > Hi Alistair,
> >
> > On Mon, Jul 13, 2020 at 9:53 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> > >
> > > On Sun, Jul 12, 2020 at 1:34 AM Alistair Francis <alistair23@gmail.com> wrote:
> > > >
> > > > On Thu, Jul 9, 2020 at 10:07 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > >
> > > > > From: Bin Meng <bin.meng@windriver.com>
> > > > >
> > > > > Update virt and sifive_u machines to use the opensbi fw_dynamic bios
> > > > > image built for the generic FDT platform.
> > > > >
> > > > > Remove the out-of-date no longer used bios images.
> > > > >
> > > > > Signed-off-by: Bin Meng <bin.meng@windriver.com>
> > > > > Reviewed-by: Anup Patel <anup@brainfault.org>
> > > > > Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
> > > >
> > > > This patch seems to break 32-bit Linux boots on the sifive_u and virt machines.
> > > >
> > >
> > > It looks only Linux boot on sifive_u is broken. On our side, we have
> > > been using VxWorks to test 32-bit OpenSBI on sifive_u so this issue
> > > gets unnoticed. I will take a look.
> >
> > I've figured out the issue of 32-bit Linux booting failure on
> > sifive_u. A patch has been sent to Linux upstream:
> > http://lists.infradead.org/pipermail/linux-riscv/2020-July/001213.html
>
> Thanks for that. What change in QEMU causes this failure though?
>

There is nothing wrong in QEMU.

> There are lots of people not running the latest Linux from master that
> this will cause breakages for.

It's just that the 32-bit Linux defconfig has never been validated by
people with 'sifive_u' machine. I bet people only validated the 32-bit
kernel with the 'virt' machine.

Regards,
Bin

Re: [PATCH v4 4/7] hw/riscv: Use pre-built bios image of generic platform for virt & sifive_u

[Bin Meng]

Hi Alistair,

On Tue, Jul 28, 2020 at 11:39 PM Alistair Francis <alistair23@gmail.com> wrote:
>
> On Wed, Jul 15, 2020 at 9:55 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > Hi Alistair,
> >
> > On Mon, Jul 13, 2020 at 9:53 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> > >
> > > On Sun, Jul 12, 2020 at 1:34 AM Alistair Francis <alistair23@gmail.com> wrote:
> > > >
> > > > On Thu, Jul 9, 2020 at 10:07 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > >
> > > > > From: Bin Meng <bin.meng@windriver.com>
> > > > >
> > > > > Update virt and sifive_u machines to use the opensbi fw_dynamic bios
> > > > > image built for the generic FDT platform.
> > > > >
> > > > > Remove the out-of-date no longer used bios images.
> > > > >
> > > > > Signed-off-by: Bin Meng <bin.meng@windriver.com>
> > > > > Reviewed-by: Anup Patel <anup@brainfault.org>
> > > > > Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
> > > >
> > > > This patch seems to break 32-bit Linux boots on the sifive_u and virt machines.
> > > >
> > >
> > > It looks only Linux boot on sifive_u is broken. On our side, we have
> > > been using VxWorks to test 32-bit OpenSBI on sifive_u so this issue
> > > gets unnoticed. I will take a look.
> >
> > I've figured out the issue of 32-bit Linux booting failure on
> > sifive_u. A patch has been sent to Linux upstream:
> > http://lists.infradead.org/pipermail/linux-riscv/2020-July/001213.html
>
> Thanks for that. What change in QEMU causes this failure though?
>

There is nothing wrong in QEMU.

> There are lots of people not running the latest Linux from master that
> this will cause breakages for.

It's just that the 32-bit Linux defconfig has never been validated by
people with 'sifive_u' machine. I bet people only validated the 32-bit
kernel with the 'virt' machine.

Regards,
Bin

Re: [PATCH v4 4/7] hw/riscv: Use pre-built bios image of generic platform for virt & sifive_u

[Alistair Francis]

On Tue, Jul 28, 2020 at 8:46 AM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> Hi Alistair,
>
> On Tue, Jul 28, 2020 at 11:39 PM Alistair Francis <alistair23@gmail.com> wrote:
> >
> > On Wed, Jul 15, 2020 at 9:55 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > >
> > > Hi Alistair,
> > >
> > > On Mon, Jul 13, 2020 at 9:53 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > >
> > > > On Sun, Jul 12, 2020 at 1:34 AM Alistair Francis <alistair23@gmail.com> wrote:
> > > > >
> > > > > On Thu, Jul 9, 2020 at 10:07 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > >
> > > > > > From: Bin Meng <bin.meng@windriver.com>
> > > > > >
> > > > > > Update virt and sifive_u machines to use the opensbi fw_dynamic bios
> > > > > > image built for the generic FDT platform.
> > > > > >
> > > > > > Remove the out-of-date no longer used bios images.
> > > > > >
> > > > > > Signed-off-by: Bin Meng <bin.meng@windriver.com>
> > > > > > Reviewed-by: Anup Patel <anup@brainfault.org>
> > > > > > Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
> > > > >
> > > > > This patch seems to break 32-bit Linux boots on the sifive_u and virt machines.
> > > > >
> > > >
> > > > It looks only Linux boot on sifive_u is broken. On our side, we have
> > > > been using VxWorks to test 32-bit OpenSBI on sifive_u so this issue
> > > > gets unnoticed. I will take a look.
> > >
> > > I've figured out the issue of 32-bit Linux booting failure on
> > > sifive_u. A patch has been sent to Linux upstream:
> > > http://lists.infradead.org/pipermail/linux-riscv/2020-July/001213.html
> >
> > Thanks for that. What change in QEMU causes this failure though?
> >
>
> There is nothing wrong in QEMU.

There is. This patch causes a regression for 32-bit Linux boot on the
sifive_u. Your v5 has not addressed this.

With this patch, the Linux boot stops here:

OpenSBI v0.8
   ____                    _____ ____ _____
  / __ \                  / ____|  _ \_   _|
 | |  | |_ __   ___ _ __ | (___ | |_) || |
 | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
 | |__| | |_) |  __/ | | |____) | |_) || |_
  \____/| .__/ \___|_| |_|_____/|____/_____|
        | |
        |_|

Platform Name       : SiFive HiFive Unleashed A00
Platform Features   : timer,mfdeleg
Platform HART Count : 4
Boot HART ID        : 3
Boot HART ISA       : rv64imafdcsu
BOOT HART Features  : pmp,scounteren,mcounteren
BOOT HART PMP Count : 16
Firmware Base       : 0x80000000
Firmware Size       : 116 KB
Runtime SBI Version : 0.2

MIDELEG : 0x0000000000000222
MEDELEG : 0x000000000000b109
PMP0    : 0x0000000080000000-0x000000008001ffff (A)
PMP1    : 0x0000000000000000-0xffffffffffffffff (A,R,W,X)
[    0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80200000
[    0.000000] Linux version 5.3.0 (oe-user@oe-host) (gcc version
9.2.0 (GCC)) #1 SMP Thu Sep 19 18:34:52 UTC 2019
[    0.000000] earlycon: sbi0 at I/O port 0x0 (options '')
[    0.000000] printk: bootconsole [sbi0] enabled
[    0.000000] initrd not found or empty - disabling initrd
[    0.000000] Zone ranges:
[    0.000000]   DMA32    [mem 0x0000000080200000-0x00000000bfffffff]
[    0.000000]   Normal   empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000080200000-0x00000000bfffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000080200000-0x00000000bfffffff]
[    0.000000] OF: fdt: Invalid device tree blob header
[    0.000000] software IO TLB: mapped [mem 0xbb1fe000-0xbf1fe000] (64MB)

Without this patch I can boot all the way to looking for a rootFS.

Please don't send new versions of patches without addresses regressions.

Alistair

>
> > There are lots of people not running the latest Linux from master that
> > this will cause breakages for.
>
> It's just that the 32-bit Linux defconfig has never been validated by
> people with 'sifive_u' machine. I bet people only validated the 32-bit
> kernel with the 'virt' machine.
>
> Regards,
> Bin

Re: [PATCH v4 4/7] hw/riscv: Use pre-built bios image of generic platform for virt & sifive_u

[Alistair Francis]

On Tue, Jul 28, 2020 at 8:46 AM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> Hi Alistair,
>
> On Tue, Jul 28, 2020 at 11:39 PM Alistair Francis <alistair23@gmail.com> wrote:
> >
> > On Wed, Jul 15, 2020 at 9:55 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > >
> > > Hi Alistair,
> > >
> > > On Mon, Jul 13, 2020 at 9:53 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > >
> > > > On Sun, Jul 12, 2020 at 1:34 AM Alistair Francis <alistair23@gmail.com> wrote:
> > > > >
> > > > > On Thu, Jul 9, 2020 at 10:07 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > >
> > > > > > From: Bin Meng <bin.meng@windriver.com>
> > > > > >
> > > > > > Update virt and sifive_u machines to use the opensbi fw_dynamic bios
> > > > > > image built for the generic FDT platform.
> > > > > >
> > > > > > Remove the out-of-date no longer used bios images.
> > > > > >
> > > > > > Signed-off-by: Bin Meng <bin.meng@windriver.com>
> > > > > > Reviewed-by: Anup Patel <anup@brainfault.org>
> > > > > > Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
> > > > >
> > > > > This patch seems to break 32-bit Linux boots on the sifive_u and virt machines.
> > > > >
> > > >
> > > > It looks only Linux boot on sifive_u is broken. On our side, we have
> > > > been using VxWorks to test 32-bit OpenSBI on sifive_u so this issue
> > > > gets unnoticed. I will take a look.
> > >
> > > I've figured out the issue of 32-bit Linux booting failure on
> > > sifive_u. A patch has been sent to Linux upstream:
> > > http://lists.infradead.org/pipermail/linux-riscv/2020-July/001213.html
> >
> > Thanks for that. What change in QEMU causes this failure though?
> >
>
> There is nothing wrong in QEMU.

There is. This patch causes a regression for 32-bit Linux boot on the
sifive_u. Your v5 has not addressed this.

With this patch, the Linux boot stops here:

OpenSBI v0.8
   ____                    _____ ____ _____
  / __ \                  / ____|  _ \_   _|
 | |  | |_ __   ___ _ __ | (___ | |_) || |
 | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
 | |__| | |_) |  __/ | | |____) | |_) || |_
  \____/| .__/ \___|_| |_|_____/|____/_____|
        | |
        |_|

Platform Name       : SiFive HiFive Unleashed A00
Platform Features   : timer,mfdeleg
Platform HART Count : 4
Boot HART ID        : 3
Boot HART ISA       : rv64imafdcsu
BOOT HART Features  : pmp,scounteren,mcounteren
BOOT HART PMP Count : 16
Firmware Base       : 0x80000000
Firmware Size       : 116 KB
Runtime SBI Version : 0.2

MIDELEG : 0x0000000000000222
MEDELEG : 0x000000000000b109
PMP0    : 0x0000000080000000-0x000000008001ffff (A)
PMP1    : 0x0000000000000000-0xffffffffffffffff (A,R,W,X)
[    0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80200000
[    0.000000] Linux version 5.3.0 (oe-user@oe-host) (gcc version
9.2.0 (GCC)) #1 SMP Thu Sep 19 18:34:52 UTC 2019
[    0.000000] earlycon: sbi0 at I/O port 0x0 (options '')
[    0.000000] printk: bootconsole [sbi0] enabled
[    0.000000] initrd not found or empty - disabling initrd
[    0.000000] Zone ranges:
[    0.000000]   DMA32    [mem 0x0000000080200000-0x00000000bfffffff]
[    0.000000]   Normal   empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000080200000-0x00000000bfffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000080200000-0x00000000bfffffff]
[    0.000000] OF: fdt: Invalid device tree blob header
[    0.000000] software IO TLB: mapped [mem 0xbb1fe000-0xbf1fe000] (64MB)

Without this patch I can boot all the way to looking for a rootFS.

Please don't send new versions of patches without addresses regressions.

Alistair

>
> > There are lots of people not running the latest Linux from master that
> > this will cause breakages for.
>
> It's just that the 32-bit Linux defconfig has never been validated by
> people with 'sifive_u' machine. I bet people only validated the 32-bit
> kernel with the 'virt' machine.
>
> Regards,
> Bin

Re: [PATCH v4 4/7] hw/riscv: Use pre-built bios image of generic platform for virt & sifive_u

[Bin Meng]

Hi Alistair,

On Wed, Jul 29, 2020 at 2:26 AM Alistair Francis <alistair23@gmail.com> wrote:
>
> On Tue, Jul 28, 2020 at 8:46 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > Hi Alistair,
> >
> > On Tue, Jul 28, 2020 at 11:39 PM Alistair Francis <alistair23@gmail.com> wrote:
> > >
> > > On Wed, Jul 15, 2020 at 9:55 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > >
> > > > Hi Alistair,
> > > >
> > > > On Mon, Jul 13, 2020 at 9:53 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > >
> > > > > On Sun, Jul 12, 2020 at 1:34 AM Alistair Francis <alistair23@gmail.com> wrote:
> > > > > >
> > > > > > On Thu, Jul 9, 2020 at 10:07 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > > >
> > > > > > > From: Bin Meng <bin.meng@windriver.com>
> > > > > > >
> > > > > > > Update virt and sifive_u machines to use the opensbi fw_dynamic bios
> > > > > > > image built for the generic FDT platform.
> > > > > > >
> > > > > > > Remove the out-of-date no longer used bios images.
> > > > > > >
> > > > > > > Signed-off-by: Bin Meng <bin.meng@windriver.com>
> > > > > > > Reviewed-by: Anup Patel <anup@brainfault.org>
> > > > > > > Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
> > > > > >
> > > > > > This patch seems to break 32-bit Linux boots on the sifive_u and virt machines.
> > > > > >
> > > > >
> > > > > It looks only Linux boot on sifive_u is broken. On our side, we have
> > > > > been using VxWorks to test 32-bit OpenSBI on sifive_u so this issue
> > > > > gets unnoticed. I will take a look.
> > > >
> > > > I've figured out the issue of 32-bit Linux booting failure on
> > > > sifive_u. A patch has been sent to Linux upstream:
> > > > http://lists.infradead.org/pipermail/linux-riscv/2020-July/001213.html
> > >
> > > Thanks for that. What change in QEMU causes this failure though?
> > >
> >
> > There is nothing wrong in QEMU.
>
> There is. This patch causes a regression for 32-bit Linux boot on the
> sifive_u. Your v5 has not addressed this.

The 32-bit Linux boot failure was fixed by:
http://lists.infradead.org/pipermail/linux-riscv/2020-July/001213.html

What additional issue did you see?

>
> With this patch, the Linux boot stops here:
>
> OpenSBI v0.8
>    ____                    _____ ____ _____
>   / __ \                  / ____|  _ \_   _|
>  | |  | |_ __   ___ _ __ | (___ | |_) || |
>  | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
>  | |__| | |_) |  __/ | | |____) | |_) || |_
>   \____/| .__/ \___|_| |_|_____/|____/_____|
>         | |
>         |_|
>
> Platform Name       : SiFive HiFive Unleashed A00
> Platform Features   : timer,mfdeleg
> Platform HART Count : 4
> Boot HART ID        : 3
> Boot HART ISA       : rv64imafdcsu

This is a 64-bit hardware.

> BOOT HART Features  : pmp,scounteren,mcounteren
> BOOT HART PMP Count : 16
> Firmware Base       : 0x80000000
> Firmware Size       : 116 KB
> Runtime SBI Version : 0.2
>
> MIDELEG : 0x0000000000000222
> MEDELEG : 0x000000000000b109
> PMP0    : 0x0000000080000000-0x000000008001ffff (A)
> PMP1    : 0x0000000000000000-0xffffffffffffffff (A,R,W,X)
> [    0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80200000
> [    0.000000] Linux version 5.3.0 (oe-user@oe-host) (gcc version

It seems that you are using quite an old kernel. Can you please try
the latest version?

> 9.2.0 (GCC)) #1 SMP Thu Sep 19 18:34:52 UTC 2019
> [    0.000000] earlycon: sbi0 at I/O port 0x0 (options '')
> [    0.000000] printk: bootconsole [sbi0] enabled
> [    0.000000] initrd not found or empty - disabling initrd
> [    0.000000] Zone ranges:
> [    0.000000]   DMA32    [mem 0x0000000080200000-0x00000000bfffffff]
> [    0.000000]   Normal   empty
> [    0.000000] Movable zone start for each node
> [    0.000000] Early memory node ranges
> [    0.000000]   node   0: [mem 0x0000000080200000-0x00000000bfffffff]
> [    0.000000] Initmem setup node 0 [mem 0x0000000080200000-0x00000000bfffffff]
> [    0.000000] OF: fdt: Invalid device tree blob header
> [    0.000000] software IO TLB: mapped [mem 0xbb1fe000-0xbf1fe000] (64MB)
>
> Without this patch I can boot all the way to looking for a rootFS.
>
> Please don't send new versions of patches without addresses regressions.

The patches were sent after addressing all regressions you reported
(well the 32-bit Linux booting issue is actually not a QEMU
regression, but one that exists in the Linux kernel side for a long
time).

I just tested 64-bit Linux boot on both virt and sifive_u, and they
both can boot all the way to looking for a root fs.

Regards,
Bin

Re: [PATCH v4 4/7] hw/riscv: Use pre-built bios image of generic platform for virt & sifive_u

[Bin Meng]

Hi Alistair,

On Wed, Jul 29, 2020 at 2:26 AM Alistair Francis <alistair23@gmail.com> wrote:
>
> On Tue, Jul 28, 2020 at 8:46 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > Hi Alistair,
> >
> > On Tue, Jul 28, 2020 at 11:39 PM Alistair Francis <alistair23@gmail.com> wrote:
> > >
> > > On Wed, Jul 15, 2020 at 9:55 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > >
> > > > Hi Alistair,
> > > >
> > > > On Mon, Jul 13, 2020 at 9:53 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > >
> > > > > On Sun, Jul 12, 2020 at 1:34 AM Alistair Francis <alistair23@gmail.com> wrote:
> > > > > >
> > > > > > On Thu, Jul 9, 2020 at 10:07 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > > >
> > > > > > > From: Bin Meng <bin.meng@windriver.com>
> > > > > > >
> > > > > > > Update virt and sifive_u machines to use the opensbi fw_dynamic bios
> > > > > > > image built for the generic FDT platform.
> > > > > > >
> > > > > > > Remove the out-of-date no longer used bios images.
> > > > > > >
> > > > > > > Signed-off-by: Bin Meng <bin.meng@windriver.com>
> > > > > > > Reviewed-by: Anup Patel <anup@brainfault.org>
> > > > > > > Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
> > > > > >
> > > > > > This patch seems to break 32-bit Linux boots on the sifive_u and virt machines.
> > > > > >
> > > > >
> > > > > It looks only Linux boot on sifive_u is broken. On our side, we have
> > > > > been using VxWorks to test 32-bit OpenSBI on sifive_u so this issue
> > > > > gets unnoticed. I will take a look.
> > > >
> > > > I've figured out the issue of 32-bit Linux booting failure on
> > > > sifive_u. A patch has been sent to Linux upstream:
> > > > http://lists.infradead.org/pipermail/linux-riscv/2020-July/001213.html
> > >
> > > Thanks for that. What change in QEMU causes this failure though?
> > >
> >
> > There is nothing wrong in QEMU.
>
> There is. This patch causes a regression for 32-bit Linux boot on the
> sifive_u. Your v5 has not addressed this.

The 32-bit Linux boot failure was fixed by:
http://lists.infradead.org/pipermail/linux-riscv/2020-July/001213.html

What additional issue did you see?

>
> With this patch, the Linux boot stops here:
>
> OpenSBI v0.8
>    ____                    _____ ____ _____
>   / __ \                  / ____|  _ \_   _|
>  | |  | |_ __   ___ _ __ | (___ | |_) || |
>  | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
>  | |__| | |_) |  __/ | | |____) | |_) || |_
>   \____/| .__/ \___|_| |_|_____/|____/_____|
>         | |
>         |_|
>
> Platform Name       : SiFive HiFive Unleashed A00
> Platform Features   : timer,mfdeleg
> Platform HART Count : 4
> Boot HART ID        : 3
> Boot HART ISA       : rv64imafdcsu

This is a 64-bit hardware.

> BOOT HART Features  : pmp,scounteren,mcounteren
> BOOT HART PMP Count : 16
> Firmware Base       : 0x80000000
> Firmware Size       : 116 KB
> Runtime SBI Version : 0.2
>
> MIDELEG : 0x0000000000000222
> MEDELEG : 0x000000000000b109
> PMP0    : 0x0000000080000000-0x000000008001ffff (A)
> PMP1    : 0x0000000000000000-0xffffffffffffffff (A,R,W,X)
> [    0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80200000
> [    0.000000] Linux version 5.3.0 (oe-user@oe-host) (gcc version

It seems that you are using quite an old kernel. Can you please try
the latest version?

> 9.2.0 (GCC)) #1 SMP Thu Sep 19 18:34:52 UTC 2019
> [    0.000000] earlycon: sbi0 at I/O port 0x0 (options '')
> [    0.000000] printk: bootconsole [sbi0] enabled
> [    0.000000] initrd not found or empty - disabling initrd
> [    0.000000] Zone ranges:
> [    0.000000]   DMA32    [mem 0x0000000080200000-0x00000000bfffffff]
> [    0.000000]   Normal   empty
> [    0.000000] Movable zone start for each node
> [    0.000000] Early memory node ranges
> [    0.000000]   node   0: [mem 0x0000000080200000-0x00000000bfffffff]
> [    0.000000] Initmem setup node 0 [mem 0x0000000080200000-0x00000000bfffffff]
> [    0.000000] OF: fdt: Invalid device tree blob header
> [    0.000000] software IO TLB: mapped [mem 0xbb1fe000-0xbf1fe000] (64MB)
>
> Without this patch I can boot all the way to looking for a rootFS.
>
> Please don't send new versions of patches without addresses regressions.

The patches were sent after addressing all regressions you reported
(well the 32-bit Linux booting issue is actually not a QEMU
regression, but one that exists in the Linux kernel side for a long
time).

I just tested 64-bit Linux boot on both virt and sifive_u, and they
both can boot all the way to looking for a root fs.

Regards,
Bin

Re: [PATCH v4 4/7] hw/riscv: Use pre-built bios image of generic platform for virt & sifive_u

[Alistair Francis]

On Tue, Jul 28, 2020 at 9:51 PM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> Hi Alistair,
>
> On Wed, Jul 29, 2020 at 2:26 AM Alistair Francis <alistair23@gmail.com> wrote:
> >
> > On Tue, Jul 28, 2020 at 8:46 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> > >
> > > Hi Alistair,
> > >
> > > On Tue, Jul 28, 2020 at 11:39 PM Alistair Francis <alistair23@gmail.com> wrote:
> > > >
> > > > On Wed, Jul 15, 2020 at 9:55 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > >
> > > > > Hi Alistair,
> > > > >
> > > > > On Mon, Jul 13, 2020 at 9:53 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > >
> > > > > > On Sun, Jul 12, 2020 at 1:34 AM Alistair Francis <alistair23@gmail.com> wrote:
> > > > > > >
> > > > > > > On Thu, Jul 9, 2020 at 10:07 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > > > >
> > > > > > > > From: Bin Meng <bin.meng@windriver.com>
> > > > > > > >
> > > > > > > > Update virt and sifive_u machines to use the opensbi fw_dynamic bios
> > > > > > > > image built for the generic FDT platform.
> > > > > > > >
> > > > > > > > Remove the out-of-date no longer used bios images.
> > > > > > > >
> > > > > > > > Signed-off-by: Bin Meng <bin.meng@windriver.com>
> > > > > > > > Reviewed-by: Anup Patel <anup@brainfault.org>
> > > > > > > > Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
> > > > > > >
> > > > > > > This patch seems to break 32-bit Linux boots on the sifive_u and virt machines.
> > > > > > >
> > > > > >
> > > > > > It looks only Linux boot on sifive_u is broken. On our side, we have
> > > > > > been using VxWorks to test 32-bit OpenSBI on sifive_u so this issue
> > > > > > gets unnoticed. I will take a look.
> > > > >
> > > > > I've figured out the issue of 32-bit Linux booting failure on
> > > > > sifive_u. A patch has been sent to Linux upstream:
> > > > > http://lists.infradead.org/pipermail/linux-riscv/2020-July/001213.html
> > > >
> > > > Thanks for that. What change in QEMU causes this failure though?
> > > >
> > >
> > > There is nothing wrong in QEMU.
> >
> > There is. This patch causes a regression for 32-bit Linux boot on the
> > sifive_u. Your v5 has not addressed this.
>
> The 32-bit Linux boot failure was fixed by:
> http://lists.infradead.org/pipermail/linux-riscv/2020-July/001213.html
>
> What additional issue did you see?
>
> >
> > With this patch, the Linux boot stops here:
> >
> > OpenSBI v0.8
> >    ____                    _____ ____ _____
> >   / __ \                  / ____|  _ \_   _|
> >  | |  | |_ __   ___ _ __ | (___ | |_) || |
> >  | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
> >  | |__| | |_) |  __/ | | |____) | |_) || |_
> >   \____/| .__/ \___|_| |_|_____/|____/_____|
> >         | |
> >         |_|
> >
> > Platform Name       : SiFive HiFive Unleashed A00
> > Platform Features   : timer,mfdeleg
> > Platform HART Count : 4
> > Boot HART ID        : 3
> > Boot HART ISA       : rv64imafdcsu
>
> This is a 64-bit hardware.

You are right. It's not 32-bit, that was my mistake. I'm used to my
first test being 32-bit, but in this case it's not.

It looks like this commit instead breaks the sifive_u for 64-bit with
the 5.3 kernel.

>
> > BOOT HART Features  : pmp,scounteren,mcounteren
> > BOOT HART PMP Count : 16
> > Firmware Base       : 0x80000000
> > Firmware Size       : 116 KB
> > Runtime SBI Version : 0.2
> >
> > MIDELEG : 0x0000000000000222
> > MEDELEG : 0x000000000000b109
> > PMP0    : 0x0000000080000000-0x000000008001ffff (A)
> > PMP1    : 0x0000000000000000-0xffffffffffffffff (A,R,W,X)
> > [    0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80200000
> > [    0.000000] Linux version 5.3.0 (oe-user@oe-host) (gcc version
>
> It seems that you are using quite an old kernel. Can you please try
> the latest version?

It is an old kernel, but old kernels should still keep working (or we
should at least know why they don't)

>
> > 9.2.0 (GCC)) #1 SMP Thu Sep 19 18:34:52 UTC 2019
> > [    0.000000] earlycon: sbi0 at I/O port 0x0 (options '')
> > [    0.000000] printk: bootconsole [sbi0] enabled
> > [    0.000000] initrd not found or empty - disabling initrd
> > [    0.000000] Zone ranges:
> > [    0.000000]   DMA32    [mem 0x0000000080200000-0x00000000bfffffff]
> > [    0.000000]   Normal   empty
> > [    0.000000] Movable zone start for each node
> > [    0.000000] Early memory node ranges
> > [    0.000000]   node   0: [mem 0x0000000080200000-0x00000000bfffffff]
> > [    0.000000] Initmem setup node 0 [mem 0x0000000080200000-0x00000000bfffffff]
> > [    0.000000] OF: fdt: Invalid device tree blob header
> > [    0.000000] software IO TLB: mapped [mem 0xbb1fe000-0xbf1fe000] (64MB)
> >
> > Without this patch I can boot all the way to looking for a rootFS.
> >
> > Please don't send new versions of patches without addresses regressions.
>
> The patches were sent after addressing all regressions you reported
> (well the 32-bit Linux booting issue is actually not a QEMU
> regression, but one that exists in the Linux kernel side for a long
> time).

Yep, that is my mistake. Sorry about the confusion.

>
> I just tested 64-bit Linux boot on both virt and sifive_u, and they
> both can boot all the way to looking for a root fs.

Can you test with older kernels?

If we can't support older kernels with the default bios option we at
least need to know why and list that in the release notes.

Alistair

>
> Regards,
> Bin

Re: [PATCH v4 4/7] hw/riscv: Use pre-built bios image of generic platform for virt & sifive_u

[Alistair Francis]

On Tue, Jul 28, 2020 at 9:51 PM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> Hi Alistair,
>
> On Wed, Jul 29, 2020 at 2:26 AM Alistair Francis <alistair23@gmail.com> wrote:
> >
> > On Tue, Jul 28, 2020 at 8:46 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> > >
> > > Hi Alistair,
> > >
> > > On Tue, Jul 28, 2020 at 11:39 PM Alistair Francis <alistair23@gmail.com> wrote:
> > > >
> > > > On Wed, Jul 15, 2020 at 9:55 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > >
> > > > > Hi Alistair,
> > > > >
> > > > > On Mon, Jul 13, 2020 at 9:53 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > >
> > > > > > On Sun, Jul 12, 2020 at 1:34 AM Alistair Francis <alistair23@gmail.com> wrote:
> > > > > > >
> > > > > > > On Thu, Jul 9, 2020 at 10:07 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > > > >
> > > > > > > > From: Bin Meng <bin.meng@windriver.com>
> > > > > > > >
> > > > > > > > Update virt and sifive_u machines to use the opensbi fw_dynamic bios
> > > > > > > > image built for the generic FDT platform.
> > > > > > > >
> > > > > > > > Remove the out-of-date no longer used bios images.
> > > > > > > >
> > > > > > > > Signed-off-by: Bin Meng <bin.meng@windriver.com>
> > > > > > > > Reviewed-by: Anup Patel <anup@brainfault.org>
> > > > > > > > Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
> > > > > > >
> > > > > > > This patch seems to break 32-bit Linux boots on the sifive_u and virt machines.
> > > > > > >
> > > > > >
> > > > > > It looks only Linux boot on sifive_u is broken. On our side, we have
> > > > > > been using VxWorks to test 32-bit OpenSBI on sifive_u so this issue
> > > > > > gets unnoticed. I will take a look.
> > > > >
> > > > > I've figured out the issue of 32-bit Linux booting failure on
> > > > > sifive_u. A patch has been sent to Linux upstream:
> > > > > http://lists.infradead.org/pipermail/linux-riscv/2020-July/001213.html
> > > >
> > > > Thanks for that. What change in QEMU causes this failure though?
> > > >
> > >
> > > There is nothing wrong in QEMU.
> >
> > There is. This patch causes a regression for 32-bit Linux boot on the
> > sifive_u. Your v5 has not addressed this.
>
> The 32-bit Linux boot failure was fixed by:
> http://lists.infradead.org/pipermail/linux-riscv/2020-July/001213.html
>
> What additional issue did you see?
>
> >
> > With this patch, the Linux boot stops here:
> >
> > OpenSBI v0.8
> >    ____                    _____ ____ _____
> >   / __ \                  / ____|  _ \_   _|
> >  | |  | |_ __   ___ _ __ | (___ | |_) || |
> >  | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
> >  | |__| | |_) |  __/ | | |____) | |_) || |_
> >   \____/| .__/ \___|_| |_|_____/|____/_____|
> >         | |
> >         |_|
> >
> > Platform Name       : SiFive HiFive Unleashed A00
> > Platform Features   : timer,mfdeleg
> > Platform HART Count : 4
> > Boot HART ID        : 3
> > Boot HART ISA       : rv64imafdcsu
>
> This is a 64-bit hardware.

You are right. It's not 32-bit, that was my mistake. I'm used to my
first test being 32-bit, but in this case it's not.

It looks like this commit instead breaks the sifive_u for 64-bit with
the 5.3 kernel.

>
> > BOOT HART Features  : pmp,scounteren,mcounteren
> > BOOT HART PMP Count : 16
> > Firmware Base       : 0x80000000
> > Firmware Size       : 116 KB
> > Runtime SBI Version : 0.2
> >
> > MIDELEG : 0x0000000000000222
> > MEDELEG : 0x000000000000b109
> > PMP0    : 0x0000000080000000-0x000000008001ffff (A)
> > PMP1    : 0x0000000000000000-0xffffffffffffffff (A,R,W,X)
> > [    0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80200000
> > [    0.000000] Linux version 5.3.0 (oe-user@oe-host) (gcc version
>
> It seems that you are using quite an old kernel. Can you please try
> the latest version?

It is an old kernel, but old kernels should still keep working (or we
should at least know why they don't)

>
> > 9.2.0 (GCC)) #1 SMP Thu Sep 19 18:34:52 UTC 2019
> > [    0.000000] earlycon: sbi0 at I/O port 0x0 (options '')
> > [    0.000000] printk: bootconsole [sbi0] enabled
> > [    0.000000] initrd not found or empty - disabling initrd
> > [    0.000000] Zone ranges:
> > [    0.000000]   DMA32    [mem 0x0000000080200000-0x00000000bfffffff]
> > [    0.000000]   Normal   empty
> > [    0.000000] Movable zone start for each node
> > [    0.000000] Early memory node ranges
> > [    0.000000]   node   0: [mem 0x0000000080200000-0x00000000bfffffff]
> > [    0.000000] Initmem setup node 0 [mem 0x0000000080200000-0x00000000bfffffff]
> > [    0.000000] OF: fdt: Invalid device tree blob header
> > [    0.000000] software IO TLB: mapped [mem 0xbb1fe000-0xbf1fe000] (64MB)
> >
> > Without this patch I can boot all the way to looking for a rootFS.
> >
> > Please don't send new versions of patches without addresses regressions.
>
> The patches were sent after addressing all regressions you reported
> (well the 32-bit Linux booting issue is actually not a QEMU
> regression, but one that exists in the Linux kernel side for a long
> time).

Yep, that is my mistake. Sorry about the confusion.

>
> I just tested 64-bit Linux boot on both virt and sifive_u, and they
> both can boot all the way to looking for a root fs.

Can you test with older kernels?

If we can't support older kernels with the default bios option we at
least need to know why and list that in the release notes.

Alistair

>
> Regards,
> Bin

Re: [PATCH v4 4/7] hw/riscv: Use pre-built bios image of generic platform for virt & sifive_u

[Bin Meng]

Hi Alistair,

On Wed, Jul 29, 2020 at 1:05 PM Alistair Francis <alistair23@gmail.com> wrote:
>
> On Tue, Jul 28, 2020 at 9:51 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > Hi Alistair,
> >
> > On Wed, Jul 29, 2020 at 2:26 AM Alistair Francis <alistair23@gmail.com> wrote:
> > >
> > > On Tue, Jul 28, 2020 at 8:46 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > >
> > > > Hi Alistair,
> > > >
> > > > On Tue, Jul 28, 2020 at 11:39 PM Alistair Francis <alistair23@gmail.com> wrote:
> > > > >
> > > > > On Wed, Jul 15, 2020 at 9:55 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > >
> > > > > > Hi Alistair,
> > > > > >
> > > > > > On Mon, Jul 13, 2020 at 9:53 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > > >
> > > > > > > On Sun, Jul 12, 2020 at 1:34 AM Alistair Francis <alistair23@gmail.com> wrote:
> > > > > > > >
> > > > > > > > On Thu, Jul 9, 2020 at 10:07 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > From: Bin Meng <bin.meng@windriver.com>
> > > > > > > > >
> > > > > > > > > Update virt and sifive_u machines to use the opensbi fw_dynamic bios
> > > > > > > > > image built for the generic FDT platform.
> > > > > > > > >
> > > > > > > > > Remove the out-of-date no longer used bios images.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Bin Meng <bin.meng@windriver.com>
> > > > > > > > > Reviewed-by: Anup Patel <anup@brainfault.org>
> > > > > > > > > Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
> > > > > > > >
> > > > > > > > This patch seems to break 32-bit Linux boots on the sifive_u and virt machines.
> > > > > > > >
> > > > > > >
> > > > > > > It looks only Linux boot on sifive_u is broken. On our side, we have
> > > > > > > been using VxWorks to test 32-bit OpenSBI on sifive_u so this issue
> > > > > > > gets unnoticed. I will take a look.
> > > > > >
> > > > > > I've figured out the issue of 32-bit Linux booting failure on
> > > > > > sifive_u. A patch has been sent to Linux upstream:
> > > > > > http://lists.infradead.org/pipermail/linux-riscv/2020-July/001213.html
> > > > >
> > > > > Thanks for that. What change in QEMU causes this failure though?
> > > > >
> > > >
> > > > There is nothing wrong in QEMU.
> > >
> > > There is. This patch causes a regression for 32-bit Linux boot on the
> > > sifive_u. Your v5 has not addressed this.
> >
> > The 32-bit Linux boot failure was fixed by:
> > http://lists.infradead.org/pipermail/linux-riscv/2020-July/001213.html
> >
> > What additional issue did you see?
> >
> > >
> > > With this patch, the Linux boot stops here:
> > >
> > > OpenSBI v0.8
> > >    ____                    _____ ____ _____
> > >   / __ \                  / ____|  _ \_   _|
> > >  | |  | |_ __   ___ _ __ | (___ | |_) || |
> > >  | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
> > >  | |__| | |_) |  __/ | | |____) | |_) || |_
> > >   \____/| .__/ \___|_| |_|_____/|____/_____|
> > >         | |
> > >         |_|
> > >
> > > Platform Name       : SiFive HiFive Unleashed A00
> > > Platform Features   : timer,mfdeleg
> > > Platform HART Count : 4
> > > Boot HART ID        : 3
> > > Boot HART ISA       : rv64imafdcsu
> >
> > This is a 64-bit hardware.
>
> You are right. It's not 32-bit, that was my mistake. I'm used to my
> first test being 32-bit, but in this case it's not.
>
> It looks like this commit instead breaks the sifive_u for 64-bit with
> the 5.3 kernel.
>
> >
> > > BOOT HART Features  : pmp,scounteren,mcounteren
> > > BOOT HART PMP Count : 16
> > > Firmware Base       : 0x80000000
> > > Firmware Size       : 116 KB
> > > Runtime SBI Version : 0.2
> > >
> > > MIDELEG : 0x0000000000000222
> > > MEDELEG : 0x000000000000b109
> > > PMP0    : 0x0000000080000000-0x000000008001ffff (A)
> > > PMP1    : 0x0000000000000000-0xffffffffffffffff (A,R,W,X)
> > > [    0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80200000
> > > [    0.000000] Linux version 5.3.0 (oe-user@oe-host) (gcc version
> >
> > It seems that you are using quite an old kernel. Can you please try
> > the latest version?
>
> It is an old kernel, but old kernels should still keep working (or we
> should at least know why they don't)
>
> >
> > > 9.2.0 (GCC)) #1 SMP Thu Sep 19 18:34:52 UTC 2019
> > > [    0.000000] earlycon: sbi0 at I/O port 0x0 (options '')
> > > [    0.000000] printk: bootconsole [sbi0] enabled
> > > [    0.000000] initrd not found or empty - disabling initrd
> > > [    0.000000] Zone ranges:
> > > [    0.000000]   DMA32    [mem 0x0000000080200000-0x00000000bfffffff]
> > > [    0.000000]   Normal   empty
> > > [    0.000000] Movable zone start for each node
> > > [    0.000000] Early memory node ranges
> > > [    0.000000]   node   0: [mem 0x0000000080200000-0x00000000bfffffff]
> > > [    0.000000] Initmem setup node 0 [mem 0x0000000080200000-0x00000000bfffffff]
> > > [    0.000000] OF: fdt: Invalid device tree blob header
> > > [    0.000000] software IO TLB: mapped [mem 0xbb1fe000-0xbf1fe000] (64MB)
> > >
> > > Without this patch I can boot all the way to looking for a rootFS.
> > >
> > > Please don't send new versions of patches without addresses regressions.
> >
> > The patches were sent after addressing all regressions you reported
> > (well the 32-bit Linux booting issue is actually not a QEMU
> > regression, but one that exists in the Linux kernel side for a long
> > time).
>
> Yep, that is my mistake. Sorry about the confusion.
>
> >
> > I just tested 64-bit Linux boot on both virt and sifive_u, and they
> > both can boot all the way to looking for a root fs.
>
> Can you test with older kernels?
>

OK I will investigate.

> If we can't support older kernels with the default bios option we at
> least need to know why and list that in the release notes.
>

Regards,
Bin

Re: [PATCH v4 4/7] hw/riscv: Use pre-built bios image of generic platform for virt & sifive_u

[Bin Meng]

Hi Alistair,

On Wed, Jul 29, 2020 at 1:05 PM Alistair Francis <alistair23@gmail.com> wrote:
>
> On Tue, Jul 28, 2020 at 9:51 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > Hi Alistair,
> >
> > On Wed, Jul 29, 2020 at 2:26 AM Alistair Francis <alistair23@gmail.com> wrote:
> > >
> > > On Tue, Jul 28, 2020 at 8:46 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > >
> > > > Hi Alistair,
> > > >
> > > > On Tue, Jul 28, 2020 at 11:39 PM Alistair Francis <alistair23@gmail.com> wrote:
> > > > >
> > > > > On Wed, Jul 15, 2020 at 9:55 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > >
> > > > > > Hi Alistair,
> > > > > >
> > > > > > On Mon, Jul 13, 2020 at 9:53 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > > >
> > > > > > > On Sun, Jul 12, 2020 at 1:34 AM Alistair Francis <alistair23@gmail.com> wrote:
> > > > > > > >
> > > > > > > > On Thu, Jul 9, 2020 at 10:07 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > From: Bin Meng <bin.meng@windriver.com>
> > > > > > > > >
> > > > > > > > > Update virt and sifive_u machines to use the opensbi fw_dynamic bios
> > > > > > > > > image built for the generic FDT platform.
> > > > > > > > >
> > > > > > > > > Remove the out-of-date no longer used bios images.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Bin Meng <bin.meng@windriver.com>
> > > > > > > > > Reviewed-by: Anup Patel <anup@brainfault.org>
> > > > > > > > > Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
> > > > > > > >
> > > > > > > > This patch seems to break 32-bit Linux boots on the sifive_u and virt machines.
> > > > > > > >
> > > > > > >
> > > > > > > It looks only Linux boot on sifive_u is broken. On our side, we have
> > > > > > > been using VxWorks to test 32-bit OpenSBI on sifive_u so this issue
> > > > > > > gets unnoticed. I will take a look.
> > > > > >
> > > > > > I've figured out the issue of 32-bit Linux booting failure on
> > > > > > sifive_u. A patch has been sent to Linux upstream:
> > > > > > http://lists.infradead.org/pipermail/linux-riscv/2020-July/001213.html
> > > > >
> > > > > Thanks for that. What change in QEMU causes this failure though?
> > > > >
> > > >
> > > > There is nothing wrong in QEMU.
> > >
> > > There is. This patch causes a regression for 32-bit Linux boot on the
> > > sifive_u. Your v5 has not addressed this.
> >
> > The 32-bit Linux boot failure was fixed by:
> > http://lists.infradead.org/pipermail/linux-riscv/2020-July/001213.html
> >
> > What additional issue did you see?
> >
> > >
> > > With this patch, the Linux boot stops here:
> > >
> > > OpenSBI v0.8
> > >    ____                    _____ ____ _____
> > >   / __ \                  / ____|  _ \_   _|
> > >  | |  | |_ __   ___ _ __ | (___ | |_) || |
> > >  | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
> > >  | |__| | |_) |  __/ | | |____) | |_) || |_
> > >   \____/| .__/ \___|_| |_|_____/|____/_____|
> > >         | |
> > >         |_|
> > >
> > > Platform Name       : SiFive HiFive Unleashed A00
> > > Platform Features   : timer,mfdeleg
> > > Platform HART Count : 4
> > > Boot HART ID        : 3
> > > Boot HART ISA       : rv64imafdcsu
> >
> > This is a 64-bit hardware.
>
> You are right. It's not 32-bit, that was my mistake. I'm used to my
> first test being 32-bit, but in this case it's not.
>
> It looks like this commit instead breaks the sifive_u for 64-bit with
> the 5.3 kernel.
>
> >
> > > BOOT HART Features  : pmp,scounteren,mcounteren
> > > BOOT HART PMP Count : 16
> > > Firmware Base       : 0x80000000
> > > Firmware Size       : 116 KB
> > > Runtime SBI Version : 0.2
> > >
> > > MIDELEG : 0x0000000000000222
> > > MEDELEG : 0x000000000000b109
> > > PMP0    : 0x0000000080000000-0x000000008001ffff (A)
> > > PMP1    : 0x0000000000000000-0xffffffffffffffff (A,R,W,X)
> > > [    0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80200000
> > > [    0.000000] Linux version 5.3.0 (oe-user@oe-host) (gcc version
> >
> > It seems that you are using quite an old kernel. Can you please try
> > the latest version?
>
> It is an old kernel, but old kernels should still keep working (or we
> should at least know why they don't)
>
> >
> > > 9.2.0 (GCC)) #1 SMP Thu Sep 19 18:34:52 UTC 2019
> > > [    0.000000] earlycon: sbi0 at I/O port 0x0 (options '')
> > > [    0.000000] printk: bootconsole [sbi0] enabled
> > > [    0.000000] initrd not found or empty - disabling initrd
> > > [    0.000000] Zone ranges:
> > > [    0.000000]   DMA32    [mem 0x0000000080200000-0x00000000bfffffff]
> > > [    0.000000]   Normal   empty
> > > [    0.000000] Movable zone start for each node
> > > [    0.000000] Early memory node ranges
> > > [    0.000000]   node   0: [mem 0x0000000080200000-0x00000000bfffffff]
> > > [    0.000000] Initmem setup node 0 [mem 0x0000000080200000-0x00000000bfffffff]
> > > [    0.000000] OF: fdt: Invalid device tree blob header
> > > [    0.000000] software IO TLB: mapped [mem 0xbb1fe000-0xbf1fe000] (64MB)
> > >
> > > Without this patch I can boot all the way to looking for a rootFS.
> > >
> > > Please don't send new versions of patches without addresses regressions.
> >
> > The patches were sent after addressing all regressions you reported
> > (well the 32-bit Linux booting issue is actually not a QEMU
> > regression, but one that exists in the Linux kernel side for a long
> > time).
>
> Yep, that is my mistake. Sorry about the confusion.
>
> >
> > I just tested 64-bit Linux boot on both virt and sifive_u, and they
> > both can boot all the way to looking for a root fs.
>
> Can you test with older kernels?
>

OK I will investigate.

> If we can't support older kernels with the default bios option we at
> least need to know why and list that in the release notes.
>

Regards,
Bin

Re: [PATCH v4 4/7] hw/riscv: Use pre-built bios image of generic platform for virt & sifive_u

[Bin Meng]

Hi Alistair,

On Wed, Jul 29, 2020 at 1:10 PM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> Hi Alistair,
>
> On Wed, Jul 29, 2020 at 1:05 PM Alistair Francis <alistair23@gmail.com> wrote:
> >
> > On Tue, Jul 28, 2020 at 9:51 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > >
> > > Hi Alistair,
> > >
> > > On Wed, Jul 29, 2020 at 2:26 AM Alistair Francis <alistair23@gmail.com> wrote:
> > > >
> > > > On Tue, Jul 28, 2020 at 8:46 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > >
> > > > > Hi Alistair,
> > > > >
> > > > > On Tue, Jul 28, 2020 at 11:39 PM Alistair Francis <alistair23@gmail.com> wrote:
> > > > > >
> > > > > > On Wed, Jul 15, 2020 at 9:55 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > > >
> > > > > > > Hi Alistair,
> > > > > > >
> > > > > > > On Mon, Jul 13, 2020 at 9:53 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > > > >
> > > > > > > > On Sun, Jul 12, 2020 at 1:34 AM Alistair Francis <alistair23@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > On Thu, Jul 9, 2020 at 10:07 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > > > > > >
> > > > > > > > > > From: Bin Meng <bin.meng@windriver.com>
> > > > > > > > > >
> > > > > > > > > > Update virt and sifive_u machines to use the opensbi fw_dynamic bios
> > > > > > > > > > image built for the generic FDT platform.
> > > > > > > > > >
> > > > > > > > > > Remove the out-of-date no longer used bios images.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Bin Meng <bin.meng@windriver.com>
> > > > > > > > > > Reviewed-by: Anup Patel <anup@brainfault.org>
> > > > > > > > > > Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
> > > > > > > > >
> > > > > > > > > This patch seems to break 32-bit Linux boots on the sifive_u and virt machines.
> > > > > > > > >
> > > > > > > >
> > > > > > > > It looks only Linux boot on sifive_u is broken. On our side, we have
> > > > > > > > been using VxWorks to test 32-bit OpenSBI on sifive_u so this issue
> > > > > > > > gets unnoticed. I will take a look.
> > > > > > >
> > > > > > > I've figured out the issue of 32-bit Linux booting failure on
> > > > > > > sifive_u. A patch has been sent to Linux upstream:
> > > > > > > http://lists.infradead.org/pipermail/linux-riscv/2020-July/001213.html
> > > > > >
> > > > > > Thanks for that. What change in QEMU causes this failure though?
> > > > > >
> > > > >
> > > > > There is nothing wrong in QEMU.
> > > >
> > > > There is. This patch causes a regression for 32-bit Linux boot on the
> > > > sifive_u. Your v5 has not addressed this.
> > >
> > > The 32-bit Linux boot failure was fixed by:
> > > http://lists.infradead.org/pipermail/linux-riscv/2020-July/001213.html
> > >
> > > What additional issue did you see?
> > >
> > > >
> > > > With this patch, the Linux boot stops here:
> > > >
> > > > OpenSBI v0.8
> > > >    ____                    _____ ____ _____
> > > >   / __ \                  / ____|  _ \_   _|
> > > >  | |  | |_ __   ___ _ __ | (___ | |_) || |
> > > >  | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
> > > >  | |__| | |_) |  __/ | | |____) | |_) || |_
> > > >   \____/| .__/ \___|_| |_|_____/|____/_____|
> > > >         | |
> > > >         |_|
> > > >
> > > > Platform Name       : SiFive HiFive Unleashed A00
> > > > Platform Features   : timer,mfdeleg
> > > > Platform HART Count : 4
> > > > Boot HART ID        : 3
> > > > Boot HART ISA       : rv64imafdcsu
> > >
> > > This is a 64-bit hardware.
> >
> > You are right. It's not 32-bit, that was my mistake. I'm used to my
> > first test being 32-bit, but in this case it's not.
> >
> > It looks like this commit instead breaks the sifive_u for 64-bit with
> > the 5.3 kernel.
> >
> > >
> > > > BOOT HART Features  : pmp,scounteren,mcounteren
> > > > BOOT HART PMP Count : 16
> > > > Firmware Base       : 0x80000000
> > > > Firmware Size       : 116 KB
> > > > Runtime SBI Version : 0.2
> > > >
> > > > MIDELEG : 0x0000000000000222
> > > > MEDELEG : 0x000000000000b109
> > > > PMP0    : 0x0000000080000000-0x000000008001ffff (A)
> > > > PMP1    : 0x0000000000000000-0xffffffffffffffff (A,R,W,X)
> > > > [    0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80200000
> > > > [    0.000000] Linux version 5.3.0 (oe-user@oe-host) (gcc version
> > >
> > > It seems that you are using quite an old kernel. Can you please try
> > > the latest version?
> >
> > It is an old kernel, but old kernels should still keep working (or we
> > should at least know why they don't)
> >
> > >
> > > > 9.2.0 (GCC)) #1 SMP Thu Sep 19 18:34:52 UTC 2019
> > > > [    0.000000] earlycon: sbi0 at I/O port 0x0 (options '')
> > > > [    0.000000] printk: bootconsole [sbi0] enabled
> > > > [    0.000000] initrd not found or empty - disabling initrd
> > > > [    0.000000] Zone ranges:
> > > > [    0.000000]   DMA32    [mem 0x0000000080200000-0x00000000bfffffff]
> > > > [    0.000000]   Normal   empty
> > > > [    0.000000] Movable zone start for each node
> > > > [    0.000000] Early memory node ranges
> > > > [    0.000000]   node   0: [mem 0x0000000080200000-0x00000000bfffffff]
> > > > [    0.000000] Initmem setup node 0 [mem 0x0000000080200000-0x00000000bfffffff]
> > > > [    0.000000] OF: fdt: Invalid device tree blob header
> > > > [    0.000000] software IO TLB: mapped [mem 0xbb1fe000-0xbf1fe000] (64MB)
> > > >
> > > > Without this patch I can boot all the way to looking for a rootFS.
> > > >
> > > > Please don't send new versions of patches without addresses regressions.
> > >
> > > The patches were sent after addressing all regressions you reported
> > > (well the 32-bit Linux booting issue is actually not a QEMU
> > > regression, but one that exists in the Linux kernel side for a long
> > > time).
> >
> > Yep, that is my mistake. Sorry about the confusion.
> >
> > >
> > > I just tested 64-bit Linux boot on both virt and sifive_u, and they
> > > both can boot all the way to looking for a root fs.
> >
> > Can you test with older kernels?
> >
>
> OK I will investigate.

I've located the commit in the newer Linux kernel that fixed the boot
failure of the 5.3 kernel. See below:

commit 922b0375fc93fb1a20c5617e37c389c26bbccb70
Author: Albert Ou <aou@eecs.berkeley.edu>
Date:   Fri Sep 27 16:14:18 2019 -0700

    riscv: Fix memblock reservation for device tree blob

    This fixes an error with how the FDT blob is reserved in memblock.
    An incorrect physical address calculation exposed the FDT header to
    unintended corruption, which typically manifested with of_fdt_raw_init()
    faulting during late boot after fdt_totalsize() returned a wrong value.
    Systems with smaller physical memory sizes more frequently trigger this
    issue, as the kernel is more likely to allocate from the DMA32 zone
    where bbl places the DTB after the kernel image.

    Commit 671f9a3e2e24 ("RISC-V: Setup initial page tables in two stages")
    changed the mapping of the DTB to reside in the fixmap area.
    Consequently, early_init_fdt_reserve_self() cannot be used anymore in
    setup_bootmem() since it relies on __pa() to derive a physical address,
    which does not work with dtb_early_va that is no longer a valid kernel
    logical address.

    The reserved[0x1] region shows the effect of the pointer underflow
    resulting from the __pa(initial_boot_params) offset subtraction:

    [    0.000000] MEMBLOCK configuration:
    [    0.000000]  memory size = 0x000000001fe00000 reserved size =
0x0000000000a2e514
    [    0.000000]  memory.cnt  = 0x1
    [    0.000000]  memory[0x0]
[0x0000000080200000-0x000000009fffffff], 0x000000001fe00000 bytes
flags: 0x0
    [    0.000000]  reserved.cnt  = 0x2
    [    0.000000]  reserved[0x0]
[0x0000000080200000-0x0000000080c2dfeb], 0x0000000000a2dfec bytes
flags: 0x0
    [    0.000000]  reserved[0x1]
[0xfffffff080100000-0xfffffff080100527], 0x0000000000000528 bytes
flags: 0x0

    With the fix applied:

    [    0.000000] MEMBLOCK configuration:
    [    0.000000]  memory size = 0x000000001fe00000 reserved size =
0x0000000000a2e514
    [    0.000000]  memory.cnt  = 0x1
    [    0.000000]  memory[0x0]
[0x0000000080200000-0x000000009fffffff], 0x000000001fe00000 bytes
flags: 0x0
    [    0.000000]  reserved.cnt  = 0x2
    [    0.000000]  reserved[0x0]
[0x0000000080200000-0x0000000080c2dfeb], 0x0000000000a2dfec bytes
flags: 0x0
    [    0.000000]  reserved[0x1]
[0x0000000080e00000-0x0000000080e00527], 0x0000000000000528 bytes
flags: 0x0

    Fixes: 671f9a3e2e24 ("RISC-V: Setup initial page tables in two stages")
    Signed-off-by: Albert Ou <aou@eecs.berkeley.edu>
    Tested-by: Bin Meng <bmeng.cn@gmail.com>
    Reviewed-by: Anup Patel <anup@brainfault.org>
    Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>

As the commit message says, this commit is a fix to commit
671f9a3e2e24 ("RISC-V: Setup initial page tables in two stages") which
is in the 5.3 kernel:

commit 671f9a3e2e24cdeb2d2856abee7422f093e23e29
Author: Anup Patel <Anup.Patel@wdc.com>
Date:   Fri Jun 28 13:36:21 2019 -0700

    RISC-V: Setup initial page tables in two stages

    Currently, the setup_vm() does initial page table setup in one-shot
    very early before enabling MMU. Due to this, the setup_vm() has to map
    all possible kernel virtual addresses since it does not know size and
    location of RAM. This means we have kernel mappings for non-existent
    RAM and any buggy driver (or kernel) code doing out-of-bound access
    to RAM will not fault and cause underterministic behaviour.

    Further, the setup_vm() creates PMD mappings (i.e. 2M mappings) for
    RV64 systems. This means for PAGE_OFFSET=0xffffffe000000000 (i.e.
    MAXPHYSMEM_128GB=y), the setup_vm() will require 129 pages (i.e.
    516 KB) of memory for initial page tables which is never freed. The
    memory required for initial page tables will further increase if
    we chose a lower value of PAGE_OFFSET (e.g. 0xffffff0000000000)

    This patch implements two-staged initial page table setup, as follows:
    1. Early (i.e. setup_vm()): This stage maps kernel image and DTB in
    a early page table (i.e. early_pg_dir). The early_pg_dir will be used
    only by boot HART so it can be freed as-part of init memory free-up.
    2. Final (i.e. setup_vm_final()): This stage maps all possible RAM
    banks in the final page table (i.e. swapper_pg_dir). The boot HART
    will start using swapper_pg_dir at the end of setup_vm_final(). All
    non-boot HARTs directly use the swapper_pg_dir created by boot HART.

    We have following advantages with this new approach:
    1. Kernel mappings for non-existent RAM don't exists anymore.
    2. Memory consumed by initial page tables is now indpendent of the
    chosen PAGE_OFFSET.
    3. Memory consumed by initial page tables on RV64 system is 2 pages
    (i.e. 8 KB) which has significantly reduced and these pages will be
    freed as-part of the init memory free-up.

    The patch also provides a foundation for implementing strict kernel
    mappings where we protect kernel text and rodata using PTE permissions.

    Suggested-by: Mike Rapoport <rppt@linux.ibm.com>
    Signed-off-by: Anup Patel <anup.patel@wdc.com>
    [paul.walmsley@sifive.com: updated to apply; fixed a checkpatch warning]
    Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>

I cherry-picked 922b0375fc93fb1a20c5617e37c389c26bbccb70 on top of a
5.3 kernel, and with that the kernel boots again with this patch set.

>
> > If we can't support older kernels with the default bios option we at
> > least need to know why and list that in the release notes.
> >

I will include the above findings in my commit message of this series,
mentioning that to test an older kernel like 5.3 version Linux,
922b0375fc93fb1a20c5617e37c389c26bbccb70 should be cherry-picked.

Regards,
Bin

Re: [PATCH v4 4/7] hw/riscv: Use pre-built bios image of generic platform for virt & sifive_u

[Bin Meng]

Hi Alistair,

On Wed, Jul 29, 2020 at 1:10 PM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> Hi Alistair,
>
> On Wed, Jul 29, 2020 at 1:05 PM Alistair Francis <alistair23@gmail.com> wrote:
> >
> > On Tue, Jul 28, 2020 at 9:51 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > >
> > > Hi Alistair,
> > >
> > > On Wed, Jul 29, 2020 at 2:26 AM Alistair Francis <alistair23@gmail.com> wrote:
> > > >
> > > > On Tue, Jul 28, 2020 at 8:46 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > >
> > > > > Hi Alistair,
> > > > >
> > > > > On Tue, Jul 28, 2020 at 11:39 PM Alistair Francis <alistair23@gmail.com> wrote:
> > > > > >
> > > > > > On Wed, Jul 15, 2020 at 9:55 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > > >
> > > > > > > Hi Alistair,
> > > > > > >
> > > > > > > On Mon, Jul 13, 2020 at 9:53 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > > > >
> > > > > > > > On Sun, Jul 12, 2020 at 1:34 AM Alistair Francis <alistair23@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > On Thu, Jul 9, 2020 at 10:07 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > > > > > >
> > > > > > > > > > From: Bin Meng <bin.meng@windriver.com>
> > > > > > > > > >
> > > > > > > > > > Update virt and sifive_u machines to use the opensbi fw_dynamic bios
> > > > > > > > > > image built for the generic FDT platform.
> > > > > > > > > >
> > > > > > > > > > Remove the out-of-date no longer used bios images.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Bin Meng <bin.meng@windriver.com>
> > > > > > > > > > Reviewed-by: Anup Patel <anup@brainfault.org>
> > > > > > > > > > Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
> > > > > > > > >
> > > > > > > > > This patch seems to break 32-bit Linux boots on the sifive_u and virt machines.
> > > > > > > > >
> > > > > > > >
> > > > > > > > It looks only Linux boot on sifive_u is broken. On our side, we have
> > > > > > > > been using VxWorks to test 32-bit OpenSBI on sifive_u so this issue
> > > > > > > > gets unnoticed. I will take a look.
> > > > > > >
> > > > > > > I've figured out the issue of 32-bit Linux booting failure on
> > > > > > > sifive_u. A patch has been sent to Linux upstream:
> > > > > > > http://lists.infradead.org/pipermail/linux-riscv/2020-July/001213.html
> > > > > >
> > > > > > Thanks for that. What change in QEMU causes this failure though?
> > > > > >
> > > > >
> > > > > There is nothing wrong in QEMU.
> > > >
> > > > There is. This patch causes a regression for 32-bit Linux boot on the
> > > > sifive_u. Your v5 has not addressed this.
> > >
> > > The 32-bit Linux boot failure was fixed by:
> > > http://lists.infradead.org/pipermail/linux-riscv/2020-July/001213.html
> > >
> > > What additional issue did you see?
> > >
> > > >
> > > > With this patch, the Linux boot stops here:
> > > >
> > > > OpenSBI v0.8
> > > >    ____                    _____ ____ _____
> > > >   / __ \                  / ____|  _ \_   _|
> > > >  | |  | |_ __   ___ _ __ | (___ | |_) || |
> > > >  | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
> > > >  | |__| | |_) |  __/ | | |____) | |_) || |_
> > > >   \____/| .__/ \___|_| |_|_____/|____/_____|
> > > >         | |
> > > >         |_|
> > > >
> > > > Platform Name       : SiFive HiFive Unleashed A00
> > > > Platform Features   : timer,mfdeleg
> > > > Platform HART Count : 4
> > > > Boot HART ID        : 3
> > > > Boot HART ISA       : rv64imafdcsu
> > >
> > > This is a 64-bit hardware.
> >
> > You are right. It's not 32-bit, that was my mistake. I'm used to my
> > first test being 32-bit, but in this case it's not.
> >
> > It looks like this commit instead breaks the sifive_u for 64-bit with
> > the 5.3 kernel.
> >
> > >
> > > > BOOT HART Features  : pmp,scounteren,mcounteren
> > > > BOOT HART PMP Count : 16
> > > > Firmware Base       : 0x80000000
> > > > Firmware Size       : 116 KB
> > > > Runtime SBI Version : 0.2
> > > >
> > > > MIDELEG : 0x0000000000000222
> > > > MEDELEG : 0x000000000000b109
> > > > PMP0    : 0x0000000080000000-0x000000008001ffff (A)
> > > > PMP1    : 0x0000000000000000-0xffffffffffffffff (A,R,W,X)
> > > > [    0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80200000
> > > > [    0.000000] Linux version 5.3.0 (oe-user@oe-host) (gcc version
> > >
> > > It seems that you are using quite an old kernel. Can you please try
> > > the latest version?
> >
> > It is an old kernel, but old kernels should still keep working (or we
> > should at least know why they don't)
> >
> > >
> > > > 9.2.0 (GCC)) #1 SMP Thu Sep 19 18:34:52 UTC 2019
> > > > [    0.000000] earlycon: sbi0 at I/O port 0x0 (options '')
> > > > [    0.000000] printk: bootconsole [sbi0] enabled
> > > > [    0.000000] initrd not found or empty - disabling initrd
> > > > [    0.000000] Zone ranges:
> > > > [    0.000000]   DMA32    [mem 0x0000000080200000-0x00000000bfffffff]
> > > > [    0.000000]   Normal   empty
> > > > [    0.000000] Movable zone start for each node
> > > > [    0.000000] Early memory node ranges
> > > > [    0.000000]   node   0: [mem 0x0000000080200000-0x00000000bfffffff]
> > > > [    0.000000] Initmem setup node 0 [mem 0x0000000080200000-0x00000000bfffffff]
> > > > [    0.000000] OF: fdt: Invalid device tree blob header
> > > > [    0.000000] software IO TLB: mapped [mem 0xbb1fe000-0xbf1fe000] (64MB)
> > > >
> > > > Without this patch I can boot all the way to looking for a rootFS.
> > > >
> > > > Please don't send new versions of patches without addresses regressions.
> > >
> > > The patches were sent after addressing all regressions you reported
> > > (well the 32-bit Linux booting issue is actually not a QEMU
> > > regression, but one that exists in the Linux kernel side for a long
> > > time).
> >
> > Yep, that is my mistake. Sorry about the confusion.
> >
> > >
> > > I just tested 64-bit Linux boot on both virt and sifive_u, and they
> > > both can boot all the way to looking for a root fs.
> >
> > Can you test with older kernels?
> >
>
> OK I will investigate.

I've located the commit in the newer Linux kernel that fixed the boot
failure of the 5.3 kernel. See below:

commit 922b0375fc93fb1a20c5617e37c389c26bbccb70
Author: Albert Ou <aou@eecs.berkeley.edu>
Date:   Fri Sep 27 16:14:18 2019 -0700

    riscv: Fix memblock reservation for device tree blob

    This fixes an error with how the FDT blob is reserved in memblock.
    An incorrect physical address calculation exposed the FDT header to
    unintended corruption, which typically manifested with of_fdt_raw_init()
    faulting during late boot after fdt_totalsize() returned a wrong value.
    Systems with smaller physical memory sizes more frequently trigger this
    issue, as the kernel is more likely to allocate from the DMA32 zone
    where bbl places the DTB after the kernel image.

    Commit 671f9a3e2e24 ("RISC-V: Setup initial page tables in two stages")
    changed the mapping of the DTB to reside in the fixmap area.
    Consequently, early_init_fdt_reserve_self() cannot be used anymore in
    setup_bootmem() since it relies on __pa() to derive a physical address,
    which does not work with dtb_early_va that is no longer a valid kernel
    logical address.

    The reserved[0x1] region shows the effect of the pointer underflow
    resulting from the __pa(initial_boot_params) offset subtraction:

    [    0.000000] MEMBLOCK configuration:
    [    0.000000]  memory size = 0x000000001fe00000 reserved size =
0x0000000000a2e514
    [    0.000000]  memory.cnt  = 0x1
    [    0.000000]  memory[0x0]
[0x0000000080200000-0x000000009fffffff], 0x000000001fe00000 bytes
flags: 0x0
    [    0.000000]  reserved.cnt  = 0x2
    [    0.000000]  reserved[0x0]
[0x0000000080200000-0x0000000080c2dfeb], 0x0000000000a2dfec bytes
flags: 0x0
    [    0.000000]  reserved[0x1]
[0xfffffff080100000-0xfffffff080100527], 0x0000000000000528 bytes
flags: 0x0

    With the fix applied:

    [    0.000000] MEMBLOCK configuration:
    [    0.000000]  memory size = 0x000000001fe00000 reserved size =
0x0000000000a2e514
    [    0.000000]  memory.cnt  = 0x1
    [    0.000000]  memory[0x0]
[0x0000000080200000-0x000000009fffffff], 0x000000001fe00000 bytes
flags: 0x0
    [    0.000000]  reserved.cnt  = 0x2
    [    0.000000]  reserved[0x0]
[0x0000000080200000-0x0000000080c2dfeb], 0x0000000000a2dfec bytes
flags: 0x0
    [    0.000000]  reserved[0x1]
[0x0000000080e00000-0x0000000080e00527], 0x0000000000000528 bytes
flags: 0x0

    Fixes: 671f9a3e2e24 ("RISC-V: Setup initial page tables in two stages")
    Signed-off-by: Albert Ou <aou@eecs.berkeley.edu>
    Tested-by: Bin Meng <bmeng.cn@gmail.com>
    Reviewed-by: Anup Patel <anup@brainfault.org>
    Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>

As the commit message says, this commit is a fix to commit
671f9a3e2e24 ("RISC-V: Setup initial page tables in two stages") which
is in the 5.3 kernel:

commit 671f9a3e2e24cdeb2d2856abee7422f093e23e29
Author: Anup Patel <Anup.Patel@wdc.com>
Date:   Fri Jun 28 13:36:21 2019 -0700

    RISC-V: Setup initial page tables in two stages

    Currently, the setup_vm() does initial page table setup in one-shot
    very early before enabling MMU. Due to this, the setup_vm() has to map
    all possible kernel virtual addresses since it does not know size and
    location of RAM. This means we have kernel mappings for non-existent
    RAM and any buggy driver (or kernel) code doing out-of-bound access
    to RAM will not fault and cause underterministic behaviour.

    Further, the setup_vm() creates PMD mappings (i.e. 2M mappings) for
    RV64 systems. This means for PAGE_OFFSET=0xffffffe000000000 (i.e.
    MAXPHYSMEM_128GB=y), the setup_vm() will require 129 pages (i.e.
    516 KB) of memory for initial page tables which is never freed. The
    memory required for initial page tables will further increase if
    we chose a lower value of PAGE_OFFSET (e.g. 0xffffff0000000000)

    This patch implements two-staged initial page table setup, as follows:
    1. Early (i.e. setup_vm()): This stage maps kernel image and DTB in
    a early page table (i.e. early_pg_dir). The early_pg_dir will be used
    only by boot HART so it can be freed as-part of init memory free-up.
    2. Final (i.e. setup_vm_final()): This stage maps all possible RAM
    banks in the final page table (i.e. swapper_pg_dir). The boot HART
    will start using swapper_pg_dir at the end of setup_vm_final(). All
    non-boot HARTs directly use the swapper_pg_dir created by boot HART.

    We have following advantages with this new approach:
    1. Kernel mappings for non-existent RAM don't exists anymore.
    2. Memory consumed by initial page tables is now indpendent of the
    chosen PAGE_OFFSET.
    3. Memory consumed by initial page tables on RV64 system is 2 pages
    (i.e. 8 KB) which has significantly reduced and these pages will be
    freed as-part of the init memory free-up.

    The patch also provides a foundation for implementing strict kernel
    mappings where we protect kernel text and rodata using PTE permissions.

    Suggested-by: Mike Rapoport <rppt@linux.ibm.com>
    Signed-off-by: Anup Patel <anup.patel@wdc.com>
    [paul.walmsley@sifive.com: updated to apply; fixed a checkpatch warning]
    Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>

I cherry-picked 922b0375fc93fb1a20c5617e37c389c26bbccb70 on top of a
5.3 kernel, and with that the kernel boots again with this patch set.

>
> > If we can't support older kernels with the default bios option we at
> > least need to know why and list that in the release notes.
> >

I will include the above findings in my commit message of this series,
mentioning that to test an older kernel like 5.3 version Linux,
922b0375fc93fb1a20c5617e37c389c26bbccb70 should be cherry-picked.

Regards,
Bin

Re: [PATCH v4 4/7] hw/riscv: Use pre-built bios image of generic platform for virt & sifive_u

[Alistair Francis]

On Sun, Aug 2, 2020 at 11:51 PM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> Hi Alistair,
>
> On Wed, Jul 29, 2020 at 1:10 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > Hi Alistair,
> >
> > On Wed, Jul 29, 2020 at 1:05 PM Alistair Francis <alistair23@gmail.com> wrote:
> > >
> > > On Tue, Jul 28, 2020 at 9:51 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > >
> > > > Hi Alistair,
> > > >
> > > > On Wed, Jul 29, 2020 at 2:26 AM Alistair Francis <alistair23@gmail.com> wrote:
> > > > >
> > > > > On Tue, Jul 28, 2020 at 8:46 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > >
> > > > > > Hi Alistair,
> > > > > >
> > > > > > On Tue, Jul 28, 2020 at 11:39 PM Alistair Francis <alistair23@gmail.com> wrote:
> > > > > > >
> > > > > > > On Wed, Jul 15, 2020 at 9:55 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > > > >
> > > > > > > > Hi Alistair,
> > > > > > > >
> > > > > > > > On Mon, Jul 13, 2020 at 9:53 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > On Sun, Jul 12, 2020 at 1:34 AM Alistair Francis <alistair23@gmail.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Thu, Jul 9, 2020 at 10:07 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > From: Bin Meng <bin.meng@windriver.com>
> > > > > > > > > > >
> > > > > > > > > > > Update virt and sifive_u machines to use the opensbi fw_dynamic bios
> > > > > > > > > > > image built for the generic FDT platform.
> > > > > > > > > > >
> > > > > > > > > > > Remove the out-of-date no longer used bios images.
> > > > > > > > > > >
> > > > > > > > > > > Signed-off-by: Bin Meng <bin.meng@windriver.com>
> > > > > > > > > > > Reviewed-by: Anup Patel <anup@brainfault.org>
> > > > > > > > > > > Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
> > > > > > > > > >
> > > > > > > > > > This patch seems to break 32-bit Linux boots on the sifive_u and virt machines.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > It looks only Linux boot on sifive_u is broken. On our side, we have
> > > > > > > > > been using VxWorks to test 32-bit OpenSBI on sifive_u so this issue
> > > > > > > > > gets unnoticed. I will take a look.
> > > > > > > >
> > > > > > > > I've figured out the issue of 32-bit Linux booting failure on
> > > > > > > > sifive_u. A patch has been sent to Linux upstream:
> > > > > > > > http://lists.infradead.org/pipermail/linux-riscv/2020-July/001213.html
> > > > > > >
> > > > > > > Thanks for that. What change in QEMU causes this failure though?
> > > > > > >
> > > > > >
> > > > > > There is nothing wrong in QEMU.
> > > > >
> > > > > There is. This patch causes a regression for 32-bit Linux boot on the
> > > > > sifive_u. Your v5 has not addressed this.
> > > >
> > > > The 32-bit Linux boot failure was fixed by:
> > > > http://lists.infradead.org/pipermail/linux-riscv/2020-July/001213.html
> > > >
> > > > What additional issue did you see?
> > > >
> > > > >
> > > > > With this patch, the Linux boot stops here:
> > > > >
> > > > > OpenSBI v0.8
> > > > >    ____                    _____ ____ _____
> > > > >   / __ \                  / ____|  _ \_   _|
> > > > >  | |  | |_ __   ___ _ __ | (___ | |_) || |
> > > > >  | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
> > > > >  | |__| | |_) |  __/ | | |____) | |_) || |_
> > > > >   \____/| .__/ \___|_| |_|_____/|____/_____|
> > > > >         | |
> > > > >         |_|
> > > > >
> > > > > Platform Name       : SiFive HiFive Unleashed A00
> > > > > Platform Features   : timer,mfdeleg
> > > > > Platform HART Count : 4
> > > > > Boot HART ID        : 3
> > > > > Boot HART ISA       : rv64imafdcsu
> > > >
> > > > This is a 64-bit hardware.
> > >
> > > You are right. It's not 32-bit, that was my mistake. I'm used to my
> > > first test being 32-bit, but in this case it's not.
> > >
> > > It looks like this commit instead breaks the sifive_u for 64-bit with
> > > the 5.3 kernel.
> > >
> > > >
> > > > > BOOT HART Features  : pmp,scounteren,mcounteren
> > > > > BOOT HART PMP Count : 16
> > > > > Firmware Base       : 0x80000000
> > > > > Firmware Size       : 116 KB
> > > > > Runtime SBI Version : 0.2
> > > > >
> > > > > MIDELEG : 0x0000000000000222
> > > > > MEDELEG : 0x000000000000b109
> > > > > PMP0    : 0x0000000080000000-0x000000008001ffff (A)
> > > > > PMP1    : 0x0000000000000000-0xffffffffffffffff (A,R,W,X)
> > > > > [    0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80200000
> > > > > [    0.000000] Linux version 5.3.0 (oe-user@oe-host) (gcc version
> > > >
> > > > It seems that you are using quite an old kernel. Can you please try
> > > > the latest version?
> > >
> > > It is an old kernel, but old kernels should still keep working (or we
> > > should at least know why they don't)
> > >
> > > >
> > > > > 9.2.0 (GCC)) #1 SMP Thu Sep 19 18:34:52 UTC 2019
> > > > > [    0.000000] earlycon: sbi0 at I/O port 0x0 (options '')
> > > > > [    0.000000] printk: bootconsole [sbi0] enabled
> > > > > [    0.000000] initrd not found or empty - disabling initrd
> > > > > [    0.000000] Zone ranges:
> > > > > [    0.000000]   DMA32    [mem 0x0000000080200000-0x00000000bfffffff]
> > > > > [    0.000000]   Normal   empty
> > > > > [    0.000000] Movable zone start for each node
> > > > > [    0.000000] Early memory node ranges
> > > > > [    0.000000]   node   0: [mem 0x0000000080200000-0x00000000bfffffff]
> > > > > [    0.000000] Initmem setup node 0 [mem 0x0000000080200000-0x00000000bfffffff]
> > > > > [    0.000000] OF: fdt: Invalid device tree blob header
> > > > > [    0.000000] software IO TLB: mapped [mem 0xbb1fe000-0xbf1fe000] (64MB)
> > > > >
> > > > > Without this patch I can boot all the way to looking for a rootFS.
> > > > >
> > > > > Please don't send new versions of patches without addresses regressions.
> > > >
> > > > The patches were sent after addressing all regressions you reported
> > > > (well the 32-bit Linux booting issue is actually not a QEMU
> > > > regression, but one that exists in the Linux kernel side for a long
> > > > time).
> > >
> > > Yep, that is my mistake. Sorry about the confusion.
> > >
> > > >
> > > > I just tested 64-bit Linux boot on both virt and sifive_u, and they
> > > > both can boot all the way to looking for a root fs.
> > >
> > > Can you test with older kernels?
> > >
> >
> > OK I will investigate.
>
> I've located the commit in the newer Linux kernel that fixed the boot
> failure of the 5.3 kernel. See below:
>
> commit 922b0375fc93fb1a20c5617e37c389c26bbccb70
> Author: Albert Ou <aou@eecs.berkeley.edu>
> Date:   Fri Sep 27 16:14:18 2019 -0700
>
>     riscv: Fix memblock reservation for device tree blob
>
>     This fixes an error with how the FDT blob is reserved in memblock.
>     An incorrect physical address calculation exposed the FDT header to
>     unintended corruption, which typically manifested with of_fdt_raw_init()
>     faulting during late boot after fdt_totalsize() returned a wrong value.
>     Systems with smaller physical memory sizes more frequently trigger this
>     issue, as the kernel is more likely to allocate from the DMA32 zone
>     where bbl places the DTB after the kernel image.
>
>     Commit 671f9a3e2e24 ("RISC-V: Setup initial page tables in two stages")
>     changed the mapping of the DTB to reside in the fixmap area.
>     Consequently, early_init_fdt_reserve_self() cannot be used anymore in
>     setup_bootmem() since it relies on __pa() to derive a physical address,
>     which does not work with dtb_early_va that is no longer a valid kernel
>     logical address.
>
>     The reserved[0x1] region shows the effect of the pointer underflow
>     resulting from the __pa(initial_boot_params) offset subtraction:
>
>     [    0.000000] MEMBLOCK configuration:
>     [    0.000000]  memory size = 0x000000001fe00000 reserved size =
> 0x0000000000a2e514
>     [    0.000000]  memory.cnt  = 0x1
>     [    0.000000]  memory[0x0]
> [0x0000000080200000-0x000000009fffffff], 0x000000001fe00000 bytes
> flags: 0x0
>     [    0.000000]  reserved.cnt  = 0x2
>     [    0.000000]  reserved[0x0]
> [0x0000000080200000-0x0000000080c2dfeb], 0x0000000000a2dfec bytes
> flags: 0x0
>     [    0.000000]  reserved[0x1]
> [0xfffffff080100000-0xfffffff080100527], 0x0000000000000528 bytes
> flags: 0x0
>
>     With the fix applied:
>
>     [    0.000000] MEMBLOCK configuration:
>     [    0.000000]  memory size = 0x000000001fe00000 reserved size =
> 0x0000000000a2e514
>     [    0.000000]  memory.cnt  = 0x1
>     [    0.000000]  memory[0x0]
> [0x0000000080200000-0x000000009fffffff], 0x000000001fe00000 bytes
> flags: 0x0
>     [    0.000000]  reserved.cnt  = 0x2
>     [    0.000000]  reserved[0x0]
> [0x0000000080200000-0x0000000080c2dfeb], 0x0000000000a2dfec bytes
> flags: 0x0
>     [    0.000000]  reserved[0x1]
> [0x0000000080e00000-0x0000000080e00527], 0x0000000000000528 bytes
> flags: 0x0
>
>     Fixes: 671f9a3e2e24 ("RISC-V: Setup initial page tables in two stages")
>     Signed-off-by: Albert Ou <aou@eecs.berkeley.edu>
>     Tested-by: Bin Meng <bmeng.cn@gmail.com>
>     Reviewed-by: Anup Patel <anup@brainfault.org>
>     Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
>
> As the commit message says, this commit is a fix to commit
> 671f9a3e2e24 ("RISC-V: Setup initial page tables in two stages") which
> is in the 5.3 kernel:
>
> commit 671f9a3e2e24cdeb2d2856abee7422f093e23e29
> Author: Anup Patel <Anup.Patel@wdc.com>
> Date:   Fri Jun 28 13:36:21 2019 -0700
>
>     RISC-V: Setup initial page tables in two stages
>
>     Currently, the setup_vm() does initial page table setup in one-shot
>     very early before enabling MMU. Due to this, the setup_vm() has to map
>     all possible kernel virtual addresses since it does not know size and
>     location of RAM. This means we have kernel mappings for non-existent
>     RAM and any buggy driver (or kernel) code doing out-of-bound access
>     to RAM will not fault and cause underterministic behaviour.
>
>     Further, the setup_vm() creates PMD mappings (i.e. 2M mappings) for
>     RV64 systems. This means for PAGE_OFFSET=0xffffffe000000000 (i.e.
>     MAXPHYSMEM_128GB=y), the setup_vm() will require 129 pages (i.e.
>     516 KB) of memory for initial page tables which is never freed. The
>     memory required for initial page tables will further increase if
>     we chose a lower value of PAGE_OFFSET (e.g. 0xffffff0000000000)
>
>     This patch implements two-staged initial page table setup, as follows:
>     1. Early (i.e. setup_vm()): This stage maps kernel image and DTB in
>     a early page table (i.e. early_pg_dir). The early_pg_dir will be used
>     only by boot HART so it can be freed as-part of init memory free-up.
>     2. Final (i.e. setup_vm_final()): This stage maps all possible RAM
>     banks in the final page table (i.e. swapper_pg_dir). The boot HART
>     will start using swapper_pg_dir at the end of setup_vm_final(). All
>     non-boot HARTs directly use the swapper_pg_dir created by boot HART.
>
>     We have following advantages with this new approach:
>     1. Kernel mappings for non-existent RAM don't exists anymore.
>     2. Memory consumed by initial page tables is now indpendent of the
>     chosen PAGE_OFFSET.
>     3. Memory consumed by initial page tables on RV64 system is 2 pages
>     (i.e. 8 KB) which has significantly reduced and these pages will be
>     freed as-part of the init memory free-up.
>
>     The patch also provides a foundation for implementing strict kernel
>     mappings where we protect kernel text and rodata using PTE permissions.
>
>     Suggested-by: Mike Rapoport <rppt@linux.ibm.com>
>     Signed-off-by: Anup Patel <anup.patel@wdc.com>
>     [paul.walmsley@sifive.com: updated to apply; fixed a checkpatch warning]
>     Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
>
> I cherry-picked 922b0375fc93fb1a20c5617e37c389c26bbccb70 on top of a
> 5.3 kernel, and with that the kernel boots again with this patch set.

Thanks for looking into this. It's unfortunate that OpenSBI won't work
with older kernels, but people can always use their own OpenSBI build
in that case. 5.4 is an LTS and it works so that seems fine to me.

Alistair

>
> >
> > > If we can't support older kernels with the default bios option we at
> > > least need to know why and list that in the release notes.
> > >
>
> I will include the above findings in my commit message of this series,
> mentioning that to test an older kernel like 5.3 version Linux,
> 922b0375fc93fb1a20c5617e37c389c26bbccb70 should be cherry-picked.
>
> Regards,
> Bin

Re: [PATCH v4 4/7] hw/riscv: Use pre-built bios image of generic platform for virt & sifive_u

[Alistair Francis]

On Sun, Aug 2, 2020 at 11:51 PM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> Hi Alistair,
>
> On Wed, Jul 29, 2020 at 1:10 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > Hi Alistair,
> >
> > On Wed, Jul 29, 2020 at 1:05 PM Alistair Francis <alistair23@gmail.com> wrote:
> > >
> > > On Tue, Jul 28, 2020 at 9:51 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > >
> > > > Hi Alistair,
> > > >
> > > > On Wed, Jul 29, 2020 at 2:26 AM Alistair Francis <alistair23@gmail.com> wrote:
> > > > >
> > > > > On Tue, Jul 28, 2020 at 8:46 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > >
> > > > > > Hi Alistair,
> > > > > >
> > > > > > On Tue, Jul 28, 2020 at 11:39 PM Alistair Francis <alistair23@gmail.com> wrote:
> > > > > > >
> > > > > > > On Wed, Jul 15, 2020 at 9:55 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > > > >
> > > > > > > > Hi Alistair,
> > > > > > > >
> > > > > > > > On Mon, Jul 13, 2020 at 9:53 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > On Sun, Jul 12, 2020 at 1:34 AM Alistair Francis <alistair23@gmail.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Thu, Jul 9, 2020 at 10:07 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > From: Bin Meng <bin.meng@windriver.com>
> > > > > > > > > > >
> > > > > > > > > > > Update virt and sifive_u machines to use the opensbi fw_dynamic bios
> > > > > > > > > > > image built for the generic FDT platform.
> > > > > > > > > > >
> > > > > > > > > > > Remove the out-of-date no longer used bios images.
> > > > > > > > > > >
> > > > > > > > > > > Signed-off-by: Bin Meng <bin.meng@windriver.com>
> > > > > > > > > > > Reviewed-by: Anup Patel <anup@brainfault.org>
> > > > > > > > > > > Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
> > > > > > > > > >
> > > > > > > > > > This patch seems to break 32-bit Linux boots on the sifive_u and virt machines.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > It looks only Linux boot on sifive_u is broken. On our side, we have
> > > > > > > > > been using VxWorks to test 32-bit OpenSBI on sifive_u so this issue
> > > > > > > > > gets unnoticed. I will take a look.
> > > > > > > >
> > > > > > > > I've figured out the issue of 32-bit Linux booting failure on
> > > > > > > > sifive_u. A patch has been sent to Linux upstream:
> > > > > > > > http://lists.infradead.org/pipermail/linux-riscv/2020-July/001213.html
> > > > > > >
> > > > > > > Thanks for that. What change in QEMU causes this failure though?
> > > > > > >
> > > > > >
> > > > > > There is nothing wrong in QEMU.
> > > > >
> > > > > There is. This patch causes a regression for 32-bit Linux boot on the
> > > > > sifive_u. Your v5 has not addressed this.
> > > >
> > > > The 32-bit Linux boot failure was fixed by:
> > > > http://lists.infradead.org/pipermail/linux-riscv/2020-July/001213.html
> > > >
> > > > What additional issue did you see?
> > > >
> > > > >
> > > > > With this patch, the Linux boot stops here:
> > > > >
> > > > > OpenSBI v0.8
> > > > >    ____                    _____ ____ _____
> > > > >   / __ \                  / ____|  _ \_   _|
> > > > >  | |  | |_ __   ___ _ __ | (___ | |_) || |
> > > > >  | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
> > > > >  | |__| | |_) |  __/ | | |____) | |_) || |_
> > > > >   \____/| .__/ \___|_| |_|_____/|____/_____|
> > > > >         | |
> > > > >         |_|
> > > > >
> > > > > Platform Name       : SiFive HiFive Unleashed A00
> > > > > Platform Features   : timer,mfdeleg
> > > > > Platform HART Count : 4
> > > > > Boot HART ID        : 3
> > > > > Boot HART ISA       : rv64imafdcsu
> > > >
> > > > This is a 64-bit hardware.
> > >
> > > You are right. It's not 32-bit, that was my mistake. I'm used to my
> > > first test being 32-bit, but in this case it's not.
> > >
> > > It looks like this commit instead breaks the sifive_u for 64-bit with
> > > the 5.3 kernel.
> > >
> > > >
> > > > > BOOT HART Features  : pmp,scounteren,mcounteren
> > > > > BOOT HART PMP Count : 16
> > > > > Firmware Base       : 0x80000000
> > > > > Firmware Size       : 116 KB
> > > > > Runtime SBI Version : 0.2
> > > > >
> > > > > MIDELEG : 0x0000000000000222
> > > > > MEDELEG : 0x000000000000b109
> > > > > PMP0    : 0x0000000080000000-0x000000008001ffff (A)
> > > > > PMP1    : 0x0000000000000000-0xffffffffffffffff (A,R,W,X)
> > > > > [    0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80200000
> > > > > [    0.000000] Linux version 5.3.0 (oe-user@oe-host) (gcc version
> > > >
> > > > It seems that you are using quite an old kernel. Can you please try
> > > > the latest version?
> > >
> > > It is an old kernel, but old kernels should still keep working (or we
> > > should at least know why they don't)
> > >
> > > >
> > > > > 9.2.0 (GCC)) #1 SMP Thu Sep 19 18:34:52 UTC 2019
> > > > > [    0.000000] earlycon: sbi0 at I/O port 0x0 (options '')
> > > > > [    0.000000] printk: bootconsole [sbi0] enabled
> > > > > [    0.000000] initrd not found or empty - disabling initrd
> > > > > [    0.000000] Zone ranges:
> > > > > [    0.000000]   DMA32    [mem 0x0000000080200000-0x00000000bfffffff]
> > > > > [    0.000000]   Normal   empty
> > > > > [    0.000000] Movable zone start for each node
> > > > > [    0.000000] Early memory node ranges
> > > > > [    0.000000]   node   0: [mem 0x0000000080200000-0x00000000bfffffff]
> > > > > [    0.000000] Initmem setup node 0 [mem 0x0000000080200000-0x00000000bfffffff]
> > > > > [    0.000000] OF: fdt: Invalid device tree blob header
> > > > > [    0.000000] software IO TLB: mapped [mem 0xbb1fe000-0xbf1fe000] (64MB)
> > > > >
> > > > > Without this patch I can boot all the way to looking for a rootFS.
> > > > >
> > > > > Please don't send new versions of patches without addresses regressions.
> > > >
> > > > The patches were sent after addressing all regressions you reported
> > > > (well the 32-bit Linux booting issue is actually not a QEMU
> > > > regression, but one that exists in the Linux kernel side for a long
> > > > time).
> > >
> > > Yep, that is my mistake. Sorry about the confusion.
> > >
> > > >
> > > > I just tested 64-bit Linux boot on both virt and sifive_u, and they
> > > > both can boot all the way to looking for a root fs.
> > >
> > > Can you test with older kernels?
> > >
> >
> > OK I will investigate.
>
> I've located the commit in the newer Linux kernel that fixed the boot
> failure of the 5.3 kernel. See below:
>
> commit 922b0375fc93fb1a20c5617e37c389c26bbccb70
> Author: Albert Ou <aou@eecs.berkeley.edu>
> Date:   Fri Sep 27 16:14:18 2019 -0700
>
>     riscv: Fix memblock reservation for device tree blob
>
>     This fixes an error with how the FDT blob is reserved in memblock.
>     An incorrect physical address calculation exposed the FDT header to
>     unintended corruption, which typically manifested with of_fdt_raw_init()
>     faulting during late boot after fdt_totalsize() returned a wrong value.
>     Systems with smaller physical memory sizes more frequently trigger this
>     issue, as the kernel is more likely to allocate from the DMA32 zone
>     where bbl places the DTB after the kernel image.
>
>     Commit 671f9a3e2e24 ("RISC-V: Setup initial page tables in two stages")
>     changed the mapping of the DTB to reside in the fixmap area.
>     Consequently, early_init_fdt_reserve_self() cannot be used anymore in
>     setup_bootmem() since it relies on __pa() to derive a physical address,
>     which does not work with dtb_early_va that is no longer a valid kernel
>     logical address.
>
>     The reserved[0x1] region shows the effect of the pointer underflow
>     resulting from the __pa(initial_boot_params) offset subtraction:
>
>     [    0.000000] MEMBLOCK configuration:
>     [    0.000000]  memory size = 0x000000001fe00000 reserved size =
> 0x0000000000a2e514
>     [    0.000000]  memory.cnt  = 0x1
>     [    0.000000]  memory[0x0]
> [0x0000000080200000-0x000000009fffffff], 0x000000001fe00000 bytes
> flags: 0x0
>     [    0.000000]  reserved.cnt  = 0x2
>     [    0.000000]  reserved[0x0]
> [0x0000000080200000-0x0000000080c2dfeb], 0x0000000000a2dfec bytes
> flags: 0x0
>     [    0.000000]  reserved[0x1]
> [0xfffffff080100000-0xfffffff080100527], 0x0000000000000528 bytes
> flags: 0x0
>
>     With the fix applied:
>
>     [    0.000000] MEMBLOCK configuration:
>     [    0.000000]  memory size = 0x000000001fe00000 reserved size =
> 0x0000000000a2e514
>     [    0.000000]  memory.cnt  = 0x1
>     [    0.000000]  memory[0x0]
> [0x0000000080200000-0x000000009fffffff], 0x000000001fe00000 bytes
> flags: 0x0
>     [    0.000000]  reserved.cnt  = 0x2
>     [    0.000000]  reserved[0x0]
> [0x0000000080200000-0x0000000080c2dfeb], 0x0000000000a2dfec bytes
> flags: 0x0
>     [    0.000000]  reserved[0x1]
> [0x0000000080e00000-0x0000000080e00527], 0x0000000000000528 bytes
> flags: 0x0
>
>     Fixes: 671f9a3e2e24 ("RISC-V: Setup initial page tables in two stages")
>     Signed-off-by: Albert Ou <aou@eecs.berkeley.edu>
>     Tested-by: Bin Meng <bmeng.cn@gmail.com>
>     Reviewed-by: Anup Patel <anup@brainfault.org>
>     Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
>
> As the commit message says, this commit is a fix to commit
> 671f9a3e2e24 ("RISC-V: Setup initial page tables in two stages") which
> is in the 5.3 kernel:
>
> commit 671f9a3e2e24cdeb2d2856abee7422f093e23e29
> Author: Anup Patel <Anup.Patel@wdc.com>
> Date:   Fri Jun 28 13:36:21 2019 -0700
>
>     RISC-V: Setup initial page tables in two stages
>
>     Currently, the setup_vm() does initial page table setup in one-shot
>     very early before enabling MMU. Due to this, the setup_vm() has to map
>     all possible kernel virtual addresses since it does not know size and
>     location of RAM. This means we have kernel mappings for non-existent
>     RAM and any buggy driver (or kernel) code doing out-of-bound access
>     to RAM will not fault and cause underterministic behaviour.
>
>     Further, the setup_vm() creates PMD mappings (i.e. 2M mappings) for
>     RV64 systems. This means for PAGE_OFFSET=0xffffffe000000000 (i.e.
>     MAXPHYSMEM_128GB=y), the setup_vm() will require 129 pages (i.e.
>     516 KB) of memory for initial page tables which is never freed. The
>     memory required for initial page tables will further increase if
>     we chose a lower value of PAGE_OFFSET (e.g. 0xffffff0000000000)
>
>     This patch implements two-staged initial page table setup, as follows:
>     1. Early (i.e. setup_vm()): This stage maps kernel image and DTB in
>     a early page table (i.e. early_pg_dir). The early_pg_dir will be used
>     only by boot HART so it can be freed as-part of init memory free-up.
>     2. Final (i.e. setup_vm_final()): This stage maps all possible RAM
>     banks in the final page table (i.e. swapper_pg_dir). The boot HART
>     will start using swapper_pg_dir at the end of setup_vm_final(). All
>     non-boot HARTs directly use the swapper_pg_dir created by boot HART.
>
>     We have following advantages with this new approach:
>     1. Kernel mappings for non-existent RAM don't exists anymore.
>     2. Memory consumed by initial page tables is now indpendent of the
>     chosen PAGE_OFFSET.
>     3. Memory consumed by initial page tables on RV64 system is 2 pages
>     (i.e. 8 KB) which has significantly reduced and these pages will be
>     freed as-part of the init memory free-up.
>
>     The patch also provides a foundation for implementing strict kernel
>     mappings where we protect kernel text and rodata using PTE permissions.
>
>     Suggested-by: Mike Rapoport <rppt@linux.ibm.com>
>     Signed-off-by: Anup Patel <anup.patel@wdc.com>
>     [paul.walmsley@sifive.com: updated to apply; fixed a checkpatch warning]
>     Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
>
> I cherry-picked 922b0375fc93fb1a20c5617e37c389c26bbccb70 on top of a
> 5.3 kernel, and with that the kernel boots again with this patch set.

Thanks for looking into this. It's unfortunate that OpenSBI won't work
with older kernels, but people can always use their own OpenSBI build
in that case. 5.4 is an LTS and it works so that seems fine to me.

Alistair

>
> >
> > > If we can't support older kernels with the default bios option we at
> > > least need to know why and list that in the release notes.
> > >
>
> I will include the above findings in my commit message of this series,
> mentioning that to test an older kernel like 5.3 version Linux,
> 922b0375fc93fb1a20c5617e37c389c26bbccb70 should be cherry-picked.
>
> Regards,
> Bin