chwe

Moderators
  • Content count

    672
  • Joined

  • Last visited


Reputation Activity

  1. Like
    chwe reacted to hjc in RockPro64   
    RK3399 is supported by mainline u-boot.
     
    I changed BOOTSOURCE to https://github.com/u-boot/u-boot.git and checked it on Firefly-RK3399. It runs pretty well, even better than Rockchip u-boot (2017.x). It's running with good USB & ethernet support, booting OS flawlessly.
    I'm already running some heavy services on NanoPC-T4 so not rebooting them, but I assume it works basically the same.
     
    Playing around with u-boot:
    DDR Version 1.12 20180518 In Channel 0: DDR3, 800MHz Bus Width=32 Col=10 Bank=8 Row=15/15 CS=2 Die Bus-Width=16 Size=2048MB Channel 1: DDR3, 800MHz Bus Width=32 Col=10 Bank=8 Row=15/15 CS=2 Die Bus-Width=16 Size=2048MB 256B stride ch 0 ddrconfig = 0x101, ddrsize = 0x2020 ch 1 ddrconfig = 0x101, ddrsize = 0x2020 pmugrf_os_reg[2] = 0x3AA17AA1, stride = 0xD OUT Boot1: 2018-04-08, version: 1.12 CPUId = 0x0 ChipType = 0x10, 217 SdmmcInit=2 0 BootCapSize=100000 UserCapSize=29820MB FwPartOffset=2000 , 100000 mmc0:cmd5,32 SdmmcInit=0 0 BootCapSize=0 UserCapSize=15193MB FwPartOffset=2000 , 0 StorageInit ok = 80087 LoadTrustBL No find bl30.bin No find bl32.bin Load uboot, ReadLba = 2000 Load OK, addr=0x200000, size=0x90f40 RunBL31 0x10000 NOTICE: BL31: v1.3(debug):f947c7e NOTICE: BL31: Built : 19:40:58, Jun 11 2018 NOTICE: BL31: Rockchip release version: v1.1 INFO: GICv3 with legacy support detected. ARM GICV3 driver initialized in EL3 INFO: plat_rockchip_pmu_init(1089): pd status 3e INFO: BL31: Initializing runtime services INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x200000 INFO: SPSR = 0x3c9 U-Boot 2018.07-rc1-armbian (Jun 19 2018 - 00:14:04 +0800) Model: Firefly-RK3399 Board DRAM: 3.9 GiB MMC: dwmmc@fe320000: 1, sdhci@fe330000: 0 Loading Environment from MMC... OK In: serial@ff1a0000 Out: serial@ff1a0000 Err: serial@ff1a0000 Model: Firefly-RK3399 Board Net: eth0: ethernet@fe300000 Hit any key to stop autoboot: 0 => => => usb start starting USB... USB0: USB EHCI 1.00 USB1: USB EHCI 1.00 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 1 for devices... 3 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found => usb info 1: Hub, USB Revision 2.0 - u-boot EHCI Host Controller - Class: Hub - PacketSize: 64 Configurations: 1 - Vendor: 0x0000 Product 0x0000 Version 1.0 Configuration: 1 - Interfaces: 1 Self Powered 0mA Interface: 0 - Alternate Setting 0, Endpoints: 1 - Class Hub - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms 1: Hub, USB Revision 2.0 - u-boot EHCI Host Controller - Class: Hub - PacketSize: 64 Configurations: 1 - Vendor: 0x0000 Product 0x0000 Version 1.0 Configuration: 1 - Interfaces: 1 Self Powered 0mA Interface: 0 - Alternate Setting 0, Endpoints: 1 - Class Hub - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms 2: Hub, USB Revision 2.0 - USB 2.0 Hub [MTT] - Class: Hub - PacketSize: 64 Configurations: 1 - Vendor: 0x1a40 Product 0x0201 Version 1.0 Configuration: 1 - Interfaces: 1 Self Powered Remote Wakeup 100mA Interface: 0 - Alternate Setting 0, Endpoints: 1 - Class Hub - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms 3: Mass Storage, USB Revision 2.10 - SanDisk Ultra USB 3.0 4C530001240422114145 - Class: (from Interface) Mass Storage - PacketSize: 64 Configurations: 1 - Vendor: 0x0781 Product 0x5595 Version 1.0 Configuration: 1 - Interfaces: 1 Bus Powered 224mA Interface: 0 - Alternate Setting 0, Endpoints: 2 - Class Mass Storage, Transp. SCSI, Bulk only - Endpoint 1 In Bulk MaxPacket 512 - Endpoint 2 Out Bulk MaxPacket 512 => dhcp ethernet@fe300000 Waiting for PHY auto negotiation to complete........ done Speed: 1000, full duplex BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 BOOTP broadcast 4 BOOTP broadcast 5 Abort =>  
  2. Like
    chwe reacted to gprovost in Helios4 Support   
    @nemo19 Ok no need to look any further, you found the issue. There should be a thermal pad between the CPU and the Heatsink as shown below. Without the thermal pad no proper heat transfer can happen, therefore the CPU might have reached above Maximum Junction Temperature (115C) resulting by it to get unstable and crash. I'm really sorry about this missing thermal pad, this should definitively not have happened, I will report / complain to the company that handled the board assembly for us.
     
    FYI the thermal pad dimension we are using is 20x20x1mm.
     
    Please provide me by private message your complete shipping address. I will send you this missing thermal pad. In the meantime you can try using thermal paste, even though the gap between CPU and Heatsink is a bit too big for thermal paste.
     

  3. Like
    chwe got a reaction from hjc in Firefly RK3399 support efforts (potential csc board?)   
    small hint:
    by disable https://github.com/hjc4869/armbian-build/blob/58af252c2b7c3acb6160f7ea456c56ef8f7412b6/config/kernel/linux-firefly-dev.config#L50
    you should get rid of the 'g42568f34-dirty' in your kernel naming. 
  4. Like
    chwe reacted to AndiH in v5.45 (desktop on top of cli, xu4 next upgrade, ...)   
    Hello,
     
    I did again some testing with the actual Nightly builds on an Odroid HC1, and detected an issue - the DNS name resolution doesn't work properly.

    Reason is that the configuration file "/etc/NetworkManager/NetworkManager.conf" now contains a line "dns=None".  After just deleting this line from NetworkManager.conf, it works fine - and NetworkManager is updating "/etc/resolv.conf" accordingly.

    (Note: with "dns=none", the DHCP client ("dhclient" resp. "dhclient-script" would have to take care of the "resolv.conf" update - but that script gets never called, as "dhclient" is started with the -sf option, and will instead invoke the NetworkManage "nm-dhcp-helper" component).

    I found the issue trying the following images:
    5.46.180602_Odroidxu4_Debian_stretch_next_4.9.103
    5.46.180602_Odroidxu4_Debian_stretch_dev_4.14.47
    5.46.180530_Odroidxu4_Debian_stretch_dev_4.14.44
     
    It was fine (i.e. "NetworkManager.conf" does not contain the "dns=none" line) in:
    5.44.180506_Odroidxu4_Debian_stretch_next_4.14.39
    5.45_Odroidxu4_Debian_stretch_next_4.9.99 
     
    So must happened somewhere in between ...
     
    Andi.
     
  5. Like
    chwe reacted to zador.blood.stained in Armbian-Stretch and IR-Remote?   
    If we are talking about connecting IR receiver to any GPIO (and not using a dedicated GPIO pin and an in-SoC CIR decoding HW) then it should be enough to use this which requires the appropriate kernel drivers, RC keymaps and DT modifications (since we don't have overlays support there yet).
  6. Like
    chwe reacted to Igor in Daily (tech related) news diet   
  7. Like
    chwe reacted to TonyMac32 in How do I use the camera on tinkerboard?   
    Current list of things to fix before I'm looking at Tinker cameras:
     
    -Mali
    -Touchscreen
    -device tree overlays
    -Tinker S hardware monitoring (voltage and headphone plug, eMMC availability with the jumper in recovery mode)
    -Meson64 stuff for other boards that I also help maintain.
    -something that will certainly require attention before now and then
    -cameras that only work with 1 board.
  8. Like
    chwe reacted to TonyMac32 in How do I use the camera on tinkerboard?   
    Well, we're not a free resource for other people's projects in this specific of a context.  What you're proposing would easily double the workload I put into a side project that does not pay my bills, simply so you can have something for nothing, so they say.  I'm not trying to be rude, but I don't have time for every user's pet project, Once I get the latest Rockchip updates stabilized I may spend some time on getting the ISP driver working, or I may not, but that will be the limit, is to get the hardware to a functional level.  Any special or new functionality is outside of the scope of what I have time, resources, and in some cases knowledge.
     
     
    And you think a loosely affiliated group of programmers doing this for their uses and enjoyment can?
  9. Like
    chwe reacted to Igor in Orange Pi Zero, dev kernel does not see expansion USB ports   
    When it is done is done. Armbian is not a professional service and we have no particular interest nor resources to deal with this function. A project is open and if this is your pain, you are welcome to join and try to move patches from NEXT to DEVelopment "today". 

    Next kernel is planned when upstream 4.17.y - 4.18.y changes in the area of particular interests are significant enough to move forward. Anything else is unpaid education or throwing resources straight into the trash bin.

    Perhaps 2-3 months?
  10. Like
    chwe reacted to JMCC in Exynos 5422 Media Testing Script   
    The UN-official, UN-supported, UN-timely, UN-derrated...
    Exynos 5422 MEDIA TESTING SCRIPT
     
    Yes, the script is somewhat untimely, because it comes when including kernel 4.14 in Armbian next images is getting troublesome. And underrated, because this old SoC seems to be losing the focus of attention in favor of some more modern powerful ones. But it is still a great SoC, and it is worth trying to get the best out of it.
     
    The script will provide the installation of all the libraries and system configurations necessary for GPU accelerated X desktop, Chromium WebGL,VPU decoding/encoding acceleration through MFC, and GLES 3.1 / OpenCL 1.1 support.
    It will also install two media players (MPV and Kodi stable) and FFmpeg, all of them using VPU acceleration.
    Two example programs using the OpenCL functionality: Examples form the Arm Compute Library, and a GPU crypto miner (an old version, but small and simple).
    Two additional small packages, that have no big interest from the developer prospective, but I find them interesting to play with: Support libraries for commercial web video streaming (tested with Netflix), and a simple Pulseaudio GTK equalizer using LADSPA.
     
    Since all the features require the 4.14 kernel to work, the script will also give the option to install an archived 4.14.43 Armbian kernel, in case some other version is detected in the system. Of course, the best option is to use armbian-config to perform a kernel upgrade, but we are providing the archived version just in case the 4.14 packages disappear temporarily from Armbian repos.
     
    Also, this script can be tailored for desktop or headless installation, by selecting the appropriate options in the main menu.
     
    Here is a more thorough documentation:
    >>> DOWNLOAD LINK <<<
    Instructions:
    Download the file above
    Untar it: tar xvf media-exynos5422_1.0.tar.xz
    cd exynos5422
    ./media-exynos5422.sh
     
    Notes:
    This script is not officially supported by the Armbian project. It is just a community effort to help the development of the main build, by experimenting with a possible implementation of the media capabilities of this particular SoC. Therefore, questions about the script should not be laid out as support requests, but as commentaries or community peer-to-peer assistance. That being said, all commentaries/suggestions/corrections are very welcome. In the same way, I will do my best to help solve any difficulty that may arise regarding the script.  
    Enjoy!
  11. Like
    chwe reacted to Igor in Stale packages on apt.armbian.com (sunxi-next)   
    No, that is not possible.

    When you install your own kernel, you have to freeze kernel updates in armbian-config to prevent updating from our repository.
  12. Like
    chwe got a reaction from pfeerick in H6 boards: Orange Pi One Plus, Orange Pi 3 Plus and Pine H64   
    there you go.. (should be more or less correct, cause only @jmmc works on such features.. )
     
    sure, a not powered board doesn't need much power...  If you want mainline on it, the things you're interested in might come in one or two years (just my opinion)...  To my knowledge, mainlining H6 is still a 'one-woman-show', so better hope that she doesn't looses interest in doing all the work.  
  13. Like
    chwe got a reaction from Ryder.Lee in BananaPi R2 (.csc mt7623 as new boardfamily)   
    a shortly: 
    GbE still sucks and the current network defaults may need some rework anyway (getting it's IP via DHCP doesn't work on firstrun) There are a bunch of generic drivers missing (my el cheapo 2.5'' USB3 enclosure isn't recognized, whereas it's no problem to access it from every other Armbian kernel I use...  after adding some other generic mass storage drivers at least the cheap USB stick gets properly recognized... Anyone a clue what's needed for a 'Innostor IS621' USB-Sata drive to work?  Cause the stick will suck in performance anyway, there's no chance to determine how fast USB is at the moment.. (it get's recognized as SuperSpeed USB but it's a 20$ 64GB noname stick, not worth to test something with it)...  I got fooled by the dev kernel... booted it once just for fun.. Cause debug UART is on UART2, I expected that in bootargs console=ttyS2, actually this was never true for Franks 4.14 Kernel, as soon as you switch to a 'unpatched mainline' (that's what dev is) the console gets silent as soon as ttyS is initialized.  Rebooted probably to early and messed up something so that the FS was corrupted. I could see that setting bootargs to ttyS2 will work but the Image was too much corrupted to bring it up. So we need to patch either franks kernel to the default behavior or patch mainline to franks behavior (I prefer to patch mainline cause I think most other boards will have debug UART on UART0, similar to the reference board, but dev kernel has no priority for me) CPU temperatures aren't accessible yet (probably also a missing module or 'not working' yet). So for anyone want to join the party. USB-UART is a must, not only a 'makes things easier'.. 
  14. Like
    chwe reacted to Igor in https://beta.armbian.com problem?   
    Yes indeed. It will take another few hours to rebuild repository. Will see in the morning if everything went o.k.
  15. Like
    chwe reacted to thc013 in Not able to find SPI in orange pi zero   
    nah that is to short to help
     
    what did you used for spi device
     
    wich pins on opi you are using
     
    how looks your armbianenv. file dig you include in overlays spi and did you set it to 1
     
    or if you using a flash device your armbianenv is different
  16. Like
    chwe got a reaction from zador.blood.stained in BananaPi R2 (.csc mt7623 as new boardfamily)   
    Proposal to introduce a new BOARDFAMILY based on MT7623n SoCs. The only (widely) available board currently is the BananaPi R2 build by Sinovoip. I 'tried' to clean and split their BSP into different repos to make it usable for armbians Buildscript. The 'initial' work is done and built images boot up (with some additional work).
     

    (found one on http://www.banana-pi.org/r2.html - hidden in the 'gallery photos' which looks like the revision I have)
     
     
    Some specs (and just to be clear here, this is not a in-depth description about performance of those interfaces, there are more experienced people for benchmarking interfaces etc. don't hang me when there's a mistake in the description ):
    MT7623n (ARM Cortex-A7 quad core) GbE over MTK7530 (1x "wan" 4x "lan") 2x USB 3.0 and 1 USB 2.0 otg port 2x SATA over asm1061 (up to) 2 mPCIE interfaces (one populated as mPCIe, the other is muxed with USB3 - you've to disable USB if you want to use it - never tested) Hardware NAT & cryptoDEV (also none of them is tested in my builds made with armbians Buildscript) wifi/bluetooth combo-chip (b/g/n / 4.1) HDMI Powering over 12V barrel jack  
    Pros:
    relatively cheap (~90$ Aliexpress) Metal case and 4G modem available (I dont' own both - so must be considered as 'not working' at the moment) 2x2 MIMO WiFi should be possible over mPCIE (as before I didn't test it) MT7623 gets relatively good upstream support by Mediatek in mainline There is a 4.14.y Kernel (currently at 4.14.42 - so it seems to be quite up-to-date) maintained by 'Frank-W' which gets frequently updates and patches from upstream are back-ported (more experienced kernelhacker have to decide if he does it in a sane way or not, that's over my skills)  See https://forum.armbian.com/topic/7296-bananapi-r2-csc/?do=findComment&amp;comment=55245  the board has some nice features either as a NAS or a routerboard (I know about the concerns of mixing router with NAS capabilities and I didn't benchmark one of this features - better let people benchmark it which know what they're doing ). It seems that Sinovoip starts to clean up their GitBook mess by switching to a wiki. There are still things wrong inside (e.g. the board-picture shows a battery connector but it was removed in the newer revisions of the board, still a lot of stuff linked to sources not provided by them self e.g. description of 'how network is implemented), but at least it's not that messy than their former 'gitbook' documentation. Frank-W provides a independent wiki where he documents his efforts and what works with his builds.   
    Cons:
    u-boot is based on a v2014.04 rc1 together with some Mediatek additional stuff with further modification by Sinovoip (and in the end by me which doesn't make things much better). Some cleanup is done (not pushed to github since it's early WIP and I only push it when it works 'somehow' reliable, it fools me quite often cause I'm definitively not a 'experienced' u-boot hacker - cause it's a bit outdated a lot of things changed to upstream and I've to google a lot of stuff to get things working). There are 3 binary blobs needed to boot into U-boot (see picture) and I still don't understand fully what they're doing (as said I'm not a u-boot hacker ) http://fw-web.de/dokuwiki/lib/exe/detail.php?id=en%3Abpi-r2%3Astorage&amp;media=bpi-r2:boot-structure.png  the 'Preloader' differs between eMMC and SD-card, so this needs for sure some 'additional work' for something like nand-sata-install. The 'Headers' are in fact two files (one seems to have he size it should, the other one is to big and get's partly overwritten by the 'preloader', so no idea how sane this is) and it seems that they set some variables to env in u-boot (I simply overwrite them to ensure that they don't do insane things and the board is booted with a bootscript sitting in /boot/boot.scr (currently wip - doesn't work every-time) During compilation of u-boot there are some warnings (I didn't care cause in the end the board boots into u-boot so this warnings are of minor interest to me - it would be possible to build u-boot based on v2014.04 upstream with huge patching, as it is done for a yocto-build by Wolfgang Tolkien here, but his is currently adjusted to yocto and will need some rework to make it usable for Armbian - nevertheless, without the help of Wolfgang, this thread would never came up he gave me a lot of hints here and there to deal with u-boot) There is no kernel defconfig for the R2 nor mt7623n SoC upstream (as far as I understand frank-w made a defconfig based on a 4.9 kernel, based on the evb board - so give him the credits for doing a lot of the hard work ), nevertheless an 'mt7623n-next/dev.config' needs some adjustments.  I think, I pickt more or less all of the SoC relevant drivers after 'a few attempts'...  Currently load a kernel with 'Flattened Device Tree blob' (CONFIG_OF_LIBFDT) does not work (Wolfgang reported similar problems for his yocto builds with the R2, but it should/does work with his evb board) and only 'appended device tree blob to zImage' (I didn't care about the drawbacks yet) works yet. Probably this needs some adjustments in builddebb (at the moment this is done by hand with 'cat zImage *.dtb > zImage-dtb ). U-boot 'should' be capable of booting a with a separate dtb file but it doesn't...   The EVB can also be booted with FIT images but this seems also not work on the BPi, maybe it's related to the binaries, maybe I got fooled by u-boot once again (it happened a lot). I simply don't know. From a support point of view: This board has a bunch of features which people will mix together (from router/NAS/'home cloud' up to HDMI capabilities) for a relative affordable price, so 'less experienced' people will buy it, will mess with it and will ask here a bunch of questions when we decide to build images or have it as .csc in armbians repo. Cause it will introduce a new boardfamily (probably *.csc only at the moment) this board doesn't get any kernel updates until the maintainers decide to add it to armbians apt server and if we do, it's more than csc and people will expect 'some support'. I only did the 'initial work' so, a lot of kernel module adjustments, u-boot cleanup and enhancements are needed to build useful 'Armbian images' and to be clear: I'm not willing nor able to do all this work alone. In case no serious developer is willing to join this 'clean up' party, we should not add this board to .csc cause it will end similar to the OPi-2g-IoT where people ask from time to time for support whereas nobody works actively to enhance the Images.  No LTS-Kernel due to 4.14 has a lot of back-ports inside which might mess up things in case a other member of the same SoC will join the boardfamily. Edit: just in case somebody asks, as far as I know HDMI is not working yet on 4.14 and only usable with the 4.4 BSP kernel, I played some days with it, tried to fix things, I failed, I got headache from the BSP-Kernel and decided to drop it fully. From my side, there will be no efforts in the BSP Kernel to get it working. If someone wants to deal with it, there's a 'kernel only' repo on my github fully 'unmaintained' not patched and currently not available as buildoption. I think people who are able to fix issues for this kernel are able to add it as buildoption but I decided to not deal with it.  
    So to summarize, what's done, what works and what's not working (everything not mentioned here must be considered as not working!):
    Next Kernel (4.14.y) builds without issues, the devicetree blob is attached after its manually (mount image --> cat zImage *dtb > zImage-dtb) Will not longer be supported by my builds. U-Boot was slightly adjusted so that it is capable of booting zImages, is able to handle ext4 FS & getting it's bootscript from /boot/boot.scr. This needs still some rework for accessing eMMC due to not working 100% reliable with freshly built Images (the first boot is done by manual u-boot commands, probably due to something gone wrong with the bootscript, after recompilation of boot.cmd onboard, the board boots up automatically without manual u-boot hacking) SATA devices are recognized, ETH was only tested once and didn't work (I guess, some adjustments in NM are needed or I missed something, cause the board is mostly connected only via UART during testing I didn't spend much attention to it (this might be a goal as soon as the board boots up reliable even on the first run). Onboard wifi will for sure not work, cause I don't pack the driver binaries to it (I don't care about wifi yet, and there are IMO more important things to fix before I even set onboard wifi to my 'issues list'). Will most likely never be supported due to 'mainline only' and I will not implement an android wifi driver into the mainline kernel. dmesg (for next) spies some errors related to USB (xhci-mtk 1a1c0000.usb: fail to get vbus), this was solved upstream, from what I see frank-w applied the patch too for his 4.14-main branch but it seems to not work properly yet on my builds. Maybe I missed some 'USB quirks' for a kernelcommand, maybe I missed a module or something else - I didn't read all the posts related to it and I don't follow all the stuff on BPis forum to get informations. Keep in mind, I'm not super experienced and this is early WIP (I fully understand why the maintainers don't want to waste much time with new SoCs, it's a bunch of work and if it's not well documented things are even worse). Dev (Linus master branch) will not be properly packed due to changes in builddebb (a slightly adjusted mt7623n-dev.config based on frank-w 4.16 defconfig is there but completely untested, it build's without fails but I never booted a dev image - wouldn't be surprised that it will not boot). 4.17.0-rc7 based on multi_v7_defconfig slightly adjusted to bring up the device but still a lot of 'clean up' needed.  
    Disclaimer: 
    If you're smart enough, you'll find part of this initial work on GitHub (if not, it's probably better that you don't play with it, cause it's only initial, and Images built with this configuration must be expected as early experimental, for testing purposes only). Some of the adjustments living only on my buildmachine as patches and aren't pushed upstream yet (call it lazy, call it I want avoid that unexperienced people clone the repo build images and complain that they don't work as expected, I don't care)...  Every support question related to 'why is *random feature* not working' will be happily ignored. I'll share my experience only with people who want to contribute to enhance things at the moment not to use it for 'home' ore 'productive' use-cases (it's a way to early for that). 
     
    It's not armbian, it's just a Image created with armbians buildscript at the moment:  
     
     
    This thread should give the maintainers and interested people a clue what's needed to get this board up with armbian. Some Initial work is done (we don't need any FAT partition anymore, we can start the board with bootscripts) and some current limitations (appended device tree blob, binary blobs for boot, u-boot needs cleanup etc.). I think with the initial work I did, a new 'board bring up' (as the socialists in germany would say `Ergebnisoffen`  open-ended) make sense. In case it ends like the last BPi R2 board bring up thread, where people were more focused on personal insults, and people start to throw dirt to each other, I'll remove all the work I did on GitHub and close this thread! You've been warned! Some initial work is done but more is needed before I'll even consider to send a PR to Armbians repo. I would be really disappointed when somebody fork my initial work and puts then 'Armbian for BPi R2' on some services like google-drive or mega (if you want to enhance the support for it, just send PRs to the repo, it helps nobody if you make some 'experimental' builds based on the initial work and give them to inexperienced users to test, the images are simply not ready yet).
     
    So happy discussion (with valid arguments)... 
  17. Like
    chwe reacted to zador.blood.stained in BananaPi R2 (.csc mt7623 as new boardfamily)   
    You may want to play with the u-boot environment - particularly with the fdt_high value. Check the README in the u-boot sources for details.
  18. Like
    chwe reacted to tkaiser in Quick review of NanoPi Fire3   
    No idea. The only 'good' SD card that died here so far is a SanDisk Extreme Pro 8 GB I used over 3 years intensively (since both great random IO performance and also sequential performance -- burning cards with up to 80 MB/s in my MacBook was always fun). All the other cards that died were cheap Noname/Intenso/Kingston crap.
  19. Like
    chwe got a reaction from zador.blood.stained in BananaPi R2 (.csc mt7623 as new boardfamily)   
    Proposal to introduce a new BOARDFAMILY based on MT7623n SoCs. The only (widely) available board currently is the BananaPi R2 build by Sinovoip. I 'tried' to clean and split their BSP into different repos to make it usable for armbians Buildscript. The 'initial' work is done and built images boot up (with some additional work).
     

    (found one on http://www.banana-pi.org/r2.html - hidden in the 'gallery photos' which looks like the revision I have)
     
     
    Some specs (and just to be clear here, this is not a in-depth description about performance of those interfaces, there are more experienced people for benchmarking interfaces etc. don't hang me when there's a mistake in the description ):
    MT7623n (ARM Cortex-A7 quad core) GbE over MTK7530 (1x "wan" 4x "lan") 2x USB 3.0 and 1 USB 2.0 otg port 2x SATA over asm1061 (up to) 2 mPCIE interfaces (one populated as mPCIe, the other is muxed with USB3 - you've to disable USB if you want to use it - never tested) Hardware NAT & cryptoDEV (also none of them is tested in my builds made with armbians Buildscript) wifi/bluetooth combo-chip (b/g/n / 4.1) HDMI Powering over 12V barrel jack  
    Pros:
    relatively cheap (~90$ Aliexpress) Metal case and 4G modem available (I dont' own both - so must be considered as 'not working' at the moment) 2x2 MIMO WiFi should be possible over mPCIE (as before I didn't test it) MT7623 gets relatively good upstream support by Mediatek in mainline There is a 4.14.y Kernel (currently at 4.14.42 - so it seems to be quite up-to-date) maintained by 'Frank-W' which gets frequently updates and patches from upstream are back-ported (more experienced kernelhacker have to decide if he does it in a sane way or not, that's over my skills)  See https://forum.armbian.com/topic/7296-bananapi-r2-csc/?do=findComment&amp;comment=55245  the board has some nice features either as a NAS or a routerboard (I know about the concerns of mixing router with NAS capabilities and I didn't benchmark one of this features - better let people benchmark it which know what they're doing ). It seems that Sinovoip starts to clean up their GitBook mess by switching to a wiki. There are still things wrong inside (e.g. the board-picture shows a battery connector but it was removed in the newer revisions of the board, still a lot of stuff linked to sources not provided by them self e.g. description of 'how network is implemented), but at least it's not that messy than their former 'gitbook' documentation. Frank-W provides a independent wiki where he documents his efforts and what works with his builds.   
    Cons:
    u-boot is based on a v2014.04 rc1 together with some Mediatek additional stuff with further modification by Sinovoip (and in the end by me which doesn't make things much better). Some cleanup is done (not pushed to github since it's early WIP and I only push it when it works 'somehow' reliable, it fools me quite often cause I'm definitively not a 'experienced' u-boot hacker - cause it's a bit outdated a lot of things changed to upstream and I've to google a lot of stuff to get things working). There are 3 binary blobs needed to boot into U-boot (see picture) and I still don't understand fully what they're doing (as said I'm not a u-boot hacker ) http://fw-web.de/dokuwiki/lib/exe/detail.php?id=en%3Abpi-r2%3Astorage&amp;media=bpi-r2:boot-structure.png  the 'Preloader' differs between eMMC and SD-card, so this needs for sure some 'additional work' for something like nand-sata-install. The 'Headers' are in fact two files (one seems to have he size it should, the other one is to big and get's partly overwritten by the 'preloader', so no idea how sane this is) and it seems that they set some variables to env in u-boot (I simply overwrite them to ensure that they don't do insane things and the board is booted with a bootscript sitting in /boot/boot.scr (currently wip - doesn't work every-time) During compilation of u-boot there are some warnings (I didn't care cause in the end the board boots into u-boot so this warnings are of minor interest to me - it would be possible to build u-boot based on v2014.04 upstream with huge patching, as it is done for a yocto-build by Wolfgang Tolkien here, but his is currently adjusted to yocto and will need some rework to make it usable for Armbian - nevertheless, without the help of Wolfgang, this thread would never came up he gave me a lot of hints here and there to deal with u-boot) There is no kernel defconfig for the R2 nor mt7623n SoC upstream (as far as I understand frank-w made a defconfig based on a 4.9 kernel, based on the evb board - so give him the credits for doing a lot of the hard work ), nevertheless an 'mt7623n-next/dev.config' needs some adjustments.  I think, I pickt more or less all of the SoC relevant drivers after 'a few attempts'...  Currently load a kernel with 'Flattened Device Tree blob' (CONFIG_OF_LIBFDT) does not work (Wolfgang reported similar problems for his yocto builds with the R2, but it should/does work with his evb board) and only 'appended device tree blob to zImage' (I didn't care about the drawbacks yet) works yet. Probably this needs some adjustments in builddebb (at the moment this is done by hand with 'cat zImage *.dtb > zImage-dtb ). U-boot 'should' be capable of booting a with a separate dtb file but it doesn't...   The EVB can also be booted with FIT images but this seems also not work on the BPi, maybe it's related to the binaries, maybe I got fooled by u-boot once again (it happened a lot). I simply don't know. From a support point of view: This board has a bunch of features which people will mix together (from router/NAS/'home cloud' up to HDMI capabilities) for a relative affordable price, so 'less experienced' people will buy it, will mess with it and will ask here a bunch of questions when we decide to build images or have it as .csc in armbians repo. Cause it will introduce a new boardfamily (probably *.csc only at the moment) this board doesn't get any kernel updates until the maintainers decide to add it to armbians apt server and if we do, it's more than csc and people will expect 'some support'. I only did the 'initial work' so, a lot of kernel module adjustments, u-boot cleanup and enhancements are needed to build useful 'Armbian images' and to be clear: I'm not willing nor able to do all this work alone. In case no serious developer is willing to join this 'clean up' party, we should not add this board to .csc cause it will end similar to the OPi-2g-IoT where people ask from time to time for support whereas nobody works actively to enhance the Images.  No LTS-Kernel due to 4.14 has a lot of back-ports inside which might mess up things in case a other member of the same SoC will join the boardfamily. Edit: just in case somebody asks, as far as I know HDMI is not working yet on 4.14 and only usable with the 4.4 BSP kernel, I played some days with it, tried to fix things, I failed, I got headache from the BSP-Kernel and decided to drop it fully. From my side, there will be no efforts in the BSP Kernel to get it working. If someone wants to deal with it, there's a 'kernel only' repo on my github fully 'unmaintained' not patched and currently not available as buildoption. I think people who are able to fix issues for this kernel are able to add it as buildoption but I decided to not deal with it.  
    So to summarize, what's done, what works and what's not working (everything not mentioned here must be considered as not working!):
    Next Kernel (4.14.y) builds without issues, the devicetree blob is attached after its manually (mount image --> cat zImage *dtb > zImage-dtb) Will not longer be supported by my builds. U-Boot was slightly adjusted so that it is capable of booting zImages, is able to handle ext4 FS & getting it's bootscript from /boot/boot.scr. This needs still some rework for accessing eMMC due to not working 100% reliable with freshly built Images (the first boot is done by manual u-boot commands, probably due to something gone wrong with the bootscript, after recompilation of boot.cmd onboard, the board boots up automatically without manual u-boot hacking) SATA devices are recognized, ETH was only tested once and didn't work (I guess, some adjustments in NM are needed or I missed something, cause the board is mostly connected only via UART during testing I didn't spend much attention to it (this might be a goal as soon as the board boots up reliable even on the first run). Onboard wifi will for sure not work, cause I don't pack the driver binaries to it (I don't care about wifi yet, and there are IMO more important things to fix before I even set onboard wifi to my 'issues list'). Will most likely never be supported due to 'mainline only' and I will not implement an android wifi driver into the mainline kernel. dmesg (for next) spies some errors related to USB (xhci-mtk 1a1c0000.usb: fail to get vbus), this was solved upstream, from what I see frank-w applied the patch too for his 4.14-main branch but it seems to not work properly yet on my builds. Maybe I missed some 'USB quirks' for a kernelcommand, maybe I missed a module or something else - I didn't read all the posts related to it and I don't follow all the stuff on BPis forum to get informations. Keep in mind, I'm not super experienced and this is early WIP (I fully understand why the maintainers don't want to waste much time with new SoCs, it's a bunch of work and if it's not well documented things are even worse). Dev (Linus master branch) will not be properly packed due to changes in builddebb (a slightly adjusted mt7623n-dev.config based on frank-w 4.16 defconfig is there but completely untested, it build's without fails but I never booted a dev image - wouldn't be surprised that it will not boot). 4.17.0-rc7 based on multi_v7_defconfig slightly adjusted to bring up the device but still a lot of 'clean up' needed.  
    Disclaimer: 
    If you're smart enough, you'll find part of this initial work on GitHub (if not, it's probably better that you don't play with it, cause it's only initial, and Images built with this configuration must be expected as early experimental, for testing purposes only). Some of the adjustments living only on my buildmachine as patches and aren't pushed upstream yet (call it lazy, call it I want avoid that unexperienced people clone the repo build images and complain that they don't work as expected, I don't care)...  Every support question related to 'why is *random feature* not working' will be happily ignored. I'll share my experience only with people who want to contribute to enhance things at the moment not to use it for 'home' ore 'productive' use-cases (it's a way to early for that). 
     
    It's not armbian, it's just a Image created with armbians buildscript at the moment:  
     
     
    This thread should give the maintainers and interested people a clue what's needed to get this board up with armbian. Some Initial work is done (we don't need any FAT partition anymore, we can start the board with bootscripts) and some current limitations (appended device tree blob, binary blobs for boot, u-boot needs cleanup etc.). I think with the initial work I did, a new 'board bring up' (as the socialists in germany would say `Ergebnisoffen`  open-ended) make sense. In case it ends like the last BPi R2 board bring up thread, where people were more focused on personal insults, and people start to throw dirt to each other, I'll remove all the work I did on GitHub and close this thread! You've been warned! Some initial work is done but more is needed before I'll even consider to send a PR to Armbians repo. I would be really disappointed when somebody fork my initial work and puts then 'Armbian for BPi R2' on some services like google-drive or mega (if you want to enhance the support for it, just send PRs to the repo, it helps nobody if you make some 'experimental' builds based on the initial work and give them to inexperienced users to test, the images are simply not ready yet).
     
    So happy discussion (with valid arguments)... 
  20. Like
    chwe reacted to arhi in single user mode ?   
    looks like a dead bloody card ... you write to it, it ignores writes ?!?!?!?! have not had this before .. wow .. well you learn something new every day thanks for help I'd probbly never put the serial on my own
     
  21. Like
    chwe got a reaction from arhi in single user mode ?   
    hmm I don't like videos, but yeah you don't have much other possibilities to show what's going on... 
     
    First a USB-UART would help yo in case something is visible on uart but not on hdmi, second starting Kernel is normally the last message you get from u-boot before the kernel controls output.. So it seems that he is only shortly able to post something on your HDMI before it f*cks up (maybe he talks a bit more to you on console, might be interesting... )..  But a good thing.. boot.scr (that's where your bootscript lives, which gives u-boot the possibility to set bootargs for the kernel) seems to be loaded and executed properly.. so you can set 'debug commands'  for the kernel.. So there's still hope..  but I think you should record when possible on serial console rather than HDMI and hope that the kernel isn't that shy to talk to you..   
    cp boot.scr boot.scr.orig edit boot.cmd with the arguments you want to send to the kernel from u-boot (sitting in bootargs=blablabla) mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr Cause you consider starting from plain again.. there's not much you can lose...    
    Edit: your u-boot talks much more to you that the one I'm currently working with.. Makes things easier..   
  22. Like
    chwe got a reaction from datsuns in Quick review of NanoPi Fire3   
    Cause the SD-Card isn't that far away from the CPU... You should have in mind that 'consumer grade' SD-Cards don't like heat that much.  They are mostly rated 'up to 85°C'... And according to this one (https://www.sdcard.org/press/thoughtleadership/150715_why_sd_memory_cards.html):
     
    they might not live that long at high temperatures.. I tried once to get some additional information from 'sd-card' makers (did they any tests? how well will their cards perform at higher temps? etc.) but the only answer I got was: We don't provide you any further information for consumer grade cards asking again what tests were done with industrial grade ones ended in no answer at all (not only one company, more or less every 'well known' sd-card maker refused to answer by their official support question form on their websites..  I have in mind that @tkaiser fried once a card by such a 'high temperature experiment' overnight?
     
    Edit: this might be less important if you use things like FEL and the whole thing lives inside ram, but for sure if your board will run at higher temperatures for longer time (probably buildfarm? I don't know if you solve it with SD-Cards or not).. 
     
  23. Like
    chwe got a reaction from zador.blood.stained in BananaPi R2 (.csc mt7623 as new boardfamily)   
    Proposal to introduce a new BOARDFAMILY based on MT7623n SoCs. The only (widely) available board currently is the BananaPi R2 build by Sinovoip. I 'tried' to clean and split their BSP into different repos to make it usable for armbians Buildscript. The 'initial' work is done and built images boot up (with some additional work).
     

    (found one on http://www.banana-pi.org/r2.html - hidden in the 'gallery photos' which looks like the revision I have)
     
     
    Some specs (and just to be clear here, this is not a in-depth description about performance of those interfaces, there are more experienced people for benchmarking interfaces etc. don't hang me when there's a mistake in the description ):
    MT7623n (ARM Cortex-A7 quad core) GbE over MTK7530 (1x "wan" 4x "lan") 2x USB 3.0 and 1 USB 2.0 otg port 2x SATA over asm1061 (up to) 2 mPCIE interfaces (one populated as mPCIe, the other is muxed with USB3 - you've to disable USB if you want to use it - never tested) Hardware NAT & cryptoDEV (also none of them is tested in my builds made with armbians Buildscript) wifi/bluetooth combo-chip (b/g/n / 4.1) HDMI Powering over 12V barrel jack  
    Pros:
    relatively cheap (~90$ Aliexpress) Metal case and 4G modem available (I dont' own both - so must be considered as 'not working' at the moment) 2x2 MIMO WiFi should be possible over mPCIE (as before I didn't test it) MT7623 gets relatively good upstream support by Mediatek in mainline There is a 4.14.y Kernel (currently at 4.14.42 - so it seems to be quite up-to-date) maintained by 'Frank-W' which gets frequently updates and patches from upstream are back-ported (more experienced kernelhacker have to decide if he does it in a sane way or not, that's over my skills)  See https://forum.armbian.com/topic/7296-bananapi-r2-csc/?do=findComment&amp;comment=55245  the board has some nice features either as a NAS or a routerboard (I know about the concerns of mixing router with NAS capabilities and I didn't benchmark one of this features - better let people benchmark it which know what they're doing ). It seems that Sinovoip starts to clean up their GitBook mess by switching to a wiki. There are still things wrong inside (e.g. the board-picture shows a battery connector but it was removed in the newer revisions of the board, still a lot of stuff linked to sources not provided by them self e.g. description of 'how network is implemented), but at least it's not that messy than their former 'gitbook' documentation. Frank-W provides a independent wiki where he documents his efforts and what works with his builds.   
    Cons:
    u-boot is based on a v2014.04 rc1 together with some Mediatek additional stuff with further modification by Sinovoip (and in the end by me which doesn't make things much better). Some cleanup is done (not pushed to github since it's early WIP and I only push it when it works 'somehow' reliable, it fools me quite often cause I'm definitively not a 'experienced' u-boot hacker - cause it's a bit outdated a lot of things changed to upstream and I've to google a lot of stuff to get things working). There are 3 binary blobs needed to boot into U-boot (see picture) and I still don't understand fully what they're doing (as said I'm not a u-boot hacker ) http://fw-web.de/dokuwiki/lib/exe/detail.php?id=en%3Abpi-r2%3Astorage&amp;media=bpi-r2:boot-structure.png  the 'Preloader' differs between eMMC and SD-card, so this needs for sure some 'additional work' for something like nand-sata-install. The 'Headers' are in fact two files (one seems to have he size it should, the other one is to big and get's partly overwritten by the 'preloader', so no idea how sane this is) and it seems that they set some variables to env in u-boot (I simply overwrite them to ensure that they don't do insane things and the board is booted with a bootscript sitting in /boot/boot.scr (currently wip - doesn't work every-time) During compilation of u-boot there are some warnings (I didn't care cause in the end the board boots into u-boot so this warnings are of minor interest to me - it would be possible to build u-boot based on v2014.04 upstream with huge patching, as it is done for a yocto-build by Wolfgang Tolkien here, but his is currently adjusted to yocto and will need some rework to make it usable for Armbian - nevertheless, without the help of Wolfgang, this thread would never came up he gave me a lot of hints here and there to deal with u-boot) There is no kernel defconfig for the R2 nor mt7623n SoC upstream (as far as I understand frank-w made a defconfig based on a 4.9 kernel, based on the evb board - so give him the credits for doing a lot of the hard work ), nevertheless an 'mt7623n-next/dev.config' needs some adjustments.  I think, I pickt more or less all of the SoC relevant drivers after 'a few attempts'...  Currently load a kernel with 'Flattened Device Tree blob' (CONFIG_OF_LIBFDT) does not work (Wolfgang reported similar problems for his yocto builds with the R2, but it should/does work with his evb board) and only 'appended device tree blob to zImage' (I didn't care about the drawbacks yet) works yet. Probably this needs some adjustments in builddebb (at the moment this is done by hand with 'cat zImage *.dtb > zImage-dtb ). U-boot 'should' be capable of booting a with a separate dtb file but it doesn't...   The EVB can also be booted with FIT images but this seems also not work on the BPi, maybe it's related to the binaries, maybe I got fooled by u-boot once again (it happened a lot). I simply don't know. From a support point of view: This board has a bunch of features which people will mix together (from router/NAS/'home cloud' up to HDMI capabilities) for a relative affordable price, so 'less experienced' people will buy it, will mess with it and will ask here a bunch of questions when we decide to build images or have it as .csc in armbians repo. Cause it will introduce a new boardfamily (probably *.csc only at the moment) this board doesn't get any kernel updates until the maintainers decide to add it to armbians apt server and if we do, it's more than csc and people will expect 'some support'. I only did the 'initial work' so, a lot of kernel module adjustments, u-boot cleanup and enhancements are needed to build useful 'Armbian images' and to be clear: I'm not willing nor able to do all this work alone. In case no serious developer is willing to join this 'clean up' party, we should not add this board to .csc cause it will end similar to the OPi-2g-IoT where people ask from time to time for support whereas nobody works actively to enhance the Images.  No LTS-Kernel due to 4.14 has a lot of back-ports inside which might mess up things in case a other member of the same SoC will join the boardfamily. Edit: just in case somebody asks, as far as I know HDMI is not working yet on 4.14 and only usable with the 4.4 BSP kernel, I played some days with it, tried to fix things, I failed, I got headache from the BSP-Kernel and decided to drop it fully. From my side, there will be no efforts in the BSP Kernel to get it working. If someone wants to deal with it, there's a 'kernel only' repo on my github fully 'unmaintained' not patched and currently not available as buildoption. I think people who are able to fix issues for this kernel are able to add it as buildoption but I decided to not deal with it.  
    So to summarize, what's done, what works and what's not working (everything not mentioned here must be considered as not working!):
    Next Kernel (4.14.y) builds without issues, the devicetree blob is attached after its manually (mount image --> cat zImage *dtb > zImage-dtb) Will not longer be supported by my builds. U-Boot was slightly adjusted so that it is capable of booting zImages, is able to handle ext4 FS & getting it's bootscript from /boot/boot.scr. This needs still some rework for accessing eMMC due to not working 100% reliable with freshly built Images (the first boot is done by manual u-boot commands, probably due to something gone wrong with the bootscript, after recompilation of boot.cmd onboard, the board boots up automatically without manual u-boot hacking) SATA devices are recognized, ETH was only tested once and didn't work (I guess, some adjustments in NM are needed or I missed something, cause the board is mostly connected only via UART during testing I didn't spend much attention to it (this might be a goal as soon as the board boots up reliable even on the first run). Onboard wifi will for sure not work, cause I don't pack the driver binaries to it (I don't care about wifi yet, and there are IMO more important things to fix before I even set onboard wifi to my 'issues list'). Will most likely never be supported due to 'mainline only' and I will not implement an android wifi driver into the mainline kernel. dmesg (for next) spies some errors related to USB (xhci-mtk 1a1c0000.usb: fail to get vbus), this was solved upstream, from what I see frank-w applied the patch too for his 4.14-main branch but it seems to not work properly yet on my builds. Maybe I missed some 'USB quirks' for a kernelcommand, maybe I missed a module or something else - I didn't read all the posts related to it and I don't follow all the stuff on BPis forum to get informations. Keep in mind, I'm not super experienced and this is early WIP (I fully understand why the maintainers don't want to waste much time with new SoCs, it's a bunch of work and if it's not well documented things are even worse). Dev (Linus master branch) will not be properly packed due to changes in builddebb (a slightly adjusted mt7623n-dev.config based on frank-w 4.16 defconfig is there but completely untested, it build's without fails but I never booted a dev image - wouldn't be surprised that it will not boot). 4.17.0-rc7 based on multi_v7_defconfig slightly adjusted to bring up the device but still a lot of 'clean up' needed.  
    Disclaimer: 
    If you're smart enough, you'll find part of this initial work on GitHub (if not, it's probably better that you don't play with it, cause it's only initial, and Images built with this configuration must be expected as early experimental, for testing purposes only). Some of the adjustments living only on my buildmachine as patches and aren't pushed upstream yet (call it lazy, call it I want avoid that unexperienced people clone the repo build images and complain that they don't work as expected, I don't care)...  Every support question related to 'why is *random feature* not working' will be happily ignored. I'll share my experience only with people who want to contribute to enhance things at the moment not to use it for 'home' ore 'productive' use-cases (it's a way to early for that). 
     
    It's not armbian, it's just a Image created with armbians buildscript at the moment:  
     
     
    This thread should give the maintainers and interested people a clue what's needed to get this board up with armbian. Some Initial work is done (we don't need any FAT partition anymore, we can start the board with bootscripts) and some current limitations (appended device tree blob, binary blobs for boot, u-boot needs cleanup etc.). I think with the initial work I did, a new 'board bring up' (as the socialists in germany would say `Ergebnisoffen`  open-ended) make sense. In case it ends like the last BPi R2 board bring up thread, where people were more focused on personal insults, and people start to throw dirt to each other, I'll remove all the work I did on GitHub and close this thread! You've been warned! Some initial work is done but more is needed before I'll even consider to send a PR to Armbians repo. I would be really disappointed when somebody fork my initial work and puts then 'Armbian for BPi R2' on some services like google-drive or mega (if you want to enhance the support for it, just send PRs to the repo, it helps nobody if you make some 'experimental' builds based on the initial work and give them to inexperienced users to test, the images are simply not ready yet).
     
    So happy discussion (with valid arguments)... 
  24. Like
    chwe reacted to wtarreau in Quick review of NanoPi Fire3   
    I'd say around 2 weeks.
     
    The default heatsink is enough if you're not running at 100% CPU full-time. For my use cases, it's mostly a network endpoint and I can run it at 1 Gbps without problems even with the board confined in a cardboard made enclosure. But if you run with all CPUs saturated, you'll reach around 5W that need to be dissipated one way or another. The default heatsink and the PCB are not large enough to dissipate 5W at a low temperature. I significantly raised the temperature thresholds (113, 115, 120) to prevent it from throttling too early. Note that these thresholds are higher than the datasheet's (85°C in commercial ranges). But the thermal sensor supports up to 125°C so probably there are some industrial/military grade variants with higher ranges. For a personal project I'd say you have some headroom. For a commercial product, you probably don't want to play with this and you may have to use a small fan, or to place a thermal pad behind the board against a metal enclosure.
  25. Like
    chwe reacted to TonyMac32 in banana pi single boards   
    It comes from a few things, vendor relations is one of them, but not the only one.  There is often an issue with vendor software and documentation being incomplete/incorrect/non-existent, sometimes hardware bugs, etc.  It may be improving, I haven't checked recently.