12:42 | topi` | jnettlet: which UBOOT would you recommend flashing into our eMMC-destined Gates/Edges? |
12:44 | rabeeh | the same famous one |
12:44 | topi` | I'm looking inside the tar.bz2 given by the HERE-1 link, it seems there is a uboot there |
12:44 | topi` | imx_usb_loader-solidrun-rev-1.1/dq/u-boot_mx6_cubox-i2ultra.imx |
12:44 | rabeeh | one u-boot rules them all; for hb/cbi/emmc/micro sd etc.. |
12:44 | rabeeh | oh; those are u-boot with dtd |
12:45 | topi` | I guess the quad one is the correct one, because this device (I think is the imx6 Dual) |
12:45 | rabeeh | those are purely intended to boot usb OTG; if you want the one in runtime just build it from our github |
12:45 | topi` | right |
12:45 | topi` | I don't have a proper setup for building uboot ./ |
12:45 | topi` | :/ |
12:45 | rabeeh | http://wiki.solid-run.com/doku.php?id=products:imx6:software:development:kernel |
12:45 | rabeeh | U-Boot section |
12:46 | topi` | can I ask is this usb-otg UBOOT package designed to do something? or does it just take me into a uboot prompt? |
12:46 | topi` | if it starts eFusing something, then I cannot undo it :) |
12:47 | topi` | Bus 004 Device 004: ID 15a2:0054 Freescale Semiconductor, Inc. i.MX6Q SystemOnChip in RecoveryMode |
12:47 | topi` | this seems to be a DualQuad som |
12:52 | topi` | jnettlet: any known limitations for compiling uboot? I think I've got gcc-4.8.4 |
12:53 | rabeeh | if you downloaded the HERE-1.1 then it only boots u-boot and kernel too |
12:53 | rabeeh | we use it internally (variation of it) to do board testing and efuse setting |
12:55 | topi` | ok, good |
12:56 | topi` | I'll try it out :) |
12:56 | topi` | I just built my own UBOOT |
12:56 | topi` | I should test it on a SD card before committing to the eMMC... |
12:56 | topi` | ah, no, I cannot force it to boot from SD... |
12:56 | topi` | I could test it on an already-fused HB2 |
12:56 | rabeeh | yup |
12:58 | topi` | what does the "runme.sh" do? |
12:59 | topi` | it just seems to generate boot.scr |
13:05 | topi` | odd, I can't see the eMMC chip in either mmc0 or mmc1 (going through the dmesg in that buildroot image) |
13:06 | topi` | and /proc/partitions is empty... there should be mmcblk0 if it really sees the eMMC |
13:06 | topi` | another possibility is that this SoM is not really that revision which has the Wilink8 and eMMC? |
13:07 | topi` | wl1271_sdio: probe of mmc1:0001:2 failed with error -61 |
13:12 | topi` | there are no /lib/modules here, so I don't know how to verify if the SoM has a Broadcom or Wilink8 |
13:13 | topi` | ah, usbcore has registered driver brcmfmac |
13:17 | topi` | if I cannot access the eMMC here; i guess my option is to install a M.2 ssd card and blow the fuses so that it will try to boot from there |
13:21 | topi` | jnettlet: did you build the kernel used by the usb-otg boot script, or was it rabeeh? Does it include the Wilink8 module/driver? |
13:28 | jnettlet | topi`, that is not from me. Does if have -som-15.dtb variations? |
13:30 | rabeeh | jnettlet: it forces load of a dtb to address 0x18000000 |
13:31 | rabeeh | the scripts loads the non -som-15.dtb variant; so TI Wilink8 won't be initialized. |
13:33 | rabeeh | i wish webusb could support this |
13:37 | jnettlet | It does, but we need standards first. https://github.com/devanlai/webdfu |
13:37 | jnettlet | which is why I am working on DFU support for everything |
13:40 | jnettlet | rewriting support for every random protocol a SOC vendor thinks up doesn't make much sense. |
13:49 | topi` | I think it tried to initialize wilink8 |
13:49 | topi` | because wl1271 returns error -61 |
13:50 | topi` | for mmc1 (SDIO) |
13:50 | topi` | if mmc1 were connected to an eMMC, it would say "SDHC" instead of "SDIO" |
13:50 | topi` | but my biggest problem here is that the eMMC is not found at all? |
13:51 | topi` | maybe wrong .dtb? |
13:51 | topi` | the "dq/imx6q-hummingboard2.dtb" is dated Oct 19, 2016 |
13:52 | topi` | so it probably lacks the nodes for the v1.5 SoM eMMC? |
13:56 | topi` | btw, our boards seem to have "boot select" jumpers, USB-OTG, SATA, EMMC, MicroSD. But do these jumpers do anything at all? |
13:56 | topi` | can they be used while the device is totally unfused? |
14:09 | topi` | mmc2: Timeout waiting for hardware interrupt |
14:09 | topi` | I think this is the eMMC it tries to probe? |
14:10 | jnettlet | topi, yes. unfortunately eMMC devices have no way to test if they are present. |
14:10 | topi` | but the eMMC is now situated in SOM and not on the baseboard ... |
14:10 | topi` | I just need to access mmcblk0 so I can flash the uboot to it |
14:10 | jnettlet | mmclk0 for eMMC or SDHC? |
14:11 | topi` | eMMC |
14:11 | topi` | this kernel (Linux buildroot 3.14.79+) has been compiled on Jan 15, so it is not very old |
14:14 | jnettlet | topi`, can you take a picture of the som and carrier you are using? |
14:16 | topi` | ok |
14:18 | topi` | Do I need to screw out the heatsink? |
14:18 | jnettlet | that would be easier for identification |
14:19 | jnettlet | really unless you are pushing it hard you don't need the heatsink. I run them all the time without it. |
14:30 | topi` | the quad does become hot if using all cores |
14:30 | topi` | OK it seems to carry a Samsung eMMC |
14:32 | topi` | which mmc should it be mapped to in the kernel? mmc0, 1 or 2? |
14:32 | topi` | if you have the Edge, is the baseboard eMMC going to "override" the SOM eMMC? |
14:33 | jnettlet | topi`, no the rev 1.5 som has resistor packs and it uses the on-board som rather than the carrier som |
14:35 | topi` | ok so it shows up in the same mmcx device as the "traditional" carrier emmc? |
14:35 | topi` | but why won't the kernel see it? |
14:36 | jnettlet | not sure. I will have to download that kernel and test |
14:37 | topi` | it came from the link: http://wiki.solid-run.com/lib/exe/fetch.php?media=products:imx6:microsom:imx_usb_loader-solidrun-rev-1.1.tar.bz2 |
14:38 | topi` | should I just try to replace that zImage with a "build_all_modules" kernel? :) |
14:47 | topi` | ok, can you give me any advice on how to proceed with this? we need to demo a working board tomorrow; I'd rather do it with the on-board eMMC than a SD card which we cannot use in deployment anyway |
14:53 | topi` | what do the "boot selection" jumpers do anyway? is it worth to try them out? to boot from e.g. a SDcard |
15:02 | topi` | I tried jumpering to "boot from SDcard" but no go... nothing on uart |
15:02 | jnettlet | topi`, yes the design of those pins was not fixed until the latest board spin we just did. |
15:02 | topi` | OK so that explais |
15:03 | topi` | I will just write "DO NOT USE" over them :) |
15:03 | jnettlet | topi`, okay so here is the deal. It looks like there is a hardware bug between the HB2 Gate and the rev 1.5 som. |
15:04 | jnettlet | however there is a simple fix |
15:04 | topi` | ok |
15:08 | jnettlet | just bridge R48 on the bottom of the board. https://goo.gl/photos/j52u8N55DphDT6BT8 |
15:09 | topi` | what does the R48 do? |
15:09 | topi` | I don't have a soldering iron here ;) |
15:09 | jnettlet | topi`, provides power |
15:11 | jnettlet | do you have a piece of wire and glue? |
15:11 | jnettlet | :) |
15:11 | jnettlet | let me look over the schematics one more time quick |
15:15 | topi` | I hope the same hw bug won't exist in the Edges we're about to order soon... |
15:18 | jnettlet | topi`, those have eMMC on the carrier, so they will have that populated |
15:22 | topi` | I tried to insert a SDcard while the uploaded kernel was running, but it fails to detect any card |
15:22 | topi` | nothing on dmesg |
15:29 | topi` | going to set the eFuses to boot from SDcard on this individual for testing... do we have to set up and fuse the MAC address at this time as well? |
15:29 | topi` | or will the fec driver use a random MAC if unfused? |
15:32 | topi` | oops, I fused 0x2850 instad of 0x2840 ... what boot device will it use then? |
15:33 | jnettle | 15:33 * jnettlet checking |
15:38 | jnettlet | uSDHC3 in 8-bit mode |
15:39 | jnettlet | topi`, so luckily you should be able to still boot from the eMMC once you fix the HB-gate |
15:45 | jnettlet | topi`, if you push SPL over the USB-OTG then you should be able to see the fused device it wants to boot from in the console output |
15:46 | topi` | I got it to boot from SDcard |
15:47 | topi` | now it seems I'm missing something from the .dtb file because it did not find the mmc0 at all, so no rootfs |
15:52 | topi` | so, R48 was taken out because the Gate doesn't carry the eMMC? |
15:55 | topi` | jnettlet: can you provide me some patches for 4.x kernel for the -som-v15.dtbs? |
15:55 | jnettlet | topi`, yep. I am trying to figure out why that matters. Because the 1.5 som works fine with the HB Base and Pro |
15:55 | jnettlet | topi`, sure |
15:59 | topi` | I just copied the hummingboard2.dtb (that works on our older boards) to hummingboard2-som-v15.dtb but it did not find the SDcard |
15:59 | topi` | the kernel did not find, I mean |
16:09 | jnettlet | topi`, is it even looking for it? |
16:13 | topi` | nope. mmc0: new high speed SDIO card at address 0001 |
16:14 | topi` | the a few messages about mmc1 and mmc2 |
16:14 | Artox | I hope this isn't the situation I ran into where m.2 fooled boarddetect into treating hb2 as hb1 |
16:14 | Artox | but that happened as early as u-boot, so you should know if or not |
16:14 | topi` | probably not |
16:14 | topi` | OF: fdt: Machine model: SolidRun HummingBoard2 Dual/Quad |
16:14 | topi` | says the kernel in the very beginning |
16:20 | jnettlet | topi`, can you stop break into u-boot so we can run some commands? |
16:20 | topi` | ok |
16:21 | topi` | there we are |
16:22 | topi` | board=mx6-hummingboard2 |
16:22 | topi` | board_fdt=try |
16:22 | topi` | CPU: Freescale i.MX6Q rev1.6 at 792 MHz |
16:23 | topi` | MMC: FSL_SDHC: 0, FSL_SDHC: 1 |
16:25 | topi` | mmc list returns both "FSL_SDHC: 0" and "FSL_SDHC: 1" but the second one is indented by one space |
16:28 | jnettlet | topi`, specifically run. env print cpu; env print board; env print somrev |
16:28 | jnettlet | yes that is correct. |
16:28 | jnettlet | but only 1 will work because the eMMC isn't powered |
16:31 | topi` | yes |
16:34 | topi` | wtf, I'm unable to break the uboot procedure |
16:34 | topi` | 3 2 1 then it boots :) |
16:34 | topi` | maybe the stupid virtualbox is to blame |
16:37 | topi` | maybe the cable is bad :/ |
16:38 | topi` | but do you know what has to be modified for the -som-v15.dts? |
16:38 | topi` | I'm unable to get via serial console, I'll try a mnitor and a keybaord |
16:48 | topi` | env print cpu -> cpu=6Q |
16:48 | topi` | board=mx6-hummingboard2 |
16:48 | topi` | somrev=-som-v15 |
16:49 | jnettlet | okay everything is detected properly |
16:50 | topi` | uboot did say it wanted to have "imx6q-hummingboard2-som-v15.dtb" |
16:50 | topi` | and then I created a symlink :) |
16:50 | topi` | very creative |
17:07 | topi` | I probably need to get back home at this point... |
17:39 | vpeter | jnettlet: Do you have any idea why cubox-i with som v1.5 would not boot libreelec image? |
17:39 | vpeter | It loads kernel, correct imx6q-cubox-i-som-v15.dtb but after 'Starting kernel ...' nothing on console. |
17:39 | vpeter | Same image works fine with cubox-i with old som. Used uboot and kernel from solidrun. |
17:39 | vpeter | https://forum.libreelec.tv/thread-5449-post-42386.html#pid42386 |
17:47 | jnettlet | vpeter, just tested a cubox-i with a rev 1.5 som with the latest u-boot and kernel and it booted without any problems. |
17:47 | jnettlet | you probably need to enable earlyprintk in the kernel and then boot to see where it is hanging. |
18:26 | vpeter | But why it would even hang? There is no real reason. |
18:39 | vpeter | Do I need to set earlyprint parameter in boot params too? |
19:07 | jnettlet | vpeter, yes |
19:08 | jnettlet | it hangs generally because it can't use the device-tree file for whatever reason |
19:09 | vpeter | good enough? earlyprintk=serial,ttymxc0,115200,keep |
19:09 | jnettlet | you should just need earlyprintk. The other parts are set in the kernel config now |
19:09 | jnettlet | but that should still work fine |
19:09 | vpeter | How do I know it is working? :) |
19:10 | jnettlet | you will see output after uncompressing kernel |
19:13 | vpeter | I see. Sending image to user to test it. |
19:15 | jnettlet | vpeter, or you could send it to me :) |
19:16 | vpeter | sure: http://vpeter.libreelec.tv/imx6-solidrun-kernel-3.14/tmp/LibreELEC-imx6.arm-8.0.1-sr-3.14-cubox-i-som-v15.img.gz |
19:28 | jnettle | 19:28 * jnettlet downloading |
19:28 | vpeter | If this works then try also original version http://vpeter.libreelec.tv/imx6-solidrun-kernel-3.14/LibreELEC-imx6.arm-8.0.1-sr-3.14.img.gz |
19:29 | vpeter | this one doesn't have serial console enabled by default (needs to set in uenv.txt). |
20:05 | mhilt | jnettlet -- are you still there? |
20:56 | jnettlet | mhilt, sure thing |
20:57 | jnettlet | just getting some chow |
20:58 | mhilt | understood -- if you have a moment, maybe you can point me in the right direction ... |
20:58 | jnettlet | sure. what do you need me to look at? |
20:59 | mhilt | I have just been having trouble getting this parallel ov5640 module to build ... |
21:00 | mhilt | I did find that it apparently built, but then was not being put into the resulting module rpm ... |
21:03 | mhilt | I tried putting that module directly into my FS ... and it seems to load with insmod but not modprobe, but does not get associated with the CSI correctly |
21:03 | mhilt | in general though, I'm not sure how I should be cleanly making these changes in Yocto ... |
21:04 | mhilt | one problem I have, is that when I rebuild core-image-x11, I lose any changes I had made before |
21:05 | mhilt | if I just compile linux-solidrun-imx6, it seems okay, but I don't get a new rootfs |
21:06 | mhilt | I guess I'm asking generally, what changes I should make to build the parallel ov5640, and then how I should build them |
21:11 | jnettlet | mhilt, well you should be able to just make the kernel config changes to the defconfig for our meta-layer. |
21:12 | jnettlet | or if you want this to be long term then make your own meta-layer and use a .bbappend to our kernel to include your defconfig with the changes you want. |
21:12 | mhilt | then should I just bitbake core-image-x11 ? |
21:12 | mhilt | or bitbake linux-solidrun-imx6 ? |
21:15 | jnettlet | for either one you will need to bitbake core-image-x11. You can use -k to only make changes since the last failure which can save some time. |
21:15 | mhilt | so the changes I should make, should be in /poky/meta-solidrun-arm-imx6/recipes-kernel/linux/linux-solidrun-imx6-3.14.1.0/defconfig ? |
21:16 | jnettlet | yes. Changing that will cause bitbake to rebuild the kernel with that configuration. |
21:17 | mhilt | okay ... so I have CONFIG_MXC_CAMERA_OV5640=m |
21:17 | mhilt | and # CONFIG_SOC_IMX6SX is not set |
21:17 | mhilt | what else should be changed to build the /capture/ov5640.c vs /subdev/ov5640.c ? |
21:18 | mhilt | with the defconfig like that, I only get the /subdev module |
21:21 | jnettlet | based on what I looked at the other day, those should be the only changes. |
21:21 | jnettlet | but wait a couple of seconds and I can verify it quickly |
21:25 | jnettlet | mhilt, actually I see the problem. NXP's build config is buggy |
21:27 | mhilt | which config? :-) |
21:27 | jnettlet | well it is buggy but it doesn't get in the way. The kernel module you should be using is. ov5640_camera_int.ko |
21:28 | mhilt | eh ... I wondered that |
21:28 | mhilt | I see in the Makefile ... ov5640_camera_int-objs := ov5640.o |
21:28 | mhilt | obj-$(CONFIG_MXC_CAMERA_OV5640) += ov5640_camera_int.o |
21:29 | mhilt | I thought the int module was somehow related to mipi ... that's not the case? |
21:30 | jnettlet | no, you should be using that. |
21:31 | mhilt | sigh ... okay, I did have that all along |
21:40 | jnettlet | mhilt, yes but does loading that find your camera? |
21:40 | mhilt | heh, was just trying ... |
21:40 | mhilt | it loads without complain |
21:40 | mhilt | but I can't use it |
21:41 | mhilt | i2c is fine |
21:41 | mhilt | would I need to change the device tree? |
21:50 | jnettlet | mhilt, it doesn't look like it. It should be using i2c to identify the device. |
21:51 | mhilt | there's no dmesg that says 'ov5640 found' ... |
21:53 | mhilt | if I change the Makefiles in /build/tmp/work-shared/solidrun-imx6/kernel-source/drivers/media/platform/mxc/capture and /subdev ... can I then build the changes with bitable core-image-x11 ? |
21:53 | jnettlet | yes and you see the device under i2c-2? |
21:53 | mhilt | I do see the device in i2c-2 ... but I do not get the 'ov5640 found' dimes |
21:53 | mhilt | ^dmesg |
21:56 | jnettlet | and you don't seen any errors? |
21:57 | jnettlet | you may want to add debug to your kernel commandline and boot with that. |
22:01 | mhilt | ... something apparently stomped on my dts changes again |
22:01 | jnettlet | mhilt, and you are using. v4l2-ctl --list-devices to check to see if the device is available? |
22:01 | mhilt | I have tried that before, but it always fails |
22:02 | mhilt | says resource unavailable |
22:02 | mhilt | to modify dts, I should edit from /build/tmp/work-shared/solidrun-imx6/kernel-source/arch/arm/boot/dts ? |
22:03 | mhilt | for some reason, some builds stomp on my changes to these |
22:04 | mhilt | to rebuild the device tree, can I edit those, then just bitbake core-image-x11 ? |
22:11 | jnettlet | for just device-tree changes I would recommend you make the changes, rebuild the package and then copy them manually over to your sdhc card |
22:12 | jnettlet | try bitbake -f -c compile virtual/kernel |
22:25 | mhilt | when I use bitbake -f -c compile virtual/kernel , I lose my device tree changes |
22:26 | mhilt | the only way I was able to get the dtb's to rebuild before, was by opening a devshell |
22:26 | mhilt | and make dtbs |
22:27 | mhilt | is this where changes should be made? /build/tmp/work-shared/solidrun-imx6/kernel-source/arch/arm/boot/dts |
22:40 | jnettlet | mhilt, well that is where the kernel source is built. but that is a temporary directory so changes aren't kept across builds |
22:43 | mhilt | yes, I've seen ... to make permanent changes then, I need make a patch? |
22:43 | jnettlet | yes |
22:44 | jnettlet | yep |
22:45 | mhilt | haha, yeah that's definitely a feature of yocto I'm not a fan of |
22:52 | jnettlet | vpeter, here that image boots to a command prompt but kodi doesn't start |
23:32 | mhilt | okay, I fixed the device tree again |
23:32 | mhilt | ov5640_camera is detected / inserted at boot |
23:33 | mhilt | but I assume that's the /subdev module, and does not work |
23:33 | mhilt | I remove that module |
23:33 | mhilt | modprobe ov5640_camera_int |
23:33 | mhilt | I see the loaded module with lsmod, but not really anything in dimes |
23:33 | mhilt | ^dmesg |