| 00:11 | Bluerise | [21:00:44] hmmm an 11" chromebook running ARM |
| 00:11 | Bluerise | [21:01:06] I still think the Samsung model looks better. |
| 00:11 | Bluerise | another arm chromebook? |
| 00:11 | Bluerise | oh, HP. |
| 00:14 | Bluerise | I have that Samsung Chromebook here. The "viewing angle" is a bit smallish, scratches get on it very easily. Else it's fine. |
| 00:14 | Bluerise | It's a good machine to work on FDT... |
| 00:38 | ojn | the HP chromebook has a very very nice display. personally the lack of sd card slot makes it a downgrade from the samsung model |
| 00:39 | ojn | but it's built very well, super sturdy, better quality feel than the samsung |
| 00:40 | Bluerise | My budget won't allow it... |
| 00:47 | ojn | well, that's a completely different subject. :) |
| 00:47 | Bluerise | Yeah. :) |
| 00:49 | Bluerise | Being a student and having an ok budget doesn't correlate well. |
| 01:02 | cbxbiker61 | I finally took the time to write a formatter that optimizes partition layouts/f2fs format on SD cards, it should work real nice |
| 01:04 | cbxbiker61 | now I'm duplicating my std cubox root partition for testing with the carrier-i |
| 02:01 | dv_ | so. |
| 02:02 | dv_ | it built. |
| 02:02 | dv_ | but the carrier one does not seem to boot sometimes. which is incredibly annoying. |
| 02:02 | dv_ | I have to wait a while until apparently something discharged, then I can try again |
| 06:01 | jnettlet | dv_, try to build u-boot without the last commit and see if that makes a difference. |
| 12:36 | dv_ | jnettlet: could it be because I am building your uboot with gcc 4.8 ? |
| 12:37 | jnettlet | dv_, I have tested it with both and it should be fine. |
| 12:37 | dv_ | so far I havent seen any activity from your veersion |
| 12:37 | dv_ | hmm perhaps something inside the OE u-boot.inc is causing this |
| 12:37 | jnettlet | It may be the last commit. That puts things back to rabeeh's clock gate settings |
| 12:37 | dv_ | some kind of incompatibility |
| 12:38 | dv_ | I went to the commit before that. |
| 12:38 | jnettlet | and still nothing? Can you try to build it outside of OE and test it? |
| 12:39 | dv_ | ah hm. I am building u-boot.bin |
| 12:39 | dv_ | is there a difference to .imx ? something other than just the extension? |
| 12:40 | jnettlet | oh yeah, you don't want to build u-boot.bin |
| 12:41 | jnettlet | well u-boot.bin gets built, but then u-boot does additional steps for the imx platform. |
| 12:42 | dv_ | alright |
| 12:42 | dv_ | u-boot 2013 support uEnv.txt files, right? |
| 12:45 | jnettlet | I don't have that setup in the config for the machine. Only boot.scr |
| 12:45 | dv_ | iirc newer uboot versions dont need boot.scr anymore |
| 12:46 | jnettlet | yep, but that is what the rest of the mx6 devices are using, so I followed along. |
| 12:47 | dv_ | yay, got something |
| 12:47 | dv_ | now trying with the latest commit |
| 12:47 | dv_ | (I was using the dd parameters for 2009.08, which include skip=2) |
| 12:48 | dv_ | removed that, and bingo! |
| 12:48 | jnettlet | yep those won't work |
| 12:48 | dv_ | well ideally uboot would look for uEnv.txt in some default location (first mmc partition perhaps), and if there is that file, load from it |
| 12:49 | dv_ | so, first set the default env variables, then look for uEnv.txt, then if present, load it |
| 12:49 | dv_ | otherwise proceed with some default boot procedure |
| 12:53 | dv_ | ok, the last commit does seem to cause problems |
| 12:53 | dv_ | I'll doublecheck and revert to the one before |
| 12:54 | dv_ | you can then try it out simply by putting in a different SRCREV |
| 13:00 | dv_ | alright then. I will add a default config that searches for uEnv.txt ,trying out fatload, ext2load etc. |
| 13:01 | jnettlet | so reverting the last commit makes things stable again? |
| 13:01 | dv_ | it makes uboot run |
| 13:02 | dv_ | with it, I see nothing on the serial console |
| 13:02 | dv_ | but this may be because of some OE extras. not sure. |
| 13:03 | dv_ | anyway, I will try to finish this today, so you can try it out |
| 13:11 | dv_ | now, gotta go. ttyl |
| 15:34 | Bluerise | jnettlet? |
| 15:34 | jnettlet | Bluerise, yes? |
| 15:34 | Bluerise | Is your c1_solo what I want for the c1 I just got? |
| 15:34 | Bluerise | Solo sounds like i.MX6S |
| 15:36 | jnettlet | Bluerise, well the c1 denotes Carrier One which is the development board. Then the microsom can hold different SOC's and RAM configurations. |
| 15:36 | Bluerise | So you branch is for the c1 with a Solo soc? |
| 15:36 | jnettlet | As best as I know all the current C1's released have 512MB's of RAM and an MX6S |
| 15:36 | Bluerise | ah, ok. |
| 15:37 | wumpus | yes |
| 15:37 | jnettlet | rabeeh, Are all the current C1's released have a MX6S and 512MB DDR? |
| 15:38 | Bluerise | The wiki made me assume it was a quad, but I guess what's meant is that the picture has the quad. |
| 15:39 | jnettlet | The quad's will come out later. |
| 15:39 | jnettlet | Bluerise, if you plan on building u-boot let me know if it won't boot. I am trying to figure out if the gating settings are causing problems. |
| 15:39 | Bluerise | your last commit? |
| 15:39 | Bluerise | going to build that, yep. |
| 15:40 | Bluerise | just wanted to make sure that's the board config I want |
| 15:40 | jnettlet | thanks |
| 15:40 | jnettlet | it is all modularized so adding the other board configs should be easy. Just no other boards yet :-) |
| 15:45 | dv_ | jnettlet: want to try out my changes? |
| 15:45 | tazou | hello |
| 15:46 | jnettlet | dv_, send me a link and I will try it later. In a battle to the death with devtree and common clock right at the moment. |
| 15:46 | tazou | I have a cubox, I run it 5 times, but I have no more time to use it. So I sell it |
| 15:46 | dv_ | jnettlet: https://github.com/dv1/meta-fsl-arm-extra |
| 15:46 | tazou | someone interested ? |
| 15:46 | dv_ | jnettlet: as before, uboot does not load uImage automatically |
| 15:46 | dv_ | but its your uboot :) and the whole thing is cleaner |
| 15:46 | dv_ | I'll continue on it in a few hours |
| 15:47 | _rmk | 15:47 * _rmk_ wishes Rabeeh would release schematics for the c1 board, or at least full connector pin details |
| 15:47 | jnettlet | dv_, oh what filesystem are you using. I am only doing fatload right now. The init code needs some flexibility |
| 15:53 | dv_ | jnettlet: ext2load |
| 15:53 | dv_ | ext2 |
| 15:53 | dv_ | err, ext3 |
| 15:54 | jnettlet | dv_, I think ext4 is supported now. |
| 15:55 | jnettlet | yep |
| 15:55 | jnettlet | oh it needs to be enabled separate. that is easy to fix |
| 16:01 | jnettlet | _rmk_, unfortunately I can't make it to Edinburgh. bummer |
| 16:02 | _rmk_ | aww |
| 16:03 | _rmk_ | right that's shesselba's tested-by's added |
| 16:04 | _rmk_ | and JF's suggestion of using #defines for the hdmi bits |
| 16:04 | jnettlet | wumpus, in your vivante testing are you letting the kernel driver scale the GPU frequency or just setting it and letting it go? |
| 16:05 | wumpus | I'm not doing anything with the frequency at all |
| 16:05 | wumpus | so I guess the driver has some sensible default :) |
| 16:05 | jnettlet | so just whatever the platform does? |
| 16:05 | wumpus | yes |
| 16:05 | jnettlet | well it is platform by platform. I am trying to write something to unify it. |
| 16:05 | wumpus | I don't think determining the frequency belongs in user space |
| 16:06 | jnettlet | I think it should be tweakable like cpu_frequency |
| 16:06 | jnettlet | kernel sets the possibilities and defaults and exposes things through sysfs |
| 16:06 | wumpus | oh I'm fine with letting people tweak it, but I mean applications (such as the Mesa driver) shouldn't be doing frequency scaling from userspace |
| 16:07 | jnettlet | agreed |
| 16:07 | dv_ | jnettlet: do something like the original cubox did. first try ext2load on mmc, then fatload on mmc, then ext2load on sata, then fatload on sata, then tftpboot |
| 16:07 | dv_ | the cubox had a rather big uboot script inside |
| 16:08 | jnettlet | dv_, yeah probably will. no sata yet. I am just doing basic defaults and then see what people want once we get boards with more functionality. |
| 16:09 | jnettlet | theoretically I could also add usb storage detection and loading |
| 16:09 | jnettlet | right now it has the functionality so dev's can get dev work done. The support will need to mature as we move forward. |
| 16:10 | dbsx | Rather, I would argue for a minimalist uboot startup script. i.e. mmc only, keep it simple. As jnettlet says you can always expand it via boot.scr. SATA and USB scans are slow and not reliable. It depends on what's plugged in to them. |
| 16:10 | _rmk_ | dbsx: not for the cubox please. its autodetection is really quite useful. |
| 16:10 | _rmk_ | I boot my cubox entirely from eSATA |
| 16:12 | dbsx | And I boot mine from flash. The possibilities are endless which is why I thing it should be kept simple. |
| 16:12 | jnettle | 16:12 * jnettlet wonders if we can do hotplug checking to decide what to scan. Will have to wait until we get an eSATA enabled device. |
| 16:12 | dbsx | s/thing/think/ |
| 16:13 | jnettlet | however the big difference is you have to have an sdhc card, so custom boot.scr's on sdhc will allow whatever the user likes. |
| 16:13 | jnettlet | difference between the Cubox and the Cubox-i that is |
| 16:13 | _rmk_ | yea, for the c1, you have to have a SD card in the slot to boot, so a boot.scr makes sense there |
| 16:14 | jnettle | 16:14 * jnettlet going to walk the dogs before it rains. Needs to clear his head. |
| 16:16 | _rmk_ | hmm, it looks threatening here too |
| 16:17 | _rmk_ | and they're saying rain this evening |
| 16:19 | Bluerise | jnettlet: If I read it correctly, copying u-boot should be `sudo dd if=u-boot.bin of=/dev/disk2 bs=512 seek=1` ? |
| 16:20 | Bluerise | (mac here ;)) |
| 16:20 | Bluerise | [16:57:56] that is why rabeeh was very adamant about the seek=2 skip=2 part of the dd command for u-boot |
| 16:20 | Bluerise | ah, seek 2 |
| 16:20 | Bluerise | but why skip? |
| 16:23 | wumpus | because you also want to skip the two blocks in the source image |
| 16:23 | Bluerise | Why do I want that? |
| 16:24 | dv_ | I think uboot should look for a uEnv.txt on mmc, sata, etc. |
| 16:24 | wumpus | because it produces the image that way it aligns with the start of the medium, so if you don't want to overwrite the MBR, you have to skip the first two blocks both when writing and reading |
| 16:24 | dv_ | and thats it |
| 16:24 | dv_ | uEnv.txt , not boot.scr . boot.scr requires some processing |
| 16:24 | dv_ | then you can stuff into uEnv.txt whatever you want |
| 16:27 | Bluerise | wumpus: So, which image to I need to use than? the elf, the objdumped bin or u-boot.imx? |
| 16:27 | Bluerise | Ah, u-boot.imx (crawling through the logs) |
| 16:28 | Bluerise | Ha |
| 16:28 | Bluerise | [19:40:40] _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 |
| 16:28 | Bluerise | that helped. |
| 16:29 | dv_ | Bluerise: there are currently two working u-boot versions. the modified 2009.08 version from rabeeh, and the 2013.10 fork from jnettlet. |
| 16:30 | Bluerise | I'm currently using jnettlet's |
| 16:30 | dv_ | with the rabeeh one, you need to add skip=2 to the dd line, and you need to build u-boot.bin, not u-boot.imx |
| 16:30 | Bluerise | I see. |
| 16:31 | dv_ | jnettlet's one must be copied without skip=2 , and you must build u-boot.imx, not u-boot.bin |
| 16:31 | dv_ | I recommend using jnettlet's , since it is a much more recent u-boot version |
| 16:31 | _rmk_ | note: conv=fsync not conv=sync |
| 16:36 | Bluerise | jnettlet: With the last commit reverted, it works. |
| 16:36 | dv_ | Bluerise: the last uboot commit? |
| 16:37 | Bluerise | dv_: yep, with https://github.com/linux4kix/u-boot/commit/534b810c93d8617089ace430cc01bc1099e1be66 reverted |
| 16:37 | dv_ | yeah I got problems too with that one |
| 16:46 | Bluerise | http://pastie.org/8389642 |
| 16:46 | Bluerise | Well, that looks good. |
| 17:03 | jnettlet | Bluerise, okay thanks. I will revert it. |
| 17:04 | jnettlet | rabeeh, when you get a chance I would love to chat with you about the clock gating options you were using in u-boot 2009. |
| 17:04 | jnettle | 17:04 * jnettlet is somewhat relieved that they are causing other people problems as well and I wasn't just losing my mind. |
| 17:04 | dv_ | jnettlet: forgot to mention: you need to use both meta-fsl-arm and meta-fsl-arm-extra |
| 17:05 | jnettlet | dv_, okay thanks. On top of yocto right? |
| 17:05 | dv_ | yes |
| 17:05 | jnettlet | got it. |
| 17:05 | dv_ | just add these two layers |
| 17:05 | dv_ | first meta-fsl-arm, then meta-fsl-arm-extra , to bblayers.conf (order matters) |
| 17:05 | dv_ | I recommend putting these after /meta and before /meta-yocto and /meta-yocto-bsp |
| 17:07 | jnettle | 17:07 * jnettlet supposes he will do that now before stepping back into the dynamic clocking ring. |
| 17:19 | jnettlet | dv_, for KERNEL_DEVICETREE we should point it at _rmk_'s |
| 17:20 | jnettlet | that is the current and proper one for the device. |
| 17:23 | dv_ | ah, no idea about that |
| 17:23 | dv_ | since I am currently using linux-imx |
| 17:23 | dv_ | I am not that familiar with devicetree. could I use the devicetree files with linux-imx ? |
| 17:26 | jnettlet | depends on the config. Since the device-tree blob is being included in the config I assume so. |
| 17:27 | jnettlet | once my source get compiled I can see where we are at. |
| 17:33 | _rmk | 17:33 * _rmk_ copies his cubox fs to a nfs export |
| 17:33 | Bluerise | Does u-boot also tell you, that SD/MMC is write-protected? |
| 17:34 | Bluerise | My driver does that, too... |
| 17:34 | jnettlet | Bluerise, are you trying to use saveenv? |
| 17:34 | Bluerise | well, that was one try in u-boot, yes |
| 17:35 | Bluerise | But I also see it after booting my OS |
| 17:35 | Bluerise | imxesdhc0: card is write protected |
| 17:35 | jnettlet | yeah. that doesn't work. |
| 17:35 | jnettlet | and that is a bug I will look at. If you pop the card out and back in you won't get the error but the saveenv still doesn't work. |
| 17:36 | jnettlet | I don't have write functionality for the filesystems in the config, and the default env is too big to be stored in the u-boot blocks of the sdhc card. |
| 17:36 | jnettlet | if you want customization use a boot.scr for now. |
| 17:36 | Bluerise | Oh, no |
| 17:36 | Bluerise | I just want write-support in my OS. |
| 17:36 | jnettlet | or send me a patch :-) |
| 17:37 | jnettlet | it is no problem in Linux. That is just the bootloader |
| 17:37 | Bluerise | maybe a wrong mux? |
| 17:39 | jnettlet | it is complicated. there are a couple of ways to do card detection and the way we are currently doing it is a bit flaky. If you want to debug it go nuts :-) |
| 17:40 | jnettlet | if you pop your card out and put it back in, it will detect fine. |
| 17:41 | Bluerise | I did that… the sd chip still says it's WP |
| 17:42 | jnettlet | boot linux and see what it says |
| 17:43 | _rmk_ | jnettlet: the WP signal on GPIO 2 isn't the WP signal |
| 17:43 | _rmk_ | :) |
| 17:43 | _rmk_ | GPIO 2 on carrier1 is used for the CIR receiver |
| 17:44 | jnettlet | oh, then I should pull that from the pads? |
| 17:49 | dv | 17:49 * dv_ still prefers uenv.txt over boot.scr :) |
| 17:50 | _rmk_ | jnettlet: for the carrier1, probably a good thing. I think the cubox-i has WP on GPIO 2 |
| 17:50 | _rmk_ | from the comments in Rabeeh's patch |
| 17:52 | jnettlet | I suppose I can just implement a getwp function that just returns true for now. |
| 17:59 | dv | 17:59 * dv_ is curious about the 3.10 linux-imx kernel otavio mentioned |
| 18:12 | jnettlet | _rmk_, interestingly enough that error is being generated by trying to read prsstat and seeif the PRSSTAT_WPSPL bit is et. |
| 21:00 | jnettlet | dv_, is your OE image supposed to be built against the danny branch? |
| 21:01 | dv_ | no |
| 21:01 | dv_ | dora |
| 21:01 | dv_ | (which is not released yet) |
| 21:02 | jnettlet | ah that explains my problems. |
| 21:03 | jnettlet | swiper no swiping, swiper no swyiping, swiper no swiping |
| 21:05 | jnettlet | excellent. much better. |
| 21:07 | jnettlet | just ran across this. very interesting. http://kune.ourproject.org/ |
| 21:08 | jnettlet | woops wrong chanel. |
| 22:06 | Bluerise | I'm not sure what I'm missing with OTG... |
| 22:06 | Bluerise | (as host) |
| 22:08 | jnettlet | in theory if it had all the pins and the proper drivers you could plug your Cubox-i into your computer and drag and drop files onto it. |
| 22:09 | jnettlet | But since those files just live on an SDHC card it is probably much easier to just pop the card out and put it in your computer |
| 22:10 | Bluerise | Yeah, usb function, that crazy stuff. I mean, I'd like to have ehci attach to the upper C1 port, so that I have a second usb port ;) |
| 22:13 | jnettlet | it is on the list |
| 22:19 | Bluerise | Well, the u-boot iomuxc configuration should be easy, as it should be only muxing VBUS/OC pins. |
| 22:20 | Bluerise | Which is what I already did |
| 22:26 | _rmk | 22:26 * _rmk_ has ubuntu 12.04 running on his carrier1 :) |
| 22:31 | _rmk | 22:31 * _rmk_ breaths a sigh of relief... proper tools at least :) |
| 22:34 | _rmk_ | ooh, I got a kind of output too on the tv but its not particularly nice |
| 22:34 | _rmk_ | colours are... interesting |
| 22:44 | Bluerise | at least output! |
| 22:44 | Bluerise | ubuntu == proper tools? ;) |
| 22:45 | jnettlet | in the 12.04 days they did |
| 22:46 | Bluerise | True that. |
| 22:50 | _rmk_ | Bluerise: I think anything is better than busybox :) |
| 22:50 | Bluerise | Somehow that made me thing of barebox. Which is a nice u-boot replacement |
| 22:51 | Bluerise | Yeah, it doesn't get worse than busybox.. |
| 22:54 | _rmk_ | now... dare I turn on stuff like PROVE_LOCKING on the imx kernel... |
| 23:10 | _rmk_ | oops :) |
| 23:10 | _rmk_ | 3.12.0-rc3+ #43 Not tainted |
| 23:10 | _rmk_ | [ INFO: possible circular locking dependency detected ] |
| 23:10 | _rmk_ | (&imx_drm_device->mutex){+.+.+.}, at: [] imx_drm_encoder_get_mux_id+0 |
| 23:10 | _rmk_ | x28/0x98 |
| 23:22 | Bluerise | uhoh |
| 23:42 | _rmk_ | its a three-lock circular dependency |
| 23:49 | _rmk_ | http://archive.arm.linux.org.uk/lurker/message/20131009.213501.d3180173.en.html |