All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v10 0/3]
@ 2023-02-02 13:52 Daniel Henrique Barboza
  2023-02-02 13:52 ` [PATCH v10 1/3] hw/riscv: handle 32 bit CPUs kernel_addr in riscv_load_kernel() Daniel Henrique Barboza
                   ` (2 more replies)
  0 siblings, 3 replies; 11+ messages in thread
From: Daniel Henrique Barboza @ 2023-02-02 13:52 UTC (permalink / raw)
  To: qemu-devel; +Cc: qemu-riscv, alistair.francis, Daniel Henrique Barboza

Hi,

This new version removed the translate_fn() from patch 1 because it
wasn't removing the sign-extension for pentry as we thought it would.
A more detailed explanation is given in the commit msg of patch 1.

We're now retrieving the 'lowaddr' value from load_elf_ram_sym() and
using it when we're running a 32-bit CPU. This worked with 32 bit
'virt' machine booting with the -kernel option.

If this approach doesn't work for the Xvisor use case, IMO  we should
just filter kernel_load_addr bits directly as we were doing a handful of
versions ago.

Patches are based on current riscv-to-apply.next. 

Changes from v9:
- patch 1:
  - removed the translate_fn() callback
  - return 'kernel_low' when running a 32-bit CPU
- v9 link: https://lists.gnu.org/archive/html/qemu-devel/2023-01/msg04509.html

Daniel Henrique Barboza (3):
  hw/riscv: handle 32 bit CPUs kernel_addr in riscv_load_kernel()
  hw/riscv/boot.c: consolidate all kernel init in riscv_load_kernel()
  hw/riscv/boot.c: make riscv_load_initrd() static

 hw/riscv/boot.c            | 96 +++++++++++++++++++++++---------------
 hw/riscv/microchip_pfsoc.c | 12 +----
 hw/riscv/opentitan.c       |  4 +-
 hw/riscv/sifive_e.c        |  4 +-
 hw/riscv/sifive_u.c        | 12 +----
 hw/riscv/spike.c           | 14 ++----
 hw/riscv/virt.c            | 12 +----
 include/hw/riscv/boot.h    |  3 +-
 8 files changed, 76 insertions(+), 81 deletions(-)

-- 
2.39.1



^ permalink raw reply	[flat|nested] 11+ messages in thread

* [PATCH v10 1/3] hw/riscv: handle 32 bit CPUs kernel_addr in riscv_load_kernel()
  2023-02-02 13:52 [PATCH v10 0/3] Daniel Henrique Barboza
