chwe

well that's probably the problem of that page... It never got the attention it should. the guidlines are missing a few stuff.. e.g. that we refused to give an answer without providing 'armbianmonitor -u' and what the developer forum was ment to be (e.g. nobody ever cared but well.. now all SoCs are considered supported, so at least we can't blaim them for asking stuff anymore.. don't throw the sbc whisperers away.. it described it as best as we can..

not new.. happened before.. in all variants.. IMO you can't really track all of that and you shouldn't even try.. If the community is intact they'll report it for topics of interest.. and for the trash topics nobody reads.. we shouldn't care nor waste time with them... One thing tho to protect the users might be the discord approach.. e.g. if you click on a link it pops a warning as soon as you leave discord showing the whole link in a popup and you've to accept that you leave discord.. It's kinda annoying but on the same side you've been warned and then it's up to you to decide if you trust that page or not..

put 2 wifi dongles in cause xradio 819 on opi zero (if it's the original zero) is prob. the worst onboard wifi you can have prone to hang the kernel with it when it fails (I don't think that everybody ever took an effort to fix that)..

http://wiki.friendlyarm.com/wiki/images/5/59/SCH_NanoPi_R2S_V1.0-1912.pdf get pwm2 running and you should be done.. iirc it's not the first friendly arm board having this kind of fan control so there should be information here and there. If it is properly defined in the dt and from a first glance.. It doesn't look like it is that someone is already there long time ago and wrote the pwm fan kernel driver... https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/hwmon/pwm-fan.txt well you might need to pack this into a device tree overlay cause I'm sure not everyone wants an annoying fan on his board. it seems the whole thread is kinda focused on treating symptoms instead of figure out the root case for it. Obviously the board doesn't have much thermal mass due to it's size and I would assume that the USB3 to ethernet phy will also add some additional heat to the system (someone ever checked which other chips 'feel warm' and when - e.g. test if the issue relies when the USB GbE phy gets disabled). Next would IMO then be to test if we have to adjust THS settings for the board or maybe the max frequency we allow it to go (iirc we had this in the past for other boards that we didn't allow them to run at max clock-speeds for various reasons maybe this board is one of them too. I have a neo3 at home somewhere but didn't even boot it up yet (call me lazy). From a first glance the board looks nicely done but I kinda expected it to be a oven.. given the tiny little case I got with it. Maybe I've a look at it this weekend who knows... I have a

Thanks for telling. Much appreciated. @lanefu took care about already. Better stepping back than getting inactive and being kicked well the notification noise gets lower and I hope that I catch then the stuff which might be important better. I prob. missed quite some stuff due to the redicolous amount of notifications for threads to unlock.

so no more hiding for @TonyMac32 btw. didn't have @JMCC also mod rights? and speaking about mods, due to busy times I had to step back from the whole project for quite a while now... Things cleaned up a bit and I might find some time to do arm related linux stuff again but likely not as active as before and so I decided to only focus on stuff I enjoy and I'm interested in. honestly 'customer service' aka user complaining about random stuff doesn't work isn't something I enjoy anymore. So @Igor @Werner and @lanefu (or who ever is in charger for that now) feel free to revoke the mod status.

sd card and PSU issues was once thought to be a subforum where stuff gets moved to once we know it's a psu issue.. to point people at it in case they don't believe their shitty setup is the reason things don't go as expected.. kinda hall of ....

IMO as easy as it is.. as long as we've no proper mainline drivers for the VPU stuff and 4.4 allows us to build debian/ubuntu on top of 4.4 without affecting much. we can stick to it.. I assume rockchip will rebase their BSP on something newer in the future (even their most recent SoCs are integrated into 4.4, e.g rk1808 and rk1806) and I don't think they go EOS prior to 4.4 goes EOL. Btw.. all the camera stuff also is a 4.4 only thing at the moment.. and we've a bunch of boards with doublecam ect. now.. for sure something people might get interested in once it works.. So I guess the way to go is base rockchip64 and rk3399 on the same BSP kernel (this release), base both on the same patchset (maybe this maybe next) base all on upstream u-boot (next release - rochchip64 is based on the bsp u-boot) and then we can merge it.. I guess by compile the mali stuff as modules we might get around having Utgard (rk3328) and Midgard (rk3399) in the same kernel.. and otherwise.. we may just have 2 slightly different configs whatever works here.. Or prioritize rk3399 over rk3328 in terms of mali support (we clearly see that more boards based on rk3399 are developed for those usecases - but let's call this the nuclear option.. :D)... If you feel motivated - go for it. don't let my rants about 4.4 let yourself demotivate.. :D In general I would be a fan if the buildscript allows a quick way to produce debs for custom packages. And I'll still play with 4.4 for a while anyway cause display and cameras on rk3399 are untouched till now.. and it's on my list to play with..

I don't think so.. e.g. to reduce fall out we could first let both use the same kernelsoruces... then patch them until they're even and finally merge but either ditch ayufans or friendlies kernel.. one part which will mess is likely mali drivers but @JMCC knows more about that for sure.. ah and before we forget.. rk3399 boards going upstream u-boot one or the other way would also be nice..

just a short one.. and I didn't read all of it.. working on: rk3399 to 5.6 (more or less done with: https://github.com/armbian/build/pull/1759 but testing needed especially for everything except pbp) display of pinebook pro working with mainline kernel - same PR camera working on 4.4 for pinebook - not even started yet I would love to merge rk3399 and rockchip64 bsp kernels to keep maintenance easier there - let's see if we get the mali mess sorted out there rk1808 into wip - the boards are there.. but time is missing and kernel source will be a pain maybe further cleaning of opi 4b DT

didn'te expect it to work.. but well.. whatever works works..

I would try "video=composite-1:d".. this goes in over u-boot variables, and they tend to mess up stuff.. cause it's then more like extraargs=video=composite-1:d whereas it should be extraargs="video=composite-1:d"..

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

on arm worls there's no installer for your os.. neither on fedora nor on ubuntu.. but stick to whatever fits to you bet.

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?