00:38 | heap_ | h |
00:38 | heap_ | hi |
00:38 | heap_ | amyone alive on that channel? |
00:39 | heap_ | which distro is better debian from solidrun or armbian? |
01:12 | heap_ | is there any plan/support of deb stretch + kernel? |
01:42 | heap_ | guys i boot my cubox from external drive connected via usb... |
01:42 | heap_ | also i asume uboot spl etc is on the sd card.... and images on the sd card in /boot |
01:43 | heap_ | i did dist-upgrade... so do i have co copy /boot from external drive to /sdcard/boot ? and dd image to sd card? |
01:43 | heap_ | or whats the process? |
02:23 | heap_ | anyone can take a look on that issue -> http://forum.solid-run.com/viewtopic.php?f=10&t=3225 |
02:23 | heap_ | thanks |
03:52 | jnettlet | vpeter, why was the inverted option removed? BOB_INVERTED is a proper method which switches the field ordering. |
09:07 | heap_ | jnettlet: ? |
09:08 | jnettlet | heap_, whats up? |
09:08 | jnettlet | sorry my bouncer had to be rebooted and I don't have my backlog right now |
09:08 | heap_ | jnettlet: could you pls take a look on the issue |
09:08 | heap_ | http://forum.solid-run.com/viewtopic.php?f=10&t=3225 |
09:09 | heap_ | im so desperate ;/ |
09:12 | heap_ | hm |
09:12 | heap_ | jnettlet: should be easy for you i think? |
09:13 | jnettlet | the power problem is normal. The USB vcc is directly attached to the main 5Volt rail. So if you have a powered USB device, or HUB that puts power on the VCC it will backfeed voltage to the cubox and keep it powered. |
09:14 | heap_ | so there is no issue with that? |
09:14 | jnettlet | heap_, it looks like u-boot can't read from the first partition on your sdhc card |
09:14 | jnettlet | heap_, it won't hurt anything no. |
09:14 | heap_ | okay thanks |
09:14 | heap_ | related to the uboot |
09:15 | heap_ | can i fix it somehow? |
09:16 | heap_ | or why it cant read first partition |
09:17 | jnettlet | I would just look at the sdhc card on another machine and make sure all the proper files on first partition |
09:17 | heap_ | what do you mean by first partition? |
09:17 | heap_ | if i mount the card .. if there are files in /boot? |
09:19 | jnettlet | heap_, actually test this first. In the u-boot shell try to do env default -f -a |
09:19 | jnettlet | then boot |
09:20 | jnettlet | that will reset the env to the default |
09:20 | heap_ | ok giv eme sec |
09:21 | heap_ | by boot you mean to type boot? |
09:21 | jnettlet | yes |
09:22 | heap_ | same thing. |
09:22 | heap_ | files not found |
09:22 | heap_ | and Loading: T T T T T T T |
09:22 | jnettlet | is it looking in /boot or just / |
09:22 | heap_ | file not found /boot.scr. /uEnv.txt .../zImage |
09:22 | heap_ | why / not /boot? |
09:23 | jnettlet | I would take the SDHC card out and make sure /boot exists |
09:24 | heap_ | it does |
09:25 | jnettlet | back in u-boot type env print boot_prefixes |
09:27 | heap_ | CuBox-i U-Boot > printenv |
09:27 | heap_ | autoboot=echo Booting ${boot_file}; if test ${boot_file} = zImage; then bootz $; |
09:27 | heap_ | autodetectfdt=if test ${cpu} = 6SOLO || test ${cpu} = 6DL; then setenv fdt_pref; |
09:27 | heap_ | baudrate=115200 |
09:27 | heap_ | board=mx6-cubox-i |
09:27 | heap_ | boot_fdt=try |
09:27 | heap_ | boot_prefixes=/ /boot/ |
09:27 | heap_ | bootcmd=mmc dev ${mmcdev}; if mmc rescan; then for prefix in ${boot_prefixes}; ; |
09:27 | heap_ | bootdelay=3 |
09:27 | heap_ | bootenv=uEnv.txt |
09:27 | heap_ | bootfile=auto |
09:27 | heap_ | bootit=setenv boot_file ${bootfile}; fdt_addr_bak=${fdt_addr}; if test -n ${ram; |
09:27 | heap_ | bootscript=echo Running bootscript from mmc ...; source; |
09:27 | heap_ | console=ttymxc0 |
09:27 | heap_ | cpu=6Q |
09:27 | heap_ | ethact=FEC |
09:27 | heap_ | ethaddr=d0:63:b4:00:6b:3f |
09:27 | heap_ | ethprime=FEC |
09:27 | heap_ | fdt_addr=0x14700000 |
09:27 | heap_ | fdt_high=0xffffffff |
09:27 | heap_ | fdt_prefixes=/ /dtb/ |
09:27 | heap_ | importbootenv=echo Importing environment from mmc${mmcdev} ...; env import -t $; |
09:28 | heap_ | initrd_high=0xffffffff |
09:28 | heap_ | ip_dyn=yes |
09:28 | heap_ | loadaddr=0x10800000 |
09:28 | jnettlet | for future reference use pastebin.com for large pastes |
09:28 | heap_ | loadbootenv=load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${file_prefix}${bootenv}; |
09:28 | heap_ | loadbootfile=load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${file_prefix}${bootfile; |
09:28 | heap_ | loadbootscript=load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${file_prefix}${script; |
09:28 | heap_ | loadfdt=if test ${boottype} = mmc; then for prefix in ${fdt_prefixes}; do if lo; |
09:28 | heap_ | loadramdisk=if test ${boottype} = mmc; then load mmc ${mmcdev}:${mmcpart} ${ram; |
09:28 | heap_ | mmcargs=setenv bootargs quiet console=${console},${baudrate} root=${mmcroot}; |
09:28 | heap_ | mmcboot=echo Booting from mmc ...; run mmcargs; setenv boottype mmc; run bootit; |
09:28 | heap_ | mmcdev=0 |
09:28 | jnettlet | that looks fine. It seems like your card probably has filesystem errors |
09:28 | heap_ | mmcpart=1 |
09:28 | heap_ | mmcroot=/dev/mmcblk0p2 rootwait rw |
09:28 | heap_ | netargs=setenv bootargs console=${console},${baudrate} root=/dev/nfs ip=dhcp nf; |
09:28 | heap_ | netboot=echo Booting from net ...; run netargs; setenv boottype net; if test ${; |
09:28 | heap_ | preboot=if hdmidet; then usb start; setenv stdin serial,usbkbd; setenv stdout ; |
09:28 | heap_ | ramdisk_addr=0x14800000 |
09:28 | jnettlet | you should take it out and run fsck on it |
09:28 | heap_ | ramdisk_file=initrd |
09:28 | heap_ | script=boot.scr |
09:28 | heap_ | splashpos=m,m |
09:28 | heap_ | stderr=serial |
09:28 | heap_ | stdin=serial |
09:28 | heap_ | stdout=serial |
09:29 | heap_ | update_sd_firmware=if test ${ip_dyn} = yes; then setenv get_cmd dhcp; else sete; |
09:29 | heap_ | update_sd_firmware_filename=u-boot.imx |
09:29 | heap_ | Environment size: 4316/8188 bytes |
09:29 | heap_ | CuBox-i U-Boot > printenv bootcmd |
09:29 | heap_ | bootcmd=mmc dev ${mmcdev}; if mmc rescan; then for prefix in ${boot_prefixes}; ; |
09:29 | heap_ | ops |
09:29 | heap_ | argh@!!! sorry |
09:29 | heap_ | root@phear:/home/heap# ls /media/heap/rootfs/boot |
09:29 | heap_ | boot.scr dtb imx6q-cubox-i.dtb uEnv.txt |
09:29 | heap_ | config-3.14.60-fslc-imx6-sr dtb-3.14.60-fslc-imx6-sr System.map-3.14.60-fslc-imx6-sr zImage |
09:29 | heap_ | cubox-i-spl.bin imx6dl-cubox-i.dtb u-boot.img zImage-3.14.60-fslc-imx6-sr |
09:29 | heap_ | thats whats on the card |
09:29 | heap_ | CuBox-i U-Boot > env print boot_prefixes |
09:29 | heap_ | boot_prefixes=/ /boot/ |
09:29 | heap_ | is that ok |
09:29 | heap_ | ? |
09:31 | heap_ | root@phear:/home/heap# fsck /dev/sde1 |
09:31 | heap_ | fsck from util-linux 2.20.1 |
09:31 | heap_ | e2fsck 1.42.9 (4-Feb-2014) |
09:31 | heap_ | rootfs: clean, 42948/948416 files, 340219/3798016 blocks |
09:31 | heap_ | no issues on the card> |
09:31 | heap_ | ?\ |
09:31 | heap_ | should i somehow reflash uboot + spl ? |
09:32 | heap_ | maybe uboot or spl is corrupted? |
09:33 | heap_ | *** Warning - bad CRC, using default environment (that one line was in my original log) http://paste.debian.net/918867 |
09:36 | heap_ | jnettlet: any idea?: |
09:36 | heap_ | ?:( |
09:38 | jnettlet | heap_, SPL doesn't matter here since it is loading u-boot. |
09:38 | jnettlet | oh. Running bootscript from mmc ... |
09:38 | heap_ | ? |
09:39 | jnettlet | you have a boot.scr file in / or /boot that is being picked up and run instead of our default scripts. |
09:39 | heap_ | yeah there is that file |
09:39 | jnettlet | that must be something that you added |
09:39 | jnettlet | that has an issue |
09:39 | heap_ | yes i put it there |
09:39 | heap_ | should i remove? |
09:39 | jnettlet | that is what is failing |
09:40 | heap_ | can i remove it using uboot? |
09:41 | jnettlet | no |
09:41 | heap_ | ok let me remove it |
09:41 | heap_ | also what d oyou think ... whats better solidrun deb or armbian? |
09:43 | jnettlet | heap_, we don't support armbian |
09:44 | heap_ | so only solidrun deb has the best support? |
09:44 | jnettlet | well that is just what we provide for our customers. It goes through our QA process etc. |
09:44 | jnettlet | it moves more slowly than Armbian because we have customers using it to create products they sell |
09:46 | heap_ | ah ok |
09:46 | heap_ | but they claim armbian supports cubox |
09:47 | heap_ | also are there any plans to upgrae to new deb release? |
09:47 | heap_ | jnettlet: it boots up! you saved me. |
09:47 | heap_ | but its not working properly?:( |
09:47 | heap_ | no network |
09:47 | heap_ | let me check.. |
09:49 | heap_ | after boot it didnt take a ip address |
09:49 | heap_ | wondering why ;/ |
09:49 | heap_ | i had to run dhclient via serial link |
09:50 | heap_ | its running now Linux linux 3.14.60-fslc-imx6-sr |
09:50 | jnettlet | heap_, that is a bug caused by systemd update. Artox, needs to build a new package. |
09:50 | heap_ | is there anything specific why it havent leased ip addresS? |
09:50 | heap_ | oh ;-((( |
09:51 | heap_ | is that generic debian bug or only cubox specific? |
09:51 | jnettlet | to fix it edit /lib/systemd/system/connman.service |
09:52 | jnettlet | heap_, it is a debian bug which they have probably fixed. we have a custom connman package that fixes some bugs regarding wifi AP mode etc. |
09:52 | heap_ | ah ok |
09:52 | heap_ | so what exactly i have to fix in that file |
09:53 | vpeter | jnettlet: you read what FernetMenta thinks about bob inverted. And he remove it. I add it back and it works for a user but I'm still investigating if this could be fixed in decoder somehow. |
09:53 | jnettlet | Change these 3 lines to this. http://pastebin.com/s2SkL6fk |
09:54 | jnettlet | vpeter, I did not read what he thought about it. |
09:56 | vpeter | for bob inverted: "Have you ever seen a similar setting on a commercial STB?. I don't think so" |
09:56 | heap_ | jnettlet: still not getting ip |
09:56 | heap_ | ;/ |
09:56 | heap_ | after that change |
09:56 | jnettlet | heap_, did you reboot? |
09:56 | jnettlet | or restart the service? |
09:57 | heap_ | sure |
09:57 | heap_ | reboot |
09:57 | jnettlet | check that connman started |
09:58 | heap_ | ps aux | grep conn |
09:58 | heap_ | root 935 0.0 0.0 3668 748 pts/0 S+ 08:58 0:00 grep conn |
09:58 | jnettlet | heap_, what happens if you run sudo systemctl start connman |
09:59 | heap_ | grep conn |
09:59 | heap_ | root 940 2.3 0.0 6528 2536 ? Ss 08:59 0:00 /usr/sbin/connmand -n |
09:59 | heap_ | but why its not rnning after boot |
10:02 | jnettlet | heap_, run systemctl status connman |
10:02 | jnettlet | that should tell you |
10:03 | heap_ | it says its running |
10:03 | heap_ | now |
10:03 | jnettlet | I would reboot and check the logs. dmesg or journalctl should tell you why it failed |
10:03 | heap_ | http://paste.debian.net/918897/ |
10:05 | heap_ | hm right now there is nothing in dmesg |
10:05 | heap_ | [ 6.291004] systemd[1]: Found dependency on connman.service/start |
10:07 | heap_ | should i reboot one more time |
10:10 | jnettlet | heap_, can you post the full contents of connman.service |
10:10 | heap_ | the conf file? |
10:12 | heap_ | root@linux:/home/debian# systemctl status connman |
10:12 | heap_ | ��● connman.service - Connection service |
10:12 | heap_ | Loaded: loaded (/lib/systemd/system/connman.service; enabled) |
10:12 | heap_ | Active: inactive (dead) |
10:12 | heap_ | after boot |
10:15 | heap_ | jnettlet: http://paste.debian.net/918899/ |
10:17 | jnettlet | now use journalctl -b to look through the logs and see what failed |
10:18 | heap_ | Mar 09 09:09:41 linux systemd[1]: Found dependency on connman.service/start |
10:18 | heap_ | there is nothing related to the conman |
10:18 | jnettlet | maybe it disabled itself. run systemctl enable connman |
10:18 | heap_ | can i find whats the current status? |
10:19 | jnettlet | Artox, please look into this issue as soon as possible. connman is failing with recent debian updates |
10:19 | heap_ | jnettlet: ? |
10:20 | heap_ | so can i find out if its enabled or disabled now |
10:20 | jnettlet | heap_, sorry I am stepping out the door. just google systemctl and you can find documentation on it |
10:20 | heap_ | i did systemctl enable connman |
10:21 | heap_ | if it fails again? |
10:21 | heap_ | how can i forcce to lease a ip after boot? |
10:23 | heap_ | its broken |
10:23 | heap_ | holy lord |
10:23 | heap_ | all the time ISSUE |
10:23 | heap_ | ;-( |
10:23 | heap_ | Artox: are you there? |
10:24 | heap_ | then what QA is there as things are failing. |
10:47 | heap_ | so anyone has any view how that systemd connman bug can be fixed? |
11:04 | heap_ | this is crazy |
11:04 | heap_ | the cubox device is really dead |
11:05 | heap_ | with the support of 1 person also only if he has time |
11:05 | heap_ | this is dead for that box |
11:08 | vpeter | It's not that bad ;) |
11:08 | heap_ | it is. |
11:09 | heap_ | even worst then bad. |
11:09 | vpeter | bad, bad, bad then :D |
11:28 | heap_ | hm |
11:33 | heap_ | jnettlet: do you have link to the official bug related to that connman issue? |
12:12 | heap_ | or can i manually save the ip address or ... something |
12:19 | heap_ | huhmhuhm |
13:14 | topi`_ | vpeter: do you know anything about HDMI video modes? we have a weird display with DVI-in and we tried to display stuff on it with a Raspi3 using OpenELEC but nothing on screen... |
13:15 | topi`_ | jnettlet: I tried to change the console res on the HB via this kernel cmdline: console=ttymxc0,115200n8 console=tty root=/dev/mmcblk0p1 rootwait rw drm_kms_helper.edid_firmware=edid/1024x768.bin |
13:15 | topi`_ | but for some reason, it still pushes 1920x1080 to my screen |
13:15 | topi`_ | the "1024x768.bin" should be a builtin name, at least in 3.4 kernels |
13:17 | topi`_ | judging by the dmesg, it seems edid_load() in drm_edid_load.c isn't getting run at all |
13:24 | topi`_ | I think the kernel is missing DRM_KMS_HELPER |
13:25 | topi`_ | â Depends on: HAS_IOMEM [=y] && DRM [=y] â |
13:25 | topi`_ | do we have HAS_IOMEM for hummingboard?? |
13:25 | topi`_ | yes |
13:45 | topi`_ | if I say "grep -i kms /proc/kallsyms |
13:46 | topi`_ | I see really nothing there, except c0379a70 t drm_irq_vgaarb_nokms |
13:46 | vpeter | topi`_: not really. But I can pass this info to popcornmix on 'our' slack. |
13:46 | topi`_ | vpeter: we try to find out what is the "correct" modeline for that display... but oddly it works with 2 different PC's |
13:48 | vpeter | topi`_: You tried openelec or libreelec? |
13:50 | topi`_ | openelec I think, it was my colleague |
13:50 | topi`_ | but he may confuse the two ;) |
13:50 | topi`_ | I wish I understood more of this D EDID mess |
13:52 | vpeter | If he didn't tried libreelec it should try it. Maybe we fixed something :-) |
13:52 | topi`_ | :) |
13:55 | vpeter | "try forcing hdmi video output modes via config.txt" |
13:55 | vpeter | first response |
13:58 | vpeter | https://www.raspberrypi.org/documentation/configuration/config-txt/video.md |
13:58 | vpeter | hdmi_ignore_edid |
14:01 | vpeter | play with the HDMI modes, to get a proper resolution |
14:31 | heap_ | how can i fix network on the cubox |
14:31 | heap_ | connman is broken |
14:31 | heap_ | any other alternatives |
14:33 | vpeter | remove connman and set static IP in one script? |
14:34 | vpeter | I think I mentioned some other distro you could use? |
14:36 | heap_ | there is no point to use other distros |
14:36 | heap_ | all of them are not maintained |
14:36 | heap_ | for the cubox device |
14:37 | heap_ | i removed the connman |
14:37 | heap_ | http://paste.debian.net/918947/ |
14:37 | heap_ | but its not getting ip after reboot |
14:37 | heap_ | holy blood |
14:38 | heap_ | that fucking debian became a windows |
14:38 | vpeter | https://www.armbian.com/cubox-i/ |
14:42 | heap_ | is it tunned and maintained properly? |
14:43 | vpeter | read http://forum.solid-run.com/viewtopic.php?f=8&t=3191&p=21711&hilit=igor#p21635 |
14:44 | flips | Does this "mainline kernel images: audio does not work on all devices, Bluetooth is unstable." mean that Armbian uses mainline kernel, or that if I switch to a mainline kernel, these issues might surface? |
14:44 | flips | :) |
14:45 | vpeter | They provide 2 images with different kernel. |
14:46 | flips | ah, Mainline vs legacy |
14:47 | flips | I was hoping for a newer kernel without BT and audio issues :) Is Cubox-i and i4Pro generally compatible in this regard? |
15:28 | topi`_ | I cannot set DRM_LOAD_EDID_FIRMWARE via make menuconfig, how can I turn it on manually? By editing the .config file? |
15:30 | vpeter | Why can't you set it? |
15:30 | topi`_ | dunno. Maybe some dependency that cannot be fullfilled |
15:31 | topi`_ | usually make menuconfig won't allow you to choose soemthing stupid, e.g. VESA support on a imx6 :) |
15:31 | vpeter | Do yuo have other DRM things enabled? |
15:31 | topi`_ | now it compiled it as a module even though I said "Y" not "M"... what gives? |
15:31 | topi`_ | CC [M] drivers/gpu/drm/drm_edid_load.o |
15:32 | topi`_ | I think this clearly states that drm_edid_load has been compiled as a module, and not baked into the kernel as I wished |
15:32 | topi`_ | damn |
15:34 | topi`_ | found it, DRM_KMS_HELPER was a module, not builtin |
15:57 | topi`_ | is there a tool on the default solid-run debian image to resize the / fs on sdcard? |
15:57 | topi`_ | 2.7 GB for / is a bit too little |
16:37 | topi`_ | vpeter: usual DRM stuff as what is enabled in the 3.14 kernel |
17:40 | topi`_ | I wonder what's the difference between "normal" edid funcs and this imx6 specific edid stuff |
18:59 | topi`_ | it seems "modetest" from mesa/drm tree does not work with vivante |
18:59 | topi`_ | it's trying to open numerous devices, like "tegra" and "msm", no vivante nowhere to be seen... |
19:00 | topi`_ | trying to open device 'imx-drm'...failed |
19:00 | topi`_ | why?? |
19:02 | wumpus | imx-drm is the one that you need for imx6, however not sure what minimum kernel version you need for using that |
19:02 | topi`_ | I have that 3.14.x from the fslc tree |
19:02 | topi`_ | [ 1.036691] [drm] Initialized vivante 1.0.0 20120216 on minor 0 |
19:03 | topi`_ | this is the message from drm initialization, maybe "modetest" requires DRM KMS to work, and not just "Plain" DRM |
19:03 | topi`_ | I guess DRM can exist without KMS support |
19:03 | wumpus | yes that may be too old |
19:03 | wumpus | vivante has nothing to do with the imxdrm |
19:04 | wumpus | that's vivante's GPL driver it uses a completely different interface |
19:07 | wumpus | at least at the last time I checked they rendered to /dev/fb only, not to DRM buffers |
19:31 | vpeter | topi`_: from popcornmix - Since January 18 firmware, we use hdmi drive if any CEA (TV style) modes are reported as supported, even if preferred mode is DMT (computer monitor). That means you get working audio in more cases with a computer monitor that has audio support. No need to ignore edid. It should usually just work. If not then hdmi_drive=2 is worth a try. If that fails you could also choose a CEA mode (e.g. 1080p60: hdmi_group=1 hdmi_mode=16). |
19:57 | heap_ | vpeter: ok, thanks |