| 10:06 | dv_ | rabeeh: will the cubox-i have the same size as the cubox? |
| 10:25 | jnettlet | dv_, yep. Same form factor and port layout as the Cubox Pro |
| 10:26 | jnettlet | unless something has changed since the launch announcement |
| 10:34 | dv_ | the red one looks funny btw. |
| 10:34 | dv_ | I was thinking: "ferrari cubox" :) |
| 10:41 | jnettlet | I like the red. But I would love a translucent one with controllable lighting. |
| 10:43 | dv_ | yeah. but actually, solidrun would be wise to not offer multiple colors |
| 10:43 | dv_ | they complicate logistics a lot |
| 10:43 | cbxbiker61_ | i really like the red, so i'm glad they're doing it |
| 10:44 | dv_ | I think its just a photo |
| 10:45 | dv_ | there is no option for selecting the color |
| 10:45 | dv_ | tbh, I do not understand why they put it there in the first place |
| 10:46 | _rmk_ | it didn't look like a photo to me, more a representation of what it may look like. notice how hard the edges are. |
| 10:46 | _rmk_ | it looked "drawn" to me |
| 10:46 | jnettlet | doesn't rabeeh have a red one in the video? |
| 10:46 | jnettle | 10:46 * jnettlet goes to check. might be confused |
| 10:47 | jnettlet | confirmed the video has a red one |
| 10:49 | jnettlet | what is great for machines this size you can release the case design files and let people 3d print a new case in whatever color they want. |
| 10:49 | dv_ | thats better |
| 10:49 | dv_ | I am concerned about the combinatorial explosion otherwise |
| 10:50 | dv_ | number_of_products x number_of_colors |
| 10:50 | jnettlet | or design a case that can hold a cubox and multiple hard-disks. |
| 10:50 | dv_ | heh. a case with the power supply inside. the power supply being bigger than the cubox. |
| 10:51 | jnettlet | If the cubox can power two usb ports and esata with a 5volt 3amp converter, it should be able to handle 2 sata ssds no problem |
| 10:52 | jnettlet | or 1 sata ssd and 1 green 2.5" drive. |
| 10:58 | jnettlet | anyone know what the max watts are on the iMX6 soc? |
| 10:58 | jnettlet | my guess would be somewhere around 6watts running all out. |
| 11:00 | jnettlet | _rmk_, is your DNS still under attack by the chinese? |
| 11:05 | cbxbiker61_ | just did some more testing on filesystem/partition alignment on USB flash drives, it makes quite a difference |
| 11:06 | cbxbiker61_ | initially my USB3 flash drive was aligned at 32K, i formatted an identical flash drive at 2M boundaries and it was a nice boost |
| 11:07 | cbxbiker61_ | f2fs likes parts aligned in multiples of 2M |
| 11:07 | cbxbiker61_ | on SD cards 4M alignment is preferred for most current devices |
| 11:08 | jnettlet | cbxbiker61_, are you using flashbench to determine that? |
| 11:08 | cbxbiker61_ | i use iozone |
| 11:08 | dv_ | does uboot 2013 support f2fs? |
| 11:08 | jnettlet | nope |
| 11:08 | cbxbiker61_ | i haven't seen any u-boot f2fs action yet |
| 11:09 | cbxbiker61_ | it'd be nice if a filesystem expert would dig into that |
| 11:09 | dv_ | does ext3 also benefit from the 4M alignment? |
| 11:09 | jnettlet | because Android always has a separate partition for the kernel and init image |
| 11:09 | dv_ | jnettlet: then perhaps we should still stick to the 2 partition setup |
| 11:10 | dv_ | fat32 for the boot partition, f2fs for the main one? |
| 11:10 | cbxbiker61_ | dv_, that's pretty much my plan except i use ext2 for boot |
| 11:11 | cbxbiker61_ | interestingly when I put this SanDisk USB3 flash drive in a system with USB3, it exceeds the manufacturer's spec for transfer rate |
| 11:11 | jnettlet | dv_, I have always been partial to that configuration. For production systems you can not mount the partition reducing the possibility of someone breaking boot accidentally. On a dev system you can just mount it to /boot for easy access |
| 11:11 | cbxbiker61_ | spec'd at 190M, tests at 207 |
| 11:12 | dv_ | true |
| 11:12 | jnettlet | They probably source from multiple chip vendors and the spec is an average |
| 11:13 | cbxbiker61_ | i have a SD-FlashFormatter.sh script that calculates optimal part sizes for particular SD cards |
| 11:14 | cbxbiker61_ | jnettlet, it also may be that f2fs is better than the FAT crap that they probably test with |
| 11:14 | _rmk_ | jnettlet: not as much as it was, but its probably not quite as I said - its a dns amplification attack againt someone else |
| 11:15 | jnettlet | _rmk_, why does that dns record return half a class C? |
| 11:15 | _rmk_ | the idea is as follows: |
| 11:16 | _rmk_ | 1. setup a domain which produces large responses (eg, by filling it with most of a class C) |
| 11:16 | _rmk_ | 2. find a bunch of nameservers which will either recurse and return it, or return an otherwise large response |
| 11:17 | _rmk_ | 3. send spoofed requests for the ultimate victim(s) (which are relatively small) to the target dns servers |
| 11:17 | _rmk_ | victim gets deluged with large dns replies from multiple servers |
| 11:18 | jnettlet | interesting. but mostly just annoying |
| 11:18 | _rmk_ | yep. well, there's two settings to control this in bind: |
| 11:18 | Bluerise | [10:51:50] heh. a case with the power supply inside. the power supply being bigger than the cubox. |
| 11:19 | Bluerise | That reminds me of the Apple TV |
| 11:19 | Bluerise | 1/3 of it is pretty much only the power supply |
| 11:19 | jnettlet | yeah there is the external recursion |
| 11:19 | _rmk_ | 1. recursive no; - something which should be enabled anyway for public facing servers |
| 11:19 | jnettlet | yep |
| 11:19 | _rmk_ | 2. 2. additional-from-cache no; - stops upwards referrals |
| 11:20 | jnettlet | interesting didn't know that one. |
| 11:20 | _rmk_ | yes, (2) is the behaviour (or rather not) which got me "selected" as a target nameserver |
| 11:21 | _rmk_ | which meant I was replying with a 500 odd byte reply with all the root nameservers in |
| 11:23 | _rmk_ | I now reply with a refused response :) |
| 11:24 | cbxbiker61_ | BTW, These SanDisk Extreme USB3 flash drives have an actual SATA controller, so I can monitor SMART status |
| 11:25 | cbxbiker61_ | i patched smartmontools to support the device |
| 11:25 | jnettlet | dv_, I just reproduced your u-boot hang. Just typing reset at the prompt will make the board all sorts of unhappy. Hitting the reset button clears it up. |
| 11:25 | jnettle | 11:25 * jnettlet will have to look into that. |
| 11:25 | cbxbiker61_ | 230 Life_Curve_Status 0x0002 100 100 000 Old_age Always - 0 |
| 11:25 | dv_ | jnettlet: ah nice |
| 11:25 | dv_ | jnettlet: pretty annoying, isnt it? :) |
| 11:25 | cbxbiker61_ | that one in particular is usefull |
| 11:27 | jnettlet | dv_, yeah. rabeeh has some code in the old u-boot that I should revisit. I had originally thought it un-necessary but maybe I was a bit hasty. |
| 11:32 | cbxbiker61_ | damn power issues on r-pi are anoying, you never know when you're having problems whether it's a power, software or hardware |
| 11:32 | cbxbiker61_ | just ordered some power plugs that are spec'd at 5.25v, that should make power less of an issue |
| 11:37 | _rmk_ | cbxbiker: at the expense of the linear regulator running hotter no doubt |
| 11:38 | cbxbiker61_ | well they're spec'd to handle up to 5.25v, so as long as they don't go over that they should be fine |
| 11:39 | cbxbiker61_ | main problem is that by the time the voltage gets to the USB ports it's drooping |
| 12:32 | _rmk_ | whee, my rpi case has arrived :) |
| 12:32 | _rmk_ | rabeeh: the USB sockets are definitely misplaced - too close to the ethernet |
| 12:32 | dv_ | _rmk_ , jnettlet , look at robclark's kernel driver interface: http://cgit.freedesktop.org/~robclark/linux/tree/include/uapi/drm/msm_drm.h?h=msm-fixes-3.12-rc2#n98 |
| 12:33 | _rmk_ | dv: yes, that's what galcore should've been doing from the start too :) |
| 12:34 | dv_ | yeah |
| 12:34 | dv_ | fits on a page |
| 12:34 | dv_ | so nice |
| 12:34 | _rmk_ | I think galcore supports doing that kind of thing via a config option though too |
| 12:34 | dv_ | galcore does too much I think |
| 12:34 | _rmk_ | SECURE_USER or something like that |
| 12:34 | _rmk_ | but in their inevitable stupidity, both userspace and kernelspace need to be built with the same option setting for it to work |
| 12:36 | jnettlet | _rmk_, yep. Userspace is never built with that because it is broken. I turned it on in the sources and gave up on it after a day of trying to fix broken stuff. |
| 12:37 | jnettle | 12:37 * jnettlet found out early that have those config options are disabled because they are horrendously broken. Not necessarily in the kernel space either. |
| 12:40 | dv_ | the guys at #etnaviv cleaned this up, threw away thousands of lines |
| 12:40 | dv_ | and shoved it all in one directory |
| 12:40 | dv_ | https://github.com/gcwnow/linux/tree/jz-3.11/drivers/gpu/vivante/v4 |
| 12:53 | jnettle | 12:53 * jnettlet is looking. |
| 12:56 | wumpus | userspace api for that is https://github.com/gcwnow/linux/blob/jz-3.11/include/uapi/vivante/gc_hal.h , still quite a lot of lines compared to robclark's interface, but already cleaned up a lot |
| 12:56 | wumpus | could be reduced a lot as soon as we're willing to completely break the binary interface |
| 12:57 | wumpus | then again, this is mostly for understanding, we've decided a long time ago it's better to start from scratch |
| 13:00 | wumpus | SECURE_USER is only part of the puzzle, it would improve security, but the biggest win is that explicit submission of bo handles makes it possible to synchronize to buffers instead of all the crap with signals |
| 13:04 | _rmk | 13:04 * _rmk_ attempts to track down what seems to be a memleak on his cubox |
| 13:05 | _rmk_ | I got bits all over the floor, they've been dribbling out for the last 14 days :( |
| 13:08 | wumpus | :/ |
| 13:10 | _rmk_ | I have my suspicion what it may be |
| 13:10 | _rmk_ | just rebooted with some additional tracking in place |
| 13:10 | _rmk_ | now just have to wait for it to leak again |
| 13:10 | _rmk_ | jnettlet: I'm going to have to dremel this case :( |
| 13:12 | jnettlet | _rmk_, yep. I actually just used a small coping saw to cut down in between the USB and Ethernet ports and then across on the bottom. |
| 13:12 | jnettlet | doing the same for top and bottom parts of the case. |
| 13:13 | jnettlet | a dremel with a cut off disc would work fine. |
| 13:13 | _rmk_ | hmm, I may do the same - I've a coping saw too but whether I still have any blades for it |
| 13:16 | jnettlet | _rmk_, I would also recommend wiring up a reset button if you haven't yet. |
| 13:17 | _rmk_ | it's pull-down ? |
| 13:17 | jnettlet | yep just to ground |
| 13:37 | jnettlet | wumpus, this driver is labeled "Open Vivante V4" support. Are there intentions to break binary compatibility with vivante's userspace libraries? |
| 13:42 | wumpus | jnettlet: I don't think so; right now unused fields are labeled with VIV_DUMMY (which renames them) and not removed |
| 13:42 | wumpus | jnettlet: the best approach to breaking compatibility is simply to create a new interface :) |
| 13:43 | jnettlet | wumpus, I completely agree. I also see that they are using an older driver as the base. |
| 13:43 | jnettlet | 4.6.6 instead of 4.6.9 |
| 13:43 | wumpus | yes, ingenic doesn't provide driver updates anymore for vivante |
| 13:43 | wumpus | that's why we can be liberal with moving and removing stuff, it won't ever get updates from upstream again |
| 13:44 | wumpus | so nothing to merge in |
| 13:44 | wumpus | though of course fixes are welcome :-) |
| 13:45 | jnettle | 13:45 * jnettlet is trying to see how possible it is to merge their work with mine of trying to get a central driver to work with. |
| 13:45 | wumpus | we do intend to merge _rmk_'s fixes as far as they apply to v4 |
| 13:46 | _rmk_ | jnettlet: isn't olpc based off the same that I'm using now? |
| 13:48 | jnettlet | _rmk_, I don't think so. I think you are working off the XO-1.75 codebase that was based off the old v2 vivante driver. Same as the Cubox. |
| 13:48 | jnettlet | We switched to V4 with the MMP3 chipset because we needed the support for dual-cores |
| 13:49 | _rmk_ | and we have v4 hardfp libs? |
| 13:52 | jnettlet | yep. I gots the goods |
| 13:52 | jnettlet | that is why I am trying to get everyone to standardize on that version. |
| 13:52 | jnettlet | at least temporarily until we can build up the Open Source driver. |
| 13:52 | wumpus | at least for for imx6 there is only v4 (not that that means anything, there are at least three different kernel binary APIs for v4) |
| 13:53 | wumpus | every BSP release they change some things |
| 13:53 | _rmk_ | jnettlet: if you could throw me the v4 stuff, I'll see about integrating it into my cubox kernel |
| 13:56 | jnettlet | wumpus, imx6 shouldn't be different than Marvell, other than the customization work for power controll. |
| 13:56 | jnettlet | _rmk_, sure. |
| 13:57 | wumpus | jnettlet: for BSP 4_0_0 they changed some pointers to unsigned long long, for BSP 4_1_0 they changed some more pointers to unsigned long long... all relatively small changes but they do break binary compatiblity |
| 13:59 | wumpus | and indeed, I wouldn't be surprised if the extra commands for power control also break the binary interface because they put everything in one big structure/union/enum, somehow they think ioctls are scarce I guess :-/ |
| 14:00 | jnettlet | wumpus, actually the power stuff is under standard IOCTL's provided by vivante. They just have stub functions that say "put machine power control code here" |
| 14:02 | wumpus | ok |
| 14:08 | _rmk_ | jnettlet: well, Rob's given a reviewed-by for the bulk of the armada drm code now :) |
| 14:09 | jnettlet | _rmk_, great! I will let that get merged then shove my mmp2/mmp3 patches at it. |
| 16:57 | b1tm0nkey | Hi, can anyone tell me if the new cubox-i boxes will support 16:10 resolutions / PAL SD etc? |
| 17:09 | jnettlet | dv_, here is the patch to fix your dvi resolution problem. https://github.com/boundarydevices/linux-imx6/commit/50aa49f52436bde67a81cf137618fa00b367c523 |
| 17:12 | jnettlet | although it is not 100% correct as it should be making sure that the HDMI_DVI_STAT bit is set. |
| 17:21 | jnettlet | b1tm0nkey, we haven't gotten to that point in the testing yet. I have only read specs about standard CEA and VESA modes. |
| 17:23 | jnettlet | dv_, and here is the 3.10 branch that was being discussed the other day. https://github.com/boundarydevices/linux-imx6/tree/boundary-imx_3.10.9_1.0.0_alpha |
| 17:23 | jnettlet | This branch is 378698 commits ahead and 10 commits behind master.....ouch |
| 17:53 | b1tm0nkey | jnettlet: thanks, will just have to wait and see then...hopefully these will support more resolutions than the original cuboxes as they look ideal for a htpc otherwise :) |
| 17:54 | jnettlet | b1tm0nkey, no offense but what crazy television do you have in your home theatre that news SD Pal resolutions? |
| 22:01 | void__ | hello everyone |
| 22:02 | void__ | is this channel just for development or can one give me an advice of what to do when Reflashing SPI does not bring my cubox back to life |
| 22:03 | void__ | really dont know what could be wrong everything looks fine but my cubox just dont writes anything back on my ttyusb0 |
| 22:04 | void__ | received it today and already bricked it :( |
| 22:48 | void__ | i always get sector not correct |
| 22:48 | void__ | :/ |
| 22:48 | void__ | anybody ran into this prob ? |
| 23:20 | robclark | oh, hmm.. looks like pinout for uart on carrier-1 isn't the same as any other board I have |