| 00:28 | _rmk_ | argh, imx-drm gets possible_clones wrong. possible_clones is a bitmask of outputs that can clone this output, not a bitmask of crtcs |
| 02:11 | jya | hello there. |
| 02:12 | jya | Was contacted by rabeeh to look at porting MythTV (www.mythtv.org) on the cubox.. |
| 02:13 | jya | some questions: is there a hdmi (audio+video_ port on the carrier-one? |
| 02:13 | Bluerise | Welcome! |
| 02:13 | Bluerise | yeah |
| 02:13 | Bluerise | Well, I don't know about audio, but it does video for sure :) |
| 02:13 | Bluerise | And I suppose also audio, but I don't know much about that part |
| 02:13 | jya | does X supports OpenGL hardware accelerated ? The pi doesn't, and I'm about to give up porting myth on that platform, just too slow for our purpose |
| 02:14 | jya | Bluerise: from the picutres, I couldn't tell, all I could see was the composite output.. |
| 02:14 | Bluerise | jnettlet: has a u-boot branch which even does hdmi |
| 02:14 | Bluerise | https://github.com/linux4kix/u-boot/commits/imx6 |
| 02:15 | Bluerise | http://imx.solid-run.com/wiki/index.php?title=File:Carrier-one.jpg |
| 02:15 | Bluerise | #3 |
| 02:15 | Bluerise | that's hdmi |
| 02:15 | jya | myth uses Qt. There are ways to use in on linux without X, by using OpenGL ES directly writing to a framebuffer; But Qt only allows for one surface only; that's very limiting when doing a full UI |
| 02:16 | jya | ah much better image ! |
| 02:16 | Bluerise | imx.solid-run.com/wiki/index.php?title=Carrier-One_Hardware |
| 02:16 | Bluerise | note: italic -> not populated |
| 02:17 | jya | ah so the coax is spdif, not video.. my bad |
| 02:18 | jya | so the carrier-one is a quad processor with 2gig of ram? |
| 02:18 | jya | now that's nice ! |
| 02:19 | jya | much easier to work on a port first, and optimise later |
| 02:19 | _rmk_ | jya: us devs got a solo processor on the initial batch |
| 02:20 | cbxbiker61 | yes, the specs are very good, and I did memory bandwidth tests that show the memory is very quick |
| 02:20 | _rmk_ | jya: the freescale kernel looks like having full support but is quite old |
| 02:20 | Bluerise | I also have the solo, despite being European! ;) |
| 02:21 | _rmk_ | jya: I'm trying to get mainline running on it but progress is very slow and lots of problems (esp with bugs in the driver already present in mainline) |
| 02:21 | jya | _rmk_: so what's the configuration in the actual carrier-one ? single and how much ram? |
| 02:21 | Bluerise | 512MB RAM |
| 02:21 | Bluerise | but, as said, only the initial batch |
| 02:21 | Bluerise | I'm looking forward to the actual CuBox-i4 Ultra.. |
| 02:22 | _rmk_ | for where I am with HDMI video output and v3.12-rc4: https://plus.google.com/103895730806848715870/posts/BqovS1Z5ATS |
| 02:22 | _rmk_ | don't know if that works for non-g+ people |
| 02:22 | robclark | _rmk_, ok, I think I got through all of the armada-drm series.. just a comment on 4/5 but should have sent s-o-b for rest unless I missed one |
| 02:23 | jya | _rmk_: so you don't have the video drivers fully working yet? |
| 02:24 | _rmk_ | robclark: yes - 4/5 probably shouldn't be part of what gets committed, its more a proof of concept and guide for the olpc mmp folk |
| 02:24 | robclark | yeah, it looked like the rest of the series stood on it's own |
| 02:24 | Bluerise | _rmk_: I heard there's some new video/drm api coming up? |
| 02:24 | _rmk_ | robclark: thresholding the alpha on cursors really doesn't look right either :) |
| 02:24 | robclark | yeah, it's not what I'd do |
| 02:24 | _rmk_ | I tried it :) |
| 02:25 | _rmk_ | jya: the freescale kernel which is available via those wiki pages supports everything |
| 02:25 | robclark | and.. well, I really doubt you get anything bigger than 32x32 that *doesn't* have more than binary alpha |
| 02:26 | _rmk_ | bluerise: not quite sure what you're referring to; I'm not aware of the drm kms api changing in a big way, but maybe robclark knows better than I :) |
| 02:26 | robclark | _rmk_, I'd slap on my s-o-b for 1-3,5, put it in a branch somewhere and send airlied a pull req |
| 02:26 | _rmk_ | robclark: exactly what I'll do tomorrow :) |
| 02:27 | _rmk_ | and hope airlied isn't already travelling to edinburgh :) |
| 02:27 | _rmk_ | anyway, its very late for me now. |
| 02:27 | robclark | there absolutely won't be any non-compatible kms API/ABI change.. there are a few things getting added (like atomic modeset/pageflip stuff).. kms already does have support for YUV overlays, so I guess that counts as video |
| 02:28 | robclark | _rmk_, cool.. well, if he is traveling already, I think he'll do a round of pull's when he gets back |
| 02:28 | robclar | 02:28 * robclark still needs to send 3.13 msm pull req |
| 02:28 | _rmk_ | one other thing which may be worth doing though: put a comment against two encoder fields... |
| 02:28 | robclark | and, fwiw, I've written code to display video w/ overlays both using kms and v4l.. and I found kms easier ;-) |
| 02:28 | _rmk_ | possible_crtcs is explanatory |
| 02:28 | _rmk_ | possible_clones isn't so. |
| 02:29 | robclark | oh, the possible_clones thing |
| 02:29 | _rmk_ | the imx drm driver assigns the same value to both of those which is wrong :) |
| 02:29 | robclark | yeah.. if you get a chance, send a patch.. fixing comments and docbook for drm is always very welcome :-) |
| 02:29 | robclark | it is a lot better than it was a year or so ago |
| 02:29 | robclark | but I've no doubt there is still room for improvement |
| 02:30 | _rmk_ | I did end up checking the Xorg code to ensure I wasn't going mad |
| 02:30 | robclark | right.. I had to figure out kms by figuring out xorg/xrandr :-P |
| 02:30 | robclark | that was when the documentation was a lot worse |
| 02:30 | _rmk_ | I think that's still a part of the learning curve :( |
| 02:31 | robclark | yeah, kms originated more or less by "let's take xrandr and put it in kernel" |
| 02:31 | robclark | they match up pretty closely.. kms only adds encoders |
| 11:59 | _rmk_ | jnettlet: I've got to the bottom of the problems; it's all to do with how the DI gets clocked, and one of those idiotic clock skipping fractional dividers |
| 12:00 | jnettlet | _rmk_, is it getting that from device-tree? |
| 12:00 | jnettlet | _rmk_, kudos on tracking it down by the way. |
| 12:00 | _rmk_ | imx-drm currently tries to generate all pixel clocks (and hdmi clock) from the ipu clock, which runs at 198MHz |
| 12:01 | _rmk_ | 198MHz into 148.5MHz (for 1080p) doesn't work |
| 12:02 | _rmk_ | 198MHz into 74.25MHz (for 720p) is 2.67, which gives some pulse skipping but not so much that the PLL on the HDMI output notices |
| 12:03 | _rmk_ | 198MHz into 40MHz (for 800x600) gives 4.95. If we program 4.95 we're skipping soo many clocks that the PLL modulates, but if we program 5, it's fine. |
| 12:03 | jnettlet | what is feeding the ipu clock. I thought it should be 200Mhz fed off the 400Mhz pll2 |
| 12:04 | _rmk_ | well, 198MHz is what the depths of the clk API tell me that clock is... hang on, I made a note from the manual of all possible clocks |
| 12:05 | _rmk_ | 198MHz comes from PLLPFD2 divided by 2 |
| 12:05 | jnettlet | okay right. I have read that for dual screen you might need to feed it from PLLPFD3 which should be 540Mhz / 2 |
| 12:06 | jnettlet | unless the solo doesn't have that available only the dual and quads, which is why this problem exists |
| 12:08 | _rmk_ | actually, none of the internal clocks derived from non-pll5 sources are right for HDMI CEA modes |
| 12:08 | _rmk_ | consider... 148.5MHz * n = a fixed clock value |
| 12:08 | _rmk_ | if you can't do that without a n being fractional... |
| 12:09 | _rmk_ | I think with the MPLL on the HDMI output, it can cope with some fractional dividers but not all |
| 12:11 | _rmk_ | I'm sorting out a system to automatically select between the ipu clock and a pll5-derived clock |
| 13:21 | jnettlet | hmm no Loki__ though |
| 14:31 | jnettlet | every single minor revision of the imx vivante drivers has a different gchal_interface definition. wtf???!!!!??? |
| 15:07 | wumpus | yes... :-/ |
| 15:07 | wumpus | I think I've mentioned that at least once |
| 15:07 | wumpus | vivante likes to change their ABI around every single time |
| 15:08 | wumpus | for our kernel driver we should do the opposite, fix an API and never change it, right robclark? :D |
| 15:08 | robclark | +1 |
| 15:12 | jnettlet | wumpus, well I have applied the patchset you showed me last week to the 4.6.9 GPL code-base. Am trying to unify a working structure between Marvell and Freescale binaries now. |
| 15:12 | jnettle | 15:12 * jnettlet wishes Freescale didn't have that ridiculous EULA for their binaries |
| 15:33 | wumpus | with lots of ifdefs it should be possible |
| 15:35 | wumpus | at least to support the latest version of the freescale and marvell binaries.. if you want to support older versions as well, things will quickly go very crazy |
| 15:39 | jnettlet | wumpus, yeah there are a few minor changes. I was hoping that I could do dynamic runtime detection but that seems to be more work than it is worth. |
| 15:40 | jnettle | 15:40 * jnettlet has a dream of one kernel that will actually boot all my devices via device-tree |
| 15:42 | wumpus | that will be possible with the new kernel driver |
| 15:42 | jnettlet | yep. I think my dream will have to wait until then. Just get this stable and somewhat unified. |
| 15:43 | dv_ | kernel 3.12 with VPU, IPU, Vivante and HDMI DRM mainlined |
| 15:44 | jnettlet | dv_, is that your dream? |
| 15:45 | wumpus | that may have to wait for 3.13 |
| 15:45 | dv_ | lets call it the optimum :) |
| 15:45 | dv_ | or that, yes |
| 15:45 | dv_ | as long as its not >3 years old |
| 15:46 | dv_ | ah, and: do the carrier-one and the cubox use simple I2S connections for audio? |
| 15:46 | dv_ | or is there some fancy audio chip involved that may contain internal buffering for some postprocess effects? |
| 15:47 | jnettle | 15:47 * jnettlet hasn't looked at audio yet. |
| 15:47 | jnettlet | just getting GPU under control. |
| 15:47 | dv_ | I'd like to try out multiroom code I've written in the past , but to have good synchronization, the audio output must not have some hidden buffering |
| 15:51 | jnettlet | dv_, looks like it is i2s with dma transfers |
| 15:54 | jnettlet | imx-pcm has a max buffer-size of 64KB |
| 15:55 | dv_ | ah thanks |
| 16:05 | Bluerise | [15:40:52] jnettlet has a dream of one kernel that will actually boot all my devices via device-tree |
| 16:05 | Bluerise | I have that dream, too... |
| 16:12 | _rmk_ | I think that's still very much a pipedream as far as full support for a SoC goes |
| 16:12 | _rmk_ | even wishing for full support for any one SoC is also a pipedream unless you use vendor kernels |
| 16:12 | Bluerise | Well, my OS only has to support about 3/4 different SoCs... ;) |
| 16:13 | Bluerise | (yet) |
| 16:13 | _rmk_ | we're what... three years into the single zImage project... |
| 16:29 | jnettlet | well I hate to say it but part of the hold up is Android. Brand new devices are still shipping with 3.0x kernels. Some have barely bumped up to 3.4 |
| 16:29 | jnettlet | Even Linaro is really only doing most their work on 2 or 3 boards |
| 16:30 | jnettlet | hardware is outpacing software at a ridiculous rate |
| 16:40 | jnettlet | _rmk_, when are you heading out to the conference? |
| 16:41 | _rmk_ | Monday afternoon |
| 16:41 | _rmk | 16:41 * _rmk_ wonders why the kernel can't change the DI clock rate |
| 16:41 | _rmk_ | imx-ipuv3 2400000.ipu: Clocks: IPU 198000000Hz DI 74250000Hz Needed 74250000Hz |
| 16:41 | _rmk_ | imx-ipuv3 2400000.ipu: IPU clock can give 66000000 with divider 3, error -11.8% |
| 16:42 | _rmk_ | imx-ipuv3 2400000.ipu: Final: IPU 198000000Hz DI 74250000Hz Got 74250000Hz |
| 16:42 | _rmk_ | imx-ipuv3 2400000.ipu: Clocks: IPU 198000000Hz DI 74250000Hz Needed 40000000Hz |
| 16:42 | _rmk_ | imx-ipuv3 2400000.ipu: IPU clock can give 39600000 with divider 5, error -1.0% |
| 16:42 | _rmk_ | imx-ipuv3 2400000.ipu: Final: IPU 198000000Hz DI 74250000Hz Got 49500000Hz |
| 16:42 | _rmk_ | yes, if I opened the allowable error up to 1% that would've used the IPU clock |
| 16:43 | _rmk_ | but I'm trying to set the DI clock to be the exact rate we want |
| 16:44 | _rmk_ | and 49.5MHz pixel clock instead of 40MHz rather explains why this thing doesn't work. |
| 16:46 | _rmk_ | the other thing which I'm not entirely convinced about is stuffing the divider and mux in the IPU's DI into the clock framework and then having to read the control register to set other settings. |
| 16:46 | _rmk_ | it sounds very much like "ooh, cool, we can obfuscate the code more by doing this!" |
| 16:47 | _rmk_ | it'd be more sensible to have this code choose the clock input and divider itself |
| 16:51 | _rmk_ | robclark: oh, I assume you actually mean Acked-by: not signed-off-by: as you're not actually involved in the path applying the patches? |
| 16:52 | robclark | _rmk_, bleh, I meant reviewed-by, what did I send? |
| 16:52 | robclark | oh, whoops |
| 16:52 | _rmk_ | you sent reviewed-by for patch 2 and sob for the other two |
| 16:53 | robclark | ok, that was *supposed* to be r-b |
| 16:53 | _rmk_ | I'll use reviewed-by :) |
| 16:53 | robclark | thanks |
| 16:53 | robclark | sometimes fingers move faster than brain |
| 16:55 | _rmk_ | you didn't explicitly reply to patch 1, but last night you said "I'd slap on my s-o-b for 1-3,5" |
| 16:57 | robclark | _rmk_, did you have an update 1/5 to use hdmi.h consts? |
| 16:57 | _rmk_ | yep |
| 16:57 | _rmk_ | + buf[PB(1)] = HDMI_SCAN_MODE_UNDERSCAN; |
| 16:57 | _rmk_ | + buf[PB(3)] = HDMI_QUANTIZATION_RANGE_FULL << 2; |
| 16:58 | _rmk_ | and added: |
| 16:58 | _rmk_ | +#include |
| 16:58 | robclark | ok, perfect.. with that it has my r-b |
| 16:58 | jnettlet | oh you aren't bringing in 4. Good then I can just submit my full MMP2/3 patchset once things are merged |
| 16:58 | robclark | (ofc) |
| 16:58 | robclark | _rmk_, want me to reply to 1 or is irc-rb good enough? |
| 16:58 | _rmk_ | in the interests of openness, it would be a good idea, thanks. |
| 16:59 | robclark | ok.. sometimes people do irc r-b, etc on #dri-devel.. but I think that is logged (not sure about #cubox) |
| 16:59 | _rmk_ | I believe this is logged too |
| 17:00 | _rmk_ | but I don't think Jean-Francois reads this |
| 17:00 | robclark | ahh, true |
| 17:01 | jnettle | 17:01 * jnettlet thinks everyone should follow #cubox |
| 17:02 | _rmk_ | okay, the reason my TV reports 1080p @ 25Hz is that it really is doing that, because: |
| 17:02 | _rmk_ | imx-ipuv3 2400000.ipu: Clocks: IPU 198000000Hz DI 74250000Hz Needed 148500000Hz |
| 17:02 | _rmk_ | imx-ipuv3 2400000.ipu: IPU clock can give 198000000 with divider 1, error 33.3% |
| 17:02 | _rmk_ | imx-ipuv3 2400000.ipu: Final: IPU 198000000Hz DI 74250000Hz, Using DI, got 74250000Hz |
| 17:03 | _rmk_ | its being clocked at 74.25MHz instead of 148.5MHz :( |
| 17:03 | _rmk_ | imx-drm die die die :p |
| 17:06 | _rmk_ | robclark: one last thing - are you happy with the dependencies on DRM_ARMADA ? |
| 17:07 | robclark | you mean kconfig or you have some dependent patchset too? |
| 17:07 | _rmk_ | yes, Kconfig deps |
| 17:07 | _rmk_ | depends on DRM && HAVE_CLK |
| 17:08 | robclark | hmm, let me check |
| 17:08 | robclark | seems like it should be ok.. |
| 17:08 | _rmk_ | maybe I should add && (PLAT_ORION || COMPILE_TEST) |
| 17:09 | _rmk_ | probably would have to be expanded for MMP* stuff though |
| 17:09 | robclark | is HAVE_CLK for common clk framework? I assume all platforms have *some* sort of clk :-P |
| 17:09 | _rmk_ | yes |
| 17:09 | _rmk_ | well, more that the platform has some kind of clk API provided |
| 17:10 | robclark | it is definitely nice to be able to at least compile test the driver when you don't have hw.. |
| 17:10 | robclark | otherwise people tend to miss the fact that they broke you when making changes in core |
| 17:10 | _rmk_ | ok, I'll leave it as is then, if it causes problems we can fix later |
| 17:10 | robclark | yeah |
| 17:16 | _rmk_ | sent. whee. :) |
| 17:17 | robclark | \o/ |
| 19:29 | shesselba | _rmk_: another broken cycle-skip clock divider in imx also? |
| 19:42 | _rmk_ | shesselba: yup |
| 19:42 | shesselba | *sigh* |
| 19:42 | shesselba | useless |
| 19:43 | _rmk_ | asking it to divide by 4.9, and then putting a PLL after that produces quite a nice frequency modulator |
| 19:44 | shesselba | cool stuff, but still quite useless.. and DI is limited to 74M25 or is it just the "driver"? |
| 19:48 | shesselba | ah, reading the backlog, I see that DI related comments |
| 19:56 | _rmk_ | shesselba: no, it's not limited, because there's a PLL we can change up stream (which goes up tto 630MHz |
| 19:56 | _rmk_ | the problem is, persuading CCF and/or imx code to use it and/or set it |
| 19:57 | shesselba | ok, I see. Haven't looked at carrier-1 except for installing a usd with jnettlet's u-boot |
| 19:57 | _rmk_ | I've no idea at the moment how the clock tree is setup, or whether at DRM driver level I can get access to enough of the tree to get it to set all the muxes and dividers correctly |
| 19:57 | shesselba | cat you 'cat /sys/debug/kernel/clk/clk_summary' ? |
| 19:58 | shesselba | path needs fixes, but I guess you can handle that |
| 19:58 | shesselba | typing needs fixes too :P |
| 19:58 | _rmk_ | it claims... |
| 19:58 | _rmk_ | pll5_video 0 0 1039500000 |
| 19:59 | _rmk_ | pll5_post_div 0 0 519750000 |
| 19:59 | _rmk_ | pll5_video_div 0 0 519750000 |
| 19:59 | _rmk_ | ldb_di0_sel 0 0 519750000 |
| 19:59 | _rmk_ | ldb_di0_div_3_5 0 0 148500000 |
| 19:59 | _rmk_ | ldb_di0_podf 0 0 74250000 |
| 19:59 | _rmk_ | ldb_di0 0 0 74250000 |
| 19:59 | _rmk_ | ipu1_di0_sel 0 0 74250000 |
| 19:59 | _rmk_ | ipu1_di0 0 0 74250000 |
| 19:59 | _rmk_ | 2400000.ipu_di0_pixel 0 0 74250000 |
| 19:59 | shesselba | omg |
| 20:01 | _rmk_ | yep, it's... very deep. :( |
| 20:02 | _rmk_ | there's 2 to 3 levels of muxes in it, and several dividers |
| 20:02 | shesselba | yeah, I see |
| 20:02 | wumpus | whoa, I thought it was a mispaste first |
| 20:03 | _rmk_ | it can ultimately source from PLL2 (528MHz) or one if its fractional outputs (which are done properly afaics), PLL3 (same) or PLL5 |
| 20:03 | wumpus | why would one ever want that many dividers? |
| 20:03 | _rmk_ | wumpus: welcome to why I've started saying that I think the complexity of this is its undoing. |
| 20:04 | _rmk_ | its too complex for its own good. |
| 20:04 | wumpus | yes, it certainly appears that way |
| 20:04 | _rmk_ | some of those are to do with supporting LVDS outputs |
| 20:05 | _rmk_ | its not helped by these names being different from what's on the clock tree diagram |
| 20:05 | shesselba | *sigh* |
| 20:06 | shesselba | so something does prevent the rate change on DI to propagate upstream |
| 20:06 | shesselba | = |
| 20:06 | shesselba | ? |
| 20:06 | _rmk_ | http://www.home.arm.linux.org.uk/~rmk/output.pdf - the clock tree (2 pages) |
| 20:07 | _rmk_ | this clock in question is on the 2nd page marked up as "IPU1_DI0_CLK |
| 20:07 | _rmk_ | _ROOT |
| 20:07 | _rmk_ | " |
| 20:07 | _rmk_ | text in red is the register name/bitfield |
| 20:07 | Bluerise | that link doesn't work here :( |
| 20:07 | Bluerise | The requested URL /~rmk/output.pdf was not found on this server. |
| 20:08 | _rmk_ | heh |
| 20:08 | _rmk_ | http://www.home.arm.linux.org.uk/~rmk/cubox/output.pdf - the clock tree (2 pages) |
| 20:08 | _rmk_ | the diagram got soo complex that they stopped drawing some clock lines on it :p |
| 20:09 | Bluerise | Ah, that diagram. |
| 20:09 | Bluerise | helped me a lot some time ago |
| 20:09 | _rmk_ | and I like this comment... "The default frequency values (in MHz) for the PLLs and PFDs |
| 20:09 | _rmk_ | is the maximum allowed frequency. The PLL and PFD control |
| 20:10 | _rmk_ | registers should not be programmed to exceed these values. |
| 20:10 | _rmk_ | " |
| 20:10 | shesselba | well, you don't want any of the fixed divider ones, and according to clk_summary above, ip_di_sel muxes ldb_di0 |
| 20:10 | shesselba | which is ipp_clk_di0, I guess |
| 20:10 | _rmk_ | Hmm. So they show PLL5 with 630MHz and we're programming it to 1.0395GHz |
| 20:10 | shesselba | ugh |
| 20:11 | Bluerise | That is quite something |
| 20:11 | _rmk_ | yea, I'm surprised it even works |
| 20:12 | Bluerise | I'm surprised it still works |
| 20:12 | Bluerise | ;) |
| 20:21 | _rmk_ | bluerise: well, it could be that the comment is wrong too |
| 20:28 | shesselba | _rmk_: looking at arch/arm/mach-imx/clk-imx6q.c and the clk_summary above, I guess you have to add some CLK_SET_RATE_PARENT to make clk_set_rate to propagate upstream |
| 20:34 | _rmk_ | bluerise: the comment is wrong. later on in the doc it says that the video PLL ranges from 630MHz to 1.3GHz |
| 20:34 | Bluerise | Ah, I see. |
| 20:35 | shesselba | bbl |
| 22:51 | _rmk | 22:51 * _rmk_ almost got it all working... almost but not quite |
| 23:04 | iandouglas | hey guys, love the idea of the cubox, getting ready to order a cubox-i pretty soon ... any chance someone could clean up the forums of the spam, maybe update the forum software to keep the spammers away, etc? It'd be a shame if new users buying these things up next month have to wade through a ton of junk. |
| 23:04 | iandouglas | question about hardware though: |
| 23:05 | iandouglas | I suppose USB 3.0 would draw a lot more power? I'm just curious about data speeds for external (and externally-powered) hard drives |
| 23:06 | iandouglas | I'm looking to run the cubox as a NAS setup using a mini RAID cabinet which has a USB 3.0 port. I know it's backward compatible to USB 2.0, but for speeds, I'd love to utilize the USB 3.0 speeds if possible... any plans for that down the line? |
| 23:19 | iandouglas | I see mention of a "dev board" in the forums, any chance those are available for purchase as well? |
| 23:31 | _rmk_ | I think you need Rabeeh to answer that question |
| 23:31 | iandouglas | nice quick work on VouchSafe, worked great |
| 23:33 | Bluerise | iandouglas: Hmm... That FreeScale chip "only" has an USB 2.0 controller |
| 23:33 | iandouglas | ah okay, so the SoC won't handle it? |
| 23:33 | Bluerise | iandouglas: But it got PCI-e. I wonder if one could connect a USB 3.0 controller via PCI-e... |
| 23:33 | Bluerise | not sure about the speeds though ;) |
| 23:33 | iandouglas | heh yeah |
| 23:34 | Bluerise | But the SoC in-built controller is not USB 3.0 capable |
| 23:34 | iandouglas | gotcha, thanks for the update |
| 23:34 | Bluerise | one can do many nasty things with PCIe though |
| 23:34 | Bluerise | The Utilite used it to embed another "Gigabit" Ethernet |
| 23:35 | Bluerise | That device is much more expensive though. |
| 23:53 | iandouglas | yeah I'm definitely looking around the $100 mark (give or take) |
| 23:54 | iandouglas | I have a NAS system now (QNAP TS-109) but the OS on there is pretty dated and not easily upgraded, but it's a pretty nice setup with network drive features, SSH access (which gives rsync via ssh), has a media server, basic LAMP stack for PHP/MySQL, etc |
| 23:55 | iandouglas | i'd love to just have a dedicated linux machine without investing a ton of money into it when 90% of the time it'll just be managing NAS duty |