chwe

Moderators
  • Content Count

    1425
  • Joined

  • Last visited


Reputation Activity

  1. Like
    chwe reacted to Myy in RK3399 : Crashs dumps   
    In order to enumerate the major issues that are *still* valid now, I'm creating a 'crash dump' thread.
    The idea is simple, if your RK3399 board crashed recently, you just :
     
    Write what happened during the crash; Provide the link you got from sudo armbianmonitor -u , after the crash happened; Provide the content of /var/log/kern.log (if this file is present on your system) (attach it or copy the content on pastebin and link it here).  
    No discussion here.
    Feel free to create a new dedicated thread afterwards to talk about the problem you encountered.
     
    Minor issues are welcome too, if they trigger a BUG message in your logs. Just state that it's a minor issue.
  2. Like
    chwe got a reaction from JMCC in Armbian v20.05 (Kagu) Planning Thread   
    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..
     
  3. Like
    chwe reacted to JMCC in Armbian v20.05 (Kagu) Planning Thread   
    Not if we put all RK3399 boards in rk3399, and all RK3328 in rockchip64. In that case, we could just keep our current kernel config and that would work.
  4. Like
    chwe got a reaction from Igor in Armbian v20.05 (Kagu) Planning Thread   
    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
  5. Like
    chwe reacted to UniformBuffer in Kernel Boot Parameters   
    So you suggest to change the command to "command" right? I tried it but nothing happen. Maybe your suggestion works, but the command itself doesn't. As i know, all current kernel boot parameter can be found on /proc/cmdline file, but there isn't.
     
    Solution found:
    I tried to use some of the texts you suggest, specifically the extraargs=video=composite-1:d (without quotes) works.
    Seems that the script look for the extraargs= prefix and add everything next to kernel parameters.
    It appear on /proc/cmdline and the command seems to work, now that connector is listed ad "disconnected".
    Thanks a lot for the help and the dedicated time!
  6. Like
    chwe got a reaction from UniformBuffer in Kernel Boot Parameters   
    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"..
     
     
  7. Like
    chwe got a reaction from aaditya in Pinebook Pro   
    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?
  8. Like
    chwe got a reaction from Tido in [Moderation] Dealing with subtle spammers placing "tiny little ads"   
    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.
     
     
     
  9. Like
    chwe got a reaction from lanefu in Armbian 20.02 (Chiru) Release Thread   
    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 ./compile.sh $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..
  10. Like
    chwe got a reaction from Xmoe in Banana PI R2 stuck on first boot   
    if upstream means armbian github.. if yes.. done see:
    https://github.com/armbian/build/commit/3b3d46ca7f1963e04c0ca98e68056ca14a9e94b4
     
    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?
  11. Like
    chwe reacted to Xmoe in Banana PI R2 stuck on first boot   
    What I have found out about this problem:
    The Bananapi R2 needs the SD card to have special headers in the first 2k of space, after that comes a preloader which is then in turn loading u-boot. Those headers and the preloader are distributed as binary blobs (found in build/packages/blobs/mt7623n/BPI-R2-preloader-2k.img of the build tool).
    As it turns out, the blob of the preloader is a bit older, which had a restriction on the size of the "u-boot.bin" it could load. There has been a newer release which increases the allowed max size of "u-boot.bin" that is loaded (http://forum.banana-pi.org/t/which-preloader-image-to-use/4602/24). So what happened is probably following: over time u-boot got more and more features and as such the u-boot-binary grew larger, so much so that at some point it was too large for the preloader. It can be fixed by upgrading the binary blob for the preloader to this one: https://github.com/BPI-SINOVOIP/BPI-files/blob/master/SD/100MB/BPI-R2-preloader-DDR1600-20191024-2k.img.gz
    (as outlined in the forum post linked above).
     
    Steps to fix the build process:
    1) Download and unpack https://github.com/BPI-SINOVOIP/BPI-files/blob/master/SD/100MB/BPI-R2-preloader-DDR1600-20191024-2k.img.gz
    2) Rename to "BPI-R2-preloader-2k.img"
    3) Move to "build/packages/blobs/mt7623n/BPI-R2-preloader-2k.img" (replace the old one by doing so)
     
    Steps to fix the provided images from https://dl.armbian.com/bananapir2/archive/
    1) Download and unpack https://github.com/BPI-SINOVOIP/BPI-files/blob/master/SD/100MB/BPI-R2-preloader-DDR1600-20191024-2k.img.gz
    2) Rename to "BPI-R2-preloader-2k.img"
    3) Be careful with the `dd` command:
    4) Patch the images by writing the new bootloader into the images using
    dd if=BPI-R2-preloader-2k.img of=<PATH/TO/ARMBIAN.img> bs=1k seek=2 status=progress conv=notrunc So for example it looks like this:
    dd if=BPI-R2-preloader-2k.img of=Armbian_19.11.3_Bananapir2_bionic_legacy_4.19.85_minimal.img bs=1k seek=2 status=progress conv=notrunc The command skips the first 2k of the armbian.img (given by seek=2 in combination with bs=1k) and then writes the new bootloader at that location, right over the old one. The `conv=notrunc` part makes sure that the rest of the original file doesn't get cut-off.
    Now you have a patched img which you can burn to your SD card.
     
    This would be great to be fixed upstream, but right now I don't know how to.
  12. Like
    chwe got a reaction from gounthar in Is it possible to shutdown properly an OrangePi Zero in case of power loss?   
    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..
    https://www.olimex.com/Products/OLinuXino/A20/A20-OLinuXino-LIME2/open-source-hardware
     
    such boards exist..
  13. Like
    chwe got a reaction from Neko May in Potential OPP issue with NanoPi M4V2   
    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 https://github.com/armbian/build/blob/e78f6db215c9444ce83b8e80c85af88158ce4c2e/config/boards/orangepizero.conf#L6 to bring up USB2 on pinheader by default.
     
     
  14. Like
    chwe got a reaction from nanopi in [solved] USB2 until unplugging + replugging, then USB3   
    it's not the distributor - it's the company behind NanoPi boards..
     
    IMO the whole thread can be moved to: https://forum.armbian.com/forum/31-sd-card-and-psu-issues/
     
    NanoPi M4 being not PD-compliant and therefore might be troublesome is mentioned on the dowloadpage:
     
    linking to
    btw @Igor or @lanefu we might add the same disclaimer from nanopi m4 to the orangepi 4 cause this board will have the same issues (I updated the thread but forgot my credentials to the WP admin board to do it on my own - feel free to remove my rights there anyways I didn't do much maintenance of it and honestly don't plan to change that in the future).
     
    (hidden cause not really an advice more a hack to maybe achieve what you want but not what you should - having a sane powering for your setup)
     
    3 amps at 5V is sufficient for the NanoPi M4 in most scenarios I had. But if you look at their "expansion hats", the USB3 and the SATA "hat" provide a barrel plug and for the sata hat additionally a ATX12V 4 Pin connector indicating that even they do not recommend using USB-C for such set-ups.. 
  15. Like
    chwe got a reaction from Werner in [solved] USB2 until unplugging + replugging, then USB3   
    it's not the distributor - it's the company behind NanoPi boards..
     
    IMO the whole thread can be moved to: https://forum.armbian.com/forum/31-sd-card-and-psu-issues/
     
    NanoPi M4 being not PD-compliant and therefore might be troublesome is mentioned on the dowloadpage:
     
    linking to
    btw @Igor or @lanefu we might add the same disclaimer from nanopi m4 to the orangepi 4 cause this board will have the same issues (I updated the thread but forgot my credentials to the WP admin board to do it on my own - feel free to remove my rights there anyways I didn't do much maintenance of it and honestly don't plan to change that in the future).
     
    (hidden cause not really an advice more a hack to maybe achieve what you want but not what you should - having a sane powering for your setup)
     
    3 amps at 5V is sufficient for the NanoPi M4 in most scenarios I had. But if you look at their "expansion hats", the USB3 and the SATA "hat" provide a barrel plug and for the sata hat additionally a ATX12V 4 Pin connector indicating that even they do not recommend using USB-C for such set-ups.. 
  16. Like
    chwe got a reaction from TRS-80 in [solved] USB2 until unplugging + replugging, then USB3   
    it's not the distributor - it's the company behind NanoPi boards..
     
    IMO the whole thread can be moved to: https://forum.armbian.com/forum/31-sd-card-and-psu-issues/
     
    NanoPi M4 being not PD-compliant and therefore might be troublesome is mentioned on the dowloadpage:
     
    linking to
    btw @Igor or @lanefu we might add the same disclaimer from nanopi m4 to the orangepi 4 cause this board will have the same issues (I updated the thread but forgot my credentials to the WP admin board to do it on my own - feel free to remove my rights there anyways I didn't do much maintenance of it and honestly don't plan to change that in the future).
     
    (hidden cause not really an advice more a hack to maybe achieve what you want but not what you should - having a sane powering for your setup)
     
    3 amps at 5V is sufficient for the NanoPi M4 in most scenarios I had. But if you look at their "expansion hats", the USB3 and the SATA "hat" provide a barrel plug and for the sata hat additionally a ATX12V 4 Pin connector indicating that even they do not recommend using USB-C for such set-ups.. 
  17. Like
    chwe reacted to hipboi in Armbian images do not boot on RockPi4a (with workaround)   
    I think there is some misunderstanding here. Last time we checked, radxa u-boot in SPI with Armbian in NVMe can boot, with MBR. Maybe some boot order change in u-boot caused this? We will look into it.
  18. Like
    chwe got a reaction from aaditya in RK3399 -Smart Technologies AM40 iQ "Module"   
    it was highly overpriced with 400-600$ (IMO still 100$ are too much for it) it is mostly undocumented what you got is a 4GB ddr3 rk3399 'TV box' with 2x2 wifi over mPCIe and 32GB eMMC with a 'connector' I've not seen any specification what's populated on it
    . which may or may not work with a 'generic DT' (generic means here any rk3399 dt file we have most of them are quite similar cause they follow more or less the reference design) for rk3399 boards. You can also (try to) 'extract' the dtb file from 'whatever is preloaded' on this box.. decompile it and follow all the phadles to see how nodes are connected to each other.. to adjust a working DT to match the box better or write one from plain.. (you can also use this blob directly on any sort 'armbian' and see if it is compatible).
     
    at least it has a debug UART populated (likely 3v3 but who knows, you should check that first)
     
    Is it worth it.. well that's up to you.. if you're interested in going down the rabbit hole and learn new things.. maybe it is (you can spend a lot of time with bootloaders, device tree etc. on it.. IIRC ddr3 should be supported with mainline u-boot, and what they have labeled 'service only' looks like a SD-card holder, so you can likely do your 'try and error attempts' to get something 'armbian a like' booting on this board without corrupting the OS which is currently preflashed on the eMMC.
    likely similar to that stuff here:http://wiki.t-firefly.com/en/Firefly-RK3399/adb_use.html
     
    So to summarize you currently got a paperweight and it's up to you to transform it in something useful. Even then I don't see much of a reason to provide support on such a board. It has a 'unknown' availability (you got it cheap from ebay, but as soon as this sellers run out of stock, it's likely never appearing again). For 100$ you get the nanopi m4v2 with a case which offers known schematics, support from the boardvendor, known connectors (including eMMC, PCIe, hdmi, camera and display interfaces) and the vendor known in SBC marked for years (they may not do everything perfect but you mostly know what you get, and in general those boards work as they should). This box might be nice if you plan to learn and dig into what can make it a pain to support random boxes with 'somehow' proper working images. But you may have to build your images on your own for a long time in case non of the images we provide for rk3399 will work out of the box (I would focus on images built for ddr3 ram type boards).
  19. Like
    chwe got a reaction from TRS-80 in RK3399 -Smart Technologies AM40 iQ "Module"   
    it was highly overpriced with 400-600$ (IMO still 100$ are too much for it) it is mostly undocumented what you got is a 4GB ddr3 rk3399 'TV box' with 2x2 wifi over mPCIe and 32GB eMMC with a 'connector' I've not seen any specification what's populated on it
    . which may or may not work with a 'generic DT' (generic means here any rk3399 dt file we have most of them are quite similar cause they follow more or less the reference design) for rk3399 boards. You can also (try to) 'extract' the dtb file from 'whatever is preloaded' on this box.. decompile it and follow all the phadles to see how nodes are connected to each other.. to adjust a working DT to match the box better or write one from plain.. (you can also use this blob directly on any sort 'armbian' and see if it is compatible).
     
    at least it has a debug UART populated (likely 3v3 but who knows, you should check that first)
     
    Is it worth it.. well that's up to you.. if you're interested in going down the rabbit hole and learn new things.. maybe it is (you can spend a lot of time with bootloaders, device tree etc. on it.. IIRC ddr3 should be supported with mainline u-boot, and what they have labeled 'service only' looks like a SD-card holder, so you can likely do your 'try and error attempts' to get something 'armbian a like' booting on this board without corrupting the OS which is currently preflashed on the eMMC.
    likely similar to that stuff here:http://wiki.t-firefly.com/en/Firefly-RK3399/adb_use.html
     
    So to summarize you currently got a paperweight and it's up to you to transform it in something useful. Even then I don't see much of a reason to provide support on such a board. It has a 'unknown' availability (you got it cheap from ebay, but as soon as this sellers run out of stock, it's likely never appearing again). For 100$ you get the nanopi m4v2 with a case which offers known schematics, support from the boardvendor, known connectors (including eMMC, PCIe, hdmi, camera and display interfaces) and the vendor known in SBC marked for years (they may not do everything perfect but you mostly know what you get, and in general those boards work as they should). This box might be nice if you plan to learn and dig into what can make it a pain to support random boxes with 'somehow' proper working images. But you may have to build your images on your own for a long time in case non of the images we provide for rk3399 will work out of the box (I would focus on images built for ddr3 ram type boards).
  20. Like
    chwe got a reaction from piter75 in rk3399-bluetooth.service is still present in "systemctl list-jobs"   
    IMO the easiest way is ./compile.sh KERNEL_CONFIGURE=yes make your changes when menuconfig pops up and you get your new config in output/config after compilation. It's even named the way it should be..
  21. Like
    chwe got a reaction from mar0ni in NanopiM4v2 booting. this is weird   
    https://github.com/armbian/build/blob/9be143c2e4788deae6faf26d8ecfd921cfd52deb/patch/u-boot/u-boot-rk3399/add-board-nanopi-m4v2.patch#L29
     
    https://lists.denx.de/pipermail/u-boot/2017-April/285942.html
     
    should explain most of it..
     
    this whole mess should be cleaned once we've moved all boards to upstream u-boot for rk3399 boards...
  22. Like
    chwe got a reaction from TRS-80 in Process for adding CSC boards?   
    blobs:
    https://github.com/armbian/build/tree/master/packages/blobs/mt7623n
    https://github.com/armbian/build/blob/909be0239d8f3a9d6e2dae9da94d18b65e350320/config/sources/families/meson-gxl.conf#L18-L27
    ends then in: https://github.com/armbian/odroidc2-blobs
     
    so we even already dealt with bootblobs we've no clue what they're doing.. especially meson-glx
     
    still needs the blobs to chainload UEFI (https://github.com/tianocore/edk2-platforms/tree/master/Platform/RaspberryPi/RPi3):
     
     
    the only serious attempt to avoid this was done by christinaa (https://github.com/christinaa/rpi-open-firmware) but more or less dead since months/years. So no there's no change that the RPi relies on bootblobs to get up and running
     
    Cause the bootloader (bootcode.bin) only understands FAT you also need some tweaks here and there in the buildscript.. But most of the needed features are there cause we support(ed?) having /boot on FAT. According to jamesh from the RPi forum their engineers don't see a reason that a bootloader should understand something like ext4 (I would have to search in my posts in their forum to get you a quote for that).. But safest bet for a more or less "sane" implementation would be bootcode chainloads u-boot and u-boot then properly loads a kernel sitting in a ext4 partition.
     
    IMO that doesn't fit to the 3b+ at all.. Maybe partly to the 4. In most when not all parts a rk3399 based on will outperform even the RP4 and for sure the RPi3
     
    what do you mean with ROCK? means RockPi? then there you go:https://www.seeedstudio.com/PoE-HAT-for-ROCK-Pi-4-p-4143.html currently out of stock but allnet has it:
    https://shop.allnetchina.cn/products/rock-pi-4b-poe-hat
     
    I guess something like this will do the trick: https://www.aliexpress.com/item/33057941535.html?spm=a2g0o.productlist.0.0.38d222ebEfaAc9&algo_pvid=ebc883c9-19fd-4f58-ae77-add76220ba26&algo_expid=ebc883c9-19fd-4f58-ae77-add76220ba26-3&btsid=1071dcd7-b020-4d15-ab51-f383395eff93&ws_ab_test=searchweb0_0,searchweb201602_9,searchweb201603_53
    obviously untested I don't deal with POE atm. Just make sure that you don't run into:
    RK3399 tends to be power-hungry..
     
    but back to topic:
    have a sane implementation dealing with the bootstuff when possible don't add additional kernel sources (means build your kernel on top of mainline) Make sure that basic functionality even when you're not interested in works (e.g. USB/HDMI/UART or it's clearly that it doesn't work - well UART must work otherwise it's a pain to debug)  
  23. Like
    chwe got a reaction from lanefu in Proposed Forum Structure Change   
    more subforums add just more subforums I'll ignore.. and there are quite some atm. And it seems we have this discussion like once a year or so... And yes I started such a thread as well must be gone somewhere by one of our forum rearrangements...
     
    we have a:
     
    where all the not armbian related software questions can go as well..
     
    and we have a
    and chit chat.. IMO chit chat is the place where everything goes in nobody wants to deal with..
    The more subforums you have the higher the chance that people choose the wrong one.. means after its more moderation work and as you said time is valuable..
    In a perfect world I would not want to moderate at all cause people don't mess stuff up.. For me moderating is splitting/merge topics on request or when they're obviously not related to each other/connected to each other. Locking stuff down when it goes out of control... which happens from time to time when people get frustrated.. Otheerwise I see myself just a normal user/dev doing dev stuff or spaming in the chit chat about chit chat stuff:
     
    that's what this subforum is for... As well as asking which TV box may or may not be a good pick can have a living there.
     
    If the new structure ends in more moderating we do things wrong, if it ends in less moderating we do stuff right.. as simple as it is.. The same reason I had a iphone for years and not an android phone.. I just had to think less where I find what I need. This got better in android world but I'm not sure if it got better in the forum over time but I don't think a more fine grained forum will help here. I can be wrong on that but people tend to post fast and think less means if they don't find the topic it will fit within page one they'l post it wherever they are at this moment..  Ask yourself.. when did you last go to page 3 or page 4 on a googlesearch? The same happens on forums.. And that's why I mostly refuse to answer to posts where the solution can be found within the first two pages of a googlesearch.. or if I do, I'll use something like https://lmgtfy.com/ to remind those people that things are easy as hell if you use the right search terms. I guess this behavior is now called being toxic - I somehow missed this change in social moves from "it's being a dickmove to waste someone else' time if it can be found with a random search engine" to "every stupid question is worth an answer an how dare you are if it's not written super welcoming and inclusive to everyone"... Back to topic:
    That may sound hard but: for your own sake, better learn to deal with it.
     
    Users are interested in:
    a working SBC with all the features a boardmaker claims (and mostly he sums up the capability of the SoC - mostly this features are based on what works on android and have barely something to do with what works on debian/ubuntu having a recent debian/ubuntu cause nobody wants to deal with something like trusty anymore but they mostly don't care about stuff like bootloader and kernel at all as long as it has the features they need. We still have a bunch of users using the 3.4 bsp kernel on allwinner and we soon ran into the same nightmare with rockchip 4.4 (at least in rockchips case there is a chance that they forward port this to a more recent kernel once android requires a newer kernel) using the most crappy powersupply they have somewhere laying around getting support ASAP cause their problem is for sure the most important one on the world Developers are interested in:
    solving some interesting parts which didn't work before dealing as less as possible with users cause their mess there nice: everything works world up and soak up the time for development having a few users for testing cause testing is boring bringing new boards up, cause board bring up is a way more interesting than board maintenance.. So you see your point: having a well organized forum doesn't really affect both of the mayor groups we're dealing here with.. There are only a few people interested in maintaining the forum and from those few even less are interested in reorganize stuff cause this means more maintenance work and explaining the users why things have changed and how it is supposed to work now. There is this nice little saying: Rome wasn't built in one day, I would add but Nero burned it down in one. To explain that a bit more, if a change breaks the current state may make sense but break existing behavior hence ends in more rebuilding/moderating. This may work as long as you have the fresh "spirit" of moderating things.. but can you keep this over time (means for years not only months)? Cause that's what is needed if we decide to moving around things or moderate more stuff. It's not a change things and everything will be fine, people will still post on the wrong threads and people will still have a wrong assumption what armbian is (a spare time project which tries to do it's best to support a variety of boards as good as possible with a recent kernel with flavors of ubuntu/debian with some tweaks here and there to make debian more useful on such boards e.g nand-sata-install, and tweaks around zram due to limited ram on most of this boards).
    Or to summarize most of it related to your new job as moderator.. be patient and accept that changes might need their time. And right reorganization of the forum might not be on high priory during a release. Especially that this release model is something we're more or less doing "the first time". Or at least it's done the first time that way as we do/try to do it yet. There's for sure a bunch of stuff I forgot to write up.. 
     
    Disclaimer: as often.. this post may contain some sarcasm, some rants etc. (I may should have this in my signature for the future)...
  24. Like
    chwe got a reaction from gounthar in Orange pi 4   
    I had time to test my newly written DT for the orangepi4:
     
    sound still doesn't work (even when I replaced the bits to use rt5651) I guess some of the mic/headphone definitions in the DT are still wrong.. wifi works with network manager ethernet works as well both USB2 are tested and working (I've the NPU version so I didn't try to look at USB3 atm, may or may not work who knows) dmesg shows still some errors to wifi but I've no idea if this is related to the opi at all or just fall out from the normal driver situation here hdmi is untested yet (i've no spare device for doing it) actually the DT should also support eDP over USB-C as far as I've saw in the schematics the opi4 should do it as well.. this should be possible and it's done similar to the pinebook, obviously I've also no spare eDP over usb-c display...
     
    so for @piter75 if you want to mess with it.. here is an updated version of it.. And for the less experienced ones.. you might not wanna mess with it yet.. at least on the powertree there's nothing horrible wrong so that the board would not boot up..
    opi4b_dts_v1.dts
  25. Like
    chwe got a reaction from Werner in Proposed Forum Structure Change   
    more subforums add just more subforums I'll ignore.. and there are quite some atm. And it seems we have this discussion like once a year or so... And yes I started such a thread as well must be gone somewhere by one of our forum rearrangements...
     
    we have a:
     
    where all the not armbian related software questions can go as well..
     
    and we have a
    and chit chat.. IMO chit chat is the place where everything goes in nobody wants to deal with..
    The more subforums you have the higher the chance that people choose the wrong one.. means after its more moderation work and as you said time is valuable..
    In a perfect world I would not want to moderate at all cause people don't mess stuff up.. For me moderating is splitting/merge topics on request or when they're obviously not related to each other/connected to each other. Locking stuff down when it goes out of control... which happens from time to time when people get frustrated.. Otheerwise I see myself just a normal user/dev doing dev stuff or spaming in the chit chat about chit chat stuff:
     
    that's what this subforum is for... As well as asking which TV box may or may not be a good pick can have a living there.
     
    If the new structure ends in more moderating we do things wrong, if it ends in less moderating we do stuff right.. as simple as it is.. The same reason I had a iphone for years and not an android phone.. I just had to think less where I find what I need. This got better in android world but I'm not sure if it got better in the forum over time but I don't think a more fine grained forum will help here. I can be wrong on that but people tend to post fast and think less means if they don't find the topic it will fit within page one they'l post it wherever they are at this moment..  Ask yourself.. when did you last go to page 3 or page 4 on a googlesearch? The same happens on forums.. And that's why I mostly refuse to answer to posts where the solution can be found within the first two pages of a googlesearch.. or if I do, I'll use something like https://lmgtfy.com/ to remind those people that things are easy as hell if you use the right search terms. I guess this behavior is now called being toxic - I somehow missed this change in social moves from "it's being a dickmove to waste someone else' time if it can be found with a random search engine" to "every stupid question is worth an answer an how dare you are if it's not written super welcoming and inclusive to everyone"... Back to topic:
    That may sound hard but: for your own sake, better learn to deal with it.
     
    Users are interested in:
    a working SBC with all the features a boardmaker claims (and mostly he sums up the capability of the SoC - mostly this features are based on what works on android and have barely something to do with what works on debian/ubuntu having a recent debian/ubuntu cause nobody wants to deal with something like trusty anymore but they mostly don't care about stuff like bootloader and kernel at all as long as it has the features they need. We still have a bunch of users using the 3.4 bsp kernel on allwinner and we soon ran into the same nightmare with rockchip 4.4 (at least in rockchips case there is a chance that they forward port this to a more recent kernel once android requires a newer kernel) using the most crappy powersupply they have somewhere laying around getting support ASAP cause their problem is for sure the most important one on the world Developers are interested in:
    solving some interesting parts which didn't work before dealing as less as possible with users cause their mess there nice: everything works world up and soak up the time for development having a few users for testing cause testing is boring bringing new boards up, cause board bring up is a way more interesting than board maintenance.. So you see your point: having a well organized forum doesn't really affect both of the mayor groups we're dealing here with.. There are only a few people interested in maintaining the forum and from those few even less are interested in reorganize stuff cause this means more maintenance work and explaining the users why things have changed and how it is supposed to work now. There is this nice little saying: Rome wasn't built in one day, I would add but Nero burned it down in one. To explain that a bit more, if a change breaks the current state may make sense but break existing behavior hence ends in more rebuilding/moderating. This may work as long as you have the fresh "spirit" of moderating things.. but can you keep this over time (means for years not only months)? Cause that's what is needed if we decide to moving around things or moderate more stuff. It's not a change things and everything will be fine, people will still post on the wrong threads and people will still have a wrong assumption what armbian is (a spare time project which tries to do it's best to support a variety of boards as good as possible with a recent kernel with flavors of ubuntu/debian with some tweaks here and there to make debian more useful on such boards e.g nand-sata-install, and tweaks around zram due to limited ram on most of this boards).
    Or to summarize most of it related to your new job as moderator.. be patient and accept that changes might need their time. And right reorganization of the forum might not be on high priory during a release. Especially that this release model is something we're more or less doing "the first time". Or at least it's done the first time that way as we do/try to do it yet. There's for sure a bunch of stuff I forgot to write up.. 
     
    Disclaimer: as often.. this post may contain some sarcasm, some rants etc. (I may should have this in my signature for the future)...