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/c211aa414c59e7275fef82bf6f0...
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