[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH for-8.2 6/7] target/riscv: add 'max' CPU type
From: |
Conor Dooley |
Subject: |
Re: [PATCH for-8.2 6/7] target/riscv: add 'max' CPU type |
Date: |
Wed, 12 Jul 2023 23:14:21 +0100 |
On Wed, Jul 12, 2023 at 06:39:28PM -0300, Daniel Henrique Barboza wrote:
> On 7/12/23 18:35, Conor Dooley wrote:
> > On Wed, Jul 12, 2023 at 06:09:10PM -0300, Daniel Henrique Barboza wrote:
> >
> > > It is intentional. Those default marchid/mimpid vals were derived from
> > > the current
> > > QEMU version ID/build and didn't mean much.
> > >
> > > It is still possible to set them via "-cpu rv64,marchid=N,mimpid=N" if
> > > needed when
> > > using the generic (rv64,rv32) CPUs. Vendor CPUs can't have their machine
> > > IDs changed
> > > via command line.
> >
> > Sounds good, thanks. I did just now go and check icicle to see what it
> > would report & it does not boot. I'll go bisect...
>
> BTW how are you booting the icicle board nowadays? I remember you mentioning
> about
> some changes in the FDT being required to boot and whatnot.
I do direct kernel boots, as the HSS doesn't work anymore, and just lie
a bit to QEMU about how much DDR we have.
.PHONY: qemu-icicle
qemu-icicle:
$(qemu) -M microchip-icicle-kit \
-m 3G -smp 5 \
-kernel $(vmlinux_bin) \
-dtb $(icicle_dtb) \
-initrd $(initramfs) \
-display none -serial null \
-serial stdio \
-D qemu.log -d unimp
The platform only supports 2 GiB of DDR, not 3, but if I pass 2 to QEMU
it thinks there's 1 GiB at 0x8000_0000 and 1 GiB at 0x10_0000_0000. The
upstream devicetree (and current FPGA reference design) expects there to
be 1 GiB at 0x8000_0000 and 1 GiB at 0x10_4000_0000. If I lie to QEMU,
it thinks there is 1 GiB at 0x8000_0000 and 2 GiB at 0x10_0000_0000, and
things just work. I prefer doing it this way than having to modify the
DT, it is a lot easier to explain to people this way.
I've been meaning to work the support for the icicle & mpfs in QEMU, but
it just gets shunted down the priority list. I'd really like if a proper
boot flow would run in QEMU, which means fixing whatever broke the HSS,
but I've recently picked up maintainership of dt-binding stuff in Linux,
so I've unfortunately got even less time to try and work on it. Maybe
we'll get some new graduate in and I can make them suffer in my stead...
> If it's not too hard I'll add it in my test scripts to keep it under check.
> Perhaps
> we can even add it to QEMU testsuite.
I don't think it really should be that bad, at least for the direct
kernel boot, which is what I mainly care about, since I use it fairly
often for debugging boot stuff in Linux.
Anyways, aa903cf31391dd505b399627158f1292a6d19896 is the first bad commit:
commit aa903cf31391dd505b399627158f1292a6d19896
Author: Bin Meng <bmeng@tinylab.org>
Date: Fri Jun 30 23:36:04 2023 +0800
roms/opensbi: Upgrade from v1.2 to v1.3
Upgrade OpenSBI from v1.2 to v1.3 and the pre-built bios images.
And I see something like:
qemu//build/qemu-system-riscv64 -M microchip-icicle-kit \
-m 3G -smp 5 \
-kernel vmlinux.bin \
-dtb icicle.dtb \
-initrd initramfs.cpio.gz \
-display none -serial null \
-serial stdio \
-D qemu.log -d unimp
qemu-system-riscv64: warning: disabling zca extension for hart
0x0000000000000000 because privilege spec version does not match
qemu-system-riscv64: warning: disabling zca extension for hart
0x0000000000000001 because privilege spec version does not match
qemu-system-riscv64: warning: disabling zcd extension for hart
0x0000000000000001 because privilege spec version does not match
qemu-system-riscv64: warning: disabling zca extension for hart
0x0000000000000002 because privilege spec version does not match
qemu-system-riscv64: warning: disabling zcd extension for hart
0x0000000000000002 because privilege spec version does not match
qemu-system-riscv64: warning: disabling zca extension for hart
0x0000000000000003 because privilege spec version does not match
qemu-system-riscv64: warning: disabling zcd extension for hart
0x0000000000000003 because privilege spec version does not match
qemu-system-riscv64: warning: disabling zca extension for hart
0x0000000000000004 because privilege spec version does not match
qemu-system-riscv64: warning: disabling zcd extension for hart
0x0000000000000004 because privilege spec version does not match
OpenSBI v1.3
____ _____ ____ _____
/ __ \ / ____| _ \_ _|
| | | |_ __ ___ _ __ | (___ | |_) || |
| | | | '_ \ / _ \ '_ \ \___ \| _ < | |
| |__| | |_) | __/ | | |____) | |_) || |_
\____/| .__/ \___|_| |_|_____/|___/_____|
| |
|_|
init_coldboot: ipi init failed (error -1009)
Just to note, because we use our own firmware that vendors in OpenSBI
and compiles only a significantly cut down number of files from it, we
do not use the fw_dynamic etc flow on our hardware. As a result, we have
not tested v1.3, nor do we have any immediate plans to change our
platform firmware to vendor v1.3 either.
I unless there's something obvious to you, it sounds like I will need to
go and bisect OpenSBI. That's a job for another day though, given the
time.
Cheers,
Conor.
signature.asc
Description: PGP signature
- [PATCH for-8.2 5/7] target/riscv/cpu.c: add a ADD_CPU_PROPERTIES_ARRAY() macro, (continued)
- [PATCH for-8.2 5/7] target/riscv/cpu.c: add a ADD_CPU_PROPERTIES_ARRAY() macro, Daniel Henrique Barboza, 2023/07/12
- [PATCH for-8.2 3/7] target/riscv/cpu.c: split vendor exts from riscv_cpu_extensions[], Daniel Henrique Barboza, 2023/07/12
- [PATCH for-8.2 7/7] avocado, risc-v: add opensbi tests for 'max' CPU, Daniel Henrique Barboza, 2023/07/12
- [PATCH for-8.2 6/7] target/riscv: add 'max' CPU type, Daniel Henrique Barboza, 2023/07/12
- Re: [PATCH for-8.2 6/7] target/riscv: add 'max' CPU type, Conor Dooley, 2023/07/12
- Re: [PATCH for-8.2 6/7] target/riscv: add 'max' CPU type, Daniel Henrique Barboza, 2023/07/12
- Re: [PATCH for-8.2 6/7] target/riscv: add 'max' CPU type, Conor Dooley, 2023/07/12
- Re: [PATCH for-8.2 6/7] target/riscv: add 'max' CPU type, Daniel Henrique Barboza, 2023/07/12
- Re: [PATCH for-8.2 6/7] target/riscv: add 'max' CPU type, Conor Dooley, 2023/07/12
- Re: [PATCH for-8.2 6/7] target/riscv: add 'max' CPU type, Daniel Henrique Barboza, 2023/07/12
- Re: [PATCH for-8.2 6/7] target/riscv: add 'max' CPU type,
Conor Dooley <=
- Boot failure after QEMU's upgrade to OpenSBI v1.3 (was Re: [PATCH for-8.2 6/7] target/riscv: add 'max' CPU type), Conor Dooley, 2023/07/13
- Re: Boot failure after QEMU's upgrade to OpenSBI v1.3 (was Re: [PATCH for-8.2 6/7] target/riscv: add 'max' CPU type), Daniel Henrique Barboza, 2023/07/13
- Re: Boot failure after QEMU's upgrade to OpenSBI v1.3 (was Re: [PATCH for-8.2 6/7] target/riscv: add 'max' CPU type), Conor Dooley, 2023/07/13
- Re: Boot failure after QEMU's upgrade to OpenSBI v1.3 (was Re: [PATCH for-8.2 6/7] target/riscv: add 'max' CPU type), Daniel Henrique Barboza, 2023/07/13
- Re: Boot failure after QEMU's upgrade to OpenSBI v1.3 (was Re: [PATCH for-8.2 6/7] target/riscv: add 'max' CPU type), Alistair Francis, 2023/07/13
- Re: Boot failure after QEMU's upgrade to OpenSBI v1.3 (was Re: [PATCH for-8.2 6/7] target/riscv: add 'max' CPU type), Daniel Henrique Barboza, 2023/07/14
- Re: Boot failure after QEMU's upgrade to OpenSBI v1.3 (was Re: [PATCH for-8.2 6/7] target/riscv: add 'max' CPU type), Conor Dooley, 2023/07/13
- Re: Boot failure after QEMU's upgrade to OpenSBI v1.3 (was Re: [PATCH for-8.2 6/7] target/riscv: add 'max' CPU type), Anup Patel, 2023/07/14
- Re: Boot failure after QEMU's upgrade to OpenSBI v1.3 (was Re: [PATCH for-8.2 6/7] target/riscv: add 'max' CPU type), Conor Dooley, 2023/07/14
- Re: Boot failure after QEMU's upgrade to OpenSBI v1.3 (was Re: [PATCH for-8.2 6/7] target/riscv: add 'max' CPU type), Conor Dooley, 2023/07/14