| 02:09 | _dab_ | geexbox r17066, does anyone know why it defaults to a bluetooth wiiremote? |
| 02:48 | Tenkawa | greetings all |
| 02:48 | Tenkawa | whats new in the cubox world? |
| 04:07 | nikitis | Anyone have issues with their cubox not powering up properly? |
| 04:08 | cbxbiker61 | there have been some issues with non-solid-run power supplies not working well |
| 04:09 | nikitis | i ordered one from solid run |
| 04:09 | nikitis | long slinder one |
| 04:09 | nikitis | I figured out that I have to power it up, pull it and quickly put it back in to boot |
| 04:10 | cbxbiker61 | yeah that sounds familiar |
| 04:10 | cbxbiker61 | the one i've tested seems to work fine |
| 04:22 | _dab_ | nikitis: I have same problem, independent of the PSU type. It is uboot (I think) |
| 04:45 | nikitis | i4 pro? |
| 05:06 | _dab_ | i4p and i2u |
| 05:08 | mk01 | _dab_: wifi on i4p is 20mhz band only, right (so no 40)? |
| 05:16 | _dab_ | mk01: can't remember. using a wifi dongle at the moment |
| 07:05 | jnettlet | nikitis, ping |
| 07:15 | jnettlet | mk01, sorry this has taken me so long. I am finally getting to sorting out your problems |
| 07:16 | mk01 | jnettlet no problem. I reverted the one commit & redistributed new kernel package |
| 07:17 | mk01 | 20 minutes. |
| 07:17 | jnettlet | mk01, uboot commit? np |
| 07:17 | mk01 | yes |
| 07:18 | mk01 | what you told me . PFD locking errata |
| 07:19 | jnettlet | mk01, I actually think we need to back two of my PFD patches out. The problem I was debugging was most likely due to failing hardware |
| 07:19 | mk01 | jnettlet: I still have the feeling that it's not fully ok |
| 07:19 | jnettlet | mk01, yeah there is another patch to remove as well. |
| 07:19 | jnettlet | I am going to revet them and have rabeeh pull the changes into his branch |
| 07:19 | mk01 | ah ok |
| 07:20 | jnettlet | mk01, revert this as well 2d0c4f544da73 |
| 07:20 | mk01 | jnettlet: oh funny. how much you spent time on that - to find out it was HW ? |
| 07:21 | jnettlet | mk01, not too long. probably half a day. It happens |
| 07:23 | jnettlet | I am much happier having the real answer though, rather than speculation |
| 07:23 | mk01 | on the last but one Gotham's merge window my fresh compiled version was refusing to start. so I spent 3h looking for problem. 1h after someone "fixed" broken fix |
| 07:24 | mk01 | i'm going to revert the 2d0... and will report back |
| 07:27 | mk01 | strange |
| 07:28 | mk01 | jnettlet: I had this second commit even in the older u-boot version. I was exactly at "cleanup boot auto detection" and this one was one before |
| 07:30 | jnettlet | mk01, that was my original patch and seemed less problematic. If it isn't needed I would rather revert back to just wholesale gating and ungating the pfd's |
| 07:30 | jnettlet | ultimately I was using a bit for detection that is marked as for "debug" only |
| 07:34 | mk01 | jnettlet: when we speak about gating ungating & ID bits. I spent some time on the CEC again. as I wanted to pin point the problem rather that as precaution take down whole CEC and then up again |
| 07:36 | jnettlet | For anyone looking for a power-switch for the CBi's. http://www.cjemicros.co.uk/blog/?p=82 |
| 07:37 | mk01 | and found it (although there must e second one). problem was at irqhandler. there is shared irq for cec & hdmi and handler is checking own bit. but even in case of not own IRQ it returned IRQ HANDLED . so HDMI lost "tick" and never woke up |
| 07:38 | mk01 | jnettlet: but to that I have question. |
| 07:39 | mk01 | jnettlet: shouldn't the IRQ be regenerated again still because the HDMI bit wasn't cleared ? |
| 07:42 | jnettlet | mk01, depends on the hardware really. |
| 07:43 | jnettlet | this is the interrupt for the hdmi hotplug detection? |
| 07:43 | mk01 | yes |
| 07:43 | jnettlet | yeah that doesn't need to be cleared. It just sends out the interrupt when the even happens and that is it |
| 07:44 | mk01 | jnettlet: ok then it makes sense |
| 07:45 | jnettlet | yep. good find |
| 07:45 | jnettlet | I am finally getting around to kernel patches today. I am not going to wait on the upstream rebase any longer. |
| 07:45 | jnettlet | So I will patch on 3.10.30 and then do a rebase later on. |
| 07:46 | cbxbiker61 | why not 3.10.37? |
| 07:47 | jnettlet | cbxbiker61, that will happen when I do a rebase |
| 07:48 | jnettlet | but I am still waiting on some patches from rmk to get finished up |
| 07:48 | jnettlet | namely a rework of the ethernet driver for performance, and some pl310 cache cleanup |
| 07:49 | nikitis | jnettlet: pong |
| 07:50 | cbxbiker61 | i pulled a couple of old 3TB drives out of my main server, i should get a chance to test cubox-i as an nfs server on 3.14 next week or so |
| 07:50 | jnettlet | nikitis, when you have to unplug and plug you CBi to get it to boot. Is this during u-boot init, or does it get to the kernel |
| 07:50 | jnettlet | what are the symptoms of it not booting? Front power led on or off? |
| 07:50 | nikitis | jnettlet: i used a usb cable to telnet into it as it boots, but it just sits there until i do the plug thing |
| 07:51 | nikitis | front power led off |
| 07:51 | jnettlet | nikitis, what u-boot version are you using? |
| 07:51 | nikitis | no clue |
| 07:51 | nikitis | the one that came with it |
| 07:51 | jnettlet | we should get you on the latest version. We have fixed a handful of early boot issues |
| 07:52 | nikitis | can you help me? |
| 07:52 | jnettlet | sure. |
| 07:55 | nikitis | so if I power it on and dmesg | grep ttyUSB it just sits there, if I do the unplug/plug method then it boots and I see things in the console |
| 07:57 | jnettlet | nikitis, is your main machinelinux or windows? |
| 07:59 | nikitis | linux |
| 08:01 | jnettlet | 1 sec need to finish rewiring this plug |
| 08:11 | _dab_ | jnettlet: on my i2u, it takes multiple power on/off to get it to boot. |
| 08:12 | jnettlet | _dab_, are you on the latest u-boot? |
| 08:12 | jnettlet | if so I need you to revert two commits |
| 08:12 | nikitis | i'm at root@cuboxi: |
| 08:13 | _dab_ | jnettlet: no. the latest never boots. I am using whatever was in the git on March 9 |
| 08:13 | nikitis | how do I tell uboot version? |
| 08:13 | jnettlet | _dab_, then test the binaries that I am posting now. |
| 08:13 | jnettlet | nikitis, actually just pull the sdhc card out and put it in your linux machine |
| 08:14 | _dab_ | jnettlet: no prob. Where? |
| 08:14 | jnettlet | nikitis, _dab_ https://dl.dropboxusercontent.com/u/736509/u-boot/uboot_fixed.tgz |
| 08:15 | jnettlet | that has SPL and u-boot.img in it |
| 08:15 | _dab_ | ok, back in a few minutes |
| 08:16 | jnettlet | nikitis, instructions for putting those files on your SDHC card are here. http://imx.solid-run.com/wiki/index.php?title=Building_the_kernel_and_u-boot_for_the_CuBox-i_and_the_HummingBoard#U-Boot |
| 08:17 | mk01 | jnettlet: tested img without the second commit. no change. eth0 can't get dhcp address. but I try again after cca uptime 20-25s, it gets address. during the run when dhcp can't be obtained, tcpdump shows regular reply pakets on cubox |
| 08:17 | mk01 | on cubox's broadcast requests |
| 08:20 | jnettlet | mk01, plugged into gigabit or 100bt? |
| 08:20 | mk01 | plugged into 1g |
| 08:20 | nikitis | jnettlet: this isn't making much sense to me |
| 08:20 | nikitis | my card automounts like 5 partitions |
| 08:20 | nikitis | one being /boot |
| 08:20 | jnettlet | nikitis, that is fine. We are writing to the raw sdhc card. |
| 08:21 | nikitis | i've got android on it now |
| 08:21 | jnettlet | mk01, can you try booting with ethernet not plugged in and then plug it in and see what happens? |
| 08:21 | jnettlet | nikitis, that is fine. |
| 08:21 | jnettlet | nikitis, do you see which device your sdhc card is showing up as? |
| 08:22 | jnettlet | and have you extract the archive I posted. You should have two files SPL and u-boot.img |
| 08:22 | nikitis | yes, and sdf |
| 08:22 | _dab_ | that took 3 power off/on s |
| 08:23 | _dab_ | on the i2u |
| 08:23 | jnettlet | nikitis, so you need to run this command. sudo dd if=SPL of=/dev/sdf bs=1K seek=1 |
| 08:24 | jnettlet | and then this one. sudo dd if=u-boot.img of=/dev/sdf bs=1K seek=42 |
| 08:24 | _dab_ | anyway I can debug this for you? |
| 08:24 | nikitis | alrighty, one sec |
| 08:25 | jnettlet | _dab_, well the problem with debugging this is that no front LED means that it failed to read the initial binary from SDHC |
| 08:26 | jnettlet | _dab_, have you tested other SDHC cards? |
| 08:27 | nikitis | done, plug in and try? |
| 08:27 | jnettlet | nikitis, yes |
| 08:27 | _dab_ | 5 different SD cards so far |
| 08:28 | jnettlet | interesting, and all exactly the same behavior? |
| 08:28 | nikitis | same, still have to plug/unplug/plug |
| 08:28 | _dab_ | yes. I thought originally that it was a uSD problem until I twigged to the pon/poff |
| 08:29 | nikitis | jnettlet: for me i've tried class 10 SD and class 4, same results |
| 08:30 | _dab_ | I have tried Transcend(ultimate 4GB 8GB and noname 4GB) , Integral 16GB class 10, Sandisk ultra 8GB |
| 08:30 | jnettlet | _dab_, quick test. Once you plug/unplug so u-boot loads. Can you escape into u-boot shell |
| 08:31 | jnettlet | then run fuse read 0 5 |
| 08:31 | jnettlet | and fuse read 0 6 |
| 08:31 | _dab_ | ok, BTB warm boot always works |
| 08:33 | _dab_ | Reading bank 0: |
| 08:33 | _dab_ | Word 0x00000005: 00002840 |
| 08:33 | _dab_ | CuBox-i U-Boot > fuse read 0 6 |
| 08:33 | _dab_ | Reading bank 0: |
| 08:33 | _dab_ | Word 0x00000006: 00000010 |
| 08:34 | jnettlet | okay that is fine |
| 08:36 | nikitis | nothing is different for me |
| 08:38 | _dab_ | jnettlet: I have tried with and without video plugged in. Makes no difference |
| 08:38 | jnettlet | and you are both using the 3amp plug that can with the CBi right? |
| 08:39 | nikitis | whatever I ordered from solid-run yeah |
| 08:39 | nikitis | it runs fine once it's going |
| 08:39 | _dab_ | On the i4pro I have a high quality 5v/3a, i2u has 5v/2.5A |
| 08:40 | _dab_ | Have tried different PSUs |
| 08:40 | _dab_ | voltage is 5.18 and very stable |
| 08:40 | jnettlet | one last bit of information. |
| 08:41 | jnettlet | when you unplug and plug it back in for it to boot. What does Reset cause read out as? |
| 08:42 | nikitis | interesting |
| 08:42 | _dab_ | Reset cause: POR |
| 08:42 | nikitis | now |
| 08:42 | nikitis | I just found something out |
| 08:43 | nikitis | if I plug in the back of the cubox-i4pro with the adapter already plugged in, I have to do a pull out and put back in |
| 08:43 | nikitis | Clarifying: If the adapter is plugged into the wall FIRST, then plug in the other end into the cubox, I have to do the plug/pull/plug trick. |
| 08:44 | nikitis | but I just tried it with it already plugged into the cubox |
| 08:44 | nikitis | and THEN plugged into the wall, and it worked |
| 08:44 | _dab_ | let me try that |
| 08:45 | nikitis | I think there's a power surge in my adapter because it's already plugged in. And it needs to be drained |
| 08:45 | nikitis | if I plug it in drained, it seems to boot on first try |
| 08:45 | _dab_ | most s modes take a while to lose power |
| 08:46 | nikitis | This looks like adapter design fail |
| 08:46 | _dab_ | makes no difference for me |
| 08:46 | nikitis | I've always only plugged into the back of the cubox after it was already in the wall |
| 08:46 | _dab_ | jnettlet: I have tried 4 different PSU |
| 08:47 | jnettlet | _dab_, I understand. |
| 08:47 | nikitis | I just this time did it in reverse because I wanted to check that it was 5v 3a, then plugged it back into the wall, and it booted first time |
| 08:47 | nikitis | when i plugged it into the wall, it was already plugged into the cubox |
| 08:48 | nikitis | so 1.) wall => cubox = plug/pull/plug, 2.) cubox => wall = boots first time. |
| 08:49 | jnettlet | nikitis, you have tested this multiple times? |
| 08:49 | nikitis | no only once |
| 08:49 | nikitis | let me try again |
| 08:49 | _dab_ | nikitis: that means that it boots with a low voltage. depending on the PSU they take varying times to reach a stable 5V |
| 08:50 | nikitis | just did it again, cubox then wall = first boot |
| 08:52 | nikitis | yeah but if I do Wall then cubox, it won't boot, but the adapter must already have capaciters charged or something, and deliver instant 5v |
| 08:52 | nikitis | the cubox then drains it some, but it's incorrect and won't boot, then when i quickly pull and plug back in, it's correct |
| 08:53 | nikitis | maybe time for adapter redesign |
| 08:56 | _dab_ | jnettlet: need anything else? |
| 08:57 | jnettlet | _dab_, you have reported this to rabeeh already? |
| 08:58 | jnettlet | it doesn't seem to be a software problem at this point, I guess I could give you something that will send out debug output as early as possible |
| 08:58 | jnettlet | although we have seen some other i2u related weirdness. Maybe we need to re-check the DDR3 setup for that SOM |
| 08:59 | jnettlet | I will look at that quick. |
| 08:59 | _dab_ | jnettlet: I have told rabeeh. My gut feel is uboot. It warm boots too well. I will try anything you give me |
| 08:59 | nikitis | Is there anything I can do for my situation hardware wise to improve? Like a different adapter? |
| 09:00 | jnettlet | _dab_, but POR and WDOG boots are two separate processes for the MX6 |
| 09:00 | jnettlet | different init steps are taken, and different clock resets are done |
| 09:07 | _dab_ | jnettlet: On my i4pro, I have no problems with a Mar9 uboot, yet I have problems with current uboot. Therefore methinks software. |
| 09:09 | jnettlet | _dab_, that is a separate problem. We have figured out what is wrong with the i4p booting. |
| 09:09 | _dab_ | ok |
| 09:12 | jnettlet | _dab_, on sec. I have one more u-boot change for you to tes.t |
| 09:13 | jnettlet | _dab_, same link, has been updated |
| 09:16 | _dab_ | ok |
| 09:17 | jnettlet | _dab_, actually, please verify those binaries boot your CBi4p successfully as well if you don't mind. |
| 09:20 | _dab_ | will do |
| 09:27 | _dab_ | jnettlet: no luck. but it is better. Only takes one retry to boot (repeated this a few times) |
| 09:27 | _dab_ | now checking i4 |
| 09:32 | jnettlet | _dab_, hold on. just found one more discrepancy. Let me get you another binary for the i2u |
| 09:33 | _dab_ | ok |
| 09:33 | jnettlet | uploaded |
| 09:38 | _dab_ | ok |
| 09:47 | _dab_ | no change on the i2u |
| 09:47 | _dab_ | works on second PO |
| 09:49 | _dab_ | do you want the last one tested on the i4? |
| 09:50 | jnettlet | _dab_, nope it won't make a difference |
| 09:50 | jnettlet | I will talk with rabeeh about it |
| 09:50 | _dab_ | ok. dinner time |
| 21:31 | heap_ | hi, not sure what i did in my archarm but i have in systemctl [email protected] running and [email protected] is in failed state |