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

[Sam Edwards]

Hi Andre,

On 6/20/23 06:42, Andre Przywara wrote:
> So yeah, the request of a "Enter FEL" command came up multiple times, but
> so far no one could be bothered to implement this properly. The idea would
> be to have a generic command (more like "fel-reset" than efex), and
> allow each SoC (family) to implement this differently, as every
> SoC requires something a bit different here (32-bit vs. 64-bit, having an
> RTC vs not, etc).
> 
> If you could post your solution somewhere, we could start this effort.
> There was some patch for the H3 already, and it's relatively
> straight-forward on the newer SoCs (H616, IIRC), so if at least two
> popular, but different SoCs would be supported, we could make sure to have
> the right abstractions in place.

I already have a "go_to_fel()" that does the right thing to enter FEL 
from the SPL; I would pretty much just need to introduce the following 
per-SoC(-family) functions:
- bool sunxi_fel_flag_test(void)
- void sunxi_fel_flag_clear(void)
- void sunxi_fel_flag_set(void)

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 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.)

> Ah, depending on the BSP kernel is indeed quite bad. I wonder what
> features of the kernel you rely on that upstream does not have? Or is it
> more about the BMC userland parts that are married to the Allwinner kernel
> and its own interfaces?

I don't fully know; getting the kernel back on mainline is, as I said, a 
push for another day. I'm very much making a point of not looking into 
it before the bootloader can be upgraded to something that isn't a 
crashy, hard-to-update, failure-prone mess. (I'm working in "biggest 
fire, first out" order.)

That said, the first such dependent feature that leaps to mind is the 
AWNAND driver's CONFIG_AW_SPINAND_SIMULATE_MULTIPLANE, which logically 
interleaves pages of the NAND in a different ordering vs. what the 
physical NAND (and mainline's spi-nand driver) does. Alas this is a 
feature we're dependent on not because it provides benefits to our users 
(it does not, and in downstream discussions I've been soapboxing about 
how it's likely wearing down people's NANDs) but because the boards are 
flashed at the factory with this flag enabled so we need it set for the 
NAND to be accessible. We've experimented with reflashing the board with 
that flag disabled, but that has so far only resulted in corrupted flash.

Hope is not lost, though, for I have a half-written tool which shows 
some promise in being able to "unscramble the egg" and migrate existing 
NANDs over to the correct layout. That should be sufficient to get 
mainline U-Boot (and Tina Linux with the flag disabled) working, but I 
have no idea about mainline Linux still: this would only peel back one 
layer of the onion, and I don't know whether the next obstacle will be 
easier, harder, or about the same difficulty.

But it does mean that, for now, we're stuck with Tina Linux.

> Final DT is a noble goal, but in reality there will always be room for
> improvement and additions. So what we typically do is to start with a
> simple .dts for the kernel tree, describing the basic peripherals, and
> everything that already works and is not subject to debate. If in doubt,
> include a node, and we will comment. Could you prepare such a patch?

The peripheral-describing .dts that I have is for Tina Linux, and uses 
incompatible compatibles (ha), includes, dt-bindings, temporary hacks 
while better driver support can be developed, and would otherwise not 
fly upstream. I can send it in *anyway* if for some reason you think 
that's a good idea, but I really don't see that as being anything other 
than a waste of time.

As well, I can't write a fresh .dts for mainline (one more likely to be 
accepted on the list). A mainline kernel has never been booted on this 
board, so I would do no better at this than a kernel contributor 
selected at random. The best I can do now is write something that 
*looks* like the correct .dts.

As I keep saying, that may change in the future. But the answer today is 
still "no, I cannot."

> This
> should not contradict any DT nodes that U-Boot uses, so it's not a double
> effort.

True, in theory it *shouldn't* but in practice, I've found it does.

One way I've been bitten is that the sunxi SPI driver in U-Boot doesn't 
support Quad-SPI, so if the DT says the SPI-NAND is connected with a bus 
width of 4, the SPI-NAND driver requests Quad-SPI transfers, but the SPI 
master driver has no idea that it needs to handle the transfer any 
differently, and we're left with corrupt NAND reads/writes. Without 
Quad-SPI support in U-Boot's master driver (and/or, better yet, a U-Boot 
equivalent to Linux commit 83596fbeb5) -- also a push for another day -- 
I have no choice but to give U-Boot a specially edited version of the DT 
that omits this property.

> This would mean we have a *second* board DT for the T113s SoC in the
> kernel, which always helps to improve quality and prevents hacks that just
> work on the MangoPi. Besides, the TuringPi board is an actually useful
> application of the SoC, deployed and available, in contrast to just some
> development board from Chinese websites.
> And once this is merged, we could just copy this over to U-Boot and add
> the defconfig and any other support patches there.

See below.

>> ...but for now it's very much meant to be out-of-tree. :)
>>
>> (I also do not work for the company that produced this board -- I'm just
> 
> Ah, that would have been a first anyway ;-)

Oh? What would have been a first? I could pass it along to my contact at 
this company and encourage him to get involved in some way. I'm sure 
they'd appreciate the opportunity for the good press associated with 
being the first at something in the F/OSS world, and it might help to 
get them in the habit of cooperating closely with upstream (to make it 
less likely that they just fork things the moment upstream doesn't solve 
some problem they're having).

> Yeah, I understand it's not the most grateful job to chase up on doing
> things properly and stay on with the upstreaming process. Ultimately it's
> the right thing to do, though, and will save you hassle over time. Plus we
> (the community) will help you with that, and you'd get a second commit in
> the kernel ;-)

Ideologically-speaking, this is music to my ears, and I think we would 
even be having this same discussion were our roles reversed: we do both 
agree fully on the (mutual) benefits of upstream contribution.

But even more ultimately: the available time on any given day is 
limited, and I have to choose my battles. There are often things that 
either require less effort, save an even greater hassle over time, or 
provide more urgently-needed benefits, which (pragmatically speaking) 
ought to take priority. That doesn't mean the other lower-priority items 
have no benefit, it just means they should not be done *now.*

> Cheers,
> Andre

Likewise,
Sam