GNUBoot
/
coreboot-kgpe-d16
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
coreboot-kgpe-d16/src/arch/riscv/boot.c

51 lines
1.4 KiB
C
Raw Normal View History

Add UCB RISCV support for architecture, soc, and emulation mainboard.. Works in the RISCV version of QEMU. Note that the lzmadecode is so unclean that it needs a lot of work. A cleanup is in progress. We decided in Prague to do this as one thing, because it forms a nice case study of the bare minimum you need to add to get a new architecture going in qemu. Change-Id: If5af15c3a70733d219973e0d032746f8ab027e4d Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/7584 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins)
2014-11-26 20:25:47 +01:00
/*
* This file is part of the coreboot project.
*
* Copyright 2013 Google Inc.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; version 2 of the License.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*/
loaders: add program_loading.h header file Instead of two headers for payload and ramstage loading combine the 2 files into one. This also allows for easier refactoring by keeping header files consistent. Change-Id: I4a6dffb78ad84c78e6e96c886d361413f9b4a17d Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/8708 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-03-17 17:43:44 +01:00
#include <program_loading.h>
RISCV: modify arch_prog_run to handle payloads correctly. Unlike the other stages, the payload requires virtual memory to be set up and also a privelege level change. Change-Id: Ibbe2a55f7719d917f121a53a17c6d90e6b2ab3d1 Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/11699 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2015-09-23 00:53:32 +02:00
#include <vm.h>
arch/riscv: Pass the bootrom-provided FDT to the payload The RISC-V boot protocol foresees that at every stage boundary (bootrom to boot loader, boot loader -> OS), register a0 contains the Hart ID and a1 contains the physical address of the Flattened Device Tree that the stage shall use. As a first step, pass the bootrom-provided FDT to the payload, unmodified. Change-Id: I468bc64a47153d564087235f1c7e2d10e3d7a658 Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Reviewed-on: https://review.coreboot.org/23797 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2018-02-16 13:36:47 +01:00
#include <arch/boot.h>
RISCV: modify arch_prog_run to handle payloads correctly. Unlike the other stages, the payload requires virtual memory to be set up and also a privelege level change. Change-Id: Ibbe2a55f7719d917f121a53a17c6d90e6b2ab3d1 Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/11699 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2015-09-23 00:53:32 +02:00
#include <arch/encoding.h>
#include <rules.h>
RISCV: Clean up the common architectural code This version of coreboot successfully starts a Harvey (Plan 9) kernel as a payload, entering main() with no supporting assembly code for startup. The Harvey port is not complete so it just panics but ... it gets started. We provide a standard payload function that takes a pointer argument and makes the jump from machine to supervisor mode; the days of kernels running in machine mode are over. We do some small tweaks to the virtual memory code. We temporarily disable two functions that won't work on some targets as register numbers changed between 1.7 and 1.9. Once lowrisc catches up we'll reenable them. We add the PAGETABLES to the memlayout.ld and use _pagetables in the virtual memory setup code. We now use the _stack and _estack from memlayout so we know where things are. As time goes on maybe we can kill all the magic numbers. Change-Id: I6caadfa9627fa35e31580492be01d4af908d31d9 Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: https://review.coreboot.org/17058 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-10-19 17:07:13 +02:00
#include <console/console.h>
Add UCB RISCV support for architecture, soc, and emulation mainboard.. Works in the RISCV version of QEMU. Note that the lzmadecode is so unclean that it needs a lot of work. A cleanup is in progress. We decided in Prague to do this as one thing, because it forms a nice case study of the bare minimum you need to add to get a new architecture going in qemu. Change-Id: If5af15c3a70733d219973e0d032746f8ab027e4d Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/7584 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins)
2014-11-26 20:25:47 +01:00
arch/riscv: Pass the bootrom-provided FDT to the payload The RISC-V boot protocol foresees that at every stage boundary (bootrom to boot loader, boot loader -> OS), register a0 contains the Hart ID and a1 contains the physical address of the Flattened Device Tree that the stage shall use. As a first step, pass the bootrom-provided FDT to the payload, unmodified. Change-Id: I468bc64a47153d564087235f1c7e2d10e3d7a658 Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Reviewed-on: https://review.coreboot.org/23797 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2018-02-16 13:36:47 +01:00
/*
* A pointer to the Flattened Device Tree passed to coreboot by the boot ROM.
* Presumably this FDT is also in ROM.
*
* This pointer is only used in ramstage!
*/
const void *rom_fdt;
program loading: add prog_run() function The prog_run() function abstracts away what is required for running a given program. Within it, there are 2 calls: 1. platform_prog_run() and 2. arch_prog_run(). The platform_prog_run() allows for a chipset to intercept a program that will be run. This allows for CPU switching as currently needed in t124 and t132. Change-Id: I22a5dd5bfb1018e7e46475e47ac993a0941e2a8c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/8846 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-03-20 21:55:08 +01:00
void arch_prog_run(struct prog *prog)
Add UCB RISCV support for architecture, soc, and emulation mainboard.. Works in the RISCV version of QEMU. Note that the lzmadecode is so unclean that it needs a lot of work. A cleanup is in progress. We decided in Prague to do this as one thing, because it forms a nice case study of the bare minimum you need to add to get a new architecture going in qemu. Change-Id: If5af15c3a70733d219973e0d032746f8ab027e4d Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/7584 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins)
2014-11-26 20:25:47 +01:00
{
RISCV: modify arch_prog_run to handle payloads correctly. Unlike the other stages, the payload requires virtual memory to be set up and also a privelege level change. Change-Id: Ibbe2a55f7719d917f121a53a17c6d90e6b2ab3d1 Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/11699 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2015-09-23 00:53:32 +02:00
void (*doit)(void *) = prog_entry(prog);
arch/riscv: Pass the bootrom-provided FDT to the payload The RISC-V boot protocol foresees that at every stage boundary (bootrom to boot loader, boot loader -> OS), register a0 contains the Hart ID and a1 contains the physical address of the Flattened Device Tree that the stage shall use. As a first step, pass the bootrom-provided FDT to the payload, unmodified. Change-Id: I468bc64a47153d564087235f1c7e2d10e3d7a658 Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Reviewed-on: https://review.coreboot.org/23797 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2018-02-16 13:36:47 +01:00
void riscvpayload(const void *fdt, void *payload);
program loading: add prog_run() function The prog_run() function abstracts away what is required for running a given program. Within it, there are 2 calls: 1. platform_prog_run() and 2. arch_prog_run(). The platform_prog_run() allows for a chipset to intercept a program that will be run. This allows for CPU switching as currently needed in t124 and t132. Change-Id: I22a5dd5bfb1018e7e46475e47ac993a0941e2a8c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/8846 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-03-20 21:55:08 +01:00
lib: remove assets infrastructure Now that only CBFS access is supported for finding resources within the boot media the assets infrastructure can be removed. Remove it. BUG=chromium:445938 BRANCH=None TEST=Built and ran on glados. Change-Id: I383fd6579280cf9cfe5a18c2851baf74cad004e9 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/12690 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-12-08 21:34:35 +01:00
if (ENV_RAMSTAGE && prog_type(prog) == PROG_PAYLOAD) {
arch/riscv: Pass the bootrom-provided FDT to the payload The RISC-V boot protocol foresees that at every stage boundary (bootrom to boot loader, boot loader -> OS), register a0 contains the Hart ID and a1 contains the physical address of the Flattened Device Tree that the stage shall use. As a first step, pass the bootrom-provided FDT to the payload, unmodified. Change-Id: I468bc64a47153d564087235f1c7e2d10e3d7a658 Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Reviewed-on: https://review.coreboot.org/23797 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2018-02-16 13:36:47 +01:00
/*
* FIXME: This is wrong and will crash. Linux can't (in early
* boot) access memory that's before its own loading address.
* We need to copy the FDT to a place where Linux can access it.
*/
const void *fdt = rom_fdt;
printk(BIOS_SPEW, "FDT is at %p\n", fdt);
RISCV: Clean up the common architectural code This version of coreboot successfully starts a Harvey (Plan 9) kernel as a payload, entering main() with no supporting assembly code for startup. The Harvey port is not complete so it just panics but ... it gets started. We provide a standard payload function that takes a pointer argument and makes the jump from machine to supervisor mode; the days of kernels running in machine mode are over. We do some small tweaks to the virtual memory code. We temporarily disable two functions that won't work on some targets as register numbers changed between 1.7 and 1.9. Once lowrisc catches up we'll reenable them. We add the PAGETABLES to the memlayout.ld and use _pagetables in the virtual memory setup code. We now use the _stack and _estack from memlayout so we know where things are. As time goes on maybe we can kill all the magic numbers. Change-Id: I6caadfa9627fa35e31580492be01d4af908d31d9 Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: https://review.coreboot.org/17058 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-10-19 17:07:13 +02:00
printk(BIOS_SPEW, "OK, let's go\n");
arch/riscv: Pass the bootrom-provided FDT to the payload The RISC-V boot protocol foresees that at every stage boundary (bootrom to boot loader, boot loader -> OS), register a0 contains the Hart ID and a1 contains the physical address of the Flattened Device Tree that the stage shall use. As a first step, pass the bootrom-provided FDT to the payload, unmodified. Change-Id: I468bc64a47153d564087235f1c7e2d10e3d7a658 Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Reviewed-on: https://review.coreboot.org/23797 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2018-02-16 13:36:47 +01:00
riscvpayload(fdt, doit);
RISCV: modify arch_prog_run to handle payloads correctly. Unlike the other stages, the payload requires virtual memory to be set up and also a privelege level change. Change-Id: Ibbe2a55f7719d917f121a53a17c6d90e6b2ab3d1 Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/11699 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2015-09-23 00:53:32 +02:00
}
arch/riscv: Unconditionally start payloads in machine mode Ron Minnich writes: "we'll change cbfstool to put a header on the payload to jump to supervisor if that is desired. The principal here is that payloads are always started in machine mode, but we want to set the page tables up for them." Change-Id: I5cbfc90afd3febab33835935f08005136a3f47e9 Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Reviewed-on: https://review.coreboot.org/15510 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2016-07-07 20:53:29 +02:00
doit(prog_entry_arg(prog));
program loading: add prog_run() function The prog_run() function abstracts away what is required for running a given program. Within it, there are 2 calls: 1. platform_prog_run() and 2. arch_prog_run(). The platform_prog_run() allows for a chipset to intercept a program that will be run. This allows for CPU switching as currently needed in t124 and t132. Change-Id: I22a5dd5bfb1018e7e46475e47ac993a0941e2a8c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/8846 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-03-20 21:55:08 +01:00
}