From: Sean Anderson <seanga2@gmail.com>
To: u-boot@lists.denx.de
Subject: [PATCH 0/7] riscv: Correctly handle IPIs already pending upon boot
Date: Tue, 8 Sep 2020 22:38:26 -0400 [thread overview]
Message-ID: <9b45823d-77e2-bb48-a1d5-cda9221f2b47@gmail.com> (raw)
In-Reply-To: <CAN5B=e+RKBY1gBDUuM=mEcoqV7yzBuYwQkGf-QPFq88NGvWBvg@mail.gmail.com>
On 9/8/20 10:02 PM, Rick Chen wrote:
> Hi Sean
>
>> On the K210, the prior stage bootloader does not clear IPIs. This presents
>> a problem, because U-Boot up until this point assumes (with one exception)
>> that IPIs are cleared when it starts. This series attempts to fix this in a
>> robust manner, and fix several concurrency bugs I noticed while fixing
>> these other areas. Heinrich previously submitted a patch addressing part of
>> this problem in [1].
>>
>> [1] https://patchwork.ozlabs.org/project/uboot/patch/20200811035648.3284-1-xypron.glpk at gmx.de/
>>
>
> It sounds like that the bootloader does not deal with SMP flow well
> and jump to u-boot-spl, right ?
>
> I have a question that why not try to fix the prior stage bootloader
> to clear IPIs correctly?
Because it is a ROM :)
>
> Actually I have encounter a similar SMP issue like you.
> Our prior stage bootloader will jump to u-boot-spl with the incorrect
> mstatus and result in the SMP working abnormal in u-boot-spl.
Perhaps we should just clear MIE then? I originally had a patch in this
series which moved the handle_ipi code into handle_trap, and got rid of
the manual checks on the interrupt. Something like
secondary_hart_loop:
wfi
j secondary_hart_loop
Of course as part of that we would need to explicitly enable and disable
interrupts. Perhaps not the worst idea, but I didn't include it here
because I figure the current system work OK, even if it is not what one
might expect.
> I mean this is an individual case, not a general case.
> If we try to cover any errors which come from any prior stage bootloaders,
> the SMP flow will become more and more complicated and hard to debug.
Of course, if a prior bootloader doesn't hold up its end of the
contract, we can be left with some awful bugs to fix. U-Boot is
generally not too bad to debug, but I've had an awful time whenever some
concurrency sneaks into the mix. I think it's much better to confine the
(necessary) complexity to as few files as possible, so that the rest of
the code can be ignorant. I think part of that is verifying that we have
everything in a known state, so that when we see something unexpected,
we can handle it/panic/whatever instead of silently getting a bug.
--Sean
next prev parent reply other threads:[~2020-09-09 2:38 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-07 18:16 [PATCH 0/7] riscv: Correctly handle IPIs already pending upon boot Sean Anderson
2020-09-07 18:16 ` [PATCH 1/7] Revert "riscv: Clear pending interrupts before enabling IPIs" Sean Anderson
2020-09-09 7:50 ` Rick Chen
2020-09-09 10:23 ` Sean Anderson
2020-09-10 6:39 ` Rick Chen
2020-09-10 10:18 ` Sean Anderson
2020-09-11 7:38 ` Bin Meng
2020-09-11 10:22 ` Sean Anderson
2020-09-11 14:45 ` Bin Meng
2020-09-11 18:30 ` Sean Anderson
2020-09-14 3:10 ` Rick Chen
2020-09-14 12:45 ` Sean Anderson
2020-09-07 18:16 ` [PATCH 2/7] riscv: Match memory barriers between send_ipi_many and handle_ipi Sean Anderson
2020-09-11 7:45 ` Bin Meng
2020-09-07 18:16 ` [PATCH 3/7] riscv: Use NULL as a sentinel value for smp_call_function Sean Anderson
2020-09-09 8:33 ` Rick Chen
2020-09-09 9:01 ` Rick Chen
2020-09-09 10:16 ` Sean Anderson
2020-09-09 10:26 ` Heinrich Schuchardt
2020-09-09 10:36 ` Sean Anderson
2020-09-10 8:09 ` Rick Chen
2020-09-14 3:21 ` Rick Chen
2020-09-11 8:04 ` Bin Meng
2020-09-14 1:58 ` Leo Liang
2020-09-14 2:07 ` Bin Meng
2020-09-14 6:10 ` Leo Liang
2020-09-14 6:15 ` Bin Meng
2020-09-14 14:05 ` Sean Anderson
2020-09-07 18:16 ` [PATCH 4/7] riscv: Clear pending IPIs on initialization Sean Anderson
2020-09-14 2:08 ` Bin Meng
2020-09-07 18:16 ` [PATCH 5/7] riscv: Add fence to available_harts_lock Sean Anderson
2020-09-10 3:26 ` Rick Chen
2020-09-11 10:39 ` Sean Anderson
2020-09-11 14:47 ` Bin Meng
2020-09-07 18:16 ` [PATCH 6/7] riscv: Ensure gp is NULL or points to valid data Sean Anderson
2020-09-14 5:25 ` Bin Meng
2020-09-14 13:03 ` Sean Anderson
2020-09-14 13:27 ` Sean Anderson
2020-09-07 18:16 ` [PATCH 7/7] riscv: Add some comments to start.S Sean Anderson
2020-09-14 5:26 ` Bin Meng
2020-09-09 2:02 ` [PATCH 0/7] riscv: Correctly handle IPIs already pending upon boot Rick Chen
2020-09-09 2:38 ` Sean Anderson [this message]
2020-09-09 2:44 ` Sean Anderson
2020-09-10 7:08 ` Rick Chen
2020-09-10 10:49 ` Sean Anderson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9b45823d-77e2-bb48-a1d5-cda9221f2b47@gmail.com \
--to=seanga2@gmail.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox