belfastraven

@chwe I think armbian firmware needs to have rockchip/dptx.bin which is in the linux-firmware-git now. That would get rid of a few dmesg messages. It is necessary for dp over USB c, I believe. Also, I note these entry from the Xorg.0.log re touchpad: (there are others like these): bodling is mine 12.222] (II) event4 - HAILUCK CO.,LTD USB KEYBOARD Touchpad: is tagged by udev as: Touchscreen. and 112.184] (II) config/udev: Adding input device HAILUCK CO.,LTD USB KEYBOARD Touchpad (/dev/input/event4) [ 112.184] (**) HAILUCK CO.,LTD USB KEYBOARD Touchpad: Applying InputClass "libinput touchscreen catchall" In the Manjaro build the touchpad is recognized as a touchpad and the Input class is "libinput touchpad catchall". I tried building with the manjaro kernel, but still using the linux-rock64dev.config and the same thing happened. I have tried with ubuntu bionic and focal desktops--because I originally though it was a userland problem. Would some touchscreen driver that was compiled in somehow be causing problems? I will try to figure out how to get a udev log from boot and see why udev is assigning this as a touchscreen. Anybody have any ideas about this?

Great! If you put the brightness to maximum before trying to run this, you shouldn't have a problem. People have been noting the initial dimness on the Manjaro arm forums and in the Pine64 forum. Note that it comes up with US keyboard. If you have an ISO keyboard, you may want to change the mapping. Although in the Manjaro build, one sees all of the Hailuck keyboard definitions twice (in dmesg). but the touchpad does work.... Here we see them 4 times. I am looking to see if I can figure out what is actually controlling them. I've seen in the past where the synaptics driver, for example, and libinput will interfere with one another. I was testing with focal, by the way, and having a problem that it seems to take the login information, and then blanks the screen and brings back the login screen. Bringing up the console, logging in there and then using "startx" brings up the desktop with no problem. Haven't had time to explore further. I have not been able to get the display to come up with the 54.y kernel. I think this has something to do with the drm bridge analogix driver and the rockchip drm software, but every time I try to patch something something else breaks. (I am not very good at this, I think) I did note from the Pine64 forum that the future deliveries of the laptop are coming with the Manjaro build installed. so maybe for this particular device there is less of a reason to maintain the older builds? (Since it is still WIP here).

I noticed two other recent Rockchip drm changes in Patchwork 1-1-drm-rockchip-fix-integer-type-used-for-storing-dp-data-rate-and-lane-count 37-51-drm-rockchip-Drop-explicit-drm_mode_config_cleanup-call but have not had a chance to see if either or both of those enabled booting without using the manjaro kernel, but with the patches already identified. The first is another tsys patch. At least we no longer have to disable sound to use the serial console:-) I'm going to try building with the v5.6 branch this weekend....

Ok. Thanks, will do. I keep checking mainline for the dts etc, too. There have been several changes in the manjaro repo , also, re suspense (S3) , etc, in the last couple of days. I hope by 5.7 things will have settled a bit!. I've been running with mainline u-boot and kernel and gnome on Wayland, and it really is a nice device. I am more e comfortable in the Debian world, though, so will be happy to get a mainline armbian build going... We also need the dts(s) in u-boot,as well.....

Oh sorry--I still didn't see force-hpd in the eDp panel defs there. If you look at the closed issues on the Schramm kenel, there was an indication that that had fixed the display problem for users who were not getting the display (I was one of those). I don't see that line in the current 5.5 dts, but If you are still building with 5.4.y, perhaps it is still necessary. I am sure I am dating myself here, but I feel as if I am playing "Adventure" : "YOU ARE IN A MAZE OF TWISTY LITTLE PASSAGES, ALL ALIKE" I'm not very good with the current build system. Are you putting your patches in userpatches and building for the Rockchip64 or RK3399 with "current". Probably I could help more if I coulde figure out how to build with the changes...

Check out the attached screenshots of commits. I believe you may need all three of these patches. One is modifying the simple panel driver to include our specific panel, one changes timing , one is to force recognition of the panel, I believe. I sent the screenshots becuase I couldn't figure out how to get the patches off of gitlab, but I imagine you will know how to do that. There have been many patches over the past 3 months, but I think these are the ones that enabled the display. There are more for bluetooth, wifi, sound, usb-c , etc. WE now have a mainline u-boot that will, when flashed to SPI , boot an NVME. If you get a build that displays , I'd like to try to get it to boot with the new u-boot. My poblem right now is that everytime I start making build system changes --I tend to get a headache . I did much better with the older ( from a few months ago) build system. The problem is me, of course, not the build system. At least serial is working well now.Schramm_panel_commits.zip

