Jump to content

onlinespending

Members
  • Posts

    7
  • Joined

  • Last visited

Everything posted by onlinespending

  1. Ended up installing the fbturbo driver, as per this article (http://linux-sunxi.org/Xorg), and it still really didn't improve anything.
  2. I'm wondering the same thing. I was able to install Chromium using the latest Ubuntu Trusty (which is based on Debian Jessie) armhf packages on my Debian Jessie Armbian build running on a Banana Pi M1. I had to install libgcrypt11, chromium-codecs-ffmpeg-extra, and chromium-browser Ubuntu .deb files. The rest of the dependencies were found from the Debian apt sources. But the performance is unbearably slow. I figured with 1GB and a dual-core ARMv7 processor, that web browsing would be at least decent and on par with the experience you get with smartphones. It's not even close. Since Armbian is a bare bones installation, is it possible that I'd need to install other packages to improve web browsing performance? I'm even running everything off a speedier SSD drive on the SATA port, rather than off of the SD card. I tried Midori and that consistently freezes after loading virtually any webpage. Thanks for any suggestions. UPDATE: I'm starting to suspect this has a lot to do with the fact that I'm on the mainline kernel without any GPU acceleration. So all of the X11 rendering is handled by the CPU, which naturally is going to be unbearably slow for any graphics intensive programs, like a web browser. This is just an assumption on my part, so I could be wrong. Sadly it looks like I'll have to back off to the legacy kernel until GPU support is added to the mainline kernel.
  3. so is it true that there's currently no way to enable h.264 hardware acceleration on the mainline kernel? I have a great Armbian based mainline kernel build running on my Allwinner A20 based Banana Pi but would really benefit to have h.264 hardware acceleration for improved NoMachine remote desktop support. NoMachine is infinitely faster and better than VNC, and without an arm based version of TeamViewer it's the best thing going for remote desktop control.
  4. Thanks for the suggestions, Igor. By the time I saw your responses, I had already setup an Ubuntu virtual machine on my PC to build a two partition image for the Banana Pi. Was much more painless than I expected. But this is good to know for future reference. I like having /boot and / on separate partitions simply because I can more easily change the filesystem of root and encrypt it, post installation.
  5. One solution that's perhaps easier, that doesn't require as much edits to the build environment, is to simply go through the usual compile.sh process (using the default ext4 for root) and convert post installation. This way you don't need to worry about partition resizing, and it gives you the option to encrypt root as well. You'll only want to ensure that the BOOTSIZE parameter is not 0, so that separate /boot and / partitions are created in the image. For the BananaPi, I used 16MB as you did. Once you've put the image on an SD card and gone through the initial boot, use a USB flash drive (or SATA drive) to temporarily mount as root. To do this, create a single ext4 partition on the USB drive, mount it (e.g. mount -t ext4 /dev/sda1 /mnt/usbdrv) and copy the contents of root to it (e.g. rsync -arx / /mnt/usbdrv). Now edit /boot/boot.cmd and set the root device as /dev/sda1 (assuming that's the partition you just copied root to). Rebuild the boot.scr (i.e. mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr) and reboot. You'll notice that the USB drive (or SATA) is now mounted as /root. This allows you to easily re-format the former root partition on the SD card (e.g. /dev/mmcblk0p2) as f2fs, with the ability to optionally encrypt the root partition using cryptsetup before you format it as f2fs. And it will preserve the size of the former ext4 partition, so no need to worry about the possible lack of f2fs resizing. Once you've mounted (e.g. to /mnt/sdcard) and copied the root files back over to the newly formatted /dev/mmcblk0p2 (e.g. rsync -arx / /mnt/sdcard) edit the /etc/fstab file on the sdcard to properly mount root using f2fs (e.g. /mnt/sdcard/etc/fstab) then you can just edit the /boot/bboot.cmd file to point back to /dev/mmcblk0p2, recreate boot.scr, take out the UBS flash drive, and reboot. If you do opt for encryption, you'll need to also edit crypttab (e.g. /mnt/sdcard/etc/crypttab) and edit the boot.cmd to reflect the use of an encrypted root (e.g. root=/dev/mapper/cryptroot cryptdevice=/dev/mmcblk0p2:cryptroot).
  6. just curious if there's a quick way to manipulate an existing Armbian build to have separate /boot and / partitions on my SD card, without needing to setup an Ubuntu build environment to compile everything myself. It's really the only thing I'd want to change about the pre-built image, and would like to avoid setting up the Ubuntu build box if I can. Thanks!
  7. Just wanted to chime in and mention that I'm seeing the same thing with a Banana Pi (M1) connected to a 4K monitor. Works fine with the legacy kernel.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines