[Hardware Hacking General] osm0sis:
Sure.

- 1) Most devices use device.fstab (ie. fs tab = filesystem table) files to mount, but you can also mount from commands in .rc files.

Stock kernel for Matricom G-Box Midnight MX2 mounts the init language way from init.amlogic.board.rc:

mount ext4 /dev/block/system /system ro noatime nodiratime noauto_da_alloc
e2fsck -y /dev/block/data
mount ext4 /dev/block/data /data noatime nodiratime norelatime nosuid nodev noauto_da_alloc
mount ext4 /dev/block/cache /cache noatime nodiratime norelatime nosuid nodev noauto_da_alloc

But the mount command doesn't accept data=writeback (no idea why, but it's like that on every device), and also doesn't appear to accept noauto_da_alloc like even Matricom intended, so I switched it to the command my GN uses to mount via fstab:

e2fsck -y /dev/block/data
mount_all /fstab.amlogic
# workaround for hung boots with nodiratime+noatime or barrier=0+data=writeback
# which can occur on some devices when used as mount options for userdata via the fstab
mount ext4 /dev/block/data /data remount nosuid nodev noatime nodiratime barrier=0

As you can see I also remounted to add even more options, this is to be safe since on my GN putting certain options together via fstab can cause problems on boot, but set any time after works fine. Everything has its limitations, I guess. I'm not sure if the MX Box has this problem, but I didn't want to take the chance considering I don't have AV output in recovery access on my device for some reason. Better safe than sorry, for my own sanity. Anyway, you can see it calls the mounts from the fstab file where the majority of the options are now.

fstab.amlogic:

# Android fstab file.
#<src> <mnt_point> <type> <mnt_flags and options> <fs_mgr_flags>
# The filesystem that contains the filesystem checker binary (typically /system) cannot
# specify MF_CHECK, and must come before any filesystems that do specify MF_CHECK

/dev/block/system /system ext4 ro,nodev,noatime,nodiratime,barrier=0,data=writeback,noauto_da_alloc,discard wait
/dev/block/cache /cache ext4 nosuid,nodev,noatime,nodiratime,errors=panic,barrier=0,nomblk_io_submit,data=writeback,noauto_da_alloc,discard wait
/dev/block/data /data ext4 nosuid,nodev,noatime,errors=panic,nomblk_io_submit,data=writeback,noauto_da_alloc,discard wait

- 2) The MX Box has a USB-OTG port on the back which theoretically should be able to support ADB over USB (like any open Android device) when connected to a PC, but Matricom has this disabled, so we have to resort to using ADB over TCP. This is not enabled on boot by default, and works best when enabled after the device has already established a connection on the network, so I tied it to it receiving an IP address from the network via DHCP in init.usb.rc:

# adb over network when connected
on property:service.adb.tcp.port=*
stop adbd
start adbd

on property:service.adb.tcp.enable=1
setprop service.adb.tcp.port 5555
on property:service.adb.tcp.enable=0
setprop service.adb.tcp.port -1

on property:dhcp.wlan0.ipaddress=*
setprop service.adb.tcp.enable 1
on property:dhcp.eth0.ipaddress=*
setprop service.adb.tcp.enable 1

Any time the service.adb.tcp.port property changes (eg. with setprop) then adbd (the adb daemon) restarts to open/listen on the port. Setting the port is also now tied to the new service.adb.tcp.enable property I added, which you can just set to 1 or 0 to enable or disable, respectively. Then finally, I made having an IP address change on the wlan0 (Wireless LAN) or eth0 (Ethernet) interfaces trigger setting that enable property to 1 so that the port will be set, which will then trigger the service to restart.

- 3) Certain mount options are known to improve access time or even throughput. sysfs is the temporary filesystem under /sys/ and /proc/ where all the temporary userspace files you can change kernel options with/get info from exist. They reset on every boot. I've found through my testing that using nodiratime and noatime on the sdcard and sysfs can improve access speed and overall fluidity/responsiveness of the system. The reason for this is atime sets the last access time for a file, but this is completely pointless on something that's just going to disappear the next time you reboot, so we disable it and the system has less to worry about when accessing them, making it faster.

- 4) We could patch the kernel if we had the source... but we don't have the actual source so we can't. All I'm doing are changes to the ramdisk which affect the settings on boot in various ways, for example by changing file values in the sysfs. Benni did find some source for the board in general, but to make that work for us on our specific device you'd need an experienced kernel dev.

Whew. Hopefully that all made sense. I've got a couple days off now (worked nights all weekend). I'll see if I can improve those pesky benchmarks for us all. :cool: