| 10:36 | RandomPixels | sh231 packages can be updated. |
| 10:36 | RandomPixels | 168 updates are security updates. |
| 10:36 | RandomPixels | New release 'precise' available. |
| 10:36 | RandomPixels | Run 'do-release-upgrade' to upgrade to it. |
| 10:36 | RandomPixels | should I ? :) |
| 10:37 | shesselba | _rmk_: with "clk stuff is messed up" you mean with or without DT? |
| 10:39 | _rmk_ | without; I found the problem - tclk was missing |
| 10:40 | _rmk_ | so the clk_get_sys() in Rabeeh's tree was returning ENOENT |
| 10:41 | _rmk_ | would have been nicer if whoever added that clk_get_sys() also added some reasonable error handling and maybe provided a default clock rate for the UARTs |
| 10:41 | _rmk_ | rather than just crashing the kernel |
| 10:41 | _rmk_ | I call that kind of programming lazyitis |
| 10:43 | _rmk_ | I'm not sure why those tclk changes were even made in Rabeeh's tree |
| 10:44 | shesselba | I guess you should blame me for that (again!) .. sorry, it looks like there is no one testing on dove except me.. |
| 10:44 | shesselba | I ve been on DT for a while now |
| 10:48 | _rmk_ | I've not yet tried video playback but everything else seems to work on 3.7-rc7 |
| 10:50 | _rmk_ | once, of course, all the yucky merge issues are fixed properly :) |
| 10:50 | shesselba | Great! BTW I ve pushed a dove patch set to u-boot mainline |
| 10:56 | _rmk_ | what I may do for my v3.7 kernel is start over; just use rabeeh's tree as a reference and import the missing stuff as entirely 'new' stuff and keep the 'import' at the head of the tree (so all work goes below that) |
| 10:56 | _rmk_ | that should mean I'm no longer having to maintain two sets of patches in parallel all the time |
| 10:57 | _rmk_ | one set against mainline and one set against my 'cubox' kernel |
| 11:00 | shesselba | so what's on your list (except galcore/vmeta/hdmi) I can help with? |
| 11:03 | _rmk_ | is the si5351 clk support queued for this merge window? |
| 11:03 | shesselba | no, but that is on my list |
| 11:04 | shesselba | basically , it needs two things added: regmap and DT |
| 11:04 | _rmk_ | ok, there's also the i2c driver... |
| 11:04 | _rmk_ | drivers/i2c/busses/i2c-mv64xxx.c |
| 11:04 | _rmk_ | it uses interruptible sleeps... |
| 11:05 | _rmk_ | that's fine if you can recover from a signal and return to complete the action, but in the i2c driver you can't |
| 11:05 | _rmk_ | so, if the HDMI code is talking to the TDA chip, and a signal becomes pending, your I2C transaction aborts never to be restarted |
| 11:05 | shesselba | uhh, mv64xxx is ppc guys.. they already stalled gbe driver conversion ;) |
| 11:07 | _rmk_ | I need to finish off working out how to split my bmm and vmeta kernel changes so I can publish something there to go along with the library git trees I've already pushed out |
| 11:08 | _rmk_ | the problem there is that they're invasive into arch/arm/mach-dove code |
| 11:08 | shesselba | well, si5351 is my code anyway. I already have a request for it and I will add regmap and DT.. |
| 11:09 | shesselba | What are they changing there? |
| 11:09 | _rmk_ | oh, its all the platform device, resources, clocks and the memory reservation (which I do properly in my tree) |
| 11:10 | _rmk_ | I'm not sure why Rabeeh isn't using arm_memblock_reserve() |
| 11:10 | _rmk_ | but instead moved the ->fixup hook and manipulates the memory information directly |
| 11:11 | _rmk_ | I sent Rabeeh patches for that, but he ignored them :( |
| 11:11 | _rmk_ | anyway, bbiab. |
| 12:40 | _rmk | 12:40 * _rmk_ notices something else that needs killing - bmm_get_kern_paddr() in userspace and the corresponding code in kernel space (thankfully it seems unused) |
| 22:41 | dv_ | has anybody here tried to boot from NFS? I get an "Unable to mount root fs on unknown-block(0,255)" error |
| 22:41 | dv_ | using archlinuxarm, latest rootfs |
| 23:05 | dv_ | ah nevermind. the alarm kernel doesnt have nfs fs linked in |
| 23:12 | hybridvs | Greetings |
| 23:15 | hybridvs | I just got my CuBox unpacked and have a little problem. I plugged the box to my swich , activated dhcp into it , and powered the cubox. The switch is blinking and the line indicator shows 1gb full duplex connection , but shows no ip in the dhcp range being used. Do i need to do something else apart from power it up ? |
| 23:27 | dotarray | evening rabeeh :) |
| 23:28 | Punkley_Chillin | generally you shouldn't, do u have ubuntu desktop up? |
| 23:29 | Punkley_Chillin | if you do try "sudo dhclient eth0" |
| 23:29 | Punkley_Chillin | if not replace the network cable and try again |
| 23:40 | hybridvs | Punk-ley , the cable i know is working, the dhcp is in the swich wich acts as a router too |
| 23:41 | Punkley_Chillin | try sudo dhclient eth0 |
| 23:44 | hybridvs | sorry , i may have explained myself poorly. I was monitoring my router/swich thru the web interface , to see if the Cubox is accessing the network , and while the cubox is with its red led on , and the swich web interface marks the port as ok , and with the line at 1000/full duplex , dhcp active with range 192.168.0.20/192.168.0.50 , cubox isn't taking any of this offered ip's , so i cannot ping |
| 23:44 | hybridvs | nor of course telnet to the box |
| 23:45 | hybridvs | i have not a micro-usb cable to try the serial console facility yet , i'll get it next week |
| 23:56 | dv_ | yay, all marvell plugins work again |
| 23:56 | dv_ | (gstreamer plugins) |