@ 2023-02-02 13:52 ` Daniel Henrique Barboza
  2023-02-02 13:52 ` [PATCH v10 2/3] hw/riscv/boot.c: consolidate all kernel init " Daniel Henrique Barboza
  2023-02-02 13:52 ` [PATCH v10 3/3] hw/riscv/boot.c: make riscv_load_initrd() static Daniel Henrique Barboza
  2 siblings, 0 replies; 11+ messages in thread
From: Daniel Henrique Barboza @ 2023-02-02 13:52 UTC (permalink / raw)
  To: qemu-devel; +Cc: qemu-riscv, alistair.francis, Daniel Henrique Barboza

load_elf_ram_sym() will sign-extend 32 bit addresses. If a 32 bit QEMU
guest happens to be running in a hypervisor that are using 64 bits to
encode its address, kernel_entry can be padded with '1's and create
problems [1].

Using a translate_fn() callback in load_elf_ram_sym() to filter the
padding from the address doesn't work. A more detailed explanation can
be found in [2]. The short version is that glue(load_elf, SZ), from
include/hw/elf_ops.h, will calculate 'pentry' (mapped into the
'kernel_load_base' var in riscv_load_Kernel()) before using
translate_fn(), and will not recalculate it after executing it. This
means that the callback does not prevent the padding from
kernel_load_base to appear.

Let's instead use a kernel_low var to capture the 'lowaddr' value from
load_elf_ram_sim(), and return it when we're dealing with 32 bit CPUs.

[1] https://lists.gnu.org/archive/html/qemu-devel/2023-01/msg02281.html
[2] https://lists.gnu.org/archive/html/qemu-devel/2023-02/msg00099.html

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
---
 hw/riscv/boot.c            | 15 +++++++++++----
 hw/riscv/microchip_pfsoc.c |  3 ++-
 hw/riscv/opentitan.c       |  3 ++-
 hw/riscv/sifive_e.c        |  3 ++-
 hw/riscv/sifive_u.c        |  3 ++-
 hw/riscv/spike.c           |  3 ++-
 hw/riscv/virt.c            |  3 ++-
 include/hw/riscv/boot.h    |  1 +
 8 files changed, 24 insertions(+), 10 deletions(-)

diff --git a/hw/riscv/boot.c b/hw/riscv/boot.c
index c7e0e50bd8..5ec6d32165 100644
--- a/hw/riscv/boot.c
+++ b/hw/riscv/boot.c
@@ -174,11 +174,12 @@ target_ulong riscv_load_firmware(const char *firmware_filename,
 }
 
 target_ulong riscv_load_kernel(MachineState *machine,
+                               RISCVHartArrayState *harts,
                                target_ulong kernel_start_addr,
                                symbol_fn_t sym_cb)
 {
     const char *kernel_filename = machine->kernel_filename;
-    uint64_t kernel_load_base, kernel_entry;
+    uint64_t kernel_load_base, kernel_entry, kernel_low;
 
     g_assert(kernel_filename != NULL);
 
@@ -189,10 +190,16 @@ target_ulong riscv_load_kernel(MachineState *machine,
      * the (expected) load address load address. This allows kernels to have
      * separate SBI and ELF entry points (used by FreeBSD, for example).
      */
-    if (load_elf_ram_sym(kernel_filename, NULL, NULL, NULL,
-                         NULL, &kernel_load_base, NULL, NULL, 0,
+    if (load_elf_ram_sym(kernel_filename, NULL, NULL, NULL, NULL,
+                         &kernel_load_base, &kernel_low, NULL, 0,
                          EM_RISCV, 1, 0, NULL, true, sym_cb) > 0) {
-        return kernel_load_base;
+        kernel_entry = kernel_load_base;
+
+        if (riscv_is_32bit(harts)) {
+            kernel_entry = kernel_low;
+        }
+
+        return kernel_entry;
     }
 
     if (load_uimage_as(kernel_filename, &kernel_entry, NULL, NULL,
diff --git a/hw/riscv/microchip_pfsoc.c b/hw/riscv/microchip_pfsoc.c
index 2b91e49561..712625d2a4 100644
--- a/hw/riscv/microchip_pfsoc.c
+++ b/hw/riscv/microchip_pfsoc.c
@@ -629,7 +629,8 @@ static void microchip_icicle_kit_machine_init(MachineState *machine)
         kernel_start_addr = riscv_calc_kernel_start_addr(&s->soc.u_cpus,
                                                          firmware_end_addr);
 
-        kernel_entry = riscv_load_kernel(machine, kernel_start_addr, NULL);
+        kernel_entry = riscv_load_kernel(machine, &s->soc.u_cpus,
+                                         kernel_start_addr, NULL);
 
         if (machine->initrd_filename) {
             riscv_load_initrd(machine, kernel_entry);
diff --git a/hw/riscv/opentitan.c b/hw/riscv/opentitan.c
index 353f030d80..7fe4fb5628 100644
--- a/hw/riscv/opentitan.c
+++ b/hw/riscv/opentitan.c
@@ -101,7 +101,8 @@ static void opentitan_board_init(MachineState *machine)
     }
 
     if (machine->kernel_filename) {
-        riscv_load_kernel(machine, memmap[IBEX_DEV_RAM].base, NULL);
+        riscv_load_kernel(machine, &s->soc.cpus,
+                          memmap[IBEX_DEV_RAM].base, NULL);
     }
 }
 
diff --git a/hw/riscv/sifive_e.c b/hw/riscv/sifive_e.c
index 3e3f4b0088..1a7d381514 100644
--- a/hw/riscv/sifive_e.c
+++ b/hw/riscv/sifive_e.c
@@ -114,7 +114,8 @@ static void sifive_e_machine_init(MachineState *machine)
                           memmap[SIFIVE_E_DEV_MROM].base, &address_space_memory);
 
     if (machine->kernel_filename) {
-        riscv_load_kernel(machine, memmap[SIFIVE_E_DEV_DTIM].base, NULL);
+        riscv_load_kernel(machine, &s->soc.cpus,
+                          memmap[SIFIVE_E_DEV_DTIM].base, NULL);
     }
 }
 
diff --git a/hw/riscv/sifive_u.c b/hw/riscv/sifive_u.c
index d3ab7a9cda..71be442a50 100644
--- a/hw/riscv/sifive_u.c
+++ b/hw/riscv/sifive_u.c
@@ -598,7 +598,8 @@ static void sifive_u_machine_init(MachineState *machine)
         kernel_start_addr = riscv_calc_kernel_start_addr(&s->soc.u_cpus,
                                                          firmware_end_addr);
 
-        kernel_entry = riscv_load_kernel(machine, kernel_start_addr, NULL);
+        kernel_entry = riscv_load_kernel(machine, &s->soc.u_cpus,
+                                         kernel_start_addr, NULL);
 
         if (machine->initrd_filename) {
             riscv_load_initrd(machine, kernel_entry);
diff --git a/hw/riscv/spike.c b/hw/riscv/spike.c
index cc3f6dac17..1fa91167ab 100644
--- a/hw/riscv/spike.c
+++ b/hw/riscv/spike.c
@@ -305,7 +305,8 @@ static void spike_board_init(MachineState *machine)
         kernel_start_addr = riscv_calc_kernel_start_addr(&s->soc[0],
                                                          firmware_end_addr);
 
-        kernel_entry = riscv_load_kernel(machine, kernel_start_addr,
+        kernel_entry = riscv_load_kernel(machine, &s->soc[0],
+                                         kernel_start_addr,
                                          htif_symbol_callback);
 
         if (machine->initrd_filename) {
diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
index a061151a6f..d0531cc641 100644
--- a/hw/riscv/virt.c
+++ b/hw/riscv/virt.c
@@ -1277,7 +1277,8 @@ static void virt_machine_done(Notifier *notifier, void *data)
         kernel_start_addr = riscv_calc_kernel_start_addr(&s->soc[0],
                                                          firmware_end_addr);
 
-        kernel_entry = riscv_load_kernel(machine, kernel_start_addr, NULL);
+        kernel_entry = riscv_load_kernel(machine, &s->soc[0],
+                                         kernel_start_addr, NULL);
 
         if (machine->initrd_filename) {
             riscv_load_initrd(machine, kernel_entry);
diff --git a/include/hw/riscv/boot.h b/include/hw/riscv/boot.h
index 511390f60e..6295316afb 100644
--- a/include/hw/riscv/boot.h
+++ b/include/hw/riscv/boot.h
@@ -44,6 +44,7 @@ target_ulong riscv_load_firmware(const char *firmware_filename,
                                  hwaddr firmware_load_addr,
                                  symbol_fn_t sym_cb);
 target_ulong riscv_load_kernel(MachineState *machine,
+                               RISCVHartArrayState *harts,
                                target_ulong firmware_end_addr,
                                symbol_fn_t sym_cb);
 void riscv_load_initrd(MachineState *machine, uint64_t kernel_entry);
-- 
2.39.1



^ permalink raw reply related	[flat|nested] 11+ messages in thread

* [PATCH v10 2/3] hw/riscv/boot.c: consolidate all kernel init in riscv_load_kernel()
  2023-02-02 13:52 [PATCH v10 0/3] Daniel Henrique Barboza
  2023-02-02 13:52 ` [PATCH v10 1/3] hw/riscv: handle 32 bit CPUs kernel_addr in riscv_load_kernel() Daniel Henrique Barboza
