A64, arisc, SCPI and regulator handling

[Karsten Merker]

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

For reference the SCPI spec:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0922c/index.html

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,
https://www.debian.org/social_contract#guidelines) and
b) has all its dependencies and build-dependencies fulfilled
within main.

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.

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.

Even if we had a firmware implementation under a DFSG-compatible
license, inclusion in main would still pose a problem as we
cannot build it with the tools in main: there is no OpenRisc
support in mainline binutils and gcc and that will probably not
change in the forseeable future:

https://people.debian.org/~mafm/posts/2015/20150421_about-the-debian-gnulinux-port-for-openrisc-or1k/

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.

Regards,
Karsten
--
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

[Siarhei Siamashka]

On Thu, 21 Jan 2016 21:38:39 +0100
Karsten Merker <mer...@debian.org> wrote:

> 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
> cores.
>
> For reference the SCPI spec:
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0922c/index.html
>
> 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,
> https://www.debian.org/social_contract#guidelines) and
> 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.

> Even if we had a firmware implementation under a DFSG-compatible
> license, inclusion in main would still pose a problem as we
> cannot build it with the tools in main: there is no OpenRisc
> support in mainline binutils and gcc and that will probably not
> change in the forseeable future:
>
> https://people.debian.org/~mafm/posts/2015/20150421_about-the-debian-gnulinux-port-for-openrisc-or1k/

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 [1]
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 :-)

[1] https://github.com/skristiansson/ar100-info

--
Best regards,
Siarhei Siamashka

[Chen-Yu Tsai]

Hi,

On Fri, Jan 22, 2016 at 9:23 AM, Siarhei Siamashka
<siarhei....@gmail.com> wrote:
> On Thu, 21 Jan 2016 21:38:39 +0100
> Karsten Merker <mer...@debian.org> wrote:
>
>> 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
>> cores.

This has been the case for Allwinner's SDK since the A31. We just
haven't used it for mainline.

>> For reference the SCPI spec:
>> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0922c/index.html
>>
>> 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:

The more immediate problem for A64 is the firmware blobs are loaded
by their boot0. Without our own boot0/u-boot, it'll be hard not to
have them running.

This makes mainlining PMIC support more complicated, as something is
running behind the scene potentially making other changes to the RSB
controller and/or the PMIC. This is what yesterday's discussion was
mainly about. Workarounds:

a) Skip RSB/PMIC support. That means you won't get things like WiFi
and Ethernet working.

b) Either port Allwinner's arisc interface or rewrite based on their
message passing design.

>> Debian/main can only contain free software that
>> a) complies with the Debian Free Software Guidelines (DFSG,
>> https://www.debian.org/social_contract#guidelines) and
>> 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)?

On the A64 there seems to be two pieces of firmware, one for arisc,
handling PMIC and DVFS, and another for secure monitor, handling
SMC calls. What the latter should do in the SMC calls I'm not sure.

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

I don't think this would be an issue, at least for boards with SoCs
that have the OpenRISC core.

Having went through most of the PMIC datasheets, the outputs for the
important stuff (CPUX, CPUS, DRAM, AVCC, SYS-PLL) are enabled by
default.

The default voltage of the DRAM regulator is hardware configurable
via the DC?SET pin. Choices are: 1.2V for LPDDR3/LPDDR2, 1.35V for
DDR3L, 1.5V for DDR3.

Unless the board is routed badly, resulting in a large voltage drop,
or the design fails to match the DRAM type with the DC?SET pin setting,
everything should work.

cpufreq / DVFS is another story.

True. Is anyone making any progress on this?

Regards
ChenYu

> PS. As you can see from my last linux-sunxi wiki edits, I've been
> doing some OpenRISC hacking recently. The ar100-info application [1]
> 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 :-)
>
> [1] https://github.com/skristiansson/ar100-info
>
> --
> Best regards,
> Siarhei Siamashka
>

> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Ian Campbell]

