[no HDMI with kernel 4.19]

Just updated to 5.85 with 4.19-41-cubox kernel. I don't see the unknown symbol messages. I do lose the hdmi output though. If I add 'imxdrm' to 'etc/modules', my monitor turns on just like before (after a reboot).

 

[no HDMI with kernel 4.19]

I also lost hdmi... After some searches I decided to try: "sudo insmod /lib/modules/4.19.20-cubox/kernel/drivers/gpu/drm/imx/imxdrm.ko" (If I understand correctly, this insert a kernel module that I did see on the previous kernel, but not on this one with lsmod). I instantly got output on my monitor.

I've also tried adding this module (imxdrm) to /etc/modules. This also helps, although you only get a picture on your monitor when the login is reached... so you don't see startup-messages.

 

Now lets hope that:

1. this also works for you, and

2. someone who is knowledgeable reads this and knows an easy fix (and shares it ).

 

 

[Hummingboard Gate Mikrobus (UART3) RS485]

This post is, more or less, a continuation of something I started here, but adapted to Armbian. I will start with an overview of what I have done (maybe this is relevant) and finish with my questions.

 

What I've done:

I have a Hummingboard Gate with a Mikrobus RS485 click 3.3V (this one: https://www.mikroe.com/rs485-33v-click). In order to make this work I need to change a few things in de device tree.

The dtb that my board uses is 'imx6dl-hummingboard2.dtb' so I copy that file to my home directory for safe keeping.

cd ~
sudo cp /boot/dtb-4.19.18-cubox/imx6dl-hummingboard2.dtb .

Then I convert this dtb to a dts:

sudo dtc -I dtb -O dts -o imx6dl-hummingboard2.dts imx6dl-hummingboard2.dtb

I looked for the pwm1grp to find the phandle of the group that is using the pin I need to use as the RTS-pin. Using this phandle I find 'pwm@2080000' in which I change the status to 'disabled'. If I understand correctly, this will free the pin for RTS use (but I might be wrong... Device trees might as well be magic to me).

 

Next I find uart3. This is the uart that is on the Mikrobus-connector. For the clickboard I use, I need to swap RX en TX (don't ask me why). I change the uart3-entry from:

hummingboard2-uart3 {
	fsl,pins = <0x168 0x538 0x0 0x2 0x0 0x1b0b1 0x164 0x534 0x90c 0x2 0x0 0x40013000>;
	phandle = <0x4b>;
};

to:

hummingboard2-uart3 {
	fsl,pins = <0x168 0x538 0x90c 0x2 0x1 0x1b0b1 0x164 0x534 0x0 0x2 0x0 0x1b0b1>;
	phandle = <0x4b>;
};

This switches the RX en TX function on the pins. Note that I do not completely understand the significance of the "0x40013000" and "0x1b0b1". Perhaps I have chosen the wrong value (see question 2 below).

Using the phandle in uart3, I find the serial-definition that I am using: "serial@21ec000". This is the serial to which I add definition for the rs485. I end up with:

serial@21ec000 {
	compatible = "fsl,imx6q-uart", "fsl,imx21-uart";
	reg = <0x21ec000 0x4000>;
	interrupts = <0x0 0x1c 0x4>;
	clocks = <0x4 0xa0 0x4 0xa1>;
	clock-names = "ipg", "per";
	dmas = <0x13 0x1d 0x4 0x0 0x13 0x1e 0x4 0x0>;
	dma-names = "rx", "tx";
	status = "okay";
	pinctrl-names = "default";
	pinctrl-0 = <0x4b>;
	rs485-rts-delay = <0x0 0xc8>;
	linux,rs485-enabled-at-boot-time;
	rts-gpios = <0x2f 0x1d 0x0>;
};

I've added the last 3 entries. The rest is unchanged.

I now compile the changed dts with:

sudo dtc -I dts -O dtb -o imx6dl-hummingboard2-changed.dtb imx6dl-hummingboard2.dts

And copy the result to the dtb-directory (See question 1 below).

sudo cp imx6dl-hummingboard2-changed.dtb /boot/dtb-4.19.18-cubox/imx6dl-hummingboard2.dtb

Now I reboot my board and the result is a board with a working rs485 connection.

 

I use this board to communicate with a modbus-rs485-device. Every now and then I see the following error message in syslog: "localhost kernel: imx-uart 21ec000.serial: DMA transaction error." Luckily this doesn't completely disturb the board. It is able to continue (see question 3 below).

 

My questions:

Question 1: Right now I am overwriting the dtb in /boot/dtb-4.19.18-cubox/ with my custom dtb. Is there a better way to do this?

Question(s) 2: Am I using the right values in the RX/TX-swap? Any idea how I would find this out?

Question(s) 3: What does the "imx-uart 21ec000.serial: DMA transaction error." mean? Any ideas how to fix it? (I've tried searching the web, but to no avail as of yet... as I said before: "Device trees might as well be magic to me").

[U-boot version question]

Hi,

 

I've just created a SD-card with Armbian Bionic (mainline kernel 4.19.y) for a Hummingboard Gate. I noticed during boot that it says it uses U-boot version 2013.10-rc4. This seems quite old compared to the 2018 version that was on the Debian Stretch image from SolidRun. I've tried to search the internet to see what the impact of something like this is and wasn't able to find something that made sense to me (could be entirely my fault). I therefore have the question:

 

Is the U-boot version intentional? (maybe it has some features that newer versions have dropped.)