• Content Count

  • Joined

  • Last visited

  1. Now I understand. Thanks for the explanation.
  2. You stated the image size is fixed but I'm failing to understand why, could you please elaborate a little bit?
  3. 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.
  4. They're in the /root directory of the images.
  5. 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.
  6. 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?
  7. 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? Update: I checked the device tree file and found this: linux,cma { compatible = "shared-dma-pool"; reusable; size = < 0x00 0x38000000 >; alignment = < 0x00 0x400000 >; linux,cma-default; }; /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`.