07:30 | jnettlet | topi`, sorry for the late response. Just recovering from a short run of the flu. Too much germ exposure in transit the last week. For the HB2 on our images and device-tree basically all the pin header is configured as gpios |
07:31 | jnettlet | and libwiringX has support for the HB2 now in their git repo. |
07:57 | purch | apt-get says: err http://download.solid-run.com/pub/solidrun/cubox/repo/debian/dists/cubox/main/binary-armhf/Packages: 302 Moved Temporarily |
07:57 | purch | where and are they coming back? |
08:03 | purch | rabeeh: |
08:19 | jnettlet | purch, which image is this? |
08:22 | jnettlet | Over 6 months ago we moved all our BSP packages to their own servers. |
08:22 | jnettlet | malte_, can you look into the URL that purch shoes as broken above? We should get that to redirect to repo.solid-build.xyz. |
09:30 | jnettlet | malte_, can you look into the URL that purch shoes as broken above? We should get that to redirect to repo.solid-build.xyz. |
09:30 | jnettlet | purch apt-get says: err http://download.solid-run.com/pub/solidrun/cubox/repo/debian/dists/cubox/main/binary-armhf/Packages: 302 Moved Temporarily |
15:04 | topi` | jnettlet: I looked at github/wiringx/wiringx and it seemed to me it only supports the original HB |
15:04 | jnettlet | topi`, HB2 support was just recently added. |
15:04 | topi` | hmm, let me see |
15:06 | jnettlet | topi`, it is still in the rewrite branch which hasn't been merged yet. |
15:06 | topi` | OK,that's why |
15:06 | topi` | I was looking at the master branch |
15:07 | topi` | how do I decipher from the wiringx source code which GPIO number goes to which pin? |
15:08 | topi` | many connectors on the Gate/Edge ;) most of the gpios seem to be in J23 and J24 |
15:10 | jnettlet | topi`, you can see the map at the top of the code. https://github.com/wiringX/wiringX/blob/rewrite/src/platform/solidrun/hummingboard_gate_edge_sdl.c |
15:11 | jnettlet | remember wiringX remaps the GPIOs to a standard enumeration. So GPIO 1 is gpio 1 on HummingBoard Pro, Edge, Raspberry Pi, etc etc. |
15:11 | jnettlet | a generic abstraction for IO |
15:12 | topi` | funny |
15:12 | topi` | it's odd to think that GPIOs would NOT be somehow platform specific :) |
15:13 | topi` | nice, there's an ASCII map of the connectors in that .c file :) |
15:13 | topi` | I guess these numbers are those that get mapped by wiringX? |
15:13 | topi` | those abstract gpio numbers |
15:15 | jnettlet | I haven't looked closely at the rewrite, but that is how it is supposed to work yes. |
15:16 | jnettlet | I also need to write an abstraction specifically for the Microbus interface. I think it should be numbered consistently for all boards that implement it. |
15:17 | topi` | yes |
15:18 | topi` | I think SR was one of the early adopters of mikroBUS, right? |
15:18 | topi` | I certainly hadn't heard anything about it before |
15:22 | jnettlet | yes, while not perfect it is a nice option for quick prototyping. While I was down at the Arrow conference I ran into 2 other companies have that adopted it now. |
15:22 | jnettlet | so it is gaining traction and MicroElectronica is turning out lots and lots of clikboards. |
15:23 | vpeter | Is it just me thinking that clickboards are expensive? |
15:24 | jnettlet | I think they are expensive. I would like to see them priced at about 30% less |
15:25 | jnettlet | but if they are for prototyping and saving a developers time then it is very easy for a company to justify a few extra dollars |
15:25 | jnettlet | I think they are priced more at hardware companies and not necessarily hobbyists unfortunately |
15:26 | topi` | GPIOs work, thanks a lot! |
15:26 | jnettlet | excellent |
15:26 | topi` | jnettlet: clickboards are a good fit for a compnay like ours... since we don't have earlly an "real" hardware guys |
15:26 | topi` | it makes it easy to do prototypes without actually getting hands dirty |
15:27 | topi` | I think it's possible to get "volume pricing" from mikroelektronika |
15:28 | topi` | but they do seem to have a monopoly on the clikc boards :) |
15:28 | topi` | now, the display itself seems to work, but I cannot write new content onto it :) |
15:28 | topi` | so something fishy about the IOCTLs that I use to write to /ev/spi* |
15:29 | topi` | there's only one command that gets through. the CLEAR DISPLAY command :) |
15:29 | topi` | I think it only takes two bytes. the CMD byte and a single pad byte of zero |
15:29 | jnettlet | well sounds like good progress. |
15:29 | topi` | I think i'll try writing bytes straight down to /dev/spi* |
15:29 | topi` | it should support that as well |
15:30 | topi` | basically, I took a project destined for Arduino and tried to replicate the spi writing on linux |
15:30 | topi` | most of the Adafruit boards have only arduino examples .( |
15:31 | jnettlet | I think there are some projects on github that support various SPI displays under Linux |
15:32 | topi` | I'm looking at a source made by someone else :) |
15:32 | topi` | it actually just setups the /dev/spi* and then writes to it with plain wite() calls |
15:32 | topi` | write() |
15:32 | topi` | this one: https://github.com/wrobell/smemlcd |
15:33 | jnettlet | looks decent. Would be better if it use WiringX :) |
15:39 | topi` | for odd reasons, raspberry pi folks don't use wiringx |
15:40 | topi` | they barely know of its existence |
15:41 | jnettlet | that is because they always had wiringPi. |
15:42 | jnettlet | We originally wanted to integrate support for the HB there, but the developer was not very friendly. Basically he refused to support anything that wasn't a Pi for kind of deluded reasons. |
15:44 | jnettlet | Anyways curlymo wrote a port originally called wiringHB I think and I told him that writing another library was the wrong way to do it and it should be modular for lots of different boards. |
15:44 | jnettlet | after an initial bout of anger at my criticism :) He came around and has created a great project. |
16:12 | crazystick | just wanted to chime in here on HB / SPI / WiringX |
16:12 | crazystick | since I added the SPI support to WiringX for the HB originally |
16:13 | crazystick | there's still an open PR here https://github.com/SolidRun/linux-imx6-3.14/pull/19 |
16:14 | crazystick | I am using Arch Linux ARM and they use an alternative kernel |
16:14 | jnettlet | crazystick, yes that is for the old kernel. I thought I had merged it for the new kernel when I added HB2 support but apparently I dropped that patch somehow. |
16:14 | jnettlet | topi`, pointed it out to me and I will merge it soon. |
16:14 | crazystick | I don't have a HB2 yet, but i will be keen to test it out soon. |
16:15 | jnettlet | crazystick are you interested in adding MicroBus support to WiringX? We need that for both HB2 and ClearFog boards. |
16:19 | crazystick | i don't know much about it. looking now, i might be interested in the GSM module |
16:27 | crazystick | looks pretty interesting. I haven't really looked in detail at the new HB (since I still can't buy one in the UK) |
16:27 | crazystick | i like the DC jack and integrated battery holder :) |
21:41 | heap_ | hi |
21:42 | heap_ | how can i boot cubox debian into safe mode? |
21:42 | heap_ | to skip to mount one device in fstab |
21:42 | heap_ | ? |
21:58 | Artox | heap_, there is no automatic mechanism |
21:59 | Artox | but you can add "init 3" to bootargs |
21:59 | Artox | err init 1 |
22:03 | heap_ | hi |
22:03 | heap_ | i managed it |
22:03 | heap_ | i dont know what the fucking holy crap happened |
22:04 | heap_ | but all worked fine now when i mount btrfs kernel panic |
22:04 | heap_ | and cubox die |
22:04 | heap_ | https://bpaste.net/show/98732bc6ce49 |
22:05 | heap_ | https://bpaste.net/show/0455daa876de |
22:05 | heap_ | and this |