03:51 | _dab_ | I now have an i2ultra. |
03:54 | _dab_ | is geexbox daily build a viable event yet? |
08:28 | _dab_ | anyone know the trick to getting a geexbox nightly to boot? |
13:52 | _dab_ | tomlohave: Is there some special trick to getting a nightly to boot on and i2ultra? |
15:19 | mk01 | jnettlet: do you have a minute ? |
16:21 | davorin | quite quiet these days (o; |
16:22 | davorin | even no email responds from solidrun for almost a week now... |
16:26 | mal- | perhaps any pre holiday |
16:27 | jnettlet | mk01, just got back. shoot |
16:29 | mk01 | wanted to ask again about the kernel cmd line problems I had (with setenv in uboot) |
16:29 | mk01 | but already recompiled uboot with adapted sizes for cmd line paraters #nr and buffer |
16:29 | mk01 | will test later |
16:30 | mk01 | this is one side of the story - when you told me maybe it is too large to fit into variable size |
16:30 | jnettlet | mk01, is this for a 3.0.35 kernel? |
16:30 | mk01 | 3.10 |
16:31 | mk01 | then you told me I should try using cmd line defined in kernel |
16:31 | jnettlet | you know you can add kernel commandline parameters to your .dts file and just recompile that? |
16:31 | mk01 | problem is I need some parameters extras - user definable |
16:32 | mk01 | so I tried defining in .config with setting it should be as addition to the one parsed from boot |
16:32 | jnettlet | can you give me examples? Most of these should be exposed through sysfs to change in userspace |
16:32 | mk01 | but in that case it is completely ignored |
16:32 | jnettlet | you will need to change your kernel config to append kernel config options to the bootloader options |
16:33 | mk01 | but when it is going about root= or rootfstype or rootflags needed to mount root ? |
16:33 | mk01 | I did that CONFIG_CMDLINE_EXTEND=y |
16:33 | mk01 | but nothing |
16:34 | mk01 | the one from kernel is "ignored" |
16:34 | mk01 | and then such "stupid" issue like putting "-" to variable |
16:35 | mk01 | from uboot command line works single quote |
16:35 | mk01 | ' |
16:35 | mk01 | from bootscript I get error |
16:35 | mk01 | on the same command |
16:35 | mk01 | it's driving me crazy |
16:36 | jnettlet | mk01, oh right with device-tree that is broken. I thought I had merged the patch to fix that. |
16:36 | mk01 | If you share the patch I will manage with this "combined" approach |
16:38 | mk01 | otherwise I need to dig into u-boot code :-/ |
16:40 | jnettlet | why are the uenv.txt options not working? |
16:41 | mk01 | I don't use uenv.txt as it doesn't support initramfs |
16:42 | mk01 | i would not be hard to adapt, but still the "setenv" problems will be the same, not ? |
16:42 | mk01 | anyhow I tried putting into env file |
16:42 | mk01 | loading it |
16:42 | mk01 | then "set import -t to load" |
16:42 | mk01 | and run XXX to process |
16:43 | mk01 | same error |
16:44 | mk01 | if I try to set env variable from uboot varieble -> same error as in case of setenv on command line. and I don't know about other tricks how to process this |
16:44 | jnettlet | are you using the latest u-boot? |
16:46 | jnettlet | I overhauled SPL quite a bit, and then rabeeh and i fixed another bug that was causing problems because of an overflow |
16:47 | mk01 | today as I was changing the config options I pulled : 3fd848b..ed888a1 |
16:47 | mk01 | but again, didn't test yet |
16:49 | jnettlet | if you can post an Image I can test again. I have my hardware back up to full capacity |
16:52 | mk01 | this MY last option (when you told me last time to try expand the sizes). and definitely then I will send you my /boot and 1M of SD if you want. or if you want to look, grab http://xbian.brantje.com/pool/devel/main/x/xbian-package-kernel-6q/xbian-package-kernel-6q_1.3.8-16_armhf.deb, extract and look at /boot/boot.scr.txt |
16:52 | mk01 | this is still working ok |
16:53 | mk01 | if you add even "ahci_imx.hotplug=1 " to "baseconfig" |
16:53 | mk01 | it will not parse it anymore |
17:00 | mk01 | jnettlet: to be exact, setenv baseconfig still works , then I need to add some others ... it is "setenv bootargs $baseconfig ......" and that fails. you will see it when you check the file. |
17:01 | mk01 | but really don't waste the time until I try to boot the new recompiled uboot |
17:01 | mk01 | maybe as you say it will work |
17:02 | mk01 | btw: could be new .bin is 70kb smaller ? |
17:03 | mk01 | 220kb vs. almost 300kb before |
17:06 | jnettlet | mk01, yep I switched over to thumb2 mode to get a smaller binary for SPL. |
17:06 | jnettlet | I had more code I needed to fit in SRAM |
17:09 | mk01 | ok |
17:19 | davorin | jnettlet: got a successful boot on the hb3? |
17:24 | jnettlet | davorin, yep everything seems okay |
17:25 | davorin | with som-i4p? |
17:25 | jnettlet | nope just single and dual-core |
17:25 | davorin | ah okay..doesn't help me (o; |
17:25 | davorin | m yhb2 also boots normal with single core |
17:26 | davorin | have to read more into tds and see how i can modify the cbi4 to a som-i4p version.. |
17:38 | jnettlet | davorin, do none of your dual-core soms work? |
17:48 | dv_ | does anything about the HB3 change with regards to kernel, dtb etc.? |
17:48 | dv_ | in other words, if I build a yocto rootfs with meta-fsl-arm and "cubox-i" as machine, will it boot? |
17:48 | jnettlet | dv_, yeah they support more stuff |
17:49 | jnettlet | we need to add a imx6q-hummingboard.dts file |
17:49 | dv_ | so the current 3.0.35 solidrun kernel will not work |
17:49 | jnettlet | no that should work because it doesn't use dts |
17:49 | jnettlet | it should pick up most the cubox stuff. |
17:49 | dv_ | yeah but any board related differences? |
17:49 | jnettlet | obviously things that won't work are LVDS, mPCIE |
17:50 | dv_ | hmm okay, so that kernel will work, just not fully |
17:50 | jnettlet | should |
17:50 | jnettlet | I am just getting to digging in |
17:50 | jnettlet | so far I have two boards up and running |
17:50 | dv_ | I have patches for meta-fsl-arm ready to use your 3.10.30 kernel already (more specifically, the solidrun fork of your kernel) |
17:51 | dv_ | I cannot submit them before the DVI thing is fixed though :/ |
17:52 | dv_ | well, perhaps I can talk to otavio to include the current release and let it work with pure hdmi monitors for now.. |
17:52 | jnettlet | yep, well now that I have more hardware to test against I can get back to things. |
17:59 | davorin | only the single works...not the som-i2u and som-i4p |
18:03 | jnettlet | mk01, you are hitting this limitation in u-boot. #define CONFIG_SYS_MAXARGS 16 |
18:03 | jnettlet | davorin, oh the i2u is the same class as the i4p. I just have the i2dl |
18:04 | davorin | also no i4p? |
18:04 | jnettlet | that is the difference. Just need to tweak the device-tree file |
18:04 | jnettlet | mk01, we can bump that to 32 easy enough |
18:05 | davori | 18:05 * davorin switching computer |
18:05 | mk01 | ok, then the changed CONFIG will work I changed to 32 before the compilation |
18:06 | mk01 | thanks for the hint! although it looks like I can't count to 20 :-/ |
18:06 | jnettlet | well you have to include the initrd and dtb in the arg length |
18:07 | mk01 | hm, right. and initramfs mem address ? |
18:07 | jnettlet | yep |
18:07 | mk01 | thx. |
18:21 | davorin | jnettlet: you have a som-i4, right? |
18:57 | jnettlet | davorin, yes, but it just got fully mounted back into a CBi casing |
18:57 | jnettlet | I need it to be protected for a while, since I was without for a bit. |
18:57 | davorin | well...i can send you some cbi-i4p (o; |
18:57 | davorin | have all models on stock.. |
18:58 | jnettlet | I will keep that in mind. But right now I am swimming in dev hardware I need to get caught up on |
18:59 | davorin | i'm still waiting for a feedback frmo rabeeh or atai regarding new hardware...especially hb3 |
19:01 | davorin | because i need the som-i2u or som-i4p for own development for a hospital here in .ch |
19:19 | jnettlet | davorin, have you tried to boot the original 3.0.35 kernel on a HB with the i4p som in it? |
19:20 | davorin | nope... |
19:20 | davorin | i just pulled the git versions of the kernel and submarine |
19:21 | jnettlet | I will be sure to include a imx6q-hummingboard.dts in my next rebase |
19:21 | davorin | hope to have more time over this long weekend... |
19:21 | davorin | but there is the other problem of cooling with som-i4p and hb |
19:22 | jnettlet | yes. |
19:22 | davorin | with i1 and i2 is no problem..but the i4 has the metall cap exposed... |
19:22 | davorin | and it needs to be low-profile |
19:22 | davorin | so add-on boards won't get a short circuit |
19:23 | davorin | have to call anyway tomorrow a supplier specialised in heatsinks and casing |
19:23 | jnettlet | and you don't want to block the mPCI and lvds ports |
19:23 | davorin | exactly.. |
19:23 | davorin | anyone ever tested if it would fit into the regular rpi case? (o; |
19:24 | jnettlet | of course an aluminum case with a copper spacer down to soc would work |
19:24 | davorin | if it doesn't fit, what's the purpose of the formfactor (o; |
19:24 | jnettlet | the new one was adjusted to fit the RPi perfectly |
19:24 | davorin | even with msata on bottom? |
19:25 | jnettlet | not all cases but most yes. |
19:25 | davori | 19:25 * davorin speaking of the multicomp case |
19:27 | davorin | has there been a shortage in i.mx6 cpus lately? |
19:27 | jnettlet | I will be testing RBPi cameras over the next couple of days |
19:27 | jnettlet | initial tests rabeeh does says they need a color space conversion done in the drivers |
19:28 | davorin | ah cool...have some spare camera on stock...regular and ir... |
19:29 | jnettlet | I have both |
19:29 | davorin | is there already a program to test it? |
19:29 | jnettlet | I need to port the drivers over the RBPi kernel tree. I don't think they are upstream yet |
19:29 | jnettlet | and then merge it into FSL's crazy mem2mem v4l driver setup |
19:33 | davorin | it's csi-2? |
19:34 | davorin | said csi wasn't specified with audio channel (o; |
19:35 | davorin | s/said/sad/ |
19:36 | jnettlet | yes csi-2 as best as I can tell |
19:36 | jnettlet | but you need the sensor driver as well |
19:40 | davori | fpga -> csi-i (o; |
20:43 | mk01 | jnettlet: you are right, RBPi cam drivers are not upstream. it was introduced only recently to RBPi |
21:44 | jnettlet | mk01, well they will be in my kernel soon enough. hopefully with IPU integration to do the necessary colorspace conversions |
22:00 | mk01 | jnettlet: RPI needed to solve this as well. they were waiting for broadcom fw update to allow processing in HW |
22:06 | mk01 | jnettlet: one more question I'm curious about. according to dmesg timing, eth0 is started here |
22:06 | mk01 | [ 11.070626] fec 2188000.ethernet eth0: Freescale FEC PHY driver [Atheros 8035 ethernet] (mii_bus:phy_addr=2188000.ethernet:00, irq=-1) |
22:06 | mk01 | and is made UP by "ip" here |
22:06 | mk01 | [ 15.065189] libphy: 2188000.ethernet:00 - Link is Up - 1000/Full |
22:07 | dv_ | quad-videodecoder? |
22:07 | dv_ | the vpu isnt a quadcore :) |
22:07 | mk01 | but pings from another machine gets responded firstly at 50seconds |
22:07 | mk01 | Request timeout for icmp_seq 48 |
22:07 | mk01 | 64 bytes from 192.168.1.12: icmp_seq=49 ttl=64 time=1.216 ms |
22:08 | mk01 | with 3.0.35 it was also a bit later (like +5+10 seconds after adapter responded UP), but not 40s |
22:08 | mk01 | why is that ? |
22:31 | davorin | you mean reply after it showed as up? |
22:32 | davorin | and when you try to set arp -s manually before ping? |
22:32 | davorin | also long delay? |