| 04:38 | MikeSeth | hste: I tried to compile the galcore driver as a module, seems to have no effect on gpu memory allocation |
| 04:39 | MikeSeth | however, if I start X w/o galcore loaded the HDMI frequency effect is the same as with uboot |
| 09:09 | hste | MiceSeth: not the galcore but the vivavnte. drm part |
| 09:32 | davorin | can the som boot directly from sata as the wandboard? |
| 09:34 | jnettlet | davorin, yep |
| 09:34 | davorin | great (o; |
| 09:34 | davorin | just not on the cuboxes... |
| 09:35 | jnettlet | on the Cubox-i's? They can, and I believe it works but I haven't found my external SATA cable to test. |
| 09:36 | davorin | as i understood the wandboard faq someone needs to move resistors to switch form sd to sata... |
| 09:36 | davorin | so it is either sd or sata... |
| 09:36 | davorin | just plug in an external sata drive doesn't boot with archlinux on it and boot partition.. |
| 09:37 | davorin | the cubox-i4p should just be a little taller and deeper to fit in a msata ssd (o; |
| 09:37 | jnettlet | davorin, oh you mean to only boot from the esata. No that isn't possible. There has to be a microsd card in the slot to load the bootloader. |
| 09:38 | davorin | yes, i meant without bootstraping from sd (o; |
| 09:38 | davorin | apperently wandboard supports it, though you break warranty (o; |
| 09:39 | jnettlet | I don't really see much benefit in that. If you then brick your bootloader you need to move your eSATA drive to another machine and work on it. SDHC is a much simpler recovery method |
| 09:40 | davorin | well...perfect would be if it takes sd first, sata 2nd...but anyway (o; |
| 09:41 | davorin | are opengl libs available under archlinux? |
| 09:41 | jnettlet | check the forums. there are no arch users on the irc channel that I know of. |
| 09:42 | davorin | i don't depend on arch (o; |
| 09:42 | davorin | just closest to what i am used to.. |
| 09:44 | davori | 09:44 * davorin prefers freebsd (o; |
| 10:19 | rabee | 10:19 * rabeeh is here reading _rmk_ bug reports |
| 10:22 | jnettlet | rabeeh, welcome back |
| 10:25 | rabeeh | jnettlet: hey |
| 10:30 | rabeeh | _rmk_'s finding are confirmed |
| 10:30 | rabeeh | on the older SOM (on the older HB) there was a pull down 10k ohm on the LED_ACT |
| 10:30 | rabeeh | the older Freescale u-boot 2009.08 did scan the MDI bus before deciding on phy address |
| 10:31 | rabeeh | that's why it worked on older u-boots then (and now works on the kernel that does a phy address scan) |
| 10:36 | jnettle | 10:36 * jnettlet will check the barebox code |
| 10:55 | hste | jnettlet: how is it going with barebox? |
| 11:18 | jnettlet | hste, it is going well. I have the HB1 booting and have the multiboot support mostly done. Still have to test that for the CBi's |
| 11:19 | jnettlet | just trying to figure out how much functionality I can fit in the 128K of SDRAM |
| 11:20 | jnettlet | but the community is a lot more flexible and accepting than u-boot, and the code design is much nicer. |
| 11:25 | hste | jnettlet: so its easier to get into barebox "mainline" then? |
| 12:31 | rabeeh | _rmk_ / jnettlet - https://github.com/rabeeh/u-boot-imx6/commit/8fb3f5e6d1e85b6fd574b4fad1b78040d5aaa9f0 |
| 12:32 | _rmk_ | rabeeh: have you tested that? |
| 12:32 | rabeeh | yes. on my box that now shows phy address 0x0 |
| 12:33 | _rmk_ | I tried that and it fails, because fecmxc ends up trying to register two mii buses with the same name |
| 12:33 | _rmk_ | and mii buses can't be deregistered |
| 12:33 | rabeeh | oh; damn it |
| 12:33 | rabeeh | so it's successding only on the first registration then |
| 12:34 | _rmk_ | yes - and there's another problem... it never returns any kind of failure if the phy isn't found |
| 12:34 | _rmk_ | that's why I came up with what I did in my patch |
| 12:35 | _rmk_ | http://fpaste.org/71050/95148139/ |
| 12:36 | _rmk_ | the change in drivers/net/phy/phy.c is needed to make it fail when the phy isn't found |
| 12:36 | _rmk_ | and then I just hacked drivers/net/fec_mxc.c to probe phy #4 if the configured phy id isn't found |
| 12:37 | _rmk_ | I think you can ignore the other changes |
| 13:01 | jnettlet | why don't we just bring back the behaviour of u-boot-2009 and scan the full bus properly? |
| 13:01 | _rmk_ | why bother with uboot :) |
| 13:02 | jnettlet | I hear ya brotha! |
| 13:19 | rabeeh | i'v forced pull up now (making phy address 0x4) |
| 13:20 | _rmk_ | note that it also changes the LED behaviour since it configures the polarity of the output |
| 13:51 | rabeeh | _rmk_: yes. but that can be configured by the driver aftwards |
| 13:52 | rabeeh | forcing the LED_ACT with a pull up shows the address now at 0x5 (instead of 0x4) |
| 13:52 | rabeeh | :) |
| 13:52 | rabee | 13:52 * rabeeh heads for lunch with family now. be back in 1.5hrs |
| 13:58 | _rmk | 13:58 * _rmk_ sighs... noooo.... this is going to need more platform specific hacks in the kernel |
| 13:59 | _rmk_ | rabeeh is all for DT, and having very little platform specific code in the kernel, but then he goes and does something silly like that... |
| 14:00 | _rmk_ | so, mainline is _not_ going to support tweaking the configuration of that LED, period. |
| 14:01 | _rmk_ | when we've got soo much other stuff to deal with, I'm not going to bother with fixing stuff up which results from bad design decisions |
| 14:02 | _rmk_ | especially ones which are avoidable |
| 14:06 | _rmk_ | and if it results in the phy appearing at address 5 (how? that's not controlled by LED_ACT) then we've now got even more of a mess than we had before |
| 14:07 | _rmk_ | thankfully the kernel doesn't care but silly boot loaders like uboot... |
| 14:08 | _dab_ | _rmk_: Are we getting closer to a usable uboot and kernel (or not)? |
| 14:10 | jnettlet | _rmk_, why are we phutzing with the pullups? shouldn't we just make the phy scan the addresses properly to fix this problem? |
| 14:11 | jnettlet | we aren't specifying a phy address in device-tree are we? |
| 14:11 | jnettle | 14:11 * jnettlet goes to look |
| 14:15 | _rmk_ | jnettlet: it really needs a pull down, which is what the data sheet specifies for that configuration of the LED |
| 14:16 | _rmk_ | with a pull-up, it configures the phy to have address bit 4 set, _and_ sets it so the output is active low (no link = high = led on, link = low = led off, activity = pulse high = flash) |
| 14:16 | _rmk_ | jnettlet: there is *no* DT stuff for phys in the kernel |
| 14:17 | jnettlet | great. |
| 14:17 | _rmk_ | so... to work around this fubar'd decision, we need to add DT support to the phy layer... |
| 14:17 | jnettlet | so with these changes the link light is now off when active? |
| 14:17 | _rmk_ | yep |
| 14:17 | _rmk_ | unless we configure it differently by software |
| 14:18 | _rmk_ | and we have no way to do that in DT |
| 14:18 | jnettlet | we would need an invert-led property or something along those lines. |
| 14:19 | _rmk_ | _and_ we need some way to extend DT into the phy layer |
| 14:19 | _rmk_ | bearing in mind that phy's are autodetected |
| 14:19 | jnettlet | yeah |
| 14:20 | _rmk_ | so, I am just not going to care about this when it could've been trivially fixed by applying the correct pull to the line |
| 14:24 | jnettlet | does the kernel even care about this, or is it just u-boot? |
| 14:26 | _rmk_ | uboot cares about the address, and we'd also have to hack that led configuration into uboot too (which I can't see a way for the platform code to do it directly... platform code can't even provide a phy reset function) |
| 14:26 | _rmk_ | and even if uboot did configure it, the kernel resets the phy after setting the iomux, which would undo that config. |
| 14:29 | jnettlet | which really brings us back to square one, which is leave the pin mux settings as is and fix the phy driver to scan the bus for the proper address. |
| 14:30 | jnettlet | yes, not elegant but seems like it will fix all our problems |
| 14:30 | jnettlet | 15 minutes to implement and debug and then we can forget about it. |
| 14:30 | jnettlet | or am I missing something on the kernel side? |
| 14:32 | _rmk_ | as I say, the kernel resets the phy |
| 14:33 | jnettlet | right, and it properly scans the bus to find the correct addr to use. |
| 14:34 | _rmk_ | and the reset will cause the LED configuration to be lost |
| 14:34 | jnettlet | oh right, the polarity of the led depends on this. |
| 14:34 | jnettlet | forgot that piont |
| 14:34 | jnettlet | point |
| 14:39 | _rmk_ | another nail in the coffin on this... |
| 14:39 | _rmk_ | the polarity can't be set by software |
| 14:39 | _rmk_ | there's no documented software configuration for this in the AR8035 data sheet |
| 14:39 | _rmk_ | and the text implies that it is solely configured by the pullup/pulldown on the pin. |
| 14:51 | MikeSeth | hste: ooh, I see, though the problem isn't that gpumem has no effect, it does, but something else allocates 128Mb |
| 14:55 | jnettlet | MikeSeth, probably for the VPU |
| 14:56 | jnettlet | _rmk_, well then the phy might need to grow dt support. Really the phy should already have device-tree support as the device-tree is supposed to describe the hardware. |
| 14:57 | jnettlet | oh alot of the phy does have device-tree support. It is just atheros that is lagging behind |
| 14:57 | hste | MikeSeth: look into arch/arm/plat-mxc/include/mach/memory.h and https://github.com/wandboard-org/linux/commit/7cbd06b2904c1855109084ca6b0c84990bc69233 |
| 14:58 | jnettlet | that is definitely less painful than needing to make a case for the entire phy having to grow device-tree compatibility for this one use case |
| 15:05 | _rmk_ | jnettlet: there's no point - the LED polarity can't be configured from software |
| 15:13 | _rmk_ | also... with mdio bus scanning, you don't end up with an of_node attached to the phydev |
| 15:14 | _rmk_ | follow the code paths from mdiobus_register() |
| 15:19 | MikeSeth | hste: thanks |
| 15:20 | MikeSeth | ohhh.. that's ugly |
| 15:36 | davorin | hmm..what bt chipset is used? |
| 16:46 | MikeSet | 16:46 * MikeSeth drills into LDD3 |
| 17:00 | rabeeh | _rmk_: https://github.com/rabeeh/u-boot-imx6/commit/efc4835294122212052a8b8b2a23d14fa2b72177 |
| 17:00 | rabeeh | want to test? |
| 17:01 | rabeeh | i have tested with both phy address is 0 and phy address is 0x4 |
| 17:01 | rabeeh | there is also a fix for the phy address 0x5 where ENET_RXD0 and ENET_RXD1 where not pulled down. |
| 17:02 | rabeeh | _rmk_: the fecmxc_initialize_multi() function now gets a phy map (instead of phy id); which what it should have been in the first place ! |
| 17:21 | davorin | rabeeh: what bt chipset is used in i2u and i4p? atheron? |
| 17:21 | rabeeh | broadcom bcm4328 |
| 17:21 | rabeeh | broadcom bcm4329 |
| 17:21 | rabeeh | it's part of the wifi chipset |
| 17:22 | davorin | so it's one kernel module for both then? |
| 17:26 | rabeeh | wifi is one module, bluetooth is another |
| 17:26 | rabeeh | it's an rfkill based setting on uart4 |
| 17:30 | davorin | rfkill only lists phy0 wifi |
| 17:38 | rabeeh | davorin: which system? kernel? |
| 17:38 | rabeeh | i'v got BT fully working only under Android |
| 17:38 | davorin | archlinux 3.0.35-6 om i4p |
| 17:38 | davorin | don't even see this bcm chip listed under make menuconfig |
| 17:38 | rabeeh | the kernel bits are there; there should be an .hcd firmware to be patched to the BT chipset nvram |
| 17:39 | rabeeh | CONFIG_BRCMUTIL=y |
| 17:39 | rabeeh | CONFIG_BRCMFMAC=y |
| 17:39 | rabeeh | CONFIG_BRCMFMAC_SDIO=y |
| 17:39 | rabeeh | wifi part |
| 17:40 | davorin | yepp..set... |
| 17:40 | davorin | CONFIG_BRCMUTIL=y |
| 17:40 | davorin | CONFIG_BRCMFMAC=y |
| 17:40 | davorin | CONFIG_BRCMFMAC_SDIO=y |
| 17:41 | davorin | from your git kernel |
| 17:44 | rabeeh | CONFIG_MACH_IMX_BLUETOOTH_RFKILL is not set by default (which is a bug) |
| 17:44 | rabeeh | i'm adding it with a bunch of other modules to be built by default |
| 17:46 | davori | 17:46 * davorin needs a ssd drive for compiling on i4p (o; |
| 17:59 | davorin | so...how far are you with the docs? *gg |
| 17:59 | davori | 17:59 * davorin ducks |
| 18:02 | rabee | 18:02 * rabeeh hides |
| 18:10 | _rmk_ | rabeeh: why might we not pull down RX0/1 ? |
| 18:11 | rabeeh | _rmk_: the reason is that the microsom supports on the same footprint Atheros 8035 and 8030 (fast ethernet version) |
| 18:11 | rabeeh | the 8035 is rgmii and 8030 is rmii; so the same 8035 RXD0 pad connects to both RGMII_RD0 and ENET_RD0 |
| 18:12 | rabeeh | the default of i.MX6 is pullup on those two pads; but u-boot configured RGMII_RD0 to pulldown of 100kohm but left ENET_RD0 at it's default (100k pullup) |
| 18:12 | rabeeh | does this answer the slightly ambiguous question? |
| 18:17 | rabeeh | _rmk_: the reset strapping on the microsom is a bit ambiguous since we try to share the data lines with the i.MX6 pull ups/down (and not forcing them by resistors) |
| 18:18 | rabeeh | the reason ofcourse is space (and price) |
| 18:18 | rabeeh | but i already have had so much pain from this that i regret we did this the first round |
| 18:51 | _rmk_ | so... RGMII_RD0 is connected to ENET_RXD0, RGMII_RD1 to ENET_RXD1, what about ENET_RX_EN? |
| 18:55 | _rmk_ | don't we also want ENET_TX* to also be high-z ? |
| 19:05 | rabeeh | ENET_RX_EN is connected via a 22ohm DPR |
| 19:06 | rabeeh | so the pad RX_DV can be either connected to ENET_RX_EN or RGMII_RXDV of the i.MX6 |
| 19:07 | rabeeh | TXD0/1 that are both shared between the RGMII and RMI of the i.MX6 are also on the same DPR |
| 19:08 | rabeeh | it's a resistor array of 4x22ohm resistors |
| 19:13 | _rmk_ | so the RGMII and RMI interfaces are wired together? |
| 19:30 | rabeeh | _rmk_: have of them |
| 19:30 | rabeeh | the TX side is is via 22ohm array of 4 resistors in order not short in case someone programs RMII and RGMII to be driving |
| 19:30 | rabeeh | the RX side is shared |
| 19:31 | rabeeh | _rmk_ actually we are thinking to completely get rid of the RMII |
| 19:31 | rabeeh | i.e. never support fast ethernet |
| 19:49 | davorin | hmm..recompiled with CONFIG_MACH_IMX_BLUETOOTH_RFKILL set and copied uImage over... |
| 19:49 | davorin | something fecked...no boot (o; |
| 19:52 | Novastorm | good evening/morning/afternoon (depending on location) |
| 19:53 | Novastorm | Is anyone with decent linux knowledge around at the moment? |
| 20:01 | Novastorm | No takers? =P |
| 20:01 | dlloyd | define decent? |
| 20:01 | dlloyd | or just ask the question? |
| 20:03 | Novastorm | sorry, thought everyone might be asleep/afk so asking the quesiton might not net any results =) here goes |
| 20:04 | Novastorm | i have arch linux on a cubox-i4pro, and i have 2 issues which as far as i know both come from the fact that network is not yet up when they get initialised: murmur service and a CIFS mount |
| 20:04 | Novastorm | i was wondering what the easies way in arch is to make sure the CIFS share isn't mounted and murmur isn't started untill network is up? |
| 20:05 | dlloyd | havent worked with arch much, but i imagine there must be some way to specificy a working network connection as a dep for starting those services?> |
| 20:06 | dlloyd | a quick googling points to https://bbs.archlinux.org/viewtopic.php?id=151921 |
| 20:06 | Novastorm | well i'm a newbie, so i'm getting a bit lost in the possible solutions...one solution i see is using rc.d for the mounting (this makes me assume rc.d is run after network is up but i might be competely off) |
| 20:08 | Novastorm | i noticed that with ps aux |grep murmur that murmur is running, but it needs a restart of the service before it acepts any connections, so maybe i could just add the restart command to rc.d as well and be done with it? |
| 20:08 | dlloyd | possibly, i don't know if rc.d waits until networking is initialized |
| 20:09 | dlloyd | and depending on how arch parallelizes the boot sequence, the network might still be initializing when it runs rc.d |
| 20:09 | Novastorm | hmm...but in rc.d it's possible to add "sleep" right? |
| 20:09 | Novastorm | since i'm not in a hurry after a reboot, i could maybe just tell it to wait for 30 seconds or so? |
| 20:09 | dlloyd | yes, you could hackishly get around it doing that most likely |
| 20:10 | dlloyd | or put in a conditional on a ping command returning successfully |
| 20:10 | dlloyd | ie make sure you can ping the target you are mounting before trying to mount |
| 20:10 | Novastorm | also when googling i found that it was possible to have something like @reboot in a cron job....like i said, googling gives me so many possilble solutions it makes my head spin =) |
| 20:11 | Novastorm | which is why i came here |
| 20:11 | Novastorm | is it difficult to make that conditional ping command? |
| 20:11 | dlloyd | well, best course of action is try one :) wait until it breaks then try something else |
| 20:11 | Novastorm | lol yeah that's a good way to learn at least |
| 20:12 | Novastorm | it think i will start with trying to use rc.d in combination with sleep, and if that works i can look into trying other ways |
| 20:12 | dlloyd | sounds good |
| 20:13 | Novastorm | now to find rc.d in arch....... |
| 20:13 | Novastorm | thanx for the input, i'm gonna go fiddle some more =D |
| 20:14 | dlloyd | stick around and i will help you with the ping part in a few minutes |
| 20:14 | Novastorm | well can't find rc.d yet, so that is going to be the first puzzle =) |
| 20:17 | Novastorm | just read that arch uses systemd, so apparently that doesn't use rc.d? |
| 20:24 | dlloyd | until ping -c 1 -W 1 192.168.1.2 >/dev/null; do echo "no network"; done; echo "connected" will block your script until it can ping |
| 20:26 | Novastorm | thanks dlloyd, now to see where the hell i can put this in arch =) |
| 20:26 | dlloyd | yeah.. can't help you there |
| 20:28 | Novastorm | that's alright, you've been a big help, and half the fun for me is finding stuff like this out =) |
| 20:28 | dlloyd | note: before putting that anywhere make sure that arch does start things in parallel |
| 20:28 | dlloyd | otherwise if that runs before your network, you will be locked in a deadlock :P |
| 20:28 | dlloyd | might be smart to put a counter in there that waits for 30 pings or something |
| 20:28 | Novastorm | ah ok, that would be bad =) |
| 20:29 | Novastorm | i think i'm going to do a workaround with sleep first, then if that works make an image of my sdcard before i attempt that scripting which might break everything =D |
| 20:31 | Novastorm | also, i might try not letting the cubox getting an IP from DHCP since that takes time, possible that it would be solved by making network available sooner without DHCP |
| 20:31 | Novastorm | ah so many possibillities to try!, i'm just going to go fiddle now. Thanks dlloyd =D |
| 20:36 | dlloyd | count=0; until ping -c 1 -W 1 192.168.1.122 >/dev/null; do if [ $count -gt 30 ]; then break;fi; echo "no network";((count++)); done; echo "connected" waits 30 attempts then gives up |
| 20:36 | dlloyd | have fun :) |
| 20:43 | Novastorm | thnx =) |
| 21:02 | rabeeh | _rmk_: i just measured the before and after LDO bypass mode effect |
| 21:02 | rabeeh | that's on the rail after the cpu LDO regulators; and it shows increase of 1.3mV :) |
| 21:03 | rabeeh | from 1.273v to 1.275v |
| 21:04 | rabeeh | so it looks i'm going to pass on enabling the LDO bypass mode since it looks like useless |
| 21:04 | rabeeh | although all the devices that are shipped that can use this feature are all marked in their second general purpose fuse |
| 21:05 | rabeeh | [root@buildroot /]# cat /sys/fsl_otp/HW_OCOTP_GP2 |
| 21:05 | rabeeh | 0xbeef0000 |
| 21:40 | Novastorm | @dlloyd: i used a cron job with @reboot and sleep to mount the cifs share and restart murmur, seems to work great =) |
| 21:41 | Novastorm | now i'm off for some battlefield 4 |