Jump to content


  • Posts

  • Joined

Posts posted by utgf

  1. Look into mmc-utils. This is the tool you want to use to interact with SD/MMC/eMMC devices. SD cards do not use SMART, you might have to dig a bit further to find out how to check their health status.


    I found a doc from Micron that might be helpful: https://media-www.micron.com/-/media/client/global/documents/products/technical-note/sd-cards/tnsd02_enable_sd_health_monitor_system.pdf?rev=1fee627f3c974c139b3533bdd47a635f


    Additionally, you must use a native mmc interface to interact with your card, such as MicroSD card slots that are directly attached to the SoC, a PCIe based card reader in your laptop, or a Realtek USB card reader that uses the "rtsx_usb" driver. The normal SCSI based card readers will not work.

  2. Hello everyone,

    I have a nanopi r2s running the latest minimal focal image, and I'm having trouble with the network configuration.



    I have an intranet connected to the LAN port (lan0), and my home network connected to the WAN port (eth0). The intranet does not connect to the internet, and both networks have functional DHCP servers on different IP ranges. For some reason the system thinks it should try to access the internet via my intranet, which is definitely not going to work.


    Suppose the intranet is, how can I tell the system to use this interface if and only if I'm accessing addresses that falls under this address space, and route everything else to the other interface? I've tired "nmcli c mod $CONNECTION ipv4.never-default true" but it only gave me an error: "Error: Failed to modify connection 'Ifupdown (lan0)': failed to update connection: settings plugin does not support modifying connections".

  3. On 7/11/2020 at 10:42 AM, sfx2000 said:


    Interesting board perhaps as it continues the NEO footprint - probably not compatible with the hats/housing, but makes up with other interesting bits...


    • USB-C for power only - IIRC, the Neo/Neo2 was uUSB with OTG, so win some, lose some
    • 1GB/2GB DDR4, and two banks of it - that's nice
    • CPU/DDR4 mounted on the bottom of the board, very nice to get some heat out in a metal case.
    • USB3 - very nice...




    • Rockchip - maybe for some, not for others, but it'll be a learning curve for NEO folks used to AW H3/H
    • FAN connector - not sure if this is a good thing? or does the Rockchip need some thermal assistance


    This will almost certainly have thermal issues (see: R2S). The small heat sink they currently have is absolutely pathetic. I'll be waiting for an aluminium enclosure :)

  4. On 8/13/2020 at 5:58 PM, P.P.A. said:

    Xunlong is putting out another batch of H5 devices at the end of the month.

    Is there any particular reason to go with a H5 board these days? As I understand it, the advantage it has over the H3 are the gigabit ethernet and the 64-bit architecture, while being a bit more mature on mainline and Armbian than the H6 or similar Rockchips?

    imho H5 runs *much* cooler than RK3328 does, which makes it an appealing target for me personally :)

  5. 55 minutes ago, balbes150 said:

    Read the topic, I already answered the question why the image size is fixed. There will be no changes.


    Pay attention. The new version changed the size of the partitions that are obtained when writing an image (all images have a fixed size of 5GB).  This u-boot entry option only applies to the new version 20200218 and subsequent versions. Don't try this for old images. This will not work on older images.

    You stated the image size is fixed but I'm failing to understand why, could you please elaborate a little bit?

  6. Balbes, please consider shrinking the rootfs partition in your images, since it will be automatically expanded on first boot anyway. Reducing that partition to 1GB would be great. Currently the images take up around 5GB each when decompressed, imo it's a bit waste of space when there's only less than 1GB of actual data in them.


    This wasn't so much of a problem back when BalenaEtcher had the ability to stream images from archives, so I could simply not decompress them and use them as-is. However, they recently removed this feature and started decompressing the images to disk everytime you write the image, so I had to decompress the images to prevent them from being written to my SSD over and over again.

  7. 2 hours ago, qstaq said:

    @utgf I have just gone through this problem with some S905 boxes. The problem was not the DTB (though changing it did give me a little extra usable RAM), the problem was with legacy u-boot




    Thanks for pointing me to the right direction, but sadly I can't make get the mainline u-boot to work. Everything I do seems to lead to the same "Synchronous Abort" handler error.

  8. On 8/8/2019 at 11:48 PM, hexdump said:

    i was looking into this a while ago for a s905w tv box and found out, that a lot of memory seems to be blocked already by legacy u-boot etc. (about 120m) and you cannot get it back by changes on linux kernel side. what helps is to chainload mainline u-boot (just build the libretech-cc u-boot from 2019.07 and use the resulting u-boot.bin):


    fatload mmc 0 0x01000000 u-boot.bin
    go 0x01000000


    in legacy u-boot and then you can use regular boot.scr or extlinux to boot further from there using the chainloaded u-boot just booted.


    good luck and best wishes - hexdump


    I'm trying to get this to work but the board will always reboot itself with this error:

    gxl_p230_v1#fatload usb 0 0x01000000 u-boot.bin
    reading u-boot.bin
    851968 bytes read in 43 ms (18.9 MiB/s)
    gxl_p230_v1#go 0x01000000
    ## Starting application at 0x01000000 ...
    "Synchronous Abort" handler, esr 0x02000000
    ELR:     1000000
    LR:      77ee4824
    x0 : 0000000000000001 x1 : 0000000073ede1b8
    x2 : 0000000073ede1b8 x3 : 0000000001000000
    x4 : 0000000000000020 x5 : 000000008c137742
    x6 : 0000000077f41000 x7 : 000000000000000f
    x8 : 0000000077f5f748 x9 : 0000000000000000
    x10: 00000000003e0000 x11: 0000000000010000
    x12: 000000000000000d x13: 0000000000000000
    x14: 0000000000000000 x15: 0000000000000000
    x16: 0000000000000000 x17: 0000000000000000
    x18: 0000000073ec8e28 x19: 0000000073ede1b8
    x20: 0000000000000002 x21: 0000000001000000
    x22: 0000000000000002 x23: 0000000077f71ef8
    x24: 0000000000000000 x25: 0000000073ee4800
    x26: 0000000000000000 x27: 0000000000000000
    x28: 0000000000000000 x29: 0000000073ec8b80
    Resetting CPU ...
    resetting ...

    @hexdump The board is a s905d TV box, and I built the u-boot binaries with this tutorial: http://wiki.loverpi.com/faq:sbc:libre-aml-s805x-howto-compile-u-boot

    The "Synchronous Abort" handler always appear whenever I try to boot just about anything. I'm trying to get Fedora on this box, and possibly even UEFI booting, but the stock u-boot just won't let me test anything. Any suggestions on how I should proceed?

  9. Recently I found out that userspace programs cannot allocate memory beyond 900MB for some reason. The box has 2GB of ram, but no matter what I do, the ram usage (observed in htop) will be capped at about 900MB. The disk cache can use the memory beyond 900MB, but user programs can't. I've tried opening a large amount of tabs in Chromium or Firefox, stress-ng --vm, none of them can utilize the memory beyond 900MB and will simply act like the system has ran out of memory.


    Note that I needed to turn off the zram swap or my system will freeze if it uses more than 1GB of ram. I can reliably reproduce this issue on the latest Armbian_5.95_Aml-g12_Ubuntu_disco_default_5.3.0-rc6_desktop_20190904 image available on your yandex disk. I'm completely out of ideas now, could you please explain what's going on with the memory issue?


    I checked the device tree file and found this:

    linux,cma {
    			compatible = "shared-dma-pool";
    			size = < 0x00 0x38000000 >;
    			alignment = < 0x00 0x400000 >;

    /proc/meminfo also says "CmaTotal:         917504 kB", so basically this chunk is reserved and can't be used by normal user programs? Why is it reserved like this? I've tried removing this range, and userspace programs are suddenly able to utilize more than 900MB of ram now. Even without that range in the device tree, CmaTotal is still around 256MB, since the kernel is compiled with `CONFIG_CMA_SIZE_MBYTES=256`.

  • Create New...