chwe

on the available versions there won't be a off switch. See the third answer you got when the thread started.

First, thanks for the openness even in such a early announcement. It's really appreciated. a lot of notebooks switch to such a powering as well (including mine going up to 65W). I do believe it becomes a standard (and therefore cheaper) in the future and it's one I actually like. I don't need several different chargers in the future one will fit. Might be more complicated with all the features you already implemented on this USB-C. great! Flash over USB? Rockchip has tools to do this (e.g. rkflashtool). E.g. is the recovery pin properly wired out (without the pain touching two testpads etc). IMO if you could hold the price (including case etc.) this seems to be a really good deal. But I assume it will be a challenge..

what a statement. always good, here are a few: Is powering over USB-C possible (means does USB-PD work, I know the rockpi uses a pd conform power-circuit up to at least 12V (could be more don't remember), so even a 4HD setup should be possible with a proper PD implementation).. Is the m.2 slot NVMe capable? With an adjusted bootloader, "advanced" bootoptions (NVMe etc.) is possible, do you populate a SPI NOR on the board? I know your focus will be on NAS usecase but IMO the SoC is capable of doing "more than just NAS" any chances to get HDMI and/or MIPI (DCI & CSI) wired out? (IMO even on a pinheader where people need an adapter board to get them 'functional' would be a nice option). It seems that eMMC is soldered directly to the board, did you consider a module option as well (as done for the RockPi, several NanoPi's etc.)? Do you have a price for the board? I assume it won't be one of the cheaper RK3399 boards due to all the additional features populated on the baseboard.

if we have the same naming as ubuntu, people expect the same behavior (e.g. 20.04 being then a LTS version). I would consider being part of LTS on one kernel as long as we have a proper definition such a LTS "project" (e.g. features don't get back-ported, running boards more conservative to keep the maintenance coast lower). Without clear 'rules' what people can expect from a LTS-like build and what they can not, it doesn't make sense.

I'll guarantee that it will be sufficient.. We even let US citizens write our documentation.. Honestly.. A bunch of people (including me) are not native native english speaker (and writer) so we'll never have 'the perfect' documentation.. But it's not the marketings department here writing some fancy stuff for the next hot shit.. It's that others understand how to do it. So as long as others can follow the instruction after your writing everybody will be fine with it. And if it's understandable or not can be tested by letting someone build under vagrant who didn't build before. that's just the old text we had there as well.. (but there are rumors that even some devs here sometimes build on native hosts - shh.. it's still not recommended. ) https://github.com/armbian/build/commit/da028f1ca3b4fa073e866e6d1461832f85f0254c#diff-04c6e90faac2675aa89e2176d2eec7d8L13 we just don't have that branch anymore (dev branch of buildscript).

confidence got denied by looking into sources.. :-/ especially the android related stuff (https://gitlab.com/friendlyelec/rk3399-android-8.1) cause it seems to be the only repositories which are open around m4 v2... U-boot seems to be some 2014.x version (don't know it this is part of the normal rockchip u-boot package for an android build or just some random mess I don't understand - I assume it's a rockchip sourcedrop from the commit history - e.g. none except the few ones from friendlyelec added on top of it). Honestly I'm surprised (and not the good way). I guess (since rockpi images boot), we can base an u-boot defconfig based on rockpi. @mindee are the sources for more recent u-boot versions (newer than 2014 based one from the android 8.1 package) not available for the board yet? Did I do a mistake and not find it? Or is it not planed to release? For those running friendly core on it, can you provide a uart boot dump? I would be interested which version of u-boot they use for everything except the android they provide. Never the less I'm (still) confident that we can provide initial support to the board soon for a 4.4 legacy and recent mainline-ish kernel as well. I just didn't feel as comfortable to create those patches to the buildscript without having the hardware to test if it boots at least.

not Igor but I can help here.. https://github.com/armbian/build/blob/259a0bf5fe3bc9a20709597e43f18421aa3ae4ed/config/sources/rockchip64.conf#L8-L9 The Rockpi uses ayufans u-boot which is not upstream (it's based on rockchips u-boot). The former nanopis are supported by upstream u-boot (DDR3 or normal DDR4 should be supported for RK3399 iirc). There were a few attempts so that upstream u-boot can handle lpddr4 but the last I heard is that it's not stable yet (someone from the forum was involved but I don't remember the name.. ). Patch in the defconfig and the DT into ayufans u-boot should be an easy task (I'm confident that friendlyarms is based on the same one.. so not much to patch around). unfortunate I would happily dive in (if there's still a spare one)..

vanilla... (and all bsp kernels are called chocolate ) stable might not be a good term here. ask the 'sunxi-gang' e.g. @martinayotte and @jernej. I think the 'glue it together' part is done quick.. Testing might be the harder part here.

Best so far I would say. - Legacy - Stable - Dev Or we have a 'policy' change (I would be slightly in favor). Keep the current 'next' branch on a LTS kernel and move only with dev. Currently all our 'favored' platforms are more or less mature in mainline (RK3399, Sunxi, and as far as I can understand meson - btw if we go for it, I'll add the missing bits for mt7623 as well currently it doesn't need many patches). So I see a chance here to bring those together (it's still a bunch of work but it might work - for sure every patch which touches non SoC specific files must be checked). I'm quite sure this isn't a small goal (bringing all kernelconfigs together and test if they're not incompatible to each other), so we might start on 5.3 with the goal to get it mature with the next LTS kernel (5.4 should be the next LTS). this seems to be a great goal.

https://github.com/buildo/react-components/pull/1367 Conclusion: we definitively need a nemobot as well here...

yeah this looks really familiar to u-boot 2014 from MediaTek.. including the common.h (I had a lot of fun and a lot more of frustration back then, cause this one at least understands FDT by default.. ) if you just want to mess around with u-boot (e.g. trying safe bootparameters without recompile u-boot the whole time or hack in the u-boot shell), scriptload (actually the way armbian boots as well) is a great tool. https://github.com/chwe17/u-boot-mt/blob/f5916a4c6d0ad8acf0e9b8fe3f649425272f5e6a/include/configs/mt7623-bpi-r2.h#L393-L397 especially cause everything inside this u-boot is defined as fatload even if ext4 should be available from the config you mentioned (there would be a proper way to probe if it's fat or ext but hell, it never worked well enough when I tried it ). with scriptload you can try to write a proper procedure to boot up your board. I think that was the guy from MediaTek sending their adjusted linux drivers upstream to u-boot to get it finally supported by u-boot. well this would mean to look into the driver sources as well.. Something I don't do for more than one reason.. First you'd to check the code license from the code drops you got a bunch of it has no authorship and license headers mentioned. Second, I honestly don't believe it's our job to do the dirty work of getting their stuff upstream. I'm currently fine with a just spend enough time to get it working when it comes to u-boot. Ideally we would have only SoC's with upstream u-boot support but it tends to take to much time for the (more) important stuff (e.g. a proper mainline kernel support.. ). Any comments on my current understanding how this thing boots?

well this part will be for sure off topic but: https://www.gnu.org/licenses/old-licenses/gpl-2.0.txt thankfully I don't have to give legal advises but I think you can have a 'confidential' document how to use your GPL derived code (and documentation is somehow a 'how to'). Is it a practice I support, for sure not but it is what it is. Luckily some companies decided to push further into making such stuff public (e.g. rockchip having a wiki, and opened a bunch of their kernelcode so that we can really work with, others like mediatek started to actively push their drivers to mainline as well - I hope others follow this way, it makes their SoCs just more useful in the long term). But back to topic, I might dive into the w2 adventure in the future I just need to sort out a few things cause I'm definitively not up to date here (actually this was some sort of a follow up after my work on the mt7623n which worked quite well in the end - well nobody here was really interested in the work in the end, but I got it more or less properly working with a mainline kernel in the end). As far as I understand the boot-process (and please correct if I'm wrong). There's a 32 bit bootloader (u-boot) supposed to chain-load the 64 bit u-boot somewhere in between the tools from them also provided the pieces of ATF needed (it's not really an isolated atf source right? this must come somewhere out during u-boot building I guess but I didn't dive into those sources right now to figure out what happens here and I'm rather unfamiliar with ATF, ). Finally, the 64 bit u-boot fires up the kernel with current limitations that this has to sit either in a squashfs or fat? (here things get messy in my head ). And there's some sort of rescue tools if you mess up with the SPI NOR to recover if you mess up there (before I really want to dive into this, I'm a uboot plumber by try and error not by complete understanding and for sure I'll mess it up more than once... ). For me as a armbian oriented plumber, it's obvious that the final u-boot needs to be able to load a kernel and a rootfs from an ext4 (I assume a 2015 u-boot should be capable to learn this, it's just a bit of tweaking needed (the mediatek u-boot for mt7623 was a 2014 version and finally also able to do this, wasn't that much work, once you figured out how outdated u-boots work). I won't repeat a fat adventure as I did with my experiments with the RPi 4 on 64 bit images built with armbians buildscript (yes, this stuff was never published and Images were never distributed, so no GPL issues here.. - and just in case someone asks, it's not gonna happen that I'll push this on github, too much mess in the buildscript to get out a barely working image - probably don't even have the branch anymore). But at least I need some hints how to recover a broken SPI once I'm there before trying heavy modifications on this side. So if one of you can summarize this a little bit, I would like to read it.

you might ask @Lion Wang or @Nora Lee if they can give you access to their newest repository on github. the repo contains a bit of documentation from RTD how the bootloaders are supposed to work (e.g. recovery etc). It seems to contain also the sourcecode for the SPI part of the bootloader (I'm not up to date how much of this code is currently 'in the wild' so please forgive me if it only contains stuff you already know).

well it took a while to figure out that there are only a few desktop recording programs for wayland.. and without wayland a 13 inch full hd display sucks as desktop, due to x can only have 100% and 200% (both of them suck with gnome, wayland is capable of 125% which is just perfect). A small hint here.. gnome wayland on ubuntu doesn't record properly with a 125% zoom, so for recording you've to go back to 100% to get something 'useful' out of it. well I better don't tell you how long I normally need to prepare presentations.. A good training is "spin the powerpoint", a 'game' we quite often played at university.. basically, you see the slides the at the same time as your audience (cause someone else wrote it). It needs a basic understanding of the topic, but you learn a lot about free speech (not the american meaning of it). You must also consider that your audience normally doesn't know your topic well, which gives you some freedom in the presentation (it doesn't have to be 100% 'scientific correct'.

Freshly from the not official Armbian studios: Armbian the last 2 years I would assume that even on a conference those topics wouldn't be presented: it's a special use case, and the question comes up on a weekly to monthly repetition pattern. that's simply user-side stuff, mostly unrelated to armbian as a project, but as a NAS example, OMV is quite common under armbian users cause the ARM maintainer of OMV is @tkaiser. that's what changelogs are for. I assume the major reason the video is on the page is not that we have a video but because it's a side-product of the conference. So chances to get a new video are rather low, except there would be a new talk about the project in another conference. And for such a talk I would propose other topics, like how to engage people to contribute or how to deal with different opinions etc. But luckily for you, most of your questions can be answered with the search engine. and with text to speech it might feel like a video.

with the green + in the right upper corner you can follow a thread without even writing in it. just out of curiosity.. what use-case do you have for the board?

check the userspace, maybe it was limited to 1.8GHz back then I don't know, check the DT (means decompile) to ensure we had the upper opps activated back then. It depends on when the image was built. Maybe there was a reason why we didn't had the higher opp's (could be powering is critical due to 'dumb' USB-C).

http://opensource.rock-chips.com/wiki_Main_Page mostly around px30 cause it's the most similar one. the kernel adjustments are likely minor, rockchip64 might be probably the best starter, for sure a bit kernelconfig adjustments are needed. maybe a few patches cause ayufans repo didn't merge everything from rockchip 4.4 adjustments in u-boot are for sure also needed. obviously a board, a proper dt and a bit of time to see what raxda changed in their kernelfork for this board. well, code which you'll have to write is likely below 100 lines of code.. but figure out what you'll have to patch and merge from other kernels to ensure things work properly (on a kernel level) can still be hours of work.

https://github.com/armbian/build/pull/1482 Far away from 'supported but basically the camera can work without loosing dt overlays. For the userspace part, once this one get merged you're on your own.. I can't provide more help than that. From a kernelside the cameras work both without crashes, they're patched to match the asus repo and you can switch between both.. Get the right commands and everything else sorted out to make them useful in userspace is a different story, and that's definitively not my story. I already spent too much time for this. turned out that a small commit in 2018 made the trick and a bunch of crappy patching.

Nevermind, their development branch seems to have it.. https://github.com/TinkerBoard/debian_kernel/blob/c2fc097dfb04bfb5780c58137e94f7c8eab64b19/arch/arm/configs/miniarm-rk3288_defconfig#L547 https://github.com/TinkerBoard/debian_kernel/blob/c2fc097dfb04bfb5780c58137e94f7c8eab64b19/arch/arm/configs/miniarm-rk3288_defconfig#L401 hmm now let's see what else is needed..

welcome back commander.. it's being quite some time. if.. and that's the if.. they have overlayFS and isp1 working on the same image.. then yes.. I'll give it a shot.. let me check their sources. Edit: seems to still based on isp10 https://github.com/TinkerBoard/debian_kernel/blob/de5c3c4a543c45dee4b102c879fb52c8604d78a3/arch/arm/configs/miniarm-rk3288_defconfig#L499

probably our posts are more or less written at the same time so you missed it.. @JMCC multimediascript is great, and once the camera would work from kernelside.. it provides more or less everything to get it working from userspace side.. But well.. it's the kernelside which doesn't work. no wonder, there's no driver trying to probing it.. Didn't had neither.. You'll grow over time.. just throw enough time to a project and things will progress.. I'm more or less done with the ISP camera for the tinker, I tried, I figured out what causes the issue, it got reported and then ignored: https://github.com/rockchip-linux/kernel/issues/98#issuecomment-396422765 There's not much more I'm willing to do to get this fixed.. If I would get 5$ per hour for this issue I could probably buy 2 SBCs in this price range. It should be, it is reported (see thread above) but I've not tested it. And friendly arm uses different camera modules, whereas for the RockPi nobody tried it, and I would assume you've to deal with dtb to get it working.

not an official.. and as long as there's no interest from rockchip to address it there's not much hope that this changes. The threads related to it are those: iirc it could work with some kernel modifications which then would not allow to use dt overlays.. which is on the other hand needed to support multiple cameras.. and it was a rabbit hole to get it booting (I know it, cause I went down this hole and wasted a few evenings and nights on it with constant sd-card swapping just to figure out that this one also doesn't boot until I got a booting one). for RK3399 the situation is slightly different, iirc it should still rely on isp10 (whereas rk3288 moved to isp1 - two different drivers developed by rockchip to access the csi) which should work but I never tested it (actually during development I saw something that rk3399 should also be supported by isp1 but I can be wrong on this). At least with isp10 they had success..

well that was back in the days where we were really excited about every rk3399 sbc and immediately supported them cause cool devices.. The board starts at ~70$ (1gb) up to 100$ (4gb) which is okay.. I like that they sell expansion boards for the m.2 slot. the fact that the board has no ethernet without adding a carrier (and I didn't check if a carrier with ethernet exists) is a bummer.. This might be an interesting sort of SOM for small series high price devices but not a casual SBC for the average user here. But nevertheless, I hope the few hints for @Hijax may help him to integrate csc support for it. As long as he can provide a sane integration of the board into the buildsystem, I don't see a reason to reject such a PR. Obviously it's then up to him and other contributors to keep those patches alive. Otherwise csc support doesn't live long for it. Reminds me to the idea of having a staging like structure (https://lwn.net/Articles/324279/) in our buildsystem for csc, eol targets so that we can sort out related patches easily in case they break supported boards. But well, that's one for a different thread..

ahh.. these guys which actually have a armbian logo on their website: https://www.96rocks.com/ but never showed up here? Well.. no dev has it.. and they claimed armbian support before the board was even available.. kernelconfig respectively boardfamily has to be either rockchip64 or rk3399.. Even as csc I don't want to see a third rk3399 boardfamily.. look at the related sources files as well.. for atf you'll need to tweak it maybe.. if possible add it to the rk3399 branch, cause it relies on upstream u-boot.. In case ram doesn't allow it switch to rockchip64.. iirc lpddr4 is not supported by upstream yet (but wip).. but ddr4 and ddr3 should be.