@chwe, Try this (on manjaro pinebook-pro dts) to get sound and uart: I think I got it from mrfixit2001, if not it was ayufan.... This now works for me-- just giving "patch" form so you can see where the changes are.... -- 5.5.rk3399-pinebook-pro.dts 2020-02-05 11:06:24.354098350 -0500 +++ my.v5.5-rc7-panfrost-fixes.rk3399-pinebook-pro.dts 2020-02-05 10:58:51.545953609 - @@ -197,10 +197,12 @@ simple-audio-card,cpu { sound-dai = <&i2s1>; + system-clock-frequency = <12288000>; }; simple-audio-card,codec { sound-dai = <&es8316>; + system-clock-frequency = <12288000>; }; }; @@ -838,7 +840,7 @@ status = "okay"; bt656-supply = <&vcc1v8_dvp>; - audio-supply = <&vcca1v8_codec>; + audio-supply = <&vcca3v0_codec>; sdmmc-supply = <&vcc_sdio>; gpio1830-supply = <&vcc_3v0>; };

@chwe--I just found this in @ayufan's repository: https://github.com/ayufan-rock64/linux-kernel/commit/afadea9477b7df1daae04389f8f1fa0f9b041c5c" " stdout-path = "serial2:1500000n8"; // disable stdout-path as it causes instability due // to sound card power leak //stdout-path = "serial2:1500000n8"; " The Manjaro boot args don't include stdout-path, or earlycon=uart8250 but do include console=ttys2. Maybe if I get brave, after dinner I will try removing that from the boot arguments.... The current Manjaro boot.txt doesn't show any video argument BTW. Maybe something in the config or dts? I will try to look after I check the sound stuff.

@chwe--I saw your comment on the issue I sent to Manjaro. I'm just curious: kernel output on the laptop screen is working fine on the Manjaro build. Are you referring to the u-boot output?. BTW. they are using this u-boot https://git.eno.space/pbp-uboot.git...which now has a branch for NVME booting, I believe.... .

Currently ,Manjaro is using a mainlineu-boot build (20.1 with pretty current atf) that was initially developed by someone else: see here https://eno.space/blog/2020/01/pbp-uboot. That is what I am currently running. Since it is now possible to mainline boot from NVME (with SPI flash) on the rockpro64 , I hope we can get that going for this device also. It seems like mainline u-boot now uses the normal device DTS with some u-boot additions. I'm a novice at this and don't understand exactly what differences are need for u-boot. I thought when I initially used the device with the default build (mtfixsit2001) I did not get any sound when the serial console switch was thrown. ON manjaro, I would get sound ... which surprised me. .. i will try to notifiy Tobias Schramm.

I just disabled the es8316-sound node , and am now getting normal output over serial from the kernel. Thanks for that info @martinayotte .

The serial cable i got from Pine always worked for me in u-boot (some of the distros seem to disable serial output in the kernel, or have it mis-configured) I did not have the problems some people have mentioned. The cable was not very well put together, however, and was too short for my comfortable use. I got one of these EZsync.021, it was pricey, but much more substantially made with a 1.8 meter cable. I will try to build first by using the Manjaro kerne lsource for mainline (since I already know that that runs well) and mainline u-boot (cuurent--20.1)with ATF (master--some changes were made in December which fix some power issues on the rk3399 chip) . If I can get that going, I'll see what patches need to be generated for vanilla mainline build. I believe some of the changes have been submitted already for inclusion in mainline. The rockpro64 is running fine for me on the "current" kernel with an experimental current uboot that will boot (from SPI ) the NVME. I believe much of the work for the pinebook has actually been done, it's a matter of getting into the build system. In general, I am very happy with the notebook. In some areas, though, I don't think the build quality was great. Using tiny m2 screws for the bottom, having an sd card reader into which it is difficult to insert the card (and which will shoot the card across the room if you are not careful while removing it) and sending an NVME adapter which actually can't be used as is with a 2280 size NVME (I had to take a hacksaw to mine) sometimes make usage difficult , especially for people like me with not great manual dexterity.

You might want to use the dts from Toobias Schramm's Manjaro source Most things are working very well. Someone else has built a mainline u-boot which can be run from Spi flash (but doesn't support NVME boot yet--an earlier version based on Rockchip does.) Manjaro for Pinebookpro is now running with 5.5 rc-something kernl, The only thing that I have found not to work is suspend, which people are still trying to make work on mainline. Check the Pine64 forum for more info. I had started to try to test an armbian build, but it takes me forever to figure out the scripts. I think mainline uboot with mainline kernel is a good way to go... If any one needs any testing/test building let me know.