@ 2023-02-02 13:52 ` Daniel Henrique Barboza
  2023-02-02 13:52 ` [PATCH v10 3/3] hw/riscv/boot.c: make riscv_load_initrd() static Daniel Henrique Barboza
  2 siblings, 0 replies; 11+ messages in thread
From: Daniel Henrique Barboza @ 2023-02-02 13:52 UTC (permalink / raw)
  To: qemu-devel
  Cc: qemu-riscv, alistair.francis, Daniel Henrique Barboza,
	Palmer Dabbelt, Bin Meng

The microchip_icicle_kit, sifive_u, spike and virt boards are now doing
the same steps when '-kernel' is used:

- execute load_kernel()
- load init_rd()
- write kernel_cmdline

Let's fold everything inside riscv_load_kernel() to avoid code
repetition. To not change the behavior of boards that aren't calling
riscv_load_init(), add an 'load_initrd' flag to riscv_load_kernel() and
allow these boards to opt out from initrd loading.

Cc: Palmer Dabbelt <palmer@dabbelt.com>
Reviewed-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
---
 hw/riscv/boot.c            | 21 ++++++++++++++++++---
 hw/riscv/microchip_pfsoc.c | 11 +----------
 hw/riscv/opentitan.c       |  3 ++-
 hw/riscv/sifive_e.c        |  3 ++-
 hw/riscv/sifive_u.c        | 11 +----------
 hw/riscv/spike.c           | 11 +----------
 hw/riscv/virt.c            | 11 +----------
 include/hw/riscv/boot.h    |  1 +
 8 files changed, 27 insertions(+), 45 deletions(-)

diff --git a/hw/riscv/boot.c b/hw/riscv/boot.c
index 5ec6d32165..1e32ce1e10 100644
--- a/hw/riscv/boot.c
+++ b/hw/riscv/boot.c
@@ -176,10 +176,12 @@ target_ulong riscv_load_firmware(const char *firmware_filename,
 target_ulong riscv_load_kernel(MachineState *machine,
                                RISCVHartArrayState *harts,
                                target_ulong kernel_start_addr,
+                               bool load_initrd,
                                symbol_fn_t sym_cb)
 {
     const char *kernel_filename = machine->kernel_filename;
     uint64_t kernel_load_base, kernel_entry, kernel_low;
+    void *fdt = machine->fdt;
 
     g_assert(kernel_filename != NULL);
 
@@ -199,21 +201,34 @@ target_ulong riscv_load_kernel(MachineState *machine,
             kernel_entry = kernel_low;
         }
 
-        return kernel_entry;
+        goto out;
     }
 
     if (load_uimage_as(kernel_filename, &kernel_entry, NULL, NULL,
                        NULL, NULL, NULL) > 0) {
-        return kernel_entry;
+        goto out;
     }
 
     if (load_image_targphys_as(kernel_filename, kernel_start_addr,
                                current_machine->ram_size, NULL) > 0) {
-        return kernel_start_addr;
+        kernel_entry = kernel_start_addr;
+        goto out;
     }
 
     error_report("could not load kernel '%s'", kernel_filename);
     exit(1);
+
+out:
+    if (load_initrd && machine->initrd_filename) {
+        riscv_load_initrd(machine, kernel_entry);
+    }
+
+    if (fdt && machine->kernel_cmdline && *machine->kernel_cmdline) {
+        qemu_fdt_setprop_string(fdt, "/chosen", "bootargs",
+                                machine->kernel_cmdline);
+    }
+
+    return kernel_entry;
 }
 
 void riscv_load_initrd(MachineState *machine, uint64_t kernel_entry)
