Gavinb

Members
  • Content Count

    22
  • Joined

  • Last visited

About Gavinb

  • Rank
    Member

Profile Information

  • Gender
    Male
  • Location
    Durban, South Africa

Recent Profile Visitors

435 profile views
  1. @karlitos This sounds like the same issue I had at a point. DSI port on the board could have a hardware fault. I switched to another board and then got it going.
  2. Are the ribbon cables connected correctly, i.e. no misalignment etc. [ 8.738486] sun6i-mipi-dsi 1ca0000.dsi: Attached device fy07024di26a30d show's that it's attached the display unit. I didn't have to add/change anything after booting up, ie no need to change armbianEnv.txt
  3. Hi @karlitosYou will need the serial cable, as you have to do the initial login/root password etc via console, alternatively via ssh if you know it's ip. Once you've created a normal user, it'll startup the desktop evironment thereafter.
  4. I'm currently looking into a new project which will use (hopefully) the Rpi Waveshare hdmi based 4" lcd touch screen, linked to the pine64/Sopine I'm at research stage, and will be looking into using a current 5.x kernel. If anyone has any info on the waveshare lcd's I need to watch out for or suggestions to get further info (specifically the touch driver side), please post a response. Progress on the project will be posted here, links will be added once I have some basics running. This can hopefully open up the waveshare displays to other devices. @Igor Yes I've read This post but am willing to do what I can to get Armbian to support the displays as best I can.
  5. 1 - Can't say how Armbian itself will move forward, as this is a specific branch for my requirements. 2 - Haven't worked with vagrant, so can't answer. Not that this branch has, and probably will remain fallen behind Armbian master.
  6. Hi @karlitos script is already set to pull that kernel.
  7. Update - Touch panel is now working :) 20200122_102315.mp4
  8. @karlitos Hi, haven't made any progress the last 2 weeks, am on leave for holidays and only return on the 13th Jan when I can catch up on other test's that are being done during this time by someone else. He's currently checking through other kernel builds, so will generate patches once we can comfirm we have things workings on the I2c side.
  9. 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
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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!
  15. Not sure about working with v3.10.y of the kernel, as am working dev level on 4.14.y (However I locked it at 4.14.59, for beta purposes). What I can tell you is we've been doing our own custom board, based on the R18/A64 with lpddr3 ram, so Sopine is the dev board. I did do some tests today, working on figuring out why cpu_freq scaling is not working, (Can post image caps later, not at work atm), and went through the following:- Downloaded and run Armbian script to build a fresh image Pine64so, Cli, Next, Stretch. Flashed onto an sdcard, and &^%$ it didn't boot. Looked at the script, and yes U-Boot is 2018.something, so reverted it to 2017.11 as the tag, and rebuilt it, (again after adding 'debs' back to the clean level) And what do you know, it boots this time, however Cpu_Frequency scaling still does not work I'm compared the Kernel config files between a working system, being the OrangePi Zero with what I have for the Pine based board, not much differences other than the order everything is in. Anyway, there's my bit in here to current known issues. Gavin