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
