chwe

@Igor when did we change RockPi to supported? Especially cause we provide 4.4 kernel in the first two dl. options as mature support.. IMO it doesn't represent the current status.. Only difference compared to before is that @ayufan took our patch and added it to his kernel (which is good cause it saves us a patch to maintain). But the 4.4 dts was never cleaned and iirc it had a bunch of 'not as healthy stuff in combination with this kernelfork. IMHO the status should still be wip, as more or less for the whole rk3399 family. But happily it's not my decision. Tagging @TonyMac32 and @martinayotte

nothing wrong with that. At least you're willing to explore things on your own and learn it which is IMO a way better than thinking you know everything whereas in reality you don't even know the basics. https://manpages.debian.org/buster/apt/sources.list.5.en.html this might be a good starter to learn more in case you're interested.

as simple as it is... with opt-in nobody will opt for it.. cause honestly people don't change stuff on their os without a benefit and I don't like the dickmove where people have to opt-out for tracking, all sort of device tracking should always be opt-in. We have a estimated 'boardpopularty' statistic with https://dl.armbian.com/_download-stats/ and that is IMO more than enough to get an idea how popular a board is (and honestly, I would overthink my contribution to the project if we start to add such a feature to the project). Contribution to Armbian is mostly driven by personal interest and availability of the board. If we would start to base contribution on popularity of the board by users, we would have to support boards like the RPi cause on a user side they are really popular, on a devs side.... not that much. Boards like a clearfog will never be as popular as a orangePi, simply cause it's too expensive for the average going cheap user which buys an ARM board. It simply targets a different user base. People buying a clearfog mostly do their homework first before they buy a board cause they more or less know what they need. People who buy the OPi Zero can also be driven by, what can go wrong if I buy a SBC which costs 15$ (just an example, there are tons of other cheap boards as well.. ). For a bunch of use cases, the OPi Zero will be a perfect solution and it's overall not a bad board (as long as you don't rely on it's wifi ) but the higher popularity compared to the solid run doesn't mean that it's the better board. It's a different board targeting a different user base and as long as we have contributors which are willing to support both we should support both. I don't see a reason to mark it as important. nice for what? What information will we gain? What's the benefit for the project? I don't see it.

they should probably use a higher resistor for this one.. I never got why they didn't made it controllable especially when everything was there to make it. @hipboi any plans to fix it in the next revision of the board? I happily adjust the DT patch (which is gone anyway). Btw. the current RockPi dts has no LEDs configured at all if I see this correctly..

honestly I've never tested mPCI cards.. I think @Igor tested a few did you check if we actually have it in our config? the config is far away from complete.. https://github.com/armbian/build/blob/master/config/kernel/linux-mt7623-default.config

if you pick an image from the downloadpage you should be fine.. if you picked an image from some shady places well.. due to different naming for the kernel package, armbian will always pick the right one and not the one from the debian repo. Tweaks from armbian are mostly named different than debian packets (or it's a newer version and apt should get it right iirc). https://github.com/armbian/build/blob/fc1715450015ae62374a13d77f19b0ab53bb1d4c/lib/debootstrap.sh#L184-L190 iirc there it happens.. not sure where or if we described it in the docs.. people normally don't care as long as it happens..

no idea, and I won't test it.. I don't even own a HDMI display anymore.. Don't have a TV.. my buildserver is mostly headless or with DVI display for maintenance when SSH isn't possible.. Don't own a DVD player or so to feed it.. Really,, I don't care much about HDMI in at the moment..

you guys have to many SBCs... They dropped cause they no longer wanted to use armbian as a base for their images iirc.. Hmm the boards I remember I have.. Beagle bone the white one beagle board xM or so, they were from the pre RPi time, I never did much with it.. opi zero, opi pc+, opi 2g-iot, opi 4g-iot, OPi 3 and OPi with H6 but no USB3 don't even remember the name.. BPi m2 zero, BPI R2, BPi W2 RPi 1b (one of the first in switzerland probably...) RPi 2b, somewhere there should be a 3b, and yes I bought a 4b RockPi 4b, somewhere there's a RK3399 TV box which I never hacked fully.. a Olimex Lime 2 (this board looks just like made by people who know what they're doing I would love to see some new boards from them.. ) and finally a Lichee Pi Zero which runs Debian stretch on a 64mb ram board without issues.. (okay.. I never gave it much workload.. but iirc there was once a python script with logging stuff running on it).. okay.. I might have also too many SBCs.. ahh.. and a Tinkerboard.. they were dirt cheap here back then.. now 2 years later they're doubled the price they had in the beginnings.. The most used one is still the OPi Zero.. it was cheap back then.. and for most of my work sufficient.. The RockPi crushed numbers for 14 days in a row sitting at 75-80°C without issues, I was actually surprised.. cause it was one of the self crafted early images for this board.. The tinker was fun to mess with.. but I never cared about desktop.. so actually this board didn't make much sense for me.. The BPi R2 was a rabbit hole to mess with u-boot, but I learned a lot (network is still crippled).. The W2, I don't know.. it's a strange thingie.. People here do crazy thing to hack TV boxes with the same SoC (actually a cool thread cause not much bloating, so please don't mess there ..). completely forgot.. there's a HC1 as well,, but this serves as a NAS box I don't mess with, I just does what I expect from a NAS box..

and the moderators have to explain again and again.. and again.. That's why csc patches should have a 'tag' (could be subfolder or csc_random_feature.patch) and a bot disables them automatically in case they break. first we would know soon which csc boards get community support and those who don't can be moved to eos, second as long as the patches apply properly they don't harm us (only if it's a 'bad' one which modifies stuff it shouldn't) so those boards get a decent support even when we don't invest much work into them. Otherwise I only see freeze kernel by default for csc as a sane option. constantly explaining our users that their csc board breaks cause we dropped their DTS and it messes around is kind of boring, including the 'armbian is not stable on my board blabla..

Maybe.. but if you separate patches in their own repo they still break from time to time.. and then? if csc patches are separate from official patches how to deal with it? the kernel will still be 'per boardfamily' means needed for csc as well to work properly.

well.. problem if csc is out of the normal pipe.. if kernelpatches are needed.. they probably break with every update.. :s I know csc are csc for a reason.. but, explaining this again and again.. will be a pain.. I would be in favor of moving csc into a subfolder of the patching.. and have some sort of a bot.. once recognized that a csc patch doesn't apply properly, it gets automatic disabled (for sure.. complains will still come, but at least we would have something which is explainable, eos related patches could sit in the same subfolder), documented that those patches are not maintained anymore by the core project...

well depends on usecase as always.. if you add the power-supply and the case and the micro HDMI to get "a KODI box" then the price difference is minor and in terms of thermal design they don't give each other much.. But the whole TV box stuff is anyways of minor interest to me... I'm quite sure the RPi4 will be a huge success for them.. It has more or less everything the average joe wants including USB3 for a 'decent NAS'.. They might figure out that once more than one plate is added things get messy.. But that is then for sure somehow a feature not a bug.. I don't like their forum.. It's always the same 5-6 suspects answering there.. to everything and it's always the user getting blamed, never the documentation nor the software nor the whatever... I know we blame quite often the user here as well but we at least admit from time to time that over software sucks as well.. that things aren't perfect.. Even the fact I don't like the attitude in the RPi forum.. it can be funny as well.. Especially when you don't agree on everything.. and from time to time.. there's some interesting stuff there to read.

If you provide more than one opportunity, people will choose the wrong one.. Especially beginners, so I understand why they only provide one... less support, less trouble and likely 'better performance' (at least up to the 3b+ with limited memory). I assume the zero will get an update next with a a53 or a35 core with a slightly higher price cause hey it's x times more performance right (never mentioned that this 5$ was just a very successful marketing gag)? So that they can slowly fade out support for RPi 1 and the early 2 versions without a53 cores. different board diffrent use-cases. I actually forgot to back the campaign but it has 15.5MB more SPI NOR Flash than the new RPi which offers some nice opportunities.. btw. are the DTS files already out for the board? Didn't check progress much.

FYI: asked about ext4 support for boot to get rid off the FAT partition: https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=243890&p=1487617#p1487617 seems not of importance for them.. some charger issues: https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=244146 and a nice link provided there: https://www.scorpia.co.uk/2019/06/28/pi4-not-working-with-some-chargers-or-why-you-need-two-cc-resistors/ as with more or less every boardmaker, things are not mature in the beginnings.. But at least some of the flaws will likely be fixed over time..

haha my fault.. I added a more or less proper support to csc for the board back then.. https://github.com/armbian/build/blob/e8e0c698f19204fd63b89132867725ce7dade8db/config/boards/bananapim2zero.csc#L7 if you disable g_serial, I assume it will just work as USB otg but not tested, don't even know where in my 'retired electronics box' the board actually is..

https://www.armbian.com/odroid-c1/ Support ended (EOS) you can test Other download options with mainline 5.1 kernel..

https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=244166 if you ever look for a textbook example of whataboutism.. There you go. We need some more HackRF boards to target all those CRT displays in the wild..

the CSI driver isn't the problem here.. iirc @@lex already had successfully cameras working under mainline linux (ov5640 if I'm right).. Problem is, there's to my knowledge no gc2035 mainline driver available (at least, there wasn't the last time I checked it).. As long as nobody touches this up we won't see gc2035 cameras working on mainline.

