chwe Posted February 10, 2020 Posted February 10, 2020 small update: it looks like this is mostly a kernel not kernel-config issue, using tobias kernel (v5.5) for majaro with our kernelconfig without any patches and the pinebook shows display output in mainline.. Either we patch something needed not into the kernel, or we patch something needed out... Note, I currently use a slightly adjusted boot.cmd but I tested this one before and with our current kernel it doesn't do the trick.
belfastraven Posted February 11, 2020 Posted February 11, 2020 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 1
chwe Posted February 11, 2020 Posted February 11, 2020 1 hour ago, belfastraven said: I believe you may need all three of these patches. check the PR, they are all already in...
belfastraven Posted February 11, 2020 Posted February 11, 2020 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...
chwe Posted February 12, 2020 Posted February 12, 2020 https://github.com/armbian/build/pull/1759/files#diff-309b3186e3060abd0485d767eefb324eR431 force-hpd just tells the display driver (panel simple) which pin is used for hotplug dedtection which is obviously not implemented in the pinebook (you can't remove the edp) and therefore likely also needed in 5.5. 21 hours ago, belfastraven said: I don't see that line in the current 5.5 dts there you go: https://gitlab.manjaro.org/tsys/linux-pinebook-pro/blob/v5.5/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts#L445 at least display timings landed in mainline 3 days ago... The pinebook dts itslef didn't. 21 hours ago, belfastraven said: 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... add my repo as remote: https://github.com/chwe17/build/tree/rk3399_pinebook pull the pinebook branch and update boot.cmd (config->bootscripts->boot-rockchip64.cmd) with the one attached (cause I didn't push this upstream yet). And then build with ./compile.sh LIB_TAG=rk3399_pinebook boot-rockchip64.cmd
belfastraven Posted February 12, 2020 Posted February 12, 2020 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.....
GOrd Posted February 27, 2020 Posted February 27, 2020 I am guessing that this Armbian login is different from the Armbian login I've used. Or it was frozen or cancelled or pigs learned how to fly. I cloned cwhe's git tree, as my next step in learning about things. I'm a dinosaur (started with UNIX in 1984). I used a vagrant plugin that is not available in Debian (I run Devuan on most of my desktop type machines) to adjust the discsize of the Bionic 18.04 box to 60 GB. The "build" of the standard Armbian kernel picking Rock64 as the closest system went to completion. After cloning cwhe's git into a parallel directory, I let it build the tool chain (all the questions/options seemed the same), and then when menuconfig came up; there was nothing specific to pinebook (or pinebook pro). I saved the config and let it start compiling the kernel. It did not finish. There were errors about trying to save things into read only storage, and vagrant was completely locked. Vagrant halt in another terminal session didn't stop things (or didn't seem to). Vagrant -f halt seemed to work, a bit. A vagrant up would not work. Some lockfile was present? I found a vboxmanager command with the UUID of the box and --emergencystop which cleaned things up. On bringing this box up again, I looked for git tags. None seemed to be related to pinebook. Asking for a list of branches, only showed master. Trying to checkout pinebook said there was nothing (branch not valid)? It seems at some point, I need to "overlay?" the u-boot mainline on top of what Armbian has now? But basically, I am too much of a dinosaur; and lack 'fu' to do this modern CVS stuff. Could cwhe post a little more verbose instructions on how to get things to work? :-) My initial "need" is to get btrfs for home. I would like to get panfrost/MESA-(19|20) at some point. At some point, maybe play with mesh networking (I have a farm). Have a great day!
Igor Posted February 27, 2020 Posted February 27, 2020 3 hours ago, GOrd said: I'm a dinosaur (started with UNIX in 1984). This script was made by/for people that start Unix in 90" or later. Close enough A few tips: - use mainstream repository https://github.com/armbian/build at least for the 1st time. - https://github.com/armbian/build#build-parameter-examples First example is the key you are missing. PinebookPRO is in the CSC/WIP section. - support for Vagrant (method I never used) is not the best. I suggest native or Docker. 3 hours ago, GOrd said: It did not finish. There were errors In case you get into the troubles, supply logs (output/debug) here https://forum.armbian.com/forum/12-armbian-build-framework/ 3 hours ago, GOrd said: My initial "need" is to get btrfs for home. Booting from SD card, running nand-sata-install and installing to BTRFS should get you there. It is also possible to create SD card with ready made BTRFS or even with LUKS ... but not recommended for 1st time build. 3 hours ago, GOrd said: I would like to get panfrost/MESA-(19|20) at some point. At some point, maybe play with mesh networking (I have a farm). I don't know how good and how bug-free those features are but consider software support for Pinebook PRO as experimental, fragile ... but developing fast.
chwe Posted February 27, 2020 Posted February 27, 2020 for the vagrant stuff.. I've no idea, never cared about it.. The board is in WIP and you need to pull from the rk3399_pinebook branch (https://github.com/chwe17/build/tree/rk3399_pinebook). This branch is still some commits behind my local git and roughly 100 behind armbian master.. And it's mostly around mainline with the non working display which drives me nuts.. But maybe I take a shot with 5.5 or 5.6 were things may work.
chwe Posted February 28, 2020 Posted February 28, 2020 just as a side node. Tobias Schramms DT goes through peer review for mainline. https://lkml.org/lkml/2020/2/27/1762
martinayotte Posted February 28, 2020 Posted February 28, 2020 11 minutes ago, chwe said: just as a side node. Interesting ... Hoping there is no other secret sauce such as defconfig ... I will give a try this over the weekend !
chwe Posted February 28, 2020 Posted February 28, 2020 well our DT in https://github.com/armbian/build/pull/1759 is based on his DT anyway.. 6 minutes ago, martinayotte said: Interesting ... Hoping there is no other secret sauce such as defconfig ... at least with his kernel, our special sauce config did show the display as well.. see https://github.com/armbian/build/pull/1759/commits/a3317c3f665f794e5a8467296ee095898761d78e followed by its revert. So either our special sauce in patches or our mainline kernel which is mainline for rk3399 did not work out properly.. I don't think it's the patches cause I didn't spot something obvious here. So I guess it's the kernel. and yes.. we do add the timings for the display on top of 5.4 https://github.com/armbian/build/pull/1759/commits/d4b5bb9cf41d4b454dbf02d4caa2d453b390937d#diff-309b3186e3060abd0485d767eefb324eR1232-R1290 https://github.com/armbian/build/blob/d4b5bb9cf41d4b454dbf02d4caa2d453b390937d/config/kernel/linux-rockchip64-current.config#L4466 the later as module in the PR... I pushed my 'last' changes in the PR just for the reference.. (https://github.com/armbian/build/pull/1759/commits/a3317c3f665f794e5a8467296ee095898761d78e) gave us the working display with our kernelconfig.
belfastraven Posted February 28, 2020 Posted February 28, 2020 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....
chwe Posted February 28, 2020 Posted February 28, 2020 well even if 5.6 fixes the display.. we've to identify what changed between 5.4 and 5.6 to backport it and get display working in 5.4. As a personal opinion current should stick to a LTS kernel for the sake of maintenance, to keep the workload lower. Fixing all the broken patches with a subversion (e.g. 5.4 to 5.5) bump soaks up a lot energy. So having at least one mainline based kernel which doesn't need that much attention would be nice to keep the stress level at an acceptable level. Additionally we've to deal with the fact that @ayufan took a step back from rockchip kernel maintenance with his fork of rockchips bsp kernel which might not be the biggest deal for rk3399 but newer SoCs (e.g. rk1808 and rk 3308) and boards based on them e.g. SoEdge from pine and RockPi S will be affected by this. In case we officially start to support those I expect quite some work on BSP kernel again.. And the pbp has a camera which nobody ever has attempted to bring up either in mainline or BSP.. It seems developers are fully confident without having a working camera no their notebooks.. On the bright side.. at least rockchip kernelwork won't get boring in the next months..
GOrd Posted March 17, 2020 Posted March 17, 2020 I tried to figure out what to do, without coming back here. I eventually got a build. Trying to see if there are updates to cwhe17's tree bring no joy. All I get from git, is I have no idea what you are talking about. My guess is that I am missing some config file variable, or some environment variable. But as mentioned below, spring is coming and I don't have time to try things. Instructions as to how to proceed past that point, are lacking. It seems that output/images (or something like that) contains an image. (and some txt file about this). Everybody and their dog talks about how perfect etcher is. I'm sorry, I disagree. If you run etcher as some non-root user - you get some error message which makes no sense, and doesn't point to the actual problem being that you need to be root to run this program. Why can't etcher look to see if it has permissions, before doing things (and generating this stupid error message?) Fine wrap etcher in sudo, and it works. Supposedly no mistakes. I boot the microSD, and no display. I plug in ethernet, and do it again, hoping that maybe there is a SSH login. NMAP can't find this host on my LAN, so if the kernel starts, it doesn't get to the point where the NIC is configured. I don't have a serial cable to see if there is boot messages to serial. I would love to work on this more, but spring is approaching. (I live on a farm.) If someone has a pointer to an image which might allow btrfs and lets the display work; that would be wonderful. I could then try to update various other hardware. If I get a rainy day, I could drop my btrfs desire to ext4. My ptp device needs an upgrade. My router is too out of date, and so it is to be replaced by a new device. But surely I can configure this device from something like a laptop before I switch wires? :-) It may be that I need to wait until next winter, to find time to pursue upgrades. Thanks to all, even if I am too stupid to figure out what to do.
martinayotte Posted March 17, 2020 Posted March 17, 2020 11 hours ago, GOrd said: I don't have a serial cable to see if there is boot messages to serial. That is a MUST if you wish to help figured out why your PBP doesn't boot. BTW, no one here got an Armbian image working with the LCD display yet ! We still have to figure out why, but it will take time ... 1
chwe Posted March 19, 2020 Posted March 19, 2020 with the newest pushed to my PR: https://github.com/armbian/build/pull/1759#issuecomment-601162767 dev images with a working display can be built, the display is currently rather dark (I guess we've to tweak the defaults from the pwm driver a bit I had it brighter in mind when using the stock OS).. The mouse is somehow bugged so an external mouse is needed and you need to build with extrawifi=no cause they didn't survive moving dev to 5.6 For those waiting for prebuilt images based on 5.6 this ain't gonna happen yet. it's simply not ready yet to deal with debug and users at the same time. And the PR involves to move pinebook to rk3399 with upstream u-boot but this goes in hand with a change in the bsp kernel (from ayufan to friendly arm) and guess what.. the display does not work there.. but mainline with 5.6-rc6 will work. The PR needs a lot of review tho.. for those wanna see a lot of errors in dmesg http://ix.io/2eGz so to summarize: display works wifi works keyboard works desktop works touchpad doesn't everything else was not tested (ah and restart doesn't work neither atm). PR needs quite some review work and testing for other boards cause.. well we all know what happens when we switch a kernel right? 1
belfastraven Posted March 20, 2020 Posted March 20, 2020 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).
belfastraven Posted March 23, 2020 Posted March 23, 2020 @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?
chwe Posted March 23, 2020 Posted March 23, 2020 20 hours ago, belfastraven said: 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. likely due to some non mandatory stuff from tobias tree patched in.. usb dp altmode is currently a non issue at all for me, except it floats dmesg. tobias had a few patches for HID stuff in his tree which I didn't patch into cause I didn't expect them to be of importance.. Maybe I've a second look into that the next days.. HID leftovers I didn't patch in.. diff --git a/drivers/hid/hid-google-hammer.c b/drivers/hid/hid-google-hammer.c index 85a054f1ce38..2aa4ed157aec 100644 --- a/drivers/hid/hid-google-hammer.c +++ b/drivers/hid/hid-google-hammer.c @@ -532,8 +532,6 @@ static const struct hid_device_id hammer_devices[] = { USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_MAGNEMITE) }, { HID_DEVICE(BUS_USB, HID_GROUP_GENERIC, USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_MASTERBALL) }, - { HID_DEVICE(BUS_USB, HID_GROUP_GENERIC, - USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_MOONBALL) }, { HID_DEVICE(BUS_USB, HID_GROUP_GENERIC, USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_STAFF) }, { HID_DEVICE(BUS_USB, HID_GROUP_GENERIC, diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h index 9f2213426556..3a400ce603c4 100644 --- a/drivers/hid/hid-ids.h +++ b/drivers/hid/hid-ids.h @@ -478,7 +478,6 @@ #define USB_DEVICE_ID_GOOGLE_WHISKERS 0x5030 #define USB_DEVICE_ID_GOOGLE_MASTERBALL 0x503c #define USB_DEVICE_ID_GOOGLE_MAGNEMITE 0x503d -#define USB_DEVICE_ID_GOOGLE_MOONBALL 0x5044 #define USB_VENDOR_ID_GOTOP 0x08f2 #define USB_DEVICE_ID_SUPER_Q2 0x007f @@ -727,7 +726,6 @@ #define USB_DEVICE_ID_LENOVO_X1_COVER 0x6085 #define USB_DEVICE_ID_LENOVO_X1_TAB 0x60a3 #define USB_DEVICE_ID_LENOVO_X1_TAB3 0x60b5 -#define USB_DEVICE_ID_LENOVO_PIXART_USB_MOUSE_608D 0x608d #define USB_VENDOR_ID_LG 0x1fd2 #define USB_DEVICE_ID_LG_MULTITOUCH 0x0064 diff --git a/drivers/hid/hid-picolcd_fb.c b/drivers/hid/hid-picolcd_fb.c index 33c102a60992..a549c42e8c90 100644 --- a/drivers/hid/hid-picolcd_fb.c +++ b/drivers/hid/hid-picolcd_fb.c @@ -458,9 +458,9 @@ static ssize_t picolcd_fb_update_rate_show(struct device *dev, if (ret >= PAGE_SIZE) break; else if (i == fb_update_rate) - ret += scnprintf(buf+ret, PAGE_SIZE-ret, "[%u] ", i); + ret += snprintf(buf+ret, PAGE_SIZE-ret, "[%u] ", i); else - ret += scnprintf(buf+ret, PAGE_SIZE-ret, "%u ", i); + ret += snprintf(buf+ret, PAGE_SIZE-ret, "%u ", i); if (ret > 0) buf[min(ret, (size_t)PAGE_SIZE)-1] = '\n'; return ret; diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c index 3735546bb524..0e7b2d998395 100644 --- a/drivers/hid/hid-quirks.c +++ b/drivers/hid/hid-quirks.c @@ -103,7 +103,6 @@ static const struct hid_device_id hid_quirks[] = { { HID_USB_DEVICE(USB_VENDOR_ID_KYE, USB_DEVICE_ID_KYE_PENSKETCH_M912), HID_QUIRK_MULTI_INPUT }, { HID_USB_DEVICE(USB_VENDOR_ID_KYE, USB_DEVICE_ID_KYE_EASYPEN_M406XE), HID_QUIRK_MULTI_INPUT }, { HID_USB_DEVICE(USB_VENDOR_ID_KYE, USB_DEVICE_ID_PIXART_USB_OPTICAL_MOUSE_ID2), HID_QUIRK_ALWAYS_POLL }, - { HID_USB_DEVICE(USB_VENDOR_ID_LENOVO, USB_DEVICE_ID_LENOVO_PIXART_USB_MOUSE_608D), HID_QUIRK_ALWAYS_POLL }, { HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_C007), HID_QUIRK_ALWAYS_POLL }, { HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_C077), HID_QUIRK_ALWAYS_POLL }, { HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_KEYBOARD_G710_PLUS), HID_QUIRK_NOGET }, diff --git a/drivers/hid/hid-sensor-custom.c b/drivers/hid/hid-sensor-custom.c index 4d25577a8573..fb827c295842 100644 --- a/drivers/hid/hid-sensor-custom.c +++ b/drivers/hid/hid-sensor-custom.c @@ -313,7 +313,7 @@ static ssize_t show_value(struct device *dev, struct device_attribute *attr, while (i < ret) { if (i + attribute->size > ret) { - len += scnprintf(&buf[len], + len += snprintf(&buf[len], PAGE_SIZE - len, "%d ", values[i]); break; @@ -336,10 +336,10 @@ static ssize_t show_value(struct device *dev, struct device_attribute *attr, ++i; break; } - len += scnprintf(&buf[len], PAGE_SIZE - len, + len += snprintf(&buf[len], PAGE_SIZE - len, "%lld ", value); } - len += scnprintf(&buf[len], PAGE_SIZE - len, "\n"); + len += snprintf(&buf[len], PAGE_SIZE - len, "\n"); return len; } else if (input) who knows..
lanefu Posted September 17, 2020 Posted September 17, 2020 Just an FYI... I've picked things up on the Pinebook Pro a bit... tracking here... https://armbian.atlassian.net/browse/AR-399 Thanks @chwe and everyone else that have done the hard parts.
lanefu Posted September 17, 2020 Posted September 17, 2020 Also who will be willing to assist with Testing PBP images?
martinayotte Posted September 17, 2020 Posted September 17, 2020 7 minutes ago, lanefu said: Also who will be willing to assist with Testing PBP images? I can do sporadic testing ...
TonyMac32 Posted September 17, 2020 Posted September 17, 2020 I can. Sent from my Pixel using Tapatalk
belfastraven Posted September 17, 2020 Posted September 17, 2020 I can test, too. I have been running with (currently) an armbian dev build with 5.8.9 kernel on focal with a gnome desktop and pcm720's uboot on spi flash, botting an nvme. The only strangeness that I have been running across is that if I boot off of an SD card, rebooting without shutting down seems to boot the NVME. I haven't spent much time investigating, though--I was just so excited to be using armbian builds again..:-) 1
lanefu Posted September 18, 2020 Posted September 18, 2020 Okay here's my best image so far https://armbian.lane-fu.com/Armbian_20.11.0-trunk-fridaytest_Pinebook-pro_bullseye_current_5.8.10_desktop.img.xz * brightness keys * battery status * touchpad tweaks * bluetooth,wifi issues: * noise in dmesg from i2s * no splash screen * sound needs manual ALSA mixer tweaks to enable I think the schedutil cpu governor works best. but that's just my unscientific opinion 1
Igor Posted September 19, 2020 Posted September 19, 2020 7 minutes ago, lanefu said: Did you happen to pull from my wip branch? There's like a thing or 2 I wanna get in there before we roll out Ooops No. Ah, but its probably much better than a current build? Currently I am working on to optimize this upgrade process so another build next week or so will not be a problem.
lanefu Posted September 19, 2020 Posted September 19, 2020 2 hours ago, Igor said: Ooops No. Ah, but its probably much better than a current build? Currently I am working on to optimize this upgrade process so another build next week or so will not be a problem. HA yes its much better.... anyway just got to get rid of this error.. with sound working, it really floods logs.. once that's fixed I feel good about merging in for WIP [ 400.823396] rockchip-i2s ff890000.i2s: Fail to set mclk -22 [ 400.824001] rockchip-i2s ff890000.i2s: ASoC: error at snd_soc_dai_set_sysclk on ff890000.i2s: -22 boot splash is broken tho.... need to get that working or at least u-boot image... otherwise people are just going to think its broken when their computer takes 2 minutes to show something on screen
Igor Posted September 19, 2020 Posted September 19, 2020 4 minutes ago, lanefu said: boot splash is broken tho Black screen or logo? Both case is not so good for 1st boot since it takes longer due to resizing.
lanefu Posted September 23, 2020 Posted September 23, 2020 alright merged in https://github.com/armbian/build/pull/2208 WARNING: I don't recommend flashing to emmc yet, just use sdcard. May not be able to boot from SD after nand-sata-install quirks boot can take a while sometimes an orange light is on.. then green then go.. I feel like there' s some u-boot stuff going on. this didnt happen when manjaro firmware was on emmc and i booted from sdcard screen will be dark for a while don't freak out after EMMC install can't boot from sdcard haven't tested headphone jack Ive been using bullseye rather than focal... but focal works. the lack of screen overlay for pressing volume keys is a xfce4 theme issue of some sort. it worked when I used the non-armbian xfce sleep config is delegated to xfce4, rather than logind X may not recover on long sleeps stuff that works bluetooth wifi volume keys brightness suspend via s2idle (non-hardware sleep mode better than nothing) mpv plays video nicely.
Recommended Posts