zador.blood.stained

Current CAN patch (version 8) consists of 4 parts (driver itself, kernel configs, DT config) and can be found in follow-ups to this message: http://www.spinics.net/lists/netdev/msg343137.html You'll need all 4 parts, and DT config also needs CAN section in device-specific sun7i-a20-cubieboard2.dts file, as by default in dtsi file CAN controller is disabled. By the way, mainline kernel just updated from 4.2.5 to 4.3, so right now build process most likely will fail due to outdated kernel config.

Ok. My suggestion is - make backups. No. Make backups. Still no. Make incremental backups before updating any critical packages. Now that I think... if it fails to boot after upgrade - check if you have /sbin/init, check if it is a symlink and it points to /lib/systemd/systemd and check size and md5sum of /lib/systemd/systemd. Maybe you can still win easily I didn't ask what is your OS version, but I assume it is Debian Jessie and init system is systemd.

Okay, now, assuming that you have some kind of filesystem corruption, that affects your init related files, there are two options: Easy - extract needed config files from your image and start from scratch with new image, Hard - try to repair this image.

Try adding some extra command line parameters from this page: https://wiki.freedesktop.org/www/Software/systemd/Debugging/ Start with systemd.log_level=debug systemd.log_target=console systemd.journald.forward_to_console=1 Edit: Okay, for some reason you again have wrong time. Maybe your RTC battery is dead? Or do you actually have RTC battery? Checked: you don't. I was right earlier: Now that I re-think all this, you don't have issue with time in future, that affects systemd. I should have noticed it earlier, only old kernel resets time to 1970-01-01, mainline would print 2085-something-something.

You just need to prevent loading WiFi and BT related kernel modules. With old 3.4.109 kernel you just need to comment several lines in /etc/modules. Try commenting these: hci_uart rfcomm ap6210

Posting again just so you get new message notification - if you did change time, you don't need init=/bin/bash in your boot script. Remove it and try normal boot.

Boot #3 hangs exactly in the same place, I don't have "random" line on my 4.2.3 kernel Boot #2 is interesting. It starts bash process. Did you try typing something to serial console or pressing Enter? As for #1 - this is strange. Edit: Also for #2 - try removing /etc/bash.bashrc.custom Edit 2: Sorry, missed that you did change time, looks like boot #3 has correct time. Remove init=/bin/bash from you boot script and try booting again.

Strange... Can you install (extract) latest kernel & dtb to this card from another system? Also just in case execute force check file system (fsck.ext4 -f). If it still doesn't boot and if you have spare sd card, you can try booting fresh image, if you don't - you can backup existing with dd and install new image on this card. Edit: First try adding init=/bin/bash to kernel command line, maybe there are issues starting init process. Edit 2: Also try flashing latest u-boot (next) Edit 3: Compared you log to my dmesg. Definitely init problem, most likely systemd and RTC related one. For me systemd starts right after usb devices init. You still need to boot to bash to correct RTC time.

Mainline kernel comes with new gpio driver with standart linux gpio interface, it doesn't need any DT configuration. You need to "export" pin number for it to appear in sysfs tree (I'm assuming you want sysfs access) Read section "Accessing the GPIO pins through sysfs with mainline kernel" here: https://linux-sunxi.org/GPIO

It seems like you are writing image to first partition of your sd card, but you need to write to disk itself, /dev/disk2 or /dev/rdisk2 rather then /dev/disk2s1 or /dev/rdisk2s1, if I correctly understood Mac OS disk device naming scheme.

2) Good old "Don't touch it if it works" method of dealing with stuff. 3) Those commands simply boot kernel with custom init parameter without executing boot.cmd (boot.scr), so it doesn't matter if your boot.scr was broken. Try adding loglevel=5 (or maybe 6) to bootargs and post boot log somewhere. It should work unless you have non-default setup or if I'm missing something about your board compared to mine (cubietruck). 4) Last time I checked only one console parameter was recognized by the kernel for some reason, although more than one should work in theory.

I think that in sun7i-a20-cubieboard2.dts you need to change leds { compatible = "gpio-leds"; pinctrl-names = "default"; pinctrl-0 = <&led_pins_cubieboard2>; blue { label = "cubieboard2:blue:usr"; gpios = <&pio 7 21 GPIO_ACTIVE_HIGH>; }; green { label = "cubieboard2:green:usr"; gpios = <&pio 7 20 GPIO_ACTIVE_HIGH>; }; }; to leds { compatible = "gpio-leds"; pinctrl-names = "default"; pinctrl-0 = <&led_pins_cubieboard2>; blue { label = "cubieboard2:blue:usr"; gpios = <&pio 4 11 GPIO_ACTIVE_HIGH>; }; green { label = "cubieboard2:green:usr"; gpios = <&pio 4 10 GPIO_ACTIVE_HIGH>; }; }; and led_pins_cubieboard2: led_pins@0 { allwinner,pins = "PH20", "PH21"; allwinner,function = "gpio_out"; allwinner,drive = <SUN4I_PINCTRL_10_MA>; allwinner,pull = <SUN4I_PINCTRL_NO_PULL>; }; to led_pins_cubieboard2: led_pins@0 { allwinner,pins = "PE10", "PE11"; allwinner,function = "gpio_out"; allwinner,drive = <SUN4I_PINCTRL_10_MA>; allwinner,pull = <SUN4I_PINCTRL_NO_PULL>; }; You'll need to recompile kernel (or at least device tree part) with build script to get new sun7i-a20-cubieboard2.dtb file. Alternatively you can try to decompile, change and recompile dtb file with dtc from device-tree-compiler package, but I'm not sure if it will work.

-22 is -EINVAL error. One of possible reasons may be transfer size limitation here: https://github.com/torvalds/linux/blob/master/drivers/spi/spi-sun4i.c#L178 This patch removes this limit http://lists.infradead.org/pipermail/linux-arm-kernel/2015-August/363074.html but I don't have proper hardware to test it.

Other serial devices are not enabled in Device Tree by default, you need to modify Device Tree files and compile new dtb file to enable them. Starting from here https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/sun7i-a20.dtsi#L1205 are sections for serial devices, common for all A20 devices, here https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/sun7i-a20-cubietruck.dts#L300 uart0 is enabled. You need to add similar sections for serial devices that you want, using pinctrl parameters from here https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/sun7i-a20.dtsi#L858 (which also answers your questions for pin numbers, you can check pin mappings in cubietruck schematics pdf). Use build script to recompile kernel (you only need new sun7i-a20-cubietruck.dtb file), adding, for example, this section to sun7i-a20-cubietruck.dts to activate uart2 &uart2 { pinctrl-names = "default"; pinctrl-0 = <&uart2_pins_a>; status = "okay"; }; Some uarts have different pinout variants, check schematic or maybe script.fex to find correct one. If pinctrl section lists 4 pins instead of 2, two other pins are RTS and CTS signals, you probably won't use them.

Hi. Decided to register here to comment on my instructions. 1) Seems like USB support for Lamobo R1 is not fully enabled in U-Boot config for some reason, maybe it's not supported yet, but it doesn't matter if you have serial console access. 2) Setenv fails because string gets too long if you add extra parameters like init or loglevel, can be solved by using double quotes like in this script: https://github.com/igorpecovnik/lib/blob/second/config/boot.cmd 3) Last post with fixtime.sh script was an idea for automatic debricking of new installations without user interaction, but since you have serial console, these https://github.com/igorpecovnik/lib/issues/111#issuecomment-145634651instructions shoud be more useful, try setting RTC clock manually and check if changes are still there on next boot.