Update (08/26/2017) Update:
I updated my SATV Pro 2015 to ROM 5.x, I did not have to replace dtb file. The img files from link below seem still working.
The following have been tested for SATV ROM 3.x.
Latest boot images based on L4T24.2 for external SD card, USB drive, internal EMMC and internal HDD can be downloaded from:
https://drive.google.com/file/d/0Bz5kaPQJx_AgZ3lvWWZFNmJFcmM/view?usp=sharing
Where,
"mmcblk1p1.img" is for booting to rootfs on external SD card.
"sda1.img" is for booting to rootfs on external USB drive (or SD card in USB adapter), or internal SATA HDD of modified 16GB SATV.
"mmcblk0p29.img" is for booting to rootfs on partition 29 (User Data) of internal eMMC of 16GB SATV if only Ubuntu is needed.
"mmcblk0p1.img" is for boot to rootfs on partition 1 of internal eMMC of SATV Pro.
"sda32.img" is for booting to rootfs on partition 32 (User Data) of HDD of 500GB SATV Pro if only Ubuntu is needed.
"sda33.img" is for booting to rootfs on partition 33 of HDD of 500GB SATV Pro for Ubuntu (modification of HDD partition table is needed).
"sda34.img" is for booting to rootfs on partition 34 of HDD of 500GB SATV Pro for Ubuntu (modification of HDD partition table is needed).
You will need to download L4T24.2 driver package and rootfs from Nvidia (https://developer.nvidia.com/embedded/linux-tegra), apply binary drivers to rootfs and copy it to external SD card/USB drive, see this post:
http://forum.xda-developers.com/showpost.php?p=69202451&postcount=421
or internal eMMC or HDD (of SATV Pro):
http://forum.xda-developers.com/showpost.php?p=69202672&postcount=422
L4T24.2 dtb from L4T24.2 rootfs "/boot" needs to be flashed. To find dtb name for your SATV, type the following in recovery mode:
sudo fastboot oem dtbname
Flash the wrong dtb will likely brick the SATV!!!
To have Wifi working, "/lib/firmware/brcm/fw_bcmdhd.bin" need to be replaced with the one from SATV (in /system/vendor/firmware/bcm4354).
To build kernel from source, download the latest L4T kernel source, modify tegra21_defconfig by adding "CONFIG_ANDROID=y", example configuration file can be downloaded from the following link
https://forum.xda-developers.com/showpost.php?p=69078331&postcount=417
Thanks for this. I'll see if I can get something booting. Very much appreciated. Glad to see some real dev going into these boxes lately. Not discrediting all the amazing devs so far, just commenting the interest is really ramping up!
thanks for the post, i was reading some things, we do have the issue with the device trees for full linux sort of. found a rather good explanation for dtbs here https://events.linuxfoundation.org/sites/events/files/slides/petazzoni-device-tree-dummies.pdf if anyone is interested. i was now checking in the cm12.1 kernel under arch/arm/boot/dts and saw there are many foster dts, to build dtbs at kernel compile time. Do we need to use tegra124-loki-foster.dts or tegra124-loki-foster-p2530-0900-c00-00.dts for the 16 gb shield, i know for the pro there is tegra124-loki-fosterhdd-p2530-0900-c00-00.dts
btw i have the l4t with cuda and your prebuilt kernel working and am running some testes with a specialized cuda program, it appears it can do around 330Gflops on the gpu (assuming the maximum of 512gflops it appears already to be good performance), second thing, comparing the single and quad core performance it has a speedup of 3.3 going from 1 to 4 cores, while going from 32bit l4t to 64bit ubuntu from the other thread here, the 64 bit one is around 13% faster both in single and quadcore computation (obviously cant compare cuda speed). on the 64 bit version it needs 3 minutes to compute something that a 2600k needs 1 minute. so the 2600k appears to be for this use approx (only) 3 times faster
crnkoj said:
thanks for the post, i was reading some things, we do have the issue with the device trees for full linux sort of. found a rather good explanation for dtbs here https://events.linuxfoundation.org/sites/events/files/slides/petazzoni-device-tree-dummies.pdf if anyone is interested. i was now checking in the cm12.1 kernel under arch/arm/boot/dts and saw there are many foster dts, to build dtbs at kernel compile time. Do we need to use tegra124-loki-foster.dts or tegra124-loki-foster-p2530-0900-c00-00.dts for the 16 gb shield, i know for the pro there is tegra124-loki-fosterhdd-p2530-0900-c00-00.dts
btw i have the l4t with cuda and your prebuilt kernel working and am running some testes with a specialized cuda program, it appears it can do around 330Gflops on the gpu (assuming the maximum of 512gflops it appears already to be good performance), second thing, comparing the single and quad core performance it has a speedup of 3.3 going from 1 to 4 cores, while going from 32bit l4t to 64bit ubuntu from the other thread here, the 64 bit one is around 13% faster both in single and quadcore computation (obviously cant compare cuda speed). on the 64 bit version it needs 3 minutes to compute something that a 2600k needs 1 minute. so the 2600k appears to be for this use approx (only) 3 times faster
Click to expand...
Click to collapse
I'm very interested in Cuda testing on Shield TV, I posted on Nvidia TX1 board:
https://devtalk.nvidia.com/default/...da-7-0-jetson-tx1-performance-and-benchmarks/
I thought Nvidia advertised Tegra X1 maximum of 1TFlops.
How did you test 64 bit version?
Which Cuda tests did you run?
yahoo2016 said:
I'm very interested in Cuda testing on Shield TV, I posted on Nvidia TX1 board:
https://devtalk.nvidia.com/default/...da-7-0-jetson-tx1-performance-and-benchmarks/
I thought Nvidia advertised Tegra X1 maximum of 1TFlops.
How did you test 64 bit version?
Which Cuda tests did you run?
Click to expand...
Click to collapse
firstly to the perfromance it advertises 512gflops/s single precision fp32 and 1tflops/s half precision fp16, you can check here
http://www.anandtech.com/show/8811/nvidia-tegra-x1-preview/2
i think its just marketing with 1Tflop...
secondly i think you misunderstood me, maybe my post was a bit confusing
i managed to test CUDA on the L4T 32 bit, but not on the 64 bit Ubuntu.
the 330 GFLOPs were on L4T 32 bit using a program called CHARMM for molecular dynamics (actually a friend tested it through ssh). That was just a short test to see the peak.
We tested the CPU performance with the same program, this time both on 32 bit L4T and 64 bit Ubuntu, there 64 bit Ubuntu was 13% faster, both single threaded and 4 threaded (comparing 1 cpu to 4 cpus/whole SOC), and the speedup multiplier between 1 and 4 threads was 3,3, which is better than that on a 2600k (it has 3,2). The difference in speed in this CPU only test was however comparing the 2600k and the shield on maximum performance (eg shield 4 threads, i think 2600k he tried with ht turned on so 8 threads) was of a factor of 3, 2600k = 1 minute, shield = 3 minutes. CPU only speed.
We are now testing with more demanding parameters so it takes longer, so we can compare the time it takes on the shield on the GPU/CUDA to the time it takes on x86 with a dedicated gfx (660 gtx or 960 gtx), with more demanding/longer parameters because the early setup stage is too long to compare the calculations time for the GPU part otherwise.
Thats why i asked you for the way of building the kernel so i could build my own to have the system on an usb drive. furthermore it would be interesting to be able to boot with a proper linux and not android dtb, but as far as i understood @Steel01 one should not change the dtb on the partition, as otherwise the bootloader fails to start and we have a brick... Thats why the kexec method or alternatively the append dtb to kernel method would be better, but than wed need to reduce the size of the kernel/initramfs so that we could append the dtb to it, again needing another kernel/initramfs. After that id probably try with proper 64 bit linux and try to perhaps get 32 bit cuda to work on it. or alternatively being stuck waiting for nvidia to release 64 bit l4t/cuda/drivers binaries, because i dont believe that 32 bit nvidia drivers are going to work on a 64 bit linxu system (eventually perhaps as multilib, but thats even more complicated on arm as on x64)
crnkoj said:
firstly to the perfromance it advertises 512gflops/s single precision fp32 and 1tflops/s half precision fp16, you can check here
http://www.anandtech.com/show/8811/nvidia-tegra-x1-preview/2
i think its just marketing with 1Tflop...
secondly i think you misunderstood me, maybe my post was a bit confusing
i managed to test CUDA on the L4T 32 bit, but not on the 64 bit Ubuntu.
the 330 GFLOPs were on L4T 32 bit using a program called CHARMM for molecular dynamics (actually a friend tested it through ssh). That was just a short test to see the peak.
We tested the CPU performance with the same program, this time both on 32 bit L4T and 64 bit Ubuntu, there 64 bit Ubuntu was 13% faster, both single threaded and 4 threaded (comparing 1 cpu to 4 cpus/whole SOC), and the speedup multiplier between 1 and 4 threads was 3,3, which is better than that on a 2600k (it has 3,2). The difference in speed in this CPU only test was however comparing the 2600k and the shield on maximum performance (eg shield 4 threads, i think 2600k he tried with ht turned on so 8 threads) was of a factor of 3, 2600k = 1 minute, shield = 3 minutes. CPU only speed.
We are now testing with more demanding parameters so it takes longer, so we can compare the time it takes on the shield on the GPU/CUDA to the time it takes on x86 with a dedicated gfx (660 gtx or 960 gtx), with more demanding/longer parameters because the early setup stage is too long to compare the calculations time for the GPU part otherwise.
Thats why i asked you for the way of building the kernel so i could build my own to have the system on an usb drive. furthermore it would be interesting to be able to boot with a proper linux and not android dtb, but as far as i understood @Steel01 one should not change the dtb on the partition, as otherwise the bootloader fails to start and we have a brick... Thats why the kexec method or alternatively the append dtb to kernel method would be better, but than wed need to reduce the size of the kernel/initramfs so that we could append the dtb to it, again needing another kernel/initramfs. After that id probably try with proper 64 bit linux and try to perhaps get 32 bit cuda to work on it. or alternatively being stuck waiting for nvidia to release 64 bit l4t/cuda/drivers binaries, because i dont believe that 32 bit nvidia drivers are going to work on a 64 bit linxu system (eventually perhaps as multilib, but thats even more complicated on arm as on x64)
Click to expand...
Click to collapse
Thanks for clarifications. I also noticed dtd issue, the normal linux kernel build involved the following steps:
Code:
make O=$TEGRA_KERNEL_OUT dtbs
make O=$TEGRA_KERNEL_OUT modules
make O=$TEGRA_KERNEL_OUT modules_install INSTALL_MOD_PATH=<your_destination>
I installed the outputs to my L4T rootfs, but the Android boot loader/kernel won't use them.
It's possible but more dangerous to repartition internal emmc to fix larger kernels That was done for chroubuntu on Chromebook CB5.
yahoo2016 said:
Thanks for clarifications. I also noticed dtd issue, the normal linux kernel build involved the following steps:
Code:
make O=$TEGRA_KERNEL_OUT dtbs
make O=$TEGRA_KERNEL_OUT modules
make O=$TEGRA_KERNEL_OUT modules_install INSTALL_MOD_PATH=<your_destination>
I installed the outputs to my L4T rootfs, but the Android boot loader/kernel won't use them.
It's possible but more dangerous to repartition internal emmc to fix larger kernels That was done for chroubuntu on Chromebook CB5.
Click to expand...
Click to collapse
to be perfectly honest, im not really thrilled to repartition the emmc... would kind of like to use normal android from the forums (zulu99 build) on it as well.
about the dtb, one can append it to the kernel https://events.linuxfoundation.org/sites/events/files/slides/petazzoni-device-tree-dummies.pdf like its outlined here. im just not sure can we do that since the dtb is already loaded by bootloader? about the size of the boot. img than, we dont need all the modules in the initramfs. we barely need the working minimum (base board functions, usb, ethernet), the rest can be just modules in the rootfs, hence the size of the initramfs would shrink.
Btw did you use the prebuilt initramfs or did oyu do it yourself. Lately i had some experience doing the initramfs for an atom tablet 2 in 1 on arch linux (took me some time to figure it out, but eventually i managed to do it with the mkinitcpio script). in all honesty i think easiest would be to just install arch linux 64 bit on it and natively compile all the kernels/initrams on it.
edit:
one more thing, when running the cuda testing, i see that the GPU frequency dinamically changes depending on the gpu usage, with higher usage the frequency goes down and vice versa. I guess it has some kind of TDP limit either in the kernel/drivers/dtb, which might be interesting to fiddle, as the thing certainly isnt thermally limited in the case.
For instance, using tegrastats:
Code:
RAM 1336/2807MB (lfb 63x4MB) SWAP 0/0MB (cached 0MB) cpu [0%,0%,0%,0%]@825 EMC 24%@1600 AVP 0%@80 VDE 0 GR3D 99%@921 EDP limit 2218
RAM 1336/2807MB (lfb 63x4MB) SWAP 0/0MB (cached 0MB) cpu [26%,24%,35%,25%]@825 EMC 24%@1600 AVP 0%@80 VDE 0 GR3D 91%@998 EDP limit 2218
RAM 1336/2807MB (lfb 63x4MB) SWAP 0/0MB (cached 0MB) cpu [30%,27%,43%,31%]@825 EMC 24%@1600 AVP 0%@80 VDE 0 GR3D 99%@921 EDP limit 2218
RAM 1335/2807MB (lfb 63x4MB) SWAP 0/0MB (cached 0MB) cpu [24%,27%,29%,29%]@921 EMC 24%@1600 AVP 0%@80 VDE 0 GR3D 99%@998 EDP limit 2218
RAM 1336/2807MB (lfb 63x4MB) SWAP 0/0MB (cached 0MB) cpu [28%,26%,41%,30%]@1530 EMC 24%@1600 AVP 0%@80 VDE 0 GR3D 0%@998 EDP limit 2218
RAM 1336/2807MB (lfb 63x4MB) SWAP 0/0MB (cached 0MB) cpu [27%,29%,30%,35%]@2014 EMC 24%@1600 AVP 0%@80 VDE 0 GR3D 99%@921 EDP limit 2218
RAM 1336/2807MB (lfb 63x4MB) SWAP 0/0MB (cached 0MB) cpu [25%,24%,32%,26%]@825 EMC 23%@1600 AVP 0%@80 VDE 0 GR3D 99%@921 EDP limit 2218
RAM 1336/2807MB (lfb 63x4MB) SWAP 0/0MB (cached 0MB) cpu [25%,26%,27%,32%]@825 EMC 23%@1600 AVP 0%@80 VDE 0 GR3D 99%@921 EDP limit 2218
RAM 1336/2807MB (lfb 63x4MB) SWAP 0/0MB (cached 0MB) cpu [23%,23%,39%,27%]@921 EMC 24%@1600 AVP 0%@80 VDE 0 GR3D 99%@998 EDP limit 2218
RAM 1336/2807MB (lfb 63x4MB) SWAP 0/0MB (cached 0MB) cpu [30%,28%,45%,28%]@825 EMC 24%@1600 AVP 0%@80 VDE 0 GR3D 99%@998 EDP limit 2218
RAM 1335/2807MB (lfb 63x4MB) SWAP 0/0MB (cached 0MB) cpu [27%,24%,38%,25%]@825 EMC 24%@1600 AVP 0%@80 VDE 0 GR3D 4%@998 EDP limit 2218
RAM 1335/2807MB (lfb 63x4MB) SWAP 0/0MB (cached 0MB) cpu [32%,27%,35%,38%]@2014 EMC 24%@1600 AVP 0%@80 VDE 0 GR3D 99%@921 EDP limit 2218
RAM 1335/2807MB (lfb 63x4MB) SWAP 0/0MB (cached 0MB) cpu [25%,25%,31%,29%]@825 EMC 23%@1600 AVP 0%@80 VDE 0 GR3D 99%@921 EDP limit 2218
RAM 1335/2807MB (lfb 63x4MB) SWAP 0/0MB (cached 0MB) cpu [22%,22%,27%,33%]@825 EMC 23%@1600 AVP 0%@80 VDE 0 GR3D 99%@921 EDP limit 2218
RAM 1335/2807MB (lfb 63x4MB) SWAP 0/0MB (cached 0MB) cpu [26%,33%,26%,30%]@921 EMC 24%@1600 AVP 0%@80 VDE 0 GR3D 99%@998 EDP limit 2218
RAM 1335/2807MB (lfb 63x4MB) SWAP 0/0MB (cached 0MB) cpu [29%,32%,28%,38%]@2014 EMC 24%@1600 AVP 0%@80 VDE 0 GR3D 0%@998 EDP limit 2218
RAM 1335/2807MB (lfb 63x4MB) SWAP 0/0MB (cached 0MB) cpu [27%,26%,41%,26%]@825 EMC 24%@1600 AVP 0%@80 VDE 0 GR3D 99%@921 EDP limit 2218
edit 2:
oh i just noticed the script here https://devtalk.nvidia.com/default/...da-7-0-jetson-tx1-performance-and-benchmarks/ where you posted, does this script work on our shield as well?
edit3:
k used the script, now cpu is at 2014mhz constantly, emc 1600 mhz constantly and gpu at 998 mhz constantly, the temp did in fact increase rather much lol, had to set the fan to a bit more, but 255 is too loud ^ ^
crnkoj said:
to be perfectly honest, im not really thrilled to repartition the emmc... would kind of like to use normal android from the forums (zulu99 build) on it as well.
about the dtb, one can append it to the kernel https://events.linuxfoundation.org/sites/events/files/slides/petazzoni-device-tree-dummies.pdf like its outlined here. im just not sure can we do that since the dtb is already loaded by bootloader? about the size of the boot. img than, we dont need all the modules in the initramfs. we barely need the working minimum (base board functions, usb, ethernet), the rest can be just modules in the rootfs, hence the size of the initramfs would shrink.
Btw did you use the prebuilt initramfs or did oyu do it yourself. Lately i had some experience doing the initramfs for an atom tablet 2 in 1 on arch linux (took me some time to figure it out, but eventually i managed to do it with the mkinitcpio script). in all honesty i think easiest would be to just install arch linux 64 bit on it and natively compile all the kernels/initrams on it.
edit:
one more thing, when running the cuda testing, i see that the GPU frequency dinamically changes depending on the gpu usage, with higher usage the frequency goes down and vice versa. I guess it has some kind of TDP limit either in the kernel/drivers/dtb, which might be interesting to fiddle, as the thing certainly isnt thermally limited in the case.
For instance, using tegrastats:
Code:
RAM 1336/2807MB (lfb 63x4MB) SWAP 0/0MB (cached 0MB) cpu [0%,0%,0%,0%]@825 EMC 24%@1600 AVP 0%@80 VDE 0 GR3D 99%@921 EDP limit 2218
RAM 1336/2807MB (lfb 63x4MB) SWAP 0/0MB (cached 0MB) cpu [26%,24%,35%,25%]@825 EMC 24%@1600 AVP 0%@80 VDE 0 GR3D 91%@998 EDP limit 2218
RAM 1336/2807MB (lfb 63x4MB) SWAP 0/0MB (cached 0MB) cpu [30%,27%,43%,31%]@825 EMC 24%@1600 AVP 0%@80 VDE 0 GR3D 99%@921 EDP limit 2218
RAM 1335/2807MB (lfb 63x4MB) SWAP 0/0MB (cached 0MB) cpu [24%,27%,29%,29%]@921 EMC 24%@1600 AVP 0%@80 VDE 0 GR3D 99%@998 EDP limit 2218
RAM 1336/2807MB (lfb 63x4MB) SWAP 0/0MB (cached 0MB) cpu [28%,26%,41%,30%]@1530 EMC 24%@1600 AVP 0%@80 VDE 0 GR3D 0%@998 EDP limit 2218
RAM 1336/2807MB (lfb 63x4MB) SWAP 0/0MB (cached 0MB) cpu [27%,29%,30%,35%]@2014 EMC 24%@1600 AVP 0%@80 VDE 0 GR3D 99%@921 EDP limit 2218
RAM 1336/2807MB (lfb 63x4MB) SWAP 0/0MB (cached 0MB) cpu [25%,24%,32%,26%]@825 EMC 23%@1600 AVP 0%@80 VDE 0 GR3D 99%@921 EDP limit 2218
RAM 1336/2807MB (lfb 63x4MB) SWAP 0/0MB (cached 0MB) cpu [25%,26%,27%,32%]@825 EMC 23%@1600 AVP 0%@80 VDE 0 GR3D 99%@921 EDP limit 2218
RAM 1336/2807MB (lfb 63x4MB) SWAP 0/0MB (cached 0MB) cpu [23%,23%,39%,27%]@921 EMC 24%@1600 AVP 0%@80 VDE 0 GR3D 99%@998 EDP limit 2218
RAM 1336/2807MB (lfb 63x4MB) SWAP 0/0MB (cached 0MB) cpu [30%,28%,45%,28%]@825 EMC 24%@1600 AVP 0%@80 VDE 0 GR3D 99%@998 EDP limit 2218
RAM 1335/2807MB (lfb 63x4MB) SWAP 0/0MB (cached 0MB) cpu [27%,24%,38%,25%]@825 EMC 24%@1600 AVP 0%@80 VDE 0 GR3D 4%@998 EDP limit 2218
RAM 1335/2807MB (lfb 63x4MB) SWAP 0/0MB (cached 0MB) cpu [32%,27%,35%,38%]@2014 EMC 24%@1600 AVP 0%@80 VDE 0 GR3D 99%@921 EDP limit 2218
RAM 1335/2807MB (lfb 63x4MB) SWAP 0/0MB (cached 0MB) cpu [25%,25%,31%,29%]@825 EMC 23%@1600 AVP 0%@80 VDE 0 GR3D 99%@921 EDP limit 2218
RAM 1335/2807MB (lfb 63x4MB) SWAP 0/0MB (cached 0MB) cpu [22%,22%,27%,33%]@825 EMC 23%@1600 AVP 0%@80 VDE 0 GR3D 99%@921 EDP limit 2218
RAM 1335/2807MB (lfb 63x4MB) SWAP 0/0MB (cached 0MB) cpu [26%,33%,26%,30%]@921 EMC 24%@1600 AVP 0%@80 VDE 0 GR3D 99%@998 EDP limit 2218
RAM 1335/2807MB (lfb 63x4MB) SWAP 0/0MB (cached 0MB) cpu [29%,32%,28%,38%]@2014 EMC 24%@1600 AVP 0%@80 VDE 0 GR3D 0%@998 EDP limit 2218
RAM 1335/2807MB (lfb 63x4MB) SWAP 0/0MB (cached 0MB) cpu [27%,26%,41%,26%]@825 EMC 24%@1600 AVP 0%@80 VDE 0 GR3D 99%@921 EDP limit 2218
edit 2:
oh i just noticed the script here https://devtalk.nvidia.com/default/...da-7-0-jetson-tx1-performance-and-benchmarks/ where you posted, does this script work on our shield as well?
edit3:
k used the script, now cpu is at 2014mhz constantly, emc 1600 mhz constantly and gpu at 998 mhz constantly, the temp did in fact increase rather much lol, had to set the fan to a bit more, but 255 is too loud ^ ^
Click to expand...
Click to collapse
Ideally, I'd like kernel and rootfs on external SD (the way I'm running ubuntu on my Chromebook CB5). It seems the only way would be to have multiroom or u-boot working.
I made changes to makefile of Link 1 such that the ramdisk is only 480 KB instead of 2 MB.
The "maxPef.sh" scrip to set CPU/GPU clocks is critical to maximize performance.
yahoo2016 said:
Ideally, I'd like kernel and rootfs on external SD (the way I'm running ubuntu on my Chromebook CB5). It seems the only way would be to have multiroom or u-boot working.
I made changes to makefile of Link 1 such that the ramdisk is only 480 KB instead of 2 MB.
The "maxPef.sh" scrip to set CPU/GPU clocks is critical to maximize performance.
Click to expand...
Click to collapse
I think you can forget uboot. Perhaps multirom, especially as the new pixel c tablet uses the same chipset and I think more people will use and develop for it. Yeah all the tests until now were with the stock governor and speeds. Have to retest all now...
crnkoj said:
I think you can forget uboot. Perhaps multirom, especially as the new pixel c tablet uses the same chipset and I think more people will use and develop for it. Yeah all the tests until now were with the stock governor and speeds. Have to retest all now...
Click to expand...
Click to collapse
I found someone even installed u-boot for Galaxy:
http://forum.xda-developers.com/galaxy-s2/general/uboot-bootloader-true-multiboot-t1680898
I like my Tegra K1 based Chromebook CB5, it's truly double boot (Ctl U for external Ubuntu and Ctl D for stock ChromeOs). I'll not even consider an overpriced Pixel C which does not have SD slot or USB 3 port or HDMI port. Shield TV is much better than Pixel C for hacking. I'll look into multiRom for shield, I got impression it failed to build for arm64.
yahoo2016 said:
I like my Tegra K1 based Chromebook CB5, it's truly double boot (Ctl U for external Ubuntu and Ctl D for stock ChromeOs). I'll not even consider an overpriced Pixel C which does not have SD slot or USB 3 port or HDMI port. Shield TV is much better than Pixel C for hacking. I'll look into multiRom for shield, I got impression it failed to build for arm64.
Click to expand...
Click to collapse
uhms, i meant, that now that the pixel c is out, more people will develop for it and we can use their work/cooperate
crnkoj said:
uhms, i meant, that now that the pixel c is out, more people will develop for it and we can use their work/cooperate
Click to expand...
Click to collapse
I also keep tracking of Jetson TX1 board, people are trying to install Android for TX1s (they did for TK1). I'm trying to understand how boot loaders were installed to new Tegra devices. I flashed boot loader to my Jetson Tk1 using nvidia flash script many times.
yahoo2016 said:
I also keep tracking of Jetson TX1 board, people are trying to install Android for TX1s (they did for TK1). I'm trying to understand how boot loaders were installed to new Tegra devices. I flashed boot loader to my Jetson Tk1 using nvidia flash script many times.
Click to expand...
Click to collapse
yeah cuz TK1 is a developer board and its open, the shield is a consumer devie and if you wish to use nvflash you need the SBK key - securebootkey, which nvidia wont give out, thats a given
crnkoj said:
yeah cuz TK1 is a developer board and its open, the shield is a consumer devie and if you wish to use nvflash you need the SBK key - securebootkey, which nvidia wont give out, thats a given
Click to expand...
Click to collapse
That's what I read from other thread that Nvidia broke their boot loader through OTA update, has not fixed the issue and won't give out the SBK - securebootkey.
I have to read more about SBK. I found the following from Nvidia are interesting:
http://http.download.nvidia.com/tegra-public-appnotes/tegra-boot-flow.html
http://http.download.nvidia.com/tegra-public-appnotes/bct-overview.html
The kernel built should be able to boot L4T or archLinux rootfs. The following are steps to download and configure L4T rootfs for Shield TV:
**********************************************************************************
2. Untar the files and assemble the rootfs:
sudo tar xpf Tegra210_Linux_R23.1.1_armhf.tbz2
cd Linux_for_Tegra/rootfs/
sudo tar xpf ../../Tegra_Linux_Sample-Root-Filesystem_R23.1.1_armhf.tbz2
cd ../
sudo ./apply_binaries.sh
***************************************************************
Click to expand...
Click to collapse
First time trying to build an rootfs image here, I probably did it wrong since the screen went dark right after booting and never go anywhere.
I followed OP's steps to build L4T rootfs. Then under Linux_for_Tegra/rootfs, I did
find ./ | cpio -H newc -o > ../rootfs.img
Then I dumped the image to my sd card:
dd if=../rootfs.img of=/dev/mmcblk0 bs=4194304 oflag=sync
Can anyone point out the correct way of making a L4T image? Many Thanks!
serige said:
First time trying to build an rootfs image here, I probably did it wrong since the screen went dark right after booting and never go anywhere.
I followed OP's steps to build L4T rootfs. Then under Linux_for_Tegra/rootfs, I did
find ./ | cpio -H newc -o > ../rootfs.img
Then I dumped the image to my sd card:
dd if=../rootfs.img of=/dev/mmcblk0 bs=4194304 oflag=sync
Can anyone point out the correct way of making a L4T image? Many Thanks!
Click to expand...
Click to collapse
I should finish the post with ways to flash rootfs. The contents of Linux_for_Tegra/rootfs should be copied to sd card with permissions preserved. The way I do it is.
(1). cd to Linux_for_Tegra/rootfs.
(2). "sudo tar -cpf ../rootfs.tar *
(3). format SD card ("sudo mkfs.ext4 /dev/mmvblk0p1")
(4). Mount SD card "sudo mount /dev/mmcblk0p1 /mnt".
(5). "cd /mnt"
(6). sudo tar -xpf [path to rootfs.tar]
I updated first post for steps of copying rootfs to SD card.
serige said:
First time trying to build an rootfs image here, I probably did it wrong since the screen went dark right after booting and never go anywhere.
I followed OP's steps to build L4T rootfs. Then under Linux_for_Tegra/rootfs, I did
find ./ | cpio -H newc -o > ../rootfs.img
Then I dumped the image to my sd card:
dd if=../rootfs.img of=/dev/mmcblk0 bs=4194304 oflag=sync
Can anyone point out the correct way of making a L4T image? Many Thanks!
Click to expand...
Click to collapse
yahoo2016 said:
I should finish the post with ways to flash rootfs. The contents of Linux_for_Tegra/rootfs should be copied to sd card with permissions reserved. The way I do it is.
(1). cd to Linux_for_Tegra/rootfs.
(2). "sudo tar -cpf ../rootfs.tar *
(3). format SD card ("sudo mkfs.ext4 /dev/mmvblk0p1")
(4). Mount SD card "sudo mount /dev/mmcblk0p1 /mnt".
(5). "cd /mnt"
(6). sudo tar -xpf [path to rootfs.tar]
I updated first post for steps of copying rootfs to SD card.
Click to expand...
Click to collapse
Actually it's faster with rsync
Let's say sdcard is mounted to /mnt
1. cd to /mnt
2. rsync -av /path/to/rootfs/* .
And done
crnkoj said:
Actually it's faster with rsync
Let's say sdcard is mounted to /mnt
1. cd to /mnt
2. rsync -av /path/to/rootfs/* .
And done
Click to expand...
Click to collapse
Thanks for the easier way to sync rootfs between development PC and target SD card. I did the other way to keep a copy of "rootfs.tar "on network drive so I can access it from other locations.
I'll include your way to the first post.
yahoo2016 said:
Thanks for the easier way to sync rootfs between development PC and target SD card. I did the other way to keep a copy of "rootfs.tar "on network drive so I can access it from other locations.
I'll include your way to the first post.
Click to expand...
Click to collapse
You could do the same on a network drive, just unpack the rootfs into a directory, than
rsync -av 192.168.1.2:/rootfs/* /desiredmountpoint
Or rsync -av /hdd_mountpoint/rootfs/* /sd_mountpoint
clearly it is a bigger mess on the hdd as its not one archive but a whole rootfs, though in its own directory, but you can edit the rootfs directly on the hdd.
crnkoj said:
You could do the same on a network drive, just unpack the rootfs into a directory, than
rsync -av 192.168.1.2:/rootfs/* /desiredmountpoint
Or rsync -av /hdd_mountpoint/rootfs/* /sd_mountpoint
clearly it is a bigger mess on the hdd as its not one archive but a whole rootfs, though in its own directory, but you can edit the rootfs directly on the hdd.
Click to expand...
Click to collapse
I edited the first post to include your even simpler one command to sync rootfs.
I found "sudo tar -cpf" did not compression rootfs (2GB), I should use "sudo tar -cjpf" to generate compressed rootfs (700 MB).
Related
Hi guys,
Not sure if this has been found yet, but in the dmesg logs you can see how the RAM on the Galaxy S is reserved.
This is from the JPK ROM:
[ 0.000000] S5PV210: PLL settings, A=800000000, M=667000000, E=96000000
[ 0.000000] s5pv210: 37748736 bytes system memory reserved for mfc at 0x30ec2000
[ 0.000000] s5pv210: 37748736 bytes system memory reserved for mfc at 0x40204000
[ 0.000000] s5pv210: 14680064 bytes system memory reserved for fimc0 at 0x42604000
[ 0.000000] s5pv210: 1048576 bytes system memory reserved for fimc1 at 0x43404000
[ 0.000000] s5pv210: 12582912 bytes system memory reserved for fimc2 at 0x43504000
[ 0.000000] s5pv210: 16777216 bytes system memory reserved for pmem at 0x332c2000
[ 0.000000] s5pv210: 10485760 bytes system memory reserved for pmem_gpu1 at 0x342c2000
[ 0.000000] s5pv210: 1536000 bytes system memory reserved for pmem_adsp at 0x34cc2000
[ 0.000000] s5pv210: 5132288 bytes system memory reserved for jpeg at 0x44104000
[ 0.000000] s5pv210: 10485760 bytes system memory reserved for texstream at 0x445e9000
[ 0.000000] s5pv210: 3145728 bytes system memory reserved for fimd at 0x44fe9000
[ 0.000000] s5pv210: 262144 bytes system memory reserved for wifi at 0x34e39000
[ 0.000000] Built 3 zonelists in Zone order, mobility grouping on. Total pages: 117856
[ 0.000000] Kernel command line: console=ttySAC2,115200 loglevel=4
[ 0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[ 0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[ 0.000000] Memory: 80MB 256MB 128MB = 464MB total
[ 0.000000] Memory: 308048KB available (9224K code, 1910K data, 2868K init, 0K highmem)
I added up all the "system memory reserved for..." lines and got 151,633,920 bytes (144.6MB) reserved.
So the kernel can definitely see about 464MB of RAM in this case, but only 308,048KB is available.
hardcore said:
Hi guys,
Not sure if this has been found yet, but in the dmesg logs you can see how the RAM on the Galaxy S is reserved.
This is from the JPK ROM:
[ 0.000000] S5PV210: PLL settings, A=800000000, M=667000000, E=96000000
[ 0.000000] s5pv210: 37748736 bytes system memory reserved for mfc at 0x30ec2000
[ 0.000000] s5pv210: 37748736 bytes system memory reserved for mfc at 0x40204000
[ 0.000000] s5pv210: 14680064 bytes system memory reserved for fimc0 at 0x42604000
[ 0.000000] s5pv210: 1048576 bytes system memory reserved for fimc1 at 0x43404000
[ 0.000000] s5pv210: 12582912 bytes system memory reserved for fimc2 at 0x43504000
[ 0.000000] s5pv210: 16777216 bytes system memory reserved for pmem at 0x332c2000
[ 0.000000] s5pv210: 10485760 bytes system memory reserved for pmem_gpu1 at 0x342c2000
[ 0.000000] s5pv210: 1536000 bytes system memory reserved for pmem_adsp at 0x34cc2000
[ 0.000000] s5pv210: 5132288 bytes system memory reserved for jpeg at 0x44104000
[ 0.000000] s5pv210: 10485760 bytes system memory reserved for texstream at 0x445e9000
[ 0.000000] s5pv210: 3145728 bytes system memory reserved for fimd at 0x44fe9000
[ 0.000000] s5pv210: 262144 bytes system memory reserved for wifi at 0x34e39000
[ 0.000000] Built 3 zonelists in Zone order, mobility grouping on. Total pages: 117856
[ 0.000000] Kernel command line: console=ttySAC2,115200 loglevel=4
[ 0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[ 0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[ 0.000000] Memory: 80MB 256MB 128MB = 464MB total
[ 0.000000] Memory: 308048KB available (9224K code, 1910K data, 2868K init, 0K highmem)
I added up all the "system memory reserved for..." lines and got 151,633,920 bytes (144.6MB) reserved.
So the kernel can definitely see about 464MB of RAM in this case, but only 308,048KB is available.
Click to expand...
Click to collapse
That's interesting. If we take the line:
Memory: 80MB 256MB 128MB = 464MB total as the total memory
So adding it all up:
((464 * 1024 (total memory)) - (9224 + 1910 + 2868 (reserved for kernel) + (144.6 * 1024 (reserved by system) ))) / 1024 = 306 MB (available for apps)
However we should be seeing 512Mb not 464 as the total, so we are missing 48 Mb somewhere.
I still don't understand how the Galaxy Tab sees 444MB for actual applications.
http://www.youtube.com/watch?v=KoOWPjIel-c look at 4:40 in this video. it clearly shows how much RAM the tab is seeing.
Maybe we should poke inside the TAB's firmware to find out what is different?
The hardware is almost 1:1 with the SGS.
hardcore said:
Hi guys,
Not sure if this has been found yet, but in the dmesg logs you can see how the RAM on the Galaxy S is reserved.
Click to expand...
Click to collapse
Yes, see this thread starting here.
mtoneman said:
That's interesting. If we take the line:
Memory: 80MB 256MB 128MB = 464MB total as the total memory
So adding it all up:
((464 * 1024 (total memory)) - (9224 + 1910 + 2868 (reserved for kernel) + (144.6 * 1024 (reserved by system) ))) / 1024 = 306 MB (available for apps)
However we should be seeing 512Mb not 464 as the total, so we are missing 48 Mb somewhere.
Click to expand...
Click to collapse
It's probably the dalvic-cache!
Because "/system/build.prop" says: "dalvik.vm.heapsize=48m"
Just an idea
any improvements if we set an higher value for dalvik heapsize?
MCOGW said:
It's probably the dalvic-cache!
Because "/system/build.prop" says: "dalvik.vm.heapsize=48m"
Just an idea
Click to expand...
Click to collapse
This is the max heapsize for a single VM...meaning
the single application can allocate max of 48Mb heap before it gets out of memory.
This has nothing to do with RAM reservation
MCOGW said:
It's probably the dalvic-cache!
Because "/system/build.prop" says: "dalvik.vm.heapsize=48m"
Just an idea
Click to expand...
Click to collapse
No its not the dalvik heapsize. Changing that value doesn't give us more usable RAM.
I'm wondering about the Tab too. I was playing with a prototype and it definitely had more accessible RAM, as one poster said - more than 400MB. Would be good to see the dmesg boot log from a Tab to see what the system reserved and total memory is.
According to this:
http://forum.xda-developers.com/showthread.php?t=792512&page=11
there are one 2GBit (256MByte) and 2 x 1GBit (128MByte each) RAM chips totalling 512MBytes on the board. What we need to find out is why the kernel is reporting "Memory: 80MB 256MB 128MB".
i.e. what happened to the 48MByte on one of the 1GBit modules.
hardcore said:
No its not the dalvik heapsize. Changing that value doesn't give us more usable RAM.
Click to expand...
Click to collapse
I don't think it's that easy to (really) modifiy this value. I think you need a JTAG to modify this because these are direct parameters for the (smdkc110) chip.
So how did you manage (and verified) this?
If you would have read this thread:
http://forum.xda-developers.com/showthread.php?t=792512
You probably have read this:
http://forum.xda-developers.com/showpost.php?p=8325266&postcount=18
Ok it is not directly a "blackhole", but it is reserved.
The SGS kernel config tells you a bit more for what it is reserved:
Code:
CONFIG_ANDROID_PMEM_MEMSIZE_PMEM=16384
CONFIG_ANDROID_PMEM_MEMSIZE_PMEM_GPU1=8192
CONFIG_ANDROID_PMEM_MEMSIZE_PMEM_ADSP=1800
...
CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC0=12288
CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC1=1024
CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC2=12288
CONFIG_VIDEO_SAMSUNG_MEMSIZE_MFC0=32768
CONFIG_VIDEO_SAMSUNG_MEMSIZE_MFC1=32768
CONFIG_VIDEO_SAMSUNG_MEMSIZE_TEXSTREAM=10240
16 (16384)
+ 8 (8192)
+ 1,75 (1800)
+ 12 (12288)
+ 1 (1024)
+ 12 (12288)
+ 32 (32768)
+ 32 (32768)
+ 10 (10240)
112 mb
And 48 mb are not in the mem map, so 112+48 = 160
512-160=352mb
but we have a total of 325 mb (jm8)
352-325=27 are still missing
Have a look at /proc/iomem for these 27mb yourself.
And by reading that:
http://forum.xda-developers.com/showpost.php?p=8350492&postcount=126
jpk is only missing 32 mb = gpu.
So everything is fine on the ram amount, nothing to worry about.
Ok I just read up on the other threads (sorry missed those initially). If I understood correctly, the radio is separate and not visible to the linux kernel (unlike the other "reserved" blocks). This probably amounts to the 48MBytes we are not seeing in the Linux dmesg output.
Total guess: the difference in free ram between SGS and the Tab is probably that video ram for the SGS comes out of the system ram, while the Tab probably has a dedicated framebuffer+ram for it's graphics, probably because it's required for the bigger screen.
Why does Froyo have less available ram than Eclair though (hardware is the same)? In fact, why do different Eclair versions have different available ram? Is this just tweaking, and if so, can we not tweak it ourselves?
RyanZA said:
Why does Froyo have less available ram than Eclair though (hardware is the same)? In fact, why do different Eclair versions have different available ram? Is this just tweaking, and if so, can we not tweak it ourselves?
Click to expand...
Click to collapse
Cause it is a different OS? With more or newer components taking various amounts of memory?
This is like saying "why does Windows 7 leave you with less available memory than Windows XP". Ummm because it is not XP.
brunes said:
Cause it is a different OS? With more or newer components taking various amounts of memory?
This is like saying "why does Windows 7 leave you with less available memory than Windows XP". Ummm because it is not XP.
Click to expand...
Click to collapse
Mmm, and why on Nexus one there is the same RAM available in Eclair and Froyo?
And Windows 7 shows exactly the same amount of total RAM available as Windows XP.
burnes,
You are wrong.
brunes said:
Cause it is a different OS? With more or newer components taking various amounts of memory?
This is like saying "why does Windows 7 leave you with less available memory than Windows XP". Ummm because it is not XP.
Click to expand...
Click to collapse
The 'OS' is Linux! It's always important to remember this. Android is just an ecosystem (a number of apps and services) running on top of stock linux. Just because Android has gone up a version, doesn't mean the underlying system has changed! Any changes to Android components are actually all far outside the kernel, and will use up the same ram as other userland apps.
The reserved memory has nothing to do with Android, and has everything to do with the hardware drivers. Since the hardware hasn't changed, the question is why the graphics and low level drivers have been allocated more ram in Froyo than in Eclair.
Possible explanations are that Samsung gave more ram to graphics to help with... something? Maybe OpenGL ES 2 needs more ram, and performs worse than OpenGL ES 1, and so the OpenGL ES 2 driver needs to eat up more ram now? Or the Froyo drivers might just be badly optimized. In any case, it seems like we can tweak this stuff, because Samsung can tweak it.
The question is, how do we tweak it? In the kernel video drivers? Are there open specs available that we could use to work it out? And more questions I can't think of...
Well actually comparing dmesg and iomem outputs from JM8 and JPK would answer a lot of questions.
Speculating is leading us nowhere.
xan said:
Well actually comparing dmesg and iomem outputs from JM8 and JPK would answer a lot of questions.
Speculating is leading us nowhere.
Click to expand...
Click to collapse
I think a very deep look at this http://opensource.samsung.com/ (and a search for "GT-I9000") would answer lots of questions (only for Eclair atm)...
MCOGW said:
I think a very deep look at this http://opensource.samsung.com/ (and a search for "GT-I9000") would answer lots of questions (only for Eclair atm)...
Click to expand...
Click to collapse
<sarcasm>Wow thanks for the link, I'm sure none of the devs on here have bothered to check!</sarcasm>
hi guys .. I've found a way to tune the Linux IO scheduler for flash drives. which is both ROM and SD in our phones case..
Linux have 4 I/O schedulers:
- No-op Scheduler
- Anticipatory IO Scheduler (AS)
- Deadline Scheduler
- Complete Fair Queueing Scheduler (CFQ)
the default is "CFQ", which brings great performance for "Magnetic Disks drives". but not for Flash drives.
in the ".config" file of Android kernel source I noticed that "Deadline" is set as default. but it's not the fastest for Flash drives.
here are some benchmarks I found which is done on a 1 GB flash drive connected on Debian:
Code:
[email protected]:/media/vfat# cat /sys/block/sdb/queue/scheduler
noop anticipatory deadline [cfq]
[email protected]:/media/vfat# postmark
PostMark v1.51 : 8/14/01
pm>set size 500 500000
pm>set subdirectories 1000
pm>run
Creating subdirectories...Done
Creating files...Done
Performing transactions..........Done
Deleting files...Done
Deleting subdirectories...Done
Time:
351 seconds total
160 seconds of transactions (3 per second)
Files:
757 created (2 per second)
Creation alone: 500 files (55 per second)
Mixed with transactions: 257 files (1 per second)
257 read (1 per second)
243 appended (1 per second)
757 deleted (2 per second)
Deletion alone: 514 files (2 per second)
Mixed with transactions: 243 files (1 per second)
Data:
69.80 megabytes read (203.62 kilobytes per second)
208.94 megabytes written (609.56 kilobytes per second)
pm>exit
[email protected]:/media/vfat# echo noop > /sys/block/sdb/queue/scheduler
[email protected]:/media/vfat# cat /sys/block/sdb/queue/scheduler
[noop] anticipatory deadline cfq
[email protected]:/media/vfat# postmark
PostMark v1.51 : 8/14/01
pm>set size 500 500000
pm>set subdirectories 1000
pm>run
Creating subdirectories...Done
Creating files...Done
Performing transactions..........Done
Deleting files...Done
Deleting subdirectories...Done
Time:
147 seconds total
1 seconds of transactions (500 per second)
Files:
757 created (5 per second)
Creation alone: 500 files (3 per second)
Mixed with transactions: 257 files (257 per second)
257 read (257 per second)
243 appended (243 per second)
757 deleted (5 per second)
Deletion alone: 514 files (514 per second)
Mixed with transactions: 243 files (243 per second)
Data:
69.80 megabytes read (486.20 kilobytes per second)
208.94 megabytes written (1.42 megabytes per second)
pm>exit
[email protected]:/media/vfat# echo deadline > /sys/block/sdb/queue/scheduler
[email protected]:/media/vfat# cat /sys/block/sdb/queue/scheduler
noop anticipatory [deadline] cfq
[email protected]:/media/vfat# postmark
PostMark v1.51 : 8/14/01
pm>set size 500 500000
pm>set subdirectories 1000
pm>run
Creating subdirectories...Done
Creating files...Done
Performing transactions..........Done
Deleting files...Done
Deleting subdirectories...Done
Time:
279 seconds total
250 seconds of transactions (2 per second)
Files:
757 created (2 per second)
Creation alone: 500 files (17 per second)
Mixed with transactions: 257 files (1 per second)
257 read (1 per second)
243 appended (0 per second)
757 deleted (2 per second)
Deletion alone: 514 files (514 per second)
Mixed with transactions: 243 files (0 per second)
Data:
69.80 megabytes read (256.17 kilobytes per second)
208.94 megabytes written (766.86 kilobytes per second)
pm>exit
[email protected]:/media/vfat# echo anticipatory
> /sys/block/sdb/queue/scheduler
[email protected]:/media/vfat# cat /sys/block/sdb/queue/scheduler
noop [anticipatory] deadline cfq
[email protected]:/media/vfat# postmark
PostMark v1.51 : 8/14/01
pm>set size 500 500000
pm>set subdirectories 1000
pm>run
Creating subdirectories...Done
Creating files...Done
Performing transactions..........Done
Deleting files...Done
Deleting subdirectories...Done
Time:
266 seconds total
131 seconds of transactions (3 per second)
Files:
757 created (2 per second)
Creation alone: 500 files (166 per second)
Mixed with transactions: 257 files (1 per second)
257 read (1 per second)
243 appended (1 per second)
757 deleted (2 per second)
Deletion alone: 514 files (3 per second)
Mixed with transactions: 243 files (1 per second)
Data:
69.80 megabytes read (268.69 kilobytes per second)
208.94 megabytes written (804.34 kilobytes per second)
pm>exit
Src: http://www.debianhelp.org/node/9148
summary: (less is better)
1) NOOP 147 sec
2) Anticipatory 266 sec
3) Deadline 279 sec
4) CFQ 351 sec
I've made and attached a shell script to set NOOP as default. to install unzip file to your home folder and do this in a terminal:
Code:
adb push 11iosched /system/etc/init.d
adb shell chmod 655 /system/etc/init.d/11iosched
adb shell sh /system/etc/init.d/11iosched
and if you have a kernel source, and want the kernel to use NOOP as default always, open .config file and change to this settings:
Code:
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
# CONFIG_IOSCHED_CFQ is not set
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE=y
# CONFIG_DEFAULT_CFQ is not set
CONFIG_DEFAULT_NOOP=y
CONFIG_DEFAULT_IOSCHED="noop"
CONFIG_FREEZER=y
i'm using my ROM Fallah 1.4 on my phone and for the first time Softweg filesystem benchmarks reached 37. before I hardly get 31.
to check if it's working, do this:
Code:
adb shell
cat /sys/block/*/queue/scheduler
you should see something like this
[noop] anticipatory deadline
[noop] anticipatory deadline
[noop] anticipatory deadline
[noop] anticipatory deadline
[noop] anticipatory deadline
[noop] anticipatory deadline
[noop] anticipatory deadline
Click to expand...
Click to collapse
the [] brackets shows the selected scheduler..
enjoy
What is it acutally? can you describe in brief?
Cool going to try it right away. Thanks
When I run the "cat /sys/block/*/queue/scheduler" command without changing anything I get:
Code:
noop [deadline] bfq
noop [deadline] bfq
noop [deadline] bfq
noop [deadline] bfq
noop [deadline] bfq
noop [deadline] bfq
noop [deadline] bfq
Is this actually going to make any noticeable difference?
Backing up and trying anyway
vijaysapkota said:
What is it acutally? can you describe in brief?
Click to expand...
Click to collapse
The NOOP scheduler inserts all incoming I/O requests into a simple, unordered FIFO queue and implements request merging. without calculating rotate and seek latencies (as in magnetic disks).
this will boost the IO tasks in Flash drives since there is no rotate or seek.
MaXo64 said:
The NOOP scheduler inserts all incoming I/O requests into a simple, unordered FIFO queue and implements request merging. without calculating rotate and seek latencies (as in magnetic disks).
this will boost the IO tasks in Flash drives since there is no rotate or seek.
Click to expand...
Click to collapse
How do I get this to stick on boot? I tried it and got it to work but when I reboot it goes back to normal :/
Is it possible to run this script from Terminal Emulator on the phone?
If yes: What do I have to type in?
Interesting. Could you please test out BFQ as well?
http://retis.sssup.it/~fabio/linux/bfq/
It is the default at CM kernels (also my .35 port). However I'm not sure whether I should be that fond of it. NOOP really looks promising due is simplicity aye
On my opinion the default IO scheduler for any phone should be deadline. It really doesn't matter how much your device scores on benchmarks, when you hold it in your hand, you want it to respond as fast as possible to your current actions.
IakobosJ said:
How do I get this to stick on boot? I tried it and got it to work but when I reboot it goes back to normal :/
Click to expand...
Click to collapse
if you pushed it to init.d as I described it'll be executed on boot.
MaXo64 said:
if you pushed it to init.d as I described it'll be executed on boot.
Click to expand...
Click to collapse
I did push it to init.d but when I reboot it sets it back to normal :/ It also reset my CPU overclock setting back to stock and changed the governor back to ondemand :/
GZFan said:
Is it possible to run this script from Terminal Emulator on the phone?
If yes: What do I have to type in?
Click to expand...
Click to collapse
after pushing it to your phone, you can do this in Terminal Emulator:
Code:
sh /system/etc/init.d/11iosched
Elemag said:
On my opinion the default IO scheduler for any phone should be deadline. It really doesn't matter how much your device scores on benchmarks, when you hold it in your hand, you want it to respond as fast as possible to your current actions.
Click to expand...
Click to collapse
been testing a while, my phone became more responsive with NOOP. and less lag when updating too many apps from the market in the same time.
IakobosJ said:
When I run the "cat /sys/block/*/queue/scheduler" command without changing anything I get:
Code:
noop [deadline] bfq
noop [deadline] bfq
noop [deadline] bfq
noop [deadline] bfq
noop [deadline] bfq
noop [deadline] bfq
noop [deadline] bfq
Is this actually going to make any noticeable difference?
Backing up and trying anyway
Click to expand...
Click to collapse
i got the same command also, is this mean im success applying the NOOP?
dikabuzz9447 said:
i got the same command also, is this mean im success applying the NOOP?
Click to expand...
Click to collapse
I think you are. Will test this when at work. Looks nice.
Sent from my Hero using Tapatalk
dikabuzz9447 said:
i got the same command also, is this mean im success applying the NOOP?
Click to expand...
Click to collapse
You need to apply this and then run that command again, as long as noop is enclosed with the brackets [] then it means you are using NOOP.
The scheduler with the [] is the one that is running.
IakobosJ said:
You need to apply this and then run that command again, as long as noop is enclosed with the brackets [] then it means you are using NOOP.
The scheduler with the [] is the one that is running.
Click to expand...
Click to collapse
thanx, i've check again and i got this
Code:
[noop] deadline bfq
[noop] deadline bfq
[noop] deadline bfq
[noop] deadline bfq
[noop] deadline bfq
[noop] deadline bfq
[noop] deadline bfq
this mean i was success didnt i.
GZFan said:
Is it possible to run this script from Terminal Emulator on the phone?
If yes: What do I have to type in?
Click to expand...
Click to collapse
I did this by using Root Explorer to move the script file to /system/etc/init.d/ and then used the Terminal Emulator to:
Code:
su
chmod 655 /system/etc/init.d/11iosched
sh /system/etc/init.d/11iosched
dikabuzz9447 said:
thanx, i've check again and i got this
Code:
[noop] deadline bfq
[noop] deadline bfq
[noop] deadline bfq
[noop] deadline bfq
[noop] deadline bfq
[noop] deadline bfq
[noop] deadline bfq
this mean i was success didnt i.
Click to expand...
Click to collapse
yes. now noop is is used..
Question: How to revert to the default (in my case, deadline) scheduler? Will deleting the script and rebooting do this?
So here is the command line disk benchmark tool Bonnie++.
Now you can test all of your cfq, bfq or whatever IO scheduler with a standard unix benchmark tool.
Github: https://github.com/haraldh/android-bonnie
precompiled version (Use "Save As..."): https://raw.github.com/haraldh/android-bonnie/master/libs/armeabi/bonnie
man page: http://linux.die.net/man/8/bonnie++
Builds with ndk-build.
Bonnie++ recommends/uses disk space twice as big as your RAM is, although you can circumvent this with "-r 0 -s <size(MiB)>". So use a partition with more than 1.6 GB space.
Running the benchmark takes quite a while depending on IO speed, filesystem type and test size (~90 minutes).
Here is a run with the Samsung Galays S2, my kernel (Backslash-1.3), on the vfat filesystem with the noop IO scheduler:
Code:
# cd /sdcard
# mkdir tt
# /data/local/bin/bonnie -u 0:0 -d tt
Using uid:1000, gid:1015.
Writing a byte at a time...done
Writing intelligently...done
Rewriting...done
Reading a byte at a time...done
Reading intelligently...done
start 'em...done...done...done...done...done...
Create files in sequential order...done.
Stat files in sequential order...done.
Delete files in sequential order...done.
Create files in random order...done.
Stat files in random order...done.
Delete files in random order...done.
Version 1.96 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
localhost 2047M 14 97 7336 22 5796 23 229 97 36143 33 301.6 46
Latency 791ms 8633ms 7713ms 73542us 51512us 2342ms
Version 1.96 ------Sequential Create------ --------Random Create--------
localhost -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 11 84 22008 97 38 52 11 85 30837 97 21 74
Latency 1025ms 3926us 162ms 316ms 8814us 358ms
1.96,1.96,localhost,1,1310695590,2047M,,14,97,7336,22,5796,23,229,97,36143,33,301.6,46,16,,,,,11,84,22008,97,38,52,11,85,30837,97,21,74,791ms,8633ms,7713ms,73542us,51512us,2342ms,1025ms,3926us,162ms,316ms,8814us,358ms
# rmdir tt
If you run out of disk space, you will get an error message like this:
Code:
Can't write block.: No such file or directory
Can't write block 218481.
Have fun testing and report your scores, along with the phone, kernel, filesystem type and IO scheduler settings.
DISCLAIMER: writing a lot on flash might degrade the lifetime of the device.
Here is a run with the Samsung Galays S2, my kernel (Backslash-1.3), on the ext4 filesystem with the noop IO scheduler. I had to limit the test size to 1024MB, which might explain the better numbers.
Code:
# cd /data/local
# mkdir tt
# /data/local/bin/bonnie -u 0:0 -r 0 -s 1024 -d tt
Code:
Version 1.96 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
localhost 1G 10 96 7391 22 6056 21 193 97 37688 32 483.0 65
Latency 907ms 12169ms 9516ms 112ms 44923us 39518us
Version 1.96 ------Sequential Create------ --------Random Create--------
localhost -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 210 94 +++++ +++ 4129 69 218 95 +++++ +++ 612 71
Latency 332ms 2115us 3736us 191ms 2624us 1260ms
1.96,1.96,localhost,1,1310697921,1G,,10,96,7391,22,6056,21,193,97,37688,32,483.0,65,16,,,,,210,94,+++++,+++,4129,69,218,95,+++++,+++,612,71,907ms,12169ms,9516ms,112ms,44923us,39518us,332ms,2115us,3736us,191ms,2624us,1260ms
I have Arc with a 351 MB ram.
vm.dirty_ratio & vm.dirty_background_ratio control how often kernel writes data to "disk" and writes the stuff to system memory and the kernel handles when/how the data is actually going to be flushed to disk
vfs_cache_pressure has value for the file system cache, lower value means to drop caches less aggressively
I'm on X-Gamer ROM v1.8 with values
vm.dirty_ratio=70
vm.dirty_background_ratio=50
vm.vfs_cache_pressure=10
Click to expand...
Click to collapse
Thunderbolt's tweaks(for 512 and less MB of RAM)
vm.dirty_ratio = 30
vm.dirty_background_ratio = 15
vm.vfs_cache_pressure = 50
Click to expand...
Click to collapse
Please suggest values of what you favor or what should I have. Thanks in advance.
Hi,
Device - Cubot King Kong MIni 2, Android 10
KINGKONG_MINI2:/ $ cat /proc/cpuinfo
processor : 0
Processor : ARMv7 Processor rev 4 (v7l)
model name : ARMv7 Processor rev 4 (v7l)
BogoMIPS : 18.17
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
Click to expand...
Click to collapse
Couple queries that I can't find answers for.
1. The device contains 4 x 64 bit A53 cores, what makes it require a a64 rom (32 bit with 64 bit bindings) over an arm64 rom, is it that some other aspect has been compiled as 32 bit (kernel etc)?
2. Despite using a a64 rom I can't run 64 bit executables receiving the error not executable: 64-bit ELF file Any idea why?
3. Finally, having conversed with AndyYan I'm still no further forward why I can mount system as R/W but changes disappear after reboot. This suggests that his Lineage 10 roms are being build using EXT4_FEATURE_RO_COMPAT_SHARED_BLOCKS but he's adamant that it only arrived with PHH's Android 11 variant (which his builds are based on) https://github.com/phhusson/treble_experimentations/releases/tag/v300.j
If this is true then somehow I have something else overriding it.
Regarding the CPU, ARMv7 is 32 bit, the SoC is MediaTek MT6761V/WBB which according to https://en.wikipedia.org/wiki/List_of_MediaTek_processors is ARMv8-A (64 bit).
Seems someone is not telling the truth.
snoopy29 said:
Regarding the CPU, ARMv7 is 32 bit, the SoC is MediaTek MT6761V/WBB which according to https://en.wikipedia.org/wiki/List_of_MediaTek_processors is ARMv8-A (64 bit).
Seems someone is not telling the truth.
Click to expand...
Click to collapse
Both are true.....You should blame your phone manufacturer....They've given you a 32bit software although your chipset supports 64bit
Benjamin B C H said:
Both are true.....You should blame your phone manufacturer....They've given you a 32bit software although your chipset supports 64bit
Click to expand...
Click to collapse
So does it mean I can flash a 64bit custom rom?
VStephen said:
So does it mean I can flash a 64bit custom rom?
Click to expand...
Click to collapse
No. it's still 32