Kurt, I'm not exactly sure whether this answers your question, but to summarize: I built using the default branches from github.com/u-boot/u-boot (master) https://github.com/ARM-software/arm-trusted-firmware (master), altthough you could use the tag 20.01 for u-boot . I used master for atf becuase there have been changes for the rk3399 in the last month or so. You need to build atf bl31.elf first : make PLAT=rk3399 bl31 and copy the bl31.elf into the u-boot directory then make rk3399-nanopc-t4_defconfig make ARCH=arm (-j 7 woorks well for me building on my rockpro64) then write to sd card on which you have written the armbian image (input files are in u-boot directory)uboot.ig dd if=idbloader of=/dev/(however your sd is defined) seek=64 conv=fsync dd if=u-boot.itb of=/dev/(however your sd is defined) seek=16384 this generates a bootable sd card. you can use armbian-config to keep file system on your ssd. You may be able to boot from the ssd, but I can't tell you if that is possible with your device. (What the u-boot mentioned in the first post of this topic does is enable use to boot from an pcie NVME device using the SPI flash, which is a bit different. ) when you mentioned "I get nothing on the console"--I hope you mean the serial console. It is very difficult to debug u-boot without using it.... If this is not clear, let me know.

See https://forum.pine64.org/showthread.php?tid=8685 Using his SPI flash image, and then using armbian-config flash from SPi/system on NVME option worked. I had commented out the set the uboot partition section to what is started booting from lines in boot cmd to do the initial testing. I have been booting mainline for a while on this device. It boots much faster, and two or three weeks agoTobias Schramms atf patch made into mainline atf so the device no longer hangs on a soft reboot. I have booted from sd, emmc and the NVME with this u-boot. I haven't tried usb3 or usb2.

I believe the problem with the dts definition which I found a year ago was fixed by Ayufan for his mainline builds, but still exists in the official repo. My rock64 is not available for me to test right now. Perhaps someone else could take a look? https://forum.armbian.com/topic/9413-make-419-kernel-available-again-for-rock64/?do=findComment&comment=70578

I'm not sure exactly how you got to the point of this failure, which I think is some kind of "key" problem, but to test, I just deleted my armbian-builder box, and the build directory, recloned the build directory .i.e. git clone --depth 1 https://github.com/armbian/build cd 'd into build i.e. cd build and ran ./compile.sh vagrant This worked; it created the box and downloaded all the compilers properly... It seems that the "new" compile.sh from about three weeks ago actually does a lot more for one than the old methodolgy. (I believe it will even install vagrant and virtualbox if they are not there) You will be given the option to halt the box when your particular compile is finished. I think you can then get back into it by issuing the vagrant up vagrant ssh command s from the /build/userpatches directory. I'd be happy to change the doc to match what is actually going on if I understood whether I have a correct understanding of things, myself. :-)

On further investigation, it looks like changes to ./compile.sh from a couple of weeks ago will look for a vagrant installation if vagrant is specified as the first parameters to compile.sh in the build directory and try to install it (and virtualbox) if it is not installed. Since it IS already installed on my machine, vagrant was brought up and the compilation proceded successfully (I build PineH64 with Dev kernel, desktop, buster) and then end by telling one to hit enter to halt the vagrant box, but would allow no further communication with the vagrant box. (I.e., I didn't want to halt it, I wanted to use it again) The way the build worked before, once the virtual box was up and one ssh'ed into it, one could do multiple compilations, logout and ssh back in, etc. I cannot figure out how to do that now. I would be happy to submit documentation changes if I could understand how this is all supposed to work, now. I know I ran into other changes on the parameters for building a few weeks earlier too. Id also be happy to test proposed build changes and match them to the documentation if that would help...

@Igor, @mother, I normally build with Vagrant, and things were working fine three weeks ago. I realize that the changes that were made two weeks ago moved some files that used to be in the "build" directory to have been moved to the "build/config/templates" directory. That is , for example, where the Vagrantfile is now. I just tried going to that directory and entering Vagrant up Vagrant ssh cd armbian ./compile.sh and the build has definitely started I am not sure whether this was the intent, that is, to have people build from the build/config/templates directory. Butdoing this right now this might solve Mother's initial issues. It looks to me like a lot of the changes made were actually for Docker, and I haven't yet had time to figure out whether the whole userpatches move has anything to do with Vagrant.

I'm running a 5.2 build (self-built using Armbian build system) on a RockPro64. I installed and used armbian-config to enable booting from SD with root on NVME. Other than adding the pcie_rockchip_host and phy_rockchip_pcie modules to the initifamfs-tool/modules file and updating initramfs, I made no major changes. Currently I'm running a disco desktop build just to play with it. The one thing I find curious (and which I also have seen before on Ayufan's images) is that it takes more that 30 seconds from getting the kernel starting message until the login prompt comes up I get no other messages on the serial interface during that time. Does anyone know why that is happening? Has anyone tried mainline u-boot for this recently? It seems that it now includes support for this board--I haven't tried it yet, myself.

Hi, I'm in Maine, (Spectrum ISP) and could reach http://apt.armbian.com/dists/stretch/stretch-desktop/binary-armhf/Packages through Chrome and also built (I don't have on of these, I was just doing this a a test...my current builds/patches are too messy) BOARD=nanopct3 BRANCH=next RELEASE=stretch BUILD_DESKTOP=yes KERNEL_ONLY=no KERNEL_CONFIGURE=no sucessfully with a Vagrant on Virtualbox build. That sure is a weird looking IP number on the " Network is unreachable message" ;-) Could this be a glitch from your ISP, or has it been happen consistently over hours or days? You'd think more poeple would run into it if it were on the apt.armbian.com end of things..

I am using the dev kernel, booting from SD and having linux root on the pcie nvme , and can confirm that rockpro64 2.1 boots fine. ( I had a problem before, though, with a rock64 v2.0 not booting which I found was fixed by reverting a couple of dts changes back to the previous kernel versions (in my case 4.19). Can you tell if the system is seeing the nvme disk.? If you boot and run linux-root from an SD card , will it boot? Can you then you mount the pcie nmve? Can you see if it boots if you use the DTB from the previous version? In which case you could try comparing the dts and dtsi files to see what might have changed... I notice ** File not found /boot/dtb/rockchip/overlay/rockchip-fixup.scr ** in your log. For me, the fixup script is getting applied. I've not run any of the earlier kernels, though, so I don't know what should happen for them. I, too, am booting from the SD card, with root on the pcie nvme. FWIW

If it helps anyone, I've been running succesfully with gigabit ethernet on eth0 using the dts and h6 dtsi from Icenowy's aosc-sunxi64-4.19-malimidgard-hack-2 branch and the armbian dev kernel . I force a stable mac_address by adding allow-hotplug eth0 iface eth0 inet dhcp hwaddress ether xx:xx:xx:xx:xx:xx (replace the xx's of course with a good address) in the /etc/network/interfaces file. I haven't yet been able to get spi-jedec-nor flashed to enable sdi boot, I get an error indicating that there is a mismatch between what is specified in the DTS vs the overlay, but I am booting off of an sd card with the file system on a usb connected ssd. I'm going to try to build with the mainline 5 kernel soon, to see If I can pick up the new graphics drivers... I believe version B of the device is supposed to be out soon...

As I noted earlier, I had problems with usb storage not being recognzed on a rock64 after update to the 4.20 kernel. In my case on a Rock64 v2.0 , I seemed to have fixed the problem by making the following changes which are reversions to the previous 4.19 dts values. vcc_host1_5v: vcc_otg_5v: vcc-host1-5v-regulator {############################# from 4.20, changed A2 back to D3 to make things work compatible = "regulator-fixed"; enable-active-high; gpio = <&gpio0 RK_PA2 GPIO_ACTIVE_HIGH>; usb2 { usb20_host_drv: usb20-host-drv { rockchip,pins = <0 RK_PA2 RK_FUNC_GPIO &pcfg_pull_none>;################# from 4.20, changed A2 back to D3 to make things work My board is version 2.0 This problem did not affect other usb devices, btw, just storage... I tried to check the specs but didn't see find anything for vcc_host1_5v , vcc_otg_5v or usb20_host_drv. I did find usb_otg_drv at A2..... I noted the aobe in the pine64rock64 forum, but have had no response their yet. I am now back to booting off of a ssd on USB3 and having a usb stick and mouse/mouse keyboard on the usb2 ports-- once again, this is on a Rock64 v2.0

Thanks everyone for checking on this. In my case, I have narrowed the problematic devices down to USB storage devices (all are USB3--don't have any 2's). I've tested with the samsung T1, a WD Passport HD, a Sandisk USB stick--in no cases are they recognized by the rock64 on 4.20 On a RockPro64 (3399) with the 4.20 kernel. they are all powered on and recognized when I plug them in. I notice that the uas module is not loaded on the rock64 I boot the device with one of those plugged in. I tried force loading it using initramfs, and it loads, but the device(s) is still not available. As I mentioned before, I was actually booting from the Samsung t1 on the 4.19 kernel. If any one want to see logs--I have a great number of them :-). If noone else is seeing this, though, I just keep trying to figure out what is broken. thanks again.