| 09:59 | rabeeh | _rmk_: can you check on the new u-boot patches i'v sent? |
| 10:24 | hste | rabeeh: Does the i series have the same expansionpossibilities like the c-series? |
| 10:48 | rabeeh | hste: no decision yet |
| 10:48 | rabeeh | we are mostly worried about how to remove the heat on the microsom when there is no heat spreading / heat sink on top of it |
| 10:51 | hste | yes it should be better than on gk802. it had a terrible design on that |
| 10:51 | _rmk_ | rabeeh: I've put a small 12v fan on top of the microsom, running off about 6v, it dropped the reported temperature by about 25C |
| 10:51 | rabeeh | _rmk_: 75c is perfectly fine |
| 10:52 | rabeeh | notice that this is the die inside the chip where the temperature differences since it's a wire bond bga is huge |
| 10:52 | rabeeh | i mean; touch it; it feels a bit warm - does it? |
| 10:52 | _rmk_ | it feels hot, hot enough that you don't want to keep your finger on it |
| 10:53 | hste | I think the heat is only a problem on high gpu usage |
| 10:53 | rabeeh | hste: this is not true |
| 10:53 | rabeeh | the gpu usage is only the tool; the high temperature is mainly because DDR bandwidth |
| 10:54 | hste | ok. nice to know |
| 10:54 | rabeeh | let me explain |
| 10:54 | rabeeh | gpu, the pixel fill engine for instance can produce huge consecutive bursts into the ddr (either reads or writes) |
| 10:55 | rabeeh | those are mostly open pages hits that can get you into the 65-70% ddr bandwidth utilization |
| 10:55 | hste | because when running 4cores at 100% cpustress at 1.2Ghz I dont have a heat problem, but heavy gpu usage it gets hot. So actually its the data tranfer that is the problem |
| 10:56 | rabeeh | hste: exactly |
| 10:56 | rabeeh | now that's why i'v asked jas-hacks_ yesterday about the samsung ddr type |
| 10:57 | rabeeh | and it's a lousy c-die that eats almost two times power than the dies we use (d and b dies) |
| 10:57 | hste | and when running vpu decoding the temp drops in xbmc |
| 10:57 | rabeeh | hste: i would bet you that even if you touch the heatsink; it's warm / host; but won't burn your hands |
| 10:58 | rabeeh | i mean heatsink on gk802 |
| 10:58 | rabeeh | s/host/hot |
| 10:58 | Juggie | anyone have android running on carrier-one? |
| 10:59 | rabeeh | Juggie: i do |
| 10:59 | _rmk_ | rabeeh: I think you're wrong. firstly, imx parts reportedly have a maximum die temperature of 105C. secondly, the way the thermal driver works, it reads from the silicon the maximum "hot" temperature, takes 5C off that, uses that as the "power down" trip point. 20C below the max is the throttle point. |
| 10:59 | _rmk_ | for the imx6s, that's 95C as the maximum |
| 10:59 | rabeeh | 90c |
| 11:00 | _rmk_ | so at 75C, it would start to throttle |
| 11:00 | rabeeh | no; throttle is 90c |
| 11:00 | _rmk_ | /sys/class/thermal/thermal_zone0/trip_point_0_temp:75000 |
| 11:00 | hste | imx6q starts trotling at 80c |
| 11:00 | _rmk_ | /sys/class/thermal/thermal_zone0/trip_point_1_temp:90000 |
| 11:00 | rabeeh | at 90c it would lower frequency to 800mhz and gpu freq to 1/64 |
| 11:01 | rabeeh | oh; that's too early |
| 11:01 | _rmk_ | those figures are calculated from the data reported by the SoC. |
| 11:01 | rabeeh | 80c is too early |
| 11:01 | _rmk_ | as I've said above. |
| 11:01 | hste | I think its a 10c safety margin |
| 11:01 | Juggie | rabeeh, any binary drivers or totally from source? |
| 11:01 | Juggie | i'm guessing there are some freescale binary components for android? |
| 11:02 | _rmk_ | the maximum reported by my SoC appears to be 95C. |
| 11:02 | hste | it was som patches that made it more accurate, but earlier kernels had a unaccuracy of reading temp with 10c |
| 11:05 | rabeeh | Juggie: android not released yet |
| 11:07 | hste | gk802 has trip_point 1 at 90 and trippoint 0 at 100 |
| 11:08 | rabeeh | _rmk_: which u-boot are you using? |
| 11:08 | _rmk_ | one of jnettlet's, I forget which one now |
| 11:09 | rabeeh | want to try a newer with ddr optimization? |
| 11:09 | rabeeh | based on jnettlet's? |
| 11:09 | _rmk_ | yea |
| 11:09 | rabeeh | i can send you a ready to use u-boot.imx |
| 11:09 | rabeeh | https://github.com/rabeeh/u-boot-imx6 |
| 11:10 | rabee | 11:10 * rabeeh rebuilds an image |
| 11:11 | rabeeh | http://dl.dropboxusercontent.com/u/72661517/tbr/u-boot.imx |
| 11:11 | rabeeh | sudo dd if=u-boot.imx of=/dev/sdX bs=512 seek=2; sync |
| 11:14 | _rmk_ | ok, will try that later this morning |
| 11:14 | _rmk_ | thanks |
| 12:08 | hste | rabeeh: is that uboot for c1? |
| 12:08 | rabeeh | yes |
| 12:08 | _rmk_ | its running now |
| 12:08 | rabeeh | make clean; make mx6_c1solo_config; make -j4 |
| 12:09 | rabeeh | _rmk_: do you have current meter on the power supply too? |
| 12:11 | _rmk_ | unfortunately not; it's being powered from a USB port on another machine |
| 12:12 | hste | rabeeh: but its the 2009.08 version and not the upstream version? |
| 12:13 | rabeeh | https://github.com/rabeeh/u-boot-imx6 |
| 12:14 | rabeeh | it's a mirror from jnettlet's u-boot |
| 12:14 | rabeeh | _rmk_: heat needs some time also to build up |
| 12:15 | rabeeh | for the microsom alone; being with no heat escaping path (no heatsink and small pcb board) it might take something like 10minutes to get to max temp |
| 12:15 | _rmk_ | yep, I'm letting it run for a while |
| 12:31 | hste | does this uboot support booting from usb? |
| 12:32 | MikeSeth | rabeeh: briefly, what's the state of debian/ubuntu on arm-hfp? does it require much hacking to get working on cubox-i? |
| 12:33 | _rmk_ | mikeseth: I run ubuntu armhf on both the cubox and carrier1 |
| 12:33 | _rmk_ | 12.04.3 |
| 12:33 | hste | MikeSeth: Jas-hacks has a ubuntu 13_04 with working gpu but not vpu |
| 12:34 | _rmk_ | I've not bothered porting over the vivante stuff because the direction I'm working, I want whatever I have in my tree able to be mainlined |
| 12:34 | hste | MikeSeth: http://stende.no-ip.info/jas/xubuntu_13_04_gpu.tar.gz |
| 12:35 | MikeSeth | so much hacking to be done? |
| 12:35 | MikeSeth | i need a small project :P |
| 12:35 | _rmk_ | not sure about small |
| 12:36 | _rmk_ | everything I've done so far with imx6 has turned out to be a blackhole as far as time is concerned |
| 12:38 | _rmk_ | well, with rabeeh's uboot, it looks like its now sitting at 78C |
| 12:38 | _rmk_ | on the same workload as before |
| 12:40 | MikeSeth | _rmk_: are you unhappy with the hardware itself? |
| 12:42 | _rmk_ | mikeseth: my suspicion is either the hardware is very buggy, or the stuff which has been pushed into the kernel so far is hellishly buggy - all that I know is that I've various problems which I've spent a very long time on without getting to a resolution |
| 12:43 | _rmk_ | eg, I've more or less accepted that after a certain number of dpms cycles, it's going to need a reboot to get the IPU back to a working state |
| 12:44 | MikeSeth | uhh |
| 12:44 | MikeSeth | this very much reminds me of the tornado phenomenon i had a decade ago with fuji ATM chips |
| 12:44 | MikeSeth | but damned if I remember what the problem was.. |
| 12:45 | _rmk_ | the annoying thing is, there's very little in the way of status to read back to tell what's working and what isn't - all you have are a few registers which tell you the status of various fifos |
| 12:46 | _rmk_ | it could be that there's a workaround for something in the FSL bsp which is not documented (there's a ton of those) |
| 12:50 | _rmk_ | I've more or less proved that it's the IPU which locks up and not the HDMI interface: even with the TV reporting no video, I can still push audio through the HDMI link |
| 12:50 | _rmk_ | and the TV plays the audio |
| 12:50 | _rmk_ | so the data islands and info frames are still being correctly generated |
| 12:51 | _rmk_ | it seems to lack all the video sync and video information |
| 12:54 | _rmk_ | The spdif output seems to work, but there's issues with that, and I'm not entirely convinced that it's pulseaudio's fault yet. |
| 12:56 | rabeeh | _rmk_: is this 78c vs. 75c? |
| 12:56 | _rmk_ | rabeeh: looks that way |
| 12:56 | rabeeh | does it mean that things got worse? |
| 12:57 | _rmk_ | well, you definitely don't want to put a finger on the mx6s device (you wouldn't be able to keep it there for more than half a second) |
| 12:58 | rabeeh | _rmk_: what does devmem 0x021b001c tell? |
| 12:58 | rabeeh | is there a ddr frequency scaling in the middle? |
| 12:58 | _rmk_ | Value at address 0x21B001C (0xb6fa701c): 0x0 |
| 12:59 | _rmk_ | rabeeh: unfortunately not, which probably isn't helping |
| 13:00 | _rmk_ | the other thing I've noticed is the imx-thermal driver reads OCOTP_ANA1 and uses the lsb 8 bits as the max die temperature - but the manual says that's customer programmable |
| 13:00 | _rmk_ | for that register, mine reports: |
| 13:00 | _rmk_ | Value at address 0x21BC4E0 (0xb6fcd4e0): 0x56F4F85F |
| 13:00 | _rmk_ | 0x5f = 95C |
| 13:03 | _rmk_ | it also apparantly contains the sensor values for 25C and that specified temperature (0x56f and 0x4f8) which are used to derive the conversion factors |
| 13:10 | rabeeh | devmem 0x21BC4E0 |
| 13:10 | rabeeh | 0x59851F5F |
| 13:12 | rabeeh | we never touch this field |
| 13:47 | rabeeh | _rmk_: i can't explain your temperature changes; but now i just double checked |
| 13:48 | rabeeh | dd if=/dev/zero of=/dev/null bs=1M count=10000 |
| 13:48 | rabeeh | on previous u-boot (i.e one commit before) it was 480mA and now it's 420mA |
| 13:48 | rabeeh | (DDR @ 533MHz btw) |
| 13:48 | rabeeh | so it definitely burns less power |
| 13:49 | rabeeh | (using busybox dd reads ~2GB/sec) |
| 14:59 | neofob | just so you all know, the current lvm2 in debian wheezy has some mlock issue (fail to allocate memory, iirc) in Cubox (Marvell version) |
| 15:01 | neofob | compiling the latest version from lvm2 git version 2.02.103 or 2.02.104 fixes this issue |
| 15:38 | hste | Is the serial on 1gnd pin 8 tx and 10 rx? I don't get serial output. |
| 15:39 | hste | the power led is lighting red |
| 15:45 | lioka | hste: http://imx.solid-run.com/wiki/index.php?title=Carrier-One_Hardware#Serial_UART_port_access |
| 15:45 | lioka | pin 1 is 3.3v |
| 15:45 | lioka | gnd is 6 |
| 15:47 | _rmk | 15:47 * _rmk_ says ouch. it sounds like hste tried it with pin 1 connected, which could be bad news (esp. if the power in is floating wrt the connected USB) |
| 15:50 | hste | is the speed 115200 n 8 1 ? |
| 15:53 | rabeeh | hste: yes |
| 15:53 | rabeeh | hw flow control off |
| 15:54 | hste | and power led shall light red? |
| 15:55 | hste | ' |
| 15:55 | svere | same here |
| 15:56 | svere | light red, 11520 8N1 hw flow off |
| 15:56 | svere | sd-card is in with binary uboot from the link on the c1 wiki page |
| 15:56 | svere | no output |
| 15:58 | hste | How much power does it need without usb connected? |
| 16:03 | rabeeh | max 700ma |
| 16:04 | rabeeh | with gigabit ethernet wired |
| 16:04 | rabeeh | but getting it to boot requires 200-300ma |
| 16:07 | svere | rabeeh: if it starts booting should the OK led turn on? |
| 16:08 | rabeeh | yes |
| 16:08 | svere | so minimal setting: no sd-card, nothing connected I should see red light + OK? |
| 16:14 | rabeeh | no |
| 16:14 | rabeeh | minimal system without sd-card (meaning nothing to boot from) only red light (which is the 3.3v rail) |
| 16:14 | rabeeh | the ok led is a gpio from the imx6 |
| 16:15 | svere | rabeeh: ok, so it still could be that i messed up uoot |
| 16:15 | rabeeh | this gpio is actually the usb enable bit |
| 16:15 | svere | s/uoot/uboot |
| 16:15 | rabeeh | you have messed with u-boot; or your sd-card wasn't flashed correctly |
| 16:16 | svere | is there a known good uboot i can try? |
| 16:16 | rabeeh | * rabeeh rebuilds an image |
| 16:16 | rabeeh | http://dl.dropboxusercontent.com/u/72661517/tbr/u-boot.imx |
| 16:16 | rabeeh | sudo dd if=u-boot.imx of=/dev/sdX bs=512 seek=2; sync |
| 16:17 | svere | a shit i think i know what went wrong |
| 16:17 | svere | if i create a partition at block 2048 will this work? |
| 16:22 | rabeeh | yes |
| 16:22 | rabeeh | u-boot at least |
| 16:22 | svere | rabeeh: sorry i have to run. will be back in 3-4h |
| 16:22 | rabeeh | run svere; run :) |
| 16:22 | svere | lol |
| 16:24 | hste | trying flashong uboot to sdcard again. still no luck |
| 16:26 | hste | I need to get me a usb-sdcard reader flashing with my gk802 might be the problem |
| 16:27 | jnettlet | you guys have all been having so much fun without me |
| 16:27 | rabeeh | jnettlet: welcome back |
| 16:28 | rabee | 16:28 * rabeeh offers cold ice beer to jnettlet |
| 16:28 | jnettlet | rabeeh, thanks. The wife's todo list was long and exhausting. |
| 16:28 | jnettle | 16:28 * jnettlet has a nice ice cold beer, thanks :-) |
| 16:28 | jnettlet | The Danish Christmas brews are hitting the store shelves |
| 16:59 | MikeSeth | rabeeh: mind a quick /msg? |
| 16:59 | rabeeh | sure |
| 17:06 | neofob | does cubox-pro have different ethernet setting than the original cubox? i boots the cubox-pro with a working sd card on original cubox but it fails to bring up eth0 |
| 17:09 | rabeeh | neofob: maybe the mac address has changed and your distro changes eth0 to eth1 (which then fails dhcp etc...) |
| 17:11 | neofob | rabeeh: hah, how do i reset that? |
| 17:13 | rabeeh | there is some udev rules under /etc that you need to wipe |
| 17:13 | rabeeh | look for eth0 under /etc/udev and you should see it |
| 17:13 | neofob | rabeeh: thanks, i found it |
| 17:13 | rabeeh | neofob: that's btw the most common mistake for image builders |
| 17:14 | rabeeh | the create a rootfs image with their MAC address on it and when anyone else tries it they fail |
| 17:14 | neofob | yes, i'm one of them; i ran into this before with virtual machine when i clone it also |
| 17:17 | jnettlet | that is why udev doesn't carry the persistent net rules by default any longer, however I hate the "hardware" device naming. |
| 17:18 | jnettlet | ah these new SPL patches are all mis-formatted :-\ |
| 17:18 | neofob | now it works like charm, i have 1G of tmpfs with cubox-pro |
| 17:22 | rabeeh | jnettlet: i briefly looked at them; i expected spl code to have some assembly; but those patches don't |
| 17:24 | jnettlet | rabeeh, this patchset doesn't handle the SPL part yet. It is just handling the C parts |
| 17:27 | jnettlet | rabeeh, Eric responds about it here. http://marc.info/?l=u-boot&m=138395032206159&w=2 |
| 17:38 | _rmk_ | well, that worked as intended.... I think I've fully solved the DRM problem wrt imx-drm sub-component stuff |
| 20:47 | hste | rabeeh: I got it to boot :) Found a way to dd the uboot that worked |
| 20:49 | rabeeh | hste: congrats |
| 20:52 | svere | :-( |
| 20:52 | svere | rabeeh: no luck with your uboot |
| 20:53 | svere | OK is not turning on |
| 20:56 | svere | hste: did you have any success booting your C1? |
| 20:56 | hste | svere: I got it working. |
| 20:56 | hste | svere: I had to find another device to dd it with |
| 20:56 | svere | ahhh so its and endianess issue? |
| 20:57 | svere | hste: so you flashed with another arm device and it worked? |
| 21:00 | hste | I found another pc with sdcardreader and flashed it there |
| 21:00 | rabeeh | svere: endianess? |
| 21:02 | svere | rabeeh: forget it... i guess i could need some sleep :-) |
| 21:04 | rabeeh | svere: i though that you were flashing the micro sd on a power-pc :) |
| 21:04 | rabeeh | but regardless, endianess shouldn't manner since you are writing 512byte blocks |
| 21:06 | svere | yeah i realized that |
| 21:09 | svere | tested another reader.... no luck |
| 21:09 | svere | hste: what was the difference between the working and non-working pc? |
| 21:10 | hste | I had an gk802 that I used to flash. Donno why it didn't work, but on the pc it worked |
| 21:15 | hste | rabeeh: running stress on 1 cpu the temp is 53 |
| 21:16 | rabeeh | hste: which benchmark? |
| 21:16 | rabeeh | give it 10 minutes to saturate |
| 21:16 | rabeeh | 53c is nothing |
| 21:16 | hste | the stress program |
| 21:17 | hste | stress -c1 |
| 21:17 | rabeeh | so it's probably not going to the memory? |
| 21:17 | rabeeh | because 53 is very low |
| 21:17 | hste | i guess its only stessing cpu |
| 21:18 | rabeeh | -c, --cpu N |
| 21:18 | rabeeh | spawn N workers spinning on sqrt() |
| 21:18 | rabeeh | sounds like L1 cache benchmark |
| 21:26 | hste | rabeeh: when only x is running with screensaver its down to 51 |
| 21:27 | rabeeh | 1080p |
| 21:27 | rabeeh | ? |
| 21:27 | hste | I don't have hdmi attached but its 720P |
| 21:27 | rabeeh | ok. |
| 21:27 | rabeeh | 16bpp? |
| 21:28 | hste | yes 16 |
| 21:29 | svere | success |
| 21:29 | svere | two errors |
| 21:30 | svere | rabeeh: the commandline for dd is wrong on the wiki page |
| 21:30 | svere | sudo dd if=u-boot.bin of=/dev/sdX bs=512 seek=2 skip=2 conv=fsync |
| 21:30 | svere | but you have to skip the 'skip=2' part |
| 21:30 | rabeeh | hste: it's 125MB/sec refresh |
| 21:31 | rabeeh | it's also peanuts for the ddr :) |
| 21:31 | rabeeh | sorry; but you have to try harder to kick it |
| 21:31 | rabeeh | hste: i'v added gpumem support to the kernel command line |
| 21:31 | rabeeh | this free additional memory the the user space |
| 21:31 | rabeeh | on c1 i can get 440MByte |
| 21:32 | rabeeh | which is btw a life saver for xbmc on c1 (blu ray 40Mbps h.264 advanced main profile content) |
| 21:32 | hste | so how low on 1080p can you set gpumem? |
| 21:32 | rabeeh | for xbmc gpumem=64M was enough |
| 21:32 | rabeeh | i haven't tried lower than this |
| 21:33 | hste | I guess the speed of ram is a limit too |
| 21:33 | rabee | 21:33 * rabeeh tries 32M |
| 21:34 | rabee | 21:34 * rabeeh is running stable on 533MHz |
| 21:34 | rabeeh | with 533MHz lots of the xbmc issues vanishes |
| 21:34 | rabeeh | it renders 135fps on xbmc main gui (30fps without dirty regions) |
| 21:34 | rabeeh | that's rendering native to 1080p ! |
| 21:34 | rabeeh | yes. on c1 :) |
| 21:34 | hste | nice. Does the sample c1's also manage 533? |
| 21:35 | rabeeh | and i can play blu ray 40Mbps h.264 advanced main profile streaming from the network with 5.1 transcoded to 2 channel stereo |
| 21:35 | rabeeh | yes |
| 21:35 | rabeeh | i'm running the same hardware you guys are running |
| 21:35 | ssvb | hste: if you want to heat cortex-a9 a bit more, you may try https://raw.github.com/ssvb/cpuburn-arm/master/cpuburn-a9.S |
| 21:35 | rabeeh | gpumem=32M is too low for xbmc |
| 21:36 | hste | 48M maybe? |
| 21:36 | rabee | 21:36 * rabeeh trying |
| 21:36 | rabeeh | same with 48M; it says - |
| 21:36 | rabeeh | Warning: No contiguous memory is reserverd for gpu.! |
| 21:38 | hste | ok. 64M should be the size then |
| 21:38 | rabeeh | for now |
| 21:38 | hste | do you use stephans xbmc build? |
| 21:38 | rabeeh | i think it's a driver bug |
| 21:39 | rabeeh | hste: i use geexbox that incorporates stephan's patches |
| 21:44 | rabeeh | hste: my mistake; works with gpumem=32M |
| 21:45 | hste | nice. with bpp 16 ? |
| 21:45 | rabeeh | bpp=32 |
| 21:45 | hste | thats nice |
| 21:45 | rabeeh | console=ttymxc0,115200 gpumem=32M root=/dev/mmcblk0p1 rootwait consoleblank=0 video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24,bpp=32 dmfc=3 |
| 21:45 | rabeeh | bpp 16 is crap |
| 21:45 | rabeeh | you need the alpha blending part to get some serious graphics |
| 21:45 | rabeeh | anyhow; i can declare that xbmc on c1 is also a winner |
| 21:45 | rabeeh | well.. not yet |
| 21:46 | rabeeh | i just need to validate that 533MHz is a winner too :) |
| 21:46 | rabeeh | i mean it runs all the time |
| 21:46 | rabeeh | we have tested on 3 systems; but i probably need more people to test |
| 21:46 | hste | I run the cpustress now. 63 at moment |
| 21:47 | hste | Some special test u want me to try? |
| 21:52 | hste | rabeeh: how much more juice do u think u can get out of the production model? |
| 21:52 | rabeeh | hste: the production will be 400mhz; those are only overclockers option |
| 21:53 | rabeeh | i got it yesterday to ~650MHz ddr clock rate |
| 21:53 | rabeeh | i wonder also if the processor can be overclocked to 1.2ghz |
| 21:55 | hste | you could try hardcode it in arch/arm/mach-mx6/cpu_op-mx6.c I did that on my gk802 |
| 21:56 | hste | line 363 |
| 21:58 | hste | arm_max_freq = CPU_AT_1_2GHz instead of arm_max_freq = CPU_AT_1GHz |
| 22:00 | hste | rabeeh: temp is still as low as 65 running cpustress |
| 22:00 | rabeeh | hste: that's good |
| 22:01 | rabeeh | if you enable gpu and vpu all together you might start seeing the late 70s |
| 22:01 | rabeeh | early 80s |
| 22:01 | rabeeh | :) |
| 22:01 | hste | the vivante is loaded running X |
| 22:01 | rabeeh | hste: want to overclock a bit too? |
| 22:02 | hste | yes no problem. |
| 22:04 | rabeeh | http://pastebin.com/gvQv4k58 |
| 22:04 | rabeeh | a big hack ofcourse; but should get you going |
| 22:05 | hste | the kernel is the same as in the wiki? |
| 22:05 | rabeeh | oh |
| 22:05 | rabeeh | nop |
| 22:05 | rabeeh | want one? |
| 22:05 | rabeeh | or want to build one? |
| 22:06 | hste | I can build or if u have a uImage that ok too |
| 22:06 | rabeeh | http://dl.dropboxusercontent.com/u/72661517/tbr/uImage |
| 22:06 | rabeeh | # md5sum uImage |
| 22:06 | rabeeh | 4b45bff1cb039da7d58575855ff03c6f uImage |
| 22:07 | rabeeh | you should see 528000000 in your kernel message |
| 22:07 | rabeeh | but which u-boot are you using? |
| 22:08 | hste | the one you pointed to here for svere |
| 22:08 | rabeeh | ok |
| 22:08 | rabeeh | https://github.com/rabeeh/u-boot-imx6 |
| 22:08 | rabeeh | make clean; make mx6_c1solo_config; make -j4 |
| 22:08 | rabeeh | in case you want to rebuild |
| 22:19 | rabeeh | i have been playing 1080p 40Mbps for 15m with overclocked ddr, gpu and video all running |
| 22:19 | rabeeh | reached 77c |
| 22:19 | rabeeh | :) |
| 22:20 | rabeeh | i wonder what _rmk_ has been running that he reaches 78c so easy |
| 22:21 | hste | rabeeh: ok. sound like oc friendly |
| 22:25 | hste | rabeeh: New DDR rate is 528000000 |
| 22:31 | hste | rabeeh: maybe u r running it a ac cooled room and he in a sauna :) |
| 22:32 | hste | rabeeh: cpustress so far 68 |
| 22:42 | rabeeh | hste: my ac is powered of |
| 22:43 | rabeeh | ambient is 26c |
| 22:51 | ssvb | hste: it just looks like your cpustress is doing a really poor job :) |
| 22:52 | hste | ssvb: I think I need to stress some gpu stuff also... :) |
| 22:53 | ssvb | multithreaded video encoding/decoding with neon is likely to produce more heat |
| 22:55 | ssvb | long parallel builds with gcc are less intensive, but used to cause problems for odroid-x (exynos4) too until they got thermal throttling right |
| 23:03 | ssvb | based on your description (just spinning in sqrt()), it looks like cpustress might be weaker than average normal applications in terms of producing heat |
| 23:07 | ssvb | btw, vsqrt.f64 is useful as part of cpuburn loop for Cortex-A7, but it's a slow long latency instruction |
| 23:07 | ssvb | so it is possible to also perform a bunch of floating point multiplications, integer multiplications, conditional branches and neon stores while the square root calculation is still running in the background |
| 23:08 | ssvb | this provides good results for Cortex-A7 - https://raw.github.com/ssvb/cpuburn-arm/master/cpuburn-a7.S (but is not optimal for Cortex-A9) |
| 23:09 | hste | ssvb: I use this one https://raw.github.com/ssvb/cpuburn-arm/master/cpuburn-a9.S |
| 23:12 | ssvb | hste: are you observing a higher temperature with it? |
| 23:13 | hste | no. 68/69 |
| 23:14 | ssvb | ok |