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

[Anup Patel]

On Thu, Aug 28, 2025 at 12:17 PM Jessica Clarke <jrtc27 at jrtc27.com> wrote:
>
> On 28 Aug 2025, at 07:20, Jessica Clarke <jrtc27 at jrtc27.com> wrote:
> > 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.
>
> Especially since you keep the author intact, don’t add any kind of
> Co-authored-by and don’t document any of the changes you have made
> between the author’s Signed-of-by and yours. This means it looks like
> it’s the submitter’s fault that there’s a bug in the commit, when in
> reality they submitted a correct patch and you broke it. That’s not a
> particularly nice thing to have done to one’s work.
>
> Might I suggest, if the goal is to avoid the author needing to submit a
> vN+1, at least confirm with the author that your intended fixes are
> correct before folding them into the patch you commit? And, for more
> minor cases, document that you’ve made changes, whether in the Linux
> kernel committer style that states what you’ve actually done, or at
> least by adding your own Co-authored-by to state you’ve done something
> unspecified.
>

I don't mind adding Co-developed-by and more comments about
my changes.

Regards,
Anup