belfastraven

It looks like you are using the dts name from the kernel rather than u-boot. I believe for u-boot the dts name is something like arch/arm/dts/rk3399-rock-pi-4.dtsi -- it looks like there are a couple that might be the one you want--. The kernel dts files and u-boot dts files don't use the same paths .... You created a patch for the kernel, not u-boot.....

@Werner, I was perhaps not being clear enough in my suggestion. I don't have any experience with managing forum software, but was wondering if you could actually stop people from generating new topics in the bug system except by their using the bug reporting link. So If someone tires to create a new topic without going through the bug reporting link, they are directed to the community forum. or their post is automativally moved there. .... One could even add that that fact to the header.... It might actually come across as "friendlier" and probably would be less work for moderators, but, as I said, I don't know enough about the forum software to know if that is even possible...... Is Armbian still using the Invision Community software? IS the documentation for it available ? I'd be happy to look into further trying to automate things if it would help...

Would it perhaps help to add the link to the bug reporting form to the heading for "Bug tracker - supported boards and images only" e.g. "Bug tracker for supported boards and images only- please use the bug reporting form found here for your initial posting. " and if the form is not filled out, just move the post to the "community supported" forum. Might that not make it easier for @Werner to moderate? It would certainly be "friendlier". Saying "invalid" and telling people that they may have "refused" to do something comes across as sounding a bit hostile--I think perhaps this is somewhat of caused by having different ways of expressing things in different languages. I think it is sometimes difficult to understand where to ask a question i you are just trying to ask for help in figuring something out, rather than reporting a bug. FWIW.

@lukaszDid you try running glxinfo? I was just trying to indicate that there seems to be a difference in gnome settings in terms of what is reported for X rather than Wayland, but in both cases glxinfo shows panfrost as the extended renderer.

@lukasz are you running on X11 For me , using self built hirsute/gnome (as opposed to just downloading) , using gnome on Wayland shows proper " mali T860 (Panfrost)" where gnome on Xorg shows " unknown, but in in either case glxinfo extended renderer section shows panfrost is used. Perhaps there is a bug in the settings program? Desktop sort of works for me on my 4k monitor (usbc dock-hdmi connection--same as on other distributions--the geometry is wrong and that also effects the display on the pinebook itself, but it has worked that way on any distribution I have tried) Natural scrolling setting seems to work on Wayland...

@piter85, here's result of testing with official build, which uses 20.7, u-boot, I see: Bourd booted fine without all of those""Timeout poll on interrupt endpoint" spams, using nand-sata-install overwrote the spi_flash just fine ( as you can see :-) ) and without this error, which I imagine would have been fixed by your most recent patch anyway? Loading Environment from SPIFlash... Invalid bus 0 (err=-19) *** Warning - spi_flash_probe_bus_cs() failed, using default environment

I will test later today with an official image

@Piter75, Just FYI, Booting a a Samsumg pm980 nvme from spi_flash with your new 20.10 u-boot (from your rockchip64-u-boot-v2020.10 branch ) works most of the time. This is a build made from playing with the desktop stuff, hirsute with gnome... It normally works--every once in a while it seems to not get past Booting using the fdt blob at 0x1f00000 not sure what is causing that yet, or the constant : Timeout poll on interrupt endpoint I did manually clear previous spi_flash and used nand-sata-install to install the build and new spi flash. I've also noticed that when asked to update spi flash, it seems like the script will error if it doesn't find an spi_flash, but does not try to erase it if it has been written, andwill fail without any error message if a program already exists there... I apologize in advance if the spoiler is not hide-able--I can't seem to make that happen

@Igor, I am happy to help with documentation--I have been playing with the desktop branch (I'm now running hirsute with gnome on wayland on my pinebook pro--which I doubt you will be recommending to users, (but have tried various other combinations). I still don't understand whether this desktop/package flexibility is just for builders or will in someway available to people who would normally be downloading just images, or perhaps assembling pre-built images using native builds? Anyway, I am volunteering documentation assistance...

Re building different desktops: The capability to build various desktops through the build system is being worked on and tested now. From my initial look, it seems like many desktops including gnome, kde, cinnamon, lxde xfce and various others are being thought about for inclusion. I just started to try to play a bit with desktop (as opposed to master) branch of the github. Obviously, this is not released yet...

Hmmm if your Ctrl-Alt-F2 prints a #, I believe it is somehow using the us (or perhaps ANSI) keyboard layout. That is what all of my other keyboards show by default--the PBP is my only ISO keyboard device. I'm certainly not an expert on any of this. If you want to build groovy, I believe you need to used EXPERT=yes on the ./compile.sh command. I have done a dev build, which builds kernel 5.9(.1 right now) . I did a console rather than a desktop build so I could play with installing a different desktop. Groovy runs very well so far for me. I am booting the NVME from SPI flash. I installed an armbian uboot myself on on SPI flash ,, but I can see that armbian-config is being enabled to do that, too. Right now, I am running without sound, since I have the UART switch flipped, and am very much "over" removing 10 tiny screws every time I want to open the back. Someone on the Pine64 forum just posted that he had been able to use a spare internal uart and a micro usb-uart adapter to bring uart out without using the switch. I think THAT would be really advantageous:-)

When you speak about opening a terminal window, do you mean on the desktop? or do you mean opening a terminal console with CNTL-ALT-F(some-number). The mechanisms are different. For the CNTL-ALT-F(some-number) , if I set the /etc/default/keyboard file so that XDBMODEL="pc105" XDBLAYOUT="gb" XDBVARIANT="intl" I get the pound sign at shift-3. For the desktop console, it is controlled by whatever desktop manager you are using, I believe. So if in the desktop settings you have the pc105 UK keyboard selected, that should be working. If it works elsewhere on the desktop, but not in the desktop terminal--could it have something to do with the particular font or character set used for the terminal? just FYI I am using groovy with a cinnamon desktop, I have an ISO keyboard, and I can indeed display the GBP

Are you trying to build a kind of "kiosk" application? XFCE is a much less resource intensive desktop than gnome and it actually has a kiosk mode-- you also have the capability of controlling the color of the desktop and what appears on a panel: see here: https://docs.xfce.org/xfce/xfconf/start. I am excited about the project that @Igor has mentioned; for now, I tend to build a "server" version of software and then install a desktop on the running system. I imagine that would not work for you even if you used clonezilla or a like program to copy the configured image, since you may need different network parameters for each installation... but I thought I would mention it.

Given the gsettings you are running, I assume you are using a GNOME desktop? if so can you try, gsettings set org.gnome.desktop.background picture-options 'none' gsettings set org.gnome.desktop.background primary-color '#000000' Assuming that since you know the user and you are using autologin ( as that won't change the background for the display manager) that will set a black background. If this is e.g. an xfce, lxde , etc. desktop, that will not work. there are other gsettings keys that you can set to eliminate desktop icons, etc. Your best bet would be to google gsettings

If anyone wants instructions for updating on debian/ubuntu as well as arch see: latest keyboard updater  with instructions for debian and arch.. Also, I have been running the pcm720 u-boot that @lanefu mentioned since the end of July, since it allows me to boot my nvme. I have played a bit with trying to work the patches/versions into the build system, but haven't been successful as of yet. . See here for the source https://github.com/pcm720/u-boot-build-scripts. There is one atf patch (which we may already have) and 4 u-boot patches. It is using u-boot 20.07, and a reasonably recent atf. I am rather confused about in which confs/patch directories I need to make the changes for current and dev builds. Is it possible for someone more up on the build system to take a look?