IRC log of #cubox of Wed 23 Jul 2014. All times are in CEST < Back to index

23:59 richardjortega cool, i added a ticket issue to RVM to check for ntp on startup, otherwise the configure process hangs
00:00 tekk i didn't come across that... mmm
00:00 tekk isn't ntp in base-files ?
00:04 richardjortega i'm not totally sure on that
00:04 richardjortega i was working previously on Gunnar Wolf's debian distro
00:04 richardjortega which is pretty bare
00:05 richardjortega i didn't realize it until i ran it and then realized that system didn't have time
00:06 kgp_ Question....
00:06 richardjortega he's the issue more specifically: https://github.com/wayneeseguin/rvm/issues/2966
00:07 kgp_ if every minute I transfer a file on the sdcard (image from a camera), transform this image, push this image on a remote server.
00:07 kgp_ delete the image.
00:07 kgp_ how long before the sd card dies.
00:07 richardjortega lol
00:08 richardjortega sorry i read that a little wrong, but rereading it, it sounds fine
00:10 richardjortega i'm using it as server, reading/writing data every second, and logrotating/archiving the data weekly
00:10 kgp_ and no dead sd card yet?
00:11 richardjortega it's only been on that for two days
00:11 richardjortega i except it not to die... otherwise this whole direction of making microcomputers would be for not
00:12 kgp_ The life of SD Cards is limited but it could be a year or more on a Pi setup
00:12 kgp_ On a forum
00:13 kgp_ Most new flash memory is no less than 100,000 writes. Most of it is 1 million writes now.
00:13 kgp_ Thats is actually untrue. Most flash cards today are in the range of 10k-1k rewrites (depends on the type of nand used)
00:14 richardjortega mmm... I write each second and data is requested of me likewise
00:14 richardjortega balls....
00:14 kgp_ write is different than read on flash memory.
00:15 kgp_ I'll have 1'440 writes per day.... so I'll kill my card in 1-4 weeks....
00:15 tekk kgp_ i thought sd cards etc these days lasted around 3 years
00:16 kgp_ if I don't do something clever like moving data around (like what you have on a ssd disk.)
00:16 kgp_ yes... if you don't use them a lot tekk....
00:16 richardjortega kgp_: looked at probably same RPi post you pulled up, but an interesting topic is remaining space on SD disk as data can move there depending on algos and ish
00:17 kgp_ yes ;)
00:17 tekk so in reality, you recon our micro-sd's inside our cubox's will last a year?
00:17 kgp_ if the algo is implemented...
00:17 tekk i'm not pushing GB/day through it
00:17 tekk and most hte data i push thorugh it never touches the disk
00:17 kgp_ "Wear leveling" is what is used in SSD and usb flash drive.
00:18 kgp_ but not on SD-card.
00:18 richardjortega well i'll be pushing second writes like it was a server for a work project, will report back to community in a month or something...
00:18 richardjortega then one day, a building will shut down and explode because it can't write
00:18 richardjortega lol
00:18 deniska kgp_: I believe it's used on some sd cards
00:18 deniska If not, you may use jffs2 or similar fs
00:19 deniska Which moves stuff around if a controller can't do that
00:19 kgp_ or use a tmpfs
00:20 tekk i flahsed that latest jessi btw
00:20 kgp_ and?
00:20 tekk its still runing kernel 3.0.35 and doesn't seem to have SPL u-boot
00:20 kgp_ No success with my gnome install...
00:21 tekk unless i'm mistaken
00:21 tekk stil getting this: http://pasti.ng/p/YmzqNkrd
00:21 tekk from cbxbiker61 's scripts
00:22 kgp_ SanDisk SD cards have an endurance specification for each sector of 100,000 writes typical (reading a logical sector is unlimited).
00:23 tekk if an sd card dies it goes read only right?
00:23 tekk not the end of the world....
00:24 tekk just clone it to a new one and start again :D
00:24 kgp_ expect if you run sometine in a customer... like a camera...
00:25 kgp_ It's a service I want to build... and if I have to go around every 1-2 months... it's not really scalable.
00:26 kgp_ Most decent SD cards use wear levelling algorithms to minimise the number of times each block is written, so if the SD card is bigger than you need the wear can be spread over a much larger area of free space.
00:28 kgp_ That's actually a problem for some embedded projects. There's absolutely no way (apparently) to know what sectors might be wear leveled at any time, so a power cycle at the wrong time can destroy data anywhere on the card, no matter where you THINK you're writing. (don't ask how I know :) )
00:30 kgp_ Wear Leveling
00:30 kgp_ Wear leveling is an intrinsic part of the erase pooling functionality of cards in the SanDisk SD
00:30 kgp_ Card Product Family using NAND memory
00:30 kgp_ http://media.digikey.com/pdf/Data%20Sheets/M-Systems%20Inc%20PDFs/SD%20Card%20Prod%20Family%20OEM%20Manual.pdf
00:30 kgp_ good
00:35 cbxbiker61 tekk, i should probably change the script to fail with error instead of defaulting to dove-cubox
00:36 cbxbiker61 but if it's not SPL u-boot, it will will mis-identify
00:43 tekk that was http://download.solid-run.com/pub/solidrun/cubox-i/Debian/Jessi-repackaged-trial/debian-jessi-4-july-2014.img.xz btw
00:43 tekk which is supposed to be SPL u-boot
00:44 tekk /boot contains uEnv.txt uImage
00:45 cbxbiker61 spl u-boot installs will always have some .dtb files in /boot
00:46 tekk ok, in that case its not an spl u-boot install
00:46 tekk do you have an older kernel build and script that will work for non u-boot ?
00:49 cbxbiker61 no, i only did .dtb based kernels, although I could use config_arm_appended_dbt, i do this for original cubox and sheevaplugs
00:49 cbxbiker61 then you'd have to append the appropriate dtb to the end of the kernel
00:50 tekk tekk>
00:50 tekk does it use SPL u-boot now though? as last image didn't iirc
00:50 tekk [10:14pm]
00:50 tekk tekk: yes
00:50 tekk [10:14pm]
00:50 tekk sorry for that
00:50 tekk [10:14pm]
00:50 tekk great :)
00:50 tekk [10:14pm]
00:50 tekk that'll make it easier, i can use one of cbxbiker61 images
00:50 tekk ;'( not true
00:51 rabeeh cbxbiker61: spl u-boot supports both the older kernel 3.0.35 (uImage with machine ID) and the newer kernels with .dtbs
00:52 cbxbiker61 oh, so we should be able to switch him over
00:52 cbxbiker61 tekk you should be able to change the script to fix the identity to imx-imx, and it should work then
00:53 cbxbiker61 cat /proc/cpuinfo for me, so i can fix it
00:53 tekk http://pasti.ng/p/uaACwaVc
00:53 tekk (pasti.ng is my own little project btw) :)
00:54 tekk cbxbiker61, if i force the identity to imx-imx won't it build the wrong type of kernel?
00:54 cbxbiker61 i'll post a modified script in just a sec
00:55 tekk ah thanks
00:55 tekk SET-IMX-KERNEL may/may not need changing too
00:57 kgp_ tmpfs /tmp tmpfs defaults,noatime,nosuid,nodev,noexec,mode=1777,size=64M 0 0
00:57 kgp_ tmpfs /var/log tmpfs defaults,noatime,nosuid,nodev,noexec,mode=1777,size=64M 0 0
00:57 kgp_ in /etc/fstab could help me
00:57 tekk noatime for sure
00:58 tekk not sure about the others helping a great deal
00:58 kgp_ yes I have it.
00:58 kgp_ I'm doing some stuff on an image.
00:58 kgp_ and it's ~10x faster.
00:58 tekk :o
00:59 tekk you'd have thought -noatime was default these days for distro's on flash
00:59 kgp_ yes :)
01:00 cbxbiker61 http://www.xilka.com/sheeva/tmp/UPDATE-KERNEL.sh , that should identify it as imx-imx, SET-IMX-KERNEL.sh doesn't need to be changed
01:01 tekk right :)
01:01 tekk gonna try in a sec
01:01 tekk thanks
01:04 tekk well its wget'ing
01:04 tekk 3.10.49
01:05 tekk rebooting :)
01:07 tekk hmm
01:07 tekk it rebooted (quite quickly)
01:07 tekk 3.0.35-g01c6ae1
01:07 tekk the fuuuck
01:08 kgp_ quickly means?
01:10 kgp_ I think I'm happy with my modifications ;)
01:11 kgp_ bedtime
01:14 cbxbiker61 tekk, you may have to move uImage out of the way, so it uses zImage
01:15 tekk http://pasti.ng/p/ApUaAaHc
01:15 tekk thats the contents of my /boot
01:15 tekk after the kernel "upgrade"
01:15 tekk should i rename imx-3.10.49-zImage to zImage ? or should it pick it up if i delete the uImage?
01:17 cbxbiker61 put SET-IMX-KERNEL.sh in /boot and run sudo ./SET-IMX-KERNEL.sh 3.10.49 that links or copies zImage, then move uImage out of the way
01:18 tekk i ran it outside of /boot last time
01:18 tekk this time i get this: http://pasti.ng/p/mVvpgbpe
01:19 tekk ( i am root )
01:19 tekk yet the files are created lol
01:19 tekk zImage exists
01:19 tekk gonna move uImage out the way and reboot
01:24 tekk ok its not returning after reboot :(
01:24 tekk im gonna continue tomorrow... super late hree
01:31 richardjortega is there a tutorial on configuring wifi?
01:31 richardjortega best to use /etc/network/interfaces or network-manager? i'll be setting this up to be non-desktop
01:47 richardjortega any reason why a keyboard pipe button would return a ~
03:01 mhoney wrong keyboard type?
03:01 mhoney I mean wrong localization
16:02 suihkulokki what's the right DEBUG_LL_UART_x for original dove/cubox ?
17:45 rabeeh suihkulokki: no idea
17:45 rabeeh i don't recall that it worked
17:58 richardjortega whoney: late response, yeah the recent debian release from rabeeh was UK keyboard. Yeah switching it over to US 101 helped me out thank
22:58 malte_ rabeeh