Re: [RFC PATCH 00/17] sunxi: rework pinctrl and add T113s support

[Sam Edwards <cfsworks@gmail.com>]

On 6/21/23 04:55, Andre Przywara wrote:
> On Tue, 20 Jun 2023 16:11:48 -0600
> Sam Edwards <cfsworks@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.msuchanek@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