On 6/21/23 04:55, Andre Przywara wrote:
On Tue, 20 Jun 2023 16:11:48 -0600
Sam Edwards <cfswo...@gmail.com> wrote:
Hi Sam,
pleasure to write with you ;-)
Hi Andre,
Likewise!
Well, so this is actually the fallback implementation which should
somewhat work on most SoCs: set a flag, reset, and catch the flag in
the SPL. For modern SoCs with CPU hotplug support (the H616 is one one
of those, and it looks like the T113s is as well), there is actually a more
direct route:
Oh man, I would definitely prefer a direct route that doesn't require
the SPL coming up a second time, but...
We put some magic and the FEL entry address into some special memory
locations, then just reset. Now the *BootROM* will do the check already,
and branch to the provided entry point, which would be the FEL routine.
This doesn't rely on a prepared SPL to be loaded, so works without a
boot device with mainline U-Boot around.
Refer to section 3.4.2.3 and 3.4.2.4 of the T113-S3 user manual (v1.1).
According to this, the magic would be 0xfa50392f, the magic's address is
0x070005C0, and CPU0's entry point address would be in 0x070005C4. I had a
proof of concept implementation for the H616 using this method.
...I tried this and it seems that the 070005C* block hardware-resets to
zero before BROM runs. Is there a softer reset method you had in mind
that would avoid this?
The only
problem left would be that someone needs to clean the magic afterwards,
otherwise any follow-up reset would trigger FEL mode again.
That's at least pretty fixable though: instead of setting the entry
address to the FEL entry point, set it to a thunk placed in SRAM that
clears the flag before continuing onward to FEL.
The "fel-reset" command (which is easier to type than what I have, "run
fel_do_enter") would then call sunxi_fel_flag_set() and initiate a
reset, and the SPL's early init just has to do sunxi_fel_flag_test() ->
sunxi_fel_flag_clear() -> go_to_fel(). Seems easy enough.
Could you recommend to me a sufficiently different chip to test my
abstractions against? Something ARMv8 and *without* RTC?
I think all ARMv8 parts have an RTC, so your generic approach might work
there as well. The complication is that the SPL switches to AArch64 very
early, in hand-stitched AArch32 assembly, check out
arch/arm/include/asm/arch-sunxi/boot0.h.
The check would need to be coded like this, then.
I can then send
in a series adding FEL support for that. (Also, did that H3 patch
actually land? I didn't see anything but want to know if I should be
refactoring my approach to extend what that H3 patch does or not.)
https://patchwork.ozlabs.org/project/uboot/patch/c211aa414c59e7275fef82bf6f0035276d6e29f3.1656875482.git.msucha...@suse.de/
This approach seems close to mine, only my go_to_fel() enters by way of
return_to_fel() after first modifying fel_stash.lr, since the
return_to_fel() mechanism already takes care of restoring the core to a
BROM-friendly state.
One might abuse the board as a T113s dev
board, maybe ;-) Does it work without any of the modules populated?
Sure, if you're thinking about getting one. You just need an ATX-pinout
PSU to power the BMC (it runs off of the 5V standby rail).
... having a board. So far you are the one contributor with access to
the hardware, so: thanks for volunteering! ;-)
Andre, please, I know you're being tongue-in-cheek here, but I said
"no." We should have reached the agree-to-disagree point 2 emails ago:
you've made your (very compelling) case for why downstream would benefit
from the early expertise of the upstream DT reviewers, and how upstream
would benefit from having the DT for a second "real" T113-using board,
but at some point you need to trust that I understand that and that I
must therefore have very good reasons not to be distracting myself with
trying to (dual-)boot a mainline kernel yet. One thing at a time, y'know? :)
The U-Boot build system support some kind of build time DT "overlay"
feature: You put a file with the same name, but ending in
"-u-boot.dtsi" in the arch/arm/dts directory, and it will be included
into the DT which gets embedded into the U-Boot image. See
arch/arm/dts/sun50i-a64-sopine-baseboard-u-boot.dts for an
example, and doc/develop/devicetree/control.rst for the proper
documentation.
So we upstream a minimal, non-controversial and non-contradicting base
.dts into the kernel tree, and can fix things up for the time being
using this method. This hack can then go away if either the mainline
kernel DT gets fixed and/or U-Boot learns the quad-SPI trick.
Oh, good to know! I'll try to remember that this option exists when the
time comes to use it.
Someone from the board vendor company actually actively adding upstream
support for their device early. There were some examples in the past
where employees participated in upstreaming, but I cannot remember
seeing this too often when it comes to the initial DT support.
I brought this email thread to the attention of the firmware development
team at this company, then. No promises (they seem to have their hands
sufficiently full with userspace work) but FWIW my opinion of them is
that they do have a community-centric and F/OSS-oriented mindset, so
with a bit of luck they may make themselves known on the upstream
mailing lists at some point.
Thank you for your ongoing efforts,
Sam
