| 00:30 | _rmk_ | yay, my sd card shows up |
| 00:52 | _rmk_ | ooh. okay, progress |
| 00:52 | _rmk_ | now have the SD card detected... and USB pendrive in top USB detected |
| 00:53 | _rmk_ | and bottom USB |
| 01:02 | _rmk_ | here's the DT file so far... |
| 01:02 | _rmk_ | http://www.home.arm.linux.org.uk/~rmk/cubox/imx6dl-cubox-i.dts |
| 01:10 | _rmk_ | and a boot log |
| 01:10 | _rmk_ | http://www.home.arm.linux.org.uk/~rmk/cubox/cubox-i-dt-boot.log |
| 06:51 | jnettlet | ah the imx6_v4 code needs to be be patched up to build properly. almost done. |
| 08:45 | jnettlet | _rmk_, oh you are so right. This imx6 version of the vivante driver needs a bunch of extra work. |
| 08:52 | wumpus | multicore makes the races much, much worse |
| 08:55 | jnettlet | because all of this is done vendor by vendor they just jam custom power management code in the driver rather than doing it properly with common clock |
| 08:56 | jnettlet | After my poking the last Marvell implementation is better, but still far from perfect. |
| 08:57 | jnettlet | imx6 just ifdef'd their own stuff into the hooks...blech |
| 08:58 | wumpus | yes they all do; though Vivante is partly to blame, for not using the proper linux kernel facilities in the first place |
| 08:59 | wumpus | none of the SoC builders wants to completely rewrite vivante's driver, so they just patch in their crap |
| 09:00 | jnettlet | well I just unpatched all the vendor specific crap out the of driver and will use it as a clean slate to do some quick bringup for Marvell and Freescale stuff. |
| 09:01 | wumpus | yes it's up to the community (read: us) to show how it can be done better |
| 09:02 | jnettlet | well that will only really happen with a kernel driver re-write. But getting something stable in the short term will help a lot of platforms |
| 09:34 | purch | which acrylic transparent casing would fit to dev board? |
| 09:34 | purch | http://dx.com/p/raspberry-pi-acrylic-case-transparent-197133 ? |
| 09:36 | jnettlet | purch, any that work with a RPi Rev 2. Although you may need to modify a bit for the USB ports. |
| 09:36 | jnettlet | purch, that is a general guess. We have no official verification yet. |
| 09:36 | purch | at last I have a reason to buy dremel :) |
| 09:37 | purch | well I order few of those |
| 09:37 | jnettlet | I should have mine early next week and will report back |
| 09:37 | purch | dx.com takes 1-2 weeks so I order now |
| 09:38 | jnettlet | ah okay. Although they have free shipping to denmark so I will bookmark that site :-) |
| 09:38 | purch | yes, free to Finland also |
| 09:39 | jnettlet | actually that case looks like it will have no problems with the usb ports. |
| 09:39 | purch | that is a dangerous place, I warned you =) |
| 09:39 | purch | full of low priced gadgets http://dx.com/gift-ideas/Under5 |
| 09:40 | purch | over 160k |
| 09:42 | jnettlet | wow impressive |
| 09:58 | purch | I took two of these (6-layer acrylic must be way better :P) http://dx.com/p/smpd01-protective-acrylic-storage-case-for-raspberry-pi-transparent-202095 |
| 10:45 | _rmk_ | rabeeh: how many of these pinmux settings are actually used? |
| 12:22 | _rmk | 12:22 * _rmk_ can't get ethernet working with 3.12-rc1 :( |
| 12:23 | _rmk_ | rabeeh: is this 50MHz enet.0 clock needed with the AR8035? |
| 12:23 | jnettlet | _rmk_, are you putting the clock definitions in device-tree as well? |
| 12:24 | _rmk_ | I'm trying to figure out why ethernet's not working |
| 12:24 | _rmk_ | it could be a pinmux setting... the pinmux stuff is a nightmare in dt |
| 12:26 | _rmk_ | the majority of the time I've spent on this has been trying to figure out what the right pinmux stuff should be |
| 12:26 | _rmk_ | and that's... quite literally taken hours. |
| 12:29 | _rmk_ | I'm getting to the point of giving up with it because its too much effort. Give me back stuffing board stuff in C files any day to this. |
| 12:30 | jnettlet | yes but then you lose multi machine support |
| 12:31 | jnettlet | which has become worse than ACPI at this point. Only difference is the community has to do all the work from the ground up. |
| 12:31 | _rmk_ | still better than spending 8+ hours burning your brain out with this |
| 12:31 | jnettlet | oh I agree. I am fighting on the mmp2 device-tree support in my spare time. |
| 12:32 | jnettlet | but uboot has enet pin mux at gpio 5 and 15 |
| 12:33 | jnettlet | clock is 25Mhz set through pll8 |
| 12:33 | jnettlet | not that it is working either, but it is a reference. |
| 12:33 | jnettlet | I have to look at the working kernel code some more. |
| 12:34 | _rmk_ | Rabeeh's kernel code says that the AR8035 produces a clock whereas the 8030 consumes it |
| 12:35 | _rmk_ | the enet.0 clock also gets set to 50MHz - I've not yet worked out exactly what clock that is yet |
| 12:35 | _rmk_ | it's not helpful that the clock names between the freescale kernel and DT are different |
| 12:36 | _rmk_ | do you have the AR8035 fixup in uboot? |
| 12:36 | jnettlet | nope |
| 12:37 | _rmk_ | you probably need that to configure the phy to provide a clock |
| 12:37 | _rmk_ | I'm wondering about this: |
| 12:37 | _rmk_ | + /* Set GPR1, bit 21 to 1 */ |
| 12:37 | _rmk_ | + mxc_iomux_set_gpr_register(1, 21, 1, 1); |
| 12:38 | _rmk_ | and whether that's also something to do with it |
| 12:38 | jnettlet | oh that must be the mx6_rgmii_rework |
| 12:38 | _rmk_ | the ar8035 is used in RGMII mode |
| 12:38 | jnettlet | this code has this comment. /* To enable AR8035 ouput a 125MHz clk from CLK_25M */ |
| 12:39 | jnettlet | seems we have some conflicting views on how things should be clocked. But we know 50MHz works under the 3.0xxx kernel |
| 12:39 | _rmk_ | all depends what that enet.0 clock is |
| 12:40 | _rmk_ | whether that's a clock provided to the phy or the mac core |
| 12:40 | jnettlet | I think we can get the docs from freescale's site. |
| 12:40 | _rmk_ | yea, I got that :) |
| 12:41 | _rmk_ | it needs... reading :) |
| 12:41 | _rmk_ | http://cache.freescale.com/files/32bit/doc/ref_manual/IMX6SDLRM.pdf |
| 12:41 | _rmk_ | Fabio was good enough to give a direct link to it on the mailing lists :) |
| 12:41 | jnettlet | very nice of hime. |
| 12:42 | jnettlet | almost 6000 pages. painful |
| 12:42 | _rmk_ | yes - hence my comment about it needing reading! |
| 12:42 | _rmk_ | no trivial matter |
| 12:43 | _rmk_ | there's quite a few contents pages in there |
| 12:43 | jnettlet | well bit 21 of gpr1 chooses the enet's reference clock mode. |
| 12:43 | wumpus | wow, that's a lot of pages |
| 12:44 | wumpus | on the bright side, maybe that means it's somewhat complete |
| 12:44 | wumpus | usually vendor docs err on the other side and provide too little info |
| 12:45 | jnettlet | which makes sense if the ar8035 is producing a clock. So that seems in order. |
| 12:46 | jnettlet | well except the ethernet isn't working in uboot yet :-P |
| 12:53 | _rmk_ | hmm, there seems to be code which sets GPR1 bit 21 already in mainline... I wonder if it's happening at the right moment |
| 12:56 | dv_ | _rmk_: so what are you working on atm? |
| 12:56 | dv_ | still galcore? |
| 12:57 | dv_ | wumpus: there are additional docs for some of the subsystems |
| 12:57 | dv_ | the VPU ones for examples, or the GAL 2D API |
| 12:57 | dv_ | freescale likes to write docs :) |
| 12:58 | _rmk_ | dv: just trying to get cubox-i up and running with v3.12-rc1... and failing |
| 12:59 | _rmk_ | dv: well, there's some success but also a lot of frustration with DT |
| 13:00 | _rmk_ | dv: yes, I noticed the additional docs on the vivante stuff in there |
| 13:01 | jnettlet | dv_, I am working some cubox-i uboot functionality, which is kind of mirroring _rmk_'s kernel debugging. |
| 13:01 | dv_ | ah |
| 13:02 | jnettlet | But you will be happy to know I started merging _rmk_'s galcore race fixes into a "clean" vivante v4 tree |
| 13:02 | dv_ | \o/ |
| 13:02 | jnettlet | and will be integrating _rmk_'s vmeta char device into the same tree. |
| 13:02 | dv_ | so, one tree to rule them all :) |
| 13:03 | dv_ | btw. I think I mentioned it once, not sure. I got the ok to upstream my chromium changes, together with the revised OE recipes to make chromium use GLES for rendering (-> smoother display & effects) |
| 13:03 | dv_ | so I am curious to see how it performs with these changes |
| 13:03 | jnettlet | then we may take minor bug fixes but won't put much work into that. We all decided it was time to just do a drm-etnaviv kernel driver |
| 13:03 | dv_ | the tons of glitches I've seen are just too numerous to be caused by chromium bugs alone |
| 13:04 | dv_ | excellent. this makes the entire stack open source and introspectible |
| 13:05 | jnettlet | dv_, they aren't. Our problems with webgl in chromium are what eventually got us access to the full vivante source. The decision was that there were too many bugs at the time to continue down the path. |
| 13:05 | jnettlet | the libGL* stuff was still binary, so only so much patching we could do. |
| 13:05 | dv_ | did you also try out chromium with GLES? |
| 13:06 | jnettlet | at that point they didn't have GLES rendering for webpages. It was only there to support WebGL |
| 13:06 | dv_ | at least chromium 31 does not crash the kernel like 29 did. its GPU process crashes though. |
| 13:06 | dv_ | at some point we had a rootfs that was behaving totally strange |
| 13:06 | dv_ | *modprobe* crashed. MODPRBE. |
| 13:06 | dv_ | the disk cache crashed. |
| 13:06 | dv_ | the kernel debugger crashed. |
| 13:07 | jnettlet | sure your SOC wasn't overheating? |
| 13:07 | dv_ | yes |
| 13:07 | dv_ | eventually we found out that large parts of memory in kernel space were being overwritten |
| 13:07 | jnettlet | looking at the IMX6 vivante changes that appears to be a problem. They have thermal checks and limiters. |
| 13:08 | _rmk_ | dv: you probably need my vivante race fixes then :) |
| 13:09 | jnettlet | dv_, you are testing this on the imx6, or cubox? |
| 13:09 | dv_ | imx6 |
| 13:09 | dv_ | cubox was even worse though |
| 13:09 | _rmk_ | jnettlet: just reading through the GPR bit definitions... looks like they have some hardware debugging for the gpu ! |
| 13:09 | dv_ | there were rendering errors all over the place |
| 13:09 | dv_ | _rmk_: indeed |
| 13:10 | jnettlet | _rmk_, really? |
| 13:10 | dv_ | but, for this project, we only need to support imx6. |
| 13:10 | _rmk_ | #define IMX6Q_GPR3_GPU_DBG_GPU3D (0x0 << 29) |
| 13:10 | _rmk_ | #define IMX6Q_GPR3_GPU_DBG_GPU2D (0x1 << 29) |
| 13:10 | _rmk_ | #define IMX6Q_GPR3_GPU_DBG_OPENVG (0x2 << 29) |
| 13:10 | jnettlet | dv_, well I will probably start with a kernel for the cubox and then integrate imx stuff as we make progress on the cubox-i |
| 13:11 | dv_ | yeah, sounds good |
| 13:15 | dv_ | jnettlet: we can then also think of some 2D API for the video stuff |
| 13:15 | dv_ | which is nice |
| 13:27 | jnettlet | dv_, I am pretty sure I know how I want to handle that. We just need a stable backend first. |
| 13:28 | wumpus | we first need to define an API before we can write a backend for 2D |
| 13:28 | jnettlet | wumpus, this is for the existing libGAL |
| 13:28 | wumpus | oh, never mind then |
| 13:29 | jnettlet | we are tag teaming, future progress vs stabilizing existing right now. |
| 13:29 | wumpus | makes sense |
| 13:30 | jnettlet | normally you let the binary driver company take care of stabilizing existing, but that does not seem to be happening. |
| 13:37 | dv_ | at least they are not suing anybody |
| 13:39 | jnettlet | yet |
| 13:39 | jnettlet | :-) |
| 13:39 | _rmk_ | it would be interesting if they tried that, because the code that's being stabilized is the GPL stuff |
| 13:41 | jnettlet | I think at this point they realize it is not a good idea. Their money is their hardware IP. Trying to limit better software from happening seems crazy. |
| 13:41 | dv_ | according to wumpus, they dont care |
| 13:41 | dv_ | yeah |
| 13:41 | dv_ | if anything, it increases their value |
| 13:42 | jnettlet | they just don't people contacting them for support. They made that very clear when they were working directly with us at OLPC. |
| 13:42 | jnettlet | they want to sit behind the hardware vendors that implement their chips |
| 13:43 | _rmk_ | jnettlet: all the more reason if they could release limited specs to a few individuals to sort out the open source stuff |
| 13:43 | dv_ | their legal department probably has a problem with that |
| 13:43 | jnettlet | _rmk_, I keep sending emails |
| 13:43 | dv_ | I heard legal is also often called the department of No |
| 13:44 | jnettlet | every monday I pick a new person on the list and send a plea. |
| 13:44 | _rmk_ | dv: or the department of wyeknot. :) |
| 13:45 | dv_ | hehe |
| 13:46 | dv_ | also, I've seen especially IBM's legal division being called "mordor", and the lawyers nazghul :) |
| 13:47 | _rmk_ | Douglas Adams came up with the perfect solution to this. Earth is allegedly about to get destroyed, so ship out the administrators and lawyers to a new planet ahead of everyone else so they can get things organised there. :) |
| 13:48 | dv_ | :) |
| 13:48 | jnettle | 13:48 * jnettlet +1 |
| 13:52 | jnettlet | oh a bunch of DRI3 stuff has just landed. Great timing for a new kernel driver. |
| 13:53 | jnettlet | we really couldn't have timed it better. |
| 13:56 | wumpus | hehe |
| 13:58 | jnettlet | dv_, DRI3 allows a dmabuf to be linked to a pixmap. Exactly what we are looking for. |
| 13:58 | _rmk_ | GAH. |
| 13:59 | _rmk_ | so, the imx6 DT files refer to clocks like <&clks 123> |
| 13:59 | _rmk_ | what does that number correspond with? |
| 13:59 | _rmk_ | enum mx6q_clks { |
| 13:59 | _rmk_ | dummy, ckil, ckih, osc, pll2_pfd0_352m, pll2_pfd1_594m, pll2_pfd2_396m, |
| 13:59 | _rmk_ | pll3_pfd0_720m, pll3_pfd1_540m, pll3_pfd2_508m, pll3_pfd3_454m, |
| 13:59 | _rmk_ | pll2_198m, pll3_120m, pll3_80m, pll3_60m, twd, step, pll1_sw, |
| 14:00 | _rmk_ | something in this very very big enum |
| 14:00 | _rmk_ | I'm not going to sit and count the fscking thing! |
| 14:00 | jnettlet | _rmk_, that is how the XO clks are as well. I am going through and breaking them out. |
| 14:01 | dv_ | jnettlet: excellent! |
| 14:02 | dv_ | jnettlet: all I need then is some dmabuf<->physaddr connection |
| 14:02 | dv_ | at least for now, until eventually the VPU library is reworked to use dmabuf fds |
| 14:02 | wumpus | so they define an enum without providing numbers, then refer to them by number, how cute |
| 14:02 | dv_ | I think _rmk_ used something similar to convert dmabuf FDs to physical addresses for BMM |
| 14:02 | wumpus | but dmabufs aren't contiguous are they? |
| 14:03 | dv_ | hm? how can a DMA buffer not be contiguous? |
| 14:03 | wumpus | I don't know, I remember robclark told me that at some point, that they're not by definition contiguous (but probably it's an option when requesting?) |
| 14:04 | _rmk_ | dv: gpu buffers can be scattered - the gpu has its own mmu |
| 14:04 | jnettlet | dv_, scatter/gather |
| 14:04 | dv_ | ah. |
| 14:04 | dv_ | yeah, its probably an option |
| 14:04 | _rmk_ | that's a very very big plus point |
| 14:04 | wumpus | yes, the gpu has an mmu, would make sense if the vpu had too |
| 14:04 | _rmk_ | it means your pixmals are very much less likely to fail on allocation |
| 14:04 | _rmk_ | pixmaps |
| 14:04 | dv_ | wumpus: perhaps, but it expects physically contiguous buffers |
| 14:05 | _rmk_ | yes, the vpu does but the gpu doesn't |
| 14:05 | wumpus | that's not always the case tho, for example ingenic jz4770 the gpu has a mmu, the ipu has a mmu, but the vpu has not :) |
| 14:05 | _rmk_ | it annoys me that the vpu is soo backwards in this regard |
| 14:05 | dv_ | _rmk_: true. only exception is the vivante direct texture extension |
| 14:06 | _rmk_ | dv: that sucks |
| 14:06 | _rmk_ | vivante fail :) |
| 14:06 | dv_ | although I am thankful for its existence. it allows me to draw fullHD videos without copy. |
| 14:06 | dv_ | I have to use the GPU, though. |
| 14:07 | dv_ | and _rmk_, I currently think bigger problems are: 1) there are three sets of allocators (VPU encoder, VPU decoder, IPU) 2) the VPU decoder framebuffer registration thing is really annoying |
| 14:08 | dv_ | oh and 3) the IPU does not have any options for framebuffer stride |
| 14:08 | dv_ | so I had to "emulate" stride by specifying the stride the framebuffer width and setting the crop rectangle to the true dimensions of the framebuffer |
| 14:39 | _rmk_ | ok, so the enet clock which Rabeeh is setting up is this one: |
| 14:39 | _rmk_ | clk[enet] = imx_clk_gate2("enet", "ipg", base + 0x6c, 10); |
| 14:39 | _rmk_ | now to figure out how to sort that in DT |
| 14:40 | _rmk_ | printk("enet = %u\n", enet); |
| 14:42 | _rmk_ | 117 |
| 14:42 | _rmk_ | which seems to be the ipg/ahb clocks to the fec |
| 15:15 | wumpus | what kind of connector am I supposed to attach to get serial on the carrier one hardware? I have a usb to 3.3v serial converter but no way to attach it |
| 15:15 | jnettlet | wumpus, did you ever get an XO? |
| 15:16 | _rmk_ | wumpus: I just rigged something up with the XO's USB to 3.3v serial converter |
| 15:17 | jnettlet | they actually make a usb to serial with breadboard female connectors to use the the RPi. |
| 15:19 | jnettlet | wumpus, and if you didn't get an XO let me know and we may be able to round up an XO-4 for you. |
| 15:19 | jnettlet | dv_, that goes for you also. ^ I can't promise anything but will try my best. |
| 15:20 | wumpus | jnettlet: nope, don't have one yet |
| 15:21 | jnettlet | wumpus, okay can you email me your shipping address and phone number. I will forward that over and see if they have any developer machines left to ship out. |
| 15:23 | wumpus | jnettlet: which email? |
| 15:23 | jnettlet | [email protected] |
| 15:24 | wumpus | ok thanks |
| 15:25 | jnettlet | dv_, that goes for you to. same info if you want me to try and get you an XO-4 for testing. |
| 15:27 | jnettle | 15:27 * jnettlet knows _rmk_ and rabeeh already have them. |
| 15:33 | jnettle | 15:33 * jnettlet is off to do shopping. |
| 15:54 | _rmk | 15:54 * _rmk_ wonders if Rabeeh did use the v4.0.0 or v4.1.0 as a base for the kernel |
| 16:06 | _rmk_ | okay, I think this calls for getting the scope out and finding the pin connections for the 8035 |
| 16:27 | _rmk_ | ok, the ar8035 is generating the clock, but its not getting a transmit clock back |
| 16:47 | wumpus | http://imx.solid-run.com/wiki/index.php?title=Carrier-One_Hardware what do they mean with "the one towards the micro-USB connector"... as I see it on the picture pin 2 seems to be the one in the corner, and 1 is closer to the USB connector |
| 16:50 | _rmk_ | yes, it is |
| 16:51 | _rmk_ | pin 2 is right on the board corner |
| 16:52 | _rmk_ | wumpus: https://lh6.googleusercontent.com/-cbxZuFUdEfQ/UkRSpMae3UI/AAAAAAAAABs/SWMWWW7SeOw/w922-h692-no/IMG_1447-sc.JPG |
| 16:52 | wumpus | thanks |
| 16:52 | wumpus | is there supposed to be any serial output without a sdcard in it? |
| 16:53 | _rmk_ | there won't be |
| 16:53 | wumpus | or at least, a valid one |
| 16:53 | wumpus | heh okay |
| 16:53 | _rmk_ | it needs the card with uboot on to produce anything |
| 16:53 | _rmk | 16:53 * _rmk_ needs to ask Rabeeh questions about ethernet |
| 16:53 | _rmk_ | like... where does the transmit clock come from |
| 16:53 | dv_ | wumpus: interesting (about the XO) |
| 16:53 | dv_ | err |
| 16:54 | dv_ | jnettlet: |
| 16:54 | _rmk_ | because the AR8035 says its an input and so does the IMX6 |
| 16:54 | dv_ | jnettlet: I will follow up soon. |
| 16:54 | dv_ | now, I gotta go. ttyl |
| 17:04 | jnettlet | dv_, no problem |
| 17:04 | jnettlet | it will benefit the project if everyone in this group has one. |
| 17:11 | _rmk | 17:11 * _rmk_ adds to the top of drivers/pinctrl/pinctrl-imx.c... |
| 17:11 | _rmk_ | #undef dev_dbg |
| 17:11 | _rmk_ | #define dev_dbg dev_info |
| 17:33 | jnettlet | _rmk_, I know it worked, but that is the most unclear pin connector example pic. |
| 17:33 | _rmk_ | it seems to work for some stuff but not everything |
| 17:35 | jnettlet | dv_, wumpus, everything is all set. Just need your info. |
| 17:58 | _rmk_ | right, getting packets on the network now but they're trash |
| 19:33 | dv_ | so. for the carrier one, do I use the imx kernel from git.freescale.com ? |
| 19:33 | dv_ | (i wanna try out freescale's imx kernel first9 |
| 19:34 | dv | 19:34 * dv_ too wonders if rabeeh based the uImage on 4.0.0 or 4.1.0 |
| 19:44 | _rmk_ | dv: the wiki says 4.1.0 but I'm wondering if that's a mistake |
| 19:50 | _rmk | 19:50 * _rmk_ thinks about getting the frequency counter out and checking the tx clock fed back to the phy. |
| 20:40 | _rmk_ | *GAH* |
| 20:40 | _rmk_ | jnettlet: I don't think the patches correspond with the kernel binary |
| 20:41 | _rmk_ | jnettlet: the ethernet clock needs to be 66MHz not 50MHz for gigabit to work |
| 20:41 | _rmk_ | so if you look in patch 2 where it gets the enet.0 clock, this fails on FSL BSP 4.1.0 |
| 20:42 | _rmk_ | but... Rabeeh's kernel boots without that warning |
| 20:42 | _rmk_ | s/warning/error/ |
| 20:42 | _rmk_ | so I don't think that bit of code is even in the kernel binary |
| 20:44 | _rmk | 20:44 * _rmk_ pulls out a lot of debugging |
| 21:08 | jnettlet | _rmk_, oh that would make sense.. |
| 21:09 | _rmk_ | http://www.home.arm.linux.org.uk/~rmk/cubox/0001-ARM-imx-initial-IMX6-Cubox-i-carrier-1-support.patch |
| 21:09 | _rmk_ | In honour of my "pintctrl-names" typo, I now declare it to be Beer O'clock |
| 21:10 | jnettlet | haha...excellent. |
| 21:30 | _rmk_ | yay, extracted rabeeh's initramfs image |
| 21:37 | Juggie | will the shipping version of cubox-i have a mini pci-e? |
| 21:39 | Juggie | or is that slot occupied by bluetooth/wifi card? |
| 21:41 | _rmk_ | I think that's a question for Rabeeh who doesn't seem to be responding today |
| 21:44 | Juggie | k, i thought some ppl had dev boards |
| 21:44 | Juggie | so i was just curious |
| 21:45 | Juggie | mostly curious if there was any way around the gbit limitation due it it being on the usb bus |
| 21:46 | _rmk_ | the dev boards are that - they're in Raspberry Pi format rather than the 2x2x2 format |
| 21:48 | Juggie | right |
| 21:48 | Juggie | web page mentions possible use as a nas |
| 21:48 | Juggie | which would be great |
| 21:48 | Juggie | but the limitation of gbit due to being on usb bus |
| 21:48 | Juggie | is a downer |
| 21:49 | _rmk_ | people keep jumping to that conclusion... its directly register addressible so it can't be on a usb bus :) |
| 21:50 | Juggie | why the limitation @ 470mbit i wonder |
| 21:51 | _rmk_ | 470mbit is the theoretical limitation according to the manual I have on the chip, measured is 400mbit for rx+tx combined |
| 21:52 | _rmk_ | "The |
| 21:52 | _rmk_ | actual measured performance in an optimized environment is up to 400 Mbps. See |
| 21:52 | _rmk_ | erratum ERR004512 in the device silicon errata document. |
| 21:52 | _rmk_ | what it actually is on this hardware is yet to be determined by folk with their dev boards |
| 21:53 | dv__ | _rmk_: do you know http://boundarydevices.com/i-mx6-ethernet/ ? |
| 21:54 | shesselba | _rmk_: almost twice as fast as Dove's GBE ;) |
| 21:57 | _rmk_ | # uname -a |
| 21:57 | _rmk_ | Linux buildroot 3.12.0-rc1+ #21 SMP Fri Sep 27 20:33:13 BST 2013 armv7l GNU/Linu |
| 21:57 | _rmk_ | x |
| 21:57 | _rmk | 21:57 * _rmk_ finally has a shell under a recent kernel :) |
| 22:03 | shesselba | hmm, I looked up my GRO tests with Dove's GBE again, actually it can do ~670Mbps .. slightly faster than I remembered ;) |
| 23:28 | _rmk_ | shame rabeeh hasn't revealed where the reset connections are |
| 23:38 | dv_ | the 2x4 pins to the left of the HDMI connector are for UART, right? |
| 23:43 | _rmk_ | no |
| 23:45 | _rmk_ | http://imx.solid-run.com/wiki/index.php?title=Carrier-One_Hardware |
| 23:45 | _rmk_ | the photo is correct |
| 23:45 | dv_ | oh |
| 23:45 | dv_ | right, I forgot the wiki has been updated |
| 23:45 | dv_ | bah, I am way too tired, cant think straight. best strategy: go to bed. |
| 23:45 | _rmk_ | you need to talk using 3.3v logic levels not rs232 levels |
| 23:45 | _rmk_ | probably :) |
| 23:46 | dv_ | ttyl |