ARMBIAN for Amlogic S905 and S905X (ver 5.44 =<)

[balbes150]

Hi.

Sorry for the delay with the answer.

 

1. You don't use the activation of the multi-boot, so I renamed the script ?

 

2. Directories dtb files is a "legacy" copy of the profile. Not yet got around to put in order.

 

3. The ability to load the dtb file from the root directory need to ensure that in case of problems with the auto-retrieve, you can manually copy the file and use the image in this mode.

 

4. Frequency control will be included in the next version.

 

5. USB ports on some models you need to include an additional command (it's built into the firmware, so it works on Android). The topic on freaktabe you have details on this issue. How to enable the port.

 

If you have any more questions, feel free to ask in PM and email (sometimes I may not immediately see messages in the forums).

[mdel]

sorry i'm still having problems with freaktab so i'll keep posting here.

 

so i have your armbian s905 running fine on sdcard, fixed the usb and cpufreq init (the cpufrequtils init.d script doesn't seem to work so i simply called cpufreq-set -g ondemand from rc.local).

 

now i'm trying to migrate the ROOTFS to my USB HDD but for some reason it does not work.

your s905_autoscript has the following config :

setenv bootargs "root=LABEL=ROOTFS rootwait rootflags=data=writeback rw ${condev} no_console_suspend hdmimode=${m} m_bpp=${m_bpp} fsck.repair=yes net.ifnames=0"

so i was assuming that swapping LABEL from the SD ROOTFS to USB ROOTFS would work but it doesn't.

The USB partition has been rsynced from the (live) SD ROOTFS as described in other usb migration threads and the filesystem is ext4.

 

I can see the disk is being accessed at boot and keeps being triggered at regular intervals but it won't boot, and unfortunately i don't have any screen output and have not connected serial to that board so far.

 

So is ROOTFS label swap enough (maybe my rsync failed) of should i change the boot script to point directly to PARTUUID or /dev/sda1 to achieved the migration ?

thx

[balbes150]

If possible, take a screenshot , how to look at the partitions on the USB drive in the gparted program. Then it will be easier to understand. To start you need to have two partitions 1. FAT (labeled "BOOT") 2. section with the system (labeled "ROOTFS"). Copy files to these partitions from the source SD card can regular MC as root. The use of "LABEL" in the mount points and the script just allows you to do copy in any media (which may be different UUID).

[mdel]

thx for your answer.

 

sorry i was doing something a bit stupid and probably didn't explain well enough.

i was booting from SD card (BOOT and ROOTFS) then decided to move only ROOTFS to USB (BOOT still on sdcard), and it didn't work but i may have not renamed my label properly as i saw my USB partition was labeled ROOT (not ROOTFS).

 

Maybe you can tell me if it's possible to have BOOT on SDcard and ROOTFS on USB, then i'll try again.

Anyways i moved both partitions to USB now and removed the SD card completely and it boots fine.

 

One thing that surprises me is that boot from USB is much (10 times) slower than sd card boot.

The "uboot splash screen" stays visible for 30 seconds or more, whereas from sd card it stays on only for 2 seconds or less, the usb hdd led is active during that time.

 

Looks like uboot has some speed problems from USB or maybe there are some timeouts as it's suposed to try sd card before usb.

 

But after booting is done, the system seems more responsive than from sd card.

 

one last thing that i noticed is that i do get a lot of those messages in the logs :

[36062.666215] WARN::hc_xfer_timeout:2690: hc_xfer_timeout: timeout on channel 4
[36062.685513] WARN::hc_xfer_timeout:2692: 	start_hcchar_val 0x00989200
[36062.703841] WARN::hc_xfer_timeout:2697: 	chn-4,ep2-IN:type:2,speed:2,len:24576,addr2

[36099.265635] WARN::hc_xfer_timeout:2690: hc_xfer_timeout: timeout on channel 7
[36099.284923] WARN::hc_xfer_timeout:2692: 	start_hcchar_val 0x00989200
[36099.303182] WARN::hc_xfer_timeout:2697: 	chn-7,ep2-IN:type:2,speed:2,len:24576,addr2

it's not related to sd card or usb hdd, as it happens from both boots, i believe it's related to USB kernel drivers.

Edited September 7, 2016 by mdel

[mdel]

i believe the WARN messages come from my Gigabit Ethernet dongle, don't know if it's a driver or hardware (power supply) fault..

 

The dongle seems to work fine though, i'll know more after using it this week..

[Hugo Cardozo]

 

 

one last thing that i noticed is that i do get a lot of those messages in the logs :

[36062.666215] WARN::hc_xfer_timeout:2690: hc_xfer_timeout: timeout on channel 4
[36062.685513] WARN::hc_xfer_timeout:2692: 	start_hcchar_val 0x00989200
[36062.703841] WARN::hc_xfer_timeout:2697: 	chn-4,ep2-IN:type:2,speed:2,len:24576,addr2

[36099.265635] WARN::hc_xfer_timeout:2690: hc_xfer_timeout: timeout on channel 7
[36099.284923] WARN::hc_xfer_timeout:2692: 	start_hcchar_val 0x00989200
[36099.303182] WARN::hc_xfer_timeout:2697: 	chn-7,ep2-IN:type:2,speed:2,len:24576,addr2

it's not related to sd card or usb hdd, as it happens from both boots, i believe it's related to USB kernel drivers.

 

I'm using my Odroid-C2 as a gateway, with an ASIX88772-based USB-Ethernet dongle, and I get those messages too, so I think they're related to the dongle. 

[balbes150]

Thanks for the clarification, now I understand (sorry, I use computer translation, so may not all understand correctly). Yes, it is possible to have the boot partition on the SD card, and the system on USB. To use this option (or Vice versa, the SD card ROOTFS , USB BOOT). You need to change the script by adding the command to enable SD and USB together (team "usb start" and "mmcinfo"). These commands tell u-boot to activate these systems at boot time. This will allow you to read their information and contact them. Speed USB lower SD cards (even the slowest SD cards). Especially low speed to record. Read USB for downloaded system at an acceptable level.

[mdel]

@hugo

yes i believe it is, although other users have reported the same kind of error using dvb dongles, and some solved the problem by upgrading their kernel.

 

the dongle seems to work with my (long) iperf / netcat tests, i'll have a better idea when using it in real world applications.

 

@balbes150

having all kinds of problems with my current armbian i installed your latest armbian 5.17 jessie docker image and the first boot got "stuck" with a message "waiting for rc.local script ..."

 

you can ssh into the box, and i saw that "/bin/sh /etc/vegas95_init.sh" was running so i killed it and then the boot sequence could finish.

 

i assume the problem comes from the "docker daemon" command in your script (docker is running).

[mdel]

@balbes150

thx for your answer i didn't read it before adding my other message above.

 

i understand now, it was just a test, i've moved back to SD card boot because i have USB power problem at boot and can't boot from USB reliably.

[mdel]

another thing with your armbian 5.17 image, after a few reboots and installing services (nfs, openvpn..), i still get a boot error message about "LSB first run" asking to "wait and don't shut down" and have a look at systemctl "systemctl status firstrun.service"

 

here's the output :

root@vegas95:~# systemctl status firstrun.service 
â— firstrun.service - LSB: PLEASE BE PATIENT AND DO NOT INTERRUPT THE FIRST REBOOT
   Loaded: loaded (/etc/init.d/firstrun)
   Active: failed (Result: exit-code) since Thu 2016-09-08 01:38:24 MSK; 7h ago
  Process: 802 ExecStart=/etc/init.d/firstrun start (code=exited, status=1/FAILURE)

Sep 08 01:38:24 vegas95 firstrun[802]: Error: /dev/mmcblk0: unrecognised disk label
Sep 08 01:38:24 vegas95 firstrun[802]: Error: /dev/mmcblk0: unrecognised disk label
Sep 08 01:38:24 vegas95 firstrun[802]: /etc/init.d/firstrun: line 135: d/mmc + 1 : division by 0 (error... 1 ")
Sep 08 01:38:24 vegas95 systemd[1]: firstrun.service: control process exited, code=exited status=1
Sep 08 01:38:24 vegas95 systemd[1]: Failed to start LSB: PLEASE BE PATIENT AND DO NOT INTERRUPT THE FIR...BOOT.
Sep 08 01:38:24 vegas95 systemd[1]: Unit firstrun.service entered failed state.
Hint: Some lines were ellipsized, use -l to show in full.

another thing, i don't know if it changed in recent armbian versions, but the first boot did not resize the sd card ROOTFS partition.

I resize it manually.

 

and to clarify, i'm back using an sd card (no usb hdd).

 

the error do seem to point to do_expand_rootfs(), that's probably why it didn't resize my ROOTFS partition, but then the firstrun script did not complete and stays there..

 

if you want to debut the script here's my block device table : (after i resized it manually)

root@vegas95:~# lsblk 
NAME         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
mmcblk0rpmb  179:64   0  512K  0 disk 
mmcblk0boot0 179:32   0    4M  0 disk 
mmcblk0boot1 179:48   0    4M  0 disk 
mmcblk0      179:16   0  7.3G  0 disk 
mmcblk1      179:0    0 14.9G  0 disk 
├─mmcblk1p1  179:1    0   64M  0 part /boot
└─mmcblk1p2  179:2    0 14.8G  0 part /

i'll test by adding a /root/.no_rootfs_resize and see what happens.

[balbes150]

The commands in this script can be commented out. The first team is responsible for activating sound. The second is the launch of the Docker daemon. But how does Docker, if you try to run it after boot from terminal as root ? It seems has not been correctly executed the script the initial system configuration. Perhaps the media has a bad blocks. And You can try to burn it to another media and see how it works ?

[mdel]

yes i have commented the docker command in your vegas script so now it boots fine.

 

And have added the usb bus power command for my second usb port on this a95x box.

i've also added cpufreq-set -g ondemand to activate dynamic frequencies, for some reason the default init "interactive" governor does not work and cpu is always at "2.02 GHz".

 

here's the output of the "docker daemon" command :

root@vegas95:~
 docker daemon
INFO[0000] New containerd process, pid: 3728
           
ERRO[0001] Failed to built-in GetDriver graph btrfs /var/lib/docker 
ERRO[0001] Failed to built-in GetDriver graph devicemapper /var/lib/docker 
INFO[0002] Graph migration to content-addressability took 0.00 seconds 
INFO[0002] Firewalld running: false                     
INFO[0002] Default bridge (docker0) is assigned with an IP address 172.17.0.0/16. Daemon option --bip can be used to set a preferred IP address 
WARN[0004] Your kernel does not support cgroup blkio weight 
WARN[0004] Your kernel does not support cgroup blkio weight_device 
WARN[0004] mountpoint for pids not found                
INFO[0004] Loading containers: start.                   

INFO[0004] Loading containers: done.                    
INFO[0004] Daemon has completed initialization          
INFO[0004] Docker daemon                                 commit=1.11.2 graphdriver=overlay version=1.11.2
INFO[0004] API listen on /var/run/docker.sock

the command does not go to background, so that's why the boot process got stuck.

I don't know if it's normal or not, and if you should change your command to "docker daemon &"

 

i will try a second sd card to see if the first.run script manages to resize the partition.

 

 

One last thing that annoys me a lot, during my configuration i'm getting boot problems because of fstab mounts (i don't know why yet), and the problem is that when it happens i can't ssh into the box and the display is black.

I can still use the keyboard ctrl+alt+del to reboot cleanly the system, but i can't see the boot error on screen.

 

i see that there's a lot of hdmi config in the boot process, including in the c2_init.sh script and i don't know if that's required to show the boot message but it would be nice to get a more reliable hdmi output when the linux boot stops early..

is there a way to fix that ?

thx

[balbes150]

You have a USB flash drive size from 16 GB or more ?

[mdel]

i will receive one 16GB USB3 stick in a few days.

 

I do have a few 16GB and 32GB SD cards, and i could also use a sd card usb adapter..

 

do you want me to test something ?

[balbes150]

Try to run it on you media box this way. It is a system that can be used for full backup and restore the contents of the internal memory, do not pay attention to it (you can find instructions passwords and logins to manage through a terminal with an attached keyboard). Backup and restore you not need to do. I'm interested in how to run this kernel on Your equipment and will operate the monitor\TV.

 

alt_ddBR_multidtb_v0_03_16GB__20160908.img

 

https://yadi.sk/d/lSCHFhd0sYQWX

[tkaiser]

Sorry to somewhat hijack this thread (since it's about S912 now). Has anyone already tried to run Linux for S905 boxes/SBC on S912? I just came across this limited $50 sale: http://www.banggood.com/NEXBOX-A3-Amlogic-S912-2GB-RAM-16GB-ROM-TV-BOX-p-1079100.html (ripping the logicboard out the enclosure, adding a giant heatsink and this would make a nice device for number crunching with 8 Cortex-A53 running at 1.5GHz, not?)

[balbes150]

I have not yet S912. So this is just a guess. S912 has a different graphics core. At S905 is mali 450 , S912 mali 820MP3. Perhaps they are compatible from the bottom up, but need to check. Regarding Boxing at the link - what kind of price is suspiciously low. Can specifically with this model have problems ?

[tkaiser]

Regarding Boxing at the link - what kind of price is suspiciously low. Can specifically with this model have problems ?

 

No idea, I only stumbled accross this through cnxsoft's comments feed http://www.cnx-software.com/2016/08/09/nexbox-a1-amlogic-s912-android-tv-box-presells-for-71/#comment-531514 and thought to share it curious whether there is already some progress being made regarding S912. But I also don't care that much since for me the main point with S905/ODROID-C2 is the awesome eMMC speed

[mdel]

@@balbes150

 

i've burnt your alt_ddBR_multidtb_v0_03_16GB__20160908.img image to SD card (32GB) and i'm trying to run in a my other a95x (brand new out of the box).

 

i have not installed your "android update" script to autoboot s905_autoscript from sdcard and usb.

 

And as it is, it doesn't seem to see your aml_autoscript in recovery mode, i always end up in the android recovery.

 

I tried starting recovery with the toothpick method and with adb reboot recovery but no luck..

 

this is the current (vanilla) uboot env of that a95x (s905) box :

as you can see it should start your aml_autoscript  from sd card in recovery but that doesn't work..

 

 

root@nexbox_a95x:/ # strings /dev/block/env                                    
baudrate=115200
bootcmd=run storeboot
bootdelay=1
bootmode_check=get_rebootmode; echo reboot_mode=${reboot_mode};if test ${reboot_mode} = factory_reset; then defenv_reserv aml_dt;setenv upgrade_step 2; save;fi;
cmdline_keys=if keyman init 0x1234; then if keyman read usid ${loadaddr} str; then setenv bootargs ${bootargs} androidboot.serialno=${usid};fi;if keyman read mac ${loadaddr} str; then setenv bootargs ${bootargs} mac=${mac} androidboot.mac=${mac};fi;if keyman read deviceid ${loadaddr} str; then setenv bootargs ${bootargs} androidboot.deviceid=${deviceid};fi;fi;
cvbsmode=576cvbs
display_bpp=16
display_color_bg=0
display_color_fg=0xffff
display_color_index=16
display_height=1080
display_layer=osd1
display_width=1920
dtb_mem_addr=0x1000000
ethaddr=00:15:18:01:81:31
factory_reset_poweroff_protect=echo wipe_data=${wipe_data}; echo wipe_cache=${wipe_cache};if test ${wipe_data} = failed; then run init_display; run storeargs;if mmcinfo; then run recovery_from_sdcard;fi;if usb start 0; then run recovery_from_udisk;fi;run recovery_from_flash;fi; if test ${wipe_cache} = failed; then run init_display; run storeargs;if mmcinfo; then run recovery_from_sdcard;fi;if usb start 0; then run recovery_from_udisk;fi;run recovery_from_flash;fi; 
fb_addr=0x3f800000
fb_height=1080
fb_width=1920
fdt_high=0x20000000
firstboot=0
gatewayip=10.18.9.1
hdmimode=720p50hz
hostname=arm_gxbb
init_display=hdmitx hpd;osd open;osd clear;vout output ${outputmode};imgread pic logo bootup $loadaddr;bmp display $bootup_offset;bmp scale
initargs=rootfstype=ramfs init=/init console=ttyS0,115200 no_console_suspend earlyprintk=aml-uart,0xc81004c0 ramoops.mem_address=0x20000000 ramoops.mem_size=0x100000 ramoops.record_size=0x8000 ramoops.console_size=0x4000 androidboot.selinux=permissive
ipaddr=10.18.9.97
loadaddr=1080000
netmask=255.255.255.0
outputmode=720p50hz
preboot=run factory_reset_poweroff_protect;run upgrade_check;run bootmode_check;run init_display;run storeargs;run upgrade_key;run switch_bootmode;
recovery_from_flash=if imgread kernel recovery ${loadaddr}; then wipeisb; bootm ${loadaddr}; fi
recovery_from_sdcard=if fatload mmc 0 ${loadaddr} aml_autoscript; then autoscr ${loadaddr}; fi;if fatload mmc 0 ${loadaddr} recovery.img; then if fatload mmc 0 ${dtb_mem_addr} dtb.img; then echo sd dtb.img loaded; fi;wipeisb; bootm ${loadaddr};fi;
recovery_from_udisk=if fatload usb 0 ${loadaddr} aml_autoscript; then autoscr ${loadaddr}; fi;if fatload usb 0 ${loadaddr} recovery.img; then if fatload usb 0 ${dtb_mem_addr} dtb.img; then echo udisk dtb.img loaded; fi;wipeisb; bootm ${loadaddr};fi;
sdc_burning=sdc_burn ${sdcburncfg}
sdcburncfg=aml_sdc_burn.ini
serverip=10.18.9.113
storeargs=setenv bootargs ${initargs} logo=${display_layer},loaded,${fb_addr},${outputmode} hdmimode=${hdmimode} cvbsmode=${cvbsmode} hdmitx=${cecconfig} androidboot.firstboot=${firstboot}; run cmdline_keys;
storeboot=if imgread kernel boot ${loadaddr}; then store dtb read $dtb_mem_addr; bootm ${loadaddr}; fi;run update;
switch_bootmode=get_rebootmode;if test ${reboot_mode} = factory_reset; then run recovery_from_flash;else if test ${reboot_mode} = update; then run update;else if test ${reboot_mode} = cold_boot; then run try_auto_burn; fi;fi;fi;
try_auto_burn=update 700 750;
update=run usb_burning; run sdc_burning; if mmcinfo; then run recovery_from_sdcard;fi;if usb start 0; then run recovery_from_udisk;fi;run recovery_from_flash;
upgrade_check=echo upgrade_step=${upgrade_step}; if itest ${upgrade_step} == 3; then run init_display; run storeargs; run update;else if itest ${upgrade_step} == 1; then defenv_reserv; setenv upgrade_step 2; saveenv;fi;fi;
upgrade_key=if gpio input GPIOAO_3; then echo detect upgrade key; sleep 5; run update;fi;
upgrade_step=2
usb_burning=update 1000
wipe_cache=successful
wipe_data=successful
edid.crcvalue=0x54ce0000

 

 

 

 

i can try another media, or do you want me to flash your "android update" and not test the original aml_autoscript recovery mode ?

[mdel]

okay as i did with your previous images, i renamed your s905_autoscript to aml_autoscript and used toothpick recovery and this time it worked, so maybe your current aml_autoscript does not work as expected ?
 
i will try again to make sure.
 
now you image is starting i'll check the boot messages.
 
when it's finished what should i do then ?
 
---
 
okay i have the "s905 login" prompt
 
in your pdf you say :
"The launch of the ddBR system from SD card is faster, but requires more control over the naming
of the media before starting the procedures for backup and restore."
 
but i'm not quite sure what i have to do, is it simply a linux to do a dd backup / restore of the internal emmc ?

 

okay i didn't see your pdf had many pages so i'm reading now..

[balbes150]

In these images there is no activation script multi-download. They need to be downloaded separately. The current version activation universal multi-boot here v_0.5

To record to the internal memory is NOT NECESSARY. These images are intended only for external drives. I was interested in how activated the monitor. Is there a activation monitor (HDMI) problem ?

 

https://yadi.sk/d/XHEJwdLTsWJoH

[mdel]

okay, so with your alt_ddBR_multidtb_v0_03_16GB__20160908.img, the hdmi display is fine.

 

But then i feel i must also be more specific about my setup.

I'm not using a tv (i don't have a tv here), but a pc monitor (16/10 1920x1200) with a hdmi-hdmi cable (not hdmi-dvi).

 

So yes the on screen display of that linux boot is okay.

 

As i said above the only thing that i did manually, was to remove the aml_autoscript which did not work in recovery mode and renamed the s905_autoscript to aml_autoscript and then the linux boot worked.

[balbes150]

If you activate a universal-boot, script s905_autoscript will work automatically. The order of activation can be viewed here .

 

https://github.com/150balbes/Amlogic_s905/wiki/s905_multi_boot

 

http://freaktab.com/forum/tv-player-support/amlogic-based-tv-players/s905/tronsmart-ac/firmware-roms-tools-at/565449-running-linux-from-sd-card-or-usb-flash-drive-using-balbes150-method-and-files

 

 

By the way, the latest version of LE kszaq added the script s905_autoscript.

[mdel]

okay yes i know about aml_ & s905_ autoscripts.

i'l check what you changed in your v0.5.

 

i also know that LE has its own batch of uboot env vars LExxx.

At some point one distro will conflict with another one if not careful, but i guess there's no other way to enable usb/sd direct boot and keep the original aml_autoscript "recovery only" feature.

 

Anyways so to sum up my test of your alt linux image above, its aml_autoscript did not work on my a95x recovery mode, but the s905_autoscript did work ( once renamed aml_autoscript), so i'm not sure what went wrong with the original aml_autoscript there.

 

And just to let your know, once alt linux finished booting, it didn't dhcp the network so i couldn't get to the web interface.

I didn't play with it much, i did see the rj45 port light up and "ip link show" had an eth0 interface but no lan ip.

[balbes150]

Universal multiboot (using s905_autoscript) compatible with previous versions and can replace them. It is sufficient to add properly configured the script with the necessary commands in the old system images. Therefore, no conflict of distributions no. I don't recommend using the update script system aml_autoscript to download images in normal conditions. This script is not designed to load distributions, it is necessary for a single refresh data in the internal memory (settings u-boot). Pay attention that the aml_autoscript is a script that must be run once to activate the multi-boot. Further work on the uploading of images is prescribed in the working script s905_autoscript. Which is located on external media and can freely and repeatedly modified to obtain the desired result. These changes as does not affect the contents of the internal memory based on the contents of u-boot). Therefore, even if we assume a critical error in the contents of the external script (s905_), neither of which is not critical, pulled out the carrier and can free to fix it. Unlike the script, the old scheme (which is used to download still images OE LE) makes all the changes to the internal memory and strictly prescribes the same algorithm and file names to load.

 

 

By default, ddBR prescribed static address 192.168.1.200. It is made specially that it was possible to know exactly the address of the system at the first system startup (something you could go in and change the settings on the right). By the way, to know the address of the system can then download the ddBR, log TV console and give the command "ip a".

[Shimon]

Hi @balbes150

 

I wanted to reclaim the reserved memory on Ubuntu as well so I modified the Armbian script the way you suggested:

setenv m "720p60hz"
setenv mbpp "24"
setenv hpd "true"
setenv nographics "1"
setenv bootargs "root=LABEL=rootfs rootwait ro console=ttyS0,115200n8 console=tty0 no_console_suspend hdmimode=${m} m_bpp=${mbpp} fsck.repair=yes net.ifnames=0 elevator=cfq disablehpd=${hpd}"
setenv boot_start "fdt addr 0x1000000; if test "${nographics}" = "1"; then fdt rm /reserved-memory; fdt rm /aocec; fi; booti 0x11000000 0x13000000 0x1000000"
if fatload mmc 0:1 0x1000000 /DTB/${s905_dtb}.dtb; then setenv dtb_img "1"; else if fatload mmc 0:1 0x1000000 dtb.img; then setenv dtb_img "1"; else setenv dtb_img "0";fi;fi;
if fatload mmc 0:1 0x13000000 uInitrd; then if fatload mmc 0:1 0x11000000 Image; then if test "${dtb_img}" = "1"; then run boot_start;fi;fi;fi;
if fatload usb 0:1 0x1000000 /DTB/${s905_dtb}.dtb; then setenv dtb_img "1"; else if fatload usb 0:1 0x1000000 dtb.img; then setenv dtb_img "1"; else setenv dtb_img "0";fi;fi;
if fatload usb 0:1 0x13000000 uInitrd; then if fatload usb 0:1 0x11000000 Image; then if test "${dtb_img}" = "1"; then run boot_start;fi;fi;fi;

Cheers!

              total        used        free      shared  buff/cache   available
Mem:           1975          66        1721           7         187        1867
Swap:          3950           0        3950

[mdel]

I wanted to reclaim the reserved memory on Ubuntu as well so I modified the Armbian script the way you suggested:

 

do you know how much memory is freed and if it's proportional to the total memory or if it's a default fixed value ?

 

then when disabled are there any other features of the soc hardware that get affected ?

thx

[Shimon]

It's a fixed amount (ca. 194M here), mostly reserved for the framebuffer. Normally (non-hacked-up setups) there shouldn't be any negative effects but after starting a few memory-intensive compilations I began getting strange segfaults, incl. SIGBUS errors which means this kernel's VM handling is slightly broken.

 

@mdel Did you notice OOM kills on getting close to full? (instead of using ZRAM/SWAP)

[mdel]

okay my 1GB box shows 777MB of free ram so 194MB of reserved fb ram should be about it.

 

I have not observed the oom behavior yet but i'm about to run out of it on that box and hopefully start swapping.

although i wouldn't really mind having the main userland process killed (torrent client).

 

Am i correct in assuming you modified the global update script, not the s905_autoscript ?

Then would it possible to achieve the same thing from the s905_autoscript, in order to preserve a default "fb on" for systems that would require it ?

[Shimon]

Nope, it's the main s905_autoscript - right now I've got two separate versions and simply copy the desired one over before rebooting. However, the fully headless option doesn't work reliably and coupled with the previoulsy reported VM problems, makes me conclude the kernel is too Odroid specific.

​

@balbes150 Have you seen the new 1.6Ghz C2 kernel announcement? If you're planning on updating your images with it, it would be worth going over the memory split/VM options in the kernel .config before recompiling.

​

​