I would check the schematics of the BPi W2 (assuming that those boards are more or less reference design at this part).. Maybe check CS pin during boot? or soldering a logic analyzer to sniff?

I couldn't less agree on this one.. It is a TV box SoC with schematics.. It might not matter if you only consume and someone else provides the images.. But it matters if you're on the other side. You (mostly) know what you get, whereas TV boxes sometimes change depending on what is cheaper at the moment (e.g. different wifi module, NAND instead of eMMC etc.). well.. IMO it was RPi who had to respond.. all those RK3399 based boards crushed the RPi fully.. I assume we'll see more specialized SBCs in the future. e.g. https://www.cnx-software.com/2019/06/19/rock-pi-s-tiny-sbc-rockchip-rk3308-processor/ some NAS ones etc. Indeed it is the first RPi since v2 which doesn't look annoying. They try their first step away from VC4 which might be interesting.. I don't get this (claimed) full backwards compatibility of images. IMO it was a good opportunity to make a cut (keep, pin-compatibility etc. but craft an image which is either fully armhf - or arm64). having a VC4 and a VC6 branch of raspian is something the majority of their believers would probably accept. I will likely buy one (will be the first one I bought after the Pi2 IIRC), I've a project where the A72 cores might shine, and if thermals are somehow controllable passively, 4xA72 for 35$ looks good to me (don't need really much ram for this project, it's really about numbers crunshing). They did a couple of things right, e.g. SPI NOR, USB-C instead of microUSB (btw it's a 'dumb' one right? so no PD), even the double HDMI was IMO a smart move (now it's somehow unique to its competitors). And from the software side I'm quite sure things will mature over time (looking forward to the PXE, my project would really benefit from a proper PXE implementation), and we'll soon get some deeper insights from people experienced in kernelcode.. E.g. https://www.cnx-software.com/2019/06/24/raspberry-pi-4-features-broadcom-bcm2711-processor-up-to-4gb-ram/#comment-563948 But I don't think that 'chinese' (whatever that means) have to respond. For different use-cased several companies have a good line-up, and the user group they target is often different. It was a needed, and from the first glace well crafted update of the (IMO) complete failure called RPi3b+. I was surprised by the 4xA72 core they've chosen and the 1,2 and 4 GB ram was smart too. Let's face it, the average 'rich' user will always opt for the 4GB variant no matter he needs it or not and I assume the profit margin will be slightly higher with this variant.

