Hi, On Fri, Jan 22, 2016 at 9:23 AM, Siarhei Siamashka <[email protected]> wrote: > On Thu, 21 Jan 2016 21:38:39 +0100 > Karsten Merker <[email protected]> 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. >> 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. 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 [email protected]. > For more options, visit https://groups.google.com/d/optout. -- 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.
