chwe

Moderators
  • Content Count

    1369
  • Joined

  • Last visited


Reputation Activity

  1. Like
    chwe got a reaction from piter75 in Armbian 20.02 (Chiru) Release Thread   
    well you've no chance I already set up the pinebook in rk3399 with u-boot 2020:
     
    U-Boot 2020.01-armbian (Jan 21 2020 - 23:08:47 +0100) Model: Pine64 Pinebook Pro DRAM: 3.9 GiB PMIC: RK808 MMC: dwmmc@fe320000: 1, sdhci@fe330000: 0 In: serial@ff1a0000 Out: serial@ff1a0000 Err: serial@ff1a0000 Model: Pine64 Pinebook Pro ## Error: Can't overwrite "serial#" ## Error inserting "serial#" variable, errno=1 rockchip_dnl_key_pressed: adc_channel_single_shot fail! Net: No ethernet found. Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc1 is current device Scanning mmc 1:1... Found U-Boot script /boot/boot.scr 2940 bytes read in 6 ms (478.5 KiB/s) ## Executing script at 00500000 Boot script loaded from mmc 1 143 bytes read in 6 ms (22.5 KiB/s) 7118384 bytes read in 752 ms (9 MiB/s) 20722176 bytes read in 2178 ms (9.1 MiB/s) 72693 bytes read in 17 ms (4.1 MiB/s) 2698 bytes read in 9 ms (292 KiB/s) Applying kernel provided DT fixup script (rockchip-fixup.scr) ## Executing script at 39000000 ## Loading init Ramdisk from Legacy Image at 06000000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 7118320 Bytes = 6.8 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 01f00000 Booting using the fdt blob at 0x1f00000 Loading Ramdisk to f5853000, end f5f1cdf0 ... OK Loading Device Tree to 00000000f57d8000, end 00000000f5852fff ... OK Starting kernel ... [ 2.647157] Internal error: Oops: 96000004 [#1] PREEMPT SMP  
    it seems it doesn't like my new DT.. but u-boot works fine and blobfree..
  2. Like
    chwe got a reaction from TonyMac32 in Armbian 20.02 (Chiru) Release Thread   
    well you've no chance I already set up the pinebook in rk3399 with u-boot 2020:
     
    U-Boot 2020.01-armbian (Jan 21 2020 - 23:08:47 +0100) Model: Pine64 Pinebook Pro DRAM: 3.9 GiB PMIC: RK808 MMC: dwmmc@fe320000: 1, sdhci@fe330000: 0 In: serial@ff1a0000 Out: serial@ff1a0000 Err: serial@ff1a0000 Model: Pine64 Pinebook Pro ## Error: Can't overwrite "serial#" ## Error inserting "serial#" variable, errno=1 rockchip_dnl_key_pressed: adc_channel_single_shot fail! Net: No ethernet found. Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc1 is current device Scanning mmc 1:1... Found U-Boot script /boot/boot.scr 2940 bytes read in 6 ms (478.5 KiB/s) ## Executing script at 00500000 Boot script loaded from mmc 1 143 bytes read in 6 ms (22.5 KiB/s) 7118384 bytes read in 752 ms (9 MiB/s) 20722176 bytes read in 2178 ms (9.1 MiB/s) 72693 bytes read in 17 ms (4.1 MiB/s) 2698 bytes read in 9 ms (292 KiB/s) Applying kernel provided DT fixup script (rockchip-fixup.scr) ## Executing script at 39000000 ## Loading init Ramdisk from Legacy Image at 06000000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 7118320 Bytes = 6.8 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 01f00000 Booting using the fdt blob at 0x1f00000 Loading Ramdisk to f5853000, end f5f1cdf0 ... OK Loading Device Tree to 00000000f57d8000, end 00000000f5852fff ... OK Starting kernel ... [ 2.647157] Internal error: Oops: 96000004 [#1] PREEMPT SMP  
    it seems it doesn't like my new DT.. but u-boot works fine and blobfree..
  3. Like
    chwe got a reaction from TRS-80 in Moderator Resources, Tips, Q&A, etc.   
    I wouldn't think 3 lines is a bloated footer (I've 3 lines I didn't update in a while - maybe I should)..
     
    A few thoughts about moderating (and I probably do mostly a bad job here cause I didn't do much moderating in a while - well I got that job somehow by mistake ).. I'm a fan of "as less as possible as much as needed". If someone chooses a obviously wrong title maybe change it.. If the title is not best, he'll learn from lack of attention that he might do better next time.
     
    I don't deal much with unfamiliar hardware anymore.. E.g. there are some parts in the forum you won't find me. Mostly Armada and amlogic. We have people knowing the odds of those boards so they can deal better with it than me. Moderators moderate first responders help. For some platforms I'm both (e.g. rockchkip) for others I just unlock topics and have a quick view if there's something odd about it (e.g. hidden shit in links). But different mods will have different styles, and as long as it is not harmful to the community at all people need to deal with it. Depending on which moderator you get you might get a different style of answer. It's not that we have to follow some cooperate guidelines how an answer should look like.
     
    If you split, merge or delete you might inform people by leaving a short post why you did it and where the other part can be found. If you move things I mostly let the checkbox with the 'simlink' so that the guy sees where his post is now.
     
     
  4. Like
    chwe got a reaction from aaditya in Rock PI 4 A not starting   
    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.
  5. Like
    chwe got a reaction from piter75 in NanoPI 4MV2   
    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
     
     
  6. Like
    chwe got a reaction from Jack953 in Orange pi 4   
    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.
  7. Like
    chwe got a reaction from gounthar in Orange pi 4   
    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.
  8. Like
    chwe reacted to karabek in OPi Zero: XR819 wifi broken in new builds   
    Users wanting to use debian builds with NetworkManager/wpa_supplicant should add the following lines to /etc/NetworkManager/NetworkManager.conf:
    [device] wifi.scan-rand-mac-address=no Ubuntu builds (bionic, focal) already contain these lines.
     
    This seems to solve the current issue on systems with the xradio wifi chip (opi zero, nanopi duo etc.)
  9. Like
    chwe reacted to Panzerknacker in ROC-RK3399-PC (Renegade Elite)   
    Does this bring some light to power supply?
    https://lkml.org/lkml/2019/12/10/517
  10. Like
    chwe got a reaction from Jack953 in Orange pi 4   
    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.
     
     
     
  11. Like
    chwe reacted to martinayotte in Image for M4 V 2   
    I've just done a RockPi4 build, will test in in the next hour ...
     
    EDIT : Tested ! It works ! But again, I had to manually finish the eMMC install with "dd" ...
    Next ! RockPro64 ! And later cleanup of both families to avoid forgetting patches during migration ...
  12. Like
    chwe got a reaction from gounthar in Orange pi 4   
    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.
     
     
     
  13. Like
    chwe got a reaction from esbeeb in Request for new Video about current state of Armbian project   
    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.
  14. Like
    chwe got a reaction from pask in (Serial) console access via 'USB-UART/Gadget mode' on Linux/Windows/OSX   
    Access to a console can be mandatory when you SBC doesn't work as expected (e.g Network or HDMI output doesn't work). When SSH/Display access isn't possible access to console via UART is the best way to get a clue where your SBC hangs. This short tutorial should give you an introduction how this works. For some boards, armbian implements an USB gadget mode (a 'fake' serial console over microUSB) describen below. As a reminder an USB-UART bridge is always prefered over USB gadget mode whenever possible (UART get's initialized before the gadget driver and also before HDMI, means even if you don't get a proper output from HDMI or gadget mode console, it is possible that UART will give you the needed information).
     
    Prerequisites:
    We need an Terminal program to access the console. If you use Linux on your host system I prefer picocom (something like minicom will also do the job) which can be installed:
    on debian a like systems:
    sudo apt-get install picocom from arch community repo:
    https://www.archlinux.org/packages/community/x86_64/picocom/
     
    on fedora systems:
    yum install picocom on Mac OS X:
    brew install picocom on Widows we use PuTTY:
     
    https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html
     
    UART USB Adapter:
    There are various USB-UART bridges e.g FT232 (and fakes of them, cause FDTI is expensive ), CH340/1,PL2303 or CP2102
    Normally it doesn't matter which one you use. I prefer the (probably fake) FDTI on the right side, but the CH341 does also a good job:

    The only thing which is needed is that the signal-level matches with your SBCs needs (this is mostly 3.3V expect some Odroids e.g HC1 which has only 1.8V!).  Most of these USB-UART bridges have jumpers for 5V and 3.3V, make sure that you use the 3.3V.  
    You've to figure out which pins on your SBC are debug UART (they've mostly a own 3 pin header, sometimes it's on the large pin header e.g. Tinkerboard) and then connect:
    GND --> GND RX --> TX TX --> RX You've to check dmesg (linux) or run devmgmt.msc (windows) to know which device you use. 
    Linux:
    [256597.311207] usb 3-2: Product: USB2.0-Serial [256597.402283] usbcore: registered new interface driver ch341 [256597.402341] usbserial: USB Serial support registered for ch341-uart [256597.402392] ch341 3-2:1.0: ch341-uart converter detected [256597.404012] usb 3-2: ch341-uart converter now attached to ttyUSB0 --> Device will be /dev/ttyUSB0
    Windows:
    for windows 10 (https://www.google.ch/search?client=opera&q=find+arduino+port+windows+10&sourceid=opera&ie=UTF-8&oe=UTF-8)
    Something like the picture in USB Gadget Mode part of the tutorial should show up)
     
    Armbians default settings are (expect some RK devices):
    For Picocom:
    picocom -b 115200 -r -l /dev/ttyUSB0 and for some RK devices:
    picocom -b 1500000 -r -l /dev/ttyUSB0 For PuTTY:
    You've to set configuration in 'Serial'. COM11 is just an example and needs to be checked first, Speed (baud) needs to be changed when you deal with the few RK boards which need 1500000.

     
    OS X:
    TBD
    should be similar to Linux whereas the naming differs a bit. See: https://forum.odroid.com/viewtopic.php?f=53&t=841 as an example with minicom.
     
    Normally you connect the USB-UART bridge to your host computer (and the SBC) and start picocom/putty before you power the board to ensure you get the full bootlog and not only parts of it. 
     
    USB Gadget Mode
    Several board (see list) for which official armbian images exist (or csc images can be built) have no HDMI display. On those boards there's USB gadget mode driver activated so that you can have console access to them via USB connection. The following short tutorial describes how you can access to console from Linux (don't have a windows machine here at the moment, I may check it later):
     
    install picocom connect your board via USB to your host computer (it should be one which is able to power an SBC via its USB port) check dmesg for the device showing up:  [184372.603816] usb 3-2: Product: Gadget Serial v2.4 [184372.603818] usb 3-2: Manufacturer: Linux 4.14.65-sunxi with musb-hdrc [184372.660041] cdc_acm 3-2:2.0: ttyACM0: USB ACM device [184372.660402] usbcore: registered new interface driver cdc_acm [184372.660403] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters  
    connect to it via picocom (in this case 'picocom /dev/ttyACM0'):  chwe@chwe-acer:~$ picocom /dev/ttyACM0 picocom v2.2 port is : /dev/ttyACM0 flowcontrol : none baudrate is : 9600 parity is : none databits are : 8 stopbits are : 1 escape is : C-a local echo is : no noinit is : no noreset is : no nolock is : no send_cmd is : sz -vv receive_cmd is : rz -vv -E imap is : omap is : emap is : crcrlf,delbs, Type [C-a] [C-h] to see available commands Terminal ready Debian GNU/Linux 9 orangepizero ttyGS0 orangepizero login: root Password: You are required to change your password immediately (root enforced) Changing password for root. (current) UNIX password:  
    I assume if you use the same settings in something like putty on windows and you check which 'serial' device shows up in *where windows shows connected devices - I forgot it* you should be able to access it from windows (someone motivated may confirm this).  
    For Windows:
    run devmgmt.msc and search for the serial device (in this case COM3) and connect to it via PuTTY (thanks to @hjc):

    for windows 10 (https://www.google.ch/search?client=opera&q=find+arduino+port+windows+10&sourceid=opera&ie=UTF-8&oe=UTF-8):
    (even the tutorial is for arduinos, it should be similar for every 'COM device')
     
    Currently boards with USB gadget mode:
    bananapim2plus bananapim2zero nanopifire3 nanopim3 nanopineo2 nanopineocore2 nanopineoplus2 orangepizeroplus nanopiair nanopiduo nanopineo olimex-som204-a20 orangepilite orangepi-r1 orangepizero orangepizeroplus2-h3 orangepizeroplus2-h5 tritium-h3  
    The silly approach
    For those, who want to save 1$ for an USB-UART bridge, you can spend 10$ for an OrangePi Zero and use its spare UARTs to log into an other SBC...  SSH --> opi, ttl --> Tinkerboard
    For those loving text more than videos:
    SSH to your SBC sudo armbian-config --> system --> hardware  to activate an spare UART (in this case it was UART2, will give you ttyS2) reboot picocom -b 115200 -r -l /dev/ttyS2  
     

    See:  https://asciinema.org/a/B87EOGhc0gx9oikMAGEG94lXR

     
     
  15. Like
    chwe got a reaction from Werner in Why are armbian images not in a format that Etcher understands?   
    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..
     
     
    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 )..
     
  16. Like
    chwe reacted to piter75 in armbian can not boot in Rock Pi4 v1.4   
    I have been happily booting Rock Pi 4B v1.4 since August with both eMMC and SD.
    As others already pointed it would be good if you had some console logs.
     
    At this point I am running custom Armbian build based on latest u-boot and open source ATF but will burn SD with latest "official" image, check if it boots and will get back with the results.
  17. Like
    chwe got a reaction from Igor in Is it Possible To Use Armbian On Pi Devices?   
    there are some ugly hacks needed to "build armbian" for the RPi... I know it cause I did it (and honestly this ugly hack will never see daylight - I don't wanna add mess to the buildscript, I don't want to maintain a RPi kernel family and I've no intention to deal with the people it would attract, IMO those beneficial to armbian could easy do the hacks to build "armbian for raspberries").. On the RPi forum the Jamesh (forum mod and RPT employee) made clear that they don't plan to make their bootblobs ext4 capable.. According to him, he talked to one of their engineers and he thought it's a dumb idea. The rest of the guys thought that vfat is for whatever reason the best thing you can have...
     
    Thomas did never adjust the buildscript to "build for raspberries". He glued a recent rootfs from armbian together with the kernel from the RPi repository and some adjustments here and there to get it the way he wants it (e.g. slow down "GbE" cause this USB2 GbE messed up, and an adjusted firstrun script to update kernel from their repository etc.). Cause Thomas no longer maintains OMV on arm, I don't think the new images will be based on armbian rootfs. The needed "glue repository" is removed from his github and I'm not sure someone forked it in time (he announced that he'll remove it). As far as I understand OMV has currently no ARM maintainer anymore.. So as soon as the support for the current version ends, it's gonna be interesting who will do the needed adjustments to build OMV in the future. It seems that their devs are either minor interested in ARM or (as we all do) lack of enough spare time to keep it rolling on ARM.
     
    Back to topic..
     
    Even if it happens such a PR has to be properly reviewed.. The only "proper" way I see would be bootblob chainloads u-boot u-boot fires up kernel but even then.. It will be mess. You need fat otherwise it's not gonna working.. You fully rely on their development speed for everything that matters (cause a bunch of stuff happens in the bootblob). Whenever they change something here and there the fallout is only visible once the our "customers" will show up and complain about *random behavior* (e.g. the thermal issues for the 3b+ were solved by lowering the throttling start to something like 65°C - announced in one git commit but neither in the changelog, cause changelog is according to jamesh for raspbian as OS not for the underlying stuff like bootblob ). Have fun to explain the Armbian users why *random stuff* behaves different from update to update (not that we can explain this for all the boards we support yet - but adding another family which needs a special treatment in this case might be annoying).
     
    Currently we have one boardfamily which has only CSC supported targets (mt7623). The reason it exists is me had fun to bring up a new boardfamily and the maintenance is minor ("pure" upstream kernel, and a ugly hacked upstream u-boot which "just works"). I don't do much on it (test images from time to time - btw. I should do it soon-ish cause Igor bumped u-boot ). The board hasn't many "fans" so only a few people will show up from time to time which is IMO manageable. The RPi for sure would attract more people, so even as csc target at least one of the "part time maintainers" would be needed to deal with it (if someone shows up only for the PR for initial support with no intention to maintain it it would be a clear "thanks, but NO thanks" from my side, even explaining that csc doesn't mean "official support" all the time would be too much wasted time). Other issues such as 32bit 64bit, we don't do 32bit userland on 64bit hardware, as well as 64bit kernels with 32bit userland (thomas suggested it once for low memory boards for which it might be beneficial) and 64bit/64bit for the raspberry is kind of a pain (I had it for the 4b, cause I only have the 1GB ram version most of the issues didn't even hit me, e.g. in the beginnings only 3GB could be used followed by USB3 (iirc for USB attached storage) having issues later on when 4GB ram should actually work) and the videocore stuff still generates fallout on 64bit/64bit systems (I was never interested in the VC capabilities so my 64bit "artwork" worked ok-ish).
     
    So as long as we don't see a talented allrounder (dealing with buildscript adjustments, kernel fixes and annoying bootloader crap) showing up and maintaining it, I'm not in favor to add broadcom SoCs to our buildscript, even as csc targets. Just do it is IMO not enough. The 26 million raspberry users (or was it 30? the number changes always when jamesh explains that their users are happy with what they get and how dare you are that you claim that something might be not perfect with their product) might be upset if something doesn't work as it works on raspbian. [can contain a bit of sarcasm.. ]
  18. Like
    chwe reacted to gprovost in Helios64 Annoucement   
    Yeah I should have mentioned that also. Through the same USB Type-C we also support Flash over USB with the rockchip dev/flash tools available. The recovery button is on one of 3 push button on the board. Each on-board memory (SPI and eMMC) can be disabled with a proper jumper ( No need to have 16 fingers to flash the board ).
     
    We will try our best. Also we will sell a simple adapter kit in order for people to use Helios64 with any mini-ITX and ATX PSU. This way people could recycle their old case and save money.
  19. Like
    chwe reacted to gprovost in Helios64 Annoucement   
    We will offer an ECC option. The Rockchip RK3399 SoC itself doesn't have a memory controller that has ECC feature, however we are currently working with a SDRAM vendor that now offer built-in ECC feature inside the SDRAM directly. It's not impossible it will be available on day one.
     
     
     
    No. It is not a use case that make sense from our point of view. I don't believe there will be a lot of people out there with a USB Type-C power adapter that can delivered up to 100W. Plus the power circuitry (and the PSU) would be quite expensive.
     
     
    No. It's a pure M.2 SATA port. FYI it's share with the SATA port 1, so the combination is either ( 1x M.2 SSD + 4x HDD/SSD ) or 5x HDD/SSD.
     
     
    Yes there is a 128Mb SPI NOR Flash.
     
     
    Something we didn't disclose because too much info already on the picture, the USB Type-C has been designed with a 4-in-1 mode concept :
    - Display Port
    - DAS mode
    - Host mode
    - Serial Console Access
    We will explain more at a later stage... but it's quite a unique design we did.
     
     
    We wanted to make the eMMC a basic feature of our board. I mean what's the point to sell it as a module when you know that in 90% of the case your user should use eMMC instead of SDcard. It also help in term of software support to know that all user Helios64 user will have the same config, therefore we can focus on installation guide that use the eMMC.
     
     
     
    You guess right this is not just some bare bone carrier board with a SoC in the middle. Between the PCIe-to-SATA bridge, the 2.5Gbe interface, the built-in UPS feature, RAM, eMMC, etc... it adds-up quickly. We also paid a lot of attention on the different power rails, this is a premium design compare to all the RK3399 board out there.
    Helios4 was USD200 with the full kit (PSU, case, cable, fan, etc...), our goal it to try to be in the same ballpark. This time we will sell a-la-carte style, you can just buy the board alone, our with the case, if you already have a PSU then no need to order one...
     
  20. Like
    chwe reacted to gprovost in Helios64 Annoucement   
    Hi guys,
     
    I guess some might have heard that we (Kobol Team) were spinning a new project to succeed to Helios4. Here it is... Helios64
     

     
     
    We didn't have to look too far for the board name since in essence the goal was to redesign from scratch Helios4 with a 64-bit SoC and try to improve every key features that made Helios4 a very targeted board for NAS setup.
     
    Right now we are at the prototyping test phase, hopefully in a 2 month time will have dozen of Eval boards to send around for evaluation and review... and if all goes well first batch should be available for order in Feb / March 2020.
     
    Happy to answer any question :-)
     
  21. Like
    chwe got a reaction from NicoD in NanoPi M4 V2 - M4 Image not working   
    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)..
  22. Like
    chwe got a reaction from TonyMac32 in Daily (tech related) news diet   
    https://github.com/buildo/react-components/pull/1367
     
    Conclusion: we definitively need a nemobot as well here...
  23. Like
    chwe got a reaction from JMCC in Request for new Video about current state of Armbian project   
    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.
  24. Like
    chwe got a reaction from Igor in Request for new Video about current state of Armbian project   
    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.
  25. Like
    chwe got a reaction from NicoD in Request for new Video about current state of Armbian project   
    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.