James Kingdon

Members
  • Content Count

    142
  • Joined

  • Last visited


Reputation Activity

  1. Like
    James Kingdon got a reaction from TRS-80 in Odroid XU4 - Ubuntu Xenial doesn't run on eMMC   
    Kudos to @tkaiser for providing so much quality info here.
  2. Like
    James Kingdon reacted to kevery in NanoPC T4   
    I'm Kever Yang from Rockchip BSP team, and I'm in charge of open source for Rockchip SoCs, you should able to see my patches to upstream U-Boot and kernel. Thanks very much to @tkaiser for share this thread to me, and I hope I can do some explanation here so that help developers understand what we are doing.
     
    The github(https://github.com/rockchip-linux/) is owned by Rockchip,  and repos on github consider to be a 'Linux SDK' of some of Rockchip SoCs(mainly for RK3328, RK3288, RK3399 now), we have a wiki to provide basic document for it(http://opensource.rock-chips.com/), the github is now maintained by one of our product team. We hope this github can be a good reference to developers who interested in Rockchip platform.
     
    I have to declare that Rockchip never try to stop community developers to report issue to Rockchip by github or by mail, but it's not correct to close issues without any comments, I'm sorry about what we have done and I promise it would never happen again. For some issues, we may not able to fix it, but people should get a saying if we have to close it. Rockchip always open to community, and, yes, we hope to get advice about github maintain.
     
    Here is the information about Rockchip source code:
    - Rockchip have only one common BSP maintained by BSP team, including U-Boot, kernel, rkbin(ddr, miniloader, trust), this is used in all Rockchip products and for many SoCs, so it including 4.4 base/LTS patches, upstream backport for some modules, vendor/rockchip solution for some modules because the requirement for production;
    - Rockchip product team will test for product SDK release, but usually only for one SoC per SDK, and it will fix at that point before next version SDK. 
    - Rockchip kernel is now 4.4, and will update to next LTS;    
      We try to use upstream source code as much as possible for all the modules, you can find this out by compare to our last version kernel 3.10, but still way to go.
    - Rockchip kernel is used for Android and Linux OS;
    - Github source code is a special 'Linux SDK', not like other 'fixed after release for one SoC' SDK, it keeps update and used for more than one SoCs, you can consider it to be a mirror of Rockchip internal BSP
         * that's why we not able to merge the pull request, we have to review all the source code internally;
         * the github release branch is  not maintained directly by BSP team, so it may not have maintained good enough now, I will sync with the maintainer, we will have better test, and better release flow;
    - Rockchip don't have official community version BSP which only have everything from upstream, and won't going to have one in near future;
    - Issue report(feature defeat, performance and etc) are always welcome, we want provide a better common kernel.
        We will fix issues really need to fix, people don't want to get a kernel always have the same issue.
    - We focus on evb first for new SoCs, and some popular board will add later; this may be one of the conflict with the what community wants.
     
        About the common kernel for community, here is my suggestion:
    - Community can chose one kernel version fork from Rockchip as common kernel, now the kernel4.4 already has good support for RK3288/RK3399/RK3328;
    - Developing, apply patches for new board support, switch some of module to upstream driver, and so on;
    - Upstream the new board support or feature support as much as you can, then rockchip kernel can support it when update to new kernel;
    - If some feature/performance issue need to fix recently, community people can contact Rockchip/me, we will try to fix it if we can;
    - maybe a mailing list is needed for better communication?
  3. Like
    James Kingdon reacted to Xalius in H6 boards: Orange Pi One Plus, Orange Pi 3 Plus and Pine H64   
    I assembled a mainline (thanks @Icenowy and @jernej!) image with some Arch rootfs for my PineH64 and now after the libdram workarounds and other spl fixes seem to work, I got a least USB2, USB3 and GbE working...  waiting for some more linux-sunxi upstream patches now to fix an issue with DRAM clocks...
  4. Like
    James Kingdon reacted to joaofl in H6 boards: Orange Pi One Plus, Orange Pi 3 Plus and Pine H64   
    Not really... They have organized the folders structure, but the images there are still the same. However, they seem to have added the schematics there: https://mega.nz/#F!wbRFwYyA!a-xbNcCcBQl8UlvTdwNj-g!dXJxQJQJ
  5. Like
    James Kingdon got a reaction from lanefu in H6 boards: Orange Pi One Plus, Orange Pi 3 Plus and Pine H64   
    My OPi one+ arrived. I burned the ubuntu image with etcher and it worked fine. I had to manually resize the fs but you expect a few rough edges with a new board.
     
    The bare board runs on the hot side, idling at a reported (but unconfirmed) 48C. Benchmarks quickly push it into throttling at 70C, but even so it is faster (just) than any of my other 4 core boards. I'll add a heatsink and fan and see if I can get the temps under control. If so, and if the board remains reliable it seems like excellent value for money. The H6 looks very promising.
  6. Like
    James Kingdon got a reaction from MX_Master in H6 boards: Orange Pi One Plus, Orange Pi 3 Plus and Pine H64   
    ... and here are the openssl/7z tests: https://pastebin.com/huSB5LhC
     
    @tkaiser updated results with the performance governor: https://pastebin.com/pUR5D7AA
     
    You were right, it makes a big difference to the openssl results at the smaller block sizes.
     
    The board has passive heatsinks only at the moment, fan is still to be added. I saw some temperatures in the high 60s during these runs, so it's possible/likely that some throttling still occurred.
  7. Like
    James Kingdon got a reaction from MX_Master in H6 boards: Orange Pi One Plus, Orange Pi 3 Plus and Pine H64   
    @tkaiser Memory test you requested on OPi one+ board: https://pastebin.com/ubszDSUH
     
    Temperature peaked at 53C during the test, so should have stayed well clear of any throttling. I added heatsinks this morning
  8. Like
    James Kingdon got a reaction from guidol in H6 boards: Orange Pi One Plus, Orange Pi 3 Plus and Pine H64   
    My OPi one+ arrived. I burned the ubuntu image with etcher and it worked fine. I had to manually resize the fs but you expect a few rough edges with a new board.
     
    The bare board runs on the hot side, idling at a reported (but unconfirmed) 48C. Benchmarks quickly push it into throttling at 70C, but even so it is faster (just) than any of my other 4 core boards. I'll add a heatsink and fan and see if I can get the temps under control. If so, and if the board remains reliable it seems like excellent value for money. The H6 looks very promising.
  9. Like
    James Kingdon got a reaction from MX_Master in H6 boards: Orange Pi One Plus, Orange Pi 3 Plus and Pine H64   
    My OPi one+ arrived. I burned the ubuntu image with etcher and it worked fine. I had to manually resize the fs but you expect a few rough edges with a new board.
     
    The bare board runs on the hot side, idling at a reported (but unconfirmed) 48C. Benchmarks quickly push it into throttling at 70C, but even so it is faster (just) than any of my other 4 core boards. I'll add a heatsink and fan and see if I can get the temps under control. If so, and if the board remains reliable it seems like excellent value for money. The H6 looks very promising.
  10. Like
    James Kingdon reacted to tkaiser in ODROID HC1 / HC2   
    If you look at page 1 of this thread there are thermal values from my 1st HC1. When my HC2 arrived some weeks ago I noticed a lot higher temperatures reported in the beginning. I carefully 'massaged' the PCB and this did the trick: temperatures later only a few degrees above HC1 (which is to be expected due to the additional 12V/5V DC-DC converter). So trying to get a better contact between SoC and heatsink (spreading the thermal paste) is always a good idea if the temperatures you get are a bit off.
     
    https://forum.odroid.com/viewtopic.php?t=27665
  11. Like
    James Kingdon reacted to tkaiser in ODROID HC1 / HC2   
    BTW: I tested through a variety of other OS images the last weeks/months and since some of those have been recently re-released I gave it a try again today. Just as an example how important appropriate settings are if you want to squeeze out the max out of your hardware.
     
    The following is 3 times exactly the same hardware (HC1 with same SSD as /dev/sda1, same SanDisk Extreme Plus with the OS on, same Gigabit network, same MacBook as client). It's even exactly same Debian version (latest Jessie) and also exactly identical Samba version. Why the performance differs that much is explained here in detail.
    The first distro tested uses an outdated 3.10 kernel, doesn't take care about IRQ affinity or any other relevant settings (except cpufreq scaling) and also uses default (AKA bad) Samba settings. The second distro is the one the first is based on. Same kernel but different cpufreq settings. Obviously also no further optimizations but here OMV has been installed with armbian-config/softy by me which explains the much better SMB write performance The 3rd is latest official OMV 3 image based on Armbian and our next kernel branch so using a rather recent 4.9 LTS kernel soon to be switched to 4.14 (tweaks explained here)  
    Disclaimer: The dietpi and Meveric numbers were made a few weeks ago and I couldn't believe that they were that low. But today I did a quick re-test (only one run since it takes ages due to that low performance) and so I decided to publish results. Please be aware that these Samba tests were made with a MacBook running macOS as client which does not show best possible performance (for reasons see here for example -- it needs a more recent Samba version with special settings to perform optimal with macOS clients) so most probably in real-world scenarios and with Windows as clients performance differences might not be that huge and overall SMB performance higher with the non OMV images.
     
    BTW: SMB write performance with dietpi increased by 6-7 times as expected just by adding the usual 4 simple lines with some adjusted settings to smb.conf. Edit: And 'use sendfile = yes' might also make a real difference, see posts below. Won't test with dietpi again since already deleted.
  12. Like
    James Kingdon reacted to tkaiser in UAS hang with 4.x kernels   
    Well, problem has been reported by Hardkernel to them but most probably with wrong description ('We need more than 3 minutes' instead of 'make the bridge behaving SAT compliant everywhere'), TL Lim forwarded JMicron a link I provided and established then a direct contact in parallel. When they got back it seemed they already considered this a bug and not a feature (which could be a valid alternative given drive enclosure manufacturers might prefer sending disks to sleep as soon as possible)
     
    You can follow progress here BTW: https://forum.armbian.com/topic/3317-orange-pi-zero-nas-expansion-board-with-sata-msata/?page=4
     
  13. Like
    James Kingdon reacted to tkaiser in Odroid XU4 - Ubuntu Xenial doesn't run on eMMC   
    Quick iozone benchmark with Hardkernel's red 16GB eMMC module on ODROID-XU4:
    random random kB reclen write rewrite read reread read write 102400 4 15188 17623 20108 19593 14499 17071 102400 16 32269 34309 47927 47609 40564 33184 102400 512 41923 41838 97742 99609 96272 40443 102400 1024 41208 41125 100828 101495 100518 40068 102400 16384 38858 37916 145011 144954 144665 39192 Though my benchmark is somewhat stupid since I'm running OMV on the eMMC transferred with nand-sata-install and using btrfs as filesystem which by default uses transparent file compression (which is another way to reduce wear on the media of course and speeds up writes to disk):
    /dev/mmcblk0p3 / btrfs rw,noatime,nodiratime,compress=lzo,ssd,space_cache,commit=600,subvolid=5,subvol=/ 0 0 But on the rootfs the most important performance metric is random IO with rather small blocksizes and HDDs totally suck here for obvious reasons (rotating platters, moving heads, waiting half a rotation on average for a random sector to appear below the drive's heads). This is a 2.5" HDD (7200 rpm) on my HC1 (ext4 formatted). Random IO performance with small block sizes is magnitudes lower than Hardkernel's eMMC:
    random random kB reclen write rewrite read reread read write 102400 4 11623 12880 16891 17099 668 1155 102400 16 41366 44853 46099 46464 2577 4961 102400 512 89816 87068 94534 97074 39159 43801 102400 1024 87287 84807 91958 98266 56494 55865 102400 16384 73295 76457 91464 94123 91582 79349 And you should always keep in mind how HDDs work:
    They're twice as fast when they're emtpy compared when they're full (detailed explanation) Especially when used for the rootfs fragmentation can become an issue after some time on a small partition and then performance further drops down
  14. Like
    James Kingdon reacted to tkaiser in Odroid XU4 - Ubuntu Xenial doesn't run on eMMC   
    XU4 and HC1 are fully software compatible (check the readme) and heat dissipation on HC1 is WAY BETTER than with XU4. But you're limited to 2.5" disks here and should keep in mind that Hardkernel already announced a HC2 without that much details (so maybe using the same JMS561 as on Cloudshell 2 minus the interconnection problems -- better ask in their forum).
     
    Wrt new boards being interesting for NAS use cases:
    Pine folks want to provide something called 'Cloudmedia Transformer' (same idea as XU4 vs. HC1, the Transformer is a 100% software compatible ROCK64 + JMS578 on the PCB in an heat emitting metal enclosure that fits a 2.5" HDD, they also thought about a 3.5" variant) Similar to 'Le Potato' a so called 'Le Fly' also with RK3328 might appear (the bottom one here) A bunch of RK3399 devices will be available (all with PCIe 2.x x4 and USB3), I expect software support next year on par with RK3328 EspressoBin might have stable software support next year (you can use the native SATA port there and add mPCIe SATA cards with 2 or even 4 additional real SATA ports) Allwinner H6 boards with both PCIe (single lane, PCIe 2.x) and USB3 will appear (see here and keep in mind that Banana Pi people also have an H6 board in the works) Banana Pi R2 might be ready next year (MTK software support looks promising so maybe next year when mainline kernel support matured we'll support the board) The GnuBees are not listed by intention.
     
     
  15. Like
    James Kingdon got a reaction from viking in Missing nanopi m3   
    Hmm, I have all 10 of my sbcs running off similar Chinese dc-dc converters. The higher powered boards have a V meter permanently attached to monitor the supply and are rock solid. They are more stable if you keep the input supply within a reasonable factor of the output voltage - I provide 12V on the high side (from another buck converter) rather than feeding the raw 18-20V from the laptop PSUs that I use.
  16. Like
    James Kingdon got a reaction from Naguissa in Cheap HDMI monitor -1   
    Hi,
     
    I noticed OrangePi have started selling a 7" lcd with an hdmi adapter. It's only 1000x600 (which might be an awkward resolution to get working with some SBCs) but I thought I'd give one a try. This might fit into my farm build as a dedicated status monitor or something
    It's 22 usd plus shipping:
    https://www.aliexpress.com/item/7inch-TFT-LCD-Screen-for-Orange-Pi-H3-chip-Boards/32831758014.html
  17. Like
    James Kingdon got a reaction from tkaiser in Pinebook install to eMMC?   
    Well, it seemed like a nice theory, but it didn't work. I've tried a few other things as well, such as switching the order of steps before attempting the speed switch, but nothing has helped so far. I took a look at the mmc driver in mainline, and it has changed a lot. A very quick attempt at dropping the new driver into the legacy build failed about as quickly as you'd probably expect. I think I'll try and boot a 4.x kernel and see if it can get the card into hs200/hs400. If it does then I can compare the speed change sequence in the new and old drivers, and hopefully either fix the old to match or put the effort into back porting the new. If the new driver can't get the card into hs200 either, then I'll clean up the existing HS/ddr50 hack and stick with that.
  18. Like
    James Kingdon got a reaction from tkaiser in Pinebook install to eMMC?   
    OK, I have a theory for being unable to switch to hs200 based on the following output from the mmc-utils:
     
    Power class for 52MHz, DDR at 1.95V [PWR_CL_DDR_52_195: 0xdd]
    Power class for 200MHz at 3.6V [PWR_CL_200_360: 0xdd]
     
    It looks to me like operation above 52MHz requires the module to be supplied with 3.6V and switched into the appropriate power class (in this case power class 13). This will mean an increase in power consumption from around 400mA to 700mA, so it will be interesting to see if it solves the problem and is worth the power in terms of actual performance gains.
     
    I wrote the code to switch the supply to 3.6V last night, but didn't realise at the time that I also need to configure the power class, so still failed the switch to HS200. Can't wait to get back and try the next step!
  19. Like
    James Kingdon got a reaction from pfeerick in Quick Pinebook Preview / Review   
    Small steps - with Zador's help I got the armbian build system working with Docker and managed to force in my changes. The new kernel now runs better than my previous attempt which couldn't load any modules for some reason, which prevented wifi from working amongst other things.
     
    I also found that the uboot version of mmc.c has the same test for csd.rev which seems like a reasonable explanation for the boot failure from eMMC, so I've removed the test and rebuilt uboot. I installed the resulting .deb onto the armbian running from sd card, rebooted and have now started a fresh run of nand-sata-install. The only problem is that I have no idea where nand-sata-install gets the copy of uboot to write to the eMMC, so I hope it picks up my modified version and not a copy of the original from somwhere!
     
    Ah, looks like the installer gets uboot from /usr/lib/linux-u-boot-pinebook-a64_5.32_arm64/ and that's been updated today, so presumably contains my new build:
     
    /usr/lib/linux-u-boot-pinebook-a64_5.32_arm64$ ls -l
    total 960
    -rw-rw-r-- 1 root root 983040 Sep  4 11:46 u-boot-with-dtb.bin
     
    Fingers crossed!
  20. Like
    James Kingdon got a reaction from pfeerick in Quick Pinebook Preview / Review   
    The fix for the 64G eMMC module looks promising - the module is now recognized when I boot armbian from sd card using the modified kernel. It's currently formatting the eMMC as the first stage of nand-sata-install...
     
    The fix is trivial. In drivers/mmc/core/mmc.c, remove or comment out the conditional block at line 317
    card->ext_csd.rev = ext_csd[EXT_CSD_REV];     /**     if (card->ext_csd.rev > 7) {         pr_err("%s: unrecognised EXT_CSD revision %d\n",             mmc_hostname(card->host), card->ext_csd.rev);         err = -EINVAL;         goto out;     }     */ This test has been removed from later releases of the driver and a comment added to indicate that the cards should be backwards compatible so the test is unnecessary.
  21. Like
    James Kingdon got a reaction from tkaiser in Pinebook install to eMMC?   
    Success! I made a rather hacky change by disabling the following call in mmc_complete_init:
    /**     err = sunxi_switch_to_best_bus(mmc);     if (err) {         MMCINFO("switch to best speed mode fail\n");         return err;     }     */ That was sufficient to allow the system to boot from the emmc. Once the kernel starts up it looks like the emmc is initialised again by the kernel's version of the mmc driver,  so that's where it makes more sense to spend time trying to get full hs400 support working.
  22. Like
    James Kingdon got a reaction from zador.blood.stained in Quick Pinebook Preview / Review   
    The fix for the 64G eMMC module looks promising - the module is now recognized when I boot armbian from sd card using the modified kernel. It's currently formatting the eMMC as the first stage of nand-sata-install...
     
    The fix is trivial. In drivers/mmc/core/mmc.c, remove or comment out the conditional block at line 317
    card->ext_csd.rev = ext_csd[EXT_CSD_REV];     /**     if (card->ext_csd.rev > 7) {         pr_err("%s: unrecognised EXT_CSD revision %d\n",             mmc_hostname(card->host), card->ext_csd.rev);         err = -EINVAL;         goto out;     }     */ This test has been removed from later releases of the driver and a comment added to indicate that the cards should be backwards compatible so the test is unnecessary.
  23. Like
    James Kingdon got a reaction from Pouria in Server and Desktop Ubuntu OPI Win issues   
    Hi Pouria,
     
    welcome to the forum
     
    The support for the OPi Win board is still very much being developed. You're welcome to try the images out and see how they work, but they will probably change from day to day and there is no particular expectation that anything will work. If I remember correctly hdmi output isn't working for me either, but since I use it headless that's not a problem for me.
     
    If you're expecting a more complete OS you'll need to give the devs more time and wait until a release is made in the "stable builds" group.
     
    All the best!
  24. Like
    James Kingdon got a reaction from Igor in Server and Desktop Ubuntu OPI Win issues   
    Hi Pouria,
     
    welcome to the forum
     
    The support for the OPi Win board is still very much being developed. You're welcome to try the images out and see how they work, but they will probably change from day to day and there is no particular expectation that anything will work. If I remember correctly hdmi output isn't working for me either, but since I use it headless that's not a problem for me.
     
    If you're expecting a more complete OS you'll need to give the devs more time and wait until a release is made in the "stable builds" group.
     
    All the best!
  25. Like
    James Kingdon reacted to EkSeL in rk3288 alternative boards (cheap tv boxes).   
    First, I have to thank @jeanrhum for posting the UT3S deal. Thanks!
     
    I have managed to boot my UT3S via SD card with the MyyQi kernel and the rootfs from the Miqi Armbian image without making any changes to the internal eMMC.
     
    My UT3S came with U-Boot 2014.10-RK3288-02 (Nov 10 2014 - 03:41:49) and I have not done any firmware updates.
     
    Here are the steps that I took:
     
    Follow this guide to creating a bootable Arch Linux ARM SD card. Make sure your UT3S will boot with it.
     
    The toolchain used in the above guide is too old to compile a mainline kernel.
    I used the gcc-linaro-5.4.1-2017.05-x86_64_arm-linux-gnueabihf toolchain which can be downloaded from here:  https://releases.linaro.org/components/toolchain/binaries/latest-5/arm-linux-gnueabihf/
     
    Download the MyyQi build script.
     
    At the top of GetPatchAndCompileKernel.sh I replaced the CROSS_COMPILE line with the following:
    export TOOLCHAIN_PATH=/path/to/toolchain export CROSS_COMPILE=${TOOLCHAIN_PATH}/gcc-linaro-5.4.1-2017.05-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf- export LD_LIBRARY_PATH=${TOOLCHAIN_PATH}/gcc-linaro-5.4.1-2017.05-x86_64_arm-linux-gnueabihf/lib:${TOOLCHAIN_PATH}/gcc-linaro-5.4.1-2017.05-x86_64_arm-linux-gnueabihf/libexec/gcc/arm-linux-gnueabihf/5.4.1 export PATH=${TOOLCHAIN_PATH}/gcc-linaro-5.4.1-2017.05-x86_64_arm-linux-gnueabihf/bin:$PATH  
    Run GetPatchAndCompileKernel.sh
    The output should go to /tmp/MyyQi
     
    Do the following to write a bootable SD card:
    cd archlinux-firefly ./firefly-rk3288-kernel/mkkrnlimg /tmp/MyyQi/boot/zImage kernel.img ./firefly-rk3288-kernel/resource_tool /tmp/MyyQi/boot/rk3288-miqi.dtb ./bin/rockchip-mkbootimg/mkbootimg --kernel kernel.img --ramdisk initrd.img -o linux-boot.img # Remove links to firefly kernel rm create-linux-sdcard-usb/boot-linux.img rm create-linux-sdcard-usb/kernel-linux.img cp linux-boot.img create-linux-sdcard-usb/boot-linux.img cp kernel.img create-linux-sdcard-usb/kernel-linux.img cp resource.img create-linux-sdcard-usb/resource-linux.img cd create-linux-sdcard-usb sudo ./create-linux-sdcard-usb  
    You should now have a bootable SD card with MyyQi kernel but no rootfs.
     
    Download the Miqi Armbian image and follow this guide for how to extract the rootfs from an Armbian image.
    Important: Make sure your rootfs image has the label "linuxroot".
     
    Copy firmware and modules from MyyQi kernal to rootfs image:
    cp /tmp/MyyQi/lib/* /path/to/rootfs/image/lib
    Write the rootfs image you have created to USB.
     
    If you would prefer to have the rootfs on the SD card you are using for booting:
    Copy the "create-linux-sdcard" script from the Linuxium RK3288 tools to archlinux-firefly/create-linux-sdcard-usb.
     
    Write SD card with rootfs:
    cd archlinux-firefly/create-linux-sdcard-usb ln -s /path/to/rootfs.img linux-rfs.img sudo ./create-linux-sdcard Put SD card (and optionally USB drive) in UT3S and power on.