chwe

Moderators
  • Content Count

    1281
  • Joined

  • Last visited

2 Followers

About chwe

  • Rank
    Embedded member

Profile Information

  • Location
    Switzerland

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. the 3 pins near to the left corner look like an UART (RX/TX/GND) I would gave those a try, in case you've no further schematics/infos.. to see if you get some sort of a bootlog.
  2. the RPi isn't a board I look long enough to it.. Glue it together and hopefully you don't have to spend more time with it at all..
  3. this thing has two bootloaders right? u-boot 1 (32bit) and u-boot 2 (64bit).. cause the one found on their Repo (seems to be a 2015 version) should understand ext4: https://github.com/BPI-SINOVOIP/BPI-W2-bsp/blob/d5eea07747a56fe1c12ce6456a26667191996b72/u-boot-rt/include/configs/rtd1295_common.h#L293-L301 It learned it on Sep 13, 2018 (https://github.com/BPI-SINOVOIP/BPI-W2-bsp/commit/c8e8e9cea4e84934744a100727975cd912f1fc73#diff-415658f491a52b802eb9ee6bbb94501a) so likely that my version has an outdated one preloaded. I really didn't follow the RTD stuff a while.. It's similar outdated to the MTK on the R2 in the beginnings.. But at least.. Mediatek did their homework to upstream u-boot and kerneldrivers so that you get a 'fully' working board with unpatched mainline kernel.
  4. is UART on testpoints there? Honestly, I never soldered anything to a Pi zero.. They got a camera, a quick and dirty case.. a well.. one got a SPI thingie attached to it (soldering wires directly to the pins.. ) In fact it is A RPi Zero without pinheader, but with 1GB ram, open bootloader, ARMv7, and 4GB NAND (which nobody will use anymore.. ).. And I think I bought it roughly 10 years ago? ahh and completely forgot.. it has a fullsize USB A and a small barrelplug for powering..
  5. just look at the small gif video.. they mostly use the white grey difference for navigation.. and the distance between two white stripes where the one car changes the track is a big longer.. In science you call this 'slightly optimized conditions'... (normally an indication that the told story didn't happen the way you try people to believe it was - some suuuper secret stuff here, the story is quit often different to the one you tell ) btw. https://www.nytimes.com/2019/06/15/us/politics/trump-cyber-russia-grid.html I would probably not start a "who has the longer one" when it comes to power grid with russia.. Not sure who pays the higher price here... reminds me to the statement of the former german minister of defense:
  6. I think this rule will just end in bloating all the other parts of the forum.. can we activate a quizzie instead? something like.. for dev you've solve this questions.. not sure but I assume it was solved for mainline.. The 4.4 kernel for the RockPi didn't get much love.. Anyway.. the board is WIP so errors are expected.
  7. yes.. same on position 0 C1:80000000 C2 ? C3hswitch frequency to 0x00000046 frequency divider is 0x00000080 switch frequency to 0x00000046 frequency divider is 0x00000004 switch to SDR 8 bit switch bus width to 0x00000008 bits success hwsetting size: 00000BC0 C4 f 5-5 s_f 5-5-2 Goto FSBL: 0x10100000 switch frequency to 0x00000046 frequency divider is 0x00000080 switch frequency to 0x00000046 frequency divider is 0x00000004 emmc_cid[3] = 0x997418B8 emmc_cid[2] = 0x76F60152 emmc_cid[1] = 0x34454D47 emmc_cid[0] = 0x38000115 switch bus width to 0x00000008 bits success DEVICE_TYPE = 00000057 emmc_sec_count = 00E90000 switch speed to 0x00000002 success switch frequency to 0x000000A6 frequency divider is 0x00000000 1st TX_window = 0x7FFFFFFE 1st phase TX VP0= 0x0000000F RX_window = 0xFFFFFF80 phase RX VP1= 0x00000013 Welcome to FSBL ... [FSBL] Warm Boot: 0x00000000 [FSBL] Secure: 0x0000BEEE [FSBL] Flash Type: 0x00000002 [FSBL] DCache Enable: 0x00000000 [FSBL] SVP = N tee_ltc_alloc_mpa init ... malloc_add_pool init ... ********** FW_TYPE_GOLD_TEE ********** FW Image to 0x10200000, size=0x0007A9E0 (0x1027A9E0) FW Image fr 0x000C3600 ********** FW_TYPE_GOLD_BL31 ********** FW Image to 0x10120000, size=0x000062A0 (0x101262A0) FW Image fr 0x0013E000 ********** FW_TYPE_BOOTCODE ********** FW Image to 0x00020000, size=0x00088BA0 (0x000A8BA0) FW Image fr 0x00020E00 md copy audio bin VERBOSE: bl31_setup NOTICE: BL31: v1.2(debug):a6c9ab6 NOTICE: BL31: Built : 15:16:22, Apr 27 2017 INFO: BL31: Initializing runtime services INFO: Start to init service std_svc INFO: Finish to init service std_svc INFO: Start to init service opteed_fast INFO: Finish to init service opteed_fast INFO: BL31: Initializing BL32 INFO: TEE-CORE: TEE OS v2.1 INFO: TEE-CORE: TA RAM slim vesion. INFO: TEE-CORE: tee os version : 0 INFO: TEE-CORE: OTP tee os version : 0 INFO: TEE-CORE: chip_rev_id : 30000 INFO: TEE-CORE: check golden fw : 0 INFO: TEE-CORE: Loaded normal F/W INFO: TEE-CORE: tee os version check pass. INFO: TEE-CORE: Initializing (b2aa60f-dev #1 Mon Aug 28 13:42:14 CST 2017 aarch64) MESSAGE: [0x0] TEE-CORE:tee_otp_get_hw_unique_key:49: ************************ tee_otp_get_hw_unique_key chip id: 30000 MESSAGE: [0x0] TEE-CORE:tee_otp_get_hw_unique_key:54: ************************ tee_otp_get_hw_unique_key used Kf INFO: TEE-CORE: teecore inits done INFO: Core_0 TEESMC_OPTEED_RETURN_ENTRY_DONE INFO: Core_0 got optee_vectors (0x1020093c) INFO: BL31: Initialized BL32 INFO: EXIT BL31 INFO: bl31_to_kernel: kernel_resume_entry = 0x1e000 INFO: bl31 jumps to EL2: LK entry welcome to lk/MP boot args 0x2 0x0 0x0 0x0 INIT: cpu 0, calling hook 0x603e8 (version) at level 0x3ffff, flags 0x1 version: arch: ARM64 platform: RTD1295 target: RTD1295 project: RTD1295 buildid: 81C95C5_MON_SEP__4_01:41:29_CST_2017 initializing heap calling constructors initializing mp initializing threads initializing timers initializing ports creating bootstrap completion thread top of bootstrap2() INIT: cpu 0, calling hook 0x5ee30 (sysparam) at level 0x70000, flags 0x1 INIT: cpu 0, calling hook 0x743e4 (lwip) at level 0x70000, flags 0x1 creating bootstrap completion thread for cpu 1 creating bootstrap completion thread for cpu 2 creating bootstrap completion thread for cpu 3 initializing platform rtd129x_pwm_pin_mux default value 0 PLL_EMMC1 = 0x00000003 switch frequency to 0x46, divder to 0x80 switch frequency to 0x46, divder to 0x4 switch_bus: width = 0x00000002 switch speed to 0x2 success switch frequency to 0xa6, divder to 0x0 PLL_EMMC1 = 0x0000137b switch erase_group_def to 0x1 success sec_count = 0xe90000 Erase Unit Size = 512KB * 0x1 factory_init, factory size:0x400000 MMC [FAC] No factory data in mmc0 sysparam_scan_factory: read SYSPARAM from factory fail!! Bring UP slave CPUs geVEVEnRRBBEOiOSRtBSiEEaO:lS :iE :bb ll3zb3li1n1__gs3 e1s_testtuaeptur TOITNpO II NCCENOETII:TC : : E B:B LcLp 3B3Lu1:1 30 :,1v: c1vv1a.1l2..(2l2i(dde(bnba60eggbu)g :)uah:6cgo9)a6:ocaak96abc6 9 4 bx dCcCOO6TcITI E E(N::r O8T 1I 6CBELB38:L ) 1 aB: 3tB 1uLli3:el B1v:te uB:i lu 1li5t0l t:0 x 11956:0: 11:520260,::10 2,A6p :r2f2,2 l2, Aap7gr As pr2 0720 x12 271 7 r F78N2I011 :IO NI:REFNOAFL: TO :EK B LR3T 1 L B8:L 3 1B1L6:38I 1n@ iI0tnix9ia8lti0izazg i0i nI00ni se tirinaugl nirtziumnitneig sm reeu rnvsetiricvemise c rvFIsN : OiIc:NeF s O SI Nta FOSr:tt a rto t Stionta itrin ti sett ros vieincrivei ts cste de_rstsvidvc_ce sv dFI tN _OIsNv:F cO : I FiN n FFOis:ihn i st ho F tiinnoi itsinh s ittero v seiircniveti s cstede vcssvtdvi_ccs e N Itd : IOsN:vF c O SI N tFa SrOt:t atr ot tSinot iaritnt istet rosv ieicnreiv tic opeste oerevptdi_ceefed a_softpa tse _t dIN :fFOIas:Nt F O I FNi FnFOisi: hn it soh F itinno iistih ns etiort viisecenr iviotc petse ereodpvi_tecfaee sd_otp fta _FIet dN fIaON:sF t O IBLN 3 F1O ::B L I 3ni 1t:Bi L3Ial1:nii zitInniigal tiiBLazli3i2nzg L3 IBgLNF3 BO2: N F 2 ICON:oFr e O: _ 2 C oT rE CeEoS_Mr3eC T__1EOEP TSTEMEECESD_OM_PRCT_EETOEPUTRD_ENE_REDETN_URTERRTNY_U_DERONNN_TEREN Y_T N:E ONN_EFD OO I N zBIOBLN: F3 1O: : IBL ni3 1Bt:Li3a l1Iin:z iItenidialt BiiLaz3eli2d edIL N3B2FOL N 2I XF IOE:NX F OI :T EB LX3 I1ET :3BILIT3N B1FOL N F IO b:NFl O3 :1 _ t bol _31bkel_rt3on1_e_klteo:r_ knkeeerrl:nn eelkl:_e rrn0Beesurl_mnree_els_eunremtrse_yu em=ent_ rR0eeyaxnt l=1rt ye e0k=0x G0 001xe eFEI00 NF1 tIaO:m0i N lF Oy : bCl0o n0 1 r 3oIbl1 lNjFeuOlrm3 1p3 s j:2tuo mp m scE tLf go 2=b: l0E0LL232:4K t en jLutrKmy pse n 2tro y EL : LK entry netif en ip 192.168.100.1 netmask 255.255.255.0 gw 192.168.100.254 calling apps_init() HDMITx_HPD=False ------------can't find tmp/factory/video_rpc.bin tv_system=25 mode=1 Set ACPU share memory ------------can't find tmp/factory/000BootParam.h Default Power-Config EEPROM: SIZE=16384, ADRESS_MODE=2, PAGE_WRITE_SIZE=64, BUFFER_SIZE=16 PMIC is gmt,g2227 starting app rtkboot ---------------LOAD NORMAL FW TABLE --------------- fw_desc_table_start = 0x00620000 fw_desc_table_ddr_base = 0x0x12418f70 [ERR] rtk_plat_prepare_fw_image:Signature() error! ---------------LOAD NORMAL FW TABLE --------------- fw_desc_table_start = 0x00620000 fw_desc_table_ddr_base = 0x0x12418f70 [ERR] rtk_plat_prepare_fw_image:Signature() error! ---------------LOAD GOLD FW TABLE --------------- fw_desc_table_start = 0x00628000 fw_desc_table_ddr_base = 0x0x12418f70 [ERR] rtk_plat_prepare_fw_image:Signature() error! entering main console loop Realtek> starting app eeprom starting app pmic cmd_pmic_entry: set DC force PWM pmic_testing returns 00 INIT: cpu 2, calling hook 0x22840 (slave_cpu_spin) at level 0x3ffff, flags 0x2 INIT: cpu 3, calling hook 0x22840 (slave_cpu_spin) at level 0x3ffff, flags 0x2 INIT: cpu 1, calling hook 0x22840 (slave_cpu_spin) at level 0x3ffff, flags 0x2 it seems to hang here... with exit I can let it drop to the u-boot shell... some random help command list: net : net toolbox page_alloc : page allocator debug commands heap : heap debug commands hexdump : hexdump memory region help : this list test : test the command processor history : command history bio : block io debug commands novm : page allocator (for devices without VM support) debug commands reboot : soft reset poweroff : powerdown version : print version sysparam : commands for manipulating system parameters dw : display memory in words dh : display memory in halfwords db : display memory in bytes mw : modify word of memory mh : modify halfword of memory mb : modify byte of memory fw : fill range of memory by word fh : fill range of memory by halfword fb : fill range of memory by byte mc : copy a range of memory crash : intentionally crash stackstomp : intentionally overrun the stack mtest : simple memory test chain : chain load another binary sleep : sleep number of seconds sleepm : sleep number of milliseconds crc16 : crc16 crc32 : crc32 adler32 : adler32 bench_cksum : benchmark the checksum routines aes_test : test AES encryption aes_bench : bench AES encryption threads : list kernel threads threadstats : thread level statistics threadload : toggle thread load display loady : Y-MODEM through UART fdt : Flat device tree commands pmic : PMIC commands keyset : for uart mp tool write secure key to factory uart_write : for uart mp tool write mac or sn fastboot : fastboot command factory : FACTORY sub system eeprom : EEPROM commands boot : platform boot command fatload : fatload command usb : usb command cache : cache operation boot_part : r/w boot partition x pwm : Control PWM 0,1,2,3 rpmb : do some rpmb operation chip : detect soc version bdinfo : Board information rtknand : rtk nand commands rtkspi : rtk spi commands rtkemmc : rtk emmc commands 'version': version: arch: ARM64 platform: RTD1295 target: RTD1295 project: RTD1295 buildid: 81C95C5_MON_SEP__4_01:41:29_CST_2017 hmm it seems that this one doesn't understand ext4 as a bunch of old crappy bootloaders.. right?
  8. remember those dirt cheap android sticks you could buy years ago? The MK802.. I knew that I bought one years ago.. but didn't know for a long time that they're equipped with a AW A10... http://linux-sunxi.org/Rikomagic_mk802 Well, seems that they're supported in mainline (u-boot and kernel). __ __ _ _____ ___ ____ | \/ | |/ ( _ ) / _ \___ \ | |\/| | ' // _ \| | | |__) | | | | | . \ (_) | |_| / __/ |_| |_|_|\_\___/ \___/_____| Welcome to Debian Stretch with Armbian Linux 5.1.7-sunxi System load: 2.26 1.12 0.43 Up time: 2 min Memory usage: 4 % of 999MB IP: CPU temp: 11°C Usage of /: 4% of 30G ... root@mk802:~# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU 21:44:11: 1008MHz 1.57 82% 30% 20% 0% 30% 0% 11.6°C 21:44:16: 1008MHz 1.68 19% 19% 0% 0% 0% 0% 10.9°C 21:44:21: 1008MHz 1.55 13% 13% 0% 0% 0% 0% 11.4°C 21:44:27: 1008MHz 1.42 22% 21% 0% 0% 0% 0% 11.2°C 21:44:32: 1008MHz 1.31 17% 14% 1% 0% 0% 0% 11.6°C 21:44:37: 1008MHz 1.20 21% 20% 0% 0% 0% 0% 11.0°C 21:44:43: 1008MHz 1.11 13% 13% 0% 0% 0% 0% 8.5°C well the thermal is a bit sloppy.. in fact the SoC was roughly 60°C at this time... and soldering UART to test points isn't as fun.. but it works and now imagine this board with sata instead of HDMI wired out.. (well maybe with the A20 instead of A10)..
  9. well.. it's your fault.. Terminal ready � C1:80000000 C2 ? C3h SD card is not detected !! switch frequency to 0x00000046 frequency divider is 0x00000080 switch frequency to 0x00000046 frequency divider is 0x00000004 switch to SDR 8 bit switch bus width to 0x00000008 bits success hwsetting size: 00000BC0 C4 64b LK EL3: arm_gic_init welcome to lk/MP boot args 0x20000 0x60 0x98007800 0x0 INIT: cpu 0, calling hook 0x603e8 (version) at level 0x3ffff, flags 0x1 version: arch: ARM64 platform: RTD1295 target: RTD1295 project: RTD1295 buildid: 81C95C5_MON_SEP__4_01:41:29_CST_2017 initializing heap calling constructors initializing mp initializing threads initializing timers initializing ports creating bootstrap completion thread top of bootstrap2() INIT: cpu 0, calling hook 0x5ee30 (sysparam) at level 0x70000, flags 0x1 INIT: cpu 0, calling hook 0x743e4 (lwip) at level 0x70000, flags 0x1 creating bootstrap completion thread for cpu 1 creating bootstrap completion thread for cpu 2 creating bootstrap completion thread for cpu 3 initializing platform rtd129x_pwm_pin_mux default value 0 PLL_EMMC1 = 0x00000003 switch frequency to 0x46, divder to 0x80 switch frequency to 0x46, divder to 0x4 switch_bus: width = 0x00000002 switch speed to 0x2 success switch frequency to 0xa6, divder to 0x0 PLL_EMMC1 = 0x00000003 eMMC Error: Response timeout eMMC Error: Response timeout eMMC Error: Response timeout eMMC Error: Response timeout eMMC Error: Response timeout switch erase_group_def to 0x1 success sec_count = 0xe90000 Erase Unit Size = 512KB * 0x1 factory_init, factory size:0x400000 MMC TIMEOUT __wait_done: addr=0x98012044, mask=0x00000008, value=0x00000008 TIMEOUT __wait_done: addr=0x98012424, mask=0x00000002, value=0x00000002 eMMC Error: Response timeout [FAC][ERR] Get factory header from mmc0 failed TIMEOUT __wait_done: addr=0x98012044, mask=0x00000008, value=0x00000008 TIMEOUT __wait_done: addr=0x98012424, mask=0x00000002, value=0x00000002 eMMC Error: Response timeout [FAC][ERR] Get factory header from mmc0 failed [FAC] No factory data in mmc0 sysparam_scan_factory: read SYSPARAM from factory fail!! Bring UP slave CPUs initializing target INIT: cpu 0, calling hook 0x40cdc (r8168) at level 0x90000, flags 0x1 r8168: REALTEK RTL8168 @0x98016000 Realtek GBE Family Controller 32 mcfg = 0024 netif en ip 192.168.100.1 netmask 255.255.255.0 gw 192.168.100.254 calling apps_init() HDMITx_HPD=False ------------can't find tmp/factory/video_rpc.bin tv_system=25 mode=1 Set ACPU share memory ------------can't find tmp/factory/000BootParam.h Default Power-Config EEPROM: SIZE=16384, ADRESS_MODE=2, PAGE_WRITE_SIZE=64, BUFFER_SIZE=16 PMIC is gmt,g2227 starting app rtkboot ---------------LOAD NORMAL FW TABLE --------------- fw_desc_table_start = 0x00620000 fw_desc_table_ddr_base = 0x0x12418f70 starting app eeprom starting app pmic cmd_pmic_entry: set DC force PWM pmic_testing returns 00 INIT: cpu 3, calling hook 0x22840 (slave_cpu_spin) at level 0x3ffff, flags 0x2 INIT: cpu 2, calling hook 0x22840 (slave_cpu_spin) at level 0x3ffff, flags 0x2 INIT: cpu 1, calling hook 0x22840 (slave_cpu_spin) at level 0x3ffff, flags 0x2 TIMEOUT __wait_done: addr=0x98012044, mask=0x00000008, value=0x00000008 TIMEOUT __wait_done: addr=0x98012424, mask=0x00000002, value=0x00000002 eMMC Error: Response timeout [ERR] rtk_plat_prepare_fw_image:Read fw_desc_table_v1_t error! (0x3100, 0x1, 0x0x12418f70) ---------------LOAD NORMAL FW TABLE --------------- fw_desc_table_start = 0x00620000 fw_desc_table_ddr_base = 0x0x12418f70 TIMEOUT __wait_done: addr=0x98012044, mask=0x00000008, value=0x00000008 TIMEOUT __wait_done: addr=0x98012424, mask=0x00000002, value=0x00000002 eMMC Error: Response timeout [ERR] rtk_plat_prepare_fw_image:Read fw_desc_table_v1_t error! (0x3100, 0x1, 0x0x12418f70) ---------------LOAD GOLD FW TABLE --------------- fw_desc_table_start = 0x00628000 fw_desc_table_ddr_base = 0x0x12418f70 TIMEOUT __wait_done: addr=0x98012044, mask=0x00000008, value=0x00000008 TIMEOUT __wait_done: addr=0x98012424, mask=0x00000002, value=0x00000002 eMMC Error: Response timeout [ERR] rtk_plat_prepare_fw_image:Read fw_desc_table_v1_t error! (0x3140, 0x1, 0x0x12418f70) entering main console loop Realtek> no.. i completely forgot about this one. W2 without SD-Card
  10. I would definitively not put all these stuff on one board... If something messes.. your entire network will be in trouble including all the data on the nas. check the PSU, if it's only that.. the board can still serve as a NAS, and thanks to the new patches for its sata implementation.. it shouldn't be a bad one.. rk3399 is powerful for a lot of your other tasks.. but still wip.. and things might change here.. means the risk is higher that things break as well. for the blog/webserver stuff.. As long as you don't expect much visitors there.. a cheap H3 might do it.. and for pihole no idea.. probably one with GbE, not my field..
  11. hmm.. the bits to grap this information are here and there.. It needs time to summarize them.. It's mostly a boring task to summarize them, and it comes with *random board*... It's not only the RPi which some random people would like to see supported.. And normally it comes with.. why is *random board* not supported not, based on my attempts, *random board* could be an new interesting platform to support, this, this and this is currently working, here there and there I'm struggling to get things working, I would like to share my work and hope that you can give me some hints to fix them.. Good examples how things can go in the right direction: and a few others (shamelessly I would say that the mt7623 platform bring up thread of mine is also a good one, even when things are on hold since a long time). It's a time vs. worthiness decision and @TonyMac32 decided to keep it short (which is completely fine, I would do it as well if I wouldn't need a break from thesis writing.. ) not really, there are still cases where the RPi shines. It's not as expensive, it's available more or less everywhere.. so if you need a board immediately it might be worth to think about the RPi as well. I've one on my own for a camera related project, where the power is sufficient.. I've set 2-3 up for projects of colleagues.. They can't manage them on their own, and I don't want to deal with those boards anymore.. So an RPi is a save bet.. I can setup a crontab for updates (so that it's not one of those sloppy IoT devices used in botnets - or at least not more than the other RPis around the world) and if they mess up things I've a bash scripts which modifies their 'default raspbian' to their needs (there's absolutely nothing fancy at their needs, it could probably be solved with a ESP8266). I didn't want to wait until another boards makes it through customs and fear that I've to pay some additional taxes.. So going to the next local store, buying a RPi and the most ugly case I could find and a reliable SD-Card and everyone was fine. The Pi is Ok and has its value.. generally spoken it's just not attractive to the developers here, therefore they spend their time on stuff they're interested in.
  12. one of the maintainer of this project (dealing with rockchip and amlogic)? Who has not the right to remind you that the discussion is pointless? The decision that current RPis are note supported by armbian was made a long time ago and it still stands. And for the who started first on throwing dirt to each other here doesn't matter to me.. If it's not working on a acceptable level I'll simply end it (without needing dirt.. but with something I don't like, means closing the thread). and if you go through this whole thread.. You get some 'objective' and probably also a lot of subjective answers to that.. And just a last one.. Guess what happens if a platform gets added in which no developer has an interest in? Exactly, nobody cares about enhancing the support for it.. Means spending hours of hours of their spare time to make things better, following upstream to pick up stuff like this: https://lkml.org/lkml/2019/5/20/431 integrate it and test if it solves the crippled mailbox system the RPi has? Dealing with the blob bootloader the RPi needs and check after every update of this blob if the new one behaves similar or if they add new thermal throttling behavior which was barley annotated when the RPi3b+ came out? This stuff needs time. It's not only adding a few lines to the buildscript and you're done.. And further Pi1 and Zero is ARMv6, pi 2 is ARMv7 and some ARMv8, pi3 is ARMv8. By default we provide userspace matching to CPU architecture.. It will be a nightmare to explain again and again (and again) that a RPi2 image might not work on a RPi3. That by using RPi3 a bunch of the things which make the Pi useful (e.g. the decoder stuff) might not work cause all the userspace stuff isn't armhf on armbian for 64bit CPUs. With Raspian, there's a decent image out for RPis, it gets updates it supports the hardware. It's not armbian but also a debian derivative. And if, for whatever reason you want a Armbian userspace but don't want to deal with kernel work nor bootloader etc. @tkaiser provides a OS layer to frankenstein a 'Armbian on RPi' together (https://github.com/ThomasKaiser/OMV_for_Raspberries). And if you want to deal with kernel as well.. Fork armbian, add the needed configs for kernel bootloader etc. Glue everything together and deal with the FAT partition the RPi needs for its bootloader (basically the buildscript should allow such FAT partitions). Find a suitable Kernel (probably the one RPi provides on their GitHub - or if you really want to deal with it.. go for a mainline) and craft your own image, based on armbians buildscript (it's on github, everyone can fork it). But don't expect that someone does the work for you especially if those people are simply not interested in the currently available iterations of the RPi. And don't expect as well that they always take as much time as I took this time to explain it again and again, when someone shows up complaining that we don't provide Armbian for RPi... I needed a break from writing serious stuff..
  13. might give the 8250 UART driver a try? At least mt7623 got really talky once it was configured properly.
  14. moved to rockchip 3399 (I think it fits better there). https://forum.armbian.com/guidelines not as 100% clear but this counts here as well: https://dl.armbian.com/rockpro64/ we provide a mainline (dev) and a bsp kernel (default) for this board. And their kernelconfigs may differ. @lanefu we might have to fix the guidelines a bit.
  15. I see some decent moderator skills here... @Igor @lanefu we should change his official title here.. btw. if this thread goes back and forth.. I'll simply close it until the first iteration of a not VC4 based RPi is out (or someone wrote a bootloader which allows to boot without binaries provided by the foundation ).