| 00:00 | rabeeh | BenQ monitor? |
| 00:00 | dv_ | yes |
| 00:00 | rabeeh | so edid is there |
| 00:00 | dv_ | yeah |
| 00:01 | dv_ | I will try the device with a direct hdmi connection tomorrow |
| 00:02 | rabeeh | what does your kernel log say? |
| 00:02 | rabeeh | basically the hdmi phy is configured differently when using dvi sink |
| 00:03 | dv_ | http://pastie.org/private/uidlarqneodzytz5h7ugkq |
| 00:03 | rabeeh | the voltage levels are different |
| 00:03 | rabeeh | shesselba_away knows those by heart |
| 00:03 | dv_ | (I was restarting X several times, that explains the last few lines I guess) |
| 00:09 | rabeeh | oh; so you are running with X |
| 00:09 | rabeeh | is it with the Xorg driver? or the fbdev? |
| 00:09 | dv_ | fbdev |
| 00:09 | dv_ | the framebuffer console already starts with 640x480 |
| 00:09 | rabeeh | so xrandr wouldn't give too much |
| 00:10 | dv_ | yeah |
| 00:10 | dv_ | also, /sys/class/graphics/fb0/modes contains: |
| 00:11 | dv_ | U:800x600p-56 |
| 00:11 | dv_ | V:640x480p-60 |
| 00:11 | dv_ | V:640x480p-60 |
| 00:16 | dv_ | but i'm tired. goodnight |
| 00:16 | rabeeh | goodnight |
| 00:18 | _rmk_ | rabeeh: we'll see what the imx guys come back with wrt keeping GPR1 bit 21 clear, but I'm not hopeful that they'll agree to do it for the carrier-1 |
| 00:23 | rabeeh | _rmk_: fabio got his board today |
| 00:24 | rabeeh | fabio the dev the is responding to you on your thread |
| 00:25 | rabeeh | the way it should work is as follow; for RGMII - |
| 00:25 | rabeeh | 1. configure pll8 to 25MHz |
| 00:25 | rabeeh | 2. enable gpr1[21] |
| 00:26 | rabeeh | 3. enable gpio_16 only to output clock |
| 00:26 | rabeeh | 4. set reset strap pull ups and down and release ar8035 phy reset |
| 00:27 | rabeeh | from that point you should get a clock coming in to ar8035 phy; then the phy will generate the 125MHz and feed it back to the i.mx6 via the enet_ref_clk |
| 00:27 | rabeeh | enet_ref_clk mentioned here is the pad itself (ball V22 on the i.mx) |
| 00:27 | rabeeh | for the RMII it's different story; it should be as follows - |
| 00:28 | rabeeh | 1. configure pll8 to 50MHz |
| 00:28 | rabeeh | 2. enable gpr1[21] |
| 00:28 | rabeeh | 3. enable gpio_16 to output clock and it's SION bit to feed the enet internally |
| 00:28 | rabeeh | 4. set reset strap pull ups and down and release ar8030 phy from reset |
| 00:29 | _rmk_ | ok, so your patch set you published for this is wrong then, because it mixes all that up |
| 00:29 | rabeeh | so you can see that both has GPR1 bit21 set |
| 00:29 | rabeeh | _rmk_: yes. it's partial patch |
| 00:29 | rabeeh | for now all the boards that were sent has RGMII and has also the crystal osc |
| 00:29 | rabeeh | so none of the above is really needed |
| 00:30 | rabeeh | it's only optimization for bill of material; i.e. lower cost CuBox-i :) |
| 00:31 | rabeeh | the only important thing about the patch is item #4 - set the reset strap correctly and then release the phy reset |
| 00:31 | _rmk_ | why then do you go to all the extent of programming the 8035 to putput a clock? |
| 00:31 | _rmk_ | hang on, are you talking about a different set of patches now? |
| 00:31 | _rmk_ | the one I'm using as a reference is this one: |
| 00:31 | _rmk_ | 0002-SolidRun-Carrier-One-board-support.patch |
| 00:32 | rabeeh | there aren't other patches |
| 00:33 | _rmk_ | okay, so I go back to my original question: why do you program the 8035 to output a 125MHz clock from CLK_25M? |
| 00:33 | rabeeh | the most important thing in that patch to get the phy running is the 'mx6dl_ar8035_phy' structure |
| 00:34 | rabeeh | to get the RGMII working the PHY must provide the clock |
| 00:34 | rabeeh | so the phy gets via the crystal 25MHz; and generates 125MHz |
| 00:35 | rabeeh | that 125MHz is feed back to the i.mx6 via the ENET_REF_CLK pad; and then that ref clock is used for gig TX |
| 00:35 | _rmk_ | so that isn't going to GPIO 16 at all? |
| 00:36 | rabeeh | today it's not using since we have an external 25MHz crystal that is feeding ar8035 |
| 00:36 | rabeeh | in our labs we have boards that uses GPIO 16 to feed the ar8035 phy with that 25MHz; that is then used to generate the 125MHz |
| 00:36 | _rmk_ | ah, right, that's what I was missing :) |
| 00:37 | rabeeh | we measured long term jitter of the i.MX6 and we found it to be even better than the crystal osc |
| 00:38 | rabeeh | so; the 25MHz clock feed to the ar8035 is excellent; and due to that the 125MHz generated by the phy and feedback to the i.MX6 would be excellent too |
| 00:38 | rabeeh | and we get about 4x4mm extra space on the SOM to add new features :) |
| 00:39 | rabeeh | actually it's a bit more; it's almost 5x5mm since we get rid of few resistors and capacitors on the way; |
| 00:39 | rabeeh | any how; _rmk_ if you have a feature that needs to be added to the microSOM please let me know; you have pure 5x5mm to do what ever you wanted with :) |
| 00:42 | _rmk_ | so, just to be clear, on our existing hardware, GPIO 16 is not connected to anything, right? |
| 00:42 | rabeeh | nop |
| 00:43 | rabeeh | it's not |
| 00:43 | _rmk_ | apart from the not fitted 0402 resistor pads |
| 00:43 | rabeeh | exactly |
| 00:43 | rabeeh | two pads actually; one to connect to XTLI or XTLO of the ar8035 |
| 00:44 | rabeeh | if you want a good clock generator then you can use them |
| 00:44 | rabeeh | they can provide 25/50/100/125; where the 100mhz is not 50% duty cycle |
| 00:46 | _rmk_ | ok, at some point tomorrow I'll check that I have 25MHz on those 0402 pads |
| 01:13 | Bluerise | C1 is now in Italy. :o |
| 03:58 | otavio | rabeeh: will solder it before sending to Fabio; so I make his life easie |
| 04:05 | SmallwoodDR82 | how's the progress with cubox and xbmc? |
| 07:07 | purch | C1 has landed and waits for a van transport to destination :) |
| 07:09 | jnettlet | the anticipation must be killing you. |
| 07:11 | purch | this horrible flu is killing me, that dhl package may shed some light to my day |
| 09:05 | jnettlet | rabeeh, here is my initial patch against u-boot HEAD. It is still not booting, and I am not entirely sure why. I have started porting _rmk_'s ar8035 device-tree configurations into u-boot but haven't finished becaause I want to solve the booting problem first. |
| 09:05 | jnettlet | https://dl.dropboxusercontent.com/u/736509/0001-imx-mx6_c1-add-initial-support-for-c1_solo.patch |
| 09:06 | jnettlet | I am hoping you can notice something obvious and stupid I am doing. |
| 09:12 | jnettlet | I still need to fixup copyrights and such before releasing |
| 09:21 | jnettlet | woops hold on that has the wrong config file included. |
| 09:22 | jnettlet | Woohoo...it is alive. |
| 09:22 | purch | does c1 work with 5V/1200mA power if you dont use USB? |
| 09:23 | jnettlet | purch, that should be fine even with a single usb |
| 09:23 | purch | nice |
| 09:23 | purch | nokia provides power then |
| 09:27 | jnettle | 09:27 * jnettlet now needs to get a u-boot prompt on HEAD |
| 09:30 | rabeeh | jnettlet: congrats |
| 09:30 | rabeeh | purch: yes |
| 09:30 | rabeeh | but you already know that |
| 09:32 | jnettlet | rabeeh, well a lot of support and fixes for hdmi and the at8305 for the iMX.6 are going right to uboot HEAD so I figured it would be helpful to have support for the carrier boards there. |
| 09:32 | jnettlet | now that it boots I can start adding the other support back in. |
| 09:32 | rabeeh | jnettlet: any idea if there is headfull support too for i.MX6 u-boot? |
| 09:32 | rabeeh | :) |
| 09:33 | rabeeh | jnettlet: worth a blog |
| 09:33 | jnettlet | yep. hdmi should be fully supported |
| 09:33 | rabee | 09:33 * rabeeh stares at _rmk_ |
| 09:33 | jnettlet | yep will do. |
| 09:50 | _rmk | 09:50 * _rmk_ holds up a mirror :) |
| 09:52 | jnettlet | _rmk_, was wondering about a couple of values you have set in your device-tree for the ar8035. Trying to figure out where you get the pin settings for. MX6QDL_PAD_ENET_TX_EN__ENET_TX_EN 0x80000000 |
| 09:52 | _rmk_ | the final figure? |
| 09:53 | jnettlet | yep. Most the settings I see for that pin stop at bit 18. |
| 09:53 | _rmk_ | I digged through the 4.1.0 BSP and those are marked NO_PAD_CONFIG or something like that. bit 31 tells the imx pinctrl code not to set the config register |
| 09:53 | _rmk_ | I'm not entirely sure that's what we want there yet |
| 09:53 | jnettlet | ah okay. |
| 09:54 | jnettlet | that clears some things up for me. |
| 09:54 | _rmk_ | bit 30 is the SION override bit |
| 09:55 | jnettlet | great then I shouldn't be far off from getting u-boot network support going. |
| 09:57 | _rmk_ | good... so then I can stop wearing out this SD card :) |
| 09:57 | jnettlet | _rmk_, consider it mechanical testing of the push-push sd slot for rabeeh. |
| 09:58 | jnettle | 09:58 * jnettlet off to walk the dogs |
| 09:58 | _rmk_ | yep - wish the cubox had a push-push slot |
| 10:46 | MikeSeth | I just realized netbsd might run on a cubox hmmm |
| 10:49 | MikeSeth | btw, are development boards still available for sale? |
| 10:49 | MikeSeth | I'm a bit confused with the websites |
| 11:08 | jnettlet | rabeeh, have you seen this? http://otherfab.com/ It is on kickstarter right now. |
| 11:12 | jnettlet | oh kickstarter is closed. |
| 12:55 | _rmk_ | Rabeeh: from the discussion yesterday, I think you meant PLL6 not PLL8. PLL6 is the ether PLL, PLL8 is for media stuff |
| 13:11 | purch | I built c1 kernel (wiki) only modules, but no firmware stuff? |
| 13:20 | dv_ | _rmk_: PLL8 can be used for tweaking the output sample rate? |
| 13:52 | _rmk_ | dv_: I've not looked that deeply into it - the IMX6 docs size makes them quite difficult to deal with |
| 13:52 | dv_ | yeah |
| 13:53 | dv_ | its the opposite of marvell |
| 13:53 | dv_ | freescale documents too much :) |
| 13:53 | _rmk_ | and not in an easy to access way either |
| 13:53 | _rmk_ | the contents pages are too verbose |
| 13:54 | _rmk_ | those pages need their own separate search facility |
| 13:55 | _rmk_ | if I want to search for something, I get evince to start the search and then go and do something else while it tries to find all the occurances |
| 13:56 | jnettlet | _rmk_, open it up in the Google Chrome. The pdf engine is much much faster |
| 14:02 | _rmk_ | right, as a I suspected, we don't need the ENET_RX_EN..ENET_TX_EN pinctrl settings for RGMII mode |
| 14:07 | jnettlet | should the u-boot sdhc boot device be sd or mmc? |
| 14:31 | wumpus | would be better if they had split up the PDF into multiple documents with separate topics, then again, I 'm not complaining, at least there are freely available and detailed docs |
| 14:35 | lubiana | oh, the cubox is on hackernews :) https://news.ycombinator.com/item?id=6488149 |
| 14:49 | MikeSeth | if only they didn't link to that childish website |
| 14:50 | _rmk_ | and I see that site is full of people jumping to wrong conclusions |
| 14:50 | MikeSeth | ethernet over usb? LOL |
| 14:52 | _rmk_ | that's precisely why I stopped reading it |
| 14:56 | wumpus | lol hacker news |
| 15:15 | jnettle | 15:15 * jnettlet is amused by the idea of carrying around a Cubox in your pocket. |
| 15:16 | wumpus | maybe add a microphone and speaker so it can be used as phone :-) |
| 15:16 | MikeSeth | in my pocket probably not |
| 15:16 | MikeSeth | but I have a military issue key spring that might do the trick |
| 15:16 | _rmk_ | only if it has decent static protection |
| 15:16 | MikeSeth | also what cubox-i probably needs is internal lighting |
| 15:17 | MikeSeth | you could probably make it gorgeous for < $1 |
| 15:17 | wumpus | so people can wonder why you're talking into a box |
| 15:17 | jnettle | 15:17 * jnettlet almost bought the RPi case that had colored LED lighting |
| 15:17 | wumpus | yeah it needs lighting too, configurable RGB of course |
| 15:17 | jnettlet | of course |
| 15:18 | MikeSeth | there isn't any unused gpio anywhere on the board is there |
| 15:18 | jnettlet | or maybe just around the bottom so it illuminates the desk underneath it |
| 15:19 | jnettlet | well the Carrier One boards have extra gpio, but I don't think the Cubox-i does |
| 15:19 | jnettlet | hmmm. I like the idea of the lights underneath, turn them into a notification LED like on an Android phone |
| 15:21 | MikeSeth | hm |
| 15:21 | MikeSeth | you could actually make a fully fledged voip phone device from it |
| 15:21 | jnettlet | no input |
| 15:21 | jnettlet | I guess bluetooth |
| 15:21 | MikeSeth | or usb |
| 15:22 | jnettlet | true |
| 15:22 | MikeSeth | I'm dying to play with linux on arm, come on, send me my cube come ooooon |
| 15:23 | jnettlet | Linux on ARM is pretty much just like Linux on everything else :-) |
| 15:23 | Bluerise | a smartwatch! |
| 15:23 | Bluerise | ;) |
| 15:24 | Bluerise | just need to get a display and a touchscreen connected... |
| 15:25 | MikeSeth | jnettlet: yeah, except there's significant porting work to be done on userspace stuff |
| 15:25 | MikeSeth | i have a wet dream of porting e.g. sbcl on arm |
| 15:25 | MikeSeth | and reviving a lisp machine |
| 15:26 | MikeSeth | i know it's too far fetched |
| 15:26 | MikeSeth | but I still want it :P |
| 15:33 | MikeSeth | hmmm |
| 15:33 | MikeSeth | voip phone may be of little use, but asterisk on cubox |
| 15:34 | MikeSeth | near zero-cost competition to big boy PBX |
| 15:34 | MikeSeth | hmmmm |
| 15:48 | jnettle | 15:48 * jnettlet is pretty sure he wants a micro-sdhc adapter that will plug into the microsdhc slot of the board and usb port of the developer computer. with the backing storage being a ramdisk |
| 16:26 | _rmk_ | shesselba: does the "ir_recv" device in dove-cubox.dts actually work? |
| 16:27 | _rmk_ | shesselba: I've tried the same with carrier-1 and it doesn't result in any platform device being created |
| 16:27 | _rmk_ | so there's no device for gpio-rc-recv to bind to |
| 16:35 | dv_ | I wonder how this whole setup with uboot in the first sector will work with hard disks |
| 16:35 | dv_ | isnt the MBR at that location? |
| 16:37 | Juggie | mbr is an x86 thing isnt it? |
| 16:37 | Juggie | x86/x64 |
| 16:39 | dv_ | its actually a partition table format thing |
| 16:39 | dv_ | comes from x86 land, yes |
| 16:39 | dv_ | but I do not know if uboot understands GPT too |
| 16:41 | Juggie | doubt it |
| 16:42 | Juggie | ah looks like it can |
| 16:43 | Juggie | but it has to be compiled to support it |
| 16:43 | Juggie | and a kernel w/ EFI |
| 16:43 | dv_ | huh? all that should be necessary is to read the GPT, and then load the uImage from the partition |
| 16:53 | _rmk_ | dv: GPT is in sector 0, uboot is sector 2 on |
| 16:53 | dv_ | MBR is in sector 0 too? |
| 16:54 | dv_ | okay, then I confused something |
| 16:54 | dv_ | and I guess uboot 2013 can handle GPT |
| 16:54 | _rmk_ | yep, but MBR doesn't get used |
| 16:54 | dv_ | yeah, sure |
| 16:54 | dv_ | MBR is for BIOS only |
| 16:54 | jnettlet | yeah uboot reads from 0x400 |
| 16:54 | _rmk_ | uboot has been able to handle GPT for ages |
| 16:54 | dv_ | nevermind then |
| 16:54 | _rmk_ | that's how the cubox boots from SD card |
| 16:54 | jnettlet | yep |
| 16:55 | jnettle | 16:55 * jnettlet knows that all too well now |
| 16:55 | dv_ | .. doh |
| 16:55 | dv_ | I use fdisk for the sd card |
| 16:55 | dv_ | of course |
| 16:56 | dv_ | well, now that I know the obvious, I am a happier dv :) |
| 16:56 | jnettlet | that is why rabeeh was very adamant about the seek=2 skip=2 part of the dd command for u-boot |
| 17:17 | jnettlet | The default IPU clock is 25Mhz? |
| 17:36 | Juggie | how does one go about buying or getting on a list for a dev board? |
| 17:37 | Juggie | b-rad (open source wdtv firmware dev/wdlxtv) asked me after I mentioned it being available. |
| 17:52 | _rmk_ | jnettlet: any success with the SD slot card detection? |
| 17:52 | _rmk_ | jnettlet: I don't know if it's rabeeh's patch which is wrong, or DT's doing something wrong or what - it just doesn't seem to be working |
| 17:53 | _rmk_ | I'm about to switch the thing to GPIO mode and see if that makes it work |
| 17:57 | _rmk_ | okay, looks like SD controller mode for CD detection is broken or non-functional on IMX6 |
| 18:22 | Bluerise | [16:54:44] <_rmk_> dv: GPT is in sector 0, uboot is sector 2 on |
| 18:22 | Bluerise | iirc MBR is sector 0, GPT sector 1 and about 16 following sectors |
| 18:22 | Bluerise | or even more |
| 18:23 | Bluerise | depending on how many partitions are set in the header in sector 1 |
| 18:23 | Bluerise | or, LBA 1 |
| 18:36 | jnettlet | _rmk_, I am sorting out a hang bringing clocks up. |
| 18:36 | jnettlet | I was wondering about the card insertion setup though. |
| 18:53 | jnettlet | _rmk_, card detection is working. |
| 18:53 | _rmk_ | just found the problem. uboot forces DAT3 detection which is wrong if you configure DAT3 with a 22K pullup |
| 18:53 | _rmk_ | only spent 4 hours finding that crap |
| 18:56 | jnettlet | shouldn't DAT3 be configured with a pulldown? |
| 18:57 | jnettlet | DAT3 is CS pin for SPI mode. A pull-down on this pin and CMD0 may set this card into the SPI mode. |
| 18:57 | jnettlet | ^should have quotes around it. |
| 19:03 | _rmk_ | jnettlet: I need to check the specs, but... DAT3 being pulled down places the card into SPI mode its something we don't want to do. |
| 19:04 | _rmk_ | in which case this is a uboot issue - it shouldn't be enabling DAT3 insert detection for no good reason |
| 19:04 | jnettlet | _rmk_, right which is why we set it with a 22k pullup |
| 19:04 | jnettlet | or at least I am in the new uboot. Let me check the old codebase. |
| 19:07 | jnettlet | _rmk_, yeah that is a bug in the old u-boot code. I am setting it up properly |
| 19:07 | _rmk_ | pullup via 22k is fine provided you don't have this: |
| 19:07 | _rmk_ | #define PROCTL 0x0002e028 |
| 19:07 | _rmk_ | writel(PROCTL_INIT, ®s->proctl); |
| 19:08 | _rmk_ | that sets bit 3, which enables card detection via a logic 1 on DAT3 |
| 19:08 | jnettlet | I will doublecheck it isn't a default in the code. I definitely don't set that up. |
| 19:08 | _rmk_ | SD cards have a 50k pullup internally on DAT3 |
| 19:09 | _rmk_ | the definition is in include/fsl-esdhc.h and the write is in drivers/mmc/imx-esdhc.c (filenames from memory) |
| 19:09 | _rmk_ | if bit 3 is set, and DAT3 is pulled up, the controller will think a card is always inserted irrespective of the CD input |
| 19:10 | jnettlet | only bits touched in PROCTL_INIT are PROCTL_DTW_4 and PROCTL_DTW_8 |
| 19:11 | jnettlet | just setting the buswidth |
| 19:12 | _rmk_ | https://github.com/rabeeh/u-boot.imx6/blob/master/include/fsl_esdhc.h#L104 |
| 19:12 | _rmk_ | your source doesn't have that? |
| 19:12 | _rmk_ | oh yes, silly me, looking at the register location |
| 19:13 | _rmk_ | so I've still got the same problem. how the hell is bit 3 being set. |
| 19:13 | _rmk_ | # devmem 0x2194028 |
| 19:13 | _rmk_ | 0x0880022A |
| 19:14 | _rmk | 19:14 * _rmk_ is starting to really _really_ hate the IMX6 as a device |
| 19:14 | jnettlet | rofl...I think I go through this phase for almost every new device. |
| 19:15 | jnettlet | We need to write up the 7 stages of new hardware development book. |
| 19:15 | jnettlet | 1) Anticipation for the new devices |
| 19:17 | jnettlet | _rmk_, you want me to dump the hardware default pre u-boot twiddling? |
| 20:05 | _rmk_ | jnettlet: it may help. |
| 20:18 | _rmk_ | jnettlet: early on in the kernel boot, I get: PROT_CTRL = 0xff858088 |
| 20:46 | jnettlet | sorry been on a call. Dumping it now. |
| 21:17 | jnettlet | _rmk_, very different for me. 0x08800220 is the initial setting. Final configuration is 0x00800022 leaving uboot |
| 21:19 | _rmk_ | that's your uboot? |
| 21:19 | _rmk_ | power on reset is 0x08800020 according to the info I have |
| 21:21 | _rmk_ | bah, that value I printed was the status |
| 21:23 | _rmk_ | ok, that ties up with my magic number too |
| 21:43 | jnettlet | okay good |
| 21:44 | _rmk_ | looks like its the kernel driver which does it, but it uses some other name for the register |
| 21:44 | _rmk_ | "SDHCI_HOST_CONTROL" |
| 21:44 | jnettlet | of course. who needs consistency |
| 21:44 | _rmk_ | which it then proceeds to use its own definitions with |
| 21:45 | _rmk_ | don't know why they didn't just do something like this: |
| 21:45 | jnettlet | if that is happening in the MMC driver we can get fixes pushed through easy. |
| 21:45 | _rmk_ | #define TWENTY_EIGHT_HEX 0x28 |
| 21:45 | _rmk_ | :) |
| 21:46 | _rmk_ | except it looks like twiddling the D3CD bit is a work-around for another issue |
| 21:46 | _rmk_ | I suspect just switching to use GPIO mode for detection is the right answer |
| 21:47 | _rmk_ | but... lets see what Shawn says |
| 22:31 | dxtr | I love that the menu in xbmc (Geexbox) is lagging |
| 22:32 | dxtr | It's at a constant 65-70% CPU with no library |
| 22:35 | dxtr | Oh right |
| 22:36 | dxtr | Is the GPU not supported if I use hardfp? |
| 22:36 | dxtr | rabeeh: ping |
| 22:36 | dxtr | http://www.solid-run.com/phpbb/viewtopic.php?f=2&t=650 <- The last post in this topic. What is the status? |
| 22:40 | dv_ | status? |
| 22:40 | dv_ | GPU hardfp and vMeta hardfp are available |
| 22:41 | dxtr | Hmm okay |
| 22:41 | dxtr | Then it isn't that |
| 22:42 | dxtr | Then why is it using so much CPU? It even works better on the raspberry pi I have |
| 22:46 | dv_ | what was my last message? |
| 22:51 | _rmk_ | 21:40 < dv_> GPU hardfp and vMeta hardfp are available |
| 23:20 | dv_ | ok |
| 23:20 | dv_ | marvell also delivered some closed-source audio codecs, but these are softfp only |
| 23:20 | dv_ | (and are implemented purely in software) |
| 23:20 | dv_ | @dxtr |
| 23:41 | dxtr | right |
| 23:42 | dxtr | But this isn't audio related (most likely) |
| 23:43 | dxtr | Also, I just ran the cubox installer and installed XilkaX. It won't boot :p |