diff --git a/hw/riscv/microchip_pfsoc.c b/hw/riscv/microchip_pfsoc.c
index 712625d2a4..e81bbd12df 100644
--- a/hw/riscv/microchip_pfsoc.c
+++ b/hw/riscv/microchip_pfsoc.c
@@ -630,16 +630,7 @@ static void microchip_icicle_kit_machine_init(MachineState *machine)
                                                          firmware_end_addr);
 
         kernel_entry = riscv_load_kernel(machine, &s->soc.u_cpus,
-                                         kernel_start_addr, NULL);
-
-        if (machine->initrd_filename) {
-            riscv_load_initrd(machine, kernel_entry);
-        }
-
-        if (machine->kernel_cmdline && *machine->kernel_cmdline) {
-            qemu_fdt_setprop_string(machine->fdt, "/chosen",
-                                    "bootargs", machine->kernel_cmdline);
-        }
+                                         kernel_start_addr, true, NULL);
 
         /* Compute the fdt load address in dram */
         fdt_load_addr = riscv_compute_fdt_addr(memmap[MICROCHIP_PFSOC_DRAM_LO].base,
diff --git a/hw/riscv/opentitan.c b/hw/riscv/opentitan.c
index 7fe4fb5628..b06944d382 100644
--- a/hw/riscv/opentitan.c
+++ b/hw/riscv/opentitan.c
@@ -102,7 +102,8 @@ static void opentitan_board_init(MachineState *machine)
 
     if (machine->kernel_filename) {
         riscv_load_kernel(machine, &s->soc.cpus,
-                          memmap[IBEX_DEV_RAM].base, NULL);
+                          memmap[IBEX_DEV_RAM].base,
+                          false, NULL);
     }
 }
 
diff --git a/hw/riscv/sifive_e.c b/hw/riscv/sifive_e.c
index 1a7d381514..04939b60c3 100644
--- a/hw/riscv/sifive_e.c
+++ b/hw/riscv/sifive_e.c
@@ -115,7 +115,8 @@ static void sifive_e_machine_init(MachineState *machine)
 
     if (machine->kernel_filename) {
         riscv_load_kernel(machine, &s->soc.cpus,
-                          memmap[SIFIVE_E_DEV_DTIM].base, NULL);
+                          memmap[SIFIVE_E_DEV_DTIM].base,
+                          false, NULL);
     }
 }
 
