Jump to content

Marko Buršič

Members
  • Posts

    60
  • Joined

  • Last visited

Profile Information

  • Gender
    Male
  • Location
    Koper, Slovenia

Recent Profile Visitors

1605 profile views
  1. Installed the image Armbian_20.08.1_Rockpi-4b_buster_current_5.8.6.img.xz . Then, in armbian-config -> Software, I had installed linux headers + source. I got two new directories: linux-headers-5.7.15-rockchip64 linux-source-5.7.15-rockchip64 If I execute: uname - r I get: root@pi:~# uname -r 5.8.6-rockchip64 The kernel version and installed source/headers are not the same, so they are useless. How to get the correct source/headers? EDIT: When first boot, the OS asked for locale/timezone settings, I did hit ENTER as default and it set the locale language to Slovene. When doing apt-get update, there was an error saying about missing files on the server. Since I am not very familiar with this language I changed to en.US-UTF-8. Then I redo apt-get update, it updated without problems. I had removed headers and source via armbian-config. Done update & upgrade, this time no problems. The version is now 5.6.12-rockhip64 Reinstalled back headers, correctly. Installed source, this time I had to choose which one, so I choose 5.6.12-rockhip64 It seems solved, now. The local language could be an issue.
  2. After some tests I have found out that this works OK with a kernel that has the ds1307 enabled as default in .config . Currently 5.4.44-rockchip64 has this rtc enabled by default (it is back again, thankfully) and it compiled as module, rk808 is compiled as device. When using above mentined .dtbo the system recognises the ds1307 at boot and then it links as /dev/rtc0, so no kernel built from trunk is needed anymore.
  3. Thank you @martinayotte, you saved me days of pain. The problem was that single line, while editing in putty terminal window, the numeric keypad doesn't work properly, so I have messed the file by myself. I find difficult to debug my .dtbo file, something is not accepted and it is reverted back, so overlays do work now just until I add my .dtbo. Does this verbosity setting may help to adjust the debug level while booting? I can't see any debug text of the overlay sequence, so I don't know where exactly goes wrong.
  4. Yes. I can change the configuration, uncheck media drivers, uncheck feildbus drivers, ....an so many drivers, but I got everything built. For now, I do think I will leave as it is, since the new armbian+ new kernel boots only in 15s compared to previous armbian version it took more than 200s.
  5. This overlays settings worked well until I have compiled my own .dtbo file and call it with overlay=..xyz... , after that all yet working overlays stopped working, even if I removed them. The boot process now skips this overlay settings. After examination, I have found file "/boot/boot.scr" and "/boot/dtb-5.4.44-rockchip64/rockchip/overlay/rockchip-fixup.scr" had some garbage characters at beginning. I didn't change anything, neither I did open them before, those files simply got garbage. After deleting the garbage chars, it won't boot anymore. Before I had tried also spi-spidev and spi-nor
  6. No luck. I have tried to customise the kernel build with KERNEL_CONFIGURE=yes. It simply builds as default, no matter what I do unselect or changed it is going to be compiled/built. Maybe @Igor knows the answer?
  7. Thank you. I was struggling to find the solution by myself (before your post), so I ended with this (if I remember correctly): git clone https://github.com/armbian/build --branch v20.05 The version v20.05.2 was installed. I hope it is the same as your way (still learning). A strange thing now is that I wanted to remove lots of useless drivers, then I did a kernel configuration, deselected many options, what I got is that almost every driver is now compiled and loaded. I will try again tomorrow, ...never ending story.
  8. Ok, but how should I install it? I did git clone https://github.com/armbian/build Should I use git clone https://github.com/armbian/build/tree/v20.05 instead?
  9. @piter75 The funny thing is that now the Armbian version is 20.08, but Release versions say it should come only in August???
  10. @piter75 Maybe you have answered meanwhile I did edit my question, so yes the ready made image works great. I am still figuring out such enormous step forward, I am installing Armbian from scratch, I hope I will make a trunk with my patches that it will work as good as ready made.
  11. Hi, I don't have an idea why it stucks. Armbian_20.05.0-trunk_Rockpi-4b_buster_current_5.4.43 EDIT: I have downloaded the pre-build image Armbian_20.05.1_Rockpi-4b_buster_current_5.4.43 and it works. It boots at an astonishing speed, only 18 sec which is a miracle. How can I build the same kernel? Is sufficient to copy just a .config file? T T DDR Version 1.13 20180801 In Channel 0: LPDDR4,50MHz CS = 0 MR0=0x98 MR4=0x3 MR5=0xFF MR8=0x8 MR12=0x4D MR14=0x4D MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 CS = 1 MR0=0x18 MR4=0x2 MR5=0xFF MR8=0x8 MR12=0x4D MR14=0x4D MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 Bus Width=32 Col=10 Bank=8 Row=15/15 CS=2 Die Bus-Width=16 Size=2048MB Channel 1: LPDDR4,50MHz CS = 0 MR0=0x98 MR4=0x2 MR5=0xFF MR8=0x8 MR12=0x4D MR14=0x4D MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 CS = 1 MR0=0x18 MR4=0x2 MR5=0xFF MR8=0x8 MR12=0x4D MR14=0x4D MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 Bus Width=32 Col=10 Bank=8 Row=15/15 CS=2 Die Bus-Width=16 Size=2048MB 256B stride channel 0 CS = 0 MR0=0x98 MR4=0x3 MR5=0xFF MR8=0x8 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 CS = 1 MR0=0x18 MR4=0x2 MR5=0xFF MR8=0x8 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 1 CS = 0 MR0=0x98 MR4=0x2 MR5=0xFF MR8=0x8 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 CS = 1 MR0=0x18 MR4=0x2 MR5=0xFF MR8=0x8 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 0 training pass! channel 1 training pass! change freq to 400MHz 0,1 channel 0 CS = 0 MR0=0x98 MR4=0x82 MR5=0xFF MR8=0x8 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 CS = 1 MR0=0x18 MR4=0x2 MR5=0xFF MR8=0x8 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 1 CS = 0 MR0=0x98 MR4=0x2 MR5=0xFF MR8=0x8 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 CS = 1 MR0=0x18 MR4=0x2 MR5=0xFF MR8=0x8 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 0 training pass! channel 1 training pass! change freq to 800MHz 1,0 ch 0 ddrconfig = 0x101, ddrsize = 0x2020 ch 1 ddrconfig = 0x101, ddrsize = 0x2020 pmugrf_os_reg[2] = 0x3AA1FAA1, stride = 0xD OUT U-Boot SPL board init U-Boot SPL 2017.09-armbian (Jun 01 2020 - 06:46:11) Trying to boot from MMC2 Card did not respond to voltage select! mmc_init: -95, time 10 spl: mmc init failed with error: -95 Trying to boot from MMC1 NOTICE: BL31: v1.3(debug):65aa5ce NOTICE: BL31: Built : 10:47:37, Jun 19 2018 NOTICE: BL31: Rockchip release version: v1.1 INFO: GICv3 with legacy support detected. ARM GICV3 driver initialized in EL3 INFO: Using opteed sec cpu_context! INFO: boot cpu mask: 0 INFO: plat_rockchip_pmu_init(1151): pd status 3e INFO: BL31: Initializing runtime services WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK ERROR: Error initializing runtime service opteed_fast INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x200000 INFO: SPSR = 0x3c9 U-Boot 2017.09-armbian (Jun 01 2020 - 06:46:11 +0000) Model: Radxa ROCK Pi 4 DRAM: 3.9 GiB DCDC_REG1@vdd_center: ; enabling DCDC_REG2@vdd_cpu_l: ; enabling DCDC_REG3@vcc_ddr: ; enabling (ret: -38) DCDC_REG4@vcc_1v8: set 1800000 uV; enabling LDO_REG1@vcc1v8_dvp: set 1800000 uV; enabling LDO_REG2@vcc3v0_touch: set 3000000 uV; enabling LDO_REG3@vcc1v8_pmu: set 1800000 uV; enabling LDO_REG4@vcc_sd: set 3300000 uV; enabling LDO_REG5@vcca3v0_codec: set 3000000 uV; enabling LDO_REG6@vcc_1v5: set 1500000 uV; enabling LDO_REG7@vcca1v8_codec: set 1800000 uV; enabling LDO_REG8@vcc_3v0: set 3000000 uV; enabling SWITCH_REG1@vcc3v3_s3: ; enabling (ret: -38) SWITCH_REG2@vcc3v3_s0: ; enabling (ret: -38) vcc1v8-s0@vcc1v8_s0: set 1800000 uV; enabling (ret: -38) dc-12v@dc_12v: set 12000000 uV; enabling (ret: -38) vcc-sys@vcc_sys: set 5000000 uV; enabling (ret: -38) vcc3v3-sys@vcc3v3_sys: set 3300000 uV; enabling (ret: -38) vcc-phy-regulator@vcc_phy: ; enabling (ret: -38) vdd-log@vdd_log: ; enabling (ret: -38) MMC: sdhci@fe330000: 0, dwmmc@fe320000: 1 SF: unrecognized JEDEC id bytes: ff, ff, ff *** Warning - spi_flash_probe_bus_cs() failed, using default environment In: serial@ff1a0000 Out: serial@ff1a0000 Err: serial@ff1a0000 Model: Radxa ROCK Pi 4 boot mode 0. Net: eth0: ethernet@fe300000 Hit any key to stop autoboot: 0 Card did not respond to voltage select! mmc_init: -95, time 10 switch to partitions #0, OK mmc0(part 0) is current device Scanning mmc 0:1... starting USB... USB0: USB EHCI 1.00 USB1: USB EHCI 1.00 USB2: Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.10 USB3: Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.10 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 Device 0: unknown device ethernet@fe300000 Waiting for PHY auto negotiation to complete.... done Speed: 1000, full duplex BOOTP broadcast 1 BOOTP broadcast 2 DHCP client bound to address 192.168.1.134 (257 ms) *** Warning: no boot file name; using 'C0A80186.img' Using ethernet@fe300000 device TFTP from server 192.168.1.1; our IP address is 192.168.1.134 Filename 'C0A80186.img'. Load address: 0x800800 Loading: T T T T T T T T T T Retry count exceeded; starting again missing environment variable: pxeuuid missing environment variable: bootfile Retrieving file: pxelinux.cfg/01-36-bb-f1-14-ce-8a Speed: 1000, full duplex
  12. SOLVED: I does work in kernel 5.4.38. [ 2921.666286] usb 6-1: new SuperSpeed Gen 1 USB device number 3 using xhci-hcd [ 2921.687193] usb 6-1: New USB device found, idVendor=0781, idProduct=5583, bcdDevice= 1.00 [ 2921.687208] usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 2921.687219] usb 6-1: Product: Ultra Fit [ 2921.687228] usb 6-1: Manufacturer: SanDisk [ 2921.687240] usb 6-1: SerialNumber: 0501634ed22050222bcbb18b9662cf60a71d58eb3accd361176c490dac57c439b94200000000000000000000f62b26dbff9d0f108355810778267974 [ 2921.688502] usb-storage 6-1:1.0: USB Mass Storage device detected [ 2921.689030] scsi host1: usb-storage 6-1:1.0 [ 2922.691087] scsi 1:0:0:0: Direct-Access SanDisk Ultra Fit 1.00 PQ: 0 ANSI: 6 [ 2922.691920] sd 1:0:0:0: Attached scsi generic sg0 type 0 [ 2922.692134] sd 1:0:0:0: [sdb] 60088320 512-byte logical blocks: (30.8 GB/28.7 GiB) [ 2922.692987] sd 1:0:0:0: [sdb] Write Protect is off [ 2922.693002] sd 1:0:0:0: [sdb] Mode Sense: 43 00 00 00 [ 2922.694608] sd 1:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ 2922.724780] sdb: sdb1 [ 2922.728106] sd 1:0:0:0: [sdb] Attached SCSI removable disk
  13. It's not so difficult as it seems, to build a module for driver. Copy header and source packages, in my case linux-headers-current-rockchip64_20.05.0-trunk_arm64.deb and linux-source-current-rockchip64_20.05.0-trunk_all to your board. Then install: dpkg -i linux-headers-current-rockchip64_20.05.0-trunk_arm64.deb It does automatically all. Next is to install source: dpkg -i linux-source-current-rockchip64_20.05.0-trunk This step only copies a tar.xf file into a directory /usr/src/ , but if you untar it it will reside in /usr/src/ directory, so let's make a new dir: mkdir /usr/src/linux-source-$(uname -r) And move the tar.xz file into that dir. (Perhaps there is a also different way to untar that untars into new dir, but I don't know it). Next untar the source archive: tar xf linux-source-5.4.38-rockchip64.tar.xz (5.4.38 is the current, you may have a newer file) Now both headers and source is installed, let's build a driver. Exactly my fbtft device from staging dir. cd /usr/src/linux-source-5.4.38-rockchip64/drivers/staging/fbtft/ Rename Makefile to Makefile.bak. Then write a new Makefile with nano Makefile: obj-m += fb_ssd1322.o all: make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules clean: make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean Save this, to make the fb_ssd1322 (or whichever you want) and execute make. make make -C /lib/modules/5.4.38-rockchip64/build M=/usr/src/linux-source-5.4.38-rockchip64/drivers/staging/fbtft modules make[1]: Entering directory '/usr/src/linux-headers-5.4.38-rockchip64' CC [M] /usr/src/linux-source-5.4.38-rockchip64/drivers/staging/fbtft/fb_ssd1322.o Building modules, stage 2. MODPOST 1 modules CC [M] /usr/src/linux-source-5.4.38-rockchip64/drivers/staging/fbtft/fb_ssd1322.mod.o LD [M] /usr/src/linux-source-5.4.38-rockchip64/drivers/staging/fbtft/fb_ssd1322.ko The driver module fb_ssd1322.ko is generated. To be continued .... (removing the driver, replacing the new one and installing back)
  14. Hi, I have one silly problem developing a FBTFT device driver for SSD1322 display : https://github.com/MarkoBursic/fbtft---SSD1322/blob/master/fb_ssd1322.c The initialisation starts OK, all GPIOs (DC, RESET, CS) follows as they should, since the data is sent through a function write_reg. For example : write_reg(par, 0xA0, 0x14, 0x11); It asserts DC low, then sends 0xA0, then asserts DC high and sends 0x14 and 0x11. Within every sent character (8bit bata) the CS toggles. The problem becomes when I want to send video data, I guess a function write_vmem is called. But here the entire tx buffer is filled and then streamed. for (y = 0; y < bl_height; y++) { for (x = 0; x < bl_width / 2; x++) { *buf = cpu_to_le16(rgb565_to_y(vmem16[offset++])) >> 8 & 0xF0; *buf++ |= cpu_to_le16(rgb565_to_y(vmem16[offset++])) >> 12; } } /* Write data */ ret = par->fbtftops.write(par, par->txbuf.buf, bl_width/2*bl_height); In fact the whole buffer is sent from SPI but the CS doesn't toggle every 8-th clock pulse, it is just asserted low and then streamed out whole 8kB. Is there any settings on SPI to tell that it has to toggle, for example the dtb ovelay for FBTFT device has a setting: buswidth=<8>; but it seems that it doesn't take care of it. Any advice? p.s.: the code was cloned from other sites that have used this device on RPi. EDIT: Problem is solved. I had a test example from BuyDisplay.com written for RPi, which sent data with toggling CS for each sent byte. I have patched this example and found out that SSD1322 works even better with a continuous stream without toggling CS when sending VRAM buffer. Later, the problem on my Rockpi4 and linux FBTFT driver was found to be a RES signal, which is active low. Therefore the display was hold in reset every time due to wrong parameter setting in DT overlay.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines