On Tue, Jul 10, 2018 at 9:52 AM, Alistair Francis <alistai...@gmail.com> wrote:
> On Mon, Jul 9, 2018 at 3:00 AM, Andreas Schwab <sch...@suse.de> wrote: > > What is the state of the sifive_u emulation? When I tried to boot a bbl > > with an included kernel I get these errors: > > > > qemu-system-riscv64: plic: invalid register write: 00002090 > > qemu-system-riscv64: plic: invalid register write: 00002094 > > qemu-system-riscv64: plic: invalid register write: 00002098 > > qemu-system-riscv64: plic: invalid register write: 0000209c > > qemu-system-riscv64: plic: invalid register write: 000020a0 > > qemu-system-riscv64: plic: invalid register write: 000020a4 > > qemu-system-riscv64: plic: invalid register write: 000020a8 > > qemu-system-riscv64: plic: invalid register write: 000020ac > > qemu-system-riscv64: plic: invalid register write: 000020b0 > > qemu-system-riscv64: plic: invalid register write: 000020b4 > > I see those as well. I haven't investigated but I assume we are just > not completely modelling the PLIC. In saying that it should still > boot. Do you not see the kernel booting? It could be a PLIC bug or it could be a Linux interrupt controller driver bug. We can see from the memory map docs for the U54 whether these memory addresses are in bounds based on the number of configured interrupt sources. I'm not sure how many sources we have configured on sifive_u. Last time I booted Linux on sifive_u I did not see these errors. I'd need your kernel config and to know what tree and branch you are building from. I will be able to look when I get time... The PLIC however seems stable in the 'virt' board at least... Sorry I've been incommunicado for several weeks. I have been working on a CLIC model (Core Local Interrupt Controller) which replaces the CLINT and has a CLINT backwards compatibility mode. It is a Core Local vs the PLIC which is the Platform Level router. Here is the "draft" spec. It will be a candidate proposed to the RISC-V Fast Interrupts working group for potential standardisation, however in any case it will be available from SiFive so we may eventuall want to include our implementation in QEMU: - https://github.com/sifive/clic-spec/blob/master/clic.adoc When i'm done with modelling the first iteration of the CLIC I'll go through my pending patch queue and make a PR for the Reviewed patches. I'll also do some testing on master to make sure we have not regressed anything in RISC-V QEMU given QEMU 2.12 and the riscv-qemu trees are both stable. BTW - with respect to 'sifive_e' and 'sifive_u' SOC changes, we'll have to see how the model matches SiFive's plans for these virtual machines. We want to avoid a proliferation of boards, and as I've mentioned before we want to be able to model the HiFive1, HiFiveU and other SiFive E Series and U Series Coreplex configurations. There are many permutations from SiFive's SOC generator so our goal is to avoid hardcoding all of the different SOC combinations (hence the removal of model numbers in my initial review of your patches). How we achieve this I do not know. We obviously want to invest our time in something that is acceptable to upstream, while also meeting the goal of modelling SiFive's many hardware configurations, given these boards also model softcore IP such as the e31 arty and u54 on Xilinx VC707. i.e. they are SiFive models. I'm not too concerned with the SOC changes assuming we don't regress any function, as we can always evolve the code in the future to match configurations from SiFive's SOC generator. At present the models are like a union of a subset of the real hardware as we are still missing many emulation models for various parts of the SOCs. After i've finished up this CLIC work, I'll go back through the list of things we still need to model. Adding the Cadence GEM to the SiFive U Series is really nice, and so is adding Xilinx PCI to the SiFive U and GPEX to virt (as discussed, given virt is generic, we want to use GPEX there). Thanks, Michael. > > > Andreas. > > > > -- > > Andreas Schwab, SUSE Labs, sch...@suse.de > > GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 > > "And now for something completely different." >