diff --git a/hw/riscv/sifive_u.c b/hw/riscv/sifive_u.c
index 71be442a50..ad3bb35b34 100644
--- a/hw/riscv/sifive_u.c
+++ b/hw/riscv/sifive_u.c
@@ -599,16 +599,7 @@ static void sifive_u_machine_init(MachineState *machine)
                                                          firmware_end_addr);
 
         kernel_entry = riscv_load_kernel(machine, &s->soc.u_cpus,
-                                         kernel_start_addr, NULL);
-
-        if (machine->initrd_filename) {
-            riscv_load_initrd(machine, kernel_entry);
-        }
-
-        if (machine->kernel_cmdline && *machine->kernel_cmdline) {
-            qemu_fdt_setprop_string(machine->fdt, "/chosen", "bootargs",
-                                    machine->kernel_cmdline);
-        }
+                                         kernel_start_addr, true, NULL);
     } else {
        /*
         * If dynamic firmware is used, it doesn't know where is the next mode
diff --git a/hw/riscv/spike.c b/hw/riscv/spike.c
index 1fa91167ab..a584d5b3a2 100644
--- a/hw/riscv/spike.c
+++ b/hw/riscv/spike.c
@@ -307,16 +307,7 @@ static void spike_board_init(MachineState *machine)
 
         kernel_entry = riscv_load_kernel(machine, &s->soc[0],
                                          kernel_start_addr,
-                                         htif_symbol_callback);
-
-        if (machine->initrd_filename) {
-            riscv_load_initrd(machine, kernel_entry);
-        }
-
-        if (machine->kernel_cmdline && *machine->kernel_cmdline) {
-            qemu_fdt_setprop_string(machine->fdt, "/chosen", "bootargs",
-                                    machine->kernel_cmdline);
-        }
+                                         true, htif_symbol_callback);
     } else {
        /*
         * If dynamic firmware is used, it doesn't know where is the next mode
diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
index d0531cc641..2f2c82e8df 100644
--- a/hw/riscv/virt.c
+++ b/hw/riscv/virt.c
@@ -1278,16 +1278,7 @@ static void virt_machine_done(Notifier *notifier, void *data)
                                                          firmware_end_addr);
 
         kernel_entry = riscv_load_kernel(machine, &s->soc[0],
-                                         kernel_start_addr, NULL);
-
-        if (machine->initrd_filename) {
-            riscv_load_initrd(machine, kernel_entry);
-        }
-
-        if (machine->kernel_cmdline && *machine->kernel_cmdline) {
-            qemu_fdt_setprop_string(machine->fdt, "/chosen", "bootargs",
-                                    machine->kernel_cmdline);
-        }
+                                         kernel_start_addr, true, NULL);
     } else {
        /*
         * If dynamic firmware is used, it doesn't know where is the next mode
diff --git a/include/hw/riscv/boot.h b/include/hw/riscv/boot.h
index 6295316afb..ea1de8b020 100644
--- a/include/hw/riscv/boot.h
+++ b/include/hw/riscv/boot.h
@@ -46,6 +46,7 @@ target_ulong riscv_load_firmware(const char *firmware_filename,
 target_ulong riscv_load_kernel(MachineState *machine,
                                RISCVHartArrayState *harts,
                                target_ulong firmware_end_addr,
+                               bool load_initrd,
                                symbol_fn_t sym_cb);
 void riscv_load_initrd(MachineState *machine, uint64_t kernel_entry);
 uint64_t riscv_compute_fdt_addr(hwaddr dram_start, uint64_t dram_size,
-- 
2.39.1



^ permalink raw reply related	[flat|nested] 11+ messages in thread

* [PATCH v10 3/3] hw/riscv/boot.c: make riscv_load_initrd() static
  2023-02-02 13:52 [PATCH v10 0/3] Daniel Henrique Barboza
  2023-02-02 13:52 ` [PATCH v10 1/3] hw/riscv: handle 32 bit CPUs kernel_addr in riscv_load_kernel() Daniel Henrique Barboza
  2023-02-02 13:52 ` [PATCH v10 2/3] hw/riscv/boot.c: consolidate all kernel init " Daniel Henrique Barboza
@ 2023-02-02 13:52 ` Daniel Henrique Barboza
  2 siblings, 0 replies; 11+ messages in thread
From: Daniel Henrique Barboza @ 2023-02-02 13:52 UTC (permalink / raw)
  To: qemu-devel
  Cc: qemu-riscv, alistair.francis, Daniel Henrique Barboza,
	Philippe Mathieu-Daudé,
	Bin Meng

The only remaining caller is riscv_load_kernel_and_initrd() which
belongs to the same file.

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
---
 hw/riscv/boot.c         | 80 ++++++++++++++++++++---------------------
 include/hw/riscv/boot.h |  1 -
 2 files changed, 40 insertions(+), 41 deletions(-)

diff --git a/hw/riscv/boot.c b/hw/riscv/boot.c
index 1e32ce1e10..72885e4a6f 100644
--- a/hw/riscv/boot.c
+++ b/hw/riscv/boot.c
@@ -173,6 +173,46 @@ target_ulong riscv_load_firmware(const char *firmware_filename,
     exit(1);
 }
 
+static void riscv_load_initrd(MachineState *machine, uint64_t kernel_entry)
+{
+    const char *filename = machine->initrd_filename;
+    uint64_t mem_size = machine->ram_size;
+    void *fdt = machine->fdt;
+    hwaddr start, end;
+    ssize_t size;
+
+    g_assert(filename != NULL);
+
+    /*
+     * We want to put the initrd far enough into RAM that when the
+     * kernel is uncompressed it will not clobber the initrd. However
+     * on boards without much RAM we must ensure that we still leave
+     * enough room for a decent sized initrd, and on boards with large
+     * amounts of RAM we must avoid the initrd being so far up in RAM
+     * that it is outside lowmem and inaccessible to the kernel.
+     * So for boards with less  than 256MB of RAM we put the initrd
+     * halfway into RAM, and for boards with 256MB of RAM or more we put
+     * the initrd at 128MB.
+     */
+    start = kernel_entry + MIN(mem_size / 2, 128 * MiB);
+
+    size = load_ramdisk(filename, start, mem_size - start);
+    if (size == -1) {
+        size = load_image_targphys(filename, start, mem_size - start);
+        if (size == -1) {
+            error_report("could not load ramdisk '%s'", filename);
+            exit(1);
+        }
+    }
+
+    /* Some RISC-V machines (e.g. opentitan) don't have a fdt. */
+    if (fdt) {
+        end = start + size;
+        qemu_fdt_setprop_cell(fdt, "/chosen", "linux,initrd-start", start);
+        qemu_fdt_setprop_cell(fdt, "/chosen", "linux,initrd-end", end);
+    }
+}
+
 target_ulong riscv_load_kernel(MachineState *machine,
                                RISCVHartArrayState *harts,
                                target_ulong kernel_start_addr,
@@ -231,46 +271,6 @@ out:
     return kernel_entry;
 }
 
