Jump to content

Ryzer

Members
  • Posts

    16
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. When testing my most recent builds using the Armbian build framework I found that I was experiencing a constant load greater than 1.00. At first, I thought this is probably normal to have a load during the system boot but after waiting over 10 minutes I found that the load did not decrease. Firstly, I used HTOP but could not find a process that was heavy utilising the CPU with the relative CPU usage show as low. Next I tried using TOP which revealed a process called kworker: freezeable_power. Trying to search for the issue I did not find much until I came across this old forum post that described the same issues I was having: https://forum.armbian.com/topic/7575-k-worker-problem-on-a20-based-boards/page/2/ Sure enough, removing the sun4i-gpadc caused the average system load to drop and even relative CPU usage dropped to around 1% utilisation rather than the usual idling around 20 – 25%. The risk is losing the CPU temperature. Following the advice from the latest post I found that setting mode to disabled seemed to do the trick of bringing down the system load while retaining CPU temperature reading. I achieved this by modifying rc.local with the line: Echo disabled > /sys/devices/virtual/thermal/thermal_zone1/mode Admittedly this works reasonably well however it take around approximately 5 minutes for system load to drop down to a more expected 15% - 20% on idle. I am hoping that someone with an understanding of the touchscreen control on the A10/A20 may be able to provide a fix as this out of my depth with my current knowledge. Without rc.local edit: with rc.local edit:
  2. Hi Roland, Ok it looks like I2C is being set up correctly but I would advise against activating all I2C interfaces at once, in case it leads to problems. As you identified earlier you only need to have I2C2 enabled. Could you please provide the code that you are trying to run to communicate with the BME280 or show what kind of error message you are getting. Unfortunately I don't have that sensor myself to test, I only have a BNO055 9 dof. So far I have had no major issues with I2C unless it has been broken by a recent kernel update. Pin 53 is the physical number on the SOC, not the board pin number on the board. for a more detailed description of the pin mapping see: https://linux-sunxi.org/GPIO as well as checking the schematic of the Banana Pi to see what pins are brought out. Best of luck Ryzer
  3. Hi Roland, What is the name of the sensor that you using and how exactly are you trying to communicate with it via i2c? The Banana Pi M1 is based around the Allwinner A20 which is a completely different SOC to the Raspberry Pi so the i2c-bcm2708 driver will not be compatible. Seeming as i2cdetect works, this suggest that i2c-dev is indeed loaded, as far as I aware it simple under /dev for i2c devices such as /dev/i2c2 which would not exist if i2c-dev has not been loaded. you can double check this by running sudo dmesg | grep i2c. from my experience you should not need define the pins as this should already be declared in the i2c overlay. if you check the pin control configuration it should show that PB20 and PB21 that they are setup for i2c2. You find this by typing sudo cat /sys/kernel/debug/pinctrl/1c20800.pinctrl/pinmux-pins | grep i2c. the output should look like this: pin 32 (PB0): 1c2ac00.i2c (GPIO UNCLAIMED) function i2c0 group PB0 pin 33 (PB1): 1c2ac00.i2c (GPIO UNCLAIMED) function i2c0 group PB1 pin 52 (PB20): 1c2b400.i2c (GPIO UNCLAIMED) function i2c2 group PB20 pin 53 (PB21): 1c2b400.i2c (GPIO UNCLAIMED) function i2c2 group PB21 Best of luck Ryzer
  4. Hi there, I have been testing this on my Pcduino3 (Same A20 Soc) and was able to generate spidev0.0 and spidev0.1 using the old examples overlays. All initially did was change the compatibility field to use "armbian,spi-dev". The original example overlays can be found here: https://github.com/armbian/sunxi-DT-overlays/tree/master/examples. I then found that I need to add the pinctrl nodes as demonstrated above to actually configure the pins correctly. You can check the pins are set correctly by using sudo cat /sys/kernel/debug/pinctrl/1c20800.pinctrl/pinmux-pins | grep PI1. Please see the resulting overlay below: /dts-v1/; /plugin/; / { compatible = "allwinner,sun4i-a10", "allwinner,sun7i-a20", "allwinner,sun8i-h3", "allwinner,sun50i-a64", "allwinner,sun50i-h5"; fragment@2 { target = <&pio>; __overlay__ { spi0_pi_pins: spi0-pi-pins { pins = "PI11", "PI12", "PI13"; function = "spi0"; }; spi0_cs0_pi_pin: spi0-cs0-pi-pin { pins = "PI10"; function = "spi0"; }; spi0_cs1_pi_pin: spi0-cs1-pi-pin { pins = "PI14"; function = "spi0"; }; }; }; fragment@1 { target = <&spi0>; __overlay__ { #address-cells = <1>; #size-cells = <0>; status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&spi0_pi_pins>; spi-max-frequency = <1000000>; num-chipselects = <2>; spidev@0 { reg = <0>; /* Chip Select 0 */ compatible = "armbian,spi-dev"; pinctrl-names = "default"; pinctrl-0 = <&spi0_cs0_pi_pin>; status = "okay"; }; spidev@1 { reg = <1>; /* Chip Select 1 */ compatible = "armbian,spi-dev"; pinctrl-names = "default"; pinctrl-0 = <&spi0_cs1_pi_pin>; status = "okay"; }; }; }; }; btw you can use the "armbian-add-overlay" command to automatically compile and move into the overlay fold best of luck Ryzer
  5. Image built with 6.1.34 works although encounter the same issues as under 6.1.26. There is a constant system load greater than 2.0 which under the prior 5.15.xx kernel this would normal settle down 5 minutes after boot. From what I could find it looks like one contributor was the r8188eu driver, which is in the staging directory but appears that it has been removed and support incorporated into the rtl8xxxu driver in the very latest kernel release. The second I discovered is the GPADC driver, this has given me grief in the past as I found that trying to use more than one of the 'adc' pins at a time seemed to cause the soc temperature reading to become very erratic. Anyway after finding the post below I found that disabling mode seemed to bring the system load to more reason levels, floating round the 0.20 - 0.30 mark. This seems like a better option rather than disabling the ability to read the CPU temperature outright, even if the output is supposedly based on average of 3 internal readings. Cheers Ryzer
  6. Hi there, I recently had an issue with this myself. The newer way to use an ili9341 display is to create a custom dts overlay to initial the drm module. You can use modinfo just check the ili9341 module is present in your kernel. This requires two segments. First request the pins that you will need to use from the port controller, how you do this will depend on the hardware you are using. Normally this will involve configuring what pin to use as the DC pin, CS pin and RST. The second segment is where we enable the SPI bus that we intend to use add attach the display. NOTE: Do not enable spidev this will cause conflict the ili9341. Please refer to this post: It refers specifically to the Allwinner/Sunxi hardware which at the very least should provide a basis to start from even if you hardware is slightly different. Best of luck Ryzer
  7. Hi there, You can find older versions in the archives: https://armbian.hosthatch.com/archive/cubieboard2/archive/ There is no version 5.15 listed but 5.10 should be good enough to avoid newer problems Alternatively if have capable hardware you can use the build framework with the legacy option which last time I checked builds with kernel version 5.15.93 Although you would first need check the cubieboard2's config file (located in 'config/boards') to make sure that there is a legacy option included if not then it should just be a case of adding it to file then it will build the legacy kernel. Best of luck Ryzer
  8. Initially I attempted upgrading the kernel from 6.1.26 to 6.1.33 using the build scripts to generate the newer kernel and headers. After rebooting I found that the system just appeared to hang around starting kernel. I did wait 10 minutes at first, thinking that perhaps their maybe some stuff going on in the background but after that conclude that it had most certainly crashed. The frustrating thing being that I did not appear to get any errors come through the debug port. At this point I assumed that perhaps something may have broke during the upgrade. My second attempt was using a completely fresh compiled image but unfortunately the result was still the same. U-Boot SPL 2022.10-armbian (Jun 15 2023 - 13:35:35 +0000) DRAM: 1024 MiB CPU: 912000000Hz, AXI/AHB/APB: 3/2/2 Trying to boot from MMC1 ns16550_serial serial@1c28000: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 U-Boot 2022.10-armbian (Jun 15 2023 - 13:35:35 +0000) Allwinner Technology CPU: Allwinner A20 (SUN7I) Model: LinkSprite pcDuino3 DRAM: 1 GiB Core: 52 devices, 23 uclasses, devicetree: separate WDT: Not starting watchdog@1c20c90 MMC: mmc@1c0f000: 0 Loading Environment from FAT... Unable to use mmc 0:1... Unknown monitor Unknown monitor In: serial Out: serial Err: serial Net: eth_designware ethernet@1c50000: Can't get reset: -2 eth0: ethernet@1c50000 230454 bytes read in 12 ms (18.3 MiB/s) Unknown monitor starting USB... Bus usb@1c14000: USB EHCI 1.00 Bus usb@1c14400: USB OHCI 1.0 Bus usb@1c1c000: USB EHCI 1.00 Bus usb@1c1c400: USB OHCI 1.0 scanning bus usb@1c14000 for devices... 2 USB Device(s) found scanning bus usb@1c14400 for devices... 1 USB Device(s) found scanning bus usb@1c1c000 for devices... 1 USB Device(s) found scanning bus usb@1c1c400 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 4121 bytes read in 2 ms (2 MiB/s) ## Executing script at 43100000 U-boot loaded from SD Boot script loaded from mmc 154 bytes read in 2 ms (75.2 KiB/s) 16660327 bytes read in 690 ms (23 MiB/s) 8480576 bytes read in 355 ms (22.8 MiB/s) Found mainline kernel configuration 42775 bytes read in 9 ms (4.5 MiB/s) 5532 bytes read in 5 ms (1.1 MiB/s) Applying kernel provided DT fixup script (sun7i-a20-fixup.scr) ## Executing script at 45000000 Kernel image @ 0x42000000 [ 0x000000 - 0x816740 ] ## Loading init Ramdisk from Legacy Image at 43400000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 16660263 Bytes = 15.9 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 43000000 Booting using the fdt blob at 0x43000000 EHCI failed to shut down host controller. Loading Ramdisk to 4901c000, end 49fff727 ... OK Loading Device Tree to 48fa9000, end 4901bfff ... OK DE is present but not probed Starting kernel ... I will gratefully for any possible insight Cheers Ryzer
  9. Hi there, does 'lsmod | grep pdc8544' even show that they module has even load? unfortunately the fbtft drivers are not that well supported hence being in the staging directory. I would advice that you look for a tiny drm based driver which is the way that small displays tend to be handled with the more recent kernel versions best of luck
  10. Hi There, Those overlays are a bit old but should hopefully work with one minor change. Try replacing the compatible field with compatible = "armbian,spi-dev" and see if this works. From what I understand there was a change to the kernel since version 5.15 which removed the old spidev driver. Best of luck Ryzer
  11. Hi there, @FruchtzergGlad to here you got it up and running. Much appreciated, I also learned from you that my cs-gpio node was in the wrong position and correcting got mine up and running. So here is the final revision of my dts overlay: /dts-v1/; /plugin/; /{ compatible = "allwinner,sun4i-a10", "allwinner,sun7i-a20", "allwinner,sun8i-h3", "allwinner,sun50i-a64", "allwinner,sun50i-h5"; fragment@0 { target = <&pio>; __overlay__{ display_pins: display_pins { pins = "PB2", "PI3"; function = "gpio_out", "gpio_out"; }; }; }; fragment@1 { target = <&spi0>; __overlay__ { /* needed to avoid dtc warning */ #address-cells = <1>; #size-cells = <0>; status="okay"; pinctrl-names = "default"; pinctrl-0 = <&spi0_pi_pins>; /* Mux the PI to make sure they are set in spi Mode*/ cs-gpios = <&pio 1 2 0>; /* PB2 (D5) - Linksprite shield TFT CS pin */ num-chipselects = <1>; display: display@0 { compatible = "adafruit,yx240qv29", "ilitek,ili9341"; pinctrl-names = "default"; pinctrl-1 = <&display_pins>; reg = <0>; spi-max-frequency = <12000000>; rotation = <270>; bgr = <0>; fps = <15>; buswidth = <8>; height = <240>; width = <320>; reset-gpios = <&pio 7 9 0>; /* PH9 (D7) */ dc-gpios = <&pio 8 3 0>; /* PI3 (D6) - Data control pin */ debug = <3>; }; }; }; __overrides__ { rotate = <&display>,"rotate:0"; fps = <&display>,"fps:0"; debug = <&display>,"debug:0"; }; }; Would have been interesting to see what they where, not that it ultimately matters now that its working. To get the desktop working you will need to tinker around with the Xorg/Xserver configuration. I have tried to manual trigger it to start but it keeps failing for a reason I have yet to identify other than this currently cryptic error '(EE) FBDEV(0): FBIOPUTCMAP: Device or resource busy' appearing a lot in /var/log/Xorg.0.log Well at least get the the touchscreen to work should be a lot easier now. From what I can see it is I2C based so you can easily get some form of identification from i2c-tools. Again it is configured in the device tree in a similar way to SPI but instead of spidev you have i2c-dev acting as the dummy receiver device. Looking forward to seeing an update with the display working and hopefully the touch panel working. All the best Ryzer
  12. Hi There, Small progress is still progress . Thanks for the offer but not need, auto translate was good enough apart from one or two sentences. Indeed it is very good guide that surprising doesn't refer to the old fb driver or the FBCP library that works on the Raspberry PI only due to direct register interactions. Still not have a lot of luck with my display, still just a white screen just like yours. I wonder if it could perhaps be related to the chip select. Luckily the Pcduino has an led attached to the SPI clock line so I can see clear that data is being sent to the display but nothing else is happening. The display is made by Linksprite but it's basically a clone of the older generation of a display made by Adafruit: https://learn.adafruit.com/adafruit-2-8-tft-touch-shield-v2. Anyway, your overlay looks good. I would just suggest changing the pins used, the guide refers to the BPI-M64 which has different pin map to that used on your BPI-M2. Please see: https://wiki.banana-pi.org/Banana_Pi_BPI-M2_ZERO. If you replace chip select with PA13 and the data control with PC4 then hopefully it should work. You can also change the reset pin to PA2 although I am not sure if the reset line is strictly necessary. Best of luck
  13. Hi there, I see that you have enabled spidev which isn't necessary. you just need to enable just the SPI bus which can be done within the overlay. overwise it will just conflict with the ili9341. slightly amended overlay: dts-v1/; /plugin/; /{ compatible = "allwinner,sun4i-a10", "allwinner,sun7i-a20", "allwinner,sun8i-h3", "allwinner,sun50i-a64", "allwinner,sun50i-h5"; fragmen@0 { target = <&pio>; __overlay__ { display_pins: display_pins { pins = "PI11", "PI12"; function = "gpio_out"; }; display_cs_pin: display_cs_pin { pins = "PB2"; function = "gpio_out"; output-high; }; }; }; fragment@1 { target = <&spi0>; __overlay__ { /* needed to avoid dtc warning */ #address-cells = <1>; #size-cells = <0>; status="okay"; num-chipselects = <1>; display: display@0 { compatible = "adafruit,yx240qv29", "ilitek,ili9341"; reg = <1>; spi-max-frequency = <32000000>; pinctrl-names = "default"; pinctrl-0 = <&display_pins>; rotation= <90>; bgr; fps = <25>; buswidth = <8>; height = <240>; width = <320>; /*reset-gpios = <&pio 0 25 0>; */ /* GPIOA 6 */ dc-gpios = <&pio 8 3 0>; /* GPIOA 3 */ cs-gpios = <0>,<&pio 1 2 0>; /* PB2 - Linksprite shield TFT cs pin */ debug = <3>; }; }; }; Just remember to change the pins back to those used bananapiM2 as the current configuration is for my Pcduino. Also could you include a datasheet for your particular display, it would be helpful to know what pins are used for dc and cs.
  14. Hi there, I have also been trying to get an ili9341 display to work on my board as well. still learning about overlays but from what I can tell from my own test is that gpio's should be <&pio 0 6 0> and <&pio 0 3 0> in your case rather than: The first number refers to the bank so A=0 followed by the pin on that bank so 6. did you do a loop back test to see that SPI was at least working first? if so did you the check lsmod to see if the ili9341 module has loaded? should probably look a bit like this: lsmod | grep ili9341 ili9341 16384 0 panel_ilitek_ili9341 20480 0 drm_mipi_dbi 24576 2 ili9341,panel_ilitek_ili9341 Admittedly I only got as far as the modules loading but I still had a white display, I can only assume so far that there may be some kind of additional configuration file that has to be setup so that it can be used as a desktop. one other problem I noticed when upgrading my kernel from 5.15 to 6.1 was that the ili9341 driver was no longer include by default other than the fb_ili9341 which I think may be the older fbtft based driver. I ended up have to use the build scripts to include the drm based ili9341 which from what I have read is the newer driver. Hopefully this at least provided a helpful starting point and best of luck.
  15. Well I finally a solution to the kernel panic on shutdown. I added a patch based on: https://github.com/torvalds/linux/commit/544a8d75f3d6e60e160cd92dc56321484598a993 which addressed the complaint of no atomic handler. diff --git a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c index 43bd2c4f3..3d8b86742 100644 --- a/drivers/i2c/busses/i2c-mv64xxx.c +++ b/drivers/i2c/busses/i2c-mv64xxx.c @@ -150,6 +150,7 @@ struct mv64xxx_i2c_data { /* Clk div is 2 to the power n, not 2 to the power n + 1 */ bool clk_n_base_0; struct i2c_bus_recovery_info rinfo; + bool atomic; }; static struct mv64xxx_i2c_regs mv64xxx_i2c_regs_mv64xxx = { @@ -179,7 +180,10 @@ mv64xxx_i2c_prepare_for_io(struct mv64xxx_i2c_data *drv_data, u32 dir = 0; drv_data->cntl_bits = MV64XXX_I2C_REG_CONTROL_ACK | - MV64XXX_I2C_REG_CONTROL_INTEN | MV64XXX_I2C_REG_CONTROL_TWSIEN; + MV64XXX_I2C_REG_CONTROL_TWSIEN; + + if(!drv_data->atomic) + drv_data->cntl_bits |= MV64XXX_I2C_REG_CONTROL_INTEN; if (msg->flags & I2C_M_RD) dir = 1; @@ -409,7 +413,8 @@ mv64xxx_i2c_do_action(struct mv64xxx_i2c_data *drv_data) case MV64XXX_I2C_ACTION_RCV_DATA_STOP: drv_data->msg->buf[drv_data->byte_posn++] = readl(drv_data->reg_base + drv_data->reg_offsets.data); - drv_data->cntl_bits &= ~MV64XXX_I2C_REG_CONTROL_INTEN; + if(!drv_data->atomic) + drv_data->cntl_bits &= ~MV64XXX_I2C_REG_CONTROL_INTEN; writel(drv_data->cntl_bits | MV64XXX_I2C_REG_CONTROL_STOP, drv_data->reg_base + drv_data->reg_offsets.control); drv_data->block = 0; @@ -427,7 +432,8 @@ mv64xxx_i2c_do_action(struct mv64xxx_i2c_data *drv_data) drv_data->rc = -EIO; fallthrough; case MV64XXX_I2C_ACTION_SEND_STOP: - drv_data->cntl_bits &= ~MV64XXX_I2C_REG_CONTROL_INTEN; + if(!drv_data->atomic) + drv_data->cntl_bits &= ~MV64XXX_I2C_REG_CONTROL_INTEN; writel(drv_data->cntl_bits | MV64XXX_I2C_REG_CONTROL_STOP, drv_data->reg_base + drv_data->reg_offsets.control); drv_data->block = 0; @@ -575,6 +581,18 @@ mv64xxx_i2c_wait_for_completion(struct mv64xxx_i2c_data *drv_data) spin_unlock_irqrestore(&drv_data->lock, flags); } +static void mv64xxx_i2c_wait_polling(struct mv64xxx_i2c_data *drv_data) +{ + ktime_t timeout = ktime_add_ms(ktime_get(), drv_data->adapter.timeout); + + while (READ_ONCE(drv_data->block) && + ktime_compare(ktime_get(), timeout) < 0) { + udelay(5); + mv64xxx_i2c_intr(0, drv_data); + } + +} + static int mv64xxx_i2c_execute_msg(struct mv64xxx_i2c_data *drv_data, struct i2c_msg *msg, int is_last) @@ -590,7 +608,10 @@ mv64xxx_i2c_execute_msg(struct mv64xxx_i2c_data *drv_data, struct i2c_msg *msg, mv64xxx_i2c_send_start(drv_data); spin_unlock_irqrestore(&drv_data->lock, flags); - mv64xxx_i2c_wait_for_completion(drv_data); + if(!drv_data->atomic) + mv64xxx_i2c_wait_for_completion(drv_data); + else + mv64xxx_i2c_wait_polling(drv_data); return drv_data->rc; } @@ -717,7 +738,7 @@ mv64xxx_i2c_functionality(struct i2c_adapter *adap) } static int -mv64xxx_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], int num) +mv64xxx_i2c_xfer_core(struct i2c_adapter *adap, struct i2c_msg msgs[], int num) { struct mv64xxx_i2c_data *drv_data = i2c_get_adapdata(adap); int rc, ret = num; @@ -730,7 +751,7 @@ mv64xxx_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], int num) drv_data->msgs = msgs; drv_data->num_msgs = num; - if (mv64xxx_i2c_can_offload(drv_data)) + if (mv64xxx_i2c_can_offload(drv_data) && !drv_data->atomic) rc = mv64xxx_i2c_offload_xfer(drv_data); else rc = mv64xxx_i2c_execute_msg(drv_data, &msgs[0], num == 1); @@ -747,8 +768,25 @@ mv64xxx_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], int num) return ret; } +static int mv64xxx_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], int num) +{ + struct mv64xxx_i2c_data *drv_data = i2c_get_adapdata(adap); + + drv_data->atomic = 0; + return mv64xxx_i2c_xfer_core(adap, msgs, num); +} + +static int mv64xxx_i2c_xfer_atomic(struct i2c_adapter *adap, struct i2c_msg msgs[], int num) +{ + struct mv64xxx_i2c_data *drv_data = i2c_get_adapdata(adap); + + drv_data->atomic = 1; + return mv64xxx_i2c_xfer_core(adap, msgs, num); +} + static const struct i2c_algorithm mv64xxx_i2c_algo = { .master_xfer = mv64xxx_i2c_xfer, + .master_xfer_atomic = mv64xxx_i2c_xfer_atomic, .functionality = mv64xxx_i2c_functionality, }; This may not be strictly be necessary as it still failed to shutdown until when looking through the options during the kernel configuration stage of the boot I found the following option: Go to Device drivers > board level reset and power off Then select regulator subsystem power off driver Now when I shutdown the USB and 3v output are successfully turned off. I thought that I should post this on the off chance that it may be usefully to someone with an A10/A20 board.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines