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 -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: Digital signature