-void riscv_load_initrd(MachineState *machine, uint64_t kernel_entry)
-{
-    const char *filename = machine->initrd_filename;
-    uint64_t mem_size = machine->ram_size;
-    void *fdt = machine->fdt;
-    hwaddr start, end;
-    ssize_t size;
-
-    g_assert(filename != NULL);
-
-    /*
-     * We want to put the initrd far enough into RAM that when the
-     * kernel is uncompressed it will not clobber the initrd. However
-     * on boards without much RAM we must ensure that we still leave
-     * enough room for a decent sized initrd, and on boards with large
-     * amounts of RAM we must avoid the initrd being so far up in RAM
-     * that it is outside lowmem and inaccessible to the kernel.
-     * So for boards with less  than 256MB of RAM we put the initrd
-     * halfway into RAM, and for boards with 256MB of RAM or more we put
-     * the initrd at 128MB.
-     */
-    start = kernel_entry + MIN(mem_size / 2, 128 * MiB);
-
-    size = load_ramdisk(filename, start, mem_size - start);
-    if (size == -1) {
-        size = load_image_targphys(filename, start, mem_size - start);
-        if (size == -1) {
-            error_report("could not load ramdisk '%s'", filename);
-            exit(1);
-        }
-    }
-
-    /* Some RISC-V machines (e.g. opentitan) don't have a fdt. */
-    if (fdt) {
-        end = start + size;
-        qemu_fdt_setprop_cell(fdt, "/chosen", "linux,initrd-start", start);
-        qemu_fdt_setprop_cell(fdt, "/chosen", "linux,initrd-end", end);
-    }
-}
-
 /*
  * This function makes an assumption that the DRAM interval
  * 'dram_base' + 'dram_size' is contiguous.
diff --git a/include/hw/riscv/boot.h b/include/hw/riscv/boot.h
index ea1de8b020..a2e4ae9cb0 100644
--- a/include/hw/riscv/boot.h
+++ b/include/hw/riscv/boot.h
@@ -48,7 +48,6 @@ target_ulong riscv_load_kernel(MachineState *machine,
                                target_ulong firmware_end_addr,
                                bool load_initrd,
                                symbol_fn_t sym_cb);
-void riscv_load_initrd(MachineState *machine, uint64_t kernel_entry);
 uint64_t riscv_compute_fdt_addr(hwaddr dram_start, uint64_t dram_size,
                                 MachineState *ms);
 void riscv_load_fdt(hwaddr fdt_addr, void *fdt);
-- 
2.39.1



^ permalink raw reply related	[flat|nested] 11+ messages in thread

* Re: [PATCH v10 0/3]
       [not found]     ` <CAC05385Mc7pqiCd5mb+1c4WM+v7K=h=GMHuvkw9xizhRFJXXBA@mail.gmail.com>
@ 2019-04-30 21:46       ` Johannes Schindelin
  0 siblings, 0 replies; 11+ messages in thread
From: Johannes Schindelin @ 2019-04-30 21:46 UTC (permalink / raw)
  To: Nickolai Belakovski; +Cc: Git List, SZEDER Gábor

Hi Nickolai,

On Mon, 29 Apr 2019, Nickolai Belakovski wrote:

> Sorry, I'm not very accustomed to mailing list development. I had assumed
> that this was being threaded with the other messages in the series, hence
> leaving the subject blank and only putting new info in the body.

The openness of a mailing list-centric development is that everybody with
an email address can participate [*1*].

The downside is that *anybody* with *any* mail program can be a reader, so
you cannot assume *anything* about how people will read your mails. Some
will read it in a mail program that color-codes levels of quotation.
Others will not have any color whatsoever. Some thread. Some don't. In
most mail programs, you cannot even search for a Message-ID. Which can be
non-unique.

So the perceived benefits of this way to run a project come at a price.

> In the future I'll add in an appropriate subject and brief re-hash in the
> body. Thanks for bringing it up.

Thank you,
Johannes

Footnote *1*: Of course, it is not *all* that open. If you cannot convince
your mail program to send mails in plain text only, and to stop
reformatting mails e.g. to make them look better on cell phones (refusing
this is the price of requiring patches to be sent in whitespace-preserving
plain text emails), then you're not invited to the party. This is why I
sometimes say, not altogether without reason, that you can use *any*
mail program to participate in the Git project as long as it is `mutt`.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH v10 0/3]
  2019-04-29 20:57   ` Johannes Schindelin
@ 2019-04-29 21:33     ` Nickolai Belakovski
       [not found]     ` <CAC05385Mc7pqiCd5mb+1c4WM+v7K=h=GMHuvkw9xizhRFJXXBA@mail.gmail.com>
  1 sibling, 0 replies; 11+ messages in thread
From: Nickolai Belakovski @ 2019-04-29 21:33 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Git List, SZEDER Gábor

Sorry, I'm not very accustomed to mailing list development. I had
assumed that this was being threaded with the other messages in the
series, hence leaving the subject blank and only putting new info in
the body.

In the future I'll add in an appropriate subject and brief re-hash in
the body. Thanks for bringing it up.

Nickolai

On Mon, Apr 29, 2019 at 1:57 PM Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>
> Hi,
>
> am I the only person who is puzzled every time this patch series with a
> completely empty subject and without any further explanation about the
> intent in the mail body is sent?
>
> Ciao,
> Johannes
>
>
> On Sun, 28 Apr 2019, nbelakovski@gmail.com wrote:
>
> > From: Nickolai Belakovski <nbelakovski@gmail.com>
> >
> > Added test_i18ncmp per instructions from Szeder
> >
> > Is there some other part of the infrastructure that's testing for this? Because it did not fail in any of my Travis CI builds.
> >
> > Travis CI results: https://travis-ci.org/nbelakovski/git/builds/525801210
> >
> > Nickolai Belakovski (3):
> >   ref-filter: add worktreepath atom
> >   branch: update output to include worktree info
> >   branch: add worktree info on verbose output
> >
> >  Documentation/git-branch.txt       | 12 ++++--
> >  Documentation/git-for-each-ref.txt |  5 +++
> >  builtin/branch.c                   | 16 ++++++--
> >  ref-filter.c                       | 78 ++++++++++++++++++++++++++++++++++++++
> >  t/t3200-branch.sh                  | 16 +++++---
> >  t/t3203-branch-output.sh           | 43 ++++++++++++++++++++-
> >  t/t6302-for-each-ref-filter.sh     | 13 +++++++
> >  7 files changed, 168 insertions(+), 15 deletions(-)
> >
> > --
> > 2.14.2
> >
> >

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH v10 0/3]
  2019-04-29  5:19 ` [PATCH v10 0/3] nbelakovski
  2019-04-29 14:12   ` SZEDER Gábor
@ 2019-04-29 20:57   ` Johannes Schindelin
  2019-04-29 21:33     ` Nickolai Belakovski
       [not found]     ` <CAC05385Mc7pqiCd5mb+1c4WM+v7K=h=GMHuvkw9xizhRFJXXBA@mail.gmail.com>
  1 sibling, 2 replies; 11+ messages in thread
From: Johannes Schindelin @ 2019-04-29 20:57 UTC (permalink / raw)
  To: Nickolai Belakovski; +Cc: git, szeder.dev

Hi,

am I the only person who is puzzled every time this patch series with a
completely empty subject and without any further explanation about the
intent in the mail body is sent?

Ciao,
Johannes


On Sun, 28 Apr 2019, nbelakovski@gmail.com wrote:

> From: Nickolai Belakovski <nbelakovski@gmail.com>
>
> Added test_i18ncmp per instructions from Szeder
>
> Is there some other part of the infrastructure that's testing for this? Because it did not fail in any of my Travis CI builds.
>
> Travis CI results: https://travis-ci.org/nbelakovski/git/builds/525801210
>
> Nickolai Belakovski (3):
>   ref-filter: add worktreepath atom
>   branch: update output to include worktree info
>   branch: add worktree info on verbose output
>
>  Documentation/git-branch.txt       | 12 ++++--
>  Documentation/git-for-each-ref.txt |  5 +++
>  builtin/branch.c                   | 16 ++++++--
>  ref-filter.c                       | 78 ++++++++++++++++++++++++++++++++++++++
>  t/t3200-branch.sh                  | 16 +++++---
>  t/t3203-branch-output.sh           | 43 ++++++++++++++++++++-
>  t/t6302-for-each-ref-filter.sh     | 13 +++++++
>  7 files changed, 168 insertions(+), 15 deletions(-)
>
> --
> 2.14.2
>
>

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH v10 0/3]
  2019-04-29 14:12   ` SZEDER Gábor
@ 2019-04-29 19:27     ` Nickolai Belakovski
  0 siblings, 0 replies; 11+ messages in thread
From: Nickolai Belakovski @ 2019-04-29 19:27 UTC (permalink / raw)
  To: SZEDER Gábor; +Cc: Git List

> Testing with GETTEXT_POISON was broken since 6cdccfce (i18n: make
> GETTEXT_POISON a runtime option, 2018-11-08), and didn't catch any of
> these issues.  See:
>
>   https://public-inbox.org/git/xmqqlg0bvppc.fsf_-_@gitster-ct.c.googlers.com/T/#u
>
> The fix f88b9cb603 (gettext tests: export the restored
> GIT_TEST_GETTEXT_POISON, 2019-04-15) was merged to master just last
> week.
>

Ah I see, thanks for the info.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH v10 0/3]
  2019-04-29  5:19 ` [PATCH v10 0/3] nbelakovski
@ 2019-04-29 14:12   ` SZEDER Gábor
  2019-04-29 19:27     ` Nickolai Belakovski
  2019-04-29 20:57   ` Johannes Schindelin
  1 sibling, 1 reply; 11+ messages in thread
From: SZEDER Gábor @ 2019-04-29 14:12 UTC (permalink / raw)
  To: nbelakovski; +Cc: git

On Sun, Apr 28, 2019 at 10:19:41PM -0700, nbelakovski@gmail.com wrote:
> From: Nickolai Belakovski <nbelakovski@gmail.com>
> 
> Added test_i18ncmp per instructions from Szeder
> 
> Is there some other part of the infrastructure that's testing for this? Because it did not fail in any of my Travis CI builds.
> 
> Travis CI results: https://travis-ci.org/nbelakovski/git/builds/525801210

Testing with GETTEXT_POISON was broken since 6cdccfce (i18n: make
GETTEXT_POISON a runtime option, 2018-11-08), and didn't catch any of
these issues.  See:

  https://public-inbox.org/git/xmqqlg0bvppc.fsf_-_@gitster-ct.c.googlers.com/T/#u

The fix f88b9cb603 (gettext tests: export the restored
GIT_TEST_GETTEXT_POISON, 2019-04-15) was merged to master just last
week.


^ permalink raw reply	[flat|nested] 11+ messages in thread

* [PATCH v10 0/3]
  2018-09-27 15:13 [PATCH] branch: colorize branches checked out in a linked working tree the same way as the current branch is colorized Nickolai Belakovski
@ 2019-04-29  5:19 ` nbelakovski
  2019-04-29 14:12   ` SZEDER Gábor
  2019-04-29 20:57   ` Johannes Schindelin
  0 siblings, 2 replies; 11+ messages in thread
From: nbelakovski @ 2019-04-29  5:19 UTC (permalink / raw)
  To: git; +Cc: szeder.dev, Nickolai Belakovski

From: Nickolai Belakovski <nbelakovski@gmail.com>

Added test_i18ncmp per instructions from Szeder

Is there some other part of the infrastructure that's testing for this? Because it did not fail in any of my Travis CI builds.

Travis CI results: https://travis-ci.org/nbelakovski/git/builds/525801210

Nickolai Belakovski (3):
  ref-filter: add worktreepath atom
  branch: update output to include worktree info
  branch: add worktree info on verbose output

 Documentation/git-branch.txt       | 12 ++++--
 Documentation/git-for-each-ref.txt |  5 +++
 builtin/branch.c                   | 16 ++++++--
 ref-filter.c                       | 78 ++++++++++++++++++++++++++++++++++++++
 t/t3200-branch.sh                  | 16 +++++---
 t/t3203-branch-output.sh           | 43 ++++++++++++++++++++-
 t/t6302-for-each-ref-filter.sh     | 13 +++++++
 7 files changed, 168 insertions(+), 15 deletions(-)

-- 
2.14.2


^ permalink raw reply	[flat|nested] 11+ messages in thread

* [PATCH v10 0/3]
@ 2015-05-14 20:17 David Turner
  0 siblings, 0 replies; 11+ messages in thread
From: David Turner @ 2015-05-14 20:17 UTC (permalink / raw)
  To: git

Change text explaining that --follow-symlinks only works with
--batch{-check,}; now it is presented as a missing feature rather than
a necessary evil.

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2023-02-02 13:54 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-02-02 13:52 [PATCH v10 0/3] Daniel Henrique Barboza
2023-02-02 13:52 ` [PATCH v10 1/3] hw/riscv: handle 32 bit CPUs kernel_addr in riscv_load_kernel() Daniel Henrique Barboza
2023-02-02 13:52 ` [PATCH v10 2/3] hw/riscv/boot.c: consolidate all kernel init " Daniel Henrique Barboza
2023-02-02 13:52 ` [PATCH v10 3/3] hw/riscv/boot.c: make riscv_load_initrd() static Daniel Henrique Barboza
  -- strict thread matches above, loose matches on Subject: below --
2018-09-27 15:13 [PATCH] branch: colorize branches checked out in a linked working tree the same way as the current branch is colorized Nickolai Belakovski
2019-04-29  5:19 ` [PATCH v10 0/3] nbelakovski
2019-04-29 14:12   ` SZEDER Gábor
2019-04-29 19:27     ` Nickolai Belakovski
2019-04-29 20:57   ` Johannes Schindelin
2019-04-29 21:33     ` Nickolai Belakovski
     [not found]     ` <CAC05385Mc7pqiCd5mb+1c4WM+v7K=h=GMHuvkw9xizhRFJXXBA@mail.gmail.com>
2019-04-30 21:46       ` Johannes Schindelin
2015-05-14 20:17 David Turner

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.