Jump to content

Pinebook Pro

WZ9V

By WZ9V
in Pinebook Pro

 Share

Recommended Posts

chwe

chwe

Posted
Posted

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... :lol: 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.

Link to comment
Share on other sites
belfastraven

belfastraven

Posted
Posted

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
Link to comment
Share on other sites
belfastraven

belfastraven

Posted
Posted

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...  

 

Link to comment
Share on other sites
chwe

chwe

Posted
Posted

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

Link to comment
Share on other sites
belfastraven

belfastraven

Posted
Posted

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.....  

Link to comment
Share on other sites
GOrd

GOrd

Posted
Posted

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!

 

Link to comment
Share on other sites
Igor

Igor

Posted
Posted
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 :D

 

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.

Link to comment
Share on other sites
chwe

chwe

Posted
Posted

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.

 

 

 

 

Link to comment
Share on other sites
chwe

chwe

Posted
Posted

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. :)

Link to comment
Share on other sites
belfastraven

belfastraven

Posted
Posted

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....  

 

 

Link to comment
Share on other sites
chwe

chwe

Posted
Posted

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.. :rolleyes::lol: It seems developers are fully confident without having a working camera no their notebooks.. :rolleyes::ph34r:

 

On the bright side.. at least rockchip kernelwork won't get boring in the next months..  :lol::ph34r:

 

 

 

 

Link to comment
Share on other sites
GOrd

GOrd

Posted
Posted

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.

 

Link to comment
Share on other sites
martinayotte

martinayotte

Posted
Posted
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
Link to comment
Share on other sites
chwe

chwe

Posted
Posted

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.. :lol:

 

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? :lol:

1
Link to comment
Share on other sites
belfastraven

belfastraven

Posted
Posted

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).

 

 

 

Link to comment
Share on other sites
belfastraven

belfastraven

Posted
Posted

@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?

 

Link to comment
Share on other sites
chwe

chwe

Posted
Posted
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..

Link to comment
Share on other sites
belfastraven

belfastraven

Posted
Posted

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
Link to comment
Share on other sites
lanefu

lanefu

Posted
Posted

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
Link to comment
Share on other sites
Igor

Igor

Posted
Posted
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.

Link to comment
Share on other sites
lanefu

lanefu

Posted
Posted
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

Link to comment
Share on other sites
lanefu

lanefu

Posted
Posted

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.
Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept