chwe

so a small update for those being impatient... well there's not much to tell as long as there aren't any results yet... Yes I do have the board and started to integrate it.. but currently fail. For those who want to join the board bring up party: UART2 is on the 3 pin pinheader as normally used by RK3399 for debugging.. It seems xunlongs buildscript points to the evb board for the 2017 u-boot when building images. I never used their buildscript, I don't plan to change this and I don't know if images built with it work. It looks cleaner than stuff I saw before but still room for improvements. The devicetree is clearly based on the evb board (nodes which aren't used are commented out e.g. evb's eDP node). Likely not the newest version (see example pin naming just as examples for naming convention. One can be compared with the schematics without even thinking.. the other one is a pain (you can guess on your own which one I prefer).. OrangePi 4 node for LED: led@1 { gpios = <&gpio0 11 GPIO_ACTIVE_HIGH>; label = "status_led"; linux,default-trigger = "heartbeat"; linux,default-trigger-delay-ms = <0> Pinebook node for LED: green-led { gpios = <&gpio0 RK_PB3 GPIO_ACTIVE_HIGH>; linux,default-trigger = "disk-activity-inverted"; default-state = "on"; mode = <0x23>; The u-boot on the board is a 2014 based one (I guess there's a android preloaded on the boards eMMC? - no idea I never connected it to a HDMI screen to actually see what happens). I tried to erase eMMC with the rkdevel tool from command line but it fails (it recognizes maskroom mode when clock of eMMC is shorted - see in documentation of xunlong how to short eMMC, not recommended if you don't know what you're doing!) but somehow I can't erase eMMC then (it worked on a TV box back then but not here). At least rockchips android bsp uses a 2014 u-boot iirc. at least I can't interrupt the 2014 u-boot from a serial debugger connected (15000000 baud) boottime is set to 0 seconds and it's not able or not set as default to boot from SD-card (i tried to build a first image but this one is either nor bootable or the 2014 u-boot just ignores SD card images - an empty eMMC would force brom to fire up SD card and I would see where it fails). after all there's still work to do to get this board running and a not preloaded eMMC would've been nice. @martinayotte if I short eMMC clk to ground does it enter maskroom directly or does it just skip eMMC and tries SD card then? I think you had the same for their first rk3399 based board back then or was it for the firefly? I don't remember anymore. @Jack953 even when first images are here. This will still be early wip cause some cleaning is needed to get the board properly working. Board bring up needs time and it doesn't get better when we rush here...

blind-shot to try to debug doesn't make sense. Without the (full) console log it doesn't make sense to step into this. So first, make sure you connect to the right UART to get the debug output. For the bootorder: https://lists.denx.de/pipermail/u-boot/2017-April/285493.html http://rockchip.wikidot.com/boot-sequence (even when I'm not sure the second one is fully complete, I guess it's mostly achieved over the choosen node) if you look at the sources of radxas bootloader, and we assume that's the one which is on your eMMC: https://github.com/radxa/u-boot/blob/6d910b7f12318e5a5bb8d1b2093fe5a9ba17dfce/arch/arm/dts/rockpi-4b-linux.dts#L26 chosen { stdout-path = &uart2; u-boot,spl-boot-order = &sdhci, &sdmmc; }; in their u-boot eMMC should have priority over SD card. If you now look on our bootloader: chosen { stdout-path = &uart2; }; it's not as clear anymore.. according to rockchip it should look in SD-Card first. But I could be that they achieve this over the choosen node, no idea what happens then if it's not defined there. Also their docs rely on their u-boot. We used a patched one based on theirs.. So another option where things can change. A bunch of variables and things go messy. debugging your issue without a bootlog isn't a option for us. So either you can provide a full bootlog (and that starts a way earlier than when the kernel takes over) or you've to follow @martinayotte recommendation and remove the eMMC. BTW for the rockchip maintainers here (adding @TonyMac32 @piter75) It might make sense to add a proper choosen node to all our DTS files to get a predictable bootorder for all RK3399 boards.

let me fix that... spotting this one (https://github.com/TinkerBoard/debian_kernel/commit/30a8401c2f3851f4e9b46c9d3e8e1138ce8d5b51) to fix camera support for the tinkerboard took me over a year... it happens and when it happens it's IMO not something you should feel ashamed for. iperf3 (combined with a computer/sbc with known good settings) is a great tool to test this. But it's interesting that the settings work well on the legacy drivers but not on mainline.

there's a tool to test this: https://github.com/ayufan-rock64/linux-build/blob/02fae982767ca242009baaf995f7ce64b5d82469/recipes/gmac-delays-test/range-test @tkaiser wrote one too back then.. but I can't remember where I have it anymore.. Nevermind https://github.com/ayufan-rock64/linux-build/blob/02fae982767ca242009baaf995f7ce64b5d82469/recipes/gmac-delays-test/range-test#L3 https://github.com/armbian/build/issues/546

for those interested in a board bring up the kernel DT can be found here (it's the commit bringing the board up, so rk3399-orangepi.dts is the most important here): https://github.com/orangepi-xunlong/OrangePiRK3399_kernel/commit/ca6af5e3a951938bcd2516ed410e1a3173d640d2#diff-a6cab00e04d1f9f954107a5555ea160a this is (likely) the used defconfig for u-boot: https://github.com/orangepi-xunlong/OrangePiRK3399_uboot/blob/6f4a1947dd2e648c36d53dd1410679865c6b257b/configs/rk3399_defconfig this might also be of interest for the first stage loaders: https://github.com/orangepi-xunlong/OrangePiRK3399_scripts/blob/a62950cafa093437f55eb0ed5a846963edbf006f/lib/compilation.sh#L40-L45 it seems xunlong did quite some cleaning of their sources to build proper images.

we might not now what your RK3399 is so maybe you want to be a bit more specific?

as soon as this PR makes it: https://github.com/armbian/build/pull/1646 and images are available on our download page. Or you build one of your own with the PR already applied.

cause Rockchips BSP kernel is a 4.4. All our legacy images for rk3288, (3308), 3328 and 3399 boards are based on this kernel (or a fork of it). if this 'somehow' doesn't end here: https://github.com/armbian/build/pulls it's IMO not much of a difference to have "armbian" or the vendors provided image. It shouldn't be as hard to get it there (at least as csc supported device). The wifi module is the same as for the RockPi (next to USB3 yay) and it's also LPDDR4 (also RockPi 4b). As a first try I would just (try to) boot an Armbian image for the RockPi (this may also answer your questions for a "generic image", I assume you look for a starting point to get your new toy working). Then create a new boardconfig patch in the (hopefully) proper DT information you get somewhere from the BSP package of this board and pray it compiles without issues (even sound should be here: https://github.com/armbian/build/blob/5c9a7ee7fb9c0d89c923b5690383f6d5006efed4/config/kernel/linux-rockchip64-legacy.config#L4303 at least for the 4.4 kernel). Send this back to Armbian and you'll likely end with (at least) csc support for this board. Except the NPU there's not much 'special' on this board so I don't see a reason why support for it shouldn't be straight forward (except the DTS file is such a mess that it doesn't work properly). IMO the most interesting parts for this board are: https://www.aliexpress.com/item/4000055556030.html?spm=2114.12010612.8148356.1.507153c3gsSLM0 https://www.aliexpress.com/item/4000055817743.html?spm=2114.12010612.8148356.6.5538603aixQ6TV camera & 10.1 inch display (both MIPI 4 lane) so that someone finally could work on camera and display support for those boards (I hope/think that they are pincompatible to all RK3399 camera/display outs with 4 lane mipi, e.g. nanopi and ROCKPro64). Actually a part of all RK3399 boards where nobody cared about it until yet.

you may play around this patch here: https://github.com/armbian/build/blob/nanopi-m4v2-u-boot-v2019.10-ddr-miniloader/patch/kernel/rockchip64-dev/rk3399-sd-drive-level-8ma.patch we've some history with SD cards or rockchip... Jusk ask @TonyMac32

these guys chatting on IRC manage to somehow be really competitive in prices for the SBCs they already released. Good look to find "cheap" developers who are willing to deal with a mt6737 to get the code needed to support it upstream. linux-sunxi is somehow a curiosity... there are people which did a lot of the heavy lifting and "the party is still going" more stuff gets mainlined even for the rusty sunxi chips (e.g. encoding/decoding stuff). The only "mobile" chip from mediatek which got a bit of upstream support is the MT6797 aka X20 but even there it's not much. Not even mentioned that you then have to deal with other stuff like lk for boot of those thingies (from all the BSPs I saw, mobile mtk chips use, as most android mobile stuff, little kernel for boot). Then it comes to the, stick to the stuff you're good at. For Pinefolks, they've a proven record in designing hardware around rockchip and allwinner chips, they're familiar with the A64 with multiple boards around it so I guess they get competitive prices when sourcing parts (SoC, pmic, RAM whatever else is needed) to design 'another' board around this SoC (in fact it's just another A64 board with a special formfactor with some additional stuff like a 4g modem soldered directly). Whereas nobody expect Xunlong (from the SBC boardmaker guys) ever did a MT6737 based board. If you offer the same "as every cheap android phone" (means a smelly outdated kernel) then there's no need to call your board somehow libre IMO. For me Libre means that I'm free to load on it whatever I want to load on it. If somehow in the future pine64 is no more, or all the current OSes they try to support with this device go down the drain I can compile a kernel, glue it to whatever the next super high "mobile linux distribution" rootfs and hack around to get the 4g modem working and I still have a working device (I'll still have a upstream kernel at hand and every fancy new linux mobile distribution should be able to deal with a upstream kernel - whereas they might drop my smelly as hell BSP kernel long time ago). Cause it doesn't really matter if pine64 exists or not, the information how to deal with allwinner SoCs is spread around so that you get the missing information. As Xunlong (with the OPI 2g/4g IoT), bananapi (with various boards) and likely others too had to learn the hard way, it's hard to form a community around your SBC if the SoC used isn't already well known in the mafia (aka community ). The 2g-IoT never took off (we purged all the code supporting it, Andreas Fäber from open Suse more or less stopped his attempts to support it upstream), the 4g-IoTdidn't even made it into the buildscript (mostly cause nobody here tried to deal with little kernel for booting - it's a way harder to deal with it than with u-boot cause lack of documentation and decent examples from others how to deal with it). Even the MT7623n (BPi R2) which has a good upstream support (even with upstream u-boot support) is mostly a 1.2 man show (@frank-w managing to keep a patched upstream kernel alive counting for 1, and me counting for the other .2 dealing with getting into the buildscript here - but except a few support questions here and there, the board is mostly "dead" - I've not seen someone else working on it, except @Igor mostly as part of his usual maintainer work dealing with stuff nobody wants to deal with). Sinovoips realtek boards somehow get a bit of attention cause they're found in multiple NAS/TV boxes, kudos to @Staars @chewitt @danman et al, I know the pain of dealing with barely documented stuff - it's not that much fun for a long long time until you get something out of it. These guys try hard (!= tryhards) to glue wings to those SoCs with steady success. I guess, for a project like pine64 it would be an overkill to get familiar with a new platform ("mediatek mobile", which has currently close to no upstream support from the SoC maker upstream - their "router boards" have), funding kerneldevs to get this thing upstream and calm the community cause "nothing" works with upstream kernel in the beginnings. People tend to be nasty when things aren't working perfectly at start, except RPi folks they celebrate every new iteration no matter what works and what doesn't work properly in the beginnings. Maybe @TLLim wants to explain their decision whenever I don't see much of a reason to do so. looking a bit around on their site for maintained devices: all of them have "freedom issues" down to the bootloader. I'd prefer a proprietary display driver (in case this is really true) than a closed bootloader on a proprietary hardware (personal opinion, I've no idea how these guys define freedom, but arm chips tend to have some lowlevel CPUs in the SoC to deal with a bunch of stuff AR100 for allwinner, Videocore for broadcom - okay.. there it is 'slightly different' it controls everything except the stuff it allows you to deal with ). So if the 4g modem is directly connected to the SoC you've basically no idea what these parts of the SoC is doing all the time. And a port can still be possible even when they don't support it. The nice part about "open source" you can fork it adjust it to your hardware and there you go, a free not officially supported version of whatever piece of software you forked for your needs. The same happens to Armbian even when "we" not always like it, or Raspbian (for sure they don't like it ) and a bunch of other projects with releases their sourcecode under a common free software license - as long as you follow the license terms you're free to do whatever you want with it, even when the original writer of that piece of code doesn't like it (not sure if RPi folks like that gpiomem works on the rk3288, or their RPi cam v2.1 with a cryptographic chip on it to avoid cheaper RPi compatible imx219 cameras for the RPi also "works" on the tinkerboard - well they may like it cause they sold at least two of them more, @TonyMac32 and I had to buy one to test it - likely we would never bought one for a RPi ).

cause we patch: https://github.com/armbian/build/tree/master/patch/kernel/rk3399-default no idea, no camera module nor this board at hand (I've a m4v2 but still no camera). for CSI I would rather expect issues than assuming everything is fine.. Just from my own experience.. the module itself supports 4 lane mipi see: http://wiki.friendlyarm.com/wiki/index.php/Matrix_-_MCAM400 now it's a question of driver and DT if you get them working

well if the module itself has wired out the 4 lanes, it's likely only a DT issue to define those 4 lines https://github.com/rockchip-linux/kernel/blob/27f039b43ada8d0301867505ce9a91d8b5c604bc/arch/arm/boot/dts/rk3288-firefly-reload-linux.dts#L319 vs. https://github.com/rockchip-linux/kernel/blob/27f039b43ada8d0301867505ce9a91d8b5c604bc/arch/arm/boot/dts/rk3288-miniarm.dts#L459 likely that on mainline driver the data lines are also configurable via DT. But you need also then a camera module with 4 data lanes and I've no idea how the schematics of those camera modules look like. For sure getting this "properly" working on mainline isn't an easy task. Even on 4.4 kernel the cameras don't work perfectly cause nobody cares. See: https://github.com/armbian/build/pull/1482 during development of the isp1 driver (branch deleted by rockchip but you can grab most of the information here: https://github.com/rockchip-linux/kernel/issues/33) people also used it successfully on rk3399. I assume with a bit of tinkering (e.g. apply the patches to fix the boot issue https://github.com/chwe17/build/blob/21c372631e4dd0a4d011c989c50d3c06667b5d3c/patch/kernel/rockchip-default/320_fix_kernelcrash_with_isp1.patch support for dt overlays in rk3399 4.4 kernel, I think we didn't add overlay support for 4.4, obviously the needed camera drivers and a proper overlay for your cameras). All this would be relatively straight forward if someone takes the time to do it. It's just the question if someone takes this task up and actually tries to get it working.. I only have 2 lane CSI cameras (e.g. RPi cams which may work on the RockPi, for everything else I miss useful CSI cameras...)

well you need a device able to go to this baudrate.. otherwise you'll only get garbage out. as describen in the topic I linked, if all things go wrong.. you can even ssh into a SBC use its UART to connect to another one, called the silly approach (and if you love the insane approach, you can then even uart back to the first one.. ).

... or also shown here:

it is doable no question. But the way raspian configures interfaces differs from ours which adds then additional work to do. I don't know if there are any web UIs for NetworkManager this might then not be exactly the same interface as this one but also work. nothing to feel bad about.. Never the less you can try to port it.. and maybe someone will help you. Only cause I'm not interested in doesn't mean nobody is.

no it's a cli based but should be possible to configure even for a newbie. you may need to write a tutorial with printscreens how to to do it. for me the whole request sounds a bit like offloading your work to us (it seems you sell a product based on armbian, I can be wrong here but it just sounds like that). Armbian is ubuntu/debian + usable kernel (might not be the official definition but it's mine), IMO this doesn't really fit into the project for the following reasons: we had to make sure that both armbian-config and RaspAP will work at the same time (means one doesn't mess the other one up) armbian uses NetworkManager, Raspbian not, so it's not just a few hacks here and there to get this working I don't see much of a use-case for it but a lot of maintenance costs to keep it updated honestly, lack of interest to maintain another piece of software I don't use.

happily we're not a vendor right. would it be nice to have the hashes published somewhere.. of course it would.. it would also be nice to have a unified bootloader on arm which doesn't suck give me headache every time I look at it. or wifi which just works or device tree which actually describes the devices properly and not copy paste gone or boardmaker cares about mainlining their products etc. If you don't trust our images you can still build them yourself. Then you just have to trust that we didn't hide something in the x lines of code to create an image (have fun to review that ). it would also be nice if someone rewrites nand-sata-install.. My attempts so far just made it worse.. He is a bit paranoid ... well 42.zip is still a thing? https://en.wikipedia.org/wiki/Zip_bomb well we had fun to send each other shutdown commands over network in school when I was young (nothing was more insecure than our schools network back then - that's why no teacher trusted it and never had exams on the school computer )..

maybe the drivers are not there. honestly I didn't test much mPCIe stuff on that board back then. you might check https://github.com/armbian/build/blob/master/config/kernel/linux-mt7623-default.config

then feel free to try out someone else's stuff. The instructions are in one place: https://docs.armbian.com/User-Guide_Getting-Started/ or in the FAQ section on the downloadpage. then it would probably make sense that you link the conversations you find. This would give a first impression that you actually did your part. Is it a satisfying solution we have right now? Probably not, but around all the stuff which isn't in a perfect shape using 2 programs for image decompression and writing is probably for most people here on the lower end of priorities. and exactly that's probably the reason nobody touches stuff which works "good enough". probably not, I'm okay when they at least read the getting started and follow the recommendations. Otherwise chances are higher that they end here: https://forum.armbian.com/forum/36-board-doesnt-start/

why not? what on armbian-config is not "end-user" friendly?

https://lmgtfy.com/?q=7zip+image+compression+site%3Aforum.armbian.com&s=g search engine might do it as well.. cause it's google.

Possible? Probably, but it doesn't make sense. The main "work" for this board will be u-boot support (from kernel-side there's not much lifting needed to get it working). We will not add a third bootsource for rk3399. Especially not a outdated 2014 version. So if you really want to do something useful.. just get at least the 2017 uboot working. I don't think this is worth it otherwise (if they didn't mess up something hard, and I don't think they did the rest will just run fine so not much 'testing' needed). I would base one on the RockPi4b defconfig and see if you need to fix things here and there to get it working.

and did you ever look into the sourcecode for this SoC (e.g. bootloader and kernel). I clearly understand why nobody wants to deal with this.. Compared to a 'well understood' allwinner a64.. have fun to build up a community around such a dead chip (in terms of being outdated) somehow motivate them to rewrite and upstream this so that your "freephone" will not be a security nightmare in the future (not that mainline is bugfree, but at least there's an existing chance that they are found over time whereas in a rotten bsp kernel they're likely last forever). I'm quite sure that something like linux-sunxi doesn't happen that often (there was a time when Allwinner offered SoCs with a interesting set of features, for a cheap price and somehow enough sourcecode and documentation reached the needed people to mainline those SoCs - luckily for them, AW SoCs being well mainlined now with minor investments from their side). I'll mix you a cocktail of hormones and half of your body will think you're pregnant. A bit more serious.. IMO that's a bit a stallman-ish point of view. I think there are several levels of free, and indeed things can be more or less free. But that's more a philosophical question. or as a friend always says: "It is, what it is. Describe the result as best as you can and others must decide if they want to false advertise your results to gain attraction" (he's a pessimistic doing in science.. ). For the Pinephone, they try at least to go a good job (e.g. datasheets for all used ICs are linked on the wiki), and they summarize what is used. It is what it is....

Could we make a diff between the two commits of a version bump? If we store those in a dedicated folder it would be easier to make a more detailed change log cause you can see what changed between those.

the driver is here... it's just a question of time to implement it properly.. And the driver itself tends do be a bit buggy see: https://lkml.org/lkml/2019/7/30/1201 I just don't see a reason to implement this into our kernel yet. Due to: It's likely to still have bugs (as by the submitter explained) without hardware accelerated encoding/decoding I don't see much of a gain to use the camera on mainline, the current state of those drivers and their userspace applications are unknown to me (I'm not much of a desktop user guy, camera support for the tinkerboard was added cause it pissed me off annoyed that I don't find the rootcase why this driver hanged the kernel each time). I don't have the hardware to test it (e.g. a nanopi, they use a 4lane csi compared to RPi/rockpi 2 lane, I'm quite sure I would fail on such an implementation without hardware to test) None of the two available camera modules for the nanopi (ov13850, nor ov4689) are mainlined, there's a vo13858 driver there but I've no idea how much those two differ. Even when the initial support was done for rkisp1 for rk3288, the community contribution to enhance the quality (e.g. imx219 aka rpi cam v2.1picture is green cause something with color stuff doesn't work properly - config files have to be loaded from userspace to ensure it gets corrected) seems to be of minor interest. I don't see a big chance that this changes with a driver which is probably in a worse condition compared to the bsp driver (in case of functionality not code quality - the mainline driver goes through the review process). the initial stuff to support the camera on mainline is here, but it's up to someone to apply and test it. Currently I don't think this someone will be myself. But I will help in case questions come up.