[PATCH v3] generic: mips: support harts to boot from mips_warm_boot

[Jessica Clarke]

On 28 Aug 2025, at 06:32, Anup Patel <anup at brainfault.org> wrote:
> On Thu, Jul 24, 2025 at 2:10 AM Chao-ying Fu <icebergfu at gmail.com> wrote:
>> 
>> We program reset base for harts (other than hart 0) to boot at
>> mips_warm_boot that jumps to _start_warm. This helps to skip some code
>> sequence to speed up.
>> 
>> Signed-off-by: Chao-ying Fu <cfu at mips.com>
>> ---
>> platform/generic/mips/mips_warm_boot.S | 20 ++++++++++++++++++++
>> platform/generic/mips/objects.mk       |  2 +-
>> platform/generic/mips/p8700.c          |  5 +++++
>> 3 files changed, 26 insertions(+), 1 deletion(-)
>> create mode 100644 platform/generic/mips/mips_warm_boot.S
>> 
>> diff --git a/platform/generic/mips/mips_warm_boot.S b/platform/generic/mips/mips_warm_boot.S
>> new file mode 100644
>> index 0000000..25cdb83
>> --- /dev/null
>> +++ b/platform/generic/mips/mips_warm_boot.S
>> @@ -0,0 +1,20 @@
>> +/*
>> + * SPDX-License-Identifier: BSD-2-Clause
>> + *
>> + * Copyright (c) 2025 MIPS
>> + *
>> + */
>> +       .text
>> +       .align  12
>> +       .globl  mips_warm_boot
>> +mips_warm_boot:
>> +       j       _start_warm
>> +       .align  2
>> +nmi_vector:
>> +       j       _start_warm
>> +       .align  2
>> +cacheerr_vector:
>> +       j       _start_warm
>> +       .align  2
>> +debugexc_vector:
>> +       j       _start_warm
> 
> nmi_vector, cacheerr_vector, and debugexc_vector are not used
> anywhere so I have dropped these at the time of merging. Please
> send separate patches to add these when they are being used
> somewhere.
> 
> Reviewed-by: Anup Patel <anup at brainfault.org>
> 
> Applied this patch to the riscv/opensbi repo.

Uh I’m pretty sure this is a reset vector, and each label is naming the
different entries in the vector, much like for mtvec.MODE=Vectored, and
therefore the result of deleting those vector entries is that, if any
of those cases occur, it will end up running whatever random code
happens to be after the first entry.

I’ve noticed you are quite eager to modify people’s patches before
applying them. Reformatting is one thing, but deleting assembly code is
another that I think goes too far. Please be more considerate of the
fact that you may not be correct in your interpretation, and so it is
not appropriate to unilaterally commit whatever unreviewed changes you
think are best, especially when it comes to vendor-specific code for
which you haven’t read any of the corresponding manuals.

Jessica