| 00:43 | _rmk_ | just remember, if you want to be pedantic, TTL != 3.3V. TTL was always based off 5V, and can supply above 3.3v as a logic 1. |
| 00:44 | _rmk_ | the serial pins are not 5v tolerant, so make sure the converter produces no more than 3.3v on its TXD pin |
| 01:03 | ojn | the adafruit one says: The power pin provides the 5V @ 500mA direct from the USB port and the RX/TX pins are 3.3V level for interfacing with the most common 3.3V logic level chipsets. |
| 01:04 | ojn | (we have some 1.8v serial voltage hardware here, it's quite annoying to deal with) |
| 01:05 | _rmk_ | yea, sounds perfect then. I just wanted to correct the "ttl" thing in case someone does try and connect a 5V ttl converter to the carrier-1 |
| 01:06 | _rmk_ | most "rs232 to ttl" converters today aren't actually ttl outputs but cmos outputs, which when 5V powered will give close to 5V for logic 1 |
| 01:07 | _rmk_ | talking about the chips not the boards |
| 01:07 | ojn | yeah |
| 08:52 | purch | thanks for the info, I ordered two different ones |
| 08:54 | purch | I try to remember to check the voltage first, thanks |
| 08:55 | purch | I went to buy a 5$ cable, ended with 3 shipments total ~90$ :) |
| 11:12 | jnettlet | hmmm setting the SOC to MX6DL instead of MX6S seems to be giving me most stable results. Time to see what is differnt |
| 11:15 | dv_ | arent they incompatible? |
| 11:15 | dv_ | at least between DL and Q there are significant differences |
| 11:16 | jnettlet | dv_, DL and Q are incompatible but DL and S are grouped together for a lot of configuration |
| 11:16 | dv_ | btw, any reason why DL and Q are incompatible? |
| 11:16 | jnettlet | the big difference between DL and S is S is only 32-bit DDR interface and DL is 64-bit like the Q |
| 11:16 | jnettlet | bus speeds |
| 11:17 | dv_ | ah |
| 11:17 | dv_ | right. thats also the difference between DL and D |
| 11:17 | jnettlet | at least best as I know for now. still absorbing the hardware specifics |
| 11:17 | dv_ | oh, and did you or _rmk_ notice the hardware resampler? |
| 11:18 | jnettlet | not I |
| 11:18 | dv_ | I looked a bit into it, and it seems to me it supports only a fixed set of sample rates |
| 11:18 | jnettlet | still working on getting basic functionality re-working |
| 11:18 | jnettlet | oh that does not surprise me |
| 11:18 | dv_ | still, 44100 <-> 48000 is included, which is by far one of the biggest cases |
| 11:18 | dv_ | *most common |
| 11:19 | dv_ | I guess the set is fixed because the filter coefficients are precomputed and stored in ROM |
| 11:20 | jnettlet | makes sense. I have found in most the SOC's any of the hardware resampling other than > 32k have horrible step aliasing artifacts |
| 11:20 | jnettlet | with the VFP you can do a much better job in software |
| 11:21 | jnettle | 11:21 * jnettlet is going to walk the dogs and think about graphics drivers |
| 11:21 | dv_ | yeah, but it can eat up CPU% |
| 11:22 | dv_ | especially if the conversion ratio isnt exactly nice. 96 <-> 48 => 2/1 . but 44.1 <-> 48? |
| 11:40 | Bluerise | rabeeh: I have a little problem with a customs office in Germany... |
| 11:41 | Bluerise | German customs suck. |
| 12:36 | jnettlet | dv_, yeah but the 44.1 <--> 48 is handled quite nicely with NEON. You will see slight cpu usage increase but nothing earth shaking. If I remember correctly they were testing this on the OMAP in pulseaudio last year and found using libspeex there was like a 2% cpu usage increase. |
| 12:37 | dv_ | what OMAP? what ARM CPU? how many cores? how many MHz? |
| 12:37 | jnettlet | dv_, single core 500Mhz |
| 12:37 | dv_ | with the speex resampler, it is important to disable the filter coefficient interpolation |
| 12:37 | dv_ | otherwise the CPU usage is much higher |
| 12:38 | jnettlet | well it was clocked down to 500Mhz...at least that is the number that sticks in my head |
| 12:38 | dv_ | if disabled, then yes, the CPU usage is rather low |
| 12:38 | dv_ | oh, and : what resampling quality setting? (1-10) |
| 12:39 | dv_ | at default quality level 4, with the interpolation, I saw ~20% CPU usage for 44.1<->48 on a 720Mhz AM3352 with a Cortex-A8 single ocre |
| 12:39 | dv_ | *core |
| 12:39 | jnettlet | I can't remember that. But the filter coefficient interpolation should be sped way up using NEON |
| 12:39 | dv_ | without the interpolation, it was about 4% |
| 12:40 | dv_ | the interpolation is just a memory usage optimization. it reduces the size of the filter table. not necessary on devices with 512 MB RAM. |
| 12:40 | jnettlet | if it is bicubic and static just load it into the appropriate vector registers and go. |
| 12:40 | dv_ | there was an attempt to add neon optimizations to the speex resampler. wasnt very useful. |
| 12:40 | dv_ | then again, the code might have been crap :) |
| 12:41 | dv_ | thats why the opus codec tools contain a copy of that resampler without filter interpolation. I think pulseaudio does the same. |
| 12:41 | jnettlet | or the NEON support in gcc may have been crap |
| 12:42 | dv_ | nono, this was pure assembler code |
| 12:42 | dv_ | a .s file |
| 12:43 | jnettlet | oh they weren't using intrinsics? |
| 12:43 | jnettlet | well then only review can really say how good it was. |
| 13:00 | jnettlet | Allright got things sorted. CONFIG_EXTRA_ENV_SETTINGS was too long and causing problems. Have a U-Boot 2013 cli!!! |
| 13:00 | jnettlet | need to sort out the problem. But good for me for now. |
| 13:05 | _rmk_ | :) |
| 13:05 | _rmk_ | does this mean we have a version of uboot which has network support? |
| 13:06 | jnettlet | _rmk_, enabling networking now to test. |
| 13:09 | jnettlet | Net: eth_init: fec_probe(bd, -1, 1) @ 02188000 |
| 13:11 | jnettle | 13:11 * jnettlet needs some tea before continuing |
| 13:25 | jnettlet | _rmk_, are you still on the device-tree patch for the Cubox-i? |
| 13:27 | _rmk_ | I just pushed out some rfc patches for it |
| 13:28 | jnettlet | _rmk_, do you want u-boot support for device-tree enabled? |
| 13:28 | jnettlet | or just append it to the kernel for now? |
| 13:30 | _rmk_ | I think having DT support in uboot would be the modern thing to do |
| 13:32 | jnettlet | I guess that will be phase 2, warm liquid goo phase. get the rest of the hardware working first. |
| 13:35 | _rmk_ | http://archive.arm.linux.org.uk/lurker/message/20131005.112217.aafd60f4.en.html |
| 13:35 | _rmk_ | http://archive.arm.linux.org.uk/lurker/message/20131005.112317.6e170986.en.html |
| 15:19 | _rmk_ | looks like mainline has no real support for audio on imx6 |
| 15:28 | dv_ | _rmk_: trying to go through the whole asoc thing again? :) |
| 15:29 | _rmk_ | dv_: urgh |
| 15:29 | _rmk_ | dv_: hopefully the imx people will get that sorted and all I'll have to do is the DT bits |
| 15:30 | dv_ | yeah, they anyway seem to be trying to mainline their patches |
| 15:30 | _rmk | 15:30 * _rmk_ wishes this buildroot image would dhcp an ip address |
| 15:31 | dv_ | that was quite inconvenient, yes |
| 15:31 | dv_ | at least its running dropbear |
| 15:31 | _rmk_ | and I kind'a wish it didn't generate a ssh key on every boot |
| 15:32 | dv | 15:32 * dv_ is wondering why the VPU encoder ignores the GOP size setting |
| 15:33 | jnettlet | people seem very confused how get_phy_driver is supposed to work. |
| 15:34 | jnettlet | none of these masks / ids are consistent |
| 15:35 | dv_ | overall, it shows the VPU IP was bought in, and has been designed to be usable for Windows CE as well |
| 15:39 | dv_ | anyway, need to shop. later |
| 15:39 | _rmk_ | okay, that's as far as I can get with audio support in DT at the moment |
| 15:39 | _rmk_ | imx-spdif sound-spdif.16: ASoC: CPU DAI (null) not registered |
| 15:39 | _rmk_ | imx-spdif sound-spdif.16: snd_soc_register_card failed: -517 |
| 15:39 | _rmk_ | platform sound-spdif.16: Driver imx-spdif requests probe deferral |
| 16:05 | Bluerise | Hope that rabeeh shows up soon... |
| 16:10 | jnettlet | Bluerise, what is your problem? I have imported lots of hardware so may be able to help. |
| 16:10 | Bluerise | German customs is asking for an order confirmation |
| 16:10 | Bluerise | i.e. they need to find out how much the thing is worth |
| 16:10 | Bluerise | they ask for a "realistic value" |
| 16:11 | Bluerise | and ask for an order confirmation or something similar |
| 16:11 | Bluerise | or like, paypal transaction proof |
| 16:11 | jnettlet | Bluerise, It should be marked on the packaging that it is an Engineering Sample. |
| 16:12 | jnettlet | because of that there will be no order confirmation. |
| 16:12 | Bluerise | Hmm, well, I can try to argue with them about that via mail |
| 16:12 | Bluerise | yeah |
| 16:13 | jnettlet | Engineering Sample and not for sale or resale are important. |
| 16:14 | _rmk_ | Bluerise: well, you haven't ordered it so there's no order confirmation. it's a gift from the manufacturer as an engineering sample, etc. |
| 16:15 | Bluerise | I know, but it's German customs, and they suck. |
| 16:16 | jnettlet | Yep, just re-iterate the point though. And make sure to re-iterate it is not a product that can be bought or sold. |
| 16:53 | jnettlet | _rmk_, the ar8035 is hooked up as phy 4 right? |
| 16:56 | _rmk_ | let me check. it's certainly binary x00, just a matter of what the x is |
| 16:56 | _rmk_ | I assume you got the reset GPIO sorted, along with the pull ups/downs to set the config? |
| 16:58 | jnettlet | _rmk_, I believe so. If you want to give it a quick lookover. |
| 16:59 | jnettlet | http://fpaste.org/44486/38098517/ |
| 17:01 | _rmk_ | okay, LED_ACT is active high to light the LED, which implies that LED_ACT is pulled low. |
| 17:01 | _rmk_ | so that makes it 000 |
| 17:01 | _rmk_ | fec 2188000.ethernet eth0: Freescale FEC PHY driver [Generic PHY] (mii_bus:phy_a |
| 17:01 | _rmk_ | ddr=2188000.ethernet:00, irq=-1) |
| 17:02 | jnettlet | hmmm |
| 17:05 | jnettlet | ah okay. Nope 000 is correct. I have link. Just need to get the hwaddress out of the fuse. |
| 17:05 | jnettlet | then we should be good to go. |
| 17:08 | dxtr | Okay, seriously. Why should it be so hard to get xbmc working? |
| 17:08 | dxtr | "xbmc needs hardware accelerated opengl rendering" |
| 17:09 | dxtr | I thought the cubox had that? I've installed all the appropriate drivers |
| 17:10 | _rmk | 17:10 * _rmk_ enables AT803x phy support in his kernel |
| 17:10 | jnettlet | dxtr, the xbmc image from the cubox installer should have that all setup. |
| 17:10 | dxtr | jnettlet: You meen geexbox? |
| 17:11 | dxtr | Guess I'll have to try that one from the installer |
| 17:11 | dxtr | I tried geexbox but.. Yeah.. It didn't work good |
| 17:11 | jnettlet | yep |
| 17:11 | dxtr | The menus lagged.. A lot :P |
| 17:12 | jnettlet | dxtr, well we are working on getting the new drivers out. I am almost done integrating a bunch of patches to the newest Vivante driver release. It will be out by Wed at the latest. |
| 17:14 | _rmk_ | much better :) |
| 17:14 | _rmk_ | fec 2188000.ethernet eth0: Freescale FEC PHY driver [Atheros 8035 ethernet] ( |
| 17:14 | _rmk_ | mii_bus:phy_addr=2188000.ethernet:00, irq=-1) |
| 17:16 | jnettlet | _rmk_, that matches me. Have you run across how the kernel is getting the MAC address? |
| 17:17 | _rmk_ | link/ether d0:63:00:00:00:00 brd ff:ff:ff:ff:ff:ff |
| 17:17 | _rmk_ | let me see where it gets that from |
| 17:18 | tomlohave | @dxtr : devel or 3.0 |
| 17:18 | tomlohave | ? |
| 17:18 | _rmk_ | hmm. |
| 17:19 | _rmk_ | my uboot says this: |
| 17:19 | _rmk_ | Net: FEC0: rxbd 27602900 txbd 27602940 ->27602980 |
| 17:19 | _rmk_ | got MAC address from IIM: d0:63:00:00:00:00 |
| 17:19 | jnettlet | that doesn't look like a real MAC address to me |
| 17:19 | _rmk_ | I'm guessing that the kernel just reads that back out from the FEC registers |
| 17:19 | jnettlet | which u-boot isn't setting up |
| 17:20 | jnettlet | I think u-boot needs to read it from the fuse and then set it in the hardware. |
| 17:20 | jnettlet | I guess I can cheat and test setting one by hand |
| 17:21 | jnettlet | well that has the interface doing something |
| 17:22 | _rmk_ | the reset state of the address registers is all zeros though |
| 17:22 | _rmk_ | it amazes me when I see code like this... |
| 17:23 | _rmk_ | * try to get mac address in following order: |
| 17:23 | _rmk_ | * 1) module parameter via kernel command line in form |
| 17:23 | _rmk_ | * fec.macaddr=0x00,0x04,0x9f,0x01,0x30,0xe0 |
| 17:23 | _rmk_ | iap = macaddr; |
| 17:23 | _rmk_ | ... |
| 17:23 | _rmk_ | /* Adjust MAC if using macaddr */ |
| 17:23 | _rmk_ | if (iap == macaddr) |
| 17:23 | _rmk_ | ndev->dev_addr[ETH_ALEN-1] = macaddr[ETH_ALEN-1] + fep->dev_id; |
| 17:24 | _rmk_ | its entirely legal for a mac address to be a per-host thing rather than per-interface - ISTR Alan Cox telling me that Sun did that |
| 17:25 | _rmk_ | let me put some debugging in here so I can see where the kernel is reading it from |
| 17:29 | jnettlet | hmmm. I am seeing the interface light blinking but ping is failing |
| 17:30 | _rmk_ | fec 2188000.ethernet (unregistered net_device): Using MAC address d0:63:00:00:00:00 from fec mac registers |
| 17:30 | _rmk_ | okay, do you have it plugged into a gigabit or fast switch? |
| 17:31 | jnettlet | gigabit |
| 17:32 | _rmk_ | the ipg/ahb clock is 66MHz rather than 50MHz? |
| 17:33 | jnettlet | IPG PERCLK 66000 kHz |
| 17:33 | jnettlet | and IPG 66000 kHz |
| 17:34 | _rmk_ | ok, iomuxc settings... |
| 17:34 | _rmk_ | RX_CTL pin, rd1, and rd0 all need to be programmed to be pull-down |
| 17:35 | _rmk_ | rd3, rd2 and rxc all need to be pull-up |
| 17:35 | jnettlet | yep |
| 17:35 | jnettlet | are the enet mux settings. Pretty much duping your device tree. http://fpaste.org/44486/38098517/ |
| 17:36 | _rmk_ | gpio4 io15 is the reset - you're pulling that low for 2ms and then raising? |
| 17:37 | jnettlet | 10ms |
| 17:38 | _rmk_ | more than enough :) |
| 17:38 | jnettlet | static void setup_iomux_enet(void) |
| 17:38 | jnettlet | { |
| 17:38 | jnettlet | gpio_direction_output(IMX_GPIO_NR(4, 15), 0); |
| 17:38 | jnettlet | imx_iomux_v3_setup_multiple_pads(enet_pads, ARRAY_SIZE(enet_pads)); |
| 17:38 | jnettlet | udelay(1000 * 10); /* Wait 10 ms before reset */ |
| 17:38 | jnettlet | gpio_set_value(IMX_GPIO_NR(4, 15), 1); |
| 17:38 | jnettlet | udelay(100); /* Wait 100 us before using mii interface */ |
| 17:38 | jnettlet | } |
| 17:38 | jnettlet | right? |
| 17:38 | _rmk_ | assuming that udelay can wait 10ms, yes. |
| 17:39 | _rmk_ | you're enabling the 125MHz clock out on the 8035? |
| 17:40 | jnettlet | let me double check, but I think the generic ar8035 code does that now. |
| 17:42 | jnettlet | yep the ar8035_config code does that. I added your patch that disables the SmartEEE. Let me comment that out quick. |
| 17:45 | _rmk_ | hmm, the pinmux settings with the 0x80000000 and 0xc0000000 may not be correct |
| 17:45 | _rmk_ | bits 31,30 are a kernel thing - I think the FSL BSP used different stuff for those |
| 17:46 | _rmk_ | I'd assume that MX6_PAD_GPIO_16__ENET_ANATOP_ETHERNET_REF_OUT sets the SION bit (the mux setting should be 0x12 for that - sion being bit 4) |
| 17:46 | jnettlet | okay that is why I was asking about it the other day. They didn't seem right. |
| 17:46 | _rmk_ | does uboot have a "NO_PAD_CTRL" thing like the FSL BSP does? |
| 17:47 | jnettlet | yep |
| 17:47 | jnettlet | use that for those three? |
| 17:47 | _rmk_ | yea |
| 17:48 | _rmk_ | if you want to translate the 0xa0b1 too... that's (let me look it up) |
| 17:48 | _rmk_ | PAD_CTL_PUS_100K_UP | PAD_CTL_PUE | PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_SRE_FAST |
| 17:49 | _rmk_ | just in case for some perverse reason uboot has different bit definitions :p |
| 17:50 | jnettlet | yeah I need to rewrangle that because PAD_CTL_PUS_100K_UP always ors PAD_CTL_PUE which ors PAD_CTL_PKE |
| 17:51 | jnettlet | there is a patch that says it is required by spec. |
| 17:55 | _rmk_ | oh, GPR1 bit 21 |
| 17:56 | jnettlet | oh that is required? |
| 17:57 | jnettlet | is setting HW_ANADIG_PLL_ENET to 0x20000 also required? |
| 17:58 | _rmk_ | yes, the GPR1 bit is needed |
| 17:59 | jnettlet | but not the clock twiddling? |
| 18:00 | _rmk_ | HW_ANADIG_PLL_ENET is what they refer to as CCM_ANALOG_PLL_ENETn in the manual... |
| 18:01 | _rmk_ | I don't think that's required on current hardware |
| 18:01 | jnettlet | I think that is the same as BM_ANADIG_PLL_ENET which is used to setup the fec_anatop_clock |
| 18:02 | jnettlet | that is broken out into the generic mx6 clock code |
| 18:02 | _rmk_ | do you have the physical address for HW_ANADIG_PLL_ENET ? |
| 18:02 | jnettlet | 0x000000e0 |
| 18:03 | _rmk_ | sounds like an offset from 0x020c8000 :) |
| 18:03 | jnettlet | is the GPR1 bit 21 part of the mux setup or board setup? |
| 18:04 | _rmk_ | its part of IOMUXC but I don't think it can be set via the pin mux tables |
| 18:05 | _rmk_ | hmm, I need to fix my setting of that PLL_ENET register |
| 18:06 | _rmk_ | anyway, as long as the crystal is fitted, the PLL_ENET settings don't matter |
| 18:07 | jnettlet | okay. my dogs are revolting. I will get back to this. very very close. |
| 18:07 | _rmk_ | heh :) |
| 18:07 | jnettlet | ttyl |
| 18:13 | purch | any ubuntu sd images yet for c1? |
| 18:14 | _rmk_ | don't know - the existing armhf stuff from ubuntu should work because the imx6 is "just another armv7 cpu" |
| 18:14 | _rmk_ | its more the peripherals such as audio/video which are likely to be problematical |
| 18:15 | purch | , well until I get the uart-usb cable I cant do anything |
| 18:15 | _rmk_ | yea, unfortunately rabeeh's uboot really needs to be talked to via serial |
| 18:16 | purch | yeah |
| 18:18 | _rmk_ | hopefully with jnettlet's work we can have a uboot which boots from network and/or can be configured, which can then be shipped in a state where it can be used to bring up a kernel, mount a SD card rootfs which dhcp's for networking and has a ssh daemon on it... which makes serial less of a hastle for people |
| 18:20 | _rmk | 18:20 * _rmk_ wonders what the absolute maximum input voltage is for the AR8035 XTLI pin |
| 18:21 | purch | is it possible to configure uboot before "make" to do few commands automatically on boot? |
| 18:21 | purch | I have tried to find information but nothing |
| 18:22 | _rmk_ | well, there must be some way because there's quite a few uboots which do things automatically :) |
| 18:23 | Bluerise | Yes, there's a way |
| 18:23 | purch | like those fatload etc |
| 18:24 | Bluerise | There are some board config headers which I think have some define for a standard "do that" |
| 18:25 | purch | just to get ubuntu netinstaller image to start |
| 18:26 | tomlohave | @purch you cando that on include/configs/mx6solo_c1.h |
| 18:27 | _rmk | 18:27 * _rmk_ aint a uboot hacker so I'm leaving all that to jnettlet :) |
| 18:28 | purch | I try to put those 3 lines from c1 wiki page to there |
| 18:29 | tomlohave | L128 |
| 18:30 | tomlohave | http://hg.openbricks.org/openbricks/file/c852859d8940/config/platforms/arm/imx6/machines/cuboxi/packages/u-boot/patches/0001_boot_mmc.patch |
| 18:33 | purch | tftpboot :) |
| 18:33 | purch | ext2 boot partition for that |
| 18:34 | purch | first kid to bed and then beer and compiling |
| 18:48 | _rmk | 18:48 * _rmk_ sticks a fixme comment in the DT file about the clock output so it doesn't get forgotten |
| 19:10 | jnettlet | this chocolate brown ale and I are going to get networking going now |
| 19:11 | jnettlet | purch, Bluerise, http://www.denx.de/wiki/DULG/UBootScripts |
| 19:12 | Bluerise | jnettlet: But those are in the umg, right? |
| 19:12 | jnettlet | Bluerise, you write the script and then use mkimage to convert it to that format yet. |
| 19:13 | Bluerise | Exactly. |
| 19:13 | Bluerise | that means you need a serial console to be able to transfer and run the script |
| 19:14 | jnettlet | my default env is now set to boot off mmc0 and if that fails try a netbook |
| 19:14 | jnettlet | I will probably tweak that a bit after I get more devices working. |
| 19:15 | _rmk_ | ooh, Rob Clark looks like he may assist with HDMI |
| 19:16 | jnettlet | _rmk_, oh I am just getting a 100Mbps link |
| 19:16 | _rmk_ | jnettlet: to a gigabit switch? |
| 19:16 | jnettlet | yep |
| 19:17 | _rmk_ | hmm, did it do that with Rabeeh's uboot? |
| 19:17 | _rmk_ | I think the phy comes up with Rabeeh's |
| 19:17 | _rmk_ | let me check that... |
| 19:18 | _rmk_ | yep, and for me comes up with a gigabit connection |
| 19:18 | _rmk_ | but only after its dropped to the prompt |
| 19:19 | jnettlet | actually there is confusion my switch says gigabit but mii in u-boot reports 100Mbps |
| 19:20 | _rmk_ | hmm |
| 19:20 | _rmk_ | MX6SDL SABRESD U-Boot > mii info |
| 19:20 | _rmk_ | |
| 19:21 | jnettlet | yeah I think rabeeh said networking was a wip |
| 19:21 | jnettlet | => mii info |
| 19:21 | jnettlet | PHY 0x00: OUI = 0x1374, Model = 0x07, Rev = 0x02, 100baseT, FDX |
| 19:23 | _rmk_ | can you read register 10 ? |
| 19:25 | _rmk_ | and 0x11 |
| 19:25 | jnettlet | 0x10 = 0862 |
| 19:25 | jnettlet | 0x11 = bc50 |
| 19:26 | jnettlet | wait maybe that isn't right |
| 19:26 | _rmk_ | bc50 = gigabit full duplex |
| 19:26 | _rmk_ | register 10 was 0x0a btw :) |
| 19:27 | _rmk_ | but 0x11 is fine because that's what its resolved to do |
| 19:27 | jnettlet | duh sorry |
| 19:28 | jnettlet | 2800 |
| 19:29 | _rmk_ | hmm. that seems to say "remote receiver ok, link partner 1000 full duplex capable, not half duplex capable" |
| 19:31 | jnettlet | that seems reasonable |
| 19:31 | _rmk_ | unless uboot reads from 0x11, it won't know about the gigabit stuff |
| 19:32 | _rmk_ | mii-tool for me reports 100basetx-fd despite using gigabit |
| 19:32 | jnettlet | do you have both the link and act lights lit up? |
| 19:32 | jnettlet | I only have act on and blinking occasionally |
| 19:32 | _rmk_ | my board doesn't have the link led |
| 19:33 | _rmk_ | ah a rob clark :) |
| 19:33 | robclark | hi _rmk_ |
| 19:33 | jnettlet | mine doesn't either. how about that |
| 19:33 | _rmk_ | and yes, the act led will blink on any network activity the phy sees |
| 19:34 | robclark | _rmk_, I guess I'll just search gmail for patches sent recently by you when I get my board and figure out what I need.. I think I'm subscribed to all the right lists |
| 19:34 | jnettlet | okay that all seems okay then. tcpdump isn't showing any arps on the switch either |
| 19:34 | _rmk_ | jnettlet: want to throw me a binary I can try? |
| 19:34 | jnettlet | _rmk_, sure |
| 19:35 | jnettlet | do you want debug output or not? |
| 19:35 | _rmk_ | robclark: if you find this message id, they should be threaded with this one: [email protected] |
| 19:35 | robclark | ok, perfect |
| 19:35 | _rmk_ | jnettlet: debug may be useful |
| 19:36 | _rmk_ | robclark: did you take on the "embedded drm" maintainership? |
| 19:36 | robclark | not really officially, but I try to help embedded drm along |
| 19:37 | robclark | I mean, I'm not sure if there is much value, vs. just getting in the way, to having a drm-arm tree |
| 19:38 | _rmk_ | just wondering if its worth having another go with the armada drm stuff - I eventually got back to moving that header file hopefully to a place airlied will be happy with, which I think was the only reason for it being rejected |
| 19:39 | jnettlet | _rmk_, https://dl.dropboxusercontent.com/u/736509/u-boot.imx you need to use dd if=u-boot.imx of=/dev/sdx bs=512 seek=2 conv=sync |
| 19:39 | robclar | 19:39 * robclark not terribly excited about the expose-paddr stuff.. vs just fixing up other drivers to work w/ dmabuf.. (was that still an issue, maybe I lost track?) |
| 19:39 | _rmk_ | I got rid of the paddr stuff before the last submission |
| 19:39 | robclark | although, with an upstream etnaviv driver, that is one less place where paddr needed |
| 19:39 | jnettlet | no skip with the new .imx images |
| 19:40 | robclark | ahh, ok |
| 19:40 | _rmk_ | jnettlet: grabbing... |
| 19:40 | robclark | yeah, I guess I should look more closely at your last submission (unless there is another one coming in near future) |
| 19:41 | robclark | but without paddr, I'd be in favor of merging |
| 19:41 | jnettlet | then use setenv ethaddr to give yourself a mac address |
| 19:41 | _rmk_ | it's now in a git tree I marked as unstable - http://ftp.arm.linux.org.uk/cgit/linux-cubox.git/ |
| 19:41 | robclar | 19:41 * robclark looks |
| 19:41 | _rmk_ | git url is likely something like git://git.arm.linux.org.uk/~rmk/linux-cubox.git/ with an appropriate branch name |
| 19:42 | jnettle | 19:42 * jnettlet will be pushing his git-tree with mmp2/3 patches later this week. |
| 19:43 | dv_ | _rmk_: btw, how do you do the bmm<->dmabuf conversion in your patched driver? |
| 19:47 | _rmk_ | jnettlet: hmm, I think congratulations are in order |
| 19:48 | jnettlet | _rmk_, it is working for you? |
| 19:48 | _rmk_ | => dhcp |
| 19:48 | _rmk_ | BOOTP broadcast 1 |
| 19:48 | _rmk_ | DHCPHandler: got packet: (src=67, dst=68, len=308) state: 3 |
| 19:48 | _rmk_ | TRANSITIONING TO REQUESTING STATE |
| 19:48 | _rmk_ | DhcpSendRequestPkt: Sending DHCPREQUEST |
| 19:49 | robclark | _rmk_, looks pretty good from a quick look. Minor suggestions: I'd probably just add drm_crtc_find()/drm_encoder_find() in drm_crtc.h directly.. and armada_ioctl.h should probably be in include/uapi/drm.. |
| 19:49 | robclark | I suppose I'll probably end up adding a drm_connector_find() for the atomic modeset stuff I'm just working on |
| 19:50 | _rmk_ | yea, armada_ioctl.h should live in somewhere userspace can see |
| 19:50 | _rmk_ | jnettlet: for some reason the usb serial ends up dropping some stuff :( |
| 19:50 | jnettlet | hmmm what is wrong with my setup then ****grrrrr* |
| 19:51 | _rmk_ | jnettlet: I'll try it on a 100mbit switch after food |
| 19:51 | _rmk_ | robclark: thanks for looking, I'll see about moving some of that then. |
| 19:51 | jnettlet | sounds good. I think dinner is also ready |
| 19:51 | robclark | no prob |
| 20:10 | _rmk_ | jnettlet: just checked something... cycled the power, and it doesn't work |
| 20:14 | _rmk_ | but nothing on GTX_CLK to the phy |
| 20:15 | _rmk_ | you are getting the 125MHz clock out of CLK_25M though into the IMX6 |
| 20:25 | _rmk_ | jnettlet: yes, missing TX_CLK |
| 20:29 | _rmk_ | check settings for RGMII_TXC on the imx6 |
| 20:31 | _rmk_ | also check that RCR bit 6 is being set for RGMII mode |
| 20:32 | _rmk_ | bit 8 should be clear too |
| 21:16 | jnettlet | _rmk_, will do |
| 22:21 | jnettlet | #define FEC_RCNTRL_RGMII 0x00000040 |
| 22:21 | jnettlet | so that should be fine |
| 22:23 | jnettlet | TX_CLK seems fine. |
| 22:26 | _rmk_ | hmm. given that it works if I don't power cycle, that suggests its a register which isn't being written |
| 22:30 | jnettlet | yep |
| 22:32 | jnettlet | _rmk_, does this need to happen? REG_WR(ANATOP_BASE_ADDR, HW_ANADIG_PLL_ENET, 0x00002000); |
| 22:33 | jnettlet | I just looked again and that clock code is only be called for the sololite, MX6SL not MX6S |
| 22:33 | jnettlet | so I am missing that step. |
| 22:34 | _rmk_ | that will be needed when the imx6 supplies 25MHz to the 8035 |
| 22:34 | _rmk_ | but as the 8035 has its own crystal at the moment... |
| 22:35 | jnettlet | ah right. not necessary yet |
| 22:36 | jnettlet | and gpr1 bit 21 should be set to 0 right? the current uboot code says to clear the bit but then sets it to 1 |
| 22:36 | _rmk_ | set to 1 |
| 22:36 | jnettlet | okay |
| 22:36 | jnettlet | yes I should look at the docs, but you are indexed much faster :-) |
| 22:36 | _rmk_ | :) |
| 22:37 | dv_ | hehe |
| 22:38 | dv | 22:38 * dv_ 's head aches from the whole annex.b vs. avcc and access units differences |
| 22:39 | dv_ | _rmk_, I can see why reassembling that elementary stream would have been a pain with vaapi |
| 23:02 | jnettlet | this is very frustrating. so close and yet so far |
| 23:24 | jnettlet | _rmk_, yep definitely a problem with transmit. pinging from another machine I see the light blinking for each icmp packet. Pinging out gives sporadic blinking lights. |
| 23:25 | _rmk_ | yea, there was no transmit clock but activity on other signals |
| 23:33 | _rmk_ | jnettlet: your pasted pinctrl has an error |
| 23:33 | _rmk_ | line 17 and 22 are the same mux setting |
| 23:34 | _rmk_ | that'd explain it |
| 23:34 | _rmk_ | in my list, line 17 is MX6QDL_PAD_RGMII_TXC__RGMII_TXC |
| 23:34 | _rmk_ | that's not the RGMII_TX_CTL pad |
| 23:35 | jnettlet | ah thanks for spotting that. I was just getting ready to go back through it. |
| 23:39 | jnettlet | working!!! |
| 23:39 | _rmk_ | :) |
| 23:40 | jnettlet | I guess I can just hardcode a MAC address for now. Nobody has two of them except rabeeh. |
| 23:42 | _rmk_ | well, we're all using d0:63:00:00:00:00 at the moment, as good as any other |
| 23:44 | jnettlet | _rmk_, that previous url should download an image with working networking. |
| 23:44 | jnettlet | will need some more tweaking but that is it for me tonight. Thanks for the extra set of eyeballs and tweaking guidance |
| 23:45 | _rmk_ | does fat loading work too? |
| 23:45 | jnettlet | It should |
| 23:45 | _rmk_ | yay, thanks for this :) |
| 23:47 | jnettlet | need to test first. but just typing boot should try to load a custom boot.scr if it exists and then fatload the uImage |
| 23:53 | Juggie | good work getting networking going |
| 23:55 | jnettlet | hurray for packets |
| 23:55 | jnettle | 23:55 * jnettlet heading to bed. |