On Thu, 21 Jan 2016 21:38:39 +0100
Karsten Merker <mer...@debian.org
> Hello everybody,
> I have read today's IRC discussion about handling the regulator
> control on the A64 via the SCPI protocol implemented by a
> firmware running on the "arisc"/AR100 (OpenRisc Core) embedded in
> the SoC, instead of controlling the PMIC directly from the ARM
> For reference the SCPI spec:
> Maxime has mentioned potential technical problems due to lack of
> certain functionality in the SCPI spec, but I would also like to
> point out another problematic angle of using loadable coprocessor
> firmware for implementing essential functionality.
> AFAICS, the firmware for the arisc gets supplied to the arisc by
> either u-boot or the kernel. This poses a problem for Linux
> distributions with strict policies such as Debian:
> Debian/main can only contain free software that
> a) complies with the Debian Free Software Guidelines (DFSG,
> b) has all its dependencies and build-dependencies fulfilled
> within main.
Can you please clarify, which clause in the Debian Free Software
Guidelines is problematic in this particular case?
> Debian also has a "contrib" and a "non-free" repository, but
> those are not part of the official Debian releases and are not
> distributed on offical installation media. The user has the
> option to enable package installations from those repositories
> later on in the installation process if he explicitly wishes to
> do so, but the Debian-Installer images published by Debian can
> only contain software from main.
> If the arisc firmware is required for basic bringup of the
> system, this would mean that Debian would have to ship the
> firmware as part of the installer images. This would only be
> possible if the firmware fulfills the requirements for being
> included in the "main" repository, which excludes any binary-only
> vendor-supplied firmware file.
I don't think that anyone considers the use of the vendor-supplied
firmware. Does the Allwinner's arisc firmware even implement the
SCPI protocol? Or is it not exactly compatible, but merely serves
a similar role (just like FEX serves a similar role as DTS)?
> The Debian-Installer offers an option for the user to provide
> loadable firmware on a USB stick, but that doesn't help when
> getting to that point already requires the ability to control
> the regulators.
I don't think that we would need to resort to this.
That said, the voltage regulators usually have sane defaults.
After all, the boot ROM is activated and starts running some
initial code when using these default voltages. The only potentially
problematic thing is the DRAM because it is not directly used by
the BROM. But we are yet to see some hardware, which is unable to
work at the default PMIC settings. I would be really interested
to know if something like this exists.
Regarding this blog. Very few of the problems mentioned there apply
to us. What we need is just a simple bare-metal toolchain to build
a very simple firmware. We don't need things like autotools and glibc,
because we are not trying to build a huge Linux distribution for
the OpenRISC architecture with lots of userland packages.
OpenRISC is already supported by the mainline binutils and newlib.
As for the GCC, indeed one of the OpenRISC patches contributor did
not reassign his copyright to the FSF, which prevents this GPL
licensed work from being merged with the mainline GCC. But a lot
of free software does not have a policy of reassigning copyright
to the original author or some organization, and such software
is packaged in Debian without problems.
Without doubt, relying on a non-mainlined GCC fork is a potential
code quality and maintenance problem. And of course, nobody likes
it this way, but I don't see any legal obstacles.
The blog says "Debian will not accept private forks of those
essential packages without a very good reason even in unofficially
supported ports". Don't we already have a very good reason? And would
just a single package with a "gcc-or1k-elf" bare-metal toolchain
cause big problems for Debian?
> To avoid all these problems, I would like to strongly propose
> doing the RSB and PMIC handling directly from the ARM core (as it
> has been done for all other Allwinner SoCs) and not use the arisc
> at all if that is technically feasible.
Well, this would prevent us from ever having a decent suspend
support among other things.
PS. As you can see from my last linux-sunxi wiki edits, I've been
doing some OpenRISC hacking recently. The ar100-info application 
got Allwinner H3 support and everyone is welcome to try it on the
boards like Orange Pi PC. I also have some sunxi-tools improvements
in the queue, which are going to make developing code for the
OpenRISC core and debugging it much easier. Wanted to make an
announcement when everything is ready, but you are kinda pushing
me to let the cat out of the bag prematurely :-)