le51

March 15

Excellent news here: I've finally found my ili9488 display and, even better, I've got it to work with https://github.com/KungfuPancake/v0_ips_touch_display/blob/main/panel-mipi-dbi-spi.txt

I had to remove

command 0x21

which is specific for IPS displays (mine is TN) to get a correct color rendering.

But unfortunately all my attempts with the ili9486 display ends up with a blank screen (driver is registered, Xorg session start, but nothing on screen. I don't know how to debug further 😪 ...)

I'm doing all of this with a Raspberry Pi4b 6.12.18-v8+. I will try to test later on a Radxa 5b

March 11

For reference and as a bookmark reminder

* https://github.com/bkosciow/gfxlcd/blob/master/gfxlcd/driver/ili9486/ili9486.py

* https://github.com/ZinggJM/ILI9486_SPI/blob/master/src/ILI9486_SPI.cpp

* https://github.com/RobertoBenjami/stm32_graphics_display_drivers/blob/master/Drivers/lcd/ili9486/ili9486.c

* https://github.com/Bodmer/TFT_eSPI/blob/master/TFT_Drivers/ILI9486_Init.h

* https://github.com/ZinggJM/ILI9486_SPI/blob/master/src/ILI9486_SPI.cpp

* https://github.com/DeadReDeamed/Raspberry-Pi-LCD-ILI9486-Driver/blob/main/LCD_Driver/LCD_Driver.c

March 11

This is from panel-mipi-dbi-spi.txt

command 0xE0 0x00 0x03 0x09 0x08 0x16 0x0A 0x3F 0x78 0x4C 0x09 0x0A 0x08 0x16 0x1A 0x0F
command 0xE1 0x00 0x16 0x19 0x03 0x0F 0x05 0x32 0x45 0x46 0x04 0x0E 0x0D 0x35 0x37 0x0F

This is from LCDWIKI_SPI.cpp for ili9488:

0xE0, 15, 0x00, 0x07, 0x10, 0x09, 0x17, 0x0B, 0x41, 0x89, 0x4B, 0x0A, 0x0C, 0x0E, 0x18, 0x1B, 0x0F,

0xE1, 15, 0x00, 0x17, 0x1A, 0x04, 0x0E, 0x06, 0x2F, 0x45, 0x43, 0x02, 0x0A, 0x09, 0x32, 0x36, 0x0F,

They are other commands that differs slightly.

I've found other sources for the init sequence which seems all to be close to panel-mipi-dbi-spi.txt :

* Juj fbcp lib: https://github.com/juj/fbcp-ili9341/blob/master/ili9488.cpp#L28

* Bodmer eTFT_SPI lib for microcontrollers : https://github.com/Bodmer/TFT_eSPI/blob/master/TFT_Drivers/ILI9488_Init.h#L11

* Jarret Bucket Adafruit GLX lib : https://github.com/jaretburkett/ILI9488/blob/master/ILI9488.cpp#L378

* this one is for STM32 : https://github.com/RobertoBenjami/stm32_graphics_display_drivers/blob/master/Drivers/lcd/ili9488/ili9488.c#L219

In the same manner, we can found init sequences for other chips in these libraries, eg ili9486.

There's already a driver in the kernel source : https://web.git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/gpu/drm/tiny/ili9486.c?h=linux-6.12.y but it is specific to Waveshare 35a or PiScreen displays (these with 4 kind of shift register ICs onboard).

So for now, while waiting for a new ili9488 display arrives home, I'm digging further around the right init sequence for ili9486.

March 10

So I've looked into my drawers and, unfortunately, I can't get my hands on the ili9488 display I own. I will order a new one.

But I've got another display of the same type (with the red PCB and 14 pins and resistive touch) with ili9486 driver IC.

In LCDWIKI_SPI.cpp, there's an init sequence for that chip, but I'm really confused.

On 12/13/2024 at 6:11 AM, robertoj said:

THANKS TO USER KungFuPancake, who showed me his github repo, where he indicates to use the latest Armbian-edge, and provides the a command byte sequence for the ili9488

Means that you have use this file: https://github.com/KungfuPancake/v0_ips_touch_display/blob/main/panel-mipi-dbi-spi.txt ?

It's really different from what is in LCDWIKI_SPI.cpp around line 1697 (for ili9488)

March 8

Hi, sorry for the delay.

On 3/5/2025 at 7:22 PM, robertoj said:

My DTS file uses the new panel-mipi-dbi-spi driver, which is not fbtft, it is tinydrm.

I can't believe it !

This is just great.

I will give it a try the next few days. Many thanks

March 5

Hi @robertoj, it's really interesting.. For now I just can get my ili9488 display working exclusively on a RBPi using JUJ's fbcp https://github.com/juj/fbcp-ili9341

Tell me if I resume well:

You got the display to work with the old fbtft driver, but touch seems unsure

You're using the tinydrm and it's fully functionnal

What is your kernel version ?

February 4, 2024

Hi there,

just to clarify; all of you having wlan0 up and running, are you using an USB adapter or the RVdock built in wifi chip

I'min the same situation as noticed here:

I'm using 23_09_sid_edge_6.6.0, and gotsame problem with current 6.1

-------------EDIT----------------

Got it working finally.

For any unknow reason, the arbiam setup script at first boot didn't finished totaly.

I have burned a new SD card with 23_09_sid_edge_6.6.0

and everything (at least Wifi) is fine.

Thank you @balbes150 great job

February 11, 2023

Hey Klaus,

I own an IQaudio Dac Pro and I want it to run on Rock5b.

I'm a bit busy these days for investigating right now, but here are some points:

IQaudio boards have an ASoc driver like:

https://github.com/raspberrypi/linux/blob/rpi-5.15.y/sound/soc/bcm/iqaudio-dac.c

or

https://github.com/raspberrypi/linux/blob/rpi-5.15.y/sound/soc/bcm/iqaudio-codec.c

Maybe they need some tweaks

You have to write and compile a device tree overlay like this one

https://github.com/raspberrypi/linux/blob/rpi-5.15.y/arch/arm/boot/dts/overlays/iqaudio-dacplus-overlay.dts

I've seen on radxa repository that there is already a dts file for an Audioinjector board:

https://github.com/radxa/overlays/blob/main/arch/arm64/boot/dts/rockchip/overlays/audioinjector-isolated-soundcard.dts

but this shouldn't be for the rock5b, as GPIO pinout (https://wiki.radxa.com/Rock5/hardware/5b/gpio) list I2S2 and I2C7 as the right data lanes name.

Be sure that I2C7 and I2S2 are in "okay" status (haven't checked) in the device tree

Hope this helps, and keep us in touch 😉

Good luck

May 23, 2020

thank you @martinayotte for the tip.

@orangepower : as you, I was in such a trouble: my solution was to remove emmc module from the nanoPi and then from my PC erase emmc's content using an usb2emmc adapter. Kind of brutal solution but really efficient

May 13, 2020

do you hav both boards : the pecanpi and the tinkerboard ?

May 12, 2020

I agree with Guidol's point of view.

But, so far

if you already have a tinkerboard lying on your desk
if you know how to use etcher (or any other tool for creating a bootable disk)

Then by following instructions given above and these on how to compile armbian you should be able to get your DAC up and running under armbian. And, maybe you will just have to adapt the "compatibility" line in the dts file ...

I would be glad to help you further, but without having the tinkerboard, and without having this dac it's hard to do more ...

May 10, 2020

do you have any board in mind. Armbian runs on a wide variety of hardware. See here:

https://www.armbian.com/download/?device_support=Supported

and here for the boards in testing stage:

https://www.armbian.com/download/?device_support=Suitable+for+testing+(WIP)

They are boards that haven't got any i2s interface.

Have a look at this thread for some guidance:

You will have to compile driver pcm179x-i2c or pcm179x-spi depending on the hardware control protocol used by your device, I'm quiet sure that it isn't enabled by default in armbian.

The device tree overlay for rpi-dac is quiet simple and should easily adaptable:

https://github.com/raspberrypi/linux/blob/rpi-4.19.y/arch/arm/boot/dts/overlays/rpi-dac-overlay.dts

// Definitions for RPi DAC
/dts-v1/;
/plugin/;

/ {
	compatible = "brcm,bcm2835";

	fragment@0 {
		target = <&i2s>;
		__overlay__ {
			status = "okay";
		};
	};

	fragment@1 {
		target-path = "/";
		__overlay__ {
			pcm1794a-codec {
				#sound-dai-cells = <0>;
				compatible = "ti,pcm1794a";
				status = "okay";
			};
		};
	};

	fragment@2 {
		target = <&sound>;
		__overlay__ {
			compatible = "rpi,rpi-dac";
			i2s-controller = <&i2s>;
			status = "okay";
		};
	};
};

Again, post mentioned above will give most of what you are looking for.

Good luck

May 10, 2020

Well, I own a nanopi m4v2 + nVme hat and ssd, but for an unknown reason, the board doesn't start anymore. I suspect that some component has been toasted elsewhere ...

So sad ...

Quote

Some boards need the sd card with the bootloader

First, I've got to say that I'm far from being a guru in all these uboot, bootloader stuff. But that is the case for the m4v2 + nvme ssd => you need sd card for booting the board and then access root filesystem on the ssd. By swapping the sd card I had the ability to install and choose to use legacy or mainline on two separate partitions.

=> so while booting the board with a fresh armbian sd card, you can backup a ssd partition or even the whole drive with dd. But I don't know if it is feasible on the emmc drive.

Btw, there is a "recovery" button on the board, what is that use for, it's a mystery

May 9, 2020

I mean, if you can boot on a sd card with armbian on it, you should be able to copy the content (using dd command) of the emmc to an external hard drive connected via usb.

May 9, 2020

@pkfox, once you have installed armbian on emmc, you can't boot on the sd card anymore (unless you remove the emmc) ?

May 9, 2020

Woua, specs are quiet excellent but it's... an expensive stuff ,🙄

May 1, 2020

Hi,

did you try that workaround:

April 29, 2020

Hi, that is a great news !

the provided dts file is for what kind of board ?
Do you plan to get the touch to work too ?

April 5, 2020

Hi Werner, hi Myy

I like big challenge

I went through all the building process (without having initialized any FLAGS as said above) on the nanoPi itself.

But I don't realize how it can impact on software performance, or compilation speed or ....

I will run the process again with

13 minutes ago, Myy said:

-march=, -mcpu= and -mtune= to native

Thank you

April 5, 2020

Hi,

that's great ! I will try your fix later next week on nanoPi m4v2 and will keep you informed if it works.

April 5, 2020

Hi,

I'm trying to build a zynthian synthesizer on a nanoPi m4v2. The principle is to start from a minimal buster image and run a bunch of compilation scripts (see here on github) to create all the needed software. But all that stuff is for Raspberry Pi.

In an initialization script (see here on github) they define compilation flags like this:

if [ "$ZYNTHIAN_FORCE_RBPI_VERSION" ]; then
    hw_architecture="armv7l"
    rbpi_version=$ZYNTHIAN_FORCE_RBPI_VERSION
else
    hw_architecture=`uname -m 2>/dev/null`
    if [ -e "/sys/firmware/devicetree/base/model" ]; then
        rbpi_version=`tr -d '\0' < /sys/firmware/devicetree/base/model`
    else
        rbpi_version=""
    fi
fi

if [ "$hw_architecture" = "armv7l" ]; then
    # default is: RPi3
    CPU="-mcpu=cortex-a53 -mtune=cortex-a53"
    FPU="-mfpu=neon-fp-armv8 -mneon-for-64bits"
    if [[ "$rbpi_version" =~ [2] ]]; then
        CPU="-mcpu=cortex-a7 -mtune=cortex-a7"
        FPU="-mfpu=neon-vfpv4"
    fi
    #CPU="${CPU} -Ofast" #Breaks mod-ttymidi build
    FPU="${FPU} -mfloat-abi=hard -mlittle-endian -munaligned-access -mvectorize-with-neon-quad -ftree-vectorize"
    CFLAGS_UNSAFE="-funsafe-loop-optimizations -funsafe-math-optimizations -ffast-math"
fi
export MACHINE_HW_NAME=$hw_architecture
export RBPI_VERSION=$rbpi_version
export CFLAGS="${CPU} ${FPU}"
export CXXFLAGS=${CFLAGS}
export CFLAGS_UNSAFE=""
export RASPI=true

I'm totally confused with aarch64, arm64, armv7, armv8 ...

Can someone help me to set the right options here.

What I've done so far, was to remove all these FLAGS initialization (because of errors), but this is for sure not the best way to optimize that :wacko:

Thank you for your input!

March 21, 2020

Yes, you can go that way.

ADCLRC and DACLRC will share the same GPIO pin number 35

March 15, 2020

That board has a 12.288 MHz crystal. You'll have to adjust the clock settings accordingly in the dts file. The sample rate will be 44100 hz.

Btw, did you notice that mikroe's proto board only has got one microphone input ?

March 9, 2020

Hi there,

This topic interest me a lot. I'm using arm sbc for sound & music applications where low latency is important.

sfx2000's post reminds me other discussions on other forums (mostly computer "assisted" music oriented) where some thoughts/experiences are related to poor application performance regarding the low positive impact of a RT kernel.

From my own experience (x86, arm SBC's and RPI), RT kernel or not, good or bad audio interface in USB or I2S, depending on the load (cpu, memory, audio stream), I always have crack, glitches and xruns.

Without RT patch, what I get:

- With a H5 board with 2Gb memory (NanoPiK1plus) I can't go under 20ms of jack audio server latency without having a to unstable config but, as is, it is still "playable".

- With a NanoPiM4 and a HD USB audio interface, I have 5ms of latency, a lot of power for apps and a NvMe interface for a fast drive. That's great

So, I really ask myself for going further in kernel "hacking" with the RT patch.

February 29, 2020

Hi,

same problem here with a NanoPi M4v2, works as it should with legacy 4.4 kernel but not with 5.4.14 kernel (armbian 19.11.9).

I didn't investigate further as this is not my priority right now.

Sign In

Forums

Store

Crowdfunding

Applications

Events

Raffles

Community Map

Posts posted by le51

Important Information