| 01:28 | Punkley_Chillin | this is me building new armhf packages for everything :( |
| 01:28 | dotarray | you're doing a good job, Punkley_Chillin :) |
| 01:28 | dotarray | i think you deserve a cup of tea and maybe a biscuit. |
| 01:29 | Punkley_Chillin | I think your the person to make that happen. |
| 03:02 | Punkley_Chillin | anyone here used marvel-ipp on hardfloat yet? |
| 08:28 | jnettlet | Punkley_Chillin, I haven't used it on the Cubox, but use it for the XO 1.75 |
| 10:30 | ralix | morning |
| 10:30 | jnettlet | morning. rainy Sunday |
| 10:31 | jnettlet | good day for hacking :-) |
| 10:32 | ralix | Here it's not raining, but I'm still waiting for my new Cubox: ( |
| 10:36 | jnettlet | ralix, still stuck in Customs? |
| 10:38 | ralix | My first is broken, and the second is somewhere in Germany. Sorry, not for me at home;-) |
| 10:39 | ralix | I hope I understood your question correctly, my english is not so good. |
| 13:21 | rmk_ | can anyone provide any insight into the hwmon driver, and where the information for reading out 'vcore' and 'vcpu' came from - the armada510 manual lists these bits as 'reserved', and reading those sysfs files provokes an overtemp alarm (reported by the temp1_crit_alarm file) |
| 13:22 | rmk_ | moreover, I'm wondering about the accuracy of those values... and if they're right, they could explain why my cubox keeps crashing under load |
| 13:22 | rmk_ | /sys/class/hwmon/hwmon0/device/vcore:938 |
| 13:22 | rmk_ | /sys/class/hwmon/hwmon0/device/vcpu:954 |
| 13:24 | rmk_ | the hardware spec says for 800MHz, vdd_cpu should be 1.05-1.15v and vdd_core should be .95-1.05v |
| 17:20 | dung | wow; greetings rmk_ |
| 17:29 | rmk_ | boo :) |
| 17:31 | rmk | 17:31 * rmk_ fixes the dove pmu/rtc interrupt code not to set other interrupts... and hooks the pmu temperature interrupts so at least I should get a warning immediately if it goes over 90C. |
| 18:51 | rmk | 18:51 * rmk_ curses the orion watchdog driver... if only it had been designed from the start so it could work across the orion range. |
| 21:14 | Kiranos | http://www.solid-run.com/phpbb/viewtopic.php?f=4&t=1000 |
| 21:14 | Kiranos | first post :) |
| 21:15 | Kiranos | thanks for great product |
| 21:15 | Kiranos | geekbox still has a few issues, seems like sound goes out of sync when I fast forward etc |
| 21:29 | markg85 | Hi all |
| 21:30 | markg85 | I have a bit of an issue here.. I kinda screwed up the cubox when trying to install the Cubox Installer. I'm guessing my u-boot is broken since the led is in dim mode. |
| 21:30 | markg85 | However, when i connect with a serial cable i don't see anything at all. |
| 21:31 | markg85 | I did find "some" possible links that "might" work, but thus far everything ended up in no results. |
| 21:34 | markg85 | Could anyone help me please? |
| 21:35 | markg85 | rabeeh: ? |
| 21:41 | markg85 | ..? |
| 23:27 | dbsx | markg85 - follow the instructions at the wiki. If it dont work be prepared to repeat a few times. |
| 23:27 | dbsx | http://www.solid-run.com/mw/index.php/Flashing_U-Boot |
| 23:27 | dbsx | http://www.solid-run.com/mw/index.php/Unbricking_CuBox_-_Reflashing_SPI_Memory |
| 23:28 | rmk_ | he's gone |
| 23:29 | rmk | 23:29 * rmk_ finally gets his cubox playing back DVD quality mpeg2 without dying in less than a minute |
| 23:29 | rmk | 23:29 * rmk_ curses the kirkwood audio driver for that. |
| 23:37 | dv_ | with the hw decoder? |
| 23:37 | rmk_ | doesn't seem to matter |
| 23:38 | dv_ | it should for the CPU usage |
| 23:38 | rmk_ | even vlc decoding to "text" via ssh... it still crashed with that so it doesn't seem to be sdram bandwidth related |
| 23:38 | rmk_ | oh yes, for cpu usage it matters but not for causing the kirkwood audio driver to kill the kernel |
| 23:38 | dv_ | oh :O |
| 23:39 | rmk_ | vlc's currently running... deciding dvd quality video atm... |
| 23:39 | dv_ | you know, sometimes I wish more platforms would just put some primitive I2C-connected DAC on the board , add a simple alsa driver with one volume control, and done |
| 23:39 | rmk_ | 4745 cubox 20 0 161m 53m 34m S 37.9 7.5 28:12.70 vlc |
| 23:39 | rmk_ | 3626 root 20 0 48364 31m 27m S 8.4 4.4 6:23.82 Xorg |
| 23:40 | dv_ | as opposed to these uber-complicated USB-Audio based DSPs |
| 23:40 | dv_ | errr, I2S-connected, not I2C |
| 23:40 | rmk_ | that's almost what the cubox has... |
| 23:40 | dv_ | almost? |
| 23:41 | rmk_ | almost, because it's I2S out into toslink(spdif) and hdmi |
| 23:41 | dv_ | hm |
| 23:41 | dv_ | so there is some switch between spdif and hdmi? |
| 23:41 | rmk_ | I've a toslink to rca converter... so don't need the tv for audio |
| 23:42 | rmk_ | I think they're fed with the same I2S |
| 23:42 | rmk_ | simultaneously |
| 23:43 | dv_ | well it sounds simple then |
| 23:44 | dv_ | how can a driver then kill the kernel? |
| 23:44 | rmk_ | in this case... |
| 23:45 | rmk_ | it signals a fifo underrun and raises an interrupt. the kernel services the interrupt, and returns, meanwhile the hardware immediately signals another underrun interrupt. |
| 23:45 | rmk_ | the kernel services that interrupt... repeat until the cows come home. |
| 23:48 | rmk_ | ah, haha, _that's_ the real reason why. |
| 23:48 | rmk | 23:48 * rmk_ grumbles at this kirkwood code |
| 23:48 | rmk_ | ok, so the underrun _doesn't_ raise an interrupt for us (we haven't hooked that interrupt in the driver) |
| 23:49 | rmk_ | what instead happens is that we get a normal interrupt raised, check the error register, clear it and return _without_ servicing the normal interrupt which is still pending. |