On Fri, Jan 12, 2018 at 9:15 AM, Jan Pazdziora <jpazdziora(a)redhat.com> wrote:
On Mon, Jan 08, 2018 at 08:17:17AM +0000, Peter Robinson wrote:
> On Fri, Dec 22, 2017 at 12:37 PM, Jan Pazdziora <jpazdziora(a)redhat.com> wrote:
> > Hello,
> > I've got Banana Pi M64 on which I am able to run
> > 2017-08-14-ubuntu-16.04-mate-desktop-beta-aarch64-bpi-m64-sd-emmc.img
> > from http://www.banana-pi.org/m64-download.html
> > except for failing WiFi connections to hidden SSID networks and
> > for kodi being unbearably slow, even the UI and mouse movements.
> > So seeing Ubuntu MATE not failing completely, I thought I'd give
> Well I suspect the Ubuntu images uses a vendor kernel and proprietary
> display drivers, neither of which we will support in Fedora for
> obvious reasons.
Do you think that
Yes, I'm watching it already. Time will tell, there's been a lot of
false starts and it took etnaviv years to be usable. It's also only of
use for the 400 series as the newer GPUs are completely different.
Someone might want to look at it, will probably need work around
libglvnd to co-exist with mesa similar to that of the nvidia binary. I
also hear it'll never support Wayland. If someone was interested in
getting it working and into rpmfusion I'm sure a lot of people would
appreciate it but personally I have no interest (or time) to do
anything around this.
> > Upon boot I see U-Boot (?) output and EFI lines and then row
> > and initial boot messages but then my TV goes blank. At no point during
> > the boot (like grub interface) do I have USB (mouse, keyboard) working.
> There is no display support  for the A64 SoC as yet, you'll need to
> use a serial console.
> There might be simple FB support landing in the 4.16 kernel so if that
> support does land there will be basic text output support in Fedora
OK. Out of curiosity, the boot messages that I can see at the early
boot stage of Fedora 27 get output via what mechanism?
Probably the simple framebuffer that's in u-boot until the kernel
re-initialises some bit of hardware but that's a guess, I personally
have never bothered to plug my Pine64 devices into a HDMI port and run
them using serial console.
> > I see wired networking and DHCP working. Upgrading kernel
seems to break
> > the wired networking
> > https://bugzilla.redhat.com/show_bug.cgi?id=1528593
> You should add the ARMTracker tracking bug so we'e aware of ARM
> related kernel bugs.
WILCO (will try to not forget ;-) next time.
> I'm aware of the breakage but I took some PTO and given the NIC
> drivers for the 64 bit AllWinner stuff was pulled back I've not had
> time to fix it. I'm sorry (I'm really not) but you can either stick on
> the 4.13 kernels until I get time to fix it or go to the 4.15rc6
> kernel  which is known to work.
I'll try it when I get some cycles to focus on it again, thanks for
> > but with all the other packages from updates upgraded, the board still
> > works including wired networking and DHCP.
> > The initial-setup.service seems to be looping during the boot and it
> > seems to also affect dnf operations so I've disabled it.
> If it's run properly from the serial console on the first boot it will
> disable itself.
Does it make sense to track the fact that on console-less machine, we
might want it to fail more gracefully?
Maybe, someone needs to have the time to implement it or at least
engage with the initial-setup developers and convince them it's worthy
of their time. At least for the vast majoriity of the newer allwinner
devices this will hopefully not be a problem with F-28/4.16 as we
should have simple console output so they'll be able to run text based
> > Specifically missing at this point seems to be USB support,
> > after boot, and WiFi networking. Is there anything which might be useful
> Have you looked at the upstream mailing lists to see if there's kernel
> patches? As far as I can see, at least on linus's master, usb should
> work (it definitely does on the various Pine64 variants) and wifi
> might work if you have the appropriate brcm*.txt text file in
> /lib/firmware/brcm/ (like what's needed on the RPi3). A grep through
> dmesg for brcm should show more details there. I've not checked
> anything older than linus's current head WRT to either of those.
I'll put this to the list of things to check.
Reply here when you have more details.