it does ___ ____ _ ____ ____ / _ \ _ __ __ _ _ __ __ _ ___ | _ \(_) | _ \ / ___| _ | | | | '__/ _` | '_ \ / _` |/ _ \ | |_) | | | |_) | | _| |_ | |_| | | | (_| | | | | (_| | __/ | __/| | | __/| |___ |_ _| \___/|_| \__,_|_| |_|\__, |\___| |_| |_| |_| \____| |_| |___/ Welcome to ARMBIAN 5.83 stable Debian GNU/Linux 9 (stretch) 4.19.38-sunxi System load: 1.31 0.44 0.16 Up time: 1 min Memory usage: 7 % of 999MB IP: 192.168.0.6 CPU temp: 33°C Usage of /: 3% of 29G [ General system configuration (beta): armbian-config ] New to Armbian? Check the documentation first: https://docs.armbian.com Thank you for choosing Armbian! Support: www.armbian.com Creating a new user account. Press <Ctrl-C> to abort http://ix.io/1MHz https://docs.armbian.com/User-Guide_Getting-Started/

define stable.. but sure, I wouldn't go with the R2 as my main router.. things are just not 100% clear yet.. and network is still a bit.. mhmm.. flunky might describe it best. There's no development cause nobody is really interested in pushing stuff here.. me neither.. you can learn things by pure pain.. pain and time.. I would separate NAS from router jobs.. If the price is not your main driving force, you might look into solidrun devices. https://www.solid-run.com/product-category/sbcs-fanless-pcs/

So you glue a BSP DTB from a 4.1 kernel together with a BSP 4.9 kernel.. good luck to get these things working.. In theory DTS should be backwords compatible, assuming that the drivers in the kernel are written properly.. well for a moment, we don't assume that all BSP drivers are written properly.. depends what warnings.. a compile log might be helpful.. did you check how many partitions this WD thingie has? Those android based system have often a bunch of them.. with some weird schema.. so you can probably guess on which one it should be found.. If stuff is not encrypted.. just tells you the memory adress this thing is loaded into it.. to actually see where it comes form, you probably have to look into sources.. But it's a Flattened device tree.. so it should be a own file for the dtb, it's not glued to the kernel so hope might be there that you just find it somewhere in the boot partition of your device.. if it would be backwards compatible drivers then not (but since bsp kernels don't give a fuck about this.. it might mess.. it might also mess if you compile this dt with a new kernel..) did you also test if the kernel panics reliable on the same event? When I had fun with the mediatek stuff.. it wasn't as predictable when the kernel crashed.. it was just sure that it will happen.. does it throws you errors during compilation? and when which one? did you also check which dts or dtsi files are included in these dts.. did you copy them as well? lastly. believe that a vendor DTS is correct is IMO naive.. my experience is more that the vendor dts is glued together from some reference-board dts modified until the thing actually boots up and mostly works before nobody ever has a look at those files.. a bunch of nodes are there witch are not populated on the actual board, on the other hand.. those there might not be 100% correct.. But you might frankenstein together a 4.9 DTS from some reference boards there by looking into a working 4.1 DTS (for the 4.1 kernel).. if the same reference boards are present on a 4.1 and a 4.9 kernel it might be easy to get an idea how things have to change..

Were those BCM chips under DSA in 4.14? If he only updates from a 4.14 to a different 4.14 nothing should happen.. If he updates to 4.19, it's likely that you've to ensure that this stuff is loaded: https://github.com/armbian/build/blob/2e3a338d481b1637b7ff55d52e43612791e6d23a/config/kernel/linux-sunxi-next.config#L2069-L2073 maybe check the DT once again.. and probably mess around with network config.. DSA doesn't like NM that much.. I would go for NetworkD for the beginning..

maybe that we just trashed the configs for it? https://github.com/armbian/build/commit/e39757e142c8f510a0b013aba33a8555075ddf16#diff-53e11bba6c9eed58a7337b6d27ea4762