[CuBox-I] make kernel 3.0.35 available #568

CurlyMoo · 2014-07-02T15:43:49Z

This was the conversion i had with rabeeh:

[17:36] <curlymo> still can't get lirc to work :(
[17:36] <@rabeeh> curlymo: on LK 3.0.35 i typically cat /etc/lirc0
[17:37] <@rabeeh> on 3.10 i don't know if we have on the right gpio !
[...]
[17:40] <@rabeeh> curlymo: if you want; you can switch to LK 3.0.35; GPIOs are already configured there !
[17:40] <curlymo> does it have btrfs support?
[17:40] <@rabeeh> and IR already working (and mini pcie, msata, audio etc...)
[17:40] <@rabeeh> nop; btrfs should be on more recent kernels
[17:40] <@rabeeh> i think mk01 has patched btrfs on xbian
[17:40] <curlymo> not sure if 3.0.35 is available on XBian
[17:41] <@rabeeh> it's not
[...]

The text was updated successfully, but these errors were encountered:

mk01 · 2014-07-02T18:55:18Z

why would anyone want 3.0.35 ???

CurlyMoo · 2014-07-02T18:56:19Z

Did you read it. With the current kernel GPIO, IR, msata, pcie all doesn't work.

mk01 · 2014-07-02T18:56:45Z

you are joking, right ?

[    2.264229] lirc_dev: IR Remote Control driver registered, major 247 
[    2.264438] Registered IR keymap rc-empty
[    2.264695] input: gpio_ir_recv as /devices/soc0/ir-receiver.22/rc/rc0/input0
[    2.264832] rc0: gpio_ir_recv as /devices/soc0/ir-receiver.22/rc/rc0

CurlyMoo · 2014-07-02T18:57:08Z

Did you actually try to receive with mode2, could you switch a led with the GPIO, connect something to the mini-pcie etc?

All doesn't work...

mk01 · 2014-07-02T19:00:03Z

sure

root@cubox:~# mode2
pulse 4483
space 4556
pulse 476
space 1762
pulse 613
space 1657
pulse 453
space 1757
pulse 483
space 665
pulse 453
space 644

CurlyMoo · 2014-07-02T19:00:15Z

How?

Also, a Hummingboard?

mk01 · 2014-07-02T19:03:34Z

ok, I will be polite again. ;) although this was few times step by step described around march at xbian thread on cubox-i forums. and is not about XBian.

to emulate old fashioned LIRC interface, one has to load ir-lirc-codec. this translates from rc0 to LIRC and creates /dev/lirc*
from this point it's like before with LIRC driver

(it is because the new IR keymaps as preferred way handling IRs)

CurlyMoo · 2014-07-02T19:04:40Z

root@cubox:~# lsmod
Module                  Size  Used by
ir_lirc_codec           3584  0
loop                   11220  2
frandom                 3316  0
f2fs                   86980  0

root@cubox:~# ls -Al /dev/lirc*
crw-rw---- 1 root video 246, 0 Jul  2 16:46 /dev/lirc0

But mode2 does nothing.

mk01 · 2014-07-02T19:05:33Z

does ir-keytable show you have LIRC supported and actually enabled as protocol ?

mk01 · 2014-07-02T19:06:33Z

root@cubox:~# ir-keytable
Found /sys/class/rc/rc0/ (/dev/input/event0) with:
Driver gpio-rc-recv, table rc-empty
Supported protocols: LIRC
Enabled protocols: LIRC
Name: gpio_ir_recv
bus: 25, vendor/product: 0001:0001, version: 0x0100
Repeat delay = 500 ms, repeat period = 125 ms

if not

root@cubox:~# ir-keytable -p LIRC
Protocols changed to LIRC

mk01 · 2014-07-02T19:07:15Z

what RC you have ? I have only Apple and Samsung and result I posted.

CurlyMoo · 2014-07-02T19:08:08Z

Remote shouldn't matter to mode2. It should just output raw pulses.

mk01 · 2014-07-02T19:08:08Z

maybe you have sticker over the IR input ;)

mk01 · 2014-07-02T19:08:34Z

YES

but the cubox-i receiver has limited range. for instance 35k (XBOX) is out of range for it.
and If I remember right, Panasonic RC5 is 35k

CurlyMoo · 2014-07-02T19:10:50Z

maybe you have sticker over the IR input ;)

I even checked 😄

but the cubox-i receiver has limited range

Of course i tested it holding it before the IR sensor.

mk01 · 2014-07-02T19:11:37Z

of course spectrum, not distance. (i know you know)

CurlyMoo · 2014-07-02T19:12:50Z

As if i'm always that clever....

CurlyMoo · 2014-07-02T19:14:38Z

[21:14] <rabeeh> it's a simple GPIO based IR sensor
[21:14] <rabeeh> 38khz

So yes, it's compatible.

CurlyMoo · 2014-07-02T19:16:44Z

What does this say at your device?

root@cubox:~# cat /sys/kernel/debug/gpio
GPIOs 0-31, platform/209c000.gpio, 209c000.gpio:
 gpio-0   (usb_h1_vbus         ) out hi
 gpio-4   (2194000.usdhc cd    ) in  lo

GPIOs 32-63, platform/20a0000.gpio, 20a0000.gpio:

GPIOs 64-95, platform/20a4000.gpio, 20a4000.gpio:
 gpio-73  (gpio-ir-recv        ) in  hi
 gpio-83  (brcm_reg            ) out hi
 gpio-86  (usb_otg_vbus        ) out hi

GPIOs 96-127, platform/20a8000.gpio, 20a8000.gpio:
 gpio-111 (phy-reset           ) out lo

GPIOs 128-159, platform/20ac000.gpio, 20ac000.gpio:
 gpio-133 (brcm_osc_reg        ) out hi
 gpio-154 (card-reset          ) out hi

GPIOs 160-191, platform/20b0000.gpio, 20b0000.gpio:
 gpio-160 (card-reset          ) out hi

GPIOs 192-223, platform/20b4000.gpio, 20b4000.gpio:

mk01 · 2014-07-02T19:17:34Z

root@cubox:~# cat /sys/kernel/debug/gpio
GPIOs 0-31, platform/209c000.gpio, 209c000.gpio:
gpio-0 (usb_h1_vbus ) out lo
gpio-4 (2194000.usdhc cd ) in lo

GPIOs 32-63, platform/20a0000.gpio, 20a0000.gpio:

GPIOs 64-95, platform/20a4000.gpio, 20a4000.gpio:
gpio-73 (gpio-ir-recv ) in hi
gpio-83 (brcm_reg ) out hi
gpio-86 (usb_otg_vbus ) out lo

GPIOs 96-127, platform/20a8000.gpio, 20a8000.gpio:
gpio-111 (phy-reset ) out lo

GPIOs 128-159, platform/20ac000.gpio, 20ac000.gpio:
gpio-133 (brcm_osc_reg ) out hi
gpio-154 (card-reset ) out hi

GPIOs 160-191, platform/20b0000.gpio, 20b0000.gpio:
gpio-160 (card-reset ) out hi

GPIOs 192-223, platform/20b4000.gpio, 20b4000.gpio:

mk01 · 2014-07-02T19:17:39Z

the same

CurlyMoo · 2014-07-02T19:18:18Z

It simply doesn't work here. @rabeeh told me to test 3.0.35. Also, the TSOP4838 (also 38Khz) does work on the Raspberry Pi.

mk01 · 2014-07-02T19:31:19Z

then go for it. I purged in Feb. completely. create new config in xbian-package-kernel. from rabeehs repo. https://github.com/rabeeh/linux.git

you don't have to stick with uImage as this is about u-boot, not kernel. just that 3.0.35 doesn't support DTBs. it is all hardcoded in kernel. so you have to specifically build for one of quad/duo/uno.

CurlyMoo · 2014-07-02T19:33:06Z

I have the Hummingboard i2ex

mk01 · 2014-07-02T19:38:09Z

(no idea) best resource there ever is Rabeeh. he started with that only option available back than and tried his best to provide a working combo (cubox with linux). but 3.0.35 is simply that much prehistoric that you simply don't want that. kernel itself is spending so much time with just running itself ... brrr

mk01 · 2014-07-02T19:38:40Z

(ach forgot point. at the time we had 3,0.35 Humming was only at design board)

CurlyMoo · 2014-07-02T19:39:59Z

He says it's the only kernel working properly with the HB. Two other options:

Fix it ourselves.
Wait for it to be fixed.

My idea about 1 is the remove the IR receiver support and put the lirc_rpi module back in so we read the gpio 73 manually.

mk01 · 2014-07-02T19:41:05Z

and with loop returning to DTB . ARM has no bios, such info is hardcoded (was), kernels since ??? separated that from kernel (via DTB). because there is separate dtb file for humming it means this info is different and needs to be implemented as target conf in system options (target machine support). if this was done for hum to 3.0.35 I don't know.

CurlyMoo · 2014-07-02T19:43:38Z

What HB do you have?

mk01 · 2014-07-02T19:56:04Z

I don't have HB

I'm still applying the LIRC patches, but XBOX doesn't build and lirc_rpi is probably conflicting with the in kernel driver. never tried turning the core off. you can. do you want access to the build machine like anaconda has ?

mk01 · 2014-07-02T20:00:15Z

open ./arch/arm/boot/dtb/ ... this are just text files. mostly written by Russell King. I check often against vanilla 3.14

CurlyMoo · 2014-07-02T20:00:42Z

And are those loading at boot time or when compiling the kernel?

mk01 · 2014-07-02T20:03:03Z

like I said earlier. it was stupid to compile it in (as you create non transferable kernel). so DTB are like additional info kernel can load during boot. if you check the XBian boot script, based on uboot variables correct dtb file is loaded with kernel just one.

the dtb files are targets as zImage. so for instance the configuration for building is

config_build_targets=zImage modules imx6dl-cubox-i.dtb imx6q-cubox-i.dtb imx6dl-hummingboard.dtb

mk01 · 2014-07-02T20:03:41Z

so once you update the text file in dtb/ you run "make name.dtb"

CurlyMoo · 2014-07-02T20:04:18Z

My idea would to remove these lines:
https://github.com/SolidRun/linux-linaro-stable-mx6/blob/linux-linaro-lsk-mx6/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi#L15-L20

mk01 · 2014-07-02T20:04:27Z

just to have idea WHAT it is (I know you know), with x86 it is loaded from BIOS. ARM has no such thing.

CurlyMoo · 2014-07-02T20:05:34Z

I don't know but i never needed it :)

mk01 · 2014-07-02T20:06:44Z

you can just copy that file to another name, "make new_name.dtb" and load it from boot.scr instead the standard.

mk01 · 2014-07-02T20:07:34Z

I see it is part of imx6dl-hummingboard.dtb ... wait, I will post you just the dtb. changed as you want.

mk01 · 2014-07-02T20:12:09Z

get http://ivka57.dyndns-ip.org/others/imx6dl-hummingboard.dtb

CurlyMoo · 2014-07-02T20:12:40Z

Can't open it

CurlyMoo · 2014-07-02T20:49:47Z

root@cubox:/# wget http://ivka57.dyndns-ip.org/others/imx6dl-hummingboard.dtb
--2014-07-02 22:49:25--  http://ivka57.dyndns-ip.org/others/imx6dl-hummingboard.dtb
Resolving ivka57.dyndns-ip.org (ivka57.dyndns-ip.org)... failed: Name or service not known.
wget: unable to resolve host address âivka57.dyndns-ip.orgâ

mk01 · 2014-07-02T21:35:53Z

.com
(not .org)

CurlyMoo · 2014-07-02T21:46:46Z

root@cubox:~# md5sum /boot/imx6dl-hummingboard.dtb
817071a32b6be6c0640adb991ee542a1  /boot/imx6dl-hummingboard.dtb

root@cubox:~# cat /sys/kernel/debug/gpio
GPIOs 0-31, platform/209c000.gpio, 209c000.gpio:
 gpio-0   (usb_h1_vbus         ) out hi
 gpio-4   (2194000.usdhc cd    ) in  lo

GPIOs 32-63, platform/20a0000.gpio, 20a0000.gpio:

GPIOs 64-95, platform/20a4000.gpio, 20a4000.gpio:
 gpio-73  (gpio-ir-recv        ) in  hi
 gpio-83  (brcm_reg            ) out hi
 gpio-86  (usb_otg_vbus        ) out hi

GPIOs 96-127, platform/20a8000.gpio, 20a8000.gpio:
 gpio-111 (phy-reset           ) out lo

GPIOs 128-159, platform/20ac000.gpio, 20ac000.gpio:
 gpio-133 (brcm_osc_reg        ) out hi
 gpio-154 (card-reset          ) out hi

GPIOs 160-191, platform/20b0000.gpio, 20b0000.gpio:
 gpio-160 (card-reset          ) out hi

GPIOs 192-223, platform/20b4000.gpio, 20b4000.gpio:

Didn't work. Is there a way to check what dtb file was used?

I also noticed some difference in the dtb files:

- model = "SolidRun HummingBoard Solo/DualLite";
- compatible = "solidrun,hummingboard/dl", "fsl,imx6dl";
+ model = "SolidRun HummingBoard DL/Solo";
+ compatible = "solidrun,hummingboard", "fsl,imx6dl";

The DualLite is the new one you sent me, the Solo is the original from XBian... Maybe we need two HB dtb files?

mk01 · 2014-07-03T01:57:23Z

what you need to check / change there ? those pins and signals are defined in imx6sl.dtsi and imx6qsl.dtsi

mk01 · 2014-07-03T01:58:19Z

in dmesg output check ~4th line

Machine: Freescale i.MX6 Quad/DualLite (Device Tree), model: SolidRun Cubox-i Dual/Quad

mk01 · 2014-07-03T01:59:41Z

you want to disable the 73 ?

CurlyMoo · 2014-07-03T08:37:14Z

[    0.000000] Machine: Freescale i.MX6 Quad/DualLite (Device Tree), model: Soli
dRun Cubox-i Dual/Quad

I want to disable the automatiic assignment of GPIO 73 to gpio-ir-recv

mk01 · 2014-07-03T10:08:46Z

what about

cd /sys/bus/platform/drivers/gpio-rc-recv
tree
echo -n "ir-receiver.22" > /sys/bus/platform/drivers/gpio-rc-recv/unbind
tree

GPIOs 64-95, platform/20a4000.gpio, 20a4000.gpio:
 gpio-83  (brcm_reg            ) out hi    
 gpio-86  (usb_otg_vbus        ) out lo

CurlyMoo · 2014-07-03T10:15:32Z

tree

Should it be installed by default? Because it's not...

Doesn't work. It indeed removes the gpio lock but reading the interrupts of gpio 73 manually doesn't work either.

CurlyMoo · 2014-07-03T10:34:20Z

I'm currently compiling my own kernel so i can experiment a bit. How can i safely deploy it?

mk01 · 2014-07-03T13:14:41Z

@CurlyMoo

you are just teasing me, tell me. the build script will provide you with .deb which you install with dpkg as written on the wiki. you have edited it, you know that.
and for building kernel you don't need even buildroot to deploy. so clone xbian repo (20k) and run kernel building.

for what reason should you be doing differently ? tell me.

CurlyMoo · 2014-07-03T13:16:31Z

Got it. Didn't use the build scripts. Just ran a normal compilation. I only wanted to know if I needed to take care of something in regard of u-boot and such.

mk01 · 2014-07-04T01:41:17Z

@CurlyMoo

not in case XBian kernel package was already installed before. In that case you can simply replace files.
(assuming kernel 3.10. in case 3.0.35 you have create uImage, then .dtb, then cat dtb >> uImage and mkimage "convert")

also I know YOU can compile kernel on your own but to have comparable situation you have to deal with the patches - there was my point going to.

CurlyMoo · 2014-07-04T08:20:37Z

If i can assume all patches are placed in the xbian-patches repository then i have them and YOU know i have them, because i already did some pull-requests 😄

mk01 · 2014-07-19T03:33:06Z

you see and this is exactly why I asked you to at least clone one new "converted repo". because despite my discussion with @anaconda on your request we told there that content of xbian-patches will move to their respective package repositories, binary copies removed and what will stay will be just config + patches for the build scri[pt to be able to generate same .deb but on its own. and of course if you clone kernel repo convenient would be to have all dependencies at once without playing Colombo what more is missing and where it can be found.

so no problem there maybe only that sometimes it makes sense listen to me too :)

I just removed folders from xbian-patches repo which are no more used from that location. some others will follow and have no clue what about the rest - this were packages Fred was taking care of but have not heard of him for a long time.

CurlyMoo · 2014-08-19T08:45:31Z

Because of the (apparent) availability of LTS kernel 3.14.14 (which should also have GPIO fixed) this issue is obsolete. See also #597.

CurlyMoo · 2014-08-27T18:21:28Z

I can confirm that the latest XBian kernel compilation (of the latest linaro sources) fixes both GPIO and IR. As soon as BTRFS is working as well, i'm ready to replace my Raspberry Pi with a Hummingboard

anaconda added the CuBox-i / HB label Jul 3, 2014

CurlyMoo closed this as completed Aug 19, 2014

[CuBox-I] make kernel 3.0.35 available #568

[CuBox-I] make kernel 3.0.35 available #568

Comments

CurlyMoo commented Jul 2, 2014

mk01 commented Jul 2, 2014

CurlyMoo commented Jul 2, 2014

mk01 commented Jul 2, 2014

CurlyMoo commented Jul 2, 2014

mk01 commented Jul 2, 2014

CurlyMoo commented Jul 2, 2014

mk01 commented Jul 2, 2014

CurlyMoo commented Jul 2, 2014

mk01 commented Jul 2, 2014

mk01 commented Jul 2, 2014

mk01 commented Jul 2, 2014

CurlyMoo commented Jul 2, 2014

mk01 commented Jul 2, 2014

mk01 commented Jul 2, 2014

CurlyMoo commented Jul 2, 2014

mk01 commented Jul 2, 2014

CurlyMoo commented Jul 2, 2014

CurlyMoo commented Jul 2, 2014

CurlyMoo commented Jul 2, 2014

mk01 commented Jul 2, 2014

mk01 commented Jul 2, 2014

CurlyMoo commented Jul 2, 2014

mk01 commented Jul 2, 2014

CurlyMoo commented Jul 2, 2014

mk01 commented Jul 2, 2014

mk01 commented Jul 2, 2014

CurlyMoo commented Jul 2, 2014

mk01 commented Jul 2, 2014

CurlyMoo commented Jul 2, 2014

mk01 commented Jul 2, 2014

mk01 commented Jul 2, 2014

CurlyMoo commented Jul 2, 2014

mk01 commented Jul 2, 2014

mk01 commented Jul 2, 2014

CurlyMoo commented Jul 2, 2014

mk01 commented Jul 2, 2014

CurlyMoo commented Jul 2, 2014

mk01 commented Jul 2, 2014

mk01 commented Jul 2, 2014

mk01 commented Jul 2, 2014

CurlyMoo commented Jul 2, 2014

CurlyMoo commented Jul 2, 2014

mk01 commented Jul 2, 2014

CurlyMoo commented Jul 2, 2014

mk01 commented Jul 3, 2014

mk01 commented Jul 3, 2014

mk01 commented Jul 3, 2014

CurlyMoo commented Jul 3, 2014

mk01 commented Jul 3, 2014

CurlyMoo commented Jul 3, 2014

CurlyMoo commented Jul 3, 2014

mk01 commented Jul 3, 2014

CurlyMoo commented Jul 3, 2014

mk01 commented Jul 4, 2014

CurlyMoo commented Jul 4, 2014

mk01 commented Jul 19, 2014

CurlyMoo commented Aug 19, 2014

CurlyMoo commented Aug 27, 2014