On Thu, 2016-01-21 at 21:38 +0100, Karsten Merker wrote:
> Even if we had a firmware implementation under a DFSG-compatible
> license, inclusion in main would still pose a problem as we
> cannot build it with the tools in main

I think if the source is available and it is DFSG free then it should
be a candidate for the firmware-free package, which is in main and
contains binary blobs + their source and instructions on how to build,
without a requirement for all manner of toolstacks to actually be in
main (a compromise based on things being firmware not run on the
primary processor AIUI).

I believe this Debian source package is derived from the parts of the
kernel.org linux-firmware.git which have source, with the rest going
into the firmware-nonfree package(s).

> : there is no OpenRisc
> support in mainline binutils and gcc and that will probably not
> change in the forseeable future:
>
> https://people.debian.org/~mafm/posts/2015/20150421_about-the-debian-
> gnulinux-port-for-openrisc-or1k/

Apart from the above, I think an openrisc cross compiler in Debian does
not depend on there being a full Debian port available, there are cross
compilers for various embedded platforms (even microcontrollers etc)
which cannot possibly support a full distro.

Support not being in mainline binutils/gcc might be a blocker, that
would need to be discussed with the relevant package maintainers I
suppose

Ian.

[Diego Roversi]

On Thu, 21 Jan 2016 21:38:39 +0100
Karsten Merker <mer...@debian.org> wrote:

> Even if we had a firmware implementation under a DFSG-compatible
> license, inclusion in main would still pose a problem as we
> cannot build it with the tools in main: there is no OpenRisc
> support in mainline binutils and gcc and that will probably not
> change in the forseeable future:
>
> https://people.debian.org/~mafm/posts/2015/20150421_about-the-debian-gnulinux-port-for-openrisc-or1k/

We don't need a complete linux porting to openrisk, for building the firmware a openrisc cross compiler (and binutils) is sufficient, I think.

Regards,
Diego.

--
Diego Roversi <die...@tiscali.it>

[Karsten Merker]

I suppose that is rather obvious for a vendor-supplied blob :-).

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

Then maybe I have misunderstood the discussion, but my impression
was that the idea was to use the vendor blob to access the PMIC.

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

Hm, according to the information that you have added to
https://linux-sunxi.org/Pine64#AXP803_PMIC it looks like not all
default voltages are correct. Things might work nonetheless of
course, but I would prefer not to have to rely on that
assumption.

> > Even if we had a firmware implementation under a DFSG-compatible
> > license, inclusion in main would still pose a problem as we
> > cannot build it with the tools in main: there is no OpenRisc
> > support in mainline binutils and gcc and that will probably not
> > change in the forseeable future:
> >
> > https://people.debian.org/~mafm/posts/2015/20150421_about-the-debian-gnulinux-port-for-openrisc-or1k/
>
> 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.

As other people have also jumped on the "full linux port" thing:
I have never written that we would need a full-fledged Linux port
for the arisc. I have just pointed out that we lack mainline gcc
support for OpenRisc and pointed to a blog entry which describes
why that is the case.

> OpenRISC is already supported by the mainline binutils and newlib.

Yes, you are of course right with regard to binutils, it's just
gcc that isn't mainlined.

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

There aren't any legal obstacles, but the lack of mainline
support means that we cannot just enable an additional target in
the existing package builds and the Debian gcc maintainer has
already stated in the past that he is not interested in having to
carry along huge patchsets for supporting architectures that have
no chance of entering mainline.

As you wrote, that is a "potential code quality and maintenance
problem".

> And would just a single package with a "gcc-or1k-elf"
> bare-metal toolchain cause big problems for Debian?

Not from a legal point of view, but having such a separate
bare-metal toolchain would require somebody with experience with
the OpenRisc architecture who is willing to package it and
maintain the package for the lifetime of each Debian release -
currently we don't have this somebody :-).

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

I know nothing about the implementation details of suspend/resume,
but suspend/resume seems to work on lots of A10/A13/A20/A23/A33-
based android tablets, which to my knowledge don't have an extra
coprocessor for that. Can't the same mechanism be used on the
newer SoCs as well? Please excuse if this is stupid question - I
probably don't have the necessary technical background knowledge in
this area.

Regards,
Karsten

P.S.:
Please see my reply to Ian's mail - if there is a policy
exception as Ian writes, the toolchain issues wouldn't be a
stopper for getting a DFSG-compatible firmware implementation
into Debian.

[Karsten Merker]

On Fri, Jan 22, 2016 at 09:31:38AM +0000, Ian Campbell wrote:
> On Thu, 2016-01-21 at 21:38 +0100, Karsten Merker wrote:
> > Even if we had a firmware implementation under a DFSG-compatible
> > license, inclusion in main would still pose a problem as we
> > cannot build it with the tools in main
>
> I think if the source is available and it is DFSG free then it should
> be a candidate for the firmware-free package, which is in main and
> contains binary blobs + their source and instructions on how to build,
> without a requirement for all manner of toolstacks to actually be in
> main (a compromise based on things being firmware not run on the
> primary processor AIUI).

Ok, I wasn't aware that ftpmaster has agreed to a policy
exception for firmware in main. The official Debian policy
documentation doesn't mention anything about this.

With such a policy exception there would of course be no problem
in getting a DFSG-compliant firmware into main.

> Apart from the above, I think an openrisc cross compiler in Debian does
> not depend on there being a full Debian port available, there are cross
> compilers for various embedded platforms (even microcontrollers etc)
> which cannot possibly support a full distro.

Please see my reply to Siarhei's mail.

[Maxime Ripard]

On Sat, Jan 23, 2016 at 07:42:49PM +0100, Karsten Merker wrote:
> > > 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.
>
> Then maybe I have misunderstood the discussion, but my impression
> was that the idea was to use the vendor blob to access the PMIC.

No, the plan was to use *a* blob.

Since the original firmware provided by Allwinner doesn't support SCPI
anyway (and that we probably can't use it in the end), it's never
really been the plan to use it.

> > > Even if we had a firmware implementation under a DFSG-compatible
> > > license, inclusion in main would still pose a problem as we
> > > cannot build it with the tools in main: there is no OpenRisc
> > > support in mainline binutils and gcc and that will probably not
> > > change in the forseeable future:
> > >
> > > https://people.debian.org/~mafm/posts/2015/20150421_about-the-debian-gnulinux-port-for-openrisc-or1k/
> >
> > 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.
>
> As other people have also jumped on the "full linux port" thing:
> I have never written that we would need a full-fledged Linux port
> for the arisc. I have just pointed out that we lack mainline gcc
> support for OpenRisc and pointed to a blog entry which describes
> why that is the case.

Even if we port Linux on that CPU, it doesn't have an MMU, so we could
probably not run debian on it anyway, so having a gcc port in debian
doesn't seem useful anyway.

I'd think that as far as Debian is involved, it would only end up
being a free (as in you have the source code) firmware that should be
packaged somehow.

> > > 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.
>
> I know nothing about the implementation details of suspend/resume,
> but suspend/resume seems to work on lots of A10/A13/A20/A23/A33-
> based android tablets, which to my knowledge don't have an extra
> coprocessor for that. Can't the same mechanism be used on the
> newer SoCs as well? Please excuse if this is stupid question - I
> probably don't have the necessary technical background knowledge in
> this area.

You're mixing up very different things.

First off, suspend / resume doesn't work in mainline. We could use a
"software" suspend / resume implementation on all the SoCs you're
talking about (and we will have to do it on the A10 and A20). However,
on the newer SoCs (since the A31), we have that openrisc co-processor
to help do that (and as far as I know, the Allwinner implementation
does use it).

What doesn't work anymore with the A64 is the PMIC communication, that
is completely orthogonal. In the A64, the ARM CPUs cannot talk to the
PMIC bus controller anymore, so we have to use the openrisc core
there. And since we will have to do this work for the A64, we can also
just use it for the A31 and later SoCs together, since they all share
the same design.

Maxime

--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com