| 00:32 | _rmk | 00:32 * _rmk_ fixes imx_thermal to automatically load at boot. |
| 00:34 | _rmk | 00:34 * _rmk_ wonders how much other stuff is missing a MODULE_DEVICE_TABLE() |
| 07:54 | jnettlet | okay today is the day. |
| 11:29 | _rmk_ | ok, so there won't be any c1 support in a -final mainline for another six months :( |
| 11:30 | jnettle | 11:30 * jnettlet is sad, but happy I have put the time into backporting a lot of stuff to the 3.10 based imx kernel. |
| 11:32 | _rmk_ | the delay is caused by the imx people wanting to redo the way they handle the pinmux stuff in DT |
| 11:34 | _rmk_ | so... if they get it sorted and into mainline during the coming merge window (due real soon now), that means it'll be in for v3.13-rc1. I'll be able to respin the stuff on top of v3.13-rc1 for the following merge window, which will then go in for the next merge window in 3 months time... and it'll show up in v3.14-rc1 shortly thereafter, and v3.14 after another 3 months. |
| 11:36 | _rmk_ | if it misses this merge window then we're looking at 9 months. |
| 13:19 | unununium_ | Hello everybody! |
| 13:27 | dv_ | "the imx people" being ? |
| 13:27 | dv_ | the freescale linux division? |
| 13:28 | _rmk_ | pengutronix |
| 13:45 | jnettlet | noooooo!!!!! |
| 13:48 | _rmk_ | yay, Gregkh has said he will now take the imx hdmi stuff into the staging tree... but not for this merge window (too late) |
| 13:49 | _rmk_ | jnettlet: I kind'a anticipated that reaction from people here that in my email over it :) |
| 13:50 | jnettlet | _rmk_, :-) Great that Gregkh is taking it in for next merge |
| 13:51 | _rmk_ | the only reason that's happening is because its now being worked on :p |
| 13:52 | _rmk_ | with a view to sorting the damn thing out and getting it out of staging |
| 13:52 | jnettlet | hurrah!!! |
| 13:55 | unununium_ | Hey jnettlet! Die you have any success already? |
| 13:55 | jnettlet | unununium_, aahhh not yet. I didn't know my wife was off today so my morning was sucked up doing husbandly duties |
| 13:56 | unununium_ | That's good! :) Because my time is very limited today as well. |
| 13:56 | jnettlet | okay then we can push. works for both of us. |
| 13:56 | unununium_ | ;) |
| 13:56 | unununium_ | Just didn't want to stay away without saying anything. |
| 14:09 | jnettlet | no worries, we won't forget you. |
| 14:11 | unununium_ | That's not what I meant. ;) I've got time. Just didn't want to keep you waiting. |
| 14:58 | Bluerise | [11:32:15] <_rmk_> the delay is caused by the imx people wanting to redo the way they handle the pinmux stuff in DT |
| 14:58 | Bluerise | _rmk_: Does that mean "silently work on it for 6 months and then try to push it to mainline"? |
| 14:59 | Bluerise | Or will the patches be public somewhere? |
| 15:00 | _rmk_ | bluerise: I don't call posting patches to mailing lists "silently work" |
| 15:00 | Bluerise | ok |
| 15:01 | _rmk_ | which I've already done... |
| 15:01 | _rmk_ | what I'm not going to do is push out lots of stuff which isn't finalised in git trees, and then have people base stuff off that only to then find that I've changed all the commits |
| 15:02 | _rmk_ | for example, the first two commits for this stuff are currently: |
| 15:02 | _rmk_ | 6ff4d9d70e84 ARM: imx: initial IMX6 Cubox-i Carrier-1 support *UNSTABLE* |
| 15:02 | _rmk_ | a866a9958668 ARM: imx6qdl: provide pinctrl configurations for DAT3 pull-down *UNSTABLE* |
| 15:03 | _rmk_ | and a866a9958668 will most likely end up being deleted |
| 15:03 | _rmk_ | once the situation with how we're going to do the DAT3 pinmux config is sorted |
| 15:04 | _rmk_ | and yesterday, I replaced the top most 10 commits in my tree when Fabio sent a new revision of his HDMI addon to imx-drm. |
| 15:05 | _rmk_ | with that kind of stuff going on, it's not worth trying to publish in git form. |
| 15:06 | _rmk_ | and I don't want to have a branch which grows lots of cruft which can never be merged into mainline; that's not my aim - my aim is to get stuff into mainline. |
| 15:06 | Catastrophe | Hi |
| 15:07 | Catastrophe | Can anyone help me ? I have this error when I tried to flash uboot on SPI : /dev/mtd0 (SPI flash) is invalid |
| 15:22 | Catastrophe | is the genius rabeeh is here ? |
| 15:26 | jnettlet | Catastrophe, your handle is fitting |
| 15:27 | Catastrophe | :) |
| 15:27 | jnettlet | is this trying to use the cubox installer? |
| 15:28 | Catastrophe | yes :( |
| 15:28 | Catastrophe | i found this : http://server.vijge.net/static/cubox/irclog/201305/cubox-20130527.html |
| 15:28 | jnettlet | Well this is the official unbricking wiki entry. http://www.solid-run.com/mw/index.php/Unbricking_CuBox_-_Reflashing_SPI_Memory |
| 15:29 | Catastrophe | already done, doesn't work |
| 15:30 | jnettlet | the commands fail, or they succeed and the error persists? |
| 15:30 | Catastrophe | second option, they succeed and the error persists |
| 15:30 | Catastrophe | like Hoof in this post : http://www.solid-run.com/phpbb/viewtopic.php?f=7&t=1307 |
| 15:33 | Catastrophe | huuuuum I think i resolve the problem |
| 15:34 | jnettlet | did you switch the usb port? |
| 15:35 | Catastrophe | no, why ? |
| 15:36 | jnettlet | one the usb ports is better than the other for flashing for some reason. Can't remember which one. |
| 15:37 | Catastrophe | the upper one |
| 15:55 | Catastrophe | wellwellwell my problem is solve |
| 15:55 | Catastrophe | how ? i don't know |
| 16:01 | _rmk_ | self resolving problems... :) |
| 19:15 | dv_ | rabeeh: is there some kind of rework that hasnt been done on my c1 ? |
| 19:15 | dv_ | no matter what uboot version I use, I still see this problem that sometimes the c1 does not start |
| 19:15 | dv_ | I see no output on serial |
| 19:16 | dv_ | I have to wait a few minutes, then it works. sometimes. its as if some sort of capacitor is still charged somewhere, and has to be fully discharged before it can successfully reboot |
| 20:55 | _rmk | 20:55 * _rmk_ now has most of imx-drm initialising in the main drm driver load callback... we're getting there :) |
| 21:21 | _rmk_ | almost at the point where imx-drm can be unbound :) |
| 21:58 | _rmk | 21:58 * _rmk_ lols. |
| 21:58 | Bluerise | ? |
| 21:59 | _rmk_ | http://archive.arm.linux.org.uk/lurker/message/20131031.203856.88c60a43.en.html |
| 22:00 | Bluerise | wtf? |
| 22:01 | Bluerise | http://arstechnica.com/security/2013/10/meet-badbios-the-mysterious-mac-and-pc-malware-that-jumps-airgaps/ |
| 22:01 | Bluerise | Glad we don't have that on ARM ;o |
| 22:01 | _rmk_ | bluerise: I believe that article to be crap |
| 22:01 | Bluerise | I don't think all of it is crap. |
| 22:02 | Bluerise | but it really sounds crazy. |
| 22:02 | _rmk_ | (a) no one else seems to be carrying the story |
| 22:02 | _rmk_ | (b) most real OSes do a handshake with the BIOS to gain exclusive control of USB such that the BIOS never gets used for USB |
| 22:03 | Bluerise | I just hope it's not real. |
| 22:03 | _rmk_ | that's why I mean - I don't think it is. |
| 22:04 | _rmk_ | I'm on another channel which has discussed that story over the last two days |
| 22:05 | Bluerise | Ah |
| 22:05 | Bluerise | conclusion? |
| 22:06 | _rmk_ | same as my conclusion |
| 22:07 | _rmk_ | there's other interesting things in there... "It's also possible to use high-frequency sounds broadcast over speakers to send network packets." -- That's quite a claim. |
| 22:08 | _rmk_ | most audio power amps roll off at around 150kHz or lower, there's no way they'll get anywhere near the frequencies needed for network packets... let alone whether a tweeter could reproduce the high frequencies found on network cables... |
| 22:10 | _rmk_ | that whole paragraph, for example, only exists in that article to make you go "oh gosh, I should move my speakers away from my network cables!" |
| 22:10 | tchebb | well, this sounds like an interesting read... |
| 22:14 | tchebb | huh. how odd |
| 22:15 | tchebb | _rmk_: Well, you wouldn't just be sending the ethernet packets directly out the speakers, would you? Presumably there's some other protocol designed to work at low frequencies which IP is tunneled through. |
| 22:16 | jnettle | 22:16 * jnettlet agrees that this is American sensationalist news reporting at the best. All headlines and no facts. |
| 22:21 | jnettlet | _rmk_, I bet this is the stupid virus that embeds itself in the bios of the network adapters. |
| 22:22 | jnettlet | It isn't jumping air gaps it is never completely cleaned from the machine. Because they only flash the bios change drives, but never completely discharge the machine power from the motherboard. |
| 22:23 | jnettlet | Considering most modern ethernet/wifi adapters are their own SOC this isn't surprising. |
| 22:24 | _rmk_ | jnettlet: if you look at the evidence behind "behaves as if it's still connected to the internet" is that the virus seemed to heal itself as they disabled other stuff... err, you don't need to be connected to the net for that to happen. |
| 22:25 | _rmk_ | now, I may be more likely to believe this if they then went on to say "we removed every other machine within proximity and the virus stopped healing itself" |
| 22:26 | _rmk_ | I could continue for ages to rip that article apart, but honestly, it's a waste of time. |
| 22:27 | _rmk_ | or if they physicallly disconnected speakers/mics from the system |
| 22:27 | tchebb | _rmk_: Didn't they? "Then, when Ruiu removed the internal speaker and microphone connected to the airgapped machine, the packets suddenly stopped." |
| 22:27 | _rmk_ | I'm quite sure they would claim that this virus can infect the magnetic coil of a loudspeaker if they thought they could get away with it. |
| 22:27 | jnettlet | and they also say the internal speaker of the machine. Which has zero ability to play any high frequency sounds |
| 22:29 | jnettlet | if it was that big a deal hook a scope up the machine and see what the hell it is doing. This is pathetic |
| 22:31 | jnettlet | "machines whisper to one another using ultrasound" bwahahahahaha |
| 22:31 | _rmk_ | jnettlet: yep and provide an image of the transmitted waveform and analysis thereof. |
| 22:31 | jnettlet | well I also enjoy that they claim these transmissions are "encrypted" |
| 22:31 | tchebb | IThe article has way too much drama and way to little information, but what reason would the people claiming this have to make it up? They seem to be fairly prominent in the security community. |
| 22:32 | tchebb | *too |
| 22:32 | jnettlet | tchebb, I think they aren't so bright. |
| 22:32 | jnettlet | they claim to have been working on this for 3 years and this is the best of their hypotheses |
| 22:33 | tchebb | jnettlet: Yeah, that's certainly a possibility. I don't buy it either; just playing devil's advocate |
| 22:33 | jnettlet | not to mention their should all be losing their jobs as they seem to be Admins for some type of computer security group. |
| 22:34 | jnettlet | really just just seem to be virus herders |
| 22:34 | tchebb | and it's not even like it's a high-profile target. If this isn't a targeted piece of software (and if it were, why would they target him?), why haven't there been other reports? |
| 22:36 | jnettle | 22:36 * jnettlet guesses that this is a hoax. Somebody demonstrating how easy it is to "hack" the news outlets |
| 22:37 | taz | hello :) |
| 22:38 | taz | I'm trying to reinstall my cubox |
| 22:38 | taz | I boot from the usb FAT 32 key with /boot on it |
| 22:38 | taz | ad nothing appear on my screen, so I did it with a usb cable avec minicom on linux |
| 22:38 | taz | and I can see my usb key booting |
| 22:39 | taz | but the process block on this step : Loading Kernel Image ... |
| 22:39 | taz | do you have an idea please ? :) |
| 22:42 | _rmk_ | you've checked that the usb key is properly readable on another machine? |
| 22:43 | taz | yes |
| 22:43 | taz | ho ok i found |
| 22:43 | taz | it is my version of uboot |
| 22:43 | taz | it is too old |
| 22:45 | taz | but I can't update my u-boot |
| 22:45 | taz | I don't understand how to do it |
| 22:45 | taz | because on this page http://www.solid-run.com/mw/index.php/CuBox_Installer it say it is automatic |
| 22:46 | _rmk_ | I'm afraid I've never done any of the official upgrades etc so... |
| 22:46 | taz | ok |
| 23:53 | taz | erf i break my cubox :( |
| 23:54 | taz | hello, i break the u-boot of my cubox v2 and this procedure don't recue me :/ http://www.solid-run.com/mw/index.php?title=Unbricking_CuBox#Linux_.28Ubuntu.29 |
| 23:54 | taz | someone for help please? |