• Content Count

  • Joined

  • Last visited

 Content Type 


Member Map






Everything posted by chwe

  1. 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..
  2. 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..
  3. just a short one.. and I didn't read all of it.. working on: rk3399 to 5.6 (more or less done with: 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
  4. didn'te expect it to work.. but well.. whatever works works..
  5. 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"..
  6. chwe

    Pinebook Pro

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


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

    Pinebook Pro

    with the newest pushed to my PR: 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 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?
  9. chwe

    Orange pi 4 Pi 4B/ the 4b and the 4 are more or less the same except the 4b USB3 is directly wired to the SPR2801S NPU.
  10. yeah but my quick and dirty patch didn't work.. it gets applied but breaks then in packing.. do you have yours already online?
  11. btw. did you had a look at the packaging script patch? They made quite some changes in it and a quick patch reverting to the 5.3 ended in a fail.
  12. chwe

    Pinebook Pro

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

    Pinebook Pro

    well our DT in is based on his DT anyway.. at least with his kernel, our special sauce config did show the display as well.. see 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 the later as module in the PR... I pushed my 'last' changes in the PR just for the reference.. ( gave us the working display with our kernelconfig.
  14. chwe

    Pinebook Pro

    just as a side node. Tobias Schramms DT goes through peer review for mainline.
  15. chwe

    Pinebook Pro

    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 ( 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.
  16. moved to p2p tech support.. I doubt this board will get any armbian support at all (except you make it happen on your own), there's no reliable reseller to buy them in quantities and therefore it doesn't really fit into rk3399 development.. I wish you the best to get something out of it.
  17. the RCs should be 'somehow' predictable.. e.g. for the linux kernel you know it's monday morning (europe) when the next one drops in how many RCs we have mostly depends on how smooth things go.. so it is possible that the releasedate is not always 100% clear.. I guess it's up to the release maintainer to decide when things are mature enough, but maybe we need a few 'must haves' and a few 'this will delay' defined (means if, it's important enough that it will delay a release).. the images which are finally released should be somehow reproducible.. something like ./ $RANDOM_FANCY_VARIABLE=release_2002 and it fetches exactly the sources which were used to produce the release (either over the armbian repo/sources) or by commit hash (which can be problematic from time to time, ask @TonyMac32 and the story of rockchip). So that someone who wants to build a 'know working' (in case it was tested for the board in question) image can build and patch on top of the release.. except the commits which alternate the rc numbers in the buildscript rc's should IMO have no commits which are not available in master as well so that after the release we can go 'back to work' without a discussion what we've to cherry pick from the release to work on master, this also means if someone wants to bring up a fancy feature during rc this must imo kept 'on hold' until the release is here.. Otherwise we end in the same mess as we had between master and our 'development' branch and all other attempts to have a 'stable' branch.. for sure stuff I didn't thought about yet..
  18. if upstream means armbian github.. if yes.. done see: thanks for investigating and sharing.. @Igor can you rebuild and push to download page.. Can't test cause I don't find my board. @Xmoe can you test after its?
  19. if there would only be a SBC which has on board LIPO charging features with powerdetection and that boardvendor would sell cells which fit to the board... oh wait.. such boards exist..
  20. and sometimes it's more or less the 'works for me' approach where it worked in the first place for 'developer x' and as long as nobody could show the opposite it was assumed to be 'good'. Mostly with one or maybe two boards of the SoC in question.. So our sample amount to optimize parameter might not be high enough to call this scientific. So our settings are based on observations but likely not on a scientific relevant sample amount. oh most of the few OC-er I know spend an unhealthy amount of time to ensure their OC setup works perfect stable at highest possible settings for their CPU/GPU/RAM, probably a way more time than we invest in our settings (my last AMD64 except my notebook where thermals don't allow to think about OC at all is now 7years old and has probably 2-3k hours stable at slightly overclocked settings, I don't see a difference between overclocking between architectures).. Now back to the topic and back to my observations.. I probably packed the linux kernel with 7z a few hundred times when I played around zram trying to find a difference in performance between lzo and lzo-rle (which is claimed to be faster on arm, and 7z is great to soak up a lot of memory). The board itself run for roughly 2 weeks with the image (5.3 kernel back then) and 7z run for hours over night packing and unpacking kernel sources. On my board I didn't notice instabilities except oom can kicks in (it mostly happened when trying to compile large libraries, but also happens sometimes with 7z and reducing available ram with kernel bootargs below 2GB iirc - could be less, I barley keep notes of such stuff when I don't see promising results. I sometimes should, turns out my brain runs oom too and I forget stuff over time). On my NanoPi M4V2 our default 2GHz/1.5GHz settings worked just fine.. Could be that I just got 'a better board than yours' which allows higher defaults (the same happens in AMD64 world - some CPUs from the same spec just perform better than others) or that something else on your settings isn't in a great shape and if this is the case I would bet on your powersupply. We see first indications that we run into the same nightmare with powering as we did with microUSB back then now on boards using USB-C in 'dump mode' being not PD compliant (USB-C is better than microUSB but the boards it's mostly used are also more powerhungry so being better doesn't mean being good). My setting was headless with a RPi4 PSU which is to my knowledge rated at 5.1V/3A. What PSU did you use for your board. @piter75 (maybe adding the other usual suspects too, so @TonyMac32 and @martinayotte) if this turns out to be a issue for m4v2 whereas the other boards do fine we could simply solve it by DT overlay and having it as default for those boards do well and disable it for the M4V2. Similar to to bring up USB2 on pinheader by default.
  21. yours looks like bsp kernel.. well I only had mainline open.. No idea how this stuff is named in bsp.. and I won't dig into it.. check which node is defined for phy supply e.g. something like this: &u2phy1_host { phy-supply = <&vcc5v0_usb2>; }; and then make your changes in the referred regulator.. and as before.. I still don't recommend it..
  22. to our luck this is not a forum only for moderators right? @Igor/ @lanefu if my style of moderating stuff is no longer valuable you can happily revoke my moderator rights then.. I'll spend my time on github and PM depending on motivation.. A forum needs to work for its users not only for the moderators. After all we as moderators do only a bit of housekeeping to keep the rest going. I favor the less active moderating style where you only take actions when things run out of control, either due to people insulting each other or it gets bloated by useless crap not related to the topic at all.. as long as things go more and less smooth I don't see a reason to either cut peoples rights or giving them 'official' warnings.. Others might have a different moderation style and that's also fine.. Different people will have different approaches how to solve things. Not everyone has to solve it the exact same way as I do but being able to edit posts is a feature people use and there are reasons to have it. and if 12 out of the 8204 users abuse it we're talking about less than 0.15% 'bad citizens'.. IMO a percentage we can and must accept. I'm confident that a higher percentage will use the same feature in a sane way.. Obviously if I see spammers I flag them, game over.. next one will come, next one will be banned as soon as it gets spotted.. Ofc this won't keep the forum a 100% clean from spam, but I can life without a 100% clean forum.
  23. about which of the 'solutions' do we talk about.. verify e-mail address (then check if the spammer didn't do that as well - and if they didn't I guess they will learn that fast) restricting edit post with "random rules" if they're 'not harsh enough' they'll simply overcome it (e.g. register two accounts and then like each other once and going further with the same strategy as before).. if they're to harsh it will affect users - maybe not the old ones but the new ones.. going through my old approving list (only 14 hours here but already edited - in a 1day rule he could still do this.. i) some people will edit their thread.. e.g. hopefully when their first iteration doesn't give the attention they want they clarify things or just add a note that they solved the problem on their own.. I'd rather prefer that they edit it than adding a second post just which might then go as well in the category of topic bumping etc. Or just to summarize things on the first post so that for those new to the thread, it's easy to get a clue what happened. E.g. I have something like 40 edits in this thread (only counting mine).. To partly clarify things.. to add new findings.. to make clear things were solved.. etc. Others in board bring up do the same.. In my opinion.. if we really talk about 12 spammers which overcome the current spam-block system then this is a non issue at all. If this would be a daily issue where threads get messed up... ordinary users: write tutorials write boardbring ups (I was one back then when I dealt with mt7623n wrote the unofficial unsupported multimedia script i still love the name ( @JMCC, okay he's no longer an ordinary user I assume, but he started as one) Obviously it makes sense to use the feature responsible (e.g. make clear what you changed and maybe also why - a git diff to see the history of a post would be great.. btw @Igor a quick google search showed that this might be possible, but it mostly ends in dead links.. maybe your invision-fuu skills are better and you find something like that?). But it is used.. and there are a cases in which it makes absolutely sense. Also to avoid confusion (when you were obviously wrong with your assumption in the first term, or when something was solved (even when it's only editing the title from *random problem* to *random promlem [solved]* in fact you do this mostly over edit post... I don't think it's worth to disable this for users due to 12 people abusing it..
  24. can you provide data how many spammers overcome our current system with first thread approved editing their follow up and how may posts they modify after its?
  25. well you should be moderator long time ago.. but that's a different story.. (btw. how did that not happen?) for the rest of this post, take it with a grain of salt problem, most of those maintenance topics are boring as hell means that people may read the first post and then decide to no longer follow it, so once 'our' solution grows the majority of let's call them power users/ developers/ maintainers and even some moderators might not even realize which new rules are in charge now.. So the majority of the people contributing to the thread might be fine with the change.. Whereas it's not clear what the majority of power users etc. thinks about it... an automatized solution to fight spam will halve a automatized counter to produce spam.. And I'm confident that they will have more resources than we have... Cause I only saw a few of them (2-3).. About how many cases do we talk here? If we have only a few of such 'power spammers' I don't think it's worth to restrict user freedoms just to get those few spammers.. As soon as they edit recent topics of interest they get caught anyway and get flagged as spammers - game over for that account.. If we have a bunch of such spammers we could talk about restrictions but obviously they'll find a way to counter this so I don't see any automatized solution which will work in the long term.. back then when I maintained my own mailserver to register on various sites I had a small firefox plugin which generated a new mailadress and also 'validated' that mailadress successful for most cases without me taking any actions.. I'm quite sure their skill-level is higher than mine to achieve it.. I even made some statistics which sites then use those random mailadresses to send me spam after its.. As soon as a forum has some popularity you'll have spam, and you'll have to deal with. If the community is overall healthy they will hopefully help to report spammers or ignore those links (which mostly solves the issue itself, best case they report it then when they click by mistake on it - if the viagra for 2$ link isn't clicked - the spammer doesn't gain anything from it). If the community isn't healthy at all we better figure out what's wrong with our community than with the spammers..