Pine A64 MIPI DSI mainline

[Learnincurve]

Hi,

 

   I have a couple of these boards which I have been using with Armbian and the old, 3.10 kernel. Ideally I would really like to go mainline as later kernels have some functionality that would be useful for my use of the board. The only remaining reason (apart from cpu freq.) for sticking to the 3.10 kernel has been the lack of MIPI DSI support in mainline, but now I see that, despite the Matrix at http://linux-sunxi.org/Linux_mainlining_effort still being red for A64 mipi, some work is being/has been done by Maxime Ripard.

 

I'm just wondering if anyone here knows if a working mainline kernel with DSI for the Pine 64 is starting to look like a possibility and if it might be possible to include in an armbian build.  I might be able to do some testing of anyone can guide me in making a build with the necessary patches.

[Learnincurve]

I received the following reply from Jagan Teki, who is working on a64 MIPI/DSI:

 

Quote

Thanks for reaching out to me.

You can try this branch
https://github.com/amarula/linux-amarula/tree/WIP-A64-DSI

PLL_MIPI look difficult to implement here, nkm 1, 3, 5 dividers seems
working for me. Let me know how it work for you?

Jagan.

It may be some time before I get a chance to try to build a system with these patches, but if anyone else wants to have a go..... ?

 

BR.

 

--Marius--

 

 

 

[Tido]

Have you already been looking in their community for combatant   https://forum.pine64.org/ on your journey to mainline kernel?

 

[Learnincurve]

No I haven't.  Normally, I would follow the Armbian build process, adding the extra patches from Jagan's GitHub branch, but don't have a suitable build environment or a system on which to run one, so am stuck at the moment.

[Learnincurve]

I see that Jagan's tree is based on 4.19 and is related to  a64-relic but don't know how to incorporate it into the Armbian build process or even if I should try.

 

 

[Learnincurve]

Hi again,

 

  I have a Virtualbox/Vagrant  Armbian build environment set up.  Can anyone guide me to using Jagan's ketrnel source tree at https://github.com/amarula/linux-amarula/tree/WIP-A64-DSI

instead of the kernel.org sources?  Can I clone this locally, then point to it instead of the kernel.org source, preventing the script from downloading from kernel.org?

 

[Learnincurve]

OK. Looks like we're not quite there yet. I pointed the build scripts to the new source and commented out the patching and can build Armbian with the unpatched code from Jagan's  4.19 tree, but have not tried to run the board from that image. The MIPI code is there but not the code for the Pine64  7" LCD panel, so that will need a module as well. Jagan has been sent a panel and the datasheet, so hopefully some existing code can be adapted to make that work too.

[Asimov]

Hi Learnincurve ,

 

I have a banana pi M2U and a SOM with R40 or A40i that I tried to run mipi_dsi over there but at this moment is not working ... I will try to download or clone the github from amarula and understand what change to run mipi_dsi on the Core R40 that have the same register that A31 and A64... If I run the mipi_dsi I post here how to do that...

 

Best Regards Diego

[Learnincurve]

For information:

 

  Jagan has updated the source tree at https://github.com/amarula/linux-amarula/tree/WIP-A64-DSI  to include specific Pine64 patches, including for the Feiyang FY07024DI26A30-D 7" MIPI-DSI LCD Panel.

 

 

I have compiled Armbian with this kernel but won't have time to try installing for a few more days.

 

BR.

 

--Marius

[Learnincurve]

Unfortunately I was unable to boot the board with the image I had compiled.  Powered up, lights on and board warm, but no network and card fs was unchanged (unexpanded) after several minutes.

 

My understanding of the arm boot process is minimal so I won't be able to do any more with this without help.

 

Image available at:

 

https://drive.google.com/open?id=1ZMiXZU0zJEQMiMTivTaVshQ3ViHPetDH

[Airtau]

your image doesn't contain subdirectories /boot/dtb

 

=> ext4ls mmc 0 /boot
<DIR>       4096 .
<DIR>       4096 ..
             104 armbianEnv.txt
            4882 boot-desktop.png
          230454 boot.bmp
            1536 armbian_first_run.txt.template
            3018 boot.cmd
            3090 boot.scr

 

=> run mmc_boot
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot/boot.scr
3090 bytes read in 15 ms (201.2 KiB/s)
## Executing script at 4fc00000
U-boot loaded from SD
Boot script loaded from mmc
104 bytes read in 9 ms (10.7 KiB/s)
** File not found /boot/dtb/allwinner/sun50i-a64-pine64-plus.dtb **
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
No FDT memory address configured. Please configure
the FDT address via "fdt addr <address>" command.
Aborting!
** File not found /boot/dtb/allwinner/overlay/sun50i-a64-fixup.scr **
** File not found /boot/uInitrd **
** File not found /boot/Image **
Bad Linux ARM64 Image magic!

 

[Learnincurve]

AH!  That would explain it!

 

I'll see if I can find those files and add to the image.

 

[Learnincurve]

Okay. I found (directly) /boot/Image, and /boot/dtb/allwinner/sun50i-a64-pine64-plus.dtb, I also found the cmd file for /boot/dtb/allwinner/overlay/sun50i-a64-fixup.scr and ran 

 

mkimage -A arm64 -T script -C none -n "sun50i-a64-fixup.scr" -d ~/armbian/cache/sources/linux-mainline/WIP-A64-DSI/arch/arm64/boot/dts/allwinner/overlay/sun50i-a64-fixup.scr-cmd /home/vagrant/armbian/output/Missing_Files/sun50i-a64-fixup.scr

 

which gave me an Invalid argument error but did put an .scr file in the destination folder. I don't know yet if the file is correct.

 

Can anyone help on how to create the uInitrd file?

 

Otherwise, recompiling just kernel and u-boot now. Will see if that generates the missing files.

 

BR.

 

 

[Learnincurve]

 

UPDATE: the kernel rebuild did not create the missing files.  Any advice welcome.

[Airtau]

16 hours ago, Learnincurve said:

 

UPDATE: the kernel rebuild did not create the missing files.  Any advice welcome.

Is there public access to your Armbian build tools?

[Learnincurve]

I just followed the instructions for the Vagrant- based VM and pointed the configs to Jagan's kernel source tree instead of the default 4.14y kernel. Also commented out the kernel patches as most of them don't work against 4.19.

 

I could post the VM file somewhere if you like, but it should be quite easy to reproduce.

 

I'm aware that it's ugly hacking and may well break the armbian build process, which is probably what has happened.  Was just hoping there was a way to patch up the image manually.

[Learnincurve]

I see that Jagan's patches just made it to:

 

https://lore.kernel.org/patchwork/project/lkml/list/?series=372679

and

https://lore.kernel.org/patchwork/project/lkml/list/?series=&amp;submitter=&amp;state=*&amp;q=feiyang&amp;archive=both&amp;delegate=

 

so it may even be possible to apply them to the official 4.14y tree that the Armbian build process is supposed to use.

I may have another try, adding those user patches to the default mainline build process.

 

[Learnincurve]

I have attached an archive of all the patches, which I will put in the userpatches/kernel/pine64-default ditrectory and try to rebuild.

 

What do I do with DT Bindings?

 

eg:

https://lore.kernel.org/patchwork/patch/1006353/

 

BR.

 

--Marius--

 

a64_MIPI-DSI_Patches.zip

[Learnincurve]

moved patches to sunxi-next as they weren't picked up from pine64-default.

 

Patching fails on many of the new patches, as original files either missing or not in patchable version, resulting in a kernel build without the new  MIPI-DSI support.

 

Will try to build basic 4.14 kernel then apply missing files to previous 4.19 build,

as the build process with Jagan's patches is above my skill level.

 

--M--

 

 

[Learnincurve]

4.14y image built and all missing files exist except uInitrd

On 11/12/2018 at 10:01 AM, Airtau said:

your image doesn't contain subdirectories /boot/dtb

 

=> ext4ls mmc 0 /boot
<DIR>       4096 .
<DIR>       4096 ..
             104 armbianEnv.txt
            4882 boot-desktop.png
          230454 boot.bmp
            1536 armbian_first_run.txt.template
            3018 boot.cmd
            3090 boot.scr

 

=> run mmc_boot
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot/boot.scr
3090 bytes read in 15 ms (201.2 KiB/s)
## Executing script at 4fc00000
U-boot loaded from SD
Boot script loaded from mmc
104 bytes read in 9 ms (10.7 KiB/s)
** File not found /boot/dtb/allwinner/sun50i-a64-pine64-plus.dtb **
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
No FDT memory address configured. Please configure
the FDT address via "fdt addr <address>" command.
Aborting!
** File not found /boot/dtb/allwinner/overlay/sun50i-a64-fixup.scr **
** File not found /boot/uInitrd **
** File not found /boot/Image **
Bad Linux ARM64 Image magic!

 

 

[Gavinb]

Hi

 

I'm jumped into this, using the above mentioned kernel https://github.com/amarula/linux-amarula/tree/WIP-A64-DSI and trying to run it on a Pine64-Lts (Sopine) board.

I have the Pine64 7" Lcd display which I'm trying to get running on the pine board.

I've patched the kernel to get the dtb's into a deb file and installed into the image.

However I'm getting a Bad Linux ARM64 Image Magic from u-boot when trying to start the kernel.

I've also noticed that the DT_fixup_script is failing on bad format as well.

Patchwork I've already done can be found here https://github.com/GavinBa/build/tree/amarula-WIP-A64-DSI

 

If anyone could suggest what I should be looking for to resolve the issue, I'd appreciate it.

 

Gavin

U-Boot SPL 2019.04-armbian (Oct 08 2019 - 12:26:14 +0200)
DRAM: 2048 MiB
Trying to boot from MMC1
NOTICE:  BL3-1: Running on A64/H64 (1689) in SRAM A2 (@0x44000)
NOTICE:  Configuring SPC Controller
NOTICE:  BL3-1: v1.0(debug):c9f55c0
NOTICE:  BL3-1: Built : 12:26:03, Oct  8 2019
NOTICE:  DT: sun50i-a64-sopine-baseboard
INFO:    Configuring AXP PMIC
NOTICE:  PMIC: fixing DRAM voltage from 1.24V to 1.20V
INFO:    PMIC: DRAM voltage: 1.22V
INFO:    PMIC: setup successful
NOTICE:  SCPI: dummy stub handler, implementation level: 000000
INFO:    BL3-1: Initializing runtime services
INFO:    BL3-1: Preparing for EL3 exit to normal world
INFO:    BL3-1: Next image address: 0x4a000000, SPSR: 0x3c9


U-Boot 2019.04-armbian (Oct 08 2019 - 12:26:14 +0200) Allwinner Technology

CPU:   Allwinner A64 (SUN50I)
Model: SoPine with baseboard
DRAM:  2 GiB
MMC:   mmc@1c0f000: 0, mmc@1c11000: 1
Loading Environment from EXT4... *** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   phy interface7
eth0: ethernet@1c30000
230454 bytes read in 12 ms (18.3 MiB/s)
starting USB...
USB0:   USB EHCI 1.00
USB1:   USB OHCI 1.0
USB2:   USB EHCI 1.00
USB3:   USB OHCI 1.0
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 1 for devices... 1 USB Device(s) found
scanning bus 2 for devices... 1 USB Device(s) found
scanning bus 3 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Autoboot in 1 seconds, press <Space> to stop
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot/boot.scr
3042 bytes read in 2 ms (1.5 MiB/s)
## Executing script at 4fc00000
U-boot loaded from SD
Boot script loaded from mmc
104 bytes read in 1 ms (101.6 KiB/s)
20693 bytes read in 4 ms (4.9 MiB/s)
0 bytes read in 2 ms (0 Bytes/s)
Applying kernel provided DT fixup script (sun50i-a64-fixup.scr)
## Executing script at 44000000
Wrong image format for "source" command
5408013 bytes read in 268 ms (19.2 MiB/s)
6866080 bytes read in 339 ms (19.3 MiB/s)
Bad Linux ARM64 Image magic!
SCRIPT FAILED: continuing...
Card did not respond to voltage select!

 

[Igor]

4 hours ago, Gavinb said:

However I'm getting a Bad Linux ARM64 Image Magic from u-boot when trying to start the kernel.

I've also noticed that the DT_fixup_script is failing on bad format as well.

You need to keep certain patches such as:
https://github.com/GavinBa/build/blob/amarula-WIP-A64-DSI/patch/kernel/sunxi-next.disabled/general-packaging-4.17-next.patch

 

I am working on a major update where this packaging will be done separately ... 

[Gavinb]

Hi Igor

Thanks for responding.

 

I had already including most of that patch, however had missed /arch/arm64/Makefile changes which I've added.

Rebuilding and will continue to debug from there.

 

[Gavinb]

Finally, something that's actually displaying something now :)

 

Armbian build script https://github.com/GavinBa/build/tree/v9-a64-dsi

Kernel used https://github.com/amarula/linux-amarula/tree/v9-a64-dsi

 

I haven't tested everything as yet, aim was to get the display at least running.

[karlitos]

Hello, any updates on this ? @Gavinb How was your experience with the v9-a64-dsi kernel ?

[Gavinb]

Hi @karlitos currently still working on getting the touch side working, however desktop image build seems to be stable with all tests we have done so far on the board.

[pszypowicz]

@Gavinb Please keep us updated. I started to play with sopine (after one year of keeping it in the drawer) but just can't find an image suitable to work with LCD.

 

I bought A64 LTS and "official" 7" LCD. Please let me know if I can help somehow with debugging.

[Gavinb]

Thanks  @pszypowicz problem I'm having is getting the I2C lines unlocked

[    9.381132] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0
[    9.381155] Goodix-TS 0-005d: i2c test failed attempt 2: -110
[    9.409109] Goodix-TS 0-005d: I2C communication failure: -110

I have commited some debugging checks into the kernel, will be continuing with it today, after I sort out mac-addr issues I'm experiencing here in the office for the network changes we've had.

Image does work on the pine64, by adding in a patch to copy the sopine-baseboard.dts over the pine64.dts, should do the same on overwrite of the pine64-lts.

[karlitos]

I am also super excited about this news. I have on original Pine A64 board from the kickstarter campaign and one Pine A64 (+) LTS, I hope I would be able to get the LCD running on both of them.

 

Quote

[ 9.381132] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0

[ 9.381155] Goodix-TS 0-005d: i2c test failed attempt 2: -110

[ 9.409109] Goodix-TS 0-005d: I2C communication failure: -110

Is there some output from i2cdetect ? I2C bus locked can be sometimes caused by too high bitrate.

[Gavinb]

I've already verified with i2cdetect, without loading the touch driver, using the normal overlay method, results are the same for both I2c-0 and 1

[Learnincurve]

Really great news that somebody is working on this!

 

Thank you so much!

 

I see that there are also new nightly builds for the Pine64, now with kernel 5.4.2 and that Jagan's patches are still maturing slowly at

https://lore.kernel.org/patchwork/project/lkml/list/?submitter=21112

 

 

I'm happy to help with some simple testing if given instructions, but am unfortunately not technical enough for any code/script changes.

Please let me know if I can help.

 

BR.