chwe
-
Posts
1432 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by chwe
-
-
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.. 
-
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:
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.
-
11 hours ago, TonyMac32 said:
You have used an RPi zero before, yes?
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..
-
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 )
On 6/12/2019 at 12:18 AM, lanefu said:That is NOT how I want to die.
btw.
https://www.nytimes.com/2019/06/15/us/politics/trump-cyber-russia-grid.html
QuoteJohn R. Bolton, said the United States was now taking a broader view of potential digital targets as part of an effort “to say to Russia, or anybody else that’s engaged in cyberoperations against us, ‘You will pay a price.’”
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...
QuoteThe commander of United States Cyber Command, Gen. Paul M. Nakasone, has been outspoken about the need to “defend forward” deep in an adversary’s networks to demonstrate that the United States will respond to the barrage of online attacks aimed at it.
reminds me to the statement of the former german minister of defense:
QuoteUnsere Sicherheit wird nicht nur, aber auch am Hindukusch verteidigt,“
-
8 hours ago, Igor said:
P.S.
You need to have 5 posts to be able to write in developers parts of the forum.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..
8 hours ago, Igor said:IIRC BT was fixed ...
10 hours ago, Schnalli said:4.4.180-rockchip64
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.
-
13 hours ago, Staars said:
Hmmm, this is with (boot-selector) SW4 in position 1 ... i guess?
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 0x2it 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_2017hmm it seems that this one doesn't understand ext4 as a bunch of old crappy bootloaders.. right?
-
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°Cwell 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)..
-
On 4/29/2019 at 4:24 PM, Staars said:
Yes, your early boot log should be very helpful. But no need to hurry, I am a bit short of time atm.
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
-
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..
-
52 minutes ago, Aux said:
That was the best answer I have received here so far.
Why not immediately so that you understand it correctly?
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..
)
54 minutes ago, Aux said:Of course, this raises a different view of RPi!
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.
-
On 6/8/2019 at 3:55 PM, Aux said:
who do you Think You Are?
one of the maintainer of this project (dealing with rockchip and amlogic)?
On 6/8/2019 at 3:55 PM, Aux said:Who had the right to remind me?
In the forum one discusses and the Tido had grinned me first.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).
On 6/8/2019 at 3:55 PM, Aux said:My initial question was just to see if it was Armbian OS for Raspberry Pi, but was attacked by you that Raspberry Pi is not worth coping with.
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..
-
-
moved to rockchip 3399 (I think it fits better there).
21 minutes ago, Martin N said:I'm running latest Armbian Bionic on Pine64 RockPro64
https://forum.armbian.com/guidelines
not as 100% clear but this counts here as well:
QuoteA support question must include the following:
Board you use
Issue you face
Description of your set-up (e.g. powering, connected hardware, used SD-Card)
'sudo armbianmonitor -u' - this gives us some needed logs which makes debugging a way easier!
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.
-
On 6/5/2019 at 1:12 AM, TonyMac32 said:
The next will be official.
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
).
-
On 5/29/2019 at 6:01 PM, prates said:
I shouldn't answer my own post, by maybe someone is also interested in this
why not? Better for everyone interested in it..
Throtteling happens for a reason.. and gambling here might not be the smartest thing.. E.g.
On 5/14/2019 at 2:15 PM, prates said:May 13 18:30:31 inova-casa kernel: [15484.645810] [hotplug]: cpu(0) try to kill cpu(2) May 13 18:30:31 inova-casa kernel: [15484.645873] [hotplug]: cpu2 is killed! .this happens when things get to hot.. and I'm not sure if you really want this behavior in case of performance..
Asides from the SoC of this board is quite near to your SD-Card and might help to slowly toast it to a corrupt level... Flash media doesn't like heat at all..
-
11 hours ago, TonyMac32 said:
ours weren't for the RockPi, so that's why.
I know where the whole device tree comes from. But since I never had network issues (e.g. lot of dropped packages or bad performance).. I didn't tried to nail down those settings.. BTW. The settings we find for the rockpi come likely from here:
which locks like reference design.
-
3 hours ago, NicoD said:
I saw that "new hardware : RockPi4"
means initial device tree is now upstream.. Doesn't mean that this is complete... e.g. you want thing anything like:
https://github.com/armbian/build/blob/master/patch/kernel/rockchip64-dev/fix-rockpi4b-led.patch
on the other hand, our RX & TX settings for gmac slightly differ:
+ tx_delay = <0x28>; + rx_delay = <0x20>;tx_delay = <0x28>; rx_delay = <0x11>;maybe this makes a difference.. who knows.. It's not that 5.1 will be boring.. But I would only push if first Ayufan pushes as well and second we can adjust all patches in one attempt..
3 hours ago, TonyMac32 said:Well, there has been a lot of peripheral stuff going I with Rockchip as well,
It's not that there isn't anything interesting..
You will probably know in which parts I'm interested due to a few PMs.. But I still think that some of them are just not ready yet.. Or might need additional DT tweaking.
3 hours ago, TonyMac32 said:I think 5.2 may be the more interesting
and then.. 5.3 will be more interesting cause maybe a LTS kernel (~3 months/kernel means november - okay.. if we assume 2 months/kernel then it will be 5.4
who cares)..
We definitively should push to either 5.1 or 5.2 to avoid having to much to fix later.. But it's IMO not priority.
-
19 hours ago, perlian said:
lol.........no the SD Card is the newest and fastest Sandisk with 32 GB and it works perfect in my Odroid XU4
21 hours ago, chwe said:Their debian/ubuntu sources are a bit outdated (means a lot of packages have to be updated) and/or your SD card is crappy slow in small block random IO
"newest and fastest" quite often ends here:
https://forum.armbian.com/forum/31-sd-card-and-psu-issues/
that's why I don't care about such information without actually prove that the used card is really fast (forum search will guide you how you can test it)... Especially when it's about Images we (as armbian team) are not 'in charge'.
5 hours ago, perlian said:I want to use the 3,5 mm jack for Audio not the HDMI
about which Image do we talk here? switched to Armbian or still on FriendlyElec's image?
a short reminder (https://forum.armbian.com/guidelines):
A support question must include the following: Board you use Issue you face Description of your set-up (e.g. powering, connected hardware, used SD-Card) 'sudo armbianmonitor -u' - this gives us some needed logs which makes debugging a way easier!besides being in 'Development' not 'Technical Support':
Development A section for more experienced users. For example for SoCs where Armbian support is currently not mature enough for full support, questions related to the build framework and 'Board Bring Up' for new boards we might consider supporting in the future. We can't provide the same level of support for WIP (work in process) SoCs cause kernels for those boards are simply not ready yet. Board Bring Up is mostly for experienced users which want to contribute in support for new boards/SoCs, a *please support random board* without any rational and no interest in contribution for such a support will simply be ignored. If you just want to point us to a new interesting board our water-cooler (General chit chat) is the right place for it.btw. @lanefu can you adjust the text there? 'Technical support' isn't anymore.. so the text need some small adjustments..
-
19 hours ago, NicoD said:
Could anyone also enable kernel 5.1 for the RockPi4 dev on the Armbian build script please?
I would love to test it out with Armbian. I'm very curious how it is.Short answer: No (or: yes you can -- > see long answer)
Long answer:
what do you expect to change between 5.0 and 5.1? there's not much changed for RK3399 between those two except:
New hardware – FriendlyELEC NanoPC-T4 and NanoPi M4, Radxa RockPi 4
means this patch needs to be adjusted:
https://github.com/armbian/build/blob/master/patch/kernel/rockchip64-dev/add-board-rockpi4b.patch
see which patches else break as well... probably a few others, e.g. every patch modifying the makefile of all the DTS. We don't switch kernels for one board.. we switch it for the whole boardfamily.. which means here rockchip64 with: RockPi, Renegade, Firefly, NanoPis 4 (at least on mainline they share their kernel), Rock64, RockPro64 and maybe a few I forgot..
20 hours ago, NicoD said:and this time it doesn't cost me money
It doesn't cost money, but it costs time...
But you can do it on your own :
- clone buildscript
- altering those lines to the 'real mainline source' (we use ayufans mainline branch which currently not switched to 5.1) go through his 60 commits on top of mainline to figure out which of those are still needed (and which need to be fixed).. then apply our ~20 patches for this kernel and fix all the regressions you'll get here..
- and if you really want to test something new, not only what has enhanced in the same 'drivers' you had in 5.0, you would need to adjust the config file as well to get the new stuff compiled (e.g. if you want to play around with the new scheduler --> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=81a930d3a64a00c5adb2aab28dd1c904045adf57 ).
-
@TonyMac32 sounds familiar? Sounds like:
4 hours ago, Humberg said:contact us,
btw.:
https://www.humberg.de/rock64/
Art-Nr. Bezeichnung Beschreibung Amazon 105440 Rock64 4GB B0755RL2D4links to a pine cluterboard on amazon..
-
20 hours ago, perlian said:
its a nightmare to install or update software with the FriendlyArm Image using apt
Sometimes it takes hours to upgrade the packages after a fresh install
two possibilities.. Their debian/ubuntu sources are a bit outdated (means a lot of packages have to be updated) and/or your SD card is crappy slow in small block random IO which normally ends then in really annoying apt upgrade sessions..
-
1 hour ago, Erfan said:
And also the display, does it work with the current 5.0.7?
display means HDMI?
1 hour ago, Erfan said:When will the 5.1 image come? The kernel was released yesterday
whenever someone fixes all the patches which might need an adjustment & proves that the board is actually booting. It probably not top priority to move to 5.1.
-
@tido, you forgot to unlock it...
-
22 hours ago, Fan KunPeng said:
Here it is:
how long did you wait then?
unfortunately they're only 4b dev samples around right?
Need help!!! Rockchip motherboard
in Beginners